The RISKS Digest
Volume 29 Issue 30

Monday, 29th February 2016

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


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
Re: Best Explanation for the Apple FBI Hack ...
Taed Wynnell
Ted Lee
Al Mac
Simson Garfinkel
Info on RISKS (comp.risks)

Risks of Leap Years and Dumb Digital Watches

Mark Brader
Mon, 29 Feb 2016 13:25:18 -0500 (EST)
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;


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

A 12-year-old girl is facing criminal charges for using certain emoji. She's not alone.

Gabe Goldberg <>
Sun, 28 Feb 2016 12:35:38 -0500
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

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.

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

"Google Wants Less Reliable Hard Disks"

"ACM TechNews" <>
Fri, 26 Feb 2016 13:01:15 -0500 (EST)
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.

Asus lawsuit puts entire industry on notice over shoddy router security

Gabe Goldberg <>
Sat, 27 Feb 2016 20:00:45 -0500

The FBI wants a backdoor only it can use, but wanting it doesn't make it possible (The Guardian)

Gabe Goldberg <>
Sat, 27 Feb 2016 19:08:32 -0500
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.

It Really Doesn't Matter What Apple's Motivations Are—Idealistic or Other Wise

Monty Solomon <>
Sat, 27 Feb 2016 10:48:38 -0500

Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

Taed Wynnell <>
Fri, 26 Feb 2016 19:12:54 +0000
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.

Re: Best Explanation for the Apple FBI Hack ... (Wynnell, R-29.30)

DrM <>
Fri, 26 Feb 2016 15:12:38 -0500
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.

Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

Ted Lee <>
Fri, 26 Feb 2016 13:55:50 -0600
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.

Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

"Alister Wm Macintyre \(Wow\)" <>
Fri, 26 Feb 2016 14:39:13 -0600
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

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's 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

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.

Re: Best Explanation for the Apple FBI Hack ... (AlMac, RISKS-29.30)

DrM <>
Fri, 26 Feb 2016 16:25:21 -0500
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

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.

Re: Best Explanation for the Apple FBI Hack ... (Mercuri, R-29.29)

Simson Garfinkel <>
Sat, 27 Feb 2016 16:10:19 -0500
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:

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.

Please report problems with the web pages to the maintainer