When it comes to security, the main objective is to establish trust. Trusting users can be subjective and ambiguous, therefore modern technology has been designed to give different types of users different level of trust, and formulate corresponding mitigation measures. The designers of every new application and device need to consider the cost-benefit ratio of adding security features. All security can eventually be breached given sufficient time and resource, therefore a primary goal is to increase protection and security to a level where an attack on a device is deemed uneconomical.
Arm IP can be found in billions of electronic devices today, ranging from low-end IoT sensors to high-end enterprise hardware. The real value doesn’t lie in the physical device, but in the data contained inside. An example of this could be in the medical industry. In recent times, vulnerabilities have been discovered in embedded medical electronic devices, exposing an urgent need to improve security to protect patients and hospital infrastructure.
The potential attack surface grows every day, thanks to the ever-expanding network of connected devices. Thus, security needs to be considered and implemented for all elements - from a secure handshake with trusted agents, right down to data encryption to prevent unauthorized accesses to sensitive information. One of the most common parts of the system frequently compromised for attacks is the debug element.
Security enclaves are aimed at providing hardware isolation, offering separation from the host application processor. Security enclaves reduce the sharing of resources and hence narrow the exploitable attack surface. The Arm TrustZone CryptoIsland family provides on-die security services in a physically isolated manner. Debug elements of the system are also guarded by CryptoIsland, avoiding any potential misuse of the debug infrastructure. The CoreSight SDC-600 Debug Authentication Channel provides a path into the security enclave, enforcing a secure API for communication with an external agent. For details on Arm CryptoIsland IP please visit: Arm CryptoIsland product page
Authenticated debug accesses with SDC-600 and CryptoIsland
A debug certificate enables a specific list of debug interfaces and features on a specific device. The OEM generates "enabler" certificates, which give a specific developer access to debug the system through dedicated interfaces. The developer translates their required interfaces into corresponding debug certificates, by embedding the device ID of the platform into a full debug certificate. The full certificate must be signed using a secret key, that is rooted in the on-chip one-time programmable (OTP) memory.
The Arm CryptoCell ROM library includes a solution for boot-time verification of debug certificates, that enables debugging capabilities (including debugging of trusted code) on secure devices. Debug certificates are provided to the Trusted Execution Environment (TEE) for verification, using the hardware facilities that are available in the trusted domain. The Debug Control Unit (DCU) within the CryptoCell products is used to control and implement accesses to the debug interfaces of CPUs and other system resources, upon successful authentication of debug certificates.
Through the new SDC-600 Debug Authentication Channel, Arm provides a comprehensive security solution, including the mechanism for authenticating external debug access to the system through exchange of keys. This subsequently facilitates:
The CoreSight SDC-600 product provides an interface through which secure debug certificates can be introduced to the platform, through the existing Debug Access Port (DAP). It eliminates the need for OEM proprietary delivery mechanisms for such certificates.
The following diagram illustrates how a debugger station is connected to the target system through CoreSight SDC-600. In this example, the DAP delivers debugger commands to the CPU DAP and to the Memory Access Port (MEMAP) – both of which are blocked until secure software can successfully authenticate the debug certificate that validates the debugger. Once validated, the secure software would set the certificate specified CryptoCell DCU settings that would subsequently enable the CPU DAP and the MEMAP. The debugger transmits its debug certificate through the CoreSight SDC-600 communication channel. This communication is handled by its software driver which interacts with the CryptoCell driver through the software debug handler. Upon completion of debug session, the debugger will need to perform a system reset to clear the DCU value before resuming with normal operation.
How a debugger station is connected to a debugged system through CoreSight SDC-600
The high-level description of the debug authentication flow involves the following steps:
This step essentially ensures correct provisioning of the CoreSight SDC-600 for transmitting protocol messages. This includes power-up of the internal block if unpowered, and performing a protocol discovery check.
Debugger requests the SoC ID from the Secure CPU. The relevant SoC ID is derived through CryptoCell and is delivered back to external debugger.
Debugger requests the secure CPU to authenticate its debug certificate which includes the requested DCU values for this debug session. The debug certificate must be based on the provided SoC ID and must include Root of Trust (ROT) permissions to debug this specific platform.
Secure CPU with the help of CryptoCell verifies the debug certificate and applies corresponding settings to the DCU before responding to debugger’s Introduce Debug Certificate command with a message which includes the current values of the DCU, indicating what capabilities are now available for use.
As a summary, CoreSight SDC-600 provides a turn-key solution for authenticated debug with the following key features:
To request for more information on CoreSight SDC-600, please visit:
SDC-600 product page