By Lee Neely
Mobile device administrators and end users need to be more cognizant of the risks of allowing unauthorized access to their smartphones and take steps to raise the bar on accessing those devices to mitigate those risks.
This is part one of two articles on securing mobile device access. In this article, I am going to focus on securing access to the physical device itself. In part two, I will discuss on-device security APIs and how one would know they are still in place.
The case for a strong passcode
When the first smartphones were introduced, they were corporate owned, managed, and secured to business standards. Device access was on par with accessing corporate laptop systems. The number, variety, and quantity of applications and personal or sensitive information stored on the device was far less than we see in modern iOS, Android, Windows Mobile, and other devices. While there were some devices owned and managed by end users, it was not as significant as it is today. The seminal events that tie to explosion of content, applications, data and personal use are the introduction of the iPhone in 2007 and Android in 2008. With this change of use, device administrators, and end users, we now need to worry about access to the information on their smartphone, and usually have less control over the device.
When the first iPhone lock-screen bypass “bug” was announced in 2008, I found the reaction was unexpectedly blasé. Further research indicated, at that time, that the majority of users weren’t setting a passcode any way, so there was no lock screen to bypass. A 2014 survey by Consumer Reports found that while 47% of users surveyed were setting a passcode, gesture or other mechanism to lock the device screen, 77% of those users were only using a four digit PIN. Further, users were unlikely to do anything more, such as configuring an automatic wipe after a specified number of passcode failures. Observation indicates that while setting a passcode is becoming more standard, a four-digit PIN remains the de-facto setting chosen by users.
While the use of a passcode is better than a device that has no screen lock, a four digit PIN is relatively simple to bypass using one of the following techniques:
- Observing the numbers used:
- SANS instructor Chris Crowley has found that he can reliably observe the numbers used in a four digit PIN from across a room, quite a feat but not at all implausible.
- Finding a likely four-digit PIN
- Searching social media, phone directories, and other on-line sources for four digit numbers of significance to the given user.
- Users typically pick passcodes that are easy to recall, such as a birth or anniversary date, home address or a simple pattern, such as 1111, four corners, etc. For more on the most common PINS, check out http://www.datagenetics.com/blog/september32012/
- Brute force:
- Devices that connect to an iOS device, such as an IP-Box, can try all 10,000 four digit PINs in about 17 hours.
- Users often don’t configure the device to wipe after ten failed passcode attempts. Additionally, there were several scenarios prior to iOS 8.3 that allow the device wipe on ten failed attempts to be bypassed.
- Devices that connect to an Android, such as a USB Rubber Ducky (using a USB OTG cable) can try all 10,000 four digit PINs in about 16 hours.
- Default behavior on the Android is forcing a 30 second pause after five failed passcode attempts, so the brute force tools simply pause as well.
The argument for stronger authentication
So, as the four digit PIN can be compromised, and with the current uses including email, shopping, banking, payment, contacts, notes, and social media applications, many configured to login as the owner without prompting for additional credentials, the need for a strong device passcode becomes increasingly more important.
The need for a strong passcode to access their smartphone and all the potentially sensitive information on it is not hard for users to understand. Yet, device administrators don’t get support when they suggest strong passcodes. My experience is most users get stuck on the idea of using, and more specifically entering, a complex password on this device they have significant personal interaction with and control of. I have found that if using more secure options is too difficult for users, they will find ways to use simpler, less secure ways to get the job done. Entering a long, complex passcode, every time they want to use their smartphone, is not something that is done quickly and easily; an alternate secure authentication mechanism is needed.
A mentor once told me “We hire the smartest people on the planet to solve problems; don’t be a problem they solve.”
Enter biometric authentication: authentication based on some intrinsic characteristic of the user. Biometrics used for authentication include fingerprints, retina scans, face recognition and voice prints. Enabling biometric authentication can offset the impact of requiring a strong passcode, a win for device administrators and users. While also reducing the times where a passcode can be observed and subsequently entered.
When the Android OS 4.1 was introduced, an option appeared to allow the smartphone to unlock when it saw the configured user’s face. The big challenge with that option is a photo of the users face would work as well as the real face. Updates were made to require the user to blink their eyes as a differentiation from a photograph. This option generally means that the device camera is on and watching full time, which may not always be appropriate or desirable. I recommend disabling this option.
Another popular form of biometric authentication has emerged, namely fingerprint readers (queue bionic sound-effect from the Six Million Dollar Man television series). These appear in one of two styles, a finger press or finger swipe. The finger press style has seen a large degree of user acceptance because it is easier to use than either a finger swipe or passcode entry and has fewer false rejections.
While biometric authentication is not free from issues, it has removed most of the situations where a user has to enter the passcode; and therefore is seeing increased adoption and acceptance.
It is important to remember that regardless of the biometric system used, if it determines that the user is not who they claim to be, they will need to enter the device passcode. Vendors work hard to adjust the False Accept Rate (FAR) and False Reject Rate (FRR) to ensure that fake users are turned away and genuine users are able to authenticate. The Crossover Error Rate (CER) is the rate at which the FRR and FAR are equal, and sometimes called sensitivity or the Equal Error Rate (EER.) The graph below illustrates this phenomenon. When the vendor delivers a product that operates with a good CER, user acceptance is high, and widespread adoption is possible.
Why focus on Android/iOS?
According to data from International Data Corporation (IDC) in Q4 of 2014, 96% of the worldwide smartphone market is comprised of Android and iOS devices. Given the substantial margin over other options, I am going to focus on iOS and Android device solutions.
The iPhone 5s and Samsung Galaxy S5 both introduced fingerprint readers to enable biometric authentication. In both cases, groups such as The Chaos Computer Club (CCC) devised mechanisms for creating a fake fingerprint that would unlock the device. Joshua Wright, author of the SANS Institute SEC575 course on Mobile Device Security and Ethical Hacking, illustrates the CCC process for creating a fake fingerprint to trick Touch ID, as shown in the course except below. A similar process can be used against Samsung devices. With the introduction of the iPhone 6 and Samsung Galaxy S6, the sensitivity of the readers has increased, meaning marginal fake fingerprints will no longer work, and at times it may pick up the fingerprint behind the fake, again causing the fingerprint to be rejected. This change in sensitivity also means some legitimate fingerprints will be rejected.
Protection of Biometric information
One of the most important security measures in biometric authentication is protection of the biometric information. In both Samsung and Apple implementations, the fingerprint scan is not actually stored. Instead, a mathematical representation of the fingerprint is made which is then stored in a secure location on the device that is not replicated to the cloud or backups. This is of critical importance since, unlike passwords, fingerprints cannot be simply changed if they are compromised.
Samsung Fingerprint Scan Data Security
Samsung devices use a trusted execution environment to protect fingerprint data. Per Samsung, the fingerprint framework works as follows:
- Actual fingerprints or biometric data is not stored. A hash is created from the scan and the resulting hash is stored in Trustzone which is the ARM architecture TEE (Trusted Execution Environment)
- Fingerprint scanner & UI are in TEE
- Fingerprints cannot be accessed outside the TEE
- Fingerprint scanner hardware cannot be accessed outside TEE
- Scanner is connected such that only TEE can access it physically
- TEE takes over display to show trusted UI for input
- Fingerprint data is not accessible outside TEE
- Trustlet provides results of scan, possibly some key protected by successful scan, but no scan information
Apple Touch ID Fingerprint Data Security
On Apple iOS devices, fingerprint representations are stored in the Secure Enclave. The Secure Enclave is a co-processor with its own boot and update processes, as well as encrypted memory with a unique key that is assigned during fabrication. The Secure Enclave maintains the security of the data contained within it, even if the main kernel is compromised. Apple provides limited System APIs for applications that wish to use Touch ID for authentication, restricting access to how the fingerprint reader is used.
Biometric Impacts on Daily Use
Using Biometric authentication has impacts, both good and bad, on how users access their devices and on privacy.
While the fingerprint readers appear to eliminate the need to enter the device passcode, there are still a few times you need to enter it. Here is a comparison of where Touch ID and Samsung’s Fingerprint Scanner still require the password:
||Apple Touch ID
||Samsung Fingerprint Scanner
||Only required if on device encryption enabled
|Idle more than 48 hours
||Can still use fingerprint
|After five unsuccessful attempts to match a fingerprint
||Must Enter. This is new with Samsung’s S6.Previously, no limit was set.
||Must Enter. Must have passcode prior to enrolling. Maximum five fingerprints stored
||Either may be used. Must have a minimum of six character “Backup Password”, including one digit and one number configured. Maximum four fingerprints stored
|Device receives a remote lock command
||Must Enter Passcode
||Must use configured lock password. Note remote lock changes the screen lock to password instead of fingerprint.
Device administrators and users should consider the table above when debating the use of biometrics in conjunction with strong passcodes.
Beyond the fingerprint replication threats publicized by CCC, using fingerprint authentication also introduces privacy concerns for some users. For example, Law Enforcement Agencies (LEA) can compel a suspect to turn over “something you have”, but the restrictions for turning over “something you know” are more difficult. Applied to biometric authentication, LEA can compel you to unlock your phone with a fingerprint, but do not have the US legal authority to compel you to reveal a PIN or password used to lock a device
If the stored fingerprint is connected to Apple Pay, PayPal, or Samsung Pay on your mobile device, potential impacts of using a fake fingerprint are increased.
Peace of Mind – Practical Recommendations
It is important to remember that creating a fake fingerprint takes time, resources, and skills. This means the chances of an attacker or street thief getting into a user’s device before they or the device administrator have had a chance to remotely wipe it are low. Additionally, the device is protected by a strong passcode that can’t be easily guessed, falling back to compromising the device passcode is also non-trivial.
Other things that must be done:
Enable on-device encryption on Android devices. (This is always on for iOS devices.) This ensures the data on the device cannot be retrieved by merely dumping the NVRAM to another computer for analysis or use.
In addition to any corporate Mobile Device Management (MDM) solution in use, verify the device is setup for either Find My iPhone or Android Device Manager. This gives the users the ability to remotely locate, ring, lock and/or wipe their device in the event something happens.
Configure the device to wipe after a pre-set number of failed passcodes. Don’t give bad guys unlimited license to try passcodes. Device administrators should set this number high enough to account for difficulties entering a passcode so as to avoid accidental data wiping. I suggest ten. If that is an unacceptable risk, set it to no lower than five.
Lastly, regardless of using a passcode, fingerprint, or any other authentication mechanism, physical possession of the device is always important. Train users to treat their smartphone as they would their wallet: don’t leave it where others can easily take it and use caution revealing authentication mechanism details.
Conclusion for Part 1
Following these recommendations, access to a user’s device and the corresponding sensitive information on it become much harder. Further, shoulder surfing a fingerprint read and then replicating it to access a device are much harder than simply capturing the PIN or password a user is entering.
Raising the bar on accessing the sensitive information on mobile devices, particularly as we find more places they enable actions and protect a greater amount of our personal information, helps us be a little more certain about who has access to that information. But, this approach also raises the question of how else these security mechanisms could be used.
In part two, we will talk about how applications access fingerprint data, how the security of those APIs are maintained, and how one would know they were still in place.
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!