CurveCP: Usable security for the Internet

Introduction

Main features:

Confidentiality

Integrity

Protocol details:

Integration:

Programming:

Confidentiality and integrity

The CurveCP client and CurveCP server encrypt and authenticate each packet, scrambling the packet in a way that only they can create and only they can understand. This cryptographic protection provides confidentiality against espionage and integrity against corruption and forgery. CurveCP also provides some availability against sabotage; this is discussed on a separate page.

The client and server administrators don't meet secretly to share an encryption/authentication key. The server has a long-term public key S visible to everyone; the client uses this key S to encrypt data for the server and to verify data from the server. The client also has a long-term public key C visible to the server; the server uses that key C to encrypt data for the client and to verify data from the client.

Does CurveCP provide server authentication?

Yes. The client verifies every packet from the server using the server's long-term public key, or using a short-term public key that the long-term key has securely vouched for. Attackers cannot pretend to be the server; forged packets labelled as being from the server are immediately recognized and discarded.

Does CurveCP provide client authentication?

Yes. The client's long-term public key securely vouches for a short-term public key, and the server verifies every packet from the client using that short-term public key. Attackers cannot pretend to be the client; forged packets labelled as being from the client are immediately recognized and discarded.

Does CurveCP stop replay attacks?

Yes. If the attacker makes copies of a legitimate client's Hello packets then the attacker will receive server Cookie packets without affecting the server state; these Cookie packets do not leak information and will be rejected by the legitimate client. If the attacker makes copies of other client packets then the copies will be rejected by this server and by other servers. If the attacker makes copies of server packets then the copies will be rejected by this client and by other clients.

Does CurveCP stop man-in-the-middle attacks?

Yes. The client knows the server's long-term public key in advance, before making a CurveCP connection. Servers that differentiate between clients know the clients' long-term public keys in advance. An attacker is then unable to

fool the client into encrypting data to the attacker rather than the server;
fool the server into accepting data from the attacker and thinking it comes from the client;
fool the server into sending responses to the attacker rather than the client; or
fool the client into accepting data from the attacker and thinking it comes from the server.

CurveCP's encryption mechanism is tied tightly and securely to its client/server identification and authentication mechanisms. An attacker with full control over every packet between the client and server can compromise availability but cannot compromise confidentiality or integrity.

Does CurveCP provide passive forward secrecy?

Yes. Two minutes after a connection is closed, both the client and the server are unable to understand (or verify) what was sent through the network. Of course, the client and server might have stored copies of the plaintext on disk, but that isn't CurveCP's fault.

CurveCP also provides forward secrecy for the client's long-term public key. Two minutes after a connection is closed, the server is unable to extract the client's long-term public key from the network packets that were sent to that server, and is unable to verify the client's long-term public key from the network packets.

Here's how the forward secrecy works. At the beginning of a connection, the CurveCP server generates a short-term public key S' and short-term secret key s', supplementing its long-term public key S and long-term secret key s. Similarly, the CurveCP client generates its own short-term public key C' and short-term secret key c', supplementing its long-term public key C and long-term secret key c. Almost all components of CurveCP packets are in cryptographic boxes that can be opened only by the short-term secret keys s' and c'. The only exceptions are as follows:

Packets from the client contain, unencrypted, the short-term public key C'. This public key is generated randomly for this CurveCP connection; it is tied to the connection but does not leak any other information.
The first packet from the client contains a cryptographic box that can be opened by c' and by s (not s'; the client does not know S' at this point). However, this box contains nothing other than constant padding.
The first packet from the server contains a cryptographic box that can be opened by c' and by s. However, this box contains nothing other than the server's short-term public key S', which is generated randomly for this CurveCP connection, and a cookie, discussed below.
The second packet from the client contains a cookie from the server. This cookie is actually a cryptographic box that can be understood only by a "minute key" in the server. Two minutes later the server has discarded this key and is unable to extract any information from the cookie.

At the end of the connection, both sides throw away the short-term secret keys s' and c'.

Does CurveCP provide active forward secrecy?

Yes. CurveCP provides forward secrecy even against man-in-the-middle attacks. This applies to the connection contents and to the client's long-term public key.

Many protocols provide forward secrecy against attackers who passively eavesdrop upon the network during a connection and then, after the connection is over, obtain the current secret keys and try to retroactively decrypt the network packets. Furthermore, many of these protocols provide integrity against more powerful attackers who actively manipulate packets during the connection. However, many of these protocols lose forward secrecy against those attackers. These protocols provide passive forward secrecy but not active forward secrecy. CurveCP provides active forward secrecy.

Does CurveCP provide options to disable encryption and to disable authentication?

No. CurveCP's server authentication is always active and cannot be disabled. CurveCP's client authentication is always active and cannot be disabled. CurveCP's encryption is always active and cannot be disabled. CurveCP's forward secrecy is always active and cannot be disabled. CurveCP has nothing analogous to IPsec's separation between AH and ESP, and nothing analogous to HTTPS renegotiation.

The lack of options in CurveCP simplifies the protocol and prevents a wide range of design and implementation mistakes. Compare the following quotes:

Ferguson and Schneier, 2003: Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect. Committees are notorious for adding features, options, and additional flexibility to satisfy various factions within the committee. As we all know, this additional complexity and bloat is seriously detrimental to a normal (functional) standard. However, it has a devastating effect on a security standard. ... When both encryption and authentication are provided, IPsec performs the encryption first, and authenticates the ciphertext. In our opinion, this is the wrong order. ... Authentication should thus be applied to the plaintext (as it is in SSL [FKK96]), and not to the ciphertext. ... An Attack on IPsec ... Clearly, the authentication property has been violated.
Degabriele and Paterson, 2010: IPsec allows a huge amount of flexibility in the ways in which its component cryptographic mechanisms can be combined to build a secure communications service. This may be good for supporting different security requirements but is potentially bad for security. We demonstrate the reality of this by describing efficient, plaintext-recovering attacks against all configurations of IPsec in which integrity protection is applied prior to encryption – so-called MAC-then-encrypt configurations. ... For concreteness, we study the common use case of using IPsec to build a simple site-to-site VPN. We describe practical attacks against all MAC-then-encrypt configurations of IPsec for this common application, including the most natural configurations as well as more "exotic" ones.

Ferguson and Schneier break an encrypt-then-MAC configuration for IPsec and recommend MAC-then-encrypt. Degabriele and Paterson show that IPsec's MAC-then-encrypt options are completely insecure. The only point of agreement between the authors is that committee-induced flexibility is a disaster for security.

Does CurveCP provide client address authentication?

No. IP addresses are not secure in any meaningful sense, and CurveCP does not attempt to make them secure. Servers that distinguish between clients must do so on the basis of long-term client public keys, not IP addresses.

Does CurveCP protect against traffic analysis?

No. An attacker can see the Internet destination, exact timing, and approximate length of each packet that you send. CurveCP is not a substitute for an anonymizing network such as Tor, although of course it can be used to protect links inside an anonymizing network.

Don't underestimate the amount of interesting information that the attacker can deduce from traffic analysis! For example, Song, Wagner, and Tian showed in 2001 that the timing of password packets in ssh leaks several bits of information about a typical password.

Version

This is version 2011.02.22 of the security.html web page.