kSecAttrAccessControl vs kSecAttrAccessible for biometric least-privilege

Direct Resolution

kSecAttrAccessControl does not provide an internal mechanism to enforce expiration; manual date verification is required by the application logic after the item is retrieved. Combining biometric prompts with device-state attributes is not redundant; they operate at different layers of the security stack: kSecAttrAccessible governs the availability of the encryption keys based on the device lock state, while kSecAttrAccessControl governs the user interaction required to release the secret.

Technical Explanation

Expiration and Lifecycle

The kSecAttrExpirationDate attribute is a metadata field. The Security framework does not treat this as a hard gate during the SecItemCopyMatching process. If the access control requirements are met, the keychain will return the item regardless of whether the expiration date has passed. To implement a least-privilege lifecycle, you must retrieve the item and manually compare the stored expiration date against the current system time before utilizing the credential.

Interaction of Access Attributes

In a least-privilege architecture, these two attributes serve distinct purposes:

• kSecAttrAccessible (Data Protection Class): Determines when the item is decrypted and available in the keychain's memory. For example, kSecAttrAccessibleWhenUnlocked ensures the data is encrypted on disk and unavailable until the user unlocks the device.
• kSecAttrAccessControl (User Presence): Adds a secondary requirement for a specific action (e.g., kSecAccessControlUserPresence or kSecAccessControlBiometryCurrentSet). This ensures that even if the device is already unlocked, the specific secret cannot be accessed without a fresh biometric or passcode challenge.

Using both prevents a scenario where a background process or a compromised app could access a secret simply because the device is in an "unlocked" state.

Implementation Steps

1. Define Access Control: Create a SecAccessControlRef using SecAccessControlCreateWithFlags, specifying the protection level (e.g., kSecAttrAccessibleWhenUnlocked`) and the biometric flags.
2. Store the Item: Pass this reference into the kSecAttrAccessControl key of your attributes dictionary.
3. Retrieve and Validate: Call SecItemCopyMatching. Upon successful retrieval, extract the kSecAttrExpirationDate and perform a manual date comparison in your Objective-C logic.
4. Purge Stale Data: If the date has passed, explicitly call SecItemDelete to remove the expired credential.

Verification

To verify this behavior, you can perform the following tests:

• Expiration Test: Store an item with a kSecAttrExpirationDate set to a date in the past. Attempt to retrieve it; if SecItemCopyMatching returns the item, manual validation is confirmed as necessary.
• Prompt Test: Set kSecAttrAccessControl to require biometrics and ensure the system triggers the FaceID/TouchID prompt even when the device is already unlocked.

Diagnostic Detail Required: Are you targeting a specific iOS/macOS version? Behavior regarding kSecAccessControlBiometryCurrentSet (which invalidates items when new biometrics are added) varies across OS versions.