4 Replies Latest reply on Mar 6, 2012 10:03 PM by christopher skinner

    Manual verification of SignatureValue

    Giovanni Castellari Newbie
      Hello, I'm trying to do a "manual" verification of a XML-Signed message. The message is the following, taken as is
      from the server.log:
      <env:Header>
         <wsu:Timestamp wsu:Id='timestamp'>
          <wsu:Created>2010-12-07T16:37:40.038Z</wsu:Created>
         </wsu:Timestamp>
         <wsse:BinarySecurityToken EncodingType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary' ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3' wsu:Id='token-2-1291739860138-12935734'>MIIBnDCCAQUCBEz+E1kwDQYJKoZIhvcNAQEEBQAwFTETMBEGA1UEAxMKbWlvY2xpZW50MTAeFw0x
      MDEyMDcxMDU4MzNaFw0xMTAzMDcxMDU4MzNaMBUxEzARBgNVBAMTCm1pb2NsaWVudDEwgZ8wDQYJ
      KoZIhvcNAQEBBQADgY0AMIGJAoGBAJlzh8T0w+FG/uJ6oDzc6uVSJMgJhuL851BPjoAynW7wCeGV
      1EEydEr2S9qOwsUEg32mLn6s9Mf19nkI3nGHjCuS9SmIil5WilWGWsHqfFSUFB7goKeLfqdGtP5i
      WDZ4QFVZ0AjMjJZP9tAY8FYzkmJUEkcg5T2OcW/1019/Ttk5AgMBAAEwDQYJKoZIhvcNAQEEBQAD
      gYEAP6De4XP3wSYDWqSUCgJZNqddZUJFIDxYp5cV6jH4yckV/xniD3IvVcTx8bCykbwWDEec3z95
      BdYWNPuU2DPWtcab3dTtD7JXez1+Ywi2IYIexChQbthkziLXkvGoPofe9Z7BlaE3hiFzPMKWRjDF
      qSOScxAyjSebLPvczWozAWQ=</wsse:BinarySecurityToken>
         <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
          <ds:SignedInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
           <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
           <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
           <ds:Reference URI='#element-1-1291739860070-11803898' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
            <ds:Transforms xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            <ds:DigestValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>d2cIarD4atw3HFADamfO9YTKkKs=</ds:DigestValue>
           </ds:Reference>
           <ds:Reference URI='#timestamp' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
            <ds:Transforms xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            <ds:DigestValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>YR/fZlwJdw+KbyP24UYiyDv8/Dc=</ds:DigestValue>
           </ds:Reference>
          </ds:SignedInfo>
          <ds:SignatureValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
      OZg96GMrGh0cEwbpHwv3KDhFtFcnzPxbwp9Xv0pgw8Mr9+NIjRlg/G1OyIZ3SdcOYqqzF4/TVLDi
      5VclwnjBAFl3SEdkyUbbjXVAGkSsxPQcC4un9UYcecESETlAgV8UrHV3zTrjAWQvDg/YBKveoH90
      FIhfAthslqeFu3h9U20=
      </ds:SignatureValue>
          <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
           <wsse:SecurityTokenReference wsu:Id='reference-3-1291739860138-11726490'>
            <wsse:Reference URI='#token-2-1291739860138-12935734' ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3'/>
           </wsse:SecurityTokenReference>
          </ds:KeyInfo>
         </ds:Signature>
        </wsse:Security>
      </env:Header>
      <env:Body wsu:Id='element-1-1291739860070-11803898' xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
        <ns1:addizionami xmlns:ns1='http://prova/ejb/to/ws/types' xmlns:ns2='http://prova/ejb/to/ws/types'>
         <Integer_1>3</Integer_1>
         <Integer_2>78</Integer_2>
        </ns1:addizionami>
      </env:Body>
      </env:Envelope>
      This message was sent from a servlet deployed on JBoss 4.2.3GA and received by a WS-Security configured Web Service
      deployed locally (on the same JBoss instance). All the automatic JBoss verifications are successful, here's the
      log:
      2010-12-07 17:37:40,404 INFO  [org.apache.xml.security.signature.Reference] Verification successful for URI "#element-1-1291739860070-11803898"
      2010-12-07 17:37:40,405 INFO  [org.apache.xml.security.signature.Reference] Verification successful for URI "#timestamp"
      2010-12-07 17:37:40,417 DEBUG [org.jboss.ws.extensions.security.WSSecurityDispatcher] Verification is successful
      Now I want to verify this manually, so I decrypt the SignatureValue content with the public key and I obtain:
      3021300906052b0e03021a05000414dccdb8570286d36c94bba8e5107faee91e0df088
      I think I did this manual decryption well, because you can recognize the "ASN.1 BER SHA1 algorithm designator
      prefix" (http://www.w3.org/TR/xmldsig-core/) in the first part of this hex string (3021300906052b0e03021a05000414).
      So the second part (dccdb8570286d36c94bba8e5107faee91e0df088) is my hash value, i.e. the SHA1 computation of the
      canonicalized SignedInfo element, and in fact it's exactly 20 bytes long. But I can't get this hash value from the
      SignedInfo element. I'm using org.apache.xml.security.c14n.Canonicalizer for the canonicalization. Is there someone
      that can obtain this hash value and tell me the exact steps/tools/code used? Thank you in advance.

      Hello, I'm trying to do a "manual" verification of a XML-Signed message. The message is the following, taken as is

      from the server.log:

       

      <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
       <env:Header>
        <wsse:Security env:mustUnderstand='1' xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
         <wsu:Timestamp wsu:Id='timestamp'>
          <wsu:Created>2010-12-07T16:37:40.038Z</wsu:Created>
         </wsu:Timestamp>
         <wsse:BinarySecurityToken EncodingType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary' ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3' wsu:Id='token-2-1291739860138-12935734'>MIIBnDCCAQUCBEz+E1kwDQYJKoZIhvcNAQEEBQAwFTETMBEGA1UEAxMKbWlvY2xpZW50MTAeFw0x
      MDEyMDcxMDU4MzNaFw0xMTAzMDcxMDU4MzNaMBUxEzARBgNVBAMTCm1pb2NsaWVudDEwgZ8wDQYJ
      KoZIhvcNAQEBBQADgY0AMIGJAoGBAJlzh8T0w+FG/uJ6oDzc6uVSJMgJhuL851BPjoAynW7wCeGV
      1EEydEr2S9qOwsUEg32mLn6s9Mf19nkI3nGHjCuS9SmIil5WilWGWsHqfFSUFB7goKeLfqdGtP5i
      WDZ4QFVZ0AjMjJZP9tAY8FYzkmJUEkcg5T2OcW/1019/Ttk5AgMBAAEwDQYJKoZIhvcNAQEEBQAD
      gYEAP6De4XP3wSYDWqSUCgJZNqddZUJFIDxYp5cV6jH4yckV/xniD3IvVcTx8bCykbwWDEec3z95
      BdYWNPuU2DPWtcab3dTtD7JXez1+Ywi2IYIexChQbthkziLXkvGoPofe9Z7BlaE3hiFzPMKWRjDF
      qSOScxAyjSebLPvczWozAWQ=</wsse:BinarySecurityToken>
         <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
          <ds:SignedInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
           <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
           <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
           <ds:Reference URI='#element-1-1291739860070-11803898' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
            <ds:Transforms xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            <ds:DigestValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>d2cIarD4atw3HFADamfO9YTKkKs=</ds:DigestValue>
           </ds:Reference>
           <ds:Reference URI='#timestamp' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
            <ds:Transforms xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'/>
            <ds:DigestValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>YR/fZlwJdw+KbyP24UYiyDv8/Dc=</ds:DigestValue>
           </ds:Reference>
          </ds:SignedInfo>
          <ds:SignatureValue xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
      OZg96GMrGh0cEwbpHwv3KDhFtFcnzPxbwp9Xv0pgw8Mr9+NIjRlg/G1OyIZ3SdcOYqqzF4/TVLDi
      5VclwnjBAFl3SEdkyUbbjXVAGkSsxPQcC4un9UYcecESETlAgV8UrHV3zTrjAWQvDg/YBKveoH90
      FIhfAthslqeFu3h9U20=
      </ds:SignatureValue>
          <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
           <wsse:SecurityTokenReference wsu:Id='reference-3-1291739860138-11726490'>
            <wsse:Reference URI='#token-2-1291739860138-12935734' ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3'/>
           </wsse:SecurityTokenReference>
          </ds:KeyInfo>
         </ds:Signature>
        </wsse:Security>
       </env:Header>
       <env:Body wsu:Id='element-1-1291739860070-11803898' xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
        <ns1:addizionami xmlns:ns1='http://prova/ejb/to/ws/types' xmlns:ns2='http://prova/ejb/to/ws/types'>
         <Integer_1>3</Integer_1>
         <Integer_2>78</Integer_2>
        </ns1:addizionami>
       </env:Body>
      </env:Envelope>
      

       

       

      This message was sent from a servlet deployed on JBoss 4.2.3GA and received by a WS-Security configured Web Service

      deployed locally (on the same JBoss instance). All the automatic JBoss verifications are successful, here's the

      log:

       

      2010-12-07 17:37:40,404 INFO  [org.apache.xml.security.signature.Reference] Verification successful for URI "#element-1-1291739860070-11803898"

      2010-12-07 17:37:40,405 INFO  [org.apache.xml.security.signature.Reference] Verification successful for URI "#timestamp"

      2010-12-07 17:37:40,417 DEBUG [org.jboss.ws.extensions.security.WSSecurityDispatcher] Verification is successful

       

      Now I want to verify this manually, so I decrypt the SignatureValue content with the public key and I obtain:

       

      3021300906052b0e03021a05000414dccdb8570286d36c94bba8e5107faee91e0df088

       

      I think I did this manual decryption well, because you can recognize the "ASN.1 BER SHA1 algorithm designator

      prefix" (http://www.w3.org/TR/xmldsig-core/) in the first part of this hex string (3021300906052b0e03021a05000414).

      So the second part (dccdb8570286d36c94bba8e5107faee91e0df088) should be my hash value, i.e. the SHA1 computation of the

      canonicalized SignedInfo element, and in fact it's exactly 20 bytes long. But I can't get this hash value from the

      SignedInfo element. I'm using org.apache.xml.security.c14n.Canonicalizer for the canonicalization. Is there someone

      that can obtain this hash value and tell me the exact steps/tools/code used? Thank you in advance.

        • 1. Re: Manual verification of SignatureValue
          Giovanni Castellari Newbie

          Solved, thanks to Thomas Pornin.
          I'm using the org.apache.xml.security.c14n.Canonicalizer for the canonicalization of the SignedInfo element, but the resulting string needs to be further handled:

           

          - Remove all the leading spaces on each line;
          - Get an hexadecimal representation of the string above and make sure that all end-of-lines use a single LF (0A).

          • 2. Re: Manual verification of SignatureValue
            Alessio Soldano Master

            nice :-)

             

            Btw, why do you need to do this manual verification? Any kind of authentication or what?

            • 3. Re: Manual verification of SignatureValue
              Giovanni Castellari Newbie

              Hi Alessio,

              there are two reasons for this. First of all my boss asked me to provide a way to do such manual verification, so in case of contestations we can give more argumentations than "JBoss told me it was ok"; second, it's my personal interest to understand a bit more how these things work (I often need to re-implement things to ensure I've understood well).

               

              It's strange that I need to transform the xml text in two different ways to calculate the correct digests: for a successful reference validation i need to put the referenced (canonicalized) element on a single line (no spaces/line-breaks between tags), while for a successful signature validation i need to remove only the leading spaces at the beginning of each line.

               

              Anyway I'm confused about xml canonicalization. I thought it was a way to give a single and unambiguous string representation of an xml, focalizing on its semantic. Instead, xml canonicalization preserves indentation of text and I can't understand the reason, I think I'm not getting its real purpose.

               

              Thank you in advance for any clarification

              • 4. Re: Manual verification of SignatureValue
                christopher skinner Newbie

                I have Similar problem:

                Client sent "demo" XML files... certificate OK, Public Key OK, Verified to Digest with 3021300906052b0e03021a05000414 and 20 bytes which MUST BE WHAT WAS SIGNED

                BUT the  digest value NOt = "Verified" digest ,ad I cant make a digest equal to either - some fiddle-de-dee has been going on

                I also use org.apache.xml.security.c14n.Canonicalizer ....   Now I can only hope the client can provide me with the exact byte array he used to get the digest.

                Unfortunately we are in an adverserial situation, the client has an interest in seeing us fail (its a long story!) so Im not holdingmybreath.

                ..........................

                You have a similar problem:

                d2cIarD4atw3HFADamfO9YTKkKs=

                unpacks to 7767086AB0F86ADC371C50036A67CEF584CA90AB

                but you KNOW that the digest signed was different! (RSA cannot lie!)

                so through ignorance or malice someone has put an incorrect value in one or both digest fields

                 

                Message was edited by: christopher skinner