[Cryptography] Is Apple correct?

[Tom Mitchell]

On Fri, Feb 19, 2016 at 3:53 AM, CANNON NATHANIEL CIOTA <
cannon at cannon-ciota.info> wrote:

> In reference to the current Apple scenario.
> I do believe government with too much power is as equal of a threat as
> much as criminals are.
> I would side with Apple if the government is demanding a backdoor or
> backdoor equivalent tool that would affect other people.
> My question is, how can the FBI's demands be considered a backdoor
> affecting anyone as if I understand correctly, would affect only the one
> specific device?
> If the firmware is programmed to only work on a phone with that specific
> IMEI number signed by Apple, am I correct that the firmware could not be
> modified to work on any other device since the signature would not match?
> Or is it that Apple fears that this may open up unintended security
> vulnerabilities in eveyrone elses phone i.e. if the IMEI number could be
> spoofed thus causing it to act as a backdoor?
>
> Please provide clarification.


This court is mandating an engineered  service.
If programmed to work on a specific IMEI -- it does not matter the existence
of the service has been established and ANY court can demand the service.
Any individual or company could purchase the service.

This is not a service or business Apple wants to be in.  It is counter to
their business model and goals that depend on a secure platform
and system -- Apple Pay, iTunes both move vast sums of money.
Yes Apple collects a fee for the transaction but that transaction fee is
a lot less than the transaction.   Thus the trust chain loses credibility.
Micropayments (and macro)  is a big deal it is central to all cell phone
services
in the future.

The nature of a court order makes it impossible for Apple to deny the
frivolous ones or even inquire as to the validity of the case or issue
behind
the order.
Once demonstrated they must research each and fight the bad ones which is
expensive or simply
rubber stamp them all.  Since they cannot research them all ...

There are two interesting things at risk for both sides.   Apple risks the
entire future
value of all their payment based products... BIG $$$
On the other side the All Writs Act is at risk a little or a lot.
A quick glance and the choice for a higher court is to
nullify the All Writs Act or not support this federal warrant.
I do not see aspects of the All Writs Act that can be isolated and struck
down
but I am not skilled in law to bet anything on this point.

Of interest this is not so much a side door but legally it removes the
entire side
of the house and one you leap over the fence the way meter readers to
there are no protections left.   Just rubbish to trip over once you are in.

This modification is ultimately invisible to the owner of the phone.
Steal/ borrow the phone in a bar or some other way.   Get it opened
install a virus or extract data, other pass words, download pornography.
Return it to the owner via a lost and found path.

An angry spouse can bring such a phone to court and submit it
as evidence of fraud, evil, foolishness...

This specific ruling does not place secrets in the hands of the FBI to
misplace
which is clever on their part.

Once demonstrated the binary version 2 can be built to load on any IMEI.
I once had to debug a unix kernel that a student had binary edited to
disable the UID=0 test.
One instruction was changed.  Checksums and signatures make this simple
change unlikely... but.
Once shown to load on any IMEI for reasons of national security a delivery
of
the  binary can be compelled by US and international courts.
The Vatican can demand that a device be unlocked to pursue child abuse.
None would deny this of the Vatican and most would allow the order to be
secret to protect the unnamed children.  It need not be a phone owned
by a priest or clergy.

At issue is not a single phone or single crime but "the first" phone
and a compelled service.   Much more than limiting key export to N bits.

This is a big deal.






-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160219/38cff714/attachment.html>