[OLPC Security] Extending theft-deterrence to support delegation.

[C. Scott Ananian]

On Thu, Jun 12, 2008 at 4:32 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
> I will analyze this further, later. However, I see one minor issue with this
> proposal right away: there is no way for a key to delegate some but not all
> of its authority. Thus, at every level, separate keys must be used for
> separate purposes - activation, kernel, ramdisk, and secure-reflash - or all
> of these permissions will be synonymous. This is totally feasible; however,
> this does limit the extensible usability of this format.

For better or worse, we already have separate keys for all these
purposes.  The current proposal continues with the 'one key per
function' idea.

> I suggest that the <serial number> part of the chained signed data be
> replaced by an application-specific <application>:<authorization details>
> field. For example, for activation, this could be
> act01:<serial number>
>  3 2 1 ?

This is reasonable, but parsing an arbitrary-length field is tricky.
We tried adding a 'disposition' field to the act01 and dev01 formats
to future-proof it, but as you can see in the end we failed to
anticipate the exact direction of expansion which would be needed.  In
the end, I'd prefer adding a new 'dev02' or 'act02' format if needed
to provide application-specific features, rather than add a field to
sig02 whose use is yet-unknown.  Arguments to the contrary are
requested.

In actual fact, the delegations that would be useful for
kernel/ramdisk/secure reflash would be over a (quite large, and daily
changing) set of laptops.  Ideas to address that are welcome, but I
suspect they won't fall under the desired 'minimal modifcation to
existing format' goals.
 --scott

-- 
 ( http://cscott.net/ )