How Inky Stores Encryption Keys Safely
Inky now lets users send and receive encrypted emails with any mail account, just by checking a box. Every Inky user has two unique “key pairs” — one for signing, and one for encryption. Today I’m going to talk about how we manage these keys behind the scenes, and how we store them safely.
The process starts with a user — let’s call her Alice — downloading the Inky app, creating an Inky account, and adding a pre-existing email account she controls. If Alice has a Gmail account, for example, she can give Inky permission to access her account via oAuth. (Use of Inky with Gmail accounts is free, so this is a popular choice among our users.)
To set up her new Inky account, Alice creates a new user name and password. We require Alice to have a reasonably strong password, as measured by Dropbox’s state-of-the-art open source tool zxcvbn. This amusingly-named program (look at your keyboard) uses a dictionary to come up with a surprisingly accurate assessment of the amount of time an adversary would need to crack Alice’s password. If her password could be cracked in, say, less than 100 years of CPU time, we require her to make it stronger.
The reason we care so much about strong passwords for Inky is that in consumer deployments the password is the trust anchor. In other words, the entire security of Alice’s data rests on the difficulty of brute forcing her password. I’ll now explain why this is.
Each Inky user has a unique 64-byte “Inky Identity Key”. Inky randomly generates this key when the user creates a new account. This key is then used to encrypt all of Alice’s sensitive settings: her oAuth tokens, passwords for IMAP servers, private keys, and so on. So we need to be very careful to protect this key — it’s able to unlock all of Alice’s secrets!
The first thing we do to protect the key is to encrypt it with a key derived from Alice’s password. This is why Alice needs a password that is very difficult to discover via brute-force guessing: we want an attacker going through the dictionary generating random passwords to spend hundreds of years before arriving at Alice’s password.
Importantly, only Alice knows her password. Alice’s password never leaves the memory of the Inky running on her phone or desktop. We ensure this by having Inky authenticate to our servers using a Zero Knowledge Proof protocol: this is a somewhat mind-bending framework whereby Alice can prove she knows her password without transmitting any bits of the password during the proof. In short, we can be sure Alice knows her password without our ever knowing her password.
The combination of a key derived from a password that only Alice knows and a Zero Knowledge Proof authentication system give us something really cool: we can store stuff for Alice in the cloud without anybody but Alice being able to decrypt it. Specifically, only Alice knows the password from which Inky derives the key used to decrypt her Inky Identity Key. (This use-a-key-to-encrypt-another-encryption-key strategy is used so often in security protocols that it has a nickname: “KEK”, short for “Key Encryption Key”.)
But we’re not done yet. We need Alice to be able to set up Inky on every new device she buys. In order to decrypt her settings, she obviously needs to know her password, but her newly-installed Inky also needs a way to get her encrypted Inky Identity Key. So we need to store these Inky Identity Keys somewhere for all our users.
This kind of keys-for-every-user database is what security people call a “honey pot”: a very tempting target for hackers who’d like to grab a copy of the data and try to guess passwords “offline” — in the privacy and comfort of their own data centers.
So ideally, we need a way to store Alice’s Inky Identity Key — and everyone else’s — in such a way that even if an attacker, Mallory, got the database and squirreled it away on his own server, he still could not brute force guess passwords and get anywhere.
At first this seems unattainable: how can we store data in a way that we can decrypt, but that Mallory couldn’t? The answer lies with something called a Hardware Security Module or HSM.
Think of an HSM as a thumb drive. The HSM stores data, just like a thumb drive, and it plugs into the same USB slot that a thumb drive does. (High-end HSMs actually plug into the PCI slot where graphics cards go, but the principle is the same.)
The difference between the HSM and a thumb drive is that the HSM stores sensitive data like keys and it never lets the device it’s attached to read these keys. It’s like write-only storage! HSMs even have anti-tampering countermeasures that cause them to self-destruct when someone monkeys around with them.
Now you may be wondering — if the HSM never reveals the keys, how are the keys ever used? The key insight is that the HSM is itself a computing device. It has its own CPU that can perform operations with keys: decryption and signing, for example.
The punch line — which by now may be obvious — is that data encrypted with a key on an HSM can only be decrypted by that HSM. So even if Mallory gets our entire Inky Identity Key database, he still can’t decrypt the keys without physical access to one of our HSMs — which, of course, we keep in a locked data center with biometric access controls.
Conceptually speaking, by using HSMs to encrypt the keys, we tie decryption of these keys to a particular place in the physical world — sort of like turning a cryptographic lock that a million would-be lock-picks could attack in parallel over the internet into a lock like the one on your house, where lock-picking requires physical access to your door.
As mentioned earlier, even prior to the HSM-based encryption, Alice’s Inky Identity Key is already encrypted with the KEK derived from her password. The HSM-based encryption is a second layer of encryption on top of that. (For enterprise deployments, the enterprise holds these second keys, and employees don’t need to remember passwords — but the method is otherwise identical.)
So now that we have a way to store a strong symmetric encryption key for Alice — in a way that prevents anyone from decrypting it but Alice, even with offline access to it — we have just what we need to securely synchronize email encryption and signing keys between all of Alice’s devices. To us, Alice’s email keys are just binary data we can store in the cloud on Alice’s behalf. But an Inky that Alice has logged into can easily decrypt these keys and use them to sign and decrypt Alice’s email.
See also: Inky Security White Paper
