agl

Setting a signature counter to constant zero is explicitly supported[1] and it's not a bug that it works. Google does not require the signature counter to increment; it's something else invalid about the response that's tripping it up.

The security story for signature counters is subtle[2] and the vast (vast) majority of sites are correct not to require them.

Using the Chrome virtual authenticator indeed works, and from the DevTools UI directly (three dots -> More Tools -> WebAuthn), no sockets required. It's not a vulnerability that it works. If it didn't, Apple, Google, and Microsoft would be effectively the only possible passkey providers. You can lock it down in enterprise environments if you need[3].

[1] https://www.w3.org/TR/webauthn-3/#sctn-sign-counter [2] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn... [3] https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn...

WebAuthn protects the sign in, but malware can still steal the resulting cookies. DBSC protects the sign in _session_. (It should stand for Don’t Bother Stealing Cookies.)

It is a fair worry. On one side, there are sites with regulations that they are supposed to meet and it's hard to do so without knowing something about the passkey provider. If we want to try and replace SMS OTP, which is depressingly easy to compromise, we can't ignore such things.

On the other, we don't want to create a situation where it's impossible to start a new passkey provider because you'll never get 1000s of websites to put you on their allowlist.

So far, we haven't done attestation for passkey providers at all. There is only the AAGUID, which is a spoofable identifer should any sites try to filter based on it. There are legitimate cases where sites are required to know more, but we're trying to find a path that doesn't lead to the problems that you worry about and, so far, are erring on the side of openness.

> The popular libraries seem to follow a kind of "shadow spec" where they agreed on using the URL-friendly variant of base64

WebAuthn itself uses base64url rather than base64. See, e.g., the `id` field here: https://www.w3.org/TR/webauthn-2/#iface-pkcredential

(It was probably a mistake, but it predates me so I don't know the motivation.)

> I still don't know whether it's possible to use both usernameless and usernameful passkeys simultaneously.

Non-discoverable credentials can only be used if their credential ID is passed in an allowlist. Discoverable credentials (a.k.a. "resident" in the API, although that name is a bit misleading) _can_ be enumerated in an allowlist. So they can work together, but to have the allowlist you must collect a username first or have some other way of know which account is pertinent to the current session.

2nd-factor WebAuthn should work fine with Android phones today. Any Android phone with a current version of Play Services and Chrome should be able to scan the QR code, if it doesn't work then it's a bug (or, at least, an old QR scanner).

When you say "nothing happens": what's the QR scanner? Do you have Chrome installed on the device? What are the app versions (from Settings) of Play Services and Chrome?

Support is not yet available on Android but support for syncable passkeys on Android was announced for some time this year at Google I/O.

You can just glue a wire to the touch plate and connect it to ground when you want to simulate a touch.

I do not represent an NVLAP lab, but I'd question whether this would pass strict muster for FIPS given IG A.5: https://csrc.nist.gov/csrc/media/projects/cryptographic-modu...

(Disclaimer: author of AES-GCM-SIV. Not casting shade here, it's a fair idea! But not sure about the specific FIPS claim.)

getrandom blocks until 128 bits of entropy have been collected since boot. It doesn't have the concept of "draining" the pool after the pool has been initialised.

Early support should be appearing in the coming weeks on Canary channel when run with --enable-features=WebAuthenticationPINSupport

There are various groupish signature systems (including DAA and BBS[1]) that would probably be a better answer here, _if you controlled the signers_. But, in this context, the devices have shipped and they do P-256 ECDSA. So the question then becomes, what _can_ we do without being able to change the signers? Can we plausibly retrofit something onto them?

[1] http://crypto.stanford.edu/~dabo/papers/groupsigs.pdf

Google has not yet transitioned from the U2F API to the Web Authentication API for login so no, not yet. (We're working on it, but there's quite a lot of moving pieces.)

Also, as another comment noted, only CTAP2 is supported for the host to authenticator API, and only the newest Yubico tokens support CTAP2.

> Is there anything in the standard about proving to the server that you have a genuine FIDO device

Yes. When registering a credential you can request[1] attestation information. Generally this will come in the form of an X.509 certificate[2] per batch of 100,000 devices which is signed by the manufacturer and which signs the generated key.

FIDO is planning on running a central registry[3] of devices which should include their certifications and manufacturer public keys etc.

For more details, see [4].

> My understanding of FIDO (v1) is that the only function a device has to offer is authentication through digital signature.

That's correct: CTAP1 just signs things. You can prove to a remote service that the credential is in live use right now because it signs over a server-provided nonce to show freshness, but that's all.

With CTAP2, devices can store keys themselves and they can provide a random oracle (i.e. HMAC) for unlocking locally encrypted data[5]. FIDO2 devices can also require a PIN to be provided before keys are released. (Or have a local fingerprint reader, although I don't know of any such devices yet.)

[1] https://www.w3.org/TR/webauthn/#attestation-convey [2] https://www.w3.org/TR/webauthn/#fido-u2f-attestation [3] https://fidoalliance.org/mds/ [4] https://www.imperialviolet.org/2018/03/27/webauthn.html#atte... [5] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...

I don't know about the specific extension, but see https://groups.google.com/a/chromium.org/d/msg/blink-dev/LZX...

Webauthn and WebUSB UIs are very different. Additionally, Chrome has banned WebUSB from claiming Security Keys.

However, it remains the case that if the user downloads and runs exes, or otherwise grants the attacker direct access to the Security Key, then they can ask it to sign an authentication request for a given website. Such an attacker could also compromise the browser and wait for the user to login themselves etc.

Webauthn works with both FIDO1 and FIDO2 keys. (Unless you have the new, FIDO2 key from Yubico then you have a FIDO1 key). You might also see them called CTAP1 and CTAP2 keys because CTAP is the bit of FIDO that defines the interface to the hardware tokens. (CTAP: "Client to Authenticator Protocol". See https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-cl...)

FIDO2 keys talk a different protocol and do everything that FIDO1 keys do, and (potentially) more. For example, they may operate in "resident key" mode where the key remembers both your username and private key. They can also support things like PIN activation.

I've only briefly poked the Yubico FIDO2 key. I think it supports a limited form of resident keys and it advertises PIN support, although I didn't exercise that.

Sorry, I worded that poorly. U2F keys will continue to work fine, it's just the Javascript API that sites use that'll change. As a user, everything will keep working.

Webauthn allows (but does not require) a mode where the key is a single-factor (i.e. acts as both username and authenticator). You need FIDO2 keys for that and we plan to support it in Chrome. Sites will decide whether that makes sense for them.

> However, I've heard that Google is kind of going on a tangent with its own U2F implementations, emphasizing an old-school implementation instead of the Web Authentication Standard that's pushed by the W3C.

Chrome has supported "U2F" (the first FIDO spec) for a while and all support for Security Keys in the last few years has been via this protocol.

But we're implementing the W3C Web Authentication (webauthn) spec and you can already use it in Chrome in place of U2F. All effort is going into webauthn now and the U2F code is frozen. At some point I'll announce a sunset date for U2F support in Chrome and happily delete that code. (Just the API, U2F keys will continue to work via webauthn.)

It's possible that new primitives based on the same SI problem might have significant performance differences, but we're basing this on the NIST round one submissions. In that setting, there's been a decent amount of optimisation done already and the performance gap is two orders of magnitude. Since elliptic-curve implementation is pretty well studied, improvements might close that gap a little, but it's unlikely to make vast differences.

So it's a balance between adding an extra ~1.5 kB to the transaction, verses that CPU difference. In different contexts those two costs will have different weights, of course, but my feeling is that in TLS, we probably want to pay for the extra bytes.

> Does that assume that all of the components (browser and server) support 1.2 as well?

No: a client, server, and MITM proxy can all be exclusively TLS 1.3 and everything will still work(+).

(+) as much as it did with TLS 1.2, anyway.

It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1.3 at the server to keep them working.)

MITM proxies, which are trusted by the client and which terminate and recreate the TLS connection, will continue to function. (Assuming they implemented TLS 1.2 correctly, which some didn't.)

This is nonsense. The self-signature on a root certificate is irrelevant unless you can easily calculate second pre-images, and that's not true even of MD5, and accepting a root doesn't mean that the validator would accept that hash function on a non-root.

Equifax is only a 1024-bit RSA key, which isn't ideal, but it expires on Aug 22nd this year and the key-size of the root doesn't impact confidentiality.

XMSS is great work, but it's not clearly suitable for use in SSH: I will occasionally copy SSH private keys around, or restore them from backups. I think that's fairly common. However, with XMSS:

"the signature schemes described in this document are stateful, meaning the secret key changes over time. If a secret key state is used twice, no cryptographic security guarantees remain." [1]

Perhaps the SSH authors have a clever answer for this! But stateful signatures are not, in general, suitable as a drop-in replacement for traditional signature schemes and I do worry that people may miss this subtle, but critical, point.

[1] https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-...

The piece seems to suggest that a) multiple processes were the performance problem and b) that a field trial was causing that and "mak[ing] my computer unusable".

Multiple processes do take more memory, but there's a good reason for them. While it's possible that it was a field trial that was causing issues here, there's no evidence to support that. Sadly, it was probably just excessive resource usage independent of any trials: Chromium did have a period where memory usage especially was allowed to drift and that was an oversight that Speed team are correcting (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/s...).

On the other hand, field trials produce important feedback. One example just from today: TLS 1.3 draft 18 had significant issues with middlebox bugs to the point where it wasn't viable to deploy it. Chromium has been using field trails to test variants of TLS 1.3 intended to work around these issues and allow TLS 1.3 to be used for real. This has resulted in concrete changes to help TLS 1.3: https://www.ietf.org/mail-archive/web/tls/current/msg24908.h...

These sorts of things require large-scale testing. We brought all the middleboxes that we could find for local testing, but that cannot account for the variety of firmware versions and configurations used in the wild.

The fact that Chromium runs multiple processes is unrelated to any field trials. Chromium has always been multi-process; that's why individual tabs and plugins can crash without taking down the whole browser. Additionally, multiple processes are needed in order to implement sandboxing on Linux.

Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in.... They are used to experiment with different solutions or, sometimes, to allow a change to be quickly reverted in the field if it's causing a problem. You can manually enable/disable several of these on chrome://flags/ (although it's not advised).

Losing one.

"Basically, the code recurses a sha256 computation 1714 times to get a lookup key, and then once more to get a password for decryption."

Other way around, no? The index is the hash of the decryption key (as it should be), it's just that the index is called "key" and the key is called "lookup".

If the decryption key was the hash of the index, then it would be trivial to decrypt every entry.

We are still working around bugs in network middleware. I hope that it will be available in Chrome and on Google's servers in Q1, 2018.