Full disk encryption isn't really that much of a big deal for the average user on a lot of modern mobile SoCs. The messaging of this is a lot worse than the security implication in practice.
Full disk encryption doesn't protect you against most 'normal' security attacks like privilege escalation, because once an attacker has gained that privilege they can read any data off the mounted encrypted file-system.
The way FDE works is that you're encrypting the blocks stored on the physical storage eMMC[1], so if someone gets their hands on your device and physically tampers with it, in theory, with enough skill and fiddly soldering and wiring to an SD card adapter you could access the data.
However, many SoCs stack the eMMC on top of the application processor directly, look up package on package or "POP". This means you can't even access any pins to wire up an adapter without "extremely" specialized equipment. We're talking about slicing a layer off the chip package without damaging it.
[1]I've left out physical SDcards because until recently there was no facility to encrypt you data in a cross platform compatible way on these devices. Android treats SDcards as plain unencryted FAT/exFAT storage by default anyway.
It can be hard to gauge public opinion from the HN echo chamber, but the apple case is causing national awareness of this important issue. The real question is: will consumers make decisions in the next 6, 12, 24 months based on the information they hear about these devices? I'd like to say yes, but i suspect the answer is no.
Whereever the user wants it to. You're essentially saying the users of those tablets shouldn't be able to protect them just because you can't see a usecase beyond "only children are using it".
There are lots of other tablets. The Fire Tablet team has a finite amount of developer time to build features for their target users. Encryption is clearly not a feature they feel it's worth working on.
With security features it's probably better to drop them rather than implement them poorly.
FireOS is a heavily skinned Android. That's it. Supporting it is free as FDE is built into Android.
As someone else said, this is probably becauase their hardware is somewhat lacklustre (it's a $50 tablet, after all) and therefore the performance hit was hurting the end user experience to an unacceptable level.
Meh. For me this is such a non-issue. While very privacy-conscious in general, since my very bad experience with an encrypted backup drive, a lost password/passphrase, and losing 2 years of data/photos as a result, I've cooled on full-device encryption.
Sure, it's preventable, and it was my own stupid fault, but I bet it happens to a lot of people and it caused them, and Amazon, more heartache than the added level of 'security' encryption would provide. "What do you mean, you can't retrieve my data? You made this thing! Can't you reset the password?"
This isn't a bad point. It's also worth noting that as a whole android hasn't been the most secure, and fde only works while the phone is off or storage is unmounted which may be important for some but most average users don't really ever turn the devices off. So if you're running fde and you get a stage fright driveby, it's fornaught.
Making a device more secure when it's off has marginal utility to most customers that aren't on hacker news. And those customers probably don't outweigh the support issues associated with FDE for everyone.
> French parliamentary deputies, defying government wishes, on Thursday voted in favour of penalising smartphone makers
who fail to cooperate in terrorism inquiries
> Claiming users weren’t using the encryption feature, and therefore that encryption is unnecessary, is of course a disingenuous argument on Amazon’s part. Users also hate using strong passwords — is Amazon going to encourage users to ditch those too?
I think it's TechCrunch that's being disingenuous here. Disk encryption is a feature, and has performance, maintenance and UX costs, unlike allowing strong passwords.
Since this is now front page and last night's thread on this has fallen off, I'll repost what I said there, supporting the theory that encryption might actually have been turned off for performance:
People unfamiliar with full-device encryption on Android devices need to be aware of the following: until Marshmallow, it was SLOW. It was so bad that while Google recommended turning on encryption by default on Lollipop, they had to back off of the recommendation because full-disk encryption made the devices run like crap. [0] The reason suspected for this is that up to and including Lollipop, Android handsets did not support hardware-backed encryption/decryption, which meant it all had to be done in software.[1] This had the end result of putting huge overhead onto the device once FDE was turned on, and over time its performance would continue to degrade. Anecdotally, I tried encrypting my HTC One M7 a few years ago when it was my daily driver, and I eventually I had to factory wipe the damn thing to turn it off. The overhead with encryption on got so bad that I would periodically turn on the screen, and it would take so long for the phone to respond that the auto-idle would turn the screen back off before I was even presented with a lockscreen!
The M7's specs were top shelf in 2013. Given the limited specs of Amazon's cheaper tablets, I would not be surprised if encrypting them could slow them down further to the point of being unusable.
> What I find quite strange is why no Android device seems to use a dedicated hardware encryption module to reduce overhead like iPhones have had since the 3GS.
Is there a source to confirm iPhone is equipped with HSM? One theory is the low-end devices want to reduce cost, and furthermore, Android devices are manufactured and sold by more than one company. But you can argue the weakest will eventually participate or die.
The phone itself. All of the encryption is done in hardware, not just for performance, but for resistance against physical attacks. The dedicated processor is nothing short of Fort-Knox-like if that paper is to be believed fully.
Well it was all over the news - the Secure Enclave uses a special chip with a unique encryption key hard burnt into it. It encrypts everything that is encrypted on the iPhone, and uses a different key for each app I believe.
iOS always include hardware accelerated components for various tasks, for example voice, video encoding are super fast on iOS and super slow on high end androids. Androids traditionally doesn't have any hardware acceleration modules.
I find this argument flawed. Why only now are they are removing encryption when hardware is getting more powerful and storage getting faster(read/writes).
As another reader pointed out Amazon tablet hardware as also plenty powerful.
Google does not control the Android hardware market so if someone wanted to make a phone using a slow processor which did not support hardware encryption(Qualcomm processors do...no one uses it though) they can but performance would be brutal with encryption on.
Amazon controls everything in their ecosystem. They could make the hardware to go with the software.
It's very possible that this never registered high enough on the list of problems to deal with. It's likely that there are very few kindle fire owners that use the encryption.. which is what they say.
The only reason I agree with you is that, if the hardware is the problem.. then why not just say that?
Then this begs the hypothetical question, 'If even only one person used encryption out of all of the devices sold, is it a feature worth keeping?'
I think most people here would say 'yes'.. but would most average company executives?
I don't like the idea that there is no way to freeze the build to avoid the un-encryption and or the possible bricking of a couple kindles for the few that used it however.
It's one thing to say, we don't support this going forward so if it's something you use get a different device next time. It's another to say, we are disabling or bricking, your choice.
When you're selling devices for $50, margins are tight. It is possible the encryption was slowing down the system so instead of adding HW to deal with it, they just simply turned off the feature.
I like your analysis until you start to posit that you don't necessarily need to secure information on a book reader. Since you can browse the web and the book reader is a pretty full featured computer there may be banking information or even browsing history that I would want to keep secure or confidential.
> "As an aside, what sort of confidential information are you likely to keep on your book reader, anyway? Or the $50 toy you bought to keep your child quiet during the upcoming road trip?"
Kindle Fire tablets aren't really a 'book reader' any more than an iPad is a 'book reader' (perhaps you're thinking of the eInk versions of the Kindle, such as the Kindle Paperwhite). Kindle Fire tablets can be used for anything a standard tablet would be, so to answer your question... Any web browsing or email content you'd rather not share with the government or hackers.
I was referring to the Kindle readers. But you are correct, the features were removed specifically from the tablets, not the readers. I've edited my post to remove that. Thanks for the correction.
After using encrypted Android devices since 4.0 or so, I find your post a bit misleading. Yes, you do lose performance in benchmarks, but the devices themselves (about 15 or so I've dealt with, mostly branded with Nexus and Samsung brands) did not severely degrade as you're trying to say. They were a bit slower, but not in a way a passerby would notice without actually putting two together.
I think there may be different factors at play. First of all, the availability of hardware instructions for encryption primitives. Secondly, some flash controllers compress data before it is stored in NAND cells, to reduce write amplification and to improve read/write throughput. Since encrypted data is high-entropy, it does not compress well. Performance takes quite a dive on such controllers.
That said, I used FDE on my Moto X 2014 with Lollipop and it worked without any problems or noticeable slowdowns. But typically Kindle has far more low-end hardware.
>they had to back off of the recommendation because full-disk encryption made the devices run like crap.
This isn't true of all android, just the N6 which was having issues with not having hardware acceleration enabled.
If OEMs want fast crypto they have to do what everyone else does: use methods that work with hardware acceleration and put that hardware in the devices.
"Apparently, Google has not merged the various drivers that optimize Qualcomm's QCE module for encryption and decryption into AOSP. The generally-assumed reason is that this code is proprietary. Without these optimizations, the Nexus 6's hardware decryption module on the Snapdragon 805 is essentially hamstrung."
This is odd. I had FDE enabled for quite some time on my old Nexus 4 (and now on a OnePlus One) and I've not experienced any performance degradation after I turned it on.
Maybe I was lucky and both phones support hardware acceleration for the relevant crypto primitives.
I would disagree with your theory. Encryption was removed because Amazon discovered virtually no one was using it and the costs associated with supporting it wasn't worth the cost.
Yes, it was done for performance! This was obvious once you look at the tablet offerings Amazon has now, none of which are designed for anything more than consumption.
The tablet offerings they have now? Their tablets have never been designed to be anything other than an Amazon store client, which I wouldn't mind too much if the Amazon app store weren't such a wasteland.
I got one for the sole purpose of access to the amazon instance library for my daughter since it wasn't an android offering at the moment.
I tried to use it as an android tablet, I was able to come up with most of the apps needed but in the end it was little things like lack of configuration that just made it useless to me. Not being able to change the keyboard and such.
Now it's only used by my daughter for content and solarium mobile.
