Implementing Secure Biometric Authentication on Mobile Applications

Nowadays, almost every mobile device has a biometric sensor that allows developers to implement local authentication and also store sensitive data securely through dedicated APIs.

Biometric authentication is generally more secure than classic username/password approach. Anyway it must be considered that a wrong implementation could allow an attacker to easily bypass authentication mechanisms by using hooking techniques which can be performed with tools like Frida, Objection, and other similar utilities.

In this article we are going to expose some common mistakes that developers can make while implementing  biometric authentication and how to implement it in the correct way.

Biometric Authentication in Android

The Android platform introduced the biometric authentication in Android 6.0 (API level 23) with the class FingerprintManager which supported only fingerprint authentication.

In Android 9 (API level 28), the FingerprintManager was deprecated due to the release of android.hardware.biometrics.BiometricPrompt.

Lastly, In Android 10 (API level 29) the biometric authentication is managed through android.hardware.biometrics.BiometricManager.

It is worth considering that the Android platform introduces also the classes androidx.biometric.BiometricManager and androidx.biometric.BiometricPrompt that could be used instead of the previous ones. These classes will automatically query the BiometricManager on devices running Android 10 (API 29) and FingerprintManagerCompat on Android 9.0 (API 28) and prior versions.

The Android platform, unlike iOS, does not allow to save arbitrary data within Keystore. However, it allows to create encryption keys, which are saved in the Keystore. For every key it is possible to define the access criteria.

In order to implement effective biometric authentication, it is therefore necessary to create a key that can be used only after a successful biometric authentication. This key should be used to encrypt and decrypt a sensitive data such as an authentication token.

In order to use the biometric authentication all of the following requirements must be fulfilled:

1) Require the proper permission in the Android Manifest:

<uses-permission android:name="android.permission.USE_FINGERPRINT" />

<uses-permission android:name="android.permission.USE_BIOMETRIC" />

2) Check if the user can authenticate using biometrics:

This includes having a protected lock screen enabled, a biometric hardware available and a biometric identity registered (For instance a fingerprint). The following piece of code shows a sample implementation:

import androidx.biometric.BiometricManager;

. . .

BiometricManager biometricManager = BiometricManager.from(this);

switch (biometricManager.canAuthenticate()) {

    case BiometricManager.BIOMETRIC_SUCCESS:

        // User can authenticate using biometrics

        break;

    case BiometricManager.BIOMETRIC_ERROR_NO_HARDWARE:

        // No biometric features available on this device

        break;

    case BiometricManager.BIOMETRIC_ERROR_HW_UNAVAILABLE:

        // Biometric features are currently unavailable

        break;

    case BiometricManager.BIOMETRIC_ERROR_NONE_ENROLLED:

        // The user hasn't associated any biometric credentials with their account

        break;

}

3) Check if the application has the correct permissions:

context.checkSelfPermission(Manifest.permission.USE_FINGERPRINT) == PermissionResult.PERMISSION_GRANTED;

context.checkSelfPermission(Manifest.permission.USE_BIOMETRIC) == PermissionResult.PERMISSION_GRANTED;

The most important methods which must be used in order to implement the biometric authentication in Android are the following ones:

1) authenticate (which starts the authentication flow):

biometricPrompt.authenticate(promptInfo, new BiometricPrompt.CryptoObject(cipher));

2) onAuthenticationSucceeded (which is called upon a successful authentication):

@Override

public void onAuthenticationSucceeded(

        @NonNull BiometricPrompt.AuthenticationResult result) {

// . . . .

}

The cipher referred in the first parameter of the authenticate method should be used in order to decrypt a secret data which has been previously stored in the device. Such cipher can use both asymmetric and symmetric algorithm.

In the following example we are going to create a key for a cipher which uses AES-CBC-PKCS7.

KeyGenerator keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, “AndroidKeyStore”);

keyGenerator.init(new KeyGenParameterSpec.Builder (KEY_ALIAS,

        KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)

        .setBlockModes(KeyProperties.BLOCK_MODE_CBC)

        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_PKCS7)

        .setUserAuthenticationRequired(true)

        .setUserAuthenticationValidityDurationSeconds(-1)

        .setInvalidatedByBiometricEnrollment(true)

        .build()

);

keyGenerator.generateKey();

When creating the key for the cipher that will be used in the biometric authentication flow, the most important options are the following ones:

1) setUserAuthenticationRequired(true): available from API level 23, when set to true, the key can be used only if the user has been authenticated. Additionally, the key will become irreversibly invalidated once the secure lock screen is disabled, or when the secure lock screen is forcibly reset. 

2) setUserAuthenticationValidityDurationSeconds(-1): available from API level 23, when set to -1 the key can only be unlocked using a biometric identity. If it is set to a different value, the key can be unlocked using a device screenlock too.

3) setInvalidatedByBiometricEnrollment(true): available only from API level 24, when set to true, the key is irreversibly invalidated when a new biometric is enrolled, or when all existing biometrics are deleted. Consider that the value is true by default.

Before authenticating the user with biometrics, the cipher should be initialized in order to check if the key is still valid. This can be done as follows:

public Cipher getCipherForBiometrics() {

    try {

        final Cipher cipher = Cipher.getInstance(

                       KeyProperties.KEY_ALGORITHM_AES + "/"

                        + KeyProperties.BLOCK_MODE_CBC + "/"

                        + KeyProperties.ENCRYPTION_PADDING_PKCS7);

        final SecretKey key;

        final KeyStore keyStore =  KeyStore.getInstance(“AndroidKeyStore”);

        keyStore.load(null);

        key = (SecretKey) keyStore.getKey(KEY_ALIAS, null);

        cipher.init(Cipher.DECRYPT_MODE, key);

        return cipher;

    } catch (KeyPermanentlyInvalidatedException e) {

        return null;

    } catch (KeyStoreException | CertificateException | UnrecoverableKeyException | IOException

            | NoSuchAlgorithmException | InvalidKeyException | NoSuchPaddingException e) {

        throw new RuntimeException("Failed to init Cipher", e);

}

Once the cipher is properly initialised it should be used as an argument for the authenticate method in order to start the biometric authentication flow.

. . .

Cipher cipher = getCipherForBiometrics();

if (cipher != null) {

    biometricPrompt.authenticate(promptInfo, new BiometricPrompt.CryptoObject(cipher));

. . .

The biometric authentication flow is then managed by the Android platform, and the method onAuthenticationSucceeded is called upon a successful authentication.

It is worth considering that this method can also be called by using hooking techniques and tools such as Frida. The difference between a valid authentication flow and a tampered authentication flow is the BiometricPrompt.CryptoObject.

Indeed, when a valid authentication flow is performed the Android platform properly instantiate the cipher contained within the BiometricPrompt.CryptoObject, and then this must be used to decrypt critical data such as the aforementioned authentication token.

Instead, when this method is called by using hooking techniques the cipher is not properly instantiated and when using it to decrypt the data, an exception will be raised.

@Override

public void onAuthenticationSucceeded(BiometricPrompt.AuthenticationResult result) {

        Cipher cipher = result.getCryptoObject().getCipher();

        byte[] decrypted = cipher.doFinal(// get here authentication token encrypted);

        String authenticationToken = decrypted.toString();

        // save the authentication token somewhere

       . . . 

}

This implementation is secure even against hooking techniques because when calling the onAuthenticationSucceeded callback with Frida, the AuthenticationResult object does not contain a valid cipher instance since the used key, that has been defined as accessible only after a biometric authentication, has not been unlocked by the Android OS and the cipher will raise an Exception when trying to decrypt the data.

During the various assessments performed on mobile applications we’ve found different insecure implementation of the biometric authentication that looks like the following one:

@Override

public void onAuthenticationSucceeded(BiometricPrompt.AuthenticationResult result) {

        enterApplication(); 

}

This kind of implementation is insecure since does not make use of the  BiometricPrompt.CryptoObject contained in the AuthenticationResult object, but it assumes that the authentication has been properly validated since the method onAuthenticationSucceeded has been called and allows the user to enter the application.

It is worth considering that even implementation that makes use of the BiometricPrompt.CryptoObject could be insecure if they do not decrypt data that are necessary to login the user (such as an authentication token, JWTs and so on). Indeed even Exceptions could be captured using hooking techniques and could be ignored in order to continue the application flow. 

Biometric Authentication in iOS

The iOS platform introduced the biometric authentication starting from iPhone 5s in 2013. At that time it supported only the fingerprint authentication known as Touch ID.

When Apple released the iPhone X, the Face ID was added as biometric option that could be used to authenticate a user.

The biometric authentication flow is usually implemented with the LocalAuthentication framework. It is worth considering however that the LocalAuthentication framework is an event-based procedure and can be bypassed with hooking techniques and tools such as Frida or Objection.

Unlike Android, the iOS platform allows to save arbitrary data within the Keychain defining the access criteria for every stored item.

In order to implement an effective biometric authentication, it is suggested to use the Keychain methods instead of the LocalAuthentication framework. Such approach consists in storing sensitive data (such as an authentication token) within the Keychain, and defining the proper access criteria so that the data can be used only after a successful biometric authentication.

In order to use the biometric authentication, it is required to check if the biometric hardware is available and if the user has enrolled biometric identitites. This can be done using the canEvaluatePolicy method as shown below:

var error: NSError? if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) { // handle biometric authentication . . .

The canEvaluatePolicy method with the deviceOwnerAuthenticationWithBiometrics flag, returns true only if the hardware to authenticate the user through biometrics is available and if the user has enrolled biometric factors.

When storing sensitive data for a biometric authentication within the Keychain it is recommended to use the following flags:

1) kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: requires that a passcode is set on the device. The data is accessible only with the device unlocked and it is deleted when the user deactivates the passcode.

2) kSecAccessControlBiometryCurrentSet/kSecAccessControlBiometryAny: requires a user to authenticate with biometrics (e.g. Face ID or Touch ID) before accessing the data in the Keychain item. When using kSecAccessControlBiometryCurrentSet, whenever the user adds a fingerprint or facial representation to the device, it will automatically invalidate the entry in the Keychain. This makes sure that the keychain item can only be unlocked by users that were enrolled when the item was added to the keychain.

The usage of the other flags should be avoided when storing data relative to biometric authentication since they do not mandatory require the usage of biometric factors to retrieve the data when accessing the application.

Following it is reported an example on how to securely save data in the Keychain for biometric authentication:

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,

                                                          kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,

                                                          SecAccessControlCreateFlags.biometryCurrentSet,

                                                          &error) else {

    // failed to create AccessControl object

    return

}

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword

query[kSecAttrLabel as String] = "label_for_auth_token" as CFString

query[kSecAttrAccount as String] = "App Account" as CFString

query[kSecValueData as String] = "here_goes_auth_token".data(using: .utf8)! as CFData

query[kSecAttrAccessControl as String] = accessControl

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {

    // successfully saved

} else {

    // error while saving

}

When requesting the sensitive data, the iOS platform will ask for biometric authentication returning data or nil depending if the biometric authentication was successful or not.

During the various assessments performed on mobile applications we’ve found different insecure implementation of the biometric authentication that make use of the evaluatePolicy method and are similar to the following one:

let context = LAContext()

var error: NSError?

context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: "Authenticate with biometrrics to access the application") { success, evaluationError in

    guard success else {

        // Authentication Failed

    }

   enterApplication();

}

This kind of implementation is insecure since does not make use of the Keychain, but it assumes that the authentication has been properly validated since the success condition has been met and allows the user to use the application.

Using hooking techniques or tools such as Frida or Objection this kind of implementation could be bypassed without providing a valid biometric authentication.

It is worth considering that even implementations that make use of the Keychain could be bypassed if the proper flags are not set when storing the data in it.

Specifically the usage of the flag kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly should be avoided since they do not require that a passcode has been previously set on the device and does not delete the data when the passcode is disabled. Furthermore if the device has no passcode, the data is always accessible since the device is considered always unlocked.

Finally the usage of the other SecAccessControlCreateFlags, except for the aforementioned kSecAccessControlBiometryCurrentSet/kSecAccessControlBiometryAny should be avoided since they do not mandatory require a biometric authentication. Indeed the device passcode could be used as well.

Conclusions

When implementing biometric authentication on mobile application it is recommended to always use solutions that relies on cryptography and secure hardware such as the Keystore for Android and the Keychain for iOS.

Event-based authentication implementation should be considered insecure since they could be easily bypassed on rooted or jailbroken devices by using hooking techniques or tools such as Frida or Objection.

Highly sensitive applications such as banking apps or financial related applications should always rely on strong implementations when using biometric authentication and they should delete the sensitive data when the biometric set is changed or completely disabled.

Finally, for sensitive applications it is also suggested to implement frameworks in order to enhance their resiliency by detecting rooted/jailbroken device or attacks that make use of hooking techniques in order to reduce the risks of being exploited.

References

Android

• https://developer.android.com/training/sign-in/biometric-auth

• https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05f-Testing-Local-Authentication.md

• https://source.android.com/security/biometric

iOS

• https://developer.apple.com/documentation/localauthentication/logging_a_user_into_your_app_with_face_id_or_touch_id

• https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

This article is the result of research through the official Android and iOS developer guides, the OWASP Mobile Security Testing Guide (https://owasp.org/www-project-mobile-security-testing-guide/) and the assessment activities on mobile applications performed by Minded Security’s consultants.

Authors

• Michele Tumolo 
• Giuseppe Porcu

Antitamper Mobile - Minded Security's Magik Quadrant for Mobile Code Protection (2018 Edition)

Minded Security's Magik Quadrant for Mobile Code Protection shows our evaluation of the top vendors in this market, based on our research and experience, updated to 2018.

Magik Quadrant

 

Why care about Code Protection?

The main reason lies in the fact that Mobile Applications runs within an environment that is not under the control of the organization producing the code.

Lack of Code Protection could have the following consequences:

• Malicious users or competitors could decompile the application and gain knowledge about proprietary algorithms or intellectual property
• Using this information, it could be possible to modify the code, repackage it and redistribute it to create a "trojanized" clone of the App
• Revenue loss due to piracy
• Reputational damage

Since 2016, the OWASP Mobile Top 10 has included two new categories related to that, that is M8-Code Tampering and M9-Reverse Engineering.

Code Tampering

Code Tampering is the process of changing a mobile app (either the compiled app or the running process) or its environment to affect its behavior.

The most common code tampering techniques are:

• Code Injection
• Binary Patching
• Local Resource Modification
• Method hooking
• Method Swizzling
• Dynamic Memory Modification  

Tools and frameworks like Frida, Substrate, Cycript, Xposed and FLEX could give an attacker direct access to process memory and important structures such as live objects instantiated by the app. 

They come with many utility functions that are useful for resolving loaded libraries, hooking methods and native functions, and more.

This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.

Code Tampering could be prevented by detecting at runtime that code has been added or changed since compile time.

Reverse Engineering

Reverse engineering a mobile app is the process of analyzing the compiled app to extract information about its source code. 

An app is said to be susceptible to reverse engineering if an attacker can derive a reasonably accurate reconstruction of the source code from the binary.

Reverse Engineering could be prevented by using an obfuscation tool that implements controls like:

• String Encryption
• Name obfuscation
• Control flow obfuscation
• Arithmetic obfuscation

Also to that, it is important to implement anti-debugging techniques and verify if the application is running on a rooted/jailbroken device.

Some commercial tools provides code protection without requiring developers to implement their own custom controls.

The remaining of this blog post is going into details about the tools available in the market in 2018.

Interpreting the Magik Quadrant

The Magik Quadrant study performed on Code Protection solutions takes into account multiple criteria based on Ability to Execute and Completeness of Vision.

Ability to Execute
Vendors must deliver strong functionality in the following areas of capability:

• Techniques implemented
• After Sale Support

Completeness of Vision
Completeness of vision in the Code Protection market considers a vendor’s vision and plans for addressing buyer needs in the future:

• Cross-platform support
• Innovation
• Sale Strategy

Before proceeding, it is worth noting that focusing on the leaders' quadrant isn't always the best choice. There are good reasons to consider market challengers. Moreover a niche player may support a specific needs better than a market leader.


Leaders
Leaders offer products and services that best cover current scenarios and are well positioned for the future. They provide solutions that are cross-platform, so with one vendor is possible to protect many platforms. Their complex solutions provide protection (through obfuscation, encryption, call hiding etc.), detection and reaction (in case an attack is detected).

Visionaries
In general, in any Magik Quadrant the Visionaries are the innovators. They understand well where the market is going and therefore they can provide innovative techniques to protect the applications in a cross-platform environment.

Niche Players
Niche Players, in our research, are vendors that do not offer, at the moment, a cross-platform solution but they are focused on a small segment. Since they are offering platform-specific solutions, in some case they are able to provide innovative and specific solutions for that specific target.

Vendor Strengths and Cautions

Arxan

This analysis pertains to Arxan's Application Protection.

Arxan is one of the most trusted names in application security. They provide protection against a widest range of static and dynamic attacks. The protection, provided by Application Protection, is implemented on different layers giving the chance to select the desired level of security.

Strengths:

• Cross-platform: Android, iOS (Objective-C and Swift applications)
• No changes to the source code 
• Protection from reverse engineering and disassembly through obfuscation
• Sophisticated Anti Code Tampering techniques
• Threat Analytics feature
• Latest OS versions supported

Cautions:

• Price could be higher than expected
• Strong binary obfuscation may interfere with the application functionalities

Company website: www.arxan.com

Inside Secure

This analysis pertains to Inside Secure Code Protection and WhiteBox.
Inside Secure is one of the leaders in the application security market. They provide a cross-platform solution based on different "modules".

Strengths:

• Cross-platform: Android, iOS (Objective-C and Swift applications)
• Strong Code and Flow obfuscation
• Anti-tampering techniques
• Strong cryptographic key protection

Cautions:

• Price could be higher than expected
• Strong binary obfuscation may interfere with the application functionalities

Company website: https://www.insidesecure.com/

Intertrust

This analysis pertains to Intertrust whiteCryption.
Intertrust is relatively new on this market but offers an innovative product that is designed to protect applications at all levels.

Strengths:

• Pioneers in Whitebox Crypto 
• Cross-platform: Android, iOS (Objective-C and Swift applications)
• Tamper Resistance
• Self-defending code
• Code obfuscation
• Anti-debugging techniques
• Cross-checking of shared libraries 

Cautions:

• Price could be higher than expected

GuardSquare

This analysis pertains to GuardSquare DexGuard and iXGuard.
GuardSquare is very famous since they develop and support ProGuard, that is the successful open source obfuscator for the Java language used for Android application. DexGuard is derived from that, while offering more advanced and sophisticated protections.
They have a great experience in Java and Android platform and recently they started offering also iOS support through the iXGuard software.

Strengths:

• Solution is solid and one of the most used thanks also to the Proguard integration in Android Studio
• Cross-platform: Android (Cordova and PhoneGap supported), iOS (Objective-C and Swift applications)
• Large adoption among our customers
• Strong code optimization and obfuscation 
• Anti-tamper detection available for the Android platform

Cautions:

• At this time iXGuard is offering only reverse engineering and not Anti-tampering protections for the iOS platform
• As demo policy seems to be changed during 2017, it's harder to obtain evaluation versions; this could be a factor to consider if you have a time-constraint project
• Price also has increased
• Solution is one of the most used so it may be easier to find deobfuscation tools/information comparing to other solutions in the market

Company website: https://www.guardsquare.com

Licel

This analysis pertains to Licel's DexProtector.
Licel is a new competitor in code protection. Its product, DexProtector, is designed for comprehensive protection of Android applications mainly against reverse engineering, clone protection and tampering.

Strengths:

• Affordable for our clients
• Strong code obfuscation
• Clone protection
• SSL Pinning support
• Root and Debug Detection

Cautions:

• Available only for the Android platform
• Some feature like Hooks Detection are additional features of the Enterprise version and priced separately

Company website: www.licelus.com

Bangcle - SecNeo

This analysis pertains to Bangcle AppShield, AppSCO and WhiteCrypto.

Strengths:

• AppShield offers protections against debuggers, tampering, decompilation and malware insertion for Android applications
• AppSCO offers reverse engineering protections (Android and iOS platform)
• WhiteCrypto offers strong key protections (Android and iOS platform)

Cautions:

• Anti Code tampering techniques are only offered for the Android platform 

Company website: http://www.bangcle.co.kr - https://www.secneo.com

Zelix

This analysis pertains to Zelix KlassMaster.
Zelix has a long story and experience in code obfuscation. Since its release in 1997, the Zelix KlassMaster Java code obfuscator has been continually developed to keep it at the forefront of obfuscation technology.
This solution provides a Java code obfuscator but it does not implement other protections such as those against code tampering attempts.

Strengths:

• Strong code and flow obfuscation
• Strong Call Hiding
• Affordable for our clients

Cautions:

• Available only for Java (Android)
• Only code protection/obfuscation

Company website: www.zelix.com

Promon

This analysis pertains to Promon SHIELD.
Promon is a Norwegian firm specializing in app hardening focusing largely on Runtime Application Self-Protection (RASP).

Strengths:

• Cross-platform: Android, iOS (Objective-C and Swift applications)
• Rooting and Jailbreak detection
• Repackaging Detection
• Protections against Runtime App Tampering
• Debugger Detection
• SSL Pinning
• Hook Detection

Cautions:

• New player in 2018 Magik Quadrant
• "RASP" acronym usually applies to solutions that protect applications from vulnerabilities at runtime, it could not fit 100% this solution

Company website: https://promon.co


Important note: it is worth noting that all these security controls do not give a guarantee that mobile applications are going to be 100% secure, but they can provide additional protection and make very hard for an attacker to carry on reverse engineering, tampering and runtime attacks.

Antitamper Mobile - Minded Security's Magik Quadrant for Mobile Code Protection

Minded Security's Magik Quadrant for Mobile Code Protection shows you our evaluation of the top vendors in this market, based on our research and experience.

Magik Quadrant

Why care about Code Protection?

There are a lot of reasons to care about Code Protection when dealing with Mobile Applications.
Every year a lot of money is lost due to piracy, intellectual property theft, cracked copyright mechanisms, tampered software, malware, and so on.

Mobile Apps are obviously installed client-side, therefore they are under the user's control.

For example, malicious users or competitors could decompile the application and analyse the result.
This could reveal valuable data as proprietary algorithms or intellectual property or allow the attackers to use that information to modify the code, repackage and redistribute it to create a "trojanized" clone of the App in a rapid fashion.

Moreover, if the App needs to run on untrusted devices, any malware could interact with the App at runtime level to steal data (credentials, credit card number etc.) or bypass security logic (local authentication, geo-restrictions, custom cryptography etc.).
As you can see a mobile App could be attacked at various layers and with very different goals in mind, creating a very complex problem for those who want to protect their products.
The following diagram shows some of the main attack types.

Why Apps reverse-engineering and tampering are easy?

Many developers do not know how easy mobile application reverse-engineering and tampering are. 

Since mobile Apps reside on user's devices and include valuable data inside  -  metadata, resources and even the code itself -, attackers could gather important information just by using publicly available tools.

In fact, according to the OWASP Top 10 Mobile Risks 2014,

“...it is extremely common for apps to be deployed without binary protection. The prevalence has been studied by a large number of security vendors, analysts and researchers.”

Without protections, it is quite easy to decompile an App to analyse its code (particularly on the Android platform) or to interact with it at runtime level on rooted/jailbroken devices.

How to make it harder?

To make the life harder to the attackers and help protecting valuable data, developers should:

• Harden DRM systems and licensing modules
• Reduce piracy
• Protect intellectual property and personal data
• Secure proprietary algorithms against analysis and reverse engineering
• Harden firmware and OS
• Protect cryptographic keys
• Protect the client side of encrypted communication
• Prevent malware intrusion

Therefore they have to deploy mobile applications with some kind of protection. To do this they could implement the following techniques:

• Code and Flow Obfuscation
• String and Class Encryption
• Debug code stripping
• Method Call Hiding (Reflection)
• Resource Encryption
• Debug Detection
• Root/Jailbreak Detection
• Runtime Injection Detection (Swizzle/Hook Detection)
• Tamper Detection
• Certificate Pinning
• Watermarking

There are many technical resources on Internet that describe at some level of detail how to implement one or more of the preceding techniques.
Moreover, there is some commercial tool which provides binary protection without requiring developers to implement their own custom controls.

Before going into detail about these tools it is worth noting that all these security controls do not give a guarantee that mobile applications are going to be 100% secure, but they can provide additional protection and make very hard to carry on reverse engineering, tampering and runtime attacks.

Interpreting the Magik Quadrant

The Magik Quadrant study performed on Code Protection solutions takes into account multiple criteria based on:

• Ability to Execute
• Completeness of Vision

Ability to Execute

Vendors must deliver strong functionality in the following areas of capability:

• Techniques implemented 
• After Sale Support

Completeness of Vision

Completeness of vision in the Code Protection market considers a vendor’s vision and plans for addressing buyer needs in the future.

• Cross-platform support
• Innovation
• Sale Strategy

Before proceeding it is worth noting that focusing on the leaders' quadrant isn't always the best choice. There are good reasons to consider market challengers. Moreover a niche player may support a specific needs better than a market leader.

Leaders

Leaders offer products and services that best cover current scenarios and are well positioned for tomorrow. They provide solutions that are cross-platform, and therefore with one vendor it is possible to protect many platforms.

Their complex solutions provide protection (through obfuscation, encryption, call hiding etc.), detection and reaction (in case an attack is detected).

Visionaries

In general, in any Magic Quadrant the Visionaries are the innovators. They understand well where the market is going and therefore they can provide innovative techniques to protect Apps in a cross-platform environment.

Niche Players

Niche Players, in our research, are vendors that do not offer, at the moment, a cross-platform solution but they are focused on a small segment.

Since they are offering platform-specific solutions, in some case they are able to provide innovative and specific solutions for that particular target.

Free and Open Source Solutions

The preceding analysis was done on commercial tools available on market.
In addition to this, we have also analyzed a free and open source solutions available for iOS: iMAS.
This solution has the main disadvantage that, since it is free and open source, it does not guarantee support. Nevertheless, we want to spend some words about it since it has some interesting features.

Vendor Strengths and Cautions

Arxan

This analysis pertains to Arxan's GuardIT.
Arxan is one of the most trusted names in application security. They provide protection against a widest range of static and dynamic attacks. The protection, provided by GuardIT, is implemented on different layers giving  the chance to select the desired level of security.

Strengths

• Cross-platform (Android, iOS, Windos Phone)
• Strong code protection
• Strong detection
• Capability to repair after damage

Cautions

• Price could be higher than expected

Company website: www.arxan.com

Metaforic

This analysis pertains to Metaforic Core, Authenticator, Concealer and WhiteBox.
Metaforic is one of the leaders in the application security market. They provide a cross-platform solution based on different "modules" (Core, Authenticator, Concealer and WhiteBox).

Strengths

• Cross-platform (Android, iOS)
• Strong Code and Flow obfuscation
• Strong cryptographic key protection

Cautions

• Price could be higher than expected

Company website: www.metaforic.com

WhiteCryption

This analysis pertains to whiteCryption's Cryptanium.
WhiteCryption provides code protection solutions since 2009, so they are relatively new on this market compared to Arxan or Metaforic. However they offer an innovative product that is designed to protect applications at all levels.

Strengths

• Cross-platform (Android, iOS)
• Strong Code and Flow Obfuscation
• Strong anti-tampering protection
• Anti-debug and anti-piracy features

Cautions

• White-box cryptography techniques are still adopted very little

Company website: www.whitecryption.com

PreEmptive

This analysis pertains to DashO and .NET Obfuscator.
The first version of DashO was released in 1998 and .NET Obfuscator was initially released few years later. Therefore PreEmptive has a long experience in Code protection.

Strengths

• Cross-platform (Android and Windows Phone)
• Strong code and flow obfuscation
• Watermarking
• Tamper prevention and reaction

Cautions

• No iOS support

Company website: www.preemptive.com

GuardSquare - Saikoa

This analysis pertains to DexGuard.
GuardSquare is very famous since they develop and support ProGuard, that is the successful open source obfuscator for the Java language. DexGuard is derived from it.
They have a great experience in Java and Android platform.

Strengths

• Large adoption among our customers
• Strong code optimization and obfuscation 
• Anti-tamper detection

Cautions

• Available only for Android

Company website: www.saikoa.com

Licel

This analysis pertains to Licel's DexProtector.
Licel is a new competitor in code protection. Its product, DexProtector, is designed for comprehensive protection of Android-applications against reverse engineering and tampering.

Strengths

• Affordable for our clients
• Strong code obfuscation
• Anti-tamper detection

Cautions

• Available only for Android

Company website: www.licelus.com

Bangcle - SecNeo

This analysis pertains to AppShield service. Bangcle provides a service that permits to developers to upload its APK on Bangcle's server and they provide fully automated App shield services. The whole process takes about one hour or less to complete.

Strengths

• Very simple use
• Anti-debug and Anti-tamper features
• App Data Encryption

Cautions

• Available only for Android

Company website: www.secneo.com

Smardec

This analysis pertains to Smardec's Allatori.
Smardec's main goal is to offer you high quality services and products at a reasonable price. Allatori first version was released in 2006 and it has reached these goals.

Strengths

• Strong code and flow obfuscation
• Watermarking
• StackTrace restoring

Cautions

• Available only for Android
• Only code protection/obfuscation   

Company website: www.smardec.com

Zelix

This analysis pertains to Zelix KlassMaster.
Zelix has a long story and experience in code obfuscation. Since its release in 1997, the Zelix KlassMaster Java code obfuscator has been continually developed to keep it at the forefront of obfuscation technology.
This solution provides a Java code obfuscator but it does not implement other protections such as those against tampering tries.

Strengths

• Strong code and flow obfuscation
• Strong Call Hiding
• Affordable for our clients

Cautions

• Available only for Java (Android)
• Only code protection/obfuscation

Company website: www.zelix.com

iMAS

This analysis pertains to iMAS.
This solution is free and open source, available on GitHub, and it provides modularity as the main feature. In particular the iMAS project is composed of many components that developers could include inside their project and every module provides a different feature. So it is up to the developers selecting the desired components and include them in the project.

Strengths

• Free
• Anti-tampering protections
• Code encryption

Cautions

• Available only for iOS
• No after sale support

Company website: project-imas.github.io