Reselect PKI-Applets after card reset #1243
Conversation
|
Yes these look reasonable for the reset case. |
|
I've added a global option to send a "keep alive" command that is to be implemented by the card driver. This should make the OpenPGP driver work even if the applet got deselected. The global card flag essentially replaces Note that this should fix concurrent access between different applications. But it does not allow accessing two different applets (card drivers) at the same time in a single application. That would require bigger refactoring, which I'll leave for future research. |
etc/opensc.conf.in
Outdated
| # name = "PIV-II"; | ||
| # driver = "piv"; | ||
| # } | ||
| # Yubikey NEO is known to have the PIV applet and the OpenPGP applet |
There was a problem hiding this comment.
It's not only Yubikey Neo anymore. This functionality is present in the recent Yubikey 4. Mine is Yubico Yubikey 4 OTP+U2F+CCID with ATR 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4.
Not sure if it matters to have this ATR in default configuration, or there should be both/all we will be able to gather.
There was a problem hiding this comment.
actually I've extracted this information from the OpenPGP driver. There are ATRs here https://github.com/Yubico/yubico-piv-tool/blob/3aaa525efc678f9bca1fb08716e282eb00536356/lib/ykpiv.h#L672-L673 and here https://ludovic.rousseau.free.fr/softwares/pcsc-tools/smartcard_list.txt. I'll integrate them later, thanks for the pointer.
etc/opensc.conf.in
Outdated
| # Default: "piv" | ||
| #driver = "openpgp"; | ||
| # | ||
| # Make sure that we can recover from different applications that may access the Yibikey |
|
Thank you for the changes. I found some minor issues that are outlined in the above comments. I tested now with Firefox (PIV-II applet) and OpenPGP (pkcs11-tool --test) and after getting back to Firefox and trying to use the card, I got an error:
After the failure, the OpenPGP is still able to pass most of the It looks like there will still be something to work on, probably in the PIV side. I am not sure if I will be able to debug this further this week. |
|
I've added a commit that should work for PIV (according to the NIST.SP.800-73-4.pdf) |
|
I tested again with the new commits and collecting the debug information, but I am still getting the same results. After accessing the OpenPGP applet from From the The non-always authenticate does not work either: There is snapshot of the last lines while doing the Sign operation. Let me know if you would need some more log data: |
|
Looks like the OpenPGP AID was still selected, so the PIV apdu fails in the OpenPGP applet. The test script I sent to @Jakuje, @frankmorgner and @mouse07410 shows that a Yubikey 4 can not handle the SELECT AID (it loses login state even when selecting the current AID) and the VERIFY Lc=empty never returns Even if they could, in the case of CKA_ALWAYS_AUTHENTICATE the VERIFY PIN and the signing command must not have any other card commands between them. A SELECT_AID or VERIFY Lc=empty are commands can not be between the VERIFY PIN and the crypto signing command. In the CKA_ALWAYS_AUTHENTICATE case the best approach is to make sure the VERIFY PIN and the signing command are in the same transaction. But the way OpenSC is setup, the VERIFY PIN is in one transaction and the the signing command is in a separate command. (This would also keep other processes from interfering at this point too.) I started working on this and it gets complicated, because the framework-pkcs11. c needs to pass this info in to the pkcs15 layer so an sc_lock is done at the verify and unlocked after the signing command, or if this never happens the lock need to be released. I see that the sign command failed with So in my option the only way to address this to make sure every transaction selects the AID as the first command. And for the CKA_ALWAYS_AUTHENTICATE the vrify must be in the same transaction. As users want to use multiple applications on the same card this gets much more complicated. Look at the CAC card which may also have a PIV application. card-cac.c is actually using multiple AID internally, |
|
I've implemented a "keep alive" command in the PIV driver based on the CHUI. @Jakuje This command should have preceded the error, which is not shown in your log. Does this work; is the re-applet selected? (It may also be a problem with parsing the flag from However, I did not have the limitation in mind that EXTERNAL AUTHENTICATE must immediately follow the VERIFY. If deselection is possible, we, indeed, need to put both commands into a single transaction. NIST.IR.7863.pdf has a section 4.2 Explicit User Action with PIN Caching, which says that the application is allowed to cache the PIN if there are other mechanisms in place to enforce "PIN always". These are already implemented in OpenSC, I think. So what I'd like to suggest is that the PIV driver caches the PIN and performs an additional verification right before EXTERNAL AUTHENTICATE if needed. So OpenSC may verify the PIN twice to the card, but the user still sees only a single prompt. |
I used the master + this branch and I copied the opensc.conf to Searching for CHUI, I am getting several failures like this (even the first call ends this way): |
|
Only problem with PIN caching is a PIN PAD reader can not be used without the user having to type the pin twice. Card with builtin readers like Yubico don't have a PIN PAD reader so ti would work for Yubikey. For a PIN PAD reader, could the verify be postponed and be part of the transaction that does the sign command? For a non PIN PAD reader, could the pin be prompted for as it does today, and held (cached) to do the verify just before the sign operation? Or make sure the VERIFY with or without a PIN PAD reader, starts a transaction that is only completed after the sign operation. Sort of what I proposed. |
|
What currently worked for me:
Need to test more: repeat the above steps several times. Preliminary conclusion: PIV driver does not re-select the applet.
That would be nice. |
|
@Jakuje looks like the PIV applet does not have a CHUI. thus the file not found. The code uses this to generate a serial number using either the FASN-N in teh CHUI for gov issued cards, or the UUID in the CHUI. (Microsoft Windows driver expects a CHUI.) The yubico-piv-tool can generate a CHUI for you . The OpenSC can write a CHUI if you have one in a file. |
|
If you are interested, I was working on having framework.c signal lower levels so verify PIN wold so a lock and sent that when the next command is done, it could release the lock. This is not finished but if you want it might be a start. |
|
The patch https://github.com/OpenSC/OpenSC/files/1656931/verify_CKA_ALWAYS_AUTHENTIC.diff.txt doesn't apply cleanly on top of this PR. :-( |
|
I've added a new commit that uses GENERAL AUTHENTICATE instead of CHUI, that might work, too...
I don't think we need to catch all corner cases. If you want to, we can disable the detection mechanism with a PIN pad reader.
Yes, that would be possible, but card-dependant and a lot of work. If people should use those tokens, it's time for some corporate engagement. Up to now it seemed that Yubiko is content with what we've got... |
|
@dengert in your patch you could also try to call |
For a token to be a useful PIV, it has to have CHUID. YubiKey tokens come without it, but one can (and should) provision CHUID via
I agree. And as I said above - I'm not aware of any card with more than one applet that also supports PIN PAD reader. And the only multi-applet token I know of is Yubikey (NEO and 4). |
|
Tried again this PR with the current master.
@Jakuje I don't know how to use When I try to do anything with When I try the current master without this PR, it works: |
|
Rather then looking at the CHUI or doing a general authenticate, using a VERIFY Lc=empty for P2=80 could be used on Yubikey to test what AID is selected. PIV can uses P2=80 for the normal PIV PIN, or p2=00 for the global pin. OpenPGP appears to use only P2=81, 82 or 83. The output of that script I sent the 3 of you shows how the responses differs depending on the which AID is active when Sending: 00 A4 04 00 06 D2 76 00 01 24 01 00 (Select OpenPGP AID) Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 (Select PIV AID) From the other test in that output I set you: So by just using the But this only works between these 2 applications because they don't use the same P2. ANd only on Yubikey. It is not general solution. (A CAC card may have a PIV application too, and may have the problems distinguishing which application is active.) If Yubico ever fixes the command to returns Not sure what the bad command does to the OpenPGP login state. Hopefully nothing. |
@dengert could you please re-send this script? Ideally - to my email, but you can post it here too if you wish. |
As you pointed out, that's true for this token. But command and response codes are standardized by ISO/IEC, there's only little deviation. The interpretation of GENERAL AUTHENTICATE, however, is proprietary (specific to PIV), so it's a better indicator. |
|
@mouse07410 thanks for the pointer. I probably skipped the part of initializing CHUID. I will give it one more shot later. I was using the following command to test the OpenPGP applet with There is some problem if you try to load pkcs11 module into pkcs11-tool of different version for some reason, if I remember well. |
|
The PIV interpretation of GENERAL AUTHENTICATE, is not proprietary. NIST 800-73 appears to be following ISO/IEC 7816-4:2013(E) Section So not only may it be a time consuming command to run, it may have unexpected consequences. In general we would like to solve the problem of any combination of applications on any card, and our application drivers need to detect if their application is running and what is the security status without causing any additional interference. But today, without PCSC help (tracking any SELECT AID commands) and no common ISO command to tell what is the active application we have to resort to other tricks. Today we are trying to address two applications: PIV and OpenPGP running on the Yubikey. The ATR of Yubico devices say it is from Yubico and a version number can be read too. So any driver can detect if it using a Yubico card. The PIV sets the card type to SC_CARD_TYPE_PIV_II_NEO or SC_CARD_TYPE_PIV_II_YUBIKEY4. The OpenPGP could do something similar to handle Yuibico as special. We are also hindered by Yubico's broken SELECT AID handling, (It loses the security state even when selecting the active application) and its broken VERIFY Lc=empty (Never returns '9000'). That is the question at hand. Because we are dealing with only PIV and OpenPGP on Yubikey I favor the use of the VERIFY Lc=empty to test for PIV pin state, in both PIV and OpenPGP drivers. (This may only work for the two applications, so if Yubico adds another application, we may have to add more tests.) So we need to do special handling for any Yubico devices. The PIV driver currently does some of this. See @mouse07410 has been adding a dummy image file as it is a protected object and is tested by the @Jakuje Have you added a dummy Image file? If not the PIV driver can not tell the login state. For the general case what is still missing is how to tell what application is currently active. Until that can be solved I think we are stuck with solving specific combinations of applications on specific card. And we need to look at CAC and PIV on CAC cards. See #1164 |
I agree. However, the Data Objects in the Dynamic Authentication Template, especially the one to retrieve a challenge (with a context specific tag), is not defined by any other standard that I know. Hence, it is specific to PIV. (I should not have used the word "proprietary", because it's simply undefined, sorry.)
If using multiple on-card-application is a valid use case and CHUI is not available and VERIFY looks exactly as defined in ISO 7816-4, then I think GENERAL AUTHENTICATE is the only choice, even if it may be slower. What kind of unexpected consequences are you thinking of? The command is already used today as generic mechanism to gather random data... My PR should not introduce unnecessary selections of any applet and it should be generic enough, that it doesn't depend on any property of the Yubikey. The problem with the |
|
@mouse07410 Here is the test script. It uses opensc-tool -c default was chosen because it does not introduce any commands from the current PIV or OpenPGP code. To run: The Muscle AID is used to simulate some interference from some other process while trying to set an AID that is not supported by the card. I real PIV card ignores the command. The Yubikey does not. |
|
You said If PIV application is active it will respond with If OpenPGP application is active it will respond with The test script in #1243 (comment) We are trying to address OpenPGP vs PIV on Yubikey. |
|
Modifying the script to add: and Shows: If PIV is active 00 87 00 9B 04 7C 02 81 00 00 returns 9000 20 ms So you can not tell if OpenPGP is active or not. A Yubikey bug that selecting an AID not on the card leaves no AID selected could be the cause. This type of interference could pop up from some other process that was trying to use a different card and causes interference with the Yubikey. And opensc-debug.log shows when it works it takes 20ms, and when fails 11 ms |
|
@frankmorgner I think this PR is OK. If we're all in agreement, perhaps this PR could be merged, so we can proceed with other improvements like #1256? |
|
I reread this PR several times, but I was not able to get back to this because of all the conferences circus of recent two weeks. The changes look good. I especially like the new naming of PIV cards :) Also the progress with the way of detection of the selected applet is a good way to go if it will actually work. But it was not the case for me unfortunately. Can you recommend some test case for this? I was trying with openpgp card in |
|
You can connect with |
|
Hmm .. both the private keys (signature, authentication) on openpgp applet have |
|
OK, I just put together simple program that is doing signatures every 10 seconds with the OpenPGP applet and if I start interfering with Correct me, if I am testing something else than you or if there is some trick that needs to be configured so the
I would expect that both of the sessions should work, if the |
|
Going through the testing again, I've discovered some more problems (see #1264). Anyway, these problems should not touch your use case. Have you updated your |
|
Note that |
|
I was updating the Then running the repetitive signatures (fisrt two are not interrupted, third one is): And before the last attempt I used the PIV driver: This is making it fail with current master (with keepalive PR merged).
What you mean by this? The other process deselected the applet. But was not this what we were trying to solve? Or we are solving the deselection only from single thread/process? |
|
The PIV-II driver does not use the keep-alive. You need #1256 which is its version of all the interference and detection of AIDs. It does its own version of keep alive based on the ATR history bytes. |
|
Passing I didn't notice that your test program is performing |
|
Sigh ... I missed that part. It is indeed very confusing that setting environment variables prevent parsing the whole configuration file. Do you think, there is anything we can do about it? For example parse everything except the drivers selection in that file? Do we have an issue for that? If not, I will open one. Thanks for the pointers. I will try that without |
|
Yes, it's confusing; I've been in that dead end, too. Feel free to open an issue. |
|
Ok, now I finally have the Yubikey with me and I performed the same test as in previous comments with more surprising results. While the Only after that I was able to get the result of the What do you think? Attaching the debug log from the |
|
looking at https://github.com/OpenSC/OpenSC/files/1710677/opensc-debug.log It then shows the '4F' object returned with 16 bytes, 190 But the lock was obtained, its that (TODO need to look closer at sc_lock to see if *_card_reader_lock_obtained returns Since the Try adding to openpgp_card_reader_obtained: |
|
@frankmorgner Thank you for having a look into that. Yes, with #1264 I can see it finally works as expected. Good job! |
Experimental: PKCS#11 Support for Multiple Applications on One Card Prior to this modification there has been a 1-to-1 relationship between the list of readers returned by PCSC and a card driver. With this mod each reader returned by PCSC may have more then one card driver. This gives each card driver its own PCSC handle and lock, and allows OpenSC PKCS#11 to support more then one applet on a card For example OpenPGP and PIV or PIV and CAC. sc_reader_t now has name (as seen by users and applications) and pname the name used by PCSC. when a card is first found, the name and pname are the for the first or only card driver. if another card driver can support this card, its reader name with be teh pname followed by [N] where N starts with 1. reader or a cloned/virtual reader can each have 4 virtual slots. Minimal tseting has been done. No testing with threads. It may need some mutexs as weach card driver gets its oen PCSP lock and pkcs11 session. So this code depends on OpenSC#1243 and OpenSC#1256 It is a change from current OpenSC, and maybe should be off by default and turned on in opensc.conf. It is only active with PCSC whe used from PKCS#11. On branch pkcs11-multi-application Changes to be committed: modified: src/libopensc/card.c modified: src/libopensc/ctx.c modified: src/libopensc/libopensc.exports modified: src/libopensc/opensc.h modified: src/libopensc/reader-pcsc.c modified: src/pkcs11/slot.c
PIV detection of AID using Discovery Object before doing select AID - Partial #1243
PKI-Applets may not be active if the card has been reset or unpowered.
The SELECT command used to activate the applet, is identical to the one
used during card matching or initialization.
Checklist