XO automatic clock setting

[Daniel Drake]

Hi,

I'd like to start a discussion about some of Martin's changes to the
olpcrd, OATS and olpc-update components -- at the very least I'd like
to make sure that the design of the new functionality has been at
least glanced at by Michael and Scott (and that they are unable to
immediately think of any risks). I'm a little uneasy at touching these
areas due to security implications and these security-related topics
should always be reviewed carefully...


1. As before, when a laptop is unactivated (or has an expired lease),
the client-side activation code in the initramfs is executed on the XO
during boot. It looks for a lease on USB, then SD, and finally falls
back to network.

Previously, the network fallback only involved looking on mesh
channels, connecting to a predefined IPv6 address on port 191, sending
the serial number and then expecting a lease in return on the same
socket. A recent addition is that the initramfs now additionally
connects to any open infrastructure networks in addition to the mesh,
but the dead-simple port 191 protocol remains the same until this
point.


Martin's work adds the functionality where the server running on port
191 can update the hardware clock on the XO. If it received any data
at all in response to the original "<SN>" message, the initramfs will
now send a 2nd message to the oats server with the string "time01:
<SN> <NONCE>" where the nonce is randomly-generated by the client at
that moment.

The server will respond with: "time01: <TIMESTAMP> sig0x: xxx"

TIMESTAMP is the time that the XO should update to. The clock update
is aborted immediately if the XO's clock is within 24 hours of the
time offered by the server. But if not, we continue:
The initramfs now verifies that the signature above is a valid
signature for the data string "<TIMESTAMP>:<NONCE>" (of the same
timestamp and nonce used in communication up to this point), and if
so, the time is set. The keys used for this verification are the
OATS_KEYS collection.

Both sig01 and sig02 formats are accepted in the server response. One
important point is that the expiry date of any sig02 keys used in the
chain are *not* checked at all -- this is because we're assuming the
XO clock might not be accurate.

Also, the time is set regardless of whether the lease is valid or not.

As it always has, the XS runs a port 191 server by default. This has
now been extended to respond to 'time01' requests with the system time
of the XS. This does not appear to be configurable. It uses the serial
number that was presented in the client's request in order to figure
out which key delegation to use to sign the response.

More details: http://dev.laptop.org/ticket/9439


2. olpc-update-query has recently been updated to look at the 'time'
field in the OATS server response and to unconditionally update the XO
hardware clock with that value.

The XS now ships an OATS server by default.  It serves leases, stolen
tags, and time. It signs using sig02.


3. For the client-side activation code in the initramfs that parses a
lease.sig from USB/SD, we now use a mmap() and regular expression
based parsing solution because the previous cjson parsing didn't scale
to 200,000 leases.

More details: http://dev.laptop.org/ticket/9442


4. sig02 leases are still unsupported in the latest OpenFirmware, but
it looks like we have renewed interest in getting this finished off,
so no initramfs changes will be needed in this area.



My own questions/concerns:

1. When updating the time over port 191, is it OK to ignore the expiry
of the sig02 lease? This seems to indicate that anyone who has got
hold of the appropriate key material to sign sig02 leases at some
point in time is now able to set the clock of any lease-expired XO who
is in range of their open network, even if their "sig02 license" has
expired.

2. Why use OATS_KEYS for signing the time over port 191? LEASE_KEYS
would seem more logical to me. Port 191 is for serving leases, so if
you are to expect any particular key on the server-side then I would
imagine it would be the lease key, and also port 191 is not the OATS
protocol which this key has historically been used for.

3. I'm uneasy at the idea of us trusting the XS clock. Particularly in
unconnected environments where it can't even rely on something like
NTP. If it hands out the wrong time then all XOs would be unable to
boot. Are there other concerns here, perhaps with someone hijacking an
XS?

I would vote that time-publishing should be disabled by default on the
XS. However, in the case of the OATS protocol it is not an optional
field. Should we extend/amend the protocol?


Daniel