Gentoo Archives: gentoo-user

From: Matti Nykyri <matti.nykyri@×××.fi>
To: "gentoo-user@l.g.o" <gentoo-user@l.g.o>
Subject: Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?
Date: Tue, 03 Jun 2014 19:53:27
Message-Id: F92CDD2F-F63A-46DE-B051-F023CEFE1FF8@iki.fi
In Reply to: Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet? by "J. Roeleveld"
1 On Jun 4, 2014, at 0:05, "J. Roeleveld" <joost@××××××××.org> wrote:
2
3 > On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote:
4 >> On Jun 2, 2014, at 18:29, "J. Roeleveld" <joost@××××××××.org> wrote:
5 >>> I actually meant the software side:
6 >>> - How to wipe the keys and then wipe the whole memory.
7 >>
8 >> The dm-crypt module inside kernel provides a crypt_wipe_key function that
9 >> wipes the memory portion that holds the key. It also invalidates the key,
10 >> so that no further writes to the drive can occur. Suspending the device
11 >> prior is recommended:
12 >>
13 >> dmsetup suspend /dev/to-device
14 >> dmsetup message /dev/to-device 0 key wipe
15 >
16 > Thank you for this, wasn't aware of those yet.
17 > Does this also work with LUKS encrypted devices?
18
19 Yes.
20
21 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.
22
23 >> When you boot into your kernel you can setup a crash kernel inside your
24 >> memory. The running kernel will not touch this area so you can be certain
25 >> that there is no confidential data inside. Then you just wipe the area of
26 >> the memory of the original kernel after you have executed your crash
27 >> kernel.
28 >>
29 >> So I do this by opening /dev/mem in the crash kernel and then mmap every
30 >> page you need to wipe. I use the memset to wipe the page. Begin from
31 >> physical address where your original kernel is located and walk the way up.
32 >> Skip the portion where you crash kernel is! Crash kernel location is in
33 >> your kernel cmdline and the location of the original kernel in your kernel
34 >> config.
35 >
36 > Hmm.. this goes beyond me. Will need to google on this to see if I can find
37 > some more. Unless you know a good starting URL?
38
39 Didn't find a good one either. Will continue searching.
40
41 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..
42
43 >>> I would keep the system controlling all that off the internet with only a
44 >>> null-modem cable to an internet-connected server using a custom protocol.
45 >>>
46 >>> Anything that doesn't match the protocol initiates a full lock-down of the
47 >>> house. ;)
48 >>
49 >> But it is much more convenient to control everything from you phone via
50 >> internet. Just have everything setup in a secure manner. Anyways it's
51 >> easier for a common burglar to break the window then to hack the server!
52 >> And you can not steal the stereos by hacking the server ;)
53 >
54 > Perhaps, but I would have added security shutters to all the windows and doors
55 > which are also controlled by the same system. Smashing a window wouldn't help
56 > there.
57 > Especially if the only way to open those is by getting the server (which by
58 > then went into a full lock-down) to open them...
59 > Now only to add a halo fire suppression system to the server room and all you
60 > need to do is find a way to dispose of the mess.... ;)
61
62 Lol.
63
64 -M

Replies