Cloud native EDA tools & pre-optimized hardware platforms
By: Biswanath Tayenjam, ASIC Digital Design Engineer and Licinio Sousa, Technical Marketing Manager
Mobile storage security is vital as users are storing more sensitive data in flash memory on their mobile applications such as digital cameras, smart phones and tablets. The Joint Electron Device Engineering Council (JEDEC) has developed two storage interface standards for such mobile applications: embedded Multimedia Controller (eMMC) and Universal Flash Storage (UFS), both of which can use inline encryption to secure data. eMMC offers reliability, throughput and support for fast boot in mainstream mobile applications, and UFS adds significant performance and power features for high-end mobile applications.
In a smart phone, the eMMC or UFS - is divided into two partitions:
Figure 1 shows the partitioning of a 32 gigabyte (GB) internal memory, out of which 25.23 GB is available for device storage and the remaining for storing the operating system (OS).
Figure 1: Android device’s internal storage partition shows that the majority of space is used for personal data that should be kept secure
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.
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.”
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.
Figure 2: Mobile Storage Host Controller IP with built-in cryptographic engine
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.
Figure 3: 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 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:
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.
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, 草榴社区 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.