Weekly Edition
Return to the Security page| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model
A paper that will be presented at the USENIX Usability, Psychology and Security (UPSEC) conference takes a look at the OLPC Bitfrost security model [PDF]. "In this paper, we discuss Bitfrost, the security model developed by the One Laptop Per Child project for its XO laptop computers. Bitfrost implements a number of security measures intended primarily to deter theft and malware, but which also introduce severe threats to data security and individual privacy. We describe several of the technical provisions in Bitfrost, outline the risks they enable, and consider their legal ramifications and the psychological impact posed for children and society."
(Log in to post comments)
(Log in to post comments)
Looks like speculation
Posted Apr 9, 2008 14:01 UTC (Wed) by epa (subscriber, #39769) [Link]
The 'paper' seems to be more armchair rumination than real analysis. For example,The P IDENT policy states that “all digital peer interactions or communication (e-mails, instant messages, and so forth) can be cryptographically signed to maintain integrity even as they’re routed through potentially malicious peers on the mesh.” Since the policy does not state the conditions under which traffic will or will not be signed, and the “unobtrusive security” goal emphasizes that “strong unobtrusive security” will occur “behind the scenes” unless it impacts usability— not privacy—we must assume that all outgoing traffic will be signed by default when possible.'We must assume'... what are you talking about? The question could be answered by a little experimentation with one of the OPLC laptops that went on sale recently, or by examining the source code, or failing that, by talking to some of the OLPC developers to give them a chance to clarify facts and put right any mistakes.
We would like to thank Lindsay Patterson for assistance with research into the psychological effects of traumatic events on children,Clearly getting the maximum possible 'think of the children' effect was more important than technical fact-checking.
Looks like speculation
Posted Apr 9, 2008 14:13 UTC (Wed) by nix (subscriber, #2304) [Link]
Their complaint about openness (their first complaint, actually) was laughable. They complain that the spec isn't open because a) it's not finalized (that's because it's still changing, duh) and b) it hasn't been submitted to a 'recognized standards body'. Under that definition, Linux, Perl, Python, GNOME and KDE are not 'open', and indeed neither are most useful C compilers because the language they implement (ISO C + bugs + language extensions) has not been submitted to a 'recognized standards body'. I think we can agree that this definition of 'open' is worthless.
Looks like speculation
Posted Apr 9, 2008 14:14 UTC (Wed) by nix (subscriber, #2304) [Link]
Also, note that once specs are submitted to a recognized standards body, it's because they're *done* and hardly expected to change anymore. I've got a word for a spec like that, which you can't change. It's 'closed'.
Looks like speculation
Posted Apr 9, 2008 14:56 UTC (Wed) by rfunk (subscriber, #4054) [Link]
That's not true at all. Open standards get revised all the time. For example, the standard for Internet email, RFC 822, was later revised, with the revision becoming RFC 2822. And that's just one that hasn't changed very much. The openness of a standard is about how free people are to implement it, not about how easy it is to change.
Looks like speculation
Posted Apr 9, 2008 14:59 UTC (Wed) by rfunk (subscriber, #4054) [Link]
Er, I should also note (before someone else does), that not all RFCs are officially considered standards, and that when they are considered official Internet standards they get STD numbers that few people actually bother to remember (since they've already been busy implementing the RFC).
Looks like speculation
Posted Apr 9, 2008 16:24 UTC (Wed) by nix (subscriber, #2304) [Link]
Yeah, but you don't generally submit something as an RFC while it's still under heavy change: they go through draft processes first. Under the definition of 'open' used in this document, that wouldn't be open yet because the standards body hadn't accepted it! (And submitting something to a standards body is neither necessary nor sufficient nor anything more than indicative that people are free to implement it: notably, you can have things which people are free to implement which are not standards, perhaps because all the code is freely available. You can also have things which are standards which are in practice unimplementable in full, perhaps because they're huge and somewhat ambiguous like CORBA or C++, or because they're just too limited to be useful, like the earlier SQL standards.)
Looks like speculation
Posted Apr 11, 2008 13:36 UTC (Fri) by DanWeinreb (subscriber, #51526) [Link]
When we are talking about security, and saying that it's important for security software to be "open", what we mean by "open" in this context is that anybody should be able to see how it works. You want it to be inspected by experts. Most important, you want to avoid "security by obscurity", which experience has shown is a bad principle. So whether it is standardized by a standards body has absolutely nothing to do with the case. If a new version comes out, of course that needs to be re-examined and re-audited. And if no finalized version has come out yet, that just means that it's not time yet for final auditing, but it's a great time for the public to point out flaws and suggest improvements. Some of the papers on Bitfrost are written as if Bitfrost were completely specified, implemented, in use, and so on. If so, then someone has grounds for complaint. But they should carefully complain about just that, NOT that it's "not open".
Standard?
Posted Apr 9, 2008 18:31 UTC (Wed) by ikm (subscriber, #493) [Link]
Why would anyone submit something like BitFrost to a recognized standards body anyway? It does not look like a standard in the first place. It's just a design documentation, as far as I understand. Later in the article they pin it down as being a (de facto) standard — what is so 'standard' about it? I'd enjoy some good bashing of BitFrost, I've always disliked its trojan essence, but this one seems to be uncalled for.
a valuable study
Posted Apr 9, 2008 18:40 UTC (Wed) by nettings (subscriber, #429) [Link]
guys, hearing bad things about those cute little XOs hurts me as much as anybody, but none of your off-hand refutes can deny that the authors of this paper have a point. the weaknesses mentioned in the paper and their social implications are indeed serious. i sincerely hope they can be fixed in the open source way - by learning from and addressing the issues. whining about criticism is not part of that methodology.
a valuable study - not!
Posted Apr 9, 2008 19:25 UTC (Wed) by jhoger (guest, #33302) [Link]
The main point of the paper seems to be that BitFrost does not provide anonymity as protection from government snooping. This is a not a design goal, probably for good reason: generally schools are a government run operation, and oversight of their student charges is their responsibility. How many 9 year old revolutionaries are there in the world? If there are any I think they should reconsider communicating about their subversive plans through government supplied/controlled devices. That said, the design of bitfrost was in no way a scholarly affair. It is an engineering design/implementation that doesn't have the feel of something that has been subjected to rigorous analysis and peer review, and so it would be great to see someone do that. That said the indictment of it as not being a standard, as though it is hiding from review is a joke. Any software developer that's working in the trenches to a project schedule would know that the time to think about standardization is after the ideas have been vetted in actual prototypes and implementations. Standards come after the fact, rarely during/before. Bitfrost is a new thing. This paper is not the analysis anyone is looking for, far from it. It is just a bunch of pseudo-intellectual tangential assertions that wouldn't survive peer review. Anyone that uses it in their list of references (unless they are writing a critical paper on writing critical papers) is doing themselves a disservice. -- John.
Re: peer review
Posted Apr 10, 2008 0:06 UTC (Thu) by krstic (guest, #41011) [Link]
The original Bitfrost spec was scrutinized intensely at a full-day summit by a handful of top security luminaries from industry and academia, after they had time to familiarize themselves with the document. I'll post their names on the blague within a few days. I also wrote a paper about it, which was accepted (and very well judged) at the ACM SOUPS symposium at Carnegie Mellon, the premier academic HCI-sec event out there.Cheers,
Ivan.
Re: peer review
Posted Apr 10, 2008 5:58 UTC (Thu) by AaronSw (guest, #51504) [Link]
You're kind of dodging the main point, Ivan. The argument of the paper is not that the Bitfrost proposal is a bad one, just that there's a blind spot in its threat model. To be fair, I had the same blind spot when I read the proposal and I wouldn't be surprised if those other security luminaries did as well.
So the question is: Do you agree that kids should be protected from officials trying to interfere with their computer use? Do you think the current Bitfrost spec does enough on this front?
Re: peer review
Posted Apr 10, 2008 12:00 UTC (Thu) by krstic (guest, #41011) [Link]
You're not paying attention to which comment I'm replying. I was addressing one particular
aspect of jhoger's message ("no peer review") because it's factually inaccurate and thus
easily debunked. As for the Patterson paper, I'll be posting my thoughts over the next few
days, but generally find it uninteresting and academically sloppy flamebait.
Re: peer review
Posted Apr 14, 2008 12:55 UTC (Mon) by brinkmd (subscriber, #45122) [Link]
That only makes it worse, because this means the paper exposes a systematic bias in the security community, especially those parts working on "Trusted Computing" and other systems where the hardware is controlled by a party different from the user.