Does / Can a HSM or TPM encrypt my private keys

Question

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.

Answer 1

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).

Answer 2

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.

Answer 3

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.