Secure Storage and Key Protection for Mobile Banking and Payment Apps

Introduction

In that article,we shall focus on the techniques used for protecting key and in general cryptographic secrets in the context of mobile banking & payment applications.

Overview of the Problem

The security of the storage of cryptographic secret is essential and vital to ensure the security of the whole chain of the cryptographic protocol where these secrets are used.

It seems 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.

While this statement should be trivial to understand, there are still many developers, especially in the mobile world, who are hardcoding 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 in clear to anyone.

Many developers lack the culture of reverse-engineering and are unaware of the tools and techniques used by reverse engineers 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, ‘homebrew’ mechanisms aimed at obfuscating the keys have very few chances to succeed against a serious attackers. Splitting, xoring the keys with other data etc… may look, at first glance, complex but for seasoned mobile reverse engineers it is a child’s play to defeat them.

Once the cryptographic keys are located and extracted, the whole security of the application collapse, therefore strongly protecting them should be treated as a priority.

Here, in what follows, we will list several of the possible techniques used in mobile development to protect such secrets.

Obfuscation

This is probably the most straightforward option.

The idea is to hide, split, mangle, tokenize, 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 do not work. For the obfuscation of the keys to be successful a great amount of obfuscation is needed with important complexity.

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.

Among the possible techniques we list these ones:

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

These are just an example of key obfuscation techniques

Secure Memory

The best way to protect cryptographic secrets is to store them (and eventually generating them inside) secure memory units.

Secure (cryptographic) memory is usually a certain type of memory protected by anti-tamper systems ( which may include as well anti-DPA, anti-SPAM protection etc…) and usually linked to a cryptoprocessor unit and a memory crypto-controller which provides secure conditional access to it.

Secure memory is typically found in:

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-purposes devices like SATA discs, flash, ram etc…

Some examples of secure memory units are:

In the case of mobile applications, there is a “natural” access to the sim card, which is eligible as secure memory. In such case, the application should (securely) generate secrets when it is installed and load them in the sim card which is naturally 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 which runs independently of the main OS and which 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 and eventually in java-enabled mobile phone operating systems.

It can be used to securely interface cryptographic secrets in addition with the other techniques.

Secure Enclave

The secure Enclave is an IOS-only system acting as a hardware-based key manager with features similar to a TEE. It provided as well acceptable security for key storage.

User Input

Finally a good way to store cryptographic secrets is to use user knowledge of some secrets to reconstruct them. A password, a geometrical pattern, a combination of symbols can be required from the users to reconstruct the cryptographic secrets.

That technique should only be used in addition with the other techniques as it does not guarantee that an attacker could not as well steal that user password using social engineering techniques for instance.

Conclusion:

It is mandatory for mobile banking and payment applications to store in a secure way cryptographic secrets such as secret keys, private keys, symmetric encryption keys etc… security by obscurity technique (e.g ‘obfuscation’) should also be implemented in all cases.

Acodez IT Solutions is a web design and web development company in India offering all kinds of web-related services. We are also a digital agency offering digital marketing services at affordable prices. To find out more, click here.