[OLPC Security] Developer Key

[Simson Garfinkel]

On Feb 21, 2007, at 9:03 PM, Carl-Daniel Hailfinger wrote:

> Simson Garfinkel wrote:
>> Several people have voiced confusion over the developer's key.
>>
>> The purpose of the developer's key is to make it possible for  
>> students
>> to change kernels, disable security features, try new operating  
>> systems,
>> etc., to further the OLPC "constructivist" learning philosophy.  We
>> don't make it easy, because disabling these features has risk to the
>> laptop and to the student.  We couldn't come up with another  
>> system that
>> would make it both possible to remove these protections and yet
>> difficult and time-consuming to do so.
>
> One concern I believe has not been addressed yet is that countries may
> wish to issue developer keys themselves instead of delegating it to  
> olpc.
> How do we deal with that ("customer is king" vs "kids must have  
> power")?

If the countries want to issue developer keys, then they will issue  
developer keys.


>
>> The developer's key is not an end-run around the security system.  
>> It's a
>> way for students to say "I will manage my own security." For example,
>> although the key makes it possible to turn off P_THEFT, it doesn't
>> require that the student do so.
>
> May I take this a bit further and say that the developer key is  
> intended
> as an alternative to opening the case for reflashing?
>

You certainly can, but you would be wrong. I don't know about Ivan,  
but I don't consider opening the case to reflash to be a reasonable  
course of action. It's too easy to break the machine.

>
> As a side note, managing your own security may as well mean the  
> ability
> to refuse official signed updates. Why? Given that some of the  
> (possible)
> customer countries may have slight political/economical stability  
> issues,
> it is entirely possible that laptops may receive updates which
> incapacitate parts of their functionality or turn them into propaganda
> vehicles.
> OTOH, updates temporarily disabling parts of the hardware may as  
> well be
> desirable e.g. to avoid laptops getting tracked down via their  
> wireless
> signature. Think military invasion here. Destroying the local
> communication infrastructure helps the attacker a lot and so laptop
> owners may be protected by making their laptops undetectable.

I consider all of these issues beyond the current security document  
that we are discussing.