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.1.1.2 SWD Security Level 1

SWD security level 1 allows for a customized security configuration. The physical debug port (SW-DP) is left enabled, and each function (application debug, mass erase command, factory reset command, and TI failure analysis) may be individually enabled, disabled, or (in some cases) enabled through password authentication, providing considerable flexibility to tailor the device behavior to specific use-cases.

When to Use This State

Level 1 is well suited for restricted prototyping/development scenarios and for mass production scenarios where the desire is to retain certain SWD functions (such as factory reset and TI failure analysis) while disabling other functions (such as application debug). Common examples of Level 1 customized configurations are given in Table 2-2.

Table 2-2 Examples of Level 1 Configurations
Level 1 Scenario Configuration
App Debug Mass Erase Factory Reset TI FA
This scenario restricts debug access with a user-specified password, but it leaves the factory reset and TI failure analysis available. This configuration allows field debug (with password), and it also allows the device to be brought back to the default "Level 0" state through factory reset. EN with PW DIS EN EN
This scenario does not allow debug. It does allow factory reset, but only with a user-specified password. This provides a way to open up a device in the field by clearing the MAIN memory contents and bringing the device back to a "Level 0" state if the password is known. Importantly, even if the factory reset password were compromised, it would not be possible for an attacker to read proprietary information in the MAIN flash memory. DIS DIS EN with PW EN
This scenario does not allow debug and it does not allow TI failure analysis. This prevents TI from performing a factory reset and further FA activities on the device, unless the user executes a factory reset with their user-specified password before returning the devices to TI for FA. DIS DIS EN with PW DIS
Note: Level 1 is the recommended configuration for most standard production use-cases. For applications which do not require secure boot, TI recommends using Level 1 in production with factory reset left enabled (with password) and TI failure analysis left enabled. In such a configuration, the device may be recovered to a less restrictive state after provisioning either by the user (with password) or by TI (through the failure analysis return flow). In use-cases requiring maximum secure boot assurance, a more restrictive Level 1 or Level 2 may be used for production, with the trade-off that devices may not be recoverable to a less restrictive state once provisioned.

When to Not Use this State

Level 1 should not be used during prototyping if complete access to the device is desired; in such a case, Level 0 should be used instead.

Level 1 should also not be used in a mass production scenario where a maximally restrictive state is desired and no SWD functions are to be enabled; in such a case, Level 2 should be used instead as it directly disables the complete SWD physical interface and minimizes the possibility of misconfiguration.

Note: If a device is configured with application debug and factory reset disabled, the only way for a user to restore debug access to the device is if the user application code provides a mechanism to change the NONMAIN configuration to a less restrictive state. If the NONMAIN is locked through static write protection then the state is not reversible and there is no way for a user to re-gain debug access.