Re: Full disk encryption options

[Alex Craven <krei () it net au>]

Hi,

Can you clarify why you need this behaviour in the first place (ie, under
what circumstances the server will be shut down)??

Mounting without manual password entry would be most useful in case of
recovering from unexpected outages, but this is the opposite of what
you're asking for. Occasional restarts for maintenance (in presence of
admin) wouldn't require such a facility. So, I conclude that you're
possibly talking about a machine which you shut down on (eg) a daily basis
when everyone goes home?
 
If this is the case, then what you're proposing is flawed since any
potential attacker would just need physical access to the machine once
it's been routinely shut down (which could be a rather long window by my
assumptions).

At any rate, without quite understanding what you're trying to achieve I
have two suggestions you may like to consider:

1) How about putting the machine into a suspend state rather than shutting
   down? That way the key can remain persistent in RAM until power is
   physically disconnected.

2) Otherwise, (assuming almost-always-on machines) you could consider
   placing a key file on another machine in the network (possibly in ram
   or on another encrypted volume) and using various signals to determine
   whether or not that machine ought divulge the key to your server on
   startup (specifics will depend on exactly what you want to achieve).


Cheers,
Alex.



On Mon, Jan 12, 2009 at 03:49:26PM -0500, aragonx () dcsnow com uttered:
> > 2009/1/9  <aragonx () dcsnow com>:
> > > Hello all,
> > >
> > > I have seen this topic on the list before I think but I want to go over
> > > it
> > > again if you don't mind.
> > >
> > > I have two volumes of business data that is sensitive.  I have a Fedora
> > > 9
> > > Linux server that these disks are in.  I would like to have these disks
> > > encrypted.  This is the easy part.
> > >
> > > Now for the hard part.  I would like to have the volumes mounted
> > > automatically at boot.  So the security issue comes here.  I would like
> > > to
> > > make it so that if the server is not shut down properly (normal init 0)
> > > then on the next boot it requires a pass phrase plus a pass key to
> > > access
> > > these volumes.  So the stored pass phrase can not be access able under
> > > any
> > > circumstances if the system is not shut down normally.
> > >
> > > Somehow I think I would also need to disable the power button on the
> > > machine to prevent someone from starting a shutdown without the root
> > > password.
> > >
> > > Any ideas on this topic?
> >
> > If you use a keyfile rather than a password, on shutdown you could
> > copy that keyfile from the encrypted (but now open because it is in
> > use) disk to somewhere on the unencrypted disk, on the next boot the
> > system uses that keyfile to open the encrypted disks. The keyfile is
> > then deleted/wiped.
> >
> > If the machine isn't shutdown correctly then the keyfile isn't copied
> > so the only copy is on the encrypted disk which doesn't help an
> > attacker. If you use lucs you can have multiple keys, one of which
> > would be a password which you could then use to access the system
> > again.
> >
> > The downside is that they keyfile sits on an unencrypted disk every
> > time the machine is shutdown correctly.
> >
> > Not sure if this exactly answers your scenario but it is a start.
>
> The problem with having it written to disk is that it is easily recovered.
>  All an attacker would have to do is find where it was written and recover
> it.  Is there a way to avoid that?  Too bad I can't keep a RAM drive
> active when the system is off.  That would be the best solution.  That
> way, if they unplugged it, it's gone...
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-- 
Alex Craven
krei () it net au
+47 90 86 14 85 (Nor)
+61 8 6102 0244 (Aus)