SLAU846B June 2023 – November 2024 MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G1519 , MSPM0G3105 , MSPM0G3105-Q1 , MSPM0G3106 , MSPM0G3106-Q1 , MSPM0G3107 , MSPM0G3107-Q1 , MSPM0G3505 , MSPM0G3505-Q1 , MSPM0G3506 , MSPM0G3506-Q1 , MSPM0G3507 , MSPM0G3507-Q1 , MSPM0G3519
Keys (private keys in asymmetric schemes such as RSA and symmetric schemes such as AES) need to be protected to ensure confidentiality. Only trusted code should be provisioned with a mechanism to securely deposit keys from flash memory to a location that only crypto engines can access. This is the concept of the MSPM0 secure key storage: secure storage that only the CSC can configure keys into. Subsequently, the main application can configure the crypto engine to use one of the stored keys but can never access any stored keys.
The key-store is housed as part of the key-store controller IP. Depending on the device, a certain number of key slots are provisioned. These slots can be used to hold some number of 256-bit and 128-bit keys. Trusted software (CSC) can write to the key-store to deposit keys securely. Writing to the key-store is automatically disabled when INITDONE is issued. Key-store contents are reset at BOOTRST and the store is unlocked for writing. Key-store contents are unaffected by SYSRST and lower order resets.
A key that is required for a crypto accelerator service (such as AES encryption) is transferred to the crypto engine when the application software configures the crypto service. The configuration is performed in the key-store controller and is of the form “transfer the 128-bit key in slot 3 to the AES engine”. This transfer is performed securely and is not visible to the application code, DMA or the debugger.