Risks Digest 29.29

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

RISKS-LIST: Risks-Forum Digest  Friday 26 February 2016  Volume 29 : Issue 29

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

  Contents:
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)
Abridged info on RISKS (comp.risks)

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

Date: Fri, 26 Feb 2016
From: Rebecca Mercuri  <mercuri () acm org>
Subject: Best Explanation for the Apple FBI Hack I've Seen and What It Means

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:
http://arstechnica.com/apple/2016/02/encryption-isnt-at-stake-the-fbi-knows-apple-already-has-the-desired-key/

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
hours.
https://www.documentcloud.org/documents/2722196-Motion-to-Vacate-Brief-and-Supporting-Declarations.html#document/p22/a279957
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.
https://www.rcfl.gov/downloads/documents/cpik-brochure 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.
http://www.cellebrite.com/Pages/ios-forensics-physical-extraction-decoding-and-analysis-from-ios-devices

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.
www.notablesoftware.com

Copyright (C) 2016 by Rebecca Mercuri   All Rights Reserved

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

Date: Thu, 25 Feb 2016 17:35:21 -0600
From: Dimitri Maziuk <dmaziuk () bmrb wisc edu>
Subject: Re: key escrow (Taylor, RISKS-29.28)

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.

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

Date: Fri, 26 Feb 2016 00:31:58 -0500 (EST)
From: Jeff Jonas <jeffj () panix com>
Subject: Re: Robots Are Reading Trader Chats to Stop Next Wave of Bank Fines
  (Goldberg, RISKS-29.28)

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?
  https://en.wikipedia.org/wiki/The_Victorian_Internet

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
https://en.wikipedia.org/wiki/Commercial_code_%28communications%29 "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
commodities)

Prisons are full of failed codes and obfuscation (as well as well known
codes):
http://www.writeaprisoner.com/vbforum/general-prison-talk/46059-general-us-prison-slang.html

Consider these failed attempts:

1)
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

2)
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:

http://arstechnica.com/tech-policy/2011/05/how-the-robber-barons-hijacked-the-victorian-internet/
How Robber Barons hijacked the "Victorian Internet"
Ars revisits those wild and crazy days when Jay Gould ruled the telegraph
and ...

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

Date: Fri, 26 Feb 2016 14:06:41 +0000
From: David Damerell <damerell () chiark greenend org uk>
Subject: Re: Hacked mid-air while writing an Apple-FBI story
  (Petrow, RISKS-29.28)

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".

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

Date: Fri, 26 Feb 2016 10:22:45 EST
From: bob () dtcc edu (Bob Rahe)
Subject: Re: Trimble date problem (Wagner, RISKS-29.28)

I had similar problems back in 2001 with a TruTime NTS-100.  There's a
discussion of it and the solution here:

https://groups.google.com/forum/#!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
dates.

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

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

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