The keystore supports storage of AES keys. Up to four 128-bit key slots are provisioned and can be used in different software-managed configurations, such as:

• Four 128-bit keys
• Two 256-bit keys
• One 256-bit key and two 128-bit keys

This configuration selection is the first to be performed by customer secure code before depositing keys into slots. Configuration is done by writing the number of 256-bit keys into the NK256 field of the CFG register.

After configuration, the key bytes can be written to selected slots in the keystore controller register. This is done by programming the KEYSZSEL (key size selection) and KEYSLOTSEL (key slot selection) fields of the KEYWR register. Note that the hardware expects any 256-bit keys to be store in lower-numbered slots. For example, if the store is configured for one 256-bit key and two 128-bit keys, the 256-bit key must be stored in slots 0 and 1. The IP reports an error (invalid configuration) if any other slot is used for the 256-bit key. If the store is configured for two 256-bit keys, then key 0 occupies slots 0 and 1 and key 1 occupies slots 2 and 3.

Depositing the key bytes into slots is done by writing them to the KEYIN register. Once a key write transaction is initiated, until and unless all the key bytes are written (4 words for a 128-bit key and 8 words for a 256-bit key), the key is not considered valid. Validity of slots is presented via a status register for the application. When customer secure code has deposited the required number of bytes, the key becomes valid and can be used by the application. The STATUS register provides status and validity fields to indicate status of the keystore controller as well as the validity of key slots.

Note that key configuration operations are permitted only while customer secure code is executing. Subsequently, the keystore configuration is locked and can not be modified. The signaling of the end of customer secure code is discussed in the Security Architecture chapter.

At run-time (after the end of customer secure code execution), the application is able to use one of the valid keys for an AES encryption/decryption operation. To configure the AES engine to use a specific key, the application references a key slot and initiates a transfer of the key data into the AES engine via a secure internal bus. This is performed by writing to the KEYSZSEL (key size selection), and KEYSLOTSEL (Key slot selection) fields of the KEYRD register. The selected key data is securely transferred to the AES engine over a private bus that is not accessible by software or the debugger.

The keystore holds the state and key data until a subsequent boot reset. At boot reset, customer startup code configures the keystore. If one or more slots are not used at the end of customer startup code execution, those slots remain unusable for the rest of the application execution.