Partial key autonomy: Difference between revisions
m (→Risks) |
(→Proposal 3: add a 'discussion' section.) |
||
(17 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
== Proposal 1 == |
=== Proposal 1 === |
||
''Maintain the firmware and dev-key status quo while permitting everything else to be modified.'' |
''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. |
|||
⚫ | |||
⚫ | |||
# 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 |
|||
⚫ | |||
* 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 [[Firmware Key and Signature Formats#Version_2|version-2 lease signatures]]. OLPC will retain responsibility for providing developer keys and firmware updates. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
* OLPC can generate developer keys itself |
* OLPC can generate developer keys itself |
||
Line 23: | Line 29: | ||
* 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 |
* 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 === |
==== Risks ==== |
||
However, the implementation of the proposal would incur several risks: |
However, the implementation of the proposal would incur several risks: |
||
* it somewhat complicates the task of making, testing, distributing, and deploying releases. |
* 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. |
* 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.) |
||
⚫ | |||
---- |
|||
''your proposal here...'' |
|||
⚫ | |||
* Firmware is extended to store additional key pairs in manufacturing data. Each key in firmware (os, fs, fw, developer, activation) can be either '''replaced''' or '''augmented''' by key(s?) in manufacturing data. (OLPC key pairs are still stored separately, *not* in the mfg-data, so they are not subject to accidental deletion.) |
|||
* The firmware reflash script, currently signed by the fs key in fs.zip, is extended to allow it to rewrite arbitrary manufacturing data. (This would also aid in converting language settings for laptops, etc.) |
|||
* On request from a country, we will program the laptops from the factory with an "augmented" fs public key ('+s' tag, below), generated by the deployment. Upon receipt, the country can use an fs.zip signed by their fs key to replace or augment the remainder of the firmware keys, as well as reflashing the machines with their customized build and/or firmware, signed with their own keys so installed. |
|||
* If the country choses to ''replace'' the OLPC keys (instead of augment them) OLPC takes no further responsibility for support, recovery, or diagnostics. |
|||
* If legal opinion states that OLPC can not legally allow the developer key to be replaced (rather than augmented), this will be enforced in firmware as a special case. (As a technical matter, if the developer key is protected from replacement, the firmware key must also be protected by replacement or augmentation. As an alternative, *only* the firmware key may be protected; dev key functionality may be provided by a special firmware with an OLPC-signed delegated key which applies to a single serial number.) |
|||
That is the extent of the proposal. No further support (key delegation, issuing dev keys for non-OLPC keys, creating builds or firmware signed by non-OLPC keys, etc) is provided. |
|||
==== Proposed implementation ==== |
|||
* Mfg-data tags "+d", "+a", "+o", "+w", "+s", if present, ''augment'' the existing developer, activation, os, firmware, and filesystem keys, respectively. |
|||
* Mfg-data tags "-d", "-a", "-o", "-w", "-s", if present, ''replace'' the OLPC developer, activation, os, firmware, and filesystem keys, respectively. |
|||
** OLPC will ship with a deployment specified '+s' key, which they can bootstrap to augment other keys (by writing additional + tags) or replace OLPC keys (by writing additional '-' tags). They do not need to delete the '+s' key during this process, so there is no window of vulnerability. |
|||
* The following reflash commands alter mfg-data tags.... ''write me'' |
|||
==== Benefits ==== |
|||
* Provides the ability to mass-update other aspects of mfg-data like keyboard data. |
|||
* Simplicitly and power. |
|||
* Only a single shipped firmware and OS image. |
|||
* OLPC's responsibility is limited to adding a single additional mfg-data tag ('+s') to machines shipped to certain deployments. This tag is "mostly harmless" even if the manufactured machines are diverted to other deployments. |
|||
==== Risks ==== |
|||
* [[User:Mstone]] believes this to be "Substantially more costly to implement than Proposal 1 since it requires a rewrite and reaudit of code capable of permanently bricking laptops." |
|||
=== Discussion === |
|||
''mstone will write this section'' |
Latest revision as of 20:26, 5 January 2009
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,
- OLPC asks party P to generate and to supply the public portions of these keys:
- P_OS_key -- per Firmware security, guards the theft-deterrence code-path through the kernel and initramfs
- P_FS_key -- see the bottom of OFW's loaddropins.fth; opens the NAND reflash lock.
- P_LEASE_key -- per Firmware security, opens the activation lock
- P_OATS_key -- per Theft deterrence protocol and 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.
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 to 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
- Firmware is extended to store additional key pairs in manufacturing data. Each key in firmware (os, fs, fw, developer, activation) can be either replaced or augmented by key(s?) in manufacturing data. (OLPC key pairs are still stored separately, *not* in the mfg-data, so they are not subject to accidental deletion.)
- The firmware reflash script, currently signed by the fs key in fs.zip, is extended to allow it to rewrite arbitrary manufacturing data. (This would also aid in converting language settings for laptops, etc.)
- On request from a country, we will program the laptops from the factory with an "augmented" fs public key ('+s' tag, below), generated by the deployment. Upon receipt, the country can use an fs.zip signed by their fs key to replace or augment the remainder of the firmware keys, as well as reflashing the machines with their customized build and/or firmware, signed with their own keys so installed.
- If the country choses to replace the OLPC keys (instead of augment them) OLPC takes no further responsibility for support, recovery, or diagnostics.
- If legal opinion states that OLPC can not legally allow the developer key to be replaced (rather than augmented), this will be enforced in firmware as a special case. (As a technical matter, if the developer key is protected from replacement, the firmware key must also be protected by replacement or augmentation. As an alternative, *only* the firmware key may be protected; dev key functionality may be provided by a special firmware with an OLPC-signed delegated key which applies to a single serial number.)
That is the extent of the proposal. No further support (key delegation, issuing dev keys for non-OLPC keys, creating builds or firmware signed by non-OLPC keys, etc) is provided.
Proposed implementation
- Mfg-data tags "+d", "+a", "+o", "+w", "+s", if present, augment the existing developer, activation, os, firmware, and filesystem keys, respectively.
- Mfg-data tags "-d", "-a", "-o", "-w", "-s", if present, replace the OLPC developer, activation, os, firmware, and filesystem keys, respectively.
- OLPC will ship with a deployment specified '+s' key, which they can bootstrap to augment other keys (by writing additional + tags) or replace OLPC keys (by writing additional '-' tags). They do not need to delete the '+s' key during this process, so there is no window of vulnerability.
- The following reflash commands alter mfg-data tags.... write me
Benefits
- Provides the ability to mass-update other aspects of mfg-data like keyboard data.
- Simplicitly and power.
- Only a single shipped firmware and OS image.
- OLPC's responsibility is limited to adding a single additional mfg-data tag ('+s') to machines shipped to certain deployments. This tag is "mostly harmless" even if the manufactured machines are diverted to other deployments.
Risks
- User:Mstone believes this to be "Substantially more costly to implement than Proposal 1 since it requires a rewrite and reaudit of code capable of permanently bricking laptops."
Discussion
mstone will write this section