[Cryptography] Hope Apple Fights This!

Jerry Leichter leichter at lrw.com
Wed Feb 17 18:29:33 EST 2016


> What they are asking Apple to do is to update code which is not
> (AAUI) secured by that cryptography.  Specifically, they want
> Apple to disable the OS code that counts the number of attempts
> that the user has made to enter the password.  That OS code
> is not customer data and isn't protected by the device encryption.
> 
> If Apple *can* do this, then it cannot legally refuse the order
> unless it wins in court.  Which I hope they do, but in this
> specific case - owner known to have committed multiple murders,
> search warrant pursuant to an ongoing investigation, and compliance
> opens a single device instead of all devices - I don't think they
> will.
TBD.  Courts will require you to turn over any material that already exists - no issues there.  *In general*, they will not compel you to go out and create stuff that doesn't already exist.  The line is gray.  Note that the order itself tells Apple that it can push back if it believes the effort is too onerous.

This case will likely be precedent-setting on exactly the issue of how far the government can go in ordering a third party to do work for it.

> If Apple *can't* do this, then it means they have given up not
> just the ability to get to their customers' data remotely but
> also the ability to update the customers' operating systems
> without the customers' express consent.
Apple has never claimed that ability, and there's no evidence they have it.  Normal updates are user-initiated, at at least user-approved.  Over-the-air updates require the phone to be unlocked.  Updates through iTunes require that the computer running be marked in the phone as "trusted".  Only an unlocked iPhone can mark a new computer as "trusted".  In most cases like this, the FBI would have access to the subject's laptop or other computer, which has probably already been marked trusted.  (Mac's don't have the kind of hardware protection that iPhones do; breaking into them is relatively much easier.)  In this case, the subjects apparently removed the hard disk from their computer, and it hasn't been found - so it's not clear if the FBI has access to a computer the phone considers "trusted".  (I *think*, even in the case of a trusted computer, the normal update process requires an unlocked phone; but I'm not sure of that.)

So it's not clear exactly what Apple would have to do to get into this phone.  We have the court ordering them to do that, and Apple pushing back on principle; we don't know if they could also push back with "we have no technical means to do what you want".  My guess is Apple can find a way to do it - but it would be difficult and would effectively reveal the existence of security hole.

> Because having many different versions of the OS out there makes
> software support into a huge expensive headache, I *REALLY*
> doubt that Apple has given up the ability to push OS updates
> regardless of customer consent. I also don't believe they've
> invested in the kind of hardware security module that would
> protect any individual part of the OS from updates without the
> customer entering the code, while allowing updates to the rest
> of the OS.
a) They don't do such updates today.  There *may* be exceptions for phones set up for remote administration.  I don't think so, though - the main things remote administration can do forcibly is wipe a stolen phone and push policies on things like minimum password lengths - though for the latter, I think you still have to accept the modification.  The main enforcement mechanism is that if you don't accept the profiles, you're denied access to corporate assets like mail accounts.

Since this is a county-owned phone, it *may* have been set up for remote administration - but in that case it's extremely unlikely the attackers would have stored anything even remotely incriminating on it.

b) Apple *has* built such a hardware security module (the "secure enclave" that's part of the CPU chip), and all iPhones since the iPhone 5S include it.

                                                        -- Jerry



More information about the cryptography mailing list