Questions on implementation of PIV Applet

[dengert]

The use of your PIV applet cam up on https://github.com/OpenSC/OpenSC/issues/1469

A quick look at the arekinath PivApplet by @arekinath as compared to NIST 800-73-3: It defines 3 non-PIV APDU ins: INS_SET_MGMT, INS_IMPORT_ASYM, INS_GET_VER These are some of the vendor supplied commands that you might be able to use.

It has MAX_CERT_SIZE = (short)900; which is way to short. On NIST demo cards (16 cards, with 4 or more certificates each) the cert objects range from 1207 to 1747. Early versions of NIST 800-73 set limits. Later versions listed suggested sizes for objects. The applet needs to be more dynamic.

If RAM_BUF_SIZE = (short)1000; is for other objects is is also too small. facialimage are as large as 12216,

It add PIV_ALG_ECCP256_SHA1 and PIV_ALG_ECCP256_SHA256 which are not standard.

It tries to construct the CHUID rather than treating as just any other object. Many of the PIV objects should be signed. NIST 800-74-4 says: "The CHUID shall be signed in accordance with Section 3.1.2.1. The card issuer’s digital signature key shall be used to sign the CHUID and the associated certificate shall be placed in the signature field of the CHUID." So the CHUID should not be constructed. (The applet or most middleware, like PKCS#11, do not check any signatures, but do allow a calling application to read the full objects with signatures.)

It constructs a key history object too. But does not support the any retired keys.

It should support the certificate objects as opaque objects, and should not care if the contained certificate is gzipped or not, just save the object.

It does not appear to have a way to delete an object. Does Java may take care of that if an object is overwritten?

It looks like a user could overwrite any object?

[arekinath]

I hope you don't mind, but I'm going to split this into separate bugs for each of the things that needs improvement. You're right that this applet is somewhat incomplete -- I'm sorry if I'm not conveying that clearly in the README at the moment.

I think I pretty clearly explain in there though that this is intended to implement some proprietary extensions (Yubico's, as well as the hash-on-card algorithm IDs) on top of PIV -- including the example commands using yubico-piv-tool, which work fine in my testing against cards with the applet installed.

yubico-piv-tool should also work against the simulator example (with PivApplet running in jCardSim) given in that ticket you linked to -- the yubico-piv-tool is simply using PCSC to send and receive APDUs (it doesn't talk to the USB device directly or anything like that, and should only be trying to work with the PIV applet). I'm not sure what's going wrong there, but I believe you're right that it's not really an OpenSC issue since it doesn't use that (just pcsclite).

Anyway, these are the issues I've made:

• arekinath/PivApplet#6 -- get rid of or vastly increase RAM_BUF_SIZE and MAX_CERT_SIZE
• arekinath/PivApplet#7 -- stop constructing CHUID file and allow writing the whole thing
• arekinath/PivApplet#8 -- add support for using retired key slots
• arekinath/PivApplet#9 -- support for object deletion
• arekinath/PivApplet#10 -- "put data" allowed without admin key auth

I've fixed #10 right away and made a new release with that fixed.

Thanks for pointing these out!

[dengert]

Your site was brought to my attention by https://github.com/OpenSC/OpenSC/issues/1469 So I took a quick look at Java code. The user was asking how to use Yubico tools with your applet. So I was interested in what your applet was doing. I must admit I started with the code, and did not read the readme.adoc. Sorry.

As the primary author of the OpenSC PIV driver, I have dealt with many issues from various NIST approved cards as well as other vendor's non-approved card/devices/applets. As well as issues with cards/devices having more then one applet, such as OpenPGP and PIV, or CAC and PIV. (PCSC does not keep track of which applet is active or the login state.) These issues deal mainly with keeping track of the login status and active applet on the card, which can change when multiple long running user applications like a mail client and browser stay open for long periods.

NIST 800-73-4 part 2 3.1.1 "SELECT Card Command" has some rules about what to do with the login state when the card receives an SELECT AID command. i.e. Ignore them if the card does not support the command and don't loses the login state if the PIV AID is selected again.

The Discovery object, 7E is an ISO standard, is also useful to detect if the PIV applet is selected and it does not have some of the problems above.

Also the VERIFY with Lc = 0 can be used to test the login state, return 9000 or return 63CX if not logged in.

So please keep in mind your applet needs to work in environment with multiple applications trying to test if your card is one one they support.

Thanks for the quick response. I suspect @mgramigna will keep in contact as he is the one trying to use your applet.

[arekinath]

@dengert Actually I have a spec lawyering question on the topic of VERIFY that you might have a better handle on than I do. I've noticed that the YubicoPIV applet can be in a state where VERIFY with Lc=0 returns SW=0x9000, but an attempt to use the 9C key in a GENERAL AUTH command will result in SW=0x6982 (SW_SECURITY_STATUS_NOT_SATISFIED), because you used the 9C key previously. Is that how the "PIN always" requirement for the 9C key and the VERIFY SW=0x9000 return based on security status are supposed to interact?

[dengert]

It is not " because you used the 9C key previously", it because the digital signature operation was not immediately preceded by the VERIFY with the PIN

NIST 800-73-4 Part 2 Section "3.2.1 X.509 Certificate for Digital Signature" "In other words, the PIN or OCC data must be submitted and verified every time immediately before a digital signature key operation. This ensures cardholder participation every time the private key is used for digital signature generation."

So any APDU sent to the card between the two commands will cause the "PIN Always" requirement to fail. VERIFY Lc=0 or SELECT AID will cause it to fail.

I first ran into this around 2006, when FireFox would do the verify then request all certificates to be read to find a certificate (it already had) before doing a C_Sign The OpenSC PIV driver caches the 4 main certificates when first starting up to avoid this.

OpenSC now supports via PKCS#11 the CKA_ALWAYS_AUTHENTICATE attribute for the 9C key so an application can then do C_Login(...,CKU_CONTEXT_SPECIFIC) . The PIV driver then knows that the next command by the application should be a C_Sign or C_Sign_Final. It makes sure the VERIFY and the next command which should be the Sign operation are in the same PCSC Transaction. This avoids other applications from trying to access the card too.And can meet the " This ensures cardholder participation every time" policy.

The PKCS#15 term for this is user_consent. opensc.conf has some ways to allow pins to be cached and to ignore_user_consent if the card or application can not handle the above.

[dengert]

You may want to look at https://github.com/makinako/OpenFIPS201 another open source PIV applet based on NIST 800-74-4. It includes the optional Secure Messaging.

(OpenSC has support for Secure Messaging but not in the PIV driver for lack of a PIV card to test with. )

[arekinath]

For @mgramigna: I've just been testing this applet on Linux in a virtual reader with my fork of jcardsim (I added support for vsmartcard/vpcd protocol over TCP rather than using BixVReader) and it seems to work ok. I did have to fix up a few little things with some lengths in jcardsim (still working out why). yubico-piv-tool seems to talk to it fine though.

So... I still can't reproduce your original issue, sorry.

[mgramigna]

@arekinath After looking at it some on Friday, I found that the command yubico-piv-tool -r '' -a list-readers does not work for the virtual reader. It will say that there are no readers found. But in my case, since I was using the "Fabio Ottavi Pipe Reader", the command yubico-piv-tool -r 'Fabio' -a <command> worked. So it seems like I was just not telling yubico-piv-tool how to talk to the reader correctly.

[arekinath]

@mgramigna Ok, good to hear. Glad you got it sorted! I'm gonna close this issue then and let the other open ones track the problems that @dengert brought up.