fido2-net-lib
fido2-net-lib copied to clipboard
Nuget v2.0.2 - attestation option "direct" - TPM class
Hi,
We have noticed an issue.
When using the attestation option "direct" then clientDataJson appears to have 118 bytes when the tpm/ pubarea class expects 84. This throws an exception "throw new Fido2VerificationException("Leftover bytes decoding pubArea");" in TPM.cs line 634.
We were able to replicate the issue on your codebase changing attestation_type variable in custom.register.js to "direct".
We've temporarily changed our codebase to use "none" until fixed. Is there an alternative?
Please let me know if you need further details.
Thanks Himesh
I don't recall seeing anything like this before, do you have a sample clientDataJson that exhibits this behavior?
Hi Aseigler,
Sorry for the late response. So decode of array below:-
'{"type":"webauthn.create","challenge":"ztuB2Bt0h_t4sPpMraDctA","origin":"https://localhost:41111","crossOrigin":false,"other_keys_can_be_added_here":"do not compare clientDataJSON against a template. See https://goo.gl/yabPex"}'
Thanks Himesh
I was looking for the attestation statement. I'm unaware of a current platform that would encode a TPM attestation statement in such a way that you would end up with a malformed statement. There was a Firefox specific issue that could cause corruption like this, but it was fixed several months ago.
Hi! We've recently had the same issue calling MakeNewCredentialAsync using Windows Hello as platform authenticator on some devices. I have tested several different devices, at the moment it seems to me that the error only occurs on devices with the latest Windows 11 Update 22H2, is that possible?
I suspect this is going to be due to TPM attestations quietly being made with ES256 instead of RS256, which got fixed here. We need to get a new build cut to get this on Nuget, I don't think we have one with this in it.
No, the last release (3.0) doesn't have the changes as far as I can see. Would be nice to get the fix out.
@aseigler @m-gug 3.0.1 is available :shipit:
https://www.nuget.org/packages/Fido2/3.0.1
https://github.com/passwordless-lib/fido2-net-lib/releases/tag/v3.0.1
Please let us know ASAP if v3.0.1 does not fix the problem.
Thanks for the quick release, the problem is solved, the registration is working again. :raised_hands:
However, another problem has emerged that did not exist before. On .Net 6, the System.Json.Text serializer now seems to choke on the return value in the MakeAssertion function.
It throws this exception: "Serialization and deserialization of 'System.IntPtr' instances are not supported. Path: $.Result.AttestationCertificate.Handle."
The problem can also be recreated in your current master branch if you register a new credential in the demo app under Custom.
As a workaround I am not returning the complete result of MakeNewCredentialAsync(..), but returning a new CredentialMakeResult only with status="ok". The frontend doesn't need the complete result, as far as I understand it, does it?
Thanks for the report!
The frontend doesn't need the complete result, as far as I understand it, does it? @m-gug The frontend is not interested in the result once the credential is created, only the CredentialCreateOptions in the first step of the dance.