Secure Provisioning: The Typical Workflow

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, Part IV Identity: Digital Signatures and Certificates, or Part V Why is a Hardware Security Module Trusted?, you can catch up here.

Secure Provisioning Workflow

Earlier in this series we covered cryptographic functions. So, with this newly gained knowledge let us examine, in detail, how these are used in the typical workflow of secure provisioning.

• CUSTOMER CONTROLLED ACTIVITY
• SECURE PROVISIONING SERVICE
• NON SECURE COMMUNICATION CHANNEL

1. Software Development

Using a software development tool, we design and test our software for our connected product and generate a binary file (see Figure 2). EPS Global can advise on tools available that dramatically simplify the secure provisioning process described herein. This binary file that is output from the development tool represents our valuable intellectual property (IP) which we need to program into the target microcontroller that we have selected as the heart of our product. Depending on the type of tool-chain used, we also create a RoT configuration file. This file has a custom format and is dependent on the development tool and provisioning service used.

Figure 2: Software Development - Creating the IP

This file is used by the programmer to determine how to program the RoT into the target microcontroller. It includes information such as target microcontroller part number, number of cryptographic keys and certificates to be provisioned (including lifecycle management keys), bootloader firmware, lockdown settings (debug & JTAG disable) and other configuration data.

2. IP Packaging

To protect our valuable IP, it is necessary to encrypt our binary file in order to keep it secure during manufacturing. However, we have learned that there are other cryptographic processes required to ensure that the IP has not been tampered with during transit and that it can be authenticated. We also need a target HSM to manage the decryption of the IP and carry out the integrity check and authentication process. To encrypt the IP for the target HSM we need the public key of the HSM. This is delivered to us by EPS Global, the chosen secure provisioning service provider, as they own the programmer that includes the HSM. EPS sends us the certificate of the allocated HSM/programmer (see Figure 3).

Figure 3: HSM Certificate

We cannot encrypt the binary file using the public key of the HSM, since a symmetric key is needed for large data encryption. So, how do we package the binary file for the HSM? The mechanism is dependent on the service provider, software development tool-chain used and HSM functionality. An example of a mechanism that can be used is shown below. We looked at an example of how to package the binary file for the HSM in Part V of this series in case you want a refresher.

3. Transfer Package to EPS Global

The encrypted package can be sent to EPS over an unsecured communication channel (see Figure 4). Why, you may ask, is that? It is because the data can only be decrypted by the target HSM as the target HSM holds the private key that will give it access to the symmetric key (for binary file decryption) and customers public key (for integrity and authentication checking). In addition to the package, the customer may also send details of the number of target devices that need to be programmed. Ideally, the number of devices to be programmed should be authorized by the sender and digitally signed. Some Service Providers have HSM's that include a production count function which prevents over-production and cloning of devices using this mechanism.

Figure 4: Transfer encrypted package to EPS Global

4. Secure Provisioning

EPS Global loads the encrypted package into the HSM. The authorized programmer operator* allocates the number of devices authorized by the job and starts the programming process. During the process, the HSM uses its private asymmetric key to decrypt the keys from the encrypted package. It decrypts the digital signature and verifies the integrity and authenticity of the encrypted package. The HSM then uses the customer symmetric key to decrypt the binary and RoT configuration files. Using the RoT configuration file and the binary file, the HSM then instructs the programmer to program the target device (see Figure 5). If the RoT configuration file has a requirement for an identity key pair to be provisioned, the HSM will generate a unique key pair per target device. During provisioning, the private key will be sent to the programming head to form part of the RoT. The HSM also generates a certificate that includes the public key of the identity key pair. This certificate is signed by the HSM using a PKI private key and can also be provisioned into the target device as part of the RoT. Part of the provisioning service is to supply the customer with all the device certificates created during the manufacturing process. The device certificates are important when the products are in the field and need to on-board to a cloud service as they provide the means for authentication of the product.

Figure 5: HSM decrypts package and provisions devices
*Our programmer operators

Conclusion

We said it at the start of this series, but it's worth saying again - Security is a complex subject with many specialty areas such as cryptography, public key infrastructure, digital certificates, HSMs etc. At EPS Global we have invested in technologies, both software and hardware, that use these techniques to implement systems that can protect our customers' valuable IP. We have taken care of the heavy lifting when it comes to using these technologies and can provide our customers with easy-to-use tools that greatly simplify the process of ensuring security during manufacturing. Support services are available for customers who may wish to use their own certificates or alternatively for those wishing to use 3rd party certificates.

Development engineers can reduce the stress of designing complex security systems by specifying the use of Secure Provisioning early on in the design of their products. With the hard work, risk and investment in the technologies that enable end-to-end security having been taken care of by EPS, development engineers and their managers can be confident that their valuable software is not stolen, cloned or over-produced during the manufacturing process.

And this concludes our 6 part series on Secure Provisioning: Essential Security Measures for the IOT. Thank you for reading, we hope you have found it useful. If you have any questions or projects you would like advice on, don’t hesitate to get in touch. We are ready to help.