Blog & News

A System-on-a-Chip (SoC) is regularly used in the automotive domain to build electronic control units (ECUs) with high demands on different functionalities and computation power. TeleChips, as a leading supplier of SoC components for automotive In-Vehicle Infotainment and cockpit solutions, chose SCHUTZWERK as an independent and experienced provider for automotive and embedded security assessments to analyze their new SoC series TCC803x (Dolphin+). This success story summarizes the approach and results of the comprehensive security assessment.

The Customer

TeleChips is a leading supplier of System-on-Chip (SoC) components for automotive In-Vehicle Infotainment and cockpit solutions. Besides automotive solutions, TeleChips also develops SoC products for Smart Home environments. Their SoC solutions are based on the Arm architecture and support different operating systems, such as Android, Linux, Windows Embedded Compact, AUTOSAR, freeRTOS, or QNX.

The Challenge

A System-on-a-Chip (SoC) is regularly used in the automotive domain to build electronic control units (ECUs) with high demands on different functionalities and computation power. Therefore, SoCs are typically used in head units or systems to support autonomous driving with high security and safety requirements.

TeleChips takes these requirements very serious, and therefore follows a security-by-design process in order to integrate security mechanisms early in the design phase of a SoC product. These security mechanisms should guarantee the integrity of data and functions, the confidentiality of customer data and intellectual property, and also protect against safety risks. While comprehensive security concepts and mature development processes are essential to effectively integrate security mechanisms in final products, it is also vital to test and technically assess the final solution from the perspective of attackers. According to the ISO 21434 standard, these assessments, also referred to as penetration tests, are now mandatory for automotive ECUs.

Therefore, in addition to their in-house security activities, TeleChips sought to further improve the security of their new TCC803x series chips (Dolphin+) through a comprehensive security assessment. TeleChips chose SCHUTZWERK as an independent and experienced provider for automotive and embedded security assessments to analyze their security measures and conduct this assessment.

The Project

The TCC803x SoC (as shown in the following figure) is based on an Arm Cortex-A53 Quad core (or Dual core) and Arm Cortex-A7 core designed especially for automotive infotainment, cluster, and cockpit systems. The SoC provides 2D/3D graphic engines, supports multi-display and multi-channel camera input, and can be run with a custom operating system such as Android or Linux.

The SoC is protected by several security features like a Hardware security module (HSM), Secure Boot and a One Time Programmable (OTP) memory. For the overall security of the real-time operating system, the secure implementation of a random number generator, of timers and the RTC as well as the protection of the Boot-ROM are also essential.

When presented with this challenge our embedded security team started by performing a comprehensive analysis of the SoC security measures and corresponding threats. The main threats we considered were:

• Direct bypassing of security mechanisms
• Unauthorized access to stored secrets and keys
• Unauthorized access to the secure world from the user world (privilege escalation)
• Manipulation of configuration
• Manipulation of the RTC and timers
• Manipulation of the real-time application from the Cortex-A53

Based on this initial analysis, we created a test plan for each of the following security mechanisms:

• HSM and Arm TrustZone integration
• Memory protection and process(or) isolation (MMU, DMA)
• Cryptographic algorithms, interfaces and Random Number Generation
• Integration of RTC and timers
• Debugging interface protection features (e.g. JTAG, UART)
• Communication interface protection over bus matrix (USB, I2C, SPI, CAN etc.)
• Secure Boot and Boot ROM protection
• Hardening of option byte settings and OTP settings
• Overall security configuration

The security assessment was conducted in a gray-box approach where TeleChips provided us with basic information about the SoC (e.g. datasheets, user manual and technical design documents). This information is typically available to developers using the platform. In addition, an example for the HSM API was provided. Source code for internals like the HSM and Boot-ROM, was not available. As typical for such gray-box assessments, some further limitations occurred. For instance, it was neither possible to access the TrustZone applications nor the OP-TEE TrustZone OS. Access to the internal components was limited to the user world on the Cortex-A53.

The test setup consisted of two development boards provided by TeleChips (see following figure).

These boards run an Android operating system on the main core A53 (an unrooted Android 10 OS) and a demonstration application on the real-time core R5. The interface for the HSM was made available via a kernel driver and an example application. The boards further provide various interfaces and access to the JTAG interface, as well as the debugging ports for the Cortex-R5 and Cortex-A53 via RS232 interfaces.

All analysis tasks were performed in our dedicated embedded security lab at the SCHUTZWERK headquarter in Ulm. The security lab is equipped with a comprehensive set of tools and devices to conduct also very low-level security assessments of embedded device. Attack vectors range from reading out flash storage over connecting to low-level debugging interfaces to remounting components to individually designed boards and launching side-channel attacks, such as power glitching or power analysis.

Based on the defined test plan, we performed several analysis steps of which some will briefly be discussed in the following:

Analysis of the Secure Boot Process

The secure boot process ensures the initial integrity for all applications running on the SoC. In order to assess the security of the boot process, we typically analyze the different boot stages for verification steps of the trust chain and dedicated signature verification procedures. For instance, we check if the root key for verifying the initial bootloader is stored in a tamper-proof storage, e.g., OTP storage, and that a manipulation of software and data at the different boot stages leads to a failure of the boot process. We also try to identify exceptions for applications or components of the SoC which have been excluded from the secure boot process.

There are often different boot modes available, which could have individual configurations for a secure boot process. Typical vulnerabilities could result from boot modes that do not perform a secure boot process and can be activated without authorization. If such insecure boot modes exist, we check if they are effectively deactivated, e.g., by respective OTP settings.

The Boot-ROM typically contains the first instructions executed by the main processor during the boot and thus represents the root of trust for the secure boot chain. The code is often treated as intellectual property and as such should be protected against readout. During our assessment, different possible attack vectors to extract the Boot-ROM content have been tested. For instance, we tested access from the Cortex-A53 cores or from the U-Boot bootloader console. However, read requests always resulted in a reboot of the whole system showing that the implemented memory read barriers or similar security measures are activated.

Analysis of the TrustZone

For the TCC803x series chips, the TrustZone implementation and inclusion is based on the standard ARM TrustZone architecture. For this architecture, we verify that the secure bit can not be set by the user world. If this is handled correctly, the security of the TrustZone primarily depends on the secure boot process to ensure only a signed TrustZone OS can be executed. In this case, the OP-TEE is loaded and the OP-TEE only executes correctly signed TrustZone applications. We typically try to modify the OP-TEE and to load a custom application in the TrustZone which is signed with the default key from the OP-TEE repositories.

If the standard ARM TrustZone architecture is correctly implemented, attacks on the TrustZone require an exploit of the running OP-TEE, a TrustZone application, or the possibility to bypass or deactivate the secure boot process for the OP-TEE. Respective vulnerabilities in this area were not discovered in the time scope of the assessment.

Analysis of Memory Protection

To prevent access to sensitive information and safety-critical components, several security measures like memory bus address filters and DMA controllers are implemented in the TCC803x SoC. In gray-box assessments without full access to all components of a SoC, available testing methods are very limited.

In our case, we were able to execute memory access tests from the Cortex-A53 via the U-Boot console running with exception level EL2 in the normal world (i.e., the NS bit is set to 1) and by dumping larger memory areas with a custom U-Boot standalone application written in C.

Especially, access to memory sections related to cryptographic components and persistent storage containing key material were tested. Unauthorized access to such ares could allow an adversary to attack the secure boot chain by extracting keys for firmware signing and encryption or by manipulating the persistent memory containing code that is executed during the secure boot process.

Memory access from the Cortex-R5 perspective was tested with an attached JTAG debugger as no custom code could be loaded into this core via the normal flash process. In this setup, the USB boot mode was selected and the provided fwdn firmware loader flashed. The debugger was then used to issue memory access commands on behalf of the Cortex-R5.

Analysis of Cryptographic Routines

If a SoC has an integrated crypto engine, we typically assess the cryptographic strength of underlying routines. For instance, we assess the entropy of the random number generator and the vulnerability of encryption methods to timing attacks in order to gain knowledge about secret keys or respective plaintext. We present an example from another project in this area in a different blog post .

Results

TeleChips puts a lot of effort in the integration of robust security mechanisms in its SoC architectures. This is reflected by our results which show that the achieved security level of the TCC803x SoC family is quite good. Nevertheless, our rigorous testing identified some vulnerabilities and opportunities of improvement in the SoCs security. The affected areas were the secure boot process, the AES cryptographic operation of the HSM, and the JTAG interface for the R5. Several of these issues were already closed by TeleChips during the assessment. This highlights the well established and fast responsive security management of TeleChips, and also emphasizes the benefit of conducting such assessments even for solutions with already mature security concepts.

Conclusion

Security assessments of complex embedded systems, especially in a gray-box approach, are challenging to plan and conduct. By leverage the experienced embedded security team of SCHUTZWERK, TeleChips was able to identify relevant vulnerabilities and areas for improvement in the already mature security concept of their SoC. Extensive and reproducible documentation provided by SCHUTZWERK, in combination with the well-established security management processes of TeleChips, allowed for swift mitigation of identified vulnerabilities, leading to an overall improved security of TeleChips products.

Finally, we would like to thank TeleChips for their great support and open collaboration during this project. We further appreciate the chance to share some insights of the project’s results. This highlights that TeleChips understands the process of security management as an iterative one which also requires an open discussion about common issues and pitfalls to make future products more secure.

References

• Title Image by Nic Wood/Pexels

~ Dr. Bastian Könings