15.2.6.1.3 Programming Data and Bitstream Initialization

Programming data creation requires the user to point to the specific JDC file. Also, in the HSM flow, all key material is handled by the U-HSM on the operation side. Therefore, the Programming Data needs a special KeySet file pre-generated by the U-HSM. KeySet files are stored in a repository shared by different Job Manager projects, which enables key sharing. For more information about handling KeySet files, see Job Manager User Guide .

The Job Manager allows the OE to modify imported design data and supports the following use cases:

• eNVM update
• Security settings overwrite

There are two main uses for eNVM or sNVM update:

• The OE receives an update from the firmware development team and updates the firmware in a Job Manager project.
• The OE performs a custom update of the existing eNVM or sNVM clients. Examples of this case could be programming of custom per-device information or information that becomes available or changed after the device was initially programmed.

eNVM or sNVM update is applied to the existing clients in the loaded design. The updated content size cannot exceed the client size in the design, but may be smaller. This allows the Libero design engineer to reserve more client space to accommodate a potential increase in firmware size.

This use case is designed to give the OE full control over security programmed into the device. The user can import a SPM file created by Libero into the Programming Data entry of a Job Manager project. This new SPM file, called Security Overwrite, substitutes all security settings imported into the Programming Data through the JDC file. The key values are still used from the KeySet file associated with the Programming Data, as all keys are protected by the HSM.

The ​Initiater programming bit stream is similar to the ​Initiater bit stream used in Libero, but is based on secured key loading using the Authorization Code Protocol (see Authorization Code Protocol for protocol description), which makes initial key loading secure and provides overbuilding protection.

The OE uses the ​Initiater bit stream to program security and any other optional bit stream components (Fabric, eNVM) into a blank device that does not have user security programmed. Initialization of the ​Initiater bit stream automatically includes all protocol data generated by the U-HSM on the Job Manager side. This data is then passed and used by the M-HSM on the FlashPro Express (Manufacturing) side.

The ​Initiater bit stream programs security settings based on SPM information in the Programming Data. If Programming Data has a Security Overwrite (explained in Security Overwrite), the overwrite supersedes the SPM from the original design. Key values are always used from the KeySet file associated with the Programming Data.

When using the ​Initiater Bitstream in the SPPS HSM flow, note the following:

• After initial key loading, the ​Initiater bit stream disables all Factory Default Key modes and Factory pass keys. This gives the user exclusive control over device access through programming interfaces with the user pass and encryption keys. Note that the user-defined pass key and encryption keys are only accessible through the U-HSM. The M-HSM can only access the user-defined pass keys and encryption keys with the authorization of the U-HSM through the Job Ticket embedded in the Programming Job.
• The user has to select the “Protect factory test mode access using FlashLock/UPK1” or “Permanently protect factory test mode access” in the SPM.
• An ERASE or VERIFY operation using the ​Initiater bit stream requires an M-HSM. This is because after initial programming, device security is always locked by UPK1. The UPK1 value is always protected by the HSM, and security unlock can only be done by the HSM through the One Time Pass Key protocol (OTPK) that securely transmits the UPK1 value to the device (see One Time Pass Key (OTPK) Protocol for details).
• A program action from the ​Initiater bit stream cannot be invoked on a programmed device. Security reprogramming can only be achieved by erasing the device first using the ​Initiater bit stream that was used to program the device.
• The ERASE programming action does not erase content of eNVM areas programmed by the ​Initiater bit stream. With this action, security settings will be erased, but eNVM content remains available for access.

The OE can choose to make any of the user-defined keys (UEK1/UPK1/UEK2/UPK2/UEK3/DPK) to be Project Wide keys or Per-device keys.

All devices programmed from the same job have the same key value programmed. These keys are used from the KeySet file without modification.

If the OE specifies any of the SPM keys to have a per-device value, every device receives a unique value derived from the respective base key in the KeySet file and Device Serial Number (DSN) of the device being programmed. This type of key derivation is referred to as a Per-Device Key Protocol (see Per-Device Protocol).

As actual device programming is done on the Production side, the programming software reads the DSN from the device and passes it to the M-HSM. The HSM uses the Per-Device protocol to derive per-device key value. This also applies to Erase and Verify operations, if UPK1 is selected to be per- device.

For more information about how to use the ​Initiater bit stream, see Job Manager User Guide .

Update bit stream is designed to update devices already programmed using the ​Initiater bit stream (see Initialization of ​Initiater Programming Bitstream).

An Update bit stream can only update eNVM, sNVM and Fabric device features. Reprogramming security is explained in a special use case in Initialization of ​Initiater Programming Bitstream.

Depending on whether or not the device has security locks on areas targeted for update, and whether project or per-device keys are used, the OE uses one of the use cases listed as follows:

In this case, all devices in the project have the same UEK1, UEK2, or UEK3 values and target device feature programming is allowed without FlashLock/UPK1 match. The Job Manager can generate a stand-alone bit stream file or non-HSM programming job that does not require the M-HSM during programming. However, this case assumes the Job Manager uses the U-HSM to encrypt the resulting bit stream using UEK1/UEK2/UEK3 token values in the KeySet file.

If the target device feature programming is locked, the M-HSM must perform a secured unlock of the device, because plain text value of the lock key cannot be used in an untrusted environment. This type of bit stream must be handled through an HSM Programming Job using the OTPK protocol (see One Time Pass Key (OTPK) Protocol). The OTPK protocol is engaged automatically by FlashPro Express.

If UEK1, UEK2, or UEK3 are per-device keys, target feature programming is not locked, and DSN for the target device is known, the user has an option to generate a device-specific programming bit stream that does not require the M-HSM during production. This bit stream can be exported as a stand-alone bit stream file or non-HSM Programming Job. In either case, DSN must be provided upon bit stream export or during the addition of the device to the job.

For all other cases related to per-device UEK1/UEK2/UEK3, the M-HSM and HSM Programming Job must be used. If the target device features are locked by per-device UPK1, UPK1 unlock is performed securely through the OTPK protocol (see One Time Pass Key (OTPK) Protocol). For more information about Initializing the bit stream in the Job Manager, see Job Manager User Guide .