Before device Reboot: Here no issue from keychain.
2025-06-17 11:18:17.956334 +0530 WAVE PTX [DB_ENCRYPTION] Key successfully retrieved from the Keychain default
When device is in reboot and locked (Keychain access is set to FirstUnlock) App got woken up in background
SEEMS(NOT SURE) DEVICE STILL IN LOCKED STARE IF YES THEN WHICH IS EXPECTED 2025-06-17 12:12:30.036184 +0530 WAVE PTX <ALA_ERROR>: [OS-CCF] [DB_ENCRYPTION] Error while retriving Private key -25308 default 2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default
——————————————————
And as per logs, here user has launch the application post unlock and application never got the keychain access here also.
HERE STILL HAS ISSUE WITH KEYCHAIN ACCESS.
2025-06-17 12:52:55.640976 +0530 WAVE PTX DEBUG : willFinishLaunchingWithOptions default 2025-06-17 12:52:55.651371 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default
Does SecItemDelete should also fail … in case of Device in locked state … right?
No.
The keychain database as a whole is available at all times. Keychain item protection is implemented by encrypting specific attributes of the keychain item. When you read the item, the system goes to decrypt those attributes. If the required key material isn’t available, then the read operation fails.
However, the system doesn’t need that key material in order to delete the item, and thus it’s possible to delete an item that you can’t currently access.
This makes more sense if you have a little understanding of how the keychain actually works internally. Have a read of SecItem: Fundamentals, and specifically its The Four Freedoms^H^H^H^H^H^H^H^H Functions section. In that model, the content column of a row is encrypted (based on the kSecAttrAccessible
column) but that doesn’t stop you from deleting the entire row.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"