Android 7.0 (Nougat) brings a lot of new interesting security features such as:
- Direct Boot
- Key Attestation
- Network Security Configuration
- Scoped Directory Access
- Media Server Hardening
All of these topics are very interesting from a security perspective. However, in this blog post we will solely focus on Direct Boot.
Motivation
There are apps, which should be available directly after booting the device. A good example is already provided in the Android examples – the alarm app [1][2].
Imagine you prepare an alarm to wake up earlier next morning (e.g. to not miss Swiss Cyber Storm). Unfortunately, the device crashes in the night and you would be late on the event, because after restarting the device it remains locked, requiring the passcode for the full-disk encryption.
This is, where Direct Boot comes into play. Direct Boot allows encrypted devices to boot straight to the lock screen (Keyguard is also Direct Boot aware). Therefore, the alarm will still be triggered after the reboot in Android Nougat.
Quick Intro: Trusted Execution Environment (TEE)
Since the Android Compatibility Definition Document (CDD)[3] for Nougat is not officially released yet, we can only speculate whether the document will change the STRONGLY RECOMMENDED to REQUIRED requirement for TEE. As it is likely to happen though, let us assume TEE is required.
The Trusted Execution Environment (TEE) is ARM’s TrustZone for popular mobile devices. TEE establishes a trusted environment, which is separated from the untrusted Android environment and its OS. This concept is very similar to the iOS security enclave, where the regular OS and components cannot access the protected memory directly. The same principle applies for the TrustZone / TEE. Note that there are are a few differences in its implementation, e.g. Android does not require a fully isolated core.
[4] TEE architecture
TEE can be used to store various secure applications similar to smart cards (JavaCard applications). In the context of Android such a secure application is the KeyMaster, where keys are stored securely and crypto-operations take place. Therefore, the untrusted zone can not access the private keys.
[5] KeyMaster in TEE
Full-Disk Encryption
Full-disk encryption is used to protect the internal and external memory (SD-card). An appreciated property is that the used key material for full-disk encryption is bound to the hardware. As you already expected, TEE is used to bind the scheme to the hardware. Additionally, the user has to provide a passphrase, which is also added to the full-disk encryption scheme in order to prevent attacks from a locked mobile device.
[6] Full-disk encryption scheme prior to Nougat
Direct Boot Storage Types
In Android Nougat the encryption scheme is not used for the whole volume anymore but is now file-based, which gives performance benefits and is based on ext4 encryption involving TEE [7]. Android distinguishes between two storage types:
- Credential encrypted storage (CE)
- Device encrypted storage (DE).
The first storage type was present in all prior Android releases. Device encrypted storage is the newly introduced storage type. There, the storage is solely protected using the hardware-bound key from TEE. All device encrypted storage data is added to /data/user_de/ and isolated from the user related credential encrypted storage in /data/user/. Since the decryption key cannot be derived without the user provided passcode an app in the DE-context cannot access data from the CE-context. There are further filesystem isolations in /data/misc and /data/system:
Direct Boot Pitfalls
There are various security pitfalls with respect to Direct Boot, which could lead to access of sensitive files by malicious apps in a multi-user context (shared device):
- Insecure file permissions
- Insecure data storage
Both aspects appear as M1 – Improper Platform Usage and M2 – Insecure Data Storage in the OWASP Mobile Top Ten 2016 [8]. Since they are ranked as the two most frequently occurring security issues, we will probably see these application specific vulnerabilities in the context of Direct Boot in the near future.
App developers need to carefully plan where to store data. Confidential and user-specific data should never be stored in the DE storage. Migration of data from CE to DE storage has to be thoroughly analyzed and file permissions set as restrictive as possible.
Sources and References:
[1] https://github.com/googlesamples/android-DirectBoot
[2] https://developer.android.com/training/articles/direct-boot.html
[3] https://source.android.com/compatibility/cdd.html
[4] https://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
[5] https://source.android.com/security/keystore/
[6] http://bits-please.blogspot.ch/2016/06/extracting-qualcomms-keymaster-keys.html
[7] https://source.android.com/security/encryption/file-based.html
[8] https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
Leave a Reply