They do, however, present attractive opportunities for hackers to steal personal information, intellectual property, and even take over or sabotage systems in the vehicle.
To realise the benefits of connected vehicles and limit the risk of hackers compromising system integrity and safety, the automotive industry clearly needs to take a lead in the battle to protect connected vehicles against potential cyberattacks.
Initiatives like the Secure Hardware Extension (SHE) specification established the foundation for an automotive cybersecurity subsystem and following SHE, the E-safety Vehicle Intrusion Protected Applications (EVITA) project, specified a hardware security module (HSM) extending the SHE concept to a programmable subsystem with three levels – Full, Medium, and Light – and addressed a broader range of use cases enabling security-relevant components and sensitive date to be protected against tampering/compromise.
Today the SHE specification is no longer independently maintained, and the EVITA project has ended albeit elements of both are still in use by automotive OEMs. However, as more connected cars enter production and cyberattacks continue to evolve in sophistication, a more standardised approach is needed.
Cybersecurity Regulation
Responding to this, the World Forum for Harmonization of Vehicle Regulations (UNECE WP.29) has developed a new regulation for cybersecurity: UNECE Regulation No 155, or UNR 155.
This requires the automotive industry to ensure sufficient risk management practices for security throughout the entire lifecycle, and across the supply chain.
UNR 155 became effective for new vehicle types in various regions from July 2022 onward, beginning in Europe, Japan and Korea. From 2024, it will apply to all vehicle types. Since obtaining vehicle type approval is dependent upon demonstrating compliance, the new regulations effectively make cybersecurity a mandatory requirement for new vehicles. Specifically, automotive OEMs must have a certified Cyber Security Management System (CSMS) and suppliers will need to support the OEMs. They must, for example, provide appropriate information to help demonstrate that supplier-related risks are identified and managed under the CSMS. The standard is closely connected to the UNR 155 regulation and broadly recognised as a means to achieve compliance with it.
Above: S32K3 processor security subsystem
Hardware Choices
New automotive grade application processors are emerging that provide a complete security subsystem comprised of hardware accelerators for cryptographic operations, secure memories and upgradeable firmware to allow ECU developers to comply with the latest regulatory requirements. Among them is the NXP Semiconductor’s S32K3 processor family with its hardware security engine (HSE) that builds on previous generations of proven security IP.
Exceeding the EVITA Full requirement, the HSE isolates security-sensitive information (e.g. secret keys) from the application and offloads the application core(s) from the demands of cryptographic operations during system start-up and at run-time.
Advanced hardware accelerators support AES-128/192/256 symmetric ciphers as well as RSA (up to 4096 bits) and ECC (up to 512 bits) assymetric ones with secure storage for more than 100 keys of different sizes and types. A secure boot feature is optimised for minimum latency and provides firmware authentication to bring the device into a trusted state. The HSE can also be used for over-the-air (OTA) updates with the encrypted binary file decrypted and authenticated during the download process. Once stored in the processor’s empty flash memory block, the ECU switches to the new firmware at the next boot sequence but with the option to perform a roll-back to the prior version should any issues arise.
Targeting a wide variety of automotive applications including body electronics, motor control and human machine interface (HMI) systems, the S32K3 processor family is built upon the Arm Cortex M7 core. Single, dual, triple and lockstep configured versions are offered to address a range of performance and safety (ASIL) requirements. Connectivity interfaces include CAN FD and Ethernet with Time Sensitive Networking (TSN) protocol support with cryptographic acceleration implemented close to the interfaces.
Finally, flexible power-management modes help reduce the overall system power consumption contributing to smaller ECU sizes, improved thermal management and, in the case of electrified vehicles, extended vehicle range.
Software Design Principles
In addition to the hardware, an appropriate software-development lifecycle is required to ensure that the software design, coding, testing, and documentation comply with application security requirements. Design techniques including the use of secure coding principles and extensive vulnerability testing are essential. Testing during the design, implementation, integration, acceptance and regression phases enables risks to be identified and corrected before they can be exploited. Communication paths within the ECU, between ECUs and from ECUs to devices external to the vehicle should also be protected by appropriate means, e.g. encryption or authentication.
Above: S32K3 processor software & tool bundle
Historically, functional safety was generally associated with automotive powertrain applications like braking, transmission and steering control, however, it now spans multiple domains from body control to advanced driver assistance (ADAS) where ASIL B to D criteria are commonplace. The S32K3 processor family has been designed as a safety element out of context as per the requirements of automotive functional-safety standard ISO 26262. A wide array of hardware safety features are available to the safety architect to meet their safety goals including: delayed lockstep cores; error correcting code (ECC) enabled flash and RAM memories; clock and power monitors; and multiple hardware redundancies and watchdogs. These and other safety mechanisms feed into the centralised Fault Collection and Control Unit (FCCU) which generates an alarm, interrupt or functional reset depending on the severity of the fault.
Like security, functional safety also extends to the supporting software. A Structural Core Self-Test (SCST) library detect latent faults in the cores during the start-up and shut-down phases and single-point hardware faults during runtime. Required for ASIL B applications based on single or dual core (non-LockStep configured) processors, SCST provides 90% fault diagnostic coverage and supports AUTOSARTM and non-AUTOSAR environments.
Like many companies, NXP also provides a comprehensive Safety Software Framework (SAF) consisting of multiple libraries for fault detection and reaction which establish the foundation for the developer’s safety application in compliance with the ISO 26262. SAF supports the device safety concept which defines how to achieve safety and availability under presence of faults by maintaining the device in one of the following states: Boot to Safety; Normal Operation; Degraded Operation; Global Recovery; Shutdown. The use of SAF can help reduce project development time as the developer isn’t required to learn the features of the core, NXP IP, interconnection between peripherals and error handling. For developers who wish to create their own safety frameworks, a package of AUTOSAR and non-AUTOSAR compliant Safety Peripheral Drivers (SPD) is also offered at zero cost.
Underpinning the processor are the new Real-Time Drivers (RTD) that also support AUTOSAR and non-AUTOSAR applications via high and low -level APIs respectively. Suitable for use in applications up to ASIL D, RTD replaces the traditional MCAL and SDK driver packages with a single set of enhanced and extended drivers that cover all processor IP and which do not require a production license fee. Developed using a using SPICE/CMMI Level 3 compliant process, the drivers can be configured using AUTOSAR integration partner’s tools and NXP’s S32 Configuration Tool embedded within the S32 Design Studio IDE.
The S32K3 family offers developers a wide range of devices with multiple hardware and software compatible sub-families offering performance, peripheral and package scalability to address a range of ECU platform requirements.
Conclusion
The electrified automotive future is challenging the industry to deliver vehicles that offer the latest in driver-assistance, infotainment, connectivity and powertrain innovations.
ECU developers require deep hardware and increasingly deep software knowledge of cybersecurity, functional safety and general embedded design topics.
For many customers this will inevitably require a level of technical support and distributors are having to expand their technical resources to include automotive-dedicated software engineers to help customers leverage the latest automotive processors.
Author details: Frank-Steffen Russ, Business Development Manager Automotive at EBV Elektronik
