santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44204] - signature/verification fails when in the same thread same key is used twice
Date Thu, 07 Feb 2008 23:41:50 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44204>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44204





------- Additional Comments From putmanb@georgetown.edu  2008-02-07 15:41 -------
I spent some time diagnosing this, as it was also reported by one of our
project's users.

This is occurring when, for the first signature, you use the same XMLSignature
instance to both sign and then verify the signature.  If you create a new
XMLSignature instance around the Signature element and verify using that, the
problem does not occur.  So I guess that's the workaround.  I know using the
same instance for both has been discouraged on the list before.

The explanation: this is occurring because of how the ThreadLocal instances* and
keys* caches in SignatureAlgorithm are being used.  What happens is:

1) sign document.  The instancesSigning and keysSigning caches are populated
with the SignatureAlgorithmSpi instance and key reference as expected.

2) Call checkSignatureValue() with same XMLSignaure.  Note the same
SignatureAlgorithm instance is being used, with an already populated instance of
SignatureAlgorithmSpi.

3) When initVerify() is now called, the initializeAlgorithm() is a no-op,
because the underlying SignatureAlgorithmSpi on that instance is already there.
 However the keysVerify map does *not* contain the entry for that
algorithmURI->key, so that is added and the Spi engine is (re)-initialized for
*verifying*.

4) verification is successful.  Note at this point that you have entries in both
keysSigning and keysVerify for that key, but only one Spi instance, cached in
instancesSigning (but left in a state initialized for *verifying* with that key!)

5) now verify a new signature with the same algorithmURI and key instance.  New
XMLSignature instance is created, with new underlying SignatureAlgorithm instance.

6) checkSignatureValue() calls initVerify().  Here's where the (evil) magic
happens.  initializeAlgorithm() has to obtain the right SignatureAlgorithmSpi
instance.  There is *not* one in instancesVerify (b/c the previous verification
used the one which was cached in instancesSigning).  So it creates a new one and
stores in the cache.  However, because the last key used for that algorithmURI
for verification, as cached by keysVerify, is the same key, it does *not* call
the Spi's engineInitVerify().  So the underlying java.security.Signature/Mac
instance is never initialized, resulting in the java.security.SignatureException
when it is actually used.

Note also that if the next attempt to *sign* something with that algorithmURI
were with the same key, I believe you'd get a similar error.  The cached
instance of the Spi in instancesSigning wouldn't get reinitialized because of
the optimization.  And since it was last initialized for *verifying* not
signing, I assume that causes Bad Things to happen.

Note this is similar to the bug I analyzed in:
http://issues.apache.org/bugzilla/show_bug.cgi?id=44335

It's coming from the fact that the optimization in SignatureAlgorithm#initVerify
(and also #initSign) assumes that if the last key used per algorithm is the same
as the current one, then the engine is already in a known good "ready" state and
doesn't need to be reinitialized.

Assuming the optimizations are maintained, I think a good possible solution for
both is for the Spi to expose state as to whether: 1) it is in the "ready" state
2) whether it is currently initialized for signing or verifying.  This would
allow the SignatureAlgorithm init methods to always do the right thing
(reinitialize the Spi engine) when necessary.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message