The Risks Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 29: Issue 29

Friday 26 February 2016


Best Explanation for the Apple FBI Hack I've Seen and What It Means
Rebecca Mercuri
Re: key escrow
Dimitri Maziuk
Re: Robots Are Reading Trader Chats to Stop Next Wave of Bank Fines
Jeff Jonas
Re: Hacked mid-air while writing an Apple-FBI story
David Damerell
Re: Trimble date problem
Bob Rahe
Info on RISKS (comp.risks)

Best Explanation for the Apple FBI Hack I've Seen and What It Means

Rebecca Mercuri <>
Fri, 26 Feb 2016
It's Apple's shareholder meeting day today, so a good time to ponder the FBI
iPhone hacking controversy.

Here's the best article I've found so far on this topic:

Most of the news articles and TV coverage I've seen about the hack that the
FBI wants to force Apple to create, don't fully explain why it's needed. A
few of the stories mention the "10-times you're out" problem, where the
phone data is deleted automatically after 10 incorrect password
attempts. 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. This means that they'd
only have to make the clone 1000 times, though there's a 50% chance the PIN
will be in the 1st half of the numbers attempted, so on average only 500
attempts will be needed. Sure, making 1000 phone memory clones and testing
them is time-consuming, but it certainly can't take longer than the time to
sue Apple all the way to the Supreme Court.

Apple has estimated that it was going to take 6-10 engineers 2-4 weeks to
write and debug the code—assuming 50 hours a week, that's 600 to 2000
On the other hand, the FBI estimates that the time it takes to extract data
from a cell phone as 15 minutes. Allowing for 15 minutes of set-up time, and
another 15 minutes to upload the memory into a cloned iPhone, you're looking
at 45,000 minutes or 750 hours, pretty close to Apple's lower bound on their
time estimate. Maybe Apple has already figured this out and isn't really
planning on writing any software? They could just make clones and
brute-force the PINs.

It turns out that it'll take longer than a few minutes to make the 10
attempts. The news pieces haven't been mentioning a further issue about the
delays, but the Ars Technica piece I cited above reveals this: "While the
first four attempts can be entered back-to-back, the iPhone will force you
to wait one minute before the fifth attempt, five minutes before the sixth,
15 minutes before the seventh and eighth, and a full hour before the ninth."
Adding in a minute for the 1st 4 tries (actually they take 80ms each),
that's 97 minutes, or a little over an hour and a half for the 10 tries. So,
if we add in another 97 minutes per phone, that's around 2367 hours for the
1000 clones with 10 time-delayed tries each, a bit over Apple's upper bound
time estimate. Apple knows their engineers rarely work a 50-hour week, so if
they supply them with some Jolt cola or powershot drinks, they can still
probably get it done in a month, or half that if they get lucky with the
brute force guesses.

Thing is, the FBI already has the equipment to perform physical extraction
of iPhone memory at their Cell Phone Investigative Kiosks available for law
enforcement use at 80 locations around the country. The most popular
extraction tool (and the one they are likely using) is Cellebrite's UFED
Physical Analyzer, which supports the full range of iPhones, including
locked iOS devices with simple or complex passcodes.

There has to be a bunch of hackers the Government has arrested in the last
year that they can ply with dropped charges who can show them how to
reinstall cloned memory contents into an iPhone 5C. Or they could just offer
to pay Cellebrite to figure out how to do this. And once they know how to
clone the memories, they can deploy 6-10 agents from the child porn detail
for 2-4 weeks and pay them some overtime to create the clones and run the
brute force attacks.

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.

Rebecca Mercuri, Ph.D.
Digital Forensics Expert
Notable Software, Inc.

Copyright (C) 2016 by Rebecca Mercuri   All Rights Reserved

Re: key escrow (Taylor, RISKS-29.28)

Dimitri Maziuk <>
Thu, 25 Feb 2016 17:35:21 -0600
Legal and societal hurdles aside, key fragments might look like a few
electrons in "the cloud" but in reality storing them requires very tangible
physical hardware with electricity bills, backups, cooling, replacement
drives, and so on and so forth. Even if this is somehow funded, there's
still catch-22: you can either stay Anonymous or apply for the funds to run
your key storage operation.

Re: Robots Are Reading Trader Chats to Stop Next Wave of Bank Fines (Goldberg, RISKS-29.28)

Jeff Jonas <>
Fri, 26 Feb 2016 00:31:58 -0500 (EST)
The book "The Victorian Internet" recounts how criminals were quick to
exploit the telegraph for insider trading.  For example: the telegraph
outran horse race results via official channels, so it was illegal to send
race results.  Criminals resorted to coded messages, which telegraphers
refused to send (when recognized).  History repeats itself with this new
attempt at supervision?

Telegrams charged by the word, so businesses economized by using
abbreviations.  Some of those codes were almost Huffman encoding (remarkably
similar to today's text abbreviations - LOL?)  so only real words were
allowed by the telegraph companies.  That resulted in Commercial
codebooks. Citing Wikipedia "Another
aim of the telegraph codes was to reduce the risk of misunderstanding by
avoiding having similar words mean similar things.  Codes were usually
designed to avoid error by using words which could not be easily confused by
telegraph operators."  The modern concepts of error detection and
compression were already addressed!

I wonder if the "Central Scrutinizer" is seeded with those codebooks.  It's
not far fetched to substitute modern instruments for obsolete commodities.
("Big Brother" is to George Orwell's novel "1984" as the "Central
Scrutinizer" is to Frank Zappa's 1979 rock opera "Joe's Garage")

Creative texting might use unicode for Klingon or Linear-b (the recently
cracked script of receipts and book-keeping: ideograms for objects or

Prisons are full of failed codes and obfuscation (as well as well known

Consider these failed attempts:

Does he have the shirts?
Yes, he has the shirts.
Are they good shirts?
Yes, they're really good shirts.
Fine, I'll take 2 1/2 shirts

Do you have the stuff?
Yea, I got the stuff.
This time, don't forget the bullets for the stuff!

A curious tangent: net neutrality, censorship and astro-turfing/hijacking
social media is over 100 years old:
How Robber Barons hijacked the "Victorian Internet"
Ars revisits those wild and crazy days when Jay Gould ruled the telegraph
and ...

Re: Hacked mid-air while writing an Apple-FBI story (Petrow, RISKS-29.28)

David Damerell <>
Fri, 26 Feb 2016 14:06:41 +0000
The meat of this story seems a little contrived to me:

> “I hacked your email on the plane and read everything you sent and
> received. I did it to most people on the flight.''  He had verbatim detail
> of a long email that he repeated back to me essentially word for word.

If I had just committed a crime, especially one which sometimes receives
truly draconian penalties, I'd be quite cautious about telling one of the
victims about it. Furthermore, while I have not flown for some years, my
understanding from RISKS suggests one might be especially careful about
doing so in an airport, where the authorities seem to engage in some quite
indiscriminate excesses.

It transpires that the alleged hacker was "in the row behind me". I wonder
if perhaps they employed the Mk I Eyeball to read this reporter's email,
something that would be easy to do and also wouldn't risk being
shoulder-surfed in turn by other passengers?

I suspect what we have here is a case of "reporter hears unlikely story but
writes it down anyway".

Re: Trimble date problem (Wagner, RISKS-29.28)

Bob Rahe
Fri, 26 Feb 2016 10:22:45 EST
I had similar problems back in 2001 with a TruTime NTS-100.  There's a
discussion of it and the solution here:!topic/comp.protocols.time.ntp/DAhxHPXPqXs

So when it started again this month, with the same (ancient) NTS-100 I tried
to find any info on the problem since I had long ago forgotten anything
about it.  Turns out that the thread above has the clue to the solution.
For the NTS-100 it is to set the 'YEAR' parameter (F68) to 2015. In the
original fix it was to set it to 1996.  And... it has to be some sort of
parameter setting for the fix since there is no real possibility of updating
the 16+ year old device.

The reasoning behind the fix seems to have to do with some issues with
relative weeks and what date/year the system has last synced with etc. etc.
But... it fixes the problem and the NTS-100 is back to replying with correct

Bob Rahe, LMIEEE, (RWR50), Delaware Technical & Community College
Computer Center, Dover, Delaware

Report problems with the web pages to the maintainer