Re: A _good_ and valid use for TPM
On Sun, Feb 22, 2009 at 03:02:43AM +0200, Alex Besogonov wrote: > Robert Millan wrote: >>> Private part of the endorsement key _never_ leaves the device (if >>> manufacturer uses the recommended TPM_CreateEndorsementKeyPair >>> method). Even device manufacturer doesn't know it. >> Even if that is true (which I doubt), it's merely incidental, because... > It's not really incidental. TCG was initially started as a group to > develop trusted computing platform. MS later tried to hijack it to > realize their wet dream of locked-down computer. Well, sounds like either the hijack was succesful, or the wet dream was shared. >>> Public key is then >>> signed by manufacturer's certificate. This ensures that the private >>> key can't be compromised. >> ...this ensures that $evil_bob can challenge you to prove you're running >> his proprietary anti-user software. > So I won't be able to answer $evil_bob challenge in any case, since I'm > mostly running Linux now. That depends on what he considers trusted. The capabilities are there and got merged in Linux tree. And who's scared of Vista anyways? ;-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 09:10:11PM -0500, Isaac Dupree wrote: > > (warning, I accidentally wrote a long essay exploring when these TPM-like > things are evil) > > Okay, suppose we use this means to make them not-so-evil: "Buyer gets a > printed copy of the TPM's private key when they buy a board." I'll call them > "(pseudo)TPMs" when they meet GNU demands. (They could be built with Free > software, openly specified hardware designs, etc... why not throw in a bonus > :-)) > > Alex Besogonov's use case is still possible. Which should make us suspicious > of whether our moral problem is solved. I don't think there's anything morally wrong with Alex' use case, although it's not technically unreplaceable either. > I think my question is: how essential is it that individual people should > (always? usually?) have an easy time taking apart their computers, putting > them back together, and changing them, and having them behave as "black > boxes" > to the outside world. Note that our concern is software, not hardware. Your microwave oven is probably a computer too, and it's not a serious problem that it's locked down and you can't change its software (that would be really dangerous!). However, if your free programs, which you run on unlocked hardware, suddenly stop working because they have to interact with third parties (e.g. a web server) who now demand you use the "Trusted" version, you lose the ability to modify them, which is one of your basic freedoms. > I think that we can understand these issues better when we actually have > access to Free software (including BIOS) that implements a crypto stack to > lock down a computer, on relatively Free hardware designed with some physical > security (which is obviously possible, just as the mini-computers called TPMs > are designed with some physical security). Whole computer becomes analogous > to TPM in its ability to hide keys etc. -- except that it can be unlocked. > Then the issues go back to ones we've been dealing with for centuries, such > as > whether you should hide a spare key under the doormat in case something > happens to the one you normally carry. Ugh, alright, at least we're back in > the physical. Another interesting example are crypto cards. They are designed to hide keys, but they don't do any more than that. They serve their purpose of authenticating you to a third party, but can't spy on your memory, and can't coerce you into running a certain program. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sun, Feb 22, 2009 at 03:21:21AM +0200, Alex Besogonov wrote: > Robert Millan wrote: >>> Making sure, that noone can override it, can be awfully difficult, >>> especially >>> under a physical attacker. A hardware that is at least a bit designed to >>> withstand such an attack can help a lot. >> I'm not sure why is physical security so awfully difficult for you (can't you >> use locks, tamper-proof seals, cameras and alarms?), but most people who're >> in >> the bussiness of protecting physical goods manage to sort it out. > My devices will be installed at clients' locations. It's impossible to > guarantee that all devices will be physically secure. > > If you live in the USA then one day such device might contain your > private data. Would you like it to be stolen? My private data is safely stored. The stuff Google reads from my Gmail account is *not* private data. If you send your private stuff elsewhere and trust noone can read it because a small chip that's not even under your control told you so, you're being naive... > Reverse engineering the TPM chip is very costly. And I'm not going to > try to protect data from NSA or CIA or another three-letter agency. ...but thankfully, not as much as I thought. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sun, Feb 22, 2009 at 03:14:07AM +0200, Alex Besogonov wrote: > Jan Alsenz wrote: Yeah, but an attacker could patch that out too. >>> Not if we first measure the MBR. It can be done without any >>> TPM-specific code in the MBR if I'm not very mistaken. >> Could you elaborate on that? >> E.g. where do you measure the MBR from? > MBR is automatically measured by the TPM module, it requires no > intervention from GRUB. Well, that is true, but for GRUB to measure all of its own stages it gets quite complicated. Overall, from a technical POV it looks like a lousy approach. It makes a lot more sense to simply have the firmware load GRUB as an executable image and measure that IMO. You can do that easily when you're in a legacy-free environment. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Mon, Feb 23, 2009 at 03:34:56AM +0100, step21 wrote: > if there is one company that I think would try to lock their hardware > down as much as possible using something like a tpm, it's apple, but > they don't. You're looking at the wrong place. Check the iphone. Anyway, it's nice to hear TPMs are disappearing from desktops. I hope it's true. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sun, Feb 22, 2009 at 03:26:32AM +0200, Alex Besogonov wrote: > Robert Millan wrote: >>> It's exactly what I want to do (minus the 'coercing' part). I want to >>> ensure that devices run only my unmodified software (which I consider >>> secure) and only in this case provide decryption keys for sensitive >>> data. Of course, it done not for DRM purposes, but rather to protect >>> sensitive data from theft (real theft, not copyright infringement). >> There's no fundamental difference between hardening a device and using that >> as your root of trust and using someone else's hardened device and using >> that as your root of trust. > There's a difference. It's impossible to create the root-of-trust > without some hardware/firmware support. I assume you mean a root of trust that's not vulnerable to physical attack. Sure, you need firmware support, but you don't need to blindly trust someone else's firmware when you can use coreboot with GRUB as your firmware. >> The only differences are: >> - One more link in the trust chain (irrelevant). >> - Because it's _someone else's_ computer (the TPM), you're irrationally >> assuming that its security is flawless. > Security of TPM vendors is audited by a third party. For most practical > purposes it can be considered quite adequate. Adequate maybe, not flawless. And using your own concrete is still cheaper and more trustworthy than someone else's silicon :-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
2009/2/23 step21 : > This whole debate made read up a little bit on TPM, for example I > checked http://www.osxbook.com/book/bonus/chapter10/tpm/ > (osx book is a very nice resource for mac/os x system internals) > regarding tpms on apple hardware. > Now contrary to what some outdated resources/rumours say, at least all > newer intel mac don't include any tpm at all, the only thing that > definitely did contain one were the developer boxes that were shipped > to apple developer connection subscribers when the transition from ppc > to intel started. Also, I can confirm this for my macbook air, neither > the device tree inside os x or logic board photos from ifixit give any > indication of a tpm chip, also all sources that don't rely on rumours > confirm that apart from developer boxes intel macs don't contain one. > You might say, now, how is that important? Well, I don't know about > current i386/bios boards, for once because there are so many and > because I don't intend to buy one in the near future, but how > widespread is the use of tpm chips nowadays, especially considering > the thing hardly counts as a new development any more? I think this is > important to include in those ideologic discussions, especially cause > if there is one company that I think would try to lock their hardware > down as much as possible using something like a tpm, it's apple, but > they don't. Also, all the annoying things like drm or this copy > protection thing for displays (don't know what it's called atm, where > all possible without a tpm. > So, how widespread are builtin tpms for normal pc boards? > As for osx86, they have a really old wiki page about tpm, but a > current comment I found said more or less to patch a current version > of os x to run on normal hardware you just have to "patch out efi with > 1-2 nops and hardocde the fsb with another 1-2 nops" > http://www.insanelymac.com/forum/index.php?showtopic=65786 > Just found this interesting ... For PC boards it's easy to find ones that do include the chip and ones that do not. I cannot tell if the ratio is like 70:30 or 50:50 but both are common. It seems the TPMs are used more by system integrators that build complete PC systems than bulk part manufacturers (possibly because of budget limits and low demand for the chips). Most PC notebooks include a fingerprint sensor that is tied to a TPM chip. At least the Windows drivers for the sensor usually require the TPM drivers installed although I guess the sensor could be used on its own. There are still many notebooks without a sensor but I have no idea how many of them do include a TPM chip. I have no idea why boards with TPM chips are shipped at all or if anybody uses them for anything but the fingerprint readers. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
This whole debate made read up a little bit on TPM, for example I checked http://www.osxbook.com/book/bonus/chapter10/tpm/ (osx book is a very nice resource for mac/os x system internals) regarding tpms on apple hardware. Now contrary to what some outdated resources/rumours say, at least all newer intel mac don't include any tpm at all, the only thing that definitely did contain one were the developer boxes that were shipped to apple developer connection subscribers when the transition from ppc to intel started. Also, I can confirm this for my macbook air, neither the device tree inside os x or logic board photos from ifixit give any indication of a tpm chip, also all sources that don't rely on rumours confirm that apart from developer boxes intel macs don't contain one. You might say, now, how is that important? Well, I don't know about current i386/bios boards, for once because there are so many and because I don't intend to buy one in the near future, but how widespread is the use of tpm chips nowadays, especially considering the thing hardly counts as a new development any more? I think this is important to include in those ideologic discussions, especially cause if there is one company that I think would try to lock their hardware down as much as possible using something like a tpm, it's apple, but they don't. Also, all the annoying things like drm or this copy protection thing for displays (don't know what it's called atm, where all possible without a tpm. So, how widespread are builtin tpms for normal pc boards? As for osx86, they have a really old wiki page about tpm, but a current comment I found said more or less to patch a current version of os x to run on normal hardware you just have to "patch out efi with 1-2 nops and hardocde the fsb with another 1-2 nops" http://www.insanelymac.com/forum/index.php?showtopic=65786 Just found this interesting ... On Sun, Feb 22, 2009 at 4:33 PM, phcoder wrote: >> For some reason he wants to store the data encrypted in multiple >> locations rather than using a simple terminal to retreive the data >> over network which makes things needlessly hard. > > He perhaps needs important amount of computing power. And in his case "all > in centre" may require too much bandwidth >> >> Now I am not sure how secure this solution is. You can usually remove >> the battery to reset BIOS password, reflash the BIOS, etc. > > Many boards save the data in flash memory so removing power won't reset > password. Second flash chip if it's dedicated can be covered with concrete > too and resetting pins can be removed. Besides with coreboot everything this > can be well controlled - you can embed the config to flash. >> >> Since manufacturers claim (or used to) that you can pry the TPM chip >> off your board and it will still work the board is bootstrapped by the >> main CPU, not the TPM. This makes it possible to short some pins on >> the TPM chip so that is cannot be accessed during boot, boot a virtual >> machine, and have the BIOS initialize the chip inside that. >> > It would require some modifications to virtual machine to skip some > initilisation but is entirely possible and needs to be done only once to > cover 99% of motherboards >> >> There's also the possibility to remove the RAM from a running computer >> given you find out what kind of RAM it uses and get a different >> compatible computer. > > concrete :) >> >> Generally this shifts the attack from the realm of plain vandalism to >> the realm of planned attack which is certainly a bonus. >> >> Still I would rather rely on a custom solution because I would know >> exactly what it does. The manufacturers of PC mainboards tend to not >> release exact specifications and there are often serious problems. >> >> Still finding the flaw in the particular mainboard would probably take >> some non-trivial effort. > > There are only few kinds of tpm chips so it's enough that someone cracks > the corresponding ship to make the attack trivial. As a matter of fact few > year from now it may be easier to get a universal reader for all tpm chips > then a reader for a specific flash chip >> >> If the attacker just wants to break something there would likely be >> easier targets. If you are specifically targeted you are doomed. > > Yes. Once an attacker has the device he is able to retrieve all the data in. > Only putting physical obstacles may slow the attacker down. And I doubt that > a cost of such operation can be over $1 no matter what protection you > use. >> >> Now to the TPM support in GRUB. >> >> This makes the TPM support debate seem quite pointless. >> > It isn't. Supporing tpm may help it becoming widespread, commonplace and > acceptable, exactly what we try to avoid > > Regards > Vladimir 'phcoder' Serbinenko > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-deve
Re: A _good_ and valid use for TPM
For some reason he wants to store the data encrypted in multiple locations rather than using a simple terminal to retreive the data over network which makes things needlessly hard. He perhaps needs important amount of computing power. And in his case "all in centre" may require too much bandwidth Now I am not sure how secure this solution is. You can usually remove the battery to reset BIOS password, reflash the BIOS, etc. Many boards save the data in flash memory so removing power won't reset password. Second flash chip if it's dedicated can be covered with concrete too and resetting pins can be removed. Besides with coreboot everything this can be well controlled - you can embed the config to flash. Since manufacturers claim (or used to) that you can pry the TPM chip off your board and it will still work the board is bootstrapped by the main CPU, not the TPM. This makes it possible to short some pins on the TPM chip so that is cannot be accessed during boot, boot a virtual machine, and have the BIOS initialize the chip inside that. It would require some modifications to virtual machine to skip some initilisation but is entirely possible and needs to be done only once to cover 99% of motherboards There's also the possibility to remove the RAM from a running computer given you find out what kind of RAM it uses and get a different compatible computer. concrete :) Generally this shifts the attack from the realm of plain vandalism to the realm of planned attack which is certainly a bonus. Still I would rather rely on a custom solution because I would know exactly what it does. The manufacturers of PC mainboards tend to not release exact specifications and there are often serious problems. Still finding the flaw in the particular mainboard would probably take some non-trivial effort. There are only few kinds of tpm chips so it's enough that someone cracks the corresponding ship to make the attack trivial. As a matter of fact few year from now it may be easier to get a universal reader for all tpm chips then a reader for a specific flash chip If the attacker just wants to break something there would likely be easier targets. If you are specifically targeted you are doomed. Yes. Once an attacker has the device he is able to retrieve all the data in. Only putting physical obstacles may slow the attacker down. And I doubt that a cost of such operation can be over $1 no matter what protection you use. Now to the TPM support in GRUB. This makes the TPM support debate seem quite pointless. It isn't. Supporing tpm may help it becoming widespread, commonplace and acceptable, exactly what we try to avoid Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On 22/02/2009, phcoder wrote: > > > > > In any case, if your attacker is that much determined to archieve their > goal, > > > reverse engineering a small chip isn't going to stop them. > > > > > Reverse engineering the TPM chip is very costly. And I'm not going to try > to protect data from NSA or CIA or another three-letter agency. > > > On this you have to trust the manufacturer. Actually you can't know how > difficult reverse-engineering is before you do. And it's only a matter of > time before some crypto-hardware geek reverse-engineers it because he was > bored or a crypto-student does it because it gives him an excellent diploma. > This is quite possible because universities often have the necessary > equipment and diploma works are supposed to be long and difficult. At this > point reading a publication and using its results is trivial. And look at > reverse-engineered opensource drivers. It's just a matter of obfuscation and > we already know that it brings no security. If you want to protect your keys > the only ways is to physically protect them like putting concrete around the > flash chip Hmm, so let me collect the data from this discussion: There is somebody who wants to lock his own computer in software so that his data is not easily accessible. For some reason he wants to store the data encrypted in multiple locations rather than using a simple terminal to retreive the data over network which makes things needlessly hard. He can have a custom solution developed for the purpose (like take an ALIX board and have the BIOS on it customized and have the flash chip covered with concrete ;-) He can also use a ready made solution - a board with a TPM chip. Now I am not sure how secure this solution is. You can usually remove the battery to reset BIOS password, reflash the BIOS, etc. Since manufacturers claim (or used to) that you can pry the TPM chip off your board and it will still work the board is bootstrapped by the main CPU, not the TPM. This makes it possible to short some pins on the TPM chip so that is cannot be accessed during boot, boot a virtual machine, and have the BIOS initialize the chip inside that. There's also the possibility to remove the RAM from a running computer given you find out what kind of RAM it uses and get a different compatible computer. Generally this shifts the attack from the realm of plain vandalism to the realm of planned attack which is certainly a bonus. Still I would rather rely on a custom solution because I would know exactly what it does. The manufacturers of PC mainboards tend to not release exact specifications and there are often serious problems. Still finding the flaw in the particular mainboard would probably take some non-trivial effort. If the attacker just wants to break something there would likely be easier targets. If you are specifically targeted you are doomed. Hire a security agency to guard your computers so that you can blame them when the data is stolen. Now to the TPM support in GRUB. It appears that if grub supports *any* integrity check of the loaded software, and the BIOS can make the TPM check GRUB you are set, the GRUB itself needs not talk to the TPM diractly, it's just a nice bonus. And if somebody wanted to lock your computer from you they would ship it with software that does it, they would not have to rely on GRUB. Most likely GRUB would not be able to load their system anyway. This makes the TPM support debate seem quite pointless. Well, enjoy the flames ;-) MS ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
In any case, if your attacker is that much determined to archieve their goal, reverse engineering a small chip isn't going to stop them. Reverse engineering the TPM chip is very costly. And I'm not going to try to protect data from NSA or CIA or another three-letter agency. On this you have to trust the manufacturer. Actually you can't know how difficult reverse-engineering is before you do. And it's only a matter of time before some crypto-hardware geek reverse-engineers it because he was bored or a crypto-student does it because it gives him an excellent diploma. This is quite possible because universities often have the necessary equipment and diploma works are supposed to be long and difficult. At this point reading a publication and using its results is trivial. And look at reverse-engineered opensource drivers. It's just a matter of obfuscation and we already know that it brings no security. If you want to protect your keys the only ways is to physically protect them like putting concrete around the flash chip Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote: > > On Saturday 21 February 2009 15:51:42 Robert Millan wrote: > > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > > > TPM can be used for good or for bad, but this is the case for > > > > everything involving cryptography. We don't refuse to use encryption > > > > algorithms because they could be used for DRM, so why should we > > > > refuse to use TPM? > > > > > > I don't agree with this analogy. Unlike cryptography, TPMs have been > > > designed from the ground up to serve an evil purpose. They *could* > > > have designed them with good intent, for example either of these could > > > apply: > > > > > > - Buyer gets a printed copy of the TPM's private key when they buy a > > > board. > > > > > > - An override button that's physically accessible from the chip can > > > be used to disable "hostile mode" and make the TPM sign everything. > > > From that point physical access can be managed with traditional methods > > > (e.g. locks). > > > > > > But they didn't. > > > > Just to clarify, are you objecting to the use of TPM on principle and > > because you don't want to encourage use of it, or because you think this > > specific use (trusted boot path) is dangerous? > > I can't reply to this question, because it's not just a specific use, it's > part of the design, of its purpose. One of the design goals is remote > attestation, which is a threat to our freedom and is unethical. > > If there was a device that behaves like a TPM except remote attestation is > not possible (e.g. by one of the means described above), I wouldn't object > to it, and I think the GNU project wouldn't either, but then referring to > that as "TPM" is misleading. (warning, I accidentally wrote a long essay exploring when these TPM-like things are evil) Okay, suppose we use this means to make them not-so-evil: "Buyer gets a printed copy of the TPM's private key when they buy a board." I'll call them "(pseudo)TPMs" when they meet GNU demands. (They could be built with Free software, openly specified hardware designs, etc... why not throw in a bonus :-)) Alex Besogonov's use case is still possible. Which should make us suspicious of whether our moral problem is solved. Here's how it's possible: Assume he has access to computer A, which is physically secured. He buys computer B, which he wants to be able to wander around in the world without much effort put into physical security. He accepts that the hard drive contents can be tampered with, but he's willing to pay for a smaller cryptographic unit that guards its secrets jealously -- the (pseudo)TPM -- in order to "prove" to computer A that computer B hasn't been changed. Alex is the buyer, so he received the printed copy of the private key, and (for example) stashes it where computer A is, or burns it. How does that make computer B free? Computer A and its buddies (if any) will still refuse to communicate with B if B runs different software than what Alex had put on it. Unless there are laws in place, Alex can go on to sell (or lease) computer B to someone else, without giving *them* the printed private key. Or in the case of the "override button" and securing the (pseudo)TPM with physical locks, Alex could secure it with a lock, and then sell computer B without giving the lock's key to person who buys the computer from him. This look at (pseudo)TPM makes them look to me as a weak way of asserting at- a-distance your legal/political ownership of a computer. Even if manufacturers cooperate with GNU demands, resulting (pseudo)TPMs are only useful for a purpose that is arguably evil... although the political arguments might be different between an end-user, a small non-computer-focused corporation, a large one, and a computer-manufacturer, asserting ownership. And it depends on whether they share such information (with police, public internets or other networks) in an attempt to detect fugitive computers. I think, in the U.S. we can make laws that coerce corporations pretty effectively, and individuals don't have much power (most people buy their computing devices from mass marketers, large corporations, not people on the streets), so -- if we chose -- we could make laws that ensured that (pseudo)TPM technology was not used for its most serious moral transgressions. (I'm not sure though, because the Internet is so strange.) Also because most software is made by big corporations that can be sued (e.g. Microsoft, Apple), and most Free non-corporate software isn't evil. But I suspect that in a part of the world where people know their immediate oppressors more intimately, where the mass market (the "free market"?) isn't trusted as much, the TPM (well, like any other piece of software or hardware, only worse) could be abused to control people. I could spin that argument one way to say that U.S. capitalism is to be desired
Re: A _good_ and valid use for TPM
Robert Millan wrote: It's exactly what I want to do (minus the 'coercing' part). I want to ensure that devices run only my unmodified software (which I consider secure) and only in this case provide decryption keys for sensitive data. Of course, it done not for DRM purposes, but rather to protect sensitive data from theft (real theft, not copyright infringement). There's no fundamental difference between hardening a device and using that as your root of trust and using someone else's hardened device and using that as your root of trust. There's a difference. It's impossible to create the root-of-trust without some hardware/firmware support. The only differences are: - One more link in the trust chain (irrelevant). - Because it's _someone else's_ computer (the TPM), you're irrationally assuming that its security is flawless. Security of TPM vendors is audited by a third party. For most practical purposes it can be considered quite adequate. - Because it's someone else's computer, this helps them get their foot in your door. Next time you notice, each PC will be verified by one of these, and then you can kiss all your freedom goodbye. And how does not supporting this functionality in GRUB affect this? > This is unnecessary. Once GRUB supports crypto, it can simply load > itself from an encrypted filesystem on disk. An image can be of > arbitrary size. Nope. Still no way to test system integrity. I was repliing to the idea of implementing sha-1 checks in the MBR. Please don't bring it out of context. Sorry, I didn't mean to. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: Making sure, that noone can override it, can be awfully difficult, especially under a physical attacker. A hardware that is at least a bit designed to withstand such an attack can help a lot. I'm not sure why is physical security so awfully difficult for you (can't you use locks, tamper-proof seals, cameras and alarms?), but most people who're in the bussiness of protecting physical goods manage to sort it out. My devices will be installed at clients' locations. It's impossible to guarantee that all devices will be physically secure. If you live in the USA then one day such device might contain your private data. Would you like it to be stolen? I'm trying to design them so that data can't be stolen easily. Even by me, if someday I become insane because of flame-wars in mailing lists. In any case, if your attacker is that much determined to archieve their goal, reverse engineering a small chip isn't going to stop them. Reverse engineering the TPM chip is very costly. And I'm not going to try to protect data from NSA or CIA or another three-letter agency. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Jan Alsenz wrote: Yeah, but an attacker could patch that out too. Not if we first measure the MBR. It can be done without any TPM-specific code in the MBR if I'm not very mistaken. Could you elaborate on that? E.g. where do you measure the MBR from? MBR is automatically measured by the TPM module, it requires no intervention from GRUB. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: Private part of the endorsement key _never_ leaves the device (if manufacturer uses the recommended TPM_CreateEndorsementKeyPair method). Even device manufacturer doesn't know it. Even if that is true (which I doubt), it's merely incidental, because... It's not really incidental. TCG was initially started as a group to develop trusted computing platform. MS later tried to hijack it to realize their wet dream of locked-down computer. Public key is then signed by manufacturer's certificate. This ensures that the private key can't be compromised. ...this ensures that $evil_bob can challenge you to prove you're running his proprietary anti-user software. So I won't be able to answer $evil_bob challenge in any case, since I'm mostly running Linux now. The question is, will it be practical for you to do disable the TPM a few years from now? (I think yes, but that's not the point) -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 10:57:50PM +0100, Jan Alsenz wrote: > > > > You took the least relevant part of my argument, and assumed this is the > > reason > > I object to TPMs. Please check the rest of my previous mail. > > I didn't assume that. And I picked this argument because it is the only one I > object! > Because I think it is not an argument... > > > Anyway, it's obvious that I trust my CPU because I have no other choice. > > The > > context in which I said this, is different: there are better choices there. > > ... and since you seem to agree, please don't use it. > > > You seem to assume, that I really like the idea of a TPM, or something like > that. > I can assure you, that this is not the case. My only goal is to keep the > discussion based on facts and reason. Which way too often get lost in this > kind > of discussion (and I want to stress that this is not an accusation to anyone > here). Thanks for clarifiing, I appreciate your response. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote: >>> First of all, I think it's a poor approach, because there's no way to >>> garantee >>> the TPM is doing what it's supposed to (can you read its source code? how >>> do >>> you know for sure there are no backdoors?). >> As I said before: you can make the very same argument for every single part >> of >> your PC. >> Why do you trust Intel or AMD with your CPU? They are also involved in the >> TCG! > > You took the least relevant part of my argument, and assumed this is the > reason > I object to TPMs. Please check the rest of my previous mail. I didn't assume that. And I picked this argument because it is the only one I object! Because I think it is not an argument... > Anyway, it's obvious that I trust my CPU because I have no other choice. The > context in which I said this, is different: there are better choices there. ... and since you seem to agree, please don't use it. You seem to assume, that I really like the idea of a TPM, or something like that. I can assure you, that this is not the case. My only goal is to keep the discussion based on facts and reason. Which way too often get lost in this kind of discussion (and I want to stress that this is not an accusation to anyone here). Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote: > > > > First of all, I think it's a poor approach, because there's no way to > > garantee > > the TPM is doing what it's supposed to (can you read its source code? how > > do > > you know for sure there are no backdoors?). > > As I said before: you can make the very same argument for every single part of > your PC. > Why do you trust Intel or AMD with your CPU? They are also involved in the > TCG! You took the least relevant part of my argument, and assumed this is the reason I object to TPMs. Please check the rest of my previous mail. Anyway, it's obvious that I trust my CPU because I have no other choice. The context in which I said this, is different: there are better choices there. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 10:04:22PM +0100, Jan Alsenz wrote: > Hi! > > I don't want to be picky here, but you know that remote attestation is simply > sending signed hash values? Sure. The tricky part is that your computer generates those, but you're not really in control of them. You need to ask your TPM to obtain them, like a beggar. > So if you build me a coreboot/GRUB version with a trusted boot chain I can > happily implement a remote attestation scheme with it and ship it to my > customers. That's the beauty of free software; you can do anything you like with it, even nasty things. Just don't expect us to help you get there. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
As I said before: you can make the very same argument for every single part of your PC. Why do you trust Intel or AMD with your CPU? They are also involved in the TCG! We can't verify that it doesn't do such things. Unfortunately we also don't have resources to build alternative chips. However it doesn't mean we should support any anti-freedom devices ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote: Just to clarify, are you objecting to the use of TPM on principle and because you don't want to encourage use of it, or because you think this specific use (trusted boot path) is dangerous? >>> I can't reply to this question, because it's not just a specific use, it's >>> part of the design, of its purpose. One of the design goals is remote >>> attestation, which is a threat to our freedom and is unethical. >>> >>> If there was a device that behaves like a TPM except remote attestation is >>> not possible (e.g. by one of the means described above), I wouldn't object >>> to it, and I think the GNU project wouldn't either, but then referring to >>> that as "TPM" is misleading. >> I wasn't actually referring to the remote attestation. Just using the TPM to >> store a disk encryption key sealed with PCR registers, so that it would only >> be provided once it's been verified that GRUB hasn't been changed. >> (Personally I wouldn't want to use remote attestation at all.) > > First of all, I think it's a poor approach, because there's no way to garantee > the TPM is doing what it's supposed to (can you read its source code? how do > you know for sure there are no backdoors?). As I said before: you can make the very same argument for every single part of your PC. Why do you trust Intel or AMD with your CPU? They are also involved in the TCG! Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Hi! I don't want to be picky here, but you know that remote attestation is simply sending signed hash values? The important thing is that the receiver has trust in the protection of the private key. So if you build me a coreboot/GRUB version with a trusted boot chain I can happily implement a remote attestation scheme with it and ship it to my customers. Greets, Jan Robert Millan wrote: > On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote: >> On Saturday 21 February 2009 15:51:42 Robert Millan wrote: >>> On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: TPM can be used for good or for bad, but this is the case for everything involving cryptography. We don't refuse to use encryption algorithms because they could be used for DRM, so why should we refuse to use TPM? >>> I don't agree with this analogy. Unlike cryptography, TPMs have been >>> designed from the ground up to serve an evil purpose. They *could* have >>> designed them with good intent, for example either of these could apply: >>> >>> - Buyer gets a printed copy of the TPM's private key when they buy a >>> board. >>> >>> - An override button that's physically accessible from the chip can be >>> used to disable "hostile mode" and make the TPM sign everything. From >>> that point physical access can be managed with traditional methods >>> (e.g. locks). >>> >>> But they didn't. >> Just to clarify, are you objecting to the use of TPM on principle and >> because >> you don't want to encourage use of it, or because you think this specific >> use >> (trusted boot path) is dangerous? > > I can't reply to this question, because it's not just a specific use, it's > part of the design, of its purpose. One of the design goals is remote > attestation, which is a threat to our freedom and is unethical. > > If there was a device that behaves like a TPM except remote attestation is > not possible (e.g. by one of the means described above), I wouldn't object > to it, and I think the GNU project wouldn't either, but then referring to > that as "TPM" is misleading. > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote: > > > Just to clarify, are you objecting to the use of TPM on principle and > > > because you don't want to encourage use of it, or because you think this > > > specific use (trusted boot path) is dangerous? > > > > I can't reply to this question, because it's not just a specific use, it's > > part of the design, of its purpose. One of the design goals is remote > > attestation, which is a threat to our freedom and is unethical. > > > > If there was a device that behaves like a TPM except remote attestation is > > not possible (e.g. by one of the means described above), I wouldn't object > > to it, and I think the GNU project wouldn't either, but then referring to > > that as "TPM" is misleading. > > I wasn't actually referring to the remote attestation. Just using the TPM to > store a disk encryption key sealed with PCR registers, so that it would only > be provided once it's been verified that GRUB hasn't been changed. > (Personally I wouldn't want to use remote attestation at all.) First of all, I think it's a poor approach, because there's no way to garantee the TPM is doing what it's supposed to (can you read its source code? how do you know for sure there are no backdoors?). But the important here is not whether there's something wrong with the use case you described or not. The important is that this use case is lumped together with something seriously nasty, and that its promoters are acting irresponsibly by not allowing us to make the distinction. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 06:58:58PM +0200, Alex Besogonov wrote: > On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: > > - An override button that's physically accessible from the chip can be > >used to disable "hostile mode" and make the TPM sign everything. From > >that point physical access can be managed with traditional methods (e.g. > >locks). > > But they didn't. > And actually, they did. > > New flexibility in EKs. In the 1.1b specification, endorsement keys > were fixed in the > chip at manufacture. This allowed a certificate to be provided by the > manufacturer for the > key. However, some privacy advocates are worried about the EK becoming > a nonchangeable > identifier (in spite of all the privacy controls around it, which > would make doing > this very difficult). ***As a result, the specification allows a > manufacturer to allow the key to > be removed by the end user and regenerated.*** Of course the > certificate at that point would > become worthless, and it could be very expensive for the end user to > get a new certificate. > > https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf I would have to study this in detail, but I don't see the text saying that remote attestation is no longer supported. What this probably amounts to is that the coercion process can now be made anonymously, which I already knew: http://en.wikipedia.org/wiki/Direct_anonymous_attestation and which is not the core of the problem. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Saturday 21 February 2009 22:31:36 Robert Millan wrote: > On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote: > > On Saturday 21 February 2009 15:51:42 Robert Millan wrote: > > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > > > TPM can be used for good or for bad, but this is the case for > > > > everything involving cryptography. We don't refuse to use encryption > > > > algorithms because they could be used for DRM, so why should we > > > > refuse to use TPM? > > > > > > I don't agree with this analogy. Unlike cryptography, TPMs have been > > > designed from the ground up to serve an evil purpose. They *could* > > > have designed them with good intent, for example either of these could > > > apply: > > > > > > - Buyer gets a printed copy of the TPM's private key when they buy a > > > board. > > > > > > - An override button that's physically accessible from the chip can > > > be used to disable "hostile mode" and make the TPM sign everything. > > > From that point physical access can be managed with traditional methods > > > (e.g. locks). > > > > > > But they didn't. > > > > Just to clarify, are you objecting to the use of TPM on principle and > > because you don't want to encourage use of it, or because you think this > > specific use (trusted boot path) is dangerous? > > I can't reply to this question, because it's not just a specific use, it's > part of the design, of its purpose. One of the design goals is remote > attestation, which is a threat to our freedom and is unethical. > > If there was a device that behaves like a TPM except remote attestation is > not possible (e.g. by one of the means described above), I wouldn't object > to it, and I think the GNU project wouldn't either, but then referring to > that as "TPM" is misleading. I wasn't actually referring to the remote attestation. Just using the TPM to store a disk encryption key sealed with PCR registers, so that it would only be provided once it's been verified that GRUB hasn't been changed. (Personally I wouldn't want to use remote attestation at all.) Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 06:48:50PM +0200, Alex Besogonov wrote: > On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: > > I don't agree with this analogy. Unlike cryptography, TPMs have been > > designed > > from the ground up to serve an evil purpose. They *could* have designed > > them with good intent, for example either of these could apply: > > - Buyer gets a printed copy of the TPM's private key when they buy a board. > Private part of the endorsement key _never_ leaves the device (if > manufacturer uses the recommended TPM_CreateEndorsementKeyPair > method). Even device manufacturer doesn't know it. Even if that is true (which I doubt), it's merely incidental, because... > Public key is then > signed by manufacturer's certificate. This ensures that the private > key can't be compromised. ...this ensures that $evil_bob can challenge you to prove you're running his proprietary anti-user software. >Besides, you can _disable_ endorsement key > (TPM_DisablePubekRead) to protect your privacy. Of course. And if you're serious about privacy, you can even trash your computer or unplug it from the internet. The question is, will it be practical for you to do disable the TPM a few years from now? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote: > On Saturday 21 February 2009 15:51:42 Robert Millan wrote: > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > > TPM can be used for good or for bad, but this is the case for everything > > > involving cryptography. We don't refuse to use encryption algorithms > > > because they could be used for DRM, so why should we refuse to use TPM? > > > > I don't agree with this analogy. Unlike cryptography, TPMs have been > > designed from the ground up to serve an evil purpose. They *could* have > > designed them with good intent, for example either of these could apply: > > > > - Buyer gets a printed copy of the TPM's private key when they buy a > > board. > > > > - An override button that's physically accessible from the chip can be > > used to disable "hostile mode" and make the TPM sign everything. From > > that point physical access can be managed with traditional methods > > (e.g. locks). > > > > But they didn't. > > Just to clarify, are you objecting to the use of TPM on principle and because > you don't want to encourage use of it, or because you think this specific use > (trusted boot path) is dangerous? I can't reply to this question, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as "TPM" is misleading. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 06:03:30PM +0100, phcoder wrote: > > The only thing that tpm offers over other possibilities is a claim to > achieve something that is theoretically impossible. Such claims are > often the case in computer industry. I call it "marketing security". And I have to admit, they got really good at it. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 06:29:01PM +0200, Alex Besogonov wrote: > On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan wrote: > >> Yes, I'm trying to do remote attestation. > > You're confusing things. I think you simply want to ensure data integrity, > > and > > the TPM doesn't even do that: it simply puts the problem in hands of a third > > party. > No, I'm not confusing anything. > > > "remote attestation" is only useful when you want to coerce others into > > running your (generaly proprietary) software. I hope this is not what you > > want to do. > It's exactly what I want to do (minus the 'coercing' part). I want to > ensure that devices run only my unmodified software (which I consider > secure) and only in this case provide decryption keys for sensitive > data. Of course, it done not for DRM purposes, but rather to protect > sensitive data from theft (real theft, not copyright infringement). There's no fundamental difference between hardening a device and using that as your root of trust and using someone else's hardened device and using that as your root of trust. The only differences are: - One more link in the trust chain (irrelevant). - Because it's _someone else's_ computer (the TPM), you're irrationally assuming that its security is flawless. - Because it's someone else's computer, this helps them get their foot in your door. Next time you notice, each PC will be verified by one of these, and then you can kiss all your freedom goodbye. > >> Well, I spoke phcoder on Jabber - there might be a way to do this. > >> He's going to investigate it. > > This is unnecessary. Once GRUB supports crypto, it can simply load > > itself from an encrypted filesystem on disk. An image can be of > > arbitrary size. > Nope. Still no way to test system integrity. I was repliing to the idea of implementing sha-1 checks in the MBR. Please don't bring it out of context. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 04:00:30PM +0100, Jan Alsenz wrote: > > If you just want to ensure noone is tampering your box, simply make your box > > tamper-proof. You don't need a protocol to allow third parties to check > > anything. > > Ok, but if you have such a protocol, only use it for yourself and do trust the > manufacturer, you only have to secure one of your boxes instead of them all, > which is usually much easier. You only have to secure those boxes you need to be secure. The method you use to secure them is irrelevant to that. > >> And how can wherever the key comes from be sure that it's talking to GRUB? > > > > Because you put it there, and made sure noone can overwrite it afterwards. > > Making sure, that noone can override it, can be awfully difficult, especially > under a physical attacker. A hardware that is at least a bit designed to > withstand such an attack can help a lot. I'm not sure why is physical security so awfully difficult for you (can't you use locks, tamper-proof seals, cameras and alarms?), but most people who're in the bussiness of protecting physical goods manage to sort it out. In any case, if your attacker is that much determined to archieve their goal, reverse engineering a small chip isn't going to stop them. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
First of all you can write anything in specifications. Real chips don't necessary follow specifications. It's even said that it's "optional". Secondly this certificate makes regenerating worthless. Companies coercing you into using they software may challenge you to use signed public key. Then you still have a choice to regenerate your key but it's simply equivalent to "but nobody's threatening your freedom: we still allow you to remove your data and not access it at all.". It's equivalent to just smashing your tpm. Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: - An override button that's physically accessible from the chip can be used to disable "hostile mode" and make the TPM sign everything. From that point physical access can be managed with traditional methods (e.g. locks). But they didn't. And actually, they did. New flexibility in EKs. In the 1.1b specification, endorsement keys were fixed in the chip at manufacture. This allowed a certificate to be provided by the manufacturer for the key. However, some privacy advocates are worried about the EK becoming a nonchangeable identifier (in spite of all the privacy controls around it, which would make doing this very difficult). ***As a result, the specification allows a manufacturer to allow the key to be removed by the end user and regenerated.*** Of course the certificate at that point would become worthless, and it could be very expensive for the end user to get a new certificate. https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Well I don't understand you. When someone speaks about an attack on tpm you always consider it not-applicable in your environment. Most of them actually are. Like power analysis is able to recover keys in $1000 margin. With firewire attack you can do it with $10. You can't seriously assume an attacker which has less then $100 budget in any application. Reading directly from tpm in its current state is just a matter of time. However you consider any attack on the scheme coreboot+grub+boot or boot virus protection+sha-1+grub+boot with the encryption key in flash memory relevant. In both of these scenarios an attacker is unable to read the key without a hardware tampering level comparable to the one required to recover the key from tpm. TPM is dangerous and once we use it it's difficult to come back. If it could provide something over the two mentioned schemes then I would say that it's worth investigating. But as it isn't I say smash you tpm chip. The only thing that tpm offers over other possibilities is a claim to achieve something that is theoretically impossible. Such claims are often the case in computer industry. I call it "marketing security". I suppose companies and engineers know that their claims are false still say it because their salaries depend on how well their product is sold Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan wrote: Yes, I'm trying to do remote attestation. You're confusing things. I think you simply want to ensure data integrity, and the TPM doesn't even do that: it simply puts the problem in hands of a third party. No, I'm not confusing anything. "remote attestation" is only useful when you want to coerce others into running your (generaly proprietary) software. I hope this is not what you want to do. It's exactly what I want to do (minus the 'coercing' part). I want to ensure that devices run only my unmodified software (which I consider secure) and only in this case provide decryption keys for sensitive data. Of course, it done not for DRM purposes, but rather to protect sensitive data from theft (real theft, not copyright infringement). Well, I spoke phcoder on Jabber - there might be a way to do this. He's going to investigate it. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Nope. Still no way to test system integrity. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: > - An override button that's physically accessible from the chip can be >used to disable "hostile mode" and make the TPM sign everything. From >that point physical access can be managed with traditional methods (e.g. >locks). > But they didn't. And actually, they did. New flexibility in EKs. In the 1.1b specification, endorsement keys were fixed in the chip at manufacture. This allowed a certificate to be provided by the manufacturer for the key. However, some privacy advocates are worried about the EK becoming a nonchangeable identifier (in spite of all the privacy controls around it, which would make doing this very difficult). ***As a result, the specification allows a manufacturer to allow the key to be removed by the end user and regenerated.*** Of course the certificate at that point would become worthless, and it could be very expensive for the end user to get a new certificate. https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: > I don't agree with this analogy. Unlike cryptography, TPMs have been designed > from the ground up to serve an evil purpose. They *could* have designed > them with good intent, for example either of these could apply: > - Buyer gets a printed copy of the TPM's private key when they buy a board. Private part of the endorsement key _never_ leaves the device (if manufacturer uses the recommended TPM_CreateEndorsementKeyPair method). Even device manufacturer doesn't know it. Public key is then signed by manufacturer's certificate. This ensures that the private key can't be compromised. Besides, you can _disable_ endorsement key (TPM_DisablePubekRead) to protect your privacy. TPM also has a notion of "ownership", and it supports ownership change (which requires physical presence of operator). > - An override button that's physically accessible from the chip can be >used to disable "hostile mode" and make the TPM sign everything. From >that point physical access can be managed with traditional methods (e.g. >locks). That's not a very good idea. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan wrote: >> Yes, I'm trying to do remote attestation. > You're confusing things. I think you simply want to ensure data integrity, > and > the TPM doesn't even do that: it simply puts the problem in hands of a third > party. No, I'm not confusing anything. > "remote attestation" is only useful when you want to coerce others into > running your (generaly proprietary) software. I hope this is not what you > want to do. It's exactly what I want to do (minus the 'coercing' part). I want to ensure that devices run only my unmodified software (which I consider secure) and only in this case provide decryption keys for sensitive data. Of course, it done not for DRM purposes, but rather to protect sensitive data from theft (real theft, not copyright infringement). >> Well, I spoke phcoder on Jabber - there might be a way to do this. >> He's going to investigate it. > This is unnecessary. Once GRUB supports crypto, it can simply load > itself from an encrypted filesystem on disk. An image can be of > arbitrary size. Nope. Still no way to test system integrity. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Saturday 21 February 2009 15:51:42 Robert Millan wrote: > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > TPM can be used for good or for bad, but this is the case for everything > > involving cryptography. We don't refuse to use encryption algorithms > > because they could be used for DRM, so why should we refuse to use TPM? > > I don't agree with this analogy. Unlike cryptography, TPMs have been > designed from the ground up to serve an evil purpose. They *could* have > designed them with good intent, for example either of these could apply: > > - Buyer gets a printed copy of the TPM's private key when they buy a > board. > > - An override button that's physically accessible from the chip can be > used to disable "hostile mode" and make the TPM sign everything. From > that point physical access can be managed with traditional methods > (e.g. locks). > > But they didn't. Just to clarify, are you objecting to the use of TPM on principle and because you don't want to encourage use of it, or because you think this specific use (trusted boot path) is dangerous? Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote: >>> "remote attestation" is only useful when you want to coerce others into >>> running your (generaly proprietary) software. I hope this is not what you >>> want to do. >> Yes, this is exactly what he tries do to: convince his keyserver, that the >> requesting server runs, what it's supposed to. >> >> Which is exactly remote attestation, just in this case he controls both >> sides, >> which I think makes it an interesting use of the technology. > > That would be like trying to rob yourself by threatening yourself with a gun, > instead of simply drawing money from your wallet. Sorry, I don't get that analogy... > If you just want to ensure noone is tampering your box, simply make your box > tamper-proof. You don't need a protocol to allow third parties to check > anything. Ok, but if you have such a protocol, only use it for yourself and do trust the manufacturer, you only have to secure one of your boxes instead of them all, which is usually much easier. >>> This is unnecessary. Once GRUB supports crypto, it can simply load >>> itself from an encrypted filesystem on disk. An image can be of >>> arbitrary size. >> Ok, but where does it get the key from? > > The public key (or just a hash) can be embedded in GRUB itself. In the > instance of GRUB that goes to the flash chip, that is. > >> And how can wherever the key comes from be sure that it's talking to GRUB? > > Because you put it there, and made sure noone can overwrite it afterwards. Making sure, that noone can override it, can be awfully difficult, especially under a physical attacker. A hardware that is at least a bit designed to withstand such an attack can help a lot. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote: > > > > "remote attestation" is only useful when you want to coerce others into > > running your (generaly proprietary) software. I hope this is not what you > > want to do. > Yes, this is exactly what he tries do to: convince his keyserver, that the > requesting server runs, what it's supposed to. > > Which is exactly remote attestation, just in this case he controls both sides, > which I think makes it an interesting use of the technology. That would be like trying to rob yourself by threatening yourself with a gun, instead of simply drawing money from your wallet. If you just want to ensure noone is tampering your box, simply make your box tamper-proof. You don't need a protocol to allow third parties to check anything. > > This is unnecessary. Once GRUB supports crypto, it can simply load > > itself from an encrypted filesystem on disk. An image can be of > > arbitrary size. > Ok, but where does it get the key from? The public key (or just a hash) can be embedded in GRUB itself. In the instance of GRUB that goes to the flash chip, that is. > And how can wherever the key comes from be sure that it's talking to GRUB? Because you put it there, and made sure noone can overwrite it afterwards. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote: >> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz >> wrote: >> [skip] >>>The TPM can proof to another party, that the PCRs have certain >>> values (of >>> course the communication needs to be established by normal software running >>> on >>> the machine) >> Yes, I'm trying to do remote attestation. > > You're confusing things. I think you simply want to ensure data integrity, > and > the TPM doesn't even do that: it simply puts the problem in hands of a third > party. > > "remote attestation" is only useful when you want to coerce others into > running your (generaly proprietary) software. I hope this is not what you > want to do. Yes, this is exactly what he tries do to: convince his keyserver, that the requesting server runs, what it's supposed to. Which is exactly remote attestation, just in this case he controls both sides, which I think makes it an interesting use of the technology. First, I don't think it's possible to implement SHA-1 hashing in MBR - there's probably just not enough space left in 512-byte code segment for that. >>> I am very sure of that. >> Well, I spoke phcoder on Jabber - there might be a way to do this. >> He's going to investigate it. > > This is unnecessary. Once GRUB supports crypto, it can simply load > itself from an encrypted filesystem on disk. An image can be of > arbitrary size. Ok, but where does it get the key from? And how can wherever the key comes from be sure that it's talking to GRUB? Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Robert Millan wrote: > On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote: >> While TPM may open a door for corporations to prevent machine owners >> from having control over their machines, in this instance I do not see >> another way to solve Alex's problem. > > There's an easy way out of this. Simply verify data integrity from the > flash chip, and make sure nobody can write to the flash chip. > > You can archieve the first by e.g. installing coreboot/GRUB there and > add some crypto support to it. > > You can archieve the second by cutting the WE wire, or by dumping lots of > concrete over your board. Yes, this is a gazillon times more secure than > a TPM. TPMs are vulnerable to reverse engineering. Everything is vulnerable to reverse engineering. The problem with a TPM is not, that it uses bad/proprietary crypto, but as you state, that you can't own it completely. >> The evil part of TPM seems to be when a person buys a computer but the >> computer is locked down with a key not provided to the buyer. > > Precisely. If it came with a key that is known to the buyer (e.g. printed > on paper), or with an override mechanism that is only accessible to its > legitimate buyer, there would be no problem with it. > > But AFAICT there are no TPMs that do this. It probably even violates the > spec. I also haven't seen a TPM that does it, but it is in the specs - called a revocable endorsement key - as an optional feature... Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Fri, Feb 20, 2009 at 02:12:01PM +0200, Michael Gorven wrote: > > Yes, I agree that there should be multiple methods, but I don't see why the > TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB > users in any way -- we would just be giving them the option to use it. GRUB is free software. You can do anything you want with it. We can't really force our users to either use TPMs or not to use them. However, we can choose not to endorse a feature if we think it's ill-intended. We can also try to raise awareness of the problem, which is what I'm doing right now. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote: > > TPM can be used for good or for bad, but this is the case for everything > involving cryptography. We don't refuse to use encryption algorithms because > they could be used for DRM, so why should we refuse to use TPM? I don't agree with this analogy. Unlike cryptography, TPMs have been designed from the ground up to serve an evil purpose. They *could* have designed them with good intent, for example either of these could apply: - Buyer gets a printed copy of the TPM's private key when they buy a board. - An override button that's physically accessible from the chip can be used to disable "hostile mode" and make the TPM sign everything. From that point physical access can be managed with traditional methods (e.g. locks). But they didn't. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote: > On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz wrote: > [skip] > >The TPM can proof to another party, that the PCRs have certain > > values (of > > course the communication needs to be established by normal software running > > on > > the machine) > Yes, I'm trying to do remote attestation. You're confusing things. I think you simply want to ensure data integrity, and the TPM doesn't even do that: it simply puts the problem in hands of a third party. "remote attestation" is only useful when you want to coerce others into running your (generaly proprietary) software. I hope this is not what you want to do. > >> First, I don't think it's possible to implement SHA-1 hashing in MBR - > >> there's probably just not enough space left in 512-byte code segment > >> for that. > > I am very sure of that. > Well, I spoke phcoder on Jabber - there might be a way to do this. > He's going to investigate it. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
And in this scenario the encryption key would also be in flash. Since you can't boot unchecked software and normal linux security wouldn't allow you to read flash unless you have the root password you can't recover the key Regards Vladimir 'phcoder' Serbinenko Robert Millan wrote: On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote: While TPM may open a door for corporations to prevent machine owners from having control over their machines, in this instance I do not see another way to solve Alex's problem. There's an easy way out of this. Simply verify data integrity from the flash chip, and make sure nobody can write to the flash chip. You can archieve the first by e.g. installing coreboot/GRUB there and add some crypto support to it. You can archieve the second by cutting the WE wire, or by dumping lots of concrete over your board. Yes, this is a gazillon times more secure than a TPM. TPMs are vulnerable to reverse engineering. The evil part of TPM seems to be when a person buys a computer but the computer is locked down with a key not provided to the buyer. Precisely. If it came with a key that is known to the buyer (e.g. printed on paper), or with an override mechanism that is only accessible to its legitimate buyer, there would be no problem with it. But AFAICT there are no TPMs that do this. It probably even violates the spec. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote: > > While TPM may open a door for corporations to prevent machine owners > from having control over their machines, in this instance I do not see > another way to solve Alex's problem. There's an easy way out of this. Simply verify data integrity from the flash chip, and make sure nobody can write to the flash chip. You can archieve the first by e.g. installing coreboot/GRUB there and add some crypto support to it. You can archieve the second by cutting the WE wire, or by dumping lots of concrete over your board. Yes, this is a gazillon times more secure than a TPM. TPMs are vulnerable to reverse engineering. > The evil part of TPM seems to be when a person buys a computer but the > computer is locked down with a key not provided to the buyer. Precisely. If it came with a key that is known to the buyer (e.g. printed on paper), or with an override mechanism that is only accessible to its legitimate buyer, there would be no problem with it. But AFAICT there are no TPMs that do this. It probably even violates the spec. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Fri, Feb 20, 2009 at 01:29:50AM +0100, Jan Alsenz wrote: > First of all a TPM is not just some kind of secure memory only accessible from > early BIOS, it basically is a small computer. The thing is, we have many of these "small computers" in any standard PC. Many of them are technically capable of performing crypto checks and validating your memory. What makes the TPM different is not what it is, but what is _designed for_. When you get one, it comes with an hostile setup. If this computer was a crypto card, this would be no trouble, since the crypto card can't coerce you into using proprietary software. However, the TPM device is capable of deciding for you when your computer is "clean" and when it isn't. This empowers third parties to figure out if you're "clean" or not. To get the picture, imagine this situation: - Youtube demands you run approved version of Adobe Flash. - You don't want to use Adobe's proprietary program, you'd rather use Gnash instead. - Youtube can challenge you to use your TPM to prove you're running Flash. Then you're forced into either bowing to your TPM or not watching any videos. Such kind of submission to a small piece of silicon is not acceptable. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Wed, Feb 18, 2009 at 11:10:22AM +0200, Alex Besogonov wrote: > I know that TPM has been mentioned several times on this list. With > absolutely inadequate knee-jerk reactions from GRUB developers :( As far as I can recall, I think all my replies explaining why TPMs are a serious threat to our freedom were polite and respectful. Please think twice before labeling a reply you disagree with as "inadequate knee-jerk reaction", or it will be impossible to have a reasonable discussion over this issue. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
>> The hard part is initializing the hardware without the use of the >> original BIOS - the specifics of initializing various chips are not >> public, and probably depend on companion hardware and/or trace length >> on the particular board as well. >It's not actually needed. If one can nop tpm code in bios then he can >boot from anything and read tpm keys. You don't need to understand the >whole bios to do it. Of course it's obfuscated but obfuscation isn't a >security in any way. Also if you write completely different code to >flash bios you don't need to be able to initialise the whole hardware >all you need is being able to read tpm and write to serial port. Then >you can simply read the key at your serial console. Actually bios isn't >protected. It's just obfuscated. It won't work. BIOS itself is checksummed by the TPM. And TPM by design gains control even _before_ BIOS. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Vesa Jääskeläinen wrote: > In case it will get some day in. I would propose that you make own MBR > code like that gets compiled to own img file like tpmboot.img (512 > bytes). Then you can just provide img file for tool chain. You are > probably throwing code away anyway from normal mbr boot code. That should be possible I guess. And I have multiple versions, using different TPM commands. One of the versions keeps all the existing functionality! I had to squeeze the existing code a bit though. It should still work as expected, but I didn't have the time to test it yet. (If someone wants to volunteer, I could send the code). Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Jan Alsenz wrote: > I agree too! > > Multiple methods are interesting and everything that can be, should be placed > in > modules. > But some parts of a trusted boot chain need to be in the MBR, etc. which is > mainline code (regardless of how how you build it). > > The way I have implemented my version of the MBR right now is with compile > flags: > If you don't want/need TPM code it won't be on your system! If you compile it > with TPM support, it won't boot if there is no TPM (I don't like silent > failures). In case it will get some day in. I would propose that you make own MBR code like that gets compiled to own img file like tpmboot.img (512 bytes). Then you can just provide img file for tool chain. You are probably throwing code away anyway from normal mbr boot code. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
I agree too! Multiple methods are interesting and everything that can be, should be placed in modules. But some parts of a trusted boot chain need to be in the MBR, etc. which is mainline code (regardless of how how you build it). The way I have implemented my version of the MBR right now is with compile flags: If you don't want/need TPM code it won't be on your system! If you compile it with TPM support, it won't boot if there is no TPM (I don't like silent failures). Greets, Jan Michael Gorven schrieb: > On Friday 20 February 2009 13:27:28 phcoder wrote: >> Free software is about freedom of choice. I think we should have >> possibility to have multiple authentication and key sources. Then one >> could e.g. not save password as md5 somewhere in configfile or embedded >> in module but check that this password opens luks. Or that it's a >> password of somebody in wheel group basing on /etc/passwd, /etc/shadow >> and /etc/group. In this case tpm-keyretrieve module may be developed >> outside of main trunk and if someone wants it he can download it > > Yes, I agree that there should be multiple methods, but I don't see why the > TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB > users in any way -- we would just be giving them the option to use it. They > would have to explicitly enable and set it up. As Jan said, the TPM is a > passive device which can be used in any way we wish, and I don't see why > using some of its features to create a more secure system is wrong. > > Regards > Michael signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Friday 20 February 2009 13:27:28 phcoder wrote: > Free software is about freedom of choice. I think we should have > possibility to have multiple authentication and key sources. Then one > could e.g. not save password as md5 somewhere in configfile or embedded > in module but check that this password opens luks. Or that it's a > password of somebody in wheel group basing on /etc/passwd, /etc/shadow > and /etc/group. In this case tpm-keyretrieve module may be developed > outside of main trunk and if someone wants it he can download it Yes, I agree that there should be multiple methods, but I don't see why the TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB users in any way -- we would just be giving them the option to use it. They would have to explicitly enable and set it up. As Jan said, the TPM is a passive device which can be used in any way we wish, and I don't see why using some of its features to create a more secure system is wrong. Regards Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Free software is about freedom of choice. I think we should have possibility to have multiple authentication and key sources. Then one could e.g. not save password as md5 somewhere in configfile or embedded in module but check that this password opens luks. Or that it's a password of somebody in wheel group basing on /etc/passwd, /etc/shadow and /etc/group. In this case tpm-keyretrieve module may be developed outside of main trunk and if someone wants it he can download it Regards Vladimir 'phcoder' Serbinenko Michael Gorven wrote: On Friday 20 February 2009 02:29:50 Jan Alsenz wrote: So in the end (after boot) you have a bunch of PCR values, that represent all the code and data, that was used to boot the system. If you have this and are sure, that the current configuration is correct, you have a reference value of the expected system state, which you can use for the following: - seal a key: You can create a key with the TPM and "bind" it to specific values of the PCRs, so it only en/decrypts with it, if these values match. You can encrypt any kind of data with this, but the only useful thing for boot is to encrypt a cryptographic key needed to further start the system. Last year I implemented support for encrypted partitions in GRUB2 [1], which means that it can load kernels and ramdisks off encrypted partitions. TPM support in GRUB2 would allow the key to be stored in the TPM and only provided to GRUB once the system has checked that GRUB hasn't been tampered with. TPM can be used for good or for bad, but this is the case for everything involving cryptography. We don't refuse to use encryption algorithms because they could be used for DRM, so why should we refuse to use TPM? TPM has the potential to make Linux even more secure. Regards Michael [1] My work is yet to be merged into GRUB2. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: [skip] >>> As far as I understand - no. >> Actually - it is. >> Check the "TCG PC Client Specific Implementation Specification for >> Conventional >> Bios" or "TCG PC Specific Implementation Specification" at >> https://www.trustedcomputinggroup.org/specs/PCClient/ >> and look for CRTM (Core Root of Trust for Measurement) > Yes, BIOS is a root of trust, but not the Core Root. BIOS itself is > checked before execution (pages 20 and onwards in the "TCG PC Client > Specific Implementation Specification for Conventional Bios" spec), > even before dynamic memory is initialized. Well on page 32 they list two options, how to implement the CRTM: BIOS Boot Block or entire BIOS Since the BIOS is usually updateable, it seems that most manufacturers opt for BIOS Boot Block, which I assume will be something like: "lets put the first sector of the BIOS in ROM" (of course it might be something else completely, but I doubt it) >>> First, I don't think it's possible to implement SHA-1 hashing in MBR - >>> there's probably just not enough space left in 512-byte code segment >>> for that. >> I am very sure of that. > Well, I spoke phcoder on Jabber - there might be a way to do this. > He's going to investigate it. Sounds interesting. >>> Second, the only safe action non TPM-aware MBR can perform if it >>> detects tampering is just shutting down hard. Everything else is >>> dangerous. >> Yeah, but an attacker could patch that out too. > Not if we first measure the MBR. It can be done without any > TPM-specific code in the MBR if I'm not very mistaken. Could you elaborate on that? E.g. where do you measure the MBR from? > PS: thanks for detailed explanation! Sure, glad I could help! Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Friday 20 February 2009 02:29:50 Jan Alsenz wrote: > So in the end (after boot) you have a bunch of PCR values, that represent > all the code and data, that was used to boot the system. If you have this > and are sure, that the current configuration is correct, you have a > reference value of the expected system state, which you can use for the > following: > - seal a key: > You can create a key with the TPM and "bind" it to specific values of > the > PCRs, so it only en/decrypts with it, if these values match. > You can encrypt any kind of data with this, but the only useful thing > for > boot is to encrypt a cryptographic key needed to further start the system. Last year I implemented support for encrypted partitions in GRUB2 [1], which means that it can load kernels and ramdisks off encrypted partitions. TPM support in GRUB2 would allow the key to be stored in the TPM and only provided to GRUB once the system has checked that GRUB hasn't been tampered with. TPM can be used for good or for bad, but this is the case for everything involving cryptography. We don't refuse to use encryption algorithms because they could be used for DRM, so why should we refuse to use TPM? TPM has the potential to make Linux even more secure. Regards Michael [1] My work is yet to be merged into GRUB2. -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz wrote: [skip] >The TPM can proof to another party, that the PCRs have certain values > (of > course the communication needs to be established by normal software running on > the machine) Yes, I'm trying to do remote attestation. > Alex Besogonov wrote: >> I don't think it's possible to recover the symmetric key used later >> during normal system operation. > It could possibly be done, but that is out of scope here. > Regardless of what you use to establish your trust, if someone can extract the > key for your disk encryption from the running system your screwed. Yes, of course. >>> And what about cache attack? >> You mean frozen memory chip attack? > No, cache timing. (search for "aes cache timing") I don't think it's applicable here. >> As far as I understand - no. > Actually - it is. > Check the "TCG PC Client Specific Implementation Specification for > Conventional > Bios" or "TCG PC Specific Implementation Specification" at > https://www.trustedcomputinggroup.org/specs/PCClient/ > and look for CRTM (Core Root of Trust for Measurement) Yes, BIOS is a root of trust, but not the Core Root. BIOS itself is checked before execution (pages 20 and onwards in the "TCG PC Client Specific Implementation Specification for Conventional Bios" spec), even before dynamic memory is initialized. > What you are referring to, is that you don't trust it to have ONLY this > functionality, but you can make the same argument for every part of your PC! > Are > you sure, there is nothing in your network card, CPU or hard drive, that can > be > used against you? Frankly, I don't care. I'm not trying to protect data against NSA or other three-letter agencies. There should be a limit to paranoia, and my paranoia ends at the hardware level. >> First, I don't think it's possible to implement SHA-1 hashing in MBR - >> there's probably just not enough space left in 512-byte code segment >> for that. > I am very sure of that. Well, I spoke phcoder on Jabber - there might be a way to do this. He's going to investigate it. >> Second, the only safe action non TPM-aware MBR can perform if it >> detects tampering is just shutting down hard. Everything else is >> dangerous. > Yeah, but an attacker could patch that out too. Not if we first measure the MBR. It can be done without any TPM-specific code in the MBR if I'm not very mistaken. PS: thanks for detailed explanation! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Hi! Alright, lets try to make sure everyone is talking about the same things here. First of all a TPM is not just some kind of secure memory only accessible from early BIOS, it basically is a small computer. You can only send it commands, and it can "decide" to reject them, e.g. if you try to read out the endorsement private key. (Of course there is always the chance that the TPM has hidden commands to do that, or the manufacturer already has the keys anyway) Next, we need to keep in mind, what kind of attack and attacker we're trying to defend against. As I see it we have an attacker with relatively low-tech abilities (he cannot replace chips, break the TPM physically, or knows it's "dark secrets"), who gets physical access to the machine. So he is basically limited to flashing the BIOS, replacing anything, that is written on a disk, controling the network, etc. I excluded a higher grade attacker, because, if we have one of these, there is nothing we can do. Any solution, TPM or not, can be broken under these assumptions. Now for, what the TPM can do and is SUPPOSED to do according to the specification. First there is nothing it can do actively, like interrupt or change anything in the system. It is pretty passive and only acts on request. The TPM has a number of PCRs (Platform Configuration Registers), where it can store and concatenate hash values - this is what every stage of a trusted boot chain has to do. Every stage has to get a hash of the next one, before it executes it. (The assumption here is, that the PCRs cannot be tampered with and the stages to it correctly) So in the end (after boot) you have a bunch of PCR values, that represent all the code and data, that was used to boot the system. If you have this and are sure, that the current configuration is correct, you have a reference value of the expected system state, which you can use for the following: - seal a key: You can create a key with the TPM and "bind" it to specific values of the PCRs, so it only en/decrypts with it, if these values match. You can encrypt any kind of data with this, but the only useful thing for boot is to encrypt a cryptographic key needed to further start the system. - remote attestation: The TPM can proof to another party, that the PCRs have certain values (of course the communication needs to be established by normal software running on the machine) The TPM has a few more functions, but I think they are not relevant here. And now for the ongoing discussion: (things I didn't comment on should have been answered above) Alex Besogonov wrote: > On Thu, Feb 19, 2009 at 9:30 PM, phcoder wrote: >>> Yes, but that's way too hard. >> Sure? There was a demonstration when rsa key was recovered just by plotting >> variations on powerline of usb port > TPM performs encoding/decoding, and I consider it secure. > > I don't think it's possible to recover the symmetric key used later > during normal system operation. It could possibly be done, but that is out of scope here. Regardless of what you use to establish your trust, if someone can extract the key for your disk encryption from the running system your screwed. >> And what about cache attack? > You mean frozen memory chip attack? No, cache timing. (search for "aes cache timing") >>> That's possible, but again I consider this not critical. BIOS itself >>> is checksummed and checked by the root of trust. >> Isn't bios (or part of it) the root of "trust" > As far as I understand - no. Actually - it is. Check the "TCG PC Client Specific Implementation Specification for Conventional Bios" or "TCG PC Specific Implementation Specification" at https://www.trustedcomputinggroup.org/specs/PCClient/ and look for CRTM (Core Root of Trust for Measurement) >>> Why? >> Because I don't want support this technology. TPM=obfuscation=unsecurity. > No. TPM is just a secure way to store keys, nothing more. It can be > used for good and bad. Well, it is a bit more, but it's definitely not just obfuscation. Actually it's pretty well documented what it's supposed to do (all the specification is available, there is an open-source emulation implementation of it). What you are referring to, is that you don't trust it to have ONLY this functionality, but you can make the same argument for every part of your PC! Are you sure, there is nothing in your network card, CPU or hard drive, that can be used against you? >> And as an opensource and open security fan I can't claim to have solved an >> impossible problem. But if you want to use obfuscation schemes it's your >> right > I want a reasonably secure scheme that DOESN'T use obfuscation. > >> You assume that noone will develop hypervisor able to fool tpm bios. One >> could powercut the tpm chip (similar to how a resistor is remove to avoid >> burning efuses in xbox) then power would be reestablished to it and bios >> would be executed on hypervisor which will retrieve the keys. > Would not work. Or rather it'll
Re: A _good_ and valid use for TPM
On Thu, Feb 19, 2009 at 9:30 PM, phcoder wrote: >> Yes, but that's way too hard. > Sure? There was a demonstration when rsa key was recovered just by plotting > variations on powerline of usb port TPM performs encoding/decoding, and I consider it secure. I don't think it's possible to recover the symmetric key used later during normal system operation. > And what about cache attack? You mean frozen memory chip attack? >> That's possible, but again I consider this not critical. BIOS itself >> is checksummed and checked by the root of trust. > Isn't bios (or part of it) the root of "trust" As far as I understand - no. >> Why? > Because I don't want support this technology. TPM=obfuscation=unsecurity. No. TPM is just a secure way to store keys, nothing more. It can be used for good and bad. > And as an opensource and open security fan I can't claim to have solved an > impossible problem. But if you want to use obfuscation schemes it's your > right I want a reasonably secure scheme that DOESN'T use obfuscation. > You assume that noone will develop hypervisor able to fool tpm bios. One > could powercut the tpm chip (similar to how a resistor is remove to avoid > burning efuses in xbox) then power would be reestablished to it and bios > would be executed on hypervisor which will retrieve the keys. Would not work. Or rather it'll require uber-precise timing, a lot of soldering and access to private data of the mainboard developer. > Actually you > can trust tpm only as much as you trust in obfuscation power of bios. Only > obfuscation prevents attacker from disconnecting tpm and reading keys from > it. And there are only few types of tpm. Sooner or later someone will figure > their interface. Then it can be read by special usb adapter TPMs are fairly well engineered, it requires several magnitudes more time to crack it than any pure software security system. >> Actually, I can probably even formally prove this assumption. > I really don't see you point. With my proposition mbr still can be verified > by tpm but grub2 needs to know nothing about tpm as long as it ensures it > doesn't load any unsigned modules. First, I don't think it's possible to implement SHA-1 hashing in MBR - there's probably just not enough space left in 512-byte code segment for that. Second, the only safe action non TPM-aware MBR can perform if it detects tampering is just shutting down hard. Everything else is dangerous. Third, it would be nice to be able to measure (attest integrity) of other files, but that's just nice and not really necessary. > This approach is more versatile. It can > be used also for e.g. checking that debian install is really from debian. > And having experience with manufacturers supplying buggy hw and sw tend to > avoid solutions directly relying on hardware when another implementation is > possible TPM will be used in the most minimalistic way possible. I'll even add pure software signature checking support (which can be useful for another purposes like checking that kernel is not damaged, etc.). > Which collaboration other than not loading anything unchecked does your > scheme need from grub? Mainly, communicating with TPM in MBR to tell it that the next stage has passed checks. > From readme of trustedgrub the only thing it does is checking integrity Yes. >> PS: please, can you CC me when you answer my posts? > Could you come to irc channel or meet me at jabber/gtalk? Feel free to contact me on Alex.Besogonov _a___ gmail.com in Jabber. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: First of all your system is still totally vulnerable to emanation and power analysis or hw tampering. Yes, but that's way too hard. Sure? There was a demonstration when rsa key was recovered just by plotting variations on powerline of usb port And what about cache attack? By reflashing bios one can bypass all tpm protections (don't say it's difficult because it's closed source and so on. Look at all closed source obfuscations/pseudo-protections that get cracked every day) That's possible, but again I consider this not critical. BIOS itself is checksummed and checked by the root of trust. Isn't bios (or part of it) the root of "trust" Personally if tpm support is merged into mainline grub2 I'll stop using it. Why? Because I don't want support this technology. TPM=obfuscation=unsecurity. And as an opensource and open security fan I can't claim to have solved an impossible problem. But if you want to use obfuscation schemes it's your right Won't work. For example, attacker can run everything inside a hypervisor and then just dump memory and extract decryption keys. You have no reliable ways to detect hypervisor from inside the running OS. You can pile layers upon layers of integrity checks, but they are useless if hardware itself is not trusted. TPM allows me to establish this trust. You assume that noone will develop hypervisor able to fool tpm bios. One could powercut the tpm chip (similar to how a resistor is remove to avoid burning efuses in xbox) then power would be reestablished to it and bios would be executed on hypervisor which will retrieve the keys. Actually you can trust tpm only as much as you trust in obfuscation power of bios. Only obfuscation prevents attacker from disconnecting tpm and reading keys from it. And there are only few types of tpm. Sooner or later someone will figure their interface. Then it can be read by special usb adapter Actually, I can probably even formally prove this assumption. I really don't see you point. With my proposition mbr still can be verified by tpm but grub2 needs to know nothing about tpm as long as it ensures it doesn't load any unsigned modules. This approach is more versatile. It can be used also for e.g. checking that debian install is really from debian. And having experience with manufacturers supplying buggy hw and sw tend to avoid solutions directly relying on hardware when another implementation is possible Which collaboration other than not loading anything unchecked does your scheme need from grub? From readme of trustedgrub the only thing it does is checking integrity First advantage is that you can override it manually supplying grub password Administrator can manually override TPM by supplying the decryption key directly instead of fetching them from my key server. [skipped because this scheme just won't work] I personally would be interested in implementing security features in grub2 as long as tpm stays away Then that's a religion, not engineering. Tell it what you want but I don't trust code that I can't verify. And tpm is root of obfuscation. PS: please, can you CC me when you answer my posts? Could you come to irc channel or meet me at jabber/gtalk? Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
>First of all your system is still totally vulnerable to emanation and >power analysis or hw tampering. Yes, but that's way too hard. >By reflashing bios one can bypass all >tpm protections (don't say it's difficult because it's closed source and >so on. Look at all closed source obfuscations/pseudo-protections that >get cracked every day) That's possible, but again I consider this not critical. BIOS itself is checksummed and checked by the root of trust. >Personally if tpm support is merged into mainline grub2 I'll stop using >it. Why? >However what you request doesn't need tpm. Authenticity of modules, >configuration files and so on can be verified by one of 4 methods: >1) internal signatures >2) file in signed gpg container >3) detached signatures >4) signed hash file Won't work. For example, attacker can run everything inside a hypervisor and then just dump memory and extract decryption keys. You have no reliable ways to detect hypervisor from inside the running OS. You can pile layers upon layers of integrity checks, but they are useless if hardware itself is not trusted. TPM allows me to establish this trust. Actually, I can probably even formally prove this assumption. >First advantage is that you can override it manually supplying grub password Administrator can manually override TPM by supplying the decryption key directly instead of fetching them from my key server. [skipped because this scheme just won't work] >I personally would be interested in implementing security features in >grub2 as long as tpm stays away Then that's a religion, not engineering. PS: please, can you CC me when you answer my posts? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
As I understand from his letters and from a quick look at tgrub all he needs is to ensure the chain of verification. It seems that tgrub never reads tpm key. Even if we one finds tpm acceptable way to check OS integrity I don't see why we would rely on it if more universal approach is possible I outlined how it can be checked that if core.img is untampered then OS isn't tampered with. I also think I might have a way to extend this chain back to mbr by using following ideas: 1) padding in sha1 isn't necessarry in this case since we always load fixed amount of sectors. 2) BPB blocks can be reclaimed. If grub boot is in partition then mbr may haven't checked it 3) only one read is necessary in first sector. All real reading function can be moved to loaded sector. So only sha1 implementation is really needed to be done in mbr. 4) I find it very important that the verification can be overriden by manually giving password. This probably won't be possible so I propose to make 2 mbrs: one with all features current mbr has (the default one) and another basic one (e.g. no chs) but with sha1 in it. Default to use is the first one but a user may explicitely override it 1. The disk must be encrypted. 2. The system must be able to boot without human interaction. That is, a user cannot be prompted for a passphrase or key. The both goals together are theoretically unachievable technics like replacing ram (or gpu memory) with non-volatile storage is always available or the method of additional energy. All tpm does is to store it in obfuscated way and providing access to it in clear way if some conditions are met. Ideally this condition is B="my system is untampered" BIOS has the duty to verify the condition A="mbr is untampered" So actually what he needs is that grub ensures (A=>B) Intermediary condition is "core.img" is untampered. I already outlined how to ensure C=>B without any sacrifices. Ensuring A=>C may require some sacrifices that's why I propose to have two versions of mbr sector. I find that the feature A=>B / C=>B is useful also in many ways not limited to tpm scenarios. Look at the following case: One has installed grub locally on small disk or in flash memory (e.g. coreboot) in otherwise lightweight terminal. Now he wants to boot the OS from remote server over unsecure network. In the same time he can always choose to boot unsigned OS by providing his password Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
The hard part is initializing the hardware without the use of the original BIOS - the specifics of initializing various chips are not public, and probably depend on companion hardware and/or trace length on the particular board as well. It's not actually needed. If one can nop tpm code in bios then he can boot from anything and read tpm keys. You don't need to understand the whole bios to do it. Of course it's obfuscated but obfuscation isn't a security in any way. Also if you write completely different code to flash bios you don't need to be able to initialise the whole hardware all you need is being able to read tpm and write to serial port. Then you can simply read the key at your serial console. Actually bios isn't protected. It's just obfuscated. Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
2009/2/19 phcoder : > First of all your system is still totally vulnerable to emanation and power > analysis or hw tampering. By reflashing bios one can bypass all tpm > protections (don't say it's difficult because it's closed source and so on. > Look at all closed source obfuscations/pseudo-protections that get cracked > every day) This is interesting. I have not thought about the way the BIOS is protected from tampering. You can probably read the BIOS and verify the signature with the TPM chip but there is nothing that can attest the machine actually used this BIOS for booting. Since the BIOS is not stored in the TPM chip and must be able to reset the TPM chip into a good state at least when the power is removed from the board it must be possible to not use the BIOS at all and leave the TPM chip in good or resettable state. The hard part is initializing the hardware without the use of the original BIOS - the specifics of initializing various chips are not public, and probably depend on companion hardware and/or trace length on the particular board as well. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Thu, 19 Feb 2009 16:05:10 +0100 phcoder wrote: > Personally if tpm support is merged into mainline grub2 I'll stop using > it. However what you request doesn't need tpm. Authenticity of modules, > configuration files and so on can be verified by one of 4 methods: > 1) internal signatures > 2) file in signed gpg container > 3) detached signatures > 4) signed hash file While TPM may open a door for corporations to prevent machine owners from having control over their machines, in this instance I do not see another way to solve Alex's problem. To restate the problem: 1. The disk must be encrypted. 2. The system must be able to boot without human interaction. That is, a user cannot be prompted for a passphrase or key. The solution using TPM, as I understand it, essentially puts the encryption key into tamper-resistant memory in the TPM module, and supports integrity verification of the system, including the software on the hard disk, at load time. It sounds like any solution to problem points (1) and (2) would require some sort of tamper-resistant module to store the key and handle the first level of verification (to verify the initial code loaded from disk). From that point on, the verified boot sector code can read the encryption key and verify the next-higher level of software, and so on. The evil part of TPM seems to be when a person buys a computer but the computer is locked down with a key not provided to the buyer. Regards, Colin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
First of all your system is still totally vulnerable to emanation and power analysis or hw tampering. By reflashing bios one can bypass all tpm protections (don't say it's difficult because it's closed source and so on. Look at all closed source obfuscations/pseudo-protections that get cracked every day) Personally if tpm support is merged into mainline grub2 I'll stop using it. However what you request doesn't need tpm. Authenticity of modules, configuration files and so on can be verified by one of 4 methods: 1) internal signatures 2) file in signed gpg container 3) detached signatures 4) signed hash file First three goals can be achieved by adding a layer similar to gzio behaviour of checking can be controlled by environment variables and flags passed to grub_signed_file_open (filename, flags); First advantage is that you can override it manually supplying grub password When signature module isn't loaded then this function is available as a dummy (all files are unsigned/wrong signature). Public key can be embedded in signature module. When loaded signature module sets strict signing policy which can be then overriden by variable (to set such a variable you need either password or a command in signed grub.cfg) Then these modules can be embedded in core.img. In this case if core.img is untampered everything is verified. Ensuring integrity of core.img is platform-dependent. Some platforms (openfirmware, efi, ...) load core.img directly and if they have an ability to check the boot image it's straightforward. I haven't thought yet how to do it in limited space of mbr. In coreboot scenario it's even the best bet. You can put grub2 in rom and if you use rom instead of flashrom it's a wonderful solution. But even if you use flash rom your security is similar to scenario you propose since as I said at the begining modyfiing flash bios you can bypass tpm scenario Advantage of this approach is the ability to safely update over network Forth goal can be achieved with usage of first part and function similar to sha1sum or whirlpoolsum (my prefered hash) Another idea: for some partitions (e.g. system partitions) signatures or mac can be much better. btrfs supports checksumming of data and metadata. Add mac support is easy. Signatures are more delicate I'm looking for compact and fast signatures. I personally would be interested in implementing security features in grub2 as long as tpm stays away Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz wrote: I've recently started porting TrustedGRUB ( http://sourceforge.net/projects/trustedgrub ) to GRUB2. I didn't get too far as I don't have too much time right now, but I managed to complete the MBR bootloader. Great! MBR is the most scary part :) I agree with you on the usefulness of a TPM for disk encryption and have a similar scheme planned. Regardless of the outcome of the discussion on the mailing list I would be interested in a "trusted" GRUB2 version. Maybe we could join forces? Absolutely. I just hate doing work that won't appear in the mainline version :( BTW, the "manufacturer key" everyone is talking about is usually referred to as "endorsement key", which is generated during production (and whose private part is considered possibly in the possession of the manufacturer). I heard, that some newer TPM versions support reinitializing this key, but I'm not sure of that. Uhm... TPM_CreateEndorsementKeyPair can be used to create the endorsement key pair, and the spec also says that TPM chip _must_ ship with empty endorsement key. It also can later be changed. And you do loose the ability to do remote attestation with "official" entities, if you do it. Well, I don't care about that. And in any case, no-one uses TPM for 'official' purposes. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz wrote: > I've recently started porting TrustedGRUB ( > http://sourceforge.net/projects/trustedgrub ) to GRUB2. > I didn't get too far as I don't have too much time right now, but I managed to > complete the MBR bootloader. Great! MBR is the most scary part :) > I agree with you on the usefulness of a TPM for disk encryption and have a > similar scheme planned. > Regardless of the outcome of the discussion on the mailing list I would be > interested in a "trusted" GRUB2 version. Maybe we could join forces? Absolutely. I just hate doing work that won't appear in the mainline version :( > BTW, the "manufacturer key" everyone is talking about is usually referred to > as > "endorsement key", which is generated during production (and whose private > part > is considered possibly in the possession of the manufacturer). I heard, that > some newer TPM versions support reinitializing this key, but I'm not sure of > that. Uhm... TPM_CreateEndorsementKeyPair can be used to create the endorsement key pair, and the spec also says that TPM chip _must_ ship with empty endorsement key. It also can later be changed. > And you do loose the ability to do remote attestation with "official" > entities, if you do it. Well, I don't care about that. And in any case, no-one uses TPM for 'official' purposes. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Thu, Feb 19, 2009 at 12:03 AM, Isaac Dupree wrote: >> I know. But there's no way to guard against this attack, so there's no >> sense fretting over it for now. > well, it's relatively straightforward for an attacker who knows what they're > doing, so perhaps you should assume that *privacy* is at least partly > compromised. I think there are ways to guard against this attack. There's 'freeze CPU cache' method and I'm also thinking about using GPU to perform decryption - this way decryption keys won't be in the main memory. For now, I'm just planning to glue memory chips to the mainboard using epoxy resin. It'll make life much harder for the attacker. > but the most that attack can achieve is observing? Can that attack make it so > that, when the system starts running again, it will be in a compromised state? Attackers can steal decryption keys, connect hard drives from my computer to their computer and then copy everything. > - they can steal all crypto identity keys and try to run a completely > different > computer with different software there, if not for TPM > - I don't know how the magic of TPM knowing everything about the state of your > computer works, maybe they can modify what's in memory and put it back and > confuse things? No. TPM is a passive chip. It might be possible to use TPM as a hardware decryptor, but it's too slow to handle full-disk encryption. > Also why does GRUB need to do any explicit interaction with TPM? (I'm > ignorant and unimportant here, but maybe it will edify people, to have this > conversation.) BIOS is only able to attest that the first stage of GRUB (512-byte MBR) is not compromized. First stage then has to check the second stage and so on. So unmodified GRUB will happily load a compromised second stage even if the first stage is attested to be not modified. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: > On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree > > wrote: > > Alex Besogonov wrote: > > But guess what? While your system is running, they can take out your RAM > > and read it (disk-encryption key and all) before the RAM forgets its > > contents, see e.g. http://blogs.zdnet.com/security/?p=900 > > I know. But there's no way to guard against this attack, so there's no > sense fretting over it for now. well, it's relatively straightforward for an attacker who knows what they're doing, so perhaps you should assume that *privacy* is at least partly compromised. but the most that attack can achieve is observing? Can that attack make it so that, when the system starts running again, it will be in a compromised state? - they can steal all crypto identity keys and try to run a completely different computer with different software there, if not for TPM - I don't know how the magic of TPM knowing everything about the state of your computer works, maybe they can modify what's in memory and put it back and confuse things? Also why does GRUB need to do any explicit interaction with TPM? (I'm ignorant and unimportant here, but maybe it will edify people, to have this conversation.) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree wrote: > Alex Besogonov wrote: > But guess what? While your system is running, they can take out your RAM and > read it (disk-encryption key and all) before the RAM forgets its contents, see > e.g. http://blogs.zdnet.com/security/?p=900 I know. But there's no way to guard against this attack, so there's no sense fretting over it for now. >> or >> exploiting some local vulnerability (which is rather unlikely). > maybe. But how do you patch security vulnerabilities in e.g. the GRUB > install, if modification = tampering? (I guess there's a way to do it, > though.) Yes, there are ways to do this. They require additional credentials (which won't be available for attackers), of course. >> I'm trying to guard against attacker who can _steal_ the server itself >> and/or tamper with the hardware. > which is very difficult. Why do you have to reboot, though? Power failure, kernel panic, someone accidentally kicking the power cord, etc. 10-15 minutes of downtime for reboot are acceptable, but several hours, required to dispatch administrator with enough access rights to boot the server, are not. > and is there someway you can store the key locally in those cases, without > compromising it further? I can't think of one. I'm open to suggestions, though :) >> PS: please, at least read the relevant specs before calling TPM >> 'Treacherous'. > the ones that say to keep the keys in the hands of the manufacturers?(no I > haven't read the specs either, maybe Robert Millan has though) So far every TPM I tried can be fully controlled by me. I also don't remember bits of specs saying about keeping keys in the hands of manufacturers. Of course, TPM in theory can be used to lock down your computer, but I doubt that in this case DRM Mafiaa is going to consider using GRUB to do this. Also, projects like SELinux can then be used to lock down your computer even further, but somehow we don't see Richard Stallman battling SELinux folks. Maybe we can just rename TPM to 'Secure Key Storage'? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
Alex Besogonov wrote: > There's no way to break this chain of trust without hacking TPM (which > I consider very unlikely) fair to say "unlikely" > doing uber-dirty hardware tricks (like > modifying RAM on-the-fly using DMA from rogue PCI devices) yeah, it's probably technically possible, but enough work to do that it's not worth guarding against. But guess what? While your system is running, they can take out your RAM and read it (disk-encryption key and all) before the RAM forgets its contents, see e.g. http://blogs.zdnet.com/security/?p=900 > or > exploiting some local vulnerability (which is rather unlikely). maybe. But how do you patch security vulnerabilities in e.g. the GRUB install, if modification = tampering? (I guess there's a way to do it, though.) > >If you suppose that your attacker is unable to tamper the hardware then > >bios and grub password is all you need. If you suppose that he can then > >you can't even trust your ram modules. It can be tampered in many ways > >like serving hacked bootloader or just being non-volatile then an > >attacker can read the key from memory. > > I'm trying to guard against attacker who can _steal_ the server itself > and/or tamper with the hardware. which is very difficult. Why do you have to reboot, though? and is there some way you can store the key locally in those cases, without compromising it further? > PS: please, at least read the relevant specs before calling TPM > 'Treacherous'. the ones that say to keep the keys in the hands of the manufacturers?(no I haven't read the specs either, maybe Robert Millan has though) -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
>I don't know much about TPM but from example that I read at >TreacherousGrub website actual verification is done by TreachorousGrub. >I don't see how such a verification can protect against anything. Wrong. The main concept in TPM is "chain of trust". First, BIOS attests that the first stage of GRUB is not tampered with. If it's somehow modified then the chain of trust is broken and keys in the TPM are locked. Then the first stage (which is by now checked to be real and unmodified) loads and checks the second stage. And so on... There's no way to break this chain of trust without hacking TPM (which I consider very unlikely), doing uber-dirty hardware tricks (like modifying RAM on-the-fly using DMA from rogue PCI devices) or exploiting some local vulnerability (which is rather unlikely). >If you suppose that your attacker is unable to tamper the hardware then >bios and grub password is all you need. If you suppose that he can then >you can't even trust your ram modules. It can be tampered in many ways >like serving hacked bootloader or just being non-volatile then an >attacker can read the key from memory. I'm trying to guard against attacker who can _steal_ the server itself and/or tamper with the hardware. PS: please, at least read the relevant specs before calling TPM 'Treacherous'. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
I don't know much about TPM but from example that I read at TreacherousGrub website actual verification is done by TreachorousGrub. I don't see how such a verification can protect against anything. If you suppose that your attacker is unable to tamper the hardware then bios and grub password is all you need. If you suppose that he can then you can't even trust your ram modules. It can be tampered in many ways like serving hacked bootloader or just being non-volatile then an attacker can read the key from memory. FSF acknowledges that treacherouscomputing may offer minor advantages but dissmisses the technology as whole and I agree with them. However, I'm neither a grub maintainer nor fsf representative. Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: I know that TPM has been mentioned several times on this list. With absolutely inadequate knee-jerk reactions from GRUB developers :( Currently I have a problem - I need to protect confidential private data (we try to protect privacy of our customers) from the _physical_ theft of the server. A simple full hard drive encryption should work just fine except for one small detail - there's nobody to enter the password when server reboots. I've solved this by adding an intermediate system which connects to another server (which I consider physically secure), retrieves decryption key and does kexec into the real OS passing this key as a parameter. So I can just delete the key from the secure server to stop the physically insecure sever from booting, it'll then be useless for attackers since there's no decryption key present on it. However, it would be fairly trivial for attacker to steal the server and/or make a full copy of its hard drive and then modify intermediate system to print the decryption key. Not good. And there's no way to solve it in software, since attacker can trivially change the bootloader. So I've added another layer of security - I use TPM to remotely attest that the bootloader and the intermediate system is not modified. It requires chain of trust from BIOS to the intermediate system. So if attacker tries to modify bootloader or intermediate system image - TPM will not provide keys for communication with the secure server. Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed to GNU gods then I can still retrieve all data because the main decryption key is NOT kept in the TPM module (TPM is only used to attest integrity of the system). Also, this is not a DRM scheme. So... Why not add TPM patches into the mainline GRUB2 project? GPLv3 protects nicely against the possible DRM misuse of GRUB2 and TPM. Also I can assist in forward-porting of 'Trusted GRUB' patch. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
A _good_ and valid use for TPM
I know that TPM has been mentioned several times on this list. With absolutely inadequate knee-jerk reactions from GRUB developers :( Currently I have a problem - I need to protect confidential private data (we try to protect privacy of our customers) from the _physical_ theft of the server. A simple full hard drive encryption should work just fine except for one small detail - there's nobody to enter the password when server reboots. I've solved this by adding an intermediate system which connects to another server (which I consider physically secure), retrieves decryption key and does kexec into the real OS passing this key as a parameter. So I can just delete the key from the secure server to stop the physically insecure sever from booting, it'll then be useless for attackers since there's no decryption key present on it. However, it would be fairly trivial for attacker to steal the server and/or make a full copy of its hard drive and then modify intermediate system to print the decryption key. Not good. And there's no way to solve it in software, since attacker can trivially change the bootloader. So I've added another layer of security - I use TPM to remotely attest that the bootloader and the intermediate system is not modified. It requires chain of trust from BIOS to the intermediate system. So if attacker tries to modify bootloader or intermediate system image - TPM will not provide keys for communication with the secure server. Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed to GNU gods then I can still retrieve all data because the main decryption key is NOT kept in the TPM module (TPM is only used to attest integrity of the system). Also, this is not a DRM scheme. So... Why not add TPM patches into the mainline GRUB2 project? GPLv3 protects nicely against the possible DRM misuse of GRUB2 and TPM. Also I can assist in forward-porting of 'Trusted GRUB' patch. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
