Implement PIN protocol two

Author: BryanJacobs

README.md

@@ -59,18 +59,19 @@ I suggest [reading the FAQ](docs/FAQ.md) and perhaps [the security model](docs/s
 |--------------------------------|---------------------------------------------------------|
 | CTAP1/U2F                      | Not implemented                                         |
 | CTAP2.0 core                   | Implemented, many caveats                               |
+| CTAP2.1 core                   | Incomplete - missing PIN token permissions              |
 | Resident keys                  | Implemented, default 50 slots                           |
 | User Presence                  | User always considered present: not standards compliant |
 | Self attestation               | Implemented                                             |
 | Attestation certificates       | Not implemented                                         |
 | ECDSA (SecP256r1)              | Implemented                                             |
 | Other crypto like ed25519      | Not implemented                                         |
 | CTAP2.0 hmac-secret extension  | Implemented                                             |
-| CTAP2.1 hmac-secret extension  | Not implemented (one secret, requiring UV, not two)     |
+| CTAP2.1 hmac-secret extension  | Implemented with one secret, requiring UV, not two      |
 | CTAP2.1 alwaysUv option        | Implemented                                             |
 | CTAP2.1 credProtect option     | Implemented, one caveat                                 |
 | CTAP2.1 PIN Protocol 1         | Implemented                                             |
-| CTAP2.1 PIN Protocol 2         | Not implemented                                         |
+| CTAP2.1 PIN Protocol 2         | Implemented                                             |
 | CTAP2.1 credential management  | Implemented                                             |
 | CTAP2.1 enterprise attestation | Not implemented                                         |
 | CTAP2.1 authenticator config   | Not implemented                                         |

docs/FAQ.md

@@ -56,14 +56,29 @@ CTAP2.1 standard says it's okay to return level three if two was requested,
 but that breaks OpenSSH, so... credProtect is incorrectly implemented in
 that it always applies level three internally.
 
-Finally, the CTAP API requires user presence detection, but there's really no
+Thirdly, the CTAP API requires user presence detection, but there's really no
 way to do that on Javacard 3.0.4. We can't even use the "presence timeout"
 that is described in the spec for NFC devices. So you're always treated as
 being present, which is to some extent offset by the fact that anything real
 requires you type your PIN (if one is set)...
 
 So set a PIN, and unplug your card when you're not using it.
 
+Fourthly, the CTAP2.1 standard says that credential matches should be performed
+in most-recent order, but to save implementation complexity and runtime performance,
+this implementation does them in arbitrary order instead.
+
+Finally, the CTAP2.0 and CTAP2.1 standards are actually mutually incompatible. When
+a getAssertion call is made with an `allowList` given, CTAP2.0 says that the
+authenticator should iterate through assertions generated with the matching
+credentials from the allowlist. CTAP2.1 says the authenticator should pick one
+matching credential, return an assertion generated with it, and ignore any
+other matches.
+
+This implementation allows toggling either behavior by flipping a boolean in the
+code, but because one or the other must be chosen, it can't be both fully CTAP2.0
+compatible and CTAP2.1 compatible at the same time.
+
 ## Why don't you implement U2F/CTAP1?
 
 U2F doesn't support PINs, and requires an attestation certificate.