You might also find this useful (https://searchfox.org/nss/rev/d4fc405cac1d3da3b7285342b5c70e10b4dae734/lib/ssl/ssl3con.c#1358). It uses the PK11 interface to verify a signature in TLS. You might have to walk backwards to see how inputs are constructed.
On Wed, Feb 15, 2017 at 4:07 AM, Robert Relyea <rrel...@redhat.com> wrote: > 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 > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
