Partial key autonomy: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 19: Line 19:
should be escrowed for safe-keeping should OLPC cease to exist.
should be escrowed for safe-keeping should OLPC cease to exist.


Finally, by installing an appropriate OLPC_FW_key-signed P-customized firmwares on a stock machine, each party P will be able to provide builds and activation leases and will be able to execute or modify the theft-deterrence protocol for that machine autonomously from all other parties Q, including OLPC. Party P may also further delegate these abilities, e.g. with [[Firmware Key and Signature Formats#Version_2|version-2 lease signatures]]. OLPC will retain responsibility for providing developer keys and firmware updates.
Finally, by installing an appropriate OLPC_FW_key-signed P-customized firmware on a stock machine, each party P will be able to provide builds and activation leases and will be able to execute or modify the theft-deterrence protocol for that machine autonomously from all other parties Q, including OLPC. Party P may also further delegate these abilities, e.g. with [[Firmware Key and Signature Formats#Version_2|version-2 lease signatures]]. OLPC will retain responsibility for providing developer keys and firmware updates.


==== Benefits ====
==== Benefits ====

Revision as of 20:17, 25 December 2008

Proposal 1

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

Essentially, I propose to fork the firmware in a standard way for anyone who asks but to keep the resulting firmware update key private.

In more detail, for each party P who so requests,

  1. OLPC asks party P to generate and to supply the public portions of these keys:
  2. OLPC generates a new firmware update key specific to P's customization request named OLPC_P_FW_key, per Firmware security.

Then, throughout the future, OLPC may generate and sign firmware containing the public values of these keys. The keys

  • OLPC_FW_key
  • OLPC_DEVELOP_key
  • and the OLPC_P_FW_key for each party P

should be escrowed for safe-keeping should OLPC cease to exist.

Finally, by installing an appropriate OLPC_FW_key-signed P-customized firmware on a stock machine, each party P will be able to provide builds and activation leases and will be able to execute or modify the theft-deterrence protocol for that machine autonomously from all other parties Q, including OLPC. 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, in particular, of firmware.
  • 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.)



Proposal 2

your proposal here...