In today's multi device world it's absolutely mandatory that the user's data be available on all screens at all times. Yet secure email protocols such as PGP were designed more than 20 years ago. This means that for encrypted email the status quo up until now has basically been: Either you're on the device your key is on or you’re out of luck. Like this poor sap that got an encrypted email on his iPhone:
Needless to say there are many ways to go about solving this problem. One could simply throw out the last 30 years of protocols like SMTP, IMAP and PGP and reinvent the wheel like DarkMail, but we at Whiteout believe in building on existing standards, since they aren't going away any time soon. This does not mean that we don't applaud the important work of creating a modern set of protocols for asynchronous messaging that solve meta-data security and forward secrecy. But given today's landscape, the large-scale adoption of such an approach is years away. In this post we'd like to discuss our approach at tackling multi device encrypted email.
The burden of key management
Studies have shown time and time again that if users are exposed to the complexities of managing their own keys, many will fail.
"Three of the twelve test participants (P4, P9, and P11) accidentally emailed the secret to the team members without encryption. Two of the three (P9 and P11) realized immediately that they had done so, but P4 appeared to believe that the security was supposed to be transparent to him and that the encryption had taken place. In all three cases the error occurred while the participants were trying to figure out the system by exploring." - Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0
This is why we, as a service provider for encrypted email, believe that one major way we can provide value to users is key management. Not only does Whiteout Mail automate public key discovery when typing in a recipient's email address, we also want to make private key management so easy that it becomes basically invisible to users (unless users explicitly want to dig deeper, of course).
Whiteout Key Sync User Experience - Technology Preview
DISCLAIMER: The following specification as well as the current version of the reference implementation are definitely work in progress and should not yet be considered for production use. We reserve the right to delete private keys from our sync service during the experimental phase in case we need to update our storage format or encryption protocol. We would also very much appreciate any feedback and suggestions. Feel free to tweet us or drop us an email (PGP Key).
Now that we've got that out of the way, if you're feeling adventurous you can try key sync today by installing the Whiteout Mail App and syncing your test keys between e.g. your Desktop PC and your Chromebook (Android App coming very soon). The setup process itself borrows heavily from existing products like Firefox Sync and the iCloud keychain from Apple. Both products allow users to sync their passwords and other personal data in an encrypted form.
It's important to note that multi device sync for Whiteout Mail is completely optional. We understand that there are users that would never sync their private PGP key (even in encrypted form) and we absolutely respect that. But if you do want to use Whiteout Mail on multiple devices, then here's what the user experience for Whiteout Key Sync looks like:
- The user starts Whiteout Mail on the Computer they first installed the app on. Either the app generated a new PGP key pair for the user on initial startup (default behavior for average users and first time PGPers) or the user chose to import an existing PGP key (option for experienced PGP users). The user must then activate
Key syncfrom the menu and is greeted with this setup screen:
In this step a random
keychain code is generated for the user which is used to encrypt the user’s private key on their computer before sync. From a UX perspective the code basically replaces the private PGP key, as the user must write down the
keychain code and keep it in a safe place.
The code is never shared or made available to Whiteout, so we cannot decrypt the user’s PGP key. The idea here is that the long asymmetric PGP key is replaced by a short (but still high-entropy) symmetric key, which can be written down easily and typed into a touch screen. (For all the technical details, please check out the protocol specification at the end of this post.)
- The user then installs the Whiteout Mail app on a new device. If sync was activated for his account the app will know this and ask the user for a recovery token which is sent to them via Email or SMS:
- After the user has been authenticated, they will be asked to provide their keychain code. Upon successful entry, the encrypted private PGP key will be sent to the device, decrypted locally and stored on the device.
And done! The user can now read and write encrypted messages on multiple devices.
It's important to note that this setup process is required only once when setting up the new device. This means that the keychain code can conveniently be kept in a safe place and does not have to be with the user at all times.
Now that we've briefly touched what the user experience looks like, here's a technical overview of the encryption protocol.
Whiteout Private Key Sync Specification
Importing/exporting the user’s private PGP key to their various devices is a challenge on non desktop systems such as iOS, as these system have no USB support. Current solutions such as iPGP can import the user’s private key through Dropbox, but this obviously compromises the private key to a cloud storage provider that the user has no control over. The goal of this specification is to create a secure and easy way to sync the user’s private key over a cloud service that the user does not have to trust completely.
This specification is split up into the various protocol steps required for key sync.
- The device configuration protocol MUST NOT allow multiple devices with the same DeviceSecret.
- The device configuration protocol MUST NOT allow a device to impersonate another one just with the knowledge of its DeviceSecret.
- The device configuration protocol MUST NOT allow a new device to be configured without the possession of the user's keypair.
- The device configuration protocol WILL NOT protect a user from a possible rogue server authorizing devices on the user's behalf.
- The device configuration protocol WILL NOT protect the user from an attacker stealing the DeviceSecret from the server and impersonating the device for that DeviceSecret.
Device registration will exploit the fact that both the user and the server have the user's public key, and the user has the private key. With this knowledge, the server will negotiate a set of random session keys to exchange and authenticate the data sent between the parties.
A device is referenced by its DeviceSecret and memorable DeviceName. The device secret is a globally unique random string with 256 bits of entropy that is generated using a RNG on the device to avoid collisions. The registration will proceed as showed in the flow diagrams below.
- The authentication protocol MUST protect the DeviceSecret from being reachable by a third party in transit.
- The authentication protocol MUST protect the session keys from being reachable by a third party in transit.
- The authentication protocol MUST avoid reusing session keys.
- The authentication protocol WILL NOT allow authentication without the user having possession of their key pair.
The authentication will exploit the same fact as device registration: using the public key for the user, the server will negotiate a set of session keys to secure future communications. The fact that the user will be able to decrypt the data sent from the server proves that she is the rightful owner of the account.
Authentication will have, along with the random keys, a challenge that the client needs to respond to. The test for the user is to just send the challenge string back to the server, but wrapped with a different encryption method.
Once these steps are complete, both the server and the client will have negotiated keys for this session.
- The key sync protocol MUST protect the private key from any other party that's not the rightful owner of it, even the server.
Key synchronization will be done by uploading the key pair encrypted to the Whiteout cloud storage. The key pair will be encrypted with a randomly generated key which will be presented to the user in the form of a QR code or a string of characters. This set of keys will not be uploaded to the cloud, so the key pair will be secure.
To download the encrypted key pair, the user will request the recovery token that the server assigned to the key at the time of the request. This recovery token will be sent to the user through SMS or email (depending on what is available). With it, the client can download the key pair and use the encryption keys to decipher and import it.
- Es(key, data): Symmetric encrypt with key.
- Ea(key, data): Asymmetric encrypt data with a public PGP key.
- Ds(key, ciphertext): Symmetric decrypt ciphertext using key.
- Pk: User’s public PGP key.
- session_keys: random encryption keys generated for a session.
Block cipher and message authentication
The protocol uses the authenticated AES-256-GCM mode for symmetric encryption.
Key derivation for private key encryption
The private key is encrypted with a 256 bit symmetric key derived from a high entropy code (which is generated for the user) using PBKDF2-SHA256 (10000 iterations, per user random salt).
For asymmetric encryption, PGP is used. Key size should be at least 2048 bits.