Advertisement
Free copy of The Founder's Checklist and The Founders Pitch Deck Template from M L Bittle - New York; Advisor/Coach.
Weekly Edition
Return to the Front page
| |||||||||||||
Bitfrost: the OLPC security model
The One Laptop Per Child platform was always going to present some
interesting security challenges. Millions of identical, network-attached
systems will be deployed into some remote parts of the world, where they
will be managed by people who are not security experts. The systems will
be obvious targets for theft, self-propagating malware, and the creation of
botnets. None of these activities feature highly on the OLPC project's
list of educational objectives, so it stands to reason that some
significant thought needs to go into how to prevent them.
The person charged with the OLPC's security thinking is Ivan Krstić. The initial results of his work, done with help from Simson Garfinkel, have now been posted with a request for comments. Ivan and company have come up with a platform named "Bitfrost," which, it is hoped, will keep OLPC systems out of trouble and available for their owners. At this point, there is quite a bit of information on what Bitfrost will do, but very little on how it will be implemented. After an introduction on the shortcomings of the traditional Unix file permissions model, the Bitfrost specification gets into the overriding principles and goals. The principles are consistent with the approach the OLPC project has taken so far: security cannot depend on hardware or software design secrets, it must be possible for users to gain complete control over the system, security cannot depend on the user being able to read, and the security mechanism must be unobtrusive. "Unobtrusive" does not mean that security won't ever get in the way; instead, it means that the user will not be pestered by popups with security-related questions. The associated goals include no user passwords, no unencrypted authentication, a system which is secure when it is first powered on, a very limited use of public-key encryption infrastructure, and no permanent data loss. The process starts at manufacturing time, when each laptop will be equipped with unique, randomly-generated serial and UUID numbers. The laptop starts out in a non-functional, deactivated state; making it work involves the use of a special activation key generated from the serial number and UUID. The customer countries will have lists of serial and UUID numbers; from those it will be able to create the activation keys. The plan is for these keys to be generated in small batches and shipped, on a USB key, to the destination schools. Once installed on a server there, the keys can be used to enable the laptops sent specifically to that school. The purpose here is to deter thieves who would grab pallets of laptops; without the activation keys, those laptops would only be useful as spare parts. There is an interesting step which happens once a laptop is activated and booted:
On first boot, a program is run that asks the child for their name,
takes their picture, and in the background generates an ECC key
pair. The key pair is initially not protected by a passphrase, and
is then used to sign the child's name and picture. This information
and the signature are the child's 'digital identity'.
The laptop transmits the (SN, UUID, digital identity) tuple to the activation server. The mapping between a laptop and the user's identity is maintained by the country or regional authority for anti-theft purposes, but never reaches OLPC. The ability to locate the proper owner of an OLPC system has obvious advantages; it should help to keep each laptop in the proper set of small hands. On the other hand, the potential for a repressive government to misuse this data seems real; it would be sad if the OLPC systems could not be used for truly free communications without fear about who might be listening. At the BIOS level, security will be handled as described in this LWN article from last August. The BIOS will only be rewritable when the new image has been signed with a special cryptographic key. There will be "developer keys" available which will enable a laptop's owner to reflash the BIOS, but, in general, the children will not have that functionality available to them. At the Linux level, security will be handled through a set of privileges assigned to each installed program. Privileges look much like Linux capabilities, but they are not capabilities; they are a new layer of protections which will be implemented via some other means. Some of the expected privileges will include:
In addition, every program will be run in an isolated mode:
A program on the XO starts in a fortified chroot, akin to a BSD
jail, where its visible filesystem root is only its own constrained
scratch space. It normally has no access to system paths such as
/proc or /sys, cannot see other programs on the system or their
scratch spaces, and only the libraries it needs are mapped into its
scratch space. It cannot access user documents directly, but only
through the file store service, explained in the next section.
Again, details on just how the sandbox will be implemented are scarce for now - though your editor has heard from Mr. Krstić that it will be based on Linux-VServer. The "file store service" is described as a sort of object-oriented database for documents, "similar in very broad terms to the Microsoft WinFS design". All access to files from programs goes by way of a user dialog; there should be no way for a program to modify files outside of its own scratch area without the user knowing about it. There is also an optional anti-theft mechanism:
It works by running, as a privileged process that cannot be
disabled or terminated even by the root user, an anti-theft daemon
which detects Internet access, and performs a call-home request --
no more than once a day -- to the country's anti-theft servers. In
so doing, it is able to securely use NTP to set the machine RTC to
the current time, and then obtain a cryptographic lease to keep
running for some amount of time, e.g. 21 days. The lease duration
is controlled by each country.
If a machine has been reported as stolen, the "anti-theft server" will instruct it to shut down hard and go back into the deactivated state. The same thing will happen eventually if the stolen system is kept isolated from the net. This mechanism should help to deter thefts; one can only hope that it is sufficiently well designed that nobody figures out how to trigger it as a denial of service attack. The phone-home feature can be disabled - but only in the presence of a developer key. One feature which will not be built into the laptops is filesystem encryption. The CPU in the OLPC XO laptop is simply too slow to perform that task without bogging down the system entirely. This issue will be reconsidered in the future. The OLPC developers have also explicitly decided to stay out of the content-filtering business. In summary, the security model developers have this to say:
[W]e believe we've imbued the OLPC security system with cunning and
more magic art than other similar works of craftmanship -- but not
for a second do we believe we've designed something that cannot be
broken when talented, determined and resourceful attackers go forth
harrying. Indeed, this was not the goal. The goal was to
significantly raise the bar from the current, deeply
unsatisfactory, state of desktop security.
If the implementation lives up to the specification, chances are that the project will have achieved that goal. The OLPC platform is an ambitious experiment from beginning to end, and its developers have, once again, not wasted the opportunity to do something interesting with it. If the security ideas incorporated into the OLPC systems work out as desired, it would not be surprising to see at least some of them adopted by other desktop environments. This could be another case where the OLPC project creates benefits for a large group of people beyond its immediate target. (Log in to post comments)
Bitfrost: the OLPC security model Posted Feb 7, 2007 21:32 UTC (Wed) by NAR (subscriber, #1313) [Link] the ability to modify the core software on the system. This privilege is normally off, and cannot be enabled without a special developer key.The DRM-clause in GPLv3 wouldn't forbid a feature like this (when the developer key is not distributed)? I guess it's not a problem, because that core software is not under GPLv3, so it's just a theoretical question.
Bitfrost: the OLPC security model Posted Feb 7, 2007 22:08 UTC (Wed) by cjb (guest, #40354) [Link] > The DRM-clause in GPLv3 wouldn't forbid a feature like this (when the developer key is not distributed)?
The GPL is a promise to supply the source on demand, and the Bitfrost scheme involves promising to supply the developer key to each user on demand -- seems entirely reasonable to me.
- Chris.
Bitfrost: the OLPC security model Posted Feb 8, 2007 6:05 UTC (Thu) by bronson (subscriber, #4806) [Link] I don't think so... I remember the FSF shooting this down a few months ago. The example used was, what if Tivo releases a developer key as a substitute for releasing their private key? Without the same key, there's no guarantee of the same rights. I did some googling but can't come up with the article so take this with a grain of salt.
The first draft even suggested that if hardware requiring a private key was found in the wild, the private key must be made public. Luckily that was softened in the second draft.
The final GPLv3 is due in March... That's coming up awful soon.
Bitfrost: the OLPC security model Posted Feb 8, 2007 6:16 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] however, this would only apply if the BIOS or the system software gets released under the GPLv3 without also being available under the GPLv2.
and since the core system software is written by the OLPC project, they wouldn't be stupid enough as to license it under a license that conflicts with their other goals.
Bitfrost: the OLPC security model Posted Feb 8, 2007 7:38 UTC (Thu) by bronson (subscriber, #4806) [Link] But the OLPC is one of the most free computer projects ever undertaken. What if the GPLv3 can't be used for its low-level (read: important) parts? Isn't that a pretty bad sign?
This appears to be one situation where DRM can actually be a good thing. Like a knife or a car or a programming language, it's all just technology. People will use it for good and they will use it for bad.
That's why the FSF's "DRM is EVIL!!" stance is so foreign to me. It's like calling gunpowder evil.
Bitfrost: the OLPC security model Posted Feb 8, 2007 12:47 UTC (Thu) by drag (subscriber, #31333) [Link] With my infinate ignorance it seems here that the difference is allowing the owner/handler of the device greater control over it versus attempting to remove control from a owner and give it to a third party.
I wouldn't nessicarially call it 'DRM'. It certainly uses features that mirror what is used in DRM, but it's goal/purpose is different. Similarly how I wouldn't consider a signature on a E-mail DRM.
The only problem I see is that it's probably going to make the system much harder to hack around with versus if it was more PC-like. To bad there isn't a positive way to identify users and key the machine to them, like through voice recognition or fingerprint or something like that. I don't suppose something like that is reasonable for a machine like this.
Bitfrost: the OLPC security model Posted Feb 8, 2007 14:28 UTC (Thu) by NAR (subscriber, #1313) [Link] It certainly uses features that mirror what is used in DRM, but it's goal/purpose is different.This feature is basically "the hardware doesn't run the code if it's not signed". Which is good, when it disables working around the anti-theft code in the OLPC, but which is bad, when disables creating graphics card drivers that dump their output into a file (to copy a DVD, etc.).
Bitfrost: the OLPC security model Posted Feb 8, 2007 18:26 UTC (Thu) by bronson (subscriber, #4806) [Link] The OLPC uses a private key to restrict the rights of the computer's owner. How can you not call this DRM?? It's exactly the same thing!
I'm not exactly clear on just who will own these devices: the student, the student's parents, the school, or the state? If the state keeps ownership of all the computers for itself, and just loans them to kids for a year at a time, would the GPLv3 still force the release of the private keys?
Would the answer change if they loaned them to random kids for an hour at a time rather than one kid for a year at a time?
Bitfrost: the OLPC security model Posted Feb 8, 2007 19:29 UTC (Thu) by cjb (guest, #40354) [Link] The OLPC uses a private key to restrict the rights of the computer's owner. How can you not call this DRM?? It's exactly the same thing!It is DRM. However, GPLv3 doesn't say no-one can implement DRM, it says that if you implement DRM you must also make the key available so that the computer's owner has the freedom to turn off the DRM if they want to. That's what OLPC is doing, so it's all good. I'm not exactly clear on just who will own these devicesI think the plan is that the devices are for the children to keep, even after they finish school.
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:18 UTC (Thu) by bronson (subscriber, #4806) [Link] I'm not sure I buy that. If OLPC gets to do this, couldn't Tivo do the same thing?
Why doesn't Tivo set up a restricted developer program? The customers who really want can jump through hoops could get themselves a developer's key. Like OLPC, developers keys will be quite hard to come by. The vast majority of people won't know, won't bother, or won't qualify.
Is Tivoization possible under the GPLv3 after all?
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:50 UTC (Thu) by drag (subscriber, #31333) [Link] And they wouldn't care either. Most people who own TiVOs don't care, and if I owned a TiVO I probably wouldn't care much either.
As long as they make the 'developer keys' (or equivelent) aviable to end users then that's all that matters. If they make significant barriers to this then that could be construed as a violation, but it's not like they have to make it easy for you either.
I'd say it would be reasonable to require you to call Tivo and provide some sort of proof (say a UUID number on the bottom of the case) that the device belongs to you and then they'll mail you a key on a cdrom or whatever for 5 bucks or whatever reasonable to cover their costs.
There is no reason why they would have to provide keys to all Tivos, just the ones you own.
And the reason I originally said it's not 'DRM' is because DRM is designed to restrict a person's rights in regards to copyrighted material. If this is DRM, then setting file permissions on your home folder is DRM also. Implimenting filesystem encryption is DRM also, then.
If you want to make the definition so broad to encompas everything then I suppose you can call any sort of security measure DRM if you want to.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:04 UTC (Thu) by bronson (subscriber, #4806) [Link] And the reason I originally said it's not 'DRM' is because DRM is designed to restrict a person's rights in regards to copyrighted material.Exactly like the OLPC BIOS. If this is DRM, then setting file permissions on your home folder is DRM also. Implimenting filesystem encryption is DRM also, then.Neither of those scenarios involve an upstream party using private keys (or other technology) to inhibit your enjoyment of a product that you rightfully own. I don't see how they could be considered DRM.
Bitfrost: the OLPC security model Posted Feb 9, 2007 7:22 UTC (Fri) by man_ls (subscriber, #15091) [Link] Exactly like the OLPC BIOS.Not really. The OLPC doesn't prevent access to copyrighted material; it shuts down the machine and turns it into a brick. Not even close. Neither of those scenarios involve an upstream party using private keys (or other technology) to inhibit your enjoyment of a product that you rightfully own. I don't see how they could be considered DRM.I don't see how you can call Bitfrost "DRM" when there is no copyrighted material and no digital "rights" to manage. DRM is not "using private keys to inhibit enjoyment of products", it involves limiting access to certain files. Drag's example (setting permissions on a directory) is actually closer to DRM than OLPC's Bitfrost, IMHO.
Bitfrost: the OLPC security model Posted Feb 10, 2007 8:01 UTC (Sat) by bronson (subscriber, #4806) [Link] DRM can be used with anything, not just copyrighted content (according to http://www.defectivebydesign.org/en/about anyway). When the OLPC turns into a brick, isn't that awfully similar to a DVD refusing to decript its content or a Vista computer refusing to run an executable? Sure seems it to me.
And both DRM and Bitfrost are very dissimilar to chmod a-rw ~/. Directory permissions don't involve a 3rd party, DRM and Bitfrost do, chmod a+rw ~/* undoes the damage; DRM and Bitfrost don't have any such exit, etc. Shall I continue?
I guess we'll just have to agree to disagree on this one.
DRM vs TM Posted Feb 10, 2007 10:21 UTC (Sat) by man_ls (subscriber, #15091) [Link] As the linked page takes pains to explain, DRM can be based (on computers) upon "Trusted Computing", which Stallman mimics as "Treacherous Computing". You are saying that DRM can be used for anything (and is indeed used on the OLPC), when in fact it is TM that you are speaking about. It seems like a pedantic point, but it is important for the discussion not to mix these concepts IMHO.TM can be a chip used by the kernel with cryptographic keys under the control of the owner, in which case it can be a good thing. The keys can also be under the control of a third party, which is a disaster. In the case of the OLPC it can turn into a brick. As it is a government-sponsored program anyway, I guess they have thought about it: if it gets disabled by mistake, you can always take it to a hypothetic repair service. I personally don't like the idea, and think it is a weak point in the whole scheme, but inexplicably nobody asked me before implementing it ;) DRM, as one of its main peddlers has just said, is always a bad idea. Notice that, in the case of a DVD player you don't even need TM, as it is a closed platform anyway; in this case the device can simply have its keys revoked and it will refuse to play protected content, which is different than turning into a brick. When it is a computer in disguise you need complicated schemes such as TM to make the device obey its true master, the manufacturer.
DRM vs TM Posted Feb 10, 2007 20:03 UTC (Sat) by bronson (subscriber, #4806) [Link] TC is now such a broad concept that it's nearly useless. The wikipedia page does make it sound like both Bitfrost and drectory permissions would fall under the TC umbrella. But so would AppArmor. And hardware virtualization extensions. That doesn't mean they have anything in common with each other.We can at least agree that FairPlay, CSS, and Microsoft's incompatible flavor du jour are examples of DRM, yes? defectivebydesign says that Tivoization is a form of DRM. And Hasp HL claims to be DRM. Bitfrost's ultimate behavior is basically the same as these technologies and has only the most superficial resemblance to directory permissions. That's why I really don't think it's a stretch to consider it DRM. Maybe you could point me to an authoritative definition of DRM? The definition at the top of the Wikipedia entry clearly includes Bitfrost but, alas, I'd hardly call it authoritative. Perhaps the media is subverting the meaning of DRM like it did with hacker? At this point, though, I'm afraid the cat's pretty far out of the bag.
DRM vs TM Posted Feb 10, 2007 20:27 UTC (Sat) by bronson (subscriber, #4806) [Link] ...*not a stretch* to call [Bitfrost] DRM. Gah.
DRM vs TM Posted Feb 10, 2007 23:01 UTC (Sat) by man_ls (subscriber, #15091) [Link] I would say that Trusted Computing is a well defined concept, or at least it was until vendors started marketing it. OTOH DRM was always snake oil, and still is today. Maybe that is why authoritative definitions are hard to find. Look at this one (in PDF):Digital Rights Management (DRM) is a system to protect high-value digital assets and control the distribution and usage of those digital assets.It comes from an academic paper, but the "high value" part is not very objective: DRM can also be used for low-value garbage. As to the examples you cite: Tivoization is a form of DRM only because it is used to protect digital content (digitized TV in this case). The article in Dr Dobb's Journal talks about protection of content and restriction of document distribution. Even if the press and the general public misuse the term, that is IMHO no excuse for spreading bad usage. DRM protects content by whatever means, even if it's just a remotely controlled daemon setting directory permissions. After all, Adobe's protected PDF's rely on something like a bit set on a file.
Bitfrost: the OLPC security model Posted Feb 8, 2007 20:51 UTC (Thu) by cjb (guest, #40354) [Link] I'm not sure I buy that. If OLPC gets to do this, couldn't Tivo do the same thing?Remove their restrictions by bundling an offer to supply a developer key that gives you complete access to the machine if you want it? Sure, they could, and they'd be GPLv3-compliant by my interpretation if they did. They presumably won't, because they don't want you to be able to (for example) use a public source of TV listings and stop paying them for monthly service. The vast majority of people won't know, won't bother, or won't qualify.No, if you've bought the device, it would be a breach of GPLv3 to not give you the key on request. A "restricted" developer program wouldn't suffice. (But no-one's suggesting the OLPC program will be restricted.)
Bitfrost: the OLPC security model Posted Feb 8, 2007 22:52 UTC (Thu) by bronson (subscriber, #4806) [Link] Of course the OLPC program is restricted.
From the article: "in general, the children will not have that functionality available to them."
From our editor's comment: "There is a delay built into the developer key mechanism; if the laptop is reported stolen during the wait, no key is issued."
This makes total sense. If there really were no restrictions, there would be no point to making the keys private in the first place. The thieves would just request the keys after they'd stolen the laptops.
I've read the v3 draft a few times. You'll notice that 6.3b doesn't specify any durations. How long could Tivo delay issuing a key before It's in violation? A few months? A year? And could Tivo pull the old tape trick used by a number of BSDs in the early 90s? (charging $400 for a $30 tape claiming "it's a reasonable cost of physically performing this conveying of source. Go ahead, take us to court -- it'll cost you a lot more than $400!")
From reading the license, it seems to me like they could.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:56 UTC (Thu) by cjb (guest, #40354) [Link] From the article: "in general, the children will not have that functionality available to them."This doesn't mean that developer keys will be refused to some children, it means that before the child asks for the key, the (BIOS-writing) functionality won't work. I've read the v3 draft a few times. You'll notice that 6.3b doesn't specify any durations.The Bitfrost spec (section 8.19) says that the delay between asking for and receiving the key will be fourteen days. That seems entirely consistent with the delay one would expect from replying to a written offer of source code under the GPL that we've been using for the last twenty years. I'm only really interested in talking about this to the extent of showing that the scheme is entirely in accord with GPLv3 and the spirit of the GPL. If your problem is that the GPL isn't free enough for you, you need to find some other people to talk to. :)
Bitfrost: the OLPC security model Posted Feb 9, 2007 2:34 UTC (Fri) by bronson (subscriber, #4806) [Link] I'm genuinely interested. I still don't understand how the GPLv3 can allow the OLPC to use DRM and at the same time prevent Tivo from abusing it. That's why I was asking about known modes of GPL abuse from the past. There will always be people who want to skirt the rules.
I *like* the GPLv2, and presumably I'll like the v3 when it ships. Ideally I'd like v3 to be able to be the go-to license for most projects. Other than the DRM language, which I'm unsure about, it looks like v3 could be that license.
Of course, I'm happy to let our discussion rest here and leave any further fine slicing to future litigators. :)
Bitfrost: the OLPC security model Posted Feb 9, 2007 2:49 UTC (Fri) by cjb (guest, #40354) [Link] I'm genuinely interested. I still don't understand how the GPLv3 can allow the OLPC to use DRM and at the same time prevent Tivo from abusing it.So, my understanding is that the GPLv3's answer to DRM is to say "Sure, you can build DRM -- after all, you wouldn't have freedom if you couldn't -- but you must give the person who you distribute the code to the freedom to remove the DRM if they wish". That's what Bitfrost tries to do. How do you think TiVo would claim to be following that, yet abusing it? The methods you mentioned (waiting too long, or charging too much) just aren't ones that we've seen people abuse over the last twenty years; I can't think of a single memorable example of either, so it certainly hasn't been common. If they *do* provide the source+key that gives you full control of the system in a timely manner, then it's Free Software.
Bitfrost: the OLPC security model Posted Feb 9, 2007 11:56 UTC (Fri) by NAR (subscriber, #1313) [Link] you must give the person who you distribute the code to the freedom to remove the DRM if they wishI think I get it - the code is distributed to the child, but not to the thief, so the thief can't ask for the key. However, an other thing occured to me. As far as I know, the children can't sell or give away their laptops, i.e. can't distribute it (I could be wrong here). Can they distribute the software (including the OpenBIOS) on the laptop? GPL (even v2) gives them the right, but will the software work on any other laptop (even if they distribute the key, which is part of the software under GPLv3)?
Bitfrost: the OLPC security model Posted Feb 8, 2007 21:04 UTC (Thu) by cjb (guest, #40354) [Link] By the way, feel free to read the GPLv3 (draft) itself. It makes it clear that the key needed to change the Program is part of the Corresponding Source, and that it is valid to supply an offer to provide the Corresponding Source on request, rather than directly bundling the Corresponding Source with the Program itself.
Bitfrost: the OLPC security model Posted Feb 8, 2007 22:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] I think lots of people agree that it's a bad sign, everyone is split between
1. it's a bad sign for the GPLv3
and
2. it's a bad sign for the OPLC project
by the way, to throw a little gasoline around here, who is the 'owner' of these things, the govenments who pay for them, or the child who takes it home each night?
if it's defined as being the govenments who pay for them then all these requirements are within the limits of the GPLv3 as the owner of the devices has all the nessasary keys.
Bitfrost: the OLPC security model Posted Feb 11, 2007 17:49 UTC (Sun) by JohnNilsson (guest, #41242) [Link] Does the GPL really care about "owners"? It only mention "users". I would think even a theif would qualify as a "user".
Bitfrost: the OLPC security model Posted Feb 8, 2007 6:35 UTC (Thu) by drag (subscriber, #31333) [Link] ""I don't think so... I remember the FSF shooting this down a few months ago. The example used was, what if Tivo releases a developer key as a substitute for releasing their private key? Without the same key, there's no guarantee of the same rights. I did some googling but can't come up with the article so take this with a grain of salt.""
I beleive that is a bogus arguement. It either gives you the ability to run modified code with no loss of functionality or it doesn't. As long as it does, then that's it as far as the GPLv3 is concerned. There is absolutely no requirement in the GPLv3 for developers to release any private keys, they just have to provide the ability to allow users to run modified code with no loss in functionality if the original makers themselves can do so also.
Garrentees be damned. If there is a question of violation then obtaining a "developer's key" and using it to load modified code and testing the functionality is all that would be needed to prove compliance.
Plus with this design even the BIOS can be swapped out with the developer's key, so the BIOS itself could be licensed GPLv3 if you felt like it.
Bitfrost: the OLPC security model Posted Feb 8, 2007 14:13 UTC (Thu) by NAR (subscriber, #1313) [Link] There is absolutely no requirement in the GPLv3 for developers to release any private keys, they just have to provide the ability to allow users to run modified code with no loss in functionality if the original makers themselves can do so also.So the developers would have to give me a key, which enables me to run the modified code - even if the modification means that I've removed the anti-theft features like the "calling home" thing. Which would brake the whole anti-theft concept. Or is there something I'm missing?
Bitfrost: the OLPC security model Posted Feb 8, 2007 16:07 UTC (Thu) by nix (subscriber, #2304) [Link] I see what you mean: what stops thieves contacting the developers and asking for a developer's key? (Equally, what stops crooked bureaucrats diverting the identity USB keys at the same time as they divert a bunch of laptops?)
Bitfrost: the OLPC security model Posted Feb 8, 2007 16:11 UTC (Thu) by corbet (editor, #1) [Link] There is a delay built into the developer key mechanism; if the laptop is reported stolen during the wait, no key is issued.
Bitfrost: the OLPC security model Posted Feb 8, 2007 23:03 UTC (Thu) by drag (subscriber, #31333) [Link] Also I presume that they would take steps to confirm your identity so that they are issuing a key to a laptop to the person that is actually suppose to have the laptop. (I don't think 'theft' would constitute 'distribution' under the GPL)
Sort of like how if you work in a corporate setting and somebody calls you up asking for (or to reset and replace) a password they 'forgot' you would want to take a bit of time to try to confirm the identity of the person on the other side of the phone before issuing the password.
Bitfrost: the OLPC security model Posted Feb 9, 2007 10:29 UTC (Fri) by tzafrir (subscriber, #11501) [Link] Are those developer keys different from system to system?
If not: all you need is one leaked key.
Once you get a hold of such a device, you ditch the original (limited) software, and replace it with an unlimited software.
How come this is not possible, and not simple to do automatically?
Developer keys Posted Feb 9, 2007 14:01 UTC (Fri) by corbet (editor, #1) [Link] Yes, each system has a unique developer key.
Bitfrost: the OLPC DRM model Posted Feb 8, 2007 1:28 UTC (Thu) by ikm (subscriber, #493) [Link] All that scheme felt quite like a Hollywood-DRM-crippled scenario to me. In no way it represents a machine that is completely open to hack on it -- quite the opposite, really. It's the "kids are dumb and grown-ups are cruel" model, and while that may well be true, it's not what was promised. This is NOT an open machine, at least without that obnoxious developer key to remove all that cripple. If I was a kid with that machine, I would absolutely hate the requirement to presumably prove something to somebody to be able to hack my machine. Instead of all that, it would be better to just think of an easy way to quickly restore the machine at school in case a kid breaks it.
Bitfrost: the OLPC DRM model Posted Feb 8, 2007 2:28 UTC (Thu) by zlynx (subscriber, #2285) [Link] I got something different out than you did, I think. To my reading, the system protects the BIOS but the running image can be modified.
So that's exactly what you want...do any programming you like and when you screw it up completely, reset and it all goes back to normal.
Bitfrost: the OLPC DRM model Posted Feb 8, 2007 2:35 UTC (Thu) by krstic (guest, #41011) [Link] That's exactly the correct reading.
Bitfrost: the OLPC DRM model Posted Feb 8, 2007 2:58 UTC (Thu) by ikm (subscriber, #493) [Link] I was talking about an open system, one that is transparent and free to modify in any way. The one described is not. It's crippled with signatures and keys, has a phone-back, user id disclosure and self-degradation functionality -- all what is commonly disliked in all the recent Hollywood developments. I can understand what all of this is for, but I don't like what I see.
OTOH, all a kid needs is a solid family, hospitality and freedom, not some computer junk. I only worry about freedom here, really.
Bitfrost: the OLPC DRM model Posted Feb 8, 2007 6:19 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] two thoughts come immediatly to mind
1. Ok, if their approach is flawed, suggest something better that meets the goals.
2. if you can't (and frankly I can't think of any way to be as 'open' as you want while implementing the needed protection) then this just emphisises the fact that it's not the technology that's evil, it's the use that the technology is put to, and so any attempt to outlaw the technology (either by governments or by licenses) is wrong
Bitfrost: the OLPC DRM model Posted Feb 9, 2007 1:49 UTC (Fri) by ikm (subscriber, #493) [Link] What ARE the goals? Making the machine unusable for unwanted people makes the machine not quite usable for legitimate users, too. That's exactly what Hollywood has been doing for some time now -- trying to make their movies unusable for thieves, but usable for customers. Usually it's the legit users who suffer. Thieves can always figure out how to steal, but normal people are clueless when suddenly something goes down...
Also note that having a developer key on a machine suddenly turns all of the currently proposed protection down, which makes me think that the bulk of the machines are not supposed to have ones. I still somehow think that it would be hard to get one.
Ok, now about suggesting something better... I think the right way is to use biometrics, with no possibility to change the user id without the help of the administration. This way, the machine belongs to a kid, and to nobody else. And it should be possible to change everything else in system if one really wishes, with an easy way to restore at school.
I can understand that adding a fingerprint sensor adds a buck or two, though. But in any way I am against the no-modify/phone-back/self-id/degrade approach, if the owner can't turn it off of course.
Bitfrost: the OLPC DRM model Posted Feb 9, 2007 4:53 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] but if the user doesn't have the right to bypass the biometric authentication it's still not completely free.
so this won't prevent theft, try again
Bitfrost: the OLPC DRM model Posted Feb 9, 2007 14:03 UTC (Fri) by ikm (subscriber, #493) [Link] Yes, that part will be closed for modifications. What matters is that it would work for a user, not for a remote party. And it will prevent theft. That's what only matters, really.
Bitfrost: the OLPC DRM model Posted Feb 9, 2007 4:59 UTC (Fri) by gjmarter (subscriber, #5777) [Link] It sounds to me like there is only one requirement to get the developer key that allows certain protections built into the computer to be disabled. You have to wait 14 days so that they can be sure that the laptop is not stolen.
Bitfrost: the OLPC DRM model Posted Feb 9, 2007 9:47 UTC (Fri) by drag (subscriber, #31333) [Link] That's what it seems like.
They stated the goal is to eliminate the chance of people making of with 'pallets' of laptops. I take that to mean you don't want people to hijack a shipment or bribe their way into a position were they obtain large numbers of laptops all at once in a attempt to get them for sale on the black market.
So the bitfrost is designed to prevent theft by requiring the developer key. Sure you could probably steal one or two laptops and get them unlocked, but you couldn't probably steal a few hundred unless you have the help of part of the government that is suppose to be the ones in charge of distributing them.
Phoning in 20-30 laptops at a time is a easy way to get busted very quickly. I figure you wouldn't be able to get even a sizable minority of them unlocked before they bricked themselves.
Then the second half is malware prevention, of course. Prevent people from tampering with the Bios and spreading effective viruses/worms to attack a 'monoculture' of these laptops similar to the botnets we have now of Windows XP machines.
Plus it pretty much allows people to muck around with the machine as much as they'd like and not have to worry about perminately brick them, unless they spring for the developer key (which would open them up to potential malware, theft, or bad bioses. But assuming people only interested in the key are people that are going to more or less know what they are doing, then it shouldn't be a big deal)
That is, of course, if it's only requirement is a 'phone home'. There could definately be a big hunk of Bitfrost that I don't know/understand or am glossing over in my ignorance.
The Difference Posted Feb 8, 2007 7:07 UTC (Thu) by orospakr (guest, #40684) [Link] To preempt all those who will try to compare this system to a Treacherous Computing/DRM system, I offer this simple distinction:
Treacherous Computing systems, such as those used in many proprietary systems such as video game consoles, work for someone other than the owner of the computer. Not only is this morally wrong, but it also is based on a fundamentally flawed threat model: the person who owns the machine can theoretically do anything she likes to the machine, and therefore Treacherous Computing systems are very often cracked. A classic example of this is a so-called "modchip" for a video game console, for instance. Cryptography buffs sometimes describe TC/DRM as attempting to make Alice and Eve the same person (do I remember those names correctly?).
Bitfrost works for the owners of the machine (in this case, the child and her country). The flaw discussed above does not apply, because the owner of the machine is still permitted to do as she likes. Bitfrost instead is intended to allow the user to get on with her business, including running untrusted code from a third party without worry.
(actually, the theft protection scheme in Bitfrost could be considered a theoretical weak point. A modchip-like device or similar hack could possibly be used to disable the anti-theft protection. However, this is unlikely to be feasible in practice. Therefore, the theft protection system has done its job: deterring theft.)
The Difference Posted Feb 8, 2007 7:52 UTC (Thu) by drag (subscriber, #31333) [Link] Well that is why stuff like TPM can be very good. It has the capability of giving over more control to the end user to fend off malicious code and attackers.
For example kernel mode rootkits.
Lets say you have TPM on the motherboard. It has some keys in itfor something like the signed key of the 'trusted grub' bootloader.
The system boots, TPM stuff is activated and tests grub binaries and grub's key cache. If they are swell then it's executed. Grub then uses it's key stash to validate the kernel and initrd. Those are brought up, executed and ran.
They have their own keys to keep track of the kernel modules and test them before loading them. And also probably will test the validity of various important system files and configurations.
Currently, with no TPM or similar technology, there is no possible way to ever ever use something like 'root kit hunter' (or any anti-rootkit software) and trust anything it tells you about the safety of your system.
The only practical way to do that sort of thing now is to take the machine offline, use something like Tripware from a different boot medium to take checksums of your system and store that in offline or read-only storage. Then you can later take down the machine and re-run the checksums to confirm the purity of your binaries. But if you can be sure that your kernel is pristine and that all the drivers are safe.. then you can effectively combat rootkits while your system is running. As long as the running kernel is safe from exploits then TPM can raise the security and trustability of your system to new heights.
If you end up with machines that can do things like test code as it's being executed then you can potentially even trust kernels that may have a local vunerability in them.
It all depends who has the keys. If you have the keys, as the owner.. Then TPM is wonderfull. If you don't have the keys and somebody else has more control over your system then you do, then TPM sucks majorly.
The challenge with this Bitfrost is to come to happy solution were you can prevent the theft of laptops, and use 'trusted computing' type features to secure the userspace from softare vunerabilities, while still allowing end users (the children) the freedom to modify their systems.
If Bitfrost works out then this can be a huge selling point for Linux desktops. If it can be applied to something like a corporate desktop environment were you can allow things like password-less (or at least be not so dependant on passwords) user identity management, simple PKI infrastructure, per-user VM (with efficiency!), etc etc. Then this can be huge attraction for Linux desktop adoption for some people.
How well could this Bitfrost can be applied to increasing the security of corporate or home desktop systems?
The Difference Posted Feb 8, 2007 7:53 UTC (Thu) by drag (subscriber, #31333) [Link] Or something like LTSP?
The Difference Posted Feb 8, 2007 19:35 UTC (Thu) by cjb (guest, #40354) [Link] (actually, the theft protection scheme in Bitfrost could be considered a theoretical weak point. A modchip-like device or similar hack could possibly be used to disable the anti-theft protection. However, this is unlikely to be feasible in practice. Therefore, the theft protection system has done its job: deterring theft.)Rather than being a weak point, I'd just call this something that isn't covered by the threat model. The worries that motivated the security system came from (for example) the possibility of someone writing a virus that bricks the BIOS on all n-hundred-million laptops at once, making them useless. Reducing that risk to the possibility of breaking the security on one laptop at a time, by disassembling it and resoldering the BIOS, is a huge step forward.
The Difference Posted Feb 9, 2007 1:57 UTC (Fri) by ikm (subscriber, #493) [Link] > Bitfrost works for the owners of the machine
Yes, until the owner would want to turn it off. And then it suddenly starts to work against his wishes.
potential for abuse Posted Feb 8, 2007 7:17 UTC (Thu) by grouch (guest, #27289) [Link] The anti-theft mechanisms (both the activation one and the "optional" one) have tremendous potential for abuse by repressors. Instead of phoning home, can the OLPC be required to take the child's photo at intervals to confirm it has not been stolen?It seems to me that it would be better to rely on a mechanism where the machine confirms its owner than to rely on reporting to a remote entity. The owner may be presumed to have his or her best interests at heart. If the remote entity has the power, even by lack of confirmation, to disable the OLPC, that remote entity is the owner of the machine. Is the goal to provide ownership of one laptop per child, or conditional loan?
potential for abuse Posted Feb 9, 2007 2:09 UTC (Fri) by ikm (subscriber, #493) [Link] > If the remote entity has the power, even by lack of confirmation, to disable the OLPC, that remote entity is the owner of the machine.
Absolutely.
potential for abuse Posted Feb 9, 2007 4:55 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] which is why bifrost shuts down the laptop after some period of not being able to phone home.
potential for abuse Posted Feb 9, 2007 10:22 UTC (Fri) by tzafrir (subscriber, #11501) [Link] A device that shuts itself if it cannot phone home may not be a good idea: China Loses Over 9,000 Domain Names in Earthquake.
potential for abuse Posted Feb 9, 2007 11:06 UTC (Fri) by k8to (subscriber, #15413) [Link] Yes, but the OLPC is designed to create its own network.
In the case that the central authority itself goes away for 21 days, the fact that OLPC systems also shut down probably will not help, but will not be a big problem compared to some.
potential for abuse Posted Feb 9, 2007 12:00 UTC (Fri) by tzafrir (subscriber, #11501) [Link] A major communication cable going down can actually cause this.
Going to a different part of the country for a month with your laptop can also brickify it.
And a malfunctioning network adapter will also brickify your device.
potential for abuse Posted Feb 15, 2007 13:07 UTC (Thu) by arcticwolf (guest, #8341) [Link] Aren't these machines supposed to use some form of ad-hoc wireless mesh networking? Communication cables going down shouldn't be a huge problem, one would hope.
Bitfrost: the OLPC security model Posted Feb 8, 2007 19:18 UTC (Thu) by iabervon (subscriber, #722) [Link] It seems like these machines are actually owned by the government or the school department, rather than the children. Which is fine, really. When I was a schoolchild, my school owned the textbooks I used. So this is really a scheme by which the owner of a laptop can secure it in certain ways and to a certain extent against people who have physical access to the machine.
I assume that these devices will have to be returned by their users once they aren't children any more. If nothing else, the users will need a phyiscally larger interface eventually.
Bitfrost: the OLPC security model Posted Feb 10, 2007 1:59 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Nothing is entirely owned by one person. Lots of people have varying kinds and degrees of ownership interest in anything. These machines are owned to a large degree by the user. It's to a lesser degree than a computer one of us might buy for personal use, but to a larger degree than a computer issued to us by our employer.In property law, one of the most important ownership interests is the right to use and exclude others from using the item. The OLPC users seem to have a pretty strong one of those rights. (Incidentally, that's why in real estate, a tenant is more of an owner than a landlord, even though we conventionally call the landlord the "owner.")
Bitfrost: the OLPC security model Posted Feb 15, 2007 13:10 UTC (Thu) by arcticwolf (guest, #8341) [Link]
Which country's laws are you talking about, specifically? Without wanting to comment on the question of who will be (or, for that matter, *should* be) considered the owner of the laptops, it seems like a bad idea to me to argue based on "the law" when there is not actually such a thing as "the law", but rather a host of different kinds of legal systems with different laws. How much DO you know about property law in, say, Brazil, China, India or Rwanda?
Bitfrost: the OLPC security model Posted Feb 16, 2007 3:25 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Yes, there's no such thing as "the law," and if you look carefully, you'll see I don't refer to "the" law. I'm talking about property law in general -- it's a matter of jurisprudence, not the law of any particular jurisdiction.The reason I'm speaking so generally is that this thread isn't concerned with the legal aspects of owning these laptops; it's about a more abstract idea of ownership, as in the idea some people have that if you "own" a computer, you should be able to run whatever software on it you want. I brought up property law as an example of how ownership isn't as simple as many people seem to think it is. While governments implement various rules with respect to ownership, lawyers broadly agree on the underlying concepts.
Repressive government Posted Feb 8, 2007 19:42 UTC (Thu) by kamil (subscriber, #3802) [Link] I don't really see the need to register these laptops as much of a problem. After all, "truly free communications without fear about who might be listening" is hardy a concern for small children.
I see the microphone and the camera, and the fact that the network is always on, as more of a problem. Children will be bringing these laptops home, so there is a threat that a repressive government could use them to spy on children's parents and their guests. It's good that OLPC plans to put a LED that indicates when the microphone is on; let's hope it will be enough...
|
|||||||||||||