Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 6:54 PM, John Watlington wrote: > > On Jul 7, 2010, at 5:07 PM, James Cameron wrote: > >> On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: >>> Unfortunately, the software changes required are to EC code, which is >>> difficult for outside contributors to work on. >> >> Yeah, that would be good to change. > > Have you forgotten that Richard and I have been working > to get that changed for XO-1.75 ? Or did we forget to report it ? I hope that XO-1.75 will also have space for a small serial flash on the motherboard then. =) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Jul 7, 2010, at 5:07 PM, James Cameron wrote: > On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: >> Unfortunately, the software changes required are to EC code, which is >> difficult for outside contributors to work on. > > Yeah, that would be good to change. Have you forgotten that Richard and I have been working to get that changed for XO-1.75 ? Or did we forget to report it ? Maybe Richard can update us on the status. Regards, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 07, 2010 at 04:57:19PM -0400, C. Scott Ananian wrote: > Unfortunately, the software changes required are to EC code, which is > difficult for outside contributors to work on. Yeah, that would be good to change. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:01 PM, C. Scott Ananian wrote: > * Updating exactly every hour is vulnerable to an attacker who > arranges to remove the battery from the machine exactly 55 minutes > after power on, every time. This is still quite awkward, but to avoid > even this attack, the EC can pseudo-randomly decide exactly when to > update the EC based on a random seed passed in from OFW from the > Geode's HWRNG, with an *average* interval of an hour. We probably > don't have to perform this extra trickery if we just shorten the > interval to 6 minutes or so, but the means that the EC's EEPROM will > wear out at the end of the 5 year service life of the machine. We can > probably detect this condition (EEPROM no longer writes reliably) and > just disable passive kill security at this point, though, which might > be nice for freedom-loving reasons. 2010 thoughts: I like the idea of pseudo-random updates. Having a uniform 1/60 probability of update every minute makes powering off as a circumvention mechanism pointless, while reducing EEPROM writes. A very simple linear feedback shift register for generating pseudo-random bits would be sufficient, since the inputs and outputs of the system are hidden. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Wed, Jul 7, 2010 at 4:48 PM, John Watlington wrote: > On Jul 7, 2010, at 4:01 PM, C. Scott Ananian wrote: > >> Since "RTC security" is being discussed again, I'm going to repost two >> relevant proposals from "the good old days". First: on making >> theft-deterrence a "feature"; then technical details of a $0.16 change >> to remove RTC dependence from the theft-deterrence feature. >> Unfortunately, the specific circuit changes required are XO-1 >> specific; presumably some slightly different version is needed for XO >> 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make >> this change in hardware at some point; I don't know if corresponding >> software was ever written. > > The EEPROM needed for this was included in early XO-1.5 prototypes, > but was dropped from production due to the lack of software making use > of it. It could be added back to any XO-1.5 SKU for a slight cost increase. Unfortunately, the software changes required are to EC code, which is difficult for outside contributors to work on. (Also some OFW work, but that's available and easily hackable.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing RTC from Theft-Deterrence
On Jul 7, 2010, at 4:01 PM, C. Scott Ananian wrote: > Since "RTC security" is being discussed again, I'm going to repost two > relevant proposals from "the good old days". First: on making > theft-deterrence a "feature"; then technical details of a $0.16 change > to remove RTC dependence from the theft-deterrence feature. > Unfortunately, the specific circuit changes required are XO-1 > specific; presumably some slightly different version is needed for XO > 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make > this change in hardware at some point; I don't know if corresponding > software was ever written. The EEPROM needed for this was included in early XO-1.5 prototypes, but was dropped from production due to the lack of software making use of it. It could be added back to any XO-1.5 SKU for a slight cost increase. Regards, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Removing RTC from Theft-Deterrence
Since "RTC security" is being discussed again, I'm going to repost two relevant proposals from "the good old days". First: on making theft-deterrence a "feature"; then technical details of a $0.16 change to remove RTC dependence from the theft-deterrence feature. Unfortunately, the specific circuit changes required are XO-1 specific; presumably some slightly different version is needed for XO 1.5, XO 1.75, etc. I vaguely remember wad saying he managed to make this change in hardware at some point; I don't know if corresponding software was ever written. Note that the principle here is that OFW and the EC are the only "protected code" in the system, and the only pieces which must be protected from unauthorized update/modification. The EC is a separate processor running its program independent of OS interference, and so is the perfect place "on which to stand" to implement a security system. Computation capabilities in the EC are limited, so any lease validation, cryptography, etc, is done in OFW on the main processor in the protected run time before the OS boots. Once the OS boots we don't expect any additional trusted computation to be done on the main processor. --scott -- Forwarded message -- From: C. Scott Ananian Date: Fri, Oct 17, 2008 at 3:11 PM Subject: 9.1 Proposal: Improving antitheft To: Devel List , sugar I'd like our antitheft support to be more of a "feature" which G1G1 users could elect to enable, if they like. This involved making it much more visible and configurable, most likely putting it in the control panel. The idea is if you are taking a trip or leaving home for a few days, you could "turn on theft-deterrence" before you go, get some added tracking/remote-kill features, and then turn it off later when you get home. Other topics: * ECO fix and EC improvements * Security control panel, with "am I stolen" and lease renewal buttons: ticket #1502, ticket #6428 * olpcrd work: ticket #7397 * Revoke root capabilities when booted with security enabled: ticket #7562 --scott -- Forwarded message -- From: C. Scott Ananian Date: Tue, Jul 15, 2008 at 1:40 PM Subject: Re: EC EEPROM security mod. To: John Watlington , Richard Smith , techteam Context for tech team: working on a minimal hardware fix that would provide enough "protected real-time clock" functionality that we could enable root and still believe in passive kill for theft-deterrence. Proposed hardware ECO: a) depopulate D31 b) add Microchip 24LC00T/OT (SOT-23 package), wiring: pin 1 (SCL) to SPIWP# (EC GPIOEC) pin 2 (Vss) to ground pin 3 (SDA) to EC_WP# (EC GPIOE0) pin 4 is n/c pin 5 (Vcc) to 3VPCU The 24LC00 part is less than $0.16 in quantity (maybe less from a Chinese source, there are lots of equivalent parts), some tiny fraction of which would be recouped by eliminating D31. This gives us 128 bits of nonvolatile storage accessible only via the EC. We use this to backstop the RTC to prevent clock replay attacks as follows: * At boot time, OFW asks the EC to read the EEPROM and takes max(RTC time, EC time) as its notion of "current time" when evaluating the validity of leases. [2010 edit: may want to completely ignore RTC instead, so that lease isn't shortened by accidentally setting RTC ahead too far in the future.] * At the point where OFW disables writes to the SPI flash, it also asks the EC to write the calculated "current time" back to its own EEPROM. Writes to the EEPROM after this point are disabled. * About once an hour (although it can be as frequently as every six minutes and still stay within the rated erase cycles of the EEPROM) the EC increments the EEPROM's value of time with its own notion of how much time has passed. We will probably deliberately calibrate this to be just shy of "real time" so the EC clock never runs faster than real time. (Details below.) The EEPROM is not accessible except via the EC, and no kernel commands can cause the EC to either avoid updating or misupdate its internal EEPROM. This allows us to give root priviledges to code running on the main processor without affecting the security of the passive kill system, addressing the major weakness in the current system. Lease times are more properly thought of in terms of "powered up time", not "real time", but they still perform their intended purpose. In my copious free time, I'll try to perform this ECO on a spare machine and hack up some EC code to drive it to prove the concept. --scott Details for the strong-hearted: * Updating exactly every hour is vulnerable to an attacker who arranges to remove the battery from the machine exactly 55 minutes after power on, every time. This is still quite awkward, but to avoid even this attack, the EC can pseudo-randomly decide exactly when to update the EC based on a random seed passed in from OFW from the Geode's HWRNG, with an *average* interval of an hour. We probably don't have to perform this extra
