What is the best way to hold a private key inside ios app

Question

Im looking to use a private key with API's the only issue is how to hold/accure the private key at least on the first run becuase after i can have it inside keychain

the best approach i see is having a p12 file and using SecPKCS12Import i can import it. but again a p12 file would need a password which will then have to be in the application so we are back to square one

In other words is it possible to have a kind of certificate inside the application and only the application it self can use/open ?

Answer 1

The approach taken in most companies is to not hold the secret key in the repo as opposed to the app.

Most of the time the keys are injected during some automated build process and we rely on code obfuscation to hide it from potential threats.

However it is impossible to hide keys from decompilers completely. The only way to do it would be to not use any third party library and instead rely on the BE to facilitate the communication to any third party.

Answer 2

Your Problem

Im looking to use a private key with API's the only issue is how to hold/accure the private key at least on the first run becuase after i can have it inside keychain

From the moment you ship inside your code something that is a secret it becomes automatically public, because in one way or another attackers will be able to grab it. They may start by statically reverse engineer your mobile app binary and If they don't succeed then they will do with a runtime attack via an instrumentation framework.

Also, storing it in the keychain leaves it also vulnerable to runtime attacks via an instrumentation framework, where the attacker will hook into the function that returns the certificate and extracted it once its outside the keychain.

Reverse Engineering

the best approach i see is having a p12 file and using SecPKCS12Import i can import it. but again a p12 file would need a password which will then have to be in the application so we are back to square one

Correct, if you use a password then you are just swapping what you need to hide/secure in your mobile app code. I notice that a lot of developers tend to resort to code obfuscation, but unfortunately this approach isn't very effective when it comes to protect secrets from being extracted of a mobile app binary. It may make it less intuitive for common developers, but attackers are used to it, and they have techniques to approach it with static analysis and runtime attacks.

For static binary analysis they can use Mobile Security Framework (MobBSF) open source tool as I exemplify on 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.

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.

While the article is in the context of extracting an API Key from an Android APK the procedure to upload the IPA file to extract the private key is the same and then you just need to lookup for it in the results presented on the MobBSF dashboard. If they don't find it here then they will proceed to a runtime attack with an instrumentation framework.

For a runtime attack they may resort to the popular Frida open source tool as I exemplify in the article How to Bypass Certificate Pinning with Frida on an Android App:

Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.

Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.

While in the context of bypassing pinning on Android you can take a look to the approach in order to get inspiration on how to do it for iOS. I have an article planned for iOS, I just didn't had the time yet.

Possible Solution

In other words is it possible to have a kind of certificate inside the application and only the application it self can use/open ?

No, and Yes. It will depend on how you approach it and how far you are willing to go to protect it.

No, because if is in the mobile app code then its up for grabs, therefore you must consider it public. It's not a question of if it will be extracted, but when it will be.

Yes, if you adopt the solution where you retrieve it just-in-time of being used from a backend at runtime, but only if the backend can assert that the request is indeed from a genuine and unmodified instance of your mobile app, not from one under any form of attack or from a request issued by curl, Postman, or even originated from a bot. After fetching the certificate from the backend never store it in whatever form in the device, even if in the keychain, because at some point you need to retrieve it from the keychain and then is up for grabs with runtime instrumentation, that will hook into the function that returns it to extract the certificate.

I will recommend you to read my accepted answer to the question How to use an API from my mobile app without someone stealing the token where the Runtime Secrets Protection seems your best option to have the certificate delivered to your mobile app when needed.

In a nutshell you will have the certificate securely stored in the cloud and have it delivered just-in-time of being used by your mobile app, but only if the same is not being under MitM or runtime attack, running on a rooted or jail-broken device, isn't attached to a debugger or running in an emulator.

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.