Opportunistic encryption: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
No edit summary
imported>Sandy Harris
No edit summary
Line 10: Line 10:
One large benefit is a reduction in administrative workload. If the administrators must set up every connection, the effort required for a fully connected network of N machines scales by N<sup>2</sup>. There are several ways to avoid this disaster on large networks, including using a centralised authentication system such as [[Kerberos]], or putting in hardware to encrypt at link level, or using [[IPsec]] to encrypt at network level. Any of these can reduce the workload to something manageable. OE, however, cuts the Gordian knot. For OE, the effort scales linearly; the work to set up N machines for OE is just N.
One large benefit is a reduction in administrative workload. If the administrators must set up every connection, the effort required for a fully connected network of N machines scales by N<sup>2</sup>. There are several ways to avoid this disaster on large networks, including using a centralised authentication system such as [[Kerberos]], or putting in hardware to encrypt at link level, or using [[IPsec]] to encrypt at network level. Any of these can reduce the workload to something manageable. OE, however, cuts the Gordian knot. For OE, the effort scales linearly; the work to set up N machines for OE is just N.


Another benefit is that more connections may be encrypted. Once OE is set up, any two OE-capable machines can secure their connections. If OE is sufficiently widespread, secure connections can be the default. Most other encryption systems aim at providing encryption ''wherever necessary''; OE aims at providing it ''wherever possible''. It is ''opportunistic'', and will encrypt ''wherever it can''.
Another benefit is that more connections may be encrypted. Once OE is set up, any two OE-capable machines can secure their connections. If OE is sufficiently widespread, '''secure connections can be the default'''. Most other encryption systems aim at providing encryption ''wherever necessary''; OE aims at providing it ''wherever possible''. It is ''opportunistic'', and will encrypt ''wherever it can''. This was a large part of the political motivation for [[FreeSWAN|FreeS/WAN]], the project that invented OE; their goal was to encrypt a large portion of the net and make various government monitoring programs impossible.


Like any encryption scheme, an OE system must rely on some form of [[information security#source authentication|source authentication]]. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details.
Like any encryption scheme, an OE system must rely on some form of [[information security#source authentication|source authentication]]. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details.

Revision as of 08:51, 1 September 2010

This article is developed but not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable, developed Main Article is subject to a disclaimer.

Opportunistic encryption, often abbreviated OE is the attempt to arrange network communication systems so that any two nodes can encrypt their communication, without any connection-specific setup by the system administrators. Once two machines are set up for OE, they can set up secure connections automatically.

Some encryption systems, for example PGP, encrypt messages while others encrypt connections. In most cases, the user asks for encryption, for example applying PGP to an email message, logging in to a remote system with SSH (instead of unencrypted telnet), or requesting an encrypted web connection by using https (instead of just http) to bring SSL into play. In other cases, administrators configure connections. For example, in building a VPN between two offices, the administrators on the two ends must co-operate to set up the connection. If you want your laptop to connect either to a wireless access point or to your office VPN, then you need to get some information from the system administrator and configure your machine to match; at the very least, you need a password and there may be other things to set up. In these cases, you are being the second administrator configuring your end of the connection.

Opportunistic encryption aims to avoid all that. Once a machine is set up for OE, it automatically checks whether the other end of any connection is capable of OE. If so, the two machines automatically set up an encrypted connection. This works without any user requests and without any need for administrators to configure connections. It even works when the two administrators have had no contact with each other. Of course, there is still some administrative work involved; the machines must be set up for OE and related policies set. An important policy decision is what to do if OE fails — communicate in the clear or refuse the connection.

One large benefit is a reduction in administrative workload. If the administrators must set up every connection, the effort required for a fully connected network of N machines scales by N2. There are several ways to avoid this disaster on large networks, including using a centralised authentication system such as Kerberos, or putting in hardware to encrypt at link level, or using IPsec to encrypt at network level. Any of these can reduce the workload to something manageable. OE, however, cuts the Gordian knot. For OE, the effort scales linearly; the work to set up N machines for OE is just N.

Another benefit is that more connections may be encrypted. Once OE is set up, any two OE-capable machines can secure their connections. If OE is sufficiently widespread, secure connections can be the default. Most other encryption systems aim at providing encryption wherever necessary; OE aims at providing it wherever possible. It is opportunistic, and will encrypt wherever it can. This was a large part of the political motivation for FreeS/WAN, the project that invented OE; their goal was to encrypt a large portion of the net and make various government monitoring programs impossible.

Like any encryption scheme, an OE system must rely on some form of source authentication. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details.

Opportunistic encryption for IP

The term "opportunistic encryption" comes from the FreeS/WAN project, who built OE into a Linux implementation of IPsec and wrote an RFC[1] documenting the design. They relied on DNS to manage authentication data.[2] Used alone, this would be secure against passive attacks; add DNS security to protect the authentication data and it is also secure against active attacks.

Another way to use IPsec with reduced administrative overheads is better-than-nothing security or BTNS[3], IPsec done without authentication. This gives the same security level as OE done without DNS security.

Normal IPsec, FreeS/WAN-style OE and BTNS are all secure against passive eavesdroppers who only try to listen in; encrypting the connection stops them. Normal IPsec, or OE with secure DNS, are also secure against active attackers who try to trick systems into communicating with them instead of legitimate partners. BTNS, or OE without secure DNS, are not; you need authentication to block those attacks.

The Planete project are building OE for IPv6. They claim "Unlike existing schemes (e.g. FreeS/WAN), our proposal does not rely on any global Third Trusted Party (such as DNSSEC or a PKI). Hence, we claim it is more secure, easier to deploy and more robust."

OE done at the IP layer of the protocol stack protects everything above that layer, and does so without any assistance from higher-layer protocols and generally entirely transparently to the users.

Opportunistic encryption of other protocols

The most widely deployed OE system encrypts server-to-server SMTP mail transfers. The original implementation was ssmail or Secure Sendmail [4], which built encryption into the mail server code. The current standard[5] instead relies on TLS. This does not provide all of the benefits of end-to-end mail encryption systems such as PGP; in particular it provides no protection against an enemy with privileged access to one of the mail servers involved, or against someone monitoring the connection between the user and the mail server. However, it does prevent attacks at routers between the mail servers. It provides partial protection against wholesale mail monitoring, forcing a government that wants to do large-scale monitoring either to subvert mail servers or to get the server owners to co-operate.

There are also TLS-based systems for encrypting the link between user and mail server. [6] [7]

There are also systems which apply OE to TCP connections, Google's obfuscated TCP and the later TCP crypt. These are secure against passive attacks but vulnerable to man-in-the-middle attacks.

References

  1. M. Richardson & D.H. Redelmeier (December 2005), Opportunistic Encryption using the Internet Key Exchange (IKE), RFC4322
  2. M. Richardson (February 2005), A Method for Storing IPsec Keying Material in DNS, RFC4025
  3. N. Williams, M. Richardson, ed. (November 2008), Better-Than-Nothing Security: An Unauthenticated Mode of IPsec, RFC5386
  4. Damian Bentley, Greg Rose, Tara Whalen (1999), ssmail: Opportunistic Encryption in sendmail
  5. P. Hoffman (February 2002), SMTP Service Extension for Secure SMTP over Transport Layer Security, RFC3027
  6. C. Newman (June 1999), Using TLS with IMAP, POP3 and ACAP, RFC2595
  7. K. Zeilenga, Ed. (August 2006), The PLAIN Simple Authentication and Security Layer (SASL) Mechanism, RFC4616