Digital Signatures
Equivalent to a hand written signature
Its an electronic verification of the sender. Uses asymmetric key encryption
Purpose:
- Authentification: The message was created and sent by the claim sender.
- Non-Repudiation: Sender cant deny having sent the message
- Integrity - Ensures the message was not altered in transit
- Bob (sender) generates two pairs of keys(public and private): Gives Alice (receiver) the public key.
- He generates a digest / hash by hashing his messages using a hash alogorithm and encrypts it using the private key generated in the previous step.
- He sends the digital signature together with the message to Alice.
- Alice decrypts the digital signature using the public key. If it fails to decrypt then she knows the sender wasn’t Bob.
- Once Alice gets the digest, she hashes the message using the same hashing algorithm used by Bob and compares the two digests. The signature is valid when the hash values are equal.
However digital signature doesn’t truly verifies the identity of the sender, as hackers may get their hands on the public key and intefere with signature together with the data itself.
Hashing
Creates a unique digital fingerprint data called digest / hash / message digest.
It is primarily used for comparison purpose not for encryption.
- You can’t reverse a hash to determine the original data. It’s not reversible, unlike in encoding (a different representation of an input).
- Fixed size.
It’s for these features that it is used for storing passwords
Digital Certificates
As mentioned in the digital signature section, digital signature does not verify true identity of the sender hence digital certificate intervenes. These are electronic credentials issued by a trusted third party. It verifies the identity of the owner and shows that the owner owns the public key.
Bob attaches a digital certificate to the signed message: It contains
- Owners name
- Owner public key and its expiration date.
- Issuer’s name
- Issuer’s digital signature
SSL Certificate
SSL stands for Secure Sockets Layer, a global standard security technology that enables encrypted communication between a web browser and a web server. SSL ensures a private “conversation” just between the two intended parties. So it’s basically a digital certificate of web server. It verifies identity of the web server and its public key.
- Browser request secure pages from the web server.
- Web server replies back with its ssl certificate (which contains its publick key) digitalLy signed by a third party or CA ( certificate authotity).
- The browser checks for the issuer’s (CA) digital certificate to validate it. It does this by running through its database containing various public keys (previously installed) of various Certificate Authorities.
- If the cerificate is valid – > its indeed signed by the said certificate authority, the browser lights up a green padlock at the address bar simply indicating that certificates really belongs to the web server.
- The browser generates a pair of symmetric secret keys, encrypts one of the keys using the web server’s public key and sends it over.
- The web server uses its private key to decrypt the message and obtain the secret key. Both parties uses the key to encrypt and decrypt any communication between them.
In this scenario we see how asymmetric and symmetric key algorithm works together.
- Asymmetric key is used to verify the identity of the owner and the public key so that trust is built.
- Once a connection has been established, symmetric key algorithm is used to encrypt and decrypt the connection between the two hosts.
SSL and the green padlock indicates that the connection is encrypted but does not mean that the website itself is secure.
SSL / TLS Handshake Protocol
Handshake protocal is involved with the top 3 layers in osi model and 1st in tcp/ip model
- client sends a message to the server containing : ssl / tls version, cryptogrtaphic algorithms and data compressing methods suported by the client.
- server responds with a message containing: cryptogaphic algorithm chosen from the list provided by the client, session id, its digital certificate and its pubic key
- client will contact server CA and verify the server digital certificate so as to established trust
- client sends a shared key encrypted with the server’s public key to the server.
- client sends a finished message encrypted with the shared secret key indicating the client part of hanshake is complete.
- server side responds with a final message encrypted with secret key indicating the handshake protocal is complete. once the handshake protocal is done, the client and the server can now exchange encrypted messages.
Leave a comment