From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsogYfYr3JVR for ; Wed, 20 Nov 2013 10:24:44 +0100 (CET) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 20 Nov 2013 10:24:44 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vj41b-0007CQ-Oy for dm-crypt@saout.de; Wed, 20 Nov 2013 10:24:43 +0100 Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 10:24:43 +0100 Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Nov 2013 10:24:43 +0100 From: Alex Elsayed Date: Wed, 20 Nov 2013 01:24:31 -0800 Message-ID: References: <20131119025246.GA8171@tansi.org> <528ADE3F.7010607@ramses-pyramidenbau.de> <20131119042038.GA10932@tansi.org> <5690ec4082664ac25c49817a7d71cd2b.squirrel@ssl.verfeiert.org> <528C0222.8060805@ramses-pyramidenbau.de> <7ffecb94408e77dc58197faa6883bf6c.squirrel@ssl.verfeiert.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Subject: Re: [dm-crypt] Integrate cryptsetup in bootloader List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Sven Eschenberg wrote: > What autheticity? grub's? > > The key will be stored by the firmware the same way the keys delivered > with it are stored, most probably. That's why I said, you'd have to trust > the firmware and that it can not easily be tampered with. > > I wanted to point out, that an attack on the bootloader itself is not > really the problem here, as you can sign it and use secure boot. > > But in turn we'd have to trust secure boot and the security of the > firmware in general. > > It is probably way easier though to manipulate the bootloader executeable, > as Arno pointed out, than using a JTAGGer and modify the firmware. Well, there are two concerns there, and the difficulty of using a JTAG debugger only addresses one. The other issue is that while GRUB2 is open-source and can be inspected for backdoors, the same is not generally true of firmware. Trinh, if you have the resources you may want to look into Coreboot with a signed (and verification-capable) U-Boot payload. That's what ChromeOS is using (although their U-Boot verification differs from and predates what went upstream), and provides a similar trust chain to Secure Boot using open-source components. That will restrict what hardware you can use, but if your use-case requires that kind of security it may be worth considering.