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 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
>> 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: SHA-1 MBR
T>his paranoid security talk is growing some big pink elephants which are >being conveniently ignored: you people are trying to protect a HD within >a computer that could be stolen, but you trust that the BIOS chip (in >ROM and whatever you want), which performs the systems initialization >(including RAM and the TPM) cannot be tampered with or even replaced. The BIOS itself is checksummed and verified by the TPM. So a simple reflashing won't work. Please, don't think that all engineers who designed the TPM are complete idiots. >When someone pointed the key-in-RAM problem the answer was "I'll just >glue it with epoxy resin"! For crying out loud! Without taking into >account that most epoxy resins take weeks to solidify under 100 ºC, Uhm.. It takes about 8 hours for the resin with hardener to solidify (speaking from experience). >if the computer is physically stolen it could be subjected to EM-field >analysis. That's WAY more complex than just swapping chips. Also, there's another small thing - I can just delete the key from my key server, and then no amount of hacking will unlock hard drive. TPM and other measures just buy time. ___ 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
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
>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
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
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
>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
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
