Android N Encryption之局限

0. Background: file and disk encryption

  1. Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement.
  2. File-based Encryption (FBE) systems (like EncFS and eCryptFS) encrypt individual files. This approach requires changes to the filesystem itself, but has the benefit of allowing fine grained access controls where individual files are encrypted using different keys.

In this view, encryption is an all-or-nothing proposition. Your machine is either on or off; accessible or inaccessible. As long as you make sure to have your laptop stolen only when it’s off, disk encryption will keep you perfectly safe.

1. What is wrong with the encryption implementation of previous Android OS?

The major difference is that smartphone users are never encouraged to shut down their device. 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.

Of course, users do lock their smartphones. In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately, Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick.

例如, 手机在半夜中重启, 之前用户设置的所有提醒,如闹钟都会因为手机并未解锁, 而没法工作. (Ref)

2. Apple''s implementation

In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user passcode and some hardware secrets embedded in the processor.

  • Complete protection (NSFileProtectionComplete - API Doc). Files encrypted with this class key can only be accessed when the device is powered up and unlocked. To ensure this, the class key is evicted from RAM a few seconds after the device locks.
  • Protected Until First User Authentication (NSFileProtectionCompleteUnlessOpen - API Doc). Files encrypted with this class key are protected until the user first logs in (after a reboot), and the key remains in memory.
  • No protection (NSFileProtectionNone - API Doc). These files are accessible even when the device has been rebooted, and the user has not yet logged in.
  • NSFileProtectionCompleteUnlessOpen (API Doc). It allows Apps to create new encrypted files when the class key has been evicted from RAM. This class uses public key encryption to write new files. This is why you can safely take pictures even when your device is locked.

3. Android N''s implementation

Android N systems can be configured to support a more Apple-like approach that uses file encryption, called Direct Boot.

  • Credential encrypted storage. Files in this area are encrypted under the user’s passcode, and won’t be available until the user enters their passcode (once).
  • Device encrypted storage. These files are not encrypted under the user’s passcode (though they may be encrypted using hardware secrets). Thus they are available after boot, even before the user enters a passcode.

3.1 What is wrong with Android N''s implementation?

新的Direct boot, 只提供了2种选择, 而 apple 提供了4种. 其中Complete Protection 的缺失是一个问题.

正如 Android Documentation 所说,

Credential encrypted storage is only available after the user has successfully unlocked the device, up until when the user restarts the device again.

Credential encrypted storage, 只要用户第一次解锁手机, 它能一直被访问,直至用户重启手机.

第二个问题, Android OS 并没提供方法让 App 知道手机是否已经重新 lock, 假如 key 已被删除, 并且手机已 lock, 当 APP 访问数据的时候,就会失败.

Reference

The limitations of Android N Encryption – A Few Thoughts on Cryptographic Engineering