So far most of our clients (online retailers and banks) have been reticent of placing any parts of theirs applications to a public cloud, although this could be a very cost effective manner to deal with temporary demand upsurge (end of month, holidays etc.)
We could place middle tier on a cloud so that no information is persisted in the cloud, or so that only non-sensitive data is stored there.
What are the best practices in this case?
Are there any regulations that I should be aware?
What are the biggest threats?
The best solution is to use cryptography.
You have the choice of public key cryptography: encrypt your data with a public key, put it "on ze cloud", then when you retrieve it, decrypt with your private key. Even better, if the data only transits through you, you can only have the public key and only your client has the private key.
Or symmetric cryptography, in which case you need the key, which will help encrypt and decrypt.
Symmetric cryptography algorithms are much faster, but if the scenario I mentioned above applies (ie, the client can have the private key), definitely go for it: you won't even be able to read the data without the client's consent.
Related
The use case is a user has a metadata that needs to be encrypted so when they sign-in a protected and stored object "encrypted" will be "checked" to verify the object information coming in plaintext is equal to what is in the encrypted object.
The question is, is it more appropriate in an Azure Key Vault to give each and every user a key with public and private key ability. Or, just use a single key that will encrypt the object that is stored and just un-sign/decrypt the object when it is accessed.
To me, the object is what is necessary to be encrypted and doesn't really relate to how the key is encrypted hence a universal 1 key to many approach.
The other approach makes sense too but I would have to create a hell of a lot of keys in order to facilitate such an approach. Is 1000's or millions of keys resulting in a key per each user appropriate?
What are the advantages or disadvantages of each other.
I think the same practice would apply to JWT token signing.
I think its better to have one key and on a regular basis rotate the key.
For example, like they do in ASP.NET Core Data Protection API (I know you are using node) where they every 90 days (by default) replace the current key with a new one, and the old one is still kept to allow decryption of old data. In .NET they call this the key-ring, that hold many keys.
I did blog about this here.
Also, do be aware that using some SDK's with Azure Key Vault, they try to download all secrets at start-up, one-by-one. That can be quite a time consuming if you have many secrets.
I'm new in node.js and I need to implement digital signatures.The Scenario is that, a user "A" will send some data by signing it with its private key (Stored on local machine) on to the server. So any other user "B" can verify it by decrypting the data with public key (Stored in DB on server) of "A".
Now following are my questions.
How to generate public private keys?
How to store private key on local machine?
How to sign data using private key and how to verify it using public key?
I found the below flow diagram on google. You can use this to get a grasp of he functionality. You can use this library to implement your signatures. Not sure if this solves your problem or not, but I hope it will help you in getting some clarity.
How do I force AWS KMI to rotate a key after a compromise? It seems I can instruct AWS to automatically rotate keys once a year. But on demand, if compromised - doesn't seem possible. Specifically, the PCI-DSS requirements:
3.6.5
a) Do cryptographic key procedures include retirement or replacement (for example, archiving, destruction, and/or revocation) of cryptographic keys when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key)?
b) Do cryptographic key procedures include replacement of known or suspected compromised keys?
(When you say KMI, I guess you mean AWS KMS.)
This is a valid question. The way to rotate keys manually is to create a new key and change the alias from the old key to the new one. Unfortunately, most AWS resources use the key id, so you have to assess which one is still using the old one.
If you use Infrastructure as Code tools such as Terraform or Pulumi, you just need to taint the KMS resource, so it will be recreated with a new ID and if you did everything right, e.g. used the alias-based data queries in Terraform, you just need to run the pipelines for those resources, and you are good to go.
How do I force AWS KMI to rotate a key after a compromise?
Key rotation doesn't mitigate compromised key data.
Key rotation is a mechanism to prevent encrypting too many chunks of data (there is a math about relation between amount of encrypted data and probability of key revelation)
Basically the key rotation creates a new version of the key for new encryptions, but KMS will allow decrypting any ciphertext encrypted with the older key version.
See:
https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html#rotate-keys-manually
Unfortunately, most AWS resources use the key id, so you have to assess which one is still using the old one.
When using manual key rotation, the application needs to know which key is the current one (e.g. using an alias), but the ciphertext needs a reference to the key id/arn to decrypt.
But on demand, if compromised - doesn't seem possible.
By default the KMS key doesn't leave the hardware. There is no way the KMS key itself is compromised, so maybe an automatic rotation is feasible having all the advantages (keeping the same ARN/ID/alias)
However - the KMS is meant for envelope encryption, KMS is used to encrypt the random data-key or a service-specific key, which can be leaked theoretically. Then you need to create policies to manage this risk
We're bringing up a webapp on EC2. Our passwords are held with a strong one way hash algorithm (SHA256, many iterations).
But what do people typically do for the rest of the data. Email addresses, birthdays, names and addresses.
We're based in the US and don't keep any financial or healthcare data. Just user profiles -- I believe there are few legal requirements, but what do people actually do.
We run EC2 app servers, MongoDB and and Amazon MySQL RDS instance. Performance is a consideration (we're expecting to have to scale out by necessity).
You could encrypt the rest of the user data before storing it. If it's not protected or sensitive data, and you're not running a site that's likely to be targeted, you can probably rely on standard security techniques when transmitting the data (e.g. SSL). But, if you would like to store the data more securely, here is a resource discussing Public-key cryptography
Here is a resource discussing performance implications of an encrypted MySQL DB:
https://security.stackexchange.com/questions/11683/how-to-improve-performance-of-encrypted-mysql-database-on-linux-backend-server
Here is an example discussing a similar use case:
How to store private encrypted user data in the database, but make them available to other chosen users?
Here is the model we are using to store the CC details how secure does this look?
All our information is encrypted using public key encryption and the keypair is user dependent (its generated on the server and the private key is symmetric encrypted using the users password which is also Hashed on the database) So basically on first run the user sends in his password via a SSL connection and the password is used with the addition of salt to generate an MD5 hash, also the password is used to encrypt the private key and the private key is stored on the server. When the user wants to make a payment, he sends his password. The password decrypts the private key, and the private key decrypts the CC details and the CC details are charged.
If the user's password is secure enough to protect the private key, why not skip the private key and use password (via a suitable key derivation algorithm) to encrypt the credit card number? Unnecessary complications definitely do not improve security.
This scheme doesn't use the public key for anything, indicating that an asymmetric algorithm is out of place here.
This ties the credit card's security to the strength of the user's password, which varies from user to user and is generally weak. It's better to creating your own symmetric encryption key, keeping that safe, and then doing a bunch of complicated stuff that experts invented, involving initialisms like CBC, CTR, and IV.
I am not sure if you store card number and private key files together. It seems like by just using user password to encrypt private key file you are opening the door for dictionary style attack if the encrypted private key files are available.
Not sure why you want to use public key cryptography which can be pretty slow. Also the model of 1 key pair per user may not scale (how many files, can you generate parameters for public key operations). Note that you may have abusive behavior - people checking to see if their list of stolen cards are good.
You could still prevent any use of card number when user is not present by adding your own master secret and deriving key schedule from combination. In general most merchants can't follow this strict requirement as there is a valid need to use card number when user is not present.
If you just want user specific keys (and you must use a different IV every time), then you can go the openssl EVP_BytesToKey route and pass a different salt each time with the master secret from which the encryption key and iv will be derived (and they will be different for each user).
Finally use of payment instrument is protected by just user password as described. Some users choose weak passwords. So you may want to use additional proofing to ensure card belongs to user - some of this is for your own good as you can fight friendly fraud chargebacks and keep your real fraud chargebacks low.
I agree with erickson that if the public key isn't used there is no point in doing asymmetric crypto.
As always the problem here is a key-management problem. The insecurity arises from not knowing how to safely hide the key that decrypts the data.
Im not sure if it is possible, but if you can afford it buy a hardware security module and let you HSM manage the keys, or encrypt all customer (private) keys with the HSM master key.
If you cannot, you should find a suitable place to store your "master" key, a possible example is the windows store (if that is a possibility). However, I most admit that i dont really know how secure the windows store is.
You may want to take a look the Payment Card Industryies "Payment Application DSS"" https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
It may help make some decisions for you.