Man-in-the-middle (MITM) attacks – where an attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other – are a very real threat, especially when it comes to authentication.
Various solutions have been put forward to prevent, or at least manage, this threat. These have met varying levels of success, although it is somewhat surprising that some of the most common technologies to prevent MITM authentication attacks are less effective than most people think.
Do Public Keys Hold the Key?
Public Key cryptography, or public key infrastructure (PKI), first introduced to the world of information technology the concept of “asymmetric” encryption; a way in which a message can be encrypted, but only unlocked by one particular user. This is while the public key is accessible to all, and can be used to encrypt a message, however only the intended recipient – the one who possessed the private key – can actually read it. This seemed to offer a great solution to encryption and decryption without the need to pre-share a common key, one which found the balance between security and usability.
Public Key encryption, however, rests on a very critical step – a step that exposes a serious weakness in the entire PKI scheme. Although there is no need to share a symmetric key, there is an actual need of trust between the two parties.
An initial interaction needs to take place between the two parties at the beginning of any session. 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 in to 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.
Currently, the PKI approaches to certification fall into two categories. For a long time, the most common method used to implement this has been the utilization of Certificate Authorities, or “CA”s, trusted third parties that “sign” digital certificates, confirming the identity of the parties. It soon became clear, however, that Certificate Authority’s (CA) presented a weak link in the chain of security.
Certificate Authorities have been shown to be vulnerable to attacks. Once these companies are compromised, the 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 in order to steal crypto keys and take advantage of certificate authority vulnerability.
Spreading the Risk
This would be disastrous; the very element that ensures trust in the system would be compromised, thus calling into question the integrity of the system in its entirety.
Understanding the risk that a hacked Certificate Authority poses, some organizations have recently offered at least a partial solution to this problem:
Instead of storing certificates in one location – which makes them vulnerable to hacking and alteration – these are spread out to a worldwide community of users.
While this is certainly a step in the right direction, it doesn’t address the other fundamental problem with the Public Key Infrastructure (PKI) system: certificates and private keys 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.
A Blockchain-type answer has been proposed to mitigate this, however it in no way addresses all the logistical burdens on businesses involved in maintaining certificates. The blockchain technology premise – decentralization – is a great idea for the actual server infrastructure, but what about the credentials? If the route by which the credentials are transferred intercepted (MITM), then anyone can use those credentials to impersonate the party to the verifier.
In fact, the word “decentralization” has been floating around the authentication industry for some time, and usually refers to the 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. However, especially with blockchain solutions, duties such as lifecycle management, submitting to validation checks and archiving services for certificates, present huge hassles for enterprises that need to divert large amounts of resources to these tasks.
Even more importantly, 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.