PUF Emulation Service

Provides a mechanism for authenticating a device, or for generating pseudo-random bit strings that can be used for many different purposes. The service accepts a 128-bit challenge and an 8-bit optype, and returns a 256-bit response unique to the given challenge, optype, and device.

RESPONSE = KeyTree(PEK, OPTYPE, CHALLENGE)

Where PEK is the factory-defined PUF emulation key and KeyTree is a function that uses the 8-bit OPTYPE concatenated with the 128-bit CHALLENGE to navigate a binary key tree with the 256-bit secret PEK at its root. The leaf of the tree that is computed as a result of the 136 internal hashing operations (one for each level in the binary tree), is a 256 bit secret. The root key, PEK, the result, RESPONSE, and the intermediate results are protected against side-channel attacks due to the nature of the protocol. The SHA algorithm implemented in the System Controller's cryptoprocessor also has strong DPA countermeasures. The OPTYPE and CHALLENGE are not protected against side-channel leakage. The OPTYPE allows the user to conceptualize that there are 256 different 128-bit key trees, each with 2128 possible output responses, which can be put to different uses without much danger of collision.

The function emulates a “strong PUF”, which means that it takes a cryptographically large challenge space and computes a pseudo-random repeatable output response from it, but in this implementation, it does not use unclonable physical properties developed during the manufacturing of the device for the challenge-response calculation, instead using classical cryptographic algorithms; thus the “emulation” disclaimer. The root key PEK is, however, protected as an encrypted/authenticated PUF key code, so the unclonable physical properties of the device do enter into the reconstruction of the PUF secret and decryption of the key code to unwrap PEK for use in this function.

There are many uses in cryptography for such a per-device unique, pseudo-random function. One use is to identify a particular chip by first recording (possibly several) challenge-response pairs, then later seeing if the target chip provides the same response as expected for one of the recorded challenges-response pairs. Another application is deriving many keys from one.

Table 1. PUF Emulation Service Request
System Service Descriptor Bit Field Value Description
15:7 MBOXADDR[10:2] Mailbox address. See Table 2.
6:0 20H PUF Emulation service command

The following table lists the PUF Emulation Service Mailbox Format.

Table 2. PUF Emulation Service Mailbox Format
Offset Length (bytes) Parameter Direction Description
0 1 OPTYPE Input Operational type
1 3 RESERVED

Reserved
4 16 CHALLENGE Input Challenge input
20 32 RESPONSE Output Response output