Storage of certificates and keys in hardware security modules (Use-case TLS)

Question

I am interested in the general security goals for public key cryptography and the different elements of it.

Outline of the use-case:
My use case is an embedded device, which will use TLS to establish secure communication between a server and a client (the embedded device). Furthermore, TLS is used with a mutual-authentication handshake, which requires also a client certificate. The embedded device contains a hardware security module (HSM) for efficient crypto-operations and safe storage.

The following elements will be present in the embedded device to enable the TLS communication:

1. TLS root certificate from CA (including its public key) to authenticate the server
2. Client leaf certificate (including its public key)
3. Private key of the client leaf certificate

We can assume that the storage space of the HSM is large enough to hold all elements 1, 2 and 3 at the same time.

My question now is, what elements should be stored inside the HSM?

1. Root certificate:
   No need for confidentiality, as this information is publicly available, as the root certificate will be installed in any device that wants to participate in the PKI.
   But what about integrity? I guess there a security problem if such a root certificate is tampered with (or exchanged) to later allow to authenticate initially not trustworthy leaf certificates from a visited malicious website. Do I have a benefit to store the root certificate inside the HSM, or is it simply enough to not provide any Interface in software to change the certificate stored in the normal memory of the device?
2. Client certificate:
   Also here we do not have the need for confidentiality in my opinion, because the certificate is sent unencrypted to the server during the mutual-authentication TLS handshake. Should we put the whole certificate into the HSM together with its private key? Is there an attack scenario, which could be mitigated if the certificate itself was stored inside the HSM?
3. Private key of Client certificate:
   This one I am 100% sure about. The private key needs to go into the HSM to increase the security.

Rephrasing everything in one sentence:

Private keys should be stored inside an HSM, if available, but is there any benefit of storing also certificates (containing their public keys) inside an HSM?

EDIT:
In my understanding the HSM in this use-case only provides a security benefit for storing private keys. However, I have read in many instances about storing certificates inside an HSM. I am just not sure, if such statements are because of sloppy wording or if there is actually any benefit of storing a certificate inside an HSM. Examples: A, B, C

Answer 1

The key thing to understanding the difference is to realize that you don't care directly about the security properties of the key. They're just a tool to ensure the security properties that you care about, which come from the use of the key.

If you need to keep an asset confidential for indirect reasons, then there is a benefit in keeping it in a high-security area that only allows the asset to be used in a specific way. For example, suppose a private key is in an HSM which allows a computer to sign or decrypt with this key¹, but does not allow the computer to extract a copy of the key. If the computer is compromised but the HSM isn't, then the attacker can use the key, but these uses will be recorded in the HSM log, so you have some information about the consequences of the breach. Furthermore, if you regain control over the computer, you know that the attacker cannot use the key anymore; this is typically not so useful for a signing key (unless the HSM logs tell you that the key hasn't been used) but it is useful for a decryption key.

If you need to protect the integrity of an asset for indirect reasons, it's another story. Consider again the computer+HSM setup, this time with a public key or a certificate in the HSM. After a recovering computer compromise, you know the attacker has not been able to modify the copy of the certificate in the HSM. That doesn't really help you, because you needed to restore a lot of data from backup, including the copy of that certificate. While the attacker has access to the computer, it doesn't matter that the certificate is in the HSM. If the attacker is bothered by that, they'll just modify the code on the computer to not access the HSM.

Using a trusted place to store a copy of data whose integrity is required is important, but you don't need an HSM for that: that's what backups are for. If you can't guarantee the integrity of the code that manipulates the data, you dont gain anything from better protecting the integrity of the data.

Thus, in your case, you definitely should put the private key in the HSM (3). There's no benefit to putting certificates in the HSM for normal operation (1, 2), but it might help you recover after a breach if you're somehow able to regain control of the device. The certificates alone aren't enough, but they might be part of a larger root of trust that includes all the code needed to boot the device in a trustworthy state.

¹ _{It shouldn't allow both with the same key.}

Answer 2

This question is barely related to security. From security perspective, public certificate store in HSM doesn't improve security since public certificate doesn't contain any sensitive information and itself is protected with digital signature. In other words, if HSM space allows, you can store public certificate there. Think like a storage for certificate.

But bear in mind that it doesn't add any extra security.