How connected cars should handle security

Did you ever wonder how your car works? Surely, there are enthusiasts who thoroughly understand the principles of an internal combustion engine and can talk about the differences between the Atkinson and Miller cycles. I can’t boast such deep knowledge myself, but I’m not the only one. Most people now see a modern car as a mode of transport to move from one location to another; they never think about what is going on inside the vehicle when the driver, for example, presses the accelerator or turns the steering wheel. Let us try and trace the evolution of the car to understand how those changes have affected us and may affect us more in the future.

For many years after its invention, the car remained a purely mechanical device — or, to be more precise, it was an electrical and mechanical device. A wire connected the gas pedal with the throttle, which opened as the pedal was pressed and added mixture to the cylinders. The brake was linked mechanically to the pedal. Let us define that first generation of cars as Auto 1.0. There were no electronic devices in the cars of that era. (This division of car generations represents the author’s opinion only and may not coincide with generally accepted views.)

How connected cars should handle security. #carsecurity

Tweet

The transition to the second generation started with the advent of the mass production of semiconductors. Electronic components began to appear in cars. Engine control units and antilock braking systems blazed the trail.

Before electronic units appeared, the carburetor performed functions of injecting an air–fuel mixture of desired consistency into the engine’s cylinders, and engineers focused on improving carburetors. The first electronic engine control units were developed by Italians for the Alfa Romeo 6C2500 model in the mid-1950s. The unit was named Caproni-Fuscaldo.1

As for antilock braking systems, the technology was patented by Bosch in 1936. But the actual realization of the idea then failed as a result of deficient digital electronics, whose function was to halt the wheels in a split second. The first successful samples of production ABS appeared in Daimler-Benz cars thanks to the talent of engineer Heinz Leiber, who prior to joining Daimler had worked for Teldix GmbH, where he developed the basics of the ABS.

The introduction of the first electronic digital blocks became a kind of a junction between the first and second generations. The real second generation of cars came with the implementation of a CAN bus (Controller Area Network bus). The CAN was developed by Robert Bosch GmbH in the mid-80s. The CAN bus’s ascendance was primarily due to car manufacturers’ desire to save on wires; the growing number of electronics multiplied the quantity of wires until the accumulated wiring was the third heaviest part of the vehicle.

The CAN bus allowed manufacturers to greatly reduce the number of wires by integrating all electronic components into a single data exchange channel. The first car with a CAN bus was introduced in 1986 — it was the BMW 850 Coupé. Its CAN bus reduced the wiring in the car by 2 kilometers and 50 kilograms.

More than 70% of the cars sold in 2006 used a CAN bus. In early 2008, the Society of Automotive Engineers (SAE) mandated that 100% of new cars sold in the United States use the CAN bus. The ultimate introduction of the universal data bus completed the transition to the Auto 2.0.

We are currently observing the transition to the third generation: network connected cars, or simply connected cars. A connected car is a car with Internet access and usually also a wireless local area network. The Web access enables various additional services for the driver and passengers as well as for the car manufacturer and third-party companies. Examples include automatic notifications about traffic, traffic jams, or other events; concierge services such as sending messages about ETA, parking reservations, and so forth; driving style classification that can affect the cost of car insurance; various services for owners of trucks and buses; telemetry data processing; troubleshooting prognosis; and much more.

Most major car manufacturers already have such technologies. Some include Volvo On Call, Chrysler UConnect, and General Motors OnStar. So what is the fundamental difference between Auto 2.0 and Auto 3.0? Technically, they’re the same. From the viewpoint of the car owner, however, the connection of one or more electronic units to the Internet provides pleasant and useful services — as well as Internet access while en route. (Never forget that posting to Twitter and Facebook while driving can be fatal.) But to a cybersecurity expert, the difference is huge: remote access to a car and its internal systems is bound to have major consequences.

And the consequences soon followed. About a year ago, at the Black Hat conference, researchers Charlie Miller and Chris Valasek reported a successful remote car hack. They took control over the air conditioning, radio, and windshield wipers first — nothing the driver did had any effect. They then seized control of the gas and brake pedals.

The vehicle had no special modifications at all; the hack took advantage of a vulnerability in the on-board Uconnect system, which is linked to the Internet via Sprint’s cellular network in Fiat Chrysler cars (Chrysler, Dodge, Fiat, Jeep, and Ram). All they needed to rewrite the code of the car’s control unit was the victim’s external IP address. Of course, Fiat Chrysler quickly responded and released a software patch for the Uconnect system, which can be installed by an authorized dealer or independently via a USB socket.

It was not the first incident with flaws found in modern cars’ default security mechanisms. Before that there had been a local control interception through an OBD-II diagnostic port and software updates substituted with the help of a fake cellular base station.

To build a reliable and proper security system, you first need to know what the threats are. I gave examples of successful attacks above, but they are just examples (though very important ones). Let us come to the issue of defining attack vectors with the help of a slightly more formal approach, and then, after understanding the threats we will discuss options for defending against them.

We must understand what a connected car is to properly define potential attack vectors. #carsecurity

Tweet

From our point of view, a modern connected car is not only — and not so much — a computer on wheels. It is a cyberphysical device, a digital or cybernetic unit, and also an array of cloud services (the driver often may be unaware that such services exist) and, certainly, mobile devices which also communicate not only with cloud services, but also with the car.

We must understand those elements of what a connected car is before we can properly define potential attack vectors.

And so we come to the threats. I would not like to tire readers with details of our threats studies (this is a topic for other articles), and I’d better move on to conclusions. We define five main categories of threat vectors: attacks on cloud services, various kinds of network access (means of delivery), the car’s router (to put it briefly, this device works as a network router, connects different electronic units, and contains routing tables of the CAN bus packets), the CAN bus, and electronic vehicle control units:

Of course, this list greatly depends on the particular configuration of a specific car, it may be shorter or include new threat vectors.

So, there are ways to hack and compromise a car — but why? Why would someone try to hack a car? There may be several reasons.

Of course, it could be money. Ransomware may well prove effective with cars. Just imagine finding one morning that you can’t start your car. The console screen states that to unlock your car you will have to transfer some bitcoins to somebody. What would you do?

Second, it could be espionage. Cars aren’t just for traveling; we also work and negotiate in them. Turning on the microphone or the camera inside the car can give access to exclusive information, and that’s without mentioning access to data. It is no secret that soon cars will store more personal information. Dr. Dieter Zetsche, chairman of the board of  directors of Daimler AG, recently said as much when speaking of the future of his company: “We are working on a new generation of vehicles that truly serve as digital companions. They … learn your habits … adapt to your choices … predict your moves … and interact with your social network.”

Third, we may see attacks with an intent to harm the driver, passengers, or other vehicles on the road.

I guess I’ve scared you enough already, and you’re not sure if you would ever buy a modern car. I’m not urging you to give up all of the benefits of consumer on-board electronics and network connectivity. I do, however, encourage automakers and parts manufacturers to take new risks into consideration while developing new cars.

In Kaspersky Lab, we aim to clearly understand possible threats and analyze these risks. Various security technologies, with their advantages and disadvantages, can be used to manage risks.

Kaspersky Lab’s approach to the internal security of modern cars is based on two architectural principles: isolation and controlled communications. Isolation ensures that independent entities (applications, drivers, virtual machines) can’t affect each other in any way. For example, infotainment applications should not affect the network in a car any more than in an aircraft.

Controlled communications would also have been very helpful to the abovementioned Jeep’s owner. Such control ensures that two independent entities that need to communicate in the system work in accordance with security policies. The use of cryptography and authentication for sending and receiving data is also an integral part of the protected system.

This approach of isolation and controlled communications is fundamental to KasperskyOS, a microkernel operating system with controlled interprocess communication. Each logical domain gets its own address space, and all communications between domains are always supervised by the security monitor.

The elements of on-board electronics that control critical car functions and are presumably vulnerable to attacks consist of a head unit (HU) and electronic control units (ECU). The latter form a network of controllers in a modern car — engine control, powertrain control, suspension control, and so forth. As a result, we can see a lot of potential applications for the Kaspersky OS within the connected car industry. By design, Auto 3.0 requires a change in the security architecture mindset.

A connected car is also a client of a huge array of cloud services such as maps and navigation, information on traffic and road conditions, driving quality monitoring, vehicle fleet management for businesses, and more. In the near future, cars will be in touch constantly, sharing megabytes of data and making decisions for drivers, greatly easing their lives. All of the advantages can turn into big problems, however, if we don’t pay enough attention to the cybersecurity of cloud infrastructure, authentication, data traffic encryption, key management and storage, and so on.

Over a hundred-odd years, the car has turned from a purely mechanical vehicle to a complex cyberphysical system of Internet-connected and interconnected devices that affect the safety of road users. And our task is to ensure that the cybersecurity of a car improves its physical safety.

What will be next? How about Auto 4.0? Perhaps it will incorporate autopilots and smart traffic control. I don’t want to to scare you, but with increasing digital advantages come more digital risks. But that’s a topic for another study and more articles.