Stopping Man-in-the-Middle Attacks With Cryptography
Man-in-the-middle. Man-in-the-browser. IP spoofing. DNS spoofing. They’re all part of the happy family of hacks generally known as Man-in-the-middle attacks, wherein a bad actor secretly relays and possibly alters the communication between two parties who believe they are communicating directly with each other. They’re a very real threat, especially when it comes to authentication. To carry out man-in-the-middle attacks, hackers use fake authentication credentials, tricking both sides into believing that they are communicating with each other securely.
Man-in-the-middle attacks are pretty common, and most current security technologies are not up to the challenge. That comes as a surprise to many people—and that fact has prompted researchers to propose ways to prevent, or at least manage, this threat.
Do Public Keys Hold the Key?
One of the ways to keep intruders out of communications is to make it more difficult to breach them, and one method that is commonly used is public key cryptography, or public key infrastructure (PKI). PKI introduced to the world of information technology the concept of “asymmetric” encryption, a method in which a message is encrypted, but unlocked only by one user. The public key is accessible to anyone so that anyone can encrypt a message, but to de-encrypt it, the recipient needs a special private key.
At first glance, it sounds like a good solution, with encryption keeping the message safe and decryption only possible by the recipient. But the system has a key vulnerability as well: Although there is no need to share a symmetric key, there is an actual need to associate the public key with the actual recipient. Think of it as if you begin a chess game simultaneously with two world champions: Let one of them start and copy their move on the other board. Then, wait for the other player to react and react in the same way in the game with the first champion. Eventually, one of them wins—and you win over the other one.
For that trust to be established, an initial interaction needs to take place between the two parties before a message is exchanged. Before the keys needed to encrypt data can be generated, the server must present the client with a digital certificate, verifying its identity. This is what occurs, for instance, every time a user logs into their Gmail account. The certificate issued by Google allows the user’s browser to know that it is, in fact, Gmail they are “talking” to and not a digital imposter.
One common approach PKI takes to certification is using of certificate authorities, or CAs, trusted third parties that “sign” digital certificates confirming the identity of the parties. But CAs are actually a weak link in the security chain; they’ve been proven vulnerable to attacks, and once these companies are compromised, their certificates can no longer be trusted, completely undermining the public key encryption they support. In fact, private keys themselves are also susceptible to the same danger. One of the more important revelations of former CIA contractor and whistleblower Edward Snowden was the efforts of Western intelligence agencies to breach communications companies to steal crypto keys and take advantage of certificate authority vulnerability.
Given how many companies use certificates, such compromise is disastrous; the very element that ensures trust in the system is compromised, thus calling into question the integrity of the system in its entirety. With the realization that a hacked certificate authority can be a major threat, some organizations have recently offered a partial solution to this problem. Instead of storing signed private key certificates in one location, which makes them vulnerable to hacking and alteration, several CAs and trusted authorities use multiple signatures on a certificate, or distributed blockchain-based storage of signed certificates.
Keyless Architecture
While this is certainly a step in the right direction, it doesn’t address the other fundamental problem with the PKI system: Private keys of certificate authorities, and therefore certificates themselves, are vulnerable to being hacked. As long as an encryption system is founded on something cybercriminals can steal, it will remain vulnerable. It’s just a matter of time before someone compromises the system.
Several ideas have been proposed to fix these problems. Naturally, these ideas avoid a centralized solution and use a distributed approach, such as the distributed trust that blockchain provides, and multi-channel communication. For example, one can send the certificate and/or the public key through several trusted channels, such as push notifications, email, SSL, HTTPS and social messengers, obtaining accumulated trust that verifies the identity of the other party before using the received public key.
In fact, the word “decentralization” has been floating around the authentication industry for some time, and usually refers to credentials being stored on devices (especially mobile) to reduce the risk of a single breach of a repository and lower the cost of IT maintenance. Secret sharing is one of the most promising approaches, as shares can be distributed, and yet the information is still accessible when a share (or some shares) is lost or erased.
Though the goal of removing the target and decentralizing credentials is a noble one, if a breach occurs through a man-in-the-middle attack, the compromising of the credentials of one user can lead to a breach that could affect the entire system. Security system designers are going to have to come up with a way to protect organizations from these ever-growing threats.
