Exploring CWE-322: Key Exchange without Entity Authentication

Introduction

A02:2021 – Cryptographic Failures is the second most common vulnerability on OWASP’s Top Ten List of web application vulnerabilities. Strong encryption is a fundamental component of data security and privacy, but it is easy to get wrong. Errors in data encryption can undermine or destroy its protections, leading to the exposure of sensitive information.

One of the ways in which cryptography goes wrong is described under CWE 322: Key Exchange without Entity Authentication. This failure addresses the fact that two parties may create a shared secret key for secure communications without verifying one another’s’ identity.

Key Exchange and Entity Authentication

Asymmetric cryptography provides a variety of different benefits, including the ability to perform key exchange and entity authentication. With asymmetric encryption, two parties can create a shared secret key over a public channel and validate that a particular message originated from a certain user.

One of the most common applications of key exchange protocols is the Transport Layer Security (TLS) protocol. TLS wraps network traffic in a layer of authentication and is the difference between insecure HTTP and secure HTTPS.

TLS connections begin with a “handshake” where the client and server agree on how they will communicate and generate a shared secret key for encrypting data. This shared secret key is generated using asymmetric cryptography, which requires at least one party to share its public key with the other. A server’s public key is commonly shared using a digital certificate. This certificate not only contains the public key but also the identity of the owner and a chain of trust leading back to a root certificate authority (CA). This enables the client to verify the identity of the webserver by verifying the certificate’s validity.

Where Entity Authentication Goes Wrong

When setting up a TLS session or other encrypted and authenticated connection, the server’s identity should be verified to protect against phishing and man-in-the-middle (MitM) attacks. In some cases, both the client and server should authenticate themselves to one another. However, entity authentication can fail for a few reasons, such as:

• Failure to Request Entity Authentication: The simplest way in which entity authentication can go wrong is a failure to attempt to validate identity. If key exchange is performed using public keys rather than digital certificates (which link public keys to identities), there is no verification that the public key used is the right one.
• Ignoring Failed Certificate Validation: Entity authentication is commonly performed by validating the digital certificate used to link a public key to a particular entity. If certificate validation fails but an application ignores that failure and continues with key exchange, they have not authenticated the other party’s identity.
• One-Sided Entity Authentication: Most TLS connections only require the server to provide a digital certificate that authenticates its identity, but no verification is performed of the client’s identity. In cases where the client’s identity matters, this could allow unauthorized access to a website.

Case Study: Eclipse Californium

Eclipse Californium implements the Constrained Application Protocol (CoAP) to allow communication with smaller IoT devices. In 2021, a vulnerability was discovered in its DTLS implementation that is tracked as CVE-2021-34433.

In the vulnerable versions of Eclipse Californium, a DTLS handshake could accidentally succeed if the server leaves out the signed_params section within the ServerKeyExchange. This implements an anonymous key exchange, meaning that the client has not verified the identity of the server.

Properly Authenticating During Key Exchange

Entity authentication is vital to ensuring that the parties in communication know who they are talking to before setting up and sending data over an encrypted connection. At a minimum, the server should be authenticated to the client to protect against phishing and MitM attacks.

Key exchanges without entity authentication most commonly occur due to a flaw in the implementation of a TLS client. Some best practices for entity authentication include:

• Exchange public keys within digital certificates
• Validate the authenticity of digital certificates
• Terminate connections before key exchange if validation fails

Guaranteeing digital privacy and security requires a clear understanding of cryptographic errors and best practices for addressing them. To learn more about cryptographic security and find out about our latest research and work, subscribe to our blog.

Up Next

To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.

We’re very committed to improving the state of cryptography and data security by sharing knowledge and helping to correct common misconceptions about how cryptography works and how to use it properly. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.