In one of our first posts, we dove into the basic background of containers, virtualisation and sandboxes. We covered how these are three of the most common terms used when talking about general computer security and mobile security, with all three being used to protect mobile applications. But what more can we learn? Let’s take a deeper look.

Virtualisation provides an abstraction over the physical hardware layer for an Operating System (OS). This abstraction allows any OS to run other OSes as guests on the same hardware. This abstraction also provides a separate environment for an application. While you can share files and peripheral devices between the main and guest OS, the guest OS will mostly be isolated from the main OS. In other words, users created on the guest OS and applications installed on the guest OS will not be available on the main OS. This flexibility of abstracting the hardware makes its possible to run more than one guest OS using the same hardware. 

In addition, it allows us to take and store snapshots of the guest OS operation at any point in time when in similar environments also running the virtualisation software. Doing so makes the deployment of software and its dependencies far more manageable than installing all of them manually on many physical devices. One can also efficiently run different applications built for other OSes on a singular OS, regardless of the version or type of main OS. In this scenario, an application running in guest OS A cannot interfere with an application running on guest OS B

The term sandbox refers to an environment that has been created for the sole purpose of providing a safe place for testing, auditing, or analysing without interference from other similar production environments. This form of isolation - or sandboxing - is most common on server deployments. A typical example of this is the Apple push notification service sandbox. 

On the other hand, the term sandbox could also refer to an isolated process running in an OS environment, shielded from other processes running in the same OS. When I say "shielded", I mean that process B cannot interfere with process A's execution and allocated resources or even communicate with process A without going through the device's OS/kernel. This form of isolation on the OS level can be called "process sandboxing".

I have now outlined some common ways to isolate software and application processes from one another. But did you know that the benefit of securely isolating an unrelated aspect of a software process from others has had a significant impact on the quality of software one can develop? The following paragraphs will outline some of the benefits of the sandboxing and isolation technique. Let's start by looking at how the Android OS uses the process-sandbox technique to provide a proper isolation environment for installed applications. 

Before an application can use a resource on a mobile device, the application would need to ask for permission from the user. The OS then needs to keep track of all the permissions that have been granted to only that application. One of the ways that the OS ensures that application A cannot use the permissions granted to application B when it comes to accessing a device resource is by using a process sandbox. 

On the sandbox level, every application process is isolated from each other. As a result, permissions can be granted and revoked on an application without affecting other installed applications, providing a basic security layer.

We can also use sandboxes to test new configurations and security models because sandbox deployments are similar to deployed production systems. The advantage of this is being able to test new features and configuration settings. Additionally, during a security audit or analysis, sandboxes provide a clone environment of the production server where basic and advanced penetration tests can be done to verify the security level of the deployed solution.

Mobile attacks are often designed to target vulnerabilities in OSes. For example, one of the most popular attacks is privilege escalation. Here, attackers gain root access on a user's device, bypassing the application process sandbox to access the device resource (such as the camera) without asking for the required permission. 

There have also been other cases where malware has been known to bypass the application sandbox to simulate a click event, whether on banking applications to approve transactions or transfer funds. This kind of attack can be organised and orchestrated at scale, leading to the loss of vast amounts of funds.

Because of these kinds of attacks, isolated or secure environments play a vital role in SCA. A secure environment creates a safe place for code execution, ensuring the transaction data is tamper-resistant from unknown sources, such as malware processes that tend to target these kinds of transactions.

In article 22 of the European Commission's Regulatory Technical Standards (RTS), there is a general requirement that "payment service providers shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Chapter II take place in secure environments, in accordance with strong and widely recognised industry standards." The requirement of using a secure environment would also be valid for smartphones, where end-users enter their credentials to access their banking app. 

The obvious question that follows from this requirement is: when is a secure environment secure enough if it runs on a customer's device? From a computer security researcher perspective, the only secure environment is one that's turned off and located in a safe on the bottom of the ocean. But because that is impossible, we've tried a more practical approach by creating a secure execution environment in the software already running on your device, which is why it's essential to keep your software updated!

To read more about the Okay product and how it creates a secure execution environment, be sure to head on over to our product page.