NYCPHP Meetup

[Tim Lieberman]

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