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
Related
Here is context:
I am using PGP to encrypt messages in a chat web app. After going through some articles, I get brief idea how PGP works and here is how I am doing it with openPGPJs :
Client(web browser) generate the public/private key-pairs and send public key to server to store it.
Sender use receiver's public key to encrypt data and send it.
Receiver use their own private key to decrypt the message.
As a chat app I need to store all messages and decrypt them when user wants to see old message. decryption of messages need the private key. here the client is web browser which neither can store the private keys for long nor can keep them safe. so I decided to store the private key on web server. Now client(web browser) asks server for the private key whenever decryption of message needed.
Considering PGP an End to End protocol, storing private key on server is vulnerable. my question is:
How PGP encryption works for web based applications where client is not able to keep private key safe and confidential?
Is it Okay to store private key on server?
Is there any better way to do this?
Thanks for any suggestions.
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?
If I want to encrypt data on a server, and send it to a client program which I have implemented and sent to the customer, is there anyway that I can store the decryption key and algorithm in the client program, without risking that reverse engineering my client program will enable the user to decrypt all the data I send.
That is, I want my client program to control what it decrypts and what not.
Thanks
Jeeji
You can hard-code the algorithm with no risk. The security must be based in the secrecy of the key, not of the algorithm.
To secretly store the decryption key, you can use a keystore.
I don't know which language you are using, but Java includes its own keystore, and for C you get a keystore through NSS. To open these keystores you will need a password that the user can type in when the client application starts up.
If your client runs on linux and gnome, then you could also use Gnome's keyring, in which case the user will not need to type the password to open the keyring (the log-in password is also used to open the keyring).
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'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.