search

arekinath / PivApplet

PIV applet for JavaCard 2.2.2 and 3.0.4+ with full ECDSA/ECDH support
111 stars 37 forks source link

AID format in APT TLV 0x4F #43

Closed vuori closed 3 years ago

vuori commented 3 years ago

GnuPG 2.3 will include direct PIV support and I was going to give it a try with a PivApplet card. Unfortunately I didn't get far: PivApplet returns an APT where object 0x4F has length 11 and it contains the full AID, while GnuPG expects the object to have 6 bytes and contain only the PIX + version without the RID.

OpenSC sources @ https://github.com/OpenSC/OpenSC/blob/0d693f63cbebda1440f1468eb30c35b7a278f7e9/src/libopensc/card-piv.c#L718 indicate that "early Yubikeys" also returned the full AID, but apparently new ones don't (a Yubikey 5 I have returns PIX+version only). SP 800-73-4 isn't really clear on the matter. Part 2 section 3.1.1 comment regarding tag 0x4F just states that "The PIX of the AID includes the encoding of the version of the PIV Card Application."

What's your take on what the object should contain? I think GnuPG ought to support both versions since both kinds of cards are in the wild, but no idea whether the developers will budge.

Addendum: sub-tag 0x4F in TLV 0x79 is apparently expected to contain only the RID (which is what's there on a Yubikey) and not RID+PIX.

dengert commented 3 years ago

In response to: "Addendum: sub-tag 0x4F in TLV 0x79 is apparently expected to contain only the RID"

As OpenSC developer for PIV, the real source should be NIST sp800-73-4 and accept sp800-73-3 as there are many of these in the field. 800-73-3 superseded 800-73-2 in 2010, appears to be the same as 800-73-4 in regards to AID.

I had though it should contain the full 11 bytes. But all the demo cards return for 4F 79 the 5 byte RID. See the examples from 2 early NIT demo cards and one 2020 Idemia ID-One based sp800-73-4below.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf "Part 1 - 2.2 PIV Card Application AID" "Part 1 - 3.3.2 Discovery Object" "Part 2 - 2.3 Card Applications" "Part 2 - 3.1.1 SELECT Card Command" "Part 2 - Table 3 Data Objects in the PIV Card Application Property Template (Tag '61')" which says: "Application identifier of application '4F' - M - The PIX of the AID includes the encoding of the version of the PIV Card Application. See Section 2.2, Part 1." (I read this as the full 11 bytes.) "Coexistent tag allocation authority '79' - M - Coexistent tag allocation authority template. See Table 4."

"Part 2 - Table 4 Coexistent Tag Allocation Authority Template (Tag '79') " says: " Application identifier '4F' - M - See Section 2.2, Part 1" (I also have read this as the full 11 bytes but all the demo cards below only return 5 bytes, i.e. NIST, the authority for PIV. This make sense because a Coexistent Tag Allocation Authority would be the authority i.e. NIST i.e. the NIST RID. And not include an application. But I can not find it stated in a document, only in the example cards. )

But I did find in sp800-73-1 from 2006, and superseded in 2008:

Table 9. Data Objects in a Coexistent Tag Allocation Authority Template (Tag '79') Description Tag M/O Comment
Application identifier ‘4F’ M NIST will post the PIV RID on http:///csrc.nist.gov/piv-project and will publish it in a technical note.

This implies that the RID might not be the same as what is in the AID, although it appears they are the same 5 bytes now. and in the 79 4F it should be the 5 byte RID.

ISO-7816 is one of the most complicated standards I have ever seen. I suspect this is why NIST wrote sp800-74 to spell out what subset of ISO 7816 it would require in a PIV applet or application. For reference purposes I include the following:

ISO 7816-4 Table 122 — "Interindustry DOs for application identification and selection" "'61' Set of application-related DOs" " '79' under DO'61' this DO indicates a coexistent tag allocation scheme" (This is the PIV case.)

" 8.3.6 Coexistent tag allocation scheme" says: "In such a scheme, all the interindustry DOs shall be nested within interindustry DOs'7E'. Moreover, tags '79' and '7E' shall not be given another interpretation (The PIV Discovery returns '7E' so needs to follow the same restrictions.

These tag allocation schemes may use tags with an interpretation not defined in ISO/IEC 7816 [6]. In order to identify a coexistent tag allocation scheme and the authority responsible for the scheme, an interindustry DO'79' shall be used. This DO shall nest one of the interindustry DOs shown in Table 16.

"If an authority is valid within a file or application, then DO'79' shall be present in the EF, DF or application DF management data (see 7.4), or in the current template set by any file selection."

Example of demo cards: (Note; last 00 in the -s string is Le=00) When I got these cards early from NIST I recall a comment about a shortage of cards and so 2 cards are from Gemalto and the rest from Oberthur.

Early NIST demo card 1 using T=0 from Gemalto PIV 1.5.5 appears to violate the standard for 4F and for 79 4F. ./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00" Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 Received (SW1=0x90, SW2=0x00): 61 11 4F 06 00 00 10 00 01 00 79 07 4F 05 A0 00 a.O.......y.O... 00 03 08

Early NIST Demo card 2 using T=1 Oberthur ID-One PIV (Type A): ./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00" Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 Received (SW1=0x90, SW2=0x00): 61 39 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79 a9O............y 07 4F 05 A0 00 00 03 08 50 0E 49 44 2D 4F 6E 65 .O......P.ID-One 20 50 49 56 20 42 49 4F 5F 50 10 77 77 77 2E 6F PIV BIO_P.www.o 62 65 72 74 68 75 72 2E 63 6F 6D 7F 66 08 02 02 berthur.com.f... 80 00 02 02 80 00 ......

Idemia ID-One PIV 2.4.1 demo card based on 800-73-4 support for SM: ./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00" Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00 Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 Received (SW1=0x90, SW2=0x00): 61 2C 4F 0B A0 00 00 03 08 00 00 10 00 01 00 50 a,O............P 0A 49 44 2D 4F 6E 65 20 50 49 56 61 09 79 07 4F .ID-One PIVa.y.O 05 A0 00 00 03 08 AC 06 80 01 2E 06 01 00 7F 66 ...............f 08 02 02 03 F8 02 02 7F FF .........

arekinath commented 3 years ago

Honestly, I think at this point Postel's law should indicate to client implementations to support both. There's clearly a mix of interpretations out in the wild. I feel like the GnuPG developers are doing themselves and their users a disservice by being too strict on this particular fine point.

For this applet, I'm happy to change to the 0x79 0x4F containing just the 5 bytes, since I think that makes sense. For the top level 4F in the APT, maybe we should provide a build configuration option?

vuori commented 3 years ago

I agree re Postel's law. I have sent a suggestion and patch to gnupg-devel to be more flexible, but it seems to be stuck in moderation. After playing with their PIV feature a bit more it seems that it's still pretty far from being ready to release anyway.

Based on Doug's reply 5-byte 79 4F sounds nice. I guess an option for the top-level 4F format would work, since the current way seems more in the spirit of SP-800-73-x but someone may want maximum Yubikey compatibility.