Talk:Partial key autonomy

We could avoid much of the pain of testing new firmware releases by putting the per-country keys in the mfg data sector. To start the process, we could issue a signed country-specific firmware release that would automatically install those keys in the mfg data sector. Subsequent firmware release would be country-neutral, containing only the OLPC keys in the OFW portion. Normal firmware updates preserve the mfg data untouched, thus any country-specific overlay keys would persist across firmware updates.

This would reduce the maintenance effort to a one-time-per-country event.

We might need to let the country choose whether the country-specific system will accept both the country key and the global OLPC key, or just the country key. The former seems like a better idea to me, but I can imagine that some country might want the latter. It could be done by adding a tag to mark the country keys as "exclusive" or "alternative". (Mitch)

Is adequate space available for the keys? --Michael Stone 20:15, 25 December 2008 (UTC)

Yes, plenty (Mitch)

---

Proposal 2 Discussion

Michael Stone speaking:

I don't understand Scott's proposal; hence, I'm going to try to write it up more clearly. I expect that Scott will read and correct my interpretation before we ship this software so that explanations are available to those who prefer paragraphs as well as those who prefer compressed fragments. Here we go:

The proposal:

1. The best way to provide partial key autonomy is by means of a "policy overlay" stored in the mfg-data.
   • This way, OLPC can supply a single firmware to all its customers but the firmware can still exhibit deployment-specific behavior in the presence of deployment-specific mfg-data.
2. Two policies which the firmware should implement include:
   1. a "replace X" policy which replaces the keyring for lock X with a deployment-specified key
   2. an "augment X" policy which augments the keyring for lock X with an additional key
      • Michael wants to know when you'd ever want to use an "augment" policy.
3. To make this really usable, we need a mechanism for modifying the mfg-data on already-deployed laptops.
   • Scott suggests that we modify the NAND-reflash code path to admit mfg-data modification.
     • Michael wants to know why this is the best way to fulfill the requirement.

Mitch:
I'm thinking of an implementation where you can choose "replace" or "augment" on a key-by-key basis, thus giving fine-grained control. The "augment" case could have up to nine additional keys. Coding that is as easy as a coarser-grained approach.
For already-deployed laptops, the safest way to modify the mfg-data is to reflash the firmware with a special no-write-lock version that fixes up the mfg-data, then reflashes itself with a new version that reinstates the write lock. But given such a two-stage process (i.e. you first have to reflash the firmware), the door is open to a variety of firmware mods to streamline the process. In any case, this isn't something we need to micromanage as part of the design-level discussion.

Questions:

1. Which locks should admit overlay data? With what policies?
2. How should the resulting keyrings be exposed to userland? (e.g. /ofw/.... in format ....)
3. How should the overlay data be inserted into the mfg-data of already-deployed machines?
4. What effect does engaging the overlay have on the support relationships between OLPC and a deployment (contractual _and_ otherwise)?
   • Scott writes that "If the country choses to replace the OLPC keys (instead of augment them) OLPC takes no further responsibility for support, recovery, or diagnostics" but this statement is not justified and does not explain what happens if deployments use a simple augmentation overlay.
5. Are there any other policies that should be available?
   • e.g. an "unlock X" policy which lets any message pass through the specified lock
6. Can an overlay specify both more than one policy for a lock?
   • If so, how do we resolve conflicting policy assignments?

Mitch:
Re Q1: That's a policy decision that will probably be revisited over time. I doesn't affect the code, unless one were to hard-code the policy in the implementation, which I'm not inclined to do.
Re Q2: If the extra keys are in mfg data, they will automatically appear as "files" in /ofw/mfg-data . At the expense of using extra space in mfg data (which has plenty of space), I could make the basic storage format be ascii hex instead of binary, so you could display the file with "cat" instead of "od". The decision boils down to whether to optimize for the convenience of a human browsing the data or the convenience of programs that read it. For the purpose of ".mfg-data" in OFW, the display format will be ascii hex in either case, as I'll add a format recognizer to the .mfg-data code.
Re Q3: Already discussed above

C. Scott:
Q2 above: Augment as well as replace allows countries more flexibility: they can make their own builds *or* use OLPC-provided builds. This is a better upstream model: it doesn't force the maintenance of a local fork as downstream customizations get incorporated into the next upstream build. It also addresses a deployment issue: it allows XOs to leave the factory with an OLPC build and an augmented key, and allows a seamless "upgrade" in the field to an exclusive key and the country's own build, if that is what is desired.
Q3, below and above: I prefer using the existing multicast distribution mechanism, if at all possible, because of the flexibility it gives deployments. For every entire-school mass-upgrade the country can decide to turn on or off or add keys. This allows key rotation, admits the possibility of ongoing changes to relationships with build providers, and so on.
Q4: irrelevant/no effect. I don't see how a software change can modify preexisting contractual terms. The phrase you quote should perhaps be reworded: I just mean that the countries can get the machines in a position where they are locked and OLPC can't unlock them for diagnosis or repair. Caveat country.
Q5: I believe many policies are possible with Mitch's general framework: that's the point.
Q6: No. If an exclusive key is present, it wins. I believe that Mitch's proposal is that a d0 key, if present, overrides the built-in OLPC developer key. And d1, etc keys apply in addition to that. It is desirable to allow "glitch-free" upgrade to an exclusive key from a shared one: the machine is shipped with d1, and you can write d0 without removing d1, so there is no point at which interruption would leave the user without a working key.