Explicitly reject FIDO applet over contact (USB CCID) interfaces at SELECT time

[micolous]

Currently, Trussed on the NitroKey 3 and SoloKeys Solo 2 returns "success" FIDO applet selection, but then returns 0x6985 (conditions of use not satisfied) to every command sent thereafter:

SELECT a0000006472f0001
>>> 00a4040008a0000006472f000100
OK "U2F_V2"
<<< 5532465f56329000

CTAP2 getInfo
>>> 80100000010400
ERROR: Conditions of use not satisfied
<<< 6985

This appears to come from here:

fido-authenticator/src/dispatch/apdu.rs

Lines 44 to 48 in 7bd0c3b

	// FIDO-over-CCID does not seem to officially be a thing; we don't support it.
	// If we would, need to review the following cases catering to semi-documented U2F legacy.
	if interface != apdu::Interface::Contactless {
	return Err(Status::ConditionsOfUseNotSatisfied);
	}

By comparison, YubiKey's USB CCID implementation explicitly rejects the SELECT command with 0x6a82 (File or application not found):

SELECT a0000006472f0001
>>> 00a4040008a0000006472f000100
ERROR: File or application not found
<<< 6a82

I believe that YubiKey's behaviour follows the intent of the public parts of the FIDO specification¹. CTAP 2.1 § 11.3.2 Protocol states that "Authenticator replies with success if the applet is present", which while the applet is technically present, it's not actually usable over non-contactless interfaces. There is no consideration given in the specification to a potential distinction – so I don't think that Trussed is following the intent of the specification.

Trussed could error out here on contact interfaces instead:

fido-authenticator/src/dispatch/apdu.rs

Lines 31 to 34 in 7bd0c3b

	fn select(&mut self, _: &Command, reply: &mut Data) -> apdu::Result {
	reply.extend_from_slice(b"U2F_V2").unwrap();
	Ok(())
	}

Impact of this issue

CTAP implementations which support smart-card interfaces cannot treat presence of the FIDO applet as usability of the FIDO applet, which makes set-up more complicated and enumeration slower.

They may also need to blocklist Trussed security key vendors by their USB CCID device name to avoid touching a useless interface, but this is not a particularly scalable solution for firmware which is intended to be adopted by multiple vendors, especially if that vendor has switched firmware implementation in the past (where the USB CCID interface may actually work) or the vendor also manufactures smart card interfaces.

Alternatively, they may need to allowlist "real" contact/contactless interfaces, which is even less scalable... 🙃

Footnotes

1. There is apparently some secret FIDO documentation which says that one should disable the FIDO applet over USB CCID (to avoid a security issue on ChromeOS), but there's no further details on how an implementation should do this. ↩