,
14 tweets,
3 min read
Read on Twitter
At re:Inforce we revealed two previously unannounced AWS network encryption features. One is embedded in our Nitro hardware security system, the other is for network links. But I want to take a second to zoom in just on multi-party key distribution ...
The root of trust in any cryptographic or authentication system is usually based on one or two things: key distribution, and high-quality randomness. With Nitro we also have our own high-quality hardware secure random number generators. Key distribution is a harder problem.
If your system depends on asymmetric keys; RSA, ECDSA, Ed25519, etc. then best practice is to generate public-private keys on a secure system and then only export the private key. This is a good practice but it comes with some challenges.
Firstly, you likely have to have a whole PKI infrastructure to make that practical. We do make it easier than ever to have a private certificate authority: aws.amazon.com/certificate-ma…
Secondly, RSA, ECDSA, Ed25519, etc, aren't great with respect to Post-Quantum Security, which people are worrying about. There are fixes; they can supplemented with hybrid algorithms, and static pre-shared keys, but those need a way to share those keys.
Thirdly, and most mundanely, sometimes you just need the same key on multiple hosts. That means we need a key distribution system! But key distribution systems make for very rich targets. That's not something to do lightly.
The best answer here is to use a secure Key Management Service. We have aws.amazon.com/kms/. KMS uses envelope encryption and support for bootstrapped mechanisms such as instance role accounts to get around all of this.
With envelope encryption, there's a hierarchy of keys that encrypt other keys, ultimately protected by a hardware root of trust, which mean that KMS can distribute keys without ever having plaintext access to the keys themselves. Very cool. O.k. but ...
VPC Encryption and our Lever Link Encryption project sit at the very bottom of the AWS networking stacks. And KMS runs on top of this! We'd have a circular dependency if we "just" used KMS, so how do we achieve the same security properties?
We distribute multiple "pre-secrets". One is distributed in a dedicated key distribution system. The other is distributed using existing configuration distribution systems. These "pre-secrets" are then mixed, using the HKDF key derivation function to make the actual key.
This is incredibly simple; but it has the effect that if the pre-secrets in the key distribution systems become known somehow, that's not fatal to the system security, it doesn't disclose the actual keys we use.
This technique works trivially for symmetric keys, but can also be used with a deterministic key generation algorithm to generate the same asymmetric keys on multiple hosts, without central knowledge.
Boring, simple, patterns are re-assuring in cryptography and I really love this one, because for very little cost, it gives a very meaningful security property. It really surprises me that it isn't more common pattern.
O.k. when I wrote "only export the private key" I *cough* meant "only export the PUBLIC key"! /end-of-thread
