[OLPC Security] Extending theft-deterrence to support delegation.

[C. Scott Ananian]

This is a proposal to extend the current activation/theft-deterrence
formats and protocols to support delegation.  Connectivity to our
deployments is not good enough in practice to support mandatory
connections to antitheft.laptop.org in order to support passive or
active kill functionality.  Daily activation and active-kill authority
needs to be delegated to schoolservers (or even to a teacher's XO)
in order to be practical.  Further, the mechanism must work even if
no online connection can ever be made by the XO or XS to OLPC's
upstream servers.

Further discussion:
  http://lists.laptop.org/pipermail/security/2008-June/000436.html

Activation delegation
---------------------
The first step is to introduce delegation into the activation lease
format.  The idea here is that OLPC will generate a 'delegate'
activation lease, which says that, until the expiration time of the
delegate lease, a specified keypair will be able to activate the
machine.  For example:

  OLPC signs: "delegate activation until 2009-01-1 to keyid ABCDEF"
  schoolserver w/ keyid ABCDEF daily signs: "activate machine until tomorrow"

The durations of each of these leases can be varied to trade off trust
in the schoolserver and the "market window" a thief has to sell the
machine before the activation expires.  For example, in places with
less risk of theft the school server might generate weekly or monthly
leases for the machines in the classroom, or it might generate longer
leases before weekends, vacations, etc.  If theft of a schoolserver is
a concern, the top-level delegation to the schoolserver might be
monthly; if the schoolserver is adequately protected by its own
passwords the delegation might be yearly or "infinite".

The same basic mechanism can work with an arbitrary chain of
delegations.  Each signature in the chain takes ~2s to check, and
adds that amount of time to every boot.  Excessive chain length
should thus be avoided, but a three-level hierarchy such as:

  OLPC signs: "delegate activation 'forever' to Uruguay Min. Ed."
  Uruguay Min. Ed. signs: "delegate activation for the year to school#XXXX"
  School daily #XXXX signs: "activate until tomorrow"

might be reasonable for some deployments.  In particular, this
structure would allow the country to manage the assignment of laptops
to school servers without the involvement of OLPC's activation service.

Technical implementation:
-------------------------
The existing activation lease and developer key formats are defined by:
    http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats
We add a new disposition type, 'D', to the activation lease and
developer key formats.  The 'D' character should be immediately
followed by a space and then a 64-byte keyid in both the activation
lease and developer key formats.  We also change the version identifier
to '02' for leases and keys with this disposition.  A complete
delegated lease looks like:

act02: SHF12345678 D aa<60>aa 20090101T000000Z sig01: sha256 bb<60>bb 7<510>7
key01: 88<474>aa<60>aa
act01: SHF12345678 K 20081201T000000Z sig01: sha256 aa<60>aa 9<510>9

I have used the notation <N> to indicate that N characters were elided
from a field in this example.  The bb<60>bb keyid corresponds to the
public key held by OLPC.  The aa<60>aa keyid in this example is the
public key held by the schoolserver.

The signed data for act02/dev02 includes '<disposition>:<keyid>' where
the act01/dev01 formats have the substring '<disposition>' in the
signed data.

Note that the existing signature and key formats are newline
terminated.  Since I am trying to make the smallest possible changes
to the existing formats, the result is effectively a three-line lease.
I would encourage these lines to be kept together to allow efficient
checking and easier separation of leases from a concatenated file, but
in order to give ourselves future flexibility there shouldn't be any
required ordering of the three lines.

Absent firmware changes, OFW will ignore discard all three of the
lines of this activation lease (the first two because the format is
new, and the third because the keyid is not known to OFW) and invoke
the activation code in the initial ramdisk.  This activation code can
correctly parse the lease and proceed with the boot process.

Firmware support would be needed to support the equivalent delegation
mechanism for developer keys.  This functionality is less critical;
OLPC should be routinely generating developer keys for all laptops
manufactured, and since developer keys do not expire the delegation
mechanism is not as useful.  It could be argued that adding delegation
to developer keys is needless complexity and should be omitted.

Theft-deterrence protocol delegation
------------------------------------
The theft-deterrence protocol
    http://wiki.laptop.org/go/Theft_Deterrence_Protocol
already provides a delegation mechanism.  However, the mechanism was
designed to include a request of the 'top-level' antitheft protocol at
every query to confirm the delegation.  The mechanism for delegating
blacklists management to one server, updates to another, and lease
renewal to a third is adequate but clumsy, requiring chaining the
delegations between the multiple servers.

The simplest workable extension to the delegation mechanism is to add
an "expiration time" field to the delegate response.  This allows
future requests to bypass the top-level OLPC service until the
expiration time is reached.

Avoiding the first-boot ping of the top-level service is accomplished
by specifying that a special file named '/security/delegate.json' will
be interpreted to contain an initial response from the top-level
server.  It must be signed by the top-level server. The nonce in this
request should be the sha256 hash of the string "<SN>:<UUID>" for the
machine.  The /security/delegate.json file should be deleted after it
is processed.

Delegating the theft-deterrence protocol confers authority to
designate a given laptop 'stolen' or not.  A local blacklist can be
maintained on the schoolserver in cases where connectivity is
inadequate to support distribution of a central blacklist.

Secure reflash delegation
-------------------------
Uruguay has expressed concern about the ability to bypass their
security system by, for example, installing Peru's build on their
machines using the secure reflash mechanism.  I believe the
fundamental issue here is solved by standardizing on this core
security functionality across all deployments, so that Peru's build
does not grant permissions denied by Uruguay's build.  But the
critical issue of protecting the root user on the machine remains:
if Uruguay locks down root to prevent clock-resetting attacks, but
Peru does not, then reflash can be used to gain root.  Whatever
protections are enforced by reflash must also be enforced by
olpc-update.

One proposal is to specify that a special file 'lock.key' in the
/security directory on NAND be used to specify that, in addition to
the usual fs.zip signatures, a valid signature by the key specified by
lock.key is required in order to perform reflash or olpc-update.  As
long as only root is able to write/erase /security/lock.key, the
desired protection can be accomplished.

Alternatives
------------
The mechanism described here extends the act01 and dev01 formats.  An
alternative would be to extend the sig01 format to support
arbitrarily-chained signatures.  The expiration time and possibly
serial-number binding would have to be moved into the signature format
in that case, but this alternative might allow OLPC to uniformly
delegate all the signed objects in the security system.  It is not
clear whether this is a workable mechanism in practice for things like
kernel signatures, but it might suffice to allow a schoolserver to
proxy for the upstream antitheft.laptop.org service.  In fact, the
delegation mechanism for the theft-deterrence protocol could be
effectively replaced by simply directing the query first to the
schoolserver (perhaps via DNS redirection by the schoolserver), and
only querying upstream if the schoolserver is unable to provide an
acceptably-signed response using its delegated authority.  [I may
attempt to explore this alternative in a future email.]

A different alternative is to simply change the trusted keypairs in
the firmware, os, ramdisk, secure reflash, and theft-deterrence/update
code, effectively creating multiple separate domains of authority for
each major deployment.  This doesn't solve the necessity of delegating
daily activation authority to a school server, unless either all
school servers share a key pair, or else the build is customized for
each school.

A more limited version of this alternative is to simply allow for
customization of the secure-reflash keypair in firmware for each
deployment.  This accomplishes the aims of secure reflash delegation
with minimal collateral damage.

-----------

Comments requested.  Is there a way to accomplish our aims with less
work or more generality?  Are there security implications I'm not
thinking of?  Does this pass the Mitch Bradley sniff test?
 --scott

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