Symmetric Key Encryption (Private key Encryption)

1. Same key is used between client and server to encryt and decrypt message
2. Copy of key exist at both ends
3. First time the copy of key generated should be sent securely to otherside.
4. Public Key Encryption(Asymmetric Encrytion) is used to get the copy of the symmetric key for the first time
5. Thoughts may arise if I could share key securely for the first time why don’t I use the same methodology but it is resource-intensive
6. Advantage is The Encrytion and Decrytion is faster compared to Asymmetric Key Encryption
7. Disadvantage is Key needs to be transferred for the first time and Key should be stored securely

Asymmetric Key Encryption (Public key Encryption)

1. Uses Public and Private Key
2. Encrypted with one key and decrypted with other key. The Client uses public key to Encryt and Server uses private key to decrypt.
3. Public key would be shared and to recieve encrypted message from client by public key
4. This similar to Safe(Public Key) and Key(Private Key), When you send data it would be encrypted using public key similar to
   safe which doesnot needs a key to lock. The Private key in server could unlock using the key it holds.

Man-In-Middle-Attack

1. Man in middle generates his own public key which is available to client
2. Client used public key provided by man in middle and sends his data
3. Man in middle decrypts using his private key and makes a genuine request by encryting public key to server
4. To address this issue certificates were used

Certificates

1. The main purpose of the digital certificate is to ensure that the public key contained in the certificate belongs to the entity to which the
   certificate was issued, in other words, to verify that a person sending a message is who he or she claims to be, and to then provide the message
   receiver with the means to encode a reply back to the sender.
2. This certificate could be cross checked and confirmed with certificate authoritiy

Certificate Authoritiy(CA)

1. A CERTIFICATE AUTHORITY (CA) is a trusted entity that issues digital certificates, which are data files used to cryptographically link
   an entity with a public key. Certificate authorities are a critical part of the internet’s public key infrastructure (PKI) because
   they issue the Secure Sockets Layer (SSL) certificates that web browsers use to authenticate content sent from web servers.
2. The role of the certificate authority is to bind a public key of Server to a name which could be verified by browser to make sure the response is from genuine server
   Certificate Authority validates the identity of the certificate owner. The role of CA is trust.
3. Certificates must contain Public Key which could be cross-checked with Certificate Authority(CA)
4. CA would be mostly big companies like Symantec, google which acts as thirdparty to reassure trust.
5. Self-Signed Certificate where you uses your own server and client to generate certificate. CA doesnot comes in play in Self-Signed Certificate
   The above method may open door to man in middle attack
6. Root Certificate is something which you would get when you use Self-Signed Certificate with your custom CA. Root Certificate would be available in
   all client system which access data with server

Communication over HTTPS(HTTP over Secure Socket Layer)

1. SSL is web servers digital certificate offered by third party.Third party verifies the identity of the web server and its public key
2. When you make a request to HTTPS website, the sites server sends a public key which is digitally signed certificate by third party or
   Certificate Authority(CA)
3. On receiving the certificate the browser sends the Certificate with public key to third party to check whether the certificate is valid
4. After verifiying the certificate the browser creates a 2 symmetric keys, one is kept for browser and other for server. The key is sent by
   encrypting using webservers public key. This encryted symmetric key is sent to server
5. Web server uses its private key to decrypt. Now the communication happens using shared symetric key.

Typically, an applicant for a digital certificate will generate a key pair consisting of a private key and a public key, along with a certificate signing request (CSR)(Step1). A CSR is an encoded text file that includes the public key and other information that will be included in the certificate (e.g. domain name, organization, email address, etc.). Key pair and CSR generation are usually done on the server or workstation where the certificate will be installed, and the type of information included in the CSR varies depending on the validation level and intended use of the certificate. Unlike the public key, the applicant’s private key is kept secure and should never be shown to the CA (or anyone else).

After generating the CSR, the applicant sends it to a CA(Step2), who independently verifies that the information it contains is correct(Step3) and, if so, digitally signs the certificate with an issuing private key and sends it to the applicant.

When the signed certificate is presented to a third party (such as when that person accesses the certificate holder’s website), the recipient can cryptographically confirm the CA’s digital signature via the CA’s public key. Additionally, the recipient can use the certificate to confirm that signed content was sent by someone in possession of the corresponding private key, and that the information has not been altered since it was signed.

The server gives the client a one-time-use number (a nonce) that it combines with the username, realm, password, and URI request. The client runs all of those fields through an MD5 hashing method to produce a hash key.

It sends this hash key to the server along with the username and the realm to attempt to authenticate.
Server-side the same method is used to generate a hash key, only instead of using the password typed into the browser, the server looks up the expected password for the user from its user DB. It looks up the stored password for this username, runs in through the same algorithm, and compares it to what the client sent. If they match then access is granted, otherwise, it can send back a 401 Unauthorized (no login or failed login) or a 403 Forbidden (access denied).

Steps

1. Client makes request
2. Client gets back a nonce from the server and a 401 authentication request
3. Client sends back the following response array

    (username, realm, generate_md5_key(nonce, username, realm, URI, password_given_by_user_to_browser)) 
   

4. The server takes username and realm (plus it knows the URI the client is requesting) and it looks up the password for that username in DB. Then it goes and does its own version of

    generate_md5_key(nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
   

5. It compares the output of generate_md5() that it got with the one the client sent, if they match the client sent the correct password. If they don’t match the password sent was wrong.

It doesn’t require sending the username and password across the wire in plaintext. It is also immune to replay-attacks, as it uses a one-time number from the server.

Lets assume, Alice sent a message and digest pair to Bob. To check the integrity of the message Bob runs the cryptographic hash function on the received message and gets a new digest. Now, Bob will compare the new digest and the digest sent by Alice. If, both are same then Bob is sure that the original message is not changed.

Step by Step Action

1. client sends a request for an access-protected resource, but an acceptable Authorization header field is not sent
2. server responds with a “401 Unauthorized” status code and a WWW-Authenticate header field (the digest-challenge)
3. client sends another request for the same resource but containing a Authorization header field in response to the challenge (the digest-response)
4. if the authorization is not successful, go to step 2; otherwise the server proceeds as normal.

When Creating a certificate the first thing we do is creating a public and private keys. The Keys generated using java keytool or either by using keystore comes with a self signed certificate which could not be verified with CA. To win third party trust we get our public key signed with someone who is in common between thirdparty and data provider(server). This common entity is nothing but Certificate Authority(CA). To Apply for certificate we should create a CSR Request along with organization name, common name (domain name), locality, and country details.

Certificate Signing Request
A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.

The CSR is signed by the applicant’s private key.This proves to the CA that the applicant has control of the private key that corresponds to the public key included in the CSR.

How does a CSR looks like?

-----BEGIN CERTIFICATE REQUEST-----
MIIC5jCCAc4CAQAwcTELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCXRhbWlsbmFkdTEQMA4GA1UEBxMH
Y2hlbm5haTESMBAGA1UEChMJbXVnaWwub3JnMRIwEAYDVQQLEwltdWdpbC5vcmcxFDASBgNVBAMT
C211Z2lsdmFubmFuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9alda8sBOwSPXBOV
IyWD2bgn96RkCcoP1hNE7wsV1sus6mGFpptcF9qu6NZib+7acjRRjFnC5yTgzVOBLse0c3/EQ8H4
KZ+AAgye2++kFmdfwCjeoPeylUaYL2hEdb/cfSIJD4tulpuuocQf1N/X6+Z7W2ojzz9KpCkVhxYv
iuk+V2/zE5Z+kTwDVEPw/t9FKYTkf4+Viv+AGnyZHI3ZjgfLhccLaVL/kxJ8Y62wBC/muFK4CN92
xotBoTj3u7eQyoKb+NsaEvvQK+8+CYacjwMrsrMSPEmyHEAjmfWFkBi/4ZBF1vWhL9tBYZaXqjk5
0npE8fZTEOexO+hNeZVUQwIDAQABoDAwLgYJKoZIhvcNAQkOMSEwHzAdBgNVHQ4EFgQUV9G4Cp5/
QslDtFRjFOXcjj5kYRkwDQYJKoZIhvcNAQELBQADggEBAAejlSzDMUuAbqSe3zNxOADSTJCqhsJU
FE+0F0lxJlkKB6cDcxSvujoDoCuARk0RF0yLfnQz54qUPjWcPWnawLs9nZF/nzFf/ylF3J41fgVX
VveyKPc7TG40S5zGI5R1Y0zpW0hE/O2vZ4kdD1ZaO7UaUmFPZUcGhJWdf2QJh7enEhK6Z+FM19B/
RTySjmDIYKyMAgh65IDqutJD89FcrQx0UcAK0WCe6xR5dylg0FNiEw4GDorJF+HlMp2YXkUuYHNZ
RAZBvjqoic4CyZ60/HhXUruStn7ElB1hga10HyfGanclmfX2+vU5W+ulkhj1xvo4JHJC4AlmKdFZ
fm69MwU=
-----END CERTIFICATE REQUEST-----

Certificate Authority
Whether it is one-way SSL or two-way SSL, certificate-based communication starts through a handshake mechanism that works on the principles of mutual trust. This trust is rooted at the top level with a root CA who is a certified, highly regulated authority that is trusted and authorized to issue and sign digital certificates.

There are multiple layers of CA with the top-most Certificate Authority known as Root CA which is the most trusted body which can issue Root Certificates and is considered as the primary authority to be trusted. Under Root CA, there can be n number of Intermediate CAs which are themselves trusted by Root CA and are eligible and authorized to issue certificates.

Typically, your web browsers store Root CAs certificates in the trust store, and whenever any secure website is accessed, SSL handshake mechanism works by utilizing this trust store to validate any subsequent intermediate or leaf certificates.

//Generate a Keystore with public and Pricate key along with selfsigned certificate
>>keytool -genkey -alias mugilcert2 -keyalg RSA -keystore “D:\mugil2.jks”

//Exporting a self signed certificate which came along in above step(which is are of no use)
>>keytool -export -alias mugilcert2 -file “D:\mugil2jks.cer” -keystore “D:\mugil2.jks”

//Generate a CSR request to be sent to CA
>>keytool -certreq -alias server -file csr.txt -keystore “D:\mugil2.jks”

Self-Signed Certificate
A self-signed SSL certificate is an SSL Certificate that is issued by the individual using it. It’s issued with software that the user has and controls. This can be good for testing environments but it’s got some major drawbacks, but essentially what you need to know is that when a browser receives an SSL Certificate it’s looking for it to be issued by a party it trusts(CA). When you sign your own certificate you’re essentially vouching for your own identity. The primary operational difference between a self-signed certificate and a CA certificate is that with self-signed, a browser will generally give some type of error, warning that the certificate is not issued by a CA.

Root Certificate, Intermediate Certificate and Leaf (Server) Certificate
Root Certificates are available in the trust-store or root store and a certificate validity is confirmed only if its chain of trust reaches to a trusted CA.Below are the list of companies that holds Root to certificate and could offer intermediate certificates.

1. IdenTrust
2. DigiCert
3. GoDaddy

The above companies has tie-up with companies like google or mozilla which install trust store or root store in users systems.. Root CA is a Certificate Authority that owns one or more trusted roots. That means that they have roots in the trust stores of the major browsers. Intermediate CAs or Sub CAs are Certificate Authorities that issue off an intermediate root. They do not have roots in the browser’s trust stores, instead, their intermediate roots chain back to a trusted third-party root. This is sometimes called cross-signing.

Intermediate Certificates are in turn trusted by a Root Certificate by chain of Trust. CAs issue digital certificates to its clients (usually intermediate CAs).
Server Certificate (also known as Leaf Certificate) is a certificate that has been issued to a server by a intermediate CA. A certificate issued to a server is usually by an intermediate CA and a chain of certificates in the form of certificate bundles gets linked to the Root CA to build a trust chain.

In the above example DigiCert is root CA and Digicert2 extended validation server is Intermeidate CA.

Root Store
A root store contains list of trusted root CA certificates.A public-facing root store is usually maintained under the authority of a major software provider, which distributes their root store along with software which depends upon it to determine trust. Many providers of browsers and operating systems operate their own root store programs, and CAs may apply to be accepted into a root store using the criteria of that program. The device will use whatever root store is native to its OS, otherwise it might use a third-party root store via an app like a web browser. There are several major root programs of note:

1. Microsoft
2. Apple
3. Google
4. Mozilla

CAs do not issue directly from their roots. They add layers of security by issuing intermediates and then signing certificates with those. This helps to minimize and compartmentalize damage in the event of a mis-issuance or security event. Rather than revoke the root certificate and literally every certificate that it signed by extension, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.

Google and the other browsers recently distrusted Symantec CA brand SSL certificates. They just removed all of Symantec CA’s roots from their trust stores. Now any certificate that is supposed to chain back to those roots fails and is distrusted

A digital signature in its simplest description is a hash (SHA1, MD5, etc.) of the data (file, message, etc.) that is subsequently encrypted with the signer’s private key. Since that is something only the signer has (or should have) that is where the trust comes from. EVERYONE has (or should have) access to the signer’s public key.

So, to validate a digital signature, the recipient

1. Calculates a hash of the same data (file, message, etc.),
2. Decrypts the digital signature using the sender’s PUBLIC key, and
3. Compares the 2 hash values.

Sender – Alice is sending a digitally signed but not encrypted message to Receiver – Bob

1. Sender generates a message digest of the original plaintext message using a secure hash function like SHA3-512.
2. Sender then encrypts the message digest using her private key. The output is the digital signature.
3. Sender appends the digital signature to the plaintext message.
4. Sender then sends the appended message to Receiver. Sender sends digital signature + Plain Text Message + Certificate with Public Key
5. Receiver removes the digital signature from the appended message and decrypts it with the public key of Sender.
6. Receiver calculates the hash of the plaintext message with SHA3-512.
7. Receiver then compares the decrypted message digest he received from Sender with the message digest Receiver computed. If the two digests match, he can be assured that the message he received was sent by Sender.

The digital signature process does not provide any privacy by itself. It only ensures that the cryptographic goals of authentication, integrity, and nonrepudiation are met. If Sender wants to ensure the privacy of her message to Receiver, she could encrypt the appended message generated in step 3 with the public key of Receiver. Receiver then would need to first decrypt the encrypted message with his private key before continuing with step 5.

What Sender Does?

Note: In the above step the hash is encrypted digitally signed using private key.In the side of the receiver public key should be used to decrypt hash for verification

What Receiver Does?

Encryption vs Digital Signature

In Encryption we use receivers public key to encrypt the message whereas when we digitally sign we use senders private to encrypt the hashed text(which is nothing again message we would like to send)

Encryption
Encryption is the act of converting plain text to cipher text. Cipher text is basically text that has been scrambled into non-readable format using an algorithm – called a cipher.

Public key encryption uses public/private key pairs. If you want me to send you an encrypted message, you send me your public key, which I import into my encryption software. I encrypt the message with your public key. When you receive the message, you decrypt it with your private key. Even though your public key can be freely distributed and used to encrypt messages addressed to you, these encrypted messages can only be decrypted with your own private key. This private key must always be kept secret. Data encrypted with the public key can only be decrypted with its corresponding private key. This is what happens in Brower Server Communication

Digital Signature
Message signing, on the other hand, uses the sender’s private key to sign the message, and his public key is used to read the signature. Message signing helps ensure data integrity, message authentication, and non-repudiation. For example, if John wants to digitally sign a message to Bob, he uses his private key to sign the message, and sends it (along with his public key if it hasn’t already been sent) to Bob. John’s public key is the only key that can verify the message signature.

In RSA crypto, when you generate a key pair, it’s completely arbitrary which one you choose to be the public key, and which is the private key. If you encrypt with one, you can decrypt with the other – it works in both directions. It is fairly simple to see how you can encrypt a message with the receiver’s public key so that the receiver can decrypt it with their private key.

A signature is proof that the signer has a private key that matches some public key. To do this, it would be enough to encrypt the message with that sender’s private key and include the encrypted version alongside the plaintext version. To verify the sender, decrypt the encrypted version, and check that it is the same as the plaintext.

Of course, this means that your message is not secret. Anyone can decrypt it because the public key is well known. But when they do so, they have proved that the creator of the ciphertext has the corresponding private key.

However, this means doubling the size of your transmission – plaintext, and ciphertext together (assuming you want people who aren’t interested in verifying the signature, to read the message). So instead, typically a signature is created by creating a hash of the plaintext. Fake hashes can never be created, so cryptographic hash algorithms such as SHA-2 are used.

• To generate a signature, make a hash from the plaintext, encrypt it with your private key, include it alongside the plaintext.
• To verify a signature, make a hash from the plaintext, decrypt the signature with the sender’s public key, check that both hashes are the same.

Encryption and Decryption
Encrytion and Decryption could use same key as in symmetric algorithm or could use different one. Below are the steps for Asymmetric encrytion.

1. Alice wants to send a message to Bob which no one should be able to read.
2. 1. Alice encrypts the message with Bob’s public key and sends it over.
   2. Bob receives the message and decrypts it using his private Key.

   Note that if A wants to send a message to B, A needs to use the Public key of B (which is publicly available to anyone) and neither public nor private key of A comes into the picture here.
   

So if you want to send a message to me you should know and use my public key which I provide to you and only I will be able to decrypt the message since I am the only one who has access to the corresponding private key.

Digitally Signing Message

1. Alice wants to send a message to Bob again. The problem of encrypting the data is solved using the above method.
2. But what if I am sitting between Alice and Bob, introducing myself as ‘Alice’ to Bob and sending my own message to Bob instead of forwarding the one sent by Alice. Even though I can not decrypt and read the original message sent by Alice(that requires access to Bob’s private key) I am hijacking the entire conversation between them.
3. Is there a way Bob can confirm that the messages he is receiving are actually sent by Alice?
4. Alice signs the message with her private key and sends it over. (In practice, what is signed is a hash of the message, e.g. SHA-256 or SHA-512.)
   Bob receives it and verifies it using Alice’s public key. Since Alice’s public key successfully verified the message, Bob can conclude that the message has been signed by Alice.