SPRUJ17H March 2022 – October 2024 AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1
The HSM architecture supports different "Device Types" controlled by eFuse settings programmed during device manufacturing. Each Device Type offers different capabilities as well as different behaviors in functional operating modes. Depending on this, some security mechanisms are relaxed or enforced.
The eFuse settings that determine device type are scanned into registers in the Security Manager module within the HSM as part of the power-on-reset process, so these settings are stable before the device starts booting. The device_type_raw is a 16-bit value, with the device type information contained in the lower bytes. For security and redundancy, the upper byte is programmed as the bit-wise inverse of the lower bytes and the Security Manager will set the device type to "BAD" if this condition is not satisfied. Refer to the Security Manager section in the HSM Addendum for more details.
Table 7-94 describes the device type and associated feature differences for each device type.
Device Type | eFUSE Field (8 bit) | Description |
---|---|---|
HS | 0b 1100 1100 | High security devices have 2 sub-types that represent the state of HS device. HS-FS (HS- Field Securable): This is the state before “customer keys Revision” and “customer keys count” is blown in the device. In this state, the device forces authentication for HSM Runtime image only. This is the state at which the HS device leaves the TI factory. HS-SE (HS – Security Enforced): This is the state after “customer keys Revision” and “customer keys count” is blown in the device. In the HS-SE device, all security features are enabled. All secrets within the device are fully protected and all of the security goals are fully enforced. The device forces secure booting. |
The different stages in the life cycle of the secure device are shown in Figure 7-86. The enforcement of the secure boot only happens when the customer keys are blown, along with the customer key count and customer key revision fields.
The device transitions from HS-FS to HS-SE only if "Customer Keys Revision" is non-zero AND "Customer Keys Count" is non-zero. Mere writing of the eFuse keys SMPK/BMPK will not change the HS-FS to HS-SE.
The motivation for HS-FS (Field Securable) device is to allow customers to run unauthenticated code before devices are seeded with customer's keys (SMPK, SMEK, and so forth) and keys are effective. Once the customers injects the booting keys in the device along with non-zero value of "Customer Keys Revision" and "Customer Keys Count" , the device will always force authentication and behave as an HS-SE device. This is a one way change.