I need to create a SAML2 assertion for a business partner we work with, who now requires a SAML2 SSO. We would be the identity provider.
They sent us their Public Key. We created a public key and sent ours to them. During the creation step, we had the option to exclude the private key and we did so.
I am not sure which combination of keys, and which form of the key (public or private), is used in the signing phase. What do we do with their public key? What do we do with our public and private keys? Do I have to create another version of our key that includes the private key?
Would someone care to offer a simple step by step explanation of a generic signing process, making clear which form of the key is used, and when?
First off. You do not give your private key to another entity. The whole point of the private-public key system is that you dont need to share you private key.
Signing is done with your private key and verified using your public key.
Encryption is down using theirs public key and is decrypted using their private key.
Related
At the moment, I am investigating the possibilities to use ZeroMQ with Curve to secure traffic between my publishers and subscribers.
I have successfully implemented a pub sub system which is using CZMQ.
At the moment, my publisher is encrypting the data he wants to send with his private key and subscribers can decrypt this data using the public key of the publisher. This is more 'authenticating' data than 'encrypting' data. Because when there is a Man In The Middle he can still decrypt all the data because the public key of the publisher is public.
I'm coding in C with the latest version of ZeroMQ and CZMQ.
My publisher.c
zctx_t* zmq_context = zctx_new();
zauth_t* auth = zauth_new (zmq_context);
zauth_set_verbose (auth, true);
zauth_configure_curve (auth, "*", CURVE_ALLOW_ANY);
zcert_t* pub_cert = zcert_load("cert.key"); // private key of publisher
void* socket = zsocket_new(zmq_context, ZMQ_PUB);
zcert_apply(pub_cert, socket);
zsocket_set_curve_server(socket, true);
//start publishing from here
My subscriber.c
zctx_t* zmq_context = zctx_new();
zcert_t* sub_cert = zcert_new();
zcert_t* pub_cert = zcert_load("cert.pub"); // public key of publisher
char* pub_key = zcert_public_txt(pub_cert);
void* zmq_s = zsocket_new(zmq_context, ZMQ_SUB);
zcert_apply(sub_cert, zmq_s);
zsocket_set_curve_serverkey(zmq_s, pub_key);
//start subscribing to topics and receiving messages from here
From this point, the publisher is encrypting all the data with his private key and the subscribing is decrypting all the data with the public key of the publisher. I would like to swap this system.
So, I would like to encrypt all the data with the public key of the publisher and decrypt all the data with the private key of the publisher.
I have tested it and changed the zcert_load("cert.key") to zcert_load("cert.pub") in my publisher.c.
I also changed this code in my subscriber.c:
zcert_t* pub_cert = zcert_load("cert.pub"); // public key of publisher
char* pub_key = zcert_public_txt(pub_cert);
to this code:
zcert_t* pub_cert = zcert_load("cert.key"); // private key of publisher
char* pub_key = zcert_secret_txt(pub_cert);
When I run my publisher and subscriber with these code changes, the publisher is constantly giving me the message: CURVE I: cannot open client HELLO -- wrong server key?
My question: Is it possibile to use a public key for encrypting data (publisher socket) and the private key for decrypting data (subscriber socket) with the architecture of ZeroMQ and CZMQ ?
Many thanks in advance,
Roy
I think you're misunderstanding the ZeroMQ CURVE mechanism. There are two great articles written about it by Pieter Hintjens, one is theoretical, where you can find this:
Clients and servers have long-term permanent keys, and for each connection, they create and securely exchange short-term transient keys. Each key is a public/secret keypair, following the elliptic curve security model.
To start a secure connection the client needs the server permanent public key. It then generates a transient key pair and sends a HELLO command to the server that contains its short term public key. The HELLO command is worthless to an attacker; it doesn't identify the client.
The server, when it gets a HELLO, generates its own short term key pair (one connection uses four keys in total), and encodes this new private key in a "cookie", which it sends back to the client as a WELCOME command. It also sends its short term public key, encrypted so only the client can read it. It then discards this short term key pair.
At this stage, the server hasn't stored any state for the client. It has generated a keypair, sent that back to the client in a way only the client can read, and thrown it away.
The client comes back with an INITIATE command that provides the server with its cookie back, and the client permanent public key, encrypted as a "vouch" so only the server can read it. As far as the client is concerned, the server is now authenticated, so it can also send back metadata in the command.
The server reads the INITIATE and can now authenticate the client permanent public key. It also unpacks the cookie and gets its short term key pair for the connection. As far as the server is now concerned, the client is now authenticated, so the server can send its metadata safely. Both sides can then send messages and commands.
So the keys you generate here are not used directly to encrypt data, they are only used to authenticate parties. The handshake process between client and server produces real encryption (and authentication as in MAC) keys that are used to encrypt the data. So if the only concern you have is MITM, you're already protected.
But you can also be concerned about rogue clients, your current scheme allows anyone to connect. This is where the second article by Pieter Hintjens can help you with "The Ironhouse Pattern". The critical part is to disable CURVE_ALLOW_ANY and tell server where to look for client public certificates:
// Tell authenticator to use the certificate store in .curve
zauth_configure_curve (auth, "*", ".curve");
Then you generate client key on the client (once! not calling zcert_new() for every connection), transfer its public part to the ".curve" directory of your server and load (on the client) that key instead of calling zcert_new().
If you want to make life a bit easier (not needing to transfer public keys from client to server for each client), you can create a "golden" client key pair, get its public part into the ".curve" store and then (via a secure channel, of course) copy the secret key on every client that needs to connect to your publisher.
If a user have 2 pairs of public and private key, how can the server that has the public keys know which one to use? The server should encrypt the message using the public key to that private key, however how does it know?
No. SSH does not do Encrypt&Decrypt, but Sign&Verify sequence.
The server sends some data, client signs them using its private key and server can verify the data using all of the public keys it has stored in authorized_keys file.
But in real world, there is optional phase before doing all the above. The client sends also the public keys to match correct public part on the server.
OpenSSL's rsautl allows signing with a private key. This is without a hash. Then recovering the signed file with a public key.
I've looked at CryptCreateHash/CryptSignHash/CryptHashData but I'm not sure how to do it. I believe those functions will only sign the hash of the data, not the data itself.
Is there any way I can sign with the private key and no hash involved?
Edit: Made necessary changes from jww's recommendations.
I have generated a self signed certificate using the CertCreateSelfSignCertificate function. This yields a PCCERT_CONTEXT.
How can I export the certificate stored in the PCCERT_CONTEXT variable with only the public key? I want to do this, to send it to other parties in the network, so these are able to encrypt messages using the public key.
I thought this was a straight forward option, but it isnt.
No need for a pfx.
The certificate is present inside the structure CERT_CONTEXT : just save the content of the buffer pointed by the member pbCertEncoded and whose length is the value of the member cbCertEncoded.
Moreover, the public key from this certificate is directly present in the CERT_CONTEXT structure : pCertInfo->SubjectPublicKeyInfo. For example, you can import it using CryptImportPublicKeyInfo and then call CryptEncrypt to encrypt data.
With these two options, you have all what is needed to start encrypting messages. Of course, the private key must be kept safe to be able to decrypt encrypted data.
Looks like you will need to first put the certificate into a certificate store and then export it using PFXExportCertStoreEx passing dwFlags of 0 (i.e. not setting EXPORT_PRIVATE_KEYS).
P.S. nothing is ever straight forward when dealing with cryptography libraries, be it CryptAPI, JSSE, OpenSSL... it's always a nightmare.
Are the exported private keys gotten by executing gpg --export-secret-keys still encrypted and protected by their passphrase? This seems to be the case but I can't find anywhere that explicitly confirms this.
If the exported keys are still encrypted then is there anyway to get the pure, unencrypted private key (like you can for the public segment)?
Exported secret keys are encrypted by default, however --export-options export-reset-subkey-passwd will produce an unprotected export:
When using the --export-secret-subkeys command, this option resets the passphrases for all exported subkeys to empty. This is useful when the exported subkey is to be used on an unattended machine where a passphrase doesn't necessarily make sense. Defaults to no.
Are exported secret keys still protected by their passphrase? You could find the answer to this so easily by exporting and then importing a secret key.
GnuPG has no simple way to export a private key in the way you describe. I can only hope you have a good reason for wanting to do this, and that you're aware of how dangerous it is to let the bits and bytes of an unprotected private key touch a disk. That said, the only option I see is to remove the passphrase before exporting...
gpg --edit-key KEYID
> passwd
> *(Press Enter twice, i.e., use a blank passphrase)*
> save
PS: This should be moved to Superuser; it's off-topic here.
Yes secret keys are encrypted after exporting. Once you've imported the private key file via the following command:
gpg --import <name of your private key>.pgp
It will prompt you to enter the correct passphrase (same passphrase used to create the private key in the first place).