SANS Penetration Testing

What's the Deal with Mobile Device Passcodes and Biometrics? (Part 2 of 2)

By Lee Neely

In the first installment of this 2-parter, I discussed the use of mobile device fingerprint scanners to unlock the device. As a follow-up, I'd like to discuss how a developer can integrate the scanner into their applications. This discussion may provide some insights into how to secure mobile apps, or even inspire some hacking ideas (this is a pen test related blog, after all). At the end of the article below, I'll discuss some ideas for compromising this type of environment.

In part one, I introduced the secure environment used to manage fingerprints. This environment is called by a couple of names. Most commonly it's called the Trusted Execution Environment (TEE) and Secure Enclave. In both cases, the terms describe a separate environment consisting of hardware and software, which performs specific tasks relating to managing and validating trusted information, isolated from the primary device applications and operating system.


Global Platform, an international standards organization, has developed a set of standards for the TEE's APIs and security services. These were published in 2010 and the corresponding APIs between the Trusted Application and Trusted OS was completed in 2011. The image below, from, describes the TrustZone standard.Blog 1

With this published, we saw the introduction of implementations from Apple and Samsung using a secure micro-kernel on their application coprocessor. A TrustZone enabled processor allows for hardware isolation of secure operations. Rooting or Jailbreaking the device Operating System does not impact the secure micro-kernel.

Both platforms are using the same paradigm. There is now a Normal World (NW) and Secure World (SW) with APIs for NW applications to access information in the SW. In both cases the Fingerprint Reader/Scanner is connected to the SW, so the fingerprint scan itself cannot be accessed by NW applications. Both platforms have API calls that mask the details of the implementation from an application developer, making it simple to incorporate this technology into applications.

Apple Implementation Details

Apple introduced their Secure Enclave when they released the iPhone 5S which included Touch ID and their A7 processor. Apple creates a Secure Enclave using encrypted memory and includes a hardware random number generator, and a micro-kernel based on the L4 family with modifications by Apple. The Secure Enclave is created during the manufacturing process with its own Unique ID (UID) that reportedly not even Apple knows. At device startup, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave's portion of the device's memory. Secure Enclave data written to the file system is encrypted with a key that is entangled with the UID and an anti-replay counter. During device startup, the Secure Enclave coprocessor also uses a secure boot process to ensure the software is verified and signed by Apple. In the event the Secure Enclave integrity cannot be verified, the device enters device firmware upgrade (DFU) mode and you have to restore the device to factory default settings.

Using Touch ID with applications:

Third-party apps can use system-provided APIs to ask the user to authenticate using Touch ID or a passcode. The app is only notified as to whether the authentication was successful; it cannot access Touch ID or the data associated with the enrolled fingerprint.

Keychain items can also be protected with Touch ID, to be released by the Secured Enclave only by a fingerprint match or the device passcode. App developers also have APIs to verify that a passcode has been set by the user and therefore able to authenticate or unlock keychain items using Touch ID.

Apple APIs

After all that, it may seem like it's hard to make a call to Touch ID for authentication. Apple is now publishing sample code and API documentation through the Apple iOS Developer Library. Note: Downloading the iOS SDK requires an Apple Developer Program membership.

This code sample Local Authentication Framework from Apple's iOS Developer Library makes it pretty simple to add a Touch ID authentication prompt to an application:


Blog 2.2

Samsung Implementation Details

Samsung introduced their Trusted Execution Environment in the Galaxy SIII. Samsung uses a micro-kernel named Mobicore. Developed by Giesecke & Devrient GmbH (G&D), it uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the "rich" operating system of the device. This isolation creates the TEE. Secure applications that run inside Mobicore are called trustlets. Applications communicate with trustlets through the Mobicore library, service and device drivers.

While third-party application developers can create their own trustlets, they need to be incorporated into Mobicore by G&D.

The following figure published by G&D demonstrates Mobicore's architecture:

Blog 2

Using Samsung Fingerprint Scanner with applications:

Samsung's fingerprint scanner can be used with Web sign-in and verification of a Samsung account. Additionally, it will be incorporated into the authorization process for the new Samsung Pay application.

Applications workflow for Fingerprint Authorization is as follows:

  1. User opens app (that uses fingerprint)
  2. User goes to authorize something (such as payment)
  3. App launches fingerprint Trustlet
  4. Secure screen takes over and provides UI for reading fingerprint
  5. Fingerprint scanner accepts input
  6. Trustlet verifies fingerprint by comparing it to stored scan data from registration and provides authorization back to App
  7. Authorization is completed

Samsung API

To access fingerprints on Samsung, you need to use the Pass SDK. It works with both the Swipe (S5, Note 4) and Touch (S6) sensor. The Pass SDK provides for not only checking a fingerprint but also has mechanisms to add, check, and even throw a handled exception in the event your application is run on a device that doesn't support a fingerprint scanner.

Sample code from the Pass SDK to authenticate with a fingerprint:

Blog 3


So now you know how the architecture works, and how to access it, the question becomes how can this be compromised? What are the risks?

The first option is to directly attack the fingerprint database. The FireEye team found HTC was storing the fingerprint database as a world-readable world-writable file, which means that any application could read or modify the contents. Reports of patches have been issued to address this.

The second option is to interfere with the communication between the fingerprint reader and the SW. If you could attach a process to that device, you could make your own collection of fingerprints accessing the device, or even more insidiously, insert your own fingerprint into the legitimate fingerprint database. Again, the FireEye team found cases where this was possible and the vendors issued patches.

The third option is to modify the device driver that's between the NW and SW portions of the device. Potentially altering the behavior of the fingerprint scan checks to always return true. Other data, which is uniquely stored in the SW, cannot so easily be faked so there are limits to how successful this would be. As luck would have it, another presentation at Black Hat 2015 found an exploit.

Di Shen's presentation from BH-15 shows how an insecure implementation of the TEE OS and driver in the Huawei devices with the Huawie HiSilicon chipset can be used to alter trusted memory, injecting shell code, accessing fingerprint data, and otherwise compromising the TEE. These compromises do require kernel (rooted) access to be successful.

A common thread in addressing these weaknesses is patches or updates. Android users have had a struggle getting these updates consistently and in a timely fashion. On August 5th, Google announced monthly Over the Air (OTA) security updates for their Nexus devices and Samsung announced a fast track OTA security update process. Samsung is negotiating with mobile operators worldwide to insure the process will be successful. With luck, other device manufacturers will follow suit. An important thing to note is the backward compatibility of the updates. Typically Android devices only have updates for eighteen months, if at all. By contrast, Apple iOS 8.4.1 is still supported on the four-year-old iPhone 4s. Once a platform with updates is chosen, it is still necessary to check for and apply the updates that are distributed.

To stay informed about security updates, subscribe to data feeds that carry announcements of updates and fixes. Google recently created an Android Security Updates Google Group. Apple announces their updates through their security page and security-announce mailing list.


When considering the use of biometrics either for device or application authentication, a risk-based decision has to be made, as with any external authentication service, whether to trust it. Fingerprint readers are still subject to bypass techniques as were described in part one. The simplest mitigation is to rely on device and application integrity checks which must pass prior to allowing the external authentication to either be enabled or succeed. Additionally, being aware of the physical security of the mobile device is paramount. Protect it like you would protect your wallet.

If the risk is acceptable, users are again provided with an authentication mechanism that cannot be merely observed to circumvent. The authentication information itself is securely stored, the application verifies it via calls through a secure API designed to detect tampering, and the application is no longer managing passwords.

One advantage an application developer has is they may elect to have layered authentication. If the target is a corporate application, working with the mobile device administration team to ensure a device level passcode is also configured would then ensure two levels of authentication prior to allowing access to your application.

One more option an application developer has is to require added authentication, within the application, prior to allowing access. Perhaps, that might be a PIN plus a Fingerprint. While this is appealing from a security perspective, from an end-user perspective this may be a tough option to accept.


In short, adding support for biometric authentication has a nominal impact and, as such, making a pitch for using it when developing applications should be an easy option for management to accept. I suggest seriously considering it for your next mobile application development project.

-Lee Neely

Want to learn more on this topic? You really should check out SEC575: Mobile Device Security and Ethical Hacking, an amazing course covering mobile device security, attacks, and much more!

Apple iOS Security Guide:

Brute Force Android PIN:

Samsung Fingerprint 4.4:

Samsung S5 Fingerprint Hacked:,news-18655.html

Samsung/Apple face-off:

Improvements to iPhone 6 Fingerprint scanner:

CCC how-to make a fake fingerprint:

FAR/FRR Graph:

Entrust Blog:

iOS Authenticate with Touch ID:

Samsung Pass SDK:

Samsung KNOX Security Overview:

MobiCore description:

BlackHat Presentation:

Attack TrustZone:




Posted April 20, 2016 at 5:49 PM | Permalink | Reply

Md. Anwar Hossain Chowdhury

People often get confused with passcode and biometrics. I'm also not an exception from this point of view. I think passcode means biometrics from a single or narrow point of view and Biometrics means a collective or larger point of view, although both perform similarly.
From this rich article, I learn many insights of biometrics and passcode and from the learners point of view, the article is really impressive. Thank you very much for your contribution.

Posted January 6, 2018 at 12:55 PM | Permalink | Reply

Webbleu Technologies

Brilliant blog, and very informative. everybody should learned a lot from this, found it really interesting. Thanks for sharing your knowledge of latest technology with us.

Post a Comment


* Indicates a required field.