Re: xmlsec / ECDSA problem

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 <[email protected]> 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
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto