Partial key autonomy: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
| 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.'' |
||
| Line 15: | Line 15: | ||
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. |
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. |
||
=== Benefits === |
==== 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: |
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: |
||
| Line 23: | Line 23: | ||
* 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: |
||
| Line 31: | Line 31: | ||
** (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 === |
==== Open Questions ==== |
||
* How do you do firmware updates after people start using customized firmware? |
* How do you do firmware updates after people start using customized firmware? |
||
== Proposal 2 == |
=== Proposal 2 === |
||
''your proposal here...'' |
''your proposal here...'' |
||
Revision as of 23:35, 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,
- ask party P to generate
- 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.
- 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.
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...