Wednesday, October 8, 2014

Data encryption in Android reviewed their evolution from … – The Free Android


If something is what we can worry more on mobile devices is the issue of security. It is easy for us to lose a device or stolen and we have access to a set of data that does not wish to share.

Google has set to work on improving their safety, and already committed L to bring Android data encryption enabled by default. But let you see it with the help of Nelenkov with a little more detail how it has evolved Android in this topic .

It was not until the 3.0 version of Android which was introduced full disk encryption (now FDE).

How does the FDE work?

The FDE Android uses dm-crypt framework to implement a Linux transparent disk encryption for user data partition (/ data). As soon as encryption is enabled, all writes going to the drive are automatically encrypted before carrying out the process and all readings decrypted when read.

The encryption key disk ( master key ) is 128 bits and is generated randomly, password protected lock screen. Encryption is used for AES in CBC mode.

The structure of encryption parameters

Android also uses a structure called crypto footer , which stores all encryption parameters. It is very similar to LUKS, but simplifying and omitting some features (only stores a copy of the master key and has other features such as the option to recover the whole key after it has been deleted from disk Thanks to the encryption key or segment also omits the checksum of the master key ).


The brute force attack

All the above encryption is considered relatively safe. But since it is an implementation software, so if the master key is sufficiently long and complex, a brute force (try key nonstop) could take years.


But, Android chose to use the PIN or password unlock, which are up to 16 characters . This leads to A brute force attack could break the FDE Android 1.0 . Yes, it is true that computer calculation shows that a mobile device is more limited, but that does not mean we can not have a copy of the encrypted footer and partition user data and perform the attack from a machine much more powerful, especially since we also use the GPU instead of the CPU.

With this you can see that with a NVIDIA GeForce 730M, retrieve a 6-digit PIN can be achieved in less 10 seconds (4 hours in the case of letters). So sure was he? It seems not …


It was not until Android KitKat (4.4) when really FDE evolved . The most important came from the hand of replacing PBKDF2 with scrypt especially hard on GPUs because it requires a lot of memory. So now executing tasks in parallel on GPUs is not as feasible, which leads to a brute force attack will take much longer.


Nevertheless, the size of the master key remains the same, as well as how disk encryption sector. All this leads to reinvent process a little brute force, and in this case thanks to Linux FDE Bruteforcer Python has also managed to crack the key, but in this case we need almost 5 minutes for 1200 PIN combinations .

Therefore, remains feasible decrypt the master key , especially when we do not put much emphasis on complicating blocking password screenshot.


And now comes the turn of the preview version of Android L, which also brings changes to the encryption disk. The first novelty is that Version footer encryption has risen to version 1.3 , which uses a new KDF (instead of PBKDF2 or scrypt), but mode disk encryption and key size have not changed


However, functionally The main novelty is that no longer need to assign a PIN or password to unlock screen , so it is very likely that the master key no longer KEK derived from them.


In this case, Android has supported QSEE ( Qualcomm Secure Execution Environment ), which offers a credential store compatible with most recent devices using hardware Qualcomm SoCs. Thus seems KEK is stored in hardware. Even so, it can still use the password unlock screen (with scrypt ).

As Android is still in prelaunch L phase, sure we have much to discover yet. However, evidence now suggests that there has been a substantial improvement in data encryption disk by Google .

Although there is something we must give virtually certain We will not be 100% sure of our data protection, as well as working on improving ciphers, also-finding that improved working on getting break existing



No comments:

Post a Comment