Cryptography is all around us. Surfing the web using SSL/TLS. SSH public key authentication. Or SAML authentication. Things get signed and encrypted all the time.
Recently I had to go through the process of integrating a SAML IdP with AEM (the SP). SAML is annoying in that it uses both signatures and encryption. And both parties have to exchange keys for this.
In this post I want to focus on the digital signatures. Understanding how signatures work will help you understand other things. Like SAML authentication with AEM. Should you ever find yourself trying to set that up. I will cover encryption in a follow-up post.
Jane is Deepti's business partner. Jane sends Deepti product data on a monthly basis. Deepti is the business owner. She has set up and endpoint to receive product data from Jane. Deepti's endpoint needs to do 2 things
Verify the senders identity.
Verify the integrity of the message.
To solve this, we are going to use digital signatures aka fingerprints.
Jane creates a public/private key pair. The private key is password protected. This whole thing relies on Jane keeping her private key safe.
Jane will publish the public key by putting it inside of an x509 certificate. The x509 certificate is the way Deepti will verify the authenticity of the public key.
Jane can start to send signed messages.
A signature is a hash that gets encrypted by Jane with her private key.
When Deepti receives the message & signature, she will decrypt the hash with the public key. Then compute the hash on the message she received. If they match, the message has not been tampered.
Because the hash gets decrypted with a trusted public key, the signature belongs to Jane. The assumption is the private key is not compromised.
We will build our own servlet to verify signatures the same way the SAML handler would.
Jane Creates, Signs & Sends
First Jane needs to create a key-pair and send Deepti the certificate. Jane could create a Certificate Signing Request (CSR). That a trusted Certificate Authority (CA) would put turn into a signed certificate. But Jane is on a budget, so self-signed certificates it is!
Jane gets prompted for a password to protect the private key. And then she will send the certificate jane_certificate.pem to Deepti. Deepti will store it in her TrustStore and send back the certificate alias which Jane will use.
Now Jane can begin to create messages
And sign them
Because she is using here private key, she will get prompted for the password. And finally, she can send it to Deepti's endpoint.
Deepti Receives & Verifies
Deepti has stored the certificate she received from Jane in AEM's TrustStore. The cert alias gets sent to Jane to use as the senderid.
Now Deepti's servlet needs to validate the signature and message. With the certificate stored in the TrustStore.
I am using Groovy here because its more fun 😊. If it piques your interest, check out my post on how to set it up in your AEM project.
And thats it! Only real way the signatures get compromised is if someone steals Jane's private key. Or if someone hacks Deepti's TrustStore.
If someone sits in the middle and intercepts the message, then yes, they can read the contents. Signatures don't ensure confidentiality. Only the integrity of the message and identity of the sender.
So now you know how a sender can sign messages. And the receiver can be confident that the message has not been tampered. And could have only originated from the sender.
What if Jane asked the intern to upload the message & signature. The intern will be unable to change the message. But they can read it. How do you prevent that? In my next post I cover encryption.