Modern Car Technology

Modern automobiles are becoming increasingly computerized — with many components controlled partially or entirely by computers and networked both internally and externally. This architecture is the basis for significant advances in safety (e.g., anti-lock brakes), fuel efficiency, and convenience. However, increasing computerization also creates new risks that must be addressed. Our research mission is to help ensure that these future automotive systems can enjoy the benefits of a computerized architecture while providing strong assurances of safety, security, and privacy.

Center for Automotive Embedded Systems Security research consists of three complementary strands:

Experimental – experimentally evaluate real examples of today’s technologies to create informed understandings of potential computer security risks with future automobiles, as well as understandings of the challenges for overcoming those risks.

Developmental – develop new security technologies to overcome those challenges and mitigate the associated risks.

Why is it important to be aware the security and privacy properties of existing, modern automobiles?

The computer security community is largely unfamiliar with automotive computer systems, the functionality they offer, and the networks they use internally.

This was perhaps a reasonable situation when automotive systems were simple and had limited connectivity. However, the trends above — that modern automobiles are becoming increasingly computerized and networked — suggest that in the future, there may be increasing opportunities for unauthorized individuals (attackers) to access and tamper with a car’s internal computers.

I believe there is a potential analogy with desktop personal computers, whose security concerns were not as widely appreciated until pervasive broadband connectivity exposed those latent flaws to Internet-based attackers. Our hope is that we can sidestep this same painful learning process with automobiles and think about their security well before significant risks manifest.

To be clear, I believe that the risk of computer security incidents to automobiles is very low today. At the same time, we also believe that these risks are slated to increase in the future. Thus, we argue that now is the right time for the full range of stakeholders — including not only car manufacturers, parts suppliers and technology providers, but also government regulatory bodies, the insurance industry, computer security and privacy researchers, and public interest groups — to focus on these issues together and make sure that our automobiles remain secure in spite of their technological transformation.

In defining our threat model, we need to distinguish between technical capabilities and operational capabilities.

Technical capabilities describe as assumptions concerning what the adversary knows about its target vehicles as well as her ability to analyze these systems to develop malicious inputs for various I/O channels.

For example, we assume that the adversary has access to an instance of the automobile model being targeted and has the technical skill to reverse engineer the appropriate subsystems and protocols (or is able to purchase such information from a third-party).

Moreover, we assume that is able to obtain the appropriate hardware or medium to transmit messages whose encoding is appropriate for any given channel.

When encountering cryptographic controls, we also assume that the adversary is computationally bounded and cannot efficiently brute force large shared secrets, such as large symmetric encryption keys. In general, we assume that the attacker only has access to information that can be directly gleaned from examining the systems of a vehicle similar to the one being targeted.

We believe these assumptions are quite minimal and mimic the access afforded

By contrast, operational capabilities characterize the adversary’s requirements in delivering a malicious input to a particular access vector in the field. In considering the full range of I/O capabilities present in a modern vehicle, we identify the qualitative differences in the challenges required to access each channel.

These in turn can be roughly classified into three categories:

Indirect physical access,

short-range wireless access,

and long-range wireless access.

Automotive Embedded Systems

The digital control, in the form of self-contained embedded systems called Engine Control Units (ECUs), entered US production vehicles in the late 1970s, largely due to requirements of the California Clean Air Act (and subsequent federal legislation) and pressure from increasing gasoline prices. By dynamically measuring the oxygen present in exhaust fumes, the ECU could then adjust the fuel/oxygen mixture before combustion, thereby improving efficiency and reducing pollutants. Since then, such systems have been integrated into virtually every aspect of a car’s functioning and diagnostics, including the throttle, transmission, brakes, passenger climate and lighting controls, external lights, entertainment, and so on, causing the term ECU to be
generalized to Electronic Control Units. Thus, over the last few decades the amount of software in luxury sedans has grown from virtually nothing to tens of millions of lines of code, spread across 50–70 independent ECUs.

Many features require complex interactions across ECUs.For example, modern(ESC) systems monitor individual wheel speed, steering angle, throttle position, and various accelerometers. When brakes are applied they must also interact with the Antilock Braking System (ABS). More advanced versions also offer Roll Stability Control (RSC), which may also apply brakes, reduce the throttle, and modulate the steering angle to prevent the car from rolling over. Active Cruise Control (ACC) systems scan the road ahead and automatically increase or decrease the throttle (about some pre-programmed cruising speed) depending on the presence of slower vehicles in the path (e.g., the Audi Q7 will automatically apply brakes, completely stopping the vehicle if necessary, with no user input).

A combination of time-to-market pressures, wiring overhead, interaction complexity, and economy of scale pressures have driven manufacturers and suppliers to standardize on a few key digital buses, such as Controller Area Network (CAN) and FlexRay, and software technology platforms (cf. Autosar [1]) shared across component manufacturers and vendors.

Indeed, the distributed nature of the automotive manufacturing sector has effectively mandated such an approach—few manufacturers can afford the overhead of full soup-to-nuts designs anymore.

Thus, the typical car contains multiple buses (generally based on the CAN standard) covering different component groups (e.g., a high-speed bus may interconnect powertrain components that generate real-time telemetry while a separate low-speed bus might control binary actuators like lights and doors). While it seems that such buses could be physically isolated (e.g., safety critical systems on one, entertainment on the other), in practice they are “bridged” to support subtle interaction requirements.

For example, consider a car’s Central Locking Systems (CLS), which controls the power door locking mechanism. Clearly this system must monitor the physical door lock switches, wireless input from any remote key fob (for keyless entry), and remote telematics commands to open the doors. However, unintuitively, the CLS must also be interconnected with safety critical systems such as crash detection to ensure that car locks are disengaged after airbags are deployed to facilitate exit or rescue.

The Center for Automotive Embedded Systems Security (CAESS) – a collaborative research of University of California and University of Washington have conducted experiments to analyzed its threats:

Stationary car – CAESS conducted in-car experiments with the car stationary. For both safety and convenience, they elevated the car on jack stands for experiments that required the car to be “at speed”; shows the experimental setup inside the car.
For these experiments, they connected a laptop to the car’s standard On-Board Diagnostics II (OBD-II) port. They used an off-the-shelf CAN-to-USB interface (the CANCapture ECOM cable) to interact with the car’s high-speed CAN network, and an Atmel AT90CAN128 development board (the Olimex AVR-CAN) with custom firmware to interact with the car’s low-speed CAN network. The laptop ran our custom CARSHARK program.

Bench – They physically extracted hardware from the car for analysis in the lab. As with most automobile manufacturers, the test vehicles use a variant of the Controller Area Network (CAN) protocol for communicating among vehicle components (for the test, both a high-speed and low-speed variant as well as a variety of proprietary higher-layer network management services). Through this protocol, any component can be accessed and interrogated in isolation in the lab. shows an example setup, with the Electronic Brake Control Module (EBCM) hooked up to a power supply, a CAN-to-USB converter, and an oscilloscope.

On the road – To obtain full experimental fidelity, for some of our results the experimented at speed while on a closed course. The researcher exercised numerous precautions to protect the safety of both our car’s driver and any third parties. For example, they used the runway of a de-commissioned airport because the runway is long and straight, giving us additional time to respond should an emergency situation arise. For these experiments, one of them drove the car while three others drove a chase car on a parallel service road; and one person drove the chase car, one documented much of the process on video, and one wirelessly controlled the test car via an 802.11 ad hoc connection to a laptop in the test car that in turn accessed its CAN bus.

Although this is not the first to observe and experiments that computerized automotive systems may present new risks, the empirical approach has given us a unique perspective to reflect on the actual vulnerabilities of modern cars as they are built and deployed today. We have to reflect these findings and then
discuss the complex challenges in addressing them within
the existing automotive ecosystem.

Extent of Damage. Above, we have discuss potential risks to cyber-physical vehicles and thus we knew that adversaries might be able to do damage by attacking the components within cars. We did not, however, anticipate that we would be able to directly manipulate safety critical ECUs (indeed, all ECUs that was tested) or that would be allowed to create unsafe conditions of such magnitude.

Ease of Attack. We found existing automotive systems—at least those was tested—to be tremendously
fragile. Indeed, despite simple fuzzing infrastructure was very effective, a large fraction of the random packets we sent resulted in changes to the state of the car. Based on this experience, it was believe that a fuzzer itself is likely be a universal attack for disrupting arbitrary automobiles (similar to how the “crashme” program that fuzzed system calls was effective in crashing operating systems before the syscall interface was hardened).

Unenforced Access Controls. While that standard access controls are weak, surprisingly at the extent to which the controls that did exist were frequently unused. For example, the firmware on an ECU controls all of its critical functionality and thus the standard for our car’s CAN protocol variant describes methods for ECUs to protect against unauthorized firmware updates. We were therefore surprised that we could load firmware onto some key ECUs, like our telematics unit (a critical ECU) and our Remote Control Door Lock Receiver (RCDLR), without any such authentication. Similarly, the protocol standard also makes an earnest attempt to restrict access to Device Control diagnostic capabilities. We were therefore also surprised to find that critical ECUs in the car would respond to Device Control packets without authentication first.

Attack Amplification. It was found multiple opportunities for attackers to amplify their capabilities—either in reach or in stealth. For example, while the designated gateway node between the car’s low-speed and highspeed networks (the BCM) should not expose any interface that would let a low-speed node compromise the high-speed network, we found that we could maliciously bridge these networks through a compromised telematics unit. Thus, the compromise of any ECU becomes sufficient to manipulate safety-critical components such as the EBCM. As more and more components integrate into vehicles, it may become increasingly difficult to properly secure all bridging points.

Should car owners be concerned?

I believe that car owners today should not be overly concerned at this time. It requires significant sophistication to develop the capabilities attack tools and I’m unaware of any attackers who are even targeting automobiles at this time.

However, I do believe that current work should be read as a wake-up call.

While today’s car owners should not be alarmed, I believe that it is time to focus squarely on addressing potential automotive security issues to ensure that future cars — with ever more sophisticated computer control and broader wireless connectivity — will be able to offer commensurately strong security guarantees as well.

I’m pleased to say that, industry is now taking automotive security more seriously. For example, both the Society for Automotive Engineers (SAE) and United States Council for Automotive Research (USCAR) now have efforts focused on automotive computer security. There are positive discussions with multiple car manufacturers and various U.S. government agencies. All the parties we have talked with are taking computer security for automobiles very seriously.