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