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.2 Flash Memory Map

Figure 3-4 illustrates the detailed flash memory map in the CSC secure boot. The following are the explanation of sections in CSC:
  • SECRET: The SECRET is visible to the privileged execution flow but will be protected by a read protect firewall, thus rendering it invisible to any aspect of the unprivileged flow (CSC and Application). The SECRE region can be used to store non-volatile keys that should be loaded into KEYSTORE at runtime. Thus, the unprivileged code will be able to use these keys but not have read access. It can also be customized by the user to include additional information such as CMAC tag and key.
  • Lockable Flash: The lockable flash provides dynamic write protection to key information that needs to be written by the privileged state and be read but unmodified by the unprivileged flow. Two typical things that will go in this region are the security counter (rollback protection), the keystore hash table, and the image hash. Notice that Lockable content will be programmed to CSC region in both flash bank0 and bank1, to make sure both bank application programs could access this region in the same way.
  • CSC Interrupt Vectors: These are the interrupt vectors for the customer secure code. This interrupt vector table will always be the first thing run from flash in the event of either a BOOTRST or a SYSRST. This is enforced as the VTOR will get cleared in both resets, meaning that 0x0000 will be used (which will point to Logical bank 0, where a copy of the immutable CSC exists).
  • CSC Code: The main code and security primitives is the bulk of the Customer Secure Code. This along with the interrupt vectors is duplicated across both banks. The images on both the primary and secondary bank should be identical, with references to code as if the code is running from 0x0000. During a bank swap, after the SYSRST triggered by INITDONE, the program will always run from Logical Bank 0 (logic 0x0000 address). FLASHCTL will map the address 0x0000 to PB0 start address 0x0000 or PB1 start address 0x0000 according to bank swap policy configuration.

    Note: In bank-swappable configuration, the firewall protections are automatically mirrored to both banks.

The following are sections of the application image:

  • Image Header, Image TLV and Image Trailer: These parts are generated by the signing tool imgtool which is provided by MCUBOOT (see python scripts in <mspm0_sdk_path>\source\third_party\mcuboot\scripts). These contents are generated and merged to a compiled application image in the CCS post-build step. There is a customer_secure_sample_image example in MSPM0 SDK which shows how a signed image is built in CCS. The following are the explanations of those image parts:
    • Image Header: The header information of application image, including the header magic (0x96F3B83D), image size and image version. It is located at the address 0x100 bytes (by default) before Application Interrupt Vectors.
    • Image TLV: MCUBOOT defines Type-length-value records (TLV) containing image metadata which are placed after the end of the image. The TLVs defined in MSPM0 CSC includes: TLV magic (0x6907), image hash, ECDSA public key hash and ECDSA signature. Refer to mcuboot/docs/design.md at main · mcu-tools/mcuboot · GitHub for more details.
    • Image Trailer: A 16-bytes magic content which is located at the end of image flash areas.

    Note: A SHA256 verification is only executed for the image content from the start address of Application Interrupt Vectors and start address of Image TLV.

  • Application Interrupt Vectors: These are separate interrupt vectors which the application program uses. During the CSC jumping to the application, the Vector Table Offset Register (VTOR) points to this position in memory, and thus all future interrupts occur without a reset link to this set of interrupt vectors. The start address needs to be 32-bytes aligned.


CSC Flash Map

Figure 3-4 CSC Flash Map