Joe Leo wrote:
The missing piece of info I guess I did not realize is that if I
encrypt some drive or part of it like folders or some system volume
that I had to have the decryption keys as part of it. I thought the
keys was encrypted as well. And, the only time it could be decrypted
is by me.
So, If I wanted to modify and update the encrypted data I would then
download it back to my machine and decrypt it and make whatever
changes and upload it back to the server. While uploading and
downloading the data it is already in encrypted form.
That sounds correct. In this scenario, you're just using the server as
a file server. Since your data are encrypted before leaving your
machine, you don't need to worry about encrypting it (again) in transit.
And, my understanding was that new data that is saved/updated by users
would be encrypted on the fly. Encrypted data that leaves the server
would be decrypted BUT then with SSL only the user would see the
requested data. This was my understanding of what tools like TrueCrypt
does. So, I think I'm totally missing the point of the product.
This is where things get tricky. If your users are submitting data
(over SSL), and the server is encrypting it for storage, you can use a
symmetric key pair, with only the encryption key on the server (you keep
the decryption key secure at your location).
Things break down, however, when you want to give other users access to
the data. Now, the server needs to decrypt the data before sending it
(which involves encrypting it via SSL, but you need unencrypted data to
feed to the SSL mechanism). Now, even with symmetric keys, you need
both keys on the server. Once you have encrypted data + the decryption
key on the server, the encryption is meaningless, since if anyone
compromises the server, they have all the information they need to
decrypt the original data.
Generally, if you're trying to communicate sensitive information via a
web based application, you want to look at the following areas:
- The host security of the server. Is the box hardened? Are you
running old, vulnerable versions of server software? Do you have a
strong password policy, or are you using SSH keys for authentication? Do
you trust the people who have physical possession of the server?
- The security of whatever web-based application is managing the
data. If I can break your web-app, then I can steal your data (even if
it's encrypteded on disk!)
- The protocol security of the protocols used to communicate with
the server. You should be using SSL (for web) and SSH (for shell access
and file transfer services) -- otherwise you run the risk of a
man-in-the-middle stealing your passwords, and subsequently your data.
If those three areas are properly addressed, you should be fine.
If the data is encrypted on disk, that's fine -- but as soon as one of
the above three is broken, your on-disk encryption is essentially
worthless. Which of course means that before any of those are broken,
it's probably meaninglessly redundant.
Note, there's a forth concern: The security of the people who are
allowed access. Are you sure that user X isn't actually a spy. This
gets into the Authorization problem, which is probably going to get
handled in your web app. If you can limit people to accessing only the
data they need, you limit your exposure. This is a non-trivial problem,
but there's a lot of good reading you can do about it.
-Tim
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
