I have a customer who is sending a Security key. The encryption they are using is triple DES. Every Assertion they send has a signature value which needs to be validated to give them necessary privileges. Can you give me a sample code which does this?
Encryption and signing are two different animals. Triple DES is a symmetric key method (same key used for encryption and decryption). Digital signatures, on the other hand, use asymmetric keys (private/public key pair), where the signature is computed using the private key, and can be validated using the public key. So if your customer wants to include signatures in XML they send you, then they need to provide you with their public key.
For encryption, what is typical in SAML is to use XMLEncryption, which defines an XML format for including encryption key information and encrypted data in your SAML messages. Since exchange of a static symmetric key is problematic -- if it's intercepted, the interceptor can both encrypt and decrypt any messages -- what can be done instead is to use a dynamic symmetric key that gets generated anew for each message, encrypt the message using the key, then encrypt that key with the public key of a private/public encryption key pair and send it along with the message. The encrypted symmetric key can only be decrypted using the private half of the key pair used to encrypt it.
So the most significant difference here, from a key perspective, is that for signing, the customer holds the private key and must share the public key with you, while for encryption, you hold the private key and must share the public key with the customer.
If you want to validate the signature on the SAML Assertion or any of the Signable XML Objects, the OpenSAML WIKI has more information:
https://wiki.shibboleth.net/confluence/plugins/viewsource/viewpagesrc.action?pageId=3277047
You can look for 'Signature Verification Examples'.
This blog post also has an example as well:
https://blog.samlsecurity.com/2012/11/verifying-signatures-with-opensaml.html
To obtain a 'credential' for validation, see here:
https://blog.samlsecurity.com/2011/03/getting-credentials-in-opensaml.html
For info on how to unmarshal XML into an Open SAML object, see here:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaCreateFromXML
Related
There are password managers that encrypt passwords and data on the client side before storing it on the server.
I understand the Symmetric and Asymmetric Encryptions on a basic level. With Asymmetric Encryption, it requires the Public key of the other user to encrypt it so only him/her can decrypt it with the Private key.
I don't understand how that would happen for a group or even a single user where both the encryptor and decrypter need the data/password.
Thanks for the help.
Typically you encrypt the data itself (the password) with a random symmetric key. You then encrypt that key with each public key you want to provide access. Since passwords are small, in principle you could just encrypt the key directly with the public key, but it's pretty common practice to do the two-step process. Asymmetric encryption is very slow, and not convenient for use on large pieces of data. And if you have a large number of public keys, it's much better to just have a small piece of data (a symmetric key) encrypted multiple times rather than the whole data set.
If it's just a single user, there's no reason for asymmetric encryption. You'd just use symmetric encryption with a single key.
I've been searching a lot but nothing hit the spot, they are questions about JWE key management.
Scenario:
Server wants to send sensitive data to client, and it chooses to encrypt the data with a symmetric algorithm by a symmetric key, i.e, Content Encryption Key (CEK).
Client will retrieve the CEK to decrypt the encrypted data, but the CEK can't be sent as a clear text together with the encrypted data, so the CEK will need to be encrypted.
Approach:
The JWE specification defines different key management modes as follows
Key Wrapping: the CEK is encrypted for the intended recipient using a symmetric encryption algorithm.
Key Wrapping Diagram
Key Encryption: the CEK is encrypted for the intended recipient using an asymmetric encryption algorithm.
Key Encryption Diagram
Direct Key Agreement: a key agreement algorithm is used to pick the CEK.
Direct Key Agreement Diagram
Key Agreement with Key Wrapping: a key agreement algorithm is used to pick a
symmetric CEK using a symmetric encryption algorithm.
Key Agreement with Key Wrapping Diagram
Direct Encryption: a user-defined symmetric shared key is used as the CEK (no key derivation or generation).
Direct Encryption Diagram
Question:
What are pros and cons of each mode?
Under what circumstance will each mode be preferable?
Any help or advise would be appreciated, thank you very much.
See this answer for the difference between the key management modes and when to use each.
Is it possible to share encrypted data between a few (dynamic count) users without decryption on the server side?
For example:
We have secrets managing back-end
User A creates a secret, encrypt it somehow and send to the server for storing
User A wants to give access to this secret to the user B
User B now can get secret from the server, but ...
how can they decrypt this secret?
Here is an idea I have now:
Make 2 back-ends:
One for storing encrypted data and manage access between users
Another one for storing public key for decryption data
Here is what I'm concerned about here:
Server-owners can get a public key, get encrypted data and decrypt that data. I don't see any way to manage (include sharing public keys) between users when the server doesn't know which key decrypts data.
Perhaps anybody knows how lastpass, passbolt or any others services solved this problem?
You seem to have a misunderstanding of how public and private keys work.
For a given public/private key pair, anyone can encrypt data using the public key, but only the owner of the private key can decrypt the data.
So to pass data between users, each user should first:
create a public/private key pair
upload their public key to the server
If user A wants to send data to user B, they would do the following:
pull user B's public key from the server
encrypt the data using B's public key
upload the encrypted data to the server.
The server now holds the encrypted data, but it cannot decrypt it because it does not have B's private key, but only the public one.
User B can now pull the encrypted data from the server and decrypt it with their private key.
Note that this only deals with encryption. It does not address issues of authentication, i.e. ensuring that data comes from a known source.
This scheme can be made more secure by issuing certificates on each user's public key from a trusted authority and storing each user's certificate on the server, and by having users apply a digital signature to messages they encrypt by using their private key. The receiver of a message can then use the sender's public key and certificate to verify the signature.
I am creating an application where I need to store client's information(Like their API Keys and API Secret to access my service, along with other confidential information).
Now, in the database, I want to store these in the encrypted format. In this regard, I decided to with symmetric key cryptography, AES in specific to encrypt the details.
However, for security purposes I want to use a different AES encryption key on a per client basis, so that even if the DB is compromised, all the data cannot be decrypted using a single key.
However, due to obvious reasons, I do not want to store my private keys in the DB with the encrypted informations.
So, I cannot seem to decide how to store my keys, especially since I need to have a binding that which key belongs to which client.
How can I achieve this, and which is the best approach in scenarios like this?
Use a KDF to derive an encryption key from the users password and then use this key to encrypt their private information.
When any action is to be taken that requires their API secret or whatever other private data you are storing, simply request the users password and use it to derive the key again and use the key to decrypt.
If you want users to be able to change their password, add an intermediary random key for each user and use this key to encrypt their data. Use the key derived from their password to encrypt the random key. Then when changing the users password, you only need to decrypt and re-encrypt the random key.
I have the need to store private keys for multiple users, so that my server application can sign files on their behalf.
I want to store the private keys securely, but I couldn't find best practices around this. If I was storing a password I would salt+hash the password to make a hash that can't be easily turned back into the password. However, with a private key I need to store it in a way I can later retrieve it.
I was thinking I would encrypt the private key and then store it in my database. I originally thought each key would be encrypted with a different password (based on some properties of the user). However, those properties would most likely be stored in the database, so if my database got leaked then the attacker has everything.
I could encrypt all private keys with a single password that is only known to my application. Then an attacker would have to steal my database, and my application to do any harm.
Is there a technique/best practice I'm missing?
You could encrypt the private key with a symmetric key based on the users password. Simply store an additional salt and perform the password "hash" to get a separate key. Then use that as key for encrypting the private key. Note that it is required to use a Password Based Key Derivation Function (PBKDF) such as PBKDF2, bcrypt or scrypt to create a secure password hash (given the normal security level of a password).
If the user is not online at the time that a signature needs to be generated, then you should indeed protect the passwords in a sense that only you / our backoffice can decrypt the keys. You can use some user ID + your own secret key to calculate an encryption/decryption key. You may even want to generate a separate RSA key pair to perform hybrid encryption decryption.
Storing private keys on behalf of users is a very dangerous practice. There are a lot of ways for the private key to become exposed (e.g. side channel attacks). To do it professionally you should really be using an HSM somewhere in the process. If this is for any serious data, please consult a professional and a lawyer.