Securing API to Protect Your Car-Key Apps

Article By : Junko Yoshida

There are too many ways to hack the API of a car-key app. CriticalBlue has a solution for that...

Now that apps on smartphones have become the mother of all digital commerce, companies are feverishly rolling out app-based products and services – digital car key apps and car-sharing services, for example — that promise consumers optimum convenience with minimum hassle. The only fly in the ointment is security.

One way to combat the vulnerabilities now present in app-based digital car keys is to throw more hardware at the problem. Tech suppliers such as NXP Semiconductors are offering car OEMs automotive-qualified Secure Element and NFC chipsets, with plans for an extra layer of security in digital car keys by adding Bluetooth Low Energy (BLE) and Ultra-Wide Band (UWB). NXP is a member of the Car Connectivity Consortium (CCC), a cross-industry organization. The CCC is spearheading the automotive industry’s initiative to standardize “smartphone-to-car connectivity” solutions.

But before shooting the moon — bringing all stakeholders including car OEMs, smartphone companies and tech suppliers together to agree to add a certain set of hardware security chips — there is a prior consideration, said David Stewart, CEO of CriticalBlue, in a recent interview with EE Times. To design a service using an app that opens a car, for example, it’s critical “to know what your app does,” he said. “More importantly, you should know what your app is communicating with.”

A top priority for protecting digital car-key apps is securing APIs, Stewart explained because every mobile app is powered by the APIs published in the mobile app. Open APIs in recent years have become a playground for hackers.

David Stewart, CEO of CritialBlue
（Source: EE Times）

Stewart said, “Hardware security [like the CCC’s efforts] is great for securing keys at rest, but the reality is that mobile apps are used to acquire and handle [keys].” The weak link, he notes, is the very fact that “the digital keys have been passed to the mobile app.”

CriticalBlue (located here) offers a product called Approov supported by its own backend infrastructure to authenticate verified user, verified channel, and verified app.

Why secure APIs?

Stewart, who started out his career as a chip designer at National Semiconductor, isn’t saying that hardware security is not necessary. He is fully aware of the significance and capability of hardware-based security. But CriticalBlue’s past projects, including development of software optimization tools to improve mobile hardware performance, have given Stewart and his team insights into the roles software plays on a mobile platform.

CriticalBlue today focuses on securing APIs to protect mobile app-based products and services.

In a white paper published this week, CriticalBlue wrote:

When it comes to APIs which service mobile apps, the trouble is that anyone – including attackers – can freely install an application on a device he/she controls to reverse engineer and study it for weaknesses.

CriticalBlue’s list of the top five threats to APIs range from man-in-the-middle attacks and data scraping to credential stuffing, app impersonation and denial of service attacks.

Notably, service providers use apps that rely on data and services provided by multiple APIs from a range of vendors. A typical app uses both internal and third-party APIs — each with its own approach to access management and associated charges. Before allowing access, most APIs require apps to present a valid API key with each request.

Problems arise when hackers extract the API key by reverse-engineering an app.

Since APIs are open and published in the app, there are many ways the API keys can fall into the wrong hands, explained CriticalBlue.

Hackers, for example, can launch a man-in-the-middle attack (by intercepting API traffic) to steal the key. They can then launch replay attacks by automated scripts for data scraping or fake account creation.

Undoubtedly, consequences are dire. An attacker could take control of a billing API to grab customer payments. Competitors could scrape proprietary data, like pricing information. App impersonation could allow cyber criminals to create “a copycat, malware-infested version of your app and tricking your would-be customers into downloading it,” according to CriticalBlue. Worse, an impersonation threat could “involve an attacker reverse engineering your API protocol and building new software that impersonates the real app to make arbitrary API calls, or otherwise access your backend infrastructure to communicate with and scrape information from your servers.”

Approov’s move

CriticalBlue’s Approov will come in, noted Stewart, when the service provider, for example, needs to “authenticate that the agent communicating with your API is your authentic app running in a safe environment.” Approov can do this by remotely identifying “an app’s unique DNA and safe run-time environment.” Approov uses no API key in app. Instead, Approov provides short-lived tokens for API calls.

As Stewart explained, the goal here is “to ensure that the keys are not to be passed to a modified app or to an app which is running in an untrusted mobile environment.”

CriticalBlue’s Approov is a live product now deployed by Sixt, a German car rental company to address the API abuse issue. The rental company chose Approov for Sixt Share, a car-sharing company it launched initially in partnership with BMW.

How Approov works, and how to deploy it

How Approov works
（Source: CriticalBlue）

How companies deploy Approov
（Source: CriticalBlue）

Why not go for standards?

Asked about NXP’s hardware-based security solutions based on the CCC Digital Key standard 2.0., Stewart acknowledged, “Since the NXP hardware security implements the standard, this implies effortless interoperability between every mobile device and every vehicle. Standards are a wonderful thing.”

But standards also come with a downside, he noted. “It takes a long time for the market to upgrade its hardware to use new technology.” Stewart asked, “So, realistically, how long will it take before CCC Digital Key standard 2.0 is supported by all cars and all mobile phones which are actively being used?”

The CCC is also working on a version 3.0 that supports Bluetooth Low Energy (BLE). Stewart said, “BLE is in use by Approov already in our offline model but is also being used by other security solutions and communication applications between mobile handsets and vehicles. So again, you see the challenge of the standards lagging the business requirements today.”

Finally, even with very strong hardware, poor implementation can compromise security, Stewart pointed out. “It’s important that the security is easy to implement and deploy.”

Indeed, CriticalBlue’s Approov is a service to which companies can subscribe today, leaving Approov SDK to automatically manage integrity checks in the cloud.

But if Approov is as effective as Stewart claims, why didn’t CriticalBlue join the CCC? Shouldn’t API projection be part of the industry standard?

Stewart said, “We’ve certainly looked at it but it’s something that appears too long-term for a small company like ours to sink time into. Added to that is the fact that standards organizations are usually looking to create a compromise solution that meets all participants’ requirements. They are not looking to adopt a proprietary solution like Approov unless we open sourced it or somehow made it free.”

He concluded, that deferring to the deliberate pace of an industry consortium is not an ideal survival strategy for small companies such as CriticalBlue, “who are trying to get things done and gain market share as quickly as possible.”