"Chilling Effects" paper at USENIX UPSEC

[John Gilmore]

>    4.  It is unfortunate that a respected conference did not do a
> better job at vetting this paper.

The conference is a small USENIX workshop (Usability, Psychology and
Security).  USENIX workshops generally involve fewer than 100
participants, more timely work, and less pre-publication peer review.
BitFrost (and criticism of the design, the spec, and the
implementation of BitFrost) are directly on-point for this workshop.
The paper appears in a "short papers" session, along with papers on
RFID and authentication via electronic pets.

>    1.  The BitFrost Specification is documentation, not detailed
> implementation.  The author does not read code.

Indeed, the paper would've been better if they had also been able to
review the implementation, but based on the paper deadline and what
they had available (a prototype XO from B3 or earlier), most of
BitFrost was not implemented in what they had access to.

>    2.  BitFrost does not promise anonymity to school children.

This is a valid criticism of a social scheme such as "give one laptop
to every child", and as pointed out by the authors, a scheme being
rolled out in some very violent, repressive countries like Nigeria.

> It would have been nice if the criticisms had been delivered directly to 
> OLPC, instead of broadcast in a public forum, ...

Almost every OLPC forum, including olpc-security, is a public forum.
If the enemies of OLPC aren't reading its open mailing lists, they
aren't very competent enemies.  It's actually more likely that they
would notice OLPC criticisms in OLPC forums, rather than at a small
USENIX workshop.  Indeed, it's the discussion of the paper here that
has probably "tipped off" OLPC's enemies.  Shh!!!

> I believe that the prevailing ethos in the white hat security community 
> is to report newly-discovered vulnerabilities first to the company in 
> question, thus giving them some amount of time to develop a patch before 
> the public announcement.

The authors didn't identify any buffer overflows or similar issues.
The things they identified were wrong at the fundamental design level,
and are not trivially patchable.

Luckily, some of them were "design goals" that never got implemented,
like signing everything with the child's private key.  Thus, many of
the BitFrost mistakes which they point out, are not actual problems in
the current shipping XO.

> The authors appear to be academics, however, so they would get little 
> credit for having contributed to OLPC security by privately contacting 
> OLPC and giving us an opportunity to address their concerns.

Ahem.

I have given generously of my time to OLPC by following the project
for some three years now; testing B1, B2, B4, and MP machines;
supporting G1G1 users; recruiting and paying others to contribute;
researching SD card protocols; contributing to discussions by email,
phone, and IM; and filing dozens of bug reports.  OLPC has seldom
graciously "addressed my concerns" on fundamental design issues, such
as BitFrost, activation, developer keys, GPL compliance, game keys, or
anything else.  When I wasn't ignored, I was criticized for attacking
OLPC, or for failing to write up my concerns as a properly tested
source code patch.  It has been hard -- indeed, impossible -- for me
to gin up the requisite perseverence to actually implement anything
for OLPC, except small patches to SimCity.  (Making those patches
turned up numerous bugs, which I reported, which are still largely
being ignored.)

The BitFrost spec was so clearly a personal hobbyhorse of Ivan that
questioning its basic assumptions was heresy, grudgingly tolerated due
to my reputation, but otherwise ignored.  I decided very early on that
it wasn't worth wasting my time and making people mad by criticizing
BitFrost in detail, partly because I expected it to fall flat on its
face.  The parts that were worth focusing on were the pervasive DRM
(maybe now that Ivan's gone, I can go back to using the right name for
"crypto that disables the owner's control").  And I was ignored and
vilified on *that* until I escalated the DRM issue to Richard Stallman
over OLPC's ongoing non-compliance with GPLv3 (and also pointed out
non-compliance with GPLv2, which is ongoing).

OLPC staff are overworked and underappreciated.  Working in the glare
of publicity has not made their jobs easier.  But giving OLPC an
opportunity to address your concerns is pretty much a null concept.
OLPC barely has the opportunity to address its own opportunities.

	John