Blog > IoT > Manufacturing protection: Provisioning IoT device secrets

Manufacturing protection: Provisioning IoT device secrets

by | Oct 20, 2022 | IoT, Security | 0 comments

Manufacturing protection: Provisioning IoT device secrets

Manufacturing Internet of Things (IoT) devices involves installing sensitive material (e.g.: keys, certificates, IP etc.) on the device. Secure provisioning of these secrets requires processor/hardware support along with special tooling or software. Using NXP i.MX8 manufacturing protection (MP) feature as an example, we illustrate how device manufacturers can:

  • Provision trust and device secrets securely (e.g.: disk encryption keys, certificates etc.)
  • Protect IP when using an untrusted contract manufacturer (CM)
  • Prevent product counterfeit
  • Detect “unauthorized production” or “overproduction”
  • Verify the processor / SoC authenticity

 

Manufacturing protection feature overview

Secure and encrypted boot helps ensure that the executing software is authentic and unreadable. However, they do not provide a solution for installing sensitive data to a new product. In the absence of a mechanism, sensitive data (e.g.: disk encryption keys) is typically kept unencrypted in the target device image or in the manufacturing flash tools. This can be easily stolen and can be used to compromise the device or counterfeit the product.

The manufacturing protection feature allows original equipment manufacturer (OEM) to securely download secrets onto the device by using an OEM-specific public/private key pair generated on the i.MX8/9 processors. There are two different workflows that can be used for network devices and non-networked devices.

 

What is the workflow for networked devices?

In this workflow, devices are first authenticated with an OEM provisioning server using i.MX manufacturing protection keys and then encrypted secrets are securely downloaded. This mechanism also allows tracking of “unauthorized production”.

 

What is the workflow for non-networked devices?

For non-networked devices, devices are directly flashed with secrets encrypted using i.MX manufacturing protection keys. This mechanism does not allow for tracking “unauthorized production” (e.g.: cloning) but secrets are still kept safe.

 

In the below sections, we will illustrate more details on the process.

 

How do you implement the Manufacturing Protection Feature on networked devices?

For devices that have a network interface, the workflow is as follows in the diagram below and illustrated in the below six steps.

During product development time, the OEM extracts the MP public key from the device which will later be used to authenticate the device during production. The OEM / device manufacturer is responsible for setting up a secure provisioning server in which the public key is stored.

 

Step 1: Enable manufacturing support on a reference chip with known provenance
Step 2: Export / store MP Public key
  • Use the u-boot “mfgprot pubk” command or OP-TEE Linux client example to extract the MP public key.
  • Store the MP public key on the OEM provisioning server.

During production, the OEM creates a signed provisioning image with secure boot and manufacturing protection enabled. The device software includes a client software that can connect to the OEM provisioning server securely over TLS and send an authentication message. Once authenticated the client software is responsible for downloading secrets from the server and storing it on device secure storage.

 

Step 3: Create provisioning image
  • OEM creates a signed provisioning image with MP and Secure boot enabled along with fuse configuration (SRK hashes etc.).
  • Contract manufacturer (CM) downloads images to the programming PC.

 

Step 4: Program devices
  • CM flashes images and fuse configuration.

 

Step 5: Authenticate device(s)
  • Client running on the device will create a “Unique ID” (e.g.: serial number) and sign it with the MP private key and send it to the OEM server.
    • Typically additional metadata such as SRK hash, software version etc. can be appended to the data to be signed. This allows for verifying additional aspects of the software running on the device.
    • The signing feature is only available to authenticated software with MP feature enabled.
  • OEM provisioning server verifies signature using MP public key; ensures the Unique ID is not previously seen by the server.

 

Step 6: Download keys / secrets over TLS
  • OEM provisioning server sends additional secrets (e.g.: disk encryption keys, cloud connection keys, device certificates etc.) securely over TLS.
    • Device stores the secrets onto secure storage based on hardware root of trust (e.g.: CAAM blob or OP-TEE secure store).
  • Additionally download proprietary software or reflash with final signed production image.

Note: Client / Server software not provided by NXP.

 

Security aspects to consider for networked devices

The above process is secure for the following reasons:

  • The MP private key is unreadable and unexportable, so attackers will not be able to get ahold of the private key to spoof a signed message.
  • To be able to create a valid signature, the following needs to happen:
    • The NXP part is genuine.
    • Authenticated software is running on the device.
      • OEM SRK fuses are flashed and secure boot is enabled.
    • MP feature is enabled in software.
  • The OEM provisioning server can additionally check for “unauthorized” production by implementing a serial number range/uniqueness check along with other metadata checks.

 

How do you implement the Manufacturing Protection Feature on non-networked devices?

Now for devices that do not have a network interface, the workflow is as follows:

During product development time, the OEM extracts the MP public key from the device AND treats it as a secret on a secure server, ideally with a HSM (e.g.: build server). A key derived from the MP public key will be used to encrypt device secrets which can then be flashed onto the device at manufacturing time.

 

Step 1:  Enable manufacturing support on a reference chip with known provenance

 

Step 2: Export / store MP Public key
  • Use the u-boot “mfgprot pubk” command or OP-TEE TA example to extract the MP public key.
  • Store the MP public key on a secure server, ideally on a HSM. The public key needs to be treated as a secret.

 

Step 3: Encrypt product secrets
  • Use a Key Derivative Function (KDF) to generate a derived key from the MP public key.
  • Encrypt product secrets (disk encryption keys etc.) using the derived key, bundle the encrypted secret with the provisioning image.

During production, OEM provides provisioning & production images, along with OTP fuse data and encrypted secrets.

 

Step 4: Create provisioning image
  • OEM creates a signed provisioning image with MP and Secure boot enabled along with fuse configuration (SRK hashes etc.), encrypted secrets and final production image.
  • Contract manufacturer (CM) downloads images to the programming PC.

 

Step 5: Program devices
  • CM flashes images and fuse configuration + encrypted secrets.

 

Step 6: Devices decrypts secrets
  • Device re-creates the derived key using the same KDF logic along with the MP public key.
  • Using the derived key the secrets are decrypted.
  • Device stores the secrets onto secure storage based on hardware root of trust (e.g.: CAAM blob or OP-TEE secure store).

 

Step 7: CM flashes final production image
  • CM flashes final production image which has the “MPPubk” command disabled to prevent leak of the key.

 

Security aspects to consider for non-networked devices

For this process to be secure, OEM is responsible for:

  • Ensuring the MP public key is treated as a secret and secured; ideally using a HSM. A PKCS#11 interface can be used to encrypt the secrets without the key being exposed outside of the HSM.
  • U-Boot/OP-TEE in the production software, has the “MPPubk” command removed to prevent the MP public key leakage.
  • Securing the programming PC at the manufacturing facility. Ideally the disk should be encrypted and only authorized personnel have access to this PC. If the provisioning or production images are “leaked,” then the product can be counterfeited or cloned.

 

Complexities

When implementing an end-to-end solution, we ran into a myriad of challenges: 

    • Reference code does not work: As of writing this blog, the example NXP OP-TEE Linux client no longer works with the latest version of OP-TEE + Linux kernel. We had to dig into the i.MX8 security reference manual and OP-TEE OS code to develop fixes.
  • Lack of out of the box solution: The provisioning software and device client needs to be developed by the OEM and is a time consuming process. 
  • Unified solution across different processors: Not all processors have built-in manufacturing protection security features. Without processor support, an external TPM or Secure Element must be added to the product. A unified software solution needs to be developed which can work across a mix of hardware platforms.
  • Network access and security complexity: Opening up network access to devices at the manufacturing facility can bring other security threats. Creating a restricted secure network to just the OEM provisioning software can alleviate the problem.

 

Conclusion

As the industry moves towards supply chain security, adopting manufacturing protection plays a crucial role. OEMs need to account for the time and effort required in adopting such solutions before the product goes into production. Further it requires skilled security architects working alongside with software developers, IT and manufacturing tooling engineers.

Whether you are looking for security consultation, training, out-of-the-box security solution (VigiShield) or customized manufacturing protection, Timesys is here to help. Schedule a free consultation to learn more about how we can help secure your products and go to market faster.

————–

Akshay Bhat is CTO at Timesys. He oversees the strategic direction of Timesys’ technology roadmap. With more than 16 years of industry experience with embedded systems software development and security, Akshay’s focus is on Timesys solutions that transform the software development lifecycle for embedded and enable the development of embedded system products with stronger security. Akshay has authored numerous embedded Linux and industry articles and delivered several embedded systems security presentations. He received his MS in Electrical Engineering from NYU Polytechnic University.

 

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.