internally generating private keys that will never see the light of day

[0Grit]

This is an excellent article.

The only thing that could be explained better is the concept mentioned in the overview, third paragraph last sentence.

"To this end, we urge the use of Hardware Secure Modules (HSM) capable of internally generating private keys that will never see the light of day."

The first path I've gone down implies the following

• technician Z signs intermediate CA certs for each device and installs them into the device.
• The device's intermediate CA private key is secured via the device's HSM
• The device ships
• When Iot Hub device provisioning occurs, the HSM using the private key signs a leaf certificate, and provides it to the DPS client running on the device

My original thinking was that Technician Z can't spoof the device because the device because Technician z doesn't know the private key of the leaf the the HSM signed.

However then I considered the following:

• Technician Z copies the private key of the Intermediate CA loaded into a device
• Technician Z makes a leaf certificate with witch a spoofed device can be registered with DPS

How does the HSM generate a private key or certificate that Technician Z can't take advantage of and will never see the light of day?

My best guess is:

• Technician Z will generate a leaf certificate and load it onto the device
• The HSM has been loaded with a certificate signed by the HSM's manufacturer
• The trusted public root of the HSM and the trusted public root of company X are uploaded to DPS
• The private key that Identifies the HSM along with the private key stored in the device are somehow both used to sign a challenge sent by DPS
• The device is considered authentic because it has been 'co-signed' by an intermediate CA of Company X and the manufacturer of the HSM

??????

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4229389d-0ea1-9f7b-db38-049ab3beecc1
• Version Independent ID: 2d979405-e7cc-a522-d736-2fa563a777ff
• Content: Concepts of Azure IoT Hub X.509 security
• Content Source: articles/iot-hub/iot-hub-x509ca-concept.md
• Service: iot-hub
• GitHub Login: @eustacea
• Microsoft Alias: eustacea

[0Grit]

Then again...

Technician Z could just spoof the device by loading the cert and key into another device with the same HSM model and manufacturer.

So the the manufacturer of the HSM would need to sign the HSMs specifically for company X.

Either way it would be nice to have cleared up whatever is implied by

To this end, we urge the use of Hardware Secure Modules (HSM) capable of internally generating private keys that will never see the light of day.

[Mike-Ubezzi-MSFT]

@loverdeg-ep Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

[eustacea]

Hi Mike, Both are good and rational thought paths but suffer from the fair and reasonable assumption that the private key is injected into the HSM. In fact, injecting private keys into HSMs has been the prevalent method in the past until the emergence of some supply chain challenges around trust with key handling. So rather then injecting the private key, newer HSMs internally generate a random number that is used as the private key. The Public key corresponding to the generated private key is then computed internally by the HSM using the asymmetric-key algorithm (e.g. ECC) and then emitted. The CA then signs the public key to create the device certificate. With a good HSM having a strong RNG nobody should be able to extract or guess the random number which in essence is the private key. The private key never exists outside of the HSM and truly never sees the light of day.

A CA certificate is then registered to a service like DPS and used for device attestation.

Cheers!

Eustace

[0Grit]

@eustacea excellent, thanks! I'd love to see that detailed in this article's text and diagrams.

Is there any way to prevent the technician form signing additional unauthorized devices? If so, is my assumption that the easiest path would be to get the HSM manufacturer involved?

[eustacea]

Unauthorized signing of devices is another emergent supply chain challenge being addressed in different ways. Suffice it to say the solution takes more than just cryptography or PKI.

• Depending on the HSM technology, rather than giving Technician-Z a signing key (which enables unlimited signings), Technician-Z could be provided an HSM enabled physical token containing the signing key and internally uses the key for signing. Tokens designed for this purpose are also enabled with hardware monotonic counters to control/limit number of signings.

• Another solution is the enable the cloud platform with information to accept only authorized devices. On Azure IoT, the Azure IoT Hub Device Registry helps with such secure accounting.

BTW, the ability of an HSM to internally generate/use/manage private keys is not a common feature in HSMs and mostly available in proprietary offerings, and details are best gotten from respective HSM Manufacturer. "Are private keys internally generated or injected into the HSM?" is a good question starting question to find out if an HSM under consideration is of the type that never emits knowledge of it's keys.

Thanks, Eustace

please-close

[vasivara-MSFT]

@loverdeg-ep We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.