Database security (crosspost)

Sorry, the prior message was multi-posted.
Here's a cross-posted version.  Please disregard the other one.


Is there a way to create and encrypted database file?

What do people do when data security is important at the file level?  In
other words, you don't want anyone to be able to take the database file (or
files) and extract data from them.

Ideally, I want a file the is absolutely encrypted on disk and that is
decrypted for data access.  The problem, obviously, is that this would be a
very costly (cpu time) approach as you couldn't create a decrypted image on
disk (this would expose the data).

Are all database systems then, non-secure?

Thanks,

-Martin

Martin (0_0_0_0_@pacbell.net)  writes:
> Is there a way to create and encrypted database file?
>
> What do people do when data security is important at the file level?  In
> other words, you don't want anyone to be able to take the database file
> (or files) and extract data from them.
>
> Ideally, I want a file the is absolutely encrypted on disk and that is
> decrypted for data access.  The problem, obviously, is that this would
> be a very costly (cpu time) approach as you couldn't create a decrypted
> image on disk (this would expose the data).
>
> Are all database systems then, non-secure?

Everything is relative. For a small database, < 50 MB, it may be possible
to encrypt it entirely and only hold the decrypted version in main
memory. Then again, memory can be dumped.

For a 1 TB databae, encryption will have to be selective. Basically,
anything you want to search on, cannot be decrypted unless you are
prepared to take very long response times.

In SQL Server 2005, there are a lot of encryption enhancements, so that
you can encrypt individual columns with asymmetric and symmettric keys.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

> Everything is relative. For a small database, < 50 MB, it may be  possible
> to encrypt it entirely and only hold the decrypted version in main
> memory. Then again, memory can be dumped.

I've experimented with a small database flat-file database (non SQL, non
Access) and in-memory tables.  The process is horribly honerous.  In memory
tables, at least what I've been able to get to using something like VB6, are
not really setup to be full blown databases but rather a place to hold
temporary data it seems.  As such, there doesn't seem to be a way to load a
small database (consisting of a number of tables) into memory and have it
act as a database.

What occured to me is that, perhaps, one can create a RAM-disk on the fly,
tell it to be encrypted and move/copy the DB into it on application start.
Then the OS would take care of the matter?  On application termination the
RAM disk would be destroyed.

My application would more than likely be single user.  It made me wonder how
high-security DB's are handled.  It seems to me that data is, for the most
part, fully exposed.

-Martin

Martin  wrote:
> What do people do when data security is important at the file level?  In
> other words, you don't want anyone to be able to take the database file (o
r
> files) and extract data from them.

IMHO, the only way to protect a database in this way is not to give the
database to persons whom you don't want to have it.

For example, you could put the database on a hosted site that your
clients can access using only prescribed methods.  Create your own
authenticated SOAP web service on your site to give access only to data
to which the client is authorized.  Then you can use technology like
firewalls and HTTPS protocol to protect the database.  In other words,
features aside from the RDBMS itself.

Encrypting the database is a kind of barrier to crackers, but unless you
use one-way encryption (which precludes reading the data), you simply
can't protect the data from a brute-force attack if you give the
database to the attacker.  If they are motivated enough to get into that
data, they can use unlimited computational resources to crack your
encryption.

Regards,
Bill K.

Martin (0_0_0_0_@pacbell.net)  writes:
> What occured to me is that, perhaps, one can create a RAM-disk on the fly,
> tell it to be encrypted and move/copy the DB into it on application start.
> Then the OS would take care of the matter?  On application termination the
> RAM disk would be destroyed.

Yes, but will the RAM disk is active, the data is accessible unencrypted.

> My application would more than likely be single user.  It made me wonder
> how high-security DB's are handled.  It seems to me that data is, for
> the most part, fully exposed.

As I indicated, the key is to encrypt discriminantly.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

- but if high level security really does matter please be aware of the
easily accessible password recovery tools on the web!
For high level confidential data, some other database might be the solution
to consider.

Best regards
Niels K

"Martin" <0_0_0_0_@pacbell.net> skrev i en meddelelse
news:bK0mf.28502$7h7.362@newssvr21.news.prodigy.com...
> Sorry, the prior message was multi-posted.
> Here's a cross-posted version.  Please disregard the other one.
>
>
> Is there a way to create and encrypted database file?
>
> What do people do when data security is important at the file level?  In
> other words, you don't want anyone to be able to take the database file
> (or files) and extract data from them.
>
> Ideally, I want a file the is absolutely encrypted on disk and that is
> decrypted for data access.  The problem, obviously, is that this would be
> a very costly (cpu time) approach as you couldn't create a decrypted image
> on disk (this would expose the data).
>
> Are all database systems then, non-secure?
>
> Thanks,
>
> -Martin
>

Martin wrote:

> It made me wonder how
> high-security DB's are handled.  It seems to me that data is, for the most
> part, fully exposed.
>
> -Martin

High security means at all levels, including physical access. Your bank
doesn't give you their confidential data on a disk does it? That's why
they don't need to encrypt it in the database - because they can secure
and authenticate the access to the data.

--
David Portas
SQL Server MVP
--

"David Portas" < REMOVE_BEFORE_REPLYI
NG_dportas@acm.org> wrote in message
news:1134081329.397680.269910@g47g2000cwa.googlegroups.com...
> Martin wrote:
> 
most 
>
> High security means at all levels, including physical access. Your bank
> doesn't give you their confidential data on a disk does it? That's why
> they don't need to encrypt it in the database - because they can secure
> and authenticate the access to the data.
>
> --
> David Portas
> SQL Server MVP
> --
>

Ahh, but I bet they don't encrypt the backups.  They should.  Oracle 10G2
allows this.
Jim

> Is there a way to create and encrypted database file?

There are plenty of ways; they commonly don't actually provide any
meaningful form of security.

> What do people do when data security is important at the file level?
> In other words, you don't want anyone to be able to take the
> database file (or files) and extract data from them.

The only realistic method is to encrypt the data before submitting it
to the database.

Anything else that they try to sell you is snakeoil.

> Ideally, I want a file the is absolutely encrypted on disk and that
> is decrypted for data access.  The problem, obviously, is that this
> would be a very costly (cpu time) approach as you couldn't create a
> decrypted image on disk (this would expose the data).
>
> Are all database systems then, non-secure?

If they claim that their database system can manage the cryptography
for you, then yes.

Look for the book _Translucent Databases_ which has examples in
various languages for various databases.
--
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/emacs.html
"Now, suddenly,  I _am_ the  expanding Russian Frontier"  -- Commander
Ivanova
"But with very nice borders..." -- Dr Franklin

> High security means at all levels, including physical access. Your bank
> doesn't give you their confidential data on a disk does it? That's why
> they don't need to encrypt it in the database - because they can secure
> and authenticate the access to the data.

You are thinking about databases in their, shall I say,
 traditionalcorporate
/business application.

Let's say that you develop an application.  This application does some work
and needs to allow the user to save it to files.  Much like MS Word or
Photoshop let you save files.  Now, the application can be best written if
it can use database technology while doing its job.  However, the resulting
files need to be encrypted for security reasons.  There are many possible
reasons for this.  One may be that you don't want your competition to
benefit from your work product and extract data from your files.

The choices, as I see them, are:

1- Create a completely custom file format, re-invent the wheel and roll out
your own db-style code.  The file would be encrypted upon storage and
decrypted upon loading.

2- Use some sort of db system that is encryption-capable.  Something like
SQL server isn't a possibility because customer machines will not have this
available.

Yes, of course, with enough time and effort almost anything can be cracked.
And, of course, the astute might even be smart enough to dig through memory
for the data.  Those I see as extreme cases.  I am more interested in the
old "keeping honest people honest" scenario rather than the high-IQ hacker
scenario.

Makes sense?

-Martin