PIV II regression: Unable to decipher (Security status not satisfied) #1292
Projects
Comments
|
Unfortunately I dont have good access till next week. No access to my test
environment.
Do you have to enter the pin the same in both?are you caching the pin?
There is one change in the commits to remove some code that was looking at
the login state of the card. It removed the verify Lc=0 and removed code to
set the "logged_in" state. Long running programs like FF and TB use this.
The security status not satisfied has to do with the verify.
If you specify only the piv driver in opensc.conf does it work?
Are there any other programs running that could be accessing the card?
Are the versions of firefox and thundbird the same in both cases?
The debug logs dont show when the pin was verified to see what may have
happend. Other processes may have interfered with the state.
…On Mar 20, 2018 10:14 AM, "David Ward" ***@***.***> wrote:
#1256 <#1256> introduced a
regression where I am no longer able to decrypt e-mails in Thunderbird or
access PKI-enabled websites in Firefox using my PIV II card. My PIN is
still accepted, and I am still able to display objects/certificates on the
card using pkcs11-tool. This problem is not resolved with either the
current master branch, or with #1249
<#1249> applied on top of that.
I am using pcsc-lite 1.8.23 and pcsc-lite-ccid 1.4.29 under RHEL 7.4, on a
Dell Latitude E7450, using its integrated smart card reader (via the
Broadcom 5880 USH).
I've collected the relevant section from the working debug log
<https://gist.github.com/dpward/646439e9e32c0fa9424abeb7da6f2c3e#file-opensc-debug-1d4f59e-log>
with commit 1d4f59e
<1d4f59e>
(immediately before this PR was merged), and the non-working debug log
<https://gist.github.com/dpward/646439e9e32c0fa9424abeb7da6f2c3e#file-opensc-debug-7ca16a7-log>
with commit 7ca16a7
<7ca16a7>
(the merge commit for this PR). ADPU contents are removed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1292>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA00McY-1mkEytNo1fF07vHHtZhY5zZMks5tgTj5gaJpZM4SyTlY>
.
|
|
I can look at it after the 28, but cant do anything this week. I only have
phone for internet.
Spy traces of FF and TB would be helpful to see what the PKCS is doing when
checking status in both before and after cases.
A pcsc trace would also show if other process is interferring too.
…On Mar 20, 2018 1:07 PM, "Mouse" ***@***.***> wrote:
@dengert <https://github.com/dengert> can you create a patch (on top of
#1256 <#1256> aka master) that adds
that "verify" code back? I'd test it, as I confirm the problem with Firefox
60.
Unless that coffee would interfere with multi-applet functionality? In
which case we need to figure something else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MdC2kTjKN9a22iI0MfmjJNrJ8n3uks5tgWGNgaJpZM4SyTlY>
.
|
Makes sense - but I've been unable to obtain SPY traces from FF because when I try to tell FF to use |
|
This is the process status of FF that hung up and became unresponsive when I removed Yubikey and inserted CAC (while FF was running): Subsequent removal of CAC does not help - FF is hung for good. |
|
Here's the complete FF state dump (in case it can be of use to anybody): Update |
|
Is that FF failure with the development version?
Is that related to this issue?
My eyes are not what they used to be. Is nor readable on my phone.
…On Mar 20, 2018 2:36 PM, "Mouse" ***@***.***> wrote:
Here's the complete FF state dump (in case it can be of use to anybody):
firefox_2018-03-20-173131_523433-mitll.hang.txt
<https://github.com/OpenSC/OpenSC/files/1831294/firefox_2018-03-20-173131_523433-mitll.hang.txt>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MY-V9LyNVGzbeIABVYbiU9AhlVzEks5tgXZUgaJpZM4SyTlY>
.
|
|
The problem manifests itself with all the recent versions of Firefox. I usually use the Dev Edition because the production release of Firefox blocks extensions that aren't signed by Mozilla, and that's unacceptable to us. |
|
Also note that I'm running FF on Mac. The original reporter of this issue appears to be using Linux. |
|
The issue I am reporting is not related to Firefox, Thunderbird, or NSS (that's just where I happened to notice the problem initially; I am not trying to duplicate #1278 here). I can produce identical logs to the ones I posted earlier by using command line tools to decrypt data with my PIV II card: First I ran all commands successfully using OpenSC commit 1d4f59e; I examined the contents of the resulting file The sections of the two logs that I posted before for comparison have different timestamps and memory addresses, but otherwise are identical when running these commands as when running Thunderbird. |
|
I just tested the decryption with master and official PIV test keys and it seems to go fine for me. Can you verify you can reproduce the issue also with the pkcs11-tool as described in the following wiki: https://github.com/OpenSC/OpenSC/wiki/Using-pkcs11-tool-and-OpenSSL What key are you using for decryption? Is there some other difference in the debug logs before this one, which might be important? |
|
Is your PIV card also a CAC card?
Is it NIST approved or a PIV like card where the vendor says they support
PIV?
We have seen some differences.
Is it a government issued card?
Can you send the ATR?
In all the cases does it prompt for the pin as expected?
In the the debug logs I am interested in
All the APDU's between the pin verify and the decrypt
Also any line with logged_in in it.
I am looking for any command that might reset the security status.
Akso line near the top that shows disconnect=
…On Mar 21, 2018 8:22 AM, "Jakub Jelen" ***@***.***> wrote:
I just tested the decryption with master and official PIV test keys and it
seems to go fine for me. Can you verify you can reproduce the issue also
with the pkcs11-tool as described in the following wiki:
https://github.com/OpenSC/OpenSC/wiki/Using-pkcs11-tool-and-OpenSSL
What key are you using for decryption? Is there some other difference in
the debug logs before this one, which might be important?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MQ6uHaMHfWbnRHclJHuxg99TyBlPks5tgnAjgaJpZM4SyTlY>
.
|
|
I think we all confirmed that there is a problem with Firefox hanging up when a hardware token (aka smartcard) gets involved. However I cannot confirm what @dpward reported, because both CMS (via openssl + libp11) and pkcs11-tool worked flawlessly for me for PIV and CAC tokens (in PIV mode). |
|
Mouse and Dave. Do you know each other? Looks like you should.
What I am looking for from Dave is to see if his card is not standard. And
last commit causes the security status to be lost and the code does not
detect it is lost.
Or there is some other process causing interference that is not detected by
last commit to card-piv.c
…On Wed, Mar 21, 2018, 10:41 AM Mouse ***@***.***> wrote:
I think we all confirmed that there is a problem with Firefox hanging up
when a hardware token (aka smartcard) gets involved.
However I cannot confirm what @dpward <https://github.com/dpward>
reported, because both CMS (via openssl + libp11) and pkcs11-tool worked
flawlessly for me for PIV and CAC tokens (in PIV mode).
$ src/pkcs11ff.sh
p11tool --export "pkcs11:manufacturer=piv_II;id=%03;object=Certificate%20for%20Key%20Management;type=cert" > /tmp/piv-22267-cert.pem
Extracted certificate in PEM format into /tmp/piv-22267-cert.pem
openssl cms -encrypt -aes256 -text -in /etc/pf.conf -out /tmp/cms.22267 -to ***@***.*** -subject test /tmp/piv-22267-cert.pem
Encrypted file /etc/pf.conf into CMS message /tmp/cms.22267 using cert /tmp/piv-22267-cert.pem
openssl cms -decrypt -aes256 -engine pkcs11 -keyform engine -text -in /tmp/cms.22267 -out /tmp/cms-decr.22267 -inkey "pkcs11:manufacturer=piv_II;id=%03;type=private" -recip /tmp/piv-22267-cert.pem
engine "pkcs11" set.
Enter PKCS#11 token PIN for <my token ID>:
p11_pkey.c:400 pkcs11_try_pkey_rsa_decrypt() out=0x7ff7d57095b0 *outlen=256 in=0x7ff7d5709450 inlen=256
p11_pkey.c:443 padding=CKM_RSA_PKCS
p11_pkey.c:470 C_DecryptInit or C_Decrypt rv=112
Decrypted CMS data into /tmp/cms-decr.22267 successfully, comparing with the original...
Original and decrypted files match
$
$ pkcs11-rsa-encr-demo2
Generate a random data file (1000 bytes), Base64-encoded...
openssl rand -base64 -out /tmp/derive.21480.text 1000
Generated
key: 32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be
iv: 794764ff6cb839d60b09407c41984e28
Encrypt file /tmp/derive.21480.text with this key and IV...
openssl enc -aes-256-cfb -a -e -in /tmp/derive.21480.text -out /tmp/derive.21480.text.enc -K 32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be -iv 794764ff6cb839d60b09407c41984e28
Encrypting this random symmetric key to token RSA KEY MAN key...
echo 32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be | xxd -r -p -c 200 | openssl rsautl -engine pkcs11 -keyform engine -encrypt -pubin -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -pkcs -out /tmp/derive.21480.key.enc
engine "pkcs11" set.
Decrypting the symmetric key on the token...
openssl rsautl -engine pkcs11 -keyform engine -decrypt -inkey "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -pkcs -in /tmp/derive.21480.key.enc | xxd -p -c 200
engine "pkcs11" set.
Enter PKCS#11 token PIN for <my token ID>:
Decrypt file /tmp/derive.21480.text.enc with this key and IV...
openssl enc -aes-256-cfb -a -d -in /tmp/derive.21480.text.enc -out /tmp/derive.21480.text.dec -K 32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be -iv 794764ff6cb839d60b09407c41984e28
KEY1="32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be"
KEY2="32c5295876e39e2734d0cc8dcd436310395daea73dcc2dbdcd02178a5ab402be"
Original and decrypted keys match
Original and decrypted files match
$
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MdhcEMJ4MiatRF1Mp8HpKym7xubHks5tgpCrgaJpZM4SyTlY>
.
|
;-) Yeah, looks like we should. ;-) I'll check with Dave.
I have another circumstantial evidence that this is the case: sometimes my token sits in the reader for a long time (after being logged in/unlocked). Then if I try to perform an operation that OS wants to authenticate (using smartcard), it pops up a confirmation window - but does not prompt me for a PIN. When I click on the "OK" button in that window - the operation is rejected. I conjecture that the card is not considered unlocked at that time, but the software (MacOS and probably OpenSC & tokend) still think it's unlocked, so they don't bother to prompt for the PIN, just ask for consent. If at this point I remove and re-insert the card, I am prompted for my PIN, and everything is fine. |
This is separate issue, which is caused by a bug in NSS and latest pre-release of Firefox. I don't think it has anything to do with this issue, since this issue was already isolated to latest commits in OpenSC. To confirm that, we should verify that we can reproduce the issue without Firefox, but I assume it will be the case. |
OK.
I am unable to reproduce it on MacOS with OpenSSL-1.0.2n, and current Github master of libp11 & OpenSC. The problem I have is different - see my previous post. And the other problem - after the smarcard is removed, often the system "thinks" that the card is still there, and, e.g., refuses to promote me for a password to unlock the screensaver, but insists on getting a PIN. As I said, my suspicion falls on the OpenSSL and libp11 versions that RHEL 7 comes with. |
|
@mouse07410 I updated to using libp11 / pkcs11_engine from the current master branch, but there was no change in behavior. RHEL 7.4 has OpenSSL 1.0.2k which I am using. @Jakuje Yes, I reproduced this with Using OpenSC commit 1d4f59e: But then using OpenSC commit 7ca16a7: (I'm working on posting sanitized logs from this that go farther back than where my other ones start, but the login is successful and then the call to @dengert I ran these commands at runlevel 2 to avoid any other processes that might try to access the smart card (including gdm). On RHEL 7, |
|
I dont see any pin parameter or pin prompts in either case. Can I assume
you removed them?
Can you grep for logged_in in the opensc debug logs in the pkcs11-tool
decrypt commands.
Look at commit efe7eb5 part of the 1256 PR.
Look to see if the discovery useless is set for your card. Also look at
last part on commit that removed test of login state. Maybe if this was
added back it might work.
Sorry I cant do much while I am on vacation using only phone.
On Mar 22, 2018 6:10 AM, "David Ward" <[email protected]> wrote:
@mouse07410 <https://github.com/mouse07410> I updated to using libp11 /
pkcs11_engine from the current master branch, but there was no change in
behavior. RHEL 7.4 has OpenSSL 1.0.2k which I am using.
@Jakuje <https://github.com/jakuje> Yes, I reproduced this with pkcs11-tool.
Using OpenSC commit 1d4f59e
<1d4f59e>
:
$ dd if=/dev/urandom of=data bs=245 count=1
$ pkcs11-tool --login --read-object --id 03 --type cert --output-file
piv-ii-key-management.crt
Using slot 0 with a present token (0x0)
$ openssl x509 -inform DER -in piv-ii-key-management.crt -noout
-pubkey > piv-ii-key-management.pub
$ openssl rsautl -encrypt -inkey piv-ii-key-management.pub -pubin -in
data -out data.crypt
$ pkcs11-tool --login --decrypt --mechanism RSA-PKCS --id 03
--input-file data.crypt --output-file data.decrypt
Using slot 0 with a present token (0x0)
Using decrypt algorithm RSA-PKCS
$ diff -s data data.decrypt
Files data and data.decrypt are identical
$ rm -f data.decrypt
But then using OpenSC commit 7ca16a7
<7ca16a7>
:
$ pkcs11-tool --login --decrypt --mechanism RSA-PKCS --id 03
--input-file data.crypt --output-file data.decrypt
Using slot 0 with a present token (0x0)
Using decrypt algorithm RSA-PKCS
error: PKCS11 function C_Decrypt failed: rv = CKR_USER_NOT_LOGGED_IN (0x101)
Aborting.
@dengert <https://github.com/dengert> I ran these commands at runlevel 2 to
avoid any other processes that might try to access the smart card
(including gdm). On RHEL 7, pcscd is started by systemd using socket
activation. For both sets of commands above, I restarted the system first
and verified that pcscd was not running.
(working on posted sanitized logs)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00Mbf55tYL_aqjV_8DUd0TmOB9l0ixks5tg6KqgaJpZM4SyTlY>
.
|
|
@dengert Yes I removed the login prompts. After login (i.e. the VERIFY command/response in the APDUs), the logs show, using OpenSC commit 1d4f59e: This is before Understand you're on vacation — I actually need to put this on hold on my end for a couple of days as well, but I'll come back to your suggestions regarding the specific commits in the PR. |
|
After making sure the current OpenSC master and libp11 master are installed, and after making sure p11-kit module points at the right I got similar results, using |
|
@dengert Yes, commit efe7eb5 seems to be the culprit. Every time that This additional SELECT command is happening in between the VERIFY command (where it logs in using the PIN) and the GENERAL AUTHENTICATE command (where it deciphers a block of data) which were back-to-back before this change. This seems to be causing the GENERAL AUTHENTICATE command to fail now. @mouse07410 I updated to OpenSSL 1.0.2o just to be certain, but there were no differences when I did that. It seems like you may have built new versions of software in /usr/local and kept the OS version in /usr. Is there any chance your tests might unintentionally be utilizing the older version somehow? I rebuilt OpenSC, PCSC Lite, CCID, libp11, and OpenSSL as RPM packages which completely replace the versions distributed with the OS. |
First - good finding! But it should not matter at all for a key without
I will double-check, but I strongly doubt that. In fact, my tests were failing until I made sure they are using the new versions. On CentOS 7 the older version refuses to do anything useful with the token for me. Update @dpward I've checked - and indeed I'm using the current software that I installed. One thing though: I run CentOS 7 under VMware Fusion (aka virtual). If you run bare-metal, other things could be in play.
|
|
Disregard this comment. |
|
In response to #1292 (comment) NIST 8-00-73-3 Part 2 Section 3.1.1 SELECT Card Command says: "If the currently selected application is the PIV Card Application when the SELECT command is given and the AID in the data field of the SELECT command is either the AID of the PIV Card Application or the right-truncated version thereof, then the PIV Card Application shall continue to be the currently selected card application and the setting of all security status indicators in the PIV Card Application shall be unchanged." So doing a Select AID of the PIV should not change the card state if your card is a compliant PIV card. Do you have the full opensc-debug log from a failing: Please obfuscate the PIN and any certificate data you may not want to expose. |
|
@dengert Here are the full opensc-debug logs with the PIN, token name, and certificate/object contents redacted (thanks for bearing with me to get these posted): opensc-debug-1d4f59e.log (working, before PR) To @mouse07410's point I am not running this in a virtualized environment, which may explain the different behavior than what he has observed. |
|
I don't see the ATR in the trace. This would show what type of card you have. Its not a NEO, or Yubikey, ot a PIV card with the OIV AID in the ATR, so to the code is calling it a generic PIV card, and the NIST 800-73 says the default AID is to be the PIV AID, but the failure of the get data for the Discovery object implies it is not the default. But the PIV AID can be selected, and it can read certificates and CHUD It appears to be an older PIV applet, as it should have returned file not found when trying to read the the discovery object Which was added in 800-73-3. It looks like you forced the driver to be PIV. So it should not have had interference from other card driver select routines. UNLESS you are using the p11kit that may load other modules. Are you? If you could send the ATR. that would help. Doing a SELECT PIV AID should never reset the security status. If it does then we will have to make some mods to not do a SELECT PIV AID unless some command fails, which on your card appears to lose the security state. The whole point of #1256 was to handle interference, and depend on a SELECT PIV AID to always keep the security state. Later or Monday, I would like to send you a script to do some simple tests on you card. |
|
@dengert The ATR is 3b:7a:18:00:00:73:66:74:65:20:63:64:31:34:34. (You previously commented about this ATR in the PR. I'm not sure if this document posted by NIST pertaining to this card's applet might be helpful.) Yes, p11-kit is installed. However to test interference from other modules, I temporarily removed all of the files from /usr/share/p11-kit/modules; afterwards the command |
The document linked in my previous comment suggests that the applet in this card only meets SP 800-73-1. |
|
The ATR and document are helpful. It says its PIV alplet is based on 800-73-1 which also says: It does not appear to support this requirement. I can look at using the historic bytes and another CI_* flag, so that the select aid is not done for every pcsc_lock for this type of card. It may still lose state for interference, but will work like the previous version. |
|
@mouse07410 you asked: "On an unrelated issue - can you send me/post a script to logout the token ("UNVERIFY")? NIST 800-73-4 defines a logout using the verify: But earlier versions of 800-73 do not have a logout. You could modify the script I sent a few months ago to test if your card can do the above. The closest thing would be with a pcsc reset or power off the reader. This in effect defeats the the disconnect="leave"; option. So you could have a program with a special opensc.conf with "reset" But if other applications have the pin cached, they could do a verify with the cached pin. |
I see, thanks! Will experiment with
That's the script I'm looking for. Update
Yes I realize that. |
|
You maybe able to just use opensc-tool: If the above does not work, you might be able to use the -s option to select some other AID. |
|
Alas, neither Probably need to select some other AID. Could you please show an example? |
|
Add a -v -v -v to the command, then look at the opensc-debug.log The reset should have worked. But other applications like tokend get notified that the card was reset. Tokend may then take action reconnect, and if has a cached pin, it may do a verify. Problem with using another AID, is NIST 800-73 says selecting an AID not on the card will have no effect on the PIV status. So using a different AID only works on cards with more then one applet. Does it have openpgp? look at the test-aid-ef.sh I sent a few months ago. It uses opensc-tool -c default to issue a set of -s options each of which is a APDU, data and and optional Le value. Each of the entries in the case statement try and issue a set of commands to test select AID, Verify, and to thest the login state after combinations of commands. |
|
fixed with 0911982 |
|
This regression seems not fixed completely. |
|
@orignal You may be seeing a different problem then than this issue. Can you send an opensc-debug.log of the failure? Or add -v -v -v to the pkcs15-crypt command. |
|
And open a new issue.
…On Sun, Jul 8, 2018, 2:07 PM Doug Engert ***@***.***> wrote:
@orignal <https://github.com/orignal> You may be seeing a different
problem then than this issue. Can you send an opensc-debug.log of the
failure? Or add -v -v -v to the pkcs15-crypt command.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1292 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA00MeD3DfhxrZ1ea43fgFt-udDV6idvks5uEliIgaJpZM4SyTlY>
.
|
|
Yubikey 4 PIV with pkcs15-crypt works with OpenSC master. But building from tag 0.18.0 eb60481 it fails. Somehow it matches a German ID card (neuer Personalausweis, nPA) After that it gets messy, trying to bind to the pkcs15 layer. @orignal |
|
looks like commit ae31408 fixed the problem of iso7816.c not calling sc_check_sw.which was added to master after 0.18.0 was released on 2018-05-16 The code that called this bad routine was 90a5b26 on 2018-04-18 between 0.18.0-rc1 and -0.18.0-rc2 @frankmorgner Time for a 0.18.1. |
|
@dengert forgot to say, I sign by ECDSA, not RSA. |
|
I just tested Yubikey NEO (ECCP256) and Yubikey 4 (ECCP384) keys with the current master (using Yubikey 4: and Yubikey NEO: Yubikey 4 using |
|
I can confirm it works fine with master after I have pulled the recent changes. |
|
Hi, The detailed output of pkcs15-crypt (-vvv) shows this after the PIN prompt - any suggestions would be more than welcome. ...more of the same... |
|
Unfortunately I don't have access to my test environment this week. The key 02 is the signing key that requires the PIN verify to be sent to the card just before the crypto operation. If not you get the security state not satisfied. Here are some things to look at or try: The debug trace does not show that you are running 0.19.0 One of the first lines printed. 0.19.0 has a minimal opensc.conf file. If you had some local changes add them back in. You can add to opensc.conf "ignore_user_consent" (check the example opensc.conf for details.) This allows OpenSC to cache the PIN and to handle cases like this. Is there any other application running that might also access the card and cause the security state to be reset. The debug output only shows OpenSC. Try adding the PIN to the command line. Can you try using the github master version of OpenSC. The problem may have been fixed. This could be a problem with pkcs15-crypt.c. Anyone else with a PIV type card have problems with pkcs15-crypt and the signing key? |
|
Thanks a lot - it turns out the opensc port on FreeBSD is "broken" in the sense that it will overwrite an existing configuration on reinstall. This is, of course, unforgivable - nearly as bad as me not checking this before complaining here :) All is good now; the config is now the bare minimum of the following: I know - the use_pin_caching line is redundant but I kept it for clarity.. |
|
@ltning or anyone else, Can you test this: pkcs15-crypt.diff.txt with the default opensc.conf (i.e. no ignore_user_consent) |
dengert
added a commit
to dengert/OpenSC
that referenced
this issue
Nov 9, 2018
This fixes problem as stated in: OpenSC#1292 (comment) pkcs15-crypt.c will treat keys with user_consent like PKCS#11 would. SC_AC_CONTEXT_SPECIFIC is set when doing a verify so a card driver can take action if needed. card-piv.c is currently the only driver doing so. It uses this to hold the card lock so both the VERIFY and following crypto operations are in the same transaction. The card enfirces this restriction. Without this additional APDUs may be sent before every transaction to test that the expected applet is selected. Unlike the circumvention of using ignore_user_consent=true and pin caching this modification allows a pin pad reader to be used for keys requiring user_consent. On branch pkcs15-context-specific Changes to be committed: modified: pkcs15-crypt.c
dengert
added a commit
to dengert/OpenSC
that referenced
this issue
Nov 9, 2018
This fixes problem as stated in: OpenSC#1292 (comment) pkcs15-crypt.c will treat keys with user_consent like PKCS#11 would. SC_AC_CONTEXT_SPECIFIC is set when doing a verify so a card driver can take action if needed. card-piv.c is currently the only driver doing so. It uses this to hold the card lock so both the VERIFY and following crypto operations are in the same transaction. The card enforces this restriction. Without this additional APDUs may be sent before every transaction to test that the expected applet is selected. Unlike the circumvention of using ignore_user_consent=true and pin caching this modification allows a pin pad reader to be used for keys requiring user_consent. On branch pkcs15-context-specific Changes to be committed: modified: pkcs15-crypt.c
frankmorgner
pushed a commit
that referenced
this issue
Nov 20, 2018
This fixes problem as stated in: #1292 (comment) pkcs15-crypt.c will treat keys with user_consent like PKCS#11 would. SC_AC_CONTEXT_SPECIFIC is set when doing a verify so a card driver can take action if needed. card-piv.c is currently the only driver doing so. It uses this to hold the card lock so both the VERIFY and following crypto operations are in the same transaction. The card enforces this restriction. Without this additional APDUs may be sent before every transaction to test that the expected applet is selected. Unlike the circumvention of using ignore_user_consent=true and pin caching this modification allows a pin pad reader to be used for keys requiring user_consent. On branch pkcs15-context-specific Changes to be committed: modified: pkcs15-crypt.c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#1256 introduced a regression where I am no longer able to decrypt e-mails in Thunderbird or access PKI-enabled websites in Firefox using my PIV II card. My PIN is still accepted, and I am still able to display objects/certificates on the card using
pkcs11-tool.I am using pcsc-lite 1.8.23 and pcsc-lite-ccid 1.4.29 under RHEL 7.4, on a Dell Latitude E7450, using its integrated smart card reader (via the Broadcom 5880 USH).
I've collected the relevant section from the working debug log with commit 1d4f59e (immediately before this PR was merged), and the non-working debug log with commit 7ca16a7 (the merge commit for this PR). APDU contents are removed.
The text was updated successfully, but these errors were encountered: