In my application I have a connection with keycloak for get an API key and a secure storage to save the user data.
How I can secure :
I read different article but I didn't find a way to properly secure those data. A simple revert engineering from the APK show the secret data.
It's possible to obfuscate the code but it's not a serious solution and this has a great impact on performance.
In my application I have a connection with keycloak for get an API key and a secure storage to save the user data.
So, using KeyCloak to retrieve the API Key at runtime in order to not have it harcoded in the mobile app, just shifts the problem from securing the API key to securing the KeyCloak secret.
How I can secure :
- the secret id need to connect to the keycloak
- the key to access the secure store
The cruel truth is that you can't properly secure them, because any secret you ship in a mobile app release must be considered as belonging to the public domain, because it's on the client side, therefore anyone can spend the time he/she wants to reverse engineer the mobile app with static or dynamic analysis to extract it.
You can hide the secret in Natice C code with the use of JNI/NDK as I show in the 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.
Now, with the secret hidden in the native C code it will be time consuming to extract it, but not impossible. So, if you cannot do it easily with statically reverse engineer it, then you can do it with a MitM attack as I show in the 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.
Do you get the the twist? You can make it very hard to extract with static binary analysis, but then the attacker just needs to use a tool like mitmproxy to intercept the traffic and lookup the API key in the header of the request.
You can try to safeguard your mobile app against MitM attacks has I exemplify in my article Securing HTTPS with Certificate Pinning:
In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.
In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.
But, you need to be aware that you can also bypass pinning as I show in the next article Bypass Certificate Pinning:
To demonstrate how to bypass certificate pinning we will use the same Currency Converter Demo mobile app that was used in the previous article.
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Other alternative for the attacker is to use an instrumentation framework to hook into the code that returns the secret or API key from the keystore or from KeyCloak server. A popular instrumentation framework used for this type of attack 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.
So, the use of Frida to hookup in the code is made easier when the code is not obfuscated, because it's easy to find the function that does it by doing some search through the code with some guessable function names, or just resort to follow the code flow with the help of an IDE.
It's possible to obfuscate the code but it's not a serious solution and this has a great impact on performance.
Yes, you are right that code obfuscation will not hide the secret, only makes it hard to understand the logic flow.
Code obfuscation should still be in your list of security hardening your mobile app, and once used as Google recommends, by shrink code and resources, obfuscate, and optimize your app with R8, and then you will not have a slower app just because the code is obfuscated, but you will have one that is much harder to follow the logic through the code, thus an attacker poking around the code to find were to hook an instrumentation framework will have a much more consuming time task, to not call it frustrating sometimes.
I read different article but I didn't find a way to properly secure those data. A simple revert engineering from the APK show the secret data.
Yes, you cannot find one because that's not a trivial problem to solve, you can only make it hard, but not impossible.
Before I dive into the possible approaches to solve your problem I would like to first clear a misconception that usually I find among developers of any seniority, that is about the difference between who and what is accessing an 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.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
Now that you are better informed about the difference between them you can make better informed decisions in terms of security and trade-offs when deciding waht approaches to take for your use case.
I call it naive approach, because has I shown in my series of articles I linked it can be bypassed, but it raises the bar for the skill set and time necessary to do it.
So, your main goal seems to be to protect the API key, that you need to use as a way to identify your mobile app with the backend API server, aka to lock down the backend API server with the genuine and untampered versions of your mobile app, that will allow for the server to only answer to requests from the same binary that you uploaded to Google Play store, then you may want to take a look into the Mobile App Attestation concept, and to for that 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.
In a nutshell the role of a Mobile App Attestation solution is to guarantee at run-time that your mobile app was not tampered with, is not running in a rooted device, not being instrumented by a framework like xPosed or Frida, not being MitM attacked, and this is achieved by running an SDK in the background. The service running in the cloud will challenge the app, and based on the responses it will attest the integrity of the mobile app and device is running on, thus the SDK will never be responsible for any decisions.
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
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.
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.
