On Thu, Aug 27, 2009 at 7:30 AM, Daniel Drake<[email protected]> 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/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
