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

This is what HSMs (separate device over ethernet / USB) and TPMs (separate chip over motherboard bus) are designed to do. That list of things you can ask it to do is defined by the device's API; most but not all HSMs / TPMs use the PKCS11 API, which is standardized here.

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

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