Current PIV Answer to Select Parsing in PIV AID #45
Comments
|
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: If we replace the call with the asn1 can be parsed correctly again. Hexdump: 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. |
|
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): which runs actually already in exactly this problem: The ASN1 is malformed and should start with: 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! |
|
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. |
|
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
From the above there is some ambiguity.
The way I read all of this:
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'. |
|
Since PivApplet supports different algorithms in different builds, I've been using that For now, I'll change this to multiple |
This corrects the malformed BER-TLV being generated on some builds (when strings in the APT are long enough), and makes our APT a little closer to standards-compliant. To get back a little of the space we're paying for all the 'AC' tags per algo, we'll stop pushing quite so many into the list (just one AES, for example). See #45
|
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. 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. |
|
@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 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) |
|
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, 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. |
|
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': |
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.
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
...
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.
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:
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. |
|
The interface test guidelines are also singular: https://csrc.nist.rip/external/nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-85A-4.pdf
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. |
|
From OF201's perspective:
For reference, this is the current OF201 FCI (145 bytes + SW12): |
|
https://www.idmanagement.gov/docs/fips201ep-smocc.pdf also says:
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 ? Looking at the OpenSC PR https://github.com/dengert/OpenSC/blob/PIV-4-extensions/src/libopensc/card-piv.c#L2805-L2829 |
|
Yes now having a read through the 7816 wording is actually very clear. OF201 was implemented only from the SP800-73 wording and this is in contradiction with the ISO standard intention. This is something we need an answer on too so I've just joined the piv-test-cards group and will post the question there. |
Is it, though? In terms of "be conservative in what you do, be liberal in what you accept from others", would the current OF201 implementation actually violate ISO 7816 in any way? If PIV is read as a subset of the ISO standards, wouldn't the existing OF201 implementation be compatible with both? |
|
|
Do you know exactly what the PIV compliance tool looks at? For example if you passed in If it dose complain, it means it is parsing the list. If not, it may only look at the first entry. |
I think asking the question is absolutely the right call. My question was more if it mattered. If they come back and say "yes, you can have multiple AC tags, each with multiple 80 algorithms", would it make sense to do so? The same with whether the 0x27/0x2E has to be first in the list or not. From a consumer standpoint, it absolutely makes sense to handle the edge cases. From a producer standpoint, though, would it not make sense to do it the way least likely to cause issues? In other words, is the answer actually useful for PivApplet or OF201, or should both just try to do it the compact, sensible, compatible way? |
|
Just from a slightly different perspective, some useful reasons for having
all the supported mechanisms listed are:
- it provides the possibility of turning on and off mechanism support by
configuration. For example I don't recommend anyone use TDEA192 or RSA1024 even though they are in the standard and this is a way to advertise the
lack of it.
- The OSS PIV implementations may (do) want to break ranks and support
mechanisms without waiting for NIST to change the standard in USGOV time
scales, so advertising that we support 25519 curve, RSA3072 or symmetric
AES CMAC 128 verification by defining some extension mechanisms and putting
them in the AC tag is a useful way to go about it.
…On Fri, 8 Apr 2022, 02:59 Mistial Developer, ***@***.***> wrote:
I take your point @mistial-dev <https://github.com/mistial-dev> and true
no-one has complained yet (including the PIV compliance tool), but I've
asked the question to NIST anyway because why not and if we get a good
response it never hurts to improve!
I think asking the question is absolutely the right call. My question was
more if it mattered.
If they come back and say "yes, you can have multiple AC tags, each with
multiple 80 algorithms", would it make sense to do so?
The same with whether the 0x27/0x2E has to be first in the list or not.
From a consumer standpoint, it absolutely makes sense to handle the edge
cases. From a producer standpoint, though, would it not make sense to do it
the way least likely to cause issues?
In other words, is the answer actually useful for PivApplet or OF201, or
should both just try to do it the compact, sensible, compatible way?
—
Reply to this email directly, view it on GitHub
<#45 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHQMM7AMENO6K5LVFKV6PILVD4H7TANCNFSM4YFET4LA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
If you are going to add additional Algorithms you will want to avoid any conflicts with whatever NIST might do in the future. sp800-73-4 refers to sp800-78 for Algorithms. The latest version of sp800-78 I could find is: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf You will note that 0x05 is not defined but: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-73-1.pdf defined it as RSA 3072. Some other AES and ECC Algorithms were also defined but dropped in later version of sp800-73. So RSA 3072 would be the easy one to add. If you do add additional Algorithms to the applet, middleware like OpenSC will also need to be updated to use these. If you can coordinate with NIST or even Yubikey, it would make the middleware changes easier. |
|
We are in sync :) I've just sent an email an hour ago to NIST asking for an
indicator of any upcoming mechanism changes. Let's see what we get.
…On Fri, 8 Apr 2022, 23:01 Doug Engert, ***@***.***> wrote:
If you are going to add additional Algorithms you will want to avoid any
conflicts with whatever NIST might do in the future.
sp800-73-4 refers to sp800-78 for Algorithms. The latest version of
sp800-78 I could find is:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf
"Table 6-2. Identifiers for Supported Cryptographic Algorithms"
The way NIST define the "GENERAL AUTHENTICATE" command you are stuck with
using a single byte P1 with the Algorithm.
You will note that 0x05 is not defined but:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-73-1.pdf
defined it as RSA 3072. Some other AES and ECC Algorithms were also defined
but dropped in later version of sp800-73. So RSA 3072 would be the easy one
to add.
If you do add additional Algorithms to the applet, middleware like OpenSC
will also need to be updated to use these. If you can coordinate with NIST
or even Yubikey, it would make the middleware changes easier.
—
Reply to this email directly, view it on GitHub
<#45 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHQMM7CHLA3RIO6M4R6BUC3VEAU2ZANCNFSM4YFET4LA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Looking closer at iso7816-4 "5.4.2 Cryptographic mechanism identifier template" So I don't think this list of encoding of AC listed in previous comments is correct: It should look more like: So the algorithms IDs are what NIST specifies in the docs as there is a OID of 0. So for example sp800-78-2 "Table 3-6. ECC Parameter Object Identifiers for Approved Curves" lists: Using https://misc.daniel-marschall.de/asn.1/oid-converter/online.php If NIST wanted to, they could have added the ECC algorithms as: And if you wanted to add a Ed25519 i.e. where XX is of your choosing for the card that returns the above in the AC tag. An example with all the standard NIST defines not needed and the card also ED25519 and RSA3072 and SM 27 supported: AC 1A |
The parts you quote require first and second. The third line says "one or more", not "subsequent pairs", and uses either a mechanism or tag 06. That would be singular, would it not? At first glance, that would suggest something like this to me: |
|
ISO7816-4
I read this as "a mechanism identifier template consist of two or more data objects." |
|
We have some answers from NIST:
|
|
Looks like @dengert is correct in his interpretation. Thank you for asking the mailing list. I will change the pull request to conform. |
|
Based in statement above: "multiple AC tags in the FCI with one 80/06 tag pair each." The old version of ISO/IEC 7816-4:2005(E) says: "Table 12 lists the file control parameters, all in the context-specific class. When a control parameter is present for a file, the Table says whether it occurs only once (explicit indication), or it may be repeated (no indication)." I think my example should look like: I will update the OpenSC PR OpenSC/OpenSC#2053 |
|
The reply from NIST still sounds ambiguous to me as to whether they expect us to use a singular AC tag with multiple pairs of 80/06 inside it, or whether they expect us to use multiple AC tags, each with one singular pair of 80/06 inside. They're clear that there should be pairs of 80/06 inside AC, and it sounds like advertising more than just the SM mechs there is fine, but that particular point still seems open to interpretation to me with the sentence "How we have specified is to expect tag AC with nested 80/06 pairs each pair specifying an algorithm" ISO 7816-4 clearly expects us to have multiple AC tags with a single pair in each, but this wouldn't be the first place where NIST has deviated from a strict reading of 7816-4. I think they might be trying to say that multiple pairs of 80/06 inside one AC is allowed, but not required? If so, it sounds like they're ok with the idea of one AC tag with multiple pairs in it, but the 7816-style multiple AC tags should be fine too? If it's that, I would be inclined towards using a singular AC tag, because it's more compact and lowers the probability that there will have to be response chaining on the response to select. |
|
Who at NIST responded to the inquire(s)? I can try asking the same type of question and point out there are three of us @arekinath, @mistial-dev, @makinako and @dengert are discussing the issue on github. |
I got the reply from Hildegard Ferraiolo, though she passed it to some internal team members. For more context here is my original question on the piv-test-cards list: https://groups.google.com/a/list.nist.gov/g/piv-test-cards/c/zLaCz5l6IyQ From that and the response I got, I for one am happy to accept the answer as being a single AC tag with multiple 80/06 tags. Even though there is a slight ambiguity in the wording, If I presume they meant multiple AC tags and re-read it, the language doesn't make sense any more. Of course ask though if you want to get clarity. |
|
@arekinath, @mistial-dev, @makinako do you have a copy of ISO7816-4? I ask because it appears to me that it says Multiple 0xAC tags. Each 0xAC tag is a "Cryptographic mechanism identifier template" and the template has one 0x80 tag followed by one or more (or is it zero or more) 0x06 OID tags. Prior to 800-73-4 there was no reason to have to look for 0XAC tags in the FCI returned by SELECT. From the NIST/PIV point of view there is only one 0xAC tag enclosing one 0x80 tag with value 0x27 or 0x2E followed by one OID with value 0. But their response: "NIST: How we have specified is to expect tag AC with nested 80/06 pairs each pair specifying an algorithm" which contradicts ISO7816-4. And since they don't ever use any additional pairs, they are still following ISO7816-4. From the point of view of a PIV applet, you could follow strict PIV specification and not ever use any additional pairs either. If you still want these visible after provisioning, one way to satisfy NIST and ISO7816-4, it to make sure if card supports SM, the first 0xAC is for 0x27 or 0x2E. And if you add additional algorithms add them as additional 0xAC templates. The next issue is what middleware needs from the card. Any provisioning software which you chose to provide or any middleware needs the info somewhere or that needs to know if card supports SM. Card vendors are providing their own drivers. It appears Windows is no longer providing a Microsoft driver, and it is not clear to me what Apple is up to with MacOS. But that is there problem. From OpenSC driver prospective, I can support either, by looking for any 0xAC that has 0x27 or 0x2E and disregard the rest as they are not needed after provisioning, as the certificates SPKI is the public key which has RSA key size or ECC nameCurve OIDs that can map to the PIV algorithm IDs used in "P1" Hopefully PivApplet and OpenFIPS201 can agree on one method that still works with NIST if they decide to add more algorithms to PIV specs. Personally I would how you agree on the iso7816-4 view that a 0xAC had only one 0x80 with one OID and there can be multiple 0XAC tags present. |
|
Sent e-mail to NIST and CC: @arekinath, @makinako but could not find actual e-mail address for @mistial-dev |
I do. I purchased
My admin@mistial.dev email should show publicly on my profile. I'll look into why it's not.
The SP800-74 mechanism seems to mainly not try to break ISO7816-4, rather than actually implementing it. Using an example from the specification (for example):
ISO7816-4 allows multiple types of OIDs in the standards: encryption, MAC, authentication protocols, and digital signatures. That example includes an authentication mechanism, and a hash function. Meanwhile, SP800-74 explicitly seems to say that the OID should be blank, and the cryptographic identifier needs to come from SP800-78.
I agree with your interpretation, but NIST is only following it to a degree. They meet the first requirement, which requires the first DO to be a reference '80'. 7816-4 requires the second DO to be an OID (check), which is a cryptographic mechanism defined in a standard. A null OID isn't. 7816-4 requires further DOs to be either '06' or '0D', but not including any of them would be fine. From a pure standards standpoint, it would be nice if they allocated an OID to their own standard and used it, but they didn't. I'm not sure how to reconcile the two standards in terms of using this mechanism to advertise support.
With open PIV-compatible implementations, the "vendor" is often the end-user. The question then becomes whether to limit the user to exactly what NIST does, or allow them to go outside those boundaries in the interest of functionality.
Sadly, this is one case where the mechanism in 7816-4 could be handy. Using real OIDs would allow a local reference to be unambiguously associated with a mechanism, although there is still an issue with NIST clobbering it in the future. SP800-78 states " Table 6-2 lists the algorithm identifiers for the cryptographic algorithms that may be recognized on the PIV interfaces. All other algorithm identifier values are reserved for future use." |
|
As a thought, would it make sense to put any extra supported algorithms in a different data file, essentially? PIV uses GET DATA as 'XX CB 3F FF'. Looking at 7816-4, table 98, a P1-P2 value other than 0000 or FFFF is a file identifier. Essentially, the PIV data is all in the "3F FF" file, with tags being retrieved from there. I believe this would be a "Dedicated File" under 7816-4, which "[hosts] an application in a card". It would be possible to move any extra algorithms supported into a different dedicated file, and present the control parameter in a proper ISO7816-4 compliant format, with OIDs actually representing the underlying supported algorithm. It would not expand the PIV ATS, standard PIV devices would not need to know it existed, and would not affect their functionality at all. It would look along the lines of @dengert 's example (for ed25519):
Essentially, the applets would have "PIV mode", and "PIV plus" mode, where PIV plus more closely followed 7816-4. If the 5x50 tag were used to identify the applet or the specification supported, middleware could act upon and support it. @makinako 's examples are good ones of extensions and the reason why having that capability makes sense. Some orgs (for example) prefer ED25519, and I've seen policies that required secp256k1 over secp256r1, for example. Having it as a separate DF would allow such functionality to be hidden from standard PIV implementations (for example, the windows built-in driver), but still allow its use with PKCS11 or custom drivers. |
The end-user still needs administrative tools to administer the card. You will need to address all the issues Yubico has addressed as they have extended the ability of the end user to administer their own card by providing administrative tools. NIST does provide some administrative commands, including generating a key pair on the card. But it does not define how to load an external key. (And the card does not store the public key directly, but returns it in responds to generate key pair.) The OpenSC piv-tool is not a Card Management System, but provides the bare bones set of NIST defined commands that could be part of a CMS. It does support authentication using 2DES, 3DES and AES administration keys. It can store on disk the public key, that can then be used in a CSR that is then signed by the token. OpenSC PIV driver, if called by PKCS11 or Minidriver could be modified to store in memory the results of a generate keypair that could then be used in a later call to retrieve it from memory. This would be an easy change. But providing the administrator key would be more difficult. (Personally I have no interesting in creating a CMS but am open to making the changes for PKCS11 and Minidriver. |
|
I am working on an open source CMS, and will be releasing with support for YubiKey and PIV Applet, at a minimum. I hope to also support Open FIPS 201, but haven't looked into that side of things. It's definitely a missing piece of the puzzle, and getting a GUI that is functional, secure, and usable is an interesting challenge. I don't think the YubiKey manager goes quite far enough in terms of functionality beyond changing PINs and loading keys/certs. |
|
With YubiKey 5.3+ you can use get metadata to get the public key. https://docs.yubico.com/yesdk/users-manual/application-piv/commands.html#get-metadata Attestation should work on older firmware as well, I believe, as the cert is issued to the public key. PIVApplet supports the attestation interface, and the PR I'm putting together implements full 5.3 API compatibility as well. I don't think it technically violates NIST standards to have the public key compatible, and attestation makes things like rekey/recert much easier for a CMS. If I have a way to get supported algorithms, I will use it to filter commands for generate and import. PivApplets build flags also allow this, but I like the OF201 dynamic approach better. It's a good idea. |
@mistial-dev Regarding your suggestion for a different DF to describe mechanisms, this is something @arekinath suggested and I like the idea of. OF201 will soon have data object and key enumeration, so adding supported mechanisms makes sense and why not make it a 80/06 pair with real OID's? Perhaps to avoid making the response too large we could only populate the OID's for non-vanilla PIV mechanisms. |
|
Some other tidbits... One thing Yubikey-piv-tool does have is the ability to create a PIV CHUID object with action "set-chuid". sp800-73 does not define a serial number. OpenSC use the CHUID's FASC-N or GUID to create a serial number. Both OpenSC and the original Microsoft PIV driver endup using the CHUID's FASC-N or GUID for container names on windows. Yubikey-piv-tool can also create a CCC with "set-ccc"
I agree. Two years ago I wrote a PR for OpenSC to use the Yubikey attestation to get touch policy. But no one was interested it. See https://github.com/dengert/OpenSC/tree/ Also note OpenSC uses PivApplet and yubico-piv-tool is github actions when a PR is submitted. https://github.com/OpenSC/OpenSC/blob/master/.github/test-piv.sh |
|
If you are interested, before I retired, we where just implementing a way to use temporary PIV cards to be used to login to AD for people who forgot their card at home, lost cards, broken cards or for employees who where waiting to get a government issued card. This is all based on OpenSC's piv-tool and bash scripts. It also contains some other utility programs to encode/decode a FASC-N, create/show a CHUID and display the facial image object. Contact me via e-mail. |
|
Looking through the NIST comments, Obethur asked specifically about the algorithm specification (OT-32):
NIST's response was vague:
They seemed to feel this resolved the question, changing it from the earlier statement Clear as mud.
I think that's quite reasonable. As the Obethur comment pointed out, there's little reason to waste space on responses that do not provide useful information. |
I also agree. NIST is only using the tag AC as a flag that SM is supported by the card. And SP 800-78 defines the mapping for algorithms supported by NIST and is referenced in SP 800-73-4 for PIV cards. So beware of using 0xED as NIST may pick it in the future. |
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 4Fis parsed as tag=61 len=4F with next tag as 06.But the it looks like it should have been
61 81 81with tag=61 len=81 and next tag =4FAnd 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.
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 00i.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.
The text was updated successfully, but these errors were encountered: