Feature Request: Stricter Contactless/Split Brain

[mistial-dev]

Putting this here to see if it's something that would be useful for mainline PivApplet. If it's something that would add value, I'll put a pull request in with my code.

Slot 9e by default doesn't require a PIN. When connected to a host, this presents a potential attack vector for untrustworthy software on the host.

I have a feature flag that essentially sets up a split brain environment, where only 9e can be done over contactless, and additionally 9e cannot be used over a contact interface (given its lack of PIN).

[dengert]

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf says:

3.1.4 X.509 Certificate for Card Authentication FIPS 201 specifies the mandatory asymmetric Card Authentication key (CAK) as a private key that may be used to support physical access applications. The read access control rule of the corresponding X.509 Certificate for Card Authentication is “Always,” meaning the certificate can be read without access control restrictions. The PKI cryptographic function (see Table 4b) is under an “Always” access rule, and thus private key operations can performed without access control restrictions.

It was designed to be used either over contact or contactless interface.

So if you are trying to use the 9E key for anything else it does not meet the specs.

If you want more keys and certificates OpenSC has support for using the "Retired X.509 Certificate for Key Management" keys for other purposes. This requires the "Key History Object" to be present and setup correctly to say how many keys are present on the card.

It OpenSC the "Card Holder Unique Identifier" must not have a FASC-N issued by gov agency. In this case it it will use the keyUsage from the certificate to specify how the key can be used.

(I am not sure if PivApplet supports these or the history object.)

[arekinath]

That seems like a very strange thing to be concerned about -- the whole idea of the 9E key is that it's used only to verify the card itself: you don't put an actual user certificate in that slot. What are you trying to do that you're concerned about host software using it? Some kind of relay attack where malware installed on the host relays APDUs to the card which originated on a physical access control reader?

[dengert]

Another point to consider for: "where only 9E can be done over contactless".

The card knows it is using contact or contactless but an attacker could switch a the reader from a contact reader to a contactless reader to gain access to the 9E key. This means the host middleware would also have to enforce no 9E usage over contact interface. But an attacker with a special reader or relay attack could trick the host so it could not tell if it is contact or contactless reader. This might require the attacker to have physical access to the host, its usb port, the reader and/or the card.

[mistial-dev]

Some kind of relay attack where malware installed on the host relays APDUs to the card which originated on a physical access control reader?

That is precisely the concern, and it's not an entirely theoretical attack, unfortunately.

[mistial-dev]

It was designed to be used either over contact or contactless interface.

Yes. This would be a non-standard extension.

So if you are trying to use the 9E key for anything else it does not meet the specs.

Yes. Like the custom touch and PIN policy YubiKey extension, which can violate the standards depending on how it is configured. This is another slot policy extension to cover specific use cases.

Kind of like PIVApplet without PIV_STRICT_CONTACTLESS enabled. Non-standard, but sometimes useful.

If you want more keys and certificates OpenSC has support for using the "Retired X.509 Certificate for Key Management" keys for other purposes. This requires the "Key History Object" to be present and setup correctly to say how many keys are present on the card.

We're using that to store some intermediate CAs. This is purely a security thing.

We don't want a phishing attack to turn into an opening for a PACS attack. Devices like the Proxmark 3 (with Bluetooth) are relatively easy to use for that kind of attack, especially with Android devices.

The issue gets even worse when a reader (by poor design or exploit) uses predictable challenges.

It OpenSC the "Card Holder Unique Identifier" must not have a FASC-N issued by gov agency. In this case it it will use the keyUsage from the certificate to specify how the key can be used.

We're mostly using PIV-I standards, so the FASC-N starts with a bunch of 9s. Is this the situation you are talking about?

[mistial-dev]

The card knows it is using contact or contactless but an attacker could switch a the reader from a contact reader to a contactless reader to gain access to the 9E key.

The specific concern here is for an organization that uses the cards for Single Sign-On. The badge is used to enter the facility, placed into a reader (for example, a dell contact-only keyboard reader), and removed when leaving the desk.

The reader in question would be contact-only.

This means the host middleware would also have to enforce no 9E usage over contact interface.

Why? It's the built-in Windows PIV support. If the reader is contact, as I understand it even a driver change in windows would not allow the card to be fooled into thinking it's a contactless reader.

But an attacker with a special reader or relay attack could trick the host so it could not tell if it is contact or contactless reader.

I have some readers that do both contact and contactless right next to each other. If one took out the separation between the two, and put some custom firmware on it, and created some custom middleware that sent the correct cert to the correct interface, then yes the card could be fooled into performing contactless-only slot actions.

That's not the threat model for this particular extension. It's a person with reasonable access levels opening a phishing email, or plugging in an infected USB stick, either at home, or at the facility.

Given the use of PIV for TLS authentication and S/MIME, there will be a number of users inserting cards at home, and those devices won't need MDM to decrypt their email.

[dengert]

We're mostly using PIV-I standards, so the FASC-N starts with a bunch of 9s. Is this the situation you are talking about? Yes, missing FASC-N or starts with 99999 is non gov issued.

I can see your point with the Proxmark 3. Malware on user's computer could misuse the 9E key, but can also also steal PIN or misuse other keys on the card. Have you discussed the issue with NIST?

[mistial-dev]

I can see your point with the Proxmark 3. Malware on user's computer could misuse the 9E key, but can also also steal PIN or misuse other keys on the card.

That is absolutely true, and while windows has taken some care to prevent that being too easy, I'm aware of middleware that takes additional security measures to try to prevent it.

Unfortunately, my role in this particular initiative is focused more on the physical access control and CA side of things. By and large we won't have control over the desktop environment, and our goal is to shore up the security on the PACS side. Many of the deployed cards will likely be used in FIDO2 mode, rather than PIV, for logical.

At the end of the day, the organizations we have talked to don't want to issue two credentials, or rip and replace, so we're trying to provide something that is extensible, fully open source, and still reasonably secure.

Have you discussed the issue with NIST?

I'd love to. Do you have a particular person or department you would recommend speaking to?

[dengert]

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf says :

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: piv_comments@nist.gov

https://csrc.nist.gov/Projects/piv/nist-piv-test-cards has the lead author's e-mail as well as a mail list for test cards.

And you can get the author's email from google that leads to: https://www.nist.gov/people/david-cooper

I suspect all of these will get to David Cooper.

[mistial-dev]

Thank you. I will reach out.

[arekinath]

I suspect a real long-term fix for this in PIV probably needs something like SM (perhaps with better reader authentication?) combined with time-of-flight restrictions in the style of the DESfire EV2 proximity check.

When your threat model includes existing readers that can barely manage to competently implement the current signature check, and which you can't easily upgrade... that just looks like a pipe dream, though.

I'm not entirely opposed to having this hack available as an option. I am tempted to suggest instead, though, having an option which separates the contactless and contact keys so that they can be entirely different. My reasoning being that I would not like to discourage host software from using 9E to verify the device still (e.g. challenging it before allowing the user to enter their PIN). I know Windows doesn't do that today without a modified minidriver, but I would prefer to encourage it as much as possible.

My reading of the spec seems to suggest that it does allow for "separate chip" implementations of PIV where the contactless interface is a totally different card... this would be not quite that (since most objects like the CHUID and possibly some of the certs will still be shared), but it feels like an easier sell to me. So, we would let you configure it so that all the objects other than the 9E cert are shared between interfaces, and then you could still have a key in 9E/contact useable by host software with a cert that just wouldn't validate for PACS.

Obviously, compile-time options for something that detailed would be annoying -- but I have been thinking of moving towards a bit more run-time configuration for things like this, anyway. Myself and some of the other developers of open-source PIV card implementations have been discussing a more common admin interface for changing properties like this during pre-personalisation.

[mistial-dev]

I am tempted to suggest instead, though, having an option which separates the contactless and contact keys so that they can be entirely different.

That would work as well, indeed.

but I have been thinking of moving towards a bit more run-time configuration for things like this, anyway.

I have some patches that I'm QCing along those lines in terms of install parameters. The first one is to set the serial number, but it would be easy enough to set split brain as an install parameter.

If you would like, I'll rebase to origin/master and push something to the fork to look at. Your approach would work absolutely fine for our needs, and avoid breaking anything on either the logical or physical side.

Interestingly (and useful from our standpoint), splitting the management key for contact and contactless would allow the static use in PACS (similar to the HID temporary cards), while allowing the customer to change the certs on the logical side.

[dengert]

One other possibility.

800-73-4 has support for Secure Messaging and VCI which can use an optional pairing code. The pairing code is only needed to create the VCI which is used over the contactless interface via SM. The pairing code may or may not be readable via the contact interface it up to the card issuer on how pairing code it transmitted to the user. So if it can not be read from the card and only needed when using contactless, it might be usable in your situation as the pairing code is never used on user's PC. But this requires the user to present the card and the pairing code to your PACS device.

PivApplet does not support SM or VCI at this time, but OpenSC has a PR https://github.com/OpenSC/OpenSC/pull/2053 that implements it and could be used for testing any PivApplet implementation.

This would then allow your PACS to work with NIST approved cards that support SM.

In addition to the one card mentioned in the PR, Idemia has a set of 5 test cards that have various combinations of pairing code configurations.

[mistial-dev]

I was under the impression that the pairing code was available over the contact interface.

NIST's slides on it states that it can be read from the card.

https://csrc.nist.gov/csrc/media/events/ispab-june-2014-meeting/documents/ispab_jun2014_pairing-code_cooper.pdf

Looking through 800-73-4, I see the pairing code reference container

3.3.8 Pairing Code Reference Data Container

The Pairing Code Reference Data Container, which shall be present if the PIV Card supports the virtual contact interface, includes a copy of the PIV Card’s pairing code (see Section 5.1.3). The Security Object enforces integrity of the Pairing Code Reference Data Container according to the issuer

The pairing code value for a PIV Card shall be stored in the Pairing Code Reference Data Container (see Section 3.3.8) on the card and may be printed on the back of the card in an agency-specific text area (Zones 9B or 10B). PIV Card Issuers may choose to provide the pairing code value to the cardholder in another manner, such as printing it on a slip of paper, rather than printing it on the back of the card.

The table shows the access over contact as "PIN or OCC". PIN is certainly a step up, though software on the host can presumably steal that, but on card comparison is less useful.

VCI on anything purpose-built makes a lot of sense (and is something I want to contribute back to PIVApplet). We've ordered both the gen1 and gen2 NIST test cards, and will be working on that.

VCI helps with skimmers, but it's going to be less useful with existing readers that do PKI-CAK and send the 200 bit FASC-N bitstream over the wiegand lines.

[mistial-dev]

As far as the split chip emulation goes, there is unfortunately a part of the standard that denies it.

For dual chip implementations, for any container that can be accessed over both the contact interface and the contactless interface (including the virtual contact interface) the data object shall be copied into the corresponding containers on both chips. 11

Specifically, for the CAK (which we use for PINless stuff)

11 As a consequence of this requirement, any keys that have to be generated on card cannot be made available over the contactless interface (including the virtual contact interface) in a dual chip implementation. In addition, the asymmetric CAK needs to be generated off-card and loaded onto both chips for dual chip implementations.

[dengert]

You are right the pairing code can be read over contact so attacker could read it. Sorry.

[mistial-dev]

You are right the pairing code can be read over contact so attacker could read it. Sorry.

The idea, from what I can tell, is to ensure that contact enrollment and contact PIN+CAK is available.

If the PIN is being validated on card, we are essentially validating the user more than the card, and I don't personally see the value in CAK+PIV Auth vs just PIV Auth. With PIV Auth VCI+contact, it's available for PIN+PKI and can be used for PACS, as long as the system is set up to permit it.

It's entirely possible that not having CAK over contact would break something horribly, but I can't think what that case would be.

[dengert]

The idea, from what I can tell, is to ensure that contact enrollment and contact PIN+CAK is available.

Windows sign-on does not depend on the 9E key, it will work with just the 9A key and certificate and the CHUI, which is used to get the FASC-N or GUID to use as a container name. (PIV does not define a serial number.)

800-74 defines what PIV card must support. NIST left card management/provisioning up to card vendors. It also left up to card issuers what they wanted on the card. And NIST has an approval process for PIV cards. Note the use of "Global PIN" in 800-74. as many of the approved cards are Global Platform based.

The fact that you are looking at PivApplet (which AFAIK is not approved and may never be) and modifying it implies you are not concerned about using NIST approved cards issued by gov agencies. If you are, contact NIST about you issue. They may have a way around it.

There are other "PIV-like" devices on the market, Yubikey and PIVKey for example, that provide their own tools to provision a card. Approved card vendors also provide ways to provision their cards. They also bend the standards, for example allowing full access over contactless or allow the "PIN Always" to be turned off.

So if you don't allow the use of the 9E key on contact but do allow it on contactless you might be sacrificing some card management function. But I doubt it. If you also do not allow access to the 9E certificate most if not all middleware with assume it is not present. The only real use of the 9E key I know is for physical access. (800-73-4 part 1 Appendix B.) So all your PACS devices would have to be contactless,

The VCI and SM were added to protect against sniffing the contactless traffic, making it easier to use the cards with phones and tablets. But SM can also be used to protect against USB logging.

[arekinath]

As far as the split chip emulation goes, there is unfortunately a part of the standard that denies it.

For dual chip implementations, for any container that can be accessed over both the contact interface and the contactless interface (including the virtual contact interface) the data object shall be copied into the corresponding containers on both chips. 11

Yeah, I wasn't suggesting that this feature would be actually compliant with the spec for dual-chip implementations, but it seems like less of a stretch to me than messing with the security condition rules. Plus it avoids punishing anyone who wants to use the 9E key in the way I was talking about.