Mobile Banking Application Protection: Challenges and Techniques

As the use of mobile phones for mobile banking and payment applications increases, so too do the security threats. Most smartphones use only two operating systems, Android and iOS, and they represent the prey of choice for criminal groups and malevolent hackers. 

In this article, we will delve deeper into the challenges associated with mobile banking application protection and outline several security techniques you can use to protect your customers.

Techniques Criminal Groups Use to Target Mobile Banking

Most attackers target mobile banking applications to initiate fraudulent transactions for financial gain and/or to steal confidential data. Due to the high potential payoff, criminal hackers have a wide range of techniques at their disposal when targeting mobile banking applications, including:

• Reversing the legitimate banking application by decompiling it and using debugging tools.
• Creating fake apps that “mimic” legitimate apps and offer the app online, eventually including “legitimate” distribution channels.
• Creating SSL proxy or spying communications between mobile phone and bank servers and/or 3rd party API servers, using protocol analyzers to capture data.
• Injecting trojans or other viruses into mobile devices, either remotely or physically (“rogue repair shop” for instance).

Effective mobile banking application protection requires numerous mutually reinforcing security layers and mechanisms within the app.

Security Layers and Techniques to Efficiently Protect Banking Applications 

Secure Connectivity 

The communication between the app and the back-end server must be secure to protect the data being sent and to ensure the app only communicates with the intended system. Securing communications can involve several mechanisms, including protection for access tokens and cookies, encrypted transport protection (HTTPS) and HTTPS tunneling, and additional assurance mechanisms to authenticate both the mobile device and the back-end system.

Application Hardening

Application hardening mechanisms should be employed to make the app difficult to attack or modify. This includes obfuscating the source code of the application and especially, the relevant data and constants that are used to connect to servers. Methods to detect app tampering attempts, especially by debuggers, simulators, and emulators should be considered. Malevolent physical access to the device and app should also be prevented. Finally, this security layer should be able to detect the rooting or jailbreaking of the device and respond accordingly.

Secure Storage and Key Protection 

The app must be able to efficiently protect the various cryptographic keys by preventing their possible recovery by an attacker. Usage of secure storage, such as using a secure element or SIM card, should also be offered if possible. Otherwise, this can be achieved with dedicated obfuscation methods.

Sentinels for Runtime Application Self-Protection (RASP)

Runtime application self-protection should use a sentinel framework, meaning having software “sensors” that stay awake to monitor all parameters. The sentinel(s) should be able to detect and react to attempts to attack the app. Proactive defensive actions should be taken by the sentinels in case an attack is detected. Possible actions could be the blocking of individual requests, voluntary crashing of the mobile application, reporting the activity to the back-end server, etc.

The sentinels should not be detectable by an attacker and should be protected from being deactivated, incapacitated, or removed. Threats against the sentinels themselves should also be detected and acted upon. 

Device Fingerprinting

The app should be able to compute the device hardware signature to uniquely and securely identify devices to remote servers. This can, of course, involve the International Mobile Equipment Identity (IMEI) or any physical unclonable function (PUF) present on the device. 

PKI

The app could use public key infrastructure (PKI) to check the legitimacy of banking applications and eventually, other applications. This could work to address the lack of security of Google’s official distribution channel (Google Play), which allows the downloading of insecure and unverified software for Android. PKCS mechanisms could also be used to enforce mobile banking security.

User Authentication

Strong user authentication such as biometric authentication and identification must be supported. 

Auto-updates

The app security layers and mechanisms should be updated periodically. Newly discovered vulnerabilities should be efficiently addressed by the security developers, and patches should be created and released as soon as possible. Of course, the auto-update must be totally bulletproof to prevent attackers from using the mechanism to update modified versions.

Development and Integration Challenges

The security mechanisms described above must be “lightweight” and smart. They should in no way hinder the development of the mobile banking application, but ease it.

The developers of the app security must stay reactive to the development of new mobile banking attacks.

They should have 24/7 support and even a 24/7 responsive “answer team” with the ability to develop rapid patches in the event of zero-day exploits, for instance. 

The architecture your security layers should be modular. This will ensure it can adapt to new attack techniques and unknown threats.

Why Work with a Specialist Security Vendor?

Many banking app providers look to security vendors to provide the necessary layers of protection, instead of developing them in-house.

Outsourcing security-sensitive aspects of mobile banking application protection enables developers to focus on delivering the most user-friendly business apps while leaving the critical security-related parts to the specialists.

Mobile banking app security is diverse. From as-a-service models to API and SDK-based offerings, you can always find a solution that meets your needs.

References and Further Reading

• Read more articles about Runtime Application Self-Protection (RASP) for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more