Android: CryptoObject and BiometricPrompt security. Is it possible to hack?

Question

I need to securely store certain secret in my app using biometry. I wanted to use BiometricPrompt to obtain CryptoObject which will be used to cipher and decipher this secret (e.g. like described here: https://medium.com/androiddevelopers/using-biometricprompt-with-cryptoobject-how-and-why-aace500ccdb7).

val promptCrypto = BiometricPrompt.CryptoObject(cipher)
biometricPrompt.authenticate(promptInfo, promptCrypto)

But is there any known vulnerabilities in this mechanism? Is there any option to obtain this CryptoObject without using biometry (e.g. on rooted device)? Is it secure on all devices or are there any differences?

Thank you for your response.

Answer 1

Your topic questions

Android: CryptoObject and BiometricPrompt security. Is it possible to hack?

If it is Software then it may be possible to hack it. It's just a question of time, knowledge and effort.

But is there any known vulnerabilities in this mechanism? Is there any option to obtain this CryptoObject without using biometry (e.g. on rooted device)?

Not that I am aware off, but I am not an expert in reverse engineering, just someone knowledgeably enough to tell you that an attacker doesn't need to bypass this security mechanism to extract the secret from your mobile app.

Just keep reading to understand how it's possible...

Secrets in a mobile app are public

I need to securely store certain secret in my app using biometry. I wanted to use BiometricPrompt to obtain CryptoObject which will be used to cipher and decipher this secret.

The use of the CryptoObject and BiometricPrompt will securely encrypt the secret and store it with the underline mechanism known by the Android Hardware-backed Keystore:

The availability of a trusted execution environment in a system on a chip (SoC) offers an opportunity for Android devices to provide hardware-backed, strong security services to the Android OS, to platform services, and even to third-party apps.

While this may be very hard to hack, an intelligent attacker will not waste his time in trying to break it, instead, the attacker will download your mobile app binary, perform some static analysis on it to find the function in your code that uses the secret after it has been decrypted, and then use an instrumentation framework to hook to this function at runtime and extract the secret to a command and control server he controls, from where he will then be able to automate attacks using the extracted secret. The reach of this type of attacks will be limited if the secret is scoped to the current user of the mobile app.

One of the most popular instrumentation frameworks is 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.

The bottom line here is that no matter how safely you store your secrets in the mobile app, they must be considered public from the moment your release the mobile app.

Delegate access to third party services and API's

I often see third-party APIs being accessed directly from within a mobile app, thus the mobile app will need to have the secrets to access them.

The problem with this approach is that once you cannot guarantee that an attacker will not steal your secrets, then you may only know that they have been compromised when your bill usage for this services goes to the roof. Worst, you may only find the secrets have been compromised after you are made aware that you have suffered a data breach, but now the reputation of your business is severely affected or damaged beyond repair, to not mention the huge fines that the business may have to pay due to breaches of laws, like the GDPR in Europe.

So my advice is to always delegate to a backend that you control the access to third party services/APIs, and you can read more about in my 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.

Now you may say that you still need a secret to access this Reverse proxy, and that is true, but now you are only including one secret in the mobile app for a backend that you have total control off, where you can apply all defence measures you see fit to monitor abuse, throttle it or completely block it. So no more surprise bills in your third party services/APIs, because now they are accessed through this backend you control.

The bottom line is that a mobile app should only communicate with a backend that is under your control and any access to third-party APIs services must be done by this same backend you control. This way you limit the attack surface to only one place, where you will employ as many layers of defence as what you are protecting is worth.

Possible Solutions to defend your backend

I mention above that you can apply defences measures you see fit, 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 Securing the API Server and A Possible Better Solution to understand some of your options.

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.