OSStatus error code -34018

Question

I am using SecItemCopyMatching to access iOS keychain. About 1 hundred times I get the result code -34018 right after restarting the application from the background. The documentation states:

The assigned error space for Keychain Services is intermittent: -25,240 to -25,279 and -25,290 to -25,329. Keychain Services can also return noErr (0) or paramErr (-50) or CSSM result Codes

So, it seems that -34018 is the “CSSM result code”. I followed the suggested link but could not find the result codes.

What is this result code -34018 ? How can I get more reliable access to keychain?

 - (NSData *)getKeychainData:(NSString *)key { NSDictionary *query = @{ (__bridge id)kSecClass:(__bridge id)kSecClassGenericPassword, (__bridge id)kSecAttrService:SEC_ATTR_SERVICE, (__bridge id)kSecAttrAccount:key, (__bridge id)kSecReturnData:@YES }; CFDataRef result = nil; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result); if(status == errSecItemNotFound) { return nil; } if(status == noErr) { return CFBridgingRelease(result); } else { [self logError:[NSString stringWithFormat:@"SecItemCopyMatching status %d", (int)status] :nil]; return nil; } } 

Answer 1

I just investigated the same error.

Its essence is that the security service apple is used to communicate with the keychain, in rare cases, when the user device has low memory, the application’s ability to talk to the keychain crashes and disables, the results of which are terrible -34018.

This happens not only when using Xcode, as some might argue.

This is the latest problem data from an Apple developer forum by an Apple employee:

UPDATE: finally, we were able to reproduce the error -34018 on iOS 8.3. This is the first step in identifying the root cause, and then coming up with a fix.

As usual, we cannot fix the release timeframe, but this has affected many developers, and we really want this to be resolved.

Earlier, I suggested adding a little delay to application: didFinishLaunchingWithOptions and applicationDidBecomeActive: before accessing the keychain as a workaround. However, this does not actually help. This means that at this time there is no known workaround other than resuming the application.

The problem seems to be related to memory pressure, so perhaps more aggressive ones in handling memory alerts can alleviate the problem.

From another Apple employee:

• Keychain technology knows well how important this problem is.
• The main problem is reproducing the crash here at Apple.
• Now we can do it (thanks in large part to the work that you guys have filed for and keep track of bug reports).

From another Apple employee on March 22, 2016 :

Ok last. This is a complex problem with several possible causes: some cases of the problem are caused by incorrect subscription to the application. You can easily distinguish this case because the problem is 100% reproducible. Some examples of the problem are caused by a bug in how iOS supports application development (23,991,853). This debugging was complicated by the fact that another error in the OS (t. 23,770,418) masked its effect, which means that the problem only occurred when the device was under memory pressure. We believe that these problems were resolved in iOS 9.3. We suspect that there may be even more causes for this problem. So, if you see this problem on a user device (one which Xcode did not talk to) that is running iOS 9.3 or later, please report an error. Try turning on the device; the system logs your error report (I understand that it can be difficult when working with client devices; one of the options is to ask the client to install Apple Configurator, which allows you to view the system log). And also if you make a mistake, send your error number, just for the record. On behalf of Apple Id, I like to thank everyone for their efforts to find this rather terrible problem. Share and Enjoy

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

Answer 2

After some research, I found this: http://opensource.apple.com/source/Security/Security-55471/sec/Security/SecBasePriv.h

So -34018 is errSecMissingEntitlement , and the comment says

 Internal error when a required entitlement isn't present. 

Has this error occurred while performing unit tests? If so, this may help: stack overflow

This problem on github says that this only happens during debugging with Xcode: https://github.com/soffes/sskeychain/issues/97 (also see <a3> )

Hope some of them help!

Answer 3

This code works for me:

 static const UInt8 kKeychainItemIdentifier[] = "com.apple.dts.KeychainUI\0"; - (NSData *)getKeychainData:(NSString *)key { NSData *keychainItemID = [NSData dataWithBytes:kKeychainItemIdentifier length:strlen((const char *)kKeychainItemIdentifier)]; NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword, (__bridge id)kSecAttrService: SEC_ATTR_SERVICE, (__bridge id)kSecAttrAccount: key, (__bridge id)kSecReturnData: (__bridge id)kCFBooleanTrue, (__bridge id)kSecAttrGeneric: keychainItemID }; CFDataRef result = NULL; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result); if(status == errSecItemNotFound) { return nil; } if(status == noErr) { return CFBridgingRelease(result); } else { [self logError:[NSString stringWithFormat:@"SecItemCopyMatching status %d", (int)status] :nil]; return nil; } } 

The main difference from the OP code is the addition of a general request to the request. The default Keychain object identifier is an apple. The reason for this is to distinguish between different elements of the keychain from each other. This is one way to make access to key files more accessible. Basically, in other words, this ensures that you get access to the default Apple key.

Answer 4

After making many corrections in the stack overflow, everything still doesn't work for me.

Which was related to switching key sharing capabilities in Xcode. Built and up and running right away.