The RISKS Digest
Volume 29 Issue 33

Wednesday, 9th March 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…


Last week's House Judiciary hearings
Susan Landau
Speech by Robert Hannigan, Director GCHQ, delivered at MIT
Encryption: Selected Legal Issues
Thompson II/Jaikaran
Apple vs. FBI primer on info extraction
FBI quietly changes its privacy rules for accessing NSA data on Americans
Spencer Ackerman
France: prison sentences for noncompliant tech execs?
Re: France to Jail Tech Execs over Encryption
Mark Brader
Hacking industrial vehicles from the Internet
Risks to our industry re: CVE
Kurt Seifried
Multiple iOS apps found to be harvesting Snapchat user credentials
geoff goodfellow
Mac 'Ransomware' Attack Exposes Vulnerability of Apple Users
Florida Senate endorses making computer coding a foreign language
Kristen Clark
Apple loses e-books USSC appeal
Apple iOS Has PINs; But has not adopted Duress Codes
Bob Gezelter
Re: Apple vs FBI
Peter Houppermans
Info on RISKS (comp.risks)

Last week's House Judiciary hearings

Susan Landau <>
Wed, 9 Mar 2016 06:20:56 -0800
The House Judiciary Committee held hearings on encryption last week. FBI
Director James Comey spoke on the first panel, Apple General Counsel Bruce
Sewell, Manhattan District Attorney Cyrus Vance, and I were on the second
one.  I took a technical viewpoint on the Apple case and on security more
generally; my written testimony is at:

Some of the ideas (e.g., security risks of Apple developing the requested
software) will be familiar to RISKS readers, but other aspects will probably
be new (this includes discussion of phones as authenticators and how the FBI
might respond to the issue of encrypted and secure communications and

And for anyone who is really into it, there's also video of the full five
hours of testimony:

Speech by Robert Hannigan, Director GCHQ, delivered at MIT

Lauren Weinstein <>
Tue, 8 Mar 2016 10:26:53 -0800
Transcript of speech by Robert Hannigan, Director GCHQ, as delivered at the
Massachusetts Institute of Technology

  [This is worth reading.  PGN]

Encryption: Selected Legal Issues (Congressional Research Service)

"Peter G. Neumann" <>
Tue, 8 Mar 2016 15:53:37 PST
This is a very nice summary analysis by Richard M. Thompson II and
Chris Jaikaran, dated 3 Mar 2016, on the current situation.

Apple vs. FBI primer on info extraction (Muckrock)

"Alister Wm Macintyre \(Wow\)" <>
Wed, 9 Mar 2016 14:54:00 -0600
Muckrock has published a Primer, and advice, on doing Apple vs. FBI Freedom
of Information Act (FOIA) document requests, to help better understand the
FBI, Apple, and the fight over keeping devices secure while allegedly
maintaining national security.

* Classified info, and how to seek out what we can find out.

* Law Enforcement Practices, and using court precedents to find out more

* While NSA 3605 is broad, they've got around that in almost 50 cases.

* Links to legally accessing other US gov agencies with secrets from
  uninformed FOIA requests, like FBI practices.

For example, you can see how many iPhones and other Apple products the NSA
has bought.

Muckrock is a collaborative news site
helping people find out about the US federal state and local government via
FOIA requests.  Getting answers to FOIA requests probably take longer than
it takes for the final court ruling on this battle.

Here are some other recent Muckrock news updates:

[Currently the Muckrock website looks nicer, cleaner, and more readable in
Chrome than it does via IE.]   [Chromatic, not IEtrogenic?  PGN]

FBI quietly changes its privacy rules for accessing NSA data on Americans (Spencer Ackerman)

"Dave Farber" <>
Tue, 8 Mar 2016 13:46:01 -0500
Spencer Ackerman, *The Guardian*, 8 Mar 2016

France: prison sentences for noncompliant tech execs?

Lauren Weinstein <>
Tue, 8 Mar 2016 09:04:18 -0800
France's lower house of Parliament has approved a measure aiming to give
prison sentences to technology company executives who refuse to give data to
investigators in terrorism-related cases

  The bill, adopted Tuesday by 474 votes to 32 in the National Assembly,
  will now have to be debated by the Senate.  One measure would punish
  executives in companies like Apple and Google with a fine of up to 350,000
  euros ($386,000) and a five-year prison sentence if they deny prosecutors
  access to a suspect's encrypted data.

Re: France to Jail Tech Execs over Encryption (RISKS-29.32)

Mark Brader
Tue, 8 Mar 2016 01:48:54 -0500 (EST)
That's not what *The Register* headline or what the article says!

  [See previous item! PGN]

Hacking industrial vehicles from the Internet

Lauren Weinstein <>
Wed, 9 Mar 2016 09:45:12 -0800

  It is possible to monitor and control float trucks, public bus or delivery
  vans from the Internet, obtaining their speed, position, and a lot other
  parameters. You can even control some parameters of the vehicle or hack
  into the CANbus of the vehicle remotely.  Those vehicles have a Telematics
  Gateway Unit (TGU) device and a 3g/4g/gprs/lte/edge/HDSPA modem to connect
  to the Internet, with a public I.P. address.  There are thousands of TGU
  connected to the Internet, with no authentication at all and with
  administrative interfaces through a web panel or a telnet session.

Imagine the fun hackers will have with self-driving vehicles.

  [The CANbus on can(ni)bus—with a u for an i instead of an i for an i?

Risks to our industry re: CVE

Kurt Seifried <>
Mon, 7 Mar 2016 19:04:33 -0700
TL;DR: Mitre controls CVE. Mitre is not giving out CVE assignments. Many
people are giving up, and in some cases not even bothering to disclose
research. The risks are obvious, discussing vulns without CVE's is annoying
and error prone, and people giving up and not releasing research is
obviously even worse.

CVE is too important to our industry to allow it to fail.

Multiple iOS apps found to be harvesting Snapchat user credentials

geoff goodfellow <>
Tue, 8 Mar 2016 13:54:31 -1000

Mac 'Ransomware' Attack Exposes Vulnerability of Apple Users

Monty Solomon <>
Tue, 8 Mar 2016 01:39:00 -0500
The infected software affected a relatively small number of people over the
weekend, but it pierces an image of safety long enjoyed by fans of the

Florida Senate endorses making computer coding a foreign language (Kristen Clark)

Lauren Weinstein <>
Tue, 8 Mar 2016 13:47:04 -0800
Kristen Clark (*Miami Herald*), in *Bellingham Herald*, via NNSquad

  State senators in Florida overwhelmingly approved a proposal Wednesday to
  allow high school students to count computer coding as a foreign language
  course, although questions linger about whether the two subjects should be
  considered one and the same.  The state Senate passed the bill by
  Democratic Sen. Jeremy Ring on a 35-5 vote.

What morons. Promoting computer skills is great—equating them to foreign
language skills is the kind of crap that only idiot politicians could come
up with.

Florida Senate endorses making computer coding a foreign language

"Peter G. Neumann" <>
Tue, 8 Mar 2016 14:48:38 PST
This may seem to be ridiculous or brilliant, or both at the same time.  In
that the *art of coding* is not a language, there is a type mismatch in the
subject line (coding per se vs code).  This might result in a confusion
between just studying a computer programming or specification language, as
opposed to actually knowing how to use it—e.g., software engineering.
But that may be too subtle for the Legislators.

Although there are syntactic, semantic, and grammatical similarities between
programming languages and natural languages, there are also significant

 * Natural languages are typically riddled with AMBIGUITIES and PROFANITIES.
   They are frequently misused and often misunderstood.  They are
   continually evolving based on common usage and long-established dialects.
   They are not created initially by experts (e.g., linguists)—except for
   Esperanto.  (Puns are plentiful.)

 * Programming languages are supposed to be UNAMBIGUOUS, but often
   nonintuitive and prone to bad programming practice and bugs.  They are
   created by individuals or committees, and hopefully standardized to avoid
   radical differences among different compilers running on different
   hardware.  (Puns are typically rare, confusing, easily ignored, or
   totally out of place.)

At least the Florida Senate did not think that study of computer languages
would be on a par with studying English (which may seem like a foreign
language to some native speakers of the language.  However, it might be
interesting to hear legislators' arguments relating to which functional and
declarative languages are in scope for credit.  Pascal might be favored
instead of French, and Euclid as a substitute for studying Greek.  Ada would
certainly have a following among literature students of English (Lovelace)
and Russian translations (Nabokov), as would Oberon (Shakespeare).
Astronomy students might prefer Algol.  LISP might be considered non-PC.  In
any case, parents will be required to sign a waiver acknowledging that
out-of-state or private colleges might not honor the credits as a foreign

Natarajan Shankar responded to me: “In what might be the first of the
flurry of emails, here's an interesting article on this topic:''

Apple loses e-books USSC appeal

"Alister Wm Macintyre \(Wow\)" <>
Mon, 7 Mar 2016 18:24:12 -0600
The U.S. Supreme Court rejected an appeal from Apple, and left intact a
ruling, that the company conspired with publishers to raise the prices of
electronic books.  Apple will have to pay out $ 400 millions to 23 million
consumers who overpaid, and $ 50 millions to reimburse court costs of the
people fighting Apple.

Apple iOS Has PINs; But has not adopted Duress Codes

"Bob Gezelter" <>
Mon, 07 Mar 2016 17:27:47 -0700
In the current brouhaha over access to a PIN-protected iPhone, I find it
personally surprising that Apple has not gone the extra step of increasing
security by providing a common feature on burglar alarms: a "Duress" code.

Simply put, many alarm systems have two codes, a password indicating a valid
access, and a duress code which indicates that the person attempting access
is under duress of some sort (e.g., is in a threatening situation).

In the case of iOS, such a feature would allow a person to "cooperate" while
safeguarding the contained information. Enter the duress code, and the
device could activate the time lockout feature or alternatively, wipe the
encryption keys, rendering the information inaccessible.

This is hardly a novel concept. As I have mentioned, duress codes (negative
authentication codes, if you will) have a long history in communications and
alarm systems. As an example, many communications systems used by field
operatives have a feature of added data to confirm authentication. Send the
wrong authenticator, and the recipient is instantly aware that the operative
has been compromised. The UK SOE used such features, as did other similar

Similarly, bank alarms have been described as having such features (see
Haley's novel "Moneychangers has a reference, as I recall).

Bob Gezelter,

Re: Apple vs FBI (Medcalf, RISKS-29.32)

Peter Houppermans <>
Tue, 8 Mar 2016 08:20:15 +0100
> This whole line of reasoning is so wrong on so many fronts.

Glad you approve :).

> The reason that the FBI is requesting Apple to "break into" the iPhone in
  question is because Apple has ALREADY CREATED the backdoor into the device
  that permits them to do this.

Actually, no.  The crux of this whole case is exactly that such a backdoor
or tools to establish one do not exist and thus need to be created (assuming
this is possible, because that is an as yet unaddressed variable - there
have been some suggestions as to methodology but that does not guarantee
success).  In effect, Apple is asked to undo the very security it spent
years achieving.

> If Apple had not done so, there would be no way for Apple to comply no
  matter what tantrums anyone decided to throw.

Maybe it's worth reading the original order, all the fun details are in
there.  It's also a good idea to verify the facts your reasoning depends on,
as there is a strong suggestion that you have never been near an iPhone and
the way it makes backups.  Computers have to authenticate to the iPhone
before they gain required access to make a device backup.  The days that you
could just jack in any computer and copy the data are long gone.

> Just as Apple has created backdoor access for themselves to turn over
  backups and so forth stored in iCloud (the definition of "Cloud" being, of
  course, Third Party operated computer system over which the data owner has
  no control or influence over the security of what is stored there).

iCloud <> hardware encoded security.  Maybe it's an idea for you to review
how Trusted Computing works because we are in essence dealing with the same
idea of a TPM baked into the chipset, which prevents the data from being
accessible once lifted out of the device as it is salted with whatever is
hiding in the chipset.  It's not exactly a *new* idea, the challenge is to
make it actually work, and being in control of your own hardware rather
helps.  For the iCloud they just had to do a password reset.

Please report problems with the web pages to the maintainer