Advice on securing a sensitive Access database

I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on
a server with multiple users linking to it from their individual PCs via
an Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.

3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.

I presume that the solution would include hardware and software
elements.

I would be grateful for any guidance.

Many thanks.
--
Les Desser
(The Reply-to address IS valid)

"Les Desser" wrote in message
news
I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on a
server with multiple users linking to it from their individual PCs via an
Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.

3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.

I presume that the solution would include hardware and software elements.

I would be grateful for any guidance.


If your data is really that sensitive/valuable then I would suggest using
Oracle or similar since Access security can be easily broken.

Keith.
www.keithwilby.com

"Keith Wilby" wrote in message
...
"Les Desser" wrote in message
news
I wonder if someone could give me some pointers on the following.

If your data is really that sensitive/valuable then I would suggest using
Oracle or similar since Access security can be easily broken.

There is another venerable DB that is used daily by the US Army, Airforce,
Navy and the FBI for the one of the very reasons you seek. After all, it was
originally invented to track the engineering data and the parts to the Space
Shuttle by Boeing, then later ported to the PC environment. I have used it
since 1983 and quite a few of my colleague developers use it for medical
records applications which require a similar security requirement.

www.RBase.com

Still very much alive and used worldwide where other solutions can't make it
work.



Keith.
www.keithwilby.com

Les Desser wrote:

I wonder if someone could give me some pointers on the following.

I need to securely encrypt an Access 2003 database currently sitting on
a server with multiple users linking to it from their individual PCs via
an Access 2003 front-end.

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.

I think you'd want a copy that is of use to someone. Hmmmm...zip it up
and put a password only the big cheeses know.

2. Ensure that only authorised users directly connected to the network
can access the database and preferably only via the designated Access
front-end database.

Network access rights.

Usually the front end is run from the C drive. What's more important?
The program/app? Or the data?


3. Authorised users cannot get a decrypted copy of the file via their
PCs - i.e. cannot use Explorer or similar to copy the file in decrypted
form.

Network access rights once again. Remove the Copy right.

I presume that the solution would include hardware and software elements.

Mostly OS elements.


I would be grateful for any guidance.

Many thanks.

Friction
http://www.youtube.com/watch?v=Mh9a5_3ATHY

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.


I have not used any strong DB security; but as others have pointed out,
someone with physical access to your serve can with time break any
encryption you apply. You need secure the server, at least in a locked room
in a building with some type of monitored alarm system. That way your random
thief would only get basic office equipment. Using Windows security; your
server hardware may be the only thing of value to an office equipment thief.
A more sophisticated thief may only take your backup media or better yet,
break-in though the internet.

In article , "paii, Ron"
Fri, 11 Apr 2008 08:48:26 writes

I need a hardware/software solution that will:-

1. Encrypt the database on the server so that a copy of it is of no use
to anyone. This is to cover if the server is stolen.


I have not used any strong DB security; but as others have pointed out,
someone with physical access to your serve can with time break any
encryption you apply. You need secure the server, at least in a locked room
in a building with some type of monitored alarm system. That way your random
thief would only get basic office equipment. Using Windows security; your
server hardware may be the only thing of value to an office equipment thief.
A more sophisticated thief may only take your backup media or better yet,
break-in though the internet.

I accept your comments and recommendations. My main problem still
exists even when physical security of the server has been addressed.
--
Les Desser
(The Reply-to address IS valid)

Hi again Les,

Security is depth is certainly the best way I can think of to approach
the issues surrounding any data confidentiality. There are many
factors to consider when approaching such a thing, and most of them
are situation dependant on how you address them. For this you need to
do a proper risk analysis, which I think is probably going beyond the
scope of this forum. If you want to approach such a thing I am happy
to try and steer you in the right direction, so just drop a note in
the forum here.

As for the 4k keys, you must understand that there is a difference in
cryptographic types (algorithms) used. Symmetric and Asymmetric. AES
is a symmetric cipher, commonly used with a 256bit key strength. A
symmetric cipher, in this case AES, is quite fast, safe, and
considered strong for securing information, but it suffers, like all
symmetric encryption, from a problem known as the 'Key Distribution
Problem'. Basically it means that you use the same key to encrypt and
decrypt the data. If you want to send the data to someone with a
symmetric cipher then in order for them to decrypt it they need to
know the same key you do - but you shouldn't transmit the key with the
data! So how do we get around this problem?

The answer lies in Asymmetric encryption. Asymmetric encryption allows
us to have a public and private key which are distinct and separate
from each other, but at the same time directly related to each other.
The way it works is that you can encrypt something with your Private
key (called signing in most instances), and anyone can acquire (safely
and without concern) a copy of your public key and see that the data
came from you. Only your public key can be used to decrypt the data
encrypted with the private key. Now if we reverse the situation, and
we encrypt the data with the public key, only the private key can
decrypt it, which means that anyone can encrypt something, send it to
you, and only you with the private key can decrypt it.

The difference between the two keys is one of information. The private
key contains enough information to be able to reproduce the public key
at will, but the public key is built in such a way that to reproduce
the private key is extremely difficult (but not impossible!). So, what
do we do to make the public key really secure? We use giant 4k keys
that make the problem so large / hard to solve that for all intents
and purposes it is unbreakable / considered secure. The problem with
Asymmetric encryption is that it is slow by comparison to Symmetric.
Slow by a long way.

So how do we solve the problem of your DB encryption? We use
Asymmetric to encrypt the Symmetric keys. The 'heavy lifting' of
encryption / decryption of the data is actually handled by the AES
cipher which is relatively fast, and only the decryption of the AES
keys is done with the slower Asymmetric cipher. This keeps the system
and data both relatively fast and safe, and also gets around the key
distribution problem.

So, crash course in cryptography aside, here are some links that I
have used for the different algorithms and components:

MD5 http://www.di-mgt.com.au/crypto.html#MD5
RSA http://www.di-mgt.com.au/crypto.html#dhvb
AES http://www.frez.co.uk/freecode.htm#rijndael

You will also find some useful code implementations he
http://www.freevbcode.com/ShowCode.asp?ID=3779

I hope that this gets you on your way, and you are successful in
implementing this for your needs. I will monitor this thread if you
need further help with this.

Cheers

The Frog

In article
, The
Frog Mon, 14 Apr 2008 00:45:10 writes

[snip detail]

So, crash course in cryptography aside,

Thank you for that. It was very clear and I actually understand it!

here are some links that I have used for the different algorithms and
components:

Thank you for all that. I will go through them in the next few days, but
it is your first post that I still need to study.

Thanks also for your kind offer of help.
--
Les Desser
(The Reply-to address IS valid)

Anytime. Glad I can offer a little help.

Cheers

The Frog

In article
, The
Frog Mon, 14 Apr 2008 00:45:10 writes

So how do we solve the problem of your DB encryption? We use Asymmetric
to encrypt the Symmetric keys. The 'heavy lifting' of encryption /
decryption of the data is actually handled by the AES cipher which is
relatively fast, and only the decryption of the AES keys is done with
the slower Asymmetric cipher.

Not sure if I quite follow that.

1. Data encrypted by AES key

2. AES key encrypted with Asymmetric public key (?)

3. AES key decrypted with Asymmetric private key (?)

4. Data decrypted by AES key

What have we achieved? The Asymmetric private key still has to be made
available.

I'm sure your previous post has the answer to this, but I can't quite
see it.
--
Les Desser
(The Reply-to address IS valid)