Securing data in the TEE

02/01/2017 / 0 Comments

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 für secure authentication.

What is the Trusted Execution Environment (TEE)?

The Trusted Execution Environment (TEE) is a separated are 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 private 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 and 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?”

During the authentication process the challenge response method is used. The user starts the authentication process by providing his SecSign ID user name to the service. The service verifies the start of the login procedure with the SecSign ID server. The ID-Server sends a random number to the users SecSign ID App. After confirmation from the user the app signs the SHA265 hash of the random number and sends it back to the server. The sever can now verify the result with the public key and release the authentication.

The SecSign ID offers key renewal at any time for the users ID, for example after updating the operating system. The keys are replaced both on the phone and the ID Server.

How is the information in the TEE secured?

The TEE runs parallel to the so-called rich-operating system (mobile OS). It works as a hybrid system by using both the hardware and the software of the device. It can access the main processor and the memory of the phone while being protected from unauthorized access from apps in the mobile OS by the hardware components.
It works as a secure storage- and processor location separated from the regular rich ID. That way it is unaccessible to attacks for example from malware. The private key, which is used for the secure two-factor authentication and certificate-based signature is never read out from the TEE. Instead, it receives a challenge from the server that is signed accordingly. The authentication is only possible with the respective signature. That way, information on the private key can not be intercepted, encrypted or accessed.
The TEE can communicated with so-called trusted applications via the internal API. That way a secure authentication is possible without making sensitive information accessible to the rich OS.

What is the SafeKey procedure?

If no TEE is available, for example in older devices, the private key is secured with the SafeKey procedure. The private RSA-key is encrypted with the corresponding password. If no password is provided, for example by using a fingerprint authentication, a random string of 16 bytes is used and secured in the keychain of the device. An AES-Key-Encryption-Key is derived from the password with the PBKDF2 algorithm. The format of the RSA key is used for the encryption in that it can not be distinguished from random data.
The private exponent is encrypted with AES in CBC-modus with the Key-Encryption-Key. If an attacker gains access to the encrypted key and obtain the correct PIN by trying out every single 4-digit combination he can not recognize it. The public key is only present on the SecSign ID server, not in the app. To verify the correct encryption of the private key an authentication process has to be initiated with the SecSign ID server. No more than 10 failed attempts of authentication are allowed before the account is locked. That way, even a 4-digit PIN is sufficient in protecting the authentication. The procedure is patented as SafeKey procedure.
The encrypted private key is secured in the Keychain of the device. It is only included in an iTunes-Backup if it is encrypted.

Conclusion

SecSign is providing PKI structures for over 18 years and we know how important the security of the keys is for two-factor authentication and certificate-based signatures.

Several Apple and Android devices contain a TEE and can support the corresponding safety features. Principally, all smartphones are equipped with an ARM-processor, that generally contains the TrustZone. We believe that most smartphones are going to support this method. Also Google requires from all manufactures that fingerprints need to be secured in the hardware-TEE (starting with Android 6). [5]

Please contact us if you are interested in securing your SecSign ID data in the TEE. The current public version still uses the SafeKey procedure as default method. Though, the TEE method is being used by numerous of our customers.

Our next update offers individual selection of your method of choice.

Sources

[1] https://en.wikipedia.org/wiki/ARM_architecture#TrustZone
[2] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
[3] https://developer.apple.com/reference/security/ksecattrtokenidsecureenclave
[4[ https://developer.apple.com/videos/play/wwdc2015/706/
[5] https://developer.android.com/training/articles/keystore.html
[6] https://static.googleusercontent.com/media/source.android.com/en//compatibility/android-cdd.pdf

Leave a Reply

0 Comments

Want to join the discussion?
Feel free to contribute!

Your email address will not be published. Required fields are marked *

Do NOT follow this link or you will be banned from the site!