Post

Replies

Boosts

Views

Activity

iOS 26/27 Passwords App: Keychain Accessibility Classes and Locked-AFU Protection
I’m looking for technical clarification on how the standalone Apple Passwords app protects credentials on iOS 26 and iOS 27, specifically when a device is locked after its first unlock since boot (AFU). Apple’s Platform Security documentation identifies Safari website passwords as using the When Unlocked Keychain protection class: https://support.apple.com/guide/security/secb0694df1a/web However, it is unclear whether this documentation also describes the implementation of the newer standalone Passwords app. Keychain accessibility classes Does the Passwords app continue to store website and application passwords using kSecAttrAccessibleWhenUnlocked or an equivalent, more restrictive class? Do passkeys, TOTP verification-code secrets, and any intermediate keys necessary to decrypt stored credentials receive the same protection? Locked-AFU protection When an iPhone has been unlocked once since boot and subsequently locked again, are the cryptographic keys required to retrieve saved website passwords inaccessible until the user unlocks the device again? Specifically, does the When Unlocked class enforce this restriction cryptographically, or could a process with elevated operating-system privileges retrieve the protected material while the device remains locked? Full-filesystem and Keychain extraction Assuming an authorized forensic examiner obtains a full-filesystem extraction or privileged operating-system execution on a device that remains locked in AFU, but does not know the device passcode: Does filesystem access alone expose usable plaintext credentials stored in Apple Passwords? Are additional cryptographic keys or authentication steps required? What security guarantees remain for When Unlocked Keychain items under these conditions? I’m not requesting information about undisclosed vulnerabilities or specific forensic-tool exploits. I’m interested in the documented behavior and security boundaries of Apple’s Keychain architecture. Independent verification Are there any published technical assessments, research papers, forensic experiments, or Apple security documents that verify the actual accessibility classes used by the Passwords app on iOS 26/27? For context, a 2026 independent security assessment of Proton Pass identified its use of kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for sensitive Keychain material as a defense-in-depth weakness and recommended kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I’m trying to understand whether Apple’s native Passwords app provides a stronger cryptographic boundary against locked-AFU extraction, rather than merely a different user-interface authentication requirement. Any clarification from an Apple engineer or references to authoritative technical documentation would be greatly appreciated.
0
0
24
8h
iOS 26/27 Passwords App: Keychain Accessibility Classes and Locked-AFU Protection
I’m looking for technical clarification on how the standalone Apple Passwords app protects credentials on iOS 26 and iOS 27, specifically when a device is locked after its first unlock since boot (AFU). Apple’s Platform Security documentation identifies Safari website passwords as using the When Unlocked Keychain protection class: https://support.apple.com/guide/security/secb0694df1a/web However, it is unclear whether this documentation also describes the implementation of the newer standalone Passwords app. Keychain accessibility classes Does the Passwords app continue to store website and application passwords using kSecAttrAccessibleWhenUnlocked or an equivalent, more restrictive class? Do passkeys, TOTP verification-code secrets, and any intermediate keys necessary to decrypt stored credentials receive the same protection? Locked-AFU protection When an iPhone has been unlocked once since boot and subsequently locked again, are the cryptographic keys required to retrieve saved website passwords inaccessible until the user unlocks the device again? Specifically, does the When Unlocked class enforce this restriction cryptographically, or could a process with elevated operating-system privileges retrieve the protected material while the device remains locked? Full-filesystem and Keychain extraction Assuming an authorized forensic examiner obtains a full-filesystem extraction or privileged operating-system execution on a device that remains locked in AFU, but does not know the device passcode: Does filesystem access alone expose usable plaintext credentials stored in Apple Passwords? Are additional cryptographic keys or authentication steps required? What security guarantees remain for When Unlocked Keychain items under these conditions? I’m not requesting information about undisclosed vulnerabilities or specific forensic-tool exploits. I’m interested in the documented behavior and security boundaries of Apple’s Keychain architecture. Independent verification Are there any published technical assessments, research papers, forensic experiments, or Apple security documents that verify the actual accessibility classes used by the Passwords app on iOS 26/27? For context, a 2026 independent security assessment of Proton Pass identified its use of kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for sensitive Keychain material as a defense-in-depth weakness and recommended kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I’m trying to understand whether Apple’s native Passwords app provides a stronger cryptographic boundary against locked-AFU extraction, rather than merely a different user-interface authentication requirement. Any clarification from an Apple engineer or references to authoritative technical documentation would be greatly appreciated.
Replies
0
Boosts
0
Views
24
Activity
8h