Introduction to Cryptographic Key Protection

Cryptography is at the heart of data security, and it has become an indispensable protection mechanism for securing data within mobile applications.

Cryptographic keys are commonly used to:

• Maintain confidentiality of digital assets;
• Enforce software product licensing;
• Bind data to devices and applications;
• Prove identity;
• Secure communication against eavesdroppers;
• Facilitate financial transactions.

How Keys Are Used to Protect Mobile Payments

Increasingly, consumers are demanding faster and richer mobile experiences that allow for offline functionality. Consumer demand has resulted in mobile app requirements for secure, offline data storage of sensitive assets. For example, Android’s Host-based Card Emulation (HCE) allows the user to conduct offline credit card purchases and mobile wallet transactions. An HCE solution stores a limited-use key (LUK) within a local data store on the user’s mobile device. The LUK allows the user to conduct financial transactions in a secure manner while the phone is offline through the use of Triple Data Encryption Standard (DES).

Why Offline Data Stores Attract Cybercriminals

By examining the steps of conducting an offline transaction, we can understand how and where cybercriminals strike and steal sensitive financial data, or the keys associated with that data, in order to conduct fraud. Let’s review the steps below:

• Step 1: Users register their mobile app with the credit card issuer’s server when they first log into the app. In response, the server generates a user key. This key permits the server to confidentially communicate anything sensitive to the mobile app in a way that ties that data to that specific user. After the user completes registration, the server generates an LUK and encrypts it using the user key.
• Step 2: The server transmits the LUK to the mobile payment app. The mobile payment app stores the LUK locally on the device within private key storage. The storage itself is typically encrypted using a separate set of encryption and decryption keys that are dynamically generated and are dependent upon physical characteristics of the device.
• Step 3: The user conducts an offline financial transaction and the mobile app’s HCE pulls the LUK out of local storage and uses the LUK as a form of identity to another NFC-enabled device, such as another users’ phone. Other sensitive information embedded on the credit card will also be stored and utilized from the local storage device as part of the offline financial transaction.

There are many potential points of fraud associated with the offline data store. Protecting the local store and underlying LUK from a malicious hacker’s prying eyes is of paramount importance.

Apps may also store other sensitive information within the offline data store to facilitate rich interactive experiences. Typical examples of useful offline information include financial transaction histories or passwords. In the event that the information becomes compromised, cybercriminals may be able to perform identity theft or bypass local security controls embedded in the app to conduct their own transactions.

How Keys Are Hacked

Within a mobile environment, cybercriminals can reverse engineer sensitive code that stores, transmits or processes encryption keys within the mobile device. Reverse engineering is extremely valuable to cybercriminals because it can immediately clarify the nature of the mobile app’s encryption as well as how the encryption or decryption keys are formed. Reverse engineering can also lead to a greater understanding of the nature of the algorithms used for encryption or decryption connected to the original sensitive content contained within that local store.

Attackers typically take the following steps to understand keys and their associated encryption algorithms:

1. Performing Static Analysis

Utilizing freely available, easy-to-use and fairly sophisticated tools like IDA Pro or Hopper, cybercriminals perform static analysis. These tools are very useful in identifying and understanding the nature of a mobile app’s cryptographic key protection. They permit the criminal to identify binary signatures within the mobile app’s code that reveal the presence of common encryption libraries like OpenSSL or CommonCrypto. For example, binary analysis may lead to the identification of an AES S-Box. Malicious hackers can then cross-reference the S-Box to an AES encryption algorithm used by the mobile app. Within an HCE, this type of intelligence greatly assists in understanding how the LUK is being encrypted and stored.

2. Performing Dynamic Analysis

When static analysis doesn’t give cybercriminals all the information they need, they can perform dynamic analysis. This might be a requirement if the app uses dynamic method invocation or heavy obfuscation. Method swizzling and method hooking are very effective attack vectors that criminals leverage to see runtime method invocation sequences to popular encryption implementations. Typically, this type of runtime intelligence allows malicious hackers to immediately determine the specific algorithm behind an encryption.

Furthermore, this allows malicious actors to determine whether an encryption key is dynamic or static in nature and how that key is formed at runtime. Depending upon the nature of the method interception, it may also be possible to steal the unencrypted data before it is encrypted. In the previous HCE example, cybercriminals can use method hooking to intercept at runtime any method calls to particularly popular Java cryptographic libraries. Once they see the runtime method invocations of these libraries, they immediately understand how local encryption of that keystore occurs.

3. Formulating Malicious Applications

Generating a malicious app that will act as the conduit for encrypted and desired data that the legitimate app has encrypted and stored on a target device. Prior to the third step, attackers have a solid understanding of how to decrypt the local data store because they know the underlying encryption and decryption algorithm, the key generation strategy and the associated key. Often, apps use simple techniques to generate and utilize keys that are stored on the local device. This makes the job of decryption particularly easy for cybercriminals.

In the previous HCE example, cybercriminals replace the legitimate form of the app with a malicious version that successfully decrypts the local store when the app is executed. Upon execution, the app immediately decrypts the local store and transmits the LUK and other sensitive information needed to mimic the credit card to the criminal’s server. Then, the app resumes normal execution and the victim will be none the wiser of the transmission to a third party. The criminal receives the LUK and is then able to conduct fraud by impersonating the victim’s credit card.

To create a very realistic-looking but malicious version of the original mobile app, the attacker will typically leverage repackaging or binary patching to make as few changes as required to the original.

4. Distributing Malicious Apps

There are a number of different ways to distribute malicious versions of apps to their intended victims. Some ways are easier than others. On Android, it can be done directly via email, websites or app stores. In iOS, cybercriminals may exploit the iOS Enterprise Deployment Model, use the central iTunes store or distribute via other enterprise stores available to end users.

There are a number of attack vectors that allow for easy substitution of legitimate apps with malicious versions. WireLurker is an excellent example of an iOS vulnerability that allows the attacker to silently replace a legitimate version of the app with a malicious version. At the same time, the malicious app obtains access to all the residual encrypted data left by the legitimate app.

In the previous HCE example, malicious hackers may distribute the malicious version of the Android app by tricking the victim into downloading it via email or phishing.

Best Practices for Cryptographic Key Protection

Below are some highly effective strategies that will help raise the bar significantly in preventing cryptographic key theft, especially when using keys in hostile environments:

• Use Encryption Keys Without Binary Signatures: At some point within a mobile app’s code, encryption or decryption keys are exposed in memory or in the data store of the mobile device just before the app uses that key for encryption or decryption. This universal feature of cryptography gives malicious hackers an excellent opportunity to steal that key if they can recognize it. Criminals can also steal hard-coded keys via static analysis or runtime keys via dynamic analysis attack vectors. In the example above, theft of the plaintext LUK keys may be possible through method hooking or swizzling, and it would result in financial fraud.
• Use Encryption Algorithm Implementations Without Binary Signatures: Conventional encryption libraries follow fairly standard binary patterns and implementations that are predictable to cybercriminals. These malicious actors can perform static analysis to quickly identify binary patterns that will immediately reveal the nature of the underlying encryption algorithms being used. Organizations may try to outsmart cybercriminals with surface-level obfuscation through method renaming, but this does not prevent them from identifying the underlying encryption that is being used when the organization employs a standard encryption library implementation like OpenSSL or CommonCrypto.

• Apply White-Box Cryptography in Lieu of Standard Cryptographic Implementations: To stop cybercriminals from reverse engineering a mobile app’s encryption, your organization should leverage a white-box cryptography solution that combines mathematical obfuscation in conjunction with classic code obfuscation. Together, these two forms raise the bar to high levels for criminals trying to identify keys or algorithm implementations via static and dynamic analysis.

White-box cryptography must protect static keys, which are embedded in applications when they ship; dynamic keys, which are generated on the fly at runtime; and sensitive user data. Ideal white-box cryptography characteristics include:

• Algorithmic Strength: This is a proven approach that is resistant to known attacks on white-box cryptography implementations. If possible, ask for validation by external third-party security firms that have cryptography expertise.
• Performance Friendliness: White-box cryptography can result in performance penalties during key transformation steps. The performance should be tunable to meet performance requirements.

• Ease of Use: Often, white-box cryptography replaces existing or skeleton code that uses an industry implementation. It should be easy to replace existing encryption code with a white-box or equivalent solution.

• Portability: Ideally, white-box cryptographic solutions should be based on solutions that are written in C since the language is highly portable to all platforms and compatible with all application hardening techniques.

• Universal Support: White-box cryptography solutions should support all major cryptography algorithms commonly prescribed today.

http://www.youtube.com/watch?v=lP1azJTHgm4