Risks Digest 29.30

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

RISKS-LIST: Risks-Forum Digest  Monday 29 February 2016  Volume 29 : Issue 30

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.30.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:  [Happy Leap Day; See Mark Brader' quadrennial message]
Risks of Leap Years and Dumb Digital Watches (Mark Brader)
A 12-year-old girl is facing criminal charges for using certain emoji.
  She's not alone. (WashPo via Gabe Goldberg)
Google Wants Less Reliable Hard Disks (Thomas Claburn)
Asus lawsuit puts entire industry on notice over shoddy router security
  (Ars Technica)
The FBI wants a backdoor only it can use, but wanting it doesn't make it
  possible (The Guardian)
It Really Doesn't Matter What Apple's Motivations Are --
  Idealistic or Other Wise (NYMag)
Re: Best Explanation for the Apple FBI Hack ... (Taed Wynnell, DrM,
  Ted Lee, Al Mac, DrM, Simson Garfinkel)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 29 Feb 2016 13:25:18 -0500 (EST)
From: msb () vex net (Mark Brader)
Subject: Risks of Leap Years and Dumb Digital Watches

All right now, how many people reading this:

[1] saw a previous version of this message in RISKS-6.34, 13.21, 17.81,
    20.83, 23.24, 25.07, and/or 26.75;

[2] still wear a wristwatch instead of using a cellphone or something
    as a pocket watch;

[3] have the kind that needs to be set back a day because (unlike the
    smarter types that track the year or receive information from
    external sources) it went directly from February 28 to March 1;

and

[4] *hadn't realized it yet*?

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

Date: Sun, 28 Feb 2016 12:35:38 -0500
From: Gabe Goldberg <gabe () gabegold com>
Subject: A 12-year-old girl is facing criminal charges for using certain
  emoji. She's not alone.

The smiley face, heart, praying hands and other "emoji" have become the way
millions of Internet users playfully punctuate their texts, posts and
messages, but for one middle schooler the icons brought the police to her
door.

The 12-year-old from Fairfax, Va., has been charged with threatening her
school after police said she posted a message on Instagram in December laden
with gun, bomb and knife emojis.

https://www.washingtonpost.com/news/local/wp/2016/02/27/a-12-year-old-girl-is-facing-criminal-charges-for-using-emoji-shes-not-alone/?tid=pm_local_pop_b

The risk? Clashing cultures, evolving communication, and misunderstood (or understood all too well) language.

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

Date: Fri, 26 Feb 2016 13:01:15 -0500 (EST)
From: "ACM TechNews" <technews-editor () acm org>
Subject: "Google Wants Less Reliable Hard Disks"

Thomas Claburn, InformationWeek, 25 Feb 2016
via ACM TechNews, Friday, February 26, 2016

In a research paper published Tuesday at the USENIX File and Storage
Technologies (FAST 2016) conference, Google researchers called on academia
and industry to work together to adapt hard disk drives to current data
center needs.  Google wants designs that are more affordable, more
error-prone, and better suited to collective operation.  Google's Eric
Brewer says conventional disks are designed for traditional servers instead
of large-scale data centers supporting cloud computing.  Brewer expects the
rate of video uploading to grow 10-fold every five years, and in order to
accommodate this massive amount of data, he argues hard disks should be
optimized to function as collections of disks instead of discrete devices
associated with a single server.  "This shift has a range of interesting
consequences, including the counter-intuitive goal of having disks that are
actually a little more likely to lose data, as we already have to have that
data somewhere else anyway," Brewer says.  The Google researchers also say
security must be improved as new use cases for storage are considered.  They
say security must be hardened to prevent unauthorized firmware changes and
encryption must be adapted to collections of disks through the support of
multiple keys, which would make it easier to secure data from different
customers in shared disk space.
http://orange.hosting.lsoft.com/trk/click?ref=3Dznwrbbrs9_6-eb02x2dd87x065381&;

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

Date: Sat, 27 Feb 2016 20:00:45 -0500
From: Gabe Goldberg <gabe () gabegold com>
Subject: Asus lawsuit puts entire industry on notice over shoddy router
  security

http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on-notice-over-shoddy-router-security/

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

Date: Sat, 27 Feb 2016 19:08:32 -0500
From: Gabe Goldberg <gabe () gabegold com>
Subject: The FBI wants a backdoor only it can use, but wanting it doesn't
  make it possible (The Guardian)

Author's comment:

My latest Guardian column traces the connection between vaccine denial,
climate denial, and the denial of ground mathematical truths, like "You
can't build a secure system with a back door that only admits good guys"
or "You can't hide keys in a computer you give to your adversary."

In all cases, the science is largely settled, but policy-makers treat it
as though it's controversial among experts.

http://www.theguardian.com/technology/2016/feb/24/the-fbi-wants-a-backdoor-only-it-can-use-but-wanting-it-doesnt-make-it-possible

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

Date: Sat, 27 Feb 2016 10:48:38 -0500
From: Monty Solomon <monty () roscom com>
Subject: It Really Doesn't Matter What Apple's Motivations Are --
  Idealistic or Other Wise

http://nymag.com/following/2016/02/apple-doesnt-care-about-you.html

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

Date: Fri, 26 Feb 2016 19:12:54 +0000
From: Taed Wynnell <TWynnell () vertical com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

I liked what you had to share on RISKS, but I think that Apple would be able
to take the password brute force one step further, and it's possible that
any Apple developer could (namely the FBI or a consultant).  There is
probably a development tool such as a simulator or virtual machine that
could start with the memory state of the phone in custody.  I'm sure Apple
would have such a tool, but I don't do iOS development so I don't know if
one is widely available.  If such a tool exists, you could just spawn 10,000
copies of it (in series or some parallelism) and provide the appropriate
virtual key presses to each.  The first time to do such a task would surely
require some setup of the scripts to do the spawning and to get them in the
right initial state, but I would imagine that to be less than a few hours.
At that point, you're probably only looking at about a small number of hours
to simulate/virtualize all of those copies and to run the 4 keypresses on
each.  Detecting success or not could be scripted, or would be simple to
just look at the simulated display to see if it logged in or not.  So start
to finish, you're probably only looking at 1 person working for one day, but
of course, it would have to be the right person doing it.

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

Date: Fri, 26 Feb 2016 15:12:38 -0500
From: DrM <notable () mindspring com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Wynnell, R-29.30)

I agree. Back in the day, when I (and Notable Software) were "Apple
Certified Developers" I seem to recall there was such then. I did think
about simulating when writing this, but didn't want to clutter up the
posting with that. And writing a simulator (if one doesn't already exist) is
a lot harder than the work-around they proposed in their court filing. I can
see the 10,000 virtual clones existing in the (i)Cloud to save memory. ...
Thanks for your message. Rebecca Mercuri.

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

Date: Fri, 26 Feb 2016 13:55:50 -0600
From: Ted Lee <tmplee () gmail com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

While Rebecca's note presents a good case, it fails to take into account an
important element of the security design of the iPhone. More out of a
busman's holiday curiosity than anything, I've carefully studied the five
revisions of the white paper Apple has written describing iPhone security.
While parts of them are obscure and even in some ways surprisingly
inconsistent, one point is very clear: the device's unique ID is burned into
silicon in the processor and not readable by anything.  (As a former
security "expert" I have to say I am very impressed by the security design
Apple has come up with.)

Quoting from the earliest white paper I've been able to find, dated May
2012, which would apply to the "Subject Device":

"Every iOS device has a dedicated AES 256 crypto engine built into the DMA
path between the flash storage and main system memory, making file
encryption highly efficient."

"The device's unique ID (UID) and a device group ID (GID) are AES 256-bit
keys fused into the application processor during manufacturing.  No software
or firmware can read them directly; they can see only the results of
encryption or decryption operations performed using them. The UID is unique
to each device and is not recorded by Apple or any of its
suppliers. ... Burning these keys into the silicon prevents them from being
tampered with or bypassed, and guarantees that they can be accessed only by
the AES engine."

Thus, cloning the memory of a device would be useless.  The only way of
accelerating an attack (brute force search for the device passcode) would be
to extract the 256 bits of the UID directly from the silicon; not knowing
anything about the technology involved or the current state of "reading" a
chip I wouldn't be able to speculate on how easy that is or even if the FBI
has the technology to do so.

Thus, the fastest rate passcodes could be brute-force searched, no matter
what software is substituted for Apple's firmware and software, is 80ms per
try, since the "tangling" algorithm is serial and involves repeated passes
through the AES chip.  I have seen assertions that the passcode in question
is 4 digits; I have no idea how anyone would know that.  The white paper
notes that a 6-character alphanumeric (upper and lower case + numbers)
passcode would take 5 1/2 years to crack.  The reader can do the math to
tell how long, say, an 8 character one, for instance, would take.

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

Date: Fri, 26 Feb 2016 14:39:13 -0600
From: "Alister Wm Macintyre \(Wow\)" <macwheel99 () wowway com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

Rebecca Mercuri says the link she shared is the best explanation she has
seen, for what is needed.

Her credentials, and others here at RISKS, are far superior to mine.  I was
merely a general IT worker.

But this debate has been going on for years, long before the latest
terrorist attacks and this particular court case.

Books have been written on the issues.  It is not a simple matter.

I think, what she shared, is a good explanation of the DOJ/FBI starting side
in the adversarial dispute in the court case which has most recently grabbed
MSM attention.  Their side has evolved, via additional court filings, as
Apple identified problems (flaws, untruths, difficulties) in the initial
DOJ/FBI filing, to which DOJ/FBI has responded to the court, and the court
has asked Apple for clarification, which has been delivered..

As such, what she shared is not a good picture., since the initial court
order had untruths, which later reports have illuminated, and the court
filings continue.

In my opinion, a good picture is one which shows many sides in perspective,
such as this Time Line mountain of links

http://markn.ca/2016/02/apple-vs-the-fbi-the-highlights/

This timeline has links to what has been stated by professionals on both
sides of the court battle, and larger issues of privacy, encryption, back
doors, national security, the constitution, what should be decided by
courts, Congress, administration, capitalism.

It shows responses to allegations, from which we learn that there are many
untruths in what the DOJ/FBI said to the judge, repeated by the article
Rebecca likes.  In time, we may see responses to Apple position, which are
on point, instead of DOJ/FBI characterizing them as marketing policy, which
is a form of trolling, unworthy of the government.  They should attack the
issues, not demonize the defendant.

* Apple does NOT have the key the FBI is asking for.  They have to engineer
it.  That will take 6-10 engineers working 2-4 weeks..  In addition, there
are implied requirements to sufficiently document the process, so that the
rights of a person to face their accuser can be satisfied, if this info is
ever used against someone in a US court of law.

* Encryption and backdoors are an issue.  Any destruction of security for
one government case becomes a precedent for many more, and opens the door
for ISIS and other adversaries to exploit the security holes for their own
ends.  Remember the OPM breach?  That was made possible by a back door
inserted by NSA, which is now all over US government sites.  We have not yet
been told NSA's reasoning, but reading between the lines, it is reasonable
to infer, that they had a fantasy that any security hole they created, could
only be exploited by them, and not by the nation=92s adversaries.  We are
now seeing the same fantasy in the DOJ/FBI case against Apple.

What we have not yet seen is info from Friends of the Court.

* She also says it is unlikely for Apple engineers to actually work 50 hour
weeks.

It is entirely normal in the IT profession for people to work 50-65 hour
weeks.  In might not be normal at Apple, or in her career experience.

In my career, it was not unusual to have crises requiring longer working
hours than usual, such as reacting to a crash, implementing a conversion,
responding to government auditors.  They want that resolved yesterday!  We
can't get it that fast, but we try to get it as fast as we can.

We IT workers are also sometimes motivated to work long hours.  Once upon a
time, the CEO walks into the computer room at 7 am and asks what I am doing
here at this hour (I normally work swing shift afternoon & evening.) I tell
him that I have been here all night.  We had a hard disk crash & IBM
estimates they will be here mid-day with a replacement.  They also told me
how to work around the magnetic hole to back up whatever we can around the
edges of the hole.  It is tedious, but I expect to get done with that before
the replacement hard drive arrives.  No one may use the system until after
IBM repair is completed.  You might want to give some clerks a day off,
those whose jobs require computer access.  After this is all resolved, I am
going to take the next weekend off.

I once worked several months working 2 1/2 shifts, 6 day week, with single
shift on the 7th day.  That was just over 100 hours a week.

It is doable if you are: in good health, no more than middle aged, the
stress levels are extremely low, and someone else fixes our food, to
maximize sleep time between long work sessions.

There are issues with fatigue impairing our productivity.  Some companies do
a good job of balancing how much extra work load in a rush job is
counter-productive, and some managers are oblivious to that dimension.

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

Date: Fri, 26 Feb 2016 16:25:21 -0500
From: DrM <notable () mindspring com>
Subject: Re: Best Explanation for the Apple FBI Hack ... (AlMac, RISKS-29.30)

Thank you for your lengthy response. I'm not sure you read very carefully
what I wrote, though.

I did not say that this debate is in any way new. Nor did I say that there
were not plenty of crypto issues (which was NOT what I was addressing in
this piece). I am old enough to remember Clipper Chip.

I did not say that Apple workers are unlikely to work 50 hour weeks. I said
they rarely work a 50 hour week. My implication was supposed to be that they
tend to work a lot longer with the addition of some caffeine. Probably I
should have said rarely work ONLY 50 hour weeks.  I assumed that any
tech-head reading this would understand that most engineers, especially at
places like Apple work FAR LONGER than ONLY 50 hour weeks.

I did not say that Apple had the key that the FBI was looking for. Nor did I
say that there were not untruths in the original testimony and court
filings.

I was not talking about backdoor exploits.

What I was focusing on was a method involving a brute force attack that
would allow Apple to avoid writing the code (and then using it, themselves,
perhaps, on the iPhone at issue) that they claim could be problematic to
their business model.

Hope this helps your perspective on trying to decypher what I wrote.

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

Date: Sat, 27 Feb 2016 16:10:19 -0500
From: Simson Garfinkel <simsong () acm org>
Subject: Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

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

> Still, the FBI could clone the phone's memory and just use brute-force to
> make different attempts on cloned phones. It's just a 4-digit PIN, so
> there's only 10,000 different PINs to try.

Dr. Mercuri's reference for her post to RISKS appears to be the Ars Technia
article that she cited. I suggest that a better reference is Apple's iOS
security guide:
        https://www.apple.com/business/docs/iOS_Security_Guide.pdf

A few critical paragraphs are:

> "Every iOS device has a dedicated AES 256 crypto engine built into the DMA
> path between the ash storage and main system memory, making encryption
> highly efficient.

> "The device's unique ID (UID) and a device group ID (GID) are AES 256-bit
> keys fused (UID) or compiled (GID) into the application processor and
> Secure Enclave during manufacturing. No software or rmware can read them
> directly; they can see only the results of encryption or decryption
> operations performed by dedicated AES engines implemented in silicon using
> the UID or GID as a key. Additionally, the Secure Enclave's UID and GID
> can only be used by the AES engine dedicated to the Secure Enclave. The
> UIDs are unique to each device and are not recorded by Apple or any of its
> suppliers. The GIDs are common to all processors in a class of devices
> (for example, all devices using the Apple A8 processor), and are used for
> non security-critical tasks such as when delivering system software during
> installation and restore. Integrating these keys into the silicon helps
> prevent them from being tampered with or bypassed, or accessed outside the
> AES engine. The UIDs and GIDs are also not available via JTAG or other
> debugging interfaces.

The other critical paragraphs are:

> "Passcodes

> "By setting up a device passcode, the user automatically enables Data
> Protection.  iOS supports six-digit, four-digit, and arbitrary-length
> alphanumeric passcodes. In addition to unlocking the device, a passcode
> provides entropy for certain encryption keys. This means an attacker in
> possession of a device can't get access to data in specific protection
> classes without the passcode.

> "The passcode is entangled with the device's UID, so brute-force attempts
> must be performed on the device under attack. A large iteration count is
> used to make each attempt slower. The iteration count is calibrated so
> that one attempt takes approximately 80 milliseconds. This means it would
> take more than 51.5 years to try all combinations of a six-character
> alphanumeric passcode with lowercase letters and numbers.

FBI can image the phone (phone "cloning" is something else, BTW), but FBI
cannot image the secure enclave. If FBI copies the data off the phone and
tries 10 passwords, the encryption key in the secure enclave will be
wiped. This is sometimes called cryptographic erasure. It doesn't matter if
the memory is copied off the phone, it's not the memory that's being erased.
There is no way to restore something and try again.

There is a way to crack the phone, but it requires the use of exotic
technology to extract the unextractable information. Once it is extracted
the password can be cracked on a cluster. Each attempt will still take 80
msec, but many can be executed in parallel.

At the end of her post, Dr. Mercuri states:

> So the FBI v. Apple lawsuit just doesn't make any sense, unless there's
> something I'm missing in my analysis or information we just haven't received
> yet about this situation.

It is quite difficult to understand what is going on in this case from
reading press accounts. Many of them contain erroneous information. However,
I trust Apple's iOS Security guide, as it predates the current event, and it
is written by an organization that has an incentive to get the facts right.

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

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.30
************************