Opensc: Yubikey is known to have the PIV applet and the OpenPGP applet. OpenSC can handle both to access keys and certificates, but only one at a time.

Created on 6 Nov 2019  Â·  29Comments  Â·  Source: OpenSC/OpenSC

Problem Description

Yubikey FIPS(and others) has a PIV applet and an openPGP applet, but cannot be used simultaneously. For historical reasons, it is easier to use the openpgp module for ssh authentication because it emulates the ssh-agent. OpenVPN, on the other hand, can work with PKCS11 (PIV).
You have both functionalities in one key at hand, but do not reach. How then do you want to open a VPN connection with one hardware key and then log in via SSH? It's OK: every time you pull out and plug the key into the usb again. But the connection is being re-established, so the VPN will timeout and SSH will be disconnected :-)

Proposed Resolution

If access to a key is through one OpenSC (PSCS) component, I do not understand why both OpenPGP and PKCS11 cannot be used at the same time. I have read something about security reasons, and even if the solution can be difficult, I think it is worth it. Please, you can pay attention to this issue.

Steps to reproduce

$ openvpn --config xxx.ovpn { use pkcs11-id xxxxxxxxx}
{possible way to do works is remove and plug in token}
$ gpg-connect-agent /bye {use putty for login to remote server - key is unavailable}
timeout vpn connection
ssh connection closed
Reconnect VPN {token is unavailable}
{possible way to do works is remove and plug in token}
Reconnect VPN
{possible way to do works is remove and plug in token}
Reconnect ssh
timeout vpn connection
....
{repeat and repeat}

Logs

Wishlist help wanted

Most helpful comment

SSH works perfectly well with PIV keys. I recommend you use it instead of trying what you currently do.

See --read-ssh-key argument (either pkcs11-tool or pkcs15-tool).

All 29 comments

SSH works perfectly well with PIV keys. I recommend you use it instead of trying what you currently do.

See --read-ssh-key argument (either pkcs11-tool or pkcs15-tool).

Another problem you have is that the bone-headed GnuPG developers insist on opening the token in exclusive mode. Which means - what you want just cannot work with the stock GnuPG installation.

GPGTools for Mac addressed this, by adding a config option to share the token. But you’re not on Mac, right?

It is complicated. And you talk about using windows too.

Smartcards started out only card manufacture wrote programs for their card. One-to-one card and card program. These days there can be more then one program (now called an applet) per card, PIV and OpenPGP in your case.

The openvpn --config xxx.ovpn may open the connection, but may require the card for every internet packet to encryt/decrypt. Not clear if you are using the PIV or OpenPGP applet on the card for this.

Software from OpenPGP thinks there is only their applet on the card and opens the card in "exclusive" mode, thus no other application can access the card while it is running. This maybe the case with gpg-connect-agent /bye. Thus VPN times out because it can't access the card. while gpg-connect is running even if it is using the OpenSC PGP driver. OpenSC drivers including the OpenSC OpenPGP driver normally use "shared" mode that allows multiple applications to time share use of the card and keep the same login state too. The PCSC process, (one per machine) enforces the "exclusive" and "shared" modes.

You say ssh and Putty. But are you using OpenPGP via Putty or PIV via Putty? Sounds like from Yubico web site its Software from OpenPGP.

There are multiple ways to use Putty. Google for putty yubikey piv and then for putty piv then for putty CAC There are a number of PIV like cards, including the Taglio PIVKey card and Yubico. There are recommendations on how to use Putty by many interested parties.

https://piv.idmanagement.gov/engineering/ssh/ talks about using Putty-CAC. (Most if not all CAC cards are also PIV cards.) It looks like you can choose between CAPI or PKCS.

CAPI can use the built in Microsoft PIV driver which does not require OpenSC. (You can force CAPI to use the OpenSC minidriver, but that is not the default. CAPI check for ATR or PIV applet on the card to decide what provider to use.

PKCS sounds like it is using PKCS#11 which may be using OpenSC PKCS#11.

OK now back to the card with two applets. OpenSC uses a combination of (SELECT FILE for an AID) or ATR to decide which driver to use. Both PIV and OpenPGP have AIDs. So by changing the order of drivers or specifying one driver be used, you can select which driver to use. But this is on a process by process bases.

See Experimental: PKCS#11 Support for Multiple Applications on One Card which was closed as there did not appear to be much interest and it is complicated.

Irregardless of how you access the applets, CAPI, OpenPGP, OpenSC or other, multi applet cards have another problem in that switching between which applet is selected may lose the login state for the other applet, thus requiring another PIN entry to regain access. This can be avoided by using PIN caching in opensc.conf. See: Pin Caching and the few lines above. You may need to set pin_cache_counter to some really large number like 2^31 if your two applications constantly switch back and forth.

But There is still hope. You can set env: OPENSC_DRIVER=PIV-II for one application and OPENSC_DRIVER=openpgp for another application to be able to select which one is used for the application. Stay away from an software from OpenPGP that like to use "exclusive" mode and just us the OpenSC code. or Microsoft code via CAPI (minidriver) for PIV.

Hi,
you are right, in the initial request I have not sufficiently described my situation. I use both Linux and Windows, but let's take a look at this: Win10, Putty (ssh client), openVPN (vpn tunnel). Previously: I have a ssh public key type Openpgp, but I have certificates for vpn type X509 mostly generated on those servers. Therefore, it is not possible to use one identity for both ssh and vpn. And then my journey began to find out how to use one hardware key for both services (ssh, vpn). I started at ssh. The best option seems to be using an openpgp-agent (which beautifully emulates a ssh-agent for putty). Use of putty-CAC and other proprietary software is out of the question (putty-CAC is not updated, it is out of date). "although now I see that putty-CAC is not outdated. Last release in October 2019. I apologize for my original opinion"

For connecting via SSH I can imagine using the X509 certificate, but I don't know how to get it into a putty. "the original ssh-agent does not support CAPI or PKCS, so I wrote it."

  1. Here I ask anyone know how to use putty with PKCS11? Can OpenSC offer keys (PKCS11) for classic windows putty? I don't know anything about it, is it possible to configure it?
  2. Can OpenSC offer openpgp certificates for putty (something like ssh-agent emulation)?

For VPN I use X509 certificates via PKCS11, built-in openvpn functionality and openSC driver:
config.ovpn
...
pkcs11-providers "C: \ Program Files \ OpenSC Project \ OpenSC \ pkcs11 \ onepin-opensc-pkcs11.dll"
pkcs11-cert-private 1
pkcs11-protected-authentication 1
pkcs11-id 'piv_II / PKCS \ x2315 ​​\ x20emulated / AABBBCCCDDDEEEFFF / client_abc / 01'
...

Thank you in advance for your reply.

You originally said: "I do not understand why both OpenPGP and PKCS11 cannot be used at the same time." I believe this caused by (As Mouse said:) "the bone-headed GnuPG developers insist on opening the token in exclusive mode." As a test, if you had two tokens, one for VPN and one for Putty, you could get around that issue and prove if this is the main issue. (and thus not an OpenSC issue too.)

Another way around the above is to find a replacement for gpg-connect-agent. or modify the gpg source to not use exclusive. Google for gnugpg smartcard "exclusive" (note the quotes on exclusive) Then google for gnupg smartcard "exclusive" Yubikey
There are many who have complained about this.

You say Putty-CAC is out of date. What version of Putty are you using? It is widely used with PIV cards.
Have a look at https://github.com/NoMoreFood/putty-cac/releases Says it is based on Putty 0.73

Also note https://piv.idmanagement.gov/engineering/ssh/ is a U.S Gov site which says to download
PuTTY-CAC v0.70u5 from https://www.github.com/NoMoreFood/putty-cac/releases It has Putty based on 0.73.

(CAC cards are used in the military and some other US gov organizations. PIV is the newer NIST standard and used for most US gov employees and many contractors. Most if not all CAC cards are also PIV cards, so PIV driver can be used. in most cases.)

If you really must use both applets on the card, you can force OpenSC to use a specific driver or change the order of drivers from the opensc.conf file. For example card_drivers = openpgp, PIV-II;
OpenPGP driver would be chosen on the Yubikey before PIV driver.

You can also set the env from at .bat file to force a specific driver for example
set OPENSC_DRIVER=PIV-II; then start the OpenVPN from the BAT file.

Using the Putty from above look at Connection->SSH->Certificate-> Set PKCS Cert... find the opensc-pkcs11.dll under C:\Program Files\OpenSC Project\OpenSC\pkcs11 or C:\Program Files (x86)\OpenSC Project\OpenSC\pkcs11 32 vs 64 bit versions of Putty and OpenSC. If the order of drivers in the opensc.conf file is set to openpgp then the OpenPGP applet would be used.

These are some other things I have not tried...

Since there is both a 32 and 64 bit versions of OpenSC and each with their own opensc.conf
You could have the order for one to be openpgp, PIV-II and the other PIV-II, openpgp.
So you could use the 32 bit vs 64 bit versions of any application like OpenVPN or Putty to say which applet you wanted to use.

Hi,
Once again, I would like to ask whether it is possible to use the OpenSC to push the OpenPGP certificate to the ssh-agent. I switched OpenSC to opengpg mode: card_drivers = openpgp; and using pkcs11-tools I have access to two keys: pkcs11-tool.exe -O
Using Slot 0 with a Present Token (0x0)
Public Key Object; RSA 4096 bits
label: Encryption key
ID: 02
Usage: encrypt, wrap
Public Key Object; RSA 4096 bits
label: Authentication key
ID: 03
Usage: Encrypt, Verify, Wrap

It is interesting to note that only two are visible, as there are four keys on the card:
C: \ Program Files (x86) \ GnuPG \ bin> gpg --card-status
Reader ...........: Yubico Yubikey 4 UTP U2F CCID 0
Application ID: AB000124040070000
Version .......... 2.1
Manufacturer .....: Yubico
Key attributes ...: rsa4096
Signature key ....: XXX created ....: 2019-10-25 20:25:22
Encryption key ....: YYYY created ....: 2019-10-25 20:26:12
Authentication key: ZZZZZ Created ....: 2019-10-25 20:27:11
General key info ..: sub rsa4096 / AAAAA 2019-10-25 <aa@bb.xx
sec # rsa4096 / hash1 created: 2019-10-25 expires: never
ssb> rsa4096 / hash2 created: 2019-10-25 expires: never
card number: 1234
ssb> rsa4096 / hash3 created: 2019-10-25 expires: never
card number: 1234
ssb> rsa4096 / hash4 created: 2019-10-25 expires: never

But especially when I try to access the certificates via pageant-cac and ... OpenSC \ pkcs11.dll, no certificate is available. (In PIV-II mode with pageant-cac via ...OpenSC \ pkcs11.dll I can see and use other certificates)

On my servers I have distributed openPGP certificates for ssh login, so I am still trying to use openPGP. There is, of course, the possibility to generate an X509 certificate from OpenGPG and upload it to the token, but that would be a waste of space.

Is there a way to use openPGP in putty (win10) and not use GnuPG (gpg-connect = agent with exclusive card access)?

Maybe.

If you have a Yubico with only OpenPGP certs it would make the testing easier.

Putty-CAC may not be able to handle a 4096 byte.

In Putty-CAC SSH->Certificates cspi uses the Microsoft CAPI interface. and with PKCS it will using PKCS#11.
opensc-pkcs11.dll then uses

When a smartcard is inserted, Microsoft uses two methods to access a smart card driver.

Using regedit.exe, look at the registry under:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards
You will see many entries, most added by OpenSC and will have:
8000001 REG_SZ C:\Proram files...opensc-minidriver.dll
Crypto Provider OpenSC CSP

There may be some vendor ones too, if you

Trying to use 32bit vs 64-bit is to complicated. Putty uses the registry to hold sessions
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions (SimonTatham is original author of Putty) This means sessions can be mixed up.

If you have two tokens, one with only OpenPGP and one with PIV it would make testing much easier.
Get either the OpenSC OpenPGP driver working first. The get the PIV card working.
setup a vpn .bat file with set OPENSC_DRIVER=PIV-II then make sure the opensc.conf has card_drivers = openpgp, PIV-II, internal; so the default is to try openpgp first for Putty or other applications.

I do not have a good way to test this but it looks like since OpenSC PKCS#11 is used, it could access any OpenSC card.

Also look at registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards
This as the mappings for different cards (mostly OpenSC) that have "CryptoProvider" "OpenSC CSP"
and list opensc-minidriver.dll, which can also access any OpenSC card and uses the order from opensc.conf.

Other entries maybe for vendors, and you may even have the Yubico versions of minidriver called ykmd.dll or Microsoft default of msclmd.dll.

There is no good way today to select which applet on a card to use other then setting in env OPENSC_DRIVER= even with PKCS#11 See the https://github.com/OpenSC/OpenSC/issues/1263 which would allow PKCS#11 to access both applets at same time. (But not the minidriver.)

Years ago I aske Yubico to define two readers on there token, that are independent. That would have also solve this problem, as GnuPG would access one with exclusive and other applications would use the other reader. to access the PIV. #1263 would not be needed.if they did this.

They did not do it.

Please send you problem to Yubico too. It is more of a problem Yubico problem then for OpenSC. Ask them how they would do it.

Also consider two devices, one for VPN and one for the user.

Any other developers want to tackle this problem?

Let me repeat myself: you are likely to address your needs with the least amount of blood if you switch to PIV-only. If you insist on using both on the same token, you will experience pain.

Several years ago, we successfully used PuTTY with CAC via PKCS#11 interface (don’t remember - the middleware library was probably ActivClient, but it should not matter).

Your 4096-bit certs aren’t likely to work, AFAIK.

And one other alternative. Use some combination of the Yubico PKCS11 and ykmd.dll or windows PIV driver Change the opensc.conf to 'card_drivers = openpgp;`

Dont use the GunPG stuff at all. It will still access in exclusive mode locking out the PIV access from any other software. They all use the underlying PCSC to access the card, and that is where the lock is at.

Hi,
Recently I have been concentrating on trying yubikey (with openpgp) through pageant-cac, but I was not successful. Pageant-cac (via PKCS11 interface) showed no certificate to use.

Maybe I've already figured out why my openpgp certificate can't be used via pageant-cac.
Before, I used gpg-agent (from gnuPGP) as an ssh agent and everything worked fine. OpenSC library, but probably can't read my certificate from the Yubico token (see below:Invalid ASN.1 report) By the ssh key string, I recognized that using the gpg-agent I am using a certificate on slot number 3 (they have the same public parts). Now I turn to the openSC project for help.

log:
C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe --read-ssh-key 1
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACA ... NVE5h9/9P2Oq4yZHDFxD79F2Ev+Jqx1w== Signature key

C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe --read-ssh-key 2
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACA ... 1DqakYxwd/+cxV/tKQFMT8nAUnf5G1Q== Encryption key

C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe --read-ssh-key 3
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACA ... hRq7zeQwEpOT3BxlU7lAyIPlA5Q== Authentication key

C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe -r 1
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
Certificate with ID '1' not found.

C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe -r 2
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
Certificate with ID '2' not found.

C:\Program Files\OpenSC Project\OpenSC\tools>pkcs15-tool.exe -r 3
Using reader with a card: Yubico Yubikey 4 OTP+U2F+CCID 0
Certificate read failed: Invalid ASN.1 object

We would need a debug log to figure out what is going on there.

You may want to try OpenSC 0.20.0-rc3 but note that some of the command line options have changed. You must use pkcs15-tool --read-certificate <arg>

Also try to list all objects:
pkcs11-tool -O

log:
P:10804; T:11304 2019-11-15 20:31:25.286 [pkcs15-tool] reader 'Yubico Yubikey 4 OTP+U2F+CCID 0'
P:10804; T:11304 2019-11-15 20:31:25.287 [pkcs15-tool] reader-pcsc.c:297:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 04 00 .....
P:10804; T:11304 2019-11-15 20:31:25.288 [pkcs15-tool] reader-pcsc.c:216:pcsc_internal_transmit: called
P:10804; T:11304 2019-11-15 20:31:25.289 [pkcs15-tool] reader-pcsc.c:306:pcsc_transmit:
Incoming APDU (2 bytes):
69 82 i.
P:10804; T:11304 2019-11-15 20:31:25.290 [pkcs15-tool] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.291 [pkcs15-tool] apdu.c:535:sc_transmit: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.292 [pkcs15-tool] card.c:525:sc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.293 [pkcs15-tool] Security status not satisfied
P:10804; T:11304 2019-11-15 20:31:25.294 [pkcs15-tool] card-openpgp.c:1719:pgp_get_data: Card returned error: -1211 (Security status not satisfied)
P:10804; T:11304 2019-11-15 20:31:25.294 [pkcs15-tool] card.c:867:sc_get_data: returning with: -1211 (Security status not satisfied)
P:10804; T:11304 2019-11-15 20:31:25.295 [pkcs15-tool] card-openpgp.c:1484:pgp_select_file: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.296 [pkcs15-tool] card.c:854:sc_select_file: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.297 [pkcs15-tool] called; 0 bytes at index 0
P:10804; T:11304 2019-11-15 20:31:25.298 [pkcs15-tool] Cannot read DO 0104 or there is no data in it
P:10804; T:11304 2019-11-15 20:31:25.299 [pkcs15-tool] pkcs15-openpgp.c:449:sc_pkcs15emu_openpgp_add_data: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.300 [pkcs15-tool] pkcs15-syn.c:187:sc_pkcs15_bind_synthetic: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.300 [pkcs15-tool] card.c:525:sc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.301 [pkcs15-tool] reader-pcsc.c:701:pcsc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.302 [pkcs15-tool] pkcs15.c:1272:sc_pkcs15_bind: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.305 [pkcs15-tool] pkcs15-cert.c:372:sc_pkcs15_read_certificate: called
P:10804; T:11304 2019-11-15 20:31:25.306 [pkcs15-tool] pkcs15.c:2323:sc_pkcs15_read_file: called
P:10804; T:11304 2019-11-15 20:31:25.307 [pkcs15-tool] path=3f007f21, index=0, count=-1
P:10804; T:11304 2019-11-15 20:31:25.308 [pkcs15-tool] card.c:475:sc_lock: called
P:10804; T:11304 2019-11-15 20:31:25.309 [pkcs15-tool] reader-pcsc.c:651:pcsc_lock: called
P:10804; T:11304 2019-11-15 20:31:25.310 [pkcs15-tool] card-openpgp.c:3493:pgp_card_reader_lock_obtained: called
P:10804; T:11304 2019-11-15 20:31:25.311 [pkcs15-tool] card-openpgp.c:3520:pgp_card_reader_lock_obtained: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.311 [pkcs15-tool] card.c:515:sc_lock: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.313 [pkcs15-tool] called; type=2, path=3f007f21
P:10804; T:11304 2019-11-15 20:31:25.315 [pkcs15-tool] card-openpgp.c:1420:pgp_select_file: called
P:10804; T:11304 2019-11-15 20:31:25.315 [pkcs15-tool] card-openpgp.c:1484:pgp_select_file: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.317 [pkcs15-tool] card.c:854:sc_select_file: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.318 [pkcs15-tool] called; 259 bytes at index 0
P:10804; T:11304 2019-11-15 20:31:25.320 [pkcs15-tool] card.c:475:sc_lock: called
P:10804; T:11304 2019-11-15 20:31:25.321 [pkcs15-tool] card.c:515:sc_lock: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.323 [pkcs15-tool] called; 255 bytes at index 0
P:10804; T:11304 2019-11-15 20:31:25.324 [pkcs15-tool] card-openpgp.c:1559:pgp_read_binary: called
P:10804; T:11304 2019-11-15 20:31:25.325 [pkcs15-tool] card-openpgp.c:1580:pgp_read_binary: returning with: 255
P:10804; T:11304 2019-11-15 20:31:25.326 [pkcs15-tool] card.c:676:sc_read_binary: returning with: 255
P:10804; T:11304 2019-11-15 20:31:25.327 [pkcs15-tool] called; 4 bytes at index 255
P:10804; T:11304 2019-11-15 20:31:25.328 [pkcs15-tool] card-openpgp.c:1559:pgp_read_binary: called
P:10804; T:11304 2019-11-15 20:31:25.329 [pkcs15-tool] card-openpgp.c:1580:pgp_read_binary: returning with: 4
P:10804; T:11304 2019-11-15 20:31:25.331 [pkcs15-tool] card.c:676:sc_read_binary: returning with: 4
P:10804; T:11304 2019-11-15 20:31:25.334 [pkcs15-tool] card.c:525:sc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.335 [pkcs15-tool] card.c:673:sc_read_binary: returning with: 259
P:10804; T:11304 2019-11-15 20:31:25.336 [pkcs15-tool] card.c:525:sc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.337 [pkcs15-tool] reader-pcsc.c:701:pcsc_unlock: called
P:10804; T:11304 2019-11-15 20:31:25.338 [pkcs15-tool] pkcs15.c:2419:sc_pkcs15_read_file: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.339 [pkcs15-tool] pkcs15-cert.c:91:parse_x509_cert: X.509 certificate not found: -1401 (Invalid ASN.1 object)
P:10804; T:11304 2019-11-15 20:31:25.340 [pkcs15-tool] pkcs15-cert.c:394:sc_pkcs15_read_certificate: returning with: -1401 (Invalid ASN.1 object)
P:10804; T:11304 2019-11-15 20:31:25.342 [pkcs15-tool] pkcs15.c:1287:sc_pkcs15_unbind: called
P:10804; T:11304 2019-11-15 20:31:25.343 [pkcs15-tool] pkcs15-pin.c:838:sc_pkcs15_pincache_clear: called
P:10804; T:11304 2019-11-15 20:31:25.344 [pkcs15-tool] card.c:416:sc_disconnect_card: called
P:10804; T:11304 2019-11-15 20:31:25.346 [pkcs15-tool] Yubico Yubikey 4 OTP+U2F+CCID 0:SCardDisconnect returned: 0x00000000
P:10804; T:11304 2019-11-15 20:31:25.348 [pkcs15-tool] card.c:438:sc_disconnect_card: returning with: 0 (Success)
P:10804; T:11304 2019-11-15 20:31:25.349 [pkcs15-tool] ctx.c:927:sc_release_context: called
P:10804; T:11304 2019-11-15 20:31:25.349 [pkcs15-tool] reader-pcsc.c:938:pcsc_finish: called

Ok,
so the x509 certificate is not there, but we knew openpgp is not x509. But what I would expect is to emulate an openpgp key so that it can be used via PKCS11 in a putty. It could be turning on emulation by parameter, or turning on in configuration. If it can emulate the gpg-agent key in the putty card, please also emulate it in openSC. Please,please.

It looks like the error starts with P:10804; T:11304 2019-11-15 20:31:25.293 [pkcs15-tool] Security status not satisfied while trying to read the object and then it is probably fails to parse the certificate as it did not get any data.

From the previous logs, I see all three keys are there, so what is the actual problem? You do not need any certificates for SSH.

Hi,

where is the problem? it will probably be the wrong procedure. I tried to retrieve these keys as PKCS11 certificates via pageant-cac and PKCS11 interface. Obviously this must have led to failure. pageant-cac strictly expects X509 certificates and will not find them.
So how to put openpgp keys for putty under win10 but not use gpg-agent (gnuPG) ??? Apparently this path does not exist yet.
I realize that this is more of a job for team pageant-cac.

Sounds like an issue of the putty-cac or pageant-cac -- it does not need the certificates for anything. Try OpenSSH, which should work you also with the openpgp applets as a charm.

Putty-CAC shows the certificates in order to allow the user to select one.
Using the NIST demo card 1, I selected the Auth cert then saved a Putty session "nist-demo-1-9A"
The session is saved HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\nist-demo-1-9A which includes
"CAPICertID"="PKCS:55ef1032a6619293a86627d215c146720916f81a=C:\Program Files\OpenSC Project\OpenSC\pkcs11\opensc-pkcs11.dll"` That is the certificate thumbprint.

S looks like you need a certificate to find the private key.

It looks like he’s trying to pull (X.509?) certificates from an OpenPGP applet. Ain’t going to happen.

Way back I suggested to stick to one PIV applet, and warned that other paths would lead to painful adventures...

Way-way back we used CAC with PuTTY to SSH-connect to other machines. Unfortunately, I don’t recall the specific details.

Hi,
The only way to use the keys from the token under windows that I found (link, see below) is to save the self-signed certificate on the token.
Creating a signature is only possible on Linux(under win ssl via pkcs11 don't work )
1.Create self-signed certificate:
$openssl req -engine pkcs11 -new -key "pkcs11:object=MyKeyPairOnToken" \
-keyform engine -out myCert.pem -days 3650 -outform pem -x509 -utf8
2.store certificate on token:
$pkcs15-init --store-certificate myCert.pem --id 00 --verify-pin

This certificate can then be loaded into pageant-cac.

Note: using windows does not work with keys from the token under openSSH (pkcs11 is unsupported) and pageant-cac only takes certificates, not keys via PKCS11.

Link:
https://zerowidthjoiner.net/2019/01/12/using-ssh-public-key-authentication-with-a-smart-card

The problem here is not with key length, but with the use of an OpenPGP card in general.

In the experiments I quite forgot something very important. You can create a certificate for a pair of keys, but you do not have how and where to store it with an openPGP card. During testing, however, I changed the OpenPGP card (token) with Nitrokey HSM, where you can store x509 certificates.
It is still annoying that the OpenPGP card cannot be used to connect ssh (with Putty under WIN) without a gpg-agent.

You seem to be using Yubikey, which has PIV applet. Yet you seem to be doing everything in your power to avoid using it, trying to implement an OpenPGP-based approach (and failing at that).

If you really want OpenPGP and are willing to make changes to Putty-CAC you could use a OpenPGP card without certificates.
Using PKCS11-SPY and a NIST demo 1 card, SPY shows Putty-CAC does:

  • Using PKCS11 load all the certificates from the card
  • Allows user to select which certificate to use using Microsoft dialog box.
  • Creates a SSH fingerprint that is a MD5 hash, (need to verify it is MD5) of the RSA modulus and exponent which is contained in the certificate in the the public key in the SPKI)
  • Saves the fingerprint in session in registry if user request it for later use
  • Using the saved or current session, loads all the certificates again apparently to recalculate their hash again to compare with the requested hash to get the CKA_ID of certificate. (Each triplet: cert, pubkey, and private key all have the same CKA_ID)
  • Does C_Login
  • Finds the private key via its CKA_ID to get a handle
  • Does C_SignInit using the handle
  • Does C_Sign to sign the SSH data as needed.

So it would be possible to modify Putty_CAC to not require a certificate but use the public key.

As a proof of concept, modify Putty-CAC that if a session already has the fingerprint, find the public key rather then the certificate to find the CKA_ID to use for the private key.

Get the fingerprint of a public key using sshkey-get -l -E md5 -f \ into a session in the registry. (See above comment about location.

If that works, Putty-CAC could be modified to show the public keys, for the user to select. An authorized_keys or authorized_keys2 file might be used as a mapping between the public key or hash and some thing the user can read.

The mod will not be easy. It would be better if select and update of the session was done from Putty-CAC.

Most internal card drivers in OpenSC are selecting the Applets (PIV/OpenPGP) only once on initialization. We would have to rewrite this code to expect no context whatsoever to simultaneously allow access to PIV and OpenPGP.

However, the reality is that most people only use either OpenPGP or PIV. If you don't want to run with the herd, sit down grab the source code and get your fingers dirty!

OpenSC currently can only access one applet per card, because of how it loads drivers. It cannot load two drivers that access the same card but different applets. See #1263 as an experimental solution which was closed for some reason. I will reiterated again...

Even with this restriction, multiple applications can use OpenSC and specify different drivers by using different opensc.conf files to set the DRIVER to be used.

Much of this code was added at the request of @mouse07410 who does use the PIV applet from one application and OpenPGP from a different application.

The PIV applet goes out of its way to support multiple applets on a card. The card_reader_lock_obtained hook was added for this purpose. At the start of each transaction just after the pcsc_lock has been obtained the driver does a "7E" command and/or SELECT AID to select the PIV applet. It does both because there are known issues with older Yubico devices that can lose the login state even with a SELECT AID.

Losing the login state when switching between applets is a big problem. By design, some applets require the login state be reset if another applet is selected. At best PIN caching can be used to do VERIFY again so user is not involved.

To use multiple applets on the same card really depends on cooperation between all applications to assume other applications can "interfere" with "their" session to a card. But there are applications that hold a pcsc exclusive lock or lock the card for long periods, such as the GnuPG smartcard code.
This can not be solved by OpenSC alone.

But there are applications that hold a pcsc exclusive lock or lock the card for long periods, such as the GnuPG smartcard code.

Note: https://GPGTools.org has a patched version of GnuPG (scdaemon, to be specific) that allows sharing of the card if the ~/.gnupg/scdaemon.conf contains a line shared-access).

Please add this info to the wiki when you find the time to

Was this page helpful?
0 / 5 - 0 ratings