Android 7.0 Security Features: Direct Boot

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.


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].

DirectBoot Alarm App

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.

DirectBoot Triggered Alarm

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.

REE & TEE Schemes

[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.

Secure Vs. Non Secure World

[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.

FDE Prior Android Nougat

[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:

  1. Credential encrypted storage (CE)
  2. 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):

  1. Insecure file permissions
  2. 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:









Windows Phone – Security State of the Art?

Compass Security recently presented its Windows Phone and Windows 10 Mobile research at the April 2016 Security Interest Group Switzerland (SIGS) event in Zurich.

The short presentation highlights the attempts made by our Security Analysts to bypass the security controls provided by the platform and further explains why bypassing them is not a trivial undertaking.

Windows 10 Mobile, which has just been publicly released on 17th March 2016, has further tightened its hardware-based security defenses, introducing multiple layers of protection starting already at boot time of the platform. Minimum hardware requirements therefore include the requirement for UEFI Secure Boot support and a Trusted Platform Module (TPM) conforming to the 2.0 specification. When connected to a MDM solution the device can use the TPM for the new health attestation service to provide conditional access to the company network, its resources and to trigger corrective measures when required.

Compared to earlier Windows Phone versions, Windows 10 Mobile finally allows end-users without access to an MDM solution or ActiveSync support to enable full disk encryption based on Microsoft BitLocker technology. Companies using an MDM solution also have fine grained control over the used encryption method and cipher strength. Similar control can be applied to TLS cipher suites and algorithms.

Newly introduced features also include the biometric authentication using Windows Hello (selected premium devices only for the moment) or the Enterprise Data Protection (EDP) which helps separating personal and enterprise data and serves as a data loss protection solution. EDP requires the Windows 10 Mobile Enterprise edition and is currently available to a restricted audience for testing purposes.

Similar to Windows 10 for workstations the Mobile edition automatically updates. Users of the Windows 10 Mobile Enterprise edition however have the option to postpone the downloading and installation of updates.

In addition the presentation introduces the Windows Bridges that will help developers to port existing mobile applications to the new platform. While a preview version for iOS (Objective C) has been made publicly available, Microsoft recently announced that the Windows Bridges for Android project has been cancelled. In the same week Microsoft announced the acquisition of Xamarin, a cross-platform development solution provider to ease the development of universal applications for the mobile platform.

The slides of the full presentation can be downloaded here.


This blog post resulted from internal research which has been conducted by Alexandre Herzog and Cyrill Bannwart.

IP-Box – Why a 4 digit passcode is still a bad idea

Up to the iPhone 4, 4 digit passcodes could be brute-forced within a short amount of time – maximum 30 minutes, depending on the passcode. With the iPhone 4s, the Boot ROM vulnerability required to upload a custom RAM disk has been closed thus rendering newer phones immune to this attack.

This is where the IP-Box comes in. The IP-Box is small box which can be ordered with various adapters for iPhones up to the iPhone 6 (Plus). The device is powered by the iPhone battery and has a light sensor to detect if the iPhone has been unlocked. The box comes at a price tag of around CHF 250, including the iOS8 adapter.

While there is only sparse documentation available for the box itself – most of it being in Chinese – Detective Cindy Murphy from the Madison Police Department created a manual which serves as an excellent starting point (iP-BOX: Breaking Simple Pass Codes on iOS Devices).

There are several modes of operation for brute-forcing the passcode. Besides the obvious sequential counting from 0000 to 9999 or from 9999 to 0000, the software allows for different pattern-based attacks – i.e. birth dates, patterns or ordered lists – slashing the time needed to crack the code.

Compass Security ordered the Box and tested if it lives up to its expectations. The hardest part of cracking the passcode was actually opening our test devices where the iPhone 5 actually resulted in a broken suction cup.

The first test subject was an iPhone 4 running iOS 7.1.3. For iOS 7 the device luckily does not need to be opened, the IP-Box and its light sensor can be attached and the device is ready to get pwned. The passcode can even be cracked if the phone is in the disabled mode. This state normally would no longer allow manually entering passcodes and requires the iPhone to be connected to iTunes to get it back to a working state.

We set the “Each group of data interval (ms)” to 4500 while leaving the “Stop while the brightness changes” and “Each time interval bit (ms)” at their respective default settings. We found that faster passcode guessing rates lead to unsuccessful passcode tries. With the above settings the box managed to enter 1 passcode per 6 seconds which means that in the worst case, cracking a 4 digit passcode would take about a day on an iOS 7 device.

As our video shows, the IP Box was not overly impressed with the fact that the iPhone 4 was disabled.

The second and third test subjects were an iPhone 4s and an iPhone 5 each running iOS 8.1. This is the last version currently supported by the IP Box. With iOS 8 a special adapter is needed and the device needs to be opened in order to disconnect the iPhone’s battery and connecting the IP-Box directly to the power connector of the device. This setup allows the IP Box to aggressively cut the power supply, preventing the iPhone from increasing the counter on failed passcode attempts.

Since the iPhone restarts after every passcode guessing attempt, in addition to the parameters used on the iOS 7 device, a startup power delay needs to be configured. In our tests we chose a delay of 15 seconds, but the delay could be decreased to 7-8 s, since the IP Box is only powered on, when the iPhone is running again.

The time required per passcode try largely depends on the time the iPhone takes to restart. We determined the startup times of the different devices as follows:

  • iPhone 4s: 48s
  • iPhone 5: 29s
  • iPhone 6: 27s

Brute-forcing a 4 digit passcode on an iOS 8 device will thus take between 3.5 and 6 days depending on the hardware.

The following video shows a successful passcode recovery on an iPhone 4s running iOS 8.1

Unlike iOS 7 where a phone can be disabled and the retrieval of the passcode is still possible, iOS 8 does no longer allow brute forcing the passcode on a disabled device. So make sure not to manually enter codes before unleashing the IP-Box on the iPhone.

Our tests lead to the conclusion that a 6 digit passcode already greatly improves the security of your iPhone. Running iOS 8 on a modern phone it would take about a year in the worst case to retrieve the passcode compared to the 3.5 days of the 4 digit code. If you are using a passcode with numbers and special characters while avoiding words from a dictionary or personal data such as the birth date, name, address or similar, it is currently virtually impossible to retrieve the passcode within a reasonable time frame.

This blog post resulted from internal research which has been conducted by Michael Fisler and Cyrill Bannwart in April 2015.

Presentation about Windows Phone 8.1

Earlier this month, my colleague Cyrill Bannwart and I held two Compass Security Beer Talk presentations in Bern and Jona about Windows Phone 8.1 security. The slides are now online and cover:

  • Our (unsuccessful) black box attempts to break out from a Windows perspective
  • A review of the implemented security features in Windows Phone 8.1 from a mobile perspective
  • Our findings around MDM integration, WiFi Sense and the ability to access low level storage APIs

Phone encryption using BitLocker is only possible through ActiveSync or MDM Policy. An individual will therefore not be able to encrypt his phone (unless he’s really motivated to do so).

WiFi Sense is a controversial new feature of Windows Phone 8.1, announced for the desktop version of Windows 10 as well. It allows you to automatically connect to open WiFi networks around you and may share your WiFi credentials with your, Skype and Facebook friends.

Finally, we were able to bypass the Isolated Storage APIs and use low level storage APIs such as CreateFile2 & CopyFile2 to read and export all files stored on the phone within C:\Windows and its sub folders. Note that we were only able to perform this attack on an unlocked device using side-loaded applications. The abundance of dumped files to analyse (over 880 MB in around 10’000 files) certainly offer further opportunities to explore this system’s security.

Further references about WP 8.1

Aktuelle Security Trainings

Web Application Security Training

Die Compass Security hat im Moment im Bereich Web Security zwei Kurse ausgeschrieben. Ein Basic und ein Advanced. Unsere öffentlichen Kurse dauern jeweils 2-Tage und bestehen zur Hälfte aus praktischen Beispielen (Hands-On Lab) und zur anderen Hälfte aus Theorie. Wobei die Doing-Aufgaben in der
Regel eine Schritt-für-Schritt Anleitung sind.

Der Hacker-Angriff erfolgt zunehmend über den Browser auf Web Anwendungen. Durch die grosse Verbreitung der Web Technologie steigt der Bedarf für Sicherheit und die sichere Programmierung. Das Thema beschäftigt nicht nur E-Banking und Online Trading Anbieter, sondern auch Shops mit Kreditkarten Zahlungen, eHealth, eVoting und Anwendungen mit schützenswerten Daten. Bei diesen Seminaren erlernen Sie anhand von Theorie und praktischen Laborübungen im Hacking-Lab die OWASP TOP 10 kennen und können im Anschluss selbst Sicherheitsprobleme aufdecken, sichere Anwendungen schreiben und Security Policies verfassen.

Web Application Security Basic, 03. und 04. März 2015 in Bern (Schweiz)

Web Application Security Advanced, 05. und 06. März 2015 in Bern (Schweiz)

Die Inhalte der Kurse können wir beliebig zusammenstellen. Weitere Themen, die im Moment nicht ausgeschrieben sind, wären:

  • DOM Injections (mittlerweile eine prominente Art von XSS)
  • AngularJS Security
  • OAuth 2
  • OpenID
  • XSLT

Secure Mobile Apps, 23. und 24. März 2015 in Bern (Schweiz)

Mit der wachsenden Verbreitung von mobilen Geräten stehen diese zunehmend im Fokus von Cyber Kriminellen. Mit einem guten App Design und der richtigen Nutzung der Hersteller API sind gute und sichere Lösungen möglich! Doch wo befinden sich die typischen Sicherheitslücken? Die Compass Security AG hat eine verwundbare Training Mobile App für Android und iOS entwickelt, um die Kursteilnehmer anhand von praktischen Beispielen in das Thema „Mobile Secure App“ einzuführen und sie für Self-Assessments und Sicherheitsfragen zu sensibilisieren.

Weitere Informationen sind unter vorhanden.

Falls Sie keinen passenden Kurs gefunden haben, schauen Sie doch in Zukunft unter vorbei. Compass Security bietet regelmässig neue Trainings an.