OpenSSH: Sign and Send Public Key Failed #1460
Comments
|
What version of OpenSSH? Is your card a real PIV card, a dual mode CAC/PIV card or some other PIV like card/device? Which certificate/key are you using? "X.509 Certificate for PIV Authentication" or "X.509 Certificate for Digital Signature". ("X.509 Certificate for Digital Signature" requires PIN Always, i.e. pin must be entered every time the key is used, or must be cached and opensc.conf set to tell it to ignore user_consent) Did anything else change other then the version of OpenSC? A pkcs11-spy trace and opensc-debug.log would be helpful and would show what type of card and which certificate/key was being used. https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC |
|
The version of OpenSSH I'm using: The card I'm using is a real PIV card, and it always requires a PIN to be entered. Here's some additional info I was able to pull from the card: Running OPENSC_DEBUG=9 pkcs11-tool --list-slots provides this via STDOUT: Slot 0 (0x0): Identiv SCR3500 A Contact Reader Running this command: I get about 5000 lines on STDERR, Here's the last 60 or so. If you need some other part, let me know, and I can upload that as well. 0x7fffb6c0f380 14:50:20.191 [opensc-pkcs11] apdu.c:390:sc_single_transmit: returning with: 0 (Success) Thanks again |
|
Al the above shows is you did not provide the PIN to pkcs11-tool. It does not show the ATR of the card, or which certificate/key was selected. Are there any other applications running, including tokend that might also be accessing the card? P.S. I am not a MacOS person. |
|
That's odd, because it did ask me my PIN and I entered it. I don't have any other applications running or accessing it. My colleague and I are both running identical laptops with High Sierra, with the only difference is he has 0.16 installed, and I've tried 0.18 and the 0.19 nightly. Yet, the PIV works on his machine. I also found out that another colleague of mine running Sierra and 0.18 and I'm able to use my PIV on his machine. I think my problem may be OS X related. I just find the different configurations that work to be very strange. UPDATE: 0x7fffb6c0f380 14:43:51.569 [opensc-pkcs11] card-piv.c:547:piv_general_io: DEE r=0 apdu.resplen=0 sw1=6d sw2=00 and this: fffb6c0f380 14:43:51.647 [opensc-pkcs11] card-piv.c:547:piv_general_io: DEE r=0 apdu.resplen=0 sw1=6a sw2=80 |
|
Can you send the full opensc-debug.log? You can obfuscate the PIN (look for it in apdu sending as hex digits followed by FFs) and maybe other information like certificate content and or chuid content. When did you start seeing problems on your computer? You tried 0.18 nightly. Did you try the released 0.18? |
|
I have a problem with the current master that may be related. It manifests itself with Pulse Secure VPN. The current master does not pick the cert, tokend log showing churning in calling getAcl() that every time returns 1 entry. After some time more than a minute or would find the correct cert and prompt for a PIN - but by then the server time-outs. It worked on Sierra, and with older OpenSC. If be happy to email the OpenSC debug log, if it's ok (and maybe Pulse Secure log, if I get permission). P.S. Released 0.18 works on one machine, didn't work on others. |
frankmorgner
changed the title
|
@dengert, sorry for taking to song in replying. I've attached the filed like you asked. I've redacted any identifying info (I think), and replaced it with ".......". Thanks for taking the time to look at the file. Just so you know, this is output when I run: OPENSC_DEBUG=9 pkcs11-tool -v -s -m RSA-PKCS -i t2048.dat -o t2048.dat.sig 2> log t2048.dat.sig is never created. I've tried running this on .18 stable(same error), and ran the command on 0.19 (nightly 2018-08-27_b5a6f9aa). 0.19 works fine on my yubikey. The only problem I'm having is with my PIV. |
|
Between the PIN verification (search for If I remember correct, then the signature creation should immediately follow the PIN verification, right? |
|
Right. |
|
That would be true for the 9C key that needs the PIN_Always/user_consent/CKA_ALWAYS_AUTHENTICATE but this sign operation is with th 9A key and that should not be enforced by the card:
The two extra commands are the SELECT_AID and get response. NIST 800-73 says selecting the AID will not changes the security status. But this appears to be a dual CAC/PIV card issued be a gov agency. The user says this card works on other Macs with 0.18.0, but not on his. So it does not look like the card is different. I suspect there is some other application is running that did CAC operation causes the PIV security status to be reset. The sign operation is tried twice, and use_pin_cache=1:
I see: @mtoconno are the readers the same on the machine were it works and your where it fails? |
|
@dengert, after some further investigation, I found that it does NOT work with 0.18 on other computers. My coworker had downgraded back to 0.16 (he checked his openSC version thru a Mac GUI which caused the confusion). So to be clear, the only release that I know works is 0.16. Sorry for the confusion. Regarding the reader: we've used the same reader on all the machines, so I don't think it's the reader. After looking at the logs on my computer, and a computer with 0.16 installed, I noticed a few areas where there are some pretty big differences: Above, it looks like the two versions diverge after check_sw. 0.16 does some pin verification, whereas 0.19 tries to get some data? The outgoing APDU for 0.19 gives a random string, whereas the outgoing APDU for 0.16 is the user pin. As well as this: The two blocks above are at the same part, but whereas 0.16 computes a signature and does some encoding stuff before sc_lock, 0.19 calls SELECT_AID. Later, you can see that openSC 0.16 correctly reads the file(which only contains the word 'test'), whereas 0.19 does not. There's a bunch more divergences, most of which are similar to the ones I posted above. If you think it would help you, I can post the log generated by 0.16 |
|
Yes the 0.16 debug log would help. The keyUsage extension in the certificate might also give a clue. Another possibility: If you want to test this out, you can modify libopensc/pkcs15-piv.c line 510: If this works, we can work through how to identify such a card, and a CI_* in card-piv.c I note that the card returns a 11 byte piv AID but the PIV cards I have seen only return 9 bytes. |
|
@dengert I've attached the 0.16 debug log for you. I tried to compile opensc on my mac, but I couldn't figure it out. I checked the project wiki and mailing list to see if I could figure it out, but no luck. @frankmorgner, if u could post some instructions on how to compile on OS X, I'd be happy to try the code modification proposed in the previous post. |
|
@mtoconno have you tried using the CAC driver? |
|
Can you try running this test script then run with PIN and basic as parameters, then run with PIN and basic11. Note output has your PIN, so before posting responses, set PIN to something like xx xx xx xx xx The script will show the login state of the card after selected commands to see it matches NIST 800-73 requirements. There is code in the PIV driver files card-piv.c and pkcs15-piv.c to use the keyusage from certificates if the card is not a gov issued card. This may need to be extended to gov issued cards like yours. But I would first need to know the keyUsage from your certificates. PIV card ID=01 uses the 9A key, and ID=02 uses the 9C key. 9C requires
I am looking to see what certificate of yours has |
|
If his card is gov't-issued (like CAC), 9A can not have "ALWAYS_AUTHENTICATE" set (aka it can not require "PIN_ALWAYS"). |
|
I agree. But the logs are not clear on why the sign command says it is
failing. It is acting like the card is enforcing PIN ALWAYS. The script
should give some clue. Changing the 0 to 1 in pkcs15-piv.c would test it
too.
Hard to debug without a Dual CAC/PIV card.
…On Sun, Sep 2, 2018, 3:09 PM Mouse ***@***.***> wrote:
If his card is gov't-issued (like CAC), 9A can *not* have
"ALWAYS_AUTHENTICATE" set (aka it can *not* require "PIN_ALWAYS").
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1460 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MQ2Q1rgbpMS4XeKY-Zaq2cAUEYCUks5uXDr3gaJpZM4WOMu8>
.
|
|
Yeah I hear you. I've heck of a time trying to get CAC (dual) to work with the latest Firefox and OpenSC. Firefox insists on choosing the cert automatically (which for web auth inevitably is 9A), and DOD Enterprise Mail rejects it (because it requires 9C). Of course there's a setting in Firefox, and of course whenever I set it to "always ask" it automatically switches back to "choose automatically"... Oh well. |
|
If you have such a Dual CAC/PIV can you dump the certificates via CAC
driver and via PIV driver and see which ones match. What are the keyUsage
of each?
Does a CAC sign key match the 9A key?
…On Sun, Sep 2, 2018, 7:36 PM Mouse ***@***.***> wrote:
Yeah I hear you. I've heck of a time trying to get CAC (dual) to work with
the latest Firefox and OpenSC. Firefox insists on choosing the cert
automatically (which for web auth inevitably is 9A), and DOD Enterprise
Mail rejects it (because it requires 9C).
Of course there's a setting in Firefox, and of course whenever I set it to
"always ask" it automatically switches back to "choose automatically"... Oh
well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1460 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MWgLJo2YqZQoR6I6tXCN03ZXdbOgks5uXHmLgaJpZM4WOMu8>
.
|
|
Let me experiment after the Holiday and get back to you. |
|
Thanks. There are many PIV and CAC/PIV card manufactures, each has written their own PIV applet. |
|
@mtoconno Try with 0.18.0. or 0.19.0. With 0.19.0 you will need to add the I say "temporary" because it is still not clear why the security status is lost and I would like to resolve this issue. Current thought is the 9A key is enforcing the PIN_ALWAYS policy or the SELECT_AID is resetting the login state on the card. Both violate the PIV specifications.
Line 764 in master, line 618 in 0.16.0 produces this on the log: The above code helps enforce the PIN_ALWAYS policy of the card issuer by default. |
|
@dengert thanks for your help. I'll send you the output from the script you posted earlier and the result of changing the conf file tomorrow. |
|
@dengert, so I added the two lines you suggested to my opensc.conf file, and it works. I'm able to sign a file, and successfully ssh. Thanks! (I'm running opensc 0.19) Of note though, I did try running the script you provided without the original conf file, and the script returned the following:
I think it probably does this because of the PIN caching issue you outlined above. Going forward, should I tell my coworkers to modify their opensc.conf files, since this seems to be against the NIST standard, and an issue for a very small subset of users? Also, just for my own understanding of the issue, the following table is what you're referring to regarding the PIN policy? |
|
Good to hear it works for you. The table above says"9C" is "PIN Always" but not "9A" Based on editing the script and running it with 2 parameters: Your PIN and basic, would show if the problem is caused by the 9A key having "PIN Always" or the SELECT PIV AID command is losing the login state. There is at least one other PIV like card where the SELECT PIV AID losees the login state despite NIST 800-73 says it should not. Depending on if you use other types of card or need to use a PIN PAD reader, you could run with the changes you have already made to the opensc.conf as it applies to all cards, and does not solve the problem if you are using a PIN PAD reader. |
|
Ok. Sorry, I misunderstood the output from the bash script (thought exit code should be 9000 initially). Here's the output after running basic:
|
|
With comments: It looks like the card does not follow NIST 800-73-4 Part 2, Section "3.1.1 SELECT Card Command": |
|
I wonder - is it a government PIV card? |
|
What's the output of If it is something like |
|
So another way to deal with the card in this issue in 0.18.0 (and maybe 0.17.0) would be to add to card-piv.c tries to avoid doing an SELECT AIDs after the first one. Other applications may still cause interference. |
|
Sorry for the late response everyone. @frankmorgner, the output I get from my PIV when running both commands is: @mouse07410, yes its a government agency issued PIV card. |
|
Are the above commands correct? The "C" does not look correct it should be "00" to meet I would also add --card-driver to not try and select a card driver that may send other commands and |
|
I added an extra 0 above too. Sorry. This may be a little more readable and run against an Oberther ID-One PIV Then if I parsed this correctly... |
|
@dengert and @frankmorgner , sorry again for the long delay in response. Here's the data you requested: |
|
So it is a Java Card Applet... But I lost track... is there still a problem to solve? Is the problem still present in 0.19.0? @dengert, do you think you need to check for the GP AIDs n card-piv.c to initialize |
|
I would like to ask @mtoconno :
It could be this dual CAC/PIV card is imposing the PIN_ALWAYS rule on the 9A key, which it should not be doing. One way to address that is to examine the keyUsage bits from the certificate. pkcs15-piv.c will use the keyUsage bits from a certificate if it not a GOV issued card. (Look for In response to question on setting There are many cards with PIV applets. These include NIST approved cards and US- GSA approved. And the above does not list the Dual mode CAC/PIV cards. The card in question may be one of these. Many of these cards are Java/GP based, but there is no NIST requirement for JAVA or GP. Checking the GP AID would not help. Even checking the ATR is not very helpful unless it says the default AID is the PIV AID or has some vendor specific fields like Yubico and Safenet. (I have tried to avoid using a list of ATRs, as anyone could put a PIV applet on almost any card.) Card-piv.c attempts to determine the type of card/token where there are multiple applets on the card and multiple running applications using one or more of the applets. It tries to not cause the current login state of the active application to be lost while trying to determine if there is a PIV applet and its issues. And at the same time test if the API is still active and the login state was not lost because some other application or card driver reset the PIV login state. |
|
@dengert , sorry for not responding earlier, this got lost in my email.
The most recent nightly build of 0.19 I tried was from Aug 27
Is there a specific debug log you'd like me to post?
I was unable to get the nightly build to compile in OS X, so I couldn't test this out (I'm not very experienced in C development in OS X)
Yes, adding those two comments got my PIV working for me. EDIT: I just saw 0.19 was released. I'll download and it install it tonight. I'll let you know tomorrow if it works for me. |
|
Even with 0.19.0 you may still need the the For those developers out there: We have been looking at Dual CAC/PIV cards and there are a number of issues, that I think we can address so the above will not be needed. These include:
|
|
In CAC driver, the certificates have in first place specific paths and are already parsed and used from the CCC: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cac.c#L1469-L1474 Did you have a look into the CCC checking in the PIV driver to unbreak it for the dual cards or do you still need some more information/help/testing? |
|
Ok I see you pickup the AID from the CCC F3 entries including any PIV object with I have one other question. PIV specs 800-73-1 used for CAC PIV Endpoint, says VERIFY is In other words NIST changed the default PIN reference from 00 to 80. The PIV driver is based on 800-73-3 so uses 80 as the default. the VERIFY with Lc=0 can be used to test the login state. So if the key reference is wrong, it may appear the card has lost the login state. Can you please try a test where you change in card-piv.c and try If so I will change to use pin reference 00 for cards not supporting 800-73-3. |
|
This did not help. It actually broke the login completely. Here is the snippet of the debug log: So this is unfortunately not a way to go. |
|
@dengert ping. Any progress here? Do you need some help with drafting a patch? |
|
I have been working on a patch for this that uses ATRs for some known Dual CAC/PIV cards and some other cards. as well as parsing the CCC if present to identify any other Dual CAC/PIV cards. I hope to have it ready in the next few days, In the meantime there is the circumvention of using. |
|
@dengert , I've been successfully using 0.19 release with the |
|
Is there anything left to do? |
|
I think this was solved with #1549 |
When trying to ssh using a US PIV card in OpenSC version 0.18 and 0.19 (nightly 2018-08-27_b5a6f9aa) on Mac OSX High Sierra, I receive the following error:
debug1: Offering public key: RSA SHA256:...... /usr/local/lib/opensc-pkcs11.so
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:......
debug3: sign_and_send_pubkey: RSA SHA256:.....
sign_and_send_pubkey: signing failed: agent refused operation
However, when logging in using 0.16, I am able to login, and receive the following verbose output:
debug1: Offering public key: RSA SHA256:.... /usr/local/lib/opensc-pkcs11.so
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:....
debug3: sign_and_send_pubkey: RSA SHA256:....
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
So it seems that there was some change to the code base that changed the sign_and_send_pubkey function between 0.16 and 0.18 that broke the functionality for US PIV cards. Can anyone shed some light on this?
Thanks!
The text was updated successfully, but these errors were encountered: