15.2.7 SPPS Protocols

Following SmartFusion 2 and IGLOO 2 devices: M2S005, M2GL005, M2S010, M2GL010, M2S025, M2GL025, M2S050, M2GL050, have a unique Factory Key programmed into it. Microchip customers who use the SPPS HSM-based solution are given a database (DB) of the Diversified Factory Keys (DFKs) upon registering their U-HSM through the Microchip Portal. Upon registration, a UUID is assigned to the user HSM. The UUID is a 32-hex symbol string identifier (40-for M-HSM). The Customer UUID is used to diversify device Factory Key values to build a Diversified Factory Key Database (DFK DB) for the customer. Diversification is a non-reversible cryptographic operation that takes the device-unique Factory Key and Customer UUID as inputs. The resulting key is called the Diversified Factory Key or DFK. The DFK value is irreversible, unique per-device and per- customer, and is stored in the DFK database in encrypted form. Encryption is done using U-HSM and M-HSM Public Keys, thus allowing only HSM modules to directly access plain text DFK values.

Blank devices do not have knowledge of the Customer UUID, so it is passed to the device through the authorization code. The UUID is authenticated but not encrypted. The device then uses the value of the Factory Key and received UUID to derive the DFK value.

The process of obtaining a DFK DB by the OE, using it for test runs, and preparing for the M-HSM in production is described in the setup section of the User HSM Installation and Setup User Guide .

Larger SmartFusion 2, IGLOO 2 (M2S060, M2GL060, M2S090, M2GL90, M2S150, and M2GL150), and PolarFire and PolarFire SoC devices have Elliptic Curve Cryptography (ECC) hardware IP along with the SRAM-PUF, which allows these devices to have a unique-per-device factory enrolled ECC public private key pair. This allows customers to use the factory ECC public key instead of the Diversified Factory Key (DFK) for initial key loading

To use these key modes, the customer uses the Elliptic Curve Diffie-Hellman (ECDH) protocol to securely establish a shared secret key, which is used to encrypt the authorization code. The ECDH operation occurs within the security boundaries of the HSM and the FPGA, and the shared secret key is not known to the outside world. Before the HSM uses the Factory ECC Public Key from the device, it validates the public key by verifying the signature on the device certificate using Microchip keys. This ensures that the public key is valid and that it belongs to a Microchip device.

There are two available key modes:

• KFP, in which the device uses the certified key pair and the HSM uses a randomly generated ephemeral key pair. They follow the ECDH protocol to derive the shared secret key.
• KFPE, in which the device uses the certified key pair along with a second randomly generated ephemeral key pair, and the HSM uses two randomly generated ephemeral key pairs. In this case, the ECDH protocol is run twice, which results in two shared secret keys that are used in another round of key derivation to generate a single shared secret key. This key mode is preferred over KFP key mode, as it uses randomly generated key pairs and therefore is more secure. However, this key mode takes longer, because there are two ECDH operations and key generations.

For more information, see UG0443: SmartFusion2 and IGLOO2 FPGA Security and Best Practices User Guide and PolarFire Family Security User Guide .

Bitstream Initialization

By selecting ​Initiater bit stream in the HSM-based flow, the user instructs the bit stream generation software to use the Authorization Code protocol with either DFK or Factory ECC key mode. The generated bit stream has a special programing algorithm for requesting the Authorization Code component from the M-HSM. The Authorization Code bit stream is generated dynamically by the M-HSM during production. The Authorization Code component is cryptographically linked to the programming bit stream, so it cannot be used with any other bitstreams, if intercepted during programming. Additional protocol-specific information is created for use by the M-HSM during generation of Authorization Code component.

HSM Job Export

Exported programming job includes the following protocol-specific information:

• Instruction to use Authorization Key Protocol along with the key mode (DFK, KFP, or KFPE)
• Header for the Authorization Code component generation and its binding with the associated bit stream
• KIP value encrypted with the Ticket Key (see Adding HSM Data to the Job through HSM Tasks)

Job Execution

In the beginning of device programming, a programming algorithm reads the Device Serial Number (DSN) and makes a request to FlashPro Express software to provide the Authorization Code.

FlashPro Express, based on the context of the current programming action (device, programming action), retrieves ticket information, encrypted KIP value, and other controlling data and passes them to the M-HSM as a part of the request for the Authorization Code.

If the key mode for Authorization code is DFK, the M-HSM finds the encrypted DFK value in its DFK DB and passes a request to the secure execution engine (SEE machine) inside its HSM module. The firmware running in the SEE machine in the HSM decrypts KIP, the bit stream binding information, Authorization Code Header, and assembles the Authorization Code component. As the last step, it decrypts DFK and uses it to encrypt the resulting Authorization Code bit stream component.

Programming software shifts the Authorization Code component into the device and then shifts in the main programming bit stream components. In the case of programming a new device with a ​initiater bit stream, the device uses its pre-placed factory key (FK) and the UUID from the Authorization Code header to compute DFK. It uses DFK to authenticate and unwrap (decrypt) KIP from the encrypted payload of the Authorization Code. Finally, it uses KIP to authenticate and decrypt the main ​initiater bit stream components (for example, the security component and the optional FPGA fabric and eNVM components).

If the key mode for authorization code is KFP or KFPE, the M-HSM generates an ephemeral ECC key pair and exchanges the public key with the device. It then uses the ECDH protocol to securely derive the shared secret key inside the secure execution engine (SEE machine). The firmware running in the SEE machine in the HSM decrypts the KIP, the bit stream binding information, and Authorization Code Header, and assembles the Authorization Code component. As the last step, it uses the shared secret key to encrypt the resulting Authorization Code bit stream component. Programming software shifts the Authorization Code component into the device and then shifts in the main programming bit stream components. In the case of programming a new device with a ​initiater bit stream, the device uses the shared secret key that it generated when running the ECDH operation to authenticate and unwrap (decrypt) KIP from the encrypted payload of the Authorization Code. Finally, it uses KIP to authenticate and decrypt the main ​initiater bit stream components (for example, the security component and the optional FPGA fabric and eNVM components).

In the case of updating a device using a unique-per-device user key, the device retrieves the selected user key from its NVM security segment and uses it to authenticate the Authorization Code and unwrap KIP from its payload. KIP is used to authenticate and decrypt the main update bit stream components containing one or both of the FPGA fabric and eNVM components.

Initial Key Loading of Per-device Keys

This flow is the same as Initial Key Loading with Project keys, but with additional steps as follows:

The Job Manager-generated ​Initiater bit stream does not include a complete security component. This is because, the per-device key values can only be derived during programming, once DSN is known. Therefore, the security component is passed to the M-HSM as a pre-filled template through data structures protected by the Job Ticket. In addition to the standard Authorization Code protocol data, HSM module attached to the M-HSM receives the security component template along with the base key(s) (originally from the KeySet file) and derives actual per-device key(s) upon programming (see protocol details in Per-Device Protocol). Derived keys are inserted into the template of the security component. Then the HSM module firmware links all the bit stream components cryptographically and proceeds to the same steps of project keys listed in Initial Key Loading of Project Keys).

Update Flow with Per-device Encryption Keys

This flow is also similar to SPPS Main flow that does the initial key loading of project keys. The difference is that the Authorization Code is encrypted with the same per-device UEK1, UEK2, or UEK3 derived by the M-HSM upon initial programming.