Based on my reading, we use both the certificate and a public key to encrypt the assertion, and to decrypt the assertion, we have to use the private key to decrypt it. I do not want to share my private key with my client, Is there other way to not provide the private key? I want to keep the private key, encrypt my assertion and give the response to my client, the client will use the public key instead to decrypt my message, does this thinking work at all?
Thank you.
The private key is just a very long number and is used to decrypt. The public key is just a very long number and is used to encrypt. Only the corresponding private key can decrypt what a public key encrypts.
A certificate (X509 public certificate) wraps the public key and the private key in identity information. The certificate is digitally signed by a certificate authority to say, to the best of its knowledge that the key belongs to who it says it belongs to.
You give your public key to your client. They verify it's from you by checking the digital signature on its certificate and they encrypt information with your public key.
You then decrypt that information using the corresponding private key which you never ever give to anyone.
It's all about Public Key Infrastructure (PKI).
I want to keep the private key, encrypt my assertion and give the response to my client, the client will use the public key instead to decrypt my message
From the text I assume you're implementing a SAML IdP.
Actually you need the client's SP public key to encrypt the assertion for the SP. And then sign the assertions with your (IdP) private key.
The SP must validate the SAML assertion signature with the IdP's public key and then they may decrypt the assertions with their SP private key.
So indeed the private keys stay with their owners.
Related
I am working with Asymmetric Cryptography (RSA & ECC). I have a very fundamental question when it comes to public key exchange or at least my understanding of the mechanism.
Considerations
client called C1
server called S1
algorithm: RSA (asymmetric)
threat: Man in the Middle
objective: transfer of sensitive information over the network (can be data or symmetric keys for hybrid encription)
What I've read so far
C1 creates a pair of RSA keys and makes an API call sending in the public key to S1.
On getting a request with the client's public key the server (S1) generates a RSA key pair and sends it back to the client (C1).
Now that the key's have now been transferred, C1 encrypts the data (cipher text) using the server's public key, sign's the cipher text with client's private key and makes an API call.
The server receives the request that contains the cipher text, uses the client's public key to validate signature, uses the server private key to decrypt the data, performs some operations, generates the response, encrypts the response using the client's public key, signs the response cipher text with server private key and returns the response.
How can the Man in The Middle Attack is possible?
in the initial call, let's say the hacker intercepts the first call that the client (C1) makes, generates a RSA key pair and sends the server the Hacker's public key instead.
The server returns back the server public key and the hacker intercepts the server response and stores the server's public key and then returns hacker's public key to the client.
The client assumes the Hacker's public key is in fact the server's public key, encrypts the data, signs it and sends it back.
The hacker intercepts that call as well and it decrypts the data, modifies it and encrypts it with the server public key, signs it with Hacker's private key and sends it to the server.
The server verifies the cipher text and tries to decrypt it and it all works since the server has hacker's public registered as the client's public key.
Now this out to be very easy to crack, the hacker (Man in the Middle) can read sensitive information and can also modify the request that can lead to malicious operations on the application server.
I am sure I am missing something in this flow since RSA and such interaction is so widely used. Can someone please point out what have I missed and if I haven't missed out anything, how can I protect the system against such attacks
When I use a keygen tag the browser generates a key pair. The public key is sent to the server, it creates a certificate and returns this certificate to the browser, but where is a private key and why does the browser seem to store it? Does browser compare private key with public key before accepting certificate? There are another reasons?
I'm trying to understand more about X.509 Digital Certificates. There seems to be lots of contradiction around. I am using Bouncy Castle to generate a key pair, using
public static void SaveToFile(X509Certificate newCert, AsymmetricCipherKeyPair kp, string filePath, string certAlias, string password)
{
var newStore = new Pkcs12Store();
var certEntry = new X509CertificateEntry(newCert);
newStore.SetCertificateEntry(certAlias, certEntry);
newStore.SetKeyEntry(certAlias,
new AsymmetricKeyEntry(kp.Private), new[] { certEntry });
using (var certFile = File.Create(filePath))
newStore.Save(certFile, password.ToCharArray(), new SecureRandom(new CryptoApiRandomGenerator()));
}
This saves the generated certificate to disk. Some articles tell us there is no need to password protect the certificate as there is no PRIVATE KEY stored in there. Then this article says the certificate does indeed contain the PRIVATE KEY.
I guess I have two questions that will hopefully help me understand this:
If I generate my keys in this way, should the password be the SAME as the passphrase for the PRIVATE KEY?
Do I distribute the X.509 certificate to prove the PUBLIC KEY is mine (being paired to my name in the certificate) or should the certificate be kept as safe and secret as the PRIVATE KEY and what use is a self-signed certificate?
A PKCS#12 file can contain both the certificate and the private key. They are, however, stored as separate, distinct objects. The certificate itself has the public key embedded within it. Since the certificate only contains the public key, it is considered "public" as well. You can feel free to distribute the certificate, as it does not contain the private key, which should be kept confidential. This is the basis of the security in asymmetric cryptography.
Because a PKCS#12 file contains both items, it is encrypted with a password to protect the private key within it. That said, you would use the private key to prove that the certificate you distribute belongs to you. For example, through the use of a digital signature on a document.
Hope that helps!
Certificate is actually the block of information which binds your identity (i.e. your name, email, whatever else) to some public key. It is public so everyone can know that this key belongs to you.
So when you will sign something they will know that actually you signed this.
The other thing is validating certificate - that's for what trusted root certificates are used.
Private key is your own secret information, and MUST be kept secret.
Can anybody explain me a sense of passing a public key along with signature which is practiced in SAML 2.0? As I know signature is needed to make sure the message was not intercepted by someone, so I need to make sure the public key I'm validating the signature with is pertained to the sender, which in case of in SAML 2.0 I can get with metadata beforehand. However if I take a public key from the message in run-time, how can I know it is not intercepted and other interceptor's public key is included?
You not only want to validate that the public key matches the signature, you also want to validate that the public key itself is valid. This is generally done through a certificate chain, where each certificate in the chain is basically a signed public key. You need to ensure that each certificate is valid (has not expired, has not been revoked) and that you trust the signers of each certificate. Be careful who you trust and pay attention to revocation.
I apologise for mixing notions but my knowledge of assymmetric web service security is shallow.
Right, I've got a java key store containing my private key and a customers public key.
When calling the customers web service I get an error message in return, saying:
"The signature or decryption is invalid".
We have found out that the public key I have in the key store and which is sent upon request, is different from the public key the customer has on its server. Somehow I have given the customer a different public key than the one I have in the key store.
What I would like to do is to regenerate the public key based on my private key in the key store, and send it to Mr Customer again. Is it possible to do so?
To be honest, this is exactly what I did by means of a keytool statement. Result, a file with .cer extension. Is the file with .cer the public key, or what?
Any advice is appreciated.
Solved it:
Above I said I tried to regenerate the public key from the key store, but I wasn't sure this was the right way to do it.
Anyhow, I provided Mr Customer with this newly generated public key and ask them to install it on their server. It worked, we've matching public keys. I used the following keytool command to regenerate the public key:
keytool -export -alias [name of private key in keystore] -file [path
to output] -keystore [path to .jks keystore]
Normally you do have the private key together with a certificate (chain) in the keystore. If you simply retrieve the first certificate from the chain with the same alias as the private key, you should have the correct certificate.
It does not hurt to check this by signing some arbitrary data with the private key and verify it with the public key from the ceritificate of course. Signature.initVerify() should even take a certificate directly. Otherwise, you could compare the (hash over the) modulus of the public and private keys as well.