Details of iOS and Android Device Encryption

swillden writes: There's been a lot of discussion of what, exactly, is meant by the Apple announcement about iOS8 device encryption, and the subsequent announcement by Google that Android L will enable encryption by default. Two security researchers tackled these questions in blog posts:

Matthew Green tackled iOS encryption, concluding that the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).

Nikolay Elenkov looks into the preview release of Android "L." He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device.

Comments

So what you're telling me

[weilawei]

Is that the NSA still has their backdoor.

Re: So what you're telling me

[Anonymous Coward]

It's the password pa$$w0rd

Re:So what you're telling me

[x0ra]

What did you believe ? Who's enough of a fool to believe acronyms agencies will let Apple, Google or Microsoft decide on their own ? Not at this scale. Agencies won't mind if a tech entrepreneur try to get his share of the pie, but he will forever be insignificant. Once he become big enough, he'll join the group as everybody else, just to stay in business because the feds will certainly have found a non-compliance from a dusty law book.

This whole thing is just a marketing show to re-gain the average customer not-so lost trust...

Re:So what you're telling me

[Anonymous Coward]

Where in the summary did you get that? The biggest question I have is the part about Google incorporating hardware-based security since Google controls the software, not the hardware. Are they now dictating that for Android to run a specific hardware protection setup must exist on the devices?

Re:So what you're telling me

[weilawei]

Where in the summary did you get that?

Disingenuous. Try reading TFA. Oh, wait, that's not allowed around here. I'll be off mucking through 20 lines of legacy Perl code as punishment.

Re:So what you're telling me

[Anonymous Coward]

OK, I TFTA. It says that the only reason Apple could "access" the device before is that only certain things on the device were actually encrypted, like mail. Other items like text messages and photos weren't, so simply bypassing the passcode request through custom firmware was all they could do. Now Apple's OS is encrypting the text messages, photos, and so forth, so it really does require cracking the passcode to get in. Offline cracking won't work since part of the key is the device UID and it is loaded into a special part of processor that is hardware designed to not allow it to be extracted. This means you have to use the phone itself to try and crack the passcode, and again the hardware is built to enforce minimum timings on password tries thereby limiting how fast a brute force can happen.

So again, where does this article say that the NSA still has a backdoor?

Re:So what you're telling me

[SumDog]

Possibly, or it may be that Google and Apple are trying to mitigate the blow-back. I remember reading a lot of the Yahoo stuff that got declassified showed that they tried hard to oppose the directive they were given; not that it mattered because we found out later that the NSA tapped their fibre backbones anyway.

I have a feeling that Google/Apple want to go down this route because it will mean that they technologically can't comply with certain NSA letters. Of course, government agencies may already have the means to bypass this. We'll find out eventually.

Re:So what you're telling me

[Noah Haders]

for me, and I think for a lot of /. readers, the biggest issue is comparing a solution that currently exists to vaporware that may exist in the future. The iOS solution is already implemented in the new OS which is on 50%+ of all iDevices after just one week. In contrast, Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.

As a community we've always been skeptical of vaporware, especially when a lagging company announces vaporware in response to an innovator releasing a tangible product. Can we hold android to this standard?

Re:So what you're telling me

[swillden]

Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.

This is true, of course, but it should also be remembered (as Elenkov explains in detail) that Android's encryption features aren't new, they exist in hundreds of millions of devices already deployed. And, L isn't really "vaporware". If you want you can go download it now, though not in its final form. Elenkov's evaluation was based on real code running on his device.

I should make clear where I stand here: I'm an Android security engineer. I work on the hardware-backed crypto infrastructure (the infrastructure that Elenkov says is used in disk encryption for L).

If you'd like me to compare Android and iOS encryption, I'm glad to: Apple's is better. Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS. One thing Android has done better is to encrypt the entire user data partition. With iOS8, Apple has (probably) addressed the issues it had there. I can't talk about future plans, but I will say that I'm not yet satisfied with Android's disk encryption. It's good, but it can and should be better. I'm not sure we can ever match Apple in this area, since Apple has the luxury of focusing on a single device and has complete control of the hardware. But we can get closer.

Can we hold android to this standard?

I would hope so. I do.

Re:So what you're telling me

[Noah Haders]

Thank you for your open response. A Q that you may have addressed elsewhere in the thread: How can Google put out a security solution that relies on a hardware feature, when it has minimal influence on the hardware designs? Does this mean that encryption will work *if* compatible hardware is provided, and if it's not provided the coverage is much weaker? Will the user be informed of this? On what percentage of devices is it expected to have the needed hardware?

kthx.

Re:So what you're telling me

[Rich0]

This is true, of course, but it should also be remembered (as Elenkov explains in detail) that Android's encryption features aren't new, they exist in hundreds of millions of devices already deployed.

I hope that Google plans to actually do better. Android does not support encryption unless you have a screen lock password turned on, and it does not support having the encryption key set to something other than the screen lock password.

Device encryption and screen locking are two different solutions to two different, but related, problems. It can make perfect sense to enable one without the other, and it makes almost no sense to use the same password for both.

The result is that most people don't bother enabling encryption at all, or if they do they use a key which is so weak it is useless.

Google needs to make both settings independently settable, with independent codes. By all means allow the user to sync them, but do not force this.

Re:So what you're telling me

[swillden]

The biggest question I have is the part about Google incorporating hardware-based security since Google controls the software, not the hardware. Are they now dictating that for Android to run a specific hardware protection setup must exist on the devices?

Not a specific hardware protection setup, no. Android defines an abstract API to hardware-backed crypto services, called keymaster, which device makers have to implement. They can implement it in whatever way they like, though AFAIK all of them currently use ARM TrustZone. And not all of them do implement it. If you'd like to find out if your device does go to Settings, then Security, then scroll down to the section on "Credential Storage" and see if it says "Storage type" is "Hardware-backed".

The documentation for the current version of the hardware crypto API is at https://source.android.com/dev...

Re:So what you're telling me

[swillden]

I can't confirm that L is using hardware security for disk encryption. Elenkov decided that we are in his analysis, but you'll have to read his words to decide if you believe it.

However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".

Re:So what you're telling me

[Anonymous Coward]

Billions of Android devices have the encryption capability already implemented. It just isn't turned on by default. Thus, it is not vaporware at all.

Re:So what you're telling me

[stephanruby]

As a community we've always been skeptical of vaporware, especially when a lagging company announces vaporware in response to an innovator releasing a tangible product. Can we hold android to this standard?

A lagging company? The last I heard, it wasn't Android that automatically uploaded naked selfies to iCloud to only have them leak to the public. Also, please note that this encryption feature doesn't even address the original iOS problem. If your phone automatically uploads pictures by default to an insecure infrastructure, then it really doesn't matter if the copy you have on your phone is encrypted or not.

Re:So what you're telling me

[Anonymous Coward]

Devil's advocate (and I could be wrong on this count.) Part of the TLA groups function is not just spying, but the other element. Preventing that country's interests from getting snooped. This is why NIST has guidelines [1] as well as info on the latest exploits that are around.

With the possibility that the other guys may have just the backdoors as the NSA does, it makes upping the ante logical. Better nobody be able to read info than just your enemies. Again, this is pure conjecture, but the NSA/NIST has done a lot of work with security in operating systems and it has helped greatly with security over time, be it the sandbox in OS X, SELinux, OS hardening in Windows so the two main vectors are Dancing Bunnies and browser add-ons.

Android's FDE is woefully inadequate, unless you have root and use an app like EncPassChanger or perform the changes in bash. Then, after you set a real passphrase on boot, the device will be secure (without needing to retype the long passphrase every time.) Apple places all their bets on the magic chip, and who knows if there is a backdoor in that. The chips are fabbed in China, and it would be trivial to add extra functionality to the mask. In fact, since the entire chip is designed in China, baking in added, undocumented "features" like password recovery or even a vector for bypassing signed code is entirely possible, and likely in place.

[1]: Basic stuff, but worth going through on various operating systems and devices to make sure nothing is missed.

Re:So what you're telling me

[mlts]

I wonder if the hardware based security can be used in addition to splitting the passphrase that mounts /data into the long phrase that unlocks the device, and the short PIN to unlock the screen. This way, even though there is protection against brute forcing similar to what Apple has, I am still packing my own parachute with a very long passphrase.

Re:So what you're telling me

[dunkindave]

Billions of Android devices have the encryption capability already implemented. It just isn't turned on by default. Thus, it is not vaporware at all.

No, more like smoke and mirrors. Present but off is an illusion of security.

Re:So what you're telling me

[subreality]

Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS.

Could you expand on that? FDE with a hardware keystore is pretty decent. What more is iOS doing?

Re:So what you're telling me

[Anonymous Coward]

Did you really think that the law that gives NSA access to everything "Made in USA" by a companies in USA can be bypassed ?
If you don't follow the law you can't do business with the government of the USA and you will not be allowed to do any business in the USA.

Re:So what you're telling me

[Noah Haders]

a couple corrections to your inaccuracies (intentional?):
* iphones back up automatically to icloud.
* the exploit in #celebgate #thefappening was taking advantage of weak passwords and/or reset questions. it's not that the infrastructure was insecure, it was user error in selecting weak passwords / reset questions.
* in response apple has widely rolled out two-factor. some people will always set their passwords to be '12345', but at least with 2FA being very easily accessible then people have less and less of an excuse.

Are we good now? kthx.

Re:So what you're telling me

[R3d M3rcury]

The iOS solution is already implemented in the new OS which is on 50%+ of all iDevices after just one week.

I see 47% and holding steady.

Re:So what you're telling me

[Anonymous Coward]

I know you are a troll, but humour me, please tell me specifically what law gives NSA access to everything "Made in USA" by companies in the USA? It isn't the Patriot Act, which includes national security letters. If by law you mean the law of human nature, specifically greed, and by "gives" you mean they can negotiate and purchase access, then yes, that is true, since everyone has their price. Of course, it is also true for the Chinese, Russians, Israelis, Bolivians, Tongans, ...

Re:So what you're telling me

[msevior]

Thank you.
I just checked my LG Nexus smart phone.
It has hardware-backed security.

Re:So what you're telling me

[clam666]

Yeah really. I canot believe ANYONE would think that LEO is all up in arms that now devices are "encrypted" and the kiddie porn will run rampant.

If you're familiar with public relations tactics, these articles are so damn blatantly obvious.

It's a good deal, google and apple who already work with the government anyway, are now allowed to act like their devices are safe, and the govt. can pretend to act like they're styimed and will never break a case again.

Seriously. Is there anyone stupid enough to believe that the govt. allows encryption techology like this without their control? Or that there aren't backdoor protocols?

Name one thing you can have where the govt. doesn't have you bent over. And people believe they either have, or are allowed to have, something they can't access.

Re:So what you're telling me

[amxcoder]

I just checked my GalaxyS3, it says "software backed", so I guess it's not implemented on at least S3's.

Re:So what you're telling me

[Anonymous Coward]

Nexus 4: Hardware backed.

Re:So what you're telling me

[Anonymous Coward]

The iOS solution is already implemented in the new OS which is on 50%+ of all iDevices after just one week.

I see 47% and holding steady.

And just how many Android Devices are running the latest OS?

You really don't want to get into that particular pissing-contest, do you, Mr. Fandroid?

Re:So what you're telling me

[stoborrobots]

I can understand implementing screen locking without device encryption; that's the state my phone currently is in, and it provides exactly the level of protection I require at this point in time - prevents casual snooping or misuse, but does not protect against a dedicated attacker.

Under what situations would device encryption be useful without a screen lock? Your phone data can be read by anyone who gets their hands on it, since the unencrypted data is exposed to anyone who swipes right...

I can't think of any good reason that your screen lock password should be weaker than your device password...

Re:So what you're telling me

[Anonymous Coward]

Don't forget the big tech companies pay cents in the dollar on their multi-billion dollar revenues.

"Say, that's a nice tax loop-hole we've let you play with ... shame if it were to close-up."

Re:So what you're telling me

[CeasedCaring]

It's not up to Google to push out OS updates.
That devolves to the manufacturer & the service provider, both of whom will sit on the update until they manage to fill it with their own bloatware (A process that can take 6 months or more).

Re: So what you're telling me

[Anonymous Coward]

The excuse and where to point the blame is irrelevant in this argument of reality... It matters not. Google vs Samsung whatever, whichever, result is the same,

It is, what it is for end-users. Screwed.

Re:So what you're telling me

[Anonymous Coward]

Present but off is the very best default setting for almost anything. I get to decide what to enable and nothing is forced on me. Hardly "smoke and mirrors", if you show even the slightest interest in learning to operate the device you will find the setting easily.

Re:So what you're telling me

[IamTheRealMike]

However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".

I think it's worth noting something here about the Android implementations. Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology. This creates a secure world inside the CPU which is isolated from the main operating system. The secure world can store data and do computation on the main CPU without being exposed to viruses or root level access from Android itself.

But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits. And in the past this is exactly what has happened, I believe some Motorola device was rooted in this way in fact, because the TrustZone protected program had some kind of overflow bug in it and that was enough to take control of the secure space.

What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games. People keep discovering clever ways to recover secret keys when running on the same physical CPU that shouldn't be possible according to the rules of the sandbox. And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it. After all bad randomness looks the same as good randomness.

The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.

Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple. That takes some bravery. Also, there's more to security than disk encryption. The Apple celebs drama wasn't caused by the NSA breaking disk encryption, it was a bunch of pimply 4-channers phishing or guessing account recovery details on the cloud service. Whilst Apple has historically been ahead of Android in on-device security, they have been behind Google on cloud account security and this is in many ways equally as important.

Re:So what you're telling me

[AmiMoJo]

The NSA/GCHQ won't bother trying to decrypt the phone. They will simply sift through all your emails and text messages that they captured as they were sent unencrypted over the networks. I'm sure they have plenty of custom iOS and Android malware ready to infect you with too. Maybe they even intercept the phone before it gets to you if you order online, like they do with network gear or hard drives.

Re: So what you're telling me

[Anonymous Coward]

Being off might as well be not existing as far as most users are concerned. It's the tyranny of the default.

Re:So what you're telling me

[Dragonslicer]

for me, and I think for a lot of /. readers, the biggest issue is comparing a solution that currently exists to vaporware that may exist in the future. The iOS solution is already implemented in the new OS which is on 50%+ of all iDevices after just one week. In contrast, Google's solution is promised for the next version of Android which will be released on TBD. This version will be used by new devices but likely trickle back to just a small percentage of old devices.

As a community we've always been skeptical of vaporware, especially when a lagging company announces vaporware in response to an innovator releasing a tangible product. Can we hold android to this standard?

You mean something like supporting full-disk encryption, which I enabled on my tablet a couple years ago? If I remember correctly, Android has had full-disk encryption since 4.0, maybe even 3.0.

Re: So what you're telling me

[Anonymous Coward]

I wish more people knew how easy Apple makes it to send encrypted mail with SMIME. It's a function baked into OSX and iOS, totally transparent to use. All you need is a cert, which are available for free online. Maybe if Apple started handing out certs tooâ¦

Re:So what you're telling me

[Anonymous Coward]

You're confusing "the" code with "a" code. Practically any encryption scheme can support multiple keys, and so long as the source for the code is secret and/or unreadable it's impossible to confirm that there isn't an additional decryption key. Given past operations it's likely that even if Google or Apple wanted to they wouldn't be allowed to reveal this sizable security hole.

Re:So what you're telling me

[Anonymous Coward]

Also not implemented in LG G2 (Verizon) models.

Re:So what you're telling me

[Anonymous Coward]

Under what situations would device encryption be useful without a screen lock? Your phone data can be read by anyone who gets their hands on it, since the unencrypted data is exposed to anyone who swipes right...

First of all, I wouldn't want no screen lock, I would want a simple screen lock that blocks after N attempts (then possibly requiring the device key).

Second, to answer your question, device encryption would be useful even without when I can switch OFF my phone before the attacker gets it.

Re:So what you're telling me

[Anonymous Coward]

Slight tangent, but I'm going to go there anyway ;)

The Apple celebs drama wasn't caused by the NSA breaking disk encryption, it was a bunch of pimply 4-channers phishing or guessing account recovery details on the cloud service. Whilst Apple has historically been ahead of Android in on-device security, they have been behind Google on cloud account security and this is in many ways equally as important.

Don't forget that the tools they were using were law enforcement tools designed for this purpose. Anything that can be done to prevent backdoors / third parties holding on to master keys is a good thing in my opinion as encryption should be viewed as protecting one's privacy and not a criminal act.

Re:So what you're telling me

[swillden]

Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology.

Yes, this is correct. The Android crypto HAL (keymaster) can be provided by any "secure" device, but at present I believe all of them use TrustZone, at least on ARM devices (Intel has something similar, but it's not the same).

But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits.

Sure they can. The benefit, though, is that the secure world code can and should be dramatically smaller and simpler than the non-secure world, and therefore amenable to much deeper security auditing. This is actually no different from what Apple does with their security chip... which still runs software written by people and can have exploits. There are some security benefits to being on a truly separate CPU, but that doesn't change the fundamental fact that exploits are always possible.

What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games.

The same issue applies to separate CPUs, and the same countermeasures apply as well, though I'll absolutely grant that it's a harder problem on a virtual secure CPU.

And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it.

All the devices I'm aware of provide a real hardware RNG. The cost is negligible, in fact it would probably cost more to remove it from the SoC designs than to leave it in. However, that still leaves open the question of how good the hardware RNG is. For the next generation of keymaster I'm trying to define some requirements around how it's used that should mitigate many possible weaknesses, and I'm also defining a mechanism that apps can use to inject some entropy of their own, in case they don't trust the RNG (assuming they have a place to get entropy). Note that injected entropy is required to be securely mixed into HW-generated entropy, so it should not be possible to inject data that actually decreases the available randomness, nor to manipulate the outputs, unless the attacker can also manipulate/predict the HW RNG.

The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.

TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.

Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple.

Thanks for the insightful response.

Also, there's more to security than disk encryption.

Vastly, vastly more. It's one very small piece of a large, complex and ever-shifting puzzle. With respect to mobile device security I think it's actually one of the less-important pieces, because the set of problems it solves is pretty narrow. It gets a lot of press and discussion because it's easy to understand.

Re:So what you're telling me

[Anonymous Coward]

As an end-user, why would I care about who device encryption?

Who will take the time and effort to brute force some random person's phone? Even then, what information will they get? Some random person pictures of some obscure person on the internet?

On the flip side, having encryption off makes data recovery so much simpler.

Re:So what you're telling me

[swillden]

I just checked my GalaxyS3, it says "software backed", so I guess it's not implemented on at least S3's.

I'd like to see people using hardware-backed credential storage as a factor when purchasing devices. It would actually take very little consumer pressure to make all devices provide it.

You can be certain that all current and future Nexus devices will.

Re:So what you're telling me

[swillden]

Android's, even without the upgrades in L, is strong enough in many contexts and it'll be even better after L, but still not as strong as iOS.

Could you expand on that? FDE with a hardware keystore is pretty decent. What more is iOS doing?

Unfortunately, I can't expand on it, not until L is actually released. Once the code is available I'll be happy to talk about the pros and cons, but it's not my place to reveal details of unreleased Android code, and I can't usefully discuss the differences without getting into the details. Ideally, a real discussion would be based a deep understanding of the details of both. We'll probably never have that deep insight into iOS, but once L is released we can at least compare known details of L with good guesses about iOS.

Re:So what you're telling me

[swillden]

Who's enough of a fool to believe acronyms agencies will let Apple, Google or Microsoft decide on their own?

As one of the guys who builds this stuff at Google... I am. You can choose what you believe, of course, but keep in mind that excessive cynicism can be just as effective as rose-colored glasses at misleading.

Re:So what you're telling me

[Aaden42]

Most schemes that encipher data with multiple keys make it obvious upon examining the output ciphertext or encrypted session key blocks that the data has been enciphered with more than one key.

With symmetric key algorithms like AES, it’s not possible to encrypt the data with two keys and have it decryptable by only one of them. The exact same key must be used on both ends, and leaking that key would be obvious.

Symmetric ciphers are often used with a session key that’s wrapped by an asymmetric cipher allowing Alice to encrypt something that only Bob can read. The encrypted session key is transmitted along the ciphertext that’s encrypted with the session key. To decrypt, Bob decrypts the key block with his private key to retrieve the session key, then decrypts the symmetric cipher text with the session key. If a message is encrypted to multiple keys, each key creates a separate encrypted session key block. If a message is encrypted to a back door key, the key block is bigger by the length of a key. It’s trivial to examine the output and determine what’s going on.

Re:So what you're telling me

[RyuuzakiTetsuya]

what i find amazing is that in the many years that mobile devices have been common place, no one's yet actually produced evidence that they're being used for nefarious purposes. Just lots of claim and bullshit.

Yes, yes, there's PRISM and god knows what else. But show me a case where the NSA or the CIA or the FBI used a built in backdoor off an off the shelf product.

Re:So what you're telling me

[Anonymous Coward]

Very nice discussion, I have learned a lot just reading your comments. Thanks both!

Re:So what you're telling me

[tlhIngan]

Apple places all their bets on the magic chip, and who knows if there is a backdoor in that. The chips are fabbed in China, and it would be trivial to add extra functionality to the mask. In fact, since the entire chip is designed in China, baking in added, undocumented "features" like password recovery or even a vector for bypassing signed code is entirely possible, and likely in place.

Actually, the chips are designed in the US (Apple has acquired numerous ASIC designers and companies) and fabbed in either the US (Samsung - Texas) or Taiwan (TSMC). It's a part of the A7/A8 processor. In fact, given Apple's fab choices, most of the have been fabbed in either Korea or the US (Samsung's SoCs for the iPhone, iPhone 3G, iPhone 3GS, Apple's design since the iPhone4 using Samsung's fabs).

In fact, if you're claiming Apple's SoCs are vulnerable, that implies EVERYONE's SoCs are vulnerable - the secure enclave is really a fancy name for secure memory and secure encryption processors which you can find in every modern SoC, be it Qualcomm (fabbed in Taiwan), Broadcom (TSMC), NVidia (TSMC), or Samsung (Korea).

And the Taiwanese may refer to themselves as Chinese, but any association with mainland China generally brings up nothing but hatred since the two countries/regions/whatever are quite separate. Fabs like TSMC are very careful because they know they're dead if there's even a hint of Chinese (mainland China) spying.

Oh yeah, Apple renewed their contract with Samsung on their fabs as well.

End result is either every phone is vulnerable (unlikely), or there really aren't any Chinese backdoors. (Because well, Pengu would be out for iOS 8 already)

Re:So what you're telling me

[IamTheRealMike]

TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.

I did not know this. That changes a lot - if even the TrustZone can't access the per device key directly then it would appear to give equivalent security (or actually better) to what Apple is doing.

It would be nice to know which devices implement exactly what kind of security, but it seems everything is heading in the right direction, which is very good to hear.

Re:So what you're telling me

[uniquename72]

I have a question about Android encryption: I've "encrypted" this morning, but I can't tell if it actually worked. Instead of an hour, it only took about 2 minutes. Is there a way to verify that the phone actually did anything?

Re:So what you're telling me

[Noah Haders]

if you're designing the keymaster, who's designing the gatekeeper?

Re:So what you're telling me

[Anonymous Coward]

I have a question about Android encryption: I've "encrypted" this morning, but I can't tell if it actually worked. Instead of an hour, it only took about 2 minutes. Is there a way to verify that the phone actually did anything?

I bet it uses rolling encryption so you can still use the device while it performs and finishes the encryption. TrueCrypt, FileVault, and others work the same way. But then I am not an Android expert so others may say this is wrong.

Re:So what you're telling me

[Noah Haders]

very interesting. this set of articles (the one you linked to and similar ones on other blogs) were all posted late yesterday, around the same time I posted my original comment. I was relying on earlier articles from a week ago saying that ios8 was at 40%+ and growing rapidly. the dangers of extrapolation!

Re:So what you're telling me

[Noah Haders]

apple has had FDE for a long time, but what has changed is apple used to have a LEO backdoor where they could unlock a phone when they physically had the phone in hand and a warrant was provided. I assume all phone makers have this loophole. What apple did with ios8 was close the loophole and take themselves out of the equation. it's actually very little difference for the end user, but a big eff u to the govt.

Re:So what you're telling me

[Anonymous Coward]

if you're designing the keymaster, who's designing the gatekeeper?

That joke is so 1984.

Re: So what you're telling me

[Anonymous Coward]

The Derp is strong with this one!

Re:So what you're telling me

[swillden]

I have a question about Android encryption: I've "encrypted" this morning, but I can't tell if it actually worked. Instead of an hour, it only took about 2 minutes. Is there a way to verify that the phone actually did anything?

What does it say under "Encryption" in Settings->Security? If it says "Encrypted", it is.

If you want confirmation, probably the best way is to enable USB debugging, install adb on a handy laptop or desktop, plug it in, reboot the device and run "adb logcat Cryptfs:V *:S" (the Cryptfs:V means show verbose logs from Cryptfs and the *:S means make everything else silent). Then read the log messages.

There may be a more user-friendly way, I don't know.

Re:So what you're telling me

[swillden]

TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.

I did not know this. That changes a lot - if even the TrustZone can't access the per device key directly then it would appear to give equivalent security (or actually better) to what Apple is doing.

I'd say it could give equivalent security, if it were applied in the right way. I'm not saying it is applied the right way to achieve that in L :-)

It would be nice to know which devices implement exactly what kind of security, but it seems everything is heading in the right direction, which is very good to hear.

It's not too hard to figure that out from looking at device logs with "adb logcat". I'm hoping to get some UI changes eventually to make it more clear without resorting to developer tools. And, yes, I completely agree that it's heading in the right direction -- up to and including a little competition with Apple to see who can lock their devices down the most thoroughly. It doesn't really matter which company "wins" that competition because, like most actual competition between products, the real winner is the consumer.

Re:So what you're telling me

[WuphonsReach]

Thanks, my HTC One (m8) has "hardware backed" security.

My older Asus tablet does not.

Re:So what you're telling me

[stephanruby]

a couple corrections to your inaccuracies (intentional?):

You tell me. Are you intentionally ignoring the claims from this security researcher? Or was your ignorance unintentional?

* iphones back up automatically to icloud.

This point needs some explaining. Which parts get backed up? Plus, I'm not sure how it contradicts what I've said already. Are you implying that the default is not to continue to upload pictures to iCloud once you've uploaded at least one?

* the exploit in #celebgate #thefappening was taking advantage of weak passwords and/or reset questions. it's not that the infrastructure was insecure, it was user error in selecting weak passwords / reset questions.

That's a pretty lame defense. Can you point to an analysis or an explanation to back that up? I've heard the same denial by the CEO of Apple on Charlie Rose, but I didn't believe it. Our infrastructure is secure, is not enough of an explanation. Security is not some binary concept. Security is a very layered concept.

For example, weak passwords can be prevented at the input level (although obviously, not all weak passwords can be prevented, that is why you rely on multiple layers). Accounts can be notified when someone else is trying to get into your account with an incorrect password. Accounts can lock out untrusted ip addresses or untrusted applications when there is the suspicion of a targeted brute force attack on that account. Back up email addresses can be used for password recovery. Even reset questions can be crafted very carefully, and then only unlock an account through the cell phone number of the person in question (after all, all those users who were compromised were iPhone users, so Apple knew their phone numbers).

* in response apple has widely rolled out two-factor. some people will always set their passwords to be '12345', but at least with 2FA being very easily accessible then people have less and less of an excuse.

Didn't they already have two-factor authentication already? If not, the problem is worst than I had thought. Even Twitter, a company widely known for its lack of security, deployed two factor authentication last year (not that everybody is going to use it, but like you said, people will have less of an excuse at least).

Are we good now? kthx.

Security is about hardening the weakest links in the chain. Again, you have nothing to brag about if your phone has the best encryption with all the latest buzzwords that go with it, if all your naked pictures end up on an insecure cloud infrastructure as soon as you take them.

Re:So what you're telling me

[ppanon]

Reset questions - how to turn a semi-effective security system into something that can be hacked by anybody (even Matthew Broderick :-) ) willing to do simple research into your background using publicly-available information. Usually added by systems where the owner doesn't want to hire enough trusted staff to help with password reset.

Most of the time you're better off putting random noise in there that can't be guessed to disable the functionality. It gets really annoying when 2 or 3 typo'd attempts force you to answer those questions, rather than using an exponentially increasing delay timer.

Re: So what you're telling me

[Anonymous Coward]

???? My S5 has an 8 digit screen lock and a diffrent password for encryption

Re:So what you're telling me

[Noah Haders]

* iphones back up automatically to icloud.

This point needs some explaining. Which parts get backed up? Plus, I'm not sure how it contradicts what I've said already. Are you implying that the default is not to continue to upload pictures to iCloud once you've uploaded at least one?

the point is, you make it sound like celebrities were posting naked selfies on the internet and then got hacked. what happened was people took private pictures on their private phones, and assumed that because the phone was in their possession their private photos were safe. they didn't intend to make them accessible online. so stop trying to slutshame them.

* the exploit in #celebgate #thefappening was taking advantage of weak passwords and/or reset questions. it's not that the infrastructure was insecure, it was user error in selecting weak passwords / reset questions.

That's a pretty lame defense. Can you point to an analysis or an explanation to back that up? I've heard the same denial by the CEO of Apple on Charlie Rose, but I didn't believe it. Our infrastructure is secure, is not enough of an explanation.

the point is, the hack was due to a weakness in the security protocols, not a technical exploit of the servers or something. Also the hack was targeted at these people. look up 'spear fishing" when you have a chance.

Re: So what you're telling me

[cronot]

I'd like to bring this discussion down a few notches and ask a more "stupid" question, to which I haven't yet seen a definite answer yet, and it looks like you guys could easily answer that. Sorry if it's a too a stupid question.

What is the performance impact of encrypting an Android device? I'm not talking necessarily about Android L, but any previous version that supports encryption (it was added on ICS, I think?). My concern in fact is with older devices, think 2012 or '13 phones. Are any of such older devices capable of hardware accelerating crypto operations (besides RNG)?

Re: So what you're telling me

[swillden]

Not stupid at all.

The answer is: Hardly any performance impact. It's measurable when reading big files, but not noticeable, even without any hardware acceleration.

When you first encrypt your device, especially on older devices with larger storage, it can take a while. Sometimes up to an hour in really extreme cases. The long time isn't because the encryption is actually slow, though... it's I/O bound, not CPU bound. Reading and re-writing every byte of your storage takes a while. L does some clever things to address this, otherwise everyone would have to wait for 20+ minutes before they could use their phone the first time they turn it on, since L enables encryption for everyone. That would be a bad user experience, so L fixes it, making the initial encryption of a new data partition very fast.

Re:So what you're telling me

[Anonymous Coward]

I prefer Jurassic World.

Re:So what you're telling me

[stephanruby]

the point is, you make it sound like celebrities were posting naked selfies on the internet and then got hacked. what happened was people took private pictures on their private phones, and assumed that because the phone was in their possession their private photos were safe. they didn't intend to make them accessible online. so stop trying to slutshame them.

I was criticizing Apple, not the celebrities. Admittedly, I do not have an iPhone. I only heard second hand accounts of what the iPhone was doing with the pictures.

If what you're saying is correct about the automatic backup, then my original statement about Apple stands.

the point is, the hack was due to a weakness in the security protocols, not a technical exploit of the servers or something. Also the hack was targeted at these people. look up 'spear fishing" when you have a chance.

Finally, you're willing to admit there was some weakness in the security protocols. That's far better than what I've heard the current CEO of Apple admit to.

Yes, I know what 'spear fishing' means in the context of security. And yes, the hack was targeted at these celebrities with iPhones. Had there been a similar security flaw with Android, I have no doubt that the hacker would have found some women celebrities to target on Android as well. It's not like he was targeting just one individual, he was targeting a class of individuals. And he could easily have found the same class of individuals on Android.

Re:So what you're telling me

[Anonymous Coward]

Sony Xperia Z3 Compact: Hardware-backed

Awesome.

Re:So what you're telling me

[Pascal Sartoretti]

a couple corrections to your inaccuracies (intentional?): * iphones back up automatically to icloud.

By default only. Mine doesn't.

Re:So what you're telling me

[Rich0]

Under what situations would device encryption be useful without a screen lock? Your phone data can be read by anyone who gets their hands on it, since the unencrypted data is exposed to anyone who swipes right...

Simple - you keep the phone on your person, and turn it off when you leave it in an unsafe place. You still want to turn off the screen so that your battery isn't wasted, but you don't need locking. You can power off when leaving the phone unattended, giving you the device lock.

I can't think of any good reason that your screen lock password should be weaker than your device password...

Your device password should be difficult for a machine to crack, since it is designed to protect against direct access of the flash hardware. That means it needs a strong password. The machine gets an unlimited number of attempts to guess it, likely measured in many attacks per second if you have lots of rounds, or millions of attacks per second if not.

Your screen password needs to be able to be entered while you're driving in case your screen locks while you're using your GPS. That means it needs to be trivial in length. That isn't a problem, because the software can throttle entry attempts, or even shut-down the device (thus falling back to the device password) after a few failed attempts.

Screen locks and device encryption keys serve two different purposes, even if people often conflate them. They have different threat models and different ways of mitigating against them.

Now, a compromise would be a hard key stored in a TPM with an easy PIN used to access it. The TPM would permanently forget the key after a few failed attempts. However, Android does not do things this way. This would still let you have an easy PIN on boot-up without requiring a screen lock.

Re:So what you're telling me

[RockDoctor]

Memo to slef : don't buy a phone from a company that's beholden to the NSA.

Oh, it's a Samsung. Well, that concern is negated then.

STOP THE VIDEO ADS SLASHDOT!

[Anonymous Coward]

STOP THE VIDEO ADS SLASHDOT!

THEY EAT ALL MY (meager) BANDWIDTH AND RELOAD CONSTANTLY!

I CANT LEAVE A SLASHDOT TAB OPEN WITHOUT HEARING RANDOM SOUND 15 MINUTES LATER!

THIS SITE IS BECOMING UNUSABLE.

IVE NEVER NEED THE REMOVE ADS FEATURE AND NOW THAT I NEED IT I CANT FIND IT. HAS IT BEEN REMOVED?

IVE NEVER USED ADBLOCK IN MY LIFE AND IM GOING TO HAVE TO DOWNLOAD IT FOR SLASHDOT! NEWS FOR NERDS INDEED. MORE LIKELY ILL JUST STICK TO REDDIT, I SEE THE SAME STORIES ON THERE DAYS EARLIER.

sTop it sTop IT stOP IT stOP it StOp iT STOp It stoP IT sTop iT SToP it sTOP it stOp iT stop iT stop IT Stop iT stOp IT StOP it stOp iT sToP IT sToP It StOp iT StOP It sToP iT StoP it STOP it sTop iT STOp It sToP IT stoP It STOP it STop It stoP IT sToP It stoP It STOp It StoP IT sTop It StOp IT stOp It Stop IT SToP It STOp IT stOp IT STop iT SToP It SToP iT SToP IT SToP IT sToP IT stoP it sTOp IT STOP IT StOP IT Stop IT StOp It stOP iT SToP IT stop it StOP it StOp iT StOp iT StOp IT stOP it STOp iT SToP it sTOP it StoP IT sTOp It StOp It sTop it StoP iT StOP iT StoP it SToP it StOP it sTOP iT stop It STOp It sToP it sToP IT sToP IT

random capitalization courtesy of: rANdoM cAPiTalIZATIon GeneraToR

Re: STOP THE VIDEO ADS SLASHDOT!

[penguinoid]

Just get Adblock already. It will spare you bandwidth, and increase your security (and your sanity).

Re: STOP THE VIDEO ADS SLASHDOT!

[Anonymous Coward]

I'm running AdBlock and various script killer extensions and have never seen any ad on slashdot ever.

Re: STOP THE VIDEO ADS SLASHDOT!

[CeasedCaring]

Get good karma on Slashdot, and they'll let you disable ads.

Re: STOP THE VIDEO ADS SLASHDOT!

[Anonymous Coward]

I have good karma, the disable ads option seems to be missing, I mentioned that in my post.

If you can't crack the password, then don't.

[Vellmont]

Presumably, the apps on the phone have access to the encrypted data on the phone, right? So there's a simple solution. The user is happily using their iWhatever. The government sends a Nation Security letter to Apple forcing them to put a backdoor into the phone of the target, such that this app can read whatever data it wants on the phone. So when the user boots up his/her phone, and enters the password, the rougue app should be able to read all the data on the phone.

Can anyone tell me why this WOULDN'T work?

Re:If you can't crack the password, then don't.

[dunkindave]

Presumably, the apps on the phone have access to the encrypted data on the phone, right? So there's a simple solution. The user is happily using their iWhatever. The government sends a Nation Security letter to Apple forcing them to put a backdoor into the phone of the target, such that this app can read whatever data it wants on the phone. So when the user boots up his/her phone, and enters the password, the rougue app should be able to read all the data on the phone.

Can anyone tell me why this WOULDN'T work?

Because National Security Letters cannot be used for that. They can only be used by the FBI to demand the handing over of data in the possession of or passing through the control of the receiver, not the performance of actions (and how the data is produced is up to the company receiving the NSL, not the FBI).

Now what is in the Cloud is a different matter since Apple would have access to that, though again it may be encrypted with a key only the iDevice possesses so Apple wouldn't be able to decrypt it for the FBI.

Re:If you can't crack the password, then don't.

[Anonymous Coward]

Can anyone tell me why this WOULDN'T work?

If your phone does not have auto-update or -download enabled, or is not attached to iCloud at all, then there's no way for Apple to push apps down. While a lot of things can be done automatically on iOS for convenience, you can turn off a lot of it as well.

I'm sure there are potential base band attacks as well, but I'm not sure how closely linked that chipset is linked with the main CPU in iPhones. Probably less linked than most Android phones since Apple uses their own CPUs.

Re:If you can't crack the password, then don't.

[Anonymous Coward]

right, National Security Letters cannot possibly be misused. And, there's an oversight committee to deal with potential infractions, so MISSION DOUBLE IMPOSSIBLE. Pretty sure it's against the law to decrypt stuff too according to the DMCA, so scotch that idea as well. Shit, this stuff really is secure. Thanks dunkindave@nsa.gov for alerting us to our complete security and Freedom(TM) thanks to this irresistible encryption feature which we will all now rely upon until the bitter end.

Re:If you can't crack the password, then don't.

[Vellmont]

They might not use an NSL, but I wouldn't count on it. The other blunt instrument the government has at it's disposal is the
Authorized use of Military force, which doesn't even mention surveilance or data and is about military force, but which the government has cited in its warrantless wiretapping when sued by the http://en.wikipedia.org/wiki/A...">ACLU. Kind of a stretch, but the government has long tried to get away with whatever they want and let the courts rule on it later.

So I have no problem beliving the US goverment wouldn't try some crazy interpretation of a statute never inteded to give them the power to do that, but which they'd hope the courts would take years to rule on.

Re:If you can't crack the password, then don't.

[iluvcapra]

The user is happily using their iWhatever. The government sends a Nation Security letter to Apple forcing them to put a backdoor into the phone of the target, such that this app can read whatever data it wants on the phone.

It's impossible to cut a hardware vendor out of the trust system, unless you audit the hardware of your device. But set this aside.

This won't work because apps never see your password or have access to the decryption keys. The CPU itself doesn't have access to the decryption keys and doesn't even do the crypto algorithms. When the CPU needs to access some data that's encrypted in memory or on the Flash drive, it tells the secure enclave and writes the data to its input. The enclave then decrypts the data, with keys it keeps in its own non-volatile storage, and writes the decrypted data back to the CPU. In the case of the fulll-disk encryption or the fingerprint encryption, at no time do any keys pass into the CPU, let alone get written to RAM. The CPU can order the enclave to create new keys or keypairs, it can enumerate and name them, and associate them with metadata outside the enclave, but it can't actually read the keys themselves.

Re:If you can't crack the password, then don't.

[jaseuk]

I agree that Apple can't give an agency access to the device.

There is still some question around any icloud backup. You can lose a device and restore to a replacement. You can forget your password and go through the reset process. These two mechanisms tell us that in fact Apple could if pressured hand over an iCloud backup with the means to decrypt it, provided that they intercept the forgotten password process.

Of course there could be some legal reason why the agency cannot change the password. If inclined of course, they could very well intercept a password reset e-mail from Apple in any case,

But if I was very security consious, then disabling all cloud services would give me a suitably secure phone.

Jason

What about iCloud?

[BrennanPratt]

Is iCloud encrypted under the consumer's key? That seems like the smart thing to do, though I imagine it could make sharing folders across devices a bit tricky.

Plus solving the brute-force problem, of course.

Re:What about iCloud?

[Anonymous Coward]

Yes, iCloud backups are encrypted in the same way (and aren't decrypted between phone and iCloud). Of course, that doesn't help you if someone social engineers your password out of you.

containment

[Mister Liberty]

Encryption can be rock solid -- still the pass phrase be sniffed
Anything typed into a device that has connectivity is floating out there.

Re:containment

[Anonymous Coward]

Anything typed into a device that has connectivity is floating out there.

That's pretty paranoid, it is the absolute worst case scenario - in reality no, not anything you type is "floating out there".

Re:containment

[koan]

Depends, places like Huffingtonpost/Facebook/Guardian are actually able to record what you type prior to you submitting it.

Re:containment

[dunkindave]

Those places use javascript on webpages to upload what has been typed so far so they can do predictions and make suggestions. When you are entering the phone's passcode or phrase it is a very different matter since that isn't being entered into a browser, it is being entered into the phone OS's native interface. Still, as long as the software was created by someone else, in theory they can do anything they want with it, including after using it to unlock the storage, store the passphrase somewhere on the device or upload it to a server. But given people jailbreaking iDevices and tearing the Apple and Google code apart, as well as analyzing all the device traffic looking for security flaws, how long do you think such a backdoor would remain undiscovered? And why do you think Apple or Google would risk being caught doing it since it would be THEIR software, not some non-attributable thrid party? Just being caught once would be devastating to their sales, likely into a death spiral.

Having said all that, I do think these third party keyboards Apple is now letting take over typing on iOS 8 do present a large security risk for applications, website, etc., but not for the device's passphrase since the device won't use it for that.

Re:containment

[Anonymous Coward]

Having said all that, I do think these third party keyboards Apple is now letting take over typing on iOS 8 do present a large security risk for applications, website, etc., but not for the device's passphrase since the device won't use it for that.

In other mobile OSes you might be right. But iOS is ultra-paranoid these days, and pops up a "Mind-Type is attempting to use the FaxPorter Service. Do you want to allow it?" type-Dialog at the drop of a hat.

Somehow, they've managed to keep from it being shades of UAC for Vista-level annoying, while still alerting the user when the App/Extension is attempting to access "dangerous" stuff.

Oh, and I believe there is a pretty big fence around iOS "Extensions" in general, and "Keyboards" in particular.

Re:containment

[Anonymous Coward]

Or encryption can be weak. Or your device can be rooted/jailbroken.

It's funny to see that this is a thing. BlackBerry has had very strong encryption (same standard used by the NSA itself) for a number of years on both data and firmware. And they're Canadian and not subject to the same draconian laws. Gee, I wonder why the media has drummed up BlackBerry hate for so long. Hmmm.

as long as you allow remote updates, not secure

[Anonymous Coward]

as long as you allow the OS to be updated remotely, the company doing the update can push a new update that disables the security.

I don't believe that either Apple or Google would do this without a fight, if at all (after all, they aren't going to have this sitting around waiting, and having the government say "you must develop this" isn't going to result in voluntary overtime to impelement it)

But as long as you allow remote updates of the OS of a device, those updates can do ANYTHING to the device.

David Lang

Backdoor in TPM chips?

[Anonymous Coward]

If I were the NSA, I'd be forcing TPM chip manufacturers to provide some kind of backdoor to extract keys. Years ago I remember reading a slashdot comment about someone who said their work in law enforcement extracting keys from TPM chips. I remember him talking about sanding off the glue that covers the pins to protect them, and then attaching equipment to the pins to interact with it. I still think you'd need a backdoor to access the key inside if you don't have a valid password. I don't remember what else he said.

Re:Backdoor in TPM chips?

[koan]

There have been backdoors in consumer electronics since the 90's.

TPM is no exception.

Re:Backdoor in TPM chips?

[Anonymous Coward]

Police goons aren't that sophisticated. Cops use off the shelf stuff 100% of the time for routine cybercrime investigations. Sanding off the tops of chips and attaching leads or a harness would be something in the domain of the NSA, military, or specialized industry contractors.

I'm sure the FBI has a few smart people working for them but even that seems to be a level of sophistication I wouldn't expect from them. It's too easy to screw up and permanently damage the chip (and thus lose access to the embedded key), best to leave it to the professionals with the right tools and experience.

The NSA, on the other hand, has actual retrofit labs where they take apart gear and do the sorts of things on this level of sophistication. The NSA may offer this service to law enforcement on an as-needed basis or there may be specialized companies who do the work.

Re:Backdoor in TPM chips?

[Anonymous Coward]

What I meant by forcing TPM manufacturers to provide a backdoor was adding a special undocumented instruction that causes it to dump all of the keys out the data pin(s). The special instruction could be hidden in some sophisticated way that I can't possibly imagine, kind of like how TCP servers can be hidden behind port knocking. They could force the company to implement it in the chip design, or if they controlled chip fab companies then they could modify the CAD files (or whichever format chip designs are sent in) before they begin etching the chips so nobody would know unless they scraped the chips layer by layer and compared it to a diagram of how it should be. I wouldn't put it past the NSA and CIA to have this level of sophistication and influence.

I also wonder if any security functions built into Intel and AMD CPUs have secret override instructions just for the NSA. For example, a way to read and write any part of memory they want, to inject instructions, etc.

Re:Backdoor in TPM chips?

[ledow]

There are a handful of companies able to do this, and a handful of well-funded amateurs with the capability to do this for 80's video game chips that everyone is desperate to pay £10k just to acquire (let alone emulate).

If you keep up with any of the MAME scene, the decapping projects are few and far between and pretty much one guy rules them all and it can take YEARS to decap a chip, and years more to understand what it does. On commercially available stuff from the 80's.

Security chips, etc. generally fall to statistical analysis and modern computing power, not someone looking inside the chip. And the keys in a TPM chip won't be stored where they can be "seen" while decapping - that reveals only the structure and to find out where to hook into in a complex encryption chip is quite a skill. To do so without disrupting the chip's operation (even if it has no security) is difficult. To extract actual useful data, even more so.

I'm not saying it couldn't happen, if a case came up with the military or NSA needed to get access to something stored on a TPM chip. But it's not something they'll be doing routinely. And you can "force" chip manufacturers all you like - most of the stuff we use does NOT originally come from the USA or from US-influenced countries. I'm not saying they're not compromised too, in some fashion, but it's not as easy as saying "We are the NSA, put in a backdoor". Most countries will tell you where to go, and get you into the international press for even trying (could even be considered an act of war if you tried that on the Chinese, for example).

Things aren't as simple as "everything is backdoored", "acres of supercomputers", "listening to every phone call", etc. That's all hyperbole. And it works on exactly the people it's intended to - the general public who have nothing of import to hide, and thus feel reassured that they're safe from nasties / scared that shouldn't become a nasty in case they get caught.

Any encryption you might use as a consumer is NOT intended to defeat a well-funded military adversary with reason to decrypt it. That might be possible, it might even be what encryption was invented for, but that's NOT the use-case of 99% of encryption out there. Don't think it is. Hell, we had the world's most popular SSL library have a flaw it in for 10 years and NOBODY NOTICED.

If anything, elliptic-curve cryptography is the weak-link. We're being forced onto it by being told everything else is weak. It's not as well-researched or understood as the algorithms that have been attacked for nearly 40 years. Implementations are few and based on published curves. And there's NOTHING being said about our move to it.

If anything, when you think the trick is happening, it's already been done.

Re:Backdoor in TPM chips?

[Anonymous Coward]

If you search YouTube for "Black Hat DC 2010: Hacking the Smartcard Chip", you'll see a series of eight videos where a guy shows how he spent six MONTHS decapping TPM chips, finding ways around their layers of security, and eventually gaining access to the core's memory pins where everything is unencrypted. He was eventually able to come up with a process that takes only hours to tap a few pins into the TPM and dump everything.

The kind of backdoor I think is built into these chips is secret undocumented instructions that don't require decapping the chip and microscopes. Cut the pins of the chip and remove it from the board, then connect what's remaining of the pins to some device that allows you to control it according to the documented specs. Use a secret sequence of commands to dump all the keys.

Re:Backdoor in TPM chips?

[Anonymous Coward]

...kind of like the clipper chip of the 1990's. I wonder if they have achieved their goal of key escrow/government master key with TPM 2.0

Re:Backdoor in TPM chips?

[IamTheRealMike]

If anything, elliptic-curve cryptography is the weak-link. We're being forced onto it by being told everything else is weak. It's not as well-researched or understood as the algorithms that have been attacked for nearly 40 years. Implementations are few and based on published curves. And there's NOTHING being said about our move to it.

I want to address this statement here, because I feel it's misleading.

Elliptic curve cryptography has been researched since the 1980's. It is not at all crazy or new. It is the current state of the art, RSA is obsolete and learning-with-errors is the current best candidate for a next-gen post quantum crypto system, as far as I can tell.

Nobody is being "forced" onto ECC by being told other things are weak. To the best of anyone's knowledge, RSA is not weak given big enough key sizes. However, ECC is just as strong when used with much smaller keys and signatures, and can be much faster. Basically you halve the key size with ECC to get the security level. So a 256 bit key gives 128 bits of security, i.e. you would need to try 2^128 times to cover the entire key space, which is physically infeasible. Whereas you need perhaps a 2048 bit RSA key to get gold standard security. Additionally ECC has various other nice features that can be useful in certain contexts.

Implementations of ECC are widespread. Every OS comes with one out of the box and implementations are available for every reasonable language and platform.

Finally "based on published curves". Yes, ECC requires people standardise on some public parameters to use it. That's no different to HTML or TCP or any other standard. The one caveat that exists here is that for the secp256r1 curve (which is widely used in ECC based SSL) the curve parameters were chosen by the NSA. However, (a) nobody knows any way that this could introduce a weakness despite decades of research into ECC and (b) there are many other curves where the parameters were not chosen by the NSA, for example Curve25591 where the parameters were not only chosen by djb but every parameter has an explanation for why it's the best value that could be chosen. There's no flexibility or magic numbers in its design at all, but it's still ECC.

The good news is that the secp256r1 curve has basically no redeeming qualities at all, except that it's one of the oldest and so support is widespread. All new applications that get a free choice of curve are being based on a modern modern one like Curve25591 or secp256k1 (bitcoin), where the parameters are much more rigid and there are no ways to insert back doors.

Re:Backdoor in TPM chips?

[ledow]

Though I agree with your post, and am aware of the majority of it but maybe couldn't reel off the exact curve names, there are problems here.

There are a number of areas where EC is being "forced".

Perfect Forward Secrecy is one (one that you hadn't heard mention of in general IT circles). Yes, there is a non-EC way to do it, but it's horrendously slow compared to the alternative. The only way to get PFS is to use EC. We're being told to abandon RSA and move to EC, in no uncertain terms in other areas. But, as you point out, RSA is still viable. Which raises more questions.

EC curve choices are things that should not come down to "one person / organisation" - no matter how much you trust djb (and he gets a certain level of respect because every bit of his software is pretty damn good on the security front), it should not be a question of trust in an individual to form a curve.

Public Key Encryption, in general, requires no magic numbers, fixed initialisation vectors, "parameters" or similar. Hashes, possibly, but PKE, not. You choose two huge primes that only you know and that's the end of it. To have to resort to "picking" a particular curve *is* akin to placing some magic number and mixing it with the primes in question - this is territory that's not to be trusted if it's to form the basis of the world's encryption standards.

For a start, as you show, the NSA curve was chosen and got into widespread circulation before anyone really noticed. If nobody knows any way it could be a weakness, do we know any way that it's a strength? And the answer is no. Which is questioning the entire use of such a chosen curve.

The parameters that need to be agreed were obviously agreed on by the NSA for some reason - hostile or not. That reasoning is different to other curves and other people's choices which, in itself, is a weakness on one side. Either we're choosing curves that the NSA is avoiding, or they're choosing curves that we're avoiding. And that's just a mess for an algorithm that needs to take over the world's data security.

I'm a mathematician, but I have to say that the exact mathematics is beyond me nowadays. However, as "suspicious IT guy" with no reason to believe in conspiracy theories, government collusion or any other crackpot schemes, it worries me that we can't agree on curves and that such agreement is even necessary.

The wonderful things about standards is that there are so many of them to choose from. But the wonderful things about security is we need one well-defined way, and to constantly work on a single replacement for it. EC, in that regard, is suspiciously popular and dangerously configurable without explanation.

as long as you allow remote updates, not secure

[Anonymous Coward]

Especially if you need a username/password to download updates instead of downloading them anonymously. Remember back in the 1990's when you bought antivirus software you would download monthly virus definition files from the antivirus company website and install them yourself? You didn't have to log-in, you could just drop the files in a directory yourself. With iOS, OSX and Windows you authenticate.

no key needed when you have the data

[raymorris]

I think you may have missed GP's point. The key protects the data. When the user enters the passphrase, the data is decrypted and apps can access all the data. Therefore, you don't NEED the key if you can put an app on the phone, then the user uses their phone. The encryption is useful only on a stolen or seized phone.

Re:no key needed when you have the data

[Anonymous Coward]

No, apps don't have access to all the data. That's exactly what iOS's sandboxing model prevents - it makes sure that apps can't read data arbitrarily across the device, instead, only the app's own data, and data that's been explicitly authorised for that app to view.

Re:no key needed when you have the data

[SJ]

Actually... The passphrase only decrypts the key that is used to protect the data.

Plus, each app is sandboxed and can not access other apps data. (with a few controlled exceptions)

Plus, warnings a thrown up if your app starts trying to access things. (Contacts, Microphone, Photos etc)

Re:no key needed when you have the data

[raymorris]

There is that, but if that were trustworthy you wouldn't need encryption. I assume, I think rightly, that any forensic app installed by Apple or a letter agency will have no trouble bypassing the sandbox. I've yet to see any sandbox model, on any OS, that didn't leak like a sieve. See Java and Flash for well-known examples of that approach.

Re:no key needed when you have the data

[Anonymous Coward]

How would apple or said letter agency install said forensic app, when they don't have your phone?

Re:no key needed when you have the data

[iluvcapra]

There is that, but if that were trustworthy you wouldn't need encryption.

Defense in depth.

Re:no key needed when you have the data

[gnasher719]

There is that, but if that were trustworthy you wouldn't need encryption. I assume, I think rightly, that any forensic app installed by Apple or a letter agency will have no trouble bypassing the sandbox. I've yet to see any sandbox model, on any OS, that didn't leak like a sieve. See Java and Flash for well-known examples of that approach.

Idiot. It's called "defence in depth". The most basic knowledge of security will tell you that you will have multiple protections. Having three layers of security isn't an admission that the first two layers are unsafe, only to a clueless idiot. The third layer provides more security.

Here's how it works

[koan]

The NSA (and other agencies) have noticed a significant drop in data, and an increase in the use of encryption/VPN/proxies/TOR since Snowden went public.

They realized more people were starting to take care with their data, so how to fix (read stop) it?

OK, first we have the NSA complaint corps (Apple, Google, Facebook, Twitter) code some "encryption" made out of tissue paper, then they send out the FBI (and other agencies) talking heads to publicly denounce this "encryption" as though they were seriously concerned.

Now people thinking they have encrypted their devices and are safe will once again become complacent.

But the real story is even more absurd, the fact that the average person believes they are of any interest to anyone but marketers.

Re:Here's how it works

[Anonymous Coward]

Presume what you are saying is not true, namely the scenario you painted is just another conspiracy theory - well true or not it is a conspiracy theory. What level of proof would be required for you to accept that the scenario is not true? Is there any level that would prove it to you, or would any proof be dismissed as just a fabrication by THEM to further the conspiracy?

Re:Here's how it works

[Anonymous Coward]

Conspiracy theories are not theories. If a claim cannot be disproven then it is not a theory since theories are testable meaning they can be proven false if that is the case.

Re:Here's how it works

[Anonymous Coward]

The word "theory" has several meanings. You're referring to scientific theories. Conspiracy theories are not scientific theories. Well spotted. But then scientific theories are not mathematical theories either, the word "theory" in mathematics means "actually proven with math" not just "disprovable in principle". Meanwhile, conspiracy theories are theories in the common sense of the word theory, which is neither a mathematical nor a scientific theory, and more akin to the mathematical "conjecture". Conjectures need not be provable or disprovable even in principle.

Re:Here's how it works

[AmiMoJo]

Seems like a very risky strategy. Android and iOS encryption have already come under a lot of scrutiny, not least from companies that make software to extract data for law enforcement. If there were weaknesses there is a good chance they would be found, as they were when problems like Goto Fail were discovered.

Even if the encryption is compromised, it would be effective against corrupt law enforcement agencies. The FBI isn't going to start cracking iOS encryption and then going to court with the evidence because it would reveal how they got it and undermine the whole scheme.

Even if you don't trust Google and Apple it's hard to see this as anything other than a vast improvement over what we have now, i.e. nothing.

Re:Here's how it works

[dargaud]

But the real story is even more absurd, the fact that the average person believes they are of any interest to anyone but marketers.

Nobody is of interest until something happens that makes you commited.

Re:Here's how it works

[koan]

And how likely is that for the average person.

Re:Here's how it works

[koan]

Seems like a very risky strategy

Like hiring outside contractors while you violate the letter of the law and gather up everyone's Internet and phone communications, including sticking backdoors into firmware, hardware, and major brands of software? Some of said brands were working with the NSA.
Risky like that?

Think about it.

Re:Here's how it works

[Anonymous Coward]

The FBI isn't going to start cracking iOS encryption and then going to court with the evidence because it would reveal how they got it and undermine the whole scheme

Parallel construction.

Re:Here's how it works

[fluffynuts]

Cool, I don't know about iOS for sure, except that iOS 8 fucking lags on an iphone 4s, so I have to assume it's doing *something*.

In addition, enabling encryption on my i9300 (android, of course), led to tangible lag in device usage. If you're going to make "tissue paper" encryption, you'd at least omit the lag, surely? Not that I'm fully refuting your claim -- just saying that if it's true, someone went to a lot of effort to waste cpu cycles so it seems as if there's something happening.

Re:Here's how it works

[koan]

I have no proof of what I say, I am basing everything off previous experience and the obvious "conspiracy" between governmental agencies and certain corporations.

I would bet a large amount of money that I am close to, or right on top of the truth of the matter.
Your mileage may vary.

Re:Here's how it works

[fluffynuts]

Like I say, I'm not disputing that there are a bunch of nefarious fucks trying to run the world; just that, if iOS and Android encryption are bunk, they either went to a great deal of effort to make them resource-intensive or they just plain hired a bunch of PHB's, pointed them at Scratch and said "go code encryption, 'cos you can!". Because seriously, Apple's planned obsolesence is working and I had to turn off encryption on my s3 after I started getting the urge to smash it.

Re:Here's how it works

[koan]

Additionally consider Apple's security track record of late, (get fail?) and frankly I don't think Google/Android were ever designed to keep things private.

Re:Here's how it works

[fluffynuts]

I dunno, perhaps I'm too much of an optimist, but:

1) I think google only wants to break privacy if it increases ad revenue; I think they'd rather "stick it to the man"
2) the latest Apple snafu with fapgate is really just dumbness, not nefariousness (if that's even a word). I mean, no lockout on incorrect password == brute force win, duh.

Perhaps they are t3h 3v0lz. Perhaps not. I prefer to "occam's razor" shit and take the simpler solution, albeit that I recognise that I may not be right; I just don't want to live constantly looking over my shoulder and I have to admit that a resounding metric buttload of conspiracy shit is exactly that -- shit. Some may be truth, but it deserves the same scrutiny we place on the "truths" we're told every day if we want to stay sane. Just my /2c.

Re:Here's how it works

[koan]

I agree I think Google is only interested in generating revenue, unfortunately the NSA and other "agencies" are going to use the data for other things.

Re:Here's how it works

[fluffynuts]

Sure thing; just balance that with the obviousness that disgruntled users == loss of revenue, either directly or through migration away from your products. There are quite a few Android spinoffs without the googleness in them, so the googleness is quite well baked out of the OS. Not saying it's perfect, but the sheer structure of the community and the opensource nature of the code makes it a more difficult target for the spybies. Then again, nothing is unhackable, nothing completely safe. So I guess I go back to the mantra "pick the battles worth fighting and live your life there rest of the time" (:

Comment removed

[account_deleted]

Comment removed based on user account deletion

What about the data?

[mveloso]

Encryption is only one part of the announcement. Apple also said that they're not going to sell your data, for the most part. What did google say about that?

Re:What about the data?

[SixGunMojo]

Encryption is only one part of the announcement. Apple also said that they're not going to sell your data, for the most part. What did google say about that?

Google is an advertising company. Of course their going to sell your "anonymous" data.

Droids

[Anonymous Coward]

So, from what I am hearing, these might be the droids you are looking for but you can't tell because they are securely encrypted. Better than just a restraining bolt, eh?

how I do it

[raymorris]

Here's how I do it:
http://osxdaily.com/2014/02/16...

Timtowtdi of course

Re:how I do it

[Plumpaquatsch]

Here's how I do it: http://osxdaily.com/2014/02/16...

Timtowtdi of course

Yeah, finding a way that doesn't require the user to turn on Automatic App Download and you having full access to the Apple-ID account (not to mention the user not noticing the new icon with a blue dot before the name) sure would be better than this one.

error in depth

[raymorris]

I'm about to go into a meeting where we're going to design a security architecture for a government agency involved in cybersecurity. While designing it, I'm going to watch out for the error GP made by implication, which is:

Today's topic is encryption of data on mobile devices.
A method of bypassing the encryption was suggested.
Gp (and you) essentially argue that the encryption doesn't need to be solid because sandboxing.
Next week, the same logic would argue that sandboxing doesn't need to be strong because encryption.
Result: Neither sandboxing nor encryption are as strong as they could be.

That's depths of weakness, not depths of defense.

One answer that adds a layer of security would be to encrypt application- private data with an application- specific key. That way, the encryption prevents an app from accessing app-private data, providing a second layer on top of the sandboxing.

Dead-man switch required.

[Anonymous Coward]

What's now required in laptops and mobile phones is a "dead-man" switch where if the user stops doing something after a certain period of time, the device switches off and all crypto keys in memory are lost. That may not be convenient for mobile phones, but if you look at how the Dread Pirate Roberts was caught - in a library by FBI determined to not let him turn off the laptop - then a dead man switch (software or hardware) could have shut his laptop down before they had time to dump its RAM to disk or similar.

Secure right?

[Anonymous Coward]

So you deal with the secure enclave in the iPhone and you're in?

I tried device encryption on CM11 nightlies...

[fluffynuts]

the other day. Here's what happened:
1) Performance sucked ass, despite reports to the contrary (i9300 -- I know it's no G3, but hey, it should damn well be enough, at quad-1.2 gHz with a gig of RAM)
2) My TWRP restore didn't include my home partition so I lost all data on there. Sucks to be me.

I'd welcome this if it didn't come at the massive lag that I experienced on a device which is normally quite spritely. I get that encryption doesn't come for free, but adding 1-3 seconds lag to every tap is not, in my book, worth it. I'd rather just use the android device manager to remote wipe if I lose my phone.

Heathens

[Anonymous Coward]

It blows my mind how few of you get encryption or how it works, or why it works.

The android key is at danger on running devices

[allo]

Try to change it with vpc. You are NOT asked for your old password.
With for example LUKS this is not possible, as the linux kernel does not give you the password of the unlocked device, which is needed to encrypt it with the new key.

Pretty sure Apple already has access

[raymorris]

AC asked: How would apple or said letter agency install ...

Plumpaquatsch replied:
        a way that doesn't require access to the Apple-ID account sure would be better

I'm fairly sure that Apple already has access to your Apple account, and the NSA or other three-letter agency can get access whenever they feel like it. Heck, I only work for a FOUR-letter agency, and I can personally access most Apple accounts.

Re:Pretty sure Apple already has access

[Plumpaquatsch]

Sure you can. I can access all Google accounts, not just "most". And you still haven't gotten around the user of the phone not noticing the new app.

Re:Pretty sure Apple already has access

[raymorris]

Do
http://www.ibtimes.com/icloud-...
you
http://securitywatch.pcmag.com...
think
http://www.thehothits.com/news...!
iCloud
http://www.businessinsider.com...
is
http://www.troyhunt.com/2014/0...
secure?
http://hollywoodlife.com/2014/...

Three major hacks in the last few months, one by a preteen.

Re:Pretty sure Apple already has access

[Plumpaquatsch]

Funny how many of the hacked celebs had Android devices, eh? Prove that Google is easily hackable. Funny how most of the hijacked iCloud accounts had the same credentials as their Google accounts - easy passwords even a moron like you could come up with. Not to mention that even mentions that the accounts where likely hacked by password recovery to an already hacked email account - most certainly Gmail. And coincidently, you do sound like a crazed, teenaged Miley Cyrus fan, so why don't you tell us how you did it, instead of just pretending you have a clue?

A blinded fanboi, I see

[raymorris]

Google's security isn't awesome. Therefore, you reason, Apple's must be perfect, because you're a fan. Do you throw your panties on stage at Apple events?

When you grow up a little bit, you'll come to understand that a) fanatacism toward a company like Apple (or Google) just means you're easily manipulated by marketing and b) all companies, all products, and all services have limitations - especially security limitations. The fact that users routinely forget their passwords makes it extremely difficult to secure mass-market services like iCloud, Gmail, Facebook, etc. When you have millions of users, tens of thousands of those will forget their passwords each year. Therefore, you _must_ make it possible to access the account without knowing the password. Because many of the users who forgot their passwords are technically unsophisticated, you must make it _easy_ to access the account without knowing the password.

If you'd like further details on exactly how it's done, refer to any of my earlier posts or posts by swillden.

Re:A blinded fanboi, I see

[Plumpaquatsch]

Yes, you do every time you look into the mirror.