The iPhone X will replace Touch ID with Face ID; But what are the mechanisms that for years have been storing our fingerprints so safely? I took a close look.
Originally published at fabianstiehle.com.
More and more data needs to be stored on mobile devices as users demand more and more convenience. However, this convenience comes at the price of privacy. The most prominent example of this contradiction might be the fingerprint sensor on many popular mobile devices.
Fingerprint information could probably be classified as the most personal information. Thus, the mechanisms to save and process such information require the highest standards in security and data protection.
This article will discuss the mechanisms to store fingerprint data as it is implemented on Apple’s iPhone. Please note that this article won’t discuss the security of a fingerprint or fingerprint sensor as such, but only the secure storage and processing.
Three pillars of security
The overall security of the fingerprint data can be divided into three pillars:
- Hashing of the fingerprint
- Encryption of the Hash and secure communication
- Complete separation from other system components through the Secure Enclave
Hashing of the fingerprint
A very important concept of Touch ID is that a fingerprint is not permanently stored. Instead, the fingerprint is temporarily saved in the encrypted memory space of the secure enclave. (We will discuss the Secure Enclave later.) The fingerprint is then vectorized for analysis until it is fully discarded.
Apple self-describes this process as follows:
“The analysis utilizes subdermal ridge flow angle mapping, which is a lossy process that discards minutia data that would be required to reconstruct the user’s actual fingerprint.”1
Most notably Apple states that the original fingerprint can’t be reproduced. So, what is “subdermal ridge flow angle mapping”?
First, we need to understand “ridge flow” in the context of fingerprints. A “ridge” describes a curved line in a fingerprint image. The ridge flow is usually used for pattern matching in fingerprint technologies.
Ridge Flow Patterns (From: Center for Unified Biometrics and Sensors, University at Buffalo, https://cubs.buffalo.edu)
Now, what is sub-dermal in the context of fingerprints? Touch ID scans for “sub-dermal” fingerprint data. The ring around the sensor is used to send an electrical signal into the skin so that the subdermal layer (inner layer of skin) can contribute to the read.
Fingerprint sensor. Notice the golden ring around the sensor that starts the subdermal scan. (From: Apple.com, Newsroom)
Now that we brushed up on fingerprint terminology we can understand Apple’s official explanation of “Ridge flow angle mapping”:
“A mathematical representation of the direction and width of the ridges extracted from a portion of a fingerprint.”1
The process reminds of the way modern password authentication is handled, the original password is never stored in the database but a hashed value from which the original password can’t be reproduced.
Encryption of the Hash and secure communication
The mathematical representation of the fingerprint is hashed using a hash function which only the Secure Enclave can read. (We will discuss this in more detail momentarily.)
The hashed fingerprint representation is now forwarded to the Secure Enclave. This is done by the main processor, it forwards the hashed data to the Secure Enclave. The only information Apple supplies about this process is as follows:
“The processor forwards the data to the Secure Enclave but can’t read it. It’s encrypted and authenticated with a session key that is negotiated using the device’s shared key that is provisioned for the Touch ID sensor and the Secure Enclave. The session key exchange uses AES key wrapping with both sides providing a random key that establishes the session key and uses AES-CCM transport encryption.”1
This contains an idea that is core to the security of Touch ID:
“[…] the device’s shared key that is provisioned for the Touch ID sensor and the Secure Enclave.”
A talk by Ivan Krstic (Head of Apple Security Engineering and Architecture at Apple) at Blackhat 2016 makes this clearer. Ivan talks about a “factory-paired security channel between Secure Enclave and Touch ID”. In the factory, a key to secure the communication between Touch ID and the Secure Enclave is established. Without this unique key pairing, the Touch ID sensor could be substituted by a malicious one which could then gain access to the Secure Enclave.
This is also the reason for the infamous error 53, if the Touch ID sensor is replaced without pairing it with the Secure Enclave, the iPhone alerts error 53 which makes the phone practically unusable. Only Apple and Apple certified partners can perform such a pairing. This radical “feature” has also received some criticism in the past.
Let’s take a closer look at the communication between the sensor and the Enclave. Through the factory-paired key, a secure session key is established via a key wrapping algorithm. Key wrap algorithms can be used to securely transport a session key by encrypting it with another encryption key.
The secure transport is of special importance until the fingerprint data reaches the secure enclave. In this security model, the application processor is not trusted. Only the Enclave is trusted with security relevant data.
We can imagine the process as follows: The Touch ID sensor sends a random key to the Secure Enclave (SEP). Data is sent over a Serial Peripheral Interface (SPI). The random key is encrypted using the factory paired key (FP). Through both random keys, a session key is established with which all further data is encrypted.
Session key negotiation
With the factory key only being used to encrypt the random key parts, there is almost no data available from which the factory key could be reconstructed by a possible attacker. As Manuel Mogollon states:
“In cryptoanalsis, the more a key is used, the higher the probability that it could be broken. By using a key-encrypting-key to wrap keys, then the KEK will be used a fewer number of times […]”.2
Apple doesn’t provide any further information about the two random keys — however, if these keys are generated from a certain data set or in a certain way it could provide an additional layer of security and authentication. Touch ID or SEP could abort the session key negotiation if the random key doesn’t adhere to a certain pattern.
Please note that this can only be an assumption on how exactly Apple handles the secure communication between Touch ID and the enclave. Information is scarce.
The Secure enclave
The Secure Enclave is the main masterpiece of the security architecture and there is a reason why I saved this explanation for so long: It’s where it all comes together.
The Secure Enclave is a separate processor — completely independent from the main processor. It runs its own kernel, drivers, applications and has its own encrypted memory space. Apple calls it a “Security Enclave Processor” (SEP). It’s based on an L4 microprocessor. (L4-embedded) But has undergone some modifications by Apple.
Communication between the SEP and the AP (Application Processor) is isolated to a mailbox system. It provides both an inbox (request) and outbox (reply). The AP writes to the inbox of the mailbox and with that triggers a hardware interrupt in the SEP, this informs the SEP that a message has been received. When a reply is ready the SEP writes a message back to the outbox and another interrupt is generated to inform the AP.
Only the Secure Enclave has access to cryptographic operations and it is the only entity to handle all data protection keys (iOS has several) through the “Secure Key Service” (SKS) which is an application running on the SEP.
With this complete separation from other systems, the SEP maintains the integrity of all data protection even when the AP has been compromised.
Secure Boot and Device UID
The SEP also has its own boot process — completely separate from the main kernel. Both kernels verify their integrity through a chain of trust. All components are cryptographically signed by Apple. This also includes the bootloader, kernel, kernel extensions and firmware.
But the SEP does more. The SEP hardware contains a true random number generator and on first power up a private key that is unique to the SEP is generated. This root device key is never shared with other software. (Also unknown to Apple) The key is used to derive all over secret keys. (In fact, this is only the half story: a master key is generated through the root device key and the user’s passcode.)
The whole picture: How Touch ID unlocks
Now that we got an overview of the security architecture, how does Touch ID unlock the phone? We will first discuss how the normal passcode unlocks.
First Springboard, the primary user facing application (which for example manages the iOS home screen) acquires the passcode from the user. It will then send it to the SEP which will generate the master key from the received passcode and the device UID. With this master key, all other keys can be decrypted. Without Touch ID the device would now destroy the master key. (It did the job, encrypting the secret keys.) Notice how all data is only kept in memory as long as it is absolutely necessary.
How Touch ID unlocks
With Touch ID an additional step is introduced: From the master key, a random secret is generated. With this random secret, the master key is encrypted. The random secret will then be sent to the SBIO application running on the SEP. Take note that only the secret will be sent — not the master key itself. The raw master key will be discarded leaving the system with only the encrypted master key and the secret in SBIO.
Unlock with SBIO 1
Now that we have a first unlock by passcode in place we can finally explore how Touch ID unlocks.
The Touch ID Sensor sends the fingerprint (as discussed earlier) to the SBIO which performs the match. If fingerprints match, the random secret it acquired earlier is sent back to the SKS. With that SKS is now able to decrypt the earlier encrypted master key and with that all other keys. The phone is unlocked again. The raw master key is again safely discarded.
Unlock with SBIO 2
For Touch ID to work the phone needs to be unlocked via passcode once so the device can safely decrypt the master key. To increase security the master key is discarded if the device reboots, after 48 hours and after five failed Touch ID recognition attempts. All those cases will then require a passcode to proceed.
Conclusion
Apple has designed a clever security concept and takes measurements to ensure fingerprint data is safe on every step the data travels on the system.
- Data is hashed and stored only as long as it is truly necessary.
- The real fingerprint is never stored permanently.
- Through the completely separated Secure Enclave a secure system is in place to handle all security relevant operations and data.
The Secure Enclave and Touch ID provides the foundation for many other security features such as Apple Pay and Local Authentication. While other manufacturers have shown less care Apple has had this system in place since the first release of Touch ID. However, many details of the process are still in the dark since Apple seldom shares security information with the public. One could criticise that and quote one of Saltzer/Schroeder’s security design principles which state: “Open design: The design should not be secret”.4 The security of a fingerprint sensor itself also remains questionable. Many attempts have shown that a fingerprint sensor can be tricked. There is also to say that this article is mostly based on how Apple claims the system works. Since the implementation is not in the open this can’t be entirely verified.
Research Sources
- Tarjei Mandt, Mathew Solnik, David Wang, Demystifying The Secure Enclave Processor, https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf (Blackhat 2016)
- Ivan Krstic, Behind the Scenes with iOS Security, https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.pdf (Blackhat 2016)
- Apple, iOS Security Guide, https://www.apple.com/business/docs/iOS_Security_Guide.pdf (June 2017)
- Mogollon, Manuel: Cryptography and security service, 2007
- Jerome H. Saltzer, Michael D. Schroeder, April 17. 1975, Basic Principles of Information Protection, http://web.mit.edu/Saltzer/www/publications/protection/Basic.html
Originally published at fabianstiehle.com.