The use of mobile devices for handling sensitive information, for example authentication for vulnerable logins or storing of data is omnipresent. To provide an efficient protection for this kind of information, Smartphone and Table producers are developing new methods to prevent common attacks.

A prevalent and proven method is the Trusted Execution Environment (TEE). The following article provides an overview for the mode of operation as well as it’s advantages and disadvantages for secure authentication.

What is the Trusted Execution Environment (TEE)?

The Trusted Execution Environment (TEE) is a separated area in the central processing unit of the device. The TEE is detached from the regular processor by hardware and operates its own firmware. It only offers a few, security-relevant functions to reduce points of attack by simplifying firmware and interface as well as preventing for example direct access to the memory.
For ARM-processors, widely used for smartphones (for example by Apple and Samsung) the TEE is realized with the TrustZone [1].
Initially, TEE were planned for protecting material protected by copyright, for example for renting digital videos. By now it has a wide range of application, for example protection of digital identities.

The TEE particularly protects the cryptographic keys from being copied, for example if the device is infected with malware. An asymmetric key pair is generated in the TEE and the corresponding app is granted only access to the public key. The private key is accessible solely to the TEE and information can be sent from the app to be signed by the private key via the interface. Even if the device is compromised the private key can not be simply read out.

Nowadays, most smartphones contain a TEE. Apple implemented the Secure Enclave, available in iPhones 5S and younger and iOS 7 and younger. Apps can access the Secure Enclave since iOS 9 and younger to protect sensitive data.
An Elliptic Curve key pair (secp256r1) is generated in the Secure Enclave. It is possible to readout the public key but not the private key. Additionally, the Secure Enclave offers the feature to sign data after the user confirmed the action with his fingerprint or PIN. That way malware can not access the private key or initiate the signing of data without the consent of the user. Apple does not plan other asymmetric procedures like RSA or similar Elliptic Curves. [2][3][4]

Android implemented the KeyStore supporting Hardware-TEEs starting with Version 4.3 or younger, if the device supports them. Devices with Android 6 or younger can provide information on supporting the TEE. [5] That way it can be determined during the registration of the two-factor authentication wether TEE is available and the appropriate security method can be selected.

What advantages does TEE provide for the user?

Information for the secure two-factor authentication and the certificate-based signature had to be secured on inconvenient smart cards. A simple software based method does not protect the sensitive data of the private key effectively and the unreliable protection with a password offers no defense to for example Brute Force attacks.

By implementing a TEE new methods of securing the sensitive keys become accessible. Securing the keys in the TEE is highly more secure than simply securing it on the phone. The TEE secures the key sufficiently without the added inconvenience of additional hardware ( for example smart cards). That way the user can simply use his phone to securely authenticate himself. A crucial advantage not only for securing the data but also to offer convenient authentication solutions.

How does the SecSign ID use the TEE?

We developed two methods for securing our two-factor authentication and the mobile signature to offer truly secure protection of the sensitive data: The SafeKey procedure and the key generation with elliptic curves and storage in the TEE.

During the SecSign ID registration process a key pair is generated on the phone for secure authentication. The SecSign app generates an asymmetric key pair with the public key secured on the Server (SSL-encrypted) and deleted from the phone. The private key is encrypted with the passcode (PIN or password) with the AES/SafeKey procedure or secured in the TEE.
Neither the passcode nor the corresponding private key are ever transmitted and thus, can not be intercepted by attackers.
The ID is immediately secured on the corresponding server and can be used for authentication.

The user needs the encrypted private key from his phone for the authentication. It is either secured against attacks by the SafeKey procedure (AES encryption with RSA key) or by the hardware TEE. The SafeKey mechanisms is explained in detailed at “What is the SafeKey procedure?”