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.3 SWD Security Level 2

SWD security level 2 configures the device in a maximally restrictive state. The physical debug port (SW-DP) is completely disabled, and all of the SWD-accessible functions (application debug, mass erase, factory reset, and TI failure analysis) are not accessible through SWD, regardless of their individual configuration.

When level 2 is selected (SW-DP disabled), the application debug configuration and TI failure analysis configuration fields are don't care fields which do not impact the device configuration.

If the BSL is disabled, then the mass erase and factory reset configuration fields are also don't care fields. However, if the BSL is enabled, then the mass erase and factory reset configuration fields are still used by the BSL to authorize mass erase or factory reset commands originating from the BSL interface.

When to Use This State

Level 2 should only be used for mass production when no further access to any SWD functions is required and a maximally secure state is desired for the device.

When to Not Use this State

Level 2 should not be used in the following cases:

  • Future application debug and/or re-programming through SWD may be required
  • The user would like TI to be able to perform failure analysis on the device
  • The user would like to be able to remove proprietary information from the flash memory by sending a mass erase or factory reset command through SWD
Note: Once a device is configured for level 2 (SW-DP disabled), further access to the device through SWD is not possible. The only way to bring a device back to a level 0 or level 1 state with SWD access restored is if the BSL and factory reset are both enabled (allowing a BSL factory reset command to be sent), or a mechanism in the user application code is included which can change the NONMAIN configuration to a less restrictive state. In either scenario, if the NONMAIN is locked through static write protection then the level 2 state is not reversible and there is no way to re-gain SWD access.