eMMC and UFS Inline Encryption in Android-Based Mobile Applications

Since much of the internal mobile storage device is used to store user data, which can be personal and sensitive, security like encryption becomes one of the most required features. This article describes how the eMMC or UFS host controller inline encryption function performs security tasks in Android-based applications. 

Software Encryption vs. Hardware Inline Encryption

Today, breaches into our private data are occurring more than ever, forcing OS developers to adopt cryptographic methods to support data storage encryption such as file-based encryption and full-disk encryption.

Software-based encryption solutions use the main system processor to perform encryption and decryption tasks. While this approach provides a decent amount of performance, it falls short due to the need for continuous improvement in storage speed. To overcome performance degradation, standard bodies such as JEDEC are adding hardware-based inline encryption capabilities to the host controller. Inline means the hardware cryptographic engine is inside the host controller (Figure 2), and encrypts and decrypts the data on the fly. Processing large volumes of secure data with the inline hardware encryption engine provides better real-time system performance by reducing latency and offloading the main processor. However, hardware inline encryption or software encryption can co-exist in the same application. Hardware inline encryption addresses symmetrical, bulk encryptions and software encryption addresses authentication, keys and file name encryptions.

Encryption in Android Devices

Data storage encryption is optional in Android devices without a secure lock screen. However, an Android device with support for a secure lock screen can enable data storage encryption of both private application data and shared application data. Android has two methods for device encryption: full-disk encryption and file-based encryption. eMMC and UFS host controllers support a variety of encryption algorithms to enable both methods, as shown in Figure 3. 

Full-disk encryption was partially introduced in Android v4.4, and fully introduced in Android v5.0. With full-disk encryption, all the user data on an Android device is encoded using an encryption key. Once a device is encrypted, all user-created data is automatically encrypted before writing to the disk and all reads are automatically decrypted before data processing.

Full-disk encryption uses a single encryption key to protect the data. The disk encryption key is protected with the user’s device password. The encryption key must not be written to storage at any time without being encrypted. In Android devices, full-disk encryption is based on the Linux Kernel feature dm-crypt, which runs at the block device layer. Therefore, encryption works with eMMC or UFS devices that present themselves to the Kernel as block devices.

Upon boot, the user must provide their credentials before any part of the disk is accessible. While this is great for security, it also means most of the core functionality of the phone is unavailable until the user provides their credentials. Because access to user data is protected behind the user credentials, features like alarms, accessibility services and phone service are unavailable. Full-disk encryption uses Advanced Encryption Standard-Cipher Block Chaining (AES-CBC) for encrypting the primary key and AES-CBC-ESSIV (Encrypted Salt-Sector Initialization Vector) for encrypting the data.

Android 7.0 and above supports another cryptographic method called file-based encryption, which encrypts different files with different keys that can be unlocked independently. Devices that support file-based encryption can also support a new feature called direct boot, allowing encrypted devices to boot straight to the lock screen without asking for user credentials, thus enabling quick access to core device functionality such as accessibility services and alarms.

In a device using file-based encryption, each user has two available storage locations:

• Credential encrypted (CE) storage - Is the default storage location and is available only after the user has unlocked the device using their credentials
• Device encrypted (DE) storage - Is the available storage location during the Direct Boot mode and also after the user has unlocked the device; the DE keys are cryptographically bound to the device's hardware root of trust

Direct boot-aware applications can access DE storage but can only access CE storage after the user has unlocked the device by providing their credentials. With file-based encryption, applications like alarms and phone services can still operate within a limited context even before the user provides the device password. In file-based encryption mode, the file contents are encrypted using AES-XTS, while file names are encrypted using the AES-CBC-CTS (ciphertext stealing) mode.

For Android, the keys protecting CE and DE storage locations must be unique and distinct, and cryptographically bound to a hardware-backed keystore in the trusted execution environment.