Re: xmlsec / ECDSA problem

On 02/14/2017 03:07 AM, Miklos Vajna wrote:
> Hi,
>
> xmlsec from <https://www.aleksey.com/xmlsec/> is a library to verify XML
> signatures (and more). It has a number of backends, one of them being
> NSS. Currently only the openssl backend of xmlsec supports ECDSA, and
> I'm trying to add support for ECDSA in its NSS backend. My first goal
> would be verifying a signature I know is valid (since openssl accepts
> it).
>
> Here is my work-in-progress code:
>
> https://github.com/vmiklos/xmlsec/commit/fd56f6d42819cbd50b34d471332fb2d948a75a60
>
> If you ignore the boilerplate code, it maps the xmlsec ECDSA key type to
> ecKey, the xmlsec ECDSA-SHA256 combined type to
> SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATUR.
>
> If you clone that repo, and built it like (on Linux):
>
> ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-gcrypt --without-openssl --enable-debugging
> make
> cd tests/aleksey-xmldsig-01
> ../../apps/xmlsec1 verify --trusted-der ../keys/cacert.der --enabled-key-data x509 enveloping-sha256-ecdsa-sha256.xml
>
> is a reproduce for the problem I have. Here are the details I figured
> out so far:
>
> - NSS wants the signature data (64 bytes) as a der-encoded pairs of
>    integers, so need to encode them before handing over the SECItem to
>    NSS in my client code (the above patch already does that).
> - Once this is solved, VFY_EndWithSignature() fails with (end of my gdb
>    session):
>
> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
> (gdb)
> 383         SECStatus rv = SECSuccess;
> (gdb)
> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
> (gdb)
> 400         if (crv != CKR_OK) {
> (gdb) print /x crv
> $1 = 0x130
> (gdb) bt
> #0  PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, count=count@entry=7, token=token@entry=0,
>      objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:400
> #1  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
> #2  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
>      wincx=<optimized out>) at pk11obj.c:736
> #3  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
> #4  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360) at secvfy.c:596
> #5  0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
>      data=0x6b36c0 "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
>      dataSize=64, transformCtx=<optimized out>) at signatures.c:347
> #6  0x0000000000443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
> #7  0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at xmldsig.c:353
> #8  0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) at xmlsec.c:1223
> #9  0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at xmlsec.c:1058
>
> 0x130 is CKR_DOMAIN_PARAMS_INVALID.
>
> Needless to say, if I do the RSA equivalent of this (the name of the
> test file in the same directory is enveloping-sha256-rsa-sha256.xml),
> then verification works fine.
>
> Any idea what can be the problem here? At least with the distro-provided
> nss (which is build with optimization enabled) I can't step into
> C_CreateObject() in gdb.
You would need to install the -debug package for nss-softokn on the 
distro to step into softoken (assuming you aren't using a hardware 
accellerator).

Fortunately you've provided enough information to get an idea of what is 
going on. EC keys have a der encoded parameter telling it what curve the 
key is associated with (generally a der encoded oid pointing to the 
specific curve). The parameter is in the field u.ec.DerEncodedParams, 
and usually applications get this from the spki in a DER certificate, or 
a raw spki encoded structure. You'll need to map the xml way of 
identifying the curve into the der encoding. NOTE: NSS only supports 
what's called the 'named curve' format of the parameters, so if xml is 
using raw curve parameters, then you'll have to map the raw curve 
parameters into known named curves.

bob
>
> But maybe there is something more fundamental here. :-)
>
> If there is anything above that is not enough for reproducing the
> problem, please let me know.
>
> Thanks a lot,
>
> Miklos


-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto