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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
