ECC and SHA-2 support in OpenSC.tokend #570
Comments
|
@mouse07410 you could use gist or pastebin for the log. Please use backticks when pasting code. The Neo's card drivers have received some updates recently. Are you testing with the most recent version? What version is your OS? |
|
A full log would help, can you post it somewhere, or send to me at deengert at gmail dot com. This looks normal, but uits not teh full log. OpenSC tries to match a card by ATR then will try other drivers that do I/O to the card. The 6A 80 is a little strange. it looked like the PIV driver was trying to read What version of the NEO do you have? On 10/2/2015 9:00 AM, Mouse wrote:
Douglas E. Engert [email protected] |
Will report more, and send a complete log to @dengert. |
|
Also, it looks like when opensc-pkcs11.so library is used as PKCS#11 interface for Thunderbird, something (Thunderbird probably) gets into infinite loop even before the user is prompted for a PIN, as indicated by application frozen and the log growing continuously with repeated records: at this point I pulled the NEO out, and killed Thunderbird. More report/log to follow |
|
I was asking what version of the NEO. You also say CAC card. I assume that you are then using a US DOD CAC card. The PIV driver will work with these if they are also PIV complaint. The NEO has a PIV like application and has a number of known differences with the PIV specifications, If this is a MAC only issue, it is most likely with PCSC, as this is where the locking is implemented. On 10/2/2015 11:06 AM, Mouse wrote:
Douglas E. Engert [email protected] |
|
Thunderbird does polling using PKCS#11 to see if any change to cards or tokens being removed or inserted. It will use the C_GetSlotInfo then wait for a few seconds and try again. The log above is not large enough to see if this is the case or if thre is some other problem. |
|
Can you have a look at #516 as it has information about locking problems on MacOS |
|
I tested quite recent versions of OpenSC's tokend on Yosimete with cardos and an other type of card, which worked as expected. I think the tokend should work in general, but I have no specific information about neo or CAC. |
|
On Oct 3, 2015, at 21:54 , Frank Morgner <[email protected]mailto:[email protected]> wrote: In my case, and based on what I’m observing from the application side (as a user - don’t have debugging info from, e.g. Keychain Access) OpenSC.tokend doesn’t seem to tell the calling application that the unlock succeeded. This applies to both US DoD CAC and Yubikey NEO. The observable behavior is the same for both:
I would love to have this problem fixed, to be able to use OpenSC.tokend with CAC and NEO on Mac OS X (Yosemite, and later on El Capitan). Please let me know how I can help - i.e. what tests I could run, what debug level I should set in opens.conf, and what debugging info I should provide you to make tracking this issue down possible. Thanks! P.S. Re. #516#516 and #487#487 (and #480#480) that if refers to - but cannot tell if it is related to the problem I’m describing. Also, please note that applications such as piv-tool and pkcs11-tool unlock the card (both CAC and NEO) just fine, so the problem doesn’t seem to manifest in the OpenSC “core”, only in its tokend. I don’t know what to make of it… P.P.S. Here’s the output of Using slot 1 with a present token (0x1) Aborting. I verified that validates correctly.Uri Blumenthal |
|
When you say "unlock" are your referring to the PC/SC locking to prevent other processes to access the card, For what you say in this note, it sounds like the verify is failing when the PIN is entered. Can you send a OpenSC debug trace, Replace you PIN digits with 9s. I wan to see if they are digits, I also want to see if there is a Discovery object on the card, and what the SWs from trying to read this are. The CAC may respond differently then a true PIV card. Set debug = 9; in opensc.conf Have you been able to use your CAC card with OpenSC on Linux? This would help eliminate tokend. (You have still not sent the debug trace I asked about last week. You said you could not send it from work.) On 10/4/2015 1:17 AM, Mouse wrote:
Douglas E. Engert [email protected] |
|
https://militarycac.com/cacdrivers.htm reports upgrade available for SCR-3310 and SCR-331 readers and some problems on Mac with SCR readers. Could this be a problem? (But the NEO has its own reader, so there could be more then one problem.) |
|
One other possible issue: The card enforces this. OpenSC id "02" is for the 9C key for this certificate. OpenSC PKCS#15 calls this user_consent. PKCS#11 has the private key attribute CKA_ALWAYS_AUTHENTICATE. C_Login with CKU_CONTEXT_SPECIFIC is used to send the PIN in again. It could be tokend is not doing this, and thus the sign fails. OpenSC has PIN caching, which my just send in the PIN again. (disregarding "ensures cardholder participation every time") OpenSC can also try and cache PINs, and may try and send the PIN in again without the user knowing. So full OpenSC debug logs with debug = 9; and pkcs#11 spy logs would help show what is going on. |
|
Sorry, no it cannot because (a) my reader is upgraded, and (b) everything else (PKard, Centrify, CACKey PKCS11.tokend) successfully unlocks my CAC. My CAC reader is SCR-3310 v2.0. Sent from my iPad On Oct 4, 2015, at 22:36, Doug Engert <[email protected]mailto:[email protected]> wrote: https://militarycac.com/cacdrivers.htm reports upgrade available for SCR-3310 and SCR-331 readers and some problems on Mac with SCR readers. Could this be a problem? (But the NEO has its own reader, so there could be more then one problem.) — |
|
I tried my CAC on Linux (running in a VM), and it worked perfectly, in all aspects - both with low-level tools from OpenSC (pkcs11-tool, etc), and with "normal" applications (accessed CAC-protected Web sites using Firefox, sent CAC_signed emails using Thunderbird - both were configured to use /usr/local/lib/opensc-pkcs11.so as PKCS#11 reader). Must say that on Mac, CAC is handled by PKard.tokend. Apparently it passes everything correctly to invoking applications, including VMware Fusion - so my Linux VM was able to interact with CAC fine. I tried with NEO. It used OpenSC.tokend (Github version). First observation - this tokend is unable to correctly pass the unlock information to the invoking applications, as seen in the log. I was also unable to access NEO from the Linux VM. I cannot attach the log (Github doesn't accept it, though it's .TXT). The relevant lines are pasted in. They show that when the application (Keychain Access) requests to unlock the token, the request appears to reach down to the card, and unlock it successfully (returning Success). However that "Success" does not seem to be propagated to the invoking application - so it never learns that the operation in fact succeeded... Nothing more in the log file - just the repetition of that getAcl()... And here's the attempt to unlock the token with the latest (of this morning) Github OpenSC.tokend, and with pin caching enforced (ignoring user consent): The above appears to say that OpenSC.tokend correctly determined what certs are on this token, received request to unlock the card, got the PIN, passed it to the token, got Success in return - but somehow failed to propagate that success to the invoker, because the invoking app still considered the token locked (as if the PIN was rejected). P.S. I wanted to attach the above log excerpts, but Github interface did not let me. So my apologies for mailbox cluttering, but I saw no choice. |
|
Update. Trying to use OpenSC.tokend with CAC produces similar results to NEO: tokend is unable to unlock the card (though the log entries indicate a different problem?). The application instead is repeatedly prompting for a PIN. Again, I have the log (6000 records :). And again, I cannot attach it. So again, the excerpts posted here: Here's what pkcs11-tool has to say about this CAC (everything appears to function as expected): |
|
The VERIFY of the PIN command failed. (I realize you have replaced the numbers with xx.) 00 20 00 80 08 xx xx xx xx xx xx FF FF . ...yyyyyy..0x7fff7e07b300 14:49:37.140733193388818 [opensc-pkcs11] reader-pcsc.c:184:pcsc_internal_transmit: called 6A 86 is "Incorrect parameter in P1 or P2" On PIV, P1 is always 00 P2 can be 00 for Global Pin, or or 80 for application PIN. The choice of which PIN (i.e. the P2 parameter) is read from the Discovery object as defined in NIST 800-73-3 Part1 The reading of the discovery object is not shown in the debug log. It would be an outgoing APDU of: If it fails what is the status bytes. If it reads it 7E 12 4F 0B A0 00 00 03 08 00 00 10 00 01 00 5F ~.O............_ Can you find this in the log? It may be that the CAC card does not return a valid Discovery object Your PIN may be correct, but the CAC card may not like the P2=80.
Douglas E. Engert [email protected] |
|
On Oct 7, 2015, at 17:58 , Doug Engert [email protected] wrote:
And that’s weird. I’ll have to re-run this all.
Will do my best.
This is the very standard current/fresh DoD CAC. The likelihood of it not being conformant to “de-facto standard” is negligible, not to mention that all the other token’s around (PKard, Centrify, CACKey) all successfully operate with in all the way (accessing web sites, and securing S/MIME email).
I’m pretty sure my PIN is correct - otherwise my CAC would have been locked/blocked by now. :-) It appears that the problem is with P1, not P2. :-( And since P1=00 is a valid code, the cause must lie elsewhere.Uri Blumenthal |
|
Issue may be that Discovery Object is not correct, or not parsed correctly, Could also be problem with opensc.tokend overwriting something. On 10/7/2015 6:46 PM, Mouse wrote:
Douglas E. Engert [email protected] |
|
Another thing - file /tmp/opensc-debug.log grows rapidly even with “debug = 3;”, but file “/tmp/opensc-tokend.log” stays empty. Is it normal? Should anything get recorded in /tmp/opensc-tokend.log? Is it all getting dumped into /tmp/opensc-debug.log , or am I missing some setting that would provide tokend-specific logging? On Oct 7, 2015, at 21:16 , Doug Engert <[email protected]mailto:[email protected]> wrote: Could also be problem with opensc.tokend overwriting something. On 10/7/2015 6:46 PM, Mouse wrote:
Douglas E. Engert <[email protected]mailto:[email protected]> — Uri Blumenthal |
|
The debug file is written by routines in libopensc. Did you find a reference to opensc-tokend.log in some code? On 10/7/2015 9:36 PM, Mouse wrote:
Douglas E. Engert [email protected] |
No, and I don't even know where to look. :-( But the file /tmp/opensc-tokend.log is created regularly, i.e. if I delete it - it re-appears, albeit consistently empty. |
|
OK, Don't know why. May be a minor bug. Did you find any entries in the opensc-debug log with the CAC card reading the Discovery Object? Grep for Discover CAC cards have a long history, and the transition to PIV may cause problems. It might be the card you have was issued by DoD and the Discovery object used only by PIV is On 10/8/2015 9:28 AM, Mouse wrote:
Douglas E. Engert [email protected] |
|
I did not see any entry of "Discover". I see some for discovery (see below). I found no incoming APDU starting with 7E - I hope I haven't redacted it out :-( :-( Apparently CAC does not have all the PIV containers - I wonder if some of those are optional...? |
|
I re-did the OpenSC.tokend experiment with CAC. There is no "Discover" in the log, nor is there any APDU starting with 7E. Indeed it appears that OpenSC.tokend fails to correctly pass the PIN to unlock the card. The error returned in Incoming APDU says "Incorrect parameter in P1". Needless to say, before redacting the PIN out, I carefully verified it, and made sure it was the correct PIN that was in the Outgoing APDU. Here's what NIST 800-73 got to say about this returned APDU: If the PIN was wrong, the card would have responded with '63' '00' Verification failed I must add, that it seems to me that cards tend to reply with 6a 86 when they think something in general is wrong... For the fun of it, I tried to pass the PIN to the CAC manually using |
|
Well the get data should not fail like that with invalid parameters. First the log which you just sent part of to me for the output of: If it is returning 0 then it is not falling through. 726 if (card->type == SC_CARD_TYPE_PIV_II_GENERIC) Then send "ALL" the log up and including the verify of the pin and its return status? 729 r = piv_select_aid(card, piv_aids[0].value, piv_aids[0].len_short, rbuf, &resplen); to sselect the AID on the card. THIS IS NOT A FIX, BUT A DEBUGING TEST.
Douglas E. Engert [email protected] |
|
Here is a simple test to see if the card can process a verify PIN command: To test if the pin reference of 80 (PIV specs say is the application pin) works: opensc-tool -s 00:20:00:80:08:31:32:33:34:35:36:FF:FF To test if the pin reference of 00 (PIV specs call the global pin) works: opensc-tool -s 00:20:00:00:08:31:32:33:34::35:36:FF:FF In both of the above replace the 31:32:33:34::35:36:FF:FF with hex version of the digits of your PIN padded to 8 bytes with FF. I can not find CAC document that says id 80 or 00 should work. It 00 works, AS A TEST, change card-piv.c line 2867 and see if tokend get any further. Douglas E. Engert [email protected] |
|
The test you suggested shows that CAC prefers P2=80 replying with OK, and rejects P2=00 replying with "Key reference not found". So something else must be wrong with how OpenSC.tokend tries to unlock the card (be it CAC or NEO). |
With the above change: Now we’re back to square one with the main OpenSC.tokend problem – OpenSC.tokend successfully passes the PIN to the card (be it CAC or NEO) and unlocks it, but does not propagate this knowledge to the invoking application(s); so as far as they’re concerned the CAC stays locked and unable to perform private key operations. P.S. The entire log been emailed to you. |
|
The problem with the pin for the CAC card looks more like a tokend problem. (Any tokend developers want to look at this?) The partial opensc-debug log created by tokend you sent me shows the verify being sent as: But when opensc-tool sends the SAME command it works and returns 90 00. Are are some possibilities: One of you snapshots or emails said something about a GemSafe tokend. A USB trace to the reader could show this... It could also be PC/SC is powering down the reader and thus resetting the security status on the card, There could be a problem with how tokend calls the sc_pkcs15 routines. There could be a different opensc.conf file that causes some driver is being called Only a FULL opensc-debug log showing "ALL" the log entries is needed to see what is different. Or tokend is not picking up the same shared libraries that the opensc tools or opensc_pkcs11.so do, There is still the additional problem that tokend with the NEO (where the opensc-debug shows the PIN was verified On 10/9/2015 10:55 AM, Mouse wrote:
Douglas E. Engert [email protected] |
|
Yes this looks at the full debug log you sent, this looks like the first bug. The default application is not the PIV and the code following I need to look closer, but I thing that a piv_select_aid is done when other opensc routines request the serial number I will submit a real patch early next week. Douglas E. Engert [email protected] |
Sorry! ;) Being at the bottom of the food-chain, have to move fast! :-)
Yes and yes. :-)
OK. In fact, I'm not sure if it is even possible. The problem as I see it is - Outlook requests for an RSA signature, so whatever the Context has to say about the algorithm and such - will be RSA. So for me to switch it to ECDSA - I need to somehow preempt the entire Context, and (a) I don't know how (and don't want to remove "const" from the input parameter), and (b) not sure we really want this kind of hack/fix... Open to suggestions.
Done. Just updated my PR frankmorgner/OpenSC.tokend#1 with the latest changes. @dengert and @frankmorgner I'd appreciate if you could review that PR and (if agreeable) merge it soonest. It also includes
OK, I agree. Now the code detects ECDH decrypt attempt, and throws exception upon it.
This is exactly the point. I would like tokend to present a different name that would be based not on the driver used for this token, but the CN of a first discovered certificate. |
|
As @frankmorgner wanted a rebase against what I think is his "sha2" branch, see PR frankmorgner/OpenSC.tokend#3. |
frankmorgner
changed the title
Fixes OpenSC/OpenSC#570 an at least 7 year old bug...
Hi @mouse07410, I'm working on something similar and found you guys here. May I know if you got the answer to that Apple Mail signing problem? |
|
@ansnunez First of all, https://github.com/mouse07410OpenSC.tokend appears to produce correct ECDSA signatures, as tested with MS Outlook and Blackberry-10.The complaint you quoted is really old. That problem was taken care of long time ago. Regarding your question (as there still is an issue :-( ), I think I got the answer. What (IMHO)
Thanks to @dengert's guidance, that part is now fixed: The one thing I'm still missing is the ability to extract Common Name from the retrieved certificate, so the token can display it instead of "PIV_II". |
|
Thanks @mouse07410 I'll try to process this info and see if I've got anything to add. That common name problem's on my list too. |
|
@ansnunez thanks, but don't bother - already finished. ;) @dengert if Apple Mail proves up to snuff, it might be the time to revisit |
|
@mouse07410 wow thanks a lot! Good thing I found this thread 👍 |
|
@mouse07410 got another question I hope you or anyone here can help me with. I've got an RSA2k SHA256 certificate that, when imported directly into Keychain Access, is successfully being used by Apple Mail or Adobe Reader XI to sign a mail/document. But when I use tokend, the inputs to generateSignature() are always signOnly = SHA1 and input size = 20 bytes. I don't know why the request isn't for SHA256. Any thoughts why the behavior is different in the two cases? |
No, you got an RSA 2k certificate that its issuer signed using SHA256. It has nothing to do with what hash would this certificate be used with. You can use it to sign with hashes from MD5 to SHA512, and everything in between (and SHA3 if your code supports it).
A snarky remark would be "try without Tokend and see if the results are different". :) Seriously though - no Apple-provided application can access tokens without Tokend (OpenSSL and Firefox/Thunderbird can because they are designed differently, and are not Apple-specific). What you observe is the evidence of the fact that Apple does not allow users to configure what hash (and what encryption algorithm, and even what certificate) to use for S/MIME. Apple knows better. Apple decided that SHA1 should be used as hash for signatures, so Apple Mail performs SHA1. Case closed, no appeal. On the other hand, since we do want to know that Tokend passes the correct data, here's a log excerpt just made with MS Outlook 2011 (with all the MS shortcomings, they still allow you to choose the certificates you want for this account, and to specify what hash and encryption algorithms to use) configured to use SHA256 for signatures: You can see from the above that the confusion is on the user's side, and the problem - on the side of Apple Mail. ;) I must also add that Apple Mail seems to have no problem verifying signatures made using SHA256, it merely refuses to create such signatures. |
|
@mouse07410 Thanks for the explanation. It's crystal clear for Apple Mail. I guess Adobe Reader suffers from a similar but not completely explained issue:
There are some discussions in the Adobe forums of people getting the same kind of problem (e.g., https://forums.adobe.com/thread/1045769). In any case, I think it might be a problem with the application itself. Finally, I tried Outlook 2011 too just now, and my SHA2 code in TokenD works fine :-) |
|
@ansnunez thank you for exploring this - it turned out to be most interesting! I did not realize Acrobat exhibited a similar problem, and the way Adobe staff tried to explain it on their forum was priceless (aka ridiculous). The problem must be with what/how the application requests from the underlying services. One reason - because we know that other applications are able to successfully obtain SHA256 from the same underlying services. Update |
|
@mouse07410 Thanks for the info. I've put Adobe testing on hold for now since Outlook confirms the SHA2 signing works. If I find a definitive answer somewhere about Adobe SHA2 support for TokenD I'll let you guys know. |
|
I still had the same SHA1 problem with Acrobat Pro DC (2015). I guess Adobe is doomed. ;) P.S. Tokend just became a bit better. ;) |
|
A looong thread to read through. Did this lead to anything? Seeing no changes in OpenSC.tokend master, I'd guess not? |
@martinpaljak it led to creation of the OpenSC.tokend fork that supports ECC and SHA-2. I needed that functionality, and wasn't able to reach an agreement on the merge. So the only path left was maintaining my own fork, which I did. That's probably what people use if they need a working SHA-2 capable tokend. I guess you can say that for the main repo it did not lead anywhere - it's still broken wrt. SHA-2, and still does not support ECC tokens. Caveat: there are no applications that I know of that can use ECDH, so ECDH support is not done (nothing to test against). ECDSA is fully functional. P.S. Regarding "I still had the same SHA1 problem with Acrobat Pro DC (2015)" - it's fixed by the Mac OS X update to 10.11.6. Now Acrobat uses SHA-256 when requested for signing with hardware tokens. P.P.S. MacOS Sierra includes a working tokend that was shown to support RSA tokens. So hopefully (depending on their ECC support) I won't need to maintain my fork for much longer. |
|
I am not able to pinpoint the actual problem that did now allow for the merge? |
I personally saw/see no technical problem either. The maintainer did not want to merge. Basically, he wanted me to re-write the code in a different way. That would make the code look nicer, but it did not work (his re-write in that style did not work either). I had neither time nor skills (nor help) to get to the bottom of that. So I left the code the way it was - working. My fork contains enhancements and fixes that @frankmorgner made, plus enhancements and fixes on top of those. As you can see from the above posts (#570 (comment)), it appears that people find my fork useful (at least those who are able to find it :). I've made another PR against the main master: OpenSC/OpenSC.tokend#28. Please feel free to merge it, or close - as you see fit. At this point I'm just maintaining my fork for bug fixes, until Apple native tokend includes all of these capabilities (or until this fork is merged into the main repo, which at this time I don't hope for very much). The only possible/missing enhancement would be full support for ECDH - and that is highly unlikely in the absence of applications that use it. Update |
|
@dengert what about setting the token label based on the certificate common name in pkcs15-piv.c ? See OpenSC/OpenSC.tokend#28 (comment) for a reasoning. |
|
Backward compatibility. PKCS#11 says: Tokend can always get all the certificates, and parse them for the CN. |
|
Well, I believe there's a sensible default between good user experience and backward compatibility. The card driver is in the best position to decide which card to use for the token label (PKCS#15 sense) and it makes sense for the Tokend driver only to relay that to the OSX UI, instead of Most drivers in OpenSC don't make use of it, only have the token label as a generic "card type" name, rather than for the end user to understand and associate with the inserted card. And once you have two cards of the same type.... Things go hairy. Anyway, I'd not be including the certificate based naming into tokend, but would suggest to implement in PIV driver. |
|
I have been referring to the Label of an object on a token. Sounds like you are referring to the label in the PKCS#11 tokenInfo. Since tokend does not use PKCS#11, RFC 7412 does not apply. Can you look and see if sc_pkcs15_get_name_from_dn which was added recently would met you needs? See commit: e4f5f84 |
|
|
|
@dengert I'm referring to the label set here: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-piv.c#L620 @mouse07410 wants to use the CN from a certificate for this label (makes sense). The same is done in https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-esteid.c#L120 I don't know what would be the best, CN seems meaningful. Anyway, setting this label is NOT the job of Tokend, for the sake of meaningful layering. |
|
I would be very reluctant to change the p15card->tokeninfo->label. There are 58 uses of "tokeninfo*.label" in src/libopensc Most of the pkcs15-.c set this to a constant to represent the card or application on the card, using strdup or set_string from a constant. p15card->tokeninfo->label is also used in pkcs11/framework-pkcs15.c So if p15card->tokeninfo->label is changed, it will impact PKCS#11 too, and cause a backward compatibility issue for current users. If you want change p15card->tokeninfo->label for the PIV, I would suggest that all the cards do the same. And get the libp11 URI advocates involved too. As I see the problem, @mouse07410 wants a name the user can relate too. Microsoft addressed the problem in the Certificate Store by showing "Issued To", "Issued By" and allowing the user to set "Friendly Name" and "Description" for a certificate. Internet Options->Content->Certificates. Click on a certificate->View->Details->Edit Properties->General What I was suggesting that tokend could take the same approach, and retrieve whatever info it wanted from the certificate, and the new sc_pkcs15_get_name_from_dn() could be used. |
Every commercial tokend presents such a name that is based on a certificate found on the token.
That's exactly what my tokend fork is doing.
Sure. I don't remember if I use it or not - it depends on when that function was introduced relative to when I released this capability... |
|
Implementation and discussion is continued here OpenSC/OpenSC.tokend#28 |
Using the current/latest OpenSC.tokend from Github, and RSA-2048 keys/certs on the latest NEO (PIV applet 0.1.3). And a current-issue CAC.
All the OpenSC utilities seem to work fine, and as expected. The only problem is with OpenSC.tokend. It is unable to unlock the card, though
I assume the successful unlock is not communicated because (a) Keychain Access does not change the card status from "locked" to "unlocked" upon receiving the correct PIN, and (b) Thunderbird keeps asking for the PIN over and over again - as if the unlock fails.
OpenSC.tokend also seems to fail to read the ATR to determine the correct card type, based on these entries in the opensc-debug.log (log shows both CAC on SCR3310 reader, and Yubikey NEO that is its own reader):
The text was updated successfully, but these errors were encountered: