SLAAE29A January   2023  – December 2025 MSPM0C1105 , MSPM0C1106 , MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G1518 , MSPM0G1519 , MSPM0G3105 , MSPM0G3106 , MSPM0G3106-Q1 , MSPM0G3107 , MSPM0G3107-Q1 , MSPM0G3505 , MSPM0G3506 , MSPM0G3506-Q1 , MSPM0G3507 , MSPM0G3507-Q1 , MSPM0G3518 , MSPM0G3518-Q1 , MSPM0G3519 , MSPM0G3519-Q1 , MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1227-Q1 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2227-Q1 , MSPM0L2228 , MSPM0L2228-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
    1. 1.1 Key Concepts
    2. 1.2 Goals of Cybersecurity
    3. 1.3 Platform Security Enablers
  5. 2Device Security Model
    1. 2.1 Device Identity
    2. 2.2 Initial Conditions at Boot
    3. 2.3 Boot Configuration Routine (BCR)
    4. 2.4 Bootstrap Loader (BSL)
    5. 2.5 Boot Flow
    6. 2.6 User-Specified Security Policies
      1. 2.6.1 Boot Configuration Routine (BCR) Policies
        1. 2.6.1.1 Serial Wire Debug Related Policies
          1. 2.6.1.1.1 SWD Security Level 0
          2. 2.6.1.1.2 SWD Security Level 1
          3. 2.6.1.1.3 SWD Security Level 2
        2. 2.6.1.2 Bootstrap Loader (BSL) Enable/Disable Policy
        3. 2.6.1.3 Flash Memory Protection and Integrity Related Policies
          1. 2.6.1.3.1 Locking the Application (MAIN) Flash Memory
          2. 2.6.1.3.2 Locking the Configuration (NONMAIN) Flash Memory
          3. 2.6.1.3.3 Verifying Integrity of Application (MAIN) Flash Memory
        4. 2.6.1.4 Bootstrap Loader (BSL) Security Policies
          1. 2.6.1.4.1 BSL Access Password
          2. 2.6.1.4.2 BSL Read-out Policy
          3. 2.6.1.4.3 BSL Security Alert Policy
      2. 2.6.2 Customer Secure Code (CSC) Security Policies
        1. 2.6.2.1 CSC Enforced Bankswap
        2. 2.6.2.2 CSC Enforced Firewalls
        3. 2.6.2.3 CSC Key Write to KEYSTORE
      3. 2.6.3 Configuration Data Error Resistance
        1. 2.6.3.1 CRC-Backed Configuration Data
        2. 2.6.3.2 16-bit Pattern Match for Critical Fields
  6. 3Secure Boot
    1. 3.1 Secure Processing Environment Isolation
    2. 3.2 Customer Secure Code (CSC)
      1. 3.2.1 Secure Boot Flow
      2. 3.2.2 Flash Memory Map
      3. 3.2.3 Features
        1. 3.2.3.1 CMAC Acceleration
        2. 3.2.3.2 Asymmetric Verification
        3. 3.2.3.3 KEYSTORE and Firewall
        4. 3.2.3.4 CSC Performance
      4. 3.2.4 Quick Start Guide
        1. 3.2.4.1 Environment Setup
        2. 3.2.4.2 Step by Step Guidance
        3. 3.2.4.3 CSC NONMAIN Configuration
        4. 3.2.4.4 Customize Changes on CSC Example
    3. 3.3 Boot Image Manager (BIM)
      1. 3.3.1 Secure Boot Flow
      2. 3.3.2 Flash Memory Map
      3. 3.3.3 Quick Start Guide
  7. 4Secure Storage
    1. 4.1 Flash Write Protection
    2. 4.2 Flash Read-Execute Protection
    3. 4.3 Flash IP Protection
    4. 4.4 Data Bank Protection
    5. 4.5 Secure Key Storage
    6. 4.6 SRAM Protection
    7. 4.7 Hardware Monotonic Counter
  8. 5Cryptographic Acceleration
    1. 5.1 Hardware AES Acceleration
      1. 5.1.1 AES
      2. 5.1.2 AESADV
    2. 5.2 Hardware True Random Number Generator (TRNG)
  9. 6FAQ
  10. 7Summary
  11. 8References
  12. 9Revision History

3.2.1 Secure Boot Flow

This section introduces the detailed boot flow in the CSC solution based on MSPM0 SDK CSC example (MSPM0 SDK 2.08.00.03), as shown in Figure 3-3. The whole execution flow is mostly compatible with the flow chart shown in Figure 3-1 and Figure 3-2.

When ROM boot code execution is done, at the first time program goes to CSC firmware, the INITDONE (SYSCTL.SECCFG.SECSTATUS.INITDONE) is in clear state. CSC firstly works in privileged state. It searches for the highest version image from both flash banks, checks version rollback, and then verifies the application image authority and integrity by a symmetric approach (AES-CMAC in hardware) or by an asymmetric approach (SHA256+ECDSA in software). After the verification is passed, CSC updates rollback counter, CMAC tag, SECRET keys and KEYSTORE. It then configures firewall in SECRET flash region and Lockable flash region, and determine bank swap policy. CSC issues an INITDONE to trigger a SYSRST and device enters the unprivileged state. Device runs from CSC firmware again with INITDONE checked in set state. After checking previous boot status successful, CSC jumps to application image to starts application.

There are some key notes related to the CSC example execution flow:

  • The CSCEXISTS and FLASHBANKSWAPPOLICY filed in NONMAIN flash need to be enabled for enabling the whole CSC sequence.
  • PB0 represents Physical Bank0. As bank swap policy does not take effect in privileged state (pre-INITDONE), the flash address used in privileged state CSC are always refer to physical address.
  • If two images in PB0 and PB1 are with the same version, the PB0 image is verified and executed in a higher priority.
  • If the highest version image does not pass the SHA256+ECDSA verification, then the image in the other bank (if exist) will be verified right after.
  • In the case of asymmetric authentication, the secure hash (SHA2-256) digest of the application code is firstly computed in software, and then software ECDSA verifies the image signature based on public key in firmware.
  • Symmetric AES-CMAC algorithm is a time-saving mechanism to verify application image in case that no firmware updating is detected. Since AES-CMAC is hardware accelerated, it is significantly faster to simply check the tag and make sure it has been unmodified since it was asymmetrically verified. The AES-CMAC approach is only applied when a BOOTRST occurs, and there is no higher version image placed in the flash since last time BOORTRST.
  • SECRET flash region is a user specified region which stores secret information and is read-execute protected by firewall. Lockable flash region is a user specified region which stores unmodified information and is write protected by firewall. Please see Flash Memory Mapping for more details.


MSPM0 SDK CSC Execution Flow

Figure 3-3 MSPM0 SDK CSC Execution Flow