[OLPC Security] Developer Key

[Carl-Daniel Hailfinger]

Simson Garfinkel wrote:
> 
> 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 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.

Maybe I didn't make this clear enough. Next try.
The developer key is intended as an no-hardware-damage-risk alternative
to opening the case for reflashing.

I disagree with your assertion that it is too easy to break the machine.
Jim Gettys once wrote: "we expect frankenlaptops will be common, and are
doing what we can to make that reasonable."
That seems to suggest disassembly is reasonably easy without damage.


>> 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.

Partially agreed. The ability to refuse updates is something we may want.
The rest of the scenario is out of the scope of the current security doc.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/