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.3.2 Asymmetric Verification

The integrity and authenticity of a new image are verified through cryptographic algorithms. Only images that have been verified are considered secure and can be executed.

SHA-256

SHA-256 (Secure Hash Algorithm 256) is a widely used cryptographic hash function that generates a fixed-length, 256-bit digest from any input message. The algorithm is designed so that even a minor change in the input message will result in a dramatically different output hash, ensuring strong sensitivity to input variations.

One of its core features is collision resistance, meaning it is extremely unlikely that two different messages will produce the same hash value. This property makes SHA-256 highly reliable for verifying the integrity of data, as any modification can be easily detected.

In practice, SHA-256 is commonly used in digital signatures and data integrity checks. By condensing an entire image into a unique digest, SHA-256 provides a robust foundation for the next of ECDSA algorithm.

ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) is a cryptographic algorithm used for digital signatures, based on elliptic curve mathematics. It offers high security with much shorter key lengths compared to traditional algorithms like RSA, making it efficient and suitable for resource-constrained environments.

ECDSA is currently the only supported asymmetric authentication method for MSPM0 secure boot. ECDSA is an asymmetric algorithm, meaning there is a separate public and private key. The public key will be stored in the device flash and the private will be maintained by the developer securely. CSC doesn’t provide secure private key management.

ECDSA uses the hash of the image and the public key to verify a digital signature, ensuring the authenticity of the data. While this process is much slower compared to symmetric cryptographic options, it does not present a key vulnerability on the device.

Note: To keep the boot flow for final deployment, it is very important to keep the private key secure and managed such that it is not easily accessible to sign images. Keeping the key on a local share drive is not a secure location! MSPM0 does not currently provide secure private key management.

Table 3-2gives the trade-offs between the two alternatives.

Table 3-2 Secure Boot Algorithm Comparison
Parameter Asymmetric (SHA2+ECDSA) Symmetric (CMAC)
Authentication time Longer, due to software hash computation and public key arithmetic Shorter, due to simplicity of algorithm and ability to leverage hardware AES acceleration when available
Code size Larger, due to SHA and ECDSA algorithms Smaller, especially if AES acceleration is available on the target device
Key integrity Public keys must be provisioned into the device and must be immutable Shared keys must be provisioned into the device and must be immutable
Key confidentiality Public keys have no confidentiality requirement and there is no need for protecting the public key from vulnerabilities in application code Shared keys must be kept confidential, and should be wrapped when not in use and secured with a static read firewall (if supported by the target device) to protect the shared key from vulnerabilities in application code

TI recommends the asymmetric implementation in most situations. In cases where code size is limited and/or authentication time must be kept to a minimum, the symmetric implementation may be used, with the trade-off that the shared key must be managed carefully. Not all devices provide secure storage (KEYSTORE) to protect shared symmetric keys from software vulnerabilities. Please see Platform Security Enablers for details.