INTEL HELD RESEARCH@INTEL DAY at the Computer Museum in MountainView, California last week. They presented a TLS replacement technology that could make it easier to deploy very large numbers of secure connections across the internet.
The technologies they presented are an attempt to addresses enterprise concerns about cloud computing security as well as next-generation consumer use of the public Internet. Intel did this by combining some hardware innovation with some system tuning. They were showing next-generation network processors (i.e. smart NIC cards) that can perform bulk encryption/decryption directly in the processing pipeline. This allows them to avoid the overhead of previous crypto hardware which had to switch keys, a slow task, as it processed a stream of multiple connections.
A prototype encrypting NIC
In order to make this all work for large numbers of connections, they took a look at the TLS protocol and came up with some changes. The suits will label this something bland like “system tuning”, and the IETF geeks will get pouty. To be fair, I think it wasn’t until the great protocol specification projects of the Dot-Com era came to a close that we learned to consider hardware implementations when designing crypto protocols. It is reasonable to say that proposing a TLS variant is not outrageous, but Intel still should take it to the IETF and all that…
They propose and have prototyped a TLS variant that facilitates the use of this technology. It puts a small (16 byte) context tag into the header, allowing each packet to keep it’s own state so the hardware one each side does not have to. With that lower of overhead, this could be used for provide offloaded secure connections between two cloud computing facilities at the enterprise or super-enterprise (Google/Amazon/Microsoft) scale.
End-To-End Security as it is labeled is clearly presented as early stage research. You could tell that by the way the dude segfaulted when I asked for an architecture diagram ;-) It would be nice to see it prototyped inside OpenSSL so interested parties could play with a Firefox/LAMP configuration when evaluating it.
Intel did think about these things – they brought the almost-not-intimidated grad student who has to put this in OpenSSL to Research@Intel day. Another good sign is that they are talking about it at an early stage, something you wish would happen any time a vendor proposes a major protocol change.
As an enterprise-class crypto plumber I wish they had addressed larger key sizes, and there are various other architecture details you’d want to work out before deploying this. Then again, it is a research project, so there is still time. It was very encouraging to see that Intel is finally putting crypto into the instruction set, we’ve been waiting for that for a long time.
They presented other security research projects which were just as interesting. So the corporation has figured out how to put some money into this topic. That’s nice to see in everyone’s biggest silicon industry trading partner.
The old way and the new way
Traditionally TLS (SSL encryption) was handled by the web server (i.e. Apache or IIS) and the web browser, together they maintained the two ends of the secure connection. As the Internet has evolved, offloading the crypto processing to an external appliance has become a viable solution. So for example you can have an F5 SSL Appliance providing many connections (on the order of hundreds) for several servers.
A typical installation would have one SSL offload appliance connected directly to the internet on the public side and connected to one or more conventional web servers on the protected side. The TLS processing work is offloaded to the appliance and all those servers don’t have to deal with securing the connection. You can construct such an environment so that the users who connect to those servers have secure connections provided by the infrastructure.
In the research presented by Intel this general solution is made more efficient through the use of optimizations in the TLS connection process. In the traditional solution a connection is established through conventional network protocol processing and then the connection itself is processed using current-generation encryption hardware. Each connection has it’s own set of crypto keys – that’s one of the reason it’s secure.
In order to process many connections simultaneously, the encryption hardware must be loaded with the appropriate keys before the network traffic for that connection can be processed. This key loading operation consumes resources – time, bus bandwidth, and memory. In the Intel research they’ve slightly modified the TLS protocol so that when network traffic arrives at the TLS connection endpoint (i.e. their new TLS-capable silicon) it contains a connection identifier that can be used to quickly select the keys to be used.
Intel also supports direct encryption in the NIC. This means that instead of moving the data out of some network device into some crypto device to perform the encrypt/decrypt operation, they do it directly in line. This allows them to provide more efficient processing of the TLS connection because the keys and the data arrive at the crypto subsystem together and there is no more “key loading” process.
The use of this TLS protocol variant allows the encryption function to be efficiently integrated into the data pipeline. That allows them to get to a much higher connection count, a claimed 10x improvement, with less hardware than conventional solutions offer. How can you argue that?S|A
Rodney
Latest posts by Rodney (see all)
- Dan Kaminsky Feels a disturbance in The Internet - Aug 2, 2009
- Defcon 17: Still going strong - Aug 1, 2009
- It’s time for Black Hat once again - Jul 26, 2009
- Intel Research shows off next-generation crypto technology - Jun 24, 2009