XO automatic clock setting

[Daniel Drake]

2009/8/27 Martin Langhoff <martin at laptop.org>:
>> 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.
>
> Here Daniel skips the fact that there is a homely but IMO valid patch
> that -- when OFW tells us <activate> -- rechecks the filesystem for a
> valid lease before trying to activate.
>
> This is a good thing if we assume that the initramfs can evolve faster
> than OFW,  and the case "OFW doesn't recognise this sig format but
> Initramfs does" is a valid one.

Except, unless I missed something in the last discussion, we don't
fully understand why the system was ever designed like this. So I'm
making the assumption that there is something important that we aren't
understanding.

I included this point (as opposed to a discussion on "should we move
boot-time lease checking into the initramfs?") as the nicer
alternative, since we don't have to rework our way of thinking if we
aren't changing the core design of the system. It lets us keep the
delta smaller.

>> 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.
>
> Migitating factor: this risk is quite narrow -- sig02 leases depend on
> delegations to specific XOs.

Can you help me understand sig02? I've re-read the wiki and design but
I still don't quite understand the workflow. OLPC is going to provide
one bit of key material per laptop for a fixed  (long) time to
deployments, who are then going to use delegation to serve shorter
leases?
How does this get transferred to the XS and in which form? etc.

>> 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.
>
> If it hands out the wrong time, it will also hand out valid leases for
> that time -- unless it's far in the future. That "a time in the
> future" kills our XOs is pretty much part of the design.

Let's not assume that everyone will use this new system, or at least
let's be careful when forcing this on people.  Especially because
we've just only just released a parallel system (multiple keys in
firmware) which is already being used by multiple countries and can
realistically be used as an alternative to the delegation system.

Right now there is no assumption that the system that responds on port
191 is the trusted system which generated the lease. Specifically I'm
thinking that we can trust that the lease was generated on a trusted
connected good-clock computer, was safely distributed to the local XS,
but then the XS clock is not necessarily accurate. This setup works
right now without the dependency on the XS clock being valid, but this
system would add such a dependency.

Another potential situation: A deployment could be using long-lasting
leases but using the OATS server on a local server for OS update
advisories. No leases would be distributed in this system (except for
in the delivery chain) but still if OATS server were to set the wrong
time for the XOs, it would be devastating.

>> 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?
>
> Disabled _on the server_? The hypothetical linux-savvy attacker
> whostole the whole school will switch it *on*. Or am I missing
> something?

Yes,  I mean disabled on the server, but I wasn't referring to the
attack scenario. In general I have seen a  lot of failed clocks and I
am thinking that it should be up to deployments to say "OK, this clock
is safe or has a connected source that we trust, so let's give it the
power over all the XOs in the school"

Daniel