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?

Sadly the exception text is not included so I cannot confirm it is error -34018.

Bummer. Can you rev your app so that the error code gets included in the log?

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?

Yeah. AFAIK 10.0.2 did not include any fixes specific to this issue. However, it’s not necessarily relevant without knowing what error you got.

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

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

Sure, but how do I get the error code in the crashlogs? I cannot seem to set an custom exception code for example.

how do I get the error code in the crashlogs?

There is no supported way to put custom app state into a crash log. However, I don’t see how that matters here. This error is reported to you as an

OSStatus

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

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

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.

This doesn’t sound like an exact match for the intermittent problem that’s the subject of this thread, but it is an interesting failure nevertheless.

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.

To be clear, the SecItem APIs always do an IPC to the security daemon, which always results in a database query against the true keychain database. So there’s no caching there.

There is, however, caching at other levels. The caches that most commonly trip folks up are:

• the TLS session cache, described in QA1727

• HTTP 1.1 (and now 2) persistent connections

• Foundation network per-session (that is, non-persistent) credential caching

One or more of these could be in play here; it’s hard to say without knowing more about how your credentials are tied to your networking.

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

To my mind the iOS 8.4 case is uninteresting; during the iOS 9 cycle we definitely fixed bugs that cause the -34018 error when using Xcode.

OTOH, the iOS 10 case is interesting. If you can distill down a reasonable test project that shows this, we would definitely appreciate a bug report for that (if you do create a bug, please post your bug number, just for the record).

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

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

That's quite strange because when I delete the key or set a new value for that key, it changes its value (or it deletes it value) until I reopen the app. At that time, in the first line of didFinishLaunchingWithOptions in the AppDelegate I print the value for that key and it's again the old value.

We are not using anything complex: we store the api token received from the login in the keychain and we use this api token for each request. The api token it's a string (see JSON Web Token)

I'll try to investigate more the problem on iOS 10.

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(?)

I was using Xcode 7.3 to run a debug build on iOS 8.3 …

As I mentioned to luca34, the iOS 8 case is uninteresting because we definitely fixed bugs related to this during the iOS 9 cycle.

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

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

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);

The problem, as you’ve described it, is unlikely to be related to your code. My recommendation here is that you file a bug, including a sysdiagnose log taken shortly after you reproduced the problem.

Note For more info on sysdiagnose logs, see our Bug Reporting > Profiles and Logs page.

Please post your bug number, just for the record.

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

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

Thank you for this response.

We have previously filed a report on this -- nr. 35622508 and we were informed that it is a duplicate of 33714117. Unfortunately that is the only information we have -- no insight on why this is happening or what's a suitable workaround.

Are you able to shed more light on this?

Hi,

it looks like to me that this problem still exists. I am experiencing same issues occasionally, and I am getting out of ideas how to resolve.
App is using keychan for storing access and refresh token, and keychain returns this kind of error on random, as I can see. On some devices works without any issues, and on some fails, from time to time, can't figure out any pattern. Using latest xcode, and it doesn't depends on iOS version. If something is wrong with keychain group, entitlements, or code I assueme that it will fail more often, since implementation is straightforward. App is presenting welcome screen, and waits for tokens to be refreshed, or it is refreshed at runtime if server request fails, and we can remove memory pressure as potentialy reason (I read somewhere that can cause this). Error is retuned no meeter if we try to retreive or store value.

Any advice would be appreciated.

Edit:
I tried to force memoryWarning, simulate memory preassure with allocating memory and data is retreived properly. Since I am logging errors into file, I just received log file from client device with message:
`Keychain loading error for key refreshToken. Keychain error status: -34018 App is using 34.21953582763672MB MB. Device memory status is: Used memory: 2350.40625 MB; free memory: 184.625 MB.`

I'm encountering -34018 error iOS 15.5

The first time my app is started after installation, the console log frequently shows this error. The first boot after restarting my iphone gives the same error. This error log appears dozens of times per startup. I suspect this bug is slowing down the startup.

P.S: I also don't know why amfi is ”Trust evaluate failure“, please let me know if you know. thanks

Here are some log segments：

16:16:01.911576+0800 imagent devicesChanged on connection account all devices num delegates: 1

16:16:01.911613+0800 mobileassetd handleCopyAssetAttributes: [languageassetd] unable to get asset attributes[com.apple.MobileAsset.DictionaryServices.dictionary2]: 1 [com_apple_MobileAsset_DictionaryServices_dictionary2/add6f6f4efb1726c78a6f4a71cded90212b901d9.zip]

6:16:01.911652+0800 imagent devicesChanged on connection account all devices num delegates: 1

16:16:01.911818+0800 securityd trustd[99]/1#12 LF=0 copy_parent_certificates Error Domain=NSOSStatusErrorDomain Code=-34018 "Client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={numberOfErrorsDeep=0, NSDescription=Client has neither application-identifier nor keychain-access-groups entitlements}

16:16:01.912004+0800 securityd trustd[99]/1#12 LF=0 copy_parent_certificates Error Domain=NSOSStatusErrorDomain Code=-34018 "Client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={numberOfErrorsDeep=0, NSDescription=Client has neither application-identifier nor keychain-access-groups entitlements}

16:16:01.912039+0800 identityservicesd Device query completed with Account ID: service: com.apple.private.alloy.multiplex1

16:16:01.912070+0800 identityservicesd - write account defaults: (has changes: YES)

16:16:01.912240+0800 trustd cert[0]: IssuerCommonName =(path)[]> 0

16:16:01.912439+0800 amfid Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName]

The first time my app is started after installation, the console log frequently shows this error.

It sounds like you can reliable reproduce this issue, which makes it’s off-topic for this thread. Quoting my initial post:

This thread is the place to post if … the problem is intermittent, that is, it shows up very occasionally on user devices in the field but is otherwise hard to reproduce

Please start a new thread with the details.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"