TMail Backend currently allows email encryption upon receiving an email in a mailbox, based on a private key that the server do not own. TMail backend both exposes PGP encrypted emails in IMAP, as well as JMAP encrypted projections as an extension in order to build an efficient encrypted webmail. Frontend work remains to be done.
However, we remain to work on a key management architecture.
Here are our constraints:
Ideally we want it to be easy to share keys across devices
We also want to not be able to use the keys from the server side
Keys recovery should be possible by a security officer
Model 1 : the key is only on the device.
No key recovery. No data recovery. Generating the key is a user concern.
Model 2 : TMail generate the PGP keys on device side, stores it on the device, and allows a file export.
No key recovery. No data recovery.
Model 3 : TMail generate the PGP keys on device side, password protected, stores it on the server, and allows a file export.
No key password recovery. No data recovery. Key generation in Flutter.
Model 4 : TMail download the CSO public key, generates the password protected key locally, and uploads the private key, and encrypted password. (ideal)
The RSE can recover keys and thus data. Key generation in Flutter.
Backend have no way to enforce that the CSO key can be used for recovery, which might be a security concern.
Model 5 : TMail backend generates the password protected key and keep the private key, and encrypted password.
The RSE can recover keys and thus data. Key generation server side.
The key password transits via the server but is not stored, which might be a security concern.
The user have no way to bypass the CSO having a way to access his data.
chibenwa
commented
1 year ago
Context
TMail Backend currently allows email encryption upon receiving an email in a mailbox, based on a private key that the server do not own. TMail backend both exposes PGP encrypted emails in IMAP, as well as JMAP encrypted projections as an extension in order to build an efficient encrypted webmail. Frontend work remains to be done.
However, we remain to work on a key management architecture.
Here are our constraints:
Model 1 : the key is only on the device.
No key recovery. No data recovery. Generating the key is a user concern.
Model 2 : TMail generate the PGP keys on device side, stores it on the device, and allows a file export.
No key recovery. No data recovery.
Model 3 : TMail generate the PGP keys on device side, password protected, stores it on the server, and allows a file export.
No key password recovery. No data recovery. Key generation in Flutter.
Model 4 : TMail download the CSO public key, generates the password protected key locally, and uploads the private key, and encrypted password. (ideal)
The RSE can recover keys and thus data. Key generation in Flutter.
Backend have no way to enforce that the CSO key can be used for recovery, which might be a security concern.
Model 5 : TMail backend generates the password protected key and keep the private key, and encrypted password.
The RSE can recover keys and thus data. Key generation server side.
The key password transits via the server but is not stored, which might be a security concern.
The user have no way to bypass the CSO having a way to access his data.
Slides
pgp.odp
Decision
If we work on PGP encryption, deliver model 1.
Customer projects can then fund the follow up work, and help choose the appropriate model.