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. _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
