Partial key autonomy: Difference between revisions
Jump to navigation
Jump to search
m (→Benefits) |
m (→Benefits) |
||
| Line 17: | Line 17: | ||
=== 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: |
|||
* OLPC can generate developer keys itself |
* OLPC can generate developer keys itself |
||
* Developer keys remain all-powerful for the laptops for which they are generated |
* 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 |
* 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 |
||
while providing much-requested autonomy who people who want to control all the other locks on their laptops, e.g. so that they can control what builds are installed and so that they can implement their own tamper-resistant theft-deterrence protocol. |
|||
=== Risks === |
=== Risks === |
||
Revision as of 23:18, 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
- 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...