Re: Database Encryption (now required by law in Italy) - Mailing list pgsql-admin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday, 05.03.2004 at 14:47 +0100, Grega Bremec wrote:

> > > [1] There are ways of avoiding having to enter the info manually,
> > > but they're very tricky to implement securely.
> >
> > Not sure I follow this - there's no point AT ALL in using LoopAES if
> > you can mount the encrypted partitions without needing manual
> > intervention at boot time.
>
> Why not, Dave? As far as I understand it, one of the major values of
> fs-level data encryption was protection from the abused data being
> collected via the means of stolen laptops or even failed hard disks
> that've been handed over to various data-rescue labs.

Yes, that's exactly my point.  Yet it sounds like you're disagreeing
with me?!

> If a machine is reasonably secure both locally and remotely (i.e.
> secure- -enough passwords, rotated on a regular basis and frequently
> enough, or even some sort of PKID mechanism such as smartcards etc.
> and proper access control for local security, tight and reasonably
> reliable encrypted authentication and authorization for remote use),
> implementing an extra layer of any level of security is plain
> senseless and simply too expensive, both in terms of CPU overhead and
> thus performance drop (in the event of application-level encryption,
> for example), and time dedicated to research and implementation, as
> far as I'm concerned. One is better off by improving techniques in
> active use, investigating for the real weaknesses of their information
> system or dedicating the time to finding a better general solution
> that would cover as many areas as possible in one step.

I agree with this too.  Yet I still get the feeling you're disagreeing
with my original point ... !

> Same goes for interactive booting. In the world where even power
> failures are accounted for and automated, what does a user have to do
> with booting a machine? Implementing strong authentication in boot
> loaders for any kind of configuration other than the default would be
> perfectly sufficient, if you ask me. Also, if I may remind you at this
> point, human failure has so far remained to be one of the top reasons
> for security compromises, social engineering not being an uncommon
> one, so eliminating an extra point of failure in the case of an
> operator being required to guide the machine through the boot process
> doesn't harm in my opinion.
>
> One of the most important guidelines in implementing and assuring
> security for one's data would be the fact that security pays off only
> as long as the total cost of its implementation is lower than or equal
> to the maximum reasonably expectable harm done in the case of a
> security breach.

I'm not sure I get your point, Grega - are you suggesting that using
LoopAES is a good idea and that a system with LoopAES should also boot
up automatically?

I don't understand that at all.  If it boots up automatically, then the
encryption is effectively transparent and pointless.  All data on the
disk is 'pre-decrypted', very conveniently for whoever has just stolen
the server/disk.

If you're using LoopAES, it should *require* manual intervention, i.e.
passphrase to be entered.  If you want the system to boot up
automatically, using LoopAES is redundant and so should not be used.

Dave.
- --
Dave Ewart
Dave.Ewart@cancer.org.uk
Computing Manager, Epidemiology Unit, Oxford
Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFASI9VbpQs/WlN43ARAoJdAKDSEGYJ4QpAiavHjQo9faNDK9ihIgCdG/CP
X0nuHIF989baKSfaq4oy7c8=
=Na0T
-----END PGP SIGNATURE-----