Want support for PIV SM/VCI

[arekinath]

It would be pretty neat to support the PIV secure messaging system as specified in 800-73-4 part 2 section 4. With support for that, we could also have VCI for contactless, which would be very useful for allowing contactless access to certs.

There are some examples in the spec under section A.6, but they're not complete and don't really give you test vectors for the authcryptogram that could be used to validate an implementation.

I also can't find any open-source implementations of a client for talking to PIV SM to validate against, which might make developing this quite tricky.

In a comment on #15, @dengert says they have acquired a card which supports SM, which would enable writing an open-source client which could then in turn be used to validate this applet. Not sure how that effort has been going though.

[dengert]

The support for (optional) SM/VCI in NIST 800-73-4 PIV in OpenSC has stalled. I asked around and no one has asked for it. NIST instead has focused on Derived PIV/CAC Credentials for mobile devices such as phones and tablets. Practically, this means the user does not have to get their PIV card out and hold it next to phone and enter a pin every time they want to use it.

The Executive Summary is quite good: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-157.pdf
Or Google for: NIST derived PIV

[martinpaljak]

I assume (no time to dig into specs at the moment) the "VCI" part is much like authentication with PACE and CAN (Card Access Number) in EU, for secure RF interface?

[arekinath]

@martinpaljak Yes, comparable to PACE/CAN as I understand it. In 800-73-4 they specify VCI ("virtual contact interface") as the combination of SM (secure messaging, where you do ECDH between a static signed key on the card and an unverified ephemeral key on the host to establish keys and then encrypt the traffic to/from the card after that) and a "pairing code" which can be printed on the card to prevent skimming attacks.

@dengert It seems to me like SM/VCI is still useful even if you have a derived PIV credential separately? 800-157 certainly seems to imply that itself when it talks about the methods to provision a derived credential. I hope they come back to it soon -- personally I would like to see more NFC features, like a specification for latency measurement inside the secure tunnel in the style of DESFire EV2's proximity check to prevent forwarding of PIV traffic over long distances.

[dengert]

@martinpaljak I am not sure. This leads to a download: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf There are 3 parts in the one PDF. NIST tends to write detailed requirements and does not reference other non-US government standards. I believe the SM is standard, but NIST spells it out.

"5.5 Virtual Contact Interface
The term virtual contact interface (VCI) is used in this document as shorthand for a security
condition. As described in access control rules in this document and in Part 2, all non-cardmanagement operations that are allowed over contact interface may be carried out over the
contactless interface if the VCI security condition is satisfied. Support for the VCI is optional."

[dengert]

I started to look at what I had in 2018 for VCI/SM in OpenSC, will see how far I get.

[frankmorgner]

The key establishment for PIV is very easy, but it's no mutual authentication as in PACE with a shared secret. Only the card's key is authenticated. This is identical to CAv2 (which is embedded in EAC to assure mutual authentication) or Opacity ZKM.

@dengert, the formatting itself is identical to what we have already implemented in sm-iso.c, so you only need to implement the crypto callbacks

[dengert]

And where are sm-iso.c and CAv2 and EAC?

Note: NIST 800-73-4 4.1 The Key Establishment Protocol says:
"The key establishment protocol for the PIV Card Application uses the One-Pass Diffie-Hellman, C(1e, 1s, ECC CDH) Scheme from [SP800-56A] in a manner that is based on a simplified profile of OPACITY with Zero Key Management [ANSI504-1], as depicted below."

So it says it is based on OPACITY but not the same.

Since last week, (4 days ago) I went back to the code I started in 2018 using a PIV card from 2018, and have gotten to step H9 in the Client Application. Card accepts my request, and I have created a shared secret Z. Next is to derive 4 AES keys, check the AuthCryptogram. Then use existing SM hooks and code in OpenSC with APDUs.

I have the NIST (free) manuals, Free but not the expensive ANSI504-1 manual.

[frankmorgner]

Maybe a bit off topic, I've sent you an e-mail.

[mistial-dev]

YubiKey has implemented Secure Channel into their newer devices.

https://docs.yubico.com/hardware/yubikey/yk-5/tech-manual/yk5-overview-5.4.html#secure-channel-label

https://docs.yubico.com/hardware/yubikey/yk-5/tech-manual/yk5-secure-channel-diverse-key-programming.html#yk5-secure-channel-diverse-key-programming-label

They are using the ISD to handle it, which makes it much easier on the applet.

% java -jar gp.jar --mode mac --mode enc --mode rmac --mode renc --debug --info 
SCardConnect("Yubico YubiKey FIDO+CCID", T=*) -> T=1, 3BFD1300008131FE158073C021C057597562694B657940
# GlobalPlatformPro
A>> T=1 (4+0000) 00A40400 00 
A<< (0025+2) (2ms) 6F178408A000000151000000A50B730906072A864886FC6B01 9000
A>> T=1 (4+0000) 80CA9F7F 00 
A<< (0045+2) (2ms) 9F7F2A4090211F90D9C9B842F04DC82294328246AADB0B18375F2764013DC18B634F06B4558F78AB11A6628B55 9000
[WARN] GPData - Invalid CPLC date: C9B8
[WARN] GPData - Invalid CPLC date: 4DC8
[WARN] GPData - Invalid CPLC date: 1837
[WARN] GPData - Invalid CPLC date: 6401
[WARN] GPData - Invalid CPLC date: 8B63
[WARN] GPData - Invalid CPLC date: AB11
CPLC: ICFabricator=4090
      ICType=211F
      OperatingSystemID=90D9
      OperatingSystemReleaseDate=C9B8 (invalid date format)
      OperatingSystemReleaseLevel=42F0
      ICFabricationDate=4DC8 (invalid date format)
      ICSerialNumber=22943282
      ICBatchIdentifier=46AA
      ICModuleFabricator=DB0B
      ICModulePackagingDate=1837 (invalid date format)
      ICCManufacturer=5F27
      ICEmbeddingDate=6401 (invalid date format)
      ICPrePersonalizer=3DC1
      ICPrePersonalizationEquipmentDate=8B63 (invalid date format)
      ICPrePersonalizationEquipmentID=4F06B455
      ICPersonalizer=8F78
      ICPersonalizationDate=AB11 (invalid date format)
      ICPersonalizationEquipmentID=A6628B55

A>> T=1 (4+0000) 80CA0042 00 
A<< (0000+2) (1ms) 6A88
A>> T=1 (4+0000) 80CA0045 00 
A<< (0000+2) (1ms) 6A88
Card Data: 
A>> T=1 (4+0000) 80CA0066 00 
A<< (0051+2) (2ms) 6631732F06072A864886FC6B01600C060A2A864886FC6B02020301630906072A864886FC6B03640B06092A864886FC6B040360 9000
Tag 6: 1.2.840.114283.1
-> Global Platform card
Tag 60: 1.2.840.114283.2.2.3.1
-> GP Version: 2.3.1
Tag 63: 1.2.840.114283.3
Tag 64: 1.2.840.114283.4.3.96
-> GP SCP03 i=60
Card Capabilities: 
A>> T=1 (4+0000) 80CA0067 00 
A<< (0000+2) (1ms) 6A88
A>> T=1 (4+0000) 80CA00E0 00 
A<< (0020+2) (1ms) E012C00401FF8810C00402FF8810C00403FF8810 9000
Version: 255 (0xFF) ID:   1 (0x01) type: AES          length:  16 (AES-128, factory key)
Version: 255 (0xFF) ID:   2 (0x02) type: AES          length:  16 (AES-128, factory key)
Version: 255 (0xFF) ID:   3 (0x03) type: AES          length:  16 (AES-128, factory key)

Warning: no keys given, defaulting to 404142434445464748494A4B4C4D4E4F
SCardDisconnect("Yubico YubiKey FIDO+CCID", true) tx:35/rx:155

[dengert]

Note that NIST sp800-73-4 defines a version of SM, VCI and Pairing for use by the end user over contactless(NFC), but can be used over the contact interface. Part 2 Section 4.1 "The Key Establishment Protocol" is based on ECC CDH and a simplified profile of OPACITY, where the card has the certificate and private key.

Yubico implemented SCP03 to be use for key management with static keys.
(The key derivation is based on a master key for a batch of devices and some data returned by the card that derives the static keys based on: https://csrc.nist.gov/publications/detail/sp/800-108/final)
Then the keys can be changed on the card by the CMS.

NIST sp800-73-4 leaves it up to the card vendor on how to manage the cards. For example It does not define how to load keys.

The GlobalPlatform SCP03 is not the same as PIV SM. A card could support both but they are intended for different purposes.

[mistial-dev]

@dengert I was speaking more as a workaround for some of the functionality (contactless cert access), not saying they are the same thing. I apologize for the lack of clarity in my comment.

PivApplet already implements most of the Yubikey extensions, and it would be possible to do a version of the strict contactless applet that could treat a secure channel like PIV cards can implement VCI.

Such an approach would allow secure on-card PIN validation over contactless, for example.

[mistial-dev]

It looks like vSEC:CMS does PIV VCI.

https://versasec.zendesk.com/hc/en-us/articles/360017812800-PIV-Settings

I should have access to that software for testing, if I can figure a card out that works with it.

[dengert]

https://versasec.zendesk.com/hc/en-us/articles/360017812800-PIV-Settings also says:
"For the management of Oberthur tokens and tokens that use OpenPIV applet it will be necessary to have knowledge of the card manager key for those tokens. This will be required for secure messaging when operating on these tokens."

So again, this is an example of a vendor (Oberthur now called Idemia) and OpenPIV applet and how to do card management.

Idemia has the ID-One PIV 2.4 (NIST approved) smart cards that support PIV SM, VCI, Pairing and fingerprint authentication on card as defined in 800-73-4. I have some of there test cards and used them to test the OpenSC driver (its a PR) that does the SM, VCI, and Pairing. I was informed that PIV SM could be used for some card management, but now writing of keys. That would would use something else. I believe it would be SCP03.

I am not sure what is OpenPIV. There is https://github.com/OpenPIV but this appears to be for "Particle Image Velocimetry". https://pivkey.com/index.html from Taglio also sells PIV-like cards and token also used zendesk for support service as does versasec.

So what I am saying, is there are two SM systems, the PIV SM in 800-73-4 that is used by users mostly for VCI over NFC to the card and vendor provided SM which varies be vendor and used in card management systems. 800-73-4 does hint at Globalplatform cards, so SCP02 (for older cards) and SCP03 (for newer cards) may be common.

[dengert]

More on this subject after playing golf today.

[arekinath]

It seems like Yubico are doing SCP03 for management commands (though it's still unclear if they plan to require it, or even provide a way to make it required for issuing admin commands?). In this they're matching a couple of commercial PIV manufacturers, and also the OpenFIPS201 applet (though of course the actual admin commands you send to each of those are different). The PIV standard, to my knowledge, doesn't constrain implementors very much at all on how their admin commands and interface work, so using or requiring SCP03 for admin auth seems fine to me from a compliance perspective (and the PIV admin auth already requires a shared secret anyway).

It also seems like based on the docs that Yubico are allowing (but not necessarily pushing?) use of SCP03 for regular non-admin commands. This is unusual. The docs are a little vague so it could be that they only really mean it to be used for admin, and this is kind of accidentally added.

Most other manufacturers seem to be going with PIV SM for use-cases where secure messaging is desired for non-admin commands, which you'd expect, given that the standard promotes it specifically for that use case (and particularly for VCI). Using SCP03 for non-admin commands would be unexpected, and if it was meant to form part of the security condition for access to read objects, it would not be really compliant with the PIV spec.

I meant this bug to be specifically about implementing PIV SM, not SCP03/GP secure channel. I'll open another bug for GP SC support, since it would be nice to keep up with compatibility with YubicoPIV, but I would like to continue using this issue specifically for discussing adding PIV SM support, if that's ok.