Let's say I have sensitive data in the database server that needs to be encrypted (i.e emails, etc..) and I want to make sure that in the event that the server is compromised, the attacker shouldn't be able to decrypt these data (at the very least make it harder).
I've read some solutions online, and it seems like I can either
Use Hardware Security Modules (i.e. Amazon KMS/Vault) to having a separate server handle encryption/decryption.
Use Public Key Encryption (where the public key in database server encrypts data, and a private key is stored in separate server that solely handles decryption)
What are the tradeoffs of each other and which one would you choose?
Related
I'm looking for USB token solution for asymmetrical decryption purpose. The server has encrypted sensitive data with periodically rotating data encryption key (DEK), which is stored alongside with the encrypted data, encrypted itself with pre-distributed public key of the USB token (KEK).
The user (web browser client) logins to the single page application with username and password. User then inserts the USB token, which will trigger the following sequence:
Retrieve the encrypted DEK's from the server
Decrypt the DEK's with USB token private key
Retrieve the data from the server with the DEK's
I have looked into solutions like Yubikey, but it seems to be more focused on the user authentication than cipher services. What is the correct product to implement hardware based cipher in portable format? Expensive HSM is out of question, as multiple users should posses an instance of the portable token. Also, each instance should contain the same private key.
Nice idea, however you are having a few issues
Decrypt the DEK's with USB token private key
Currently no browser supports using decrypting by pkcs#11 (smart card or usb token keystore protocol) directly.
The browsers can use a stored keypair to authenticate and that's it. (if I missed something, please correct me).
Though you could use some local utility(non-web) to decrypt using a smartcard (gpg, openssl,...)
Also, each instance should contain the same private key.
Most of the serious smart cards allow generating a new private key, but you not importing own key material (at least the ones I had). So it is difficult to create multiple smart cards with the same keypair
What you could do is encrypt the DEK for a set of public keys
If they are tied to just one specific device, when do they change?
If they are device specific, how is that I can check my email on multiple computers or smartphones? If each computer has a different public key and a different private key, how can each successfully decrypt the message?
Sorry if this question is layman.
There are several good explanations online of public key cryptography. This is a pretty good one I recently came across. The key thing to know about public key cryptography (without getting into a huge amount of detail) is that you have two keys: with your public key (which you can share, hence the name), I can encrypt things that can only be opened with your private key. Both you and the server have a public key, thus you can encrypt messages back and forth. This is encryption -- that is, it is entirely to keep the conversation between the server and client secret, and away from prying eyes.
This is entirely separate from the reason that you are able to log into a website from multiple devices! For this, you are typically using a password. That is what is common among all your devices that allows you to log in -- your input.
No, key pairs are not tied to a device.
There are standards for the encoding and storing public and private key information so that a key pair can be exported from one application and imported into many others. Of course, not every application or operating system that might generate key pairs supports these standards or permit this operation, but most do.
Encrypted email is not commonplace, and even today, setting up email encryption is harder than it needs to be. So, if you (or your system administrator) didn't do anything deliberate, like generating a key pair, and purchasing a certificate for your public from a certifying authority, then exporting the key store to your various devices (or the analogous activities for PGP), I doubt you are using "encrypted email."
Most mail servers support "transport encryption", where TLS ("SSL") is used to keep your mail (and mail service password) private. But this is different than encrypted email. Encrypted email using S/MIME or PGP will protect your email while it's stored on servers or on your client, and on any links between mail servers that don't use TLS.
I have a webserver application which receives uploaded files, encrypts and decrypts them using AES256. I encrypted them so a potential hacker, who somehow got into the storage, can't do anything with the files. At the moment every file is being encrypted using the same hard-coded key.
Is it more secure to encrypt every file with an other random key stored in a database, maybe hashed (and salted, too)? Does this even provide a higher level of security? Or can it be worse to store such keys in the database?
key storage is a rather fundamental problem and hard to solve without rather special hardware.
as long as you store the keys on same machine as the encrypted data, an attacker will get both. that doesn't fundamentally change if you just have more keys.
you can't hash / salt the keys either, as hashing is a one-way function and with just the stored hash you yourself (or your app) would not be able to compute the key, so this is pointless.
if practicable, you could enter the key manually when the app server starts, so the key just lives in RAM, not on disk. make sure it doesn't get paged out to swap partition.
if you could encrypt the files clientside (before upload), so only the user has the keys, that would be safer...
I'm encrypting some data that needs to stay on the client, and so will the Salt, Key and IV. Is there a standard way of handling this data on the client to prevent people from discovering it and encryption your data?
I can think of plenty of things to obscure them, but there must be an industry standard way of dealing with this issue.
There's no additional security risk if the IV and salt are known. IV's are safe to store in the clear, and salts are to help prevent precomputation and rainbow tables.
So you're really just talking about the key. There's a couple solutions, each with it's own tradeoffs. In your question, you only mention you need to encrypt data on the client. Does the client not need to decrypt?
If this is a Windows client, you can use the Data Protection API to protect the key under the users credentials.
Protect the key with a passphrase. If you don't mind entering a passphrase each time the client needs the key, this can offer reasonable protection, and it's supported in most cryptosystems like OpenPGP.
If the client only needs to encrypt, you can use a hybrid approach with public keys (like OpenPGP). In this case, you only store the public key on the client, and the private key somewhere safe. When you encrypt data, you'll generate a random symmetric key, and encrypt that under the client's public key. Now if someone compromises the machine, they won't be able to decrypt any of the session keys.
Use specialized hardware like a hardware security module or smart card. This is the most expensive route, but depending on your threat model might be viable.
Scenario:
Multiple clients to upload files to server over HTTP/S.
Files are to be encrypted with company public key, for later decryption with company private key on a different environment. On upload, files are dropped (encrypted with company public key) on server.
Going the other way, company has to send documents back to clients. Each document is encrypted using public key of client and posted to the company server for retrieval. Client logs in to server over HTTP/S and grabs encrypted file. Once document is on client machine, they are to decrypt it using their private key.
Questions:
- What is the best way to store the client public keys such that the application can easily grab these at encryption time? If a key server, where should the key server reside?
- Once client has grabbed the encrypted file and downloaded it to their environment, is there an opensource option to decrypt the file?
This is ideally done in a Microsoft environment using ASP.NET. Any additional components, including keyserver are ideally opensource or failing that, affordable to a non-profit.