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
