Saturday, April 22, 2006
Could you sign here, please?
What I like very much about web services, is that it's XML. It forces flat-file minded people to flip a switch in their brains to become XML junkies. Converting from flat-file to XML can go from simply putting an XML tag around the flat-file up to a well structured and self-explaining XML document. Besides the fact that a nicely structured XML document is easier to work with, it also brings the additional benefit that project managers find it sexy in their presentations. So that's really the way to go I'd say.
Now during this XML convertion process people might stumble on a thing called digital signatures. Some will take signatures as an argument for sticking with their flat-file while others persist in their XML-ification and inevadibly hit XMLDSig after a while. XML based signatures are a hot topic these day. With XAdES (see DContract for an implementation) even politics is trying to get a grip on it. Unfortunately converting regular signatures to an equivalent XML signature, according to the XMLDSig specification, is not a straightforward process. The big difference with XML signatures is the level of freedom. And, freedom is dangerous as it comes to security. Instead of specifying the signature algorithms in a bullshit big-design-up-front document, one can now specify all signature parameters at runtime within the XML signature element itself. We can choose the signature algorithm, the digest algorithms, we can even specify what to sign via the ds:Reference elements. All this freedom is very cool if we don't forget that in the end it is a machine that has to be able to verify the correctness of the XML signature. Especially verifyingwhat has been signed is a big challenge. Checking the URI attribute of the ds:Reference elements just is not enough. A ds:Reference can contain transformations with the most exotic XPath expression one can ever think of. This opens up a door for XML signature attacks. So it is of crucial importance to also verify what has been signed. For the do-it-yourself creative brains under you, please don't start analysing the transformation expressions. Instead, analyse what the XML signature engine will eventually digest itself. In case you're using the Apache XML Security library, one can retrieve the DOM node set that will be digested by the XML signature algorithm via:
Take some critical DOM nodes out of the original document yourself and verify whether the're present in the digested node set. If not, someone is trying to mess with your system.
Now during this XML convertion process people might stumble on a thing called digital signatures. Some will take signatures as an argument for sticking with their flat-file while others persist in their XML-ification and inevadibly hit XMLDSig after a while. XML based signatures are a hot topic these day. With XAdES (see DContract for an implementation) even politics is trying to get a grip on it. Unfortunately converting regular signatures to an equivalent XML signature, according to the XMLDSig specification, is not a straightforward process. The big difference with XML signatures is the level of freedom. And, freedom is dangerous as it comes to security. Instead of specifying the signature algorithms in a bullshit big-design-up-front document, one can now specify all signature parameters at runtime within the XML signature element itself. We can choose the signature algorithm, the digest algorithms, we can even specify what to sign via the ds:Reference elements. All this freedom is very cool if we don't forget that in the end it is a machine that has to be able to verify the correctness of the XML signature. Especially verifying
XMLSignatureInput signatureInput = signature.getSignedInfo().getReferencedContentAfterTransformsItem(0);
Set<Node> nodeSet = signatureInput.getNodeSet();
Take some critical DOM nodes out of the original document yourself and verify whether the're present in the digested node set. If not, someone is trying to mess with your system.