Secure Applications

Keep out uninvited guests

As the amount of valuable IP and personal information available in embedded and mobile electronic products increases, they become more profitable targets for malicious software. Digital wallets, multimedia digital rights management (DRM), and corporate data storage are just a few examples of up and coming secure applications that push software complexity and connectivity to a new level, making the protection against attacks ever harder.

Arm takes security very seriously, developing a breadth of hardware, software and tools technology to enable products that can offer both feature-rich functionality and robust security.

Porting trusted execution environments

Devices based on Cortex-A processors benefit from TrustZone technology, which provides infrastructure for security in the hardware. These devices feature secure and non-secure processor modes, with a hard boundary between secure and non-secure software, as well as restricted access to hardware resources from non-secure code.

DS-5 Debugger provides full support for TrustZone, simplifying the creation and porting of Trusted Execution Environments to new devices. By connecting to the target via a low-level debug interface such as JTAG you can switch between secure and non-secure processor modes, and visualize memory contents and settings breakpoints that apply to only one of the modes. This way you can debug the communication between secure and non-secure software, and easily verify that your system is resilient against different types of software attacks.


ARM DS-5 screenshot showing i.MX53 secure debug session

S and N prefixes indicate secure and non-secure modes.


Development of trusted applications

Once a Trusted Execution Environment is in place, it provides the infrastructure to develop trusted applications, which provide services that require secure access to software and hardware resources. The Trusted Execution Environment provides a secure infrastructure to communicate standard applications with these trusted applications.

Arm is a co-founder of Trustonic, together with Giesecke & Devrient (G&D) and Gemalto. Thanks to our technical collaboration with Trustonic it is possible to debug trusted applications in the Trustonic Trusted Execution Environment via a dedicated agent-based connection.

Securing the debug connection to the target

Arm’s silicon partners wishing to protect their systems further can make use of the CoreSight debug infrastructure available in Arm-based devices to enable debug authentication. By authenticating a debug connection, only developers issued with a security key can connect to the target via a low-level debug connection such as JTAG, which provides a very high level of visibility of both the low-level software running on the target and the underlying hardware.

Debug authentication typically requires a secure hardware module added to the hardware, as well as an authentication server where developers can log in to gain access to the target. Arm’s wide ecosystem of partners includes companies like Discretix, who provides both parts of the solution.

The scriptable target configuration interface in DS-5 Debugger enables the communication with the secure hardware module in order to lock and unlock access to the device, as well as a connection to the authentication server. This enables platform providers to manage all security aspects of the solution, such as key management, key distribution and records of usage of keys.

Higher levels of protection for applications

The application stack is a common target for malicious software, as it can be used to gain access to sensitive data stored in the application’s local variables and passed between functions. Even worse, by writing to a return address in the stack it is possible to redirect the execution flow, effectively taking control of the application altogether.

The Arm Compiler has a dedicated feature to protect an application’s stack against malicious attacks. The compiler achieves this by automatically inserting a randomly generated cookie within each stack frame, and validating that it is still there upon function returns. If the software detects that security has been compromised it can then report a fault or turn itself down. Learn more on stack protection.