Cars were originally designed to be isolated systems mechanically operating autonomously in a segregated network environment. Naturally, previous development and testing efforts were focused on ensuring the integrity and reliability of safety-critical systems such as brakes and air bag deployment systems. There was little (if any) reason to consider the security posture of a vehicle in terms of malicious actors attempting to access, traverse, or compromise a vehicle’s network or sub-components.
With the advent of car-hacking threats that can put drivers and passengers in physically threatening situations, the definition of security in relation to cars has evolved. The more “connected” something becomes, the larger its attack surface also becomes. So as new models include more connected components, automotive manufacturers must be proactive when it comes to preventative software security measures.
It is worth noting that the problem is not so much the addition of technology as it is the implementation of such new technology into an older ecosystem. For instance, in 2016, the Tesla Model S was compromised using a smartphone app. Simple modifications made to the app allowed penetration testers to open the car doors, enable keyless driving, and even drive away with the vehicle—all remotely. Then there is the Jeep Uconnect compromise, in which researchers used the vehicle’s Wi-Fi hotspot system to take complete control of the car—also remotely.
These examples highlight the consequences of bringing cars into the realm of the Internet of Things (IoT), where vehicles are no longer isolated systems, yet have not been updated to match more modern automotive and computer engineering expectations in terms of cyber security.
This brings us to the new specification written by the Connected Car Consortium (CCC): the Digital Key Release 1.0 specification, which presents a method for users to transfer digital keys to their smart devices. While security is not the primary focus of the specification, it does note that the mechanism carmakers use should prevent unauthorized copying, modification, and deletion of existing keys. It also indicates that carmakers should actively prevent unauthorized provisioning and factor attack considerations into the implementation of a digital key transfer mechanism. But how?
From a software security standpoint, the specification does not function as a cohesive document. While it does suggest how developers should address functionality and associated security topics, it does not firmly address potential security issues or provide remediation advice in any valuable depth.
You see, for a vehicle to be secure, each component must be secured independently to strengthen or prevent weak links in connected applications that may allow for chained exploits, or pivot points for mounting further attacks if exposed. Such security considerations encompass the hardware and software of the car, in addition to the connected components and their subcomponents that involve networks and the cloud, including coverage of common threat vectors such as key-disposal management.
The Digital Key Release 1.0 specification should additionally carefully consider how various mechanisms could be used in a way they weren’t originally intended—for instance, sending messages in an unexpected order or with unexpected (albeit valid) parameters. These simple alterations can be very effective in compromising a system.
It is not enough to consider whether the smartphone in use has been rooted or who has access to it. Carmakers must also ensure that the communications remain “complete and valid” while being as minimalistic as possible. The specification should advise that the communications protocols in use contain no details about the vehicle other than the minimum required and that a mechanism be in place to ensure trusted messages and commands.
The design outlined by the CCC mandates that an owner be able to create virtual keys for those who would like to access the vehicle. It also discusses how to create keys with limited access rights for purposes such as speed governance or valet parking. The concern from a security point of view is that an attacker could copy the same permissions that the owner (or a master user) has. A digital key is pretty much the same as a real nickel silver key—if a key is stolen or copied without the owner’s knowledge, then the thief has the same level of access as the owner. However, digital access is infinitely easier to copy than a metal key. This is because the “digital” element generally removes the requirement to have physical access.
Thus the problem becomes how to strengthen the security considerations in the standard is to address how the car stores authentication keys and, more importantly, how they should be removed. If an extra unused key is stored on the car, it could be as dangerous as, and easier to exploit than, one generated by an attacker. Using passcodes and biometric readers is not enough to strengthen these weaknesses as passcodes work only when the associated passcode generation and storage mechanism is secure. Security considerations in this regard include the strength of the passcode, encryption of data at rest, and the management of key storage.
Biometric readers, while adding an extra degree of difficulty to forgery, address only physical usage and historically have been easy to hack or bypass. Biometric systems still rely on a background subroutine that handles the authentication/verification, which is just as vulnerable as relying on passcode authentication. Therefore, biometrics adds only another layer of abstraction rather than another layer of security.
Even fingerprint readers and iris scanners have been easily subverted in the past. A relevant example is the Samsung iris-scanning compromise, in which a printed copy of a simple infrared photograph of the true owner, taken 20 meters away, fooled the scanner into successfully authenticating an attacker.
Clearly, it is not enough to rely on technologies such as these to address the gaps in the Digital Key Release specification, as these technologies are prone to the same weaknesses as connected cars are. Security should be approached from all angles. Carmakers must proactively secure each system, each subcomponent, and each technology as cohesively as they approach automotive vehicle functions each day. As a general rule of thumb, the more layers of difficulty which exist in the different sectors of technology (e.g., cloud and hardware), the smaller the open attack surface of the car becomes. Including security in automotive specifications such as the Digital Key Release specification further supports such protection.
Samantha Isabelle Beaumont, Security Consultant at Synopsys
Larry Trowell, Principal Security Consultant at Synopsys
Image Credit: Fancycrave1 / Pixabay