SLAAE29 January   2023 MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G3105 , MSPM0G3106 , MSPM0G3107 , MSPM0G3505 , MSPM0G3506 , MSPM0G3507 , MSPM0L1105 , MSPM0L1106 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346

 

  1.   Abstract
  2.   Trademarks
  3. 1Introduction
    1. 1.1 Goals of Cybersecurity
    2. 1.2 Platform Security Enablers
  4. 2Device Security Model
    1. 2.1 Initial Conditions at Boot
    2. 2.2 Boot Configuration Routine (BCR)
    3. 2.3 Bootstrap Loader (BSL)
    4. 2.4 Boot Flow
    5. 2.5 User-Specified Security Policies
      1. 2.5.1 Boot Configuration Routine (BCR) Security Policies
        1. 2.5.1.1 Serial Wire Debug Related Policies
          1. 2.5.1.1.1 SWD Security Level 0
          2. 2.5.1.1.2 SWD Security Level 1
          3. 2.5.1.1.3 SWD Security Level 2
        2. 2.5.1.2 Bootstrap Loader (BSL) Enable/Disable Policy
        3. 2.5.1.3 Flash Memory Protection and Integrity Related Policies
          1. 2.5.1.3.1 Locking the Application (MAIN) Flash Memory
          2. 2.5.1.3.2 Locking the Configuration (NONMAIN) Flash Memory
          3. 2.5.1.3.3 Verifying Integrity of Application (MAIN) Flash Memory
      2. 2.5.2 Bootstrap Loader (BSL) Security Policies
        1. 2.5.2.1 BSL Access Password
        2. 2.5.2.2 BSL Read-out Policy
        3. 2.5.2.3 BSL Security Alert Policy
      3. 2.5.3 Configuration Data Error Resistance
        1. 2.5.3.1 CRC-Backed Configuration Data
        2. 2.5.3.2 16-bit Pattern Match for Critical Fields
  5. 3Secure Boot
    1. 3.1 Secure Boot Authentication Flow
    2. 3.2 Asymmetric vs. Symmetric Secure Boot
  6. 4Cryptographic Acceleration
    1. 4.1 Hardware AES Acceleration
      1. 4.1.1 Overview
      2. 4.1.2 AES Performance
    2. 4.2 Hardware True Random Number Generator (TRNG)
  7. 5Device Identity
  8. 6Summary
  9. 7References
  10. 8Revision History
  11.   A Security Enablers by Subfamily

3.1 Secure Boot Authentication Flow

The following provisioning steps are required to prepare a device to support secure boot:

  1. The boot image manager firmware must be configured and programmed into the MAIN flash memory, with the reset vector at 0x0000.0004 pointing to the start of the boot image manager
  2. Any authentication key material needed by the boot image manager must be programmed into the MAIN flash memory, adjacent to the boot image manager
  3. The device NONMAIN configuration memory must be programmed with the following characteristics:
    1. The MAIN flash sectors containing the boot image manager firmware and key material must be configured as statically write protected to prevent modification.
    2. The NONMAIN flash sector must be configured as statically write protected to prevent modification.
    3. The mass erase and factory reset commands are recommended to be password protected or disabled (disabling factory reset with the above configuration settings will result in the NONMAIN configuration becoming permanently locked, together with the sectors containing the boot image manager and authentication keys.
    4. The MAIN flash memory integrity check is recommended to be enabled, with the address range set to include the boot image manager and authentication keys.

Once provisioned, and once signed firmware is programmed into the device, the secure boot flow from device power-up is as follows:

  1. During power-up, the device is in a maximally secure state. The BCR will check the integrity of the device configuration memory and load the user-specified policies accordingly if the device configuration is valid.
  2. The BCR will compute the CRC value corresponding to the MAIN flash memory containing the BIM and key material. If the CRC check passes, the BCR will transition execution to the first user code (the boot image manager).
  3. The boot image manager will compute the digest of the remaining application code:
    1. In the case of asymmetric authentication, the secure hash (SHA2-256) digest of the application code will be computed in software
    2. In the case of symmetric authentication, the CMAC message authentication code corresponding to the application code will be computed using the authentication key
  4. The boot image manager will validate the digest against the provided signature:
    1. In the case of asymmetric authentication, the digital signature will be decrypted in software using the elliptic curve digital signature algorithm (ECDSA), and the result will be compared with the computed hash
    2. In the case of symmetric authentication, the computed CMAC will be compared with the CMAC in the digital signature
  5. If the application code digest matches the signature, the application code is started, else a user-specified failure handler will be invoked.