Encryption and Storage Performance in Android 5.0 Lollipop
by Brandon Chester & Joshua Ho on November 20, 2014 8:00 AM EST
As alluded to in our Nexus 6 review, our normal storage performance benchmark was no longer giving valid results as of Android 5.0. While Androbench was not a perfect benchmark by any stretch of the imagination, it was a reasonably accurate test of basic storage performance. However, with the Nexus 5 on Android’s developer preview, we saw anywhere between 2-10x improvement to Androbench’s storage performance results with no real basis in reality. It seems that this is because the way that the benchmark was written relied upon another function for timing, which has changed with Android 5.0.
While we haven’t talked too much about AndEBench, it has a fully functional storage test that we can compare to our Androbench results. While we’re unsure of the 256K sequential and random read results, it seems that the results are equivalent to Androbench on Android 4.4 when a 1.7x scaling factor is applied. However, AndEBench results should be trustworthy as we saw no difference in results when updating devices from 4.4 to 5.0. In addition, the benchmark itself uses low level operations that shouldn’t be affected by updates to Android.
| Androbench Results - Valid vs. Faulty | ||
| Nexus 5 Androbench Results on 4.4 KitKat | Nexus 5 Androbench Results on 5.0 Lollipop | |
| Random Read | 10.06 MB/s | 27.70 MB/s |
| Random Write | 0.75 MB/s | 13.09 MB/s |
| Sequential Read | 76.29 MB/s | 182.78 MB/s |
| Sequential Write | 15.00 MB/s | 47.10 MB/s |
As you can see, the results show a degree of improvement that is well beyond what could realistically be accomplished with any sort of software optimizations. The results for the random write test are the most notable, with a result that suggests the performance is over 17x faster on Android Lollipop, which could not be the case. This required further investigation, and it's one of the reasons why we were hesitant to post any storage benchmarks in the Nexus 6 review.
The other factor affecting the results of the benchmarks on the Nexus 6 specifically is Android Lollipop's Full Disk Encryption (FDE). Android has actually had this ability since Android 3.0 Honeycomb, but Lollipop is the first time it's being enabled by default on new devices. When FDE is enabled, all writes to disk have the information encrypted before it's committed, and all reads have the information decrypted before they're returned to the process. The key to decrypt is protected by the lockscreen password, which means that the data should be safe from anyone who takes possession of your device. However, unlike SSDs, which often have native encryption, eMMC has no such standard. In addition, most SoCs don't have the type of fixed-function blocks necessary to enable FDE with little to no performance penalty.
As a result, we've observed significant performance penalties caused by the use of FDE on the Nexus 6. Motorola was kind enough to reach out and provide a build with FDE disabled so we could compare performance, and we've put the results in the graphs below. For reference, the Nexus 5 (Lollipop) numbers are run using Andebench, while the original values are read out from Androbench on Android 4.4. The Nexus 5 is also running without FDE enabled, as it will not enable itself by default when updating to Lollipop via an OTA update.
As you can see, there's a very significant performance penalty that comes with enabling FDE, with a 62.9% drop in random read performance, a 50.5% drop in random write performance, and a staggering 80.7% drop in sequential read performance. This has serious negative implications for device performance in any situation where applications are reading or writing to disk. Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties.
When the Nexus 6 review was published, I commented that there were performance issues that weren't present on the Nexus 5 running Android Lollipop. Many users commented that the FDE may have been to blame. Like I mentioned earlier, Motorola provided us with a build of Android with FDE disabled. Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display.
To me, the move to enable FDE by default in Lollipop seems like a reactionary move to combat the perception that Android is insecure or more prone to attack than iOS, even if that perception may not actually be accurate. While it's always good to improve the security of your platform, the current solution results in an unacceptable hit to performance. I hope Google will either reconsider their decision to enable FDE by default, or implement it in a way that doesn't have as significant of an impact on performance.
Facebook
Twitter
RSS
91 Comments
View All Comments
MikeMurphy - Thursday, November 20, 2014 - link
A PIN or password lock will keep the contents of your phone safe from 99.999% of thieves. I see no advantage to NAND encryption for consumers except for the most highly sensitive data. I'd rather Google focus more on connectivity encryption and generally protecting online privacy via Tor-like solutions.EyelessBlond - Friday, November 21, 2014 - link
This isn't about security; it's about complying with a California law requiring that phone owners have a "kill switch" for their phone: a way to delete all their data by remote if it gets lost or stolen. The best way to do that is encrypt the data, and if the kill code is sent, the phone securely deletes the encryption keys.sprockkets - Thursday, November 20, 2014 - link
"Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties."You need to read up on how android's encryption work in version 5.0, as the system no longer relies on passcodes for default encryption but 128 to 256 generated keys. This is used REGARDLESS if the user sets a passcode or not, or uses a pattern lock.
Setting a password will be used to re encrypt the key, but is no longer necessary to use.
Passwords are generated and hashed using scrypt multiple times and for devices that support it, the encryption key is signed by a key stored in a protected memory area. Thus, offline attacks against the key are useless.
Come on guys, you are supposed to be at the top of your game.
psyside1 - Thursday, November 20, 2014 - link
All this talk about big resolution is wrong imho. There was devices with S4 pro, and 1200p (nexus 7 2013) which absolutely flies when you enable ART. I have a hard time to believe that gpu 2x faster cant push 1440p, same can be said for S600 - HTC M7 and other S600 based 1080p devices with stock or close to stock Android.JoshHo - Thursday, November 20, 2014 - link
While it's true that this protects against offline attacks, the issue is that it's trivial to turn the device on and pull user data over adb if a password isn't used as well.Brandon Chester - Thursday, November 20, 2014 - link
I'm aware. When I wrote that it's protected by the passcode but that things are encrypted regardless, it was meant to imply that you don't need the passcode for FDE to work. It doesn't change that users aren't really protected unless they put a passcode because someone who gets a hold of your device without a passcode can just access everything freely anyway.sprockkets - Friday, November 21, 2014 - link
OK I see your point, thanks.Laststop311 - Thursday, November 20, 2014 - link
With that kind of performance hit unless you are a terrorist guarding your attack plans the encryption just isn't worth it. The FDE is a good idea though and their first try was a valiant effort. I'm sure with the nexus 7 the SOC designers will have some fixed function in the SOC to fix this problem. I'm happy with my galaxy note 2 still. It's only 2 years old and still does everything I need it to do quickly. I was going to get a note 4 for the 700mhz block a support for t-mobile but now that performance has started to hit a plateau I expect my next phone to last a good 5-6 years and for it to last that long I'm going to wait for 64 bit as I have the feeling later versions of android are going to require 64 bit to run. So if i want to use cyanogenmod to keep my phone up to date for 6 years 64 bit is going to be crucial. I'm sure next fall the note 5 will most likely use the snapdragon 810 for some 64 bit action.If only apple would sell the A8 chip for the galaxy note boy o boy would that be sweet. As much as I hate the iphone apples A8 soc is miles ahead of every other phone soc. The more powerful dual cores is such a better design than less powerful 4 cores as single threaded performance is really what determines the speed of almost every single app. Multi tasking is rarely needed on a phone so having your power budget. spread over 2 cores instead of 4 is just much better in every way. Also the powervr graphics are the best SoC graphics design as well. power vr 6 series consistently slaughters adreno and mali and nvidia can't get their single kepler core design into a phone which is the only hope of dethroning power vr 6 series and their 7 series is around the corner.
What I would love to see happen is nvidia really step their game up and make their next gen erista chip fit in a phones tdp with some rly nice 2nd gen dual core denver cpu's and a maxwell smm for the graphics as this is really the only hope for android to catch up to apples superior soc design. Since maxwell is so much more power efficient than kepler and with efficiencies they can gain in 2nd generation of denver dual core cpu. Nvidia may finally crack the code and remove qualcomm from having the fastest android phone soc. A galaxy note 5 with 2nd gen dual core denver cpu's and maxwell gpu would really be an amazing phone that could finally keep up with apples performance.
tipoo - Thursday, November 20, 2014 - link
Yep. Denver is handicapped by being a process node behind Apple right now, I'd love to see what they can do on the next node.name99 - Friday, November 21, 2014 - link
You mean the node that will be competing against the A9X manufactured on 16nm FF+?Hmm, I think I can predict how that will go down...