Will ubiquitous encryption of important network traffic ever happen? A group of researchers presenting at next month's Usenix Security Symposium will talk about a technology they say could make end-to-end encryption of TCP traffic the default, not the exception.
The group, made of mostly Stanford University researchers, will talk up a TCP extension known as tcpcrypt. Implemented in the transport layer, tcpcrypt protects legacy applications and provides backwards compatibility with legacy TCP stacks and middleboxes, the groups says.
The technology also provides a hook for integration with application-layer authentication, largely obviating the need for applications to encrypt their own network traffic and minimizing the need for duplication of features. Finally, tcpcrypt minimizes the cost of key negotiation on servers; a server using tcpcrypt can accept connections at 36 times the rate achieved using SSL, the researchers stated in their paper.
The group says that by using what it calls the asymmetry of common public key ciphers, it is possible for a server to accept and service around 20,000 tcpcrypt connections per second without session caching. Even higher rates are possible with caching. Data transfer rates are not an issue either; encryption and integrity protection can be done at several gigabits p/sec without hardware support on 2008-era hardware, according to their paper.
"The newest Intel CPUs incorporating AES instructions are even faster-tcpcrypt can reach 9Gb/s using AES-UMAC on a dual-core i5 desktop, suggesting that six-core i5 servers should handle 10Gb/s. These results suggest that tcpcrypt should have a negligible impact on the vast majority of applications," the researchers state.
"The main contribution of this work is not performance, though this is a prerequisite. There are no new cryptographic primitives, nor is the protocol especially novel. The main contribution is from putting well-understood components together in the right way to permit rapid and universal deployment of opportunistic encryption, and then providing the right hooks to encourage innovation and deployment of much better and more appropriate application-level authentication. This ability to integrate transport-layer security with application-level authentication largely obviates the need for applications to encrypt their own network traffic, thereby minimizing duplication of functionality," the researchers state.
So why isn't more traffic encrypted? The researchers offered up these reasons:
The group goes on to state that they believe that each of these points either is not true, or can be directly addressed with well-established techniques. "Application writers have little motivation: encryption rarely makes a difference to whether an application succeeds. Getting it right is difficult and time consuming, doesn't help time to market, and developers are hard-pressed to make the business case. For server operators, too, the process can be tedious. One reason people don't use SSL is that X.509 certificates are a mild pain both for the server administrator and, if the server administrator didn't buy a certificate from a well-known root CA, for users."
End-to-end encryption is one of the ideal ways data can be protected in the wild. Recently Heartland Payment Systems, the victim last year of a massive data breach of sensitive card data, vowed after that devastating event to develop new security gear based on end-to-end encryption between itself and its merchants to prevent such a breach from occurring again.
IBM has rolled out a security device it says will protect online banking and keep cyber-criminals from being able to make fraudulent funds transfer even from a compromised PC. The IBM technology, called Zone Trusted Information Channel (ZTIC), is a UBS device that uses X.509 certificate-based encryption to set up a trusted channel with bank servers that routinely handle funds transfers and payments requests to make sure these requests are real.
Follow Michael Cooney on Twitter: nwwlayer8
Layer 8 Extra
Check out these other hot stories: