[Cross-posted from the Android Developers Blog]
Over the course of the summer, we previewed a variety of security enhancements in Android 7.0 Nougat: an increased focus on security with our vulnerability rewards program, a new Direct Boot mode, re-architected mediaserver and hardened media stack, apps that are protected from accidental regressions to cleartext traffic, an update to the way Android handles trusted certificate authorities, strict enforcement of verified boot with error correction, and updates to the Linux kernel to reduce the attack surface and increase memory protection. Phew!
Now that Nougat has begun to roll out, we wanted to recap these updates in a single overview and highlight a few new improvements.
Direct Boot and encryption
In previous versions of Android, users with encrypted devices would have to enter their PIN/pattern/password by default during the boot process to decrypt their storage area and finish booting. With Android 7.0 Nougat, we’ve updated the underlying encryption scheme and streamlined the boot process to speed up rebooting your phone. Now your phone’s main features, like the phone app and your alarm clock, are ready right away before you even type your PIN, so people can call you and your alarm clock can wake you up. We call this feature Direct Boot.
Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys. Essential apps can opt-in to run in a limited state after reboot, and when you enter your lock screen credential, these apps then get access your user data to provide full functionality.
File-based encryption better isolates and protects individual users and profiles on a device by encrypting data at a finer granularity. Each profile is encrypted using a unique key that can only be unlocked by your PIN or password, so that your data can only be decrypted by you.
- Verified Boot: Verified Boot is now strictly enforced to prevent compromised devices from booting; it supports error correction to improve reliability against non-malicious data corruption.
- SELinux: Updated SELinux configuration and increased Seccomp coverage further locks down the application sandbox and reduces attack surface. Library load order randomization and improved ASLR: Increased randomness makes some code-reuse attacks less reliable.
- Kernel hardening: Added additional memory protection for newer kernels by marking portions of kernel memory as read-only, restricting kernel access to userspace addresses, and further reducing the existing attack surface.
- APK signature scheme v2: Introduced a whole-file signature scheme that improves verification speed and strengthens integrity guarantees.
- Apps that want to share data with other apps now must explicitly opt-in by offering their files through a Content Provider, like FileProvider. The application private directory (usually /data/data/) is now set to Linux permission 0700 for apps targeting API Level 24+.
- To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.
- With Network Security Config, developers can more easily configure network security policy through a declarative configuration file. This includes blocking cleartext traffic, configuring the set of trusted CAs and certificates, and setting up a separate debug configuration.
- To improve device privacy, we have further restricted and removed access to persistent device identifiers such as MAC addresses.
- User interface overlays can no longer be displayed on top of permissions dialogs. This “clickjacking” technique was used by some apps to attempt to gain permissions improperly.
- We’ve reduced the power of device admin applications so they can no longer change your lockscreen if you have a lockscreen set, and device admin will no longer be notified of impending disable via onDisableRequested(). These were tactics used by some ransomware to gain control of a device.