We’ve been asked to start developing a standardised approach to transferring XML data in a project, which will eventually be used throughout this particular industry. Some of the requirements include:
- XML must allow partial/complete encryption of data
- Must be able to verify the source of the XML (server and client will be known to each other)
- Must support both online and offline processing (batches)
- Any online processing must be over a secure channel
The ‘server’ and ‘client’ will ‘register’ with each other, and will both initiate the sending of messages.
Some thoughts that have been raised by the consortium:
- SOAP isn’t liked by most members – it often causes more problems and overhead than it solves
- The XML integrity and encryption is more important than the transport
- Most members prefer the concept of encryption/decryption at the application level, rather than solely at transport
- SSL connections would be online, realtime only and could not be enforced at the web-application level.
We already have a basic XML schema that has been used at the proof-of-concept stage, and basically consists of:
- A command / response type
- Variables / response messages
We’re at a high-level stage at the moment, and I’d be interested to know what standards currently exist and what approaches would suggest.
If you are going for partial encryption, then PKCS#7/CMS would quickly become a cludge. PGP is probably not very useful for this either, so this leaves you with XML signature & XML encryption standards.
For signature generation/verification it would be logical to use XML digital signature. However, you need to very clearly specify what you are going to sign and which choices you are going to make regarding verification. A good verification clearly verifies the canonicalization methods, hashing methods and so on. Beyond that you must make really really sure that what you sign is what you retrieve from the XML. It’s very easy to verify one part and find out you are using an entirely different part of XML. Sometimes software is vulnerable because an attacker can simply strip the signature from the data!
If you always (always) verify your XML before decryption, you can simply use XML encryption and AES-CBC. If you don’t, you should use GCM mode. As it is currently a working draft, it might require you to create some changes in current software. Without verification or a cipher with integrity protection, you will be vulnerable to padding oracle attacks.
Of course, for both signature generation and verification as well as encryption/decryption you should use an x509 infrastructure. You can setup you own CA software, e.g. using EJBCA, but you should get the expertise to do so (buying support?). Certificate and key management should be one of the main focusses. Alternatively, you could use standard SSL/TLS certificates. This will allow you to setup SSL enabled servers as well. If you go for SSL/TLS (highly recommended) use client authentication and a small set of safe cipher suites.
Finally, you should really limit the number of available options, while keeping options open for future changes. If you keep too many options open, it will get very tough to test and attackers will simply choose the least difficult one to attack. If performance is of interest, choose ECC for the X509 certificates with a well known named curve, but beware of the complexities and the likelyhood that some partners won’t be able to find the right libraries.
You can buy all this from reputable vendors, but I would be pretty skeptic about XML encryption support. I’ve wandered away (even before testing them) from some open source libs because I simply was not able to trust them enough. Unfortunately, I’ve seen much worse from “for profit” organizations. You need a crypto expert with a proven reputation to check the protocols and implementations – just hacking something together is not going to be good enough.