Cryptographic Failures and Security Protocols

Cryptographic failure

Cryptographic failure refers to a flaw in the way we protect confidential information, either when we transmit data from one end to another (at transit), or when we persist the data (at rest).

I do not want to state the obvious by writing that you must use SSL and end with that, because there is so much more to it and for that, we need to understand what hashing and encryption mean and this is what I am going to focus on in this section.

Man-In-The-Middle Attack

Before we discuss how we apply security protocols across the network, we first need to understand what are they aimed at resolving and that is MITM(Man-In-The-Middle) attacks.

A MITM attack is when a malicious third party intercepts the communication between two ends, then it can 

• Tamper with the message, impersonate to one side, and send requests on its behalf
• Collect sensitive information 

From previous posts, you already know that Rocco is a very proficient hacker, so He knows how to place himself between the user and the server.

Maybe he did it using an ARP spoofing attack, or perhaps IP spoofing or any other method. For us, it doesn’t matter. 

The question is how we deal with the outcomes?

Message tampering

Security protocols tackle message tampering by applying a hash function on the message content and attaching the hashed value to the payload. 

Once the receiver reads the payload, it will decompose it to the original message and the hash value and apply the same hash function to the message.

If the value is equal to the hash value in the payload, then the receiver can trust the integrity of the data.

Hash function characteristics:

• one-way function – function’s value is not possible to invert 
• fixed size value – otherwise
  • It would not be possible to decompose the payload to hash and message 
  • You can infer the length of the original message 
• small changes in the input cause a major difference in the value 
• value collisions are rare 

Common hash algorithms

• MD5 (128 bits)
• SHA – you can read about the implementation here 
  https://blog.boot.dev/cryptography/how-sha-2-works-step-by-step-sha-256/
  • sha1 (160 bits)
  • sha256 (256 bits – most common)
  • sha512  (512 bits)
• HMAC – hash is created by:
  • hash function – can be SHA hash / MD5 or another
  • key – adds another layer of security. Both sender and receiver must hold the key in order to compute the digest of the payload.

Message spoofing

Hashing ensures data integrity, as the receiver can tell if the payload was manipulated, but what if the server and client are sending confidential information across the wire?

Consider the following story, about twenty years ago, my father worked In Washington, and just before going back home to Israel, he had to put his car on sale. 
One day, two foreign workers came to see the car, and the three went for a test drive.

During the drive, the two discussed how they are going to convince my father to lower the price. 
Unfortunately for them, my father speaks their language, so the price stayed fixed. If they spoke in a language only both of them understand, it could have played out as they hoped it would.

Obviously, it is not practicable to create a new language for each conversation that a third party will not understand, so what could they do instead? 

The two could have agreed that given X <- number between 1 to 10, the speaker will change each letter to the next X letter in the alphabetical order, and they will agree on that number just before the ride. 

for example, for “aba” and x=1 , the new word would be “bcb”, and to invert it you would simply have to go back 1 letter. 

so the Algorithm is moving to the next letter in the alphabet and the key is X (a number between 0 and 10) => and that’s encryption, a very naïve method that an attacker can easily hack.

Encryption

Encryption is a two-way function that changes the original value of the message and the receiver of the encrypted message can invert it using a unique key. 

There are two types of keys, symmetric keys, and asymmetric keys.

Symmetric key

• Both the sender and the receiver use the same key to encrypt and decrypt the message
• Low on CPU and performs better than asymmetric
• Shared – therefore, less secured 

commonly used symmetric keys:

• 3DES(168 bit)
• AES (128/192 and 256 bits)
• ChaCha20

Symmetric vs Asymmetric

Symmetric key:

Advantages:

• Low CPU usage for encrypt/decrypt

Disadvantages:

• less secure – shared keys, you would need to think how to share it across the wire 

Asymmetric key:

advantages:

• Very secured – a private key belongs only to one end 

Disadvantages:

• High Cpu required – slower

• Supports only one side transmits  

So what to choose? Enjoy both worlds using a hybrid model. 

Hybrid model

The main idea behind a hybrid model is to use the asymmetric key for authenticating the server and exchanging a symmetric key.

The server and client will then use this temporary symmetric key for communication between the two ends.

Think of the two diagrams we showed throughout this post 

Steps to send a shared key: 

• The client creates a symmetric key.

• The client encrypts it using its public key (asymmetric key). 

• The client creates a payload that contains

  • Symmetric key.

  • The hash value of the symmetric key. 

• The server receives the key. 

• The server decomposes the message to hash and key. 

• Server validates hash(key) = hash.

• if true – begin communicating with the server using that symmetric key. 

TLS Certificate

We’ve mentioned that the client authenticates the server before it trusts any further communication with it. 

The server identifies the client, using a TLS certificate, considers it as a passport card that also serves for data encryption, as it also contains a public key. 

Certificate Authority

Hold on a second. How can the client tell that the server’s encryption can be trusted? And that the server certificate indeed proves its identity?

Continuing with our analogy to passports, when you hand over a passport to an airport security officer, the officer can’t trust your id, unless it was issued by department-of-state.

In TLS, the client can trust any certificate signed by a certificate authority (CA). Therefore, you can think of CA’S as government offices that sign identifications (certificates). 

Nowadays, there are six large root CA’s that most rely on:

• digitCert
• Entrust
• GoDaddy
• GeoTrust
• QuaVadis
• Verisign

PKI – private key infrastructure

All the above leads us to the private-key infrastructure that is constructed by three parties

• Client
• Server
• Certificate Authority 

Key Exchange

So far, we know that an asymmetric key is used to transmit a shared symmetric key between the client and the server, and from that point, that key is used to transfer data between them. 

possible (but incorrect) implementation:

In one of the previous diagrams above, you’ve seen that one option is to have the client create the symmetric key and send it across the wire encrypted by the public key, so only the server could read it. 

However, the server is not involved in the key creation. Therefore; the key is prone to security issues.

You can never trust the client to be in charge of such an imperative decision.

the alternative solution is to have the server generate the key and send it, encrypted by the private key, as the following diagram suggests

Though this is extremely insecure, and we’ve actually made matters worse, remember? Anybody can have the public key, therefore, anyone can decrypt this message! 

Solution: Diffie Hellman

Both the servers and the client can negotiate together on a key. 

There are several implementations of the Diffie-Hellman algorithm, but the main idea is to use a one-way function on both ends and exchange only partial arguments that will be used to create the key, preventing from an attacker from getting the whole picture. 

Each side contributes its own part and together they agree upon a one-way key generation that cannot be inverted 

Example: the modulo method

General Concept, let’s say two sides are Alice and bob :

• Alice chooses
  • p – prime number
  • a – Alice’s private key 
  • g – Alice’s public key
• Bob chooses
  • b – bob private number

Both sides will use their private key (a, b) to compute the symmetric key, but they will not send it across the wire. Therefore, this method is much more secure than simply having one compute it and send it to the other 

The solution is as followed

notes:

• f(x) = x mod p, is a one-way function, therefore if a man in the middle grabs holds of it, it cannot invert Alice’s private key (a) from it. 

• both sides compute the shared symmetric key using their private keys

• Even though different inputs are used to calculate the key, both sides reach the same value as shown above

• private keys are kept secret and not sent across the wire. 

Security Protocols 

Cipher Suite negotiation 

In both protocols, The Server and the Client need to reach some agreement on how they are going to communicate with one another. 

As We’ve discussed so far, there are several parameters that both sides need to determine:  

• communication protocol
  • In most cases – TLS
• key-exchange algorithm(optional) – by default client will generate it as previously shown
  • ECDH – (Elliptic-curve Diffie–Hellman) – is another form of Diffie-Hellman that we did not cover in this post
  • SRP
  • PSK – pre-shared key, when the server and client have already shared the key prior to the TLS handshake.
• Asymmetric key function
  • RSA
  • DSA
  • ECDSA
• Symmetric key generation function
  • RC4
  • AES (with mode: GCM or CDC)
  • DES
  • 3DES
  • IDEA
  • Camellia
  • ChaCha20 
• Hash Function
  • SHA
  • MD5

for that specific example => 

• TLS
• Key Exchange Algorithm = Elliptic-curve Diffie–Hellman
• asymmetric key encryption method = RSA
• symmetric key encryption method = 256-bits AES,  GCM mode  
• Hash method = 384-bits Sha 

TLS 1.2 Protocol

In TLS 1.2, we begin the handshake by having the client send to the server a ‘client hello’ message that includes the list of ciphers that the client agrees to work with. Here is the example in Wireshark:

Once The server receives client hello, it responds with a “server hello” message, in which it chooses one cipher or rejects the connection.  

How TLS 1.3 upgrades the prior version?

• Performance Improvement
  • fewer packages exchanges for a complete handshake
  • other optimizations that we will not cover here, feel free to google it 😉 
• Better Security
  •  removes vulnerable ciphers and protocols supported

Summary

My intention in this post was to provide a proper introduction to security protocols and bring all the information together in a single post. 

We’ve learned together that a man-in-the-middle attack can happen on an unreliable network, where the attacker can eavesdrop on the communication line and tamper with the messages being transmitted. 

Then, we moved to explain what are the components used to secure that transmission of data, and how to disrupt the ability of an attacker to use it for its benefit. 

Those components, if you want to widen your knowledge and google for some more details are:

• Hashing
• Encryption
  • Asymmetric key
  • Symmetric Key
• Certificates 
• Key exchanges (Diffie-Hellman for example)
• PKI infrastructure

We completed the post by discussing TLS 1.2 and TLS 1.3 and showing examples of both protocols on Wireshark. 

In the next post on this subject, I will try to cover more about encryption and the security of data at rest. 

 Recommendations: 

• Download Wireshark and checkout the TLS communication on your site 
• Read what is a self-signed certificate how to create it
  • https://www.keyfactor.com/blog/self-signed-certificate-risks/
  • https://devcenter.heroku.com/articles/ssl-certificate-self
• Watch a video explaining RSA, the most common asymmetric key generation method
  • youtube.com/watch?v=Pq8gNbvfaoM

Hope you enjoyed this post, till next time…