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

2.5.3.1 CRC-Backed Configuration Data

The BCR configuration data and BSL configuration data structures in the NONMAIN memory each include a CRC32 value corresponding to the CRC32 digest of the respective structure. During the device boot process, the BCR will compute the CRC digest of the data structures and compare it with the stored CRC values before the data contained within the structures is trusted for use.

BCR Configuration CRC Fail Handling

In the event that the BCR configuration data (which contains the SWD policies, BSL enable/disable policy, and flash memory protection and integrity check policies) fails its CRC check during boot, a catastrophic boot error results and the following limitations are imposed:

  • The error cause will be logged in the CFG-AP as a boot diagnostic
  • The BSL will not be invoked, even if it was configured to be enabled
  • The user application is not started
  • No application debug access is enabled
  • A pending SWD factory reset command, if enabled or enabled with password, is honored
  • A pending TI failure analysis flow entry, if enabled, is honored
  • The boot process will re-attempt up to 3 times
    • If the 2nd or 3rd attempt pass, the device boots normally
    • If the 3rd attempt does not pass, no further boot attempts are made until the next BOR or POR

The benefit of the this CRC check is that any bit flips in configuration data, such as the static write protection configuration (which is a pillar of secure boot), may be detected with high confidence during the boot process. The fail handling procedure explicitly prevents the BSL and user application from running, and the only supported options (SWD factory reset and TI FA) are protected by 16-bit pattern-match fields.

BSL Configuration CRC Fail Handling

If the BSL configuration data (which contains the BSL password and BSL policies) fails the CRC check during BSL invocation, a catastrophic boot error results and the following limitations are imposed:

  • The error cause is logged in the CFG-AP as a boot diagnostic
  • The BSL is not invoked, even if it was configured to be enabled
  • The user application is not started
  • No application debug access is enabled
  • The boot process re-attempts up to 3 times
    • If the 2nd or 3rd attempt pass, the device boots normally
    • If the 3rd attempt does not pass, no further boot attempts are made until the next BOR or POR

The benefit of this CRC check s that any bit flips in the BSL configuration data may be detected with high confidence during the invoke process. The failure handling procedure prevents the BSL from starting with invalid data which could lead to a loss of security.

TI Factory Trim Data CRC Fail Handling

In addition to the user-specified configuration data, if the TI factory trim fails its CRC check during boot, a catastrophic boot error will also result with the following limitations:

  • The error cause will be logged in the CFG-AP as a boot diagnostic
  • The BSL will not be invoked, even if it was configured to be enabled
  • The user application is not started
  • No application debug access is enabled
  • A pending TI failure analysis flow entry, if enabled, is honored
  • The boot process will re-attempt up to 3 times
    • If the 2nd or 3rd attempt pass, the device boots normally
    • If the 3rd attempt does not pass, no further boot attempts are made until the next BOR or POR