On Wed, Aug 19, 2009 at 1:00 PM, Emmanuel Fleury<fle...@labri.fr> wrote: > Dear all, > > I know this is a quite sensitive topic and I'm really not willing to > start a new flame-war about it. I just want to know the exact status of > it and what is the (official) position of the GRUB team on the TPM support. > > Last discussion about the TPM issue was in February (see: > http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) and > it ended up with a kind of statu quo. It wasn't a status quo. TPM is a harmful technology which can't be accepted in any software conscious of freedom. I know that TPM can provide features some people consider useful but: 1) Making use of TPM you become dependent on good will of TPM manufacturer. You can never know if or when the TPM manufacturer or someone connected with them will ask you to use remote attestation to prove them that you use only the software they signed and that they effectively control your computer. Put in simple words it's like locking you with your computer in a prison cell and going in this cell every time you use your computer and relying on someone else to gently open you the door every time you need it. It this case even if you really trust the person holding cell keys it's not a freedom. You can argue that there are several TPM manufacturers and none will do any nasty things but you forget about TPM consortium and that actions around TPM are coordinated and that harmful features are a part of TPM specification. 2) The similar features can be implemented without resorting to TPM by using coreboot and make every stage verify the signature of every next stage. Signature handling will be done in grub when crypto patches are merged and someone (perhaps me) will have enough time to implement signatures (I already implemented RSA once but unfortunately I deleted my compile directory which also had sources). This is like locking your computer and keeping the key. 3) TPM manufacturers claim to achieve the goals like being tamperproof. This is simply not possible. Everything is tamperable. It's just the question of effort. Someone with electronic microscope and enough time and material would be able to recover TPM key. And electronic microscope is something you can have access to if you have a diploma or connections. Even without such equipment it's just a question of time before a fatal flow in TPM is discovered and published. After that point TPM wouldn't be very different from WEP. One of such flows is very known: firewire. Anyone with physical access to your computer can add a firewire card to it and dump RAM through it and have any information he wants. Any cryptographical implementation claiming to achieve impossible has a weakness. If it's open-source it clearly states "weakness is this" and explains whole functionality. Commercial implementations would just close the specifications, hide the weakness and sell as much as they can before the weakness is found out. It's like trusting someone something is steel just because it looks like such. In short tamperproof is unachievable. If your goal is to delay the attacker, obfuscate your system yourself. This way you have the advantage that the attacker can't just read publication and see the weaknesses of a particular system. If your goal is to deflect physical attacks the only way to do so is to restrict physical access. Put good locks and guards around your computer or bury it and put concrete around it or use any of 1000 ways to physically protect the computer. > > I just propose to expose the consequences of TPM support for GRUB, first > in a technical point of view and then on an ethical one. Then, I hope > the GRUB team will write his official position on the TPM support. > GRUB is GNU project and GNU's position is detailed here: http://www.gnu.org/philosophy/can-you-trust.html > > 1) Technical Aspects > ==================== > > From a purely technical point of view, the TPM support in GRUB is about > the "Trusted Boot" with a partial support and a full one. > > Partial support means that GRUB is able to (TPM commands are taken from > "Part 3 - Commands", see further for references): > > 1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of > the kernel that is intended to be loaded. > Michael Gorven has ported libgcrypt SHA-1 and other hashes to grub2. Additionally SHA-1 is depreceated and flawed. > 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the > SHA-1 digest. > Why would we need a chip to check if SHA-1 matches if we can use signatures? > > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value > of a previous (safe) boot. We assume that the previous link of the chain > of trust (BIOS?) has already checked that GRUB hasn't been tampered > before starting it. You propose to check that our checksum in PCR is ok but you already assume GRUB wasn't tampered. If you assume grub wasn't tampered no need to checksum. If you don't it's useless to checksum. > > If this part fail, GRUB should stop here and tell the user that the > kernel has been tampered. If everything went ok, GRUB get back to the > usual way... > Signatures give that > > > A full support of TPM means that GRUB should also be able to ask to a > remote authority if the content of the PCR is still ok... Why do I as user need someone else to check my computer? > > [Note that, according to the TPM specifications, it is always possible > to clear the TPM without password under physical presence assertion > (TPM_ForceClear command, Part 3, p.29) and thus the user will also be > able to use the TPM (if you are ok to loose all the data stored on the > platform).] If you assume attacker has no physical access to a machine checking signatures on updates recieved from network and proper permission model is enough to deflect any attack > > On the other hand, there is a quite high step between the partial > support that I've described before and the full support with remote > attestation... (and users may require this partial support for their own > usage). Usage like? We're speaking about security here and any serious secure system has to answer questions: 1) "Which attacks is it supposed to deflect?" 2) "Does it deflect those attacks?" 3) "How much does the security costs?" (in money, ressources and inconvinience) 4) "Which other holes does it open?" (inexact quotation of Bruce Schneier) Just adding crpytography layers, pronouncing "AES" three times a day or putting autographed picture of Bruce Schneier on your computer doesn't enhance the security. > > Now, the question whether one shouldn't support a technology because it > may lead to evil usage is something that should be solved inside the > GRUB team (and I believe that the GRUB team has already solved this > question out). It's not like just "can lead". Remote attestation is a part of TPM spec. It's like saying nuclear bombs aren't a problem just because "they can explode".
-- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
