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

 

  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.2 Asymmetric vs. Symmetric Secure Boot

While the boot image manager provided in the MSPM0 SDK supports both asymmetric and symmetric secure boot, there are trade-offs between the two implementations which should be carefully weighed for a given application. Table 3-1 gives the trade-offs between the two alternatives.

Table 3-1 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 to protect shared symmetric keys from software vulnerabilities.