commit d5b519e817d07443baf76ad4153ad414f009b020
author Martin Kreichgauer <martinkr@google.com> Wed Aug 17 18:13:48 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Aug 17 18:13:48 2022
tree c3c85f73d19c00c5b305c4e12ef183c72adb2a92
parent c7f7dd0aa2c2404ccab441a9cffbb4d73d4938cb

fido/mac: fix a bug in keychain item handling

CL:3781120 changed the data persisted into the kSecAttrApplicationTag
attribute for new credentials. Prior to that change, and up to
CredentialMetadata version 2, the field contained an encoding of (RP ID,
user ID); the CL makes that field store the encrypted metadata. Another
thing that CL changed was the data type of the stored value, from
CFStringRef to CFDataRef (because the official keychain docs say it
should be CFDataRef:
https://developer.apple.com/documentation/security/ksecattrapplicationtag?language=objc#:~:text=The%20corresponding%20value%20is%20of%20type%20CFDataRef%20and%20contains%20private%20tag%20data).

However, TouchIdCredentialStore::FindCredentialsImpl() expected all
query keychain items to contain CFDataRef, and returned absl::nullopt if
that wasn't true. This made credential lookups in the Touch ID
authenticator fail in the presence of older (version < 3) credentials
for the given RP.

To fix this, change TouchIdCredentialStore::FindCredentialsImpl() to not
bail entirely if kSecAttrApplicationTag doesn't contain the expected
type.

An existing test in CredentialStoreTest would have caught this issue, if
it hadn't been for a test bug where creating a legacy credential
mistakenly created a V3 credential. So this fix that bug as well.

Fixed: 1353101
Change-Id: I6cc04e84c1a011b5db1eed96734792fa9cd8aa4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3832144
Reviewed-by: Adam Langley <agl@chromium.org>
Commit-Queue: Adam Langley <agl@chromium.org>
Auto-Submit: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/main@{#1036179}