Google Nexus 6P security teardown
The Google Nexus 6P has finally started shipping in the UK, and here at IT Security Thing we have got our hands on one in order to do a Google Nexus 6P security teardown. Of course, instead of drooling over the gorgeous 2,560 x 1,440 resolution AMOLED screen with its 518ppi density or all-metal unibody design, we are more interested in determining how secure it is.
There are four areas in which the Nexus 6P shines as far as security improvements to the Android family of smartphones are concerned, namely: biometrics, OS security updates, app permissions and encryption. Let’s take a closer look at each in turn.
The most obvious, and written about, security feature of the Nexus 6P is the inclusion of a fingerprint reader which Google calls ‘Nexus Imprint’ in the same way that Apple refers to fingerprinting on the iPhone as ‘Touch ID’. Apart from the location of the reader, it’s centrally situated about a third of the way down the back of the handset whereas the iPhone opts for a combined home button and reader on the front, the two technologies are fairly similar it turns out.
For a start there’s the sheer turn of speed both display, with recognition of an enrolled finger almost instantaneous. Apple iPhone users have complained that they cannot use the home button to see the lockscreen as the fingerprint reader unlocks the handset too quickly; no such problems for Nexus 6P users courtesy of the separation of the reader from any other buttons. Having also used Touch ID on an iPhone, we can report that the enrollment procedure for Nexus Imprint is much faster and straightforward with the index fingers of both hands being completed in less than half the time it takes to enroll a single digit on the iPhone.
All of the above, however, is just fluff. None of that really impacts upon security, assuming you discount the ‘if it’s difficult to use then nobody will use it’ argument of course. What does impact upon security, what really matters, is how fingerprint data is stored. Apple got this right, right from the start, with Touch ID. What Apple did was create a mathematical representation (non reverse engineerable) of the scanned fingerprint which is then encrypted and stored in the Secure Enclave (protected by a key only available to the Secure Enclave) that is walled off from the rest of the chip as well as the rest of iOS.
Apple describes it thus “The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised.” But we are talking about Android here, and unfortunately Android devices have something of a history when it comes to getting it wrong.
Earlier this year, researchers from FireEye presented a paper that explained how some Android handsets, including the HTC One Max, had implemented a very insecure design for fingerprint security. Essentially, it allowed for direct interaction between the kernel and the fingerprint sensor, vendor fingerprint libraries and fingerprint services. The long and short of it being that were an attacker able to get root of the device, then they could get access to the fingerprint data.
Indeed, with fingerprint scans being stored as unencrypted bitmap files where any attacker could locate them easily enough, it was only going to be a matter of time before the sticky brown stuff met the whizzy round thing. The irony being that the ARM architecture of the devices concerned already allowed for a secure method of doing the fingerprint thing by isolating critical peripherals from being accessed outside of the TrustZone.
Thankfully, Huawei and Google have learned plenty from the past and the Nexus 6P does not fall into the insecure fingerprint implementation trap. Nexus Imprint adopts a very similar approach to Apple’s Secure Element for Touch ID; this hardware partitioning provides the kind of isolation that is required to nullify the exploits that would have been possible with earlier fingerprint implementations such as found on the HTC One Max.
Google’s updated Marshmallow Compatibility Definition Document (CDD) states that OEMs must rate limit attempts for at least 30 seconds after 5 false trials for fingerprint verification, must have a hardware-backed keystore implementation and must perform the fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE.
If that were not enough, they must also ensure that all identifiable fingerprint data is encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE) as documented in the implementation guidelines on the Android Open Source Project site.
You want more? OK, they must also prevent adding of a fingerprint without first establishing a chain of trust by having the user confirm existing (or add a new) device credential such as PIN/pattern/password using the TEE as implemented in the Android Open Source project. Oh, and they must not enable 3rd-party applications to distinguish between individual fingerprints either for good measure.
During a Reddit Q&A Dave Burke, the engineering lead at Google on the Nexus 6P project, stated: “fingerprint features are securely encrypted on the device, and processed in the secure TrustZone protected area of memory. The Android 6.0 fingerprint APIs do not provide any access to the fingerprint material to apps. Fingerprint features never leave the device and are not shared with Google (so for example if you setup a new phone, you need to re-enroll your fingers).” What’s more, fingerprint data is not backed up to your computer or other devices, nor is it backed up to Google servers. Finally, fingerprint data is not shared with apps; they have no have access to fingerprint data or hardware, but rather are simply notified if a fingerprint has been verified or not.
Although there remains, largely within the IT security industry and amongst privacy advocates, some opposition to the idea of fingerprints as a secure replacement for passwords we are not sure we can agree 100 per cent. Sure, we could get technical and lay out all sorts of reasons why a fingerprint is not as secure as a password (which involves everything from hashing capability through to an inability to change it should compromise occur) but the truth of the matter is, for most ordinary users, it adds another layer of security rather than introducing another opportunity to attack.
Let’s get real for a moment, and remember we are not talking about some high value target for whom the time and money required could be justified in terms of attack return but rather ordinary folk who are only attacked opportunistically, because bad passwords are easier to crack than fingerprints are to fake. Spoofing or stealing mass fingerprint data would be all but impossible, as storage is both local and isolated on your hardware, and without physical access to your Nexus 6P it is much harder to break your fingerprint protected remote service than it is a password protected one. There are, of course, ways to get around fingerprint security (the video of a kid placing a sleeping parental finger on an iPhone being one such example) but all of them pretty much require access to your smartphone and your finger.
The most important thing to remember, and why we are happy with the Nexus 6P implementation of fingerprinting, is that while Nexus Imprint will unlock the phone itself, it remains a secondary method for Android. You are still required to protect the handset with a PIN or password or pattern. The mistake is in thinking of Nexus Imprint as 1FA (One Factor Authentication) when actually it’s part of a multi-factor setup.
Another thing to remember is that Nexus Imprint is only as safe as you allow it be. So, for example, because the fingerprint reader itself is located on the rear of the handset rather than the front, some people may want to sidestep having to pick it up off the desk in order to access the phone. Seriously, it takes a second to pick the damn thing and retain the security benefit. Alternatively, you could do what we’ve seen recommended by people who really should know better and implement Android’s Smart Lock system so that the lock screen (and Nexus Imprint) is bypassed when you are in your office, or at home, or is near a trusted Bluetooth device or when you say OK Google. Then again, if you use Smart Lock we do wonder what you are even doing reading an IT security publication to be honest.
OK, let’s move on to Nexus 6P security improvement number two: OS security updates. Now you might either be thinking that this is nothing new or asking what the hell is an Android security update depending upon the handset you have and/or the carrier network your contract is with. And that, right there, is the problem in a nutshell: the Android OS distribution is so fragmented, and updating reliant upon so many variables, that security is compromised as a result. Think that’s a little bit of a FUD statement, think Stagefright, think again. While Google is pretty good at responding to vulnerabilities and issuing patches in short order, getting those patches out onto devices is another matter entirely.
Having your hardware come right out of Google and running stock Android is the best way to ensure that any updates to Android hit your device sooner rather than later. It’s one of the reasons why people buy into the Nexus brand in the first place. With the arrival of Android 6, or Marshmallow as it has been dubbed, is another good reason: monthly security updates. Again, in theory, these updates are available to every device. Back in the real world that really ain’t going to happen, and the best way to ensure they hit your handset bang on time is having Nexus writ large on the back of it.
Google says it will provide security updates for three years from when the 6P first went on sale or 18 months from the last direct sale from the Google Store, whichever is longest, so you are pretty much covered there. When we setup our Nexus 6P out of the box there was an update waiting for us, the November one in fact. According to the official security updates group forum this included fixes for seven vulnerabilities, two of which were listed as critical. So the security value of these regular patches really cannot be overplayed in our opinion.
Talking of Android Marshmallow brings us nicely onto the third of the security improvements we have really rated when it comes to the Nexus 6P, and that’s how app permissions are now handled. OK, we appreciate that this is a software rather than a hardware thing but the Nexus is the first handset to come with Marshmallow out of the box so we think, like the monthly security updates, it deserves a place in our round up. App permissions have, to put it mildly, been taken out the back and given a good kicking by Google; and not before bloody time. We are fed up to the back teeth with apps presenting us with a huge list of permissions that need agreeing to, as one, in order to install them. Especially when the reasoning for some of the inclusions are obtuse to say the least. We tend not to install these kind of apps anyway, as a matter of principle, but that’s beside the point.
The point is that app permissions have, for the longest time, been both confusing and inconsistent. Marshmallow puts this right. Now, rather than not installing an app because of the permissions list it demands, you can refuse permissions on a per app, per permission basis. Don’t want to let it access the microphone, then deny it. If the app doesn’t work properly as a result you can then evaluate whether you want to grant permission or delete the app. The permissions are no longer sought when downloading, but rather when they are required the first time. This is done by way of a permissions pop-up when an app tries to access your contacts list for the first time, for example. We like this as the user can actually see what functionality relates to the permission being requested. Not only does this lift the fog of confusion for the user, but it should encourage app developers not to ask for permissions they really should not need.
What if you accidentally grant a permission, or change your mind later? No problem, the solution (and then some) sits in the system settings. A two finger swipe down, click on ‘Apps’ and then hit the cogwheel. This reveals a menu including ‘App permissions’ which is the one you want now. This lists all the permissions, showing how many apps of those requesting access you have granted it to. A click on the category, camera (11 of 23) for example, and you can then toggle the apps that can access it individually.
Which just leaves us without final improvement, and this one will no doubt be the cause of much debate as it’s something of an about-turn for Google: forced full disk encryption out of the box. This was first brought in with the Nexus 6 (Nexus 7 tablet) but was much hated by many users as it slowed the devices down noticeably upon start-up and in use. In fact, Google changed its mind about forcing this kind of mandatory encryption on all new Lollipop devices due to just these kind of performance issues. Here at IT Security Thing we were, maybe unsurprisingly, happy to take a small performance hit in return for a huge security benefit and so implemented the encryption on every device we could.
This time around, at least in the case of the Nexus 6P (we have not had a chance to play with a Nexus 5X as of yet) the encryption has not appeared to have any noticeable impact upon performance. Which is just as well as there is no way to turn it off and roll the device back to an unencrypted state. This speed increase will partly be down to the Nexus 6P being much higher specced to start with (it’s a beast), but also thanks to it using the ARMv8 AES instructions, which speed up the encrypt/decrypt process. During a Reddit-hosted Q&A session, Google’s Dave Burke said that while the encryption remains software accelerated “the ARMv8 as part of 64-bit support has a number of instructions that provides better performance than the AES hardware options on the SoC.”
These instructions take the multiple algebraic steps that AES encryption requires and perform them as a single instruction. By getting rid of a long chain of individual instructions, performance takes much less of a hit.
And there you have it, the Google Nexus 6P security teardown from IT Security Thing. This isn’t a review, we don’t do them, but if it were our conclusion would be that the Nexus 6P is not only the best Nexus that Google has thrown out there to date, and offers incredible value for money up against premium handsets from rivals including Apple and Samsung, but it ticks plenty of boxes on the security side of things as well. In fact, until the malware-eating SnapDragon 820 chip starts appearing in smartphones in 2016 the Nexus 6P would be our first choice for a secure Android stock experience.