iOS Keychain writing value results in error code -34018

Question

I have an iOS application that stores some sensitive information in the keychain. While writing values into the keychain, I am getting error code -34018.

I am currently using Apple's iOS KeyChainItemWrapper class.

Both of the following lines of code receive the same error code.

OSStatus res1 = SecItemCopyMatching((__bridge CFDictionaryRef)genericPasswordQuery, (CFTypeRef *)&attributes);
OSStatus res = SecItemUpdate((__bridge CFDictionaryRef)updateItem, (__bridge CFDictionaryRef)tempCheck);

This issue does not occur every time, but intermittently. Once I get this error, I am no longer able to write any values to the keychain.

I have printed the error description like so:

NSError *error = [NSError errorWithDomain:NSOSStatusErrorDomain code:res userInfo:nil];

and this is what the error prints out:

Error: Error Domain=NSOSStatusErrorDomain Code=-34018 "The operation couldn’t be completed. (OSStatus error -34018.)"

Chewink

https://mcmap.net/q/181730/-secitemadd-and-secitemcopymatching-returns-error-code-34018-errsecmissingentitlement – Chalice

Answer 1

Seems like this is a bug in Keychain, which only appears when you launch your app from xcode. See here: https://github.com/soffes/sskeychain/issues/52

We debugged it a lot and it seems an issue accessing the keychain when the app is launched from the background. This is only happening with the debugger (i.e. when launched from Xcode). We think the issue might be related in our case to the debugger keeping alive the app even if it should be killed by the OS. We tried in fact to run the app and then put it in background and launch many other app to occupy RAM. With the debugger the bug came up when resuming the app from the background, while without the debugger it didn't (we did run at least 10 tests each).

Krissy

Interesting. There doesn't seem to be a workaround, at this point. See Apple engineer comments here: forums.developer.apple.com/thread/4743 – Raseta

In the thread @Raseta linked, Apple responded on March 22, 2016 saying they believed this bug was fixed in iOS 9.3. – Wrapped

@Kuba, Zeb's answer may have solved your issue because the issue you were having is different from the issue OP was having. iOS 10 wasn't even around when this question was posted.This question may be more relevant now concerning this error. – Wrapped

Answer 2

If someone will come here back with this error and XCode8 with iOS10, probably you have to enable KeyChain Share in the tab Capabilities:

Crape

I wish i could give you a cookie for finding this. I spent a long time to analyze this. – Meadows

In Italy it's breakfast time, so it would be very appreciated! – Crape

Unfortunately this problem can occur even with keychain sharing turned on. – Gilman

Make sure your configuration actually USES the custom entitlements file. That was our issue. – Clamorous

I thought KeyChain Share only matters if you have multiple app IDs (i. e. A main app and app extension) in your app share group? Am I wrong on this? or did this solve the problem even for someone with just a single App ID? I ask because I'm using Xamarin and the provisioning for capabilities is a nightmare in Visual Studio for mac and I can't seem to enable it in my entitlements. – Adele

Does not work even on XCode 13 and iOS 14 or 15 – Hudak

Answer 3

As others have mentioned, this is a Keychain bug, one that Apple is aware of and has been aware of since at least mid-2015.

As of March 22, 2016, however, Apple has said:

We believe these problems were resolved in iOS 9.3.

iOS 9.3 was released on March 21, 2016.

See the thread: https://forums.developer.apple.com/thread/4743

To quote the response by an Apple employee:

Mar 22, 2016 3:28 AM

OK, here’s the latest. This is a complex problem with multiple possible causes:

• Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible.

• Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure.

  We believe these problems were resolved in iOS 9.3.

• We suspect that there may be yet more causes of this problem.

So, if you see this problem on a user device (one that hasn’t been talked to by Xcode) that’s running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record.

On behalf of Apple I’d like to thank everyone for their efforts in helping to track down this rather horrid issue.

Share and Enjoy

Wrapped

Answer 4

This held me up for 2 hours before I found a quick "fix" - reboot the iOS device

A quote from the discussion at http://forums.developer.apple.com/thread/4743,

From user littledetails

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.

When I rebooted my device the error went away, allowing me to continue testing. Not sure what else to do. In my situation, moving to NSUserDefaults or some other storage solution was not a possibility.

Nowt

In my case when i restart application the error went away, allowing me to continue testing. – Friulian

I was debugging my iOS app with AppCode & Xcode. Rebooting the device did resolve the keychain access problem! – Macfadyn

Answer 5

One way to get around this issue with the keychain is to use dispatch_async to allow the app to launch. This works when the app is opened from the background. Also make sure you have the kSecAttrAccessibleAfterFirstUnlock accessibility setting on the keychain.

 dispatch_async(dispatch_get_main_queue(), ^{
    // save/write to keychain
 })

Ephialtes

Note though, that I can recreate this bug on the main thread. – Raseta

Answer 6

I am using GenericKeychain classes from apple:

https://developer.apple.com/library/content/samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2

struct KeychainConfiguration {

static let serviceName = "MyAppService"



/*

    Specifying an access group to use with `KeychainPasswordItem` instances will create items shared accross both apps.



    For information on App ID prefixes, see:

        https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
    and:
        https://developer.apple.com/library/ios/technotes/tn2311/_index.html
*/

//    static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"



/*

    Not specifying an access group to use with `KeychainPasswordItem` instances

    will create items specific to each app.

*/

static let accessGroup: String? = nil

}

In this file I was specifying my custom accessGroup in this line static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"

After returning to static let accessGroup: String? = nil the problem was gone. :)

Watchcase

Answer 7

Make sure keychain sharing must on under Capabilities in project Target.

In my case the App_Name.entitlements file has different bundle id than of my project bundle id. So, I change bundle id in the App_Name.entitlements file as of my project bundle id. e.g., Suppose your project bundle id is com.Apple.testApp then got to

1. App_Name.entitlements file open key Keychain Access Groups key which is of Array type.
2. Under item0 set value of your project bundle id as eg:- $(AppIdentifierPrefix)com.Apple.testAp.

Pagination

Answer 8

According to @iCaramba's answer. I've found a workaround:

1. Stop the task to kill the app (if you are already running the app)
2. Launch the app on your device manually. DO NOT use Xcode
3. Use Xcode to re-launch the app

Overseer