The mobile world today is largely divided into two worlds:  Apple and Android.  While their approach to many things may be different, they do share a common approach to security — think layer cake.  Yes, the one thing that seems to matter most in making a great cake is layers.   Just like your security posture.  Layers add depth, and the more the better.

Three Layer Cake

For Apple, the iPhone has (at least) three layers:  1) Applications; 2) iOS kernel; and 3) an added security chip.  The security chip is unique to Apple, which is a very good thing. However, don’t be misled as it only performs one core function.  The security chip is used for isolating the encryption keys and the use of those keys from the other layers.  The code in the security chip is small, which makes it easy to analyse, thereby validating its integrity.  Thinking in terms of layers, there is the iOS kernel, which focuses on isolating the application leveraging standard approaches to security at this layer.

When you look at Android’s approach, the end point devices don’t historically have a fixed security architecture.  This enables diversity and innovation that allow the chipset vendors do many different things.  However, on a typical ARM-based Android device you will find three security layers:  1) Applications; 2) Linux Kernel; and 3) TrustZone.  The first two layers are very similar to Apple’s approach at a conceptual level.  However, TrustZone is very different to the added Apple security chip.

TrustZone itself can be considered an Operating System (OS) of sorts along with its own inherent internal security separation.  This internal security separation is commonly referred to as a Trusted Execution Environment (TEE), or sometimes as a Secure Payload (SP), and even as Trusted Apps (TA).  TrustZone is where most Android devices keep their encryption keys (i.e. the crown jewels), and it implements the same key use functions that the Apple security chip does.

The huge difference between Apple and Android is the very different security profile of this configuration by Android.  TrustZone shares the same CPU with the Android OS, which leaves it vulnerable to side-channel attacks (i.e. Spectre, DDR Rowhammer, etc.)  TrustZone also has a much larger attack surface than a dedicated security chip.  To add to the risk for TrustZone is that third-party software (TAs) can be loaded and then leveraged to present an even larger attack surface.  Though the TA is supposed to be isolated from the TEE, this new larger attack surface, if compromised, can give the attacker new avenues to attack the TEE and its critical encryption key handling software.  Though, it is not my intent to provide a path forward for malevolent behaviour, there is precedent for successful attacks that lead to the extraction of the encryption keys from TrustZone.

Google has not stood idle. They have updated their security APIs to *require* the keys to be separated from the Kernel (i.e. using TrustZone or elsewhere), but it still only puts the onus for security on Android devices on TrustZone, which does have its issues as stated earlier.

Four Layer Cake

Qualcomm has recognized the danger, and now offers a similar security chip, the Secure Processing Unit (SPU), for the latest devices that performs the same functions as Apple’s security chip.  This does not mean that Android has achieved parity with Apple, but if you are using a Qualcomm-based Android device you now have four layers (apps, kernel, TZ, security chip) of security – which stands up as a much better security posture.

Five Layer Cake

Today, Cog’s security and virtualization APIs are available in select QualComm Snapdragon mobile platforms, including the recently launched Snapdragon 855. This will enable connected devices, such as Android phones and IoT devices, to access Cog’s virtualization based modular security technology, known as D4 Secure.

Given the above, Cog’s value-add vis a vis virtualization is a bit more nuanced, but very much relevant.

• Firstly, TrustZone is not a friendly place to write apps. TA’s have many restrictions and can’t operate as applications in the usual sense – like an Application on the OS.
• Second, virtualization solves this, as it provides the ability to add additional virtual machines that can be enabled to run anything from small to very large applications, and even whole operating systems. All of which are running in their own little worlds provided by the hypervisor.
• Third, many of the things that are being put into TrustZone today would be better suited to run in a virtual machine. Virtualization provides a richer and more flexible environment that makes it much simpler to develop isolated components by putting them into virtual machines, where those components would have far fewer restrictions and greater capability.  Plus, the risk of a hacked component has much less impact on the security within the rest of the system.
• Fourth, there are other benefits of virtualization, such as the ability to have more oversight on what’s going within each virtual machine and potentially detecting issues in the other virtual machines. A new capability is opened for applications that currently reside in Android due to lack of access to, or the unsuitability of the TrustZone environment, to be run within a VM.
• Fifth, the Cog on Qualcomm solution offers five full layers of security that will just work right out of the box.

Let Them Eat Cake

In summary, if you want to make an even bigger leap to your defence in depth – adding virtualization is akin to adding another layer to your protection profile.  Virtualization offers greater flexibility, improved security, better architecture for secure application development, and new opportunities to move software that currently run (due to no viable alternative) as Apps on the Android system into their own isolated virtual machines.  There’s no reason to be satisfied with just three layers – Cog can help you get greater depth in your defence, regardless of your OS of choice.