Here are some notes about "questions we need to answer", after a meeting where Michael, Emiliano, and I sat down and read through Uruguay's antitheft code together.
1. Why aren't the firmware/os/lease/developer public keys in manufacturing data, instead of burned into firmware? If we were to consider making Uruguay-only keys so they can sign their own builds, at the moment we would have to fork the firmware and make separate Uruguay-only firmware releases. Originally these keys were going to be in the manufacturing data, to make them more easily customizable. We seem to have a vague recollection that these were moved to the firmware because of limited space in the manufacturing data area. Mitch, can you refresh our memory? [This is not to say whether ultimately forking the key data is a good idea; the open question here is more along the lines of, is this an option we should consider?] 2. The indication that a machine is stolen comes from a blacklist. Who is trusted to make this blacklist? (One option is to delegate blacklist authority for certain serial numbers, but Emiliano has indicated that the number of machines on the blacklist is very small -- 5 or 6 machines -- and infrequently updated. It may be reasonable for OLPC to centrally maintain the blacklist and provide countries with a means to update this via the activation server. This still begs the authority question: what users are authorized to blacklist which machines?) 3. Activation delegation? I am proposing to introduce a new 'delegated' lease type, which says, "until the expiration time, access lease renewals from this key". (This would use the 'disposition' field in http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease but needs to record the trusted key somewhere.) This would allow OLPC to generate long (5 year?) leases which delegate to a school server, which is then entrusted with generating short (daily?) leases. How many levels of delegation should be allowed? By varying the time of the "long" and "short" leases we can make tradeoffs for better/worse connectivity and the relative gain to be had by stealing a schoolserver along with the laptops. 4. What's the recovery process for a machine marked stolen? Emiliano has said that currently a blacklisted machine must be sent to the repair center for reflash and thus reactivation, since the activation lease will be wiped when the machine is reflashed (a feature). Since we are considering various schemes to allow reflash w/o removing key material, we need to ensure that these don't bypass the mechanism used to mark a machine as stolen. 5. Replay protection on blacklist. The machine is removed from the blacklist if it is recovered (or incorrectly marked stolen). Blacklists need some replay protection to prevent someone from attacking the system with old blacklists with outdated 'stolen' information. 6. Delegation in the theft-deterrence protocol. The delegation mechanism specified works well for places with at least initial internet connectivity (like Uruguay); it might not work well in Peru where an online interaction with antitheft.laptop.org at first boot is impractical. How best to incorporate offline delegation? (http://wiki.laptop.org/go/Theft_Deterrence_Protocol) 7. The OLPC theft-deterrence protocol uses nonces to prevent replay attacks (such as the above). Given recent discussion about ensuring high-quality randomness for early boot events, we should review whether these nonces are effective. (I personally believe that a nonce attack is just a special case of the real-time-clock attack, and assuming you can prevent the latter then the former ought not be a concern.) 8. Wireless activation. We need to more routinely test wireless activation on our builds; Emiliano reports problems with 703. Also, the activation server runs out of memory and panics the kernel when given 60Mb of leases running on an XO. 9. Currently the only way to protect against RTC attacks is to deny root (one must also check for 'suspiciously old' dates during activation, which OFW currently does but olpcrd does not). This is sad; we'd like to be able to give root access. Ivan's original protocol assumed on-line access to a trusted time source, so that the local RTC need not be trusted. Can/should we give strongly antitheft guarantees in places where connectivity is guaranteed? (You can't make do with "once a day" connectivity, because then you're relying on the RTC again to let you know whether you need to do your "once a day" check.) Discussion welcome! --scott -- ( http://cscott.net/ ) _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
