The highly technical automotive realm of today, which reflects a significant and growing focus on automotive cybersecurity, has its roots in the worlds of the tinkerer, inventor, and shade tree mechanic. Traditionally, once a person purchased their vehicle, they could choose to modify or repair it themselves or hire someone to do it. And many of the parts themselves could be repaired multiple times before they had to be replaced. The technology was basic enough and advanced slow enough that, once learned, a person’s automotive repair skills could remain valid for many years, even decades.
But as vehicle technology has evolved, these systems have become increasingly complex, and this complexity has come at an ever-increasing pace. Today, certification programs teach this increasingly-complex vocation and help provide assurances to the owner that the technician has the technical competence required to repair today’s complex systems. But even after achieving their initial certification, this knowledge must be maintained. Skills now atrophy quicker, necessitating almost continuous learning. Fewer parts have become truly repairable, and many parts have become items that now can only be traded in and repaired safely by a competent remanufacturer, or they are one-use items designed only to be removed and replaced. This is due to many factors, including economy of scale, potential liability, tighter tolerances, material improvements, and the increasing role of software in modern systems. Software and communications systems are particularly vulnerable. It is not just a hardware-oriented world anymore.
Back in the day, if an owner wanted to experiment with increasing performance, they would reach for wrenches and screwdrivers. But today, many of those adjustments are now made in software. So, who can modify that software? And what might happen if they adjust one element, that has unforeseen consequences for other systems? Does the owner of the car actually own the systems within it?
Due to the potential for great harm by a bad actor who might gain access, it is not good for anybody to possess super root control, even the OEMs. That said, typically the OEMs have the most access, which is a logical correlation given that they might have the most potential accountability and liability exposure. And of course, dealerships have the secondary level of access to perform complex repairs and updating tasks that require specialized tools and strict adherence to procedures. But constraints must be placed even on what a dealership can do. It is not good for a dealership to have too much access, due to many factors including the temptation for unauthorized modifications and the potential for blurring the lines of accountability.
And then there's the poor user. If they are given broad access, then there is also a significant risk of giving the attackers access. What if their computer is infected with malware that installs itself in an ECM and gives a bad actor override control with no warning? The automotive industry can’t police all the devices of every car owner. How do we as an industry handle the issue of the right to repair, and manage this whole civil conversation?
For example, what if the ECU in my car dies? How come I, as the owner, can't just go replace it as I can today with wiper blades and batteries? I now must possess a specialized tool to perform ECU work. Even if I as the owner am willing to invest in these tools and I check a box that says I take responsibility for the ramifications of doing it myself, the impact of an autonomous vehicle reaches far beyond the physical boundaries of that individual car itself, potentially extending to every other entity in the ecosystem.
OEMs have strict protocols and standards and regulations that they must adhere to before the car can even be sold. Allowing an owner to have the same access would effectively undermine and bypass these safeguards. Does the typical owner really understand the risks they are taking on? Is that the right thing to do for the owner? Is that the right thing to do for the ecosystem? How would risks be handled and litigated in a complex blended access scenario?
If I as an autonomous fleet owner allow you to fix your own vehicle, that's great for you. But that puts my entire fleet at risk, and I don't want that to happen. So, if one traces the full risk management or risk assessment process, they will see that certain things can’t be allowed to happen, simply because an individual who says they are assuming the risk, realistically can’t do so. If an individual owner checks that box assuming full responsibility, and they modify the code in a way that accidentally causes all autonomous vehicles to crash into obstacles, that fleet owner could be out many millions of dollars that the individual has no hope of reimbursing them for, not to mention the incalculable ramifications to innocent persons. We as an industry must put these security mitigations in place.
The industry relies on guidance from formally vetted standards and regulations, to help make sure that unqualified or under-qualified persons are not provided too much access. It's just the kind of world we live in, having more limited access to be able to fix things, and it is likely to be the way it is going to trend in the future.
One of the most difficult challenges about automotive cybersecurity that must be solved is to figure out the replacement of ECUs and other key components. Due to the growing variety of ECUs authenticating themselves, the authentication burden is likewise growing, and it is going to get much more complicated.
The industry has relatively simple authentication now. Essentially, ECUs now communicate authentication that is the technical equivalent of something like this: "I broadcast this VIN number on the canvas. I'm a good login controller, you’ve got to believe me." And that's it. The ECU is considered authentic by the rest of the system, just because it says it is. That isn’t very robust.
However, OEMs are taking a closer look at authentication. For example, some recent sports car models have received more attention about how a lot of their authentications are performed. For example, the owner might try to upgrade their car by putting a radar module on it, adding features that it didn't originally come with, or that they don't want the OEM to know about. Supposedly, users could not just add features to their cars that they didn't originally come with. But all the owners had to do is download some open source software, insert the VIN number, and now they had blind spot detection in the car, which it didn't have before. These are the kind of workarounds that the OEMs are going to have to actively block. This is a goal for them because they're losing out on income if instead, they can build the car with those features and mark up the price accordingly.
True, given the entire population of owners, there is but a small subset of people who like hacking on their cars and adding features. But these people still need to be addressed. In the future, the controller is going to have an authentication mechanism that can't be reproduced. That is going to be something like a certificate signed by the organization. An owner can't do that. There's no way for an owner to replicate that mechanism. If the owner replaces that controller, they won’t easily be able to drop that in their car and hack the VIN number. They will have to go to the dealership, which holds those certificates. The dealership will have to possess an API mechanism that is able to procure a new certificate, and then the dealership will have to add it to the vehicle. This is the level of complexity that they are dealing with. Once installed, the vehicle domain controller will recognize that controller with the new certificate, it now can activate the radar sensor capabilities.
The industry must develop this capability. Right now, everybody's kind of struggling with the authentication mechanism. They must learn how to perform these tasks in the most secure way.
Once the input sources are validated, an ECM will consider incoming data trustworthy and react to it without questioning it, until it is given a reason to validate the source again. Theoretically, if the ECM itself proves too tough a nut to crack, a bad guy might try to hack the vehicle through other means, some of them unorthodox.
One path might be to try to fool the vehicle by creating a virtual ECM that is substituted for the physical ECM hardware bolted into the car, not unlike the same general concept of creating a virtual machine on a traditional computer. Virtual machines are not tangible machines that you can lay your hands on, rather, they only exist in software. You can create multiple different virtual machines on a single desktop, each one running a different operating system, and each one isolated so that it has no idea the others exist. The applications running inside those virtual machines have no idea they are running on a virtual operating system; they think that they are running directly on one OS installed on tangible hardware.
Virtual machines are quite common and well understood. They are useful for testing things in isolation. If something goes wrong, just delete it and start over. But what if a creative hacker were to apply that same concept to an ECM? They would probably have to start at the domain controller if they were going to try to do that, and it would be incredibly complicated.
The domain controllers and other APIs, run virtual machines, which are containerized products. They can certainly handle virtual machines or full-blown Linux systems, just like your desktop can. A bad guy could try to spin up a domain controller added into the system to create their own ecosystem, but that would be pretty advanced. I haven't heard of anybody trying to spin up their own virtual ECM.
One of the OEMs I worked with had virtual controllers for communication while internal testing. It wasn't like a full-blown controller, you could test communications, and you could test other things with it. I guess you could consider it a virtual controller in some regards. But I'm not sure if I can think of any case or instance, where people are presently going to that much detail to try to drop a virtual controller into the vehicle to gain other access. But that doesn’t mean someone won’t try it someday. That’s the kind of creativity we constantly must guard against.
Another vector might come from inputs further upstream, essentially lying to the ECM to manipulate what it thinks it is doing in good faith. Instead of trying to create a virtual controller, you could essentially lie to the legitimate controller by slipping in something upstream that lies to it, using something like unencrypted Canvas products. If you look at the current landscape of the automotive world, there are several vehicles today that will enable you to easily spoof a product. That's what we're talking about approximately. However, when we move to the next generation of vehicles, device authentication is going to help prevent that.
Consider a next-generation domain controller. Before it talks to any other part of the system or accepts anything that it is being told, those sources must authenticate themselves to the controller. The only way to do that is through a certificate that the organization has signed. These different certificates can communicate back and forth and perform a mutual authentication. Once the elements feel like they know each other, they both indicate this to each other. Only then do they begin to accept communications back and forth.
If a bad guy drops in a spoofing device, and they try to connect back to the organization or connect back to the domain controller, pretending to be a new radar sensor or some other system, it must provide proper credentials back to the domain controller. Meanwhile, the domain controller typically has access to a list of authorized items and capabilities installed in the vehicle, because the physical vehicle is very static. If the controller comes back with a certificate that reflects items and capabilities other than what was factory installed in the vehicle, or it doesn't come back with a valid certificate, then the other components will not talk to it. That port gets shut down, and absolutely nothing else is allowed to happen.
So, that is the future state of automotive cybersecurity and automotive communications. This makes piecemeal component upgrades and replacement very difficult, because the information in the controller is very sensitive, and it must be moved from the old controller to the new one. Or if that's too much of a security risk, the new controller is installed with the sensitive information already uploaded to it before it is bolted into the car. And once installed, we don't touch it, we leave it, and we must tell the other controller or the domain controller, that this is now part of the ecosystem.
The industry is struggling with how to do all of that securely. There's probably a good solution here, but at some point, someone somewhere is going to have to be given the means of performing that work, and that will be the point of greatest security risk. Different manufacturers are probably going to implement different solutions. It will depend on what kind of ecosystem the OEM has, how that tool can get to the cloud and gain access, and if it must pull certificates and other considerations.
Automotive cybersecurity presents a host of real problems, and this issue is one that everybody in the industry has struggled with. This is the kind of conversation that we had about some OEMs having their controllers use these authentication mechanisms. You can't just replace them and go, it's something that the tool must go in and update. But this is the kind of world we live in.
We must figure out the best way for dealerships and for people to try to handle these right-to-repair conversations. Right now, many people are just saying that the owner will simply have to go to the dealership. If you are the owner and you want a replacement part, this is what you will have to do for security to be maintained. So, that could be the reality of the automotive business in the future.
Felice Ferri: Apr 30, 2024 4:02:22 PM
The Power of Real-Time Alerting Real-time alerting can be thought of as both a concept and a loose set of rules within the discipline of analytics....
Kelly Stephenson
