Connectivity is used to increase traffic safety and to provide motorists with infotainment content, but connectivity also creates vulnerability. Increasingly connected vehicles are becoming targets for hackers that can access the vehicle’s electronic control units (ECUs), controller area network (CAN) bus systems, or even sensors through the cloud or other IT pathways. This is causing very real concerns about cyber security in modern vehicles, and how to protect driver safety and privacy. Irdeto is a security solutions provider for digital platforms and applications across multiple industries, including automotive. Since its inception in 1969, Irdeto’s software security technology has protected over 5 billion connected devices and applications. We spoke with Ben Gardiner, Principal Security Engineer at Irdeto and discussed the latest trends in automotive cyber security, and specifically focused our conversation on automotive sensors.
MEMS Journal: What would the motivation be for someone to hack sensors in a vehicle?
Ben Gardiner: There has been much written about attackers seeking to inflict personal injury or damage personal property. However, our experience in other industries leads us to believe that the threats that can’t be ignored are those posed by financially motivated attackers.
Since sensor MCUs could be intermediary goals for attackers seeking to compromise a vehicle, the motivations for hacking sensors are the same as the motivations for hacking the vehicle itself. One potential motivation is to ransom your car from you, the owner, using malware commonly called ransomware. This form of malware encrypts the data on a system, denying use of the system unless a ransom is paid – it has been a huge industry for hackers this past year where the FBI estimated the revenue generated at $209 million in the first three months of 2016. You could also imagine an attacker installing ransomware on a fleet of warrantied vehicles and holding them ransom to the OEM. Under the same umbrella of motivations for hacking the vehicle, attackers could seek to steal goods on a commercial vehicle or they could be seeking to defeat automated toll systems (or sell such solutions to consumers).
In terms of potential motivations for hacking the sensors themselves -- attackers might be seeking to create solutions they can sell to fool other car’s sensors. One theoretical example would be to design bumper stickers that could fool other vehicles’ sensors and make them believe that a standard car is a pedestrian or an ambulance.
MEMS Journal: What could potentially an outside threat do with access to unsecured vehicle sensors?
Ben Gardiner: With access to unsecured vehicle sensors, many of the above threats mentioned could be realized. We believe this is a risk due to the trust relationships on the vehicle buses. Compromising the firmware of a sensor’s MCU could lead to compromising other vehicle systems.
Vehicles are exposed to many physical access threats over the course of their service lifetimes, e.g. at service stations. Sometimes the “attacker” is also the owner of the car, seeking to understand the operation of a subsystem to defeat it or to create a solution to sell to others. This physical access will yield access to the vehicle buses and could lead to compromise of sensor FW. This would be a step towards the attacker achieving their goals.
MEMS Journal: Which sensors are the most critical to protect in a vehicle?
Ben Gardiner: I’m not an expert of vehicle safety, so speaking strictly from the perspective of cybersecurity, the most critical sensors to protect are those that are accessed by the software with the highest privilege and those sensors whose output is the most trusted by the software (without defensive programming against corrupted or malicious data). This is, of course, a function of the system into which the sensors are integrated, and not under the control of the individual sensors. Vehicle developers should err on the side of caution and assume that their sensors will be used by the highest privilege software and have their vehicle network frames trusted implicitly. Mitigations should be included in their designs to be conservative and make them robust.
MEMS Journal: What are the main challenges in automotive security solutions adoption by customers? Is it an uphill battle to convince customers (i.e. Tier 1 and OEMs) about the value?
Ben Gardiner: All the OEMs and Tiers that we’ve had the good fortune of interacting with are taking cybersecurity seriously and are investing in developing solutions. I think there is an uphill battle for the OEMs in passenger cars as opposed to the commercial vehicle space. In the former, the purchasers (consumers) are largely ambivalent to the cybersecurity threats. Pundits have been talking about “cyber fatigue” and I think they’re right. Compare this to the commercial vehicle space where the purchasers (fleet operators) do care about cybersecurity risks, and the threats to their assets and revenue are much clearer. There, the largest group of operators (National Motor Freight Traffic Association or NMFTA) are dedicating their considerable resources to specifying what is needed and ensuring that it can be delivered to them.
MEMS Journal: The traditional CAN bus, which is widely used to connect sensors and other modules in vehicles, has limited security. What new standards are being used in modern vehicles to remedy this?
Ben Gardiner: Yeah, that is true. I have heard many people talk about “securing the CAN bus” and “securing J1939”. There have been some really well-considered designs and I’ve heard that the SAE committee responsible for J1939 is looking for proposals to secure it as well.
What modern vehicles are doing right now to remedy the security problem is segregating the bus -- they are installing a gateway, or firewall device between the vehicle network and the diagnostics port. Gateways at other points where less-privileged software is running are also being included, e.g. the head unit. Some cars already have them deployed— as a colleague of mine discovered earlier this year.
These gateway devices forward traffic based on whitelists. But also, these gateways appear to have “bypass modes” for diagnostics at the garage and forensics at the crash site. Obviously this mode will be attractive to attackers seeking privileged access to the CAN buses. Ultimately the security of the CAN bus in these modern vehicles comes down to the firmware security of these gateways.
For 2017, we plan on securing a number of OEM and Tier 1 solutions. These companies are interested in our solution, which we consider to be a positive trend for the industry as it shows that deep-level cybersecurity is a priority.
MEMS Journal: Vehicles are not “islands” anymore and are increasingly becoming connected. Can you talk about the security risks especially regarding sensors in the vehicle?
Ben Gardiner: You’re right, vehicles are becoming increasingly connected – both externally and internally. Cybersecurity threats to automotive as a result of increased connectivity have been discussed extensively by the industry this year. There are trust relationships assumed in the design of components on the vehicles’ buses. Adding connectivity to these systems has (already several times) enabled attackers to exploit these trust relationships.
The vehicle is a network of engine control units (ECUs) and these units are increasingly becoming more powerful. We think of sensors as having a front-end, pre-processing, digitization and post-processing. From our perspective, the vehicle’s sensors are becoming nodes on these networks. They are ‘tiny’ computers themselves -- sending packets to consuming software on other ECUs and receiving their own packets that networking rules dictate they must respond to.
A unique threat to sensors is in malicious injection of signals -- either at the response level (taking advantage of the sensitivity) or at the analog front end. There is an interesting example where successful attacks were conducted on the analog part of sensors by a set of researchers in the field, including Dr. Yongdae Kim’s SysSec group, Jonathan Petit et al. and Yasser Shoukry of UC Berkeley. There are already mitigations designed into sensor systems to reject noise or other “exogenous input” as Shoukry puts it. However, these planned attacks highlight how vulnerable sensors can be in a system. Another security risk pertinent to sensors is reverse engineering of the signal processing firmware where sensor data can be manipulated.
MEMS Journal: What is your long term vision for sensor security in vehicles? Where is this market now and where will it be in 5 years?
Ben Gardiner: Today there are many sensors connected to the vehicle networks that will execute unsigned code. The only mitigation to security threats is re-flashing procedures or authentication with short, brute-force keys. Many units also have mitigations based on vehicle speed or network segregation techniques. This is good, but not having integrity checks of code is not good.
In five years’ time the MCUs for automotive sensors will be employing code signature enforcement during boot (and re-flash), and will be performing some runtime integrity checks of the executing code as well. With code integrity verification at boot and runtime in place, there will be a good foundation for detecting signal injections or other “analog” attacks. In addition, the machine code will be hardened against reverse engineering by attackers.
MEMS Journal: What are the most interesting trends related to automotive sensors and security vulnerabilities?
Ben Gardiner: The trend towards unification of ECUs in the vehicle combined with the proliferation of sensors on a handful of buses, is interesting from the perspective of cybersecurity. There will be multiple privilege levels of software executing within ECUs. The technologies that make it possible to run the multiple privilege levels often come with protections against compromising each other, i.e. sandboxing. Let’s assume that the sandboxing will make it unlikely for attackers to escalate privilege from one software component to the next within the unified ECU. Then any sensors that are used by higher privilege software components, but that are on the same bus used by a lower privilege software component, become targets for compromise. In other words, attackers will seek to compromise the runtime operation of these sensors’ MCUs to, in turn, compromise the runtime of the higher privilege software on the unified ECU.
A second interesting trend from the perspective of security is sensor fusion and its combination with neural networks. Classification routines are relying heavily on neural networks and will continue to do so in the future. However, we know that neural networks (the ones today anyways) have a weakness in that they can be inverted to solve for inputs that will achieve a desired output. Two related examples include “Machine Duping” by Clarence Chio and the recent facial recognition fooling glasses from researchers at Carnegie Mellon University.
MEMS Journal: At what levels should security be implemented – at the sensor, data transfer, or application level? Is there an argument to encrypt raw sensor data?
Ben Gardiner: I think best practices in security design calls for a layered approach – the NHTSA has recently stated as much in their “Cybersecurity Best Practices for Modern Vehicles”. So, protect the data transfer, protect the sensor firmware, and protect the consumer of the sensor data. Protect from what – and how – are the real questions.
Would encryption help protect data transfers? Encryption, by itself, is a protection against compromise of confidentiality. Now, the driving habits of an individual is their personal private information and so there are legal reasons why such data must be kept confidential in some areas of the world. However, whether or not that data in transit in the vehicle network must be protected as such isn’t clear to me. I’m not a lawyer.
Anything else? There are probably command and control traffic to ECUs and sensors, which includes firmware upgrade and other sensitive operations. These should be kept confidential from eavesdropping on the bus. Should it all be encrypted -- everything on the bus? Probably not.
What needs to be protected is tampering of critical data transfers or forgery of critical data transfers. Encryption, by itself, won’t do this. But digital signatures will. With signatures on the critical data transfers, the consuming software application could trust and verify that the data it is receiving is valid.
I mentioned before that you need to either assume that other software will trust the output implicitly or include mitigations into the design. If the sensor firmware signed messages and were implemented in a way that entangled firmware integrity with the signing key, then any attacks on the firmware would break signing – pushing attackers to breaking crypto, which is hard.
*********************************************
This article is a part of MEMS Journal's ongoing market research project in the area of cyber security and automotive sensors. If you would like to receive our comprehensive market research report on this topic, please contact Dr. Mike Pinelis at [email protected] for more information about rates and report contents.
Copyright 2017 MEMS Journal, Inc.
Comments