From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F306E1381FA for ; Tue, 3 Jun 2014 21:28:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8F50DE0956; Tue, 3 Jun 2014 21:28:15 +0000 (UTC) Received: from kellari.lyseo.edu.ouka.fi (unknown [82.128.138.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 4D3D9E0874 for ; Tue, 3 Jun 2014 21:28:14 +0000 (UTC) Received: by kellari.lyseo.edu.ouka.fi (Postfix, from userid 1973) id F11DC20201BC; Wed, 4 Jun 2014 00:27:57 +0300 (EEST) Date: Wed, 4 Jun 2014 00:27:57 +0300 From: Matti Nykyri To: "gentoo-user@lists.gentoo.org" Subject: Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet? Message-ID: <20140603212757.GA6920@lyseo.edu.ouka.fi> References: <538B1D0A.9070405@libertytrek.org> <2018854.UoMFgieO5e@andromeda> <06A7F4C9-8B0B-4C1D-9CC3-77D2F41DA886@iki.fi> <2916348.CGJUT6OHQy@andromeda> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: fe677d10-2677-4f17-993d-c276ae3960a6 X-Archives-Hash: fa0b215c687e5b310f22d7970f72088a On Tue, Jun 03, 2014 at 10:53:15PM +0300, Matti Nykyri wrote: > On Jun 4, 2014, at 0:05, "J. Roeleveld" wrote: > > > On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote: > >> On Jun 2, 2014, at 18:29, "J. Roeleveld" wrote: > >>> I actually meant the software side: > >>> - How to wipe the keys and then wipe the whole memory. > >> > >> The dm-crypt module inside kernel provides a crypt_wipe_key function that > >> wipes the memory portion that holds the key. It also invalidates the key, > >> so that no further writes to the drive can occur. Suspending the device > >> prior is recommended: > >> > >> dmsetup suspend /dev/to-device > >> dmsetup message /dev/to-device 0 key wipe > > > > Thank you for this, wasn't aware of those yet. > > Does this also work with LUKS encrypted devices? > > Yes. > > Well LUKS is just a binary header that contains all the necessary setups for a secure disk encryption. If you don't use LUKS you must do all the steps it does by your self. From kernel point of view it does not see LUKS at all. When cryptsetup setups a LUKS drive in device-mapper it gives it only the portion of the drive behind the LUKS-header. LUKS is just a good way of storing your setup (cipher, master key etc...). There is a really good article about LUKS, but i failed to find it now. Begin by reading these: tomb.dyne.org/Luks_on_disk_format.pdf http://clemens.endorphin.org/TKS1-draft.pdf http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf These contain very good info about LUKS and disk encryption. The last one is probably a bit ruff one. http://clemens.endorphin.org/cryptography - a good one. I strongly suggest to dig into disk encryption before implementing it! > >> When you boot into your kernel you can setup a crash kernel inside your > >> memory. The running kernel will not touch this area so you can be certain > >> that there is no confidential data inside. Then you just wipe the area of > >> the memory of the original kernel after you have executed your crash > >> kernel. > >> > >> So I do this by opening /dev/mem in the crash kernel and then mmap every > >> page you need to wipe. I use the memset to wipe the page. Begin from > >> physical address where your original kernel is located and walk the way up. > >> Skip the portion where you crash kernel is! Crash kernel location is in > >> your kernel cmdline and the location of the original kernel in your kernel > >> config. > > > > Hmm.. this goes beyond me. Will need to google on this to see if I can find > > some more. Unless you know a good starting URL? > > Didn't find a good one either. Will continue searching. Here are few pages: http://naveengopala-embeddedlinux.blogspot.fi/2012/01/reading-physical-mapped-memory-using.html http://stackoverflow.com/questions/647783/direct-memory-access-in-linux and mmap man-page for sure... It is really straight forward... just mmap the page you want and erase it. You will just need to know what addresses to mmap and what not. Do it one page at a time and always align. The memory should not contain very sensitive data on how to access your disks if you wipe the keys. > There are many ways to do it though. Through the kernel or just write your own program that runs all by it self... Like memtest86. In its source there is everything you need to wipe the memory. But that is more advanced then doing it via kernel interface in my opinion.. > > >>> I would keep the system controlling all that off the internet with only a > >>> null-modem cable to an internet-connected server using a custom protocol. > >>> > >>> Anything that doesn't match the protocol initiates a full lock-down of the > >>> house. ;) > >> > >> But it is much more convenient to control everything from you phone via > >> internet. Just have everything setup in a secure manner. Anyways it's > >> easier for a common burglar to break the window then to hack the server! > >> And you can not steal the stereos by hacking the server ;) > > > > Perhaps, but I would have added security shutters to all the windows and doors > > which are also controlled by the same system. Smashing a window wouldn't help > > there. > > Especially if the only way to open those is by getting the server (which by > > then went into a full lock-down) to open them... > > Now only to add a halo fire suppression system to the server room and all you > > need to do is find a way to dispose of the mess.... ;) > > Lol. > > -M -- -Matti