TEE, the next step for mobile payment technology?

In such a fast-evolving situation, banks must consider all existing options, balancing what suits their strategy best (security vs. usability, agreements with other players such as OEMs or MNO, technological maturity of the market) with awareness of new solutions that could disrupt the mobile payments market.

Two questions mobile application security developers might ask: are the payment application and customers’ data well protected? And is it worth changing the payment application’s security measures? There is no quick answer to these questions. Several aspects have to be considered, such as:

• Protection of new user input data interfaces (fingerprint sensor, camera, etc.)
• Costs of changing the technology
• User perception of impact on security: will users feel that my application is now more secure?

Today we analyze a new solution that is starting to make a name for itself, Trusted Execution Environment (TEE) which may solve some functional and security shortcomings SE or HCE have.

TEE: a solution based on isolation

TEE is a security solution based on hardware and software isolation. A smartphone with TEE implemented is divided in two:  the mobile ‘normal world’ (Rich OS) with its hardware, operating system (e.g. Android) and applications; and the ‘trusted world’ (Trusted OS), where only trusted apps will be executed on a Trusted OS, that uses trusted hardware resources.

TEE is not really a new solution. Most new generation mobile phones could use a TEE. Some smartphones are already using a proprietary type of TEE, for instance Qualcomm QSEE, Apple Secure Enclave or HiSilicon Trusted Core. And many of us have used TEE applications, called Trusted Applications (TA), such as iOS Touch ID or Android File System Encryption.

So why is this security architecture still not used as an alternative to current mobile payment technologies? Here are four reasons this could change in the near future:

A middle ground solution in the “security vs performance” debate: In the struggle between HCE and SE solutions, one key issue is how to balance security and performance. SE may be bullet-proof (with some holes as we will later see) but it has very limited functionalities (reduced API Set, low memory capacity and low data transfer speed), high implementation costs and a complex ecosystem.  HCE technology is cheaper to implement and has a simplified ecosystem that will attract many decision-makers in banks. However, HCE is a software-based solution which has important security weak points (i.e. its security relies on device OS/Rich OS). Banks using this solution must rely on transaction risk analysis (e.g. data analysis provides real-time transaction assessment to identify unusual activity) rather than security assurance.  In contrast TEE is a middle ground solution in terms of security and functionality (see the chart below) because it uses device resources with hardware and software countermeasures.

Unprotected biometrics (and other peripherals): Many banks and handset manufacturers are introducing biometrics as a keystone of authentication and authorization. The increasing popularity of biometry only serves to underline an existing security problem for all the current solutions. Peripherals are not protected in either SE or HCE solutions. SE tamper-resistant protection and HCE tokenization systems may protect sensitive user data but what happens if a fingerprint sensor or touchscreen is unprotected?  As FireEye researchers showed at the BlackHat USA security conference in 2015, while Rich OSs continue to manage these peripherals, malware would still jeopardize them.

Protection against Malware: Properties a TEE must have such as isolation, trusted path or secure storage (basically file system encryption) will make life harder for malware. All tasks executed by a TEE will run using device resources isolated from Rich OS resources. Hardware RAM isolation, for instance, can prevent malware from gathering information from those addresses set as trusted. Also, if peripheral drivers are handled by TEE OS, a malicious agent will have much more difficulty when trying to take control of them.

Hardware support: The main TEE hardware architecture is based on ARM Trustzone. Nearly 90% of the world’s smartphones and tablets use ARM architecture, devices on the markets using ARMv7 or ARMv8 Cortex-A family processors are already prepared to implement this solution. Therefore, it is not necessary to change current devices’ hardware architecture for this technology.

TEE Use case: A payment transaction

The following graphic illustrates a typical use case: a payment transaction using a TEE

The Payment App consists of two applications. One is found on the Rich OS side (Client App): main GUI and non-critical actions such as receiving the latest news from your bank. The other is on the TEE OS side (Trusted App) where all the sensitive tasks are executed, including generating crypto keys and validating the user’s fingerprint.

1. Transaction start
2. Authorization Request: delegated to the Trusted Application.
3. Fingerprint Request: trusted peripheral.
4. Fingerprint Verification
5. Search Token: keep in Trusted File System
6. Cryptogram: from Token
7. Payment Authorized

TEE shortcomings: standardization & ecosystem

Although TEE technology seems ripe to disrupt the mobile payment market, some important issues need to be clarified before becoming a real alternative.

As explained above, TEE technology is already being used in new smartphones but as a handset manufacturer proprietary solution. The lack of standardization is a key obstacle for banks and technology vendors to develop their own Trusted Apps, replicating the ecosystem problem of SE-based solutions.

Standardization would require the collaboration of handset manufacturers in order to integrate any TEE OS with their System on Chip to made use of hardware security properties (for example TrustZone) which it is still not so easy. Also, integrating Trusted Applications (TA) on different TEE operating systems needs to be analyzed to prevent application developers having to develop a completely different TA for each TEE OS.

TEE integration with other solutions

One of the possible outcomes for TEE technology is to complement existing solutions for mobile payment. As was mentioned in the Smart Alliance HCE white paper, the TEE can be part of an HCE solution providing an additional level of security when the main operating system is compromised. In this scenario, the HCE will use the trusted OS for a reduced number of sensitive functions (user authentication, token storage, cryptographic functions, etc.). TEE can also be used as a complement for SE solutions to filter access to applications stored in the Secure Element or transmit a PIN stored in the SE. In both cases, TEE can be used to improve security offered by existence solutions.

In fact, this integration capability is already helping make TEE part of different payment applications. Apple Pay and Samsung Pay protect some of their assets (for instance user’s fingerprint or payment tokens) using a TEE.

TEE and IoT devices

In closing, it is important to highlight that one of the main strengths of TEE technology is its versatility. It is not a secure payment solution, but a security solution for all kinds of connected devices that manage sensitive data (DRM, Identification, etc.). In fact, ARM has already developed a specific TEE architecture for IoT devices (Cortex –M23 and M33), using an operating system called mbed OS. A standardized TEE ecosystem will help to deploy mobile payment solutions to new connected devices such as Smart Watches, Smart TVs and perhaps, why not, Smart Fridges to buy our groceries online.

By Jose Alejandro Rivas Vidal