Don’t Rely on the OS hero graphic

Don’t Rely on the OS

Posted On

By Paul Butterworth


Modern operating systems are complex, large and subject to continual attacks. It’s estimated that the Android operating system contains between 12-15 million lines of code; with that comes a vast potential for weaknesses that hackers try to exploit. Which is why the “StrandHogg” vulnerability is only the latest in a string of high-profile Android exploits over the past months, including one giving an attacker full control of smartphone camera apps

iOS Vulnerable Too

Generally, Apple’s iOS is believed to be more secure than Android as it doesn’t use open source code, but this reputation may be ill deserved. In reality, the market dominance of Android, which has an estimated 87% global market share compared to Apple’s 13%, makes it a much more attractive target for hackers. That’s the downside of having such a successful platform. However, being a smaller target does not fully mitigate security risks, as evidenced by the iPhone hacking campaign revealed in August that exploited fourteen different iOS vulnerabilities over a two-year period. 

Device Built-in Protections

To help protect applications, mobile operating systems provide a number of tools and in-built security services, like the Android keystore or the Apple Secure Enclave. Both of these services let applications create cryptographic keys and provide an API that allows applications to perform cryptographic operations using those keys. Although the keys can be used to perform functions such as encrypt, decrypt and sign, they cannot be exported from these systems, keeping them safe from extraction. These services are also designed to keep the keys secure and protected from attack by other applications. The services are usually built using a hardware-backed mechanism, typically a Trusted Execution Environment (TEE). A TEE is a hardware isolated minimal operating system, running alongside the normal operating system, which delivers cryptographic functions and protects the keys from attack by other applications running on the device. In normal operations, running your security services inside a TEE should provide adequate protection.

In addition to the key storage and cryptographic functions, most operating systems provide some sort of application isolation functionality. Application isolation helps prevent apps from getting access to view or modify another application’s code or data. Isolation should also prevent an application from identifying if another specific application is installed onto the device, thus reducing threats even further.

Jailbroken/Rooted Devices

In an ideal world, these services should deliver all the capability and security features you need to keep your apps, their keys and data, and your IP safe. However, many users jailbreak or root their devices to bypass operating system restrictions and take full control of the device. Jailbreaking is the term used for rooting on iOS devices. Throughout this blog when I refer to rooting or rooted devices, I’m including iOS jailbroken devices also.  People don’t only root devices for malicious intent, it’s often to perform something mundane like customizing the user interface. In most cases, it’s done without users being aware of the potential risky side effects. Once a device has these operating system restrictions removed, it is possible to launch attacks to potentially bypass security controls. By intercepting all API calls to the security subsystem, or launching illicit calls, attackers can gain important insight into the security. They can also gain key access to sign messages, decrypt data, or otherwise attack the system. By rooting the device, the application isolation features are also removed; all files and data managed by all applications installed are now vulnerable. 

Protecting Your App

Given the challenges, what can be done to protect your apps? One option is to try to detect if a phone is rooted, and to terminate the application if it is. Various tools  can help you accomplish that, but do you really want to exclude everyone who chooses to root their device from running your apps? Another option is to detect the rooting and make a risk management decision as to how that affects your application. You may, for example, choose to request that the user provides a second level of authentication before performing sensitive functions if the app is running on a rooted device. 

To further reduce the risk, but still allow execution, it’s recommended that you don’t rely on system security services that become weakened if the device is rooted. Instead, build security directly into your application. Employ whitebox cryptography to perform standard cryptographic functions while ensuring that the keys are never exposed in the clear, even when in use. Whitebox cryptographic libraries provide a trustworthy place to perform cryptographic operations, with no reliance on any specific hardware features. In addition, you can use application shielding tools, which enable your apps to protect themselves from reverse engineering or tampering by detecting debugging or modifications and enabling the app to take defensive action should any threats be detected.

Don’t Be Complacent

Take your application security seriously, and be aware that your applications will get reverse engineered, and will become installed on rooted devices. Relying on the operating systems to provide sufficient security to protect your apps, keys, secrets, and customer data is no longer adequate.

Download this white paper to learn more about application shielding techniques and how Intertrust can help you build properly protected applications.

Paul Butterworth

About Paul Butterworth

Paul Butterworth is an experienced payment and security professional, having spent almost 30 years in the card, payments and IT security industries. Paul is responsible for global product marketing for the Intertrust Secure Systems’ market leading application shielding and device identity solutions.