Manual verification of XML Signature

Question

I can successfully do manual reference validation (canonicalize every referenced element --> SHA1 --> Base64 --> check if it\'s the same of DigestValue content) but I fail with

Answer 1

MCEwCQYFKw4DAhoFAAQU3M24VwKG02yUu6jlEH+u6R4N8Ig= is Base64 encoding for a DER-encoded ASN.1 structure: a SEQUENCE containing first an AlgorithmIdentifier (which states that this is SHA-1, with no parameters since SHA-1 accepts none), then an OCTET STRING which contains the actual 20-byte value. In hexadecimal, the value is: dccdb8570286d36c94bba8e5107faee91e0df088.

This ASN.1 structure is part of the standard RSA signature mechanism. You are using RSA decryption to access that structure, which is non-standard. You are actually lucky to get anything at all, since RSA encryption and RSA signature are two distinct algorithms. It so happens that they both feed on the same kind of key pairs, and that the "old-style" (aka "PKCS#1 v1.5") signature and encryption schemes use similar padding techniques (similar but not identical; it is already a bit surprising that the Java implementation of RSA did not choke on the signature padding when used in decryption mode).

Anyway, 6l26iBH7il/yrCQW6eEfv/VqAVo= is Base64 encoding for a 20-byte value, which, in hexadecimal, is: ea5dba8811fb8a5ff2ac2416e9e11fbff56a015a. This is what you get by hashing the XML structure you show above, after having removed all whitespace between tags. Removing all whitespace is not proper canonicalization. Actually, as far as I know, whitespace is affected only between attributes, within the tags, but external whitespace must be kept unchanged (except for line ending normalization [the LF / CR+LF thing]).

The value which was used for the signature generation (the dccdb85...) can be obtained by using the XML object you show and by removing the leading spaces. To be clear: you copy+paste the XML into a file, then remove the leading spaces (0 to 3 spaces) on each line. You make sure that all end-of-lines use a single LF (0x0A byte) and you remove the final LF (the one just after </ds:SignedInfo>). The resulting file must have length 930 bytes, and its SHA-1 hash is the expected dccdb85... value.

Answer 2

Looking at your particular XML token, I can tell you a few things.

• You are using the Canonicalization method Exclusive XML Canonicalization Version 1.0. This is a very IMPORTANT factor in ensuring that you produce the right digest values and signature.

• You are using the same Canonicalization method both for computing the reference digests, and for canonicalizing the SignedInfo before producing the signature.

The specification for Exclusive XML Canonicalizaiton Version 1.0 is produced by W3C and can be found at its respective W3C Recommendation. If you are computing your values manually, be sure that you are conforming exactly to the specification, because canonicalization is a hard thing to get right, and is very important to do this correctly, otherwise your values will be incorrect.

I just wrote an extensive article describing the XML Signature validation process. The article is located at my blog. It describes the process in much more detail than my answer, as there are many intricacies to XML Signature. It also contains links to prevalent specifications and RFCs.