Return-Path: Received: from localhost (localhost [127.0.0.1]) by mail.saout.de (Postfix) with ESMTP id DC737964B for ; Mon, 10 Aug 2009 09:07:45 +0200 (CEST) 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 OMVw7J09i--P for ; Mon, 10 Aug 2009 09:07:39 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 10 Aug 2009 09:07:38 +0200 (CEST) Date: Mon, 10 Aug 2009 09:10:46 +0200 From: Heinz Diehl Message-ID: <20090810071046.GA7462@fancy-poultry.org> References: <20090808132614.GA29656@fancy-poultry.org> <4A7D91A8.5080902@gmx.de> <20090808153635.GA31434@fancy-poultry.org> <20090810061245.GA9508@maude.comedia.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090810061245.GA9508@maude.comedia.it> Subject: Re: [dm-crypt] LUKS/dm-crypt vulnerable? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 10.08.2009, Luca Berra wrote: > To achieve this, they will have to hand it back, wait for you to type > your password to boot, then steal it again :P I was nearly clear over that, but had to ask anyway, because it was so many disinformation. I did read that "stoned" could hook into the BIOS and capture some traffic from there which should be enough to get access to the key. I just couldn't believe that this is possible when the machine is powered off. Besides, I'm not using Truecrypt at all (since I do not use Windows), but my thoughts went almost immediately to LUKS/dmcrypt. I always power my Laptop completely down when no longer in use, after my former one got stolen I'm somewhat sensible now. (There's my online bank account, a lot of business email, letters, documents and so on...). > Truecrypt developers said that was a moot point, because, if someone is > able to replace the boot sector it could well replace the code that > checks its integrity. ..which is not true, of course. I can e.g. have a copy of the boot sector/MBR on a memory stick, together with a checksum file of /boot. Copying the first 512 bytes and checking it against the checksum of the known good bootsector on the memory stick will detect any manipulation immediately. A simple "dd if=mbr_copy of=/dev/sda bs=512 count=1" will cure the problem.