Re: Intermittent -34018 errors from users in the field

We raise an exception (/crash) when any unexpected keychain status code is returned. So our crash logs alert us to problems with the keychain. Sadly the exception text is not included so I cannot confirm it is error -34018.

At the moment, we have a couple of crash logs with Keychain problems, including one on iOS 10.0.1. Does that qualify as the latest release or should we only be looking for iOS 10.0.2 and higher?

Hi,

I'm developing an application in Swft 2.3 that uses this library to access the keychain (version 3.0.16). We use a keychain for a group that includes the iOS app, a keyboard extension and an iMessage app

We are experiencing some problems on testing devices where a really old access token is persisted.

So this is the flow:

The user log in successfully -> The user log out -> An old access token (not the latest one) is in the keychain.

What I found out (just through an experimental way, please correct me if I'm wrong) is that the Security framework provides a kind of in-memory cache that has the priority on the stored keychain and where the operation is done even if the stored keychain hasn't been modified. That's why the user can login successfully and can use their own brand new access token.

This problem, by the way, it's occurring only on the access token field, not for the other values stored in the keychain, which they are cleaned as well after the user log out.

So I started to investigate this problem that seems to appers without any logic. It happens on an iPhone 6 Plus iOS 8.4 and on an iPhone 6 iOS 10.0.1 (both connected at least once on Xcode and not rebooted).

While debugging this error on these devices I found out that trying to set a new value or delete the value for the key in keychain results in a -34018 OSStatus, while, in the same moment, setting or deleting any other value works perfectly

Unfortunately I can't give you any other info since I'm still stucked in this problem and we are, sadly saying, moving to a shared user default with encrypted values there.

My app got a -34018 OSStatus calling SecItemCopyMatching when resuming from facebook login process.

I was using Xcode 7.3 to run a debug build on IOS 8.3 Iphone 7, 1, not 100% reproducible but I have seen it happened a few times and our QA have reported a few occurrences before.

Key chain access calls working fine after the app was launched, read and write returns successfully.

Then Facebook login is trigger and the app was pushed to background, after the Facebook login is done and returned to the app, the keychain read failed with -34018 and keep failing all the calls until the app is terminated.

I assume the bug was triggered when

- Resuming the app

- System resources may be low(?)

We're seeing an issue where calls to SecKeyCreateRandomKey for generating a key into the SE hang. Below is how we call it (on an iOS 10 device; the kSecAttrApplicationTag attribute points to some NSData object containing a tag derived from a string.)

This happened to us in the lab once. This is accompanied by log messages about access permissions from keychain -- however note that the call hangs. When we saw this in the lab, we were able to make this call right after application launch, in the application delegate's application:didFinishLaunchingWithOptions: call -- hangs again. Seems like once a device is in that state, it's persistent. The only way we were able to recover was to reboot the device.

We now get reports on this from customers in the field.

Any pointers will be appreciated.

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

CFErrorRef error = NULL;

SecAccessControlRef access = NULL;

access = SecAccessControlCreateWithFlags(kCFAllocatorDefault,

                                                 kSecAttrAccessibleWhenUnlockedThisDeviceOnly,

                                                 kSecAccessControlPrivateKeyUsage,

                                                 &error);   // Ignore error

NSDictionary* attributes =

    @{ (id)kSecAttrKeyType:             kSecAttrKeyTypeECSECPrimeRandom,

       (id)kSecAttrKeySizeInBits:       @256,

       (id)kSecAttrTokenID:             (id)kSecAttrTokenIDSecureEnclave,

       (id)kSecAttrAccessControl:  (__bridge id)access,

       (id)kSecPrivateKeyAttrs:

           @{ (id)kSecAttrIsPermanent:    @YES,

              (id)kSecAttrApplicationTag: ....

              }

       };

        SecKeyCreateRandomKey((__bridge CFDictionaryRef)attributes,

                                              &error);