Home > News & Blog > Why is a Hardware Security Module Trusted?
Why is a Hardware Security Module Trusted?
Part V Secure Provisioning: Essential Security Measures for the IOT
Incase you missed Part I - What is Secure Provisioning?, Part II - Encryption: Symmetric and Asymmetric Keys, or Part III - Building a Hardware Root of Trust, or Part IV Identity: Digital Signatures and Certificates, you can catch up here.
Hardware Security Module
Once we have encrypted our software to ensure it is protected from intrusion, how is it decrypted and programmed into the target device? Do we simply send it to a programming house with instructions on how to decrypt the file and load it onto the programmer? Obviously, not.
This is where one of the most important components of a secure provisioning system comes into play and that is a Hardware Security Module or HSM as they are more commonly referred to. A HSM is a special 'trusted' computer performing a variety of cryptographic operations such as key management, key exchange, encryption/decryption etc. A HSM is trusted because:
- a) It is specialized hardware that is well-tested and certified in special laboratories.
- b) It runs on a security-focused operating system.
- c) It has limited access via a network interface that is strictly controlled by internal rules.
- d) it actively hides and protects cryptographic material through tamper resistant mechanisms.
In our secure provisioning system, we must ensure that it is only the HSM that is capable of decrypting our software. To do this, we use the HSM's certificate which gives us access to its public cryptographic key. With this key we can create a process whereby only the target HSM can access the secret data using its private key (see Figure 4).
An important aspect in the design of the secure provisioning system is that the HSM should be integrated into the programmer and mounted in such a way that it is difficult for a bad actor to access the interface between the HSM and programming head. Most microcontrollers today do not have a mechanism to pass programming data to the bare-metal over an encrypted interface (JTAG for example). This presents a small weakness in the system as the communication between the HSM and the programming head is not encrypted, i.e. the software we are trying to protect is in the clear. Newer secure microcontrollers from Renesas solved this weakness by introducing boot mechanisms that can accept encrypted data which is decrypted by the bare-metal CPU and flashed into internal memory, well away from prying eyes.
Example of How to Package the Binary File for the HSM
To manage the secure provisioning process, we generate an asymmetric key pair and a symmetric key. Generation of cryptographic keys is possible using tools such as OpenSSL. It is important to reiterate that both the private part of the asymmetric key pair and the symmetric key used for secure provisioning must be kept secret by the customer (see Figure 1). It is also important, for added security, that the development tool-chain allows customer generated keys to be used in the system. Additional keys may be required by the software development tool for product life-cycle management. Providing a mechanism to allow software updates to a product that has been deployed in the field is an important aspect of maintaining security. The key usage mechanism for software updates differs between software development tools. Details of the software update mechanism will be provided by the software development tool vendor.
We use the symmetric key to encrypt the binary file and the RoT configuration file. We use the symmetric key as the data to be encrypted can be large (see Figure 2).
Using the process shown in Figure 3, we use the customer private key to create a signature. This enables the HSM receiving the encrypted data to check the integrity of the binary file and its authenticity i.e. signed using the customer's private key. The HSM will use the customers public key to check authenticity.
In order to securely transport all the necessary keys to the HSM (symmetric key, customer public key and any additional software update keys), we use the HSM's public key that we extract from its certificate, delivered via the service provider (see Figure 4). Only the HSM's private key can extract the keys once delivered.
The next part in the Secure Provisioning: Essential Security Measures for the IOT we will be taking a detailed look at the Secure Provisioning Workflow, including Software Development, IP Packaging, Package Transfer and Secure Provisioning itself.
In the meantime, if you have any questions or require secure provisioning services get in touch, we have local engineering and sales teams ready to help. You can find a full list of our locations here.
Alternatively if you have any questions or would like us to focus on additional topics around IOT security and provisioning in future blogs, don’t hesitate to let us know: programming@epsglobal.com.
Til next time…
