Secitemadd and Secitemcopymatching Returns Error Code -34018 (Errsecmissingentitlement)

SecItemAdd always returns error -34018 in Xcode 8 in iOS 10 simulator

I was able to work around this in my app by adding Keychain Access Groups to the Entitlements file. I turned on the Keychain Sharing switch in the Capabilities section in your test app, and it is working for me as well.

Item to add to entitlements:

keychain-access-groups

    $(AppIdentifierPrefix)com.evgenii.KeychainBugDemo

I have only tried this on macOS Sierra (10.12), so I'm not sure if it will work for you on 10.11.5.

SecItem methods fail with -34018

-34018 is errSecMissingEntitlement according to osstatus.com

Internal error when a required entitlement isn't present.

For iOS 10+ you need a .entitlements file to access the keychain. Something like this:

    com.apple.keystore.access-keychain-keys
    
    com.apple.keystore.device
    

Testing the Keychain - OSStatus error -34018

To answer your question: Yes, I experience the same problem. It seems to work fine when running my app. But when I run my XCTests on my device it seems that the keychain returns error -34018.
The strange thing is that it doesn't happen when I run the tests on the simulator.

EDIT: I found a solution which I have explained in this answer

OSStatus error:[-34018] Internal error when a required entitlement isn't present error on device

I had the same issue. And the solution was very easy. Check once again accessGroup parameter in Keychain initializer.
For example, you add the Keychain Group in Capabilities with the name "com.myCompany.app". But it is not the full name of accessGroup. To solve the issue just prepend "App ID prefix" to the keychain group name. You can find this prefix in your apple developer account inside your App ID configuration. The full accessGroup name will be "XXXXXXXXXX.com.myCompany.app", where XXXXXXXXXX is your App ID prefix.

OSStatus error code -34018

I've been just researching the same error.

The gist of it is that the security service apple uses in order to communicate with the key chain, in rare cases, when the user's device is low on memory, crashes and taking away the app ability to talk to the keychain which results the dreadful -34018.

This is not happening only while running through Xcode like some may claim.

This is the most recent data regarding the issue taken from the Apple developer forums by one of the Apple staff:

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.

From Another Apple staff member:

• 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).

From Another Apple staff member on Mar 22, 2016:

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

Unfortunately there are no known workarounds and the issue is still not fixed in 9.3.2 Beta 1 (13F51a)

---

Related Topics