Partial key autonomy

From OLPC
Revision as of 23:35, 24 December 2008 by Mstone (talk | contribs)
Jump to navigation Jump to search

Proposal 1

Maintain the firmware and dev-key status quo while permitting everything else to be modified.

For each party P who so requests,

  1. ask party P to generate
  2. generate a firmware, initramfs, and olpc-update which contain the public values of these keys.
    • alternately, provide the keys through /ofw and rewrite the initramfs and olpc-update code to read /ofw
  3. have OLPC return a signed version of the customized firmware to party P.

By installing the signed customized firmware on a stock machine, party P will be able to autonomously provide builds and activation leases and will be able to execute or modify the theft-deterrence protocol for that machine. Party P may also further delegate these abilities, e.g. with version-2 lease signatures. OLPC will retain responsibility for providing developer keys and firmware updates.

Benefits

In addition to providing much-requested autonomy who people who want to control all the other locks on their laptops, this proposal preserves the status quo in three important ways:

  • OLPC can generate developer keys itself
  • Developer keys remain all-powerful for the laptops for which they are generated
  • If v2 signature checking is implemented in the firmware, OLPC can delegate its ability to generate developer keys to others on a per-laptop basis

Risks

However, the implementation of the proposal would incur several risks:

  • it somewhat complicates the task of making, testing, distributing, and deploying releases.
  • unless some care is taken, it poses a denial-of-service risk to innocent third-party users of locked machines.
    • (people willing to unlock their machines with a devkey or to maintain their own customized firmware suffer little additional risk.)

Open Questions

  • How do you do firmware updates after people start using customized firmware?




Proposal 2

your proposal here...