Slashdot Mirror
OLPC Has Kill-Switch Theft Deterrent
Sid writes "Ars Technica reports that the One Laptop Per Child (OLPC) XO has an anti-theft daemon in the OS that can be used to remotely disable machines, much like WGA. The Project added the kill switch at the behest of a few countries concerned about laptop theft. From the report, 'OLPC has responded to such concerns by developing an anti-theft daemon that the project claims cannot be disabled, even by a user with root access. Participating countries can then provide identifying information such as a serial number to a given country's OLPC program oversight entity, which can then disable the devices in certain scenarios.'"
Psshaww... Sony's laptops have much more effective kill switches than this.
There are many tongues to talk, and but few heads to think. -Victor Hugo
Sadly, I would imagine it will be a very short period of time before the feature is defeated. It's still a deterent I suppose, just not as much of one ...
In most cases the value to the thief is not in the object itself but in its resale value. If they know that the laptops will be bricked before they can shift them, it might deter some people from swiping them.
If the user has root access, then it is his box. Any component can be removed, including the dhcpcd client which attempts to enforce this rule.
It is only "possible" if you agree to run their software as installed.
Their reliance on GPL components should make it clear which components need to be replaced to avoid asking permission to continue using the software.
So, does this mean that the OLPC project is going to need a back-end infrastructure to support this Daemon? With the amounts of laptops considered in this project, that means that a pretty large back-end infrastructure is going to be needed to support this process.
In addition, there's going to need to be a tremendous amount of "process defintion" for something of this scale. What constitutes a "stolen" laptop in this case? How is it reported? To Whom? Who is ultimately responsible?
Sounds like a massive undertaking and far from clearly defined, other than a "Daemon is available."
Lindsay Blanton
RadioReference.com
I can see the writing on the wall.
...
Greetz griefers! Want to 0wn the n00b in your class? download this script and run it to disable anyone's OLPC.
Here's what you do:
Sounds to me like a convenient way to gag someone that a government doesn't want to be heard. "Are they making derrogatory comments about the leadership? Well then, just turn their computer off."
I suppose, it probably will only be a matter of time before some individual will figure out (in their mind) that this is a good way to extort money from someone else. "Send me $nn or I will disable your computer(s)." Then again, if they're using a $100 laptop given to them, what money would there be to extort?
If an invading nation wants an information blackout, shut everyone's laptop out.
Yeah since information only flows through laptops... right? How the hell is this modded insightful.
As I mentioned before, the whole concept of an unconnected laptop or one with minimal internet access (i.e wireless mesh) goes for a toss with this feature. The worst of the activation features which windows has, negating the real advantage of having a laptop you could take literally anywhere. Locking out someone just because they couldn't hook their PC into the network for twenty days is no way to make OLPC work. The real way to keep them off the black market is to reward those who keep their machines intact - just like the way to get kids to come to school has been a free lunch programme (and I sit in an Indian state with 99% literacy rates).
Or if you're really interested in reducing the utility of the machines, send an access code to the school master every month - for the laptops to get on the internet. You need to go pick up the coupon to get back on the internet and just kick the ones which are reported missing in audits - rather than go in for an active licensing scheme as mentioned in the document.
But in general, technical solutions for social (as well as economic) problems hardly work out, by themselves.
Quidquid latine dictum sit, altum videtur
It will be used to shut off the machines of disadents. Governments don't seem to care that much about machines being stolen, but they do care about giving power to political opponents. If I buy a machine, I should have complete control of it. No one should be able to remotely turn off the machine without my explicit authorization. I can't think of any way to make a feature like this safe from abuse.
-All that is gold does not glitter - Tolkien
www.ra
I have to say, I don't like the decidedly big-brother tilt the OLPC project has been taking lately. With all the news that has come out lately on OLPC, the whole "users will be able to read/understand/modify its source code" stance seems to have gone away.
If I can read and compile the O/S, who's to say I can't just remove the kill daemon from my build and then install it? In order to be robust, they'll have to lock down the installed software and make it impossible for the user to change. No community development; no share-and-share-alike; no software libre, counter to the whole "open source" philosophy they tout as the project's base.
This isn't a hacker's dream toy; its a business proposition to sell expensive supporting infrastructure and services along with a loss-leading locked-down client device disguised as charity in the name of educating the poor.
Several people, myself included, specifically pointed this out during the last story on OLPC's BitFrost system..
And can we please remember that it's One Laptop Per Child, and not One Laptop Per Slashdot-reading Guerilla Geek? Any abuse regarding deactivation of the laptops is more likely to be carried out by confiscation of the laptop by school personal.
Also, the feature can be disabled with a Developer Key from OLPC:
- http://dev.laptop.org/git.do?p=security;a=blob;hbMy Blog: http://nic.dreamhost.com/
The monitor only lets the OLPC authority shutdown the machine IF the anti-theft server says the machine has been stolen, OR the laptop is kept from accessing the server for more than x days (21 I think). And the daemon CAN be disabled, if the child requests the developer key from the OLPC authority (theres a 7 day wait to make sure the laptop wasn't stolen between the request and giving the key). The laptop uses code signing to prevent the operating system from being permanently modified (if you have the master key(s), or the developer key, you can modify it as much as you want, if you don't you can modify most of it but only in a copy of the system files, its a very nice way to allow most of the system to be modifiable by the kids, but if they bork it, you can just reset to using the original system files (assuming you didn't modify the original using the master/developer keys).
Now if the thief steals the developer key with the laptop, then the daemon is useless (unless they're too slow), and in the BitFrost document they acknowledge that theres is no way they can guarantee no laptops will be stolen, just try and discourage the thiefs.
When this (old) news first came out, I posted this gloom and doom comment, but after reading the spec, I realized that the picture was more complicated than my comment, or the summary above, indicates.
FTF Spec:
The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and disabling it requires a developer key). This, in effect, means that a child is free to do any modification to her machine's userspace (by disabling P_SF_RUN without a developer key), but cannot change the running kernel without requesting the key. The key-issuing process incorporates a 14-day delay to allow for a slow theft report to percolate up through the system, and is only issued if the machine is not reported stolen at the end of that period of time.My earlier concerns were that this funcitonality was the same type of call-home spying and TPM kill-switch control that MSFT in its most evil moments would love to have over all of its users and that OLPC had totally screwed the pooch.
The spec makes it seem a bit more like a maximally secure default setting, whose override is difficult but still accessible. They are simply storing the lock (the laptop) and the key (the developer key) in different places. The keys won't be given out if the lock has been reported stolen, but if not, they are available to the machine's owner.
Something about this still worries me, though. The developer key makes this system radically different from something like the WGA's phone-home spyware "feature" in that it can be disabled by the machine's owner, but given that the default setting is so hard to override, is the effect really all that different? Is this going to screw over less techical users who make a mistake and somehow manage not to "renew their lease" frequently enough? Worst of all, if something goes wrong with the centrally-managed key distribution system, millions of kids will be left with fully locked down, unhackable, TPM machines that will brick in an instant if they wait too long to phone home to the server of a government that may be more interested in censoring them than empowering them.
I'd be curious to hear what Stallman has to say about this project, especially this aspect of the security system. I think everything else about this project would suit even his lofty standards to a tee, but I think OLPC is walking a fine line with this anti-theft system.
No jokes, please
From the Bitfrost specification (which this killswitch is part of):
http://dev.laptop.org/git.do?p=security;a=blob;hb