[OLPC Security] Uruguay Security open issues

[Mitch Bradley]

C. Scott Ananian wrote:
> Here are some notes about "questions we need to answer", after a
> meeting where Michael, Emiliano, and I sat down and read through
> Uruguay's antitheft code together.
>
> 1. Why aren't the firmware/os/lease/developer public keys in
> manufacturing data, instead of burned into firmware?

It is (or at least was, when we were first deploying security) easier to 
release the
keys as part of a firmware release compared to injecting them into the 
Quanta
manufacturing process.  It took Quanta several iterations to stablize their
tools and procedures for the existing mfg data tags.  I didn't want to upset
that process at the time - mass production was imminent - with something
that had as much bricking potential as security keys (the transition was 
painful
enough as it was :-)

There was also the situation that we wanted to be able to deprecate the 
first
set of test keys.  Doing that "automatically" as part of a firmware 
upgrade was
easier than having to create additional flashing procedures for 
jiggering the
manufacturing data to replace old keys.

We might be at the point now where we could revisit that decision, but 
see below...
> If we were to
> consider making Uruguay-only keys so they can sign their own builds,
> at the moment we would have to fork the firmware and make separate
> Uruguay-only firmware releases.  Originally these keys were going to
> be in the manufacturing data, to make them more easily customizable.
>   
It turns out that putting the keys in the manufacturing data is probably 
not any
easier, because doing a "key substitution" firmware release is very easy.

The firmware is stored in FLASH as a collection of "files" in a format akin
to the "romfs" format.  Each "file" has a 32-byte header with 
signature,  name,
compressed length, uncompressed length, and checksum, followed by the data.
The files are simply concatenated together, so manipulating the list of 
files
is quite easy.  (I developed this approach a long time ago to made it 
easy for
Sun OEMs and clone vendors to add custom firmware drivers, by concatenating
a new file to a stock Sun firmware image.)

Each of the four keys is stored in a separate such file, in binary 
format, not
compressed.  Changing the keys doesn't require any changes at all to the
firmware code, because the "linkage" is done at run time - the firmware
opens the key files by name.

We could just build multiple versions of each release with
different key "files", or we could postprocess the generic version to
inject different keys after-the-fact.  I have a toolkit for manipulating
this "filesystem" to insert, delete, or replace files.

Creating a release variant is thus quite easy and "safe" in that it doesn't
touch anything except the key data.  The issue becomes one of manufacturing
procedure.

Hmmm, I would also argue that it is "safer" to have the keys in firmware 
filesystem,
because then they are part of a signed wad.

> We seem to have a vague recollection that these were moved to the
> firmware because of limited space in the manufacturing data area.
> Mitch, can you refresh our memory?

The manufacturing data is in its own private 64K FLASH erase block, so there
is plenty of space there now.   That wasn't always the case - originally 
it was
at the end of the FLASH block that contains the EC code, hence the compact
encoding format.

> [This is not to say whether
> ultimately forking the key data is a good idea; the open question here
> is more along the lines of, is this an option we should consider?]
>   

I vote for leaving the keys in the firmware and releasing variant 
versions as needed.
If we end up needing a lot of variants and the procedure becomes 
unwieldy, we can
revisit the situation later.