Repository navigation
Wrong Digest Value generated. Actual XML and Expected XML is not matching. Working from last three nights. #212
Description
Dear All,
I have used this library to generate a signature which is done at root level. The signed xml is not matching as per the expected xml. The digested value and signature value is not matching with real real value. Can't figure this out working from last three night and almost gone mad. please help me out.
var builder = require('xmlbuilder');
var SignedXml = require('xml-crypto').SignedXml;
var fs = require("fs");
module.exports.SXML = function() {
//Created the request XML as per the required format
var xml = builder.create('Esign').att('AuthMode', '1').att('aspId', 'TNIC-001').att('kycId', '')
.att('ekycIdType', 'A').att('responseSigType', "pkcs7")
.att('responseUrl', 'https://nic-esigngateway.nic.in/eSign21/response?rs=localhost:8080/Esign_client/hello1')
.att('sc', 'Y').att('ts', '2020-05-19T11:28:01').att('txn', '999-ESIGN-DIVISION-2020-05-19T11:28:01')
.att('ver', '2.1');
//xml.ele("Docs").ele("InputHash",{'docInfo':'hello', 'hashAlgorithm':'SHA256', 'id':'1'},'5df2936623312f38371871bf5226e666c66318329d826bf7db544237096a837e');
xml.ele("Docs").ele("InputHash", {
'docInfo': 'hello',
'hashAlgorithm': 'SHA256',
'id': '1'
}, '5df2936623312f38371871bf5226e666c66318329d826bf7db544237096a837e');
// XML doc is ready for signing. Converted to String
var xmldoc = xml.toString({
pretty: true
});
var sig = new SignedXml();
//sig.addReference("/*",['http://www.w3.org/2000/09/xmldsig#enveloped-signature'],'http://www.w3.org/2001/04/xmlenc#sha256','','','',true);
sig.addReference("/*", ['http://www.w3.org/2000/09/xmldsig#enveloped-signature'], 'http://www.w3.org/2000/09/xmldsig#sha1', '', '', '', true);
sig.signingKey = fs.readFileSync("nicesign.pem");
sig.canonicalizationAlgorithm = "http://www.w3.org/TR/2001/REC-xml-c14n-20010315";
sig.signatureAlgorithm = "http://www.w3.org/2000/09/xmldsig#rsa-sha1";
sig.computeSignature(xmldoc.toString());
return sig.getSignedXml();
}Output XML is:
<Esign AuthMode="1" aspId="TNIC-001" kycId="" ekycIdType="A" responseSigType="pkcs7" responseUrl="https://nic-esigngateway.nic.in/eSign21/response?rs=localhost:8080/Esign_client/hello1" sc="Y" ts="2020-05-19T11:28:01" txn="999-ESIGN-DIVISION-2020-05-19T11:28:01" ver="2.1">
<Docs>
<InputHash docInfo="hello" hashAlgorithm="SHA256" id="1">5df2936623312f38371871bf5226e666c66318329d826bf7db544237096a837e</InputHash>
</Docs>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>4IoV5vTOEUL9jI4p5N2Z+oq6rgY=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>qQ4DZk+OZNMsalFk2J9ke9QEyv0FwqpBbY2k5s22JivHPuC0lbhxW0xAH7XOkTB4s6kJGL3sf1+Q19V8BL1uX62AgJeWukkQ9qWf72KmIVOT6DUqKDst2rFIZRLUSSNwBqfspzX2aQbHriImLll0LOAkha5bFAZSLlzClVDR0ULGkMEfVfe+e6p84b7zY5HRrH2nBXF1+37C/TUA7pLnUGqP9WILRyh4z+2qguhZTV5oqNWDCFJ1JfwxYJqr+1YVqhIc4AK6v0c3MmPRElH97t98D/R+NVqy3GpOCX9+LldqLJJbCoVnYWMOAb2Au1Cf1K0gg5GJpIjtEGIJT80dXA==</SignatureValue>
</Signature>
</Esign>Expected Output is: (Difference in digest value and even if the algorithm mentioned in this same as well as content of the XML)
<Esign AuthMode="1" aspId="TNIC-001" kycId="" ekycIdType="A" responseSigType="pkcs7" responseUrl="https://nic-esigngateway.nic.in/eSign21/response?rs=localhost:8080/Esign_client/hello1" sc="Y" ts="2020-05-19T11:28:01" txn="999-ESIGN-DIVISION-2020-05-19T11:28:01" ver="2.1">
<Docs>
<InputHash docInfo="hello" hashAlgorithm="SHA256" id="1">5df2936623312f38371871bf5226e666c66318329d826bf7db544237096a837e</InputHash>
</Docs>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>4IoV5vTOEUL9jI4p5N2Z+oq6rgY=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>qQ4DZk+OZNMsalFk2J9ke9QEyv0FwqpBbY2k5s22JivHPuC0lbhxW0xAH7XOkTB4s6kJGL3sf1+Q19V8BL1uX62AgJeWukkQ9qWf72KmIVOT6DUqKDst2rFIZRLUSSNwBqfspzX2aQbHriImLll0LOAkha5bFAZSLlzClVDR0ULGkMEfVfe+e6p84b7zY5HRrH2nBXF1+37C/TUA7pLnUGqP9WILRyh4z+2qguhZTV5oqNWDCFJ1JfwxYJqr+1YVqhIc4AK6v0c3MmPRElH97t98D/R+NVqy3GpOCX9+LldqLJJbCoVnYWMOAb2Au1Cf1K0gg5GJpIjtEGIJT80dXA==</SignatureValue>
</Signature>
</Esign>
Activity
djaqua commentedon May 8, 2023
@niladrinic did you ever figure this out or do you still need help with it?
cjbarth commentedon May 29, 2023
@niladrinic , I've pretty printed your code and used properly labeled fences to make it much easier to read. After pretty printing the XML, it appears that both are the same. If more help is needed, more information is needed. Please reply with more information to reopen this.
CarlaMck77 commentedon Aug 13, 2023
I have a mismatched DigestValue and SignatureValue as well. I have no idea how to fix it. This is new to me.
Have you figured out what was causing this issue?
cfficaurzua commentedon Feb 15, 2024
i have the same problem
I checked byte by byte
the digest value is indeed wrong
other libraries with same configuration gets another value
I also check with this tool https://tools.chilkat.io/xmlDsigVerify.cshtml
cjbarth commentedon Feb 15, 2024
I am sorry that you're having issues. We certainly want to fix them, however, we don't have enough information to help. The original post lists the expected output as the exact same as the produced output, so we've got nothing to go on there. Please provide more information, sample code, received vs. expected, etc., otherwise there is nothing that anyone can do to help.
srd90 commentedon Feb 16, 2024
Issue reporters didn't share anything to work with so lets try at least something.
At the time when issue was raised (based on timestamp)
xml-cryptoversion was1.5.3andxmlbuilderis/was15.1.1.This gives us about following
package.json{ "name": "foo", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "license": "ISC", "dependencies": { "xml-crypto": "1.5.3", "xmlbuilder": "15.1.1" } }BUT lets start by asking second opinion about Digest value from
xmlsec1tool:Script output is:
and
DigestValueis:if produced signed XML is pasted to https://tools.chilkat.io/xmlDsigVerify.cshtml it reports
Pretty printed version of output signed xml for better readability
Now lets try with code snippet from issue report
Output signed XML is:
and
DigestValueis:if produced signed XML is pasted to https://tools.chilkat.io/xmlDsigVerify.cshtml it reports
Pretty printed version of output signed xml for better readability
FWIW,
xml-crypto3.1.0is used result is same.4.xand5.xbecause those should be marked vulnerable and no-one should use thosexml-crypto6.0.0quick grepping around
xml-cryptocodebase about used algorithms it turned out thathttp://www.w3.org/TR/2001/REC-xml-c14n-20010315is not explicitly tested.Based on aforementioned observation searching issues which have string
20010315: https://github.com/node-saml/xml-crypto/issues?q=is%3Aissue+is%3Aopen+20010315returned among other things #210 (tl;dr; with just enveloped-signature at transformatons array digest values mismatch but with enveloped-signature followed by REC-xml-c14n-20010315 digest values matched ).
Lets try to add REC-xml-c14n-20010315 to the transformations list:
Output signed XML is:
and
DigestValueis:if produced signed XML is pasted to https://tools.chilkat.io/xmlDsigVerify.cshtml it reports
Pretty printed version of output signed xml for better readability
So:
REC-xml-c14n-20010315transform) which passed XmlDsigVerify's test.REC-xml-c14n-20010315to the transformations list) produced exactly same digest as "second opinion case" and XmlDsigVerify had same opinion about digest value.I have no idea whats actually wrong with
xml-crypto<= 3.1.0versions (didn't test with>= 6.x) but now there exists some test material for debugging and comparing with outputs of other tools.I don't have any idea who (xml-crypto, xmlsec1 and/or XmlDsigVerify) is interpreting spec correctly.
edit: added pretty printed versions of signed output xmls for better readability
srd90 commentedon Feb 16, 2024
Testing whether #212 (comment) comments "second opinion case's" signed xml output verifies without errors with
xml-crypto1.5.3(note: that XML has digestvalue that matches with content based on "third opinion" and that particular XML doesn't have explicitly listed REC-xml-c14n-20010315 transformation at transformations list:output is
based on this it seems/feels as if this (from
1.5.3) would not be applied symmetrically (i.e. as if it would be applied to signature validation part only where-as other tools seem to be applying implicitly for digestvalue calculaton also or something like that):xml-crypto/lib/signed-xml.js
Lines 656 to 667 in d295ecc
cjbarth commentedon Feb 17, 2024
@srd90 your sample code here gives a lot to go on, and I'm glad you were able to find this. @niladrinic , @CarlaMck77 , @cfficaurzua , if any of you would like to put up a PR to address this, that would be most welcome. I don't know when I'll have time to look into this, especially since this problem isn't affecting anything I'm working on. Even if you just put up a PR with a test that fails, that would be a huge help to getting things rolling.
cjbarth commentedon Sep 24, 2026
This was fixed by #581, released in 6.2.0. When
enveloped-signaturewas the only transform, signing hashed xmldom's serialization of the node while verification applied the implicit C14N, so the two disagreed. Both sides now canonicalize a node-set left at the end of the transforms, as the XMLDSig reference processing model requires.With 6.3.2, the reproduction in #212 (comment) produces
1vWDVKN2jliWtO825GBmO4M3il4=, the digest xmlsec1 computed, without listing the C14N transform explicitly. 6.1.2 still produced4IoV5vTOEUL9jI4p5N2Z+oq6rgY=.If you still see a digest mismatch on 6.3.2 or later, please comment here with a reproduction and we'll reopen.