Partial key autonomy: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 4: Line 4:
For each party P who so requests,
For each party P who so requests,


# ask party P to generate
# OLPC asks party P to generate and to supply the public portions of these keys:
#* P_OS_key -- per [[Firmware security#Summary|Firmware security]], guards the theft-deterrence code-path through the kernel and initramfs
#* P_OS_key -- per [[Firmware security#Summary|Firmware security]], guards the theft-deterrence code-path through the kernel and initramfs
#* P_FS_key -- see the bottom of OFW's [http://openbios.org/viewvc/cpu/x86/pc/olpc/loaddropins.fth?view=markup&root=OpenFirmware loaddropins.fth]; opens the NAND reflash lock.
#* P_FS_key -- see the bottom of OFW's [http://openbios.org/viewvc/cpu/x86/pc/olpc/loaddropins.fth?view=markup&root=OpenFirmware loaddropins.fth]; opens the NAND reflash lock.
#* P_LEASE_key -- per [[Firmware security#Summary|Firmware security]], opens the activation lock
#* P_LEASE_key -- per [[Firmware security#Summary|Firmware security]], opens the activation lock
#* P_OATS_key -- per [[Theft deterrence protocol]] and [[User:Mstone/Commentaries/Mass olpc-update|Mass olpc-update]], verifies theft-deterrence messages.
#* P_OATS_key -- per [[Theft deterrence protocol]] and [[User:Mstone/Commentaries/Mass olpc-update|Mass olpc-update]], verifies theft-deterrence messages.
# OLPC generates a new firmware update key specific to P's customization request named OLPC_P_FW_key, per [[Firmware security#Summary|Firmware security]].
# 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
# have OLPC return a signed version of the customized firmware to party P.


Then, throughout the future, OLPC may generate and sign firmware containing the public values of these keys. The keys
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 [[Firmware Key and Signature Formats#Version_2|version-2 lease signatures]]. OLPC will retain responsibility for providing developer keys and firmware updates.
* 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.

By installing these signed 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.


==== Benefits ====
==== Benefits ====
Line 30: Line 34:
* unless some care is taken, it poses a denial-of-service risk to innocent third-party users of locked machines.
* 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.)
** (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?





Revision as of 23:49, 24 December 2008

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

By installing these signed 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 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.)




Proposal 2

your proposal here...