3 ms·

Keys like this should never be used by a team. They should never touch a developer or devops workstation. They exist in prod only inside of an HSM. High perfor

• wahern 3y ago
  > Keys like this should never be used by a team. They should never touch a developer or devops workstation. That's the point of KeyMux: keys never leave a secure enclave. In fact, KeyMux has no logic to load private keys or to perform key operations in-memory, except in the context of ephemeral TLS. The TLS layer does support using HSM keys for mTLS authentication, so you can use a security token for peer mTLS authentication to a network attached HSM. That's the whole point--you can use all the tools built and commonly used with in-memory keys, but using enclaved keys, instead. A follow-on idea I'd like to spend time on, if I have the chance, is to write modules for Vault and/or some KMIP implementation that integrate with the app so that authorization for key operations on a networked-attached key store require the consent of multiple parties (with that consent using local secure enclave-based authentication, of course). So, for example, if you're going to roll a release, one developer or an automated pipeline submits the request but the signing awaits confirmation from other team members.
• tatersolid 3y ago
  > High performance HSMs capable of handling 10k+ transactions/second are well within the price range of a well funded startup. Microsoft knows this, and even offers HSMs as a cloud service. HSMs simply don’t scale up to something the size of azure AD. Even if you could use 10K+ of them in a global cluster, copying keys between HSMs inherently exposes the master keys anyway. And how do you secure access to the HSMs, with another secret shared on every validation server? Turtles all the way down.
  • viralpoetry 3y ago
    > copying keys between HSMs inherently exposes the master keys anyway that's not true, even with their BYOK you export the key from one HSM under a shared key and then import it to another device