Symmetric Key Cryptography
- In symmetric key cryptography, PartyA generates a key and somehow shares the key with PartyB.
- Now, all the communication between the two parties is encrypted using this key.
- Since no one else knows the key, they can not decrypt the data.
Public-Private Key Pair Cryptography
- PartyA generates a public-private key pair. PartyA never shares the private key with anyone. The public key is available to all.
- Two kinds of communications can be done through this key pair-
- PartyA sends a message to PartyB:
- PartyA puts a signature on the message using the private key. Its almost impossible to create the same signature on the same message since no one else knows the private key.
- PartyB has the knowledge of Public key. So, it does a computation of checksum on the incoming message and verifies the signature. This ensures that the message actually came from PartyA and it has not been tempered. This is explained below in "Digital Signing and Verification" below.
- PartyB sends a message to PartyA:
- PartyB encrypts the message using the public key. Nobody can decrypt it because no one knows the private key.
- PartyA is able to decrypt it using its private key.
- Self signed certificate = Name of the entity (PartyA) + public key + signed using private key. If it is signed by some Certificate Authority (CA) then that means that it is signed using the private key of CA.
- In short certificate is a name bound to a key.
Digital Signing and Verification
- Digital Signing
- Take Data(D) and run a hash on it giving a hash result(HR).
- Encrypt this HR using private key of the signer, resulting in HRe.
- This HRe is called signature.
- Signer also has a certificate(C) which contains the public key of the signer.
- D + HRe + C = digitally signed data
- Verification
- Run Hash on Data(D) to get hash result HR.
- Take the signature (HRe) and decrypt using public key of the signer, resulting in HR.
- If the HR in above 2 steps is equal that proves that the message came from the signer and the data hasn't been tempered with.
- Usually Data(D) is the certificate itself. This process guarantees that the certificate came from the right source.
Certificates
- If you look at a website's certificates you can find out a lot of information. Such as -
- Issued By (Certificate Authority)
- Issued To
- Valid From etc
- In the details tab, you see a lot of fields and their values.
- The orange fields, such as, version, issuer, public key etc are header fields and they are always there.
- The green fields may or may not be there. These fields are called extensions.
- Some of the extension fields are marked with exclamation mark - they mean that if you don't know how to process them - you should not use the certificate.
- You can use certutil.exe - a command line utility to do some operations on the certificates. For example, "certutil -dump abc.cer" will display all the contents of the certificate on the console. You can download a website's certificate by using "copy to file" feature for the certificate.
- Private keys are located usually inside ProgramData\Microsoft\Crypto\RSA. But this depends on OS, configuration and other details.
- IE uses the MS Crypto API to store the certificates but FireFox has its own store. You can access that by going to Tools->Options->Advanced->Encryption tab and then View Certificates button.
- Usually certificates are chained. You can identify the parent using "Issuer" and "Subject" fields. If the "Issuer" and "Subject" are one and the same, that means its a root level certificate. Usually a CA first issues a root certificate to itself. Then it uses this certificate to issue other certificates for other CAs.
Certificate Revocation List
- When you try to access a website which uses a certificate, the browser gets the certificate from that website and sees the Serial Number in the certificate.
- This serial number is then sent to a URL, which is usually the URL of CA. This URL is located in the "CRL Distribution Points" header value.
- If you go to this URL, you can download the *.crl file which contains a list of all certificates that have been revoked.
- If the serial number you received is in this list, then usually the browser lets you know that this certificate is not valid and what action you would like to take.
- Usually, it is a good practice to not take any further action as the certificate can not be trusted anymore.
- Since the revocation list can become really large, another method is sometimes used. Its a separate service (called OCSP) where you call the service and it only replies with Yes or No stating whether the certificate is good or not.
SSL Handshake
- Browser issues secure session request (usually, https://something)
- Server sends X.509 certificate containing server's public key.
- Browser authenticates certificate against list of known CAs. If CA is unknown, browser can ask for user action to proceed.
- Browser generates a random symmetric key and encrypts it using server's public key and sends to server.
- Browser and server now both know the symmetric key and rest of session proceeds using this symmetric key.
So, How does it all add up?
- CA signs a certificate with its private key and gives it to a website. The certificate now contains the public key amongst other information.
- When a browser requests some transaction on the website, the browser inspects the certificate and using the logic mentioned above (public key and checksum) it finds out whether the certificate was issued by the trusted CA. So just for this purpose, the browser doesn't need to go to CA all the time.
- The only thing that requires CA access by the browser is when it wants to validate whether the certificate has been revoked or not as mentioned above.
- If all is good, it shows a green signal suggesting the validity of certificate. Otherwise, it displays a warning or a red signal suggesting that the certificate couldn't be validated and warns user for further action.
- For future data transfers, SSL Handshake establishes a symmetric key known only to browser and server.