Risks Digest 29.31

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Thursday 3 March 2016  Volume 29 : Issue 31

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
  <http://catless.ncl.ac.uk/Risks/29.31.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Navigation app sends Israeli soldiers into Palestinian area, two dead
  (YNetNews via Mark Thorson)
Over a thousand suitcases not transported on Leap Day (Debora Weber-Wulff)
Palo Alto school's medical privacy case (John R Levine)
No Surprise: Health IT in the ER, new `error' categories (Erik Hollnagel)
SSLv2 Support Compromises TLS Connections (Ars Technica)
IRS identity theft story -- wanna bet it is much, much bigger? (Paul Saffo)
"OpenSSL update fixes Drown vulnerability" (Fahmida Y. Rashid)
Hack the Pentagon (Alister Wm Macintyre)
Re: A 12-year-old girl is facing criminal charges for using certain emoji.
  She's not alone. (David Weil)
Court orders Facebook to release WhatsApp data (James Hughes)
ISIS turns to foreign encryption products as Apple-FBI fight rages in U.S.
  (Daily Dot)
Amazon Quietly Removes Encryption Support from its Gadgets (Motherboard)
NY Judge rules in Apple's favor (Alister Wm Macintyre
Re: Best Explanation for the Apple FBI Hack ... (John Levine, Ted Lee,
  Simson Garfinkel)
EFF and 46 Technology Experts Ask Court To Throw Out Unconstitutional Apple
  Order (EFF)
Apple vs FBI - the Apple logo obscures the issue (Peter Houppermans)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 1 Mar 2016 15:58:30 -0800
From: Mark Thorson <eee () sonic net>
Subject: Navigation app sends Israeli soldiers into Palestinian area, two dead

They asked for the shortest route to their destination, but did not specify
avoiding Palestinian areas.  They passed roadside warning signs, drove into
the area, and were allegedly attacked.  More soldiers were sent into the
area to rescue them, and two Palestinians were killed.

http://www.ynetnews.com/articles/0,7340,L-4773114,00.html

------------------------------

Date: Tue, 1 Mar 2016 16:04:29 +0100
From: Debora Weber-Wulff <weberwu () htw-berlin de>
Subject: Over a thousand suitcases not transported on Leap Day

It's Leap Day, a comp.risks high holiday!

In Germany, the Düsseldorf airport reportedly has 1200 suitcases
stacked up, the local news reports, because the system did not recognize
29 Feb as a proper date.

The automatic luggage distribution system refused to transport some, but not
all, of the 25 to 50 thousand suitcases it deals with a day. The airport
speaker suggested that air travelers pack important things such as medicines
in their hand luggage.

http://www1.wdr.de/nachrichten/rheinland/flughafen-duesseldorf-koffer-schalttag-100.html

Prof. Dr. Debora Weber-Wulff, HTW Berlin, 10313 Berlin +49-30-5019-2320
weberwu () htw-berlin de http://www.f4.htw-berlin.de/people/weberwu/

------------------------------

Date: 3 Mar 2016 16:11:10 -0500
From: "John R Levine" <johnl () taugh com>
Subject: Palo Alto school's medical privacy case

Cystic Fibrosis is a serious genetic disease.  C.C. is a child who has a
genetic marker for CF but does not have the disease, a relatively common
situation.  C.C. only knows about the marker from a genetic screening during
treatment for an unrelated condition as an infant.  A CF web site claims 4%
of all people have a recessive CF gene and hence a CF marker.

C.C.'s family moved from Singapore to Palo Alto in 2012 and enrolled him at
his neighborhood middle school and provided his medical information as part
of the enrollment process.  People who have CF get dangerous lung infections
and should not meet each other due to risk of cross-infection.  Two siblings
who have CF attend the school, and when a school employee improperly told
their parent (Mrs. X.) of C.C.'s genetic marker, she demanded C.C. be
removed.  C.C.'s parents provided a leter from C.C.'s doctor that he did not
have CF and posed no risk, but the school relied on a letter from a "top
Stanford doctor" who had never examined C.C., later revealed to be
Dr. Carlos Milla, and ejected him anyway and moved him to a school several
miles away. C.C.'s family sued, the school backed down, and in 2014 the
district court dismissed the case on the bases that he was back in school
and the school's concern about a threat to Mrs. X's children was reasonable.

C.C.'s parents, the Chadams, appealed the decision to the Ninth Circuit on
the bases that they suffered damages under the Americans with Disabilities
and Rehabilitation Acts, that the court had made unwarranted factual
assumptions when it dismissed the case, and that the school had revealed
even more of C.C.'s private medical data to Mrs. X.

What makes this case more than routine is that the U.S. government
intervened in January with an amicus brief supporting the Chadams.  The
government's brief argues that the school discriminated against C.C. based
on its belief that he had a disability (CF), and that the schools did not
demonstrate that C.C. was a "direct threat" (which would have been hard
since he was and is not.)

This case combines a privacy failure with a medical failure -- C.C.'s
medical information should not have been disclosed, and even if it were, the
school's actions were not supported by medical evidence or necessity.  As
often happens, a privacy failure compounds failures of other sorts.

(This summmary is from court documents in this case, public information on
the courts' web sites.)

------------------------------

Date: Tue, 1 Mar 2016 09:28:20 +0100
From: Erik Hollnagel <hollnagel.erik () gmail com>
Subject: No Surprise: Health IT in the ER, new `error' categories

As ER doctors and nurses grapple with the transition to digitized record
systems, these mistakes seem to be happening more frequently.  ``There are
new categories of patient safety errors'' in emergency rooms that didn't
exist before the push to use electronic record systems, said Raj Ratwani,
scientific director at MedStar Health's National Center for Human Factors in
Healthcare in Washington, D.C.

  Not really surprising. But I wish they would stop calling it "patient
  safety errors" when it is rather increased difficulty in adjusting to
  (ever changing) working conditions. The 'error', if any, is of the people
  who developed, designed, and purchased the technology.

------------------------------

Date: Tue, 01 Mar 2016 06:20:43 -0700
From: "Bob Gezelter" <gezelter () rlgsc com>
Subject: SSLv2 Support Compromises TLS Connections

Ars Technica reports that over 13 million sites still permit clients to
request use of SSLv2, despite long-known flaws. Of these sites, 97,000 are
among the top one million sites on the WWW.

In short, while SSLv2 is not the default, it is possible for it to be
requested. This enables an attack against the servers private key.

It is recommended that all sites verify that SSLv2 support is completely
disabled. An update to OpenSSL related to this vulnerability is soon to
be release.

The Ars Technica article is at:

http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/

------------------------------

Date: Thu, 03 Mar 2016 12:35:32 -0800
From: Paul Saffo <psaffo () mac com>
Subject: IRS identity theft story -- wanna bet it is much, much bigger?

http://krebsonsecurity.com/2016/03/thieves-nab-irs-pins-to-hijack-tax-refunds/#more-34039

I will bet $$$ that this is just the tip of an iceberg, as it is
breathtakingly stupid for the IRS to have been snookered by a KBA attack.

------------------------------

Date: Wed, 02 Mar 2016 09:47:31 -0800
From: Gene Wirchenko <genew () telus net>
Subject: "OpenSSL update fixes Drown vulnerability" (Fahmida Y. Rashid)

Fahmida Y. Rashid, InfoWorld, 1 Mar 2016
The Drown attack decrypts TLS sessions on servers supporting SSL v2
and using RSA key exchange
http://www.infoworld.com/article/3039825/security/openssl-update-fixes-drown-vulnerability.html

selected text:

An international team of researchers has uncovered an attack that can
compromise encrypted network traffic in a matter of hours.

The Drown (Decrypting RSA with Obsolete and Weakened Encryption) attack
successfully decrypts TLS (transport layer security) sessions by exploiting
a vulnerability in the older SSL v2 protocol that exposes private RSA
keys. Once again, old cryptography is breaking the security of all online
communications.  mobile social collaboration faces heads

Drown is different from other attacks against TLS in that it doesn't need
servers to be using the older version; the attack will succeed as long as
the targeted system supports SSL v2. The cross-protocol attack
(CVE-2016-0800) could lead to decryption of any encrypted session using
SSL/TLS protocols as long as the server supports SSL v2 and uses RSA key
exchange, the researchers said in their technical paper.

"In the future we must ensure that all obsolete crypto is aggressively
removed from all systems. If it's not, it's going to come back to bite us,
sooner or later," Ristic said.

  [Don't forget all the other flaws, brought to light by the IEEE SSP
  best paper by Beurdouche et al., noted in RISKS-28,58.  PGN]

------------------------------

Date: Thu, 3 Mar 2016 05:16:56 -0600
From: "Alister Wm Macintyre \(Wow\)" <macwheel99 () wowway com>
Subject: Hack the Pentagon

The U.S. Department of Defense (DoD) has invited hackers participate in
"Hack the Pentagon", to find & report vulnerabilities in some of their
websites.

Volunteers must be US citizens who pass a background check.

Beware, background checks may get you on OPM, which gets hacked thru an NSA
back door.

A new US agency has been launched to replace some of OPM activity, the
National Background Investigations Bureau (NBIB).

I hope the replacement system learns from the mistakes of OPM.  This kind of
data does not need to be on the Internet, it should be on an intranet.

That way NSA back doors do not reveal the data to as many adversaries.

https://www.helpnetsecurity.com/2016/03/02/hack-the-pentagon-hackers-asked-to-help-secure-public-facing-systems/

  [On an intranet?  But the Dark Net is not all that invisible...  PGN]

------------------------------

Date: Wed, 2 Mar 2016 11:50:28 -0500
From: David Weil <theobviousname () gmail com>
Subject: Re: A 12-year-old girl is facing criminal charges for using certain
  emoji. She's not alone. (RISKS-29.30)

Does this mean that the authorities are going to make (school) libraries
censor all symbol-based swearing from their collections?  If I'd had a smart
phone when I was twelve, I might have done this too -- because that was the
way the comic books I read depicted swearing.

http://tvtropes.org/pmwiki/pmwiki.php/Main/SymbolSwearing
http://2.bp.blogspot.com/_fnXu10W5PIY/S7A1IhXZV-I/AAAAAAAADQU/PvPnFfRYueo/s1600/swear.gif

(There are a bomb, a knife, 2 skulls, 2 guns, and 3 symbols that look like
explosions.) [However, even for those who are trope-o-philes rather than
trope-o-phobic, it may be difficult to distinguish one expletive from
another.  %^&#@!  PGN]

------------------------------

Date: Thu, 03 Mar 2016 09:31:14 -0800
From: James Hughes <jphughes () mac com>
Subject: Court orders Facebook to release WhatsApp data

A court had ordered Facebook to provide data from WhatsApp, a messaging app
it owns, in connection with a criminal investigation into drug
trafficking. Police in Sao Paulo questioned Facebook's VP for Latin America
Diego Dzodan on Tuesday, and he remained in jail overnight.
http://money.cnn.com/2016/03/02/technology/facebook-brazil-executive/index.html

  This could easily escalate to jailing random employees to extort a
  backdoor. This would be easier in some countries than others.

------------------------------

Date: March 2, 2016 at 12:00:50 PM EST
From: Lauren Weinstein <lauren () vortex com <mailto:lauren () vortex com>>
Subject: ISIS turns to foreign encryption products as Apple-FBI fight
  rages in U.S. (Daily Dot)

http://www.dailydot.com/politics/isis-apple-fbi-congressional-hearing-crypto-international/

  Prompted by a case related to the ISIS-inspired terrorist attack in San
  Bernardino, the intense discussion heavily focused on thwarting the
  Islamic State.  But ISIS supporters online didn't seem worried at all.
  Instead, they've spent the week--and longer--promoting strong encryption
  tools from outside the United States that the American government cannot
  touch with legislation.  In the last month, Islamic State supporters have
  promoted security software from Finland, Romania, America, France, the
  Czech Republic, Canada, Panama, Germany, Switzerland, Saint Kitts and
  Nevis, and other nations, a Daily Dot review found.

------------------------------

Date: Thu, 3 Mar 2016 13:26:06 -0800
From: Lauren Weinstein <lauren () vortex com>
Subject: Amazon Quietly Removes Encryption Support from its Gadgets

  While Apple is fighting the FBI in court over encryption, Amazon quietly
  disabled the option to use encryption to protect data on its
  Android-powered devices.  The tech giant has recently deprecated support
  for device encryption on the latest version of Fire OS, Amazon's custom
  Android operating system, which powers its tablets and phones. In the
  past, privacy-minded users could protect data stored inside their devices,
  such as their emails, by scrambling it with a password, which made it
  unreadable in case the device got lost or stolen.  With this change, users
  who had encryption on in their Fire devices are left with two bad choices:
  either decline to install the update, leaving their devices with outdated
  software, or give up and keep their data unencrypted.
https://motherboard.vice.com/read/amazon-removes-device-encryption-fire-os-kindle-phones-and-tablets

------------------------------

Date: Mon, 29 Feb 2016 21:24:37 -0600
From: "Alister Wm Macintyre \(Wow\)" <macwheel99 () wowway com>
Subject: NY Judge rules in Apple favor

A federal judge has ruled that Apple does not have to unlock iPhone in a New
York drug case, where the All Writs Law was used,

This is NOT the San Bernardino case, but there are similarities.
* All Writs Act used in both cases.
* NY case is an iPhone running iOS 7.
* San Bernardino case asks for a lot more than was asked in NY case.

According to news media reports, Judge James Orenstein wrote:

``The U.S. government's argument doesn't justify "imposing on Apple the
obligation to assist the government's investigation against its will.''

``The government posits a reading so expansive -- and in particular, in such
tension with the doctrine of separation of powers -- as to cast doubt on the
AWA's constitutionality if adopted.''

``Nothing in the government's arguments suggests any principled limit on how
far a court may go in requiring a person or company to violate the most
deeply rooted values to provide assistance to the government the court deems
necessary.''

Orenstein said law enforcement is inappropriately trying to use powers that
it hasn't been given by Congress.

The feds say they will appeal this case.

http://www.politico.com/story/2016/02/federal-judge-apple-doesnt-have-to-unlock-iphone-in-ny-case-219999

http://money.cnn.com/2016/02/29/technology/judge-apple-feds/

http://www.wired.com/2016/02/judge-says-apple-doesnt-have-to-unlock-iphone-in-case-similar-san-bernardino/=20

To avoid confusion, be aware that there are about 60,000 cases of law
enforcement demanding that Apple unlock individual iPhones, about a dozen of
them from the feds, including the San Bernardino terrorist iPhone.  A ruling
in one case is not a binding precedent on other cases, and some people can
even defy the US Supreme Court with impunity.

The antique nature of the All Writs Law is not relevant, unless you also
want to throw out the US Constitution, which has the same age.

------------------------------

Date: 1 Mar 2016 02:18:02 -0000
From: "John Levine" <johnl () iecc com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Garfinkel, R-29.29)

> There is an error in Rebecca Mercuri's analysis of the FBI-Apple issue.

Well, maybe.

> FBI can image the phone (phone "cloning" is something else, BTW), but FBI
> cannot image the secure enclave.

Indeed they cannot, because the Secure Enclave was introduced in the A7
processor used in the iPhone 6 series, and the A6 processor in the San
Bernadino iPhone 5C doesn't have one.

As I read the Apple document, the main CPU in the A6 contains the secret
random UID and only has instructions to use it as part of a key for
encryption or decryption.  So it seems like the claim is correct that if
Apple wrote and installed a new GovtOS, that OS could use the crypto
instructions to test entered passcodes, but not add the time delays or do
the data wipe.

For that matter, why couldn't GovtOS just try all of the passcodes itself
and display the one that worked on the welcome screen?  Seems a lot easier
than entering them all by hand or via some remote data source, although I
suppose that would make it more obvious what a privacy disaster it was.

------------------------------

Date: Mon, 29 Feb 2016 20:29:46 -0600
From: Ted Lee <tmplee () gmail com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Garfinkel, R-29.30)

Simson Garfinkel wrote:

> FBI can image the phone (phone "cloning" is something else, BTW), but FBI
> cannot image the secure enclave.

Simson said essentially what I said, but got this almost irrelevant point
wrong.  The 5c under question does not have the secure enclave.  What is not
clear from the white paper is how much of the software (aka firmware) in the
secure enclave is burned in silicon and how much is booted from the file
system.  I am guessing that just like for the application processor the
lowest level boot code is burned in hardware and everything else is pulled
in from the file system (after passing the signature check.)  What the
secure enclave does is complicated enough it would seem necessary to be able
to update it ("securely", of course) when a bug needs to be fixed or some
design enhancement made.  It is clear, for instance, that the Touch ID code
is updateable, since that is one of the publicly announced changes in one of
the recent IOS updates.  So I suspect a court order to do the same sort of
thing on, say, a iPhone 6, that they are asking be done on the 5c would be
technically possible -- just more complicated.

BTW, I don't know how many people reading this noticed that there were some
recent press reports that Apple is already designing fixes for the
vulnerabilities in the present state of affairs, including those in the
iCloud backup process that allows Apple to accede to warrants for backups.

See, for instance, among several similar articles,
http://www.nytimes.com/2016/02/25/technology/apple-is-said-to-be-working-on-an-iphone-even-it-cant-hack.html

------------------------------

Date: Tue, 1 Mar 2016 07:12:15 -0500
From: Simson Garfinkel <simsong () acm org>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Levine, R-29.29)

John Levine helpfully indicated that the Apple iPhone in question is a 5C
which does not have a "Secure Enclave."

I was confused, because I had referred to the current Apple iOS Security
Guide [1].  The operative Security Guide for the iPhone 5c is Apple's May
2012 Security Guide [2], which is no longer available on the Apple website,
but which is available on a course website at MIT [2].

In the previous Security Guide, Apple uses the term "tangled" to describe
the combination of the hardware AES key with the user's PIN. (The current
Security Guide's use of the word "entangled" comes from quantum computing,
although there is no quantum computer within the iPhone.) On the 5c is AES
key is burned into the Apple processor.

The important difference, as John and I discussed in several private emails,
is that the hardware does not enforce wiping of the key, which is enforced
by Apple's operating system. This means that if you can perform a forensic
removal and restore of the memory in the iPhone 5c, you can do a brute force
attack, with an 80msec delay between each attempt.

So the question is this: how can you remove and restore the memory of the
iPhone 5c?  Oxygen Forensics [3], one of the leading iPhone forensics
providers, claims that the passcode is required for memory
extraction. Another way is to use the JTAG interface, but I've found no
indication online that this is possible with an iPhone 5C. It may be
possible remove the surface mount memory chips and try to set up some kind
of socket arrangement, so that the memory can copied out and repeatedly
rewritten as the next 10 codes are tried. To get an idea of how hard this
would be, look at the iFixIt teardown photos of the iPhone 5c [4]. The
memory module is evident in Step 10, the Toshiba THGBX2G7B2JLA01 128 Gb (16
GB) NAND flash. Good luck getting that off without damaging the A6 processor
on the other side. I haven't heard of anyone doing this in practice.

I wrote an article about back in 2012 that discussed these issues in more
depth [5].

[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
[2] http://css.csail.mit.edu/6.858/2015/readings/ios-security-may12.pdf
[3] http://www.oxygen-forensic.com/en/compare/devices/software-for-iphone
[4] https://www.ifixit.com/Teardown/iPhone+5c+Teardown/17382
[5] https://www.technologyreview.com/s/428477/the-iphone-has-passed-a-key-security-threshold/

However, Apple's Security Guide specifically discusses another approach for
extracting the key. Once it's extracted, you can mount an attack on your
cluster:

"A 256-bit AES key that's burned into each processor at manufacture. It
cannot be read by rmware or software, and is used only by the processor's
hardware AES engine. To obtain the actual key, an attacker would have to
mount a highly sophisticated and expensive physical attack against the
processor's silicon. The UID is not related to any other identifier on the
device including, but not limited to, the UDID."

------------------------------

Date: March 3, 2016 at 4:09:14 PM EST
From: "EFF Press" <press () eff org>
Subject: EFF and 46 Technology Experts Ask Court To Throw Out
  Unconstitutional Apple Order

Cindy Cohn, Executive Director, cindy () eff org, +1 415-436-9333 x108
David Greene, Civil Liberties Director, davidg () eff org, > +1 415-436-9333 x143

EFF and 46 Technology Experts Ask Court To Throw Out Unconstitutional Apple
Order Forcing Apple to Write and Sign Code Undermining iPhone Security
Violates First Amendment

Riverside, California -- The Electronic Frontier Foundation (EFF) and 46
technology industry experts, including inventors of modern cryptography,
told a federal court today that forcing Apple to write and sign computer
code disabling crucial iPhone security features that protect millions of
users violates the company's free speech rights.

The Federal Bureau of Investigation (FBI) should not be allowed to, in
 effect, stand over the shoulders of Apple programmers and force them to
 create and sign off on code that would decimate the iPhone;s security, EFF
 said. The signed code would send a clear message that it's OK to undermine
 encryption that users rely on -- a view the government endorses but Apple
 fiercely opposes. EFF made its arguments in a friend-of-the-court brief
 filed today in U.S. District Court for the Central District of
 California. The brief was signed by 46 technologists, security researchers,
 and cryptographers, including digital signature pioneers Martin Hellman and
 Ronald Rivest.  [...]

------------------------------

Date: Tue, 1 Mar 2016 09:34:20 +0100
From: Peter Houppermans <peter () houppermans net>
Subject: Apple vs FBI - the Apple logo obscures the issue.

To quote the (sadly) late Louise Rennison: "Honestly, what planet do these
people live on?  Any why isn't it farther away?"

Let me give a different slant to this, amalgamating a number of aspects into
one article.  My apologies for the length but, paraphrasing Mark Twain, I
don't have time to shorten it.  Please note that this is opinion, I'm not a
lawyer.

To recap:

- Apple was ordered to assist in accessing an iPhone 5C, the only device
  the San Bernadino shooters had not wiped;
- To do so, Apple would have to break its own security, and create
  forensic tools that as yet do not exist;
- The order states it would be a one-off, never to be repeated, limited,
  unique (etc., etc.) exercise;
- Apple has filed a later motion that shows other pending cases by the
  FBI, so much for the one-off, but we'll get back to that.

The technical bit:

- There has as yet not been even the most remote assessment of this
  being possible, although the 5C is rumoured to be the last model with
  *some* softness in its protection;
- There have been no statements as to what would happen in the purely
  theoretical case that Apple would and could do this, and then fails;
- It is not possible to lift the data from the device and run it on (n)
  virtual machines to crack it because the encryption is tied to a unique
  chip in the device that is designed to defy analysis.  In other words,
  lifting the data from the device means trying a lot more passwords than
  just a 4 digit PIN (how do we know it's only 4 digits?).
- As the phone is the property of the State, it was supposed to be
  managed via a Mobile Device Management system (MDM) which would have
  allowed changing the PIN.  This went wrong, so from a technical
  perspective this is asking a Super Secure Safe manufacturer to publicly
  crack their own safe AFTER the receiving bank had set its own
  combination and forgot what it was.

The real problem in my opinion:

- By going public instead of following informal channels, this order
  demands that Apple commits commercial seppuku by publicly undoing many
  man years of security development.
- The US legal system relies on precedent.  It is so fundamental that
  there is no established way to *prevent* precedent setting, and that
  renders any success of this case a template for repeat ad infinitum
- Both FBI council and judge should be familiar with the principle of
  precedent, which makes "this is a one-off statements" not just
  questionable and misleading, but actively alarming.
- The thickness of the terrorist sauce poured over this case alone is
  enough to set off alarm bels.  Experience shows that the more emotional
  pressure is exerted, the more one must look underneath to see what the
  attempt at emotional distraction seeks to conceal.

My theory:

- Establishing such a precedent will initiate an absolute FLOOD of demands,
  affecting every US provider of equipment and services of note.  The aim of
  such a campaign of simple brute harassment would be to make it simply more
  economical for such companies to build in a backdoor than to fight lawsuit
  after lawsuit.  Capitalism works.  Some evidence is already apparent of
  this harassment as the on-off clearly wasn't as shown by Apple's latest
  filing.  In this context it is worth noting that the FBI has been a long
  standing and vocal critic of iOS security;

- The next thing that happens to such a precedent is scope creep.  Now it
  would used to access data of evil people with suspected links to terror
  (note that that is very carefully already one step removed from "people
  suspected of being terrorists themselves"), but eventually that will be
  worn down, precedent after precedent to "anyone we feel like investigating
  because, well, hey, the sun is shining and we are bored".

- In short, the long con appears to be a play to get the beloved backdoors
  in place, this time the attack vector is a campaign of aggressive legal
  harassment using the above precedent. The FBI doesn't have to worry about
  costs as it uses the tax payer's money and it gives their flood of lawyers
  something to do, but the companies so attacked are not just facing costs,
  see below.

Conclusions and questions:

- FBI as well as DoJ are publicly stating here that "the fate of the world"
  (to slide along with the hyperbole) depends on access to the one and only
  device the San Bernadino killers did NOT bother wiping (and to which they
  should have had access if not for technical error).  Thus, they casually
  admit that they were unable to gather enough alternative intelligence,
  despite multi-billion dollar budgets and unprecedented vaguely legalised
  data access powers since 9/11: they need the data on that single
  off-the-shelf consumer device so desperate that they are quite prepared to
  harm the security of billions.  What on earth have they then done with
  those budgets and powers?  Methinks Congress ought to know.

- The implications of a win are that it will no longer be possible to
  protect ANY information held on US provided equipment and services.
  Consumers might as well buy a Chinese knock off for the level of security
  it brings.  One would presume that Huawei et al are praying on their knees
  that the FBI and DoJ win this because it will pretty much bar US providers
  from selling into markets that respect the right to privacy, and that is
  not just Europe.  A win for the DoJ and FBI is would be the last straw for
  Silicon Valley companies already reeling from the EU canceling Safe
  Harbor.  It confirms my opinion that in matters privacy, security plays
  but a quiet second fiddle - law comes first (to be exact, security
  actually plays *third* fiddle, but that's for another day).

- It is worth noting that FBI and DoJ appear not to be above misleading the
  American public and the Court (from what I have gathered, it appears the
  judge merely went along with FBI's talk about one-off, which is troubling
  in itself). Any talk about this affair being "once, "a one off", "an
  exception", "a special case" and "limited" is wilful misdirection and no
  doubt will now be used by any defence lawyer seeking to discredit the
  agency's statements in Court.  Oops.

- Is it really a good idea to set a precedent that it is quite OK to legally
  compel a company to commit commercial suicide when it has not broken any
  laws?

And finally:

- Don't get me wrong, I am for law enforcement having the tools to do their
  job, but with great power comes great responsibility and I have as yet not
  seen any movement towards the required transparency and accountability for
  such powers to be exercised.  Edward Snowden's revelations should have
  been a wake up call, but not much has changed.

- Asking Apple to remove its security because bad people use it is
  equivalent to asking Volvo to remove all car safety measures because
  criminals use their cars to ram-raid shops.  If I recall correctly,
  harming a large volume of people at once is supposed to be the
  *terrorists'* modus operandi.

- Given that the FBI considers iPhones so uncrackable, are Apple now their
  phone provider of choice? :)

------------------------------

Date: Mon, 17 Nov 2014 11:11:11 -0800
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
 comp.risks, the feed for which is donated by panix.com as of June 2011.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.  The mailman Web interface can
 be used directly to subscribe and unsubscribe:
   http://mls.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
   risks-request () csl sri com
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe () csl sri com or risks-unsubscribe () csl sri com
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
   <http://www.CSL.sri.com/risksinfo.html>
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users may contact <Lindsay.Marshall () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line.
 *** NOTE: Including the string `notsp' at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 http://www.risks.org takes you to Lindsay Marshall's searchable archive at
 newcastle: http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's historical Illustrative Risks summary of one liners:
    <http://www.csl.sri.com/illustrative.html> for browsing,
    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing
  is no longer maintained up-to-date except for recent election problems.
 *** NOTE: If a cited URL fails, we do not try to update them.  Try
  browsing on the keywords in the subject line or cited article leads.
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 29.31
************************