[Cryptography] Hope Apple Fights This!

Ray Dillinger bear at sonic.net
Wed Feb 17 15:38:56 EST 2016



On 02/16/2016 08:58 PM, Harlan Lieberman-Berg wrote:
> Aram Perez <aramperez at mac.com> writes:
>> [The court orders Apple to] disable the feature that wipes the data on
>> the phone after 10 incorrect tries at entering a password."
> 
> The response, of course, is to make sure you design your systems such
> that you can't be put in this situation in the first place.  The newer
> versions of Apple's phones, in fact, use a secure co-processor with
> secure flash for this exact purpose.

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.

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.

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.

So technically, it comes down to the OS update signature check.
If Apple is able to do the remote update, then it can produce
the weapon and sign it with their update key.  At that point
they have an ugly choice.  They can either revoke their update
key, which costs them $Millions because it requires an in-person
update to millions of devices, or it can leave all those devices
vulnerable to surreptitious installation of the fake OS update,
which costs them $Millions in lost customer trust and business.

The only other thing they could have done consistent with their
"everybody's running the same software so support costs are
limited" business model would be to have even "mandatory" OS
updates not take effect until the customer enters the passcode.
But that's a design refinement that I rather doubt they thought
of before now, so one way or another they're going to lose a
hell of a lot of money over this.


				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160217/e441f3f4/attachment.sig>


More information about the cryptography mailing list