Friday, January 13, 2017

Strong androids. How does full-disk and file-by-file encryption in Android – Hacker

article Content

the Smartphone and tablet — ideal collectors private information. It has to be protected from applications with the manners of spyware, Trojans banking Trojans, common thieves, and just overly curious coworkers. Securely it can be done only through encryption, but can available in the Android tools to provide an adequate level of protection? With this article we begin a new series on data protection in Android and today we will talk about resistance built into the OS cryptographic system.

the First full-disk encryption (full disk encryption — FDE) tried to introduce a tablet version of Android 3.0 Honeycomb. Then, together with the 2.6.36 Linux kernel there is the module dm-crypt that provides encryption capability for any block storage device (including NAND Flash). In universal, the fourth version of Android encryption is also available, but for most it remained unclaimed option. Due to the lack of software optimizations and low-speed embedded processors of that time enabling encryption resulted in a decrease in the performance of I / o 6-8 times on top models and 20 times on a budget.

to Fix the situation was only with the advent of 64-bit processors with a separate instruction set for acceleration of cryptographic calculations. Therefore, mandatory encryption in Android was only at version 5.0, pre-installed to the device with the latest single-chip systems.

in the fifth version of Android there was a flag forceencrypt fstab that indicates whether encryption is activated when you first turn on the device. Note: there is a fundamental difference between whether the device is updated to Android 5.x or later, and immediately issued with this version. In the second case, the data encryption will be performed always. In the first option (refresh), it will remain optional and can be disabled by resetting to factory settings (factory reset).

In the General case for full-disk encryption in Android there are three bit strings: the master key, salt and the user pin. Master key and salt are generated automatically, and the pin is entered by the device owner. The role of a pin may also use a password, pattern, or any other “secret” — for the CPU it’s still a bit sequence, and quite short.

strong password encryption

Most user sets a short password on your smartphone or tablet, because they often have to enter it. The problem is that Android uses the same password for all operations, including the unlock screen and decrypting data. App EncPassChanger allows you to set separate passwords and enhance the security of the storage schema of the master key, which encrypted user data. The app works on Android 4.0.3 and above (requires root).


User data is encrypted with a master key, but the salt and the pin are only used to store the master key in encrypted form. So changing the password does not perestroika all data. The key always remains the same (initially generated), and the new password only changes its cryptographic shell. Let us examine this scheme in more detail.

When you first turn on the device with pre-installed Android 5.0 and above generates a pseudo-random 128-bit key. It is called a master key, or DEK (device encryption key). In addition to DEK, is also generated by another pseudo-random 128-bit number (salt), and the user is asked to enter a password.

with the help of DEK in the end all data is encrypted on the user section in /data. It looks like this key, the owner of the device knows. He never enters it and cannot even take regular means.

In earlier versions of Android (prior to 5.0) master key and the encryption settings were stored in a separate unencrypted crypto footer structure (simplified analog LUKS) at the beginning of the encrypted data section. DEX itself is encrypted with another key that is calculated on the basis of the user password and salt.

This method does not protect from brute force the master key to the external computer systems, so in Android 5.0 and above there is a new requirement for device manufacturers to provide hardware-level secure storage of keys. Additionally, DEK has been signed using another key (HBK — hardware-bound private key) specific to this device. He sehardcore at the production stage and not available to any user process.

Sorry, but the article is only available to subscribers

unfortunately, the articles in this issue of the magazine is not yet available for routine sale. To read this article, you must purchase a subscription.

Subscribe to the magazine “Hacker” at the best price

the Subscription allows you for a specified period of time to read ALL paid materials of the site, including this article. We accept Bank cards, Yandex.Money and payments from the accounts of mobile operators. Read more about the project

Already signed up?


No comments:

Post a Comment