Protecting Your SDK With Approov

Photo by Ann H from Pexels

When we talk about Approov API Threat Protection, we usually talk about it in the context of ensuring that only genuine instances of your own mobile app can use your API to access your backend servers. However, there is another use case which occurs commonly in our customer base - ensuring that only your SDK can use your API where you distribute your SDK to your customers. Here also, Approov is highly effective.

The Why and How of Distributing SDKs 

You are likely familiar with the notion of using 3rd party SDKs in mobile apps, in fact the average number of SDKs per mobile was calculated to be 18.2 in 2018 by SafeDK, and there is no reason to think that this number has dropped. Not all of these SDKs will have an API in order to communicate with an associated cloud service but most of them will, and some will use multiple APIs. 

In the more traditional use case of deploying services for mobile customers, you own and control the mobile app, the API and the backend servers. This allows you to control the security policies and mechanisms from one end of the mobile channel to the other. This doesn’t make you immune from fraud, data scraping and other forms of API abuse, as we know well, but this use case is easier to protect than one where the API is used by an SDK embedded inside a 3rd party app. How do you know the API traffic is really coming from a genuine instance of that 3rd party app, rather than a script or some unofficial app? 

There are good reasons in many markets for service providers to use an SDK distribution model rather than deploy a mobile app directly.  For clarity in this article we will refer to the owner and distributor of the SDK as the provider and we will refer to the owner of the mobile app as the enterprise. The SDK distribution use case generally applies in situations where a provider only implements part of the functionality that the enterprise delivers but that part is specialized and not core to the enterprise offering. Therefore, for commercial and efficiency reasons it makes sense for the enterprise to use an SDK and for the provider to provide an SDK (and associated API).

We’ll look at some market examples in a moment but let’s first consider the distribution, integration and deployment model. Simply put, the SDK is a self-contained software module which is embedded into and invoked from the mobile app code. It will be passed certain information relevant to the service provided by the SDK and it will return the result once the task is completed. That task will probably require the use of the provider’s API. Once the mobile app has consumed the output of the SDK it may well communicate with the enterprise backend service via the enterprise’s own API. This architecture is illustrated in the diagram below.

Let’s now examine the above diagram from a security perspective. Clearly the enterprise is motivated to care about ensuring that the assets and data contained in their cloud service can only be accessed by genuine instances of their mobile app. One could argue that since the enterprise has control of all the elements (app, API and cloud service) then the security should be straightforward but the reality of defending against automated attacks such as credential stuffing (aka account takeover) and data scraping is a bit more complex. For more on the general threats against API which service mobile apps, we suggest that you read our mobile API security eBook.

How does the security look from the perspective of the SDK provider? They will want to ensure that API requests which come into their cloud service have truly come from their embedded SDKs. But how can they be sure of this? They may provide an API key to each enterprise which embeds the SDK but that is a static secret which will probably be presented in the API request. It is therefore something which could be intercepted or reverse engineered from the app and used to launch an automated attack at scale. Unlike the security challenge for the enterprise who controls their own mobile app, SDK providers have no powers over the end client and therefore have a higher risk to mitigate.

Distributed SDK models are common in markets such as advertising, gaming and travel but let’s look at a couple of sectors where the risk profile is well understood.

Distributed SDKs in Financial Services 

Regulated industries like financial services are prime candidates for an SDK distribution model because there are compliance factors to consider for an enterprise to decide if it wants to develop and own particular functionality. Taking a function in house implies taking on responsibility for maintaining its ongoing compliance, and the increased risk of penalties if a regulator finds that you have not done a good job. The flipside of this of course is that there are opportunities for providers to specialise and to take on the compliance load.

Payments are a good example of this. Enterprises who need to process financial transactions do not want to take responsibility for managing the card/wallet data and verifying the transactions, and they will pay for 3rd party providers to deliver this service. The relevant security compliance organisation for payments is the Payment Card Industry Security Standards Council (often referred to as PCI) who set the standards and enable external providers of compliance verification services. A summary of popular payment SDKs in 2019 can be found here.

Distributed SDKs in Automotive/Mobility 

The automotive market is another where SDK distribution is regularly used. Two common use cases are the provision of third party services related to infotainment services such as maps and gaming, and the provision of security services for accessing the vehicle itself to enable mobility services such as car sharing.

The implications of abuse of the APIs which the embedded SDKs use in automotive and mobility businesses could be significant. Leakage of data detailing where a particular vehicle has been and when might be possible, or simply stealing vehicles via a car sharing app might be possible, either of which would generate horrible publicity for both the provider and the automotive OEM. 

How Does Approov Help?

In December 2019 a new PCI Security Standard for Contactless Payment on Commercial off-the-shelf devices (CPoC) was announced which enables merchants to accept contactless payments by mobile devices using NFC. Software attestation checks are used rather than relying on static authentication data. We wrote about this in a recent blog article. Our Approov product is a software attestation solution. Attesting, or authenticating, remote client software such as mobile apps and SDKs is becoming a mainstream solution securing mobile businesses. PCI CPoC is just one example. 

The regular Approov flow and underlying technology is well covered on our website so we won’t go into here except to say that a short lifetime token is transmitted with API requests coming from the remote client and this token is checked at the API endpoint. If it is valid, the API request can be accepted; if it is invalid, expired, or there is no Approov token, the API request should be denied.

The Approov flow for protecting SDKs is very similar. Remember that the intention is to be able to protect the provider API when it is called directly from the enterprise app, via the embedded SDK. Including Approov in the provider SDK will significantly improve security by ensuring that only genuine and unmodified enterprise apps can use the provider API, i.e. no scripts/bots and no hacked versions of the enterprise app.

Once Approov has been integrated into the provider SDK and the provider SDK has been integrated into the enterprise app, the provider API is fully protected. The diagram below shows how this works. Although only one enterprise is shown, this model can be repeated for as many enterprise customers as required by the provider.

When the enterprise app launches, the Approov SDK (embedded inside the provider SDK) will request to be authenticated by the Approov Cloud Service. The authentication process will be repeated every 5 minutes during the app session but the app user will not be aware of it. A successful authentication will result in a short lifetime valid token being delivered to the SDK within the app and the SDK will further transmit the token, along with the API request, via the provider API to the provider cloud service. The token is checked for validity at the API endpoint within the provider cloud service.

An unsuccessful authentication, caused by attempts to use the provider API via scripts, bots, modified apps or genuine apps running in unsafe environments, will cause the Approov Cloud Service to send an invalid token. The provider will determine what constitutes an unsafe environment by defining an Approov security policy.

In Conclusion

Distributing SDKs is a viable and necessary approach to deliver key functionality in mobile apps. Most SDKs are served by APIs and those APIs are often open to abuse which could be highly detrimental to the business prospects of the SDK provider. Approov provides an easy to use, simple to deploy solution which dramatically improves security of your APIs and reduces the attendant risks to your business.