5 ms·

Been tracking this project for a while, I'm surprised they don't have a FIDO2 implementation yet, given how popular that's gotten

dathinab 2y ago
their approach is a one which is fully stateless on the chip (see their documentation for why) theoretically this is quite desirable but various protocols aren't build in a way enabling it e.g. TOTP pushes a secret from the server to the client, instead of having some form of deterministic key exchange similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not now it doesn't mean you can't make it work with tkeys but it can get more complex e.g. for TOTP using TKey to guard a local password vault which then does the TOTP instead of having the TOTP on the key directly (but then while TOTP is better then SMS 2FA it's still pretty bad compared to what technically is possible, like much worse then a lot of people realize)
- woodruffw 2y ago
  > similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not It's been a while since I've looked deeply at FIDO, but I think they would have had to make a handful of nontrivial security concessions to make WebAuthn stateless. One pretty important one that comes to mind is the token counter, which in principal enables RPs to detect a cloned credential.
  - Rafert 2y ago
    The counter can always be 0, which is what cloud synced passkeys are doing IIRC.
    - woodruffw 2y ago
      Huh yeah, I hadn't considered how they got around that. I suppose in that case this key could do something similar?
    - dathinab 2y ago
      The problem starts earlier with the secret key which you can't place "into" a TKey. You can deterministically derive one between the TKey and a server using some thing like a (semi) static DH but that isn't how it is implemented in general.
      - cuu508 2y ago
        I understand that the ability to place stuff "into" a TKey would be needed to support discoverable WebAuthn credentials ("passkeys"). But would it also be needed for non-discoverable credentials?
        Borealid 2y ago
        Yes, to set a PIN protecting the non-discoverable credentials. The FIDO PIN can be changed while you have access to the authenticator and not to the credentials it previously created.
        arianvanp 2y ago
        User verification is optional. If you only do user presence and non-discoverable, then WebAuthn is completely stateless and deterministic for a given (challenge,rpId,origin) triplet
        michaelt 2y ago
        Isn't a 'passkey' with no discoverable credentials and no user verification just a regular U2F token?
        Borealid 2y ago
        Well, it could still provide credBlob (up to 32 bytes of data stored in the non-discoverable credential and handed back after verification). But mostly yes, it's losing the advantages of FIDO2.
        arianvanp 2y ago
kfreds 2y ago
We're working on it. Our next hardware should have USB HID, FIDO2, and persistent storage. The persistent storage will be per device app. Well, that's the idea anyway. I'm not sure when we'll be done but check our website in a few months, or join our mailing list.

dathinab 2y ago

their approach is a one which is fully stateless on the chip (see their documentation for why) theoretically this is quite desirable but various protocols aren't build in a way enabling it e.g. TOTP pushes a secret from the server to the client, instead of having some form of deterministic key exchange similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not now it doesn't mean you can't make it work with tkeys but it can get more complex e.g. for TOTP using TKey to guard a local password vault which then does the TOTP instead of having the TOTP on the key directly (but then while TOTP is better then SMS 2FA it's still pretty bad compared to what technically is possible, like much worse then a lot of people realize)

woodruffw 2y ago
> similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not It's been a while since I've looked deeply at FIDO, but I think they would have had to make a handful of nontrivial security concessions to make WebAuthn stateless. One pretty important one that comes to mind is the token counter, which in principal enables RPs to detect a cloned credential.
- Rafert 2y ago
  The counter can always be 0, which is what cloud synced passkeys are doing IIRC.
  - woodruffw 2y ago
    Huh yeah, I hadn't considered how they got around that. I suppose in that case this key could do something similar?
  - dathinab 2y ago
    The problem starts earlier with the secret key which you can't place "into" a TKey. You can deterministically derive one between the TKey and a server using some thing like a (semi) static DH but that isn't how it is implemented in general.
    - cuu508 2y ago
      I understand that the ability to place stuff "into" a TKey would be needed to support discoverable WebAuthn credentials ("passkeys"). But would it also be needed for non-discoverable credentials?
      - Borealid 2y ago
        Yes, to set a PIN protecting the non-discoverable credentials. The FIDO PIN can be changed while you have access to the authenticator and not to the credentials it previously created.
        arianvanp 2y ago
        User verification is optional. If you only do user presence and non-discoverable, then WebAuthn is completely stateless and deterministic for a given (challenge,rpId,origin) triplet
        michaelt 2y ago
        Isn't a 'passkey' with no discoverable credentials and no user verification just a regular U2F token?
        Borealid 2y ago
        Well, it could still provide credBlob (up to 32 bytes of data stored in the non-discoverable credential and handed back after verification). But mostly yes, it's losing the advantages of FIDO2.
        arianvanp 2y ago

kfreds 2y ago

We're working on it. Our next hardware should have USB HID, FIDO2, and persistent storage. The persistent storage will be per device app. Well, that's the idea anyway. I'm not sure when we'll be done but check our website in a few months, or join our mailing list.