Re: What Should I Push On?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/7/2012 9:45 AM, Douglas E. Engert wrote:


On 5/5/2012 12:58 PM, Henry B. Hotz wrote:
Thanks for the info. I may have issues to deal with afer this one. *sigh*

Since the specific problem shows with a PKCS12 credential as well, I'm thinking I should get a real RedHat 6.2 instance to test with first.


Here is a possible patch that appears to work for 1024 bit keys at least:

--- ./src/libckyapplet/,cky_applet.c    Fri May  4 13:34:35 2012
+++ ./src/libckyapplet/cky_applet.c     Mon May  7 13:40:23 2012
@@ -1298,7 +1298,7 @@
     if (length + dataSize > CKY_MAX_WRITE_CHUNK_SIZE) {
        CKYBuffer_AppendBuffer(&tmp, data, 0, CKY_MAX_WRITE_CHUNK_SIZE-length);
     } else {
-       CKYBuffer_AppendBuffer(&tmp, data, 0, length+dataSize);
+       CKYBuffer_AppendBuffer(&tmp, data, 0, dataSize);
     }

     prsd.tag_1.tag = 0;
@@ -1331,7 +1331,7 @@
     }

     pasd.chain = 0;
-    pasd.len = dataSize;
+    pasd.len = dataSize + 1 + ber_len_1 + 1 + ber_len_2;

     ret = CKYApplet_HandleAPDU(conn, PIVAppletFactory_SignDecrypt,
                            &pasd, NULL, CKY_SIZE_UNKNOWN,




This morning, after using the pcscd -d -f -a to look at the
APDU commands sent to the card and the responses:

It looks like the PIVApplet_signDecrypt routine in cky_applet.c
is sending a short command without the data (RSA padded data)
to be signed, and it is only requesting the first 128 bytes of
the response.

The response includes a header that the PIV will return with
the signature.

The PIV card is taking this as the data to be signed is all zero
or whatever is in some buffer on the card, and the header plus the
first 122 bytes of the signature is returned as requested, and
status of "90 00" Success is returned.

The header returned is 6 bytes for a RSA 1024 bit key.

The coolkey parses the header, skips the 6 bytes and only
returns the 122 bytes, even though the header says there should
be 128 signature.

Attached is pcscd output showing what Coolkey and OpenSC do
with a sign operation. (Note some data bytes changed to XX XX
to not expose a valid signature.)


On May 4, 2012, at 1:40 PM, Douglas E. Engert wrote:

On 5/4/2012 8:57 AM, Douglas E. Engert wrote:


On 5/3/2012 11:18 PM, Greg Hudson wrote:
On 05/03/2012 08:52 PM, Henry B. Hotz wrote:
[5571] 1336088306.8828: Selected etype info: etype aes256-cts, salt "SC.JPL.NASA.GOVhotz", params "
CoolKey PIN:
[5571] 1336088310.707006: Preauth module pkinit (16) (flags=1) returned: 12/Cannot allocate memory
[5571] 1336088310.708361: Preauth module pkinit (15) (flags=1) returned: 12/Cannot allocate memory

That almost certainly indicates a bug--either in our code, the
Scientific Linux packaging of it, or the PKCS11 library invoked for the
PIV card.


What version of coolkey are you running? In the past coolkey only supported
the CAC cards. DOD has been moving to dual CAC and PIV cards. NASA cards may
be PIV only, thus may not work with some versions of coolkey.

To test if it is a PKCS#11 issue, OpenSC has a pkcs11-spy module
that could be used to trace the PKCS#11 calls and results.

export PKCS11SPY=/usr/lib64/pkcs11/libcoolkeypk11.so
kinit -X X509_user_identity=PKCS11:/path/to/pkcs11-spy.so hotz@xxxxxxxxxxxxxxx

OpenSC also has PKCS#11 and supports PIV.


I got coolkey-1.1.0-19 to build on Solaris 10 in 32 bit mode. (although
some of the patches from the rpm to the 1.1.0 source did
not apply cleanly and I have to make a minor modification for Solaris.)

Using krb5-1.10.1 and the OpenSC pkcs11spy and a PIV card,
I can see it reads the certificates, prompted for PIN and did a C_Sign operation
but coolkey only returns 122 bytes rather then 128 bytes as expected for the signature.

I then get a kinit: Message stream modified while getting initial credentials.

So it looks like there are some problems in the coolkey code in processing the
returned signature.

Using the same card, with krb5-1.10.1 and OpenSC pkcs11 works.



Unfortunately, I think the next step is to grab the SRPM for krb5 and
either (a) build with debugging symbols (and without optimization) and
start poking around in gdb, or (b) build with the PKINIT debugging
defines turned on and collect more information. Either is pretty
time-consuming.
_______________________________________________
krbdev mailing list krbdev@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/krbdev




--

Douglas E. Engert<DEEngert@xxxxxxx>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx





_______________________________________________
Coolkey-devel mailing list
Coolkey-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/coolkey-devel

--

 Douglas E. Engert  <DEEngert@xxxxxxx>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

_______________________________________________
Coolkey-devel mailing list
Coolkey-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/coolkey-devel


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Women]

  Powered by Linux