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 <csc...@laptop.org>
Date: Fri, Oct 17, 2008 at 3:11 PM
Subject: 9.1 Proposal: Improving antitheft
To: Devel List <de...@laptop.org>, sugar <su...@lists.laptop.org>
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 <csc...@laptop.org>
Date: Tue, Jul 15, 2008 at 1:40 PM
Subject: Re: EC EEPROM security mod.
To: John Watlington <w...@laptop.org>, Richard Smith
<rich...@laptop.org>, 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 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.
* Broken updates are a problem. The 128 bits of EEPROM are broken
into two banks of 64 bits each, which keep a 62-bit "seconds since the
epoch" time value plus a 2 bits "bank counter" in the last byte to
updated. We read from the highest "bank counter", where 00 is deemed
greater than 11, and write the lowest "bank counter" with the value of
the highest bank counter plus 1. This ensures that our updates commit
atomically, and that writes are spread evenly among the two banks.
Special case startup, when both banks are 11, and write bank counter
00 to bank 0.
--
( http://cscott.net/ )
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
