Current PIV Answer to Select Parsing in PIV AID

[dengert]

In response to OpenSC issue OpenSC/OpenSC#2242 by @jo-bitsch please see
OpenSC/OpenSC#2242 (comment)

This points out a problem in the response to the Select AID where the length of the tag is wrong,
61 81 4F is parsed as tag=61 len=4F with next tag as 06.
But the it looks like it should have been
61 81 81 with tag=61 len=81 and next tag =4F

And the interpretation "AC" by NIST approved Idemia card which supports sp800-73-4 Secure Messaging differs from PivApplet interpretation which also made the response larger then needed.

OpenSC/OpenSC#2242 deals with tag is not parsed correctly, but looking at the data in the response, the response is not constructed by PivApplet correctly.

Incoming APDU (133 bytes):
61 81 4F 06 00 00 10 00 01 00 79 0D 4F 0B A0 00 a.O.......y.O...
00 03 08 00 00 10 00 01 00 50 22 50 69 76 41 70 .........P"PivAp
70 6C 65 74 20 76 30 2E 38 2E 32 2D 64 65 76 2F plet v0.8.2-dev/
52 45 65 50 53 41 73 78 4C 72 61 44 58 5F 50 26 REePSAsxLraDX_P&
68 74 74 70 73 3A 2F 2F 67 69 74 68 75 62 2E 63 https://github.c
6F 6D 2F 61 72 65 6B 69 6E 61 74 68 2F 50 69 76 om/arekinath/Piv
41 70 70 6C 65 74 AC 1B 80 01 03 80 01 08 80 01 Applet..........
0A 80 01 0C 80 01 06 80 01 07 80 01 11 80 01 14 ................
06 01 00 90 00 

Based on the name this appears to be a dev build, with a long name that caused the problem with the long tag.

It also pointed out current OpenSC card-piv.c can not handle the response if over 128 bytes.
But OpenSC/OpenSC#2053 could handle it.

Contributing to the problem is the length of the tag AC This is new in NIST sp800-74-4 and defined in Table 5. Which say just before table 5:
" A PIV Card Application may use a subset of the cryptographic algorithms defined in SP 800-78. Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. The encoding of tag 0xAC shall be as specified in Table 5. Each instance of tag 0x80 shall encapsulate one algorithm. The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite. Tag 0xAC shall be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure messaging."

PivApplet added 9 elements by adding "ALL" the algorithms supported by the card.

An Idemia NIST approved demo card that supports SM from sp800-74-4 only adds 2 elements:
AC 06 80 01 2E 06 01 00 i.e. is supports SM using 2E and a null OID.

sp800-73-3 does not define the "AC" tag.

It looks like Idemia interpreted table 5 to be added only when SM was supported as stated in bolded line above and did not report the standard required algorithms.

So if PivApplet can shorten the AC, or remove it or shorten comments by 2 bytes everything will work.

[jo-bitsch]

Just to make sure this is clear: this was not the upstream version of the PiVApplet, but one, where I locally lengthened the version information by a few bytes. This resulted in the answer to select becoming longer than 129 bytes. This made the generated asn1 invalid that was generated in the following line:

PivApplet/src/net/cooperi/pivapplet/PivApplet.java

Line 855 in 806a035

wtlv.push((byte)0x61);

If we replace the call with

wtlv.push256((byte)0x61);

the asn1 can be parsed correctly again. Hexdump:

61 81 85 4F 06 00 00 10 00 01 00 79 0D 4F 0B A0 
00 00 03 08 00 00 10 00 01 00 50 26 50 69 76 41 
70 70 6C 65 74 20 76 30 2E 38 2E 32 2D 64 65 76 
65 6C 6F 70 2F 52 45 65 50 53 41 73 78 4C 72 61 
44 58 5F 50 26 68 74 74 70 73 3A 2F 2F 67 69 74 
68 75 62 2E 63 6F 6D 2F 61 72 65 6B 69 6E 61 74 
68 2F 50 69 76 41 70 70 6C 65 74 AC 1B 80 01 03 
80 01 08 80 01 0A 80 01 0C 80 01 06 80 01 07 80 
01 11 80 01 14 06 01 00

--> https://lapo.it/asn1js/#YYGFTwYAABAAAQB5DU8LoAAAAwgAABAAAQBQJlBpdkFwcGxldCB2MC44LjItZGV2ZWxvcC9SRWVQU0FzeExyYURYX1AmaHR0cHM6Ly9naXRodWIuY29tL2FyZWtpbmF0aC9QaXZBcHBsZXSsG4ABA4ABCIABCoABDIABBoABB4ABEYABFAYBAA

Now this is a problem in my code, not (necessarily yet) in the unchanged code from this repository. However, it might lead to issues in the future, with cards having more algorithms, compile options being added or version numbers potentially including a git reference.

Thanks so much to @dengert for pointing out the malformed ASN1. I didn't notice it while debugging.

[jo-bitsch]

So I justed tested again with the version from the current master (806a035)

The current answer to select is (in the default configuration running in jcardsim):

61 80 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79
0D 4F 0B A0 00 00 03 08 00 00 10 00 01 00 50 1C
50 69 76 41 70 70 6C 65 74 20 76 30 2E 38 2E 32
2F 52 45 65 50 53 41 78 4C 72 61 44 5F 50 26 68
74 74 70 73 3A 2F 2F 67 69 74 68 75 62 2E 63 6F
6D 2F 61 72 65 6B 69 6E 61 74 68 2F 50 69 76 41
70 70 6C 65 74 AC 1B 80 01 03 80 01 08 80 01 0A
80 01 0C 80 01 06 80 01 07 80 01 11 80 01 14 06
01 00

which runs actually already in exactly this problem: The ASN1 is malformed and should start with:
61 81 80 4F [...].
The culprit is exactly the referenced code line above in sendSelectResponse:

PivApplet/src/net/cooperi/pivapplet/PivApplet.java

Line 855 in 806a035

wtlv.push((byte)0x61);

which should be wtlv.push256((byte)0x61); . So, this is an actual bug in the current master and not just a potential bug later on if strings gets longer.

Nevertheless: Thanks for this awesome piece of software! I really appreciate the work!

[dengert]

OK, thanks for catching OpenSC/OpenSC#2242 which only shows up if the asn1 tag length is not correct. If the PivApplet sends valid length, things will work.

There is still a question why PivApplet sends all the cryptographic algorithms but NIST approved sp800-74-4 cards do not, but only send it to indicate card supports of Secure Messaging.

[dengert]

PivApplet does not appear to follow NIST or ISO standards in the following lines:

PivApplet/src/net/cooperi/pivapplet/PivApplet.java

Lines 871 to 929 in 806a035

	wtlv.push((byte)0xAC);
	//#if PIV_SUPPORT_3DES
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_3DES);
	//#endif
	//#if PIV_SUPPORT_AES
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_AES128);
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_AES192);
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_AES256);
	//#endif
	//#if PIV_SUPPORT_RSA
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_RSA1024);
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_RSA2048);
	//#endif
	//#if PIV_SUPPORT_EC
	if (ecdsaSha != null || ecdsaSha256 != null) {
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP256);
	}
	if (ecdsaSha384 != null) {
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP384);
	}
	/*#if !PIV_USE_EC_PRECOMPHASH
	if (ecdsaSha != null) {
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP256_SHA1);
	}
	if (ecdsaSha256 != null) {
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP256_SHA256);
	}
	if (ecdsaSha384 != null) {
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP384_SHA1);
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP384_SHA256);
	wtlv.writeTagRealLen((byte)0x80, (short)1);
	wtlv.writeByte(PIV_ALG_ECCP384_SHA384);
	}
	#endif*/
	//#endif
	/*
	* SP 800-83-4 part 2, 3.1 says: "Its value is set to 0x00"
	* regarding this 0x06 tag. Previous PivApplet releases
	* interpreted this as an empty 0x06 tag with no contents
	* (length = 0), but it seems more logical that it should
	* contain a single zero byte.
	*/
	wtlv.writeTagRealLen((byte)0x06, (short)1);
	wtlv.writeByte((byte)0x00);

1. NIST sp800-73-3 list the required and optional tags it supports and does not list the 'AC' tag at all.
2. NIST sp800-73-4 list the 'AC' tag to be used if the card supports Secure Messaging, and "Table 5 Data Objects in a Cryptographic Algorithm Identifier Template (Tag 'AC')" shall have "Cryptographic algorithm identifier", and "Object identifier" "Its value is set to 0x00". and says "Tag 0xAC shall be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure messaging."
3. ISO 7816-4 "5.4.2 Cryptographic mechanism identifier template" Says "Referenced by tag 'AC', one or more cryptographic mechanism identifier templates may be present in the control parameters of any DF" "The first data object shall be a cryptographic mechanism reference, tag '80' (see Table 33).
   The second data object shall be an object identifier, tag '06', as defined in ISO/IEC 8825-1."
4. ISO 7816-4 gives two examples: "{'AC' - '0B' - {'80'-'01'-'01'} - {'06'-'06'-'28818C710201'}}" and "{'AC' - '11' - {'80'-'01'-'02'} - {'06'-'05'-'28CC460502'} - {'06'-'05'-'28CF060303'}}"
5. ISO 7816-4 uses the term "Cryptographic mechanism identifier template" PIV uses the term "Cryptographic Algorithm Identifier Template" which is not in ISO 7816.
6. Idemia NIST approved demo card that supports SM from sp800-74-4 only adds 2 elements:
   AC 06 80 01 2E 06 01 00 i.e. is supports SM using 2E and a null OID.
7. Neither NIST or ISO appear to limit the size of the response to a select AID command.

From the above there is some ambiguity.

• 5 Different names for the same thing?
• 3 and 4 say tag 'AC' can be repeated.
• 4 says each 'AC' has one tag '80' and one or more tags of '06'
• 1 does not require or even mention 'AC'
• 2 uses the 'AC' for Secure Messaging for the '27' and '2E' tags.
• 2 also says "Each instance of tag 0x80 shall encapsulate one algorithm."
• 2 also says "but not both ('27' and '2E')" which implies there could be multiple 'AC' tags.
• Some other PIV like cards/applets don't support all the required algorithms, but that is not a problem because the algorithms can also be found from private keys in certificates.

The way I read all of this:

• The 'AC' tag should only be present if Secure Messaging is supported by the card.
• Since 3 did not require all algorithms be listed, they need not be listed in the response to SELECT. In addition the use of the symmetric algorithms are only used for card management and card management is left up to the vendor, they should not be in response to SELECT. The vendor should have other ways to determine what the card supports.
• The use of multiple tag 'AC' is allowed both by 2, 3 and 4 and ignored by 1.
• 2, 3, and 4 all say there is only one tag '80' within each 'AC'.
• 6 adds only one tag 'AC' with one tag '80' and one tag '06' which meets both the requirements of 1, 2, 3 and most of 4 and 7.

I would suggest that the code in PivApplet be simplified and do what the 6 Idemia does. Keep it short and meet the minimum requirements for the response to SELECT AID.

OpenSC/OpenSC#2053 is looking for the first 'AC' and will only look at the first tag '80' to see if its value is '27' or '2E' and ignore all other tag 'AC' or or all other tag '80' in the first tag 'AC'.

If you don't change the code but intend to support Secure Messaging at a later date, Please make sure the first tag 'AC' has a singe tag '80' with the value '27' or '2E'.

[arekinath]

Since PivApplet supports different algorithms in different builds, I've been using that AC tag to indicate which ones have been enabled and detected in the particular build and card that it's running. I understand that the spec doesn't require it, but my reading was that it doesn't say you can't do it, either, and it seems convenient to me. Do you know of any implementations which actually blow up at repeated AC tags for non-SM algos? If you know of some, that might change by mind on using it.

For now, I'll change this to multiple AC tags with one 80 in each, as you've indicated. That was my bad, misreading how the multiple instances of the tag were meant to be structured. And I'll make sure to add a note that if/when SM is supported, it should go first in the list (that seems sensible anyway).

[dengert]

This is a chicken and egg problem...

A driver would test for the 'AC' tag only if the driver supported the optional Secure Messaging defined in 800-73-4.
because this it the way the driver knows if the card supports SM or not. (800-74-4 also extends the pin policy bits and can support a "pairing" code too.)

The only cards I know of that support 800-73-4 SM are the Idemia cards, ID-One PIV 2.4.1. The vendor sent me a set. They have their own driver to support it on windows for sure, not clear if they have an Apple or Linux version. But it would most likely never be used to access any other cards. There maybe others by now and I know some US government agencies are looking at issuing these cards.

OpenSC/OpenSC#2053 is the only open source driver I know of that supports supports SM, the pin policy and the pairing code and I used the Idemia cards to test it.

I would hope other PIV Applet developers could use the OpenSC/OpenSC#2053 to implement the applet side of the SM, as it is very complicated.

The Secure Messaging is most useful over NFC or if one is worried about USB sniffers or Remote Desktop. SM can protect all the traffic including PIN. Could be useful with a phone or tablet. But most phones are Apple or Android.

So the answer is I do not know of any drivers that would choke.

[arekinath]

@dengert Yeah, I understand the situation roughly. I thought there was more than just Idemia's implementation out in the commercial world though? E.g. I thought some other physical security vendors advertised support for PIV SM when reading cards over NFC?

In any case, I'm going to continue including AC tags in the APT for now for other algorithms. pivy uses these to detect the extra proprietary algorithm IDs that PivApplet supports on JC2.2.x cards for doing hash-on-card ECDSA.

Maybe I will revisit this behaviour when removing the hash-on-card extension (which I'm considering doing at some point, since it seems like most of the JC2.2.x cards which this is useful on have pretty bad side-channel weaknesses when doing ECDSA anyway, and JC3.0.x cards are becoming very common and cheap now)

[mistial-dev]

In terms of SP-800-73-4, C.2 seems to require a singular AC tag.

"The Application Property Template, which is included in the response to the SELECT command,
optionally includes a tag 0xAC, which indicates what cryptographic algorithms the PIV Card
Application supports"

I would think that they would have said "one or more" if they wanted that to be permitted, but that's just how I read it.

[dengert]

In SP-800-73-4 part 1, C.3 "PIV Algorithm Identifier Discovery for Secure Messaging" Has the above and it says "algorithms" So there can be more then one.

Then it says: "The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite." '27' uses ECDSA p-256 and '`2E' uses ECDSA P-384. Since the SM requires the "PIV Secure Messaging key" '04' there is only one key and one "3.3.7 Secure Messaging Certificate Signer" per card.

Since NIST only defined RSA 2048 and ECDSA P-256 and ECDSA P-384 these are defined in the standards they are implied and are not required to be listed in any 'AC' tag.

The AC tag could have other algorithms but only '27' or '2E' indicate card supports SM.

The OpenSC proposed PR checks for '27' or '27':
https://github.com/dengert/OpenSC/blob/PIV-4-extensions/src/libopensc/card-piv.c#L2798-L2851

[mistial-dev]

Has the above and it says "algorithms" So there can be more then one.

I agree.

If you look at 800-73-4, table 3.1.1, it again states "Cryptographic algorithms supported", not algorithm. This means that the tag would contain multiple algorithms.

Further down, it states "Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. The encoding of tag 0xAC shall be as specified in Table 5. Each instance of tag 0x80 shall encapsulate one algorithm"

So, 0xAC contains multiple algorithms, each encapsulated in one 0x80.

In other words, the Application Property Template "optionally includes a tag 0xAC", and that tag (if present) encodes the cryptographic algorithm(s).

With secure messaging, then, you would have only one of the references 0x27 or 0x2E, but other references could be present without such restrictions.

The presence of algorithm identifier '27' or '2E' indicates that the corresponding cipher suite is supported by the PIV Card Application for secure messaging and that the PIV Card Application possesses a PIV Secure Messaging key of the appropriate size for the specified cipher suite.

Tag 0xAC shall be present and indicate algorithm identifier 0x27 or 0x2E (but not both) when the PIV Card Application supports secure messaging

This says "Tag 0xAC", which is consistent with singular usage. The use of "but not both" in that context would seem to indicate singular.

I'd respectfully disagree on your interpretation that "but not both" implies there could be multiple AC tags. The way that I'd read it would be "the card must choose one or the other, because you can't do multiple AC tags". They clearly don't want both supported on one card, and if you could have two tags, then the appropriate phrasing would be something along the lines of "a Application Property Template may not contain both '27' and '2E' cipher suites". Instead, they only constrain the AC tag to achieve their end, because there should be only one AC tag.

The GSA also considers this a ban on 0x27 and 0x2E both being present in a card, not just in a tag.

https://www.idmanagement.gov/docs/fips201ep-smocc.pdf

When Cipher Suite 2 or 7 are supported, only one is allowed. Both are not allowed on the same card, per the following:

...

Tag ‘AC’ may contain a series of ‘0x80’ tags defining cryptographic algorithms and one PIV cipher suite supported by the PIV card.

As further evidence of a singular tag, I'd point out the way that the tag is referred to elsewhere in SP 800-73-4.

If the 0xAC tag of the application property template (APT) includes '27'

If the 0xAC tag of the APT includes '2E', then generate an ephemeral key pair over Curve P-384.

Both usages are singular, and consistent with a single 0xAC tag that must contain one or the other. If multiple 0xAC tags could be present, then it should be "If a 0xAC tag in the application property template"

This continues in the command interface section:

Algorithm reference ('27' or '2E'), as specified in the 0xAC tag of the application property template

I would agree with your assessment of ISO 7816-4, and Microsoft seems to as well in their GIDS specification based upon it, but PIV is a subset of 7816-4, as we see in many areas in the standard.

[mistial-dev]

The interface test guidelines are also singular:

https://csrc.nist.rip/external/nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-85A-4.pdf

P1, algorithm reference, is set to '27' or '2E', as indicated by the 0xAC tag obtained from the application
property template in step 1

Step 1 is a SELECT command, so it would return multiple tags if present. The test guidelines say "the 0xAC tag".

All four times that tag is referenced in the test guidelines (that are not quoted from the other standards), it's used in the singular form, as a result of a SELECT.

[makinako]

From OF201's perspective:

• Lengths >= 128 are a-ok, it just needs to fit into a short-form RAPDU.
• The AC tag is conditional, which we interpret as 'Optional, but mandatory if you support PIV SM'
• AC tag is definitely intended to convey multiple algorithms Tag 0xAC encodes the cryptographic algorithms supported by the PIV Card Application. (3.1.1)
• The AC tag should only appear once, containing multiple 80h tags Each instance of tag 0x80 shall encapsulate one algorithm

For reference, this is the current OF201 FCI (145 bytes + SW12):

61 81 8F 
  4F 0B A0 00 00 03 08 00 00 10 00 01 00 
  79 07 4F 05 A0 00 00 03 08 
  50 0B 4F 70 65 6E 46 49 50 53 32 30 31 
  5F 50 49 
        68 74 74 70 3A 2F 2F 6E 76 6C 70 75 62 73 2E 6E 69 73 74 2E 
        67 6F 76 2F 6E 69 73 74 70 75 62 73 2F 53 70 65 63 69 61 6C 
        50 75 62 6C 69 63 61 74 69 6F 6E 73 2F 4E 49 53 54 2E 53 50 
        2E 38 30 30 2D 37 33 2D 34 2E 70 64 66 
  AC 1E 
     80 01 00 
     80 01 03 
     80 01 08 
     80 01 0A 
     80 01 0C 
     80 01 06 
     80 01 07 
     80 01 11 
     80 01 14 
     06 01 00 

[dengert]

https://www.idmanagement.gov/docs/fips201ep-smocc.pdf also says:

When one of 0x27 or 0x2E are present, this text states “…the PIV Card Application supports
secure messaging.” This is an incomplete view. When the APT says SM is supported by the
card, it means the card manufacturer enabled SM on the PIV card platform and the PIV applet.
It does not indicate that the issuer enabled Secure Messaging on the PIV card that is
responding to the reader/application.
This must be verified by determining if the CVC certificates and keys are present as
established by the issuer.

The way I read 800-73-4 the CVC certificate is either P256 or p384 thus if SM is to work the AC must have 0x27 or 0x2E.

My test PIV cards have AC 06 80 01 27 06 01 00

As you indicated, the specs follow ISO 7816, but are written to only require a subset be supported. What they appear to say is only a subset of algorithms i.e. (either 0x27 or 0x2E) are allowed.

Have you tried asking on the https://csrc.nist.gov/projects/piv/nist-piv-test-cards ?
David Cooper has been very responsive.

Looking at the OpenSC PR https://github.com/dengert/OpenSC/blob/PIV-4-extensions/src/libopensc/card-piv.c#L2805-L2829
it looks for either 0x27 or 0x2E and will use the first found, and skip over any other in the list, so should work with the "OF201 FCI (145 bytes + SW12):" if 0x27 or 0x2E was added anywhere in the list.