Custom firmware with a different bitfrost key

[Mitch Bradley]

From: Guylhem Aznar <olpc at guylhem.net>

> For a project I'm working on, I need to sign images. However, these
> will be custom images, not olpc official ones - so I am wondering how
> I could sign them myself, creating a custom certificate for this.
>
> >From what I understand, it means changing the keys in the firmware.
> What do I need to do then to sign my images?
>
> Any pointer is appreciated.

You don't have to change the firmware; you can do the key augmentation in manufacturing data, as described at 
http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support

The procedure below requires that you have developer keys for all the machines that you wish to secure with new keys.  For machines without developer keys, the process is more complicated, requiring that OLPC issue a special signed "keyjector" firmware to augment the keys. OLPC issues keyjectors only in special circumstances, because of the security risk lest the keyjector escape and be used to unlock other deployed machines.

For the developer-key case, the process is reasonably simple.  

To make new crypto keys, do the following

  git clone -q git://dev.laptop.org/bios-crypto
  cd bios-crypto/build
  make

(The preceding works on most 32-bit x86 Linux systems; it might not work on 64-bit systems)

Then for each key that you wish to make, execute:

  ./makekey a1

The output goes to "a1.public" and "a1.private".  Repeat with other names to make additional keys, with names as described in the wiki page cited above.

Get this file:

http://tracker.coreboot.org/trac/openfirmware/browser/cpu/x86/pc/olpc/mfgkeyject.fth

Edit it to reflect your set of new keys (the value of "new-key-list$") and the set of SKUs (values of the P# mfg-data tag as shown by ".mfg-data") to which the new keys should apply (the "wrong-sku?" word).  (The SKU list check is a safety feature to guard against accidentally corrupting machines belonging to others.  A SKU - short for Stock Keeping Unit - is a particular system configuration for a given customer - SKUs differ according to keyboard printing, battery manufacturer, and default settings for language, keyboard mapping, and factory security settings).

Copy the edited mfgkeyject.fth file to a USB key, naming it \boot\olpc.fth .

Copy the .public files to the root directory of the same USB key, with names ending in ".pub" (e.g. \a1.pub ).

Insert the USB stick into the XO and boot from it.  After the key injection has been performed, the system will reset, and the next time the script will exit because the new keys are already present.  Remove the USB key and you are done.

> I'll add my experience to the firmware wiki page.

Yes, please.  Also, did you add to the wiki that description of firmware recompilation procedures that I sent a couple of weeks ago?