3 ms·

The key has to be in memory on all of their front end servers. Do you think a quorum of engineers should get together every time a front end server boots or reb

by ses1984 4y ago

The key has to be in memory on all of their front end servers. Do you think a quorum of engineers should get together every time a front end server boots or reboots? Genuinely asking because I’ve struggled with this question.

bob1029 4y ago
I don't understand how initializing cryptographic keys from an HSM at boot time is an untenable proposition. The quorum would be for accessing the key by human means. You can have a separate, approved path for pre-authorized machines to access cryptographic primitives across an isolated network.
lrvick 4y ago
Lots of cloud instances support remote attestation these days which gives you a reasonable path to autoscaling secure enclaves. 1. You compile a deterministic unikernel appliance-style linux kernel with a bare bones init system 2. You deploy it to a system that supports remote attestation like a nitro enclave. 3. It boots and generates a random ephemeral key 4. m-of-n engineers compile the image themselves, get the same hash, and verify the remote attestation proof confirming the system is running the bit-for-bit trusted image 5. m-of-n engineers encrypt and submit shamirs secret shares of the really important private key that needs protecting 6. key is reconstituted in memory of enclave and can start taking requests 7. Traffic goes up and autoscaling is triggered 8. New system boots with an identical account, role, and boot image to the first manually provisioned enclave 9. First enclave (with hot key) remotely attests the new enclave and obtains its ephemeral key (with help of an internet connected coordinator) 10. First enclave encrypts hot key to new autoscaled enclave 11. rinse/repeat
kccqzy 4y ago
The key doesn't have to in memory on all of their front end servers. Any respectable company that cares about security wouldn't put their TLS private key on all of their front end servers anyways. You expose a special crypto oracle that your front end servers talk to; the oracle can be a specially hardened process on a dedicated server or better yet a HSM; the point is, the private key is never in memory on any server that handles untrusted data.

bob1029 4y ago

I don't understand how initializing cryptographic keys from an HSM at boot time is an untenable proposition. The quorum would be for accessing the key by human means. You can have a separate, approved path for pre-authorized machines to access cryptographic primitives across an isolated network.

lrvick 4y ago

Lots of cloud instances support remote attestation these days which gives you a reasonable path to autoscaling secure enclaves. 1. You compile a deterministic unikernel appliance-style linux kernel with a bare bones init system 2. You deploy it to a system that supports remote attestation like a nitro enclave. 3. It boots and generates a random ephemeral key 4. m-of-n engineers compile the image themselves, get the same hash, and verify the remote attestation proof confirming the system is running the bit-for-bit trusted image 5. m-of-n engineers encrypt and submit shamirs secret shares of the really important private key that needs protecting 6. key is reconstituted in memory of enclave and can start taking requests 7. Traffic goes up and autoscaling is triggered 8. New system boots with an identical account, role, and boot image to the first manually provisioned enclave 9. First enclave (with hot key) remotely attests the new enclave and obtains its ephemeral key (with help of an internet connected coordinator) 10. First enclave encrypts hot key to new autoscaled enclave 11. rinse/repeat

kccqzy 4y ago

The key doesn't have to in memory on all of their front end servers. Any respectable company that cares about security wouldn't put their TLS private key on all of their front end servers anyways. You expose a special crypto oracle that your front end servers talk to; the oracle can be a specially hardened process on a dedicated server or better yet a HSM; the point is, the private key is never in memory on any server that handles untrusted data.