Application is not able to access any keychain info on application launch post device reboot

Further analysis: When client couldn't get the key from the keychain then it goes for a key to save in keychain for the same identity anyway here on this task keychain error occured, does any chance on this might have deleted the existing key from keychain even though keychain locked:?

2025-06-17 12:12:30.246151 +0530 securityd insert failed for item <keys,kcls=0,klbl=3026A4A26A2CF40D21517C07AD2BEA631768FDBF,atag=636F6D2E6D73692E696E737461506F432E617373796D65747269632E7075626C69634B6579,crtr=0,type=42,bsiz=2048,esiz=2048,sdat=2001-01-01 00:00:00 +0000,edat=2001-01-01 00:00:00 +0000,agrp=group.com.msikodiak.eptt,sync=0,musr=, |otherAttr,tomb=0,cdat=2025-06-17 06:42:30 +0000,mdat=2025-06-17 06:42:30 +0000,perm=1,priv=1,modi=1,sens=0,asen=0,extr=1,next=0,encr=1,decr=0,drve=0,sign=0,vrfy=1,snrc=0,vyrc=0,wrap=1,unwp=0,pdmn=ck,sha1=4D6CC4172C5F6BA16D034165E2E365A070D16347,v_Data=<?>,UUID=7B669714-C788-4AAD-9992-52A706742B45,persistref=9295DE3FB385455BACFAA0E4656FE30E,clip=0> with Error Domain=NSOSStatusErrorDomain Code=-25308 "ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?)." UserInfo={numberOfErrorsDeep=0, NSDescription=ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?).} default

2025-06-17 12:12:30.263329 +0530 securityd deleted <keys, |otherAttr,rowid=374,sha1=005C72451B95532930BD165CE3F0D174DA2CD1B1,clip=0> from <SecDbConnection rw open> default

2025-06-17 12:12:30.265810 +0530 securityd WAVE PTX[235]/1#12 LF=0 add Error Domain=NSOSStatusErrorDomain Code=-25308 "ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?)." UserInfo={numberOfErrorsDeep=0, NSDescription=ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?).} default HK

I’d like to clarify what you’re complaint is here. It seems that:

• You have a keychain item whose access is set to one of the after-first-unlock values.

• Your app is being launched before first unlock.

• And thus can’t access the item.

Is that right?

If so, that seems to be the keychain working as designed.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

You have a keychain item whose access is set to one of the after-first-unlock values. YES

Your app is being launched before first unlock. YES

And thus can’t access the item.

To clarify further,

Here App got launched in background when device is still locked state and tries to access the keychain item and it got failed which is expected, the same time client tries to save the keychain item for the same keychain item id which is also got failed as expected BUT DOES THIS SAVE ATTEMPT DELTES THE EXSTING ONE when device is locked ?

2025-06-17 12:12:30.263329 +0530 securityd deleted <keys, |otherAttr,rowid=374,sha1=005C72451B95532930BD165CE3F0D174DA2CD1B1,clip=0> from <SecDbConnection rw open> default

2025-06-17 12:12:30.265810 +0530 securityd WAVE PTX[235]/1#12 LF=0 add Error Domain=NSOSStatusErrorDomain Code=-25308 "ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?)." UserInfo={numberOfErrorsDeep=0, NSDescription=ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?).} default

Device unlocked here

2025-06-17 12:15:11.172081 +0530 symptomsd First unlock occurred, proceeding default

When attempted to retrive the same key post unlock, client never got the key says key not found

2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default

That depends. During this save:

• Which SecItem calls are you making?

• And which one fails?

• And with what error?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Wanted to understand the Keychain behaviour in case Device is rebooted and Locked state:

• SecItemCopyMatching: this API throws error saying Keychain locked(-25800), AS EXPECTED
• SecItemDelete: this API doesn't throws any error on deletion(how this is happened even though device is locked): but as per logs looks deleted the key ?? NOT SURE WHAT's happening in the issue case as explained below, later key not found from the keychain
• SecItemAdd: this API also throws error saying Keychain locked(-25800), AS EXPECTED

Here I see that below is executed without any error, meant Delete API succeeded without any error(device is still locked)

OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);
 

But below SAVE API failed with error KEYCHAIN LOCKED but it is not same for Delete API as mentioned above on the same time

        status = SecItemAdd((__bridge CFDictionaryRef)query, NULL);

ERROR: 2025-06-17 12:12:30.265810 +0530 securityd WAVE PTX[235]/1#12 LF=0 add Error Domain=NSOSStatusErrorDomain Code=-25308 "ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?)." UserInfo={numberOfErrorsDeep=0, NSDescription=ks_crypt: e00002e2 failed to 'od' item (class 7, bag: 0) Access to item attempted while keychain is locked (hibernation?).} default HK

So the Query is Does SecItemDelete should also fail(shouldn't delete the key) in case of Device in locked state(First reboot), right? : I dont find any logs indicating the success or failure in this case

If this is not deleted at this moment, then next client queries the same key post device First Unlock says key not exist

`2025-06-17 12:15:11.172081 +0530 symptomsd First unlock occurred, proceeding default

2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default `

Code: keyIdentifier is same for both case

+ (BOOL)saveSymetricKeyToKeychain:(NSData *)symmetricKeyData keyIdentifier:(NSString *)keyIdentifier
{
    NSString *appGrpIdentifier = [SQLiteExtUtil getAppGroupIdentifier];
    NSDictionary *query = @{
            (__bridge id)kSecClass: (__bridge id)kSecClassKey,
            (__bridge id)kSecAttrApplicationTag: keyIdentifier,
            (__bridge id)kSecValueData: symmetricKeyData,
            (__bridge id)kSecAttrKeyClass: (__bridge id)kSecAttrKeyClassSymmetric,
            (__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlock,
            (__bridge id)kSecAttrAccessGroup: appGrpIdentifier
        };
 
        // First, check if the key already exists in the Keychain. To handle downgrade client upgrade usecases
        OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);
        if (status != errSecSuccess && status != errSecItemNotFound) {
            NSLog(@"<ALA_ERROR> [DB_ENCRYPTION] Error deleting existing key: %d", (int)status);
            return NO;
        }
 
        // Now add the key to the Keychain
        status = SecItemAdd((__bridge CFDictionaryRef)query, NULL);
        
        if (status == errSecSuccess) {
            NSLog(@"[DB_ENCRYPTION] Key successfully stored in the Keychain");
            return YES;
        } else {
            NSLog(@"<ALA_ERROR> [DB_ENCRYPTION] Error storing key in the Keychain: %d", (int)status);
            return NO;
        }
}
 
// Retrieve a symmetric key from the Keychain
+ (NSData *)retrieveSymmetricKeyFromKeychain:(NSString *)keyIdentifier
{
    NSDictionary *query = @{
        (__bridge id)kSecClass: (__bridge id)kSecClassKey,
        (__bridge id)kSecAttrApplicationTag: keyIdentifier,
        (__bridge id)kSecReturnData: (__bridge id)kCFBooleanTrue,
        (__bridge id)kSecAttrKeyClass: (__bridge id)kSecAttrKeyClassSymmetric
    };
 
    CFTypeRef result = NULL;
    OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &result);
    
    if (status == errSecSuccess) {
        NSLog(@"[DB_ENCRYPTION] Key successfully retrieved from the Keychain");
        return (__bridge NSData *)result;
    } else {
        NSLog(@"<ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: %d", (int)status);
        return nil;
    }
}

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"

Thanks for the update, this helps to address the issue.

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.