App and API Level Security for Connected Car Platforms

In 2009, the app economy officially kicked off with the Apple trademarked refrain “There’s an app for that.” A decade later, the mobile app is the center of gravity of the digital economy, transforming how we shop, bank, read, commute, socialize, work, travel, manage our health, and much more. Today, it seems, if there’s no app for that, then it’s probably not a fully digital experience.

Much of the functionality and sophistication required of these modern mobile apps is delivered via APIs. Even ostensibly simple activities such as posting on social media or streaming video would not be possible without mobile APIs. And as modern mobile apps grow in both functionality and sophistication, the complexity, and the value, of the API ecosystem underlying these applications increases exponentially.

Take connected cars, a growing market with revenue projections of $480 billion by 2024. Automotive connectivity is no longer just a nice-to-have feature with one estimate putting the number of connected vehicles on the road by 2020 at 250 million.

Mobile Apps, APIs, and Connected Cars

Cars today are becoming more like software platforms than hardware platforms, able to be modified, controlled and monitored digitally. It’s a great benefit to owners. But if they can be modified, controlled and monitored by their rightful owners, then they are also vulnerable to bad actors who would take advantage of this new capability. Auto makers have been trying to make it harder for hackers to attack the vehicles themselves, or the cloud servers where information is stored and analyzed, but there is another weakness that is quite vulnerable – the mobile phones that connect to the vehicles and act like tools to control them.

APIs fuel the connected car opportunity. They provide the critical point of connectivity needed to bring together data and services from a broad and diverse range of systems across OEMs, aftersales, infrastructure, insurance, regulatory, and technology partners. That is already a degree of complexity that will only get more acute as connected cars evolve into V2X (vehicle-to-everything) connectivity involving communicating with other vehicles, pedestrians, infrastructure, grid, etc.

So, APIs provide a simple and efficient interface to expand the functionality and enhance the connected car experience. They allow mobile apps to connect to vehicles and to cloud servers and are intended to enable easy communication, but they can be tricked and when such an attack on a car or the servers is under way, everything may well look totally fine from a traditional security standpoint. Further, API abuse attacks such as this scenario are expected to be the most-frequent attack vector over the next few years. And connected cars operate at the intersection of mobile, IoT, and cloud, all of which rely on APIs for their utility and functionality.

The Security Challenge

As cars evolve into software platforms, the attacks on connected cars have already increased sevenfold over the past decade. Every possible ecosystem node, including OEMs, consumers, commercial vehicles, car-sharing services, and governments, has been attacked. Every vector has been probed for vulnerabilities and mobile apps, it turns out, are a top three favorite among bad actors, alongside keyless systems and servers.

This creates a huge challenge that the connected care industry as a whole has to address as the private ownership of connected cars expands. It is of especial and more immediate concern for at-scale use cases, such as car sharing, connected car rentals, fleet management, etc., where multiple users, apps, and devices will have access to the vehicle. Last year, for instance, the mobile app of a popular short-term car rental service appears to have been central to a fraudulent scheme that resulted in the disappearance of over 100 luxury vehicles, some of which were then used to commit crimes.

But when it comes to mobile apps and APIs in the connected car ecosystem, not all incursions have to be as high octane or hostile as that to pose potentially detrimental or destructive consequences.

Scenario 1: Securing Mobile APIs

Take the case of SIXT, Germany’s first car rental company with a 100-year legacy and significant investments in the car sharing model.

Since car sharing is a mobile-first application, SIXT relied extensively on APIs to deliver dynamic and up-to-date data, such as vehicle availability, characteristics, and location, to their mobile app. These APIs also allowed aggregators to run promotions that increase traffic and bookings. However, the company soon realized that data access was so simple and straightforward for external players that access to more sensitive information and even vehicle functionality was just a few advanced commands away. SIXT, to be clear, did not want to stop sharing data but the company definitely required a security-first approach to authenticate API requests, secure customer data, and prevent unauthorized access to their vehicles.

To achieve those objectives, SIXT started by deploying a mobile app authentication solution that gave the company complete control over vehicle availability and location data while restricting reservations and vehicle access to the official app. With that loophole closed, SIXT then added three more security layers; one, to detect API monitoring by bad actors and prevent MitM attacks, two, to identify and protect against any attempts to reverse engineer the SIXT mobile app, and three, to minimize the risk of at-scale attacks.

With this security foundation in place, SIXT now has granular control over the quality and the quantity of data that can now be accessed through its APIs.

Scenario 2: Securing Mobile Apps

Another huge challenge for car sharing services is the need to maximize platform security as well as customer experience without compromising either. This was the challenge that the BMW Group, which offers factory-ready vehicles for car sharing services, set out to address.

In the case of private ownership vehicles, addressing this is as simple as binding mobile app instances to specific mobile devices. In the case of car sharing services, however, it is not practical — and possibly not GDPR-compliant — to require every user across the lifetime of a vehicle to register their device with the service. For this use case, protection of the digital virtual keys, at rest and in transit, becomes paramount.

This situation clearly requires a security strategy based purely on the mobile app software, with the added caveat to avoid standard approaches, such as embedding secrets in mobile app code, for instance, that have been proven to be vulnerable in the past.

In order to address this challenge effectively, BMW opted for a software-only mobile security solution that i), was agnostic to mobile device characteristics and ii), did not involve storing secrets in the app code. The SDK that BMW deployed uses a proprietary service to measure a running app’s DNA and attest that every API request is originating from a genuine instance of the mobile app, running in a safe environment. The security aspects addressed, the solution went a step further by enabling Bluetooth-based mobile app authentication for scenarios such as underground parking lots and remote terrain, with weak or unstable Internet connectivity.  

This solution, after extensive testing across BMW’s own fleet and that of their car share partners, has since been rolled out across several thousand vehicles.

Software-only Security for Connected Cars

The conventional approach to secure the ‘app as a key’ component in connected cars has been to throw more hardware at the problem. Even as development progresses on that track, it is important to explore the potential of software-only solutions that are, arguably, more easily and cost-effectively deployed at scale, and which don't add the friction of binding the security to an individual users' mobile device. This is especially relevant in the case of connected cars, where mobile apps and APIs are critical to the digital experience as well as susceptible to the exploits of black hats. Connected cars deployed in the shared service model have their own distinct range of security requirements that can only be addressed by unique software-based solutions.