-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support alternative authentication methods #18
Comments
There's also the admin challenge-response mechanism in PIV. But supporting all such use cases in |
Makes sense. What do you propose instead? Another extension? |
The issue is that such challenge-response mechanisms are very application-specific. They also would not easily integrate with the SE050 and with the key derivation mechanism, so I don't see what it would bring to have them here? |
I thought here about providing alternative authentication methods, like the proposed by the initial reporter, which are out of the regular specification. I believe that it's better to keep all auth-related code in a single place, instead of scattered over applications' codebases.
|
Not necessarily even an extension. Each application can handle that in code. For example this is the code that handles authentication in piv: https://github.com/Nitrokey/piv-authenticator/blob/main/src/lib.rs#L478 It is stateful (2 back and forth), has two modes (mutual and single authentication). We could integrate it in trussed-auth, but it would not be a generic, reusable bit of code outside of PIV. Neither Opcard, FIDO or the secrets app would benefit from it, therefore I don't see the interest of putting it here. If we ever come up with our own challenge-response based authentication mechanism, that is shared between multiple applications it might make sense to have it here. And if we do so, I would rather be using something like OPAQUE than something custom. Otherwise I don't see the point. |
Yes, this would have to unlock entropy stored on the device, which would be used for encryption. Interesting idea with OPAQUE - looks like it was published back in the 2018, so should be pretty mature. |
There is somewhat with secure messaging. If supported it would make more sense to me to have it in the CCID related crates (usbd-ccid, apdu-dispatch and iso7816). |
Support alternative authentication methods, like challenge-response using ECC keys
See Nitrokey/opcard-rs#104
Idea. To be discussed. Original reporter had an use-case.
The text was updated successfully, but these errors were encountered: