-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Extracted from documentation: T3-InfoSec/t3-memassist#10
What is the Problem or Limitation?
The cards and sensitive data (e.g., SA0) need to be encrypted to protect the user’s information and maintain data confidentiality. Without encryption, the cards are vulnerable to tampering, unauthorized access, or leakage, which could compromise the integrity of the memorization assistant. EKA (Encryption Key for Assistant) must be used as the encryption key to ensure secure storage.
Describe the Solution You Would Like
The solution involves implementing a strong encryption mechanism using EKA to protect both the cards and SA0. This ensures that only authorized users with the correct EKA can decrypt and access the data. Below are the specific steps required:
-
Generating the EKA (logic already implemented):
- EKA is a 32-character hexadecimal string with 128-bit entropy, generated using a cryptographically secure random number generator.
-
Encryption of Cards and SA0:
- Use AES-256 encryption in GCM mode (or another suitable algorithm) to encrypt the cards and SA0.
- Store the encrypted data along with an initialization vector (IV) and authentication tag to ensure secure decryption.
-
Decryption Flow:
- When the user needs to interact with the cards or SA0, they must provide the correct EKA.
- The system uses the EKA along with the IV to decrypt the data. If the decryption fails, the user is notified, and access is denied.
-
Secure Storage:
- Store the encrypted cards and SA0 in the secure local database.
Additional Considerations
- Error Handling: Implement robust error handling for incorrect EKA inputs or failed decryption attempts.
- Testing: Thoroughly test the encryption and decryption logic to ensure data integrity and smooth user interactions.