Why Existing Mobile Software Protections are Insufficient

In August 2018, Security researchers from Kryptowire, a security firm, found 38 different vulnerabilities loaded onto 25 Android phones, including devices from Asus, ZTE, LG and the Essential Phone, which are used by global consumers.The vulnerabilities range in severity, but some of the worst ones would allow an attacker to remotely record screens, log keystrokes, or steal private information by getting the victim to download malware.It should be shocking when a phone lands in consumers’ hands with this level of security flaw. As an industry, software security can do so much more to protect consumers, and the fact that faulty mobile security is showing up in the latest releases of phones is a great example of why this is so problematic.

The fault doesn’t rest squarely on the shoulders of the mobile manufacturers, though. Banks, governments and other trusted mobile application providers need to step up their game. This is especially so for banks, where vulnerabilities in the SWIFT network and the fact that banks are continually assaulted by sophisticated cyber crime can often mean the loss of millions of customers’ money – costing as much as US$1 million per incident.

More recently, with exploitation of text messages by cyberthieves undermining confidence around two-factor authentication, there is a clear urgency to increase efforts to work in parallel with mobile security providers to restore public confidence in delivering services over mobile applications.

What’s out there now, and why it’s not working:

Currently, there are three main types of software protection. Though they vary in effectiveness and all offer some benefits, none are as successful as we need.

1. Code obfuscation

For decades—since well before mobile—the tech industry has been trying to secure software applications from users who have access to their binary executable files, but do not want them to be able to perform reverse engineering or modify them. The traditional way of preventing code from being understood or modified is code obfuscation. All applications, no matter what language they are written in, eventually get compiled into machine instructions, which a processor reads.

A simple obfuscation approach is to change function names into random-looking names, in the hope of making it difficult for the attacker to figure out what each function does. But this only slows down the attacker a bit as the code structure is still intact. Code can be further obfuscated by taking a single instruction and separate it into many different instructions so that an attacker has to read and reverse-engineer these operations in order to figure out how to compromise them. A coder might also transform the operations by simply transforming a computation into something that is equivalent mathematically but difficult to understand, so that an attacker has to untangle what is happening to find the original intent of the code.

One problem is that doing this slows down applications. Especially in consumer-facing applications, a user expects a fast interface. They might be willing to wait for one second, but they’re not willing to wait for 10. If every instruction is obfuscated into 100 instructions, the operation will also be 100 times slower, and that’s untenable for a consumer-facing application where experience is paramount. Companies address this problem by obfuscating only the most vital pieces of code so the rest of the application is unaffected.

Often, though a company could make their code 100 times more secure, they will instead make it 10 times more secure, creating a balance between security and interface.

Even so, making something only 10 times more secure isn’t enough. If it would take an attacker one hour to break an unobfuscated code, it would only take them 10 hours—barely a day’s work—to break code that is made 10 times bigger through obfuscation. Obfuscation buys you time but doesn’t fix the underlying issues.

2. Runtime Application Self-Protection (RASP) and App Shielding

RASP or App Shielding involve putting pieces of code inside an application to detect if the application is being traced or tampered with by an attacker. Like code obfuscation, this has been a common software security strategy since pre-mobile days—most of the research and progress in the field came from web application protection, but is now common in mobile security protection. In essence, RASP watches for attacks and vulnerability exploitations, allowing the application to protect itself.

Often, RASPs are reverse engineered to identify how the threat response mechanisms are implemented. The problem here, though, is that most skilled reverse engineers would be able to bypass security protections within a short time frame by identifying where they are in the code. In the same way that code obfuscation can only hold back attackers for a limited amount of time, most RASP implementations also fail.

3. White-box cryptography

White-box cryptography is newer, relative to other protections. In this type of cryptography, a key is “dissolved” into a much larger code base. This effectively embeds the key into the code but the key itself “disappears”. Immediately, this demonstrates the first problem: white-box cryptography results in a large executable binary.

Size aside, it also doesn’t equate to perfect protection. Although it’s more secure in terms of being able to hide the key, it’s still not un-hackable. In cryptography, it doesn’t matter how well the key is secured and it doesn’t matter what the code is—if the device is compromised and the attacker can call the piece of code that performs the decryption, then white-box cryptography is effectively useless in protecting a user’s key from being used. If all you want to achieve is the confidentiality of keys, then white-box cryptography is a feasible solution. But for more complicated processes, like confidentiality of encrypted data and user attestation, it is not a secure answer.

Essentially, white-box crypto doesn’t provide any more protection than what we see with isolated hardware: it’s a very fancy way to keep keys secure, but in much the same ways that hardware is, meaning it only works until the the application that uses it is compromised, at which point it becomes useless. White-box cryptography is vulnerable to attacks and doesn’t provide the integrated security that is needed in the mobile ecosystem.

What’s the solution?

Fundamentally, all of these protections are a great place to start—but they simply don’t hold attackers back for long enough.

There is a range of security solutions that claim to solve the security problems for enterprise networks, but the simple fact is, they don’t. As an industry, we’ve taken a step back and decided that what is out there now is good enough. But, as we’ve seen, each of these security protections provides, at most, a few weeks’ delay. Every year, security practitioners go into the marketplace and try to find the top solutions that are the best and most current, but none provide true protection.

Rather than compromising, we need to develop permanent solutions to the fundamental flaws in digital software security. We need to think beyond old solutions imported from the pre-mobile world to create new, innovative software solutions specifically for mobile. We need to look past what’s buzzy or trendy to choose those new solutions that will provide lasting change. If we do all these things, we’ll finally be able to reject a status quo where “best-in-class” mobile security solutions only delay an attacker’s success instead of preventing it. Finally, we’ll have mobile apps that are actually secure.

With contribution from the Hippo Thinks research network.

Stay tuned for the next article in this series and follow us on LinkedIn and Facebook for more updates.