XO automatic clock setting

[C. Scott Ananian]

On Thu, Aug 27, 2009 at 7:30 AM, Daniel Drake<dsd at laptop.org> wrote:
> The server will respond with: "time01: <TIMESTAMP> sig0x: xxx"

I don't understand why this is necessary; there is already a 'time'
field in the server response for this purpose:
 http://wiki.laptop.org/go/Theft_deterrence_protocol#Theft-deterrent_server_response

> 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.

Server time is trusted, because it is validated with a signature; the
XO's local time should be updated if necessary, but validation should
be done with the server's time to avoid races with another process
updating the XO's clock.

> 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.

That seems roughly correct.

> 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

Yeah, that sounds reasonable.

> 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.

I don't think we ever needed OFW changes; OFW knows enough to punt to
the initramfs.

> 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.

The OATS server request has the correct trusted signatures, that should be used.

> 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.

OATS keys are a little 'less secure' than the lease keys, since they
(a) live on the OATS servers, not in Cambridge, and (b) sign a lot
more material.  Separating the high security and low security keys is
good security practice, so that compromise of one doesn't compromise
the other.

> 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?

There's a proposal which uses only the OATS server time, and doesn't
rely on the XO clock at all.  If I understand correctly, wad included
the hardware support for this in XO 1.5.

> 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?

I'm not sure why you believe it should be disabled.  Hijacking an XS
allows for lots of attacks on local XOs, since the XS is a trusted
part of the infrastructure.  Hopefully those attacks are limited to
the XOs which trust that particular XS (ie, not all of them).  This
was part of the sig02 tradeoff: increased XS trust in exchange for
less centralized management.  The way it is architectured you can vary
the amount of trust in your XS on a per-deployment basis (ie, you can
trust only the canonical OATS server in cambridge, and never trust an
XS, if that's what you prefer for your deployment).
 --scott

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