search

trussed-dev / trussed-auth

Authentication extension and backend for Trussed
1 stars 3 forks source link

Support alternative authentication methods #18

Open szszszsz opened 1 year ago

szszszsz commented 1 year ago

Support alternative authentication methods, like challenge-response using ECC keys See https://github.com/Nitrokey/opcard-rs/issues/104

Idea. To be discussed. Original reporter had an use-case.

sosthene-nitrokey commented 1 year ago

There's also the admin challenge-response mechanism in PIV. But supporting all such use cases in trussed-auth would be out of scope IMO.

szszszsz commented 1 year ago

Makes sense. What do you propose instead? Another extension?

sosthene-nitrokey commented 1 year ago

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?

szszszsz commented 1 year ago

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.

  1. I understand, that you propose to make another extension for that, instead of using this repository, is that right?
  2. Do you support challenge-response inside your PIV application?
sosthene-nitrokey commented 1 year ago

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. Also note that unlike Password-based authentication it is not possible to use the result of such challenge-response protocol to as additional entropy to encrypt persistent user data.

szszszsz commented 1 year ago
  1. This looks like a chicken and egg problem for me. I would wish here for a standardized approach, which could be shared across apps, instead of implementing it by hand per app.
  2. Original reporter requests that to extend OpenPGP with challenge-response for his workflow, hence the interest in having that here. Similarly for Secrets and Webcrypt apps. Let's keep it in the discussion phase though for the time being.

Also note that unlike Password-based authentication it is not possible to use the result of such challenge-response protocol to as additional entropy to encrypt persistent user data.

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.

sosthene-nitrokey commented 1 year ago

would wish here for a standardized approach

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).