Token2 throws PIN_AUTH_INVALID when PIN Auth Protocol V2 and hmac-secret are used about python-fido2 HOT 5 OPEN

Note, I don't think this is related to the use of pinAuth sharedKey encryption on the hmac-secret salt. That part works fine, and when testing with PIN Protocol V1 that payload is sent without UV and without PinAuth token on the request and it still works as expected.

from python-fido2.

I worked out the issue. It all comes down to this line in the code.

When PinProtocol is not set on the Client when doing GetAssertion (because uv is false, verification is not required), it sets the PinUVAuthVersion parameter on the GetAssertion request to None, that the FIDO2 spec says it implies Pin Protocol V1. But during the process of encrypting the HMAC-secret salt for the HMAC-secret extension, the code uses PIN Protocol V2 (because that is the default on Token2). That puts the Token2 in a situation where the call is assumed to be using Protocol V1, but the HMAC-secret extension has used Protocol V2.

I don't really know what the solution would be for this. The ClientBackend needs to know if any of the extensions have instantiated a Pin Protocol, and ensure it matches the PIN protocol itself is currently using (or if it doesn't have one, set it).

from python-fido2.

Another thing to consider is the fact that Extensions are instantiated and processed (process_get_input()) before the ClientBackend runs _get_auth_params(), where it would normally create its own PinProtocol instance if required. This seems out of order to me. But it can't be the other way around because extensions can define permissions requirements, that are used by _get_auth_params(), so it cannot be the other way around. It seems to me that a PinProtocol instance should always be created as the first operation, then that instance is passed to each of the extensions as they require it, then that same instance is used in _get_auth_params() for creating ClientPIN if required. That would ensure the same PIN Protocol is used consistently across the whole backend.

from python-fido2.

Version 1.1.2 is now released and should hopefully resolve this.

from python-fido2.

I raised #197 before I saw this issue.

from python-fido2.