EN 
DE Evaluation of certificate handling and security in cars
Authors: Florian Pramme, Jan-Phillip Foltz, Prof. Dr.-Ing. Gert Bikker, Ostfalia University of Applied Sciences
Contribution – Embedded Software Engineering Congress 2017
This article presents the research focus "SecuRIn – Security Reference Model Industry 4.0," funded by the Lower Saxony Ministry of Science and Culture. The goal of this interdisciplinary research focus is to develop procedural models that support companies in easily and securely developing Industry 4.0 applications in the future and operating them securely throughout their entire lifecycle. The use case used in this article focuses on the digitalization of vehicles and the associated challenges. Specifically, studies have been conducted to analyze the temporal behavior of current automotive encryption chips within the security lifecycle.
Introduction
The networking of cars with the internet and with each other has been discussed for some time. The advantages offered by the possibility of a vehicle connected to its environment are obvious. Software updates „Over-the-Air“ This would mean immense cost savings for car manufacturers. Furthermore, driving could be made much more comfortable and pleasant if the vehicle communicated with the next intersection early and initiated a green light phase, or if high traffic volumes and hazardous areas were relieved through intelligent vehicle rerouting. But where doors are opened, uninvited guests are sure to follow.
State of the art
The possibility of attacks on vehicle networks has been demonstrated publicly on several occasions. One example is the 2015 attack on the Jeep Cherokee, in which two security researchers exploited a vulnerability in the infotainment system via the internet to take control of the vehicle while it was in motion [1]. Even with vehicles that are not connected to the internet, it has been possible on several occasions to either take control of a vehicle or drastically impair its operation. For instance, the same two IT security specialists managed to interfere with the braking and steering of a Toyota Prius while it was in motion via the OBD diagnostic interface, which has been in use for several years [2]. This demonstrates that vehicle security has by no means received sufficient attention in the past.
Cryptographic methods in the vehicle network
Generally speaking, the goal of cryptography for in-vehicle communication is more focused on integrity, Message authentication and authenticity focused, less on confidentiality. The content of these messages is not necessarily sensitive enough for the operation of the vehicle and the bus system. When using a cryptographic method within this domain, it is particularly important that communication is not delayed.
Asymmetric encryption is unsuitable for in-vehicle communication because the hardware requirements and constantly increasing key lengths for these methods are too high. Furthermore, asymmetric encryption is not appropriate for the broadcast messages of the CAN bus in the vehicle. Therefore, a symmetric method should be used primarily for standard communication in in-vehicle communication. Message authentication could be implemented either through encryption with the addition of a nonce in the message or through MACs. Regardless of the method used, the distribution of keys and the arrangement of the control units in the network are important. Separate subnets with their own keys and a supergateway, which incorporates many security mechanisms such as... Firewalls, Intrusion Detection, Key renewal and ECU authentication The implemented solutions sound promising. Updates can also be verified beforehand by this central gateway using asymmetric methods. This allows the control units themselves to completely forgo asymmetric methods. Furthermore, such a topology would closely resemble the topology already used in vehicles, with subnetworks and gateways. The keys for the subnetworks should be renewed regularly to make it more difficult for attackers to crack them.
The already heavily utilized control units typically lack the resources for implementing additional cryptographic algorithms. Furthermore, these algorithms are often highly demanding and require significant processing power to complete tasks within prescribed timeframes. Therefore, it is essential to provide the control units with additional hardware optimized for cryptography. This hardware will become standard in control units in the future and will implement a set of different cryptographic algorithms. The following measurements demonstrate that this hardware acceleration can offer a significant performance improvement and relieve the main processor.
Performance measurement of cryptographic methods on I.MX6
The following was suitable for an exemplary comparison of a potential cryptography hardware chip with a normal control unit: Cryptographic Acclerator and Assurance Module (CAAM) of the NXP i.MX6. This supports a wide variety of cryptographic methods, thus meeting the EVITA medium requirements [3]. Measurements are taken once on the main CPU of the i.MX6 and once on the CAA module, which is connected via the cryptodev The library is addressed. Measurements are taken for 5 seconds each for data blocks ranging in size from 16 bytes * 2^x to 65,536 bytes, and the number of successfully encrypted/hashed blocks is counted. A data throughput is then calculated from this data. Additionally, the diagrams include measurements from Escrypt GmbH for their cryptographic library. CycurLIB [4] included for comparison with real control units. This one has a 32-bit Cortex-M3 @ 80MHz processor.
(see. PDF, Image „Fig. 1 – AES CBC encryption with 128 bit key length“)
The measurement data for AES CBC encryption with a 128-bit key length can be found in section A. It is evident that the software solution exhibits a relatively constant data throughput of around 35 MB/s, regardless of the data volume. The hardware solution, on the other hand, struggles with small data volumes but performs better with larger ones. The control unit has a data throughput of approximately 0.76 MB/s. Therefore, even with data as small as 64 bytes, the hardware support demonstrates a significant speed advantage over the ECU.
In Fig. 1 (see. PDFThe focus is on CPU utilization during measurements for key lengths of 128, 192, and 256 bits. It is clearly visible that the CPU load during the test procedure exceeds... cryptodev(HW) decreases significantly. The larger the data blocks become, the lower the CPU load, as more processing power is offloaded to the crypto chip. The key length is irrelevant to the CPU load. OpenSSLThe software solution requires constant full CPU load, resulting in a sustained CPU usage of 100%. Surprisingly, the CPU usage is relatively high with small datasets. In contrast, the hardware solution shows a CPU usage of 70% in such cases. This likely explains the poor performance with small datasets on the hardware solution.
Fig. 2 (see. PDFThe graph shows the percentage increase in time per packet. Specifically, if a 16-byte packet takes one millisecond to encrypt and another 32-byte packet takes two milliseconds, the resulting increase is 100%. The software solution always has an increase of approximately 100%. The hardware solution, on the other hand, shows an increase of only about 10% up to a size of 1 KB. Therefore, the encryption time is almost constant regardless of the data volume. This is particularly important for vehicle networks, as they have strict real-time requirements.
Comparing the CAA module's measured results directly with the software performance figures is rather disappointing. However, it's important to note that the i.MX6 in question uses an ARM Cortex A9 quad-core processor with a 1 GHz clock speed. Such a processor is not common in currently used control units. Therefore, it can be assumed that this CAA module still offers a performance improvement in an automotive control unit. A comparison of performance with standard control units paints a clearer picture.
However, it is generally apparent that the hardware chip's performance is rather low at smaller block sizes. At the same time, the CPU load is unusually high at these points, even for the hardware. It is likely that the bottleneck here is the transfer of the encryption task from the CPU to the CAA module. The best hardware results are always found at the points with the lowest CPU load. If these transfer problems were eliminated, the performance could certainly be improved significantly, even at smaller blocks.
What's particularly interesting is that hardware encryption for data blocks up to approximately 1 KB doesn't result in significant differences in encryption time. This is especially important in automotive environments, as time-critical control data must have a known maximum delay, and the data blocks don't exceed 1 KB. Only with larger data blocks does the percentage increase for the hardware chip become more pronounced, but it doesn't reach the 100% mark until at least 65 KB, which corresponds to a doubling of the required time compared to the previous block. Since the block sizes always double per step, but the required time doesn't, this further demonstrates that the CAAM chip performs better with larger data blocks in these measurements.
Bibliography
[1] A. Greenberg, „wired.com,“ July 2015. [Online].
Available: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/. [Accessed October 2017].
[2] A. Greenberg, C. Miller, and C. Valasek, „Hackers Reveal Nasty New Car Attacks,“ Forbes Security, July 24, 2013.
[3] EVITA, „Final EVITA Workshop on Security of Automotive On-Board Networks,“ November, 2011.
[4] W. Siebenpfeiffer, Networked Automobile, Springer Verlag, 2014.
authors
Florian Pramme M.Sc. has been working as a research assistant in the research group of Prof. Dr.-Ing. Gert Bikker at the Institute for Distributed Systems at Ostfalia University of Applied Sciences since 2011. After intensive work in software testing and simulation, his current research focus is the virtual validation of embedded systems. He is also involved in teaching and the development of autonomous vehicles.
Jan-Phillip Foltz B.Sc. has been supporting the working group since 2017 in the field of research on safety systems in vehicle networks.
Automotive – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of automotive/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Automotive – Expertise
Valuable expertise in automotive/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
