UNECE R155 – How secure is your car against cyber attacks and hacks?

It doesn’t help, we have to get technical first and stick to specific definitions. UNECE R155 reads in full as follows: “Proposal for a new UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system“. This means that in the future, new and specific requirements will apply to the security of current (and from 2024 also older) vehicle types against cyber attacks. It makes sense – the vehicle as a rolling device, as a massive Internet of Things module, is now full of software, has an operating system, and receives over-the-air updates. There is therefore potential room for attack, which must be safeguarded by vehicle manufacturers – now also mandatory, in the form of UNECE R155. So now liability no longer ends at the edge of the vehicle, and not even for a short period of time.

Instead, the new regulation requires vehicle manufacturers to provide a cyber security management system, usually just referred to as “CSMS” for short, as well as prove that it actually works. This is even relevant for registration – without the proof no type approval for the corresponding vehicle type is possible.

Among other things, the CSMS in question must already contain processes at the concept level for identifying risks, evaluating them and, if necessary, eliminating or at least mitigating them. We’ll talk more below about how this affects end-user vehicles differently, for example, compared to an entire fleet of vehicles. Thus, attacks that have become known must be passed on, updates must be written – here UNECE R156 flanks the new regulation; more on this in the following paragraph.

Last but not least, an independent testing institute, conceivably an institution such as TÜV, must conduct an assessment to provide evidence that the CSMS complies with R155. Only by means of this proof a type approval for the tested vehicle is possible. It practically goes without saying that this poses enormous challenges for an industry that is still in its infancy in these respects itself. Expertise must exist on the testing side as well as at the manufacturer level, infrastructures must be formed, and what time will bring is hard to predict. This is because the R155 stipulates that coverage against cyber-attacks applies to the entire life of the vehicle. It is true that classic passenger cars are operated for an average of only 10 years. Individual examples, however, last much longer, in some cases decades, and even with a classic car registration, the manufacturer would still be responsible for the vehicle’s cybersecurity until even the last vehicle of this type is no longer actively operated on the road. That is, we say it quite profanely: A darn long time. We’ll address the obvious problems this regulation presents at the end of the article – first, we’ll take a look at the accompanying R156 and ISO/SAE 21434 regulations.

UNECE R156 – Fun with control units in connection with R155

Admittedly, the connection is obvious: to safeguard against cyber attacks, especially after certain attack patterns become known, it will be necessary to provide control units (and other electrical/electronic elements on board) with updates. This can be done at certain intervals in the workshop, but must also be able to be done quickly over-the-air in critical cases. The ability to act in the face of cyber attacks is a key point of the R155 already discussed. Pronounced, the additional regulation is called R156: “Proposal for a New UN Regulation on Uniform Provisions Concerning the Approval of Vehicles with Regards to Software Update and Software Update Management System” and is a further regulation of the UNECE (Economic Commission for Europe), which determines the future handling of ECU software updates.

As with the R155, a management system is again required, namely a “Software Update Management System”, or “SUMS” for short. In this case, too, functionality must be demonstrated by a testing institute accepted by the approval authority in order for type-specific approval to be granted. Similar to R155, a new ISO is to help with this: ISO 24089 (as of 26.07.2022, this is still in draft mode) will describe measures that will help the industry to implement the requirements of R156. The purpose of the regulation is to ensure that software updates of functions that are relevant for approval (such as exhaust gas, brakes, engine control) remain legally compliant even after the update, and that the updates are “safe and secure”. As far as possible, this means that the updates should be protected against malfunctions and bugs (such as the airbag deploying due to violent acceleration) and be tamper-proof. Even if an update fails, the basic function must still be retrievable safely and without problems.

ISO21434 – How manufacturers and suppliers find new liability paths and share responsibility

Whoever says UNECE R155 and R156 must also say ISO 21434. The name “ISO” anticipates it: This is not a law, but a standard for “Road Vehicles – Cybersecurity Engineering” in motor vehicles. This new standard is intended to apply to components in series-produced vehicles as well as to spare parts and accessories, and covers development, production, operation, maintenance and recycling throughout the vehicle’s lifecycle. The International Organization for Standardization (ISO) and SAE International, where “SAE” stands for “Society of Automotive Engineers”, are involved in this standard. ISO 21434 is therefore primarily a standard for the supplier industry. This ensures that all supplied components play their part in ensuring that the OEM placing the order can guarantee compliance with R155 and R156 and thus obtain approval for the vehicle type in question.

What did the new laws (R155, R156) and standards (ISO 24089, ISO 21434) mean for the automotive industry?

What is completely new for the entire industry is that manufacturers now have to take care of the vehicle’s cyber security over the entire life of the car. So we’re not talking about the maintenance of just any crypto library, but the entire lifecycle of the automotive product – and that doesn’t just apply to the materials used, but also extends to the cloud. This entails complete security monitoring (and building the underlying infrastructure). Vehicle data must be read out at regular intervals (which have yet to be defined), for example by reading out the fault memory during maintenance at the workshop. However, constant checking of the online connection is now also required, possibly on a daily basis, including an analysis for anomalies. The fact that this involves a lot of data being located in dedicated control units, which first have to be merged and brought into a uniform data picture, is just one of the many exciting challenges on the road to compliance with the UNECE regulations. Sure – the data all exists in the vehicle already. Until now, however, these were often not saved or simply discarded as irrelevant numbers. Now, however, completely new conspicuousness can arise – one control unit suddenly constantly sends small errors to the other, messages are sent: Malfunction, or phishing attack? A coherent evaluation of these data, which have so far been largely isolated, is therefore absolutely necessary.

The Jeep Cherokee Hack and Its Implications for Automotive Cybersecurity

There is no question that the move toward more cybersecurity, toward more functional security, is a sensible one. Consider Black Hat USA 2015, where Charlie Miller and Chris Valasek explained how they were able to hack the Jeep Cherokee’s WLAN practically from the comfort of their couch, since the associated password was based on the time of the first login and could thus be figured out. In this hack, researchers could control the music player, change stations, change volumes. Sounds harmless, but at 150 km/h on the highway it can be frightening and cause moments of danger and distraction. But Miller and Valasek also checked the steering wheel, engine, transmission, brake system, windshield wipers, air conditioning and door locks with a comparatively simple hack, and in addition, they were able to determine the GPS data of virtually every Jeep Cherokee. The opportunities for abuse were significant. This moment startled an entire industry, including politics, because until then people were hardly aware of the extent to which – and the sometimes simple means with which – brutal hacks could be carried out.

After all, it’s not just about controlling vehicles; the mass of personal data, from personal data to end-user credit card data, is also of high interest to cybercriminals. Sure – the hack took the researchers years, and important field tests have not succeeded, such as the management of components linked to the CAN bus. But it was a clear sign that the new possibilities in vehicle manufacturing also brought with them entirely new possibilities for the use and abuse of cybersecurity – and that action is needed to ensure that the industry does not lose touch with the technical standard and thus with user confidence.

State of alert thanks to UNECE R155: And who will do it in 20 years?

The history of the cyber industry in the context of the automotive sector is by all means a special one. To understand why there is now a lot of excitement in the industry and practically every manufacturer is suddenly talking about intensive intrusion detection, you have to know the situation before 2015 and the Jeep hack. Today’s car as an end product is basically a rolling Internet of Things device, weighing tons, surrounded by people. It is hard to imagine the tragic consequences that could be triggered by the hack of the engine control unit and a resulting acceleration that cannot be stopped by the driver. Security concepts that are well known and established outside the industry are therefore now also conquering the automotive industry, such as the aforementioned intrusion detection, TARA (Threat and Risk Assessment) or CVE (Common Value Evaluator). These concepts represent a huge step forward for the industry. Manufacturers sometimes didn’t even know in detail which software was installed at which point in the vehicle – which wasn’t necessary, after all, that’s what suppliers were for. The almost “holy grail” in terms of identification was the hardware part number, and even suppliers rarely tracked it. It was certainly still known which other supplier from the chain supplied the corresponding software for a particular ECU. But which version exactly, hardly anyone knew, which made appropriate monitoring almost impossible.

The fact that software is now being recognized and managed as an asset in its own right is an enormously important step for the industry. For their management, the complete tooling is now created, special knowledge is developed, technical possibilities are explored. Especially in the area of embedded software, classical IT systems do not get any further, so that new options have to be created so that statically generated, fully optimized codes are also taken into account in small standard control units for monitoring, updates, maintenance. For this purpose, it is necessary to know the software, which ideally can now be checked, for example, on a weekly basis by looking at a corresponding database.

To give a practical example, let’s just say Tier 1 supplier XX develops an ECU, with which some software is also supplied. XY needs to be fully aware of exactly what software this is, and be able to tap into various sources such as CVE databases, cybersecurity lists, etc. to look for “known issues.” Are there any new findings here, without any data readout at all, but simply by publicizing problems that occur based on vehicles that have been delivered? If something new emerges here, it must be reported, analyzed and, if necessary, remedied, ideally directly and over the air – and this over the entire life cycle of the vehicle. This is definitely one of the biggest challenges: How do you ensure such monitoring, including responsiveness, over 30 years? Will the required interfaces still be available at all in 20 years’ time? Do the operating systems still exist, are there still the specialists in the industry who have the necessary expertise? There is no experience here, as the scheme is far too new for even a single type of vehicle to have reached the end of its life cycle. So who is liable for a software error after 25 years? What will the industry do when essential hardware innovations conquer the market, such as quantum computers? Then the existing control units, the current computers and the algorithms of current cybersecurity are hardly worth the production costs at that time. In order to be able to continue to guarantee safety here, there is no getting around the physical replacement of control units in the vehicle. But how can this be implemented for a 20-year-old vehicle type?

Solution approaches, or: Why the industry can grow from its challenges

Of course: up to this point, the smoke around the UNECE R155 fire sounds a bit like the lamentations of an industry that has not always moved with the necessary foresight in the past and not in all respects, no question. The title of the article is no coincidence – it is a story of partial neglect of promising and permanently safe concepts. But in this word also lies one of the keys: concepts. Whereas classic algorithms in vehicle security used to say “yes” or “no”, “right” or “wrong”, an anomaly can now occur that says something like: “You, there’s something kind of funny”. This is open to interpretation and not very concrete. Well-positioned suppliers, meanwhile, are preparing for these scenarios, especially companies positioned in the areas of data science and cloud IT, such as Cognizant Mobility. Here, the focus has always been on scalability and expandability, and the concepts known from the extensive requirements management in numerous projects for well-known OEMs, which take the future into account, can be extended to include the specifications for UNECE R155 / R156 or ISO 21434. Not with a snap of the fingers, of course, but let’s face it: the journey is fun, too. We are people, explorers, researchers – the terra incognita is not so unknown, and it is tempting. New concepts don’t have to be developed, no: we get to develop them, ensure safety, and put an all-around great product on the road, and grow together through the challenges. Aggregation of fault patterns via a fleet picture is one such approach, where monitoring is not done at the vehicle level, but at the fleet level. Of course, this cannot always prevent a single vehicle from being attacked in individual cases, but the spread of everything that makes up a larger picture can already be efficiently stopped. An extremely important basis for the upcoming UNECE R155 regulations.

The “end of life” of the vehicle type must also be completely re-evaluated. It used to be simple: if the last vehicle of its type was delivered to the scrap yard, that was it. Put it in the press, press the cubes and you’re done. Today, however, there are numerous data connections in the car. Almost any car can access OEM systems, data is sent and received, and a hack of the systems, the underlying cloud, would be conceivable. The definitive end of the vehicle will therefore also be a cryptographic end; corresponding systems must be made inaccessible. So, thanks to UNECE R155, this also has to be taken into account in the future – where are my interfaces, where are my connection points, and how do I secure them and how do I deactivate them at the end of the vehicle’s life cycle

These are the advantages that the automotive industry has over UNECE R155/R156

A completely new aspect of the regulations is that cybersecurity and updates are now relevant for approval. This requires proof that the manufacturer has fully prepared and is willing to continue to care. Interestingly, only one of them is actually possible, namely the proof of preparation. Whether an OEM will succeed in really taking care of this completely remains to be seen, as there is currently no experience of this, as simply not enough time has passed for a vehicle type covered by the UNECE rules to have reached the end of its life cycle. Let’s talk about it again in 30 years.

Nevertheless, there are first car manufacturers who have already provided proof for individual types. There is also still a certain gray area in the UN specifications here, as there are still transition periods, some of which are limited to completely new vehicle types or to modifications of existing types. However, no one really knows yet what the OEMs will have to face.

Above all, responsiveness – an important part of UNECE R155 / R156 – must be ensured and poses the greatest challenges from the points described, if only because hardware and software change rapidly and essentially over the years.

Nevertheless, the industry is not helpless. Experience from the safety area can be transferred to the security area, especially from the area of functional safety. Of course, there are differences, but the basic concept of doing a Thread and Risk Assessment (TARA), for example, is not completely new at the base level. Companies that were already strongly positioned in the area of safety are also suitable for the lifecycle liability of security and can certainly adapt more quickly here than other suppliers or even large original equipment manufacturers.

Go ahead: UNECE R155/R156 and ISO 21434 and their challenges

It is obvious that despite the light at the end of the adhesion tunnel, there are still sleepers on the tracks that may encourage tripping. The question of margin alone is an interesting one: the final price of a vehicle is based on a calculation that is invalidated by the new specifications. Who bears the additional costs of building an entire infrastructure, including tooling, skilled workers, and systems that have been functional for decades? Which are driven further up through maintenance, analysis and response? Condemning the end user to a voluntary cyber flat fee can hardly be the solution. Will customers even be willing to book in-car subscription packages that promise more or less functionality in a few years’ time? Or will drivers only think in terms of the previously known equipment packages? The implementation of UNECE R155 and R156 must therefore basically be feasible free of charge, or at least with the existing on-board resources – completely unrealistic, of course. So, in addition to pure implementation, it is an urgent task for the industry to find fair solutions here, a model with the predicate “one fits all” – because without suppliers who can meet the requirements and are part of the pricing structure to do so (more than ever), OEMs are also unable to obtain approvals for their products.

Other hurdles on the way are also many of the open points that the UNECE rules have. The question of when an OEM can really prove that it is prepared for R155 is already somewhat complex. How many attacks of what nature do you need to be prepared for in order to be truly “ready”? After all, safety liability is not only limited to the car, but also to the back-end systems thanks to R156. Their current state will certainly be completely obsolete in 15 years – and experts for the operation of obsolete systems will not be any easier to find than is already the case today, after all, specialists are already being hotly courted. What to do with obsolete hardware because quantum computing offers completely different options, both in terms of OEM and end-user offerings and for attackers? For a quantum computer, current security algorithms would be little more than a joke. Completely new structures in security are therefore needed. But they would be anyway, so it is certainly one of the smaller problems – but it is there nonetheless – and brings directly even more worries in the baggage. To meet new cryptographic challenges, hardware parts will have to be replaced, especially those with time-critical tasks, such as control units for brakes, steering or engine control.

It is also not yet at all clear whether the tests to determine the extent to which a vehicle type complies with R155 and R156 will then only be possible on a type-specific basis, or whether cyclical tests of the entire company would be conceivable. And then there is a nasty loophole that can set standards, especially in terms of trust: Manufacturers could decide to simply waive the update capability of individual components. A game with fire, after all, an OEM wants, can, must be competitive. But a component that cannot be updated does not require proof of SUMS preparation (we remember) for that component. In such a case, the entire component would have to be replaced if there is a safety risk – but this can then be passed on to the supplier. It is more than questionable whether they will even take such a clear risk in terms of warranty.

UNECE R155 – Crisis is opportunity!

Let’s bring a long line of evidence to closing argument. The History of Data Violence is clearly over, and an era of first pioneering spirit is coming to an end. The terra incognita lies fallow before us, and at the end awaits a duty of proof with lifelong liability. How we get there, whether as suppliers, as OEMs, as programmers, as car enthusiasts, is up to us. While the shock waves have been slowly spreading for years and have reached even the last participants in the industry, clever minds are working on solutions. It has never been more fun to be at the very beginning. We have basic knowledge, we develop tool landscapes, methods, systems – and that’s fun. Research is no longer limited to optimization and further development: something entirely new can, may, must be created, and let’s face it: we absolutely want to develop safe products that are fun to use. Cars need to be safe, from start to finish, and suppliers and OEMs alike are happy to deliver great, clean, safe vehicles into the hands of their customers. Admittedly, this will require a rethink in many niches of the industry. Procedures have to be created, requirements management will experience a blossoming without equal, and finally everyone is in the same boat again in terms of know-how. Will say car.

Cognizant Mobility, as a proven expert in Safety, Functional Safety, Attack Path Analysis, Requirements Management and other core competencies, is definitely ready and excited to tackle these challenges. Feel free to contact us via the contact form, or just call, email, follow us on LinkedIn – and then we’ll have a chat and see what we can do for you.

There is a lot to do. Let’s do it.