Use TouchBar/TouchID as a secure element for implementing a U2F security key |
||||||||||||||
Issue descriptionThe new MacBook Pros with TouchID have a secure enclave for storing the fingerprint data. We may be able to use this element for implementing an on-computer second-factor security key. The requirements for this would be: - Private key is generated in the secure enclave, not in macOS - Key material is exclusively stored in the secure enclave - Private key is not extractable from the secure enclave awhalley notes: "Looks like kSecAttrTokenIDSecureEnclave is available in macOS 10.12 so you can indeed create a key inside the SEP on the mac! Doesn't yet looks there's a way to verify a key does indeed come from an SEP, so the server relying on the token would have to trust the client to create it in the SEP initially. https://developer.apple.com/reference/security/ksecattrtokenidsecureenclave" (but we aren't concerned about rogue clients since it's outside the threat model) jschuh found via Twitter an iOS implementation: https://github.com/mastahyeti/security-key So this may be doable, which would be handy given that the new MBPs are USB-C only and FIDO keys don't work presently without an adapter. It's an open question on whether we'd do this within Chromium or as an extension with a native component.
,
Mar 8 2017
,
Mar 2 2018
For what it's worth, I've been using https://github.com/github/SoftU2F. This comes with a downside though, which a Chromium implementation would also run into. Some sites only support a limited number of u2f device vendors - they do this by checking the attestation cert (which is used to sign a challenge during registration) against a whitelist. Any software-based approach would need to bundle the private attestation key (even though the actually sensitive secrets are stored in the SEP). I wouldn't be surprised if some sites were unwilling to whitelist this attestation cert - any random person could use it, so it wouldn't guarantee that secrets are stored in a secure element.
,
Mar 2 2018
Er sorry, I didn't read carefully, and that's exactly what awhalley@ said in comment 1, oops :-)
,
Mar 2 2018
martinkr@ is looking into this, assigning to them for now.
,
Apr 9 2018
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eaf85f188f05b2874821d06b863dd696a3113653 commit eaf85f188f05b2874821d06b863dd696a3113653 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue May 01 19:52:42 2018 //device/fido: add authenticator operations for Touch ID. Bug: 678128 Change-Id: I77057cf8f630668d07fa93f9c4d09fefae187aa3 Reviewed-on: https://chromium-review.googlesource.com/1013054 Commit-Queue: Balazs Engedy <engedy@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Cr-Commit-Position: refs/heads/master@{#555154} [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/base/mac/foundation_util.h [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/base/mac/foundation_util.mm [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/BUILD.gn [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/BUILD.gn [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/attested_credential_data.h [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/ctap_make_credential_request.h [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/ec_public_key.cc [modify] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/ec_public_key.h [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/get_assertion_operation.h [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/get_assertion_operation.mm [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/get_assertion_operation_unittest_mac.mm [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/make_credential_operation.h [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/make_credential_operation.mm [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/make_credential_operation_unittest_mac.mm [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/util.h [add] https://crrev.com/eaf85f188f05b2874821d06b863dd696a3113653/device/fido/mac/util.mm
,
May 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fc901c2841cba46477ff3def670c9fabd89bd1a6 commit fc901c2841cba46477ff3def670c9fabd89bd1a6 Author: Martin Kreichgauer <martinkr@google.com> Date: Thu May 24 20:20:16 2018 //device/fido: add TouchIdAuthenticator behind a feature flag This adds the WebAuthenticationTouchId feature flag (default disabled). If enabled, the FidoRequestHandler tries to instantiate a TouchIdAuthenticator on supported platforms for the current request. Bug: 678128 Change-Id: Iddc4ea00b3247b6ffbe875e280e1bf30488ca81f Reviewed-on: https://chromium-review.googlesource.com/1064921 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Camille Lamy <clamy@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Cr-Commit-Position: refs/heads/master@{#561605} [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/content/public/common/content_features.cc [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/content/public/common/content_features.h [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/fake_fido_discovery.cc [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/fido_discovery.cc [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/fido_request_handler_base.cc [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/fido_request_handler_base.h [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/fido_transport_protocol.h [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/mac/authenticator.h [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/mac/authenticator.mm [modify] https://crrev.com/fc901c2841cba46477ff3def670c9fabd89bd1a6/device/fido/mac/touch_id_context.h
,
May 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f67a80912f289adc69d2dd28b6257279f2521783 commit f67a80912f289adc69d2dd28b6257279f2521783 Author: Martin Kreichgauer <martinkr@google.com> Date: Thu May 24 21:32:16 2018 //device/fido/mac: fix a bug in MakeAuthenticatorData AuthenticatorData was previously created with the hash of the clientDataJSON, rather than the hash of the RP ID. See https://www.w3.org/TR/webauthn/#authenticator-data for reference. Bug: 678128 Change-Id: I1628172212fadedd02a8ccf5daa46237bccd12bd Reviewed-on: https://chromium-review.googlesource.com/1066486 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#561640} [modify] https://crrev.com/f67a80912f289adc69d2dd28b6257279f2521783/device/fido/mac/get_assertion_operation.mm [modify] https://crrev.com/f67a80912f289adc69d2dd28b6257279f2521783/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/f67a80912f289adc69d2dd28b6257279f2521783/device/fido/mac/util.h [modify] https://crrev.com/f67a80912f289adc69d2dd28b6257279f2521783/device/fido/mac/util.mm
,
May 30 2018
,
May 31 2018
,
Jun 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7acb4716808f303c7c8bafc762f1fcda769a33bd commit 7acb4716808f303c7c8bafc762f1fcda769a33bd Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Jun 05 19:14:16 2018 device/fido/mac: encrypt credential metadata in the macOS keychain This adds a CredentialMetadata class to encrypt any account metadata associated with a WebAuthn credential (user ID, user name, user display name, and RP ID) before writing it to the macOS keychain. The key will be generated and stored in the Chrome profile under which the credential was created. (It is currently hardcoded but I'm changing that in a follow-up CL.) Deletion of the profile or key will therefore render the data unreadable. Bug: 678128 Change-Id: I536d537e9220cc5f89d487c7f94e169d06d62e7a Reviewed-on: https://chromium-review.googlesource.com/1073708 Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#564609} [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/BUILD.gn [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/BUILD.gn [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/authenticator.mm [add] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/credential_metadata.cc [add] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/credential_metadata.h [add] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/credential_metadata_unittest.cc [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/get_assertion_operation.mm [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/make_credential_operation.h [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/operation_base.h [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/util.h [modify] https://crrev.com/7acb4716808f303c7c8bafc762f1fcda769a33bd/device/fido/mac/util.mm
,
Jun 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1 commit f4729ae834a9bb6ff09a82d00b3bbc3997d805a1 Author: Findit <findit-for-me@appspot.gserviceaccount.com> Date: Tue Jun 05 20:55:19 2018 Revert "device/fido/mac: encrypt credential metadata in the macOS keychain" This reverts commit 7acb4716808f303c7c8bafc762f1fcda769a33bd. Reason for revert: Findit (https://goo.gl/kROfz5) identified CL at revision 564609 as the culprit for failures in the build cycles as shown on: https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtLzdhY2I0NzE2ODA4ZjMwM2M3YzhiYWZjNzYyZjFmY2RhNzY5YTMzYmQM Sample Failed Build: https://ci.chromium.org/buildbot/chromium.mac/Mac10.11%20Tests/27041 Sample Failed Step: device_unittests on Mac-10.11 Original change's description: > device/fido/mac: encrypt credential metadata in the macOS keychain > > This adds a CredentialMetadata class to encrypt any account metadata > associated with a WebAuthn credential (user ID, user name, user display > name, and RP ID) before writing it to the macOS keychain. > > The key will be generated and stored in the Chrome profile under which > the credential was created. (It is currently hardcoded but I'm changing > that in a follow-up CL.) Deletion of the profile or key will therefore > render the data unreadable. > > Bug: 678128 > Change-Id: I536d537e9220cc5f89d487c7f94e169d06d62e7a > Reviewed-on: https://chromium-review.googlesource.com/1073708 > Reviewed-by: Balazs Engedy <engedy@chromium.org> > Reviewed-by: Adam Langley <agl@chromium.org> > Commit-Queue: Martin Kreichgauer <martinkr@google.com> > Cr-Commit-Position: refs/heads/master@{#564609} Change-Id: I24c8937ae0855ce542e16f0fa9f21ca159d51abe No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 678128 Reviewed-on: https://chromium-review.googlesource.com/1087613 Cr-Commit-Position: refs/heads/master@{#564659} [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/BUILD.gn [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/BUILD.gn [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/authenticator.mm [delete] https://crrev.com/1ab35304662a42a2d584522fcfa64f58538f4967/device/fido/mac/credential_metadata.cc [delete] https://crrev.com/1ab35304662a42a2d584522fcfa64f58538f4967/device/fido/mac/credential_metadata.h [delete] https://crrev.com/1ab35304662a42a2d584522fcfa64f58538f4967/device/fido/mac/credential_metadata_unittest.cc [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/get_assertion_operation.mm [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/make_credential_operation.h [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/operation_base.h [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/util.h [modify] https://crrev.com/f4729ae834a9bb6ff09a82d00b3bbc3997d805a1/device/fido/mac/util.mm
,
Jun 13 2018
,
Jun 13 2018
,
Jun 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0e1b15ef6a4771963e89d46892206f246fc969c9 commit 0e1b15ef6a4771963e89d46892206f246fc969c9 Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Jun 20 02:59:50 2018 //device/fido: implement the Touch ID credential metadata secret. This moves the responsibility of generating the CredentialMetadata 'secret' parameter (formely profile_id) into the AuthenticatorRequestDelegate. CredentialMetadata uses the parameter to derive the HMAC and AEAD keys for encrypting/encoding credential metadata before storing it in the macOS keychain. For Chrome, implement profile-specific secrets by storing the value in the browser profile PrefService. This guarantees that credentials will be logically separated by user profile. Bug: 678128 Change-Id: I8c3d12c6db266105eeb63191e9d277d8cdb173ee Reviewed-on: https://chromium-review.googlesource.com/1102179 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Reviewed-by: Dominic Battré <battre@chromium.org> Cr-Commit-Position: refs/heads/master@{#568706} [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/browser/BUILD.gn [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/browser/prefs/browser_prefs.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/browser/webauthn/chrome_authenticator_request_delegate.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/browser/webauthn/chrome_authenticator_request_delegate.h [add] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/browser/webauthn/chrome_authenticator_request_delegate_unittest.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/chrome/test/BUILD.gn [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/content/public/browser/authenticator_request_client_delegate.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/content/public/browser/authenticator_request_client_delegate.h [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/authenticator.h [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/authenticator.mm [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/credential_metadata.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/credential_metadata.h [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/credential_metadata_unittest.cc [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/get_assertion_operation.mm [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/0e1b15ef6a4771963e89d46892206f246fc969c9/device/fido/mac/operation_base.h
,
Jun 26 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3207d3de660518da8c8bfa6a1c8834748af978f0 commit 3207d3de660518da8c8bfa6a1c8834748af978f0 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Jun 26 20:30:23 2018 //device/fido: check for Touch ID in isUVPAA() This updates the implementation of isUserVerifyingPlatformAuthenticatorAvailable to call TouchIdAuthenticator::IsAvailable on macOS >10.12.2. The method returns true on supported hardware if Touch ID is available and enrolled. Also move the __builtin_available guards checking for a minimum macOS version *inside* the TouchIdAuthenticator class to make the interface less clunky. Bug: 803842 , 678128 Change-Id: Iea2600767b872660debf7d5a807e13f99132d4ec Reviewed-on: https://chromium-review.googlesource.com/1112800 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Reilly Grant <reillyg@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Cr-Commit-Position: refs/heads/master@{#570515} [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/content/public/browser/authenticator_request_client_delegate.cc [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/content/public/common/content_features.cc [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/content/public/common/content_features.h [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/device/base/features.cc [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/device/base/features.h [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/device/fido/mac/authenticator.h [modify] https://crrev.com/3207d3de660518da8c8bfa6a1c8834748af978f0/device/fido/mac/authenticator.mm
,
Jun 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/aa06bffab97b8f709cb617aef6e26ce90d097f13 commit aa06bffab97b8f709cb617aef6e26ce90d097f13 Author: Martin Kreichgauer <martinkr@google.com> Date: Fri Jun 29 07:54:10 2018 device/fido/mac: make encoding of the RP ID for metadata storage reversible This changes the CredentialMetadata::EncodeRpId method to allow an RP ID to be recovered from the encoding, given the secret key; and it adds a CredentialMetadata::DecodeRpId method to do so. This is necessary because we need an effective way to test whether a given credential in the macOS keychain "belongs" to a given profile (i.e. was the metadata sealed/encoded under that profile's secret key), when performing browsing data deletion for that profile. This was previously impossible: Unsealing the credential ID requires the correct RP ID, with which the credential id ciphertext is authenticated. The other two fields (RP ID + user handle, and RP ID) are encoded with HMAC-SHA-256, so they are not reversible without the RP ID either. This CL changes the kSecAttrLabel field, which previously stored HMAC-SHA-256(rp_id), to store a deterministic encryption of rp_id instead. The cipher is AES-GCM-SIV with a fixed nonce. This makes the encoding reversible (because you can retrieve the RP ID by decrypting), while maintaining easy lookup of all credentials for a given RP (because the encoding is deterministic) and confidentiality (because you need the key to decrypt). Bug: 678128 Change-Id: I2e34ca5c7f28a2bd14a953539de6e0ac90568bec Reviewed-on: https://chromium-review.googlesource.com/1117609 Commit-Queue: Adam Langley <agl@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#571422} [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/crypto/aead.cc [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/crypto/aead.h [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/crypto/aead_unittest.cc [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/device/fido/mac/credential_metadata.cc [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/device/fido/mac/credential_metadata.h [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/device/fido/mac/credential_metadata_unittest.cc [modify] https://crrev.com/aa06bffab97b8f709cb617aef6e26ce90d097f13/device/fido/mac/operation_base.h
,
Jul 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d52effd049b0068b918cf1f286a28968e03288b6 commit d52effd049b0068b918cf1f286a28968e03288b6 Author: Martin Kreichgauer <martinkr@google.com> Date: Mon Jul 09 20:33:09 2018 device/fido/mac: add browsing data deletion interface This adds the DeleteWebAuthnCredentials method which deletes WebAuthn credentials that have been created under a given browser profile and in a given time interval. Bug: 678128 Change-Id: I7f7b54b099c8d5cd622c70d16a510cf16f8948e6 Reviewed-on: https://chromium-review.googlesource.com/1123627 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Cr-Commit-Position: refs/heads/master@{#573431} [modify] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/BUILD.gn [modify] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/BUILD.gn [modify] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/authenticator.h [modify] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/authenticator.mm [add] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/browsing_data_deletion.h [add] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/browsing_data_deletion.mm [add] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/browsing_data_deletion_unittest.mm [modify] https://crrev.com/d52effd049b0068b918cf1f286a28968e03288b6/device/fido/mac/keychain.h
,
Jul 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf345a8beda494eb6ae73e1e25cd741abf24ee85 commit bf345a8beda494eb6ae73e1e25cd741abf24ee85 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Jul 10 18:46:09 2018 device/fido/mac: hide DeleteWebAuthnCredentials behind flag This changes device::fido::mac::DeleteWebAuthnCredentials to have no effect when the feature flag for the Touch ID authenticator (WebAuthenticationTouchId) is turned off. Bug: 678128 Change-Id: I2fef6fe53903dad3329a075aa00d5152365af133 Reviewed-on: https://chromium-review.googlesource.com/1129779 Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#573832} [modify] https://crrev.com/bf345a8beda494eb6ae73e1e25cd741abf24ee85/device/fido/mac/browsing_data_deletion.h [modify] https://crrev.com/bf345a8beda494eb6ae73e1e25cd741abf24ee85/device/fido/mac/browsing_data_deletion.mm [modify] https://crrev.com/bf345a8beda494eb6ae73e1e25cd741abf24ee85/device/fido/mac/browsing_data_deletion_unittest.mm
,
Jul 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1ca416dccabb7e514b68e319668ee53ec51dc668 commit 1ca416dccabb7e514b68e319668ee53ec51dc668 Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Jul 11 00:43:19 2018 Add chrome://flags#enable-web-authentication-touch-id This turns the existing WebAuthenticationTouchId feature into a chrome://flags flag. Bug: 678128 Change-Id: I8741f1d66409bdf636645c79cfb2145d679cb8d9 Reviewed-on: https://chromium-review.googlesource.com/1130699 Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#574001} [modify] https://crrev.com/1ca416dccabb7e514b68e319668ee53ec51dc668/chrome/browser/about_flags.cc [modify] https://crrev.com/1ca416dccabb7e514b68e319668ee53ec51dc668/chrome/browser/flag_descriptions.cc [modify] https://crrev.com/1ca416dccabb7e514b68e319668ee53ec51dc668/chrome/browser/flag_descriptions.h [modify] https://crrev.com/1ca416dccabb7e514b68e319668ee53ec51dc668/tools/metrics/histograms/enums.xml
,
Jul 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d54b58e5b08b96664080795a01e0bd2373952e6e commit d54b58e5b08b96664080795a01e0bd2373952e6e Author: Martin Kreichgauer <martinkr@google.com> Date: Thu Jul 12 20:13:31 2018 device/fido/mac: integrate with browsing data deletion This updates browsing data deletion for DATA_TYPE_PASSWORDS to call device::fido::mac::DeleteWebAuthnCredentials, which deletes credentials created by the macOS platform authenticator from the OS keychain. Also combine the two Touch ID specific configuration methods in {Chrome,}AuthenticatorRequestDelegate and introduce a static variant for Chrome. Bug: 678128 Change-Id: I0034e0815da068fb27c1ea60cad95f958956838e Reviewed-on: https://chromium-review.googlesource.com/1125177 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Reviewed-by: Christian Dullweber <dullweber@chromium.org> Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org> Cr-Commit-Position: refs/heads/master@{#574697} [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/chrome/browser/browsing_data/chrome_browsing_data_remover_delegate.cc [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/chrome/browser/webauthn/chrome_authenticator_request_delegate.cc [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/chrome/browser/webauthn/chrome_authenticator_request_delegate.h [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/chrome/browser/webauthn/chrome_authenticator_request_delegate_unittest.cc [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/content/public/browser/authenticator_request_client_delegate.cc [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/content/public/browser/authenticator_request_client_delegate.h [modify] https://crrev.com/d54b58e5b08b96664080795a01e0bd2373952e6e/device/fido/mac/authenticator.h
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29 commit 82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29 Author: Martin Kreichgauer <martinkr@google.com> Date: Mon Jul 16 18:40:11 2018 device/fido/mac: fix a threading bug in TouchIdContext TouchIdContext implements the Touch ID authorization prompt. After receiving the OS reply callback from the Security framework it forwards the result to the user-supplied callback, but doesn't do so on the original TaskRunner that it was invoked on. As a result, Touch ID authenticator requests fail some sequence checker tests. This fixes that by posting the user-supplied callback back on the original runner. Bug: 678128 Change-Id: I0e7a8730ec898f288cd25323134aa95ef50ddbdf Reviewed-on: https://chromium-review.googlesource.com/1136496 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Commit-Position: refs/heads/master@{#575361} [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/get_assertion_operation.h [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/get_assertion_operation.mm [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/make_credential_operation.h [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/operation_base.h [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/touch_id_context.h [modify] https://crrev.com/82d980b04b3f29e9fac4b8ad0a9424e1b9cb2a29/device/fido/mac/touch_id_context.mm
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9be10b62d2a0a79de46380164f4acdf135389376 commit 9be10b62d2a0a79de46380164f4acdf135389376 Author: Martin Kreichgauer <martinkr@google.com> Date: Mon Jul 16 19:40:34 2018 device/fido/mac: set the User Present (UP) bit in authenticator data See https://www.w3.org/TR/webauthn/#sec-authenticator-data. AFAIU, the spec is not exactly clear whether or not to set this bit from a user verifying authenticator. It says that the bit should be set if the user is "present", which is defined as having successfully completed a "user presence test". User presence test is defined separately from user verification test (which is what Touch ID does). Logically, a user verification test always includes a user presence test, but the spec doesn't say so explicitly. Regardless of what the spec says, setting both bits seems less likely to confuse server implementations IMO. A naive server e.g. might *just* check for the UP bit, and if it is not set reject the response, even though the UV bit is set. Hence, we should probably set both. Bug: 678128 Change-Id: I02be366dba324e4f9b83ba0d354a674242fc72dc Reviewed-on: https://chromium-review.googlesource.com/1137216 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Commit-Position: refs/heads/master@{#575386} [modify] https://crrev.com/9be10b62d2a0a79de46380164f4acdf135389376/device/fido/mac/util.mm
,
Jul 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/45fa2bc178d5f5df6381ae274eaf6127932675b9 commit 45fa2bc178d5f5df6381ae274eaf6127932675b9 Author: Martin Kreichgauer <martinkr@google.com> Date: Mon Jul 16 23:08:05 2018 device/fido: move protocol detection into FidoDiscovery This moves the AuthenticatorGetInfo request to determine whether an authenticator supports the kCtap ProtocolVersion out of FidoTask and into FidoDiscovery. As a result, no half-initialized FidoDevice instances are passed into the FidoRequestHandler and FidoTask subclasses. This is going to make it easier to centralize checking of certain request preconditions, like AuthenticatorSelectionCriteria e.g.. Currently checking for those is handled within FidoTask (after completion of the AuthenticatorGetInfo dance), and therefore TouchIdAuthenticator evades it. Determining FidoDevice capabilities upfront allows us to move these checks out of FidoTask such that TouchIdAuthenticator can be covered by them. Bug: 678128 Change-Id: Ie0f9101eeca5ee6d0fbf2d7f8885d9a1dc46d032 Reviewed-on: https://chromium-review.googlesource.com/1135120 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Cr-Commit-Position: refs/heads/master@{#575466} [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fake_fido_discovery_unittest.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_device.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_device.h [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_discovery.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_discovery.h [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_discovery_unittest.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_request_handler_base.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_request_handler_unittest.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_task.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/fido_task.h [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/get_assertion_task.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/get_assertion_task_unittest.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/make_credential_task.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/make_credential_task_unittest.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/mock_fido_device.cc [modify] https://crrev.com/45fa2bc178d5f5df6381ae274eaf6127932675b9/device/fido/mock_fido_device.h
,
Jul 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2b7537268999a6853a3908512f898a3d2e4b6558 commit 2b7537268999a6853a3908512f898a3d2e4b6558 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Jul 17 01:06:01 2018 device/fido: move request precondition checks into request handlers This moves CheckUserVerificationCompatible() from GetAssertionTask into GetAssertionRequestHandler, and CheckIfAuthenticatorSelectionCriteriaSatisfied() from MakeCredentialTask into MakeCredentialRequestHandler. These preconditions are now checked before dispatching a request onto a FidoAuthenticator. This means, precondition checks now cover all types of authenticators, not just FidoDeviceAuthenticator subtypes. The FidoAuthenticator interface gets a new Options() method to support the preconditions check (and an implementation for Touch ID is added). Corresponding unit tests are moved from the FidoTask test into the matching FidoRequestHandler test. Also, remove AuthenticatorSelectionCriteria from the FidoTask class and from the FidoAuthenticator::MakeCredential() signature, where it has become superfluous due to this change. Bug: 678128 Change-Id: I75259e63a8ef4fda4ecb0d8c9f8ff25f10c077a6 Reviewed-on: https://chromium-review.googlesource.com/1135601 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Cr-Commit-Position: refs/heads/master@{#575505} [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_authenticator.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_device.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_device.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_device_authenticator.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_device_authenticator.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/fido_task.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/get_assertion_handler_unittest.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/get_assertion_request_handler.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/get_assertion_task.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/get_assertion_task.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/get_assertion_task_unittest.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/mac/authenticator.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/mac/authenticator.mm [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/mac/browsing_data_deletion_unittest.mm [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/make_credential_handler_unittest.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/make_credential_request_handler.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/make_credential_task.cc [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/make_credential_task.h [modify] https://crrev.com/2b7537268999a6853a3908512f898a3d2e4b6558/device/fido/make_credential_task_unittest.cc
,
Jul 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b4378946e1f28757667494a4a43620bf8d988e9 commit 1b4378946e1f28757667494a4a43620bf8d988e9 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Jul 17 18:32:39 2018 device/fido/mac: invalidate LAContext before deleting it This causes any pending Touch ID consent prompt to be dismissed when the authenticator is deleted, e.g. because the transaction was cancelled. Otherwise the dialog sticks around until the OS lets it time out. (See https://developer.apple.com/documentation/localauthentication/lacontext/1514192-invalidate?changes=_2.) Bug: 678128 Change-Id: Ic4102b54ec78781ed869fa6a7827885ace5345e1 Reviewed-on: https://chromium-review.googlesource.com/1137218 Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Reviewed-by: Robert Sesek <rsesek@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#575729} [modify] https://crrev.com/1b4378946e1f28757667494a4a43620bf8d988e9/device/fido/mac/touch_id_context.mm
,
Jul 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8987fd0ef8e33333f9b529b3e62f8893182a56cf commit 8987fd0ef8e33333f9b529b3e62f8893182a56cf Author: Martin Kreichgauer <martinkr@google.com> Date: Fri Jul 20 22:42:03 2018 device/fido: move post request checks from FidoTask in RequestHandler This extends the scope of these checks to cover non-device authenticators (like Touch ID). The following checks are moved from MakeAssertionTask into MakeAssertionRequestHandler: - |CheckRpIdHash| to verify the RP ID of the request matches the returned credential. The following checks are moved from GetAssertionTask into MakeAssertionRequestHandler: - |CheckRpIdHash| to verify the RP ID of the request matches the returned credential. - |CheckRequirementsOnReturnedUserEntities| to check constraints on the optional UserEntity response field. - |CheckRequirementsOnReturnedCredentialId| to check whether the returned credential id was in the allow list (except for resident keys). Also fixes the following bugs in |CheckRequirementsOnReturnedCredentialId|: - Responses with resident key support should still have their response checked against the allow list if one was provided. - For allow lists of size 1, the credential id may be omitted in the reponse; but if it is not, it must be checked against the allow list. Corresponding unit tests are moved accordingly. Bug: 863988 , 678128 Change-Id: If7b76e7ecac45d96914a62661da9979c62895a25 Reviewed-on: https://chromium-review.googlesource.com/1144403 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Cr-Commit-Position: refs/heads/master@{#577017} [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/fido_request_handler.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/fido_task.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_handler_unittest.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_request_handler.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_request_handler.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_task.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_task.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/get_assertion_task_unittest.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_handler_unittest.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_request_handler.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_request_handler.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_task.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_task.h [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/make_credential_task_unittest.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/mock_fido_device.cc [modify] https://crrev.com/8987fd0ef8e33333f9b529b3e62f8893182a56cf/device/fido/mock_fido_device.h
,
Jul 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9aa7c54540178d4bc52f6ffc87567d76beb99094 commit 9aa7c54540178d4bc52f6ffc87567d76beb99094 Author: Martin Kreichgauer <martinkr@google.com> Date: Fri Jul 27 04:05:54 2018 webauthn: disable platform authenticators in incognito mode This changes IsUserVerifyingPlatformAuthenticatorAvailable to return false in incognito mode, and disable platform authenticator instantiation for MakeCredential/GetAssertion in incognito. Also change IsUVPAA to not return true on platforms where Touch ID is enabled but the embedder does not not provide a configuration. Bug: 678128 Change-Id: I2fc6b0182fcb9ae718acd842f1247baee81c5281 Reviewed-on: https://chromium-review.googlesource.com/1149115 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Commit-Position: refs/heads/master@{#578535} [modify] https://crrev.com/9aa7c54540178d4bc52f6ffc87567d76beb99094/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/9aa7c54540178d4bc52f6ffc87567d76beb99094/content/browser/webauth/authenticator_impl.h [modify] https://crrev.com/9aa7c54540178d4bc52f6ffc87567d76beb99094/device/fido/mac/authenticator.h
,
Jul 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e commit 43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e Author: Martin Kreichgauer <martinkr@google.com> Date: Mon Jul 30 19:59:41 2018 device/fido: fix attestation format used in Touch ID TouchIdAuthenticator was using FidoAttestationStatement, which is fido-u2f, when it should have been using packed format. This adds a PackedAttestationStatement class and changes the Touch ID code to use it. Bug: 868571 , 678128 Change-Id: I84626df6299d4d9df44500dcbbba365e9a30f2a2 Reviewed-on: https://chromium-review.googlesource.com/1153849 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Commit-Position: refs/heads/master@{#579131} [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/BUILD.gn [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/BUILD.gn [rename] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/attestation_statement_formats.cc [add] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/attestation_statement_formats.h [add] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/attestation_statement_formats_unittest.cc [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/authenticator_make_credential_response.cc [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/ctap_response_unittest.cc [delete] https://crrev.com/e9a9227483671255fbb14458be5310f62778b60f/device/fido/fido_attestation_statement.h [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/fido_test_data.h [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e/device/fido/mac/util.mm
,
Jul 31
,
Aug 1
,
Aug 2
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ba41bf8405450227b7ef580e40bbba1662efdc45 commit ba41bf8405450227b7ef580e40bbba1662efdc45 Author: Martin Kreichgauer <martinkr@google.com> Date: Thu Aug 02 21:30:33 2018 [Merge M69]device/fido: fix attestation format used in Touch ID TouchIdAuthenticator was using FidoAttestationStatement, which is fido-u2f, when it should have been using packed format. This adds a PackedAttestationStatement class and changes the Touch ID code to use it. (cherry picked from commit 43debfd7d6cdb16ba2bf2c5226eeaa85d7c5387e) Bug: 868571 , 678128 Change-Id: I84626df6299d4d9df44500dcbbba365e9a30f2a2 Reviewed-on: https://chromium-review.googlesource.com/1153849 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#579131} Reviewed-on: https://chromium-review.googlesource.com/1161252 Cr-Commit-Position: refs/branch-heads/3497@{#354} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/BUILD.gn [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/BUILD.gn [rename] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/attestation_statement_formats.cc [add] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/attestation_statement_formats.h [add] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/attestation_statement_formats_unittest.cc [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/authenticator_make_credential_response.cc [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/ctap_response_unittest.cc [delete] https://crrev.com/39157691ae59c1eb8d145cc17ecd2f2d3ec11d8d/device/fido/fido_attestation_statement.h [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/fido_test_data.h [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/mac/make_credential_operation.mm [modify] https://crrev.com/ba41bf8405450227b7ef580e40bbba1662efdc45/device/fido/mac/util.mm
,
Aug 6
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/73a4f93cf24731ce084bbb7acddd72b740cc5376 commit 73a4f93cf24731ce084bbb7acddd72b740cc5376 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Aug 14 12:16:22 2018 fido/mac: Change AAGUID for Touch ID self-authentication to all zeroes. Touch ID previously used a non-zero AAGUID chosen by us. But WebAuthn requires self-attestation to use an all-zero AAGUID value. Also delete the unused |TouchIdAaguid| function. Bug: 678128 Change-Id: I27bc82f7248d2c22ede773c0e6b010f56022d255 Reviewed-on: https://chromium-review.googlesource.com/1172911 Reviewed-by: Adam Langley <agl@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#582888} [modify] https://crrev.com/73a4f93cf24731ce084bbb7acddd72b740cc5376/device/fido/mac/util.h [modify] https://crrev.com/73a4f93cf24731ce084bbb7acddd72b740cc5376/device/fido/mac/util.mm
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c commit a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Aug 14 20:44:10 2018 fido: disable Touch ID for makeCredential with AuthenticatorAttachment::kAny This disables platform authenticators (i.e. Touch ID) for makeCredential requests with an unset AuthenticatorAttachment value in AuthenticatorSelectionCriteria. This is done to prevent Touch ID fingerprint prompts for requests that could be handled by external authenticators, as long as Touch ID is not integrated with UI. Filed crbug.com/873710 to track reversal of this change once UI integration is there. Bug: 678128 Change-Id: I7aaffe53dfca7ee14b5a94f9ead2027ab370c35c Reviewed-on: https://chromium-review.googlesource.com/1172912 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#583020} [modify] https://crrev.com/a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c/device/fido/ctap_response_unittest.cc [modify] https://crrev.com/a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c/device/fido/fido_test_data.h [modify] https://crrev.com/a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c/device/fido/make_credential_handler_unittest.cc [modify] https://crrev.com/a37f17593eb309fbbd5e4be7bfea3e95d6a4bd1c/device/fido/make_credential_request_handler.cc
,
Aug 14
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f81d3dc3188d5c56aedf94e522393332e87abe26 commit f81d3dc3188d5c56aedf94e522393332e87abe26 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Aug 14 22:11:09 2018 fido: avoid hairpinning of FidoRequestHandlerBase callbacks Currently, the |FidoRequestHandlerBase::AddAuthenticator| method synchronously invokes the virtual |DispatchRequest| method, which subclasses implement to process the request and invoke the response handling callback. Most authenticators are instantiated by a |FidoDiscovery| which does some asynchronous discovery work and then calls |AddAuthenticator|. Platform authenticators, on the other hand, are instantiated by |MaybeAddPlatformAuthenticator|, which gets invoked synchronously with request handler instantiation. This makes it possible to have a synchronous code path from request handler instantation to response callback invocation (i.e. hairpinning). In those cases, |AuthenticatorImpl| is unable to handle the response (see e.g. https://cs.chromium.org/chromium/src/content/browser/webauth/authenticator_impl.cc?sq=package:chromium&dr&g=0&l=749). This change makes |DispatchRequest| invocation asynchronous, which eliminates any possibility of response callback hairpinning. Bug: 678128 Change-Id: I6bf273775885abac1fa38fe12c964e930407cc7e Reviewed-on: https://chromium-review.googlesource.com/1172917 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Cr-Commit-Position: refs/heads/master@{#583051} [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/fido_request_handler_base.cc [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/fido_request_handler_base.h [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/fido_request_handler_unittest.cc [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/get_assertion_request_handler.cc [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/get_assertion_request_handler.h [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/make_credential_request_handler.cc [modify] https://crrev.com/f81d3dc3188d5c56aedf94e522393332e87abe26/device/fido/make_credential_request_handler.h
,
Aug 21
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ccb151f399ed5decac6538102cbcc3b6c3367569 commit ccb151f399ed5decac6538102cbcc3b6c3367569 Author: Martin Kreichgauer <martinkr@google.com> Date: Tue Aug 21 20:55:37 2018 device/fido/mac: allow password fallback for Touch ID This relaxes the access control restriction for keychain items created by the Touch ID authenticator to require biometric authentication *or* password entry. The effect is that the native Touch ID dialog will show a "use password" button next to the cancel button. Not that despite the name of the kSecAccessControlUserPresence attribute, the TouchIdAuthenticator is still user-*verifying* (passcode entry is a valid user verification method in the WebAuthN spec). Related Apple Developer documentation can be found here: https://developer.apple.com/documentation/security/secaccesscontrolcreateflags/ksecaccesscontroluserpresence?language=objc This change is somewhat backwards-incompatible: If a user tries to authenticate using a credential created *before* this change *and* actually chooses the "Use Password" fallback, they will afterwards be prompted with a second Touch ID dialog that does not have the password fallback button. This is acceptable since the feature hasn't launched yet. Bug: 678128 Change-Id: If4e3461ccd378bac286dbba68c3011fee2eb0fa3 Reviewed-on: https://chromium-review.googlesource.com/1183636 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#584896} [modify] https://crrev.com/ccb151f399ed5decac6538102cbcc3b6c3367569/device/fido/mac/touch_id_context.mm
,
Aug 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/61b63bd8bb1ef2ec4b71453dcb06b2878ef9025d commit 61b63bd8bb1ef2ec4b71453dcb06b2878ef9025d Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Aug 22 09:51:19 2018 fido: disable back button in Touch ID UI sheet TouchIdAuthenticator currently fails a DCHECK when GetAssertion or MakeCredential get invoked multiple times. Using the Back button (and then proceeding to Touch ID again) can trigger a second call to DispatchRequest and therefore the DCHECK fail. Clicking the back button on the Touch ID sheet would not dismiss the native Touch ID dialog, which would then hover over the welcome screen sheet. So simply disabling the button seems like the right thing to do. Bug: 678128 , 847985 Change-Id: I90dbf5ab016a177811575a4db61ca12d15e43841 Reviewed-on: https://chromium-review.googlesource.com/1184236 Commit-Queue: Balazs Engedy <engedy@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#584983} [modify] https://crrev.com/61b63bd8bb1ef2ec4b71453dcb06b2878ef9025d/chrome/browser/ui/webauthn/sheet_models.cc [modify] https://crrev.com/61b63bd8bb1ef2ec4b71453dcb06b2878ef9025d/chrome/browser/ui/webauthn/sheet_models.h
,
Aug 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5bac165c3a66f63ce3511975a81d72c8b7031058 commit 5bac165c3a66f63ce3511975a81d72c8b7031058 Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Aug 22 16:41:10 2018 fido: return NOT_ALLOWED_ERROR for OPERATION_DENIED from platform authenticator This changes FidoRequestHandler to translate any CtapDeviceResponseCode::kCtap2ErrOperationDenied (CTAP2_ERR_OPERATION_DENIED) responses from platform authenticators into FidoReturnCode::kUserConsentDenied. Upon receiving this error, all outstanding authenticator requests are cancelled, and the error is bubbled up into a NOT_ALLOWED_ERROR. More concretely, this is going to change UI behavior such that the request is cancelled if the user clicks cancel or fails verification in the native macOS Touch ID dialog. The WebAuthn spec in sections 5.1.3 and 5.1.4 states that "If any authenticator returns a status indicating that the user cancelled the operation", which indicate that the UA should cancel the entire operation and return NOT_ALLOWED_ERROR in this case". CTAP2_ERR_OPERATION_DENIED is used by the CTAP2 spec to signal - user declined to create a credential - user failed gesture verification - time out during user consent collection - user failing to select a credential on authenticators with account chooser UI (deny or timeout) Because of the reference to authenticator-defined timeouts, it is debatable whether this CTAP error sufficiently indicates that "the user cancelled the operation". For internal authenticators (Touch ID), however, this is definitely the case. I will track a follow-up discussion whether to extend this behavior to external authenticators also in crbug/875982. Also fix a bug in MockFidoDevice GetId generation and add a |ExpectCtapRequestAndReturnError| helper method. Bug: 875982 , 678128 Change-Id: I616b319accb7d387c0d98de059c52b04bc80ce59 Reviewed-on: https://chromium-review.googlesource.com/1181863 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Jun Choi <hongjunchoi@chromium.org> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#585070} [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/content/browser/webauth/authenticator_impl.cc [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_constants.h [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_request_handler.h [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/fido_request_handler_unittest.cc [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/get_assertion_handler_unittest.cc [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/make_credential_handler_unittest.cc [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/mock_fido_device.cc [modify] https://crrev.com/5bac165c3a66f63ce3511975a81d72c8b7031058/device/fido/mock_fido_device.h
,
Aug 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e03ef80704ff372bde51966b9ea54074754c8e34 commit e03ef80704ff372bde51966b9ea54074754c8e34 Author: Martin Kreichgauer <martinkr@google.com> Date: Thu Aug 23 09:40:05 2018 fido: add a delay for dispatching requests to Touch ID from the UI Bug: 678128 , 847985 , 876806 Change-Id: I27acd32a7796edff6aabce304b698365063a4f7e Reviewed-on: https://chromium-review.googlesource.com/1185237 Reviewed-by: Balazs Engedy <engedy@chromium.org> Commit-Queue: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#585439} [modify] https://crrev.com/e03ef80704ff372bde51966b9ea54074754c8e34/chrome/browser/webauthn/authenticator_request_dialog_model.cc
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ad9b63e7496393cf05c145b3636a7c1258363926 commit ad9b63e7496393cf05c145b3636a7c1258363926 Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Aug 29 13:38:54 2018 fido/mac: require user interaction before returning any error on GetAssertion The TouchIdAuthenticator previously skipped the Touch ID prompt if no matching credential existed for a GetAssertion request. This information is now passed up into the UI at authenticator instantiation time, so the authenticator does not need to handle it. Instead, it should implement safe, spec-compliant behavior and *always* prompt the user before returning an error. Bug: 678128 Change-Id: I6aff58807a9c0b9b7b2f2f154af60f5103be5ac9 Reviewed-on: https://chromium-review.googlesource.com/1194953 Reviewed-by: Balazs Engedy <engedy@chromium.org> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/heads/master@{#587094} [modify] https://crrev.com/ad9b63e7496393cf05c145b3636a7c1258363926/device/fido/mac/get_assertion_operation.h [modify] https://crrev.com/ad9b63e7496393cf05c145b3636a7c1258363926/device/fido/mac/get_assertion_operation.mm
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37 commit 311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37 Author: Martin Kreichgauer <martinkr@google.com> Date: Wed Aug 29 16:09:12 2018 webauthn: add special error sheet for GetAssertion on internal transport This adds a special error screen for GetAssertion requests that are about to be dispatched to Touch ID but there is no available credential in the keychain. The screen can be reached by selecting Touch ID from the transport selection UI. If Touch ID is the only available transport, the UI auto advances to the error screen. This also fixes a bug where the UI auto advanced to the regular Touch ID screen on GetAssertion even though no matching credential was present. Bug: 678128 , 847985 Change-Id: Ia4ce02a495821c7d0a3caa34c7a2e7eaeb1cbc42 Reviewed-on: https://chromium-review.googlesource.com/1194954 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#587140} [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/ui/views/webauthn/sheet_view_factory.cc [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/ui/webauthn/sheet_models.cc [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/ui/webauthn/sheet_models.h [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/webauthn/authenticator_request_dialog_model.cc [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/webauthn/authenticator_request_dialog_model.h [modify] https://crrev.com/311a2e6f35ab9ba7d998d2aeb2afc7c20d806d37/chrome/browser/webauthn/authenticator_request_dialog_model_unittest.cc
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1abf6643628c17a905420f9366adf04a84f3ebf6 commit 1abf6643628c17a905420f9366adf04a84f3ebf6 Author: Martin Kreichgauer <martinkr@google.com> Date: Thu Aug 30 14:55:29 2018 webauthn: prevent UI from dispatching to the same authenticator multiple times Using the transport switch drop-down menu, it is possible to cycle away from and then back to the Touch ID sheet, which currently causes the request to be dispatched onto the TouchIdAuthenticator each time the sheet is shown. This sort of works in the production build (it restarts the request, which will make the Touch ID dialog disappear and then reappear). In debug, however, it crashes on a DCHECK. We haven't defined whether a FidoAuthenticator should be able to handle multiple invocations of MakeCredential/GetAssertion over the lifetime of the instance. Hence, the UI should stop doing this. Bug: 678128 , 847985 Change-Id: Id008de98bc8aa6477e9863ca2e22cd136316b423 Reviewed-on: https://chromium-review.googlesource.com/1196427 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Reviewed-by: Balazs Engedy <engedy@chromium.org> Cr-Commit-Position: refs/heads/master@{#587575} [modify] https://crrev.com/1abf6643628c17a905420f9366adf04a84f3ebf6/chrome/browser/webauthn/authenticator_request_dialog_model.cc [modify] https://crrev.com/1abf6643628c17a905420f9366adf04a84f3ebf6/chrome/browser/webauthn/authenticator_request_dialog_model.h [modify] https://crrev.com/1abf6643628c17a905420f9366adf04a84f3ebf6/chrome/browser/webauthn/authenticator_request_dialog_model_unittest.cc
,
Jan 10
This launched in M70, so closing this out. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by rsleevi@chromium.org
, Jan 4 2017