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.
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;
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.
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).
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.
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?
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:
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.
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?
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.
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.
25 comments
[ 6.0 ms ] story [ 41.2 ms ] threadI 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...
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.
Even so-called zero-knowledge centralized software like iMessage is only a centrally mandated update away from turning their backs on their privacy policy.
iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.
Signal have none of those particular problems.
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.
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:
There's also an optional setting you can enable so that after 10 failed consecutive attempts the device's data is wiped.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...)
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.
https://en.wikipedia.org/wiki/Key_stretching
If this goes badly and loses on all appeals it is over.
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.
If you're the only one to decide what software runs on it, this crap can't be enforced against you.
It is a delicious twist, though.