Full Disk Encryption in Android
Developing an Android device gets gradually more difficult. As the security threats against Android devices are increasing, Google has adopted FDE since the release of Lollipop, which means Full Disk Encryption. The outline of this feature is like the following.
This illustration shows the coverage of FDE.
Every block disk has to be encrypted as a whole.
In fact, this feature is not new. dm_crypt is one of the key security features in Linux since 2.6 version. As per dm_crypt, it is kind of a device mapper target, so it can see the whole area of a disk and encrpyt the data. It also has a range of advantages compared to its predecessor such as cryptoloop. However, I am not going to go there because it is out of the scope of this article. XTS, LRW and ESSIV are the keywords to understand how dm_crypt works. If you want more information regarding these theory, you might have to find them in another articles. Anyway, what I would like to say is that FDE is not a new technology, but a adaptation for Android to use Linux feature more effectively. FDE uses 128 or higer bits to make a encrypt key. By this key the whole disk will be scrambled and nobody can understand what the data is without the key.
How FDE meets the basic information security
The 3 basic principle in information security is confidentiality, integrity and availablity. It is obvious that FDE can provide these features, and I will elaborate more.
Confidentiality
As the data in a disk has been scambled with a 128 or more bits key which is stored in a hardware security area such as Trust Zone. In this regard, even though an attacker can get the user data from an Android device, the data would be useless unless the attacker obtain the key. However, the key will be place in secured area by hardware, so it is almost close to impossible to get it.
Integrity
Say that a hacker implant a virus in Android device. If FDE is enabled, in the process of decrypting, the virus will be transformed to unexecutable weird data. So simple. So no one can affect to the existing data as long as they don’t have the previlege to access the encryption key.
Availablity
Needless to say that this is of course abled to obtain. Isn’t it?
How it works
- Encrytion Algorithm: 128 Advanced Encryption Standard (AES) with cipher-block chaining (CBC) and ESSIV:SHA256.
OpenSSL will encrypt the master key with 128 AES. And this will be done by user input such as PIN, password and pattern or by a default value. Read Google’s guide for this.
Upon first boot, the device creates a randomly generated 128-bit master key and then hashes it with a default password and stored salt. The default password is: “default_password” However, the resultant hash is also signed through a TEE (such as TrustZone), which uses a hash of the signature to encrypt the master key.
- vold
Because vold can listen to uevent from kernel and it can also communicate with MountService in Framwork, this is the right place to work with FDE. On moounting a new block device it can issue some changes in properties which make init to do encryption or decryption. To read more about vold, visit hereand here you can see the source code.
- Flows
Please refer to the official Android guide.
Questions
- If a user downloaded a video clip to the space on sdcard, are there things to do with FDE?
C Memory Layout
The most confusing thing in memory layout in C is the difference between BSS and Data section. Bear this in mind. BSS is the region for uninitialized global variables, and it will be set to 0 while kernel allocate the area. Of course, Data section is for initialized global and static variables. For more information, please visit here and read the explanation.
Test code to see where the areas take place
#include <iostream>
#include <stdio.h>
using namespace std;
const char rodata[] = "abcdefg";
int bss1;
int bss2;
int data = 0;
int main()
{
cout << "data region starts from " << &rodata << endl;
cout << "data region " << &data << endl;
cout << "text segment starts from " << main << endl;
int stack1;
int stack2;
int stack3;
static int bss3;
cout << "stack starts from " << &stack1 << endl;
cout << "stack " << &stack2 << endl;
cout << "stack " << &stack3 << endl;
cout << "bss area starts from " << &bss1 << endl;
cout << "bss area " << &bss2 << endl;
cout << "bss area " << &bss3 << endl;
}
#
To read more, visit here
Linux IPC
Linux has a broad range of IPC mechanism. The following picture is showing the outline of that. Recently, I had a chance to work with BSD socket and pipe to make a RIL solution for Android. During the development, I found that there are more IPC mechanisms in Linux and they are intriguing me a lot.
Linux IPC
According to the purpose of an application, the proper IPC should be selected considerately.