Re: [gentoo-user] Demise of Truecrypt - surprised I haven't seen t his discussed here yet?

[Matti Nykyri]

On Tue, Jun 03, 2014 at 10:53:15PM +0300, Matti Nykyri wrote:
> On Jun 4, 2014, at 0:05, "J. Roeleveld" <joost@××××××××.org> wrote:
>
> > On Tuesday, June 03, 2014 09:53:58 PM Matti Nykyri wrote:
> >> On Jun 2, 2014, at 18:29, "J. Roeleveld" <joost@××××××××.org> 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