SWCU195A December 2024 – May 2025 CC2744R7-Q1 , CC2745P10-Q1 , CC2745R10-Q1 , CC2745R7-Q1 , CC2755R10
Public key-based authentication is being used here. When ccfg.debugCfg.authorization == REQ_AUTH, the user must continue configuring secure debug in the scfg.debugAuthCfg field. The authentication process uses a challenge-response sequence where the device will provide a challenge for the debugging host to sign with the relevant private key. The private key can be looked up in a user's database with the scfg.debugAuthCfg.*.keyId field. The debugging host sends the signed challenge back to the device, which verifies the signature based on the public key information it has in scfg.debugAuthCfg.*.publicKeyHash
Secure debug is authenticated through SACI just as was previously done on some other TI devices. However the SACI commands are different.
Levels of authentication:
Secure
Requires the configuration of the scfg.debugAuthCfg.secureKey field and for the relevant key to be used during authentication
Non-Secure
Requires the configuration of the scfg.debugAuthCfg.nonSecureKey field, and for the relevant key to be used during authentication
Non-Invasive Only
Requires the configuration of the scfg.debugAuthCfg.nonSecureKey field, and for the relevant key to be used during authentication
Using the scfg.debugAuthCfg.challengeVector field, the user can configure the challenge vector lifetime and deviceConst fields:
lifetime
Ephemera—Each debug auth request to a given device will result in a securely random challenge vector. More secure and stops replay attacks
Endless—Each debug auth request to a given device will result in an identical challenge vector. This is a simplified process, but it could potentially provide less security.
deviceConst
Mac Const—Each debug auth request between a fleet of devices will have a unique challenge vector. More secure and stops replay attacks.
Zeroed Const—Each debug auth request between a fleet of devices will result in an identical challenge vector. Less Secure. Potentially useful as a stepping stone or temp simplification as users ramp up with the feature.
Persistent Debug, as its name suggests, allows the device to remember a secure debug connection that had previously been made and to automatically re-authorize that debug connection again for a simplified user experience. A secure debug connection, if fully authenticated initially, persists until either a PoR or the DEBUG_CLOSE_SESSION SACI command is received.
The user can be confident that, by either removing power from the device or explicitly sending the debug close session command, the secure debug connection has been closed, and for a new secure debug connection to be opened, the full challenge response sequence must be followed as described above.