Symmetric Encryption

• Single key used for both encryption and decryption

• Over the same network sniff

It is a secure way of encryption but the same key is required to encrypt and decrypt the data and the key needs to be exchanged between the sender and receiver so there is a risk of hackers gaining access to the key.

Asymmetric Encryption

Pairs of key

• Private Key

• Public Key

For SSH

To generate key pairs need to use the command ssh-keygen

This will create two file

• id_rsa → for private key

• id_rsa.pub → for public key

The actual command is ssh-keygen -t rsa

Locking down all the access to the data using a public key can be done by making an entry into cat ~/.ssh/authorized_keys

Can only be accessed through the private key ssh -i id_rsa user1@server1

Now if other users want to or need to access the server then new key pairs need to be generated by the new user and the owner needs to create an additional door for them and need to lock it with their public key. Once it is done need to copy their public lock to all the servers. Other users now can access the server with their private key. cat ~/.ssh/authorixed_keys

To securely transfer the symmetric key from the client to the server, we use asymmetric encryption.

For Web apps

For web servers, we use openssl to generate public and private key pairs. Whereas ssh-keygen was used to create key pairs for SSH purposes.

For private key, openssl.genrsa -out my-bank.key 1024

For public key, openssl rsa -in my-bank.key -pubout > mybank.pem

How asymmetric encryption works

1. When users first access the web server using HTTPS, they get the public key from the server. Hacker also gets the same key because they are sniffing the traffic over the same network.

2. The user browser now encrypts the symmetric key using the public key provider by the server. The user now sends the encrypted symmetric key with the public key to the server. Hackers also get the same copy.

3. The server uses the private key to decrypt the message and retrieve the symmetric key from it. Hackers can’t do the same because they don’t have the private key.

4. Now, a symmetric key is only available to the user and the server.

5. Users can now encrypt the message using the symmetric key and send it to the server and the server can also decrypt the data because they have the symmetric key.

How Hackers Trick Us:

• Now to access/get the credential hacker makes a replica of the website we want to visit. They do the same key pairs and send a public key to the user to look like it is secure. But all information goes to the hacker server.

Q. How we can check the public key sends to us is a legitimate key?

When a public key is sent to the user by the server, it is sent with a certificate

Q. Anyone can make that certificate on their own even a hacker. So how to identify the certificate is legitimate?

1. By looking into the signed/Issued by

2. In fact all of the web browser is built in with the certificate validation mechanism

Q. Who signed the certificates?

Certified Authority

e.g., Symantac, Digicert, Comodo, GlobalSign

• To generate a certificate signing request (CSR) need to use command

openssl req -new -key my-bank.key -out my-bank.csr -subj “/C=US/ST=CA/O=MyOrg, Inc./CN=mydomain.com

This will generate my-bank.key, and my-bank.csr file.

• Now CA checks and verifies the details and once it checks out they sign the certificates and send them back.

Q. How did the browser know that the CA itself was legitimate?

All the CA itself have their public and private key (key pairs). CA uses the private key to sign the certificate. All the public keys of CA are built in the browser. Browser validates the certificate using the public key that CA.

• But these all are for public websites. They can’t help with private networks such as a company’s website.

  • To solve the problem, need to deploy the CA into the organization’s internal server. Now can get the key pairs of the internal CA server installed on all the employees’ browsers and servers of the organization.

The whole thing from the beginning we read (managing, validating, distributing) is known as Public Key Infrastructure (PKI).

Note: The key pairs (Public and Private)

• Only the public key is not able to encrypt the data

• In fact, both keys are related keypairs

We can encrypt the data with any of them. But need to decrypt with the other one. Not with the same key.

Public Key

• .crt, .pem

• e.g., server.crt, server.pem, client.crt, client.pem

Private Key

• .key, -key.pem

• e.g., server.key, server-key.pem, client.key, client-key.pem

Sum up

To install openssl package: sudo yum install -y openssl

Creating your own self-signed certificate: sudo openssl req -x509 -nodes, -days 365 -newkey rsa:2048 -keyout app01.key -out app01.crt

Copying public key from one host to another to configure passwordless SSH connection: ssh-copy-id -i ~/.ssh/mykey.pub thor@app01

Generate CSR file

• cd /etc/httpd/csr

• sudo openssl req -new -newkey rsa:2048 -nodes -keyout app01.key -out app01.csr

To check entries: openssl req -noout -text -in app01.csr