[dm-crypt] luksSuspend

[dm-crypt] luksSuspend

[Navix]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

I have an alarm system that runs a script and I'm looking for the quickest
method to clear the encryption keys from the RAM to prevent cold boot
attacks. The server has two RAID 0 arrays assume "ARRAY0" is the boot drive
that is encrypted and contains Ubuntu 10.04, the cryptsetup binary is on
this array. The other array "ARRAY1" is a storage array that is also
encrypted. Will running the commands below clear the encryption keys from
the RAM even tough the cryptsetup binary is on the encrypted array that will
be suspended and is there a better method for doing this? Also do these
commands clear the write buffer for the hard drive or could some data be
lost?

cryptsetup luksSuspend ARRAY1
cryptsetup luksSuspend ARRAY0

[-- Attachment #2: Type: text/html, Size: 766 bytes --]

Re: [dm-crypt] luksSuspend

[Arno Wagner]

On Thu, Jan 27, 2011 at 03:35:26AM -0500, Navix wrote:
> I have an alarm system that runs a script and I'm looking for the quickest
> method to clear the encryption keys from the RAM to prevent cold boot
> attacks. 
> The server has two RAID 0 arrays assume "ARRAY0" is the boot drive
> that is encrypted and contains Ubuntu 10.04, the cryptsetup binary is on
> this array. The other array "ARRAY1" is a storage array that is also
> encrypted. Will running the commands below clear the encryption keys from
> the RAM even tough the cryptsetup binary is on the encrypted array that will
> be suspended and is there a better method for doing this? Also do these
> commands clear the write buffer for the hard drive or could some data be
> lost?
> 
> cryptsetup luksSuspend ARRAY1
> cryptsetup luksSuspend ARRAY0

Have you looked at the man-page of cryptsetup? There is a clear 
warning:

    WARNING:  never  try  to  suspend device where is the cryptsetup
              binary itself.

I would suggest that your project is not well-researched at this 
time.

Also accordiong to the man-page, all IO is frozen immediately,
which means all data in buffer is lost, unless you luksResume
later. This is correct behaviour. Flushing can take arbitrarily
long, especially if an application is writing data. If you want
a working slush, I suggest you umount the devices before issuing
the luskSuspend. You will find thid rather difficult with
the root filesystem, so you could try a remount to ro (read-0only)
here. This may still fail or block.

What I would suggest, is to put a statically compiled copy of 
the cryptsetup binary onto a ram-disk and run it from there.

What you should do in any case before continuing, is to 
clearly state your security goals and their priority 
level compared to operational considerations, like 
preventing data loss and corruption. These priorities 
will have a huge impact on the solution. 

Also, you should think about your sensor design. A cold-boot
attack willt ypically just issue a hardware reset, and
there is no way to prevent this on the x86 platform.

Arno


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier