Keychain error -34018 (errSecMissingEntitlement)

Yes, I still get this in my app. But I'm also getting a new one:

SecItemCopyMatching status: -25300

I'm not sure what this one means though but it happens when I launch my app and access the keychain during the launch process.

I have multiple keys in my Keychain that I'm trying to access on launch and they all fail with the above error. Although it could mean that the keys are not available int he keychain yet.

UPDATE: We have finally been able to reproduce the -34018 error on iOS 8.3. This is the first step in identifying the root cause and then coming up with a fix.

As usual, we can't commit to a release timeframe, but this has affected many developers and we really want to get this resolved.

Earlier I suggested adding a small delay in application:didFinishLaunchingWithOptions and applicationDidBecomeActive: before accessing the keychain as a workaround. However, that doesn't actually appear to help. That means that there's no known workaround at this time other than relaunching the app.

The issue appears to be related to memory pressure, so perhaps being more aggressive in handling memory warnings may alleviate the problem.

--gc

I have a consistent repro, in an app that uses the keychain whenever it gets to foreground. I have seen similar repro steps in the forums before, but adding mine too:

- run the app on device with debugger attached

- go to homescreen and open a lot of other apps until xcode reports the app to have less than 30kb of memory (this will often lead to app termination, you have to try several times)

- open the app, keychain returns a 34018 error until app is terminated

I have tried to use access keychain in a dispatch_after with up to a couple of seconds delay, without this fixing the issue. So at least under very low memory conditions, the suggested workaround doesn't work for me.

Hey gc.,

I came to this forums to ask this exact question, but searched first and found this post.

> The best we can tell so far, it's an issue with accessing the keychain too soon after the app has been launched or resumed.

This rings very true in my scenario. Right now, I can only recreate it maybe 5-10% of the time. I usually open another app, and then re-open my application, and receive the error.

I was considering encrypting things on my own and storing them in NSUserDefaults because this issue is rendering my app un-usable. However, I see your comment here...

> For a workaround, try adding a small delay in application:didFinishLaunchingWithOptions and applicationDidBecomeActive: before accessing the keychain.

What type of delay do you recommend? Is 0.1s going to suffice?

Hey gc,

we are also having this issue... and it's a pretty major one for us. It is single-handedly preventing us from releasing our app. We have been struggling with this for months so some workaround would really save us.

We have tried with the delay (sleep(0.5)) as you have suggested but we've had no luck. Could you give us some more details on how we could work around this?

Thanks!

This bug is actually very easy to reproduce. That being said why has Apple not fixed it after years of reports/examples etc. https://github.com/DinosaurDad/Keychain-34018

I agree. We have tried everything and we've received no response from Apple everytime.

If they are working on this, the communication has been very poor. If they aren't, than we expect better from Apple.

Can we have at least some kind of reply from an Apple Staffer?

Just wanted to post to all here that we've received some news from Apple today.

Apparently they are working on this and suggest that postponing keychain access until application:didFinishLaunchingWithOptions or applicationdidBecomeActive mitigates the problem.

We are trying this, although we will be sacrificing state restoration (still better than a crashing app).

Is there any suggested alternative best practice for storing sensitive data like tokens?

APPLE? Beuller? Beuller?

There are strict limits on the amount and type of information I can share here. I will say that:

• Keychain engineering is well aware of how important this issue is.

• The primary problem has been reproducing the failure here at Apple.

• We're now able to do that (largely thanks to the work you guys have put in filing and following up on your bug reports).

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have a different error, but it seems related to me.

App goes in the background and saves state for UI restoration.

User locks device (key / fingerprint enabled)

App is terminated by the OS for low memory conditions

App is launched by WatchKit extension: WKInterfaceController.openParentApplication -> ApplicationDelegate.handleWatchKitExtensionRequest

Console reports the following errors:

------------------------------

Jul 19 01:16:02 iPhone-6 MyApp[380] <Warning>: Error reading archived restorable state: Error Domain=NSCocoaErrorDomain Code=257 "The operation couldn’t be completed. (Cocoa error 257.)" UserInfo=0x170662480 {NSFilePath=/var/mobile/Containers/Data/Application/EA07FC55-81DA-47B9-904E-3A15518A1E24/Library/Saved Application State/com.gunpmedia.MyApp.savedState/data.data, NSUnderlyingError=0x170251fd0 "The operation couldn’t be completed. Operation not permitted"}

Jul 19 01:16:02 iPhone-6 securityd[90] <Error>: securityd_xpc_dictionary_handler MyApp[380] copy_matching The operation couldn’t be completed. (OSStatus error -25308 - ks_crypt: e00002e2 failed to unwrap item (class 6, bag: 0) Access to item attempted while keychain is locked.)

Jul 19 01:16:02 iPhone-6 MyApp[380] <Error>: SecOSStatusWith error:[-25308] The operation couldn’t be completed. (OSStatus error -25308 - Remote error : The operation couldn‚Äôt be completed. (OSStatus error -25308 - ks_crypt: e00002e2 failed to unwrap item (class 6, bag: 0) Access to item attempted while keychain is locked.))

Jul 19 01:16:02 iPhone-6 securityd[90] <Error>: securityd_xpc_dictionary_handler MyApp[380] add The operation couldn’t be completed. (OSStatus error -25308 - ks_crypt: e00002e2 failed to wrap item (class 6, bag: 0) Access to item attempted while keychain is locked.)

Jul 19 01:16:02 iPhone-6 MyApp[380] <Error>: SecOSStatusWith error:[-25308] The operation couldn’t be completed. (OSStatus error -25308 - Remote error : The operation couldn‚Äôt be completed. (OSStatus error -25308 - ks_crypt: e00002e2 failed to wrap item (class 6, bag: 0) Access to item attempted while keychain is locked.))

------------------------------

It looks like some of the state restoration data is saved in the keychain, but I can see no mention of this in the documentation.

I have an app called "Shoot" that take pictures and share them on social network using OAuth2. Access and refresh token issued after the Oauht2 dance are stored in the Keychain with the ACL "kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly" (new to iOS8).

When I build my "Shoot" app from Xcode6.3 and run on iOS keychain used to work fine. Now I've migrated it to Xcode7/Swift2 and when deployed either to iOS8 or iOS9 I keep hitting the -34018 Keychain error.

See source code with Swift1.2: https://github.com/aerogear/aerogear-ios-cookbook/tree/master/Shoot

with Swift2: https://github.com/corinnekrych/aerogear-ios-cookbook-1/tree/swift-2.0

I'm puzzled, any hints welcome.

++

Corinne

One thing i notice is that Xcode6.3 version uses 7Mb mem whereas Xcode7 running the same app uses 10.5Mb.

++

Corinne

Now I've migrated it to Xcode7/Swift2 and when deployed either to iOS8 or iOS9 I keep hitting the -34018 Keychain error.

You hit it every time, or occasionally? If it's every time then there's almost certainly something wrong with your code signing. If it works the vast bulk of the time but fails under specific circumstances, that's the bug that discussing on this thread.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Indeed, fixing code signing for the project make the issue behaves differently. When launched the first time with a cleared keychain on the iPhone 5s device, I'm able to access the keychain a couple of time but then hit the issue.

I've upgraded to Xcode7 beta4.

I wonder what will be an acceptable work around.

++

corinne

So the two things that fixed it for me were to 1, turn on the Keychain Sharing entitlement (why, I don't understand since I'm not sharing the Keychain with any other apps) to fix my issue at App launch, and 2, doing a dispatch_async(dispatch_get_main_queue()) from my UIApplicationWillEnterForegroundNotification handler for dealing with bringing the App forward.

Now everything appears to be happy.

Andrew

Hello,

I am also struggling with a occasional -38014 error code when accessing keychain data with the following code.

I can reproduce the issue almost every time the app runs, the keychain data is read corrctly, then all of a sudden, it throws the error.

I tried to add keychain sharing to the configuration and this did not work. This is primarially an issue when we are running in debug mode(with the device connected to the debugger) in developing new features for our app.

Any help in mitigating the issue would be appreciated.

NSMutableDictionary *queryDictionary = [[NSMutableDictionary alloc] init];
    [queryDictionary setObject:[key dataUsingEncoding:NSUTF8StringEncoding] forKey:(__bridge id)kSecAttrGeneric];
    [queryDictionary setObject:(__bridge id) kCFBooleanTrue forKey:(__bridge id)kSecReturnAttributes];
    [queryDictionary setObject:(__bridge id) kSecMatchLimitOne forKey:(__bridge id)kSecMatchLimit];
    [queryDictionary setObject:(__bridge id) kCFBooleanTrue forKey:(__bridge id)kSecReturnData];
    [queryDictionary setObject:(__bridge id) kSecClassGenericPassword forKey:(__bridge id)kSecClass];

    NSDictionary *returnedDictionary = NULL;/
    CFDictionaryRef cfquery = (__bridge_retained CFDictionaryRef)queryDictionary;
     CFDictionaryRef cfresult = NULL;
     OSStatus keychainError = SecItemCopyMatching(cfquery, (CFTypeRef *)&cfresult);
     CFRelease(cfquery);
    if (keychainError == errSecSuccess)
    {
        returnedDictionary = (__bridge_transfer NSDictionary *)cfresult;
        NSData *rawData = [returnedDictionary objectForKey:(__bridge id)kSecValueData];
        NSString* value = [[NSString alloc] initWithBytes:[rawData bytes] length:[rawData length] encoding:NSUTF8StringEncoding];
        AMZLogDebug(@"Get Value for KeyChain key:[%@],%@", key,value);
    
        return value;
    }
    else
    {
        AMZLogDebug(@"Get Value for KeyChain key:[%@],%@", key,@"nil");
        return nil;
    }

I ran into this problem running Xcode 7 beta 5, and iOS 9.0 Beta 6 running in Debug mode started from Xcode. I am requiring User Presence for accessing an important value in my keychain, and if I start the app with passcode set, everything works fine. This error pops up when putting the app in the background, removing the passcode, and bringing the app back to foreground. When trying to access this value, I start receiving -34018 rather than the proper Keychain error values I am looking for. However, if I start this app with no passcode being set at app launch, then all error codes are given appropriately, and I have no issues.

This does not happen with iOS 8.X running the same code.

Is this being caused because it is a Beta build? or will this possibly happen with App Store builds for iOS 9 as well?

Quinn, I have a detail that I don't see elsewhere in this thread.

When starting or resuming my app normally, I never have any problems accessing the keychain immediately when UIApplicationDidBecomeActiveNotification gets fired. However, I'm in the process of adding support for iOS 9 Universal Links, and ONLY when resuming the app as a result of tapping a web link I get the -34018 keychain error 100% of the time. In that case, and only in that case, when the UIApplicationDidBecomeActiveNotification notification gets fired, attempts to access the keychain fail. This may mean that I cannot ship with the Universal Links feature until it is fixed.

Keychain Access Fails Consistently When Resuming App From a Universal Link

rdar://22583555

I also tried removing all apps from the multitasking view until it was just my app and Dropbox.app (where I keep a file for testing Universal Links), trying to rule out memory pressure, and I still got the keychain error.

Thanks so much for your patience and help on this matter.

Here are some more potentially helpful details I've discovered:

1. This issue only happens when the debugger is attached. Run the app from the device alone without Xcode, and it all works as expected. Should have tried this sooner. :/

2. Everything works as expected on my iPad mini 1. Problem exists only on my iPhone 6 Plus. Strange.

3. The problem happens also when tapping a spotlight result that opens my app.

Just to add some more color:

I'm storing oauth2 creds in the keychain. From a fresh start, the following work:

* Accessing an existing credential

* Deleting a credential and storing a new one.

Where I run into problems is in resuming app after being previously logged in, stepping out to settings, and returning. One feature of the internal build is that the identifier for the service to be used is stored in NSUserDefaults, so the user can go to iOS Settings and toggle their service endpoint. When the app resumes after this happends, I check to see if the service changed, and if it did, I force a logout and ask the user to sign in again.

It is at this point I run into problems. After having previously been able to read/write the keychain, I get a -34018 for every keychain access. While the deletes happen almost immediately after the app resumes, the adds typically happen quite a while afterwards, since the user has to enter a name and password.

I'm using accessibility specifier kSecAttrAccessibleAfterFirstUnlock. I have app groups enabled, and an entitlements file in place. Codesign output is as expected.

This is happening on iOS9b5 / 13A4325c on an iPhone6+. It does not happen on my iPhone5 running iOS 8.4./12H143.

I would like to confirm that for me as well:

1. the issue only happens with debugger attached on iPhone (for me it's iPhone 5S)

2. Everything works on iPad mini with or without debugger

@gc That's great news.

As others have reported, this mysterious keychain error is most easily observable when launching via Xcode with the debugger attached. Once the error starts occurring, the keychain doesn't seem to right itself regardless of memory pressure until one reboots the device.

I just wanted to add that I've received reports from end users that indicate to me that this error can also occur in a production App Store environment, not just when connected to the debugger. For example, I get sparse reports of things like a player's coin balance no longer updating in one of my games (their coin balance in this case is stored in a keychain item to make it harder to tamper with - as opposed to using NSUserDefaults). I've carefully checked my code and the only way I can figure that players aren't being credited coins sometimes is that the keychain becomes inaccessible and is returning this error. I've observed the same behavior when attached to the debugger when this error occurs. The incidence of this error in production seems to be <1%, but it's obviously a serious problem for affected users.

Until this is fixed it looks like I'll have to migrate my code away from using the keychain for storing small bits of critical information. 😟 End users who have this problem have little recourse except to reboot their device, which seems to fix the problem. Any update for us?

In the middle time at Apple resolves this bug, what is your recomendation for save critical data?

What is your recomendation developers? In my case, i am affected by this issue only when debug on iOS 9 device and receive system memory warnings .

I can test many other options, wrappers, codes and more for save data and after read without problems, but finally I verify that this is the same issue with SecItemCopyMatching.

So, what other options can use to save critical data or save in other way?

When is possible to fix this issue Apple?

This is nuts. I'm really coming to the conclusion that we can simply ignore OSStatuses (a little bit exagerating, but at least I meant that really for -34018). All goes fine, pretty much like a Success. False positive. Very disturbing.