Secure Connections Between Smartphones and In-Vehicle Systems

This blog describes a high-level approach to securing and authenticating the connection link between in-vehicle systems and smartphone applications. A secure link is needed in cases such as vehicle data collection, receiving firmware updates (using store and forward model), enabling premium features and other scenarios.

Some smartphone connectivity methods (such as WiFi) provide a certain level of encryption natively, but recent hacks have revealed significant vulnerabilities. Even with strong encryption, WiFi does not provide the infrastructure for the in-vehicle system to authenticate and “trust” the application it is communicating with. While encryption at the transport level provides some authentication between the in-vehicle system and a given smartphone, it does not authenticate the specific application running on the phone.

Smartphones have become ubiquitous and powerful devices that can enhance the user experience in the car by providing connectivity, up-to-date software, a powerful computing platform and popular applications. For all their advantages, though, smartphones do create additional security vulnerabilities.

Encryption is the typical method used to secure the connection between smartphone applications and devices, requiring keys or certificates to be stored on the phone.  Applications that need keys and certificates can use various techniques to try to protect these secrets.  However, as we see below, there are drawbacks to the various protection techniques.

Applications can be modified, reverse engineered and debugged. If a certificate or key is stored in the application, an attacker can extract it from the application code via reverse engineering or at runtime by debugging.  Obfuscation and other tools can make the attacker’s job harder at the end of the day, but not impossible.

Application developers may turn to the smartphone operating system to provide protection of keys and certifications.  However, if the phone is rooted / jailbroken, all the security mechanisms that come with the operating system can be bypassed.

Mobile operating systems provide infrastructure to store keys and certificates outside the application, referred to as keystores. However, such information can be extracted relatively easily on a jailbroken phone. For an example in iOS see: http://highaltitudehacks.com/2013/08/20/ios-application-security-part-12-dumping-keychain-data/

Some phones provide hardware-backed keystores, e.g. https://source.android.com/security/keystore/. Even if the keys are protected, they still need to be added to the phone somehow. On a rooted device, malware can inject its own intermediary layer and intercept the keys. It is not practical for keys to be stored by the phone manufacturer (unless it is a system app), and user installed applications where keys are downloaded from the cloud risk interception during delivery.

While WiFi provides some level of encryption, a recently-discovered vulnerability (https://www.krackattacks.com/) shows that all WiFi encryption levels can be breached. Even when this specific vulnerability is patched, WiFi encryption by itself is not enough to guarantee security. Even if WiFi provides an encrypted connection between the phone and the in-vehicle system, it does not authenticate the application. Any application on the phone can communicate with the in-vehicle system over the established WiFi connection, therefore necessitating an additional authentication mechanism.

From the point of view of the in-vehicle system, it is impossible to tell independently what remote application the system is talking to on the phone. The connection identification information received through the link is not reliable. IP or Mac addresses can be easily spoofed, and even if a secure connection is established with the phone (over WiFi, USB or Bluetooth) any application can communicate with the in-vehicle system and “pretend” that it is the “official” application. If the vehicle needs to send or download sensitive data, it cannot rely solely on generic system infrastructure for security and authentication.

As described in this blog, there must be an additional authentication and security mechanism between the in-vehicle system and the authentic smartphone application. 

There are no guarantees that any smartphone application cannot be compromised. Therefore, the next best thing is to limit any attack to only one phone or system. In other words, if a key is compromised from one phone, it should not make it possible to access other (non-compromised) in-vehicle systems and phones. The opposite should also hold true; if a vehicle system key is compromised, it cannot be used to connect to other (non-compromised) phones.

To avoid mass hacking, the in-vehicle systems need to have individual private keys stored in a secure location, preferably in Hardware Security Module (HSM), if available. The in-vehicle system and smartphone application can establish secure Transport Layer Security (TLS) connection using certificates on the phone side that are generated for that specific connection. The phone side certificate is signed by a trusted Certificate Authority (CA) and contains a connection specific token that is provided by the in-vehicle system.

During the TLS handshake sequence, the in-vehicle system verifies the certificate sent by the phone application. It checks if the certificate is for the specific connection (phone <-> in-vehicle system) and is signed by a trusted authority. If those conditions are satisfied the connection is allowed, otherwise it is rejected.

This way, even if an individual phone is compromised, its certificate cannot be used to connect to other in-vehicle systems. 

A more detailed description of the approach to secure and authenticate the connection between a smartphone application and in-vehicle systems can be found in Abalta’s white paper.