“Security for the Car: Rethinking it from Scratch?”
Cars are going online – is the automotive industry prepared for the associated security risks? A talk with experts from Giesecke+Devrient, Consulting4Drive and IAV
The “connected car” is opening up all sorts of business opportunities – such as retroﬁt functions, databased services and ever more extensive driver assist systems. Yet ﬂexibility and the ability to communicate also harbor risks and make the car vulnerable. Commercial IT has developed a number of measures and methods to combat threats of this nature – but can they be applied to the car without further ado? In this interview with experts, Dr. Christian Schläger (Head of Cyber Security Product Management at Giesecke+Devrient, specialists in mobile security technologies), Timm Kellermann (Managing Director of Consulting4Drive, IAV’s management consultants) as well as Kai Feuerstake (Senior Vice President for Hardware and Software, Security at IAV) discuss the changes that need to take place in the automotive value chain and development processes. The interview was facilitated by Christoph Hammerschmidt, journalist with a special focus on vehicle electronics and IT.
Cars are becoming increasingly autonomous, they are going online, connecting and using data services. This also exposes them to risks lurking in cyberspace. How well is the automotive industry prepared to cope with these challenges?
Feuerstake: Security is not a new issue in the automotive industry because it has always been about protecting the car and its components – you only have to think about the digital key and access mechanisms or the immobilizer. Connecting with data services and the cloud also involves the application of common security technologies, such as authentication and encryption. What’s definitely still lacking are security mechanisms between the control units and components in the vehicle. The processes involved demand significant computing capacity and are an immense burden on network traffic. Besides considerations on necessary standardization, such as in Adaptive AUTOSAR, discussion is now leaning heavily toward vehicle/security architecture and to the question of how much security the industry can or wants to afford.
Kellermann: I think that what we understand by security will in future need to embrace a whole new dimension. The subject will become far broader, and the consequences of a potential cyber problem will also be much more serious than they are today. What would happen, for instance, if an autonomous car were to be hacked and turned into a weapon? The responsibility for preventing a risk of this type has become far greater in recent years.
Schläger: In the car, the question of security is present in concentrated form. It concerns consumer data, added-value services that access personal and payment data. This matter is familiar from industry which has already gathered a certain amount of experience in protecting machines. With the car, though, there’s the added factor of mobility. This makes the question of safety and security – which are closely connected – very complex. On the other hand, the OEMs already have mechanisms in place to monitor matters like this. They have their security operating centers, they have their incident and event processes. They must now extend them to “endpoint vehicle” at all of these levels. We from G+D Mobile Security know how many vehicles are being put online with our SIM cards alone. The car is already an IoT element, and on a relatively large scale too. So, OEMs haven’t started today to think about how they are going to deal with all this. wie sie das managen wollen.
The future will also see the vehicle’s software being updated online. Doesn’t this add a whole new dimension to the car?
Schläger: Yes, but on the other hand, this is the only way of keeping a car safe and secure throughout its life cycle. The main problem we see is the long life cycle of vehicles. With the security chips we install today in a Master or Visa card, we have a life span of three years before the card becomes invalid. With a vehicle, we have life cycles of ten, ﬁfteen years or even longer. Of course, there’s always something that can be updated every now and again, but not the hardware. I need to do this with software updates over the air. The important matter is the timing of such security updates. In the IT environment, we have meanwhile arrived at a rhythm of no more than a month. But with a car – what service intervals do they have today? Two years? 15,000 kilometers? Twelve months? That’s far too long for updating software. This can only work successfully if the software is quickly updated whenever necessary by means of online mechanisms through a secure channel. Otherwise you don’t have a chance.
Kellermann: Exactly! The frequency and extent of these updates create a whole new dimension. We in the automotive industry have just maneuvered ourselves into an interesting catch-22 situation. We believe we can add a lot of value by providing cars with driver assist systems. This reduces strain on the driver and lowers the level of stress. At the same time, this means that we will have to make ongoing improvements to safety-critical software in the ﬁeld too. In the worst case, these updates will have to be made every day – normally though it will be once a week, maybe once a month. Whatever the case, this is a frequency we have never had in the automotive industry before. Given this perspective, we are assuming that it must be possible to exchange a small part of the electrics/electronics to provide suﬃcient protection and ensure vehicle, occupant and pedestrian safety over a vehicle’s life cycle.
Feuerstake: This raises even more problems. Today, when a car has been launched, it is passed from Engineering to Aftersales. As things stand today, changes are only made to control unit software if frequent problems occur in the ﬁeld. In this case, it is a matter of getting individual suppliers to make the necessary changes, most of which are functional. In future, the situation will demand that control units are regularly provided with security patches – for up to 15 years after SOP. Meeting this requirement will involve adjustments to the manufacturers’ processes for managing development, release and content. Updating existing software in the ﬁeld is likely to involve huge amounts of development work. This challenge is exacerbated by the variety of models and the necessary validation and release processes.
Software will also open up completely new business models. For example, customers will be able to purchase speciﬁc car features in aftersales by software update.
Kellermann: This aspect also involves issues relevant to security technology because it affects the driver proﬁle consisting of user rights and user-speciﬁc functions. For the latest cars, we are noticing that it is still very diﬃcult to change a user proﬁle. So far, the automotive industry is not particularly well prepared for identity management. Which person is currently allowed to use this vehicle – whether on a private basis or in a shared-mobility context? In other words, the car must know who is currently driving it and also the rights that person has. The licenses not only apply to the car but also to the driver. This involves rethinking on a grand scale. Protecting these proﬁles, guarding them from misuse and keeping a complete record of all changes and the persons involves is a very complicated process.
Schläger: Identity management is in fact one of the core functions we will have in the car. The car has an identity, the control units have one, so does the manufacturer and, of course, the drivers or fleet managers. Basically, this is very similar to what we offer our customers from the banking or telecoms sectors. This is what has triggered a process of rethinking at many of our customers who, as a result, no longer see themselves as product manufacturers but as service providers. This will be just the same in the automotive environment. As far as vehicle use is concerned, these identities can be stored where they are secure – for example, in the secure area of a cell phone which is already used as a key. This secure device can manage access to any other service in the same way as it can provide access to the vehicle. This can also be a payment service. What’s important is being able to manage such identities in a secure way. Once that’s possible, the technology behind it is ultimately immaterial.
So, will every manufacturer have its own identity management platform or will there be an IT standard that applies to all manufacturers?
Kellermann: We have discussed this matter time and again but still not found any ﬁnal answer. Proceeding from a technically perfected environment, it would in fact make sense to have a standard in the industry. But when a new technology is evolving and it’s still not certain as to which solution will prevail, it’s too early to think about standardization. This makes us assume that for the time being the OEMs will try and establish their own standards and platforms to give themselves a competitive edge. Time will then tell as to whether it will be possible to agree on shared interfaces and on partial or extended standards to protect society and enhance collaboration with business partners. It is in these last two points that I see signiﬁcant potential for standardization at an early level of maturity.
Feuerstake: This raises the question of whether it makes sense to develop such as function as a standard. Diversity has the charm of not leaving every gateway open in case anything were to be hacked.
Does the automotive industry really need to invent these things itself? The IT industry has had technologies of this kind for years; there’s no way the banks could exist without them. In implementing secure functions, can’t the automotive industry simply help itself to the IT toolbox? Or does the automotive sector need to tread its own path here?
Feuerstake: There’s no need to re-invent everything, that’s not what we are attempting to do. The main reason why some of the technologies from IT can’t be applied directly to the car is a scarcity of resources in vehicles. PCs, servers the cloud – all of them have far more computing power than vehicle control units, exceeding it many times over. In the car, we will only see high-performance systems of this type in domain computers in the near future. Beside the cost factor, size, weight and durability are the main obstacles. Otherwise, many things from IT could go into the vehicle straight away. Of course, we are also seeing many approaches and discussions toward moving algorithms and functions from the car and putting them on the cloud. When it comes to security, though, I can imagine that this will only take place on a limited scale.
Schläger: This is compounded by another problem: someone needs to “translate” the subject of security between IT and automotive sector. As we come from diﬀerent industries, we have diﬀerent development cycles, lead times as well as diﬀerent requirements and standards. This distinguishes the automotive industry from classic manufacturers, network providers or the banking industry. Expectations are constantly diﬀering as to how we will develop as well as how we can work together. On the other hand, I am also seeing that IT can learn a lot from the automotive industry, particularly when it comes to the matter of reliability. And in IT, I realize that the concept of “long term” has a completely diﬀerent meaning than it does with you.
Kellermann: I think it’s worthwhile taking a closer look here. A life cycle of ten, ﬁfteen years is a very long time in IT and security matters. This means we need to focus our thoughts on how much ﬂexibility we want to get into the car from the aspect of replacing hardware and the intervals for updating software. The age of the digital platform economy has only just dawned. One ﬁnding is already becoming evident though: in the Internet of Things, vehicle and back-end system ﬂexibility will provide a far greater level of eﬀective added value – both under security aspects and under aspects of consumer orientation – than has so far been the case in the automotive industry.
The boundary conditions have shifted too. Cars have been online in the past too, but this was rather in a supporting capacity or the exception. In the future, the car will in principle be a device in the Internet of Things (IoT) and also managed as such. Oﬄine status will occur and there will be special processes for this. Unlike a bank, there is the additional aspect of physics in a car. It moves, presenting a source of physical danger. People sitting in the car must be protected, just as those in the driving environment. This shows that security and safety are concepts that cannot be viewed entirely in isolation of each other. In other words, we not only need to reﬂect on the technical architecture but also on the sequences or processes that protect users in their mobility context. So far, cars have been manufactured and driven out of the factory gate. Mr. Schläger has illustrated that we will probably need to carry out an update every few weeks in future, maybe even more often.
Schläger: I tend to disagree. We have similar product life cycles in mechanical and plant engineering. Today, we are dealing with machines that are still active in the ﬁeld whereas other specimens from the same series are museum pieces.
Feuerstake: But not in the same number as in the automotive industry. And are these machines connected to the Internet?
Schläger: Yes, in the meantime, they are. We have a solution for this: separating product and security. I can’t update a machine anymore; we integrate an upstream security component on separate hardware that acts as gatekeeper. This deﬁnes a boundary that can be monitored. Of course, in the case of a system like the car, which I put into someone else’s hands, this is somewhat diﬀerent than for a machine.
Feuerstake: That’s precisely the crux of the matter. Any potential attacker wanting to hack vehicles and access them later from a remote point will ﬁrst purchase one or several cars and then get to work on them. This is something we won’t be able to prevent. This risk is not necessarily given in machine and plant engineering.
Schläger: That’s right. But we can learn from the manufacturers of mobile devices who have the same problem. They put a million or more devices on the market and know that anyone getting their hands on one will ﬁrst try and crack the security features. These manufacturers use the traditional approaches from IT. You need to monitor the devices as well as the context of their use, you need a mechanism for detecting fraud and you need processes that let you respond very quickly. But managing such a ﬂeet of vehicles and devices requires a completely diﬀerent infrastructure and an architecture of processes, capacities etc.
Kellermann: Within the future automobility framework, this security analytics component – i.e. fraud detection, monitoring etc. – will be really huge and extremely important. I can see hardly any parallel with an application in any other sector with such sensitivity – both in terms of production ﬁgures as well as relevance to society. We as the industry are entering new territory because we need to combine the technologies, processes and response mechanisms for the automotive industry in a new way. This becomes evident from one dimension alone. When I notice that a security-relevant irregularity occurs in the ﬂeet I am monitoring, I must, under certain circumstances, be in a position to respond within minutes and activate an emergency program. In the past we have not had abilities like this. They do exist for military applications and for other ﬁelds of application involving low volumes. But the combination of mass distribution, mobility, inherent hazard potential because of speed and, on top of all this, highly complex functions, which will in future be largely software-based, produces a whole new dimension. Here, it is necessary to develop new solutions for the automotive industry that involve various ﬁelds of competence.
To deal with this, the IT security sector has CERTs (Computer Emergency Response Teams). These are teams that can respond to such problems. Would this be a viable path?
Schläger: We are only familiar with CERT systems of this type from closed systems, such as the ones found at operators of critical infrastructures. They must also respond in real time. But these are stationary, monitored systems. I can’t take a CERT model like this and apply it to a ﬂeet of vehicles. Ultimately you need to make decisions on a case-to-case basis: what is currently going right or wrong with this speciﬁc vehicle, at this speciﬁc point and with these speciﬁc vehicle occupants?
Feuerstake: OEMs will inevitably need to put the subject on their agenda. Customers will expect their second largest investment in life – after buying a home – to be well secured and protected from manipulation. In general, it will not be enough to detect and ward oﬀ an attack – it will be important to ﬁnd out the attacker’s intentions. For OEMs or ﬂeet operators, this information is, of course, highly interesting. They can use it to improve their defense strategies and, if necessary, predict future problems. Monitoring of this kind would have to be relatively detailed, perhaps even extending down to control unit level. I have already spoken about the next steps needed to close security loopholes and the necessity to include ECU suppliers as far as EOL (end of life). But I still don’t have a clear idea of which strategies will need to be chosen if a ﬂeet is hacked or infected and no appropriate patch is available right away. Simply ceasing to use the car – as you could perhaps do with a home PC – is hardly an option. These are all highly interesting aspects and challenges that we will need to face.
Kellermann: Basically, these security scenarios can be broken down into three areas. Firstly: my consumer or my customer is fraudulently trying to obtain a service that he or she has not paid for. Secondly: I am dealing with a criminal activity relating to a manufacturer or customer group, or thirdly: I am looking at a terrorist energy setting out to harm society. They all involve highly complex threat and risk scenarios. Basically, these aren’t new, but they are in the context of the automotive industry. In view of this, we are well advised to fundamentally rethink security at cross-sectoral level – as an element of architecture and a process of our IoT products and services, and not just under the aspect of technology. This concerns the structure of our process landscapes as well as our approval processes, rules and regulations. “Secure and safe by design” – we have tried to think along these lines in control unit development, likewise with the ECU network. But in the context we have just discussed, with its many new usage and misuse scenarios, we must very carefully reﬂect on the architecture of processes and supplier relations in terms of the need for action under safety and security aspects.