​iPhone encryption is six years ahead of Android: cryptographer

  • Liam Tung (CSO Online)
  • 25 November, 2016 08:04

An analysis of the encryption Google Android 7.0 Nougat could explain why US law enforcement is so concerned about Apple’s iPhone.

According to cryptographer and professor at John Hopkins University, Matthew Green, Google is having serious problems implementing encryption on Android and some of it appears to stem from its failure to appreciate the nuances of hardware.

“In 2016 Android is still struggling to deploy encryption that achieves (lock screen) security that Apple figured out six years ago. And they’re not even getting it right. That doesn’t bode well for the long term security of Android users,” wrote Green after analyzing Android 7.0 Nougat’s on-device encryption.

While Android is by far the most widely used OS on smartphones, Apple’s encryption on iOS remains the focus of law enforcement lobbying for mandatory backdoors. Green’s analysis may show why.

When Google unveiled Android 7.0 Nougat one of headline data protection features was file-based encryption, where individual files on a device can be encrypted with their own key.

It improved encryption for data stored on the device and moved Google’s mobile OS closer to encryption on Apple’s iOS, which has used file-based encryption since iOS 4 in 2010.

Until Android 7.0, Android encryption resembled data protection on PCs that use full-disk encryption, where one key is used to unlock a whole system.

But, says Green, Google’s decision to use full-disk encryption for Android in the first instance was a major misstep that could leave Android nearly a decade behind Apple’s iOS on encryption today. It may also show a certain naivety on Google’s part when it comes to hardware and security.

“The problem is that smartphones are not PCs. The major difference is that smartphone users are never encouraged to shut down their device,” writes Green of pre-Nougat encryption.

“In practice this means that — after you enter a passcode once after boot — normal users spend their whole day walking around with all their cryptographic keys in RAM. Since phone batteries live for a day or more (a long time compared to laptops) encryption doesn’t really offer much to protect you against an attacker who gets their hands on your phone during this time.”

Google could have destroyed the keys from RAM when a user locked their phone, however, as Greene notes, this would have locked users out of all content on their storage drive and left them with expensive paper weights, which explains its switch to file-based encryption.

Apple, by contrast, offers app developers a three-tiered gateway to data on devices, the highest being when a device has been been powered on and unlocked with the right passcode. It also offers a second level that leaves some files encrypted until the first time a use logs in after a reboot, and a third that allows files to remain accessible after reboot even if the user hasn’t logged in.

Green says Apple’s approach isn’t perfect, but it “is the obvious result of a long and careful thought process.”

Even with the switch to file-based encryption in Android 7.0, Google faces problems because of the way it’s instructing developers to write apps securely for Android. If Google does attempt to push further towards an Apple-like system, it will break a million apps that followed Google’s previous recommendations.

“By treating encryption as a relatively low priority, Google is basically telling these people that they shouldn’t get the same protections as other users. This may keep the FBI off Google’s backs, but in the long term it’s bad judgement on Google’s part,” wrote Green.