
DoJ to Apple: we can force you to decrypt - k4jh
http://boingboing.net/2015/10/23/doj-to-apple-your-software-is.html
======
gdwatson
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.

------
Analemma_
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.

~~~
a3n
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.

------
amdolan
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...](https://ia801501.us.archive.org/27/items/gov.uscourts.nyed.376325/gov.uscourts.nyed.376325.15.0.pdf)

~~~
Natanael_L
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.

~~~
lewisl9029
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.

~~~
shalmanese
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.

~~~
chatmasta
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.

~~~
shalmanese
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.

------
Natanael_L
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.

------
snissn
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?

~~~
astrange
[https://www.apple.com/business/docs/iOS_Security_Guide.pdf](https://www.apple.com/business/docs/iOS_Security_Guide.pdf)
page 10.

~~~
ludbb
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.

~~~
Someone
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...](http://arstechnica.com/apple/2015/06/apple-to-
require-6-digit-passcodes-on-newer-iphones-ipads-under-ios-9/))

~~~
ludbb
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.

~~~
scintill76
> 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.

~~~
ludbb
Right, my bad, I missed it.

------
rdl
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.

~~~
kalessin
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?

~~~
dogma1138
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://qz.com/356233/apples-capitulation-to-china-undermines-
obamas-tough-talk-on-snooping/) [http://www.wsj.com/articles/us-presses-china-
on-bank-technol...](http://www.wsj.com/articles/us-presses-china-on-bank-
technology-rules-1425009951)

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...](http://www.dailyfinance.com/2010/08/07/rim-deal-saudi-arabia-
access-blackberry-user-data/)

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.

