Secure Storage and Key Protection for Mobile Banking and Payment Apps

The security of the storage of cryptographic secrets is essential to ensuring the security of the whole chain of the cryptographic protocol, where these secrets are used. It should seem obvious to anyone that there is no point in ciphering or signing data if the cryptographic secrets used for such an operation can be located, extracted, and read.

This might seem obvious, but there are still many developers, especially in the mobile world, who hardcode symmetric encryption keys or private keys directly inside their code. If the application data are not deeply obfuscated (a “general purpose” obfuscator is not enough), it’s almost like giving away the keys and publishing them where anyone could find them.

Overview of the Problem

Many developers lack the culture of reverse engineering and are unaware of the tools and techniques reverse engineers use to disassemble, decompile, and reconstitute a software application. There is a good saying about this: "Amateurs talk about encryption. Professionals focus on key management."

For instance, developers may think that encrypting cryptographic secrets is enough. But it is not difficult for a reverse engineer to understand the mechanism of encryption of the secrets and locate the corresponding key encryption keys (KEKs), etc.

Basic, ‘home brew’ mechanisms aimed at obfuscating the keys have very few chances to succeed against a serious attack. Splitting, and XORing the keys with other data might seem complex. However, for a seasoned mobile reverse engineer, it is child’s play to defeat them.

Once the cryptographic keys are located and extracted, the entire security of the application collapses. Therefore, strongly protecting them should be treated as a priority.

Below, we will list several of the secure storage and key protection techniques you can use to protect cryptographic secrets in mobile banking and payment apps.

Obfuscation

Obfuscation is probably the most practical option for controlling access and usage of a key. The idea is to hide, split, mangle, tokenize, and obfuscate the keys in such a way that trying to locate them and reconstruct them in the code is much too costly in terms of time and resources, or even impossible.

Of course, as we mentioned, basic techniques don't work. You need a significant amount of obfuscation and complexity to successfully obfuscate keys.

There are no standards regarding cryptographic key obfuscation. So, it’s up to the designers and experts to create the best methods that will guarantee adequate security against reversing.

Possible key obfuscation techniques include:

• Creating a complex reconstruction mechanism to generate the keys
• Splitting the keys into multiple sub-keys to reconstruct the key that is randomly located in the binary
• Hiding the keys in a pool of dummy keys (deception techniques)
• Building a factory to generate a great number of dummy keys for reconstruction techniques
• Use steganographic techniques. For example, hide the keys of some data needed to reconstruct the keys into bitmap or dummy data
• Count the number of occurrences of given patterns in the binary to generate data needed to reconstruct the keys

The complex reconstruction mechanism can involve custom hashing or cryptographic functions using, for example, an algorithm that designs blocks by using a pseudo-random generated number, which seed itself depends on other complex parameters. This creates very good security by obscurity.

Secure Memory

The best way to protect cryptographic secrets is to store them and generate them inside secure memory hardware units. Secure (cryptographic) memory is usually a certain type of memory protected by anti-tamper systems. They may include anti-DPA and anti-SPA protection. They're usually linked to a crypto-processor unit and a memory crypto-controller that provides secure conditional access to it.

Secure memory is typically found in:

• The cryptographic core of hardware security modules (HSMs)
• Smartcards - including EMV chip cards and SIM cards
• The Trusted Platform Module (TPM) of computers equipped with it
• The secure element of NFC devices
• Secure coprocessors (like the ones usually equipping the EFTPOS terminals, the ATMs, etc.).

Usually, cryptographic secrets are generated inside such memory and not allowed to leave it, making the extraction of such secrets impossible. In many implementations, the secrets are accessed via PKCS#11 operations.

Secure memory, which is generally EEPROM memory, is different from the average memory found in “standard” computers and general-purpose devices like SATA discs, flash, RAM, etc.

In the case of mobile applications, there's either “natural” access to the SIM card or a secure element on the mobile device, both of which are eligible as secure memory. In such cases, the application should securely generate secrets and load them into the secure memory which is protected against intrusion and tampering.

Trusted Execution Environment

The Trusted Execution Environment (TEE) is often linked to secure memory but is actually a different concept. The TEE is a parallel environment that runs independently of the main OS and acts as a trusted zone. Storing secrets in the TEE if it is present, is generally a good idea.

KeyStore

The KeyStore, usually the Java KeyStore, is a software API present in Android. It can be used to securely interface cryptographic secrets in addition to other techniques. 

Secure Enclave 

The Secure Enclave is an IOS-only system acting as a hardware-based key manager with features like a TEE. It also provides acceptable security for key storage.

User Input/Authentication

Lastly, a good way to protect access to cryptographic secrets is by utilizing the users’ knowledge of some secrets to reconstruct the cryptographic secrets. A password, a geometrical pattern, or a combination of symbols can be required from users to reconstruct the cryptographic secrets.

This technique should only be used along with other techniques because it does not guarantee that an attacker could not steal the user password by using social engineering techniques.

In Summary

It's mandatory for mobile banking and payment applications to securely store cryptographic secrets like secret keys or private keys. Adding security by using an obscurity technique such as obfuscation should also be implemented in all cases.

References and Further Reading

• Read more articles about application security for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more
• Internet Security Threat Report, Volume 24 (February 2019), by Symantec Corporation 
• MASC Mobile App Security Core (2019), Web page by Cryptomathic