[OLPC Security] "Correlating bitfrost and threats"

[MBurns]

Hi Jameson,

You raise some good points. As best I could I tried to go
point-for-point with you, to not miss any of your questions. As
always, if I am unclear (or mistaken, or dead wrong) I look forward to
your reply.

To keep things in perspective: I am an intern for OLPC. I am one of
three (Michael Stone and Noah Kantrowitz, who have done the vast
amount of "work") who are implementing parts of the Bitfrost spec.
This isn't just a "my opinions are not that of my employer" preface,
but rather a "I don't have all the answers, but I will help find them
if I know someone who does".

On 7/30/07, Jameson Chema Quinn <jquinn at cs.oberlin.edu> wrote:
> Sorry if I have the wrong jargon. I mean file sharing, not activity sharing.

No jargon, just misunderstood you.

Yes, file sharing will be supported. How it is supported is not
entirely clear, as it is not yet implemented (welcome to OLPC-land).
Assuming this shareable feature is supported, lets get back to your
concerns:

> > >  Are documents that are explicitly world-shared stored unencrypted?

If you are "explicitly" saying that the world can read a file, why not
leave them unencrypted?

> > >  How about narrower shares - there could be a complicated system of group keys and session keys, though the benefit is limited.

Group Chat (yes, this is activity sharing, but it is using Tubes, just
like local file sharing will) will be able to manage session key
output. The same mechanism will be used for trading of files amongst
trusted friends.

> And don't tell me there will be no such thing - how does a student hand in a paper and then receive the comments back? Not all collaboration is real-time.

You are quite right, it is not. In the homework turn-in case I suspect
the student would encrypt the file in question with the teacher's
public key and offer it to download. How the UI presents this is
another discussion ('pressing a Turn In Homework' key of some sort?).

> As I state in the talk page of the wikipage that started this thread, I could give 4 pieces of key to other random laptops from the same batch, of which any 2 pieces were sufficient. I could also choose to give duplicates of those 4 pieces to up to four friends, but no laptop would accept more than 8 keypieces, all for separate keys, for storage.

So you supplant 1 server having your private key with 2 pairs of your
peers having your private key. How is this reliable? As *their* copy
of half your key must also be backed up.

You could surely create a cloud of partial-keys distributed over your
classmates. But trusting your peer over your teacher isn't necessarily
a good thing. Indeed, you are putting a great ammount of trust in
either (whether it be the entire key on the SS or half your key to one
of 2 or 4 peers). If you are that concerned, you need to set a
password or generate your own private key, and make backup of that
token independent of other people.

> No central record would record who has whose key. When I had to restore, there would be a broadcast message to the whole batch: "Somebody wants so-and-so's key." This would be a low-priority but visible event to all users. The 4 laptops which had my key would allow their users to either approve or disapprove, and also tell the server who they were (so that I could track them down).

This system requires that your adolescent peers are not susceptible to
social engineering. Something that is not true of even moderate and
expert computer users, let alone novice ones.

It is an interesting idea, but terribly more complicated. Requiring
more people to out-of-band confirm that this person standing in front
of them is the same as the one who I talked with N months ago (and
indeed, regularly in between). A proof-of-concept would be a welcome
side project. Shifting the responsibility around does not
fundamentally change the problem, though.

> Obviously, a committed big-brother could still twist two kids' arms and convince the rest to ignore the message. But that doesn't scale well to stealing EVERYONE's data and mining it, which is the real threat.

But they wouldn't need to get everyone. The handful of kids they
choose to strong arm (or coerce or 'borrow' the laptops of, or analyze
while repairing, or, or, or...) would be--using your system--carrying
1/2 of another person's key. Several halves, in fact. Get a large
enough sample, then you are getting the private keys of children that
they didn't directly interact with. Would this be easy for a million
kids at once? Probably not. But at that point, you are also assuming a
great number of things about your government, like that they didn't
install keyloggers on the XOs before shipping them out or during
repair.

The point is *nothing* is completely secure. Ours is by far (in
design) the most secure widely-deployed system that I know of. But it
is *not* a perfect solution.

> And what, the server just deletes the key at that moment? And then re-encrypts all the backed-up files and deletes the old copy? Hmmm...

:)

Yes, if you use even a potentially tainted private key, you can't
strictly trust the data it was encrypted by. Couple options on how a
migration might work off the top of my head:

1. Assuming you are trusting the school server, you would also have it
back up your priv key, so migrating your files from the old to the new
(or indeed, granting your unique XO access to the backed-up private
key under a socially-controlled process) would just be common sense.
All future files would be encrypted by your XO and shoveled up stream.

2. If you don't trust the server (and lost your old private key) I
imagine you would have to do a bit of swapping. Get a new key (or be
re-granted access to your old key), download all data to a local
SD/USB key or similar. Generate a *new* key personally. Re-encrypt all
data with that key to which only you have access. Toss old private
keys. Use the backup system with your new key but backup your private
key by out-of-band means (copy go , secure in the fact that you are a
paranoid nerd. This way the SS, your government and your peers never
get to see your private key.

> If you want security for your key, you need to have it from day 1, you can't patch it back up later.

Absolutely. Neither of our systems fixes this, though. We either trust
our school or we trust 2 brand new computer users to trust your
private key with the weight and brevity that owner feel it deserves.

> I'm not talking about backup, I mean restore. What good is a backup to me if it will take me two weeks of dropped connections to get it back?

The magic of the datastore is that you *don't* keep your entire
history of documents (a collective bundle of which might indeed take
days to download) locally. Instead, just download the last week's
worth of touched documents, along with a complete metadata log (no
more than a few megs, at a guess). When you want to reach back into
time, you will be able to transparently reach out to the school server
or the global backup server to retrieve it.

> Or are you imagining the case where a school server is stomped? Since the ratio is 1 server per 100 laptops, most locales will have two servers, and network considerations mean that you want these physically separated anyway. Even if not, I'd rather have my secondary backup be peer-to-peer with my nearest neighbor, not in the Google Dimension.

Fair enough. But when an XO has maybe 900 meg of usable space (we are
shooting for a <100MB system footprint), and most of it is used by the
owner's documents, having a distributed backup system becomes less
efficient than a centralized one.

Even if you want to keep only your absolute latest documents backed up
(100 meg, 50, 10?) then you still have to worry about the other 800+
meg of 'older' documents to be backed up somewhere.

A distributed backup model fundamentally needs to have a user sharing
significantly more 'cache' space (on the order of 10:1 at worst, 3:1
in ideal circumstances) than they are relying on the network to
backup, otherwise you run out of room. Consider the case of laptops
being 'asleep', not being able to serve up your cached data, not being
on the network at all or machines being out of battery, etc.

> I'm personally less worried about data continuity after large natural disaster than I am about big brother.

Fair point. But at that point, you are beyond the default scope of
average users. Children who are concerned will be able to do this
(similar to getting a developer key), and be sure they are absolutely
not being spied on.


-- 
Michael Burns * Intern
 One Laptop Per Child