The overall data encryption function has appeared in the era of Android 3.0, but Google did not enable this function by default until the Nexus 6 in 2014. The biggest reason is that this function has an impact on the reading and writing performance of mobile phone memory. As for the impact of performance, please see our test.
In the previous evaluation of devices running Android 5.0, our regular eMMC read-write test yielded abnormal results. Take the Nexus 5 running Android 5.0 developer preview. After using Androbench to test the memory read-write speed, The results under Android 5.0 have improved by 2~10 times compared with the results under Android 4.4. After in-depth exploration, we found that the main reason for this problem is that the software Androbench we used for testing is a time algorithm in the Android system when calculating the results, which is different from the algorithm in 4.4 and 5.0.
So we used another software, AndEBench, for testing. Its functions are similar to those of Android, but this software itself uses low-level operation instructions, so the upgrade of Android from 4.4 to 5.0 has no impact on the results of this software.
In addition, during the evaluation of Nexus 6, we found that the Nexus 6, which is native to Android 5.0, enabled Android's Full Disk Encryption (hereinafter referred to as FDE) by default when it left the factory. This function first appeared on Android 3.0, but Google did not enable this function by default until the 5.0 system. When FDE is enabled, all data written to memory will be encrypted before writing, and encrypted data read from memory must be decrypted before processing. The key to decryption is naturally the lock screen password set by the user, which means that no one can read the data in the phone without a password after getting the phone.
However, the FDE function on Android phones is different from that on SSDs. The FDE function on SSDs often has native hardware support, while the eMMC chip used on mobile phones did not add this module at the beginning of design, and most SoCs do not have hardware level support for FDE. If the support of hardware modules is added at the beginning of SoC design, the impact of FDE on performance is minimal, or even negligible.
So all of this is explained. On the Nexus 6, which has FDE enabled by default, we found a very significant decline in read and write performance. After brushing the firmware released by Motorola that does not have FDE enabled by default, we compared the test results of the two. In the comparison, we also added Nexus 5.
In the chart, the data of Nexus 5 (Lollipop) is tested by AndEBench after upgrading to 5.0, and Nexus 5 is the score under 4.4. It should be noted that Nexus 5 will not automatically start the FDE function after upgrading to 5.0 system via OTA or by brushing image package.
From the above test results, it is easy to see that FDE implemented by software will lead to serious degradation of reading and writing performance: random reading performance will decline by 62.9%, random writing performance will decline by 50.5%, and sequential reading performance will decline by an astonishing 80.7%. As long as the user lets the mobile phone read and write to the memory, The impact of FDE on performance is visible. In addition, Google's default opening of FDE may not be very helpful to improve the security of users' actual use - after all, users' usage habits are very important in security. In addition, the encrypted data on Nexus 6 is only protected by passwords or gestures. If no password is set, Then FDE is a device in terms of security, which is useless except for affecting the performance.
When evaluating the Nexus 6, I also found that the Nexus 6 has a performance problem in some cases, but this problem does not exist on the Nexus 5 running Android 5.0. At first, we thought it might be caused by FDE. However, after the firmware with FDE turned off is flushed, the performance improvement is not obvious, at least not as obvious as the above test, There is still an obvious needle problem in Messenger and Calendar APP, so this problem can only be attributed to the GPU used by the Nexus 6 or the insufficient bandwidth of the processor to cope with the 2K screen.
For me, Google may be justifiable in the current general environment for forcing FDE on the Nexus 6. Of course, it is necessary to enhance the security of mobile data, but at the cost of performance, this simple and crude solution is not desirable. In the future, I still hope that Google will cancel the default setting of FDE, or take other measures to minimize the impact of FDE on performance.
Via
