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}
Showing
Please register or sign in to comment