[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

-- 
 ( http://cscott.net/ )