It is not uncommon for a modern automotive MCU or SoC to support a wide range of in-vehicle networking protocols with several communication buses for each protocol type. For example, the RCAR V3H SoC used in camera systems for driver assistance applications has two 1GbE Ethernet ports, three CAN FD channels, and two MIPI CSI-2 camera inputs. The RH850/U2A microcontroller supports up to 16 CAN FD channels and two Ethernet ports. The increasing number of network interfaces is a natural result of the increase in vehicle feature content, especially data-rich applications, and the emergence of domain-based electronics and more centralized electrical architectures. Whether it is electrification, integrated cockpits, ADAS, or infotainment, advanced E/E vehicle systems have one common theme: they are data- and computation-intensive applications. There has been a sharp increase in the demand for CPU resources to process the data from the many legacy in-vehicle communication networks like CAN FD\LIN\FlexRay, the emerging Gigabit Ethernet connectivity for on/off vehicle networks, and more specialized high-throughput sensor interfaces like MIPI CSI-2. Performing this processing in a hostile cyber environment multiplies the burden, as these systems must both process large quantities of network data reliably with low latency, and do so in a secure fashion with a strong emphasis on data integrity, confidentiality, and availability.
The phrase “hostile cyber environment” may seem an exaggeration, but automotive cyber security news and even mainstream media outlets are making clear the increasing cyber threats against automotive systems and the reality and imminence of cyber-attacks. Indeed, security has become a hot topic for automotive systems in recent years, and this is evident in the increased level of seriousness of OEMs, government agencies, and industry groups in getting ahead of the cyber-threat landscape. This is translating into a fundamental shift across the entire automotive supply chain, which is racing to ramp up security competency. For semiconductor vendors like Renesas Electronics, this means producing devices that offer high data-processing and communication performance that is both secure and also able to meet the many other constraints of automotive embedded systems.
Consider the case of a camera sensor that is sending 30fps at 8Mpixel resolution over the MIPI CSI-2 interface. Securing the image data from the sensor means the receiving SoC must decrypt and authenticate the data at a minimum of 6Gbps per camera sensor. To compound the challenge, single-camera systems are not adequate to enable many newer vehicle features. To perform this task in software alone would place a severe strain on the computational resources of the target device and may even impact the real-time responsiveness to the incoming sensor data.
The traditional approach proposed by EVITA relies on embedded HSMs with various levels of capability in terms of the types and numbers of included crypto accelerators, and the presence of either a CPU or a state machine to manage security resources. Architectures that rely solely on the HSM to provide secure storage and crypto-algorithm acceleration do not scale well and are reaching their performance limits.
Looking at the problem of authentication or decryption of large, real-time data sets, the bottleneck is frequently not in the crypto accelerators themselves, but in the overhead of transferring data through the various memory buses and communication interfaces. Moreover, these crypto accelerators are often shared across multiple security use cases and are not limited to network security, so the logistics of job-dispatching and prioritization for crypto tasks themselves add to the system loading and latency.
At the same time, unreasonable demands on single HSMs can be created by virtualization, multi-tenancy, heterogeneous OSes, various communication protocols, external and internal memory, and the explosion of network-data security needs. This forces a rethink of how these subsystems are organized and used but, again, the realities of the automotive environment mean that any solution must function within the real-time performance, computational, power, and cost constraints or else be deemed unusable.
Given these trends, Renesas is rethinking future Automotive MCUs and SoCs, to implement a new, scalable, cybersecurity architecture called Centralized Management and Distributed Acceleration.
Centralization of security management is essential to simplify the handling of security policies and decisions across all the subsystems in a single device. This translates to securely booting each processor core, providing a unified strategy for JTAG access control, and controlling the key material across various security accelerators in case of a security policy violation. At the same time, distributed security acceleration provides localized, high-throughput encryption and authentication services for the various secure-communication use cases such as SecOC, TLS, IPsec, and even proprietary sensor-security protocols that rely on standard cryptographic primitives.
Fourth-generation R-Car devices are taking the first major step toward this goal, including domain-specific HSMs and parallel crypto-coprocessors, which can be assigned to assist specific virtual machines, application cores, or real-time cores in the SoC directly. The system maintains isolation through fine-granularity access control on the AXI bus, separating access among masters at startup. This prevents the misuse of security assets by unauthorized virtual machines or cores.
The concept of distributed security is then further expanded in R-Car Gen5 devices, which will include in-line encryption engines for interfaces with standardized security, for an even more responsive system with near-zero data latency. One such implementation will be CAN XL, which is a successor to CAN FD that will provide bitrates up to 10Mbps and support payloads up to 2048 bytes. Securing these payloads with traditional software/HSM approaches would place a significant burden on both the host CPU and a shared HSM. To address this, CAN XL includes a standard security approach, which will allow for in-line encryption and authentication. The CAN XL security protocol itself does not force a particular implementation, but it is suitable for the integration of an inline encryption AES engine within the CAN XL controller, to authenticate and/or encrypt CAN XL frames during transmission and reception processing. This relieves the CPU of the overhead from encryption, authentication, and freshness handling.
Another similar application is the flash data encryption and authentication use case. UFS is one such solution, in which crypto engines embedded in the flash controller interface enable automatic, in-line encryption/decryption during memory writes and reads respectively, without CPU intervention. The PCI Special Interest Group (PCI-SIG) is working toward a solution for PCIe that would add link-level security to standard endpoint authentication and enable controller-integrated accelerators.
MIPI does not currently define its own interface security standards, but the alliance has organized a Security Investigation Group to determine strategy, provide guidance to individual working groups, and work toward consistent solutions for connected devices, including secure automotive sensors. This variation highlights the continued need for flexible solutions in addition to dedicated, standards-based approaches that allow integrated, transparent cryptographic acceleration, and clearly aligns with the Renesas strategy of relying on distributed acceleration as the answer to keeping up with the security throughput demands.
Of course, the concept of distributed crypto engines for high-bandwidth interfaces does not, by itself, produce a secure system. To achieve security, these resources must be tied together with a centralized security-management approach through a central HSM, which controls the assets of the various security peripherals. This central security manager must have the access and authority to interfere when necessary, to deny access to security resources or zeroize keys, to prevent malicious internal applications from taking advantage of the automated security features of the chip.
There is no doubt that security is reshaping our computational world, and at Renesas Electronics we live this daily as we design the security platforms that enable future systems to meet the parallel needs of performance and security in a reliable fashion.