Thread: Database Encryption (now required by law in Italy)

Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
The new italian law about personal data protection (aka "privacy") requires
the use of cryptography _both_ for protecting the network traffic _and_ for
protecting the (personal) data stored on the hard disk.

While I can see how to protect a PGSQL connection using SSH tunneling or a
VPN, I cannot see any way to encrypt a PGSQL database stored on a hard disk,
put aside the possibility to encrypt the hosting file system with LoopAES.

Is there any (native/third party) tool for encrypting a PGSQL database on the
disk? Is there any PGSQL option for encrypting data on the fly?

Many thanks in advance for your attention.

NOTE: the italian law on privacy ("Decreto Legge 196/03", Dicembre 2003) is
available on the net:

http://www.garanteprivacy.it
http://www.interlex.it

Of course, just in italian...
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Radu-Adrian Popescu
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Silvana Di Martino wrote:

| The new italian law about personal data protection (aka "privacy")
| requires the use of cryptography _both_ for protecting the network
| traffic _and_ for protecting the (personal) data stored on the hard
| disk.
|
| While I can see how to protect a PGSQL connection using SSH
| tunneling or a VPN, I cannot see any way to encrypt a PGSQL
| database stored on a hard disk, put aside the possibility to
| encrypt the hosting file system with LoopAES.
|
| Is there any (native/third party) tool for encrypting a PGSQL
| database on the disk? Is there any PGSQL option for encrypting data
| on the fly?
|
| Many thanks in advance for your attention.
|
| NOTE: the italian law on privacy ("Decreto Legge 196/03", Dicembre
| 2003) is available on the net:
|
| http://www.garanteprivacy.it http://www.interlex.it
|
| Of course, just in italian...
| ----------------------------------------- Alessandro Bottoni and
| Silvana Di Martino alessandrobottoni@interfree.it
| silvanadimartino@tin.it
|
| ---------------------------(end of
| broadcast)--------------------------- TIP 7: don't forget to
| increase your free space map settings
|
|
Are you sure you need to encrypt the _database_ ? It seems strange to
require encryption
of all the data, as you would get using LoopAES. I think you only need
to decide (and probably
the privacy protection law stipulates this) what data you need to
encrypt and store that data
encrypted in the database; such as customer's names, addresses, social
data, payment data
and so on. On the other hand, I think you should be doing this anyway.
I know we are :-)

Regards,

- --
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
+40213212243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFASEQCVZmwYru5w6ERAqrSAJ0b2LPIe2TznFS4f4l9iYC3nMA9VgCgiKDs
MMFfrReUhbvI5xXfG+Ha1PE=
=X1ZW
-----END PGP SIGNATURE-----



Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday, 05.03.2004 at 11:10 +0200, Radu-Adrian Popescu wrote:

> | While I can see how to protect a PGSQL connection using SSH
> | tunneling or a VPN, I cannot see any way to encrypt a PGSQL
> | database stored on a hard disk, put aside the possibility to
> | encrypt the hosting file system with LoopAES.

What's wrong with using a LoopAES filesystem?  It protects against
someone walking off with the server, or at least the hard disk, and
being able to see the data.

Keeping encrypted data in the database itself is also perfectly
possible; you just need to decide what you're going to use to decrypt it
afterwards.

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)

iD8DBQFASEZpbpQs/WlN43ARApVHAKD+ymIbp+HAFUJwaTQ7JyUL07f3GgCeN9D7
miJut0SeQ7/16ANQf1NUUWk=
=lzG/
-----END PGP SIGNATURE-----

Re: Database Encryption (now required by law in Italy)

From
Date:
Is it enough to encrypt some table fields only, i.e. "personnal data"
personal(social security) number, name-surname and birth data - if one can
not easily tell whom the data(e.g. bank account) belongs to then it may be
quite enough?
Just because "personal" data is quite a loose term: it can be all or nearly
nothing.

Brgds, Laimis

> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org
> [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of
> Silvana Di Martino
> Sent: 5. mars 2004 09:54
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] Database Encryption (now required by law in Italy)
>
>
> The new italian law about personal data protection (aka
> "privacy") requires
> the use of cryptography _both_ for protecting the network
> traffic _and_ for
> protecting the (personal) data stored on the hard disk.
>
> While I can see how to protect a PGSQL connection using SSH
> tunneling or a
> VPN, I cannot see any way to encrypt a PGSQL database stored
> on a hard disk,
> put aside the possibility to encrypt the hosting file system
> with LoopAES.
>
> Is there any (native/third party) tool for encrypting a PGSQL
> database on the
> disk? Is there any PGSQL option for encrypting data on the fly?
>
> Many thanks in advance for your attention.
>
> NOTE: the italian law on privacy ("Decreto Legge 196/03",
> Dicembre 2003) is
> available on the net:
>
http://www.garanteprivacy.it
http://www.interlex.it

Of course, just in italian...
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino alessandrobottoni@interfree.it
silvanadimartino@tin.it

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
On Friday, 05.03.2004 at 09:21 +0000, lnd@hnit.is wrote:

> Is it enough to encrypt some table fields only, i.e. "personnal data"
> personal(social security) number, name-surname and birth data - if one
> can not easily tell whom the data(e.g. bank account) belongs to then
> it may be quite enough?
>
> Just because "personal" data is quite a loose term: it can be all or
> nearly nothing.

I realise the original poster is from Italy, but in the UK there is a
Data Protection Act which defines personal data.

It says that personal data means "data that relate to a living
individual who can be identified from those data or from those data and
other information in the possession of, or likely to come into the
possession of, the data controller".  This seems like a good definition
to me, although we extend it to also apply to people who have died.

There is an extension which states that "sensitive" personal data is a
subset of personal data where the data is one of several categories,
such as "physical or mental health" (this is most appropriate one of for
us, doing medical research).

I guess there may similar legislation in Italy and elsewhere.

Suggestions:

1. You need to decide which fields in the database should be encrypted.

2. Perhaps keep all 'personal' data in a separate table and control
access to that table more closely with database permissions.
Optionally, encrypt the contents of that table too.

3. Use a loopback-encrypted filesystem.

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


Re: Database Encryption (now required by law in Italy)

From
"Matt Clark"
Date:
> What's wrong with using a LoopAES filesystem?  It protects against
> someone walking off with the server, or at least the hard disk, and
> being able to see the data.

Yes, but only if the password has to entered manually [1] at boot time.
And it gives zero protection against someone who gains root access to the
server.

So you _also_ have to encrypt the sensitive data before giving it to the
DB, using a key that is not stored on the DB server.

Of course that means your app servers have to have _those_ passwords/
keys entered manually at boot time, or else someone who roots them can
read your sensitive data quite trivially.

And to do any better than that you need one of those very snazzy cards
from nCipher or whoever, that allow you to process encrypted data in a
hardware sandbox so even your application doesn't see it, or at least
only allow signed code to manipulate the data.


Matt

[1] There are ways of avoiding having to enter the info manually, but
    they're very tricky to implement securely.


Re: Database Encryption (now required by law in Italy)

From
Sergio Chaves
Date:
Hi.

That is an article on www.linuxuser.co.uk , issue 34 entitled "A Guide
to filesystem encryption"
that may do what you want to do.
It uses a method called "Loop-AES"  http://loop-aes.sourceforge.net .

Hope it works for you

Sergio

Silvana Di Martino wrote:

>The new italian law about personal data protection (aka "privacy") requires
>the use of cryptography _both_ for protecting the network traffic _and_ for
>protecting the (personal) data stored on the hard disk.
>
>While I can see how to protect a PGSQL connection using SSH tunneling or a
>VPN, I cannot see any way to encrypt a PGSQL database stored on a hard disk,
>put aside the possibility to encrypt the hosting file system with LoopAES.
>
>Is there any (native/third party) tool for encrypting a PGSQL database on the
>disk? Is there any PGSQL option for encrypting data on the fly?
>
>Many thanks in advance for your attention.
>
>NOTE: the italian law on privacy ("Decreto Legge 196/03", Dicembre 2003) is
>available on the net:
>
>http://www.garanteprivacy.it
>http://www.interlex.it
>
>Of course, just in italian...
>-----------------------------------------
>Alessandro Bottoni and Silvana Di Martino
>alessandrobottoni@interfree.it
>silvanadimartino@tin.it
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>
>

--
  °v°          Sergio Chaves            °v°
 /(_)\       www.turbocorp.com         /(_)\
  ^ ^    Enhanced Solutions Computing   ^ ^
               770.532.2239
            Linux User #221305






Re: Database Encryption (now required by law in Italy)

From
Radu-Adrian Popescu
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Clark wrote:

|>What's wrong with using a LoopAES filesystem?  It protects against
|>someone walking off with the server, or at least the hard disk, and
|>being able to see the data.
|
|
|Yes, but only if the password has to entered manually [1] at boot time.
|And it gives zero protection against someone who gains root access to the
|server.
|
|So you _also_ have to encrypt the sensitive data before giving it to the
|DB, using a key that is not stored on the DB server.
|
|Of course that means your app servers have to have _those_ passwords/
|keys entered manually at boot time, or else someone who roots them can
|read your sensitive data quite trivially.
|
|And to do any better than that you need one of those very snazzy cards
|from nCipher or whoever, that allow you to process encrypted data in a
|hardware sandbox so even your application doesn't see it, or at least
|only allow signed code to manipulate the data.
|
|
|Matt
|
|[1] There are ways of avoiding having to enter the info manually, but
|    they're very tricky to implement securely.
|
|
|---------------------------(end of broadcast)---------------------------
|TIP 2: you can get off all lists at once with the unregister command
|    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
We're basically doing it this way: generate a pair of private/public
keys and save these.
Then we get sensitive data in from some outside source, use it in the
processing part,
then we encrypt it using the public key (obviously) and store it in
the database. They
public key lives itself inside the database, because it presents no
security risk if exposed.
The private key lives on a separate machine in another physical
location. So no-one can
decrypt the data even if gaining access to the server machines.
Obviously this assumes
that we do not decrypt the data after using it... Which is something
rather hard to enforce,
depending on the application.

If we do need to decrypt the data, we take the encrypted data to a
safe location, get the private key
securely and then decrypt and use the data.

- --
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
+40213212243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFASGTdVZmwYru5w6ERAtCkAJ47bkhYffP3CeehdOKZThhCSoOoJgCfQGU3
9ZQkJc6yiuK5WwpmHtvRQ0E=
=jkE+
-----END PGP SIGNATURE-----



Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 09:51, venerdì 5 marzo 2004, Dave Ewart ha scritto:
> I guess there may similar legislation in Italy and elsewhere.

Actually, the Italian law is an implementation of a EU directive strictly
inspired to the existing UK law. It will affect all EU in a few years.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 09:20, venerdì 5 marzo 2004, Dave Ewart ha scritto:
> What's wrong with using a LoopAES filesystem?  It protects against
> someone walking off with the server, or at least the hard disk, and
> being able to see the data.

Nothing! I just wonder if there is any other tool, more specific to
PostgreSQL.

> Keeping encrypted data in the database itself is also perfectly
> possible; you just need to decide what you're going to use to decrypt it
> afterwards.

Of course, that is right. I meant a different thing, anyway: I would like to
have a encrypt/decrypt tool that I do not have to implement by myself (both
because I'm lazy and because I like standard tools.)

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 09:10, venerdì 5 marzo 2004, Radu-Adrian Popescu ha scritto:
> Are you sure you need to encrypt the _database_ ? It seems strange to
> require encryption
> of all the data, as you would get using LoopAES. I think you only need
> to decide (and probably
> the privacy protection law stipulates this) what data you need to
> encrypt and store that data
> encrypted in the database; such as customer's names, addresses, social
> data, payment data
> and so on. On the other hand, I think you should be doing this anyway.
> I know we are :-)

Deciding which data are relevant is not easy. The law stipulates that all of
the "personal data" have to be encrypted and that "personal data" are the
data that allow a "spy" to infer any of the following information about a
person:
- identity
- age
- health status
- political orientation
- religious faith
- address
- phone number
- email address
- and a few more...
As you can see, almost everything is a "personal data". At least, almost
everything worth to be stored in a database is.

We just think it is easier and safer to encrypt the whole database, or even
the whole disk, than try to understand what the law actually means.

At the moment, our data are on a server protected by a firewall and accessible
just by authorized people. This was clearly declared as being "sufficient" by
the italian law until December 2003. The new law, instead, clearly states
that personal data have to be encrypted even when stored in a safe place like
that.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
On Friday, 05.03.2004 at 12:51 +0000, Silvana Di Martino wrote:

> Alle 09:51, venerdì 5 marzo 2004, Dave Ewart ha scritto:
> > I guess there may similar legislation in Italy and elsewhere.
>
> Actually, the Italian law is an implementation of a EU directive
> strictly inspired to the existing UK law. It will affect all EU in a
> few years.

That's interesting to know, certainly.

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


Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
On Friday, 05.03.2004 at 11:17 +0000, Matt Clark wrote:

> > What's wrong with using a LoopAES filesystem?  It protects against
> > someone walking off with the server, or at least the hard disk, and
> > being able to see the data.
>
> Yes, but only if the password has to entered manually [1] at boot
> time.  And it gives zero protection against someone who gains root
> access to the server.
>
> [...]
>
> [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.

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


Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
On Friday, 05.03.2004 at 12:52 +0000, Silvana Di Martino wrote:

> Deciding which data are relevant is not easy. The law stipulates that all of
> the "personal data" have to be encrypted and that "personal data" are the
> data that allow a "spy" to infer any of the following information about a
> person:
> - identity
> - age
> - health status
> - political orientation
> - religious faith
> - address
> - phone number
> - email address
> - and a few more...

Interesting - of course some of the above, such as age, political
orientation and religious faith are NOT personal data if the other
identifying information is absent (e.g. you know that someone aged 35 is
a Communist and a Christian - not terribly helpful on its own).

The exception to that rule is where there are very few people having the
characteristics in question.

But as you say, encrypting 'the whole database' in some way is probably
safest ...

If you find any 'automated' front-end to do this at the database-level,
rather than something like loopback at the filesystem level or at the
field level for specific fields, I think there would be a lot of
interest.

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


Re: Database Encryption (now required by law in Italy)

From
Grega Bremec
Date:
...and on Fri, Mar 05, 2004 at 12:08:02PM +0000, Dave Ewart used the keyboard:
> >
> > [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.

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.

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.

Cheers,
--
    Grega Bremec
    Senior Administrator
    Noviforum Ltd., Software & Media
    http://www.noviforum.si/

Attachment

Re: Database Encryption (now required by law in Italy)

From
Mark Gibson
Date:
Silvana Di Martino wrote:

>Is there any (native/third party) tool for encrypting a PGSQL database on the
>disk? Is there any PGSQL option for encrypting data on the fly?
>
>
>
Have a look in contrib/pgcrypto.
Although I haven't actually tried it yet.

--
Mark Gibson <gibsonm |AT| cromwell |DOT| co |DOT| uk>
Web Developer & Database Admin
Cromwell Tools Ltd.
Leicester, England.


Re: Database Encryption (now required by law in Italy)

From
Mitch Pirtle
Date:
Dave Ewart wrote:

> If you find any 'automated' front-end to do this at the database-level,
> rather than something like loopback at the filesystem level or at the
> field level for specific fields, I think there would be a lot of
> interest.

But that is the problem, isn't it?  Any 'automated'
encryption/decryption will be just as useful to the would-be perpetrator
of data theft.  This is like having an automatic alarm system on your
car that works for anyone that walks up to it.

The same logic applies to encrypting the data in the database -
somewhere on your server the application has to know how to decrypt it,
and that means anyone that gains access to your server will have that
ability also...

I understand (and demand) requiring SSL connections for database
clients, and MD5 hashing of passwords before storing in the database,
but implementing two-way encryption of database data just doesn't make
sense to me.

-- Mitch

Re: Database Encryption (now required by law in Italy)

From
Dave Ewart
Date:
-----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-----

Re: Database Encryption (now required by law in Italy)

From
Matt Davies
Date:
And how does one account for key information? If one encrypts any information
deemed worthy to be a key then you have to decrypt the entire database to find
particular information.


Of course, you could keep keys unencrypted for use, but then again, why encrypt
it at all?




Quoting Mitch Pirtle <mitchy@spacemonkeylabs.com>:

> Dave Ewart wrote:
>
> > If you find any 'automated' front-end to do this at the database-level,
> > rather than something like loopback at the filesystem level or at the
> > field level for specific fields, I think there would be a lot of
> > interest.
>
> But that is the problem, isn't it?  Any 'automated'
> encryption/decryption will be just as useful to the would-be perpetrator
> of data theft.  This is like having an automatic alarm system on your
> car that works for anyone that walks up to it.
>
> The same logic applies to encrypting the data in the database -
> somewhere on your server the application has to know how to decrypt it,
> and that means anyone that gains access to your server will have that
> ability also...
>
> I understand (and demand) requiring SSL connections for database
> clients, and MD5 hashing of passwords before storing in the database,
> but implementing two-way encryption of database data just doesn't make
> sense to me.
>
> -- Mitch
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>




Re: Database Encryption (now required by law in Italy)

From
Mitch Pirtle
Date:
Alex Page wrote:

> It all comes down to what you're trying to protect your data *from*. If
> you're trying to protect it from people sniffing network traffic between
> clients and the server, then SSL is sensible. If you're trying to
> protect against somebody reading passwords out of a database and using
> them to impersonate other users, use MD5 (or SHA) hashing.

Yep.  And the previously-mentioned concept of encrypting identifying
data (name, contact info) per-user using their password as the key would
also be a great complement.  If their password was ever lost, then you
would only have to verify their identity and have them select a new
password.  I think I will implement this scheme in my next weblication
just to see how it would look and work...

> If you're trying to protect against somebody taking down your server
> room door with a sledgehammer, lifting your server out of the rack,
> driving it away and booting off an alternative medium to avoid needing
> to know your root password, then a loopback encrypted partition (or data
> encrypted in GPG where the decryption key is not stored on the database
> server) is a sensible precaution.

In my entire career, the only time I have lost a server to compromise
was just that - the physical threat.  I had a development server in an
office location, and the perpetrator simply climbed over the walls
(through the ceiling tiles) to get into the office.  NOTE:  Their
elevator key was supposed to have been deactivated, or they would never
had access to my floor.  So this was a double-whammy security failure by
both myself and the building's security.  Never again!

> I expect that for most database users, it comes down to meeting the
> standards defined by law rather than realistic expectations of an attack
> - I expect that most of the situations we attempt to prevent are
> unlikely in the extreme, but we have various contractual and legal
> obligations which mean we have to defend against them anyway.

If this list could come up with a solid approach that supported these
requirements, that would be a huge win on a global scale :)

Here is my proposal, and I'd like to see if it could pass muster on this
list:

The only identifier for the account would be the login, all other
contact data (phone, name, address etc.) would be encrypted before
storage by (blowfish, twofish, AES, your choice), using the password as
the key.  Password is stored in the database hashed by MD5.  You could
steal the database and all the data, but no contact information could be
decrypted, as each account has had their personal information encrypted
with a different key.

What do the rest of you think?

> Of course, this loopback encryption with a boot-time passphrase may fail
> if they take the rackmount UPS as *well*, and keep the machine powered
> at all times ;)

Two problems I see with this:

1) I've never seen a quad-xeon live on a UPS for more than 90 seconds
2) They will probably fail to get the external RAID storage unit

ROTFL

-- Mitch

Re: Database Encryption (now required by law in Italy)

From
Alex Page
Date:
On Fri, Mar 05, 2004 at 08:53:04AM -0500, Mitch Pirtle wrote:

> I understand (and demand) requiring SSL connections for database
> clients, and MD5 hashing of passwords before storing in the database,
> but implementing two-way encryption of database data just doesn't make
> sense to me.

It all comes down to what you're trying to protect your data *from*. If
you're trying to protect it from people sniffing network traffic between
clients and the server, then SSL is sensible. If you're trying to
protect against somebody reading passwords out of a database and using
them to impersonate other users, use MD5 (or SHA) hashing.

If you're trying to protect against somebody taking down your server
room door with a sledgehammer, lifting your server out of the rack,
driving it away and booting off an alternative medium to avoid needing
to know your root password, then a loopback encrypted partition (or data
encrypted in GPG where the decryption key is not stored on the database
server) is a sensible precaution.

I expect that for most database users, it comes down to meeting the
standards defined by law rather than realistic expectations of an attack
- I expect that most of the situations we attempt to prevent are
unlikely in the extreme, but we have various contractual and legal
obligations which mean we have to defend against them anyway.

Of course, this loopback encryption with a boot-time passphrase may fail
if they take the rackmount UPS as *well*, and keep the machine powered
at all times ;)

Alex
--
Mail: Alex Page <alex.page@cancer.org.uk>
Real: Systems/Network Assistant, Epidemiology Unit, Oxford
Tel:  01865 302 223 (external) / 223 (internal)
PGP:  8868 21D7 3D35 DD77 9D06  BF0A 0746 2DE6 55EA 367E

Re: Database Encryption (now required by law in Italy)

From
Matt Davies
Date:
Quoting Mitch Pirtle <mitchy@spacemonkeylabs.com>:

> Matt Davies wrote:
>
> > And how does one account for key information? If one encrypts any
> information
> > deemed worthy to be a key then you have to decrypt the entire database to
> find
> > particular information.
> >
> >
> > Of course, you could keep keys unencrypted for use, but then again, why
> encrypt
> > it at all?
>
> My question is much more basic than that:  Why encrypt anything beyond
> passwords?  If you secure the accounts on the machine, and encrypt all
> network traffic to the machine (ssh, scp, ssl) then what additional
> security can you add?

I totally agree. Depending on interpretation this would totally negate the
usefullness of a database at all.

>
> I have servers in remote facilities all over the world.  It is just not
> possible for me to fly to each datacenter to be there at boot time when
> I upgrade the kernel. I'd love the travel, but it is not feasible.
>
> Second, hard-disk encryption will only come into play if someone stole
> the hardware, right?  And even then, as long as the thing boots, then
> they would have access!  That is, unless we went back to the
> human-required-at-boot scenario.
>
> As a former CSO for an 18000-person company, I'm a horribly paranoid
> person when it comes to security; but security that is easily bypassed
> (or dificult-to-impossible to enforce) is just added effort, isn't it?
>
> Here is an idea to beat up on:  how about having the end user of the
> application supply the key that is used to decrypt their data, and only
> their data?  Take your basic, garden variety PHP website, for example.
>
> When the user is given an account, they are also given a password.  This
> password is also used as the key for the (blowfish, via mcrypt maybe?)
> encryption of the data that gets stored for that person.  If you do not
> have that key, then you cannot decrypt their data.  To boot, their key
> is useless for everyone else's data as they used their own...
>


I have thought about this scenario many times. The problem then is lost
passwords and so forth. All data is then useless because you can't decrypt it.


I worked for a public certification authority at one time and we were starting
to explore key escrow. That would be a useful feature, but in the end, one
sufficiently motivated will probably find a way to circumvent the system.



> Excellent discussion, maybe we could all come up with a sort of best
> practices for PostgreSQL and security :)
>
> -- Mitch
>

Yes, excellent discussion. Security and privacy are always important, but it is
also necessary to remember the business case and use of databases and not
reduce their functionality to nil. It is a hard balance to find.



Re: Database Encryption (now required by law in Italy)

From
Mitch Pirtle
Date:
Matt Davies wrote:

> And how does one account for key information? If one encrypts any information
> deemed worthy to be a key then you have to decrypt the entire database to find
> particular information.
>
>
> Of course, you could keep keys unencrypted for use, but then again, why encrypt
> it at all?

My question is much more basic than that:  Why encrypt anything beyond
passwords?  If you secure the accounts on the machine, and encrypt all
network traffic to the machine (ssh, scp, ssl) then what additional
security can you add?

I have servers in remote facilities all over the world.  It is just not
possible for me to fly to each datacenter to be there at boot time when
I upgrade the kernel. I'd love the travel, but it is not feasible.

Second, hard-disk encryption will only come into play if someone stole
the hardware, right?  And even then, as long as the thing boots, then
they would have access!  That is, unless we went back to the
human-required-at-boot scenario.

As a former CSO for an 18000-person company, I'm a horribly paranoid
person when it comes to security; but security that is easily bypassed
(or dificult-to-impossible to enforce) is just added effort, isn't it?

Here is an idea to beat up on:  how about having the end user of the
application supply the key that is used to decrypt their data, and only
their data?  Take your basic, garden variety PHP website, for example.

When the user is given an account, they are also given a password.  This
password is also used as the key for the (blowfish, via mcrypt maybe?)
encryption of the data that gets stored for that person.  If you do not
have that key, then you cannot decrypt their data.  To boot, their key
is useless for everyone else's data as they used their own...

Excellent discussion, maybe we could all come up with a sort of best
practices for PostgreSQL and security :)

-- Mitch

Re: Database Encryption (now required by law in Italy)

From
Bruno Wolff III
Date:
On Fri, Mar 05, 2004 at 07:43:10 -0700,
  Matt Davies <matt@mattdavies.net> wrote:
> And how does one account for key information? If one encrypts any information
> deemed worthy to be a key then you have to decrypt the entire database to find
> particular information.

It depends on what kinds of searches you do. If they are searches for
equals, you can use one way hashes and still have efficient searches.
"Transluscent Databases" has some other tricks in it along these lines.

Re: Database Encryption (now required by law in Italy)

From
Bruno Wolff III
Date:
On Fri, Mar 05, 2004 at 10:31:41 -0500,
  Mitch Pirtle <mitchy@spacemonkeylabs.com> wrote:
>
> 1) I've never seen a quad-xeon live on a UPS for more than 90 seconds

A UPS isn't supposed to do that. Its purpose to is to allow for a clean
shutdown or time to switch to an alternate power source. You need a backup
generator if you want to continue running through power outages.

Re: Database Encryption (now required by law in Italy)

From
Bruno Wolff III
Date:
On Fri, Mar 05, 2004 at 10:00:23 -0500,
  Mitch Pirtle <mitchy@spacemonkeylabs.com> wrote:
>
> Second, hard-disk encryption will only come into play if someone stole
> the hardware, right?  And even then, as long as the thing boots, then
> they would have access!  That is, unless we went back to the
> human-required-at-boot scenario.

Your can generate a random key on boot that is stored in volatile memory.
If the system is powered down the data will become unavailable. This
might be useful for some groups of people (e.g. criminal organizations),
but for others the problems with losing the data due to a power outage might
be too high.

Re: Database Encryption (now required by law in Italy)

From
Radu-Adrian Popescu
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mitch Pirtle wrote:

| Dave Ewart wrote:
|
|> If you find any 'automated' front-end to do this at the
|> database-level, rather than something like loopback at the
|> filesystem level or at the field level for specific fields, I
|> think there would be a lot of interest.
|
|
| But that is the problem, isn't it?  Any 'automated'
| encryption/decryption will be just as useful to the would-be
| perpetrator of data theft.  This is like having an automatic alarm
| system on your car that works for anyone that walks up to it.
|
| The same logic applies to encrypting the data in the database -
| somewhere on your server the application has to know how to decrypt
|  it, and that means anyone that gains access to your server will
| have that ability also... I understand (and demand) requiring SSL
| connections for database clients, and MD5 hashing of passwords
| before storing in the database, but implementing two-way encryption
| of database data just doesn't make sense to me.
|
| -- Mitch
|
| ---------------------------(end of
| broadcast)--------------------------- TIP 1: subscribe and
| unsubscribe commands go to majordomo@postgresql.org
|
|

My point and I think Mitch's point is this: if you use the data when
you receive it, and then encrypt it and store it, then you offer
nothing to a possible intruder
and are safe and sound, provided that you use a PKI scheme, where your
application has only the public key that it encrypts with.
If you also take data out and decrypt it, then you must do so in a
manner that does not compromise the system. That is, transfer the needed
data to a known to be safe location, such as the computer in front of
you, and decrypt it there. At all times, except when you use the data
at another
location, the secret (decryption) key does not reside anywhere near
the data. If someone stole your hard disk, they can make really good
use of it
by storing porn flics over your DB, but they can never, ever retrieve
that data.

Cheers,

- --
Radu-Adrian Popescu
CSA, DBA, Developer
Aldratech Ltd.
+40213212243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFASMr4VZmwYru5w6ERAhLFAJ9oLXaahBMEZelYcdjzMIcr+vnLfQCffRbf
WoSqd/9IZRmyrtVWwRzBEgw=
=wN4g
-----END PGP SIGNATURE-----



Re: Database Encryption (now required by law in Italy)

From
Chris Ruprecht
Date:
On Friday 05 March 2004 10:31, Mitch Pirtle wrote:

[snip]

> 1) I've never seen a quad-xeon live on a UPS for more than 90 seconds

I had mine (Acer Altos G900) running for more than 10 minutes the other day,
until I decied the outage would take a little longer than usual and shut
everything down. I have a 1400 VA APC UPS without any spare battery packs.

Best regards,
Chris


Re: Database Encryption (now required by law in Italy)

From
Hans Spaans
Date:
On Fri, Mar 05, 2004 at 12:52:05PM +0000, Silvana Di Martino wrote:
<knip>
> At the moment, our data are on a server protected by a firewall and accessible
> just by authorized people. This was clearly declared as being "sufficient" by
> the italian law until December 2003. The new law, instead, clearly states
> that personal data have to be encrypted even when stored in a safe place like
> that.

Hopefully not to off-topic.

I'm just wondering, does that law applies on all databases or just on
new databases. In the Netherlands laws about privacy only apply on new
databases and for old databases the law of that time-frame only
applies. I must note that the database must be registered with
http://www.cbpweb.nl/

Hans

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 11:30, venerdì 5 marzo 2004, Radu-Adrian Popescu ha scritto:
> We're basically doing it this way: generate a pair of private/public
> keys and save these.
> Then we get sensitive data in from some outside source, use it in the
> processing part,
> then we encrypt it using the public key (obviously) and store it in
> the database. They
> public key lives itself inside the database, because it presents no
> security risk if exposed.
> The private key lives on a separate machine in another physical
> location. So no-one can
> decrypt the data even if gaining access to the server machines.
> Obviously this assumes
> that we do not decrypt the data after using it... Which is something
> rather hard to enforce,
> depending on the application.
>
> If we do need to decrypt the data, we take the encrypted data to a
> safe location, get the private key
> securely and then decrypt and use the data.

That is quite complicated. It looks like what we actually need is a system
like Kerberos (devoted to data encryption "on the fly" instead of user
authentication). The logical schema of Kerberos fits well our model: a
third-party system authenticate and authorize whoever (process or human) that
have to access the data. Just the third party stores the private keys and use
them. All other parties just uses public keys.

Unfortunately, just a community of crypto-specialists can implement such a
mechanism.

See you.
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 13:53, venerdì 5 marzo 2004, Mitch Pirtle ha scritto:
> The same logic applies to encrypting the data in the database -
> somewhere on your server the application has to know how to decrypt it,
> and that means anyone that gains access to your server will have that
> ability also...

That's true, of course but...
1) The cryptographic keys used by the application to access the data could be
stored (encrypted) inside a compiled C/C++ or Delphi/Kylyx program.
2) No matter what we think about data encryption, a (stupid) italian law
enforces it ("Allegato B, Decreto Legge 196/03, Dicembre 2003).
3) As I told in another message, our law prohibites that our SysAdmin had
access to data. Just authorized operators can read them.

> I understand (and demand) requiring SSL connections for database
> clients, and MD5 hashing of passwords before storing in the database,
> but implementing two-way encryption of database data just doesn't make
> sense to me.

Neither to me, actually, but it makes to our law-makers (Have you heard of
Silvio Berlusconi?).

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 15:00, venerdì 5 marzo 2004, Mitch Pirtle ha scritto:
> My question is much more basic than that:  Why encrypt anything beyond
> passwords?  If you secure the accounts on the machine, and encrypt all
> network traffic to the machine (ssh, scp, ssl) then what additional
> security can you add?

The following:
- protect your data from the "prying eyes" of your SysAdmins (our law imposes
this kind of protection)
- protect your data in case of hardware theft

> I have servers in remote facilities all over the world.  It is just not
> possible for me to fly to each datacenter to be there at boot time when
> I upgrade the kernel. I'd love the travel, but it is not feasible.

Technically speaking, this is not required:
- we could have a boot system that requires the password on the net to a
"password server" or a human. A few network-based booting systems for
diskless workstations do something like that already. We just need a
network-based password system similar to Kerberos or DHCP. It does not exists
yet, and it will be hard to implement, but it can be created.

> Second, hard-disk encryption will only come into play if someone stole
> the hardware, right?  And even then, as long as the thing boots, then
> they would have access!  That is, unless we went back to the
> human-required-at-boot scenario.

See above. The laptop must ask for a password on the net. You just lock the
password of any stolen/missing PC on your password server.

> As a former CSO for an 18000-person company, I'm a horribly paranoid
> person when it comes to security; but security that is easily bypassed
> (or dificult-to-impossible to enforce) is just added effort, isn't it?

That's why I did not vote Berlusconi: he is prone to enforce this kind of
"security"... ;-)

> Here is an idea to beat up on:  how about having the end user of the
> application supply the key that is used to decrypt their data, and only
> their data?  Take your basic, garden variety PHP website, for example.
>
> When the user is given an account, they are also given a password.  This
> password is also used as the key for the (blowfish, via mcrypt maybe?)
> encryption of the data that gets stored for that person.  If you do not
> have that key, then you cannot decrypt their data.  To boot, their key
> is useless for everyone else's data as they used their own...

This is not a solution: "delegated operators" must be able to access the data
without bothering the data "owner" (that is: the person described by the
data). They cannot (and must not) ask the owner to grant them access to the
data every time they need to use them.

> Excellent discussion, maybe we could all come up with a sort of best
> practices for PostgreSQL and security :)

I do hope so: this problem is going to affect a lot of SysAdmins EU-wide and
deserves a standard solution.

See you

BTW: if you have a USA-based company and collect info regarding Italian
people, you have to comply with this absurd Italian law. Funny, isn't it?

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 15:11, venerdì 5 marzo 2004, Alex Page ha scritto:
> If you're trying to protect against somebody taking down your server
> room door with a sledgehammer, lifting your server out of the rack,
> driving it away and booting off an alternative medium to avoid needing
> to know your root password, then a loopback encrypted partition (or data
> encrypted in GPG where the decryption key is not stored on the database
> server) is a sensible precaution.

Unfortunately, the new Italian law forces us to take seriously into account
this catastrophic scenario and another one that is almost as worring: an
unfaithful SysAdmin that copies your data and sells them to KGB. So, database
encryption (and not disk encryption) is the _only_ answer.

> - I expect that most of the situations we attempt to prevent are
> unlikely in the extreme, but we have various contractual and legal
> obligations which mean we have to defend against them anyway.

This is the point.

> Of course, this loopback encryption with a boot-time passphrase may fail
> if they take the rackmount UPS as *well*, and keep the machine powered
> at all times ;)

The server should listen to the (encrypted/digitally signed) "Heartbeat" of a
password server through the net to prevent this kind of attack.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 12:12, venerdì 5 marzo 2004, Dave Ewart ha scritto:
> If you find any 'automated' front-end to do this at the database-level,
> rather than something like loopback at the filesystem level or at the
> field level for specific fields, I think there would be a lot of
> interest.

As I told in another message, this problem should be faced in a systematic and
community-oriented way because this law is going to affect all EU SysAdmin in
a few years and could push many GPL RDBMS out of the market. I will try to
manage it somehow, just to satisfy my specific needs of the moment, but this
problem do deserves a standard solution.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 11:17, venerdì 5 marzo 2004, Matt Clark ha scritto:
> Yes, but only if the password has to entered manually [1] at boot time.
> And it gives zero protection against someone who gains root access to the
> server.

This is a problem for italian users because the italian law clearly states
that only the people delegated to perform maintenance on the personal data
can have access to them. SysAdmin are clearly escluded. So, we do have to
protect the data even from the "prying eyes" of our SysAdmin... :-(

> So you _also_ have to encrypt the sensitive data before giving it to the
> DB, using a key that is not stored on the DB server.

Right.

> Of course that means your app servers have to have _those_ passwords/
> keys entered manually at boot time, or else someone who roots them can
> read your sensitive data quite trivially.

Right.

> And to do any better than that you need one of those very snazzy cards
> from nCipher or whoever, that allow you to process encrypted data in a
> hardware sandbox so even your application doesn't see it, or at least
> only allow signed code to manipulate the data.

Actually, we are considering the adoption of USB cryptographic keys for this
task. Having the passwords stored in a USB EPROM should be safer and easier
to use than a set of hard-to-remember/hard-to-crack alphanumeric passwords
(each at least 8 characters long, accordingly with our law).

IMHO, this crypto topic should be seriously taken into account by the
developers of all of the major Open Source Database Engines (PostgreSQL,
MySQL and Firebird). Given that a large part of the data stored into these DB
are somehow "personal" or even "sensitive", the lack of built-in
cryptographic protection could push our beloved GPL RDBMS out of the market.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
"scott.marlowe"
Date:
On Fri, 5 Mar 2004, Silvana Di Martino wrote:

> Alle 15:11, venerdì 5 marzo 2004, Alex Page ha scritto:
> > If you're trying to protect against somebody taking down your server
> > room door with a sledgehammer, lifting your server out of the rack,
> > driving it away and booting off an alternative medium to avoid needing
> > to know your root password, then a loopback encrypted partition (or data
> > encrypted in GPG where the decryption key is not stored on the database
> > server) is a sensible precaution.
>
> Unfortunately, the new Italian law forces us to take seriously into account
> this catastrophic scenario and another one that is almost as worring: an
> unfaithful SysAdmin that copies your data and sells them to KGB. So, database
> encryption (and not disk encryption) is the _only_ answer.

the only way for this to work is for it to be a "two key system" like the
military uses for missile launch.

One sysadmin as the "key" to the database box, but the data is encrypted
before being sent to the database box on another system with another admin
with another "key".  Preferably these two would never interact or know
each other.

If the encryption and decryption happen on the same box that runs that
database, then it's simply more work for the sysadmin to get at the data,
not an impossibility.  Anything outside of two seperate systems, one with
storage, the other doing encrypting without any form long term storage is
just a charade of security.


Re: Database Encryption (now required by law in Italy)

From
Stephan Szabo
Date:
On Fri, 5 Mar 2004, Silvana Di Martino wrote:

> Alle 15:11, venerdì 5 marzo 2004, Alex Page ha scritto:
> > If you're trying to protect against somebody taking down your server
> > room door with a sledgehammer, lifting your server out of the rack,
> > driving it away and booting off an alternative medium to avoid needing
> > to know your root password, then a loopback encrypted partition (or data
> > encrypted in GPG where the decryption key is not stored on the database
> > server) is a sensible precaution.
>
> Unfortunately, the new Italian law forces us to take seriously into account
> this catastrophic scenario and another one that is almost as worring: an
> unfaithful SysAdmin that copies your data and sells them to KGB. So, database
> encryption (and not disk encryption) is the _only_ answer.

But since your sysadmin (if not trusted) could go behind your back and
replace the database, any applications that are using the data, etc, I'm
not sure that's even sufficient.

> > Of course, this loopback encryption with a boot-time passphrase may fail
> > if they take the rackmount UPS as *well*, and keep the machine powered
> > at all times ;)
>
> The server should listen to the (encrypted/digitally signed) "Heartbeat" of a
> password server through the net to prevent this kind of attack.

That'll help prevent this sort of attack (although doesn't entirely unless
you can guarantee that the password server cannot be taken at the same
time) but also gives you a remote point of failure.

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 13:53, venerdì 5 marzo 2004, Mark Gibson ha scritto:
> Silvana Di Martino wrote:
> >Is there any (native/third party) tool for encrypting a PGSQL database on
> > the disk? Is there any PGSQL option for encrypting data on the fly?
>
> Have a look in contrib/pgcrypto.
> Although I haven't actually tried it yet.

Thanks!

The pgcrypto package contains a few server-side (C + PL/PGSQL) functions that
implement a few data encryption/decryption methods. It looks like they can be
used to protect my data from unauthorized access.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 20:14, venerdì 5 marzo 2004, Stephan Szabo ha scritto:
> > Unfortunately, the new Italian law forces us to take seriously into
> > account this catastrophic scenario and another one that is almost as
> > worring: an unfaithful SysAdmin that copies your data and sells them to
> > KGB. So, database encryption (and not disk encryption) is the _only_
> > answer.
>
> But since your sysadmin (if not trusted) could go behind your back and
> replace the database, any applications that are using the data, etc, I'm
> not sure that's even sufficient.

Replacing the RDBMS engine and/or the "client" application, would be useless:
the "cracker" still need the password to access the encrypted data.

> > > Of course, this loopback encryption with a boot-time passphrase may
> > > fail if they take the rackmount UPS as *well*, and keep the machine
> > > powered at all times ;)
> >
> > The server should listen to the (encrypted/digitally signed) "Heartbeat"
> > of a password server through the net to prevent this kind of attack.
>
> That'll help prevent this sort of attack (although doesn't entirely unless
> you can guarantee that the password server cannot be taken at the same
> time) but also gives you a remote point of failure.

Right.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 19:26, venerdì 5 marzo 2004, Hans Spaans ha scritto:
> I'm just wondering, does that law applies on all databases or just on
> new databases. In the Netherlands laws about privacy only apply on new
> databases and for old databases the law of that time-frame only
> applies. I must note that the database must be registered with
> http://www.cbpweb.nl/

The italian law applies to all databases (containing personal data) and they
must be registered at www.garanteprivacy.it.

As I told before, there is a EU directive that enforces this logic. All UE
countries will have to comply with it in a few years.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 19:38, venerdì 5 marzo 2004, scott.marlowe ha scritto:
> > Unfortunately, the new Italian law forces us to take seriously into
> > account this catastrophic scenario and another one that is almost as
> > worring: an unfaithful SysAdmin that copies your data and sells them to
> > KGB. So, database encryption (and not disk encryption) is the _only_
> > answer.
>
> the only way for this to work is for it to be a "two key system" like the
> military uses for missile launch.
>
> One sysadmin as the "key" to the database box, but the data is encrypted
> before being sent to the database box on another system with another admin
> with another "key".  Preferably these two would never interact or know
> each other.

Well, this is not necessarly true. Data maintainers and SysAdmin performs
different tasks (accordingly to italian law):
- SysAdmins take care of the hardware and of the software. They should never
need to access data. They just need to access the RDBMS software and its
configuration.
- Just Data Maintainers need to access data.
This should allow us to have two password for two different tasks. So, there
is not any need to use the military scheme to enforce data security.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Stephan Szabo
Date:
On Fri, 5 Mar 2004, Silvana Di Martino wrote:

> Alle 20:14, venerd� 5 marzo 2004, Stephan Szabo ha scritto:
> > > Unfortunately, the new Italian law forces us to take seriously into
> > > account this catastrophic scenario and another one that is almost as
> > > worring: an unfaithful SysAdmin that copies your data and sells them to
> > > KGB. So, database encryption (and not disk encryption) is the _only_
> > > answer.
> >
> > But since your sysadmin (if not trusted) could go behind your back and
> > replace the database, any applications that are using the data, etc, I'm
> > not sure that's even sufficient.
>
> Replacing the RDBMS engine and/or the "client" application, would be useless:
> the "cracker" still need the password to access the encrypted data.

Only for data that's already there though, right?  What about any
additions (and possibly changes) made after that point?

Re: Database Encryption (now required by law in Italy)

From
"scott.marlowe"
Date:
On Fri, 5 Mar 2004, Silvana Di Martino wrote:

> Alle 19:38, venerdì 5 marzo 2004, scott.marlowe ha scritto:
> > > Unfortunately, the new Italian law forces us to take seriously into
> > > account this catastrophic scenario and another one that is almost as
> > > worring: an unfaithful SysAdmin that copies your data and sells them to
> > > KGB. So, database encryption (and not disk encryption) is the _only_
> > > answer.
> >
> > the only way for this to work is for it to be a "two key system" like the
> > military uses for missile launch.
> >
> > One sysadmin as the "key" to the database box, but the data is encrypted
> > before being sent to the database box on another system with another admin
> > with another "key".  Preferably these two would never interact or know
> > each other.
>
> Well, this is not necessarly true. Data maintainers and SysAdmin performs
> different tasks (accordingly to italian law):
> - SysAdmins take care of the hardware and of the software. They should never
> need to access data. They just need to access the RDBMS software and its
> configuration.
> - Just Data Maintainers need to access data.
> This should allow us to have two password for two different tasks. So, there
> is not any need to use the military scheme to enforce data security.

Sorry, but that's the wrong answer.  Once someone has root on a unix box
her can do ANYTHING he wants.  and he can cover his tracks.  If the
encryption takes place on his box, he can attach to the process doing the
encryption and /or replace it with a trojan copy of his own and get your
data.  The ONLY way to keep the data secure is  for it to be encrypted
elsewhere before it gets to the storage box.  If the box that stores it
encrypts, it, the root user on that box can impersonate anyone and any
process on that box to get to the data in mid stream.


Re: Database Encryption (now required by law in Italy)

From
Bruno Wolff III
Date:
On Fri, Mar 05, 2004 at 20:12:37 +0000,
  Silvana Di Martino <silvanadimartino@tin.it> wrote:
>
> BTW: if you have a USA-based company and collect info regarding Italian
> people, you have to comply with this absurd Italian law. Funny, isn't it?

Only if you are going to come within reach of Italian LE. I doubt Bush
will let Italy extradite and business people from the US who violate
this law.

Re: Database Encryption (now required by law in Italy)

From
Michael Chaney
Date:
> BTW: if you have a USA-based company and collect info regarding Italian
> people, you have to comply with this absurd Italian law. Funny, isn't it?

No, we don't.  We're not bound by Italian law, only US law.

Michael
--
Michael Darrin Chaney
mdchaney@michaelchaney.com
http://www.michaelchaney.com/

Re: Database Encryption (now required by law in Italy)

From
Grega Bremec
Date:
...and on Fri, Mar 05, 2004 at 02:31:50PM +0000, Dave Ewart used the keyboard:
>
> 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.

Darn, you made me shorten my hefty post into ten lines. :-(
Just when I I was beginning to like it the way it was... :)

Mind, this is not only in reference to LoopAES.

All I'm saying is that good local security _can_ provide for lack of any
kind of interactive unlock procedure during boot in case the piece of
information required to un(b)lock access to encrypted media can be securely
stored and used by the boot loader in a non-revelatory manner, for example
by pushing the authentication process one step down. One example of that
would be a PSK-protecting boot loader (for boot arguments) and some sort
of key-encrypted boot loader config file.

That way, even if someone can boot the Damn Thing [tm], they can not log
into the system and access the protected data, nor do they have access to
information required to access unencrypted data (passphrases, keys, ...).

Cheers,
--
    Grega Bremec
    Senior Administrator
    Noviforum Ltd., Software & Media
    http://www.noviforum.si/

Attachment

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 21:29, venerdì 5 marzo 2004, Bruno Wolff III ha scritto:
> On Fri, Mar 05, 2004 at 20:12:37 +0000,
>
>   Silvana Di Martino <silvanadimartino@tin.it> wrote:
> > BTW: if you have a USA-based company and collect info regarding Italian
> > people, you have to comply with this absurd Italian law. Funny, isn't it?
>
> Only if you are going to come within reach of Italian LE. I doubt Bush
> will let Italy extradite and business people from the US who violate
> this law.

I agree. We are still waiting the american pilot of the A3 Intruder that
crashed down a ropeway on our mountains in (I think) 1996 and killed 20
people. He was promoted the last year and still flies (but this time on _USA_
mountains, for our sake...).

Humor apart, there are already a few cases of privacy law violations of this
kind being examined by our authority. It looks like that the foreing web
sites that violated this law will be obscurated. Considering that this law
will slowly spread UE-wide, I will take it seriously even if I worked from
USA.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 23:23, venerdì 5 marzo 2004, Michael Chaney ha scritto:
> > BTW: if you have a USA-based company and collect info regarding Italian
> > people, you have to comply with this absurd Italian law. Funny, isn't it?
>
> No, we don't.  We're not bound by Italian law, only US law.

Unfortunately, that is not so easy. Consider this:
- you sell books online, like Amazon
- you collect personal data from your customers
- a part of your customers are from Italy (or from any other of the 25
countries of 2005 EU, something like 400 milion people)
- you violate the privacy law of these country
- they obscure your site (using their firewall), a technique already used
against porno web sites.
- you lose 400 milion potential customers and win a nice (extremely expensive)
trial for violation of an international law on online commerce.

It happened already. The new law (that I consider quite stupid) imposes
exactly this punishment to companies that violate it (plus a trans-national
criminal trial and a quite large fine).

Both USA and UE companies have to comply with WTO rules. There are
international agreements between USA and EU regarding online commerce and
these agreements states that a company in EU cannot violate the law on
commerce of USA if it operates on the USA territory and, of course, vice
versa. Nowadays, no one can play just for himself on this small planet, in
particular if he wants to sell his stuff to others.

Of course, you do not have to trust me. Ask your company's lawyer about this.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 20:34, venerdì 5 marzo 2004, scott.marlowe ha scritto:
> Sorry, but that's the wrong answer.  Once someone has root on a unix box
> her can do ANYTHING he wants.  and he can cover his tracks.  If the
> encryption takes place on his box, he can attach to the process doing the
> encryption and /or replace it with a trojan copy of his own and get your
> data.  The ONLY way to keep the data secure is  for it to be encrypted
> elsewhere before it gets to the storage box.  If the box that stores it
> encrypts, it, the root user on that box can impersonate anyone and any
> process on that box to get to the data in mid stream.

That's right, of course, but I think we have to consider what we actually have
to prevent, accordingly by law.

A "man-in-the-middle" attack to the encryption system or a
brute-force/dictionary-based attack to the password/data is a crime "per se",
both in Italy and in many other countries. The law does not impose on us the
burden to defend the end-user from a well-planned, well-performed criminal
act. This is the business of our Police. We just have to do our best to
protect our data from human curiosity, human errors and teenager hackers.

The italian law states exactly this: protect your data at the best of your
technological capabilities. Real crime is a police problem.

Anyway, even data encrypted on Mars would be vulnerable to a well-performed
brute-force attack. It is just a matter of computing resource and time.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Lamar Owen
Date:
On Friday 05 March 2004 03:34 pm, scott.marlowe wrote:
> Sorry, but that's the wrong answer.  Once someone has root on a unix box
> her can do ANYTHING he wants.  and he can cover his tracks.

This is what things like the capabilities system and SELinux are designed to
prevent in the Linux world.  As Fedora Core 2 will ship with SELinux
installed and enabled, it will become much more difficult for someone to
randomly get root and do damage.  It is quite simple with SELinux to prevent
any of the attacks you mentioned.  Root is no longer root.  Things on an
SELinux system, or a system fully implementing the kernel capabilities model,
can indeed be locked away from root, at least in network attached multiuser
mode.  This does, of course, make maintenance of the data more difficult; one
must be at the console in a special mode to do full maintenance.  But someone
remotely cracking root no longer is the threat they once were, when some
system like SELinux is in use.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

Re: Database Encryption (now required by law in Italy)

From
Gorshkov
Date:
On March 6, 2004 03:59, Silvana Di Martino wrote:

>
> Both USA and UE companies have to comply with WTO rules. There are
> international agreements between USA and EU regarding online commerce and
> these agreements states that a company in EU cannot violate the law on
> commerce of USA if it operates on the USA territory and, of course, vice
> versa. Nowadays, no one can play just for himself on this small planet, in
> particular if he wants to sell his stuff to others.
>
> Of course, you do not have to trust me. Ask your company's lawyer about
> this.
>

You are, of course, correct - but you're missing one thing.

When you connect to amazon.com from italy,  my understanding is that you're
(legally) conducting business in the USA, because that's where the
transaction actually takes place - that's where the servers are.

The reverse however should be correct - I should now be able to connect to an
Italian website from here in Canada, and not have to worry about my info
winding up in the hands of some @#*($&@#*( spammer :-)


Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 13:55, sabato 6 marzo 2004, Lamar Owen ha scritto:
> On Friday 05 March 2004 03:34 pm, scott.marlowe wrote:
> > Sorry, but that's the wrong answer.  Once someone has root on a unix box
> > her can do ANYTHING he wants.  and he can cover his tracks.
>
> This is what things like the capabilities system and SELinux are designed
> to prevent in the Linux world.  As Fedora Core 2 will ship with SELinux
> installed and enabled, it will become much more difficult for someone to
> randomly get root and do damage.  It is quite simple with SELinux to
> prevent any of the attacks you mentioned.  Root is no longer root.  Things
> on an SELinux system, or a system fully implementing the kernel
> capabilities model, can indeed be locked away from root, at least in
> network attached multiuser mode.  This does, of course, make maintenance of
> the data more difficult; one must be at the console in a special mode to do
> full maintenance.  But someone remotely cracking root no longer is the
> threat they once were, when some system like SELinux is in use.

A better, more structured architecture of permissions on Unix is a
long-standing need. It looks like SELinux is offering a new and interesting
approach to this problem.

Regarding this topic I have a dream: the hyerarchical permission architecture
of OS/400 (and many other IBM OSs for mainframe) ported to Linux. Just imagine
this: you have a omnipotent "root" who can access the machine from the
console only, a whole set of powerful, configurable administrators who can
act from the net, each of them devoted to administer a specific part of the
OS or of the File System, and finally a crowd of simple users, with
configurable permissions. Nobody would have more power of what it actually
need for his job, not even the root.

Would not it be a better (safer and more manageable) world to live on?

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 17:24, sabato 6 marzo 2004, Gorshkov ha scritto:
> When you connect to amazon.com from italy,  my understanding is that you're
> (legally) conducting business in the USA, because that's where the
> transaction actually takes place - that's where the servers are.

Well, there are two different and unrelated business operations:
- When you buy a book on Amazon, you are doing buiness in the USA, because the
transaction takes place in the USA (or, at least, so it looks like)
- When Amazon collects personal data regarding italian people in a wrong way,
is violating an italian law because the data collection regards italian
citizens and takes place in Italy. At least, this is what our law-makers
implicity states in the text of this new privacy law.

Anyway, the only reliable source of info about this topic is WTO. Is WTO that
rules these international aspect of business.

> The reverse however should be correct - I should now be able to connect to
> an Italian website from here in Canada, and not have to worry about my info
> winding up in the hands of some @#*($&@#*( spammer :-)

That is exactly what should happen.

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: OT: Database Encryption (now required by law in Italy)

From
Mitch Pirtle
Date:
Silvana Di Martino wrote:

> Regarding this topic I have a dream: the hyerarchical permission architecture
> of OS/400 (and many other IBM OSs for mainframe) ported to Linux. Just imagine
> this: you have a omnipotent "root" who can access the machine from the
> console only, a whole set of powerful, configurable administrators who can
> act from the net, each of them devoted to administer a specific part of the
> OS or of the File System, and finally a crowd of simple users, with
> configurable permissions. Nobody would have more power of what it actually
> need for his job, not even the root.

Great, then all of my linux users, thanks to the administrators in their
physical presence, would get an account with SECADM privileges.

(rimshot)

Re: OT: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 13:25, domenica 7 marzo 2004, Mitch Pirtle ha scritto:
> Silvana Di Martino wrote:
> > Regarding this topic I have a dream: the hyerarchical permission
> > architecture of OS/400 (and many other IBM OSs for mainframe) ported to
> > Linux. Just imagine this: you have a omnipotent "root" who can access the
> > machine from the console only, a whole set of powerful, configurable
> > administrators who can act from the net, each of them devoted to
> > administer a specific part of the OS or of the File System, and finally a
> > crowd of simple users, with configurable permissions. Nobody would have
> > more power of what it actually need for his job, not even the root.
>
> Great, then all of my linux users, thanks to the administrators in their
> physical presence, would get an account with SECADM privileges.
>
> (rimshot)

This would be a human act of will (a "betrayal"). It looks like that not even
God can protect humans from this (have you ever heard of "free will"?). This
would not be different from a Linux/Unix Root giving away its password. I
cannot see any way to protect ourselves from such a betrayal, neither with
technological tools nor in any other way.

BTW: you understandably suppose that administrators have the power to give
SECADM privileges to other users. This may be true or may be not. I cannot
remember which was the situation on OS/400 but I would not be surprised to
discover that ADMINs do not have such a power. Most likely, just a SECADM can
create a new SECADM. A strict division of powers is a fundamental concept of
any security system.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
"Peter Galbavy"
Date:
Silvana Di Martino wrote:
> Actually, the Italian law is an implementation of a EU directive
> strictly inspired to the existing UK law. It will affect all EU in a
> few years.

Perhaps, given the potential commercial necessities of this for larger
organisations, find out what Oracle and IBM propose doing or have
implemented ?

For strict comformance, you really should consult a local legal professional
for their opinion, and be prepared to pay for that protection.

Peter


Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 09:32, lunedì 8 marzo 2004, Peter Galbavy ha scritto:
> Perhaps, given the potential commercial necessities of this for larger
> organisations, find out what Oracle and IBM propose doing or have
> implemented ?

I do not know of IBM.

Oracle has a system similar to pgcrypto but more sophisticated. I do not know
if it can use encrypted indexes, encrypted dates and encrypted times (it is
likely but I did not tried, yet). It stores its "global encryption password"
into a system table in encrypted form. Only authenticated users can decrypt
data.

Something like that can be done with PostgreSQL, as well. The problem is that
I have to store somewhere a password in clear text (either the password used
to encrypt/decrypt data or the password used to decrypt this password).
Oracle has a built-in feature for encrypting/decrypting this password's
password.

> For strict comformance, you really should consult a local legal
> professional for their opinion, and be prepared to pay for that protection.

We are doing it. Unfortunately, our lawyer still have to discuss technical
problems with a technician (that is: me).

BTW: It looks like I'm the only one here facing this problem. That's
surprising, given the number of countries that have a law like the italian
one and the wide diffusion of PostgreSQL.

See you.
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
"Peter Galbavy"
Date:
Silvana Di Martino wrote:
> Oracle has a system similar to pgcrypto but more sophisticated. I do
> not know if it can use encrypted indexes, encrypted dates and
> encrypted times (it is likely but I did not tried, yet). It stores
> its "global encryption password" into a system table in encrypted
> form. Only authenticated users can decrypt data.

This can then be broken. Anything that does without some sort of human
intervention is waiting to be hacked one way or another.

> BTW: It looks like I'm the only one here facing this problem. That's
> surprising, given the number of countries that have a law like the
> italian one and the wide diffusion of PostgreSQL.

I cannot speak or read Italian, so any reference to an English version of
the legislation or analysis of it would be greatly appreciated.

As some background to my next comments, for those not in the EU, there is a
lot of inconsitency in the way that member countries implement EU
directives. These glaring differences sometimes, no scratch that: ALWAYS,
cost taxpayers dear, while the legislators and the civil and criminal
justice systems sorting issues out after the fact, and at great cost.

Two observations in this light;

1. Some countries within the EU still have national laws, unless I blinked
and they disappeared, that mandate some control over cryptography.
Historically, France was certainly one - anyone with current specifics ?
This leads to a potential conflict if the EU mandates in anyway that
countries must require _encryption_ (as opposed to string protection) of
personal data by data controllers (i.e. ever incorporated business and many
sole traders that I know of).

2. I have been unable to find, as an amateur with interests in the subject,
a *single* instance of a prosecution under Data Protection laws in the UK.
Lots of "enforcement by discussion and threat" and stuff, but no court time
to test the laws directly. Probably don't know the right places to look.
Again, anyone with real data for the UK and the EU in general for how
existing Data Protection laws have been enforced ?

rgds,
--
Peter


Re: Database Encryption (now required by law in Italy)

From
Date:
> BTW: It looks like I'm the only one here facing this problem. That's
> surprising, given the number of countries that have a law
> like the italian
> one and the wide diffusion of PostgreSQL.

This is normal because the task to encrypt database is usually done at
hardware/OS level. In general the security of data is about a complex of
measures: it's a set of requirements to both software protection and physical
protection. The easy way(from software's perspective) to deal with the
requirements is to encrypt the whole disk(which is not a database job alone
and that's why you have little response here). By encrypting the whole disk
one:
     a) avoids many pecularities of selecting which  fields, tables, etc
to encrypt and
    b) solves the issue of lost (or made accesible) storage device
itself: hard disk, tape, cd, dvd or the whole server - I know at least one
case when the whole server(s) was stolen from governmental organization with
VERY sensitive personal data(it remains unknown if thieves were aware of the
cost of the data they've got into their hands) while losing laptop PC's by
CIA and alikes seems to be a daily buisness.

When it comes to that kind of protection then the encryption is done by a
black box hardware capable of destroying  the key if a physical intervention
(to open the box with a screwdriver for example) is attempted.

Just a simple software solution relying on keeping keys in the server means
only that you may as well keep your data decrypted in the server and regard
it(server) as a secure black box:
    -    attempting to steal the server or open it and read data
should destroy the data. Or such a thing a stealing server or getting a
physical access to it should be made as expensive as decrypting data.
    -     all data coming in/out is decrypted/encrypted

Ideally your black box keeping the key(or the whole key hierarchy) is not
disposing the key to the outside at any time but performing the
encryption/decryption inside.
My former company I worked for was making a PCI cards for HDD encryption
using Dallas Chip as a key storage: not a very good solution but better than
nothing. A smart card chip protected from physical intervention is probably
one of the best available solutions nowdays: it can be used as an encryption
engine or to generate session keys. Anyway, the idea is to protect the key by
all means if the server itself can not be protected equally easily.
At first glance it seems to be rather easy to protect the server if the
server is not a mobile laptop but a stationary device. The point is that
protection must extend to backups for example: it means that overall
encryption of all files (even those written to the tape or another backupe
storage) is quite a good method to protect data "in one place".

Brgds,
Laimis


Re: Database Encryption (now required by law in Italy)

From
Joe Conway
Date:
Silvana Di Martino wrote:
> Oracle has a built-in feature for encrypting/decrypting this password's
> password.

Right, and this master password is only protected because Oracle is
closed source. It is not possible to do the same thing with Postgres
because you could find the master key (or the algorithm to produce it)
in the source code.

However this amounts to "security by obscurity", and anyone serious
about encryption will tell you it is insufficient. There is no way to
have cryptographically sound protection of your data using a key
embedded in the software like that.

Joe


Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 12:30, lunedì 8 marzo 2004, Peter Galbavy ha scritto:
> Silvana Di Martino wrote:
> > Oracle has a system similar to pgcrypto but more sophisticated. I do
> > not know if it can use encrypted indexes, encrypted dates and
> > encrypted times (it is likely but I did not tried, yet). It stores
> > its "global encryption password" into a system table in encrypted
> > form. Only authenticated users can decrypt data.
>
> This can then be broken. Anything that does without some sort of human
> intervention is waiting to be hacked one way or another.

You are right, of course. For having a reasonably robust system, (at least) we
should keep the "password's password" on a separated (and well-protected)
server and access via SSH or SSL when needed.

> I cannot speak or read Italian, so any reference to an English version of
> the legislation or analysis of it would be greatly appreciated.

Being italian law, addressed to italian speakers, no english translation is
available. I cannot translate it because of lack of time. Sorry...

> 1. Some countries within the EU still have national laws, unless I blinked
> and they disappeared, that mandate some control over cryptography.
> Historically, France was certainly one - anyone with current specifics ?
> This leads to a potential conflict if the EU mandates in anyway that
> countries must require _encryption_ (as opposed to string protection) of
> personal data by data controllers (i.e. ever incorporated business and many
> sole traders that I know of).

Our governement is discussing since a long time this topic and seems to be
possible that cryptography will be prohibited. How do they hope to reconcile
this prohibition with the requirement to use cryptography to protect personal
data is behind my ability to understand the human logic.

> 2. I have been unable to find, as an amateur with interests in the subject,
> a *single* instance of a prosecution under Data Protection laws in the UK.
> Lots of "enforcement by discussion and threat" and stuff, but no court time
> to test the laws directly. Probably don't know the right places to look.
> Again, anyone with real data for the UK and the EU in general for how
> existing Data Protection laws have been enforced ?

I can tell you for sure that we never had any actual prosecutions in Italy,
neither under the "old" law (675/96) nor under the "new" one (196/03). This
does not mean that we will not see any prosecution in the future, as well. A
company that violates the new law can receive a 35.000 euro fine and this
money can be a strong motivation for our governement.

See you
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Silvana Di Martino
Date:
Alle 17:29, lunedì 8 marzo 2004, Joe Conway ha scritto:
> Silvana Di Martino wrote:
> > Oracle has a built-in feature for encrypting/decrypting this password's
> > password.
>
> Right, and this master password is only protected because Oracle is
> closed source. It is not possible to do the same thing with Postgres
> because you could find the master key (or the algorithm to produce it)
> in the source code.
>
> However this amounts to "security by obscurity", and anyone serious
> about encryption will tell you it is insufficient. There is no way to
> have cryptographically sound protection of your data using a key
> embedded in the software like that.

Right. I completely agree. The only way to implement such a mechanism in a
open source product is to keep the password away from the RDBMS host. See my
previous messages for a plausible scenario.

See you

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

Re: Database Encryption (now required by law in Italy)

From
Robert J Carter
Date:
On March 6, 2004 03:59, Silvana Di Martino wrote:
>  pgsql-admin@postgresql.org

> Both USA and UE companies have to comply with WTO rules. There are
> international agreements between USA and EU regarding online commerce and
> these agreements states that a company in EU cannot violate the law on
> commerce of USA if it operates on the USA territory and, of course, vice
> versa. Nowadays, no one can play just for himself on this small planet, in
> particular if he wants to sell his stuff to others.

You are, of course, correct - but you're missing one thing.

When you connect to amazon.com from italy,  my understanding is that you're
(legally) conducting business in the USA, because that's where the
transaction actually takes place - that's where the servers are.

The reverse however should be correct - I should now be able to connect to an
Italian website from here in Canada, and not have to worry about my info
winding up in the hands of some @#*($&@#*( spammer :-)


Re: Database Encryption (now required by law in Italy)

From
Enrico Weigelt
Date:
* Silvana Di Martino <silvanadimartino@tin.it> wrote:

<snip>
> We just think it is easier and safer to encrypt the whole database, or even
> the whole disk, than try to understand what the law actually means.

BTW politicians should have to be enforced to tell people what their
laws really mean. Representants voting for some law they cannot explain
to plain people should get corporal punishment.

cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service
  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
---------------------------------------------------------------------
  Realtime Forex/Stock Exchange trading powered by postgresSQL :))
                                            http://www.fxignal.net/
---------------------------------------------------------------------

Re: Database Encryption (now required by law in Italy)

From
"Ryan J. Cavicchioni"
Date:
Enrico Weigelt wrote:
> * Silvana Di Martino <silvanadimartino@tin.it> wrote:
>
> <snip>
>
>>We just think it is easier and safer to encrypt the whole database, or even
>>the whole disk, than try to understand what the law actually means.
>
>
> BTW politicians should have to be enforced to tell people what their
> laws really mean. Representants voting for some law they cannot explain
> to plain people should get corporal punishment.
>
> cu

I may be late to the conversation. Sorry if I am but there are some
cryptography tools in the contrib/pgcrypto folder in the source tree.

Hope that helps.

- Ryan

--
Ryan Cavicchioni

GPG ID: C271BCA8
GPG Public Key: http://confabulator.net/gpg/ryan.asc
GPG Fingerprint: 83E4 2495 6194 0F66 ED85 22B4 4CC0 DA01 C271 BCA8

Re: Database Encryption (now required by law in Italy)

From
Bruce Momjian
Date:
Ryan J. Cavicchioni wrote:
> Enrico Weigelt wrote:
> > * Silvana Di Martino <silvanadimartino@tin.it> wrote:
> >
> > <snip>
> >
> >>We just think it is easier and safer to encrypt the whole database, or even
> >>the whole disk, than try to understand what the law actually means.
> >
> >
> > BTW politicians should have to be enforced to tell people what their
> > laws really mean. Representants voting for some law they cannot explain
> > to plain people should get corporal punishment.
> >
> > cu
>
> I may be late to the conversation. Sorry if I am but there are some
> cryptography tools in the contrib/pgcrypto folder in the source tree.

There is an FAQ item about encryption.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Database Encryption (now required by law in Italy)

From
Chris Browne
Date:
pgman@candle.pha.pa.us (Bruce Momjian) writes:

I owe you a patch on runtime.sgml for the summary I did on "Use of
Encryption."

I just sent it...
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78.  "I will not tell my Legions of Terror
"And he must  be taken alive!" The command will be:  ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>