Boston — Chances are, your car is newer than my "younger" car, which is 16 years old. Although my cars have some electronic hardware and software under the hood, they have far less than today's new vehicles. Thus, I don't have to worry about wireless software updates, bugs, or hackers causing "crashes." Today's vehicles rely heavily on electronic control units (ECUs) that need software updates. But as we've seen, wherever there's software, there's a hacker looking for weaknesses to exploit. Security is a big issue, which may be one reason that I hang onto my old car.
We've already seen software hacks in vehicles, as Junko Yoshida reported in Auto Security Demands All-Over Answer. Recognizing the problem, a group of researchers, students, and developers from New York University, the University of Michigan, and the Southwest Research Institute have developed a software architecture designed to combat intrusions during ECU firmware updates.
NYU Prof. Justin Cappos leads the Uptane design project.
Called Uptane, the architecture is intended as an open platform in which software developers, mathematicians, and cryptographers can participate in its development and testing. The Uptane working group revealed its design at a meeting with auto makers and their suppliers on January 17th in Ann Arbor, Mich. The following day, I spoke with project leader Justin Cappos, professor of computer science at NYU's Tandon School of Engineering, about how this technology will be tested.
In the video below, NYU PhD student Trishank Karthik Kuppusamy describes the problem and the Uptane architecture. Because the Uptane concept is open to the public, you can read the 27-page Design Overview. The details reside in the Uptane Implementation Specification.
Updating software involves a complex system of transferring software images and metadata stored in repositories and delivered to ECUs. During the process, updates must be verified for authenticity and proper delivery. The verification uses software keys that identify genuine images stored in a repository, and those key codes can expire. Security software needs to keep those keys out of hackers' hands.
15 of the most hackable and exposed attack surfaces on a connected car. (Source: Intel)
A key aspect of the Uptane design is the addition of a director role on the server side, as opposed to the client side. The Design Overview explains how the director identifies updates in its database and uses a vehicle's VIN to verifiy the vehicle to receive the update because each ECU has a unique serial number. Once all are verified, download and installation instructions are invoked and updates can begin. Of course, there's a lot more information needed for security, such as timestamps. The documents linked here explain those details.
"There are three issues," said Cappos in our telephone interview:
How do you know if the design is good?
How do you know if the implementation of the design meets the goals of the design?
How do you know that the way it's used in practice still has the desired properties?
As with any design, Uptane needs testing and verification. With security products, you don't know how well security software does its job unless it fails. Because Uptane is an open design, its creators have invited the software community to try to crack it and provide feedback.
"We apply best practices used in computer science to test security code," said Cappos. "We will write our test procedures so that anyone can implement them with test code written in any language."
Why invite others to try to hack a system? "It's possible that we missed something," said Cappos. Software companies regularly invite others to evaluate and comment on designs. That's why software developers release alpha and beta versions; they want public comment. "The software you use today has been evaluated by programmers, mathematicians, and cryptographers," explained Cappos. "We want smart people to try to break the code. Evaluations by hundreds, and perhaps thousands, of experts can find many flaws." Cappos noted that he's already received emails from people reviewing the Uptane design. At this point, the feedback is bringing in questions rather than pinpointing errors. That will surely come, but it will take time, and those findings should result in a more secure design prior to implementation.
Could a reviewer find a flaw, recommend a change, and then exploit it? Cappo responded by saying that the review community is asked to publicly comment on design changes, which lets others review suggested changes.
If the Uptame concept proves successful, it could find its way into applications beyond cars. Hopefully, software developers will be able to take advantage of it, especially in IoT and Industrial IoT, which I really fear could open many doors to hackers if not implemented properly.