Keychain error -34018 (errSecMissingEntitlement)

Any news regarding this one?

You uploaded this thread in Jul 2015, we are now in Feb 2016. You claimed "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."

So, thousands of engineers and... nothing???

I've managed to recreate this bug in a slight different way. I can access the keychain as many times as I want in a short space of time, however as soon as I launch the camera through an image picker view controller, then I immediately start getting the -34018 on all future reads and writes.

Just to add a little bit to this thread.

iOS 9.2.1 has this issue

Reproducibility

- I can reproduce it more often with a debugger attached (currently with about 25% probability). However, sometimes I see it even without a debugger (much, much rarer).

- Usually failures are clustered. Sometimes I am getting this problem several times in the row and after I don't see it for a while.

- I have about ~200MB of free memory when I reproduce this issue. So, it could be one of the variables, but it's not only thing which casues it. One of the thread mentioned that securityd got killed because of memory pressure. I don't think it's simple like that (there were other people who mentioned like me that they saw the problem without memory pressure).

- I don't think that signing has any influence on this thing. The same app (with the same signature and the same profiles installed on the device) will sometimes throw this error and sometime work fine.

- I am seeing this problem on main thread. So, I don't think that a problem is running on non main thread (I saw solution recommending to do dispatch to run on the main thread)

- I don't think that multiple or frequent access to Keychain has anything to do with it. I did a test and run a loop with 1000 access in it and it went well (if the problem was # or frequence it would fail). However, I see this error most of the time literally on the first attempt to work with a keychain.

- People were reporting that it happens only when an app switches from a background or go through a deeplinking. In my cases, it happens with a just common usage (an app being started by a debugger).

Thoughts

I hope that Apple engineers will figure it out. It's kind of strange to not being able to rely on Keychain.

Just a shot in the dark. Frankly, taking into account all of these factors which kind of influence, but aren't exact immediate cause, my guess would be that it's either tricky race condition or a memory corruption somewhere in keychain related process.

I think the only temporary workaround is to not use Keychain (with all security implications of this decision).

Our app was just launched and this is our top crash. By a very very large margin.

I can easily reproduce as well.

in my applicationDidBecomeActive I call SecItemCopyMatching. I open bunch of apps like Safari and open tabs loading various pages, then I resume my app. After a few attempts like this I get the -34018 error.

I work on a security app, so it's pretty important that the Keychain works properly. Please fix this Apple.

Was just able to reproduce and caught the console logs. When the error hits, I see this same entries over and over again in the console log:

Mar 9 13:06:41 Jeejah securityd[94] <Error>: secTaskDiagnoseEntitlements MISSING keychain entitlements: raw entitlement values: <CFBasicHash 0x14fe2ebc0 [0x19fc27b68]>{type = mutable dict, count = 0,

entries =>

}

Mar 9 13:06:41 Jeejah securityd[94] <Error>: secTaskDiagnoseEntitlements MISSING keychain entitlements: original ag: (null)

Mar 9 13:06:41 Jeejah securityd[94] <Error>: secTaskDiagnoseEntitlements MISSING keychain entitlements: newly parsed ag: (null)

Mar 9 13:06:41 Jeejah securityd[94] <Error>: __security_simulatecrash Simulating crash, reason: keychain entitlement(s) missing, code=53c00007

Mar 9 13:06:41 Jeejah ReportCrash[372] <Error>: Simultaneous simulate crash requests for pid 94

Mar 9 13:06:41 Jeejah securityd[94] <Error>: securityd_xpc_dictionary_handler KP Prevention[371] copy_matching Error Domain=NSOSStatusErrorDomain Code=-34018 "client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={NSDescription=client has neither application-identifier nor keychain-access-groups entitlements}

I'm posting the full console log to the bug report we filed. And in case you are wondering, yes the app DOES have an application-identifier.

BTW - I can tell from conversations I have with management on this issue that not all are convinced that it is an Apple defect. So, to paraphrase what somebody else has said in this thread, Apple is making our life harder by being so quite on this issue.

Congrats Apple! The original thread for this bug is now more than 1 and a half years old (18 Sept 2014).

😢

Pretty insane that Apple hasn't addressed this yet. Anyone have any advice for storing private/important data (e.g., user token) without keychain?

What we did is use User Defaults while encrypting the desired values in AES256 and build+obfuscate the key in runtime. I know its a massive degradation to the security of the app but we had no other option. It was using this bypass or killing the app and telling the user to clean his memory and open it again.

I suggest opening a bug in the bug reporter and start praying Apple will solve it until 2019 christmas.

I'll hook in to this thread in the hopes that iOS 9.3 release will bring any changes...

Hi eskimo,

Is this issue solved permanently in iOS9.3? (keychain OSStatus -34018)

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
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

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

Quinn,

Thank you for the update. I have one follow-up and one request:

Follow-ups: You mentioned getting a system log on a 9.3 device "that hasn't been talked to by Xcode" - do you mean that once the device has been connected to Xcode, that the system log is not helpful? We have encountered this bug on an app signed with an Enterprise certificate (app installed over the air, not while tethered to XCode) - but the device itself has been connected to XCode for debugging; is the device system log still useful in this case?

Request: I know that Apple's policy is to not comment on defects, and it is for a very good reason; but it is a 'policy' and not a fundamental law and therefore exceptions can be discussed and granted. Due to the longevity of this defect, and the seemingly random nature of which apps or devices it occurs on, makes this a strong candidate. Especially since one app will experience this issue while another won't leaves very smart people to believe that there must be something wrong in the code my code. While I can only speak for myself, I have wasted a great deal of energy writing and testing code that attempts to work around this defect; I suspect others on this forum also have had such an experience. Please, on behalf of those who are wasting their energies on this defect instead of implementing other iOS features or other improvements on their app, request an exception from management and get all known details out in the open. Thank you.

Andrew

… do you mean that once the device has been connected to Xcode, that the system log is not helpful?

When you connect a device to a Mac with Xcode running, it puts the device in ‘developer mode’. My suggestion is that you try to reproduce this on a device where that’s not happened.

Note that restarting the device clears this state, so when I said “talked to by Xcode” I should have said “talked to by Xcode since it was last restarted”.

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

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

EDIT: still happening to us

Quinn this is excellent news!

Thank you for your efforts on keeping us updated. You have been our only beacon of hope in this dark hour for Apple 🙂

Love,

The whole team at Easter Egg!