Many good conversations about cryptography have ended badly after someone asks this: “How are you managing your keys?” Bad key management undermines even the best cryptography.

Why? Because if the bad guy gets the key and the encrypted data, they get the unencrypted data. It’s as simple as that. There are three important things to consider in good key management: generation, storage, and communication of keys. Each of these are a field of study in and of themselves. We’ll provide a quick overview.

This article is part of our Security Guide series – Encryption for Developers. Read more in that series of in-depth technical articles on getting encryption right in your application.

Key Management: Generation

Randomly generated keys are very secure, but they have to be stored somewhere. Be sure to use a cryptographically secure random number generator, not just any rand() function. Each algorithm requires keys of a specific size and shape. For AES, a completely random 128 or 256 bit key is appropriate. For RSA and ECC, a complicated mathematical relationship dictates the rules for key generation. Occasionally, we see internet-wide vulnerabilities because of a systematic non-randomness in key generation.

Key size varies greatly per algorithm and type of cryptography. Asymmetric keys are often much larger than symmetric keys. Compared to everything else, this is a relatively easy decision since the standard key sizes for most modern algorithms is secure.

You can also derive cryptographic keys from user-generated passwords. This is convenient because you don’t have to store them, but they are strictly less secure. Depending on how good the user is at thinking up passwords they vary from “pretty secure” to “not secure.”  Password-based key derivation is a good approach if the security of the cryptography and of the account are the same anyway. You must use a proper password-based key derivation function. We see too many instances where the password itself is truncated or padded to 128 bits and used as the key. Big no-no because this makes it very fast to brute force the key.

Key Management: Storage

If you’re encrypting data for storage, it’s tempting to store the key in the same database as the encrypted data itself. This completely undermines the encryption. It’s just bad key management. A variation on this mistake is to put an encryption key in the code itself. This is OK if you want to add some slight obfuscation technique, but it is not encryption.

It is better to use a key management system like a hardware security module (HSM), hardware enclave, or Key Manager. For instance, on iOS and some versions of Android, there is a key management subsystem that programmers can use. It is tied to a hardware enclave used to protect the key from even root-level vulnerabilities. The user’s biometric or password unlocks the enclave, so the programmer doesn’t have to worry about that.

Key Management: Types of Key Storage Systems

Many key storage systems like hardware enclaves and HSMs provide two modes of operation: 1) Generate a key in the enclave and ask the enclave to perform your cryptography. This is nice because you never have to handle the (private) key again. It will not be hacked out of your application because your application doesn’t have it. 2) Generate a key in your application, ask the enclave to encrypt it, and store the encrypted key e.g. in your database. This isn’t as strong as option 1, but may be more convenient. Cloud services like AWS have HSM wrapper tools like KMS to make HSMs easier to use in this mode.

Not all of these systems support the same algorithms, so plan ahead. For instance, if you want to encrypt something in an HSM and decrypt it on a secure enclave in iOS, you need to make sure that they both support (and let the programmer access) the same algorithms. Most things support AES-GCM now-a-days, but this is harder than it seems, particularly for asymmetric encryption, which varies more.

Registering and Communicating Keys

If there is any communication in your encryption, you will need a method for registering the key and for looking up which keys are associated with which users. This is a tricky part of key management; communicating a shared or public key presents a bootstrapping problem.  This can be relatively easy to solve such as a scheme where you send the user public key during signup and store it in their user record. Or it can be relatively hard such as a situation where two end users need to exchange keys without trusting any third party (such as the programmer!)

The bootstrapping problem: you need a secure communication channel to share the key, but you need to have already shared the key to establish a secure communication channel. There are a few strategies for this:

• Certificate Authority: This is the trust model of HTTPS, also known as Public Key Infrastructure (PKI).
• Trust on First Use: The first time you encounter the system or user, you trust the public or shared key. For instance, this is how SSH often works (when identifying the server) or when a user registers and sets their password or public key.
• Pre-Shared Key: The two systems can be given the same key, e.g. during the manufacturing process or during configuration.
• Out of Band Verification: For instance, two friends who want to communicate can call each-other up on the phone, make sure they’re talking to the right person, and read their public keys to each-other.
• Key Rotation: It’s worth mentioning at this stage that keys need to be rotated periodically, either because they have to be replaced after being used too many times (as with AES-GCM), because they got stolen by a bad guy, because they got lost, or because the algorithms changed. If you already have a secure channel established, you can often use that to rotate the key, but not if the key is lost.

User identity and authentication (password, biometrics, 2FA) isn’t strictly about the key management, but it’s caught up in all this. If your encryption relies on authentication (e.g. you release the user key when they log in) then encryption will only be as strong as your authentication no matter your approach to key management. Depending on your use case, that may be unavoidable, but keep in mind that authentication is typically orders of magnitude weaker than encryption. Additionally, you should consider that your attacker can circumvent authentication.

Have questions about Key Management? Contact the team at Tozny for information about how our TozStore platform takes care key management for our clients. Better yet, schedule an appointment with one of encryption experts to discuss your specific security needs!