-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test of PKCS # 11 yields CKR_USER_NOT_LOGGED_IN (0x101) #1531
Comments
What version of OpenSC are you running? Some debugging would be helpful. See https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC Windows has its own driver for PIV and so there can be interference from multiple applications. The debug log should help. |
Thank you for getting back to me so promptly! I am running 0.19.0, the latest stable release advertised by the website yesterday. I don't really know how to follow the page you provided.
Sorry that I am not fluent in this! Are you able to break it down for me at all? Thanks. -Dan |
Here is what I get on Windows 10 with 0.19.0.0 installed on 8.30/18. This is using NIST demo card 1.
Your command gets an error here. My command continues...
I then cancelled it here; This sounds very similar to: #1460 What is the output (the card's ATR) from running: Can you try #1460 (comment) 0.19.0 simplified the
# debug = 3;
# debug_file = opensc-debug.txt
framework pkcs15 {
# use_file_caching = true;
}
} Previous versions of OpenSC had a fully commented version of opensc.conf but that is not installed. This could be a good starting # debug = 3;
# debug_file = %TEMP%\opensc-debug.txt;
#card_atr 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00 {
# driver = "PIV-II";
# type = 14005;
# }
framework pkcs15 {
# use_file_caching = true;
# Use PIN caching?
# Default: true
# use_pin_caching = false;
# Older PKCS#11 applications not supporting CKA_ALWAYS_AUTHENTICATE
# may need to set this to get signatures to work with some cards.
# Default: false
# pin_cache_ignore_user_consent = true;
}
} To get debuging output uncomment the To treat your card differently, uncomment the To see if it is a problem with the PIN_always/user_consent uncomment the |
The above example opensc.conf should have a first line:
|
dengert, adding: fixed it for me! I do have a dual cac/piv card, so that worked. Thank you! |
OK, I will look at checking for this ATR in the code. |
It looks like I have got very similar report that dual CAC/PIV card is no longer detected by the PIV driver: https://bugzilla.redhat.com/show_bug.cgi?id=1651748 It has also attached a debug log if somebody would like to peek into that. If I see right, the PIN is properly verified, but then the login state is lost which results in the failure of the signature (no always_authenticate is involved here). The old card from 2012 (which I talked about in #1533) is not detected at all in PIV driver, but I do not think it was ever detected nor the workaround here helps. |
Yes it does look similar. The circumvention was to tell the PIV driver to assume the card type = 1405` It was found that some cards can lose the login state when a SELECT AID was done for the PIV AID even though the NIST 800-73-* says this shall not happen. The SELECT AID was being done to make sure the the PIV applet was/is the current applet. (interference avoidence). There may be other cards that have this compliance issue. But how to identify them? I found this: CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc which list current and obsolete CAC cards with their ATRs. All the current applets are all V2.6.2b. So far the 1 card with the problem as fixed in 0911982 and the card in question are listed as current. These are Giesecke & Devrient (PIV Endpoint) 3B 7A 18 00 00 73 66 74 65 20 63 64 31 34 34 (exp 6 2019 SHA1) All of these are running CAC Applet Package V2.6.2b The other ongoing card is The ATR in https://bugzilla.redhat.com/show_bug.cgi?id=1651748#c3 is not listed. It looks like it loses the login state after SELECT_AID or the 9A key is being treated as "PIN Always" Look for the Verify then later: I can't tell from the log which it might be. So some possible ways to handle a card that returns NIST 800-73-2 was released in Sept 2008 and "Added optional Discovery Object." So any card that returns something other then Sunflower 3_2 AI Applet v2.6.2b Security Policy Card_v1.2 Final_PDM1.1.doc says: "PIV EP Wrapper Applet – This applet implements the Personal IdentityVerification services from NIST SP800-73-1". This implies Discovery object is not implemented. I will submit a PR to tighten up the setting up of the card issues flags so any of these cards will look like SC_CARD_TYPE_PIV_II_GI_DE type 14005 which does not try and do any interference prevention. |
I suspect the current CAC (dual) exhibits this problem too. |
The ATR from the card in the previous comment (Red Hat bugzilla) is Therefore exactly the same as from the @dpmcgonigle . The same workaround works also for this card. @dengert let me know if there is something I can help in some way, I should test something or get some data from the card Just checking the content of the card, the CCC looks this way:
(Value File)
From manual parsing, the Where did you find what version of applet is used on the card? |
https://www.cac.mil/Portals/53/Documents/CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc (I also found a 2013 version but can not find it anymore.) It appears to be a DoD list of all DoD CAC cards with ATR, version, card vendor, and most interestingly Many of the "Obsolete Platforms" are using 1024 bit keys and the card with SHA1 signed certificates are due to expire June 2019. All the "Current Platforms" support "PIV Endpoint". i.e. Dual CAC/PIV. Are there any other CAC cards out there? You had said there was some need for the CACv1 cards. CACv1 Appear to only use 1024 RSA. As a side note: Depending on how the applet was written could lead to "PIN Always" being enforced on the PIV auth. cert/key. Don't know if we have ever run into this. It is also possible that since accessing the CAC Sign key via CAC does not enforce "PIN Always" but accessing the same key via PIV enforces the "PIN Always" or it might not. @mouse07410 while typing this comment: Is there anyway to start using the PIV Auth cert/key with those sites? What ATR are your Dual CAC/PIV cards? |
The need for the CACv1 were the Alt Tokens -- not actual CAC tokens, but to some extent compatible cards. They do not carry everything you will find in CAC and they do not need to be the classical identity cards. They usually have just one or two certificates provisioned for special use case as far as I understand it. |
@Jakuje It should show the same CCC but with combined tag length values. If it does, looking for F3 with CAC RID of I would like to avoid a list of ATR in the code unless https://www.cac.mil/Portals/53/Documents/CAC-utilziation-and-variation-matrix-v2.03-20May2016.doc contains all of them. I would like to fall back on the CCC if present via PIV to test if it is a CAC card too without having to do a SELECT AID if possible. This has some good stuff to: |
Here you are:
This looks the same as the CCC from the CAC driver. Standard PIV cards do not have these, neither any of
This sounds like a good pointer where to start for detecting these cards. |
Hello, I'm having the same issue with my card. Meaning, that when I run the command: "pkcs11-tool -t -l" It fails as described by dpmcgonigle. I tried adding the attributes provided to the opensc.conf file, however that didn't work. So I'm wondering, how can I double check my cards attributes? Is there a way using the pkcs11-tool to get them? Thanks! Here is the command output: |
The ATR would help us. Use Did you add to opensc.conf the stanza as in: #1531 (comment) but with your ATR? This forces the card driver to assume a card has certain properties. What version of OpenSC are you running? |
Woow, thanks for the prompt response! I changed the attribute to the one returned when running opensc-tool -a. I don't get that error anymore, however I'm getting this: "ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)". This is the full output:
I'm using opensc 0.19.0 |
What was the ATR of your card? I would like to know if it is a CAC card or not.
|
the card attribute is: "3b:fc:18:00:00:81:31:80:45:90:67:46:4a:00:64:2d:70:c1:72:fe:e0:fe". As you mentioned, it is a PIV card that runs a JAVA applet. I'll look on the closed issues to solve the Thank you! |
Your card appears to be a PIVKEY card or token from Taglio. I have a few of these but not with the same ATR, and I have not done much with them. So I am not sure why your card fails as it is not a CAC. An opensc-debug.log would be very useful. They appear to support the Discovery Object, but there is no Discovery object on the card. Its optional. (Blank cards have a CARD AUTH cert/key signed by Tiglio. Note: PIV standards does not require a PIN to be entered so this should not be used to authenticate a user, only a card.) |
@erick-orozco if you have time and don't mind a potentially unnecessary experiment, perhaps you could try building OpenSC from my fork https://GitHub.com/mouse07410/OpenSC.git ? One of the differences is that my fork disables ALWAYS_AUTHENTICATE enforcement by software, and I suspect your problem could be related to that. If your card works with my fork, it would prove my theory and give you a usable solution. If it doesn't - well, then I'm wrong and I apologize. @dengert my apologies for a delayed response. No, in my experience no browser would actually force using SIGN cert, regardless of how the web site is configured. In fact, my problem with such sites was the opposite: the browser would not ask me what cert to pick, and automatically choose PIV AUTH (which then was promptly rejected by the server). I think the incessant prompting for the PIN it's not related to the ALWSYS_AUTHENTICATE, but to the erroneous (IMHO) way the software tried to enforce it. No, there's no way to convince those servers to accept AUTH cert instead of SIGN cert. I don't think they differ between PIV and CAC. I know that SIGN includes SAN email attribute, and NON-REPUDIATION flag - which AUTH cert lacks. Might also be the fact that they're issued by different CAs, but both chain-link to the same DoD root... |
I agree with: "No, in my experience no browser would actually force using SIGN cert, regardless of how the web site is configured." It has more to do with the certificate keyUsage and other extensions along with and who signed it. I was suggesting is there a way to register the PIV Auth cert as the one to use at a specific web site. Not having access to a real CAC card and reluctance of users to expose their certs in these issue I can only suggest. In regards to the PIN. there are some possible issues:
4: There is no way to test if a card supports the "PIN Always" on a key, other then to try it. 800-73-* says the SIGN key is protected, and a compliant card applet will enforce it. You might note that the solution to many of these problems is to treat the card as a "SC_CARD_TYPE_PIV_II_GI_DE" type 14005. in 0911982
which in effect turns off trying to check for the login state of a card before any transaction. My intention at this time is to have the PIV driver use a list of ATR of known CAC cards or cards that can return a CCC object that says there are CAC type objects on the card as a 1405. (The card must still allow a SELECT AID for PIV to be considered a PIV card.) |
Hello, this is the best support I've ever had from an open source project!! Attached are the logs. @mouse07410 I'll build it from the fork, and send you the logs. Thanks! |
I don't know about KU and EKU - as I said, I rather suspect it's the SAN extension that differentiates between the AUTH and SIGN certs for those "special" web sites. I also don't know if the CA chain matters. The only KU attribute that I think could matter is "Non-Repudiation". Everything else shouldn't matter, IMHO.
Alas, no. I found three kinds of sites:
I do not know. Hopefully you can make sense of it. It's beyond my expertise and experience.
Somehow I suspect that this is the case, though I can't be sure.
Thankfully, at least Yubikey seems to work fine (and people at work are thanking me for introducing them to this nifty device ;). You're probably right about the cause, and as you said, it's probably related to (2). Maybe we'll figure how to deal with it. For now I'm reasonably happy to just forget about "cac" driver, and use PIV driver for everything I got (except the OpenPGP applet on Yubikeys, of course ;).
Frankly and bluntly - I couldn't care less. If the card "meant" to have ALWAYS_AUTHENTICATE but lacked hardware support for it, I don't need software to fix that at the cost of inconveniencing user (by making him type PIN twice) or risking the problem we seem to experience with CAC and Firefox. The card is supposed to hardware-enforce that property, and that's a fundamental enough property to expect compliance. If it doesn't - too bad.
So far it seems to work.
I don't know. All the newer CAC are PIV-compliant, AFAICT. For the older stuff, why not just use the old driver and be done with it?
That's one big concern. @erick-orozco thanks, I got the log. I'm afraid I'm not as skilled at getting nuggets of it as @dengert is. All that I saw of interest was that (a) it seemed to be a Feitan card, and (b) it kept failing attempts to SELECT objects on it. Perhaps @dengert can tell if things look right there. Also, what did you try to do? And did it work? I.e., is this a log of a problem, or a record of success? Re. support - yes, I find that Open Source in general provides much better support than many commercial products, and OpenSC package (including some "daughter-packages" like libp11) is supported better than most. |
@dengert to emphasize my point about "OpenSC trying to play cop". We all know that vendors do screw up their implementations of the standard, and in general exhibit non-compliance to various degree. Understandably, we're trying to accommodate and make our middleware work with as many tokens as we can. The question is how far we should go. IMHO, some properties are so fundamental that if they're not present, it doesn't make sense to use such a token at all. For example, a card that allows extracting private keys in the clear, or but enforcing PIN access when it is configured. Such tokens wouldn't offer security that people associate with use of hardware tokens compared to, e.g., software tokens. |
@mouse07410 I'm running the The same issue happened with the forked repo you suggested. Thanks! |
In regards to playing "cop": This belongs in #1533. |
https://pivkey.zendesk.com/hc/en-us/articles/360002596891-Getting-Started also says: "PIVKey can be used on Linux or Mac OSX with the installation of additional middleware, however, for these environments PIVKey is read-only! The standard PIVKey admin tool on Windows must be used to load certificates to the card. Using PIVKey with the Firefox browser also requires an additional PKCS11 component that supports the PIV interface. OpenSC is an open source package that can do so." |
@dengert I knew that the token we are using is read-only on Linux, but I thought that it will only behave like that when loading certificates and keys to the token. Let me take a step back, and ask what is the test trying to do when it fails (I know is trying to generate random numbers, but for what purpose)? Thanks! |
Some applications may want to use a hardware decice to generate a random
number via PKCS#11. The PIV can do that via the APDU that is failing. Not
all PIV cards have a 9B key.
Looks like PIVKEY can not. I plan to submit a PR for this problem.
…On Thu, Nov 29, 2018, 1:26 PM erick-orozco ***@***.*** wrote:
@dengert <https://github.com/dengert> I knew that the token we are using
is read-only on Linux, but I thought that it will only behave like that
when loading certificates and keys to the token. Let me take a step back,
and ask what is the test trying to do when it fails (I know is trying to
generate random numbers, but for what purpose)?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1531 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MeKfsaASvkCE5uWtbcmXUUujxYS-ks5u0DTYgaJpZM4Yapw7>
.
|
What's the status of this issue? Is there anything to do? |
I would say it could be closed. There is circumvention for @dpmcgonigle and @erick-orozco is trying to do something the PIVKEY card can not do. |
I had the same problem with a DoD CAC/PIV on Linux. While I could do every other function (Firefox, Thunderbird, Chromium, LibreOffice, Openconnect VPN) with the CAC, I could not sign PDF forms with PDF Studio. For the benefit of others, and for possible revision of software, here is what I did:
|
I request that this issue be reopened. It was closed by @frankmorgner on the basis that the submitter found a workaround. While that workaround (which I have summarized) is effective, it is not a solution. Perhaps these cards do not comply with standards, but given the number of CAC/PIV cards in use, there are almost certainly more that potentially exhibit this problem, and most users will have no idea what OpenSC is, never mind find their way to this issue. |
AFAIK the issue of CAC/PIV cards losing login state was already addressed too. What OpenSC version are you using? |
This is from Debian 10; it is quite possible that it is addressed as Debian stable tends to be old.
Do you know what issue addressed it? It is not evident here that it was ever addressed, only, as I said, that the submitter had a workaround so the issue was closed. |
Change
Note that those ATRs are already included in the most recent stable version, which doesn't require any modification to |
AFAIK, it was fixed with PR #1549 which is in 0.20.0, but not in 0.19.0 yet. |
Keeping up with what versions of CAC/PIV are in in current use is not easy. They changed the name of the document from 2016. I have found a newer version at https://github.com/liamh Look this over to see if your CAC card is listed, as current or obsolete. I will review the table and update card-piv.c |
It's the second column "Oberthur ID One 128 v5.5" (mine is v5.5a). It is listed as both current (first page) and obsolete (last page, as "Dual"). They have the same ATR listed. My card expiration is JAN 2022. I believe that keeping up is not easy - when they required us to add PIVs to our cards, they didn't tell us that some models didn't support that, and that we had to get new cards if our card wouldn't take it. I wasted much time trying to figure out why their instructions didn't work. Would it help to consult CACKey? I had been using that for years. It works for my current card for applications that support it (but not all do, which is one reason why I moved to OpenSC for everything). |
If you want to use the CAC applet vs the PIV applet you can change the order of the drivers in opensc.conf, something like OpenSC does not have a way to allow pkcs11 to access more then one one applet on the card at the same time. But I had modification from 2 years ago, but there was no interest in it then. There are cards with OpenPGP and PIV too. https://github.com/dengert/OpenSC/tree/pkcs11-multi-application-2 In the DOD table look close at the current table vs obsolete, the difference is most likey RSA 2048 with SHA-256 signatures are now (required) current and obsolete had RSA 1024 SHA-1 which are not consifered secure by everyone. |
I'm having the same problems as others in this thread. I'm using the latest build of OpenSC on MacOS. My ATR is:
I've tried adding my ATR to the conf file as discussed above, but no luck. This card works fine on Windows. I appreciate any help you can offer. |
The ATR says it is a "PIVKey CP70 (PKI)" https://pivkey.com/ NIST SP 800-73 does not allow a PIN to be sent over a contactless interface. Are you using a contact or contactless reader? OpenSC can handle some PIVKey cards, but I have not seen/ What version of OpenSC? When you say it works over windows do you mean with Can you get a debug log: (Note it might expose your PIN and certificates): |
Here's the debug log: Gist Using the default Windows driver. Using contact mode. OpenSC 0.22.0 Thanks! |
The driver does not recognize the ATR but finds it has a PIV applet on card, so treats it as SC_CARD_TYPE_PIV_II_GENERIC (14001). Try adding something like the following to
From the debug log, It looks like there is one zipped certificate on the card. NIST 800-73 Part 1 says: Table 3: "Card Authentication key" (i.e. 9E key) "Security Condition for use" "Always" which means it does not require a PIN. The certificate and key are meant to be used without a PIN so the card can authenticate itself to the host or physical security device as outlined in: B.1.5 Authentication using Card Authentication Key. It appears the card comes with such a certificate and key. https://shop.pivkey.com/c70-dp-dual-pki-smart-card-with-prox/ In other words the PIVKey card is not following the PIV standard and requiring the PIN to be verified to use this key. This is complicated because the the PIN was verified in line 2965, if the security status on the card is not lost, it may work. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L3426-L3433 for PIV_Key cards sets a card issue flag:CI_PIV_AID_LOSE_STATE so a select of PIV will not be done once the card is matched to avoid a reset of login state selected. NIST 800-73 says a select of the PIV AID or an attempt to select some AID not recognized by the card will not reset the PIV login state. The PIVKey card is not following the standard in this case. For other cards to avoid interference of other applications trying to access the card the driver will make sure the PIV applet is selected but AFAIK the PIVKey cards do not have other applets. Thus the select AID is not needed for these card once the card is recognized to get around non compliance issues. This is at the trade off of user must avoid having two applications accessing the card at the same time. pkcs11-test tries to test all the features of a card to meet the standards. The Future releases of OpenSC the PIVKey ATR could be added to the driver to avoid having to modify 'opensc.conf'. |
That worked! So, based on your explanation. Is this a problem with how the cards are being configured by our team? Or is this a problem with this brand of PIV card? |
Offhand, IMHO, it's how you're team misconfigured (mis-provisioned) the card. |
I will get the ATR into the driver for next release. Also found this: https://pivkey.zendesk.com/hc/en-us/articles/208029123-PIVKey-and-OpenSC-Middleware
You did not say how you are configuring the cards, or that you have a team. Since one can buy a single card, you could be doing this for yourself. Based on your github account, looks like you work for the state of Louisiana. The card has a zipped certificate. https://shop.pivkey.com/products/C70-Series/ says: "Converged Physical & Logical Access in One Smart Card" and has 4 versions and come with or without a "pre programmed certificate" So I assume the card came with a "pre programmed certificate". It is not clear if you intend to use these for "Physical access" or "Logical access" or both. "Physical access" would include things like door locks. "Logical access" would include authentication to network services like web servers, Active Directory login, email services including signed and/or encrypted email and signed documents. Here the certificates and key are issued by a trusted CA, like a government agency or even a local Active Directory Domain. NIST PIV specifications can support both. PIVKey has added some additions and has two "issues" that differ with the NIST standards. The "pre programmed certificate" (and the 9E key) are set by the card vendor and usable for Physical Access. but could be over written, or if not need buy the cards without a pre programmed certificate, or issue the key and certificate locally. With logical access cards are usually issued by some organization or government agency as part of an ID card with the 9A authentication certificate and key for authentication, with a user ID, and a 9C signature key and certificate used for signatures with an e-mail extension and a 9D key and certificate used for encryption. The 9D key be held by a key escrow system so as to recover encrypted data. https://csrc.nist.gov/glossary/term/key_escrow_system. The 9E key and certificate are usually not used with Logical access. Depending on your needs you may want to look at the federal government approved cards at: https://www.idmanagement.gov/approved-products-list-piv/#approved-piv-cards In addition to the approved PIV cards many vendors or open source versions of PIV cards or applets are out there.one. |
Appreciate the help and knowledge tranfer! Would it helpful to you if I donated one of our new cards to the project? |
In response to Issue OpenSC#1531, PIVkey was contacted to provide the list of ATRs for curent PKvKey devices. [email protected] provided list of ATRs which included previously known cards. Some of these ATRs may be used by other card drivers. But will only be accepted by card-piv.c if the card responds to a SELECT PIV AID. On branch PIVKey-ATR Changes to be committed: modified: card-piv.c
In response to Issue #1531, PIVkey was contacted to provide the list of ATRs for curent PKvKey devices. [email protected] provided list of ATRs which included previously known cards. Some of these ATRs may be used by other card drivers. But will only be accepted by card-piv.c if the card responds to a SELECT PIV AID. On branch PIVKey-ATR Changes to be committed: modified: card-piv.c
In response to Issue OpenSC#1531, PIVkey was contacted to provide the list of ATRs for curent PKvKey devices. [email protected] provided list of ATRs which included previously known cards. Some of these ATRs may be used by other card drivers. But will only be accepted by card-piv.c if the card responds to a SELECT PIV AID. On branch PIVKey-ATR Changes to be committed: modified: card-piv.c
Problem Description
When testing PKCS #11 with your commands:
"""
You may test the PKCS#11 support of your card with
"C:\Program Files\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test
"C:\Program Files (x86)\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test
""",
I get the log errors reproduced below. (error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101))
I installed both the 32 and 64 bit msi files as directed on the install page. I am running windows 10 on an Acer Aspire7. For a card reader, I have IOGEAR GSR202.
Logs
C:\Users\Dan>"C:\Program Files (x86)\OpenSC Project\OpenSC\tools\pkcs11-tool.exe" --login --test
Using slot 0 with a present token (0x0)
Logging in to "MCGONIGLE.DANIEL.PATRICK.JR.1291".
Please enter User PIN: C_SeedRandom() and C_GenerateRandom():
seeding (C_SeedRandom) not supported
ERR: C_GenerateRandom failed: CKR_DATA_INVALID (0x20)
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
RIPEMD160: OK
Signatures (currently only for RSA)
testing key 0 (PIV AUTH key)
error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101)
Aborting.
The text was updated successfully, but these errors were encountered: