DoJ to Apple: we can force you to decrypt | Hacker News Reader

DoJ to Apple: we can force you to decrypt

boingboing.net

74 pointsk4jh25 comments

The full headline on BoingBoing is much better than the abbreviated version: "DoJ to Apple: your software is licensed, not sold, so we can force you to decrypt." The HN headline just means that DoJ hasn't given up the fight; the full headline makes it clear that there's a novel legal argument involved.

While the DoJ's legal argument here is insane and it deserves to be thrown out with prejudice, software companies have happily used the "we're not selling this to you, we're licensing it to you" argument to justify all kinds of gross anti-consumer behavior - including Apple, when they used it to crush Psystar. It's a long shot, but I wonder if the DoJ prevails here it'll make companies think a little harder about whether licensing is the correct way to distribute software, and if consumers might end up getting some rights back because of it.

If DoJ prevails, I would think that the original thoughts that decided licensing was better for a company than selling would still prevail, and they'll just comply with the new legal environment.

It is a delicious twist, though.

The wording that the link discusses is in the pdf[0] section 1.a. on pg 13. Which, for reasons beyond my understanding, argues the point "Apple is not 'far removed' from this matter". The DOJ is discussing a phone that pre-dates iOS 8.

I think the main argument in the linked document is that Apple has the ability to unlock pre iOS 8 phones, and has done it before. Again, that "Apple is not 'so far removed from the underlying controversy that its assistance could not be permissibly compelled.”

The OP seems wrong but IANAL.

> it doesn't have the technical capability to do so;

Is factually incorrect in this case... Right?

[0] https://ia801501.us.archive.org/27/items/gov.uscourts.nyed.3...

Like with iMessage, their claim "we can't" seems to have the catch "today, without changing the code and patching it". While they have a whole bunch of safeguards, they're still actually incomplete as far as I can tell.

In other words, Apple design their security measures under the assumption that they themselves are not the enemy. That's not good enough anymore. If you get compromised, you become the enemy. The designer should lock even themselves out, the end user should be the one in control.

This is exactly why I wish we had more decentralized software that runs only on the client. It's the only way to truly lock yourself out of your users' data.

Even so-called zero-knowledge centralized software like iMessage is only a centrally mandated update away from turning their backs on their privacy policy.

If I try to send you a message and your phone is off and my phone is off by the time you turn your phone on, where does the message live until you turn your phone back on? It has to live somewhere not controlled by either of us if we don't want unacceptable degradations in usability.

can't it just live on the sender's device until the receiver is online? think about sending an iMessage on the subway... "undelivered" doesn't mean that your message is sitting on Apple servers somewhere. it means it's still on your phone and you can try sending it again when you have a better uplink.

When you can't reach Apple, it's undelivered. But there's also the case where you can reach Apple but Apple can't reach the recipient. Then, the message sits on Apple's servers until the recipient can be reached.

Encrypted on the server, TextSecure / Signal has solved that already with 3DH + axolotl.

Right, but that's not software that runs only on the client. There's still a server sitting in the middle.

iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.

The real problem with iMessage is that public keys are unverifiable. The apparent lack of PFS is also a negative. And the iCloud backups in plaintext (although optional).

Signal have none of those particular problems.

Yes decentralized messaging does come with that as a serious usability penalty. But I'm not calling for all communications to be decentralized.

I'd like to see more viable options in this space for communications that truly need to be confidential, both in terms of content and metadata. Centralized services can only provide the former for as long as the centralized provider has not been compromised, and simply cannot provide the latter at all.

Yet another reason for why you as the device owner should be the authority over your own phone.

If you're the only one to decide what software runs on it, this crap can't be enforced against you.

If my phone is protected with a 4 digit pin, and someone has physical access to it, why is it so hard to decrypt? Can someone point me to an explanation of the hardware that protects my data?

https://www.apple.com/business/docs/iOS_Security_Guide.pdf page 10.

The more relevant part about passcodes (4 or 6 digits) is described on page 12.

It's not fully specified, but since the PDF mentions "iteration count" then Apple is using some sort of KDF after you enter your PIN to make brute force attacks harder to perform. It also mentions the following delays:

  Delays between passcode attempts
   Attempts       Delay Enforced
    1-4            none
      5            1 minute
      6            5 minutes
    7-8            15 minutes
      9            1 hour

There's also an optional setting you can enable so that after 10 failed consecutive attempts the device's data is wiped.

Minor correction: "IOS supports six-digit, four-digit, and arbitrary-length alphanumeric passcodes"

Also note how they mention "six-digit" before "four-digit". Six digits is the default on new installations now (http://arstechnica.com/apple/2015/06/apple-to-require-6-digi...)

Sure, that correction is correct ;) but it's not mentioned in that section of the mentioned documented. It leads me to believe that the restrictions described do not apply to them.

> It leads me to believe that the restrictions described do not apply to them.

Which restrictions? The table of delays is on the same page as "six-digit, four-digit, and arbitrary-length alphanumeric passcodes", about 3 paragraphs away. If this is what you're referring to, I see no reason to believe PINs vs. passwords are treated differently.

Right, my bad, I missed it.

Key stretching combined with hardware security (i.e., it's hard to extract the encryption key from the chip).

https://en.wikipedia.org/wiki/Key_stretching

I'm glad Apple has both virtually unlimited resources and a clear desire to win this. It may not be existential risk to them, but enh.

If this goes badly and loses on all appeals it is over.

Isn't the ability to sell their phone in other markets (e.g: APAC) a clear desire to win? I'm not gonna buy or recommend a phone if I know my competitors can tap into it anytime?

Apple and other US tech companies struck a deal with China that reportedly involved handing out decryption keys as well.

http://qz.com/356233/apples-capitulation-to-china-undermines... http://www.wsj.com/articles/us-presses-china-on-bank-technol...

RIM at the time fought Saudi Arabia on the same thing, but has also eventually given up.

http://www.dailyfinance.com/2010/08/07/rim-deal-saudi-arabia...

Companies will always do what it's profitable for them, for RIM Saudi Arabia at the time was a big enough market, today it's China. While there might be some backlash, most people don't care and while you might need to invest money in spinning this if a country doesn't allow you to sell the products in the first place you lose by default.

ATM there seems to be sufficient public pressure to fight against these decisions in the US and Europe, but not so much in other regions, and if China gets to access your phone YBA the US won't be in a position to give up on it either, not that they seem to want to at least at this point in time regardless of that reality.

Reply on news.ycombinator.com