如何在 Android 应用程序中保护 Azure 翻译 API 密钥

Question

I am developing Android Translation App. The app uses Azure cognitive service text translation API key.

The API key is inside the App source code in Java file, and if I publish the app, people can crack the app apk file and use my API key, which will be quite expensive. Is there away how to protect my API key from being stolen? There is no login in the app, no sign in and anyone can download it from play store.

How can I protect the API key from being stolen?

Answer 1

You can use android Keystore which is there for a scenario like yours official docs

or can refer to a sample code here

Answer 2

Reverse Engineering

The API key is inside the App source code in Java file, and if I publish the app, people can crack the app apk file and use my API key

Yes, and its not hard to do when a lot of different open-sources exist to make this task easy to achieve, even by non technical people, like I demo with the Mobile Security Framework in my article How to Extract an API key from a Mobile App with Static Binary Analysis :

The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.

Also, you can use the grep command in the upload directory of MobSF to find other secrets that MobSF is not able to find:

grep -irl '_key"' --include 'strings.xml' --include "AndroidManifest.xml"

and

grep -irn '_key' --include '*.java' --include "*.smali" ./java_source/tld/domain ./smali_source/tld/domain

Replace _key with whatever other pattern you may want to look for.

Replace tld/domain with the one used by the mobile app being reverse engineered, eg: com/example .

Secret Hidden in Native C Code

Secrets can be hidden in native C code as in the demo on the above linked article :

During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.

But then if you cannot find it with static analysis then you do a MitM attack, as I demo on this other article Steal that Api Key with a Man in the Middle Attack :

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key .

So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.

Secrets in Hardware Keystores or Vaults

An alternative to the MitM attack is to use an instrumentation framework to hook at runtime to the code that retrieves the secret, be it from the Android Hardware baked Keystore or from any other vault provided by your cloud provider of choice:

Frida :

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

Third Party Services

The API key is inside the App source code in Java file, and if I publish the app, people can crack the app apk file and use my API key, which will be quite expensive.

Yes, it can be very expensive and you only discover it when the bill is already huge, despite you can set billing alerts, they don't work as you may think they do.

Reverse Proxy to the Rescue

Is there away how to protect my API key from being stolen?

Best practices don't recommend to use third party services directly from within a mobile app, instead they should be delegated to the API backend for the mobile app or to a Reverse Proxy, as I wrote in this my other article Using a Reverse Proxy to Protect Third Party APIs :

In this article you will start by learning what Third Party APIs are, and why you shouldn't access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.

So, by now you may think that you are just shifting from protecting the secret for accessing the translation API for the one to access the Reverse Proxy or API backend, and you are right, but with a huge difference, that makes all the difference, you are in control of the Reverse Proxy and/or API backend, therefore you can closely monitor the traffic, throtle/shutdown it and apply as many security defenses as necessary to keep things under control.

Open APIs

There is no login in the app, no sign in and anyone can download it from play store.

So, you have created a friction-less user experience but you have also created a security nightmare for yourself to solve.

Before I delve in more details it's important to first clarify some misconception around the difference between who vs what is accessing the backend.

The Difference Between WHO and WHAT is Accessing the API Server

I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

You can think about the who as the user your API backend or Reverse Proxy could be able to Authenticate and Authorize access to the data(if you were using it), and think about the what as the software making that request in behalf of the user.

In an open API you are not able to identify the who in the request, but even if you were able it would not be enough to lock-down the mobile app with the API backend or Reverse Proxy.

So, what you need to strength the delegation of the third party service to your own backend or reverse proxy is to find a way of locking them down with the mobile app.

A Possible Additional Solution

Is there away how to protect my API key from being stolen?

The mobile app and the API backend and/or Reverse Proxy can be tight together by locking them down in a way that they only accept requests comming from a genuine and untampered version of your mobile app by introducing the Mobile App Attestation concept, and I recommend you to read this answer I gave to the question How to secure an API REST for mobile app? , especially the sections Hardening and Shielding the Mobile App , Securing the API Server and A Possible Better Solution to learn some more defense techniques and to learn about Mobile App Attestation.

In a nutshell the Mobile App Attestation solution will allow for any backend to assert with a very high degree of confidence that the request comes indeed from what you expect, a genuine and untampered version of your mobile app, aka not from a bot, script, cURL or any other tool.

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide :

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

Answer 3

Another way to make your keys hard to reverse engineer is to save them in the NDK as native code.

Answer 4

One more solution is to create you own service proxy, which is your REST service that takes user requests, gets translation responses from AWS, and sends back responses to mobile devices.

The beauty is the secret key won't be stored on the mobile device while the downside is that your REST service becomes the single point of failure therefore you may need to provision redundant servers.

However, as your service is light-weighted, it shall scale well.