Posted by arlene

Some types of asymmetric algorithms are immune to MITM attacks, which are only successful the first time two people try to communicate. When a third party intercepts the communications between the two trying to communicate, the attacker uses his own credentials to impersonate each of the original communicators.

Beware of the key exchange mechanism used by any PKE system. If the key exchange protocol does not authenticate at least one and preferably both sides of the connection, it may be vulnerable to MITM-type attacks. Authentication systems generally use some form of digital certificates (usually X.509), and require a PKI infrastructure.

Also, note that MITM-based attacks can only occur during the initial correspondence between two parties. If their first key exchange goes unimpeded, then each party will authenticate the other’s key against prior communications to verify the sender’s identity.

Bad Key Exchanges

Because there isn’t any authentication built into the Diffie-Hellman algorithm, implementations that use Diffie-Hellman-type key exchanges without some sort of authentication are vulnerable to MITM attacks. The most notable example of this type of behavior is the SSH-1 protocol. Since the protocol itself does not authenticate the client or the server, it’s possible for someone to cleverly eavesdrop on the communications. This deficiency was one of the main reasons that the SSH-2 protocol was completely redeveloped from SSH-1. The SSH-2 protocol authenticates both the client and the server, and warns of or prevents any possible MITM attacks, depending on configuration, so long as the client and server have communicated at least once. However, even SSH-2 is vulnerable to MITM attacks prior to the first key exchange between the client and the server.

As an example of a MITM-type attack, consider that someone called Al is performing a standard Diffie-Hellman key exchange with Charlie for the very first time, while Beth is in a position such that all traffic between Al and Charlie passes through her network segment. Assuming Beth doesn’t interfere with the key exchange, she will not be able to read any of the messages passed between Al and Charlie, because she will be unable to decrypt them. However, suppose that Beth intercepts the transmissions of Al and Charlie’s public keys and she responds to them using her own public key. Al will think that Beth’s public key is actually Charlie’s public key and Charlie will think that Beth’s public key is actually Al’s public key.

When Al transmits a message to Charlie, he will encrypt it using Beth’s public key. Beth will intercept the message and decrypt it using her private key. Once Beth has read the message, she encrypts it again using Charlie’s public key and transmits the message on to Charlie. She may even modify the message contents if she so desires. Charlie then receives Beth’s modified message, believing it to come from Al. He replies to Al and encrypts the message using Beth’s public key. Beth again intercepts the message, decrypts it with her private key, and modifies it. Then she encrypts the new message with Al’s public key and sends it on to Al, who receives it and believes it to be from Charlie.

Clearly, this type of communication is undesirable, because a third party not only has access to confidential information, but she can also modify it at will. In this type of attack, no encryption is broken because Beth does not know either Al or Charlie’s private keys, so the Diffie-Hellman algorithm isn’t really at fault. Beware of the key exchange mechanism used by any PKE system. If the key exchange protocol does not authenticate at least one and preferably both sides of the connection, it may be vulnerable to MITM-type attacks. Authentication systems generally use some form of digital certificates (usually X.509), such as those available from Thawte or VeriSign.

Authentication

Is the receiver able to verify the sender? The answer depends on the type of encryption. In cases of symmetric cryptography, the answer is no, but in cases of asymmetric cryptography, the answer is yes. With symmetric cryptography, anyone with access to the secret key can both encrypt and decrypt messages. Asymmetric cryptography can authenticate a sender by their private key, assuming that the key is kept private. Because each person is responsible for their own private key, only that person is able to decrypt messages encrypted with their public key. Similarly, only those persons can sign messages with their private key that are validated with their public key.

Non-Repudiation

Asymmetric cryptography ensures that an author cannot refute that they signed or encrypted a particular message once it has been sent, assuming the private key is secured. Again, this goes back to the fact that an individual should be the only person with access to their private key. If this is true, only that person could sign messages with their private key and therefore, by extension, all messages signed with their private key originated with that specific individual.

Access Control

Additionally, in limited ways, cryptography can provide users with some access control mechanisms. Some systems can provide access control based on key signatures. Similar systems use X.509 certificates in the same manner. The idea is that, based on a certificate presented by a user that has been signed by that user, a particular user can be identified and authenticated. Once the authentication has occurred, software access controls can be applied to the user.

One-time Pad

There is a type of cryptography that has been mathematically proven to be unbreakable. The concept is called the one-time pad (OTP). It requires you to use a series of random numbers equal in length to the message you want to send. The problem with using this type of cryptography is that both sides need access to the random number generator, and the random number listings can never be reused.A suitable source of randomness that is truly random and unpredictable to put the concept to use has not been found. Considering that OTP’s were created almost 100 years ago, far before most modern cryptography techniques, and have been used in the military and intelligence communities for many years, it is a very interesting concept.

The OTP algorithm is actually a Vernam cipher, which was developed by AT&T in 1917. The Vernam cipher belongs to a family of ciphers called stream ciphers, since they encrypt data in continuous stream format instead of the chunk-by-chunk method of block ciphers. There are two problems with using the OTP, however:You must have a source of truly random data, and the source must be bit-for-bit as long as the message to be encoded.You also have to transmit both the message and the key (separately), the key must remain secret, and the key can never be reused to encode another message. If an eavesdropper intercepts two messages encoded with the same key, then it is trivial for the eavesdropper to recover the key and decrypt both messages. The reason OTP ciphers are not used more commonly is the difficulty in collecting truly random numbers for the key and the difficulty of the secure distribution of the key.

Possibly related posts: (automatically generated)
Cryptography MITM Attacks

• E-NEWSLETTERS - DEFINING AND REFINING Part 5
• Using Cryptography: Confidentiality, Integrity, Digital Signatures
• Public key Cryptography, when can be seriously Attack
• Cryptography (Public-Key) Standards and Protocols Notice
• Why your Computers get attacked and how? PC Privacy Security Issues continued
• Network Sniffers Do Not See All Packets
• E-NEWSLETTERS - DEFINING AND REFINING Part 4
• Data Encryption Standard and Triple Data Encryption Standard
• Network IDS Attack Recognition
• Why You're Not Finished Yet