Slashdot Mirror

http://blog.cryptographyengine...

Both of the links in the post are useless hot takes, otherwise.

Fairly certain the phone in question has Secure Enclave (I believe they said 5s, and I think that was the first with it). If it was just in software, you could copy the phone's memory into an emulator and guess 10 passwords and then restore the VM to its previous state and start again. Secure Enclave makes attacks have to be on the phone because the PIN and UID are embedded in hardware and can't be read. An attack would have to update the firmware for Secure Enclave and at make the UID and PIN readable or at least make the PIN brute force guessable by disabling the counter. The PIN and UID are combined to PBKDF2-AES encrypt the device.

Technically the FBI could still brute force the phone off the device, but brute forcing PBKDF2-AES isn't easy, especially without at least the UID. Here's a blog post on it from a couple years ago. Apparently law enforcement didn't crack the phones in the past, just bypassed the boot and read the cleartext data. With full phone encryption that isn't possible.

If you're interested in how the hardware-driven encryption works in current versions of iOS: Why can't Apple decrypt your iPhone?

Just so that the debate here is a little more well-informed: The government is not asking that Apple give out the user's password, or decrypt the phone, both of which they cannot just do (i.e. are incapable of performing). The request is that Apple produce a piece of iOS software or boot image (as I understand it), that would: 1) Disable the auto-erase feature 2) Allow the FBI to brute force submit password guesses to the phone, and 3) Disable or reduce the increasing-delay-between-guesses feature of the passcode lock. I would be curious to know whether for this iPhone 5c (with iOS 9) this is even possible for Apple to do.

http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html:

Addendum: how did Apple's "old" backdoor work?

One wrinkle in this story is that allegedly Apple has been helping law enforcement agencies unlock iPhones for a while. This is probably why so many folks are baffled by the new policy. If Apple could crack a phone last year, why can't they do it today?

But the most likely explanation for this policy is probably the simplest one: Apple was never really 'cracking' anything. Rather, they simply had a custom boot image that allowed them to bypass the 'passcode lock' screen on a phone. This would be purely a UI hack and it wouldn't grant Apple access to any of the passcode-encrypted data on the device. However, since earlier versions of iOS didn't encrypt all of the phone's interesting data using the passcode, the unencrypted data would be accessible upon boot.

No way to be sure this is the case, but it seems like the most likely explanation.

Mechanics of "why not" here: http://blog.cryptographyengine...

Math of "why not" good introduction here: http://www.eetimes.com/documen...

Which still means that even if a manufacturer intends to comply, they'd have to immediately suspend all sales until the software patch is released. In fact, because of how the encryption is currently performed, it may require hardware modification to even make backdoored encryption possible: http://blog.cryptographyengine...

ScreenOS uses Dual EC in a strange, non-standard way. Rather than generating all of their random numbers with Dual EC (which would be slow), they only use Dual EC to generate a seed for a fast 3DES-based generator called ANSI X9.17. Since that generator is actually FIPS-140 approved and generally believed to be sufficient to the purpose, it's not clear what value Dual EC is really adding to the system in the first place -- except, of course, its usefulness as a potential backdoor.

The good news here is that the post-processing by ANSI X9.17 should kill the Dual EC backdoor, since the attack relies on the attacker seeing raw output from Dual EC. The ANSI generator appears to completely obfuscate this output, thus rendering Dual EC "safe". This is indeed the argument Juniper made in 2013 when it decided to leave the Dual EC code in ScreenOS.

http://blog.cryptographyengine...

We know that the developers were pretty sure that the last version of TrueCrypt was still secure.

The last version of TrueCrypt passed a public security audit with flying colors.

The linked http://blog.cryptographyengine... has some settings.
https://freakattack.com/

This might be academic if it was just a history lesson — but for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. This would involve deliberately weakening technology so that governments can intercept and read our conversations. While officials are carefully avoiding the term “back door” — or any suggestion of weakening our encryption systes — this is wishful thinking.

You seem to be under the impression that https is secure.

http://blog.cryptographyengine...

He does a good job of calling out pretty much everything expressed here. As well as highlighting some of the half-truthes and/or complete lies in the letter.

This paper was released as a preprint a year ago. Schneier's response can be found here.

That doesn't seem to be true.

The Many Flaws of Dual_EC_DRBG

Back in 2004-5, NIST decided to address a longstanding weakness of the FIPS standards, namely, the limited number of approved pseudorandom bit generator algorithms (PRGs, or 'DRBGs' in NIST parlance) available to implementers. This was actually a bit of an issue for FIPS developers, since the existing random number generators had some known design weaknesses.*

  NIST's answer to this problem was Special Publication 800-90, parts of which were later wrapped up into the international standard ISO 18031. The NIST pub added four new generators to the FIPS canon. None these algorithms is a true random number generator in the sense that they collect physical entropy. Instead, what they do is process the (short) output of a true random number generator -- like the one in Linux -- conditioning and stretching this 'seed' into a large number of random-looking bits you can use to get things done.** This is particularly important for FIPS-certified cryptographic modules, since the FIPS 140-2 standards typically require you to use a DRBG as a kind of 'post-processing' -- even when you have a decent hardware generator.

  The first three SP800-90 proposals used standard symmetric components like hash functions and block ciphers. Dual_EC_DRBG was the odd one out, since it employed mathematics more that are typically used to construct public-key cryptosystems. This had some immediate consequences for the generator: Dual-EC is slow in a way that its cousins aren't. Up to a thousand times slower.

Now before you panic about this, the inefficiency of Dual_EC is not necessarily one of its flaws! Indeed, the inclusion of an algebraic generator actually makes a certain amount of sense. The academic literature includes a distinguished history of provably secure PRGs based on on number theoretic assumptions, and it certainly didn't hurt to consider one such construction for standardization. Most developers would probably use the faster symmetric alternatives, but perhaps a small number would prefer the added confidence of a provably-secure construction.

I don't remember if I've seen that link before, but thanks for sharing it. That is a great explanation, and reinforces the point I've been making.

The Many Flaws of Dual_EC_DRBG

The 'back door' in Dual-EC comes exclusively from the relationship between P and Q -- the latter of which is published only in the Dual-EC specification.

There *is* something wrong with Dual_EC_DRBG, the possibility of a backdoor is the most serious flaw but it isn't the only one : http://blog.cryptographyengine...

Are you referring to this RSA's CTO Sam Curry's "defense", which Mathew Green and Matt Blaze has had so much fun ridiculing? http://blog.cryptographyengine...

RSA Security really haven't made anything close to a coherent defense.

> They can't go and release the details of a confidential contract simply because somebody thinks it contains something it doesn't have.

Given that NSA made the contract in bad faith, is RSA Security still obligated to keep their silence? Maybe, but it seems insane. What RSA Security could say for starters was for example to explicitly confirm that a $10,000,000 contract exists. They haven't even done that.

RSA Security also have not yet given a good explanation for why they ignored the multitude of red flags until 2013. As cryptographer Matthew Green writes:

> So why would RSA pick Dual_EC as the default? You got me. Not only is Dual_EC hilariously slow -- which has real performance implications -- it was shown to be a just plain bad random number generator all the way back in 2006. By 2007, when Shumow and Ferguson raised the possibility of a backdoor in the specification, no sensible cryptographer would go near the thing. And the killer is that RSA employs a number of highly distinguished cryptographers! It's unlikely that they'd all miss the news about Dual_EC.

If RSA Security makes secret contracts that impacts other people's security, I don't see why RSA Security should get any benefit of the doubt. Why should we trust a company cloaked in secrecy who has shown themselves to be overwhelmingly incompetent and/or malicious?

> There's zero evidence that RSA knew about the weakness when accepting the money to include the algorithm in their products.

It is possible that RSA Security was not aware of the possible backdoor in 2004, though unlikely. But that in no way excuses or explains why RSA security kept using the algorithm after the flaws became apparent and widely known in 2006 and 2007: http://blog.cryptographyengine...

> There's zero evidence that RSA knew about the weakness when accepting the money to include the algorithm in their products.

It is possible that RSA Security was not aware of the possible backdoor in 2004, though unlikely. But that in no way excuses or explains why RSA security kept using the algorithm after the flaws became apparent and widely known in 2006 and 2007: http://blog.cryptographyengine...

I breathed a sigh of relief upon reading this headline.

The latest TLS version Firefox supported until now has been broken in principle--and increasingly in practice--since almost a year ago

Here's Matthew Green, JHU cryptography engineering professor/researcher, with a full account: http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

We don't need "software updates that improve the security of OpenSSL", we need a whole new protocol.

If you really want to be helpful, Google, provide support and coordinate a competition to create a new SSL protocol, à la AES and SHA-3. Then we could make progress towards truly better security.

Case in point, Matthew Green:

I admit that at this point one of my biggest concerns was to avoid coming off like a crank. After all, if I got quoted sounding too much like an NSA conspiracy nut, my colleagues would laugh at me. Then I might not get invited to the cool security parties.

All of this is a long way of saying that I was totally unprepared for today's bombshell revelations describing the NSA's efforts to defeat encryption. Not only does the worst possible hypothetical I discussed appear to be true, but it's true on a scale I couldn't even imagine. I'm no longer the crank. I wasn't even close to cranky enough.

There are several good reasons why multiple (cascade) encryption is not necessarily more secure than either algorithm on its own. Moreover, there are examples of situations where cascade encryption provide a false sense of security. Matthew Green posted an articlein 2012 on his website that addresses this issue.

You mean like SSL is broken and nobody talks about it?

First there was BEAST in 2011, which was fixed. But the situation in 2013 is not better!
https://www.globalsign.com/blog/is-ssl-broken.html (and links therein, especially the last two)
https://www.imperialviolet.org/2013/02/04/luckythirteen.html
http://blog.cryptographyengineering.com/2013/02/attack-of-week-tls-timing-oracles.html
List of all attacks: http://armoredbarista.blogspot.de/2013/01/a-brief-chronology-of-ssltls-attacks.html

As pointed out by others, this 'problem' is nonsense because the random number is generated by the client's browser. A government could lean on browser providers, but that puts the 'attack code' client-side and waiting to be noticed.

Trust of keys from providers is a real problem. In order to be certain that a connection is actually secure from listening you have to trust that what you are getting is the real certificate from the service provider, and not an 'attack' certificate generated by some dodgy CA (e.g. DigiNotar and the Iranian google snooping, and others). This can be reduced in some (limited) cases by using certificate pinning, or by using something like EFF's SSL Observatory.
Even if you actually are getting the 'real' certificate, you need to trust that the service provider hasn't already handed that certificate over to government. This isn't just a problem for the current certificate trust model - obviously if the other person is giving away their keys then you're pretty screwed regardless of the encryption system.
Finally, even if the communication is encrypted and the spying group doesn't have the keys, you still have to trust the service provider to not just hand over the unencrypted network traffic or your content anyway.
That's a lot of trust being spread around.

In the case of something like gmail, the solution is more encryption - it is encryption of the content end-to-end rather than just in transit, and with keys only you and the recipient have. That could be personally exchanged self-signed x509 keys/certs or OpenPGP keys, or even preshared symmetric keys. If you're a bit more trusting, it could be keys signed by a trusted other (a genuinely trusted other, not a large company).

So the solution is more encryption - in part at least. Just not more TLS.

And there's another blog entry on it: Where Things Fall Apart: Protocols (Part 2 of 2)

The summary is that there's a mutual authentication key (MAK) that should be different for each vehicle on the road, however if some manufacturer has taken a short cut and used the same key on a large number of vehicles then all those cars are at risk, and looking at the article it seems to be the case - the device works for some vehicles but not other.

As for their habit of going in on the passenger side - that's where the glove compartment is and where it's likely that some valuables are found.

Mixing or laundry services aren't necessary. There is a cryptographic solution to this problem, zerocoins. Can someone please tell me how this doesn't solve the problem? It seems to me like the conundrum has already been resolved.

You don't need to put your coins into a laundry if you use zerocoins instead. End of problem. Whoever wrote this article (and everyone commenting) doesn't know how to do a little research. Total anonymity and pseudymity are possible.

This post gives a high-level summary of the attack:

http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html

(I previously posted this as AC, but it vanished.)

The API has two padding modes for RSA, PKCS#1v1.5 and OAEP. OAEP is provably secure. That is, if the underlying scheme (RSA) is a secure public key cipher, then RSA combined with OAEP is a semantically secure encryption scheme that is resistant to chosen-plaintext attacks. On the other hand, not only is PKCS#1v1.5 not provably secure, it has been known for years to be vulnerable to real world attacks.

Most of the time when you see people using it today it is for backwards compatibility, but in this case they are designing a brand new API. Why not go with the one which we know to be secure instead of encouraging the use of a dangerously vulnerable scheme?

It's not just bad corporate policies. It's the entire commercial security industry as well:

http://blog.cryptographyengineering.com/2012/03/why-antisec-matters.html