[OLPC Security] "Correlating bitfrost and threats"

Jameson "Chema" Quinn jquinn at cs.oberlin.edu
Thu Aug 2 20:20:58 EDT 2007


I think we've come to agreement:

1. A secret-sharing scheme, which would include both (random, unknown?) 
peers and teachers, would be a useful additional level of security.
2. It is too complicated for version 1.

So here are the action items, as I see them:

1. Ensure that data stored on the primary backup server is encrypted. An 
exception could be made for files where on-laptop encryption is a 
significant processor drain; this will still encrypt all text, which is 
the greatest risk for large-scale attacks anyway.
rationale: while this does not actually protect it in version one, as 
the decryption key is sitting right there, it allows a much simpler 
update to version 2. As long as this update is performed honestly 
(throwing away the keys instead of keeping a copy), it gives security 
against later compromises of the server data.
Note that the bitfrost spec currently implies that this will NOT be the 
case - if it is already planned, the action item reduces to "rewrite the 
bitfrost spec".
2. Do NOT copy the keys to the regional backup server. Since (unlike 
much of the rest of the "archival" data on the primary backup server) 
these are already redundantly stored (laptop and primary) the chances of 
a quasi-simultaneous loss of both copies is minimal. (also, add this to 
the spec too)
rationale: Again, an actor with gov-level access could easily remove 
this protection before they shipped the local backup servers. However, 
as long as the local backup servers are honestly shipped and maintained, 
this protects against attacks at the regional level before the update to 
version 2. It would also be practically impossible to destroy the keys 
at the regional level if an industrial-strength backup scheme were in 
place there, whereas the local level does NOT need to be backing up to 
other media as they rely on the regional backup.

Just one more quibble:

>
> The problem comes down to that by splitting up your key (either in a 
> simple half-n-half system, or a more rigid/proper 'secret sharing' 
> (see below) system, is that either way, the N peers that you split up 
> your private key have the potential to get at your private documents. 
> Relying on some type of hardware-level (UUID, or similar) component 
> alongside the private key should be able to get around this. Moving to 
> a new laptop would require the social process (asking a teacher to 
> update the mapping of student->laptop pairing previously talked 
> about). Combining these two steps should create a secure scheme that 
> relies on your peers and your teachers to not conspire against you but 
> that keeps either individual party from being able to snoop on you 
> without raising big red 'what the hell are you doing' flags.

I don't get it - the UUID in this context is just another piece of data 
available on the laptop, like any data it either exists [possibly as 
part of a shared secret] elsewhere (server/peers), or it doesn't.

Jameson Quinn


More information about the Security mailing list