OpenSAML user discussion

[Tom Delorenzi <>]

Thanks brent. Good info. 

-----Original Message-----
From: Brent Putman 
[mailto:]
 
Sent: Tuesday, March 16, 2010 2:47 PM
To: 

Subject: Re: [OpenSAML] Yet another signature verification problem



On 3/16/10 10:18 AM, Tom Delorenzi wrote:
> >  
> 
> KeyInfoCredentialResolver resolver =
> SecurityHelper./buildBasicInlineKeyInfoResolver/();
> KeyInfo keyInfo = sig.getKeyInfo();
> CriteriaSet criteriaSet = new CriteriaSet(new 
> KeyInfoCriteria(keyInfo)); try {
>   for (Credential cred : resolver.resolve(criteriaSet))
>   {
>     SignatureValidator sigValidator = new SignatureValidator(cred);
>     sigValidator.validate(sig); 
>   }
> }



That code looks fine to me, as far as just validating the signature
against the KeyInfo-supplied key.  That code itself can't be causing any
of your problems, it's too simple and too high level.  Your failures are
much lower down at the Apache xmlsec layer.


> 
> The simulator failed in XMLSignature which for me was line 625 doing:
> 
> // have SignatureAlgorithm sign the input bytes and compare them to
> // the bytes that were stored in the signature.
> 
> if (!sa.verify(sigBytes))
> 


That's indicating a failure to validate the SignedInfo with the supplied
key. I don't think we see this failing as much as the next case.

Nominally either 1) the key is wrong, or else 2) the SignedInfo has been
modified from what was signed, or is at least being evaluated
differently by the verifier than the signer.  Assuming the latter is the
case, and that they aren't any obvious ways in which the document is
being modified (intentionally or unintentially reformatted after
signing, possibly by some aspect the
serialization/deserialization/unmarshalling process), one thing you
might check is the canonicalization algorithm in use.  If it's not one
of the exclusive ones, then that might be causing it, e.g signing
environment is different than the validation one wrt parent element
namespace decls and so forth.


>  
> The precanned one passed that but failed a bit later in
> Reference.verify() in the following block
> 
> byte[] elemDig = this.getDigestValue();
> byte[] calcDig = this.calculateDigest(true);
> boolean equal = MessageDigestAlgorithm./isEqual/(elemDig, calcDig);
> if (!equal) {
> /  log/.warn("Verification failed for URI \"" + this.getURI() + "\"");
> /  log/.warn("Expected Digest: " + Base64./encode/(elemDig));
> /  log/.warn("Actual Digest: " + Base64./encode/(calcDig));
> }



That's the more typical case that the target of the signature that was
signed (the target of the Reference) is in some way not the same bytes
that are being verified.  That's almost always due to some unintentional
modification of the data (reformattting after the signature, etc), but
could also be the c14n issue above, I'd check that.




>  
> If anyone has any suggestions let me know. Thanks!


As always, you'll get some useful info from turning on the Apache xmlsec
logs at DEBUG for categories:


org.apache.xml.security.utils.SignerOutputStream  (for the SignedInfo)
org.apache.xml.security.utils.DigesterOutputStream  (for the Reference)


Looking at those closely by themselves alone might give you some hints
(i.e. look for what namespace decls might be getting pulled in there by
the canonicalizer), but they are mostly only useful if you have the same
data from the signing side with which to compare.  If you can get both,
the problem usually becomes immediately clear - you'll see what the
differences are, and can then usually infer what is causing them in the
source document in the processing flow.



--Brent