XO automatic clock setting

[Martin Langhoff]

On Thu, Aug 27, 2009 at 4:05 PM, Daniel Drake<dsd at laptop.org> wrote:
>> 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.

Why do both OFW and initramfs check the same thing? Hysterical
raisins. Mitch wanted OFW to boot a very skinny initramfs if it all
matched right, and the 'fat' initramfs only when needing to activate.

Mitch's point is valid, as we spend quite a bit of time reading,
computing & checking hashes, and uncompressing the initramfs.

On the other hand, the Bitfrost arch has the expectation that the
signed&trusted initramfs starts an 'init' that runs  the OAT protocol
client. This work is not complete, but as you've seen, we _always_ end
up with a python init (hence, a 'fat' initramfs).

This thread (of many on the topic) has lots of the core elements of
the discussion http://lists.laptop.org/pipermail/devel/2007-July/005732.html

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

Good question. In brief:

1 - country gets their own set of keys
   - ... and gets them loaded on the XOs to be used with multi-key
support (either in "slot0", overriding OLPC's key or in "slot1",
augmenting OLPC's key)

2 - country keeps a good inventory of what XO is going to go to which school
   - makes spreadsheet with "schoolname, sn, uuid"
   - export spreadsheet into CSV
   - feeds CSV to magic olpc-bios-crypto script
   - results: one keypair created for every XS (on the first run),
plus files with the correct delegations for each school

Notes on "Correct delegations for each school":

 - We need delegations from the OATS and LEASE keys, each delegation
must be from the appropriate key to the specific XS key, for a limited
time, and for the specific XO (uuid, sn).
 - For the OATS delegation, we don't need the uuid to be present in
the delegation file, but we do need it for the LEASE delegation (so
that the XS has the sn+uuid to make a new lease). As a result, the
delegation file format is slightly different.


 3 - country team loads the whole thing in a USB stick, and plugs said
USB stick into every XS
    - XS looks for a directory with its 'name' and imports keypair
(first time only) and delegation files

   A single USB stick fits the scenario of preparing all the XSs in a
central location. You can of course prepare a USB per XS, ship them
together or separately, etc.

 4 - XS is running at school -- it creates leases and signs messages
with its own private key, then searches for the right delegation for
the requesting XO, and "inlines" the delegation. This  shows that it's
signature is done with a key that has been blessed by the appropriate
top-level key, for the specific XO that is requesting it.

Phew. That's the short version anyway.

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

Multi-keys and delegation are orthogonal.

> Right now there is no assumption that the system that responds on port
> 191 is the trusted system which generated the lease.

The time is signed and with a nonce (so no replays).

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

Yes. But the XO clocks are not reliable either.

> 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 share your concern there.

You can easily shut down the port 191 service via xinetd. And yes, you
could make the time field in the response optional.

But the day it happens (that an XS clock is really off) things do go
pear-shaped.

cheers,


m
-- 
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff