2

I'm still not completely sure about the role of using an HSM or TPM on a device when it comes to storing private keys for security purposes.

My use case would be using TLS with an embedded device which contains a unique self-signed device certificate signed by a root CA private key. The device authenticates itself on AWS using the device certificate and uploaded root CA certificate.

The device therefore has two private keys which nobody should ever get access to.

Does an HSM or TPM completely decrypt these keys and store them? However, what happens when the software needs these keys for the authentication process? If it obtains the TPM or HSM for the keys, surely they will be decrypted and a hacker could then access them if they got into the system? Thanks in advance.

5

Let's do a thought-experiment.

Imagine a device whose purpose in life is to hold a private key. There are a couple of things it will do for you; you can ask it:

  • Please wipe your own memory and generate a new private key.
  • Please give me the public key associated with your stored private key.
  • Please use your stored key to sign or encrypt this data.
  • Please use your stored key to verify or decrypt this data.

Now imagine this device has been built to military spec so that you cannot remove the casing and remove the RAM sticks without completely and utterly destroying the device and all data on it; you cannot use x-ray or magnetic spectroscopy to learn anything useful about the CPU as it is running. Yes, there are private keys in there, yes the device will happily use them for you, but you are never getting the raw private keys out.

HSMs (separate device over ethernet / USB) and TPMs (separate chip over motherboard bus) have grown to do more than what's described here, but the list above is their core function. Most but not all HSMs / TPMs use the PKCS11 API, which is standardized here, though some devices use a custom API.

The security model for an HSM / TPM is that if an attacker can get onto your running system, they can use your keys, but they cannot extract your keys and walk away with them. That means that during an attack, at least it's possible to power down the infected device, cut network access to the HSM, etc, and you know the attack is over. The attack was also done on your system where you will presumably have logs to trace what the attacker did with your keys.


Also, minor quibble: "contains a unique self-signed device certificate signed by a root CA private key". If it's signed by a root CA, then by definition it is not self-signed (unless you're directly using the root CA as the device cert).

2
  • thank you for that minor quibble, my OCD went "bing" and my head exploded.
    – rip...
    Jun 3 at 0:10
  • 1
    Also, would add PCIe for the HSM list. Most HSMs support multiple APIs, PKCS11, their own, CSP, CNG, EKM, a few others. And most Crypto systems (Bouncycastle, etc) allow you to hook an HSM in underneath, so you are using their normal API but hitting the HSM for the actual crypto operations.
    – rip...
    Jun 3 at 0:12
1

TPM and HSM's has key hierarchies that encrypts your private key. For simple understanding you can say it "Master Key". Master Keys are generated and stored within the TPM and HSM itself and are never exposed to any software, process or user. All operation related to these keys happen inside TPM and HSM.

TPM and HSM are also hardened w.r.t physical attacks so even if someone got the access to HSM or TPM chips they are fairly secure. Even the operations of decryption are fairly secure.

So, even if you are performing decrypting operations in TPM and HSM and someone has access to your system they can at most use the keys inside the system but cannot get the key outside of system assuming there are no known hardware vulnerability present on TPM and HSM hardware's.

0

Adding some color, please see Mike Ounsworths answer.

You said: The device therefore has two private keys which nobody should ever get access to.

This is incorrect. The device has ONE private key, and one other certificate (the root CAs). A certificate is NOT a private key, it is an attestation that the signature it contains was generated using a private key, said private key having the public key that is also contained in the certificate. Ie, the cert is a reference with a public key.

You asked: Does an HSM or TPM completely decrypt these keys and store them?

This is actually implementation dependent. In most cases, an HSM stores the keys in an encrypted form, using some sort of device master key (also implementation dependent).

A TPM doesn't (usually) even store the keys. It encrypts them (device master key again) and spits it back you. You store it someplace. When needed, you hand the encrypted key to the TPM along with a command and some data, and the TPM decrypts the key, does the operation and returns the result.

And the keys are never available outside in the clear, only available outside encrypted. You send the key and the operation and the data and get back the result.

11
  • I'm fairly certain the device has two private keys - one for the root CA and the other for the actual device certificate. Jun 4 at 3:00
  • I'm fairly certain the device has two private keys - one for the root CA and the other for the actual device certificate. My device works as follows : When it boots up, it checks if device certificates have been generated. If not, a device certificate gets generated, signed with the root CA private key and verified on AWS. AWS verifies that my generated device certificate is genuine by using the uploaded root CA public key from the CA certificate for this authentication. This is the only time however that the root CA private key is required, when first generating and registering a new device. Jun 4 at 3:24
  • Then when the device gets registered on AWS, the private key for the device certificate is used for authentication during the TLS handshake, when a session starts between the device and AWS. So would you agree?.. two private keys are actually required here. Jun 4 at 3:26
  • Please edit the original post to be explicit with what you have. "...an embedded device which contains a unique self-signed device certificate signed by a root CA private key..." can absolutely not be true. If the device cert is self-signed, then it is signed with the private key that the certificate is attesting. That is what "self-signed" means. Now, your device may very well have a "root" CA key, and if this turns out to the be same root CA key as on every other device of this class, that is a significant security Fail. So: paint us a picture in the original post.
    – rip...
    Jun 5 at 18:42
  • And remember: A "certificate" is NOT NOT NOT a private key. It is a reference to a private key that is held someplace else.
    – rip...
    Jun 5 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.