The more sensitive that our digital transactions and operations have become, the more it makes sense for us to think of the mobile ecosystem as being split into two worlds:
The trusted world, and the untrusted world.
In a recent talk about Trusted Applications and Trusted Execution Environments, our co-founder and CTO, Mikhail Dudarev, spoke about the concept of Trusted Execution. For something to be trusted, he said, means embracing isolation; removing the influence of the external world towards a component.
That is what a Trusted Application and Trusted Execution Environment can help you to achieve.
In this article, we’ll explain how.
Defining a Trusted Application
The digital world is anything but simple, of course. In the next breath of his talk, Mikhail also acknowledged that it can be quite limiting to not be able to communicate with the external, untrusted world.
We’ll explain the solution to this conundrum shortly. But first, let’s attempt to answer the question posed in the title of this article: what is a Trusted Application?
A Trusted Application is a specialized app that is designed to run within a Trusted Execution Environment (TEE). It exists to handle sensitive cryptographic operations such as encryption, decryption, hashing, signing, authentication, and secure storage. And it provides an extra layer of protection by running in an isolated and secure environment.
A Trusted Application is a specialized app that is designed to run within a Trusted Execution Environment (TEE). It exists to handle sensitive cryptographic operations such as encryption, decryption, hashing, signing, authentication, and secure storage. And it provides an extra layer of protection by running in an isolated and secure environment.
A Trusted Application is part of the trusted world concept that Mikhail was talking about; and indeed the wider concept of Trusted Execution. The main idea of this concept is to separate the execution environment between the trusted and untrusted worlds. Its goal is to bring security to untrusted devices.
In the image above you’ll see that either side of the Platform Hardware lie our two worlds. There’s the untrusted world, with its Rich OS and Client Application(s) operating within a Rich Execution Environment; and then there’s the trusted world, with its Trusted OS and Trusted Application(s) operating within a Trusted Execution Environment.
So, in the trusted world you have a Trusted Application that implements some sensitive code from within a safe and secure environment where this app can run. You also have the API (TEE API) which allows the application to communicate with the external world. This is a large part of the answer to the conundrum we referenced earlier.
This process aligns with the main characteristics of a TEE and, by association, of a Trusted Application:
The first one – which we’ve already covered – is isolation. Then there’s confidentiality; we want to prevent data that is owned by one Trusted Application from being obtained by another application. This is important because another key objective here is integrity – making sure that the Trusted Application has not been tampered with or modified and, also, making sure that the whole environment around the app is safe. Another characteristic of Trusted Applications and TEEs is secure execution. The idea here is that nobody be allowed to interfere with the app’s processes or carry out a side channel attack in order to understand what is happening inside the execution process. Without this secure execution, attackers could identify the sensitive logic of an application and extract private keys from the memory. Finally, there’s controlled access, which means that each Trusted Application only has access to its own resources and not those of other applications.
Hopefully these characteristics are already clarifying in your mind why a Trusted Application and TEE might be helpful. Particularly for verticals where applications are carrying out incredibly sensitive transactions or operations. After all, a Trusted Application might work with some critical business logic, or it might implement IP algorithms that need to be worked on in isolation. Think about mobile wallet solutions, for example, or SoftPOS solutions that enable vendors to accept payments on a mobile device.
Organizations in these sectors are already using our own virtual TEE solution (we’ll explain more about this later) to create and run Trusted Applications.
What level of Trusted Execution do you need?
The concept of TEEs has been around for longer than you think.
The first example of a Trusted Execution Environment is arguably Java Card. It was created in 1997 with the idea of ensuring an app firewall for hardware devices. If you still own a DVD player, take a look at the back of it and you’ll probably see a Java logo.
These days, Java Cards are in all of our phones because smart cards, e-sims, and bank cards all use Java Card technology. You might not think about it very often, but in the second that it takes for you to place your mobile device in the electromagnetic field and make a payment using an NFC terminal, a lot of magic happens. The Java operating system powers up and a special Java Card Applet (Trusted Application) is selected, which performs some security operations and returns a signed cryptogram to the payment server for processing.
Until recently, a TEE was almost always a hardware solution. And there are three main ways that TEE architecture can be implemented with hardware:
The most secure - but least used (because it’s expensive) - is using an external secure element like a SIM card to perform a sensitive operation. Another variant is when a TEE is embedded as a chip on your phone and shares some memory to communicate with your application or some Kernel drivers. The third way that TEE architecture can be implemented with hardware (and the most common in practice) is when a TEE is implemented directly on the processor. This could be either via ARM TrustZone or Intel Virtualization. If we take the former as an example, then a special register in an ARM processor is used to switch each operation and tell the processor exactly whether the operation is happening in the trusted world or the untrusted world.
These TEE implementations exist to solve a persistent challenge for mobile app developers; how to work with cryptographic operations and keys in a secure way. Imagine if some secret keys were stolen from your device and then used by attackers on another device to access banking systems or other sensitive operations, for example.
It was in response to critical challenges like this that Google initially released the Android Hardware Keystore, where they guaranteed that all operations involving secret keys would take place in an isolated environment, albeit stopping short of guaranteeing security. Then, from Android 9, Google introduced StrongBox.
Android StrongBox uses the second TEE implementation variant (with a separate chip) that we covered above. It operates in the secure, trusted world, with a TEE on a chip, and a Trusted Application called Keymaster which operates with cryptographic keys. Then there’s a layer that communicates from the client application to the trusted world.
So, is StrongBox strong enough?
If you choose a cipher and encrypt some bytes using this cipher (as with the code example below), then Android StrongBox guarantees that these keys can’t be extracted from the trusted execution element. The only public thing that might be exposed is plainBytes, but that isn’t concerning here. We care more about encrypted bytes.
In this example we can be satisfied that StrongBox is strong enough.
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] encryptedBytes = cipher.doFinal(plainBytes);
key is never exposed outside
plainBytes could be exposedHowever, if we add two simple lines of code and make the encryption process slightly less straightforward, or if we want to decrypt data and then re-encrypt it using a different key, then enough has changed here from an application security perspective. In the code example below, we’re less sure about the strength of Android StrongBox.
// decrypt data
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, decyptionKey);
byte[] decryptedBytes = cipher.doFinal(encryptedBytes);
// re-encrypt data
cipher.init(Cipher.ENCRYPT_MODE, encryptionKey);
byte[] reencryptedBytes = cipher.doFinal(decryptedBytes);
decyptionKey, encryptionKey is never exposed outside
sensitive decryptedBytes could be exposedYou see, when we re-encrypt data, we’ve decrypted bytes in the application memory. And when these decrypted bytes are transferred from secure elements through different interfaces to application memory, they can be hooked and dumped millions of times using simple debuggers like Frida. An attacker could obtain this data and influence your application processes.
In conclusion, then, StrongBox is strong enough to secure some primitive cryptographic operations. But when it comes to protecting sensitive cryptographic algorithms, it isn’t strong enough.
Keep in mind, too, that the example above is a fairly simple one. If you imagine some complex payment schemes where you need to make transactions, then the situation is even more complicated and you risk completely losing control of the execution of your code.
Enhanced security with Virtual Trusted Execution Environments
The example above highlights that traditional TEEs come with some limitations. Not all cryptographic algorithms are supported, and it’s a closed platform which means you can’t extend to or create new Trusted Applications.
Hardware TEEs also tend to be vendor locked. Each vendor – Google, Apple, or Samsung, for example – have their own implementations and different limitations. And this can make things pretty complicated.
There are also performance issues to consider with legacy TEEs. If we’re talking about the third type of architecture (ARM TrustZone) that we covered earlier, then these can be pretty fast. But embedded secure elements cannot be fast by design because it’s a separate processor.
The idea of our vTEE was to take the Trusted Execution Environment from the phone – from a hardware platform – and to put it into a mobile application. This means that during the integration phase and the protection phase, the vTEE is like a trusted virtual machine that executes the Trusted Application, deals with secure storage, and works with cryptography. So, your app contains its own TEE as well as a Trusted Application.
The image below should help you to visualize how it works.
Circling back to the key characteristics of a TEE from earlier in this article, there’s plenty of synergy here, too, because the most important characteristics of the Licel vTEE are isolation, controlled access, and integrity.
A vTEE brings the benefits of cross-platform compatibility, too. So, by definition the vTEE is a software implementation with only a little bit of hardware dependency. This means that a Trusted Application created using the Licel vTEE could run inside mobile apps for the Android and iOS platforms.
And because it’s a software-based implementation, the vTEE allows you to create your Trusted Application based on different techniques. You can write a native application, or you can write Java applications that utilize Java Card API, to implement its functionality.
The nature of a virtual TEE also makes it scalable. There’s no mobile platform vendor lock, so you can deploy it on a wide range of devices from different regions. It’s pretty much open to developers to decide how they influence or create real security components for mobile applications.
So, you see that there are some significant advantages of a Virtual Trusted Execution Environment over a traditional TEE. However, at Licel we’re great believers that the best tech solutions involve some kind of combination of both hardware and software elements. We see our vTEE as a helpful reinforcement in the marketplace rather than a complete changing of the guard.
Whether you opt for a traditional TEE or a virtual one like ours, we hope that if you’ve read this far then you now have a much better idea about what a Trusted Application is - and you understand why it’s so important to the future of secure app development.
Licel’s vTEE has now been EMVCo evaluated and approved for both major mobile platforms; Android and iOS.
