Partial key autonomy

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:
   • 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.
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 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."

Proposal 3

your proposal here