Returning not found status when security condition not required

[mistial-dev]

As a relatively minor issue, the YubiKey returns that the security status is not satisfied before checking/revealing that a Data Object is not present.

YubiKey manager uses the printed data object to store the management key in PIN-protected configurations (as it can only be read with the PIN entered), so consistent behaviour here helps ensure compatibility.

An upcoming compatibility pull request will change the behaviour to match that of the YubiKey.

			if (file == null || file.data == null ||
			    file.len == 0) {
				ISOException.throwIt(ISO7816.SW_FILE_NOT_FOUND);
				return;
			}

			final byte policy;
			if (isContact())
				policy = file.contact;
			else
				policy = file.contactless;

			if (policy == File.P_NEVER) {
				ISOException.throwIt(
				    ISO7816.SW_SECURITY_STATUS_NOT_SATISFIED);
				return;
			}

[dengert]

As a relatively minor issue, the YubiKey returns that the security status is not satisfied before checking/revealing that a Data Object is not present.

I think that is appropriate (don't expose the existing of protected objects without PIN), although I can't pin down in sp800-73 if it should return "not found" or "security status not satisfied".

YubiKey manager uses the Printed Information to store the management key in PIN-protected configurations (as it can only be read with the PIN entered), so consistent behaviour here helps ensure compatibility.

That sounds like YubiKey is not following sp800-73-4 and is messing with the definition in "Part 1, Appendix A, Table 14 Printed Information".

Some examples:

Using PIV test card 1 from original NIST Beta Test Cards, early 2004...

opensc-tool -c default -s '00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00 00' -s '00 CB 3F FF 05 5C 03 5F C1 09 00' -s 00:20:00:80:08:31:32:33:34:35:36:FF:FF -s 00:20:00:80 -s '00 CB 3F FF 05 5C 03 5F C1 09 00'
Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00
Sending: 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 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                                        ...
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x69, SW2=0x82)
Sending: 00 20 00 80 08 31 32 33 34 35 36 FF FF 
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 80 
Received (SW1=0x63, SW2=0xCA)
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x90, SW2=0x00):
53 50 01 1A 54 65 73 74 20 43 61 72 64 68 6F 6C SP..Test Cardhol
64 65 72 20 2D 20 50 49 56 20 54 65 73 74 02 08 der - PIV Test..
45 6D 70 6C 6F 79 65 65 04 09 32 30 33 30 44 45 Employee..2030DE
43 33 31 05 0A 30 30 30 30 30 31 32 33 34 35 06 C31..0000012345.
0F 54 53 54 49 53 52 33 32 30 31 36 31 37 31 39 .TSTISR320161719
FE 00 

Yubico 4:

opensc-tool -c default -s '00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00 00' -s '00 CB 3F FF 05 5C 03 5F C1 09 00' -s 00:20:00:80:08:31:32:33:34:35:36:FF:FF -s 00:20:00:80 -s '00 CB 3F FF 05 5C 03 5F C1 09 00'
Using reader with a card: Yubico YubiKey CCID 00 00
Sending: 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 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                                        ...
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x69, SW2=0x82)
Sending: 00 20 00 80 08 31 32 33 34 35 36 FF FF 
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 80 
Received (SW1=0x63, SW2=0xC3)
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x90, SW2=0x00):
53 12 01 0E 4E 45 4F 20 64 75 6D 6D 79 20 64 61 S...NEO dummy da
74 61 FE 00    

Yubico 5 NFC with no printed data:

opensc-tool -c default -s '00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00 00' -s '00 CB 3F FF 05 5C 03 5F C1 09 00' -s 00:20:00:80:08:31:32:33:34:35:36:FF:FF -s 00:20:00:80 -s '00 CB 3F FF 05 5C 03 5F C1 09 00'
Using reader with a card: Yubico YubiKey OTP+FIDO+CCID 00 00
Sending: 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 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                                        ...
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x6A, SW2=0x82)
Sending: 00 20 00 80 08 31 32 33 34 35 36 FF FF 
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 80 
Received (SW1=0x90, SW2=0x00)
Sending: 00 CB 3F FF 05 5C 03 5F C1 09 00 
Received (SW1=0x6A, SW2=0x82)

[mistial-dev]

That sounds like YubiKey is not following sp800-73-4 and is messing with the definition in "Part 1, Appendix A, Table 14 Printed Information".

Indeed. They warn about messing with it, and their SDK actually prevents you from doing so.

https://docs.yubico.com/yesdk/users-manual/application-piv/commands.html#encoded-printed

Note that the SDK does not allow putting data into the Printed tag. However, Yubico uses this tag to store information. If you GET DATA with this tag, you will likely see either no data or data that does not follow this format.

You should never overwrite the information in the Printed tag. If you do, it could make your YubiKey unusable.

[mistial-dev]

The older version of the software did some PBKDF2 stuff with a seed for PIN-protected management keys. They have switched to just storing the management key plaintext.

As an example of the data structure:

        // 0x88 = PIVMan Protected Data
        // 0x89 = Management Key
        // 0x88 0x1A 0x89 0x18 [MGMT KEY]
        final byte[] managementData = new byte[]{(byte) 0x88, (byte) 0x1A, (byte) 0x89, (byte) 0x18, 
                (byte) 0x01, (byte) 0x02, (byte) 0x03, (byte) 0x04, (byte) 0x05, (byte) 0x06, (byte) 0x07, (byte) 0x08,
                (byte) 0x01, (byte) 0x02, (byte) 0x03, (byte) 0x04, (byte) 0x05, (byte) 0x06, (byte) 0x07, (byte) 0x08,
                (byte) 0x01, (byte) 0x02, (byte) 0x03, (byte) 0x04, (byte) 0x05, (byte) 0x06, (byte) 0x07, (byte) 0x08};

[mistial-dev]

I believe the idea is that a YubiKey does not have any printed information, so that tag has no functional use or semantic value.

[mistial-dev]

This is the option in question.

[mistial-dev]

For older implementations, like yubikey-piv-manager, they stored a salt and derived it using PBKDF2.

https://developers.yubico.com/yubikey-piv-manager/PIN_and_Management_Key.html

This caused problems when changing the PIN using anything other than their tools.

Technical description of Key derivation from PIN
When choosing to use a Management Key derived from the PIN, the following takes place:
A random 8-byte SALT value is generated and stored on the YubiKey.
The derived Management Key is calculated as PBKDF2(PIN, SALT, 24, 10000).
The PBKDF2 function (described in RFC 2898) is run using the PIN (encoded using UTF-8) as the password, for 10000 rounds, to produce a 24 byte key, which is used as the management key. Whenever the user changes the PIN this process is repeated, using a new SALT and the new PIN.

The exact implementation is not overly relevant to PivApplet, in terms of compatibility. I want to avoid the application/SDK thinking that the PIN was already entered when it was not, and ensure the flow allows newer yubikey management tools to remain fully compatible, as much as reasonably possible.

If the user chooses to write a technically invalid blob of data to their card as part of the issuance process, it won't make the applet itself incompatible. If they were writing invalid data as part of their applet (rather than the client SDK), it would potentially be a significant problem.

Ultimately it is up to the user to decide if the added convenience of non-static, PIN-protected keys is worth the potential compatibility issues with software that follows and expects the standard to be followed.

[dengert]

I believe the idea is that a YubiKey does not have any printed information, so that tag has no functional use or semantic value.

True, there is no room on the token and the "Printed Information" and the object is optional.

But middleware code following FIPS201/PIV expects the printed info to be readable and follow standards.

But Yubico provide their own middleware software. So what is the point in being PIV compatible?

NIST provide for vendor administration/provisioning. So they could have provided a different file or object rather to store the management key in the "Printed Information". Who knows - maybe in the future they will sell a Yubikey "Card" and will need to use the "Printed Information" as intended.

So as a "card vendor" you can chose to use the Yubikey managment software.

[mistial-dev]

So what is the point in being PIV compatible?

To tick the checkboxes for organizations (including federal) that want it. More importantly, you can write actual PIV-compatible data to it if you want.

Essentially, you just don't use their SDK.

My personal take is that they initially did PIV-ish in order to get native support without a minidriver. It was just a way to store keys that worked on windows.

They seem to have gotten more compatible and care more about compatibility as time went on.

NIST provide for vendor administration/provisioning. So they could have provided a different file or object rather to store the management key in the "Printed Information"

I suspect that the reason they used the printed information container instead of creating a new container (like they did with attestation certs) is that they had legacy devices they wanted the mechanism to function with.

There were only so many identified data objects, so they picked one that "wasn't needed".

[dengert]

I agree with you observations.

My personal take is that they initially did PIV-ish in order to get native support without a minidriver. It was just a way to store keys that worked on windows.

Yes, Microsoft implemented special support for PIV early on, but (best I can tell) did not update it to support ECC or and sp800-73-4 featrures. Idemia and Yubico provide a plug-and-play for smartcards: https://docs.microsoft.com/en-us/windows-hardware/drivers/smartcard/smart-card-plug-and-play And they end up installing CivMinidriver64.dll and ykmd.dll respectively and add registry entries in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards

In other words, Microsoft has not (or does not need to) kept up their version of a PIV driver.

So with cards with PivApplet if you want to get ECC or non-standard algorithms you will need a minidriver. OpenSC provides this, but also requires: OpenSC/OpenSC#2053 and OpenSC/OpenSC#2523

[mistial-dev]

I can't speak for the author of PivApplet, but Secure Messaging is extremely high on my list of things to work on for it.

It comes after the test suite and compatibility fixes, however. There are some relatively minor implementation issues that make direct cooperation with YubiKey-related software difficult, and I see some of those quality of life things being a distinguishing factor between PivApplet and OpenFIPS201.

Even though PivApplet objectively works in deployment, I think that more formalized testing might help with adoption, especially when they make the issuance side of things easier.