Created attachment 368474 [details] DMDC PDF explaining the change. Description of problem: C_GetSlotInfo() doesn't return CFK_TOKEN_PRESENT. This appears to be because Coolkey doesn't properly select the PKI applet during card detection. This is because the 144K card applets have been restructured, and the module is attempting to directly select an applet instead of querying the Card Capability Container applet. Version-Release number of selected component (if applicable): 1.1.0 How reproducible: Always. Steps to Reproduce: 1. Get a new 144K CAC from JITC. 2. Run pkcs11-tool from OpenSC using the Coolkey PKCS#11 module. 3. Observe error. Actual results: No card detected. Expected results: Card should be detected and function. Additional info: Attached is the DMDC notification of the change from Feb 2009. While marked draft, this is the version that was published earlier this year.
Created attachment 368475 [details] Coolkey debug log with 144K card inserted.
Created attachment 368476 [details] pkcs11-spy output of 'pkcs11-tool -L' using the coolkey module and a 144K CAC inserted.
Thanks Tim, two questions, 1) how do I get cards for myself and Jack (Magne). 2) how do I get the document on the Card Capability Container Applet? (is it on all CAC cards, even old ones? thanks. bob
We are working on getting some cards. I'll make sure this one is on the list of cards we request.
Bob, Jack-- You can go direct to the JITC PKI and request test CACs: http://jitc.fhu.disa.mil/pki/ Red Hat's still on contract with DISA, so the DoD PKI PMO can act as a sponsor for JITC CACs too. If that's a problem, contact me and we'll work something out through the AF PKI SPO as we did before. In re: the CCC: The CCC specification is in Section 6 & 7 of GSC-IS 2.1: http://csrc.nist.gov/publications/nistir/nistir-6887.pdf That will cover using the CCC to access the CAC edge. You guys need to decide if Coolkey will move forward to support PIV cards, or if you're going to rely on OpenSC's PKCS#11 module for that. -- Tim
(In reply to comment #5) > Bob, Jack-- > You can go direct to the JITC PKI and request test CACs: > http://jitc.fhu.disa.mil/pki/ > Red Hat's still on contract with DISA, so the DoD PKI PMO can act as a sponsor > for JITC CACs too. If that's a problem, contact me and we'll work something > out through the AF PKI SPO as we did before. > In re: the CCC: > The CCC specification is in Section 6 & 7 of GSC-IS 2.1: > http://csrc.nist.gov/publications/nistir/nistir-6887.pdf > That will cover using the CCC to access the CAC edge. You guys need to decide > if Coolkey will move forward to support PIV cards, or if you're going to rely > on OpenSC's PKCS#11 module for that. > -- Tim Tim, We (WHS/OSD) can sponsor them if it's easier for all. Mark
Additional information: GSC-IS is the existing CAC interface specification; Coolkey *should* already comply with it to be considered viable CAC middleware. The problem with the 144K cards appears to be the result of Coolkey *not* obeying this specification.
On question on the spec... There appears to be both filesystem and vm card interfaces. Coolkey only recognized vm cards.
GSC-IS was intended as an abstraction for a large variety of cards, so it covers both. If you paw through SP800-73 (GSC-IS's successor) it's the same in that respect. CAC is only deployed (and AFAIK will only deploy) on VM cards. -- Tim
WORKAROUND: =========== I just wanted to post a workaround that should enable you to use these new cards in Linux. You can use opensc (I used 0.11.4 because it was installed on the distro) instead of coolkey. I have tested it with Firefox, pam pkcs11 login, and as a JDK 1.5 security provider. It is probably available from the repos of the distro you are using but you can download it here: http://www.opensc-project.org In all configurations that take /usr/lib/pkcs11/libcoolkeypk11.so, replace it with /usr/lib/opensc/opensc-pkcs11.so Notes: ====== It appears necessary to remove the coolkey security device from firefix and close/reopen before adding the opensc security device -- your mileage may vary. Using opensc as a JDK security provider is much slower than coolkey was on my machine. And if you pick the wrong certificate (when given a choice), i.e. not your identity certificate, it seems to die quietly.
mbucknam, thanks for bringing up opensc-pkcs11, but it did not seem to work for me. No disrespect, just another data point. Bob, the GSC-IS spec says you're supposed to talk to the Card Capability Container (CCC) before you talk to the CAC applet - irrespective of the VM/file-based distinction. This gives you a list of containers - an RID, AID and OID with a use code for each container - which you then choose from and talk to. The change is that instead of three applets, each containing one certificate, so that the OID does not really matter, you now have one applet containing three certificates, and the OID matters. I've used scriptor from pcsc-tools to choose both the applet and the object based on AIDs and OIDs I read (visually) out of the CCC. The block is that when I ask for the first part of the certificate (APDU 00 36 00 00 64), new CACs give me an error, and I can't seem to find any documentation in the GSC-IS, the DMDC announcement, or anywhere else about that APDU, much less what should happen instead. Can you shed any light on that?
Hi, perhaps I can shed a little historical light on your problem. The Get Certificate command (APDU 00 36 00 00 64) was defined for the "PKI applet" in the "CAC Applet Developer's guide 1.0". GSC-IS does not use that command. For backwards compatibility, later CAC cards still supported the command as they adopted GSC-IS, and 800-73. It seems that the new version no longer supports the command. I suppose you can try the GSC-IS commands of READ BUFFER to read the certificate, after Get Certificate fails. The long run solution is to move to 800-73, Part 2. http://csrc.nist.gov/publications/PubsSPs.html#800-73, and say goodbye (RIP) to the historical CAC interface. Hope this helps, Andrew
and in Tim Miller's "Data Model Change" attachment you can see this quote: "GET CERTIFICATE APDU is no longer supported in GSC-IS v2.1; thus, READ BUFFER should be used."
Thanks! I think you just saved me 98 Swiss francs. ( http://www.iso.org/iso/catalogue_detail.htm?csnumber=37989 )
I'd like to share my experience with these new cards that I hope will help. I wrote a Java applet that is able to read certificates off the 144K cards. Our users run (a signed copy of) it load their certificates into our organization's LDAP directory. The missing "Get Certificate" command caused me headache due to the sparse docs on the "Read Buffer" command and how it works with the certificate container(s). Some other findings: * "Read Buffer" is available on the old and new cards, and you can use it to read certs off of both (i.e. you can ditch the "Read Certificate" command and be backwards compatible) * The certificates are gzipped on the card, so after reading the buffer you'll have to decompress to see the certificate bytes * Reading the ID cert is the same buffer for both the new and old cards I've attached some pseudocode. Hope any of this helps..
Created attachment 401279 [details] pseudocode showing how to read certs on both 144k and 72k cards
I've modified CoolKey to read the CCC, find the Universal AIDs and OIDs therein, store those in shared memory along with the certificates, and use them to choose certificates before signing/encrypting/decrypting. This implements part of the PIV standard. (As for making my changes available, I'm still trying to find out how to do it properly within the legal and administrative context I'm in.) Having done that, I found that the certificates on the new cards have 2048-bit keys (that's 256 bytes), and input must be padded to the length of the key, and you can't say Lc = 256 with a short APDU. So I modified CoolKey to generate Extended APDUs (see ISO 7816-4 Annex A, http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_annex-a.aspx), only to find that my smartcard readers and my T=0 protocol cards don't seem to be happy with the extended APDUs. (See http://pcsclite.alioth.debian.org/ccid_extended_apdu.html.) I tried using the ENVELOPE APDU to encapsulate an extended APDU in a series of short APDUs, but my card didn't seem to support it. Tracing APDUs sent and received by ActivClient during the Windows login process when using a new card, I saw it say (among many other non-standard commands and undocumented applet identifiers): > 80 42 80 00 EF [0xef bytes of data] < 90 00 > 80 42 00 00 11 [0x11 bytes of data] < 61 00 (last 00 means there are 256 bytes of response) > 00 C0 00 00 00 (last 00 means Le = 256) < [256 bytes] 90 00 "00 42 00 00 Lc data" appears to be the ISO7816 encrypt-some-data APDU; note that this apparently nonstandard 80 42 APDU manages to send all the data without sending or receiving any Extended APDUs. My attempts to imitate ActivClient in this way using a different card and the scriptor have failed (card says wrong Lc), suggesting that I don't understand enough about the P1-P2 pairs 80 00 and 00 00. Because the CLA is 0x80, I don't think this is an ISO standard APDU, so I don't think I'd learn anything if I ponied up the Swiss francs for ISO 7816-8. Does anyone have any randomly awesome pointers for me from here? Andrew Webb, perhaps?
http://csrc.nist.gov/publications/nistir/nistir-6887.pdf describes the 5.3.6.1 Private Sign/Decrypt APDU. I vaguely remember P1 chaining, where the high bit=1 indicates more data to come, and high bit off indicates last data block. Not ISO though. Can you post your exact commands and responses that gave the "wrong LC" Also there should be some official DOD support for CAC. Have you tried cacsupport.mil ?
Here's me trying to send the exact same 80 42 APDUs that I copied from a session using a new CAC card (2048 bit key, 256 bytes, == 0xEF + 0x11), with my older CAC card. j ~/src/pcsc-tools-1.4.16 $ ./scriptor crypt2 No reader given: using O2 Micro Oz776 00 00 Using T=0 protocol Using given file: crypt2 00 A4 04 00 07 A0 00 00 00 79 01 01 > 00 A4 04 00 07 A0 00 00 00 79 01 01 < 61 0D : 0x0D bytes of response still available. 00 20 00 00 08 xx xx xx xx xx xx xx xx > 00 20 00 00 08 xx xx xx xx xx xx xx xx < 90 00 : Normal processing. 00 A4 04 00 07 A0 00 00 00 79 01 01 > 00 A4 04 00 07 A0 00 00 00 79 01 01 < 61 0D : 0x0D bytes of response still available. 00 A4 02 00 02 01 01 > 00 A4 02 00 02 01 01 < 90 00 : Normal processing. 80 42 80 00 EF 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 > 80 42 80 00 EF 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 < 67 00 : Wrong length. 80 42 00 00 11 10 77 A6 14 6B 70 79 6C 2C 37 F9 0F C4 67 70 44 E6 > 80 42 00 00 11 10 77 A6 14 6B 70 79 6C 2C 37 F9 0F C4 67 70 44 E6 < 67 00 : Wrong length. 00 C0 00 00 00 > 00 C0 00 00 00 < 6D 00 : Instruction code not supported or invalid. Here it is with 128 FF's chopped out of the middle, to make the data to crypt the same size as my key: j ~/src/pcsc-tools-1.4.16 $ ./scriptor crypt3 No reader given: using O2 Micro Oz776 00 00 Using T=0 protocol Using given file: crypt3 00 A4 04 00 07 A0 00 00 00 79 01 01 > 00 A4 04 00 07 A0 00 00 00 79 01 01 < 61 0D : 0x0D bytes of response still available. 00 20 00 00 08 xx xx xx xx xx xx xx xx > 00 20 00 00 08 xx xx xx xx xx xx xx xx < 90 00 : Normal processing. 00 A4 04 00 07 A0 00 00 00 79 01 01 > 00 A4 04 00 07 A0 00 00 00 79 01 01 < 61 0D : 0x0D bytes of response still available. 00 A4 02 00 02 01 01 > 00 A4 02 00 02 01 01 < 90 00 : Normal processing. 80 42 80 00 6F 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 > 80 42 80 00 6F 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 < 67 00 : Wrong length. 80 42 00 00 11 10 77 A6 14 6B 70 79 6C 2C 37 F9 0F C4 67 70 44 E6 > 80 42 00 00 11 10 77 A6 14 6B 70 79 6C 2C 37 F9 0F C4 67 70 44 E6 < 67 00 : Wrong length. 00 C0 00 00 80 > 00 C0 00 00 80 < 6D 00 : Instruction code not supported or invalid.
Please show the " Tracing APDUs sent and received by ActivClient during the Windows login process when using a new card". I suspect the "non-standard commands and undocumented applet identifiers)" are in fact described in the instructions of Section 4.0, page 5 of "DMDC PDF explaining the change." attached above. They call keys containers in error, but it says: >> the following .. are impacted in the “New Consolidated PIV+CACv2 Data Model”: CAC PKI Keys • CAC PKI Digital Signature Key <---- You are trying this. • CAC PKI Key Management Key >>> NOTE: The ... above will require two selects to access the specific ... 3. Select the AID of the Applet Instance (0xA0.00.00.00.79.01.00) containing the DoD Person Container (new) 4. Select the OID of the container, such as the DoD Person Container (02.00) (new) http://csrc.nist.gov/publications/nistir/nistir-6887.pdf describes the 5.3.3.3 Select Object APDU for the 2 byte Now look at the table on page 2, "DMDC pdf", and observe the application name "CACv2" has the entries: AID: A0000000790100 OID: 0100 Identity Key 0101 Digital Signature Key 0102 Key Management Key So I think they want you to do: Select A0000000790100 Select Object 0101 80 42 80 00 EF 80 42 80 00 11 to use the digital signature key now. best regards, Andrew
> So I think they want you to do... Understood; but note that when I was trying the APDUs myself, I was trying it on my CAC card, which is an old one. I just verified that my card does the same thing when I select both the Universal AID and the OID as it did when I only selected the Universal AID: it doesn't like the 80 42 APDUs.
Your old CAC card has 1024 bits keys I assume. I thought Coolkey worked on old CAC cards but failed on the new. Does 80 42 00 00 80 .... fail on your old card ?
80 42 00 00 80 [...] does the same thing on my old card as 00 42 00 00 80 [...]. You may have meant to ask a different question, so here's a discussion of the permutations of APDUs and results. We have three variables: class (00 or 80), CAC type (old or new), input data length (128 bytes or 256) and APDU strategy (one short APDU, one extended APDU, or two APDUs with this "P1 chaining" you speak of). -- (short, CLA 00, 128 bytes) 00 42 00 00 80 [...] ("I'm sending you 0x80 bytes, please crypt them") works on my card. It doesn't work on a new CAC, because there the keys are longer than 0x80 bytes. (extended, CLA 00, 256 bytes) 00 42 00 00 00 01 00 [...] ("I'm sending you 0x0100 bytes, please crypt them," extended APDU) doesn't work for me anywhere. pcscd complains something about the T=0 protocol on a new CAC, and my old CAC says wrong length. (chained, CLA 00, 128 bytes) 00 42 80 00 6F [...], 00 42 00 00 11 [...] ("I'm sending you 0x6F bytes, not done, now I'm sending you 0x11 bytes, please crypt all of them") does not work on my old card. It also wouldn't work on a new one owing to the wrong data length. (short, CLA 80, 128 bytes) 80 42 00 00 80 [...] (possibly "I'm sending you 0x80 bytes, please crypt them") works the same on my old card as (a), but seems to be less standard. It can't work on a new CAC because the keys there are longer than 0xff bytes (extended, CLA 80, 256 bytes) 80 42 00 00 00 01 00 [...] (possibly "I'm sending you 0x0100 bytes, please crypt them," extended APDU) I have not tried this anywhere (chained, CLA 80, 128 bytes) 80 42 80 00 6F [...], 80 42 00 00 11 [...] (possibly "I'm sending you 0x6f bytes and I'm not done sending, now I'm sending you 0x11 bytes and I am done sending, please crypt them all"), for a total of 0x80 bytes) does not work for me on my old CAC. (chained, CLA 80, 256 bytes) 80 42 80 00 EF [...], 80 42 00 00 11 [...] (possibly "I'm sending you 0xEF bytes and I'm not done sending, now I'm sending you 0x11 bytes and I am done sending, please crypt them all," for a total of 0x100 bytes) does not work on my old CAC, and does work on a new CAC (this is what ActivClient is doing). -- The only reason I'm trying to send chained APDUs with 128 bytes of data is to make sure I understand this chaining thing. Apparently I don't. Is it in a standard somewhere? Doesn't CLA 80 mean less standard than CLA 00? So far the only CLA 80 APDUs CoolKey emits are in GSC-IS; that makes me feel good. Will we have to depart from standards to make the new CAC work?
Created attachment 402714 [details] ActivClient smartcard traffic log All the traffic that ActivClient sent and received from a new (128K/144K) CAC in the course of logging into, then out of, a Win2K3 terminal server. (Certificate contents and PIN censored, of course)
jared, jared, jared.... You have it working ! >>> short, CLA 00, 128 bytes) 00 42 00 00 80 [...] ("I'm sending you 0x80 bytes, please crypt them") works on my card. >>> (chained, CLA 80, 256 bytes) 80 42 80 00 EF [...], 80 42 00 00 11 [...] (possibly "I'm sending you 0xEF bytes and I'm not done sending, now I'm sending you 0x11 bytes and I am done sending, please crypt them all," for a total of 0x100 bytes) does not work on my old CAC, and does work on a new CAC You are just too optimistic that one set of APDUs would actually work on both cards.
Well - I suppose so. I've added a CKYApplet_SignDecrypt_InHalves that sends the crypt input 0xff bytes at a time, using the 80 42 80 ... APDU, and met with success using both my old CAC card and someone else's new one.
Greetings Everyone, To Jared Jennings: Great work. This is awesome. Thanks for all your hard work and effort in this. Question: 1. Will your fix be included in rhel5? 2. Do you or someone have an estimate time when this will happen? I'm willing to be a beta tester for the fix. To mbucknam Your post the following: WORKAROUND: =========== I just wanted to post a workaround that should enable you to use these new cards in Linux. You can use opensc (I used 0.11.4 because it was installed on the distro) instead of coolkey. I have tested it with Firefox, pam pkcs11 login, and as a JDK 1.5 security provider. Question: What distro are you referring to above? Thanks in advance for your answer, Gerald
Answer to Gerald: Ubuntu Desktop 9.0.4
I can test on Fedora 12 x86_64
If Jared can post his patch, I would be willing to review it and get it into coolkey upstream. (preferably if we have cards here to test to make sure it works;). Once it's in upstream, it's relatively easy to get into current fedora releases. RHEL is only a little problem (we have to catch an update train). bob
Hi, I just talked to Jared today, he is going to send me a copy of the bin to test on my systems. He is also talking with his boss at AF just to get the official ok to release the patch outside the DoD. I don't think this is an issue since you ( RH PKI ) are the prime support contract to the DOD PKI office and we are working in conjunction with a trusted support vendor - he just needs the 'ya go verily' from the chain of command. - Aaron
> (chained, CLA 80, 256 bytes) 80 42 80 00 EF [...], 80 42 00 00 11 [...] Does anyone know of a document that says you can do this? I'm trying to brief this to less technical people and I'd rather not explain the process of watching ActivClient generate APDUs. GSC-IS v2.1 has the 80 42 APDU, but specifies that P1 must be 00, not 80.
My government supervisor has decided that one release to everyone is wiser than many releases to restricted sets of people. The fixes are currently going through the public release process. People tell me to expect it to take at least a month.
I got a new CAC 'cause the chip died on the old one. The new one is as mentioned in this thread and does not work in Firefox at all. Will that be fixed when this bug is fixed or is it a different problem? pcsc_scan (with newest released version) does see it.
(In reply to comment #39) > My government supervisor has decided that one release to everyone is wiser than > many releases to restricted sets of people. The fixes are currently going > through the public release process. People tell me to expect it to take at > least a month. <From https://software.forge.mil/sf/go/post2979> Has anyone done the paperwork to get this a CoN so that it can be used on NIPR systems? In order to install this on an Army NIPR computer the software has to go thru a process at multiple levels, from the local SYSAD to the Network Enterprise Center (NEC) then on to NETCOM for approval. Is this something that is being worked on or considered? reply to post2979.mil
Well - once the fix finally gets posted, I reckon it'll probably be integrated into RHEL. Before that happens, perhaps it's not Networthy and perhaps you can't install it. After that, it's part of RHEL, and if RHEL is certified, maybe you're good to go. But you wouldn't seek a CoN for a Windows hotfix, would you? This fix is the same size or smaller.
I've created CACKey to resolve this issue. It can be found on Forge.mil: https://software.forge.mil/sf/frs/do/listReleases/projects.community_cac/frs.cackey
(In reply to comment #43) > I've created CACKey to resolve this issue. Tested with Firefox and Thunderbird on Slackware 13 and it works great. Thanks very much!
I get: An error occurred during a connection to localhost:1924. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) It appears to be asking for client auth. bob
Try loading the "libcackey_g.so" PKCS#11 driver and capturing Firefox's stderr. This will contain information regarding the operation of the driver. Also, are you using the latest version (0.5.5?) Thanks, Roy Keene
Yes, Bob, software.forge.mil requires a client certificate (CAC or ECA) to get into the site.
Jared, Roy, et all, Your work on this effort is sincerely appreciated. I am a Department of Army Civilian working for IMCOM CIO-G6 and can assist with the certification of the fix posted to FORGE.MIL if still needed. My organization can initiate the leg work to start the accreditation process if this has not already been started. We are relying on RHEL and the work done to this point has saved my department and tremendous amount of time. Kudos to all involved!
Hi, Is CaCKey a patch of the coolkey libs? If so, is there anything stopping us from just using them to patch the coolkey baseline so that this solution could be generally accessible to the rest of the community? Yours, Aaron
The CaCKey patch works for firefox and evolution but it does not work as a JDK security provider. I get prompted for my pin so it seems to be finding certificates but it comes back with no usable certificates.
mbucknam: Fixed in CACKey 0.5.11 https://software.forge.mil/sf/frs/do/viewRelease/projects.community_cac/frs.cackey.0_5_11
Roy: Wow. You give paid vendor support a bad name! If I had any money I would certainly send it to you. That fix works perfectly. Thanks so much. Chasing CAC PKI support in Linux is a tough job and the hard work of people like you is definitely appreciated. Thanks again!
Roy: Well, that fix seems to allow the JDK to read the certificate and I can access the public key and private key in code and the keytool list command works as expected. However, I get an error when attempting to create a two-way SSL connection using HTTPS. Of course this may have nothing at all to do with the lower level apis (like CACKey) but I wanted to mention it just in case... I have detailed logs if you're interested; the last part of the log as it dies is: *** *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 main, WRITE: TLSv1 Handshake, length = 1311 SESSION KEYGEN: PreMaster Secret: 0000: 03 01 69 9E 48 27 4A 82 1C 32 4F B1 E0 2D F0 3A ..i.H'J..2O..-.: 0010: 2B FE F6 AF 18 4E 59 A7 01 94 80 F2 A5 0E 26 D6 +....NY.......&. 0020: D6 0F 54 93 A1 91 36 E2 27 E8 90 84 A8 F3 C2 CF ..T...6.'....... CONNECTION KEYGEN: Client Nonce: 0000: 4C 0D 1A 5A EF 27 7E BC 1C 59 E9 7C B0 65 AB 86 L..Z.'...Y...e.. 0010: 4D F6 BA 86 54 66 6D CC EA 26 85 37 F2 FB 19 E4 M...Tfm..&.7.... Server Nonce: 0000: 4C 0D 1B 57 0F 2B C1 80 A7 BC 7F 0A D6 33 98 08 L..W.+.......3.. 0010: 30 75 E4 CA 59 6C 76 57 E1 C0 D8 8F 75 AD 6E 79 0u..YlvW....u.ny Master Secret: 0000: 32 2F 45 C5 EF D6 A1 10 43 25 AC 55 C9 8D 5A 9A 2/E.....C%.U..Z. 0010: A5 5B 2C 99 B6 24 2A 18 B3 7E D2 6E D8 53 41 82 .[,..$*....n.SA. 0020: C3 62 34 37 81 D5 32 34 BC DD B1 86 C4 8C 9E 7E .b47..24........ Client MAC write Secret: 0000: 20 45 5C 74 CF BE D0 5E 1B FE CB 76 B0 6C 6F 0B E\t...^...v.lo. Server MAC write Secret: 0000: F3 28 BB 52 3E 8F B9 50 78 3C 48 E7 AC C2 28 90 .(.R>..Px<H...(. Client write key: 0000: C9 64 10 55 DC E9 AF 9F 8E DB FD AA 49 35 0C A4 .d.U........I5.. Server write key: 0000: D4 CC A7 A0 B0 25 2E 55 B0 7F 20 4B 74 FC FB 6D .....%.U.. Kt..m ... no IV used for this cipher *** CertificateVerify main, WRITE: TLSv1 Handshake, length = 262 main, WRITE: TLSv1 Change Cipher Spec, length = 1 *** Finished verify_data: { 218, 78, 189, 93, 191, 0, 240, 135, 208, 82, 203, 207 } *** main, WRITE: TLSv1 Handshake, length = 32 main, waiting for close_notify or alert: state 1 main, READ: TLSv1 Alert, length = 2 main, RECV TLSv1 ALERT: fatal, decrypt_error main, called closeSocket() main, Exception while waiting for close javax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error javax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error
mbuckham: Try loading "libcackey_g.so" instead of "libcackey.so", it will produce a lot of debugging information on stderr that may be useful in diagnosing the problem if it is with CACKey.
Just a final note that Roy has fixed the issue described in comment 53. The latest version as of today can be downloaded here: https://software.forge.mil/sf/frs/do/viewRelease/projects.community_cac/frs.cackey.0_5_12 It also contains a readme file describing how to build, install, and test it. Thanks again to Roy for all his hard work to provide this.
Also tested v0.5.12 with success in Firefox and Thunderbird on Fedora13/x86_64. (Dell smartcard reader keyboard w/ Oberthur v5.2a Dual smartcard) The test program complained about the "padding scheme": cackey_end_transaction():963: Sucessfully terminated transaction on slot (Dell smart card reader keyboard 00 00) cackey_signdecrypt():2068: Unrecognized padding scheme -- passing back and hoping for the best! cackey_signdecrypt():2070: Returning in success, retval = 128 (bytes) cackey_mutex_unlock():2410: Called. cackey_mutex_unlock():2433: Returning sucessfully (0) C_DecryptUpdate():4917: Returning 0 but finished successfully, anyway: Testing libcackey... DONE. Status = 0
Tested v0.5.12 with success in Firefox, Thunderbird on Fedora 12 & 13/x86_64 SCR3310 V2.0 usb Card Reader yum install pcsc-lite.x86_64 pcsc-lite-devel.x86_64 yum remove openct.x86_64 (* this conflicts with pcsc access to card reader *) From your system menus, Open up System -> Administration -> SELinux Management. Select the "Process Domain", type in "pcsc" in the filter. Select pcscd and hit the "Permissive" Icon. build as instructed, import device, logon, ran ./test sucessfully, access AKO & Forge.mil -> OK Thanks Roy !
Folks, Are the changes in CACKey being rolled back into CoolKey? Should someone (I can do it) attached a diff from CACKey to CoolKey? Is anyone from Coolkey watching this bug? The priority for this bug should not be LOW! Thanks! Joel
CACKey is not based on CoolKey, so a diff between the two pieces of software would not be useful. CoolKey could be patched to work with new CACs, but it's a horrendous design and would have taken me more time to patch CoolKey than to write a working replacement. (Just to send a single 7 byte APDU I had to touch 4 files). CACKey does have the disadvantage of not supporting CoolKey tokens, but I only have DoD CAC/PIV tokens so I don't care about it. Support for those tokens would require some additional code to CACKey. CACKey was only written to comply to: a) GSC-ISv2.1; and b) Extended APDUs that I have seen on the APDU dump posted on this bug to deal with 256 byte (2048 bit) keys. I am not inclined at this point to write a patch against CoolKey since my needs are met by CACKey. Additionally, someone from above has already written a patch and is just awaiting approval for public release. Thanks, Roy Keene
> CoolKey could be patched to work with new CACs, but it's a horrendous design > and would have taken me more time to patch CoolKey than to write a working > replacement. (Just to send a single 7 byte APDU I had to touch 4 files). I already have the patch for Coolkey now;). Beauty is in the eye of the beholder;). bob
Thank you, Roy. I have tested CACKey-0.5.18-1 and it has me up and running again (though I did have to use a Windows box to get to forge.mil in the first place... sigh). Many thanks for the effort and time you spend in creating this solution.
I rebuilt the cookey 1.1.0.16.fc12 package for FC12 and it worked like a charm. My new CAC is up and running. Any chance these versions will be pushed for FC12 anytime soon? Any chance this bug will be assigned to someone and/or closed? It is strange having a bug that is clearly being worked on, but isn't assigned. Thanks!
Roy, I seem to have encountered a problem with your CACKey solution. After installing cackey-0.5.18-1 via RPM, I was able to successfully use my CAC card. However, after restarting my computer, my card reader was no longer recognized. A co-worker found a solution: As root: 'lsof |grep usb' kill process id citing /dev/bus/usb/005/003 'service pcscd restart' The card reader is then functional. Any idea what's going on there? Thanks again for your efforts.
Dwight, Is this condition repeatable ? If so, can you load "libcackey_g.so" in an application (e.g., Firefox) and capture that application's stderr during the time the failure condition occurs and send it to me ? libcackey_g.so is the debugging version of CACKey, it includes symbols as well as extra code to print out what is happening within the library. Thanks, Roy Keene
Created attachment 438223 [details] Output of libcackey_g.so when running firefox I have included commands run, followed by their output for the initial "broken" phase as well as my work-around.
My apologies for the double-post. Roy, to answer your question this condition is repeatable every time I reboot my PC without exception.
Since this is a coolkey bug, and coolkey now has 144K card support in rawhide (which is what this bug is specifically about), RHEL 5.6 (plus a RHEL 5 hot fix). I'm closing this as RELEASE_PENDING. bob
Can you please push to F12 and F13 as well? I am running the rawhide package rebuilt on F12 just fine for about a week now.
Where can I get this patch/source for the new coolkey. I use ubuntu and need to update as I have one of the new cards. Thanks.
Has this been pushed to F14? I can't get my card to work under F14.
(In reply to comment #70) > Has this been pushed to F14? I can't get my card to work under F14. Nevermind. It DOES work under F14 but not with my internal card reader (Dell). The external card reader works.
Can someone please port this fix to F12/13? Thanks!
Not sure if this is related, but on Fedora 15 Firefox 10.0.1 and coolkey 1.1.0-19.fc15 appear not to work together with the Oberthur ID One 128 v5.5 CAC smartcard. Once the associated pkcs11 addin is added to firefox, firefox fails to start with the CAC inserted. Loaded pcsc-tools and pcsc_scan properly identifies the CAC. Output of pcsc_scan below: PC/SC device scanner V 1.4.17 (c) 2001-2009, Ludovic Rousseau <ludovic.rousseau> Compiled with PC/SC lite version: 1.6.6 Scanning present readers... 0: Broadcom 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 Sun Mar 25 12:30:54 2012 Reader 0: Broadcom 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 Card state: Card inserted, ATR: 3B DB 96 00 80 1F 03 00 31 C0 64 B0 F3 10 00 07 90 00 80 ATR: 3B DB 96 00 80 1F 03 00 31 C0 64 B0 F3 10 00 07 90 00 80 + TS = 3B --> Direct Convention + T0 = DB, Y(1): 1101, K: 11 (historical bytes) TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU 250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s TC(1) = 00 --> Extra guard time: 0 TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 ----- TD(2) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following ----- TA(3) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V + Historical bytes: 00 31 C0 64 B0 F3 10 00 07 90 00 Category indicator byte: 00 (compact TLV data object) Tag: 3, len: 1 (card service data byte) Card service data byte: C0 - Application selection: by full DF name - Application selection: by partial DF name - EF.DIR and EF.ATR access services: by GET RECORD(s) command - Card with MF Tag: 6, len: 4 (pre-issuing data) Data: B0 F3 10 00 Mandatory status indicator (3 last bytes) LCS (life card cycle): 07 (Operational state (activated)) SW: 9000 (Normal processing.) + TCK = 80 (correct checksum) Possibly identified card (using /home/mike/.smartcard_list.txt): 3B DB 96 00 80 1F 03 00 31 C0 64 B0 F3 10 00 07 90 00 80 DoD CAC, Oberthur ID One 128 v5.5 Dual ------------- When the CAC is not installed, firefox starts normally.
Correctly close the bug. If you will still have issues with this, please open a new bug.