Security For Android-Based Ecosystem With Mobile Storage IP

By Biswanath Tayenjam and Licinio Sousa

Users are storing more sensitive data in flash memory on their mobile applications such as digital cameras, smart phones and tablets. Because of this reason, the Joint Electron Device Engineering Council (JEDEC) have developed two storage interface standards using inline encryption to secure data: embedded Multimedia Controller (eMMC) and Universal Flash Storage (UFS). For mainstream mobile applications, eMMC provides reliability, throughput and support for fast boot, and for high-end mobile applications, UFS adds significant performance and power features.

In a smart phone, the eMMC or UFS is divided into two partitions – read only and apps and data. The system uses the read only partition to store the Android Operating System, which users can’t program and modify without breaking the phone’s functionality. The apps and data partition stores applications and user data such as documents and multimedia files.

This article describes how the eMMC or UFS host controller inline encryption function performs security tasks in Android-based applications.

What is encryption?
Encryption is a process for encoding data so it is only accessible by authorized users. According to the book ‘Introduction to Cryptography‘ by Barry K. Shelton, “Encryption algorithms or ciphers are mathematical formulas or functions applied to data to transform the unprotected information [i.e., plaintext or  cleartext] into an unrecognizable format commonly referred to as ciphertext. There are generally two inputs to an encryption algorithm: a key and the plaintext itself.  A key is simply a number with a predetermined length. Ideally, each key is truly random meaning that any possible key combination is equally likely and that keys are not generated in a predictable fashion. A strong algorithm and key combination should take at least millions of years to break, based on mathematical predictions.”

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, standards 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 1), 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.

Figure 1: Mobile Storage Host Controller IP with built-in cryptographic engine

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

Figure 2: eMMC and UFS support encryption algorithms for both full-disk encryption and file-based encryption methods

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

Conclusion
Security is of paramount importance because of the increase in hacking and consumers’ use of memory partitions to secure private data in their mobile devices. While operating systems like Android provide software encryption, standard organizations like JEDEC provide encryption and decryption engines inside the host controllers to address security-related tasks. By encrypting data with hardware inline encryption, users of the JEDEC eMMC and UFS standards achieve better system performance. Compliant with the latest JEDEC standards, Synopsys DesignWare Mobile Storage IP solutions include a built-in advanced encryption standard (AES) hardware engine to carry out a variety of cryptographic operations targeting the Android ecosystem.

Licinio Sousa is the technical marketing manager responsible for MIPI and Mobile Storage DesignWare IP product lines at Synopsys.