CurveCP: Usable security for the Internet
Confidentiality and integrityThe 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
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:
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.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.
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.
VersionThis is version 2011.02.22 of the security.html web page.