It has been said that the US National Security Agency (NSA) blocked the
implementation of encryption in the TCP/IP protocol for the original
ARPANET, because it wanted to be able to listen in on the traffic that
crossed that early precursor to the internet. Since that time, we have
been relegated to always sending clear-text packets via TCP/IP. Higher
level application protocols (i.e. ssh, HTTPS, etc.) have enabled encryption
traffic, but the vast majority of internet communication is still in the
clear. The Tcpcrypt project is an
attempt to change that, transparently, so that two conforming nodes can
encrypt all of the data portion of any packets they exchange.
One of the key benefits that Tcpcrypt offers is transparency. That means
that if both endpoints of a connection support it, the connection will be
encrypted, but if one doesn't support Tcpcrypt, the other will gracefully
fall back to standard clear-text TCP/IP. No applications are required to
change, and no "new" protocols are required (beyond Tcpcrypt itself, of
course) as applications will send and receive data just as they do today.
But there is an additional benefit available for those applications that
are willing to change: strong authentication.
Tcpcrypt has the concept of a "session ID" that is generated on both sides
as part of the key exchange. This ID can be used in conjunction with a
shared secret, like a password, to authenticate both ends of the
communication. Because the client and server can exchange cryptographic
hash values derived from the shared secret and session ID, they can be
assured that each is talking over an encrypted channel to an endpoint that
has the key (password). A "man in the middle" would not
have access to the password and therefore can't spoof the exchange.
Even without any application changes for stronger authentication, Tcpcrypt
would defend against passive man-in-the-middle attacks, like
eavesdropping. Active attacks could still spoof responses that said
Tcpcrypt was not supported, even if the other endpoint did support it, or
even relay encrypted traffic. That would still be better than the usual
situation today where a passive attacker can gather an enormous amount of
clear-text traffic, especially from unencrypted or weakly encrypted wireless
There is an Internet Engineering Task Force (IETF) draft available
that describes how Tcpcrypt works by using two new TCP options. Those two
options, CRYPT and MAC, will not be recognized by
endpoints without Tcpcrypt support, and are therefore harmless. The CRYPT
option is used to negotiate the use of Tcpcrypt and to exchange encryption
keys, while the MAC option carries a hash value that can be used
the integrity of the packet data.
In addition to the IETF draft, the project has produced a paper, The case for ubiquitous
transport-level encryption [PDF], that was presented at the 2010
USENIX Security conference. It gives a somewhat higher-level look at how
Tcpcrypt integrates with TCP/IP, while providing a lot more information on
the cryptographic and authentication algorithms. The slides [PDF] from the
presentation are also instructive.
One of the basic premises that underlies Tcpcrypt is that computers have
gotten "fast enough" to handle encrypting all internet traffic. Doing so
at the transport level, rather than in application protocols (e.g. ssh),
can make it transparent to applications. In addition, Tcpcrypt can work
through NAT devices, which is something that another lower-layer encryption
protocol, IPSec, cannot handle.
Because Tcpcrypt keys are short-lived, non-persistent public/private key
pairs, it does not
require the public key infrastructure (PKI) that other solutions, like
HTTPS, need. That means that endpoints can communicate without getting
certificates signed by centralized authorities. Of course the existing PKI
certificates will work just fine on top of Tcpcrypt.
While computers may be "fast enough" to handle encryption on every packet,
there is still the problem of asymmetry. Servers typically handle
much more traffic than clients, so Tcpcrypt is designed to put the
most difficult parts of the key negotiation and encryption onto the client
side. The claim is that speeds of up to 25x that of HTTPS (i.e. SSL/TLS)
can be achieved
by Tcpcrypt. One wonders whether mobile devices are "fast enough", but
that problem—if it even is one—is probably not one for that
Overall, Tcpcrypt is an intriguing idea. It certainly isn't a panacea for
all of today's network ills, but that is no surprise. Unlike other
proposals, Tcpcrypt can be incrementally deployed without requiring that
restart the internet. Since it won't break existing devices, it can be
developed and tested within the framework of the existing net. If for no
other reason, that should give Tcpcrypt a leg up on other potential solutions.
to post comments)