Archive for May 23, 2015

Saturday, May 23, 2015

Whose Phone Is This?

Daniel Jalkut:

The problem to my mind is not that Siri shares my name and contact information, but that it goes a step further, showing not only my main telephone number, but my physical address, all my telephone numbers, email addresses, as well as my AIM, Twitter, and Facebook accounts. It also happily provides my birthdate, the names of my wife, mom, dad, brother, heck, the names of any person I have assigned a relationship to.

[…]

Of course, you don’t have to share all this information with whatever stranger manages to pick up your phone. Simply disable Siri access from the lock screen, and nobody will be able to access your private information using it. Of course, this means no airline employee who finds your phone tucked between the seats will be able to easily return your phone to you, either.

There’s no great solution here because of the classic privacy vs. convenience trade-off. Another option would be to disable Siri on the lock screen and use the Health app’s “Medical ID” card, which is accessible by swiping right at the lock screen and then tapping Emergency.

The Logjam Attack

How Diffie-Hellman Fails in Practice:

We have uncovered several weaknesses in how Diffie-Hellman key exchange has been deployed:

  1. Logjam attack against the TLS protocol. The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.
  2. Threats from state-level adversaries. Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections.

The site says that my Safari 8.0.6 is vulnerable.

Their Imperfect Forward Secrecy paper (PDF):

Our calculations suggest that it is plausibly within NSA’s resources to have performed number field sieve precomputations for at least a small number of 1024-bit Diffie-Hellman groups. This would allow them to break any key exchanges made with those groups in close to real time. If true, this would answer one of the major cryptographic questions raised by the Edward Snowden leaks: How is NSA defeating the encryption for widely used VPN protocols?

Scott Aaronson:

The further fact is that in NFS, you can arrange things so that almost all the discrete-logging effort depends only on the prime number p, and not at all on the specific numbers g and h for which you’re trying to take the discrete log. After this initial “precomputation” step, you then have a massive database that you can use to speed up the “descent” step: the step of solving of ga=h (mod p), for any (g,h) pair that you want.

It’s a little like the complexity class P/poly, where a single, hard-to-compute “advice string” unlocks exponentially many inputs once you have it. (Or a bit more precisely, one could say that NFS reveals that exponentiation modulo a prime number is sort of a trapdoor one-way function, except that the trapdoor information is subexponential-size, and given the trapdoor, inverting the function is still subexponential-time, but a milder subexponential than before.)

The kicker is that, in practice, a large percentage of all clients and servers that use Diffie-Hellman key exchange use the same few prime numbers p. This means that, if you wanted to decrypt a large fraction of all the traffic encrypted with Diffie-Hellman, you wouldn’t need to do NFS over and over: you could just do it for a few p’s and cache the results. This fact can singlehandedly change the outlook for breaking Diffie-Hellman.

Matthew Green:

This work is the result of an unusual collaboration between a fantastic group of co-authors spread all around the world, including institutions such as the University of Michigan, INRIA Paris-Rocquencourt, INRIA Paris-Nancy, Microsoft Research, Johns Hopkins and the University Of Pennsylvania. It’s rare to see this level of collaboration between groups with so many different areas of expertise, and I hope to see a lot more like it. (Disclosure: I am one of the authors, but others did all the good bits.)

[…]

However, there is a second class of servers that are capable of supporting 512-bit Diffie-Hellman when clients request it, using a special mode called the ‘export DHE’ ciphersuite. Disgustingly, these servers amount to about 8% of the Alexa top million sites (and a whopping 29% of SMTP/STARTLS mail servers).

[…]

Here it is in a nutshell: if the server supports DHE-EXPORT, the attacker can ‘edit’ the negotiation messages sent from the a client -- even if the client doesn’t support export DHE -- replacing the client’s list of supported ciphers with only export DHE. The server will in turn send back a signed 512-bit export-grade Diffie-Hellman tuple, which the client will blindly accept -- because it doesn’t realize that the server is negotiating the export version of the ciphersuite. From its perspective this message looks just like ‘standard’ Diffie-Hellman with really crappy parameters.

Bruce Schneier:

One of the problems with patching the vulnerability is that it breaks things:

On the plus side, the vulnerability has largely been patched thanks to consultation with tech companies like Google, and updates are available now or coming soon for Chrome, Firefox and other browsers. The bad news is that the fix rendered many sites unreachable, including the main website at the University of Michigan, which is home to many of the researchers that found the security hole.

This is a common problem with version downgrade attacks; patching them makes you incompatible with anyone who hasn't patched. And it's the vulnerability the media is focusing on.

Update (2015-10-15): Alex Halderman and Nadia Heninger:

However, the documents do not explain how these breakthroughs work, and speculation about possible backdoors or broken algorithms has been rampant in the technical community. Yesterday at ACM CCS, one of the leading security research venues, we and twelve coauthors presented a paper that we think solves this technical mystery.

[…]

If a client and server are speaking Diffie-Hellman, they first need to agree on a large prime number with a particular form. There seemed to be no reason why everyone couldn’t just use the same prime, and, in fact, many applications tend to use standardized or hard-coded primes. But there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.

How enormous a computation, you ask? Possibly a technical feat on a scale (relative to the state of computing at the time) not seen since the Enigma cryptanalysis during World War II. Even estimating the difficulty is tricky, due to the complexity of the algorithm involved, but our paper gives some conservative estimates. For the most common strength of Diffie-Hellman (1024 bits), it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year.

iOS 9 and Mac OS X 10.11 Rumors

Mark Gurman:

According to sources within Apple’s software development departments, Apple engineers have been pushing executives for a Snow Leopard-style stability focus in 2015, following numerous bugs that clouded the launches of both iOS and OS X. Apple directors reportedly opposed a complete pause on new features, but agreed to focus on quality assurance by holding back some features that were initially planned for the latest operating system launches. One source explained, “I wouldn’t say there’s nothing new for consumers, but the feature lists are more stripped down than the initial plans called for.”

[…]

Marquee features aside, Apple has been working on significant enhancements to the security fundamentals of both operating systems, ranging from a major new initiative called “Rootless,” re-architected Apple apps with iCloud Drive file encryption, and a new feature called “Trusted Wi-Fi.”

Landon Fuller is worried about Rootless, as one more step towards locking down the system and restricting what apps can do. I would like to see more details on this.

Moving Notes from an IMAP to iCloud Drive back end makes sense. I’m not sure why Gurman says that Reminders and Calendar are also currently using IMAP (rather than CardDAV and CalDAV).

In what will come as a surprise to many people, our sources note that even A5-based Apple devices, including the original iPad mini and discontinued iPhone 4S, will be able to run iOS 9. In order to avoid the sluggishness and bugginess that was most notably seen in iOS 7 for the iPhone 4, Apple has restructured its software engineering process to better support older hardware.

This certainly sounds good.

Swift is planned to reach what is known as “Application Binary Interface (ABI) stability,” and its code libraries will therefore be pre-installed within the new iOS and Mac operating systems. This means that Swift applications updated for iOS 9 and OS X 10.11 will require less space and consume less data when downloaded over a cellular connection.

However, apps would still need to ship the Swift libraries for compatibility with Mavericks and Yosemite.

GitUp 0.7

GitUp (via iOS Dev Weekly):

Work quickly, safely, and without headaches. The Git interface you’ve been missing all your life has finally arrived.

It’s from Pierre-Olivier Latour, of Quartz Composer, Everpix, and Automatic fame. GitUp has a very different interface, focused on the map. For someone like me with a simple repository structure, this does not see like a helpful approach, but I could see it being useful for others. GitUp seems to make manipulating the commit graph easy. Seeing the code that changed in a particular commit, which other Git clients make easy, takes an extra step.

The most interesting feature to me is that it can optionally build an index (SQLite FTS) at .git/co.gitup.mac/cache.db to make searching the repository by diff content very fast. (My main Git client, Tower, doesn’t even have a slow way of doing this.)

GitUp is currently free, but you need to create an account to enable most of the features. It seems to be in a rough state right now: the commit view’s notion of what’s changed in my working directory is out of sync with what other Git clients show [Update (2015-05-26): This is not a bug in GitUp; see the comments.], and trying to commit a file just gave me a “launch path not accessible” error. But I think this is definitely an app to watch.

Update (2015-05-29): Jonathan Wight:

The Map view and Quicklook views are an interesting take on presenting the structure of a git repository while being able to selectively dive into the details of individual commits. I feel however that the information density of traditional Log views in other git clients is superior to the map view.

Compare the following screenshots of the same repo in Gitx and Gitup (both on 13" MBP): GitUp, GitX.

Optical Adjustment

Luke Jones (via iOS Dev Weekly):

In my early days as a designer, I relied on Photoshop or CSS to tell me whether something was right or wrong. If Photoshop indicated that two shapes were aligned, then they were aligned. If two different shapes were the same size, then that was the case. If two colours had the same hex values, then they looked the same colour.

This approach seemed logical, but it was an incorrect way of working.

[…]

Understanding these subtle differences and knowing how to adjust them is what makes a good designer even better — few will notice if it has been considered, but many will notice if it hasn’t.

How Not to Crash #3: NSNotification

Brent Simmons:

I have one simple, hard-and-fast rule: NSNotifications are posted on the main thread only. No exceptions. If some code is running in another thread and it needs to post a notification, it does so on the main thread.

[…]

Your notification handlers should be written so that they can deal with getting called twice. And it should be impossible for a given object to register twice for the same notification. Both.