Cryptography

 Handling Secure Communications between Client and Server

The client or application that wants to access your service will need an API Key and a Secret Key from you as the service owner. These keys are usually randomly generated strings and is given to the client beforehand. API Keys are unique to each client/application. Both the client and server will hold the API Key and Secret Key.

When the client makes a call to the API, the message content is hashed, using the secret key on the client, to generate a HMAC signature.
This value, along with the original message and the API Key is then passed to the server’s API.

Using the client API key, the equivalent Private key stored on the server is retrieved and the server also generates a HMAC signature which is compared with the one from client. Request is authorized when both match.

Digital Signature

The client holds the Private Key used to sign the message.
The client will provide its public key to the server. 
Each request is then made to the server by signing the message content using the private key. 
Server validates the message using the corresponding  Public key.

For two way communication, both servers will hold their own private keys and exchange public keys with each other.

The difference with this method from HMAC is that the server and client does not share the same secret key, hence neither party can impersonate one another.

How TLS works

Asymmetric encryption (also called public key encryption involves usage of private and public key pairs) is used to establish a secure session between a client and a server, and symmetric encryption (also called as private key encryption) is used to exchange data within the secured session. 

Ref - https://www.geeksforgeeks.org/difference-between-private-key-and-public-key/

TLS verifies the identity of the server with asymmetric cryptography. So that client can verify it’s connecting to the intended server only and can prevent man-in-the-middle attacks.
TLS then encrypts the connection between the client and server using symmetric key cryptography to protect the data exchange between the two. This makes sure if someone intercepts the message he/she will not be able to read it as it’s encrypted and they don't have the key to decrypt it.


1. Client contacts the server.
2. The server sends its certificate and public key to client.
3. Client verifies certificate authenticity with CA.
4. Client (Web browser) creates/encrypts the session key with Servers public key and sends it back to server.
5. Server decrypts the session key using its private key and the session is established.
6. This Session key is used to encrypt and decrypt data between client and server.

mTLS

When to Use:
Service to Service communications
B2B API interactions and financial transaction

In mutual TLS, there is an additional step involved in which the server also asks for the client's certificate and verifies it at their end.
A secure connection for data transfer is only established when both client and server successfully authenticate themselves and verify each other’s certificates. This is also known as two-way SSL.

Step1 - Client initiates handshake with 'Client Hello' (Session ID is shared)
Step2 - Server responds with 'Server hello' (Session ID is shared)
Step3 - Server sends certificate along with Cert chain and its public key.
Step4 - Client verifies the cert authenticity.
Step5 -  To verify whether the certificate belongs to the intended server, the client creates a random secret key and encrypts it using the server’s public key and sends it to the server.
Step6 - Now the server decrypts the random secret key using its private key.
Step7 - Next, the client sends its certificate along with its certificate chain and its public key.
Step8 - Server verifies the cert authenticity
Step9 - To verify whether the certificate belongs to the client, the server creates a random secret key and encrypts it using the client’s public key and sends it to the server 

Challenges

1. Maintaining certificates for all the clients and validate and verify each client for each session. 
2. Slower than TLS.

Digital certificates are also called X.509 certificates. The Certification Authority (CA) stores the public key of a user along with other information about the client in the digital certificate. The information is signed and a digital signature is also included in the certificate.

The creation of a certificate takes place as follows:

  • Private and public keys are created.
  • CA requests identifying attributes of the owner of a private key.
  • Public key and attributes are encoded into a CSR or Certificate Signing Request.
  • Key owner signs that CSR to prove the possession of a private key.
  • CA signs the certificate after validation.

Comments

Popular posts from this blog

AWS Organizations, IAM

Key Concepts

Linear Algebra Concepts