Switch to real public keys

[jg]

It may take a bit before Ivan completes #1495; a temporary key could be used in the meanwhile, and the real key substituted in a later update, though messing with manufacturing data is never our idea of fun.

There are at last 4 keys that go into SPI flash.

[wmb@…]

OFW already reports all the manufacturing data in the device tree, and there is another ticket for exposing the device tree to user space.

The remaining task for this ticket is thus to put the public key in the manufacturing data. That is a manufacturing process step, not something that is done directly in OFW code, so I'm reassigning this bug to manufacturing.

[cjb]

If this bug tracks everything up to userspace, it must also include getting the ofwfs device tree patch included in our kernel.

[vance.ke]

Hi, we don't know which detail procedures needed to do.
Could you please give us the details. Thanks. e.g.:
1. Where is proper OLPC public key location in 2k manufacturing data area of BIOS.
2. Use what utility to generate OLPC public key.
3. What is formation , length of OLPC public key in 2k location? (e.g. xxx.asc , xxx.gpg ,...)
4. etc.

Dear Luna,
Please assist factory and co-work with Elvis with the issue. Thanks.

Ref: http://wiki.laptop.org/go/Manufacturing_Data

[jg]

1. Mitch can assign the manufacturing data code for it. 2. Ivan can tell you the format we will use, though I'm sure it will be representable as ascii. 3. Ivan is responsible for generating the real public key. If this cannot be done in a timely fashion, we can supply a temporary one until the escrow and physical security issues are handled at OLPC.a

[kimquirk]

The device tree patch is in 406.6. Ivan will be generating a temporary key. This should go in immediately after OFW version is known for B4.

[krstic]

Temporary (testing) public key payload is here:

http://dev.laptop.org/~krstic/testkey_0612.public

[wmb@…]

I have been discussing this whole public key issue with Ivan. The current thinking is that the public key does not need differ from country to country. That being the case, it makes more sense to embed the PK in OFW, instead of putting it in the manufacturing data.

The only current "client" of the PK is secure firmware update, which means that nothing outside of OFW needs to see the PK except perhaps for diagnostic purposes.

Consequently, we should just wait until OFW integrates the secure update feature and incorporate the PK in OFW as part of that effort. The milestone remains Trial-2, but the responsibility is now solely in the OFW domain. No need for manufacturing support at the present time.

[kimquirk]

Moving to FRS since we don't have real keys for Trial-3

[wmb@…]

Q2D01 uses a different set of "MP" keys. The "real" HSM-generated keys are not yet available.

[gregorio]

Is this really a blocker for 8.2.0?

If so, can we get a design proposal and lead customer ASAP?

If not please reset the target release and add it to the 9.1.0 tracking page at: <br> http://wiki.laptop.org/go/9.1.0#Priorities_from_Engineering

[cscott]

I've got some software security work I want to get done in the initramfs; I'll probably switch to a new set of keys after that is done, so that we can manage/limit downgrades. That's currently scheduled for the 9.1 timeframe.

[wmb@…]

The current key generation procedure and the keys it generated are adequate.