Keychain error -34018 (errSecMissingEntitlement)

This thread has been locked by a moderator.

This is a continuation of from the old forums: https://devforums.apple.com/thread/246122


Calling SecItemCopyMatching will sometimes return an OSStatus of -34018 (errSecMissingEntitlement). This seems to happen when the system is running low on memory. This has not been fixed in iOS9. I've of course filed radars about this and I would encourage others to do the same while iOS 9 is under development.

Up vote post of briandw
99k views

Replies

Same here on SecItemDelete on an iOS 10 simulator using Xcode 8 Beta 6.

Same. 😢

"Adding the "Share keychain entitlement" fixes this issue." from


https://forums.developer.apple.com/message/170381#170381


fixes it, why does this work? why would the device need this and not the simulator?

Still appears to be an issue in Xcode 8 GM.


While Adding the "Share keychain entitlement" may provide a workaround for this it is not a fix.

I'm having the same issue in Xcode 8 GM

Same here. Is this going to be fixed? The Share Keychain entitlement does fix it, but why is this required now? We rather not touch anything that has to do with Keychain settings because it is so crucial and we are not sure what the exact implications are.

Any news for this?


It seems that with iOS 10 this problems always occurs. I just could reproduce the problem when opening the sample app for this project: https://github.com/kishikawakatsumi/KeychainAccess (using the master) and running it in the simulator (iPhone 7 / iPad with iOS 10).

Make sure you enable keychain sharing in the capabilities screen.


https://github.com/soffes/SAMKeychain/issues/149


We're seeing the same issue accessing the keychain in the simulator. Works fine on device.


Unfortunately the Share Keychain work around did not fix it on the simulator for us. Even if it did work, I wouldn't feel comfortable enabling that entitlement when it's not needed on device.

Folks, if you’re experiencing -34018 errors in the simulator, this is not the right thread for you. It turns out that a -34018 error in the simulator is related to changes in how the simulator deals with entitlements. You can hop over to this thread for the details.

OTOH, if you’re still experiencing intermittent -34018 errors from user devices in the field, all the advice I’ve posted earlier on this thread still applies.

Share and Enjoy

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

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

Hi,

I've seen this bug come and go (last week I could regenerate it all day, and today - nothing...)


While observing the notifications UIApplicationProtectedDataWillBecomeUnavailable and UIApplicationProtectedDataDidBecomeAvailable the behavior seems to me somewhat peculiar and that might, maybe, hmmm... give some clue.


When the application is in the foreground and the device becomes locked (can be via the lock key or just enough time passes), then UIApplicationProtectedDataWillBecomeUnavailable is NOT called. additionally, the keychain is not locked at this stage.


I'm testing if the keychain is unlocked by adding a key with UnlockedThisDeviceOnly access


So now we have the app in the background, it goes there thinking that the keychain is unlocked, and since it does not get the notification it thinks the device is unlocked too.


When the app come back, then first we get the UIApplicationProtectedDataDidBecomeAvailable notification (twice) and the keychain is unlocked, then applicationWillEnterForeground and applicationDidBecomeAvailable.


1st question - why isn't the WillBecomeUnavailable event called at the time of occurance?

2nd question - why isn't there an event DID become unavailable - is the app unavailable when it's locked?

3rdd question - when does the keychain actually get locked? there's a time difference between willBecomeUnavailable and the actual keychain lock


NOW, in my app there's a timer to test that when X time passes the user gets a session timeout.

So when the app comes back from background the timer is called and sends an internal "logout" notification.

When this notification is sent, the app perfoms logout and reloads the data from the keychain.


And this is the crux.


My assumptions is that since notifications are asynchroneous, if the logout notification is received BEFORE the DidBecomeAvailable notification, then I will not read the data.

Moreover, if for example the app is awaken by a post notification, then the same thing can occur.


And in a widget the notifications are definitely not working properly, or rather - the widgets are available when the device is locked so there should certainly be a didBecomeLocked event in this case or a synchroneous query


Conclusion:

I think that in addition to the lock state notification, there should be a synchroneous lock state query, and the keychain should work with both this synchroneous query and the notification to make sure to fix mismatch.

Adding an item to the keychain to see if it's locked is a bit ugly... 🙂

I don’t see any mention of error -34018 in your problem description. As such, I recommend that you start a new thread for this. This thread is already long enough.

Share and Enjoy

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

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

I assumed it was obvious 🙂

I get error -34018 when setting the UnlockedThisDevice property and that was my assumption for this case

And keychain sharing is also applied to this key

I am also strugling with this, when trying to write to the KeyChain, Simulator iPhone 6, IOS 10, Xcode 8, when unit testing..


I have tried signing the Test Tarrget
codesign -d --verify --force -i AXXXXXXXXXXXXXXXXXXXXXXXXXXXX43C --entitlements $SRCROOT/TheSDKTests/SDKtest.entitlements --sign AXXXXXXXXXXXXXXXXXXXXXXXXXXXX43C "$CODESIGNING_FOLDER_PATH"


But still I get the error : -34018

I’ve taken the extraordinary measure of locking this thread. This is for two reasons:

  • The original purpose of this thread was to discuss intermittent -34018 errors that only crop up on user devices in the field. However, error -34018 can show up in other contexts, and it’s better to keep those issues separate.

  • This thread is now super long (this final post created the eighth page!) and that makes it hard to follow.

If you encounter error -34018, please read the Error -34018 errSecMissingEntitlement pinned post for advice on how to proceed.

Share and Enjoy

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

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