5 ms·

Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. It's an interesting trade-off. It seems

Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. It's an interesting trade-off. It seems like batch keys for device attestation was designed to help protect individual privacy (good), but if you can't ban a key without potentially a lot of splash damage when you detect a bad actor, that seems like a very limiting choice.

tialaramex 5y ago
The intent of attestation is that a business could decide, OK, we think FooCorp are doing a proper job and we trust their FIDO tokens, but we don't like all these dozens of cheap alternatives. So for our corporate site we'll require FooCorp tokens, and we'll just issue every employee a FooCorp token on our dime. Maybe it could make sense for a bank to do this, sending account holders a special custom Security Key with the bank's branding on it. I personally think that's stupid, but I can imagine it appealing to bank executives and it's not so stupid as to be worse than SMS or TOTP 2FA that banks do today. But it clearly isn't relevant for no-cost services like Facebook or Gmail, and so sure enough you can just tell them you don't want to give them attestation and they work anyway (I don't know if either of them ask, I just reflexively deny attestation if it's requested). It isn't intended to be useful for trying to do stuff like Cloudflare are attempting here. Which doesn't mean Cloudflare can't succeed in their goals, but in the FIDO threat models a "bad actor" would be a whole vendor, maybe some outfit is using fixed long term secret keys inside their Security Key products and they just sell the NSA a list of those keys - you might decide to just refuse all the products from this vendor. Whereas for Cloudflare the "bad actor" they're worried about just buys a half dozen of whatever was cheapest from eBay and then plugs them into a Raspberry Pi. Or, do they? That's the gamble I think Cloudflare is taking. Maybe the value of defeating this intervention is so low that bad guys will not, in fact, build a Raspberry Pi Security Key clicker proxy to make their thing work.
ignoramous 5y ago
> Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. You're right. I meant Cloudflare could ban the generated public-key and not the device's public-key itself. Besides, they could also mark the batch as being taken over by bots and increase the level on challenges issued to the batch. Note though, a single secure module can only generate / store so many public-keys. For instance, Yubi Key 5 supports up to 25 keys, though those could be reset to generate a newer set of 25, but repeat registration of a number of keys from a single batch is bound to trigger some statistical anomalies. From Cloudflare's blog about Cryptographic attestation of personhood https://archive.is/4EbER https://archive.is/4EbER > For our challenge, we leverage the WebAuthn registration process. It has been designed to perform multiple authentications, which we do not have a use for. Therefore, we do assign the same constant value to the required username field. It protects users from deanonymization. Currently, the user-name field is constant for all users. I wanted to point out that that they could amend the registration ceremony to register any user in particular.
- TimWolla 5y ago
  > For instance, Yubi Key 5 supports up to 25 keys This is for resident keys. A YubiKey 5 supports an infinite number of non-resident WebAuthn keys, because the returned key handle will simply be the private key encrypted with a master key stored on the YubiKey. For authentication the service will send the stored key handle back to the YubiKey which then can decrypt it and use the decrypted private key to sign the challenge.
  - deleted 5y ago
    [deleted]
  - ignoramous 5y ago
    TIL. Envelope encryption. Neat. Can WebAuthn keys be (made) a resident key? If so, is that preferred instead? Conversely, what use case is there for resident keys in context of WebAuthn? For example, if there are multiple master keys, can I switch between them per browser / website (assuming the master key itself is a resident key and not burnt into the element)? Thanks.
    - TimWolla 5y ago
      The WebAuthn API can register a resident key on the YubiKey. This will basically store the username, private key and domain on the YubiKey. The website then can later request authentication based off a resident key. This will cause your web browser to query the YubiKey for resident keys of the website. You then can select the resident key with the correct username and will be logged in based on strong cryptography without needing to enter your password or username. Depending on your YubiKey configuration you might need to enter your YubiKey pin for this to work. See the screenshot in this comment on a GitHub issue: https://github.com/keepassxreboot/keepassxc/issues/3560#issuecomment-610773697 https://github.com/keepassxreboot/keepassxc/issues/3560#issu... The website will need to support this of course. Also the amount of storage available for resident keys on the YubiKey is limited.

tialaramex 5y ago

The intent of attestation is that a business could decide, OK, we think FooCorp are doing a proper job and we trust their FIDO tokens, but we don't like all these dozens of cheap alternatives. So for our corporate site we'll require FooCorp tokens, and we'll just issue every employee a FooCorp token on our dime. Maybe it could make sense for a bank to do this, sending account holders a special custom Security Key with the bank's branding on it. I personally think that's stupid, but I can imagine it appealing to bank executives and it's not so stupid as to be worse than SMS or TOTP 2FA that banks do today. But it clearly isn't relevant for no-cost services like Facebook or Gmail, and so sure enough you can just tell them you don't want to give them attestation and they work anyway (I don't know if either of them ask, I just reflexively deny attestation if it's requested). It isn't intended to be useful for trying to do stuff like Cloudflare are attempting here. Which doesn't mean Cloudflare can't succeed in their goals, but in the FIDO threat models a "bad actor" would be a whole vendor, maybe some outfit is using fixed long term secret keys inside their Security Key products and they just sell the NSA a list of those keys - you might decide to just refuse all the products from this vendor. Whereas for Cloudflare the "bad actor" they're worried about just buys a half dozen of whatever was cheapest from eBay and then plugs them into a Raspberry Pi. Or, do they? That's the gamble I think Cloudflare is taking. Maybe the value of defeating this intervention is so low that bad guys will not, in fact, build a Raspberry Pi Security Key clicker proxy to make their thing work.

ignoramous 5y ago

> Each key is associated with a batch of devices, though. If you ban a key, you risk banning a bunch of legitimate users. You're right. I meant Cloudflare could ban the generated public-key and not the device's public-key itself. Besides, they could also mark the batch as being taken over by bots and increase the level on challenges issued to the batch. Note though, a single secure module can only generate / store so many public-keys. For instance, Yubi Key 5 supports up to 25 keys, though those could be reset to generate a newer set of 25, but repeat registration of a number of keys from a single batch is bound to trigger some statistical anomalies. From Cloudflare's blog about Cryptographic attestation of personhood https://archive.is/4EbER https://archive.is/4EbER > For our challenge, we leverage the WebAuthn registration process. It has been designed to perform multiple authentications, which we do not have a use for. Therefore, we do assign the same constant value to the required username field. It protects users from deanonymization. Currently, the user-name field is constant for all users. I wanted to point out that that they could amend the registration ceremony to register any user in particular.

TimWolla 5y ago
> For instance, Yubi Key 5 supports up to 25 keys This is for resident keys. A YubiKey 5 supports an infinite number of non-resident WebAuthn keys, because the returned key handle will simply be the private key encrypted with a master key stored on the YubiKey. For authentication the service will send the stored key handle back to the YubiKey which then can decrypt it and use the decrypted private key to sign the challenge.
- deleted 5y ago
  [deleted]
- ignoramous 5y ago
  TIL. Envelope encryption. Neat. Can WebAuthn keys be (made) a resident key? If so, is that preferred instead? Conversely, what use case is there for resident keys in context of WebAuthn? For example, if there are multiple master keys, can I switch between them per browser / website (assuming the master key itself is a resident key and not burnt into the element)? Thanks.
  - TimWolla 5y ago
    The WebAuthn API can register a resident key on the YubiKey. This will basically store the username, private key and domain on the YubiKey. The website then can later request authentication based off a resident key. This will cause your web browser to query the YubiKey for resident keys of the website. You then can select the resident key with the correct username and will be logged in based on strong cryptography without needing to enter your password or username. Depending on your YubiKey configuration you might need to enter your YubiKey pin for this to work. See the screenshot in this comment on a GitHub issue: https://github.com/keepassxreboot/keepassxc/issues/3560#issuecomment-610773697 https://github.com/keepassxreboot/keepassxc/issues/3560#issu... The website will need to support this of course. Also the amount of storage available for resident keys on the YubiKey is limited.