Gatekeeper Password Storage: How Android Secures Devices
In our new white paper on Android 6.0 (Marshmallow) forensics, we talk a little bit about Gatekeeper password storage, a new-as-of-Lollipop feature designed to introduce a new level of obfuscation to PIN and pattern locks—both in file name and location, and in hash settings.
In previous Android versions starting with 2.2, devices’ 4- to 16-digit PIN or alphanumeric passwords were stored in the /data/system/ directory with a filename of password.key. Pattern locks, meanwhile, were stored in the same directory under the gesture.key filename.
On the other hand, unless you were working with a rooted device, or with a bootloader exploit to communicate with a device in custom recovery mode, it wasn’t possible to access the /data/system/ folder and gesture.key file directly.
By contrast, /data/system now contains the files gatekeeper.password.key and gatekeeper.pattern.key. However, as with older Android versions, these files are still supplemented by device_policies.xml, the file that provides information about what type of password is in use, its length, and any special characters.
Gatekeeper now erases old, unused PINs, so that a gatekeeper.password.key file that is only 0 bytes in size may indicate that a PIN has been replaced by a pattern lock.
Gatekeeper Password Storage: Password hashing on Android Marshmallow devices
Pre-Gatekeeper, Android passwords were salted by laying out their SHA-1 and MD5 hashes back to back. The salt was then stored in a file in the settings.db or (after Android 4.4, KitKat) the locksettings.db SQLite database, while the post-salt password hash was stored in the gesture.key or password.key files. Because a dictionary attack could not break a salted hash, examiners had to obtain the salt from the lockscreen.password_salt record. This salt could then be used to brute-force the lock.
Pattern locks were likewise encrypted using SHA-1, but remained unsalted. Because pattern locks could only be generated using the 3×3 keypad, only a finite number of pattern combinations existed, and so although the plain text wasn’t possible owing to the use of SHA-1, you could nonetheless generate a dictionary of all possible hashes.
Alternatively, you could use a rainbow table—a way to search a large amount of hashes quickly. Before Gatekeeper, these tables didn’t apply much to passwords, which were salted, then run through an algorithm that gave a nonreversible SHA-1 value. This way, you could find a matching value, because the tables are programmed to know that the value is given under certain condition. By comparing this dictionary to hashes found within gesture.key or password.key, you could extract the pattern or password, and break the salt easily without much brute forcing.
In Marshmallow, PIN and pattern locks are still breakable, but no longer use simple hashes. Gatekeeper password storage manages and verifies passwords via Hash-based Message Authentication Code (HMAC) with a hardware-backed secret key. It authenticates pattern or password locks in a Trusted Execution Environment (TEE), which calculates the HMAC using a device-specific key. The HMAC key is kept solely in Gatekeeper.
Perhaps most importantly, while brute-forcing is still possible, it is now much more difficult. Gatekeeper throttles consecutive failed brute-force verification attempts on a user credential, and “must refuse to service requests based on a given timeout and a given number of consecutive failed attempts.”
For more information, including whether tools like the Octoplus box can still reset the screen lock, download the Demystifying Android Marshmallow Forensics white paper now!
