[OLPC Security] Uruguay Security open issues

[C. Scott Ananian]

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? 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.
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? [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?]

2. The indication that a machine is stolen comes from a blacklist.
Who is trusted to make this blacklist? (One option is to delegate
blacklist authority for certain serial numbers, but Emiliano has
indicated that the number of machines on the blacklist is very small
-- 5 or 6 machines -- and infrequently updated. It may be reasonable
for OLPC to centrally maintain the blacklist and provide countries
with a means to update this via the activation server. This still
begs the authority question: what users are authorized to blacklist
which machines?)

3. Activation delegation? I am proposing to introduce a new
'delegated' lease type, which says, "until the expiration time, access
lease renewals from this key". (This would use the 'disposition'
field in http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease
but needs to record the trusted key somewhere.) This would allow OLPC
to generate long (5 year?) leases which delegate to a school server,
which is then entrusted with generating short (daily?) leases. How
many levels of delegation should be allowed? By varying the time of
the "long" and "short" leases we can make tradeoffs for better/worse
connectivity and the relative gain to be had by stealing a
schoolserver along with the laptops.

4. What's the recovery process for a machine marked stolen? Emiliano
has said that currently a blacklisted machine must be sent to the
repair center for reflash and thus reactivation, since the activation
lease will be wiped when the machine is reflashed (a feature). Since
we are considering various schemes to allow reflash w/o removing key
material, we need to ensure that these don't bypass the mechanism used
to mark a machine as stolen.

5. Replay protection on blacklist. The machine is removed from the
blacklist if it is recovered (or incorrectly marked stolen).
Blacklists need some replay protection to prevent someone from
attacking the system with old blacklists with outdated 'stolen'
information.

6. Delegation in the theft-deterrence protocol. The delegation
mechanism specified works well for places with at least initial
internet connectivity (like Uruguay); it might not work well in Peru
where an online interaction with antitheft.laptop.org at first boot is
impractical. How best to incorporate offline delegation?
(http://wiki.laptop.org/go/Theft_Deterrence_Protocol)

7. The OLPC theft-deterrence protocol uses nonces to prevent replay
attacks (such as the above). Given recent discussion about ensuring
high-quality randomness for early boot events, we should review
whether these nonces are effective. (I personally believe that a
nonce attack is just a special case of the real-time-clock attack, and
assuming you can prevent the latter then the former ought not be a
concern.)

8. Wireless activation. We need to more routinely test wireless
activation on our builds; Emiliano reports problems with 703. Also,
the activation server runs out of memory and panics the kernel when
given 60Mb of leases running on an XO.

9. Currently the only way to protect against RTC attacks is to deny
root (one must also check for 'suspiciously old' dates during
activation, which OFW currently does but olpcrd does not). This is
sad; we'd like to be able to give root access. Ivan's original
protocol assumed on-line access to a trusted time source, so that the
local RTC need not be trusted. Can/should we give strongly antitheft
guarantees in places where connectivity is guaranteed? (You can't
make do with "once a day" connectivity, because then you're relying on
the RTC again to let you know whether you need to do your "once a day"
check.)

Discussion welcome!
--scott

[Mitch Bradley]

Post by C. Scott Ananian
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...

Post by C. Scott Ananian
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.

Post by C. Scott Ananian
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.

Post by C. Scott Ananian
[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.