Attacks against XML Digital Signatures & Encryption

XML Digital Signatures are indirected signatures. To construct a signature, the content to be signed is canonicalized, digested, and metadata about the content (its location, the digest and canonicalization method) is saved as XML. This XML metadata is then itself canonicalized, digested, and the digest of the metadata is signed to produce the final signature. Key information may optionally be packaged with the signature.The order of operations for signature validation, while unimportant from a cryptographic standpoint, can have a significant impact on whether many of the attacks detailed here are available to anonymous adversaries, or if the attack surface can be authenticated.The first operation of signature validation should be key resolution. Optimally, any KeyInfo attached to the signature can be discarded, and the proper key inferred from context and provided directly by the caller. If the KeyInfo must be resolved from the signature, this resolution must be a distinct step so a trust decision in the key can be made before proceeding.The next operation is to verify the signature by canonicalizing and digesting the signed info metadata. Finally, with the instructions in the signed info metadata authenticated, resolution and verification of reference digests can proceed. Unfortunately, many implementations perform reference validation before verifying the signature, exposing the reference resolution attack surface anonymously. Common APIs of the form: KeyInfo validate (Signature s), which perform all operations and return the resolved key, expose all operations to an anonymous attacker, as a trust decision in the key cannot be made until after all processing is complete.C14N Transform Injection is the simplest and most reliable method of determining the order of operations of system in a black box manner. The author has observed no implementations that defend explicitly against this attack, so timing observations can provide a reliable test. If injecting redundant C14N transforms into a Retrieval Method element causes no change in validation timing, KeyInfo is likely not processed. If injecting redundant C14N transforms into a Reference causes a long delay before validation fails, Reference processing is likely being performed before Signature validation.The attacks are categorized as follows:1 C14N Denial of Service-> C14N Entity Expansion2 Transform Injection-> C14N Transform Injection-> XPath & XPath Filter 2.0 Transform Injection-> XSLT Transform Injection3 Hash Collision attack against SignedInfo with C14N with Comments4 External Reference Attacks5 Reference Complexity6 Element Wrapping Attacks7 Untrusted KeysCanonicalization: As canonicalization must take place prior to any cryptographic operations, attacks against canonicalization are available to the anonymous attacker.Reference Resolution: Reference resolution contains a large amount of attack surface. Whether this surface is anonymous or authenticated depends on the order of operations, as discussed above.Key Resolution: If key resolution is performed, this is attack surface is always available to the anonymous attacker, because no signature checking can be performed without a key. Attacks against RetrievalMethod fall on the key resolution surface.Signature Evasion: Some attacks are aimed at evading or subverting the cryptographic guarantees of the signature. These may fall on the anonymous attack surface, or they may be ways in which an authenticated party attempts to repudiate a signature.Pre-validation of a Signature against an XML schema is recommended in several cases to mitigate attacks against processors lacking the API support to perform adequate hardening. This validation should be done with care, and may need to be performed out-of-band on a copy of the signature, as the schema validation may introduce changes to the XML infoSet (e.g. default attributes) that invalidate the signature.