The need for speed

It seems like a truism to say that XML Appliances are particularly suited to processing XML Signature and XML Encryption. But, let's look at exactly why they are suited to this job...

SSL Acceleration

For SSL, a whole industry of SSL Acceleration Cards grew up (e.g. nCipher, who are speaking at the Vordel Conference on Thursday 25th). These cards accelerate the handshaking part of the SSL transaction, the part which uses asymmetric (public and private key) cryptography. The cards are particularly useful where a large number of browsers hit an ecommerce website at the same time (e.g. following a television commercial advertising the site). For each one of the browsers, handshaking must occur. If this occurs on the main CPU, it goes slowly and the site becomes slow. If it uses a cryptographic acceleration card, then delays are minimized. Once the handshaking happens, a secure session is established, and the session includes a symmetric encryption key. Subsequent traffic from that browser goes over that session, with the symmetric encryption using the main CPU not the acceleration card. i.e. The hardware acceleration is used for the assymetric (public and private key) operations.

XML Security

With XML Signature and XML Encryption, public and private cryptography is used (as well as a digest algorithm in the case of XML Signature, and a symmetric algorithm in the case of XML Encryption). This is accelerated by the use of cryptographic acceleration cards. Just as important, the cryptographic processing is taken off the core CPU, so it does not slow down the application.

Don't forget about XML Acceleration too

XML Gateways, such a Vordel's, go a step further by taking the both the cryptographic processing and the associated XML processing off the application and putting it onto the network. Remember, processing XML Signature or XML Encryption includes a significant amount of XML processing as well as the actual cryptography, and that is accelerated by an XML Acceleration subsystem.

A CPU hit for every single message

So, putting this into context, let's say a client sends 100 XML messages to an application. Here are two scenarios:

Scenario One: SSL only
If SSL alone is used, with no XML Encryption or XML Signature, then the CPU is only taxed for the initial handshake. The 100 message then sail through on the symmetric session which is then created, without acceleration being required at that point.

Scenario Two: The XML messages are signed and encrypted
In this case, each XML message is signed with XML Signature and encrypted with XML Encryption. If hardware acceleration is not used, then the application will slow noticably as the CPU is taxed with the task of processing the assymetric cryptography for every one of the 100 messages.

In fact, the most likely scenario is:

Scenario Three: The XML messages are signed and encrypted, and sent over SSL
This will tax the CPU for the initial SSL handshake, and then for the asymmetric cryptographic operations for every single one of the 100 messages.


Scenario 2 and Scenario 3 are the reasons why the addition of an XML Gateway can have a dramatic performance benefit on an application which must perform XML Signature and XML Encryption. XML security is arguably more of a sweet spot for cryptographic acceleration than ecommerce ever was.


Footnote:
There are specifications such as WS-SX which allow for an SSL-like session to occur over multiple XML messages. That would mean that if a client sends 100 messages, then the signing and encryption can make use of negotiated keys (much like in case of an SSL handshake). However, WS-SX is not widely used yet, by any means.