Keychain error -25295 and -25307 when using SecKeyGeneratePair on MacOS

Hello,

In our legacy code, we used to generate private and public key pair using SecKeyGeneratePair API on MacOS login keychain.

We don't enable iOS-style keychain and still rely on login keychain/ACL on MacOS for backward compatibility.

Recently, we encountered error code -25295 (errSecInvalidKeychain) and -25307(errSecNoDefaultKeychain) while doing SecKeyGeneratePair.

I looked up those error codes online, but I was unable to find much information on those two error codes.

Could you please help me to understand possible root causes for each error code and how to address them?

Thank you!

Could you please help me to understand possible root causes for each error code and how to address them?

-25295 can be passed back in some cases when the Keychain is not recognized or invalid and -25307 is returned when the default Keychain is not found. Are you trying to access the Keychain with a complete user session? For example, not through an SSH session or any other user context that is limited?

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Thank you for your reply, Matt!

We are generating private-public RSA key pair programmatically in Objc-C. I don't think we are using an SSH session or other limited user context.

Just to confirm

  1. -25307 is returned when the default Keychain is not found

Doesn't this mean when we try to write keychain objects into login keychain, and if keychain access doesn't have login keychain in the default keychain section? However, are there other scenarios that could lead to this? if the user already has login keychain as the default

  1. -25295

I was not able to gather much information on this error. seems quite rare. is this related to above error? I am familiar with error -50 that happens when you pass in invalid params into the query dictionary, but -25295 seems different. I was talking to Eskimo a while ago, and he mentioned that SecKeyGeneratePair has some known bugs that cause public key to be treated as private keys and such. I wonder if this error code could be something that also happens due to some unknown bugs associated with SecKeyGeneratePair?

If it helps, this is how we currently generate key pairs in the legacy code base on MacOS One weird thing I notice is that kSecAttrAccessible is being set, even thought it is only applicable to MacOS keychains that have iOS-style sharing enabled. I believe kSecAttrAccessible and kSecAttrAccess are mutually exclusive right? Could this also contribute to issues like -25295, -25307?

  //private public key specific 
  [privateKeyAttr setObject:privateTag forKey:(__bridge id)kSecAttrApplicationTag];
  [publicKeyAttr setObject:publicTag forKey:(__bridge id)kSecAttrApplicationTag];
  [privateKeyAttr setObject:[NSNumber numberWithBool:NO] forKey:(__bridge id)kSecAttrIsExtractable];
  [privateKeyAttr setObject:(id)kCFBooleanTrue forKey:(__bridge id)kSecAttrIsSensitive];
  [publicKeyAttr setObject:(id)kCFBooleanFalse forKey:(__bridge id)kSecAttrIsExtractable];
  [publicKeyAttr setObject:(id)kCFBooleanTrue forKey:(__bridge id)kSecAttrIsSensitive];
  
   //actual dictionary that goes into SecKeyGeneratePair
  [keyPairAttr setObject:[NSNumber numberWithBool:YES] forKey:(__bridge id)kSecAttrIsPermanent];
  [keyPairAttr setObject:(__bridge id)kSecAttrKeyTypeRSA forKey:(__bridge id)kSecAttrKeyType];
  [keyPairAttr setObject:[NSNumber numberWithInt:keySize] forKey:(__bridge id)kSecAttrKeySizeInBits];
  [keyPairAttr setObject:label forKey:(__bridge id)kSecAttrLabel];
  [keyPairAttr setObject:privateKeyAttr forKey:(__bridge id)kSecPrivateKeyAttrs];
  [keyPairAttr setObject:publicKeyAttr forKey:(__bridge id)kSecPublicKeyAttrs];
  [keyPairAttr setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id)kSecAttrAccessible];
  [keyPairAttr setObject:(__bridge id) [access reference object for ACL] forKey:(__bridge id)kSecAttrAccess];
   
  // This does both generation and storing of the private and public key refs
  status = SecKeyGeneratePair((__bridge CFDictionaryRef)keyPairAttr, &publicKeyRef, &privateKeyRef);

Hi Matt, could you help to answer my question above?

Thanks, Peter

I don't think we are using an SSH session or other limited user context.

So, are you calling SecKeyGeneratePair from a standard macOS GUI app? If not, what?

How reproducible are these problems? It sounds like you can’t reproduce them internally but are, instead, working from reports coming in from the field. Is that right?

I believe kSecAttrAccessible and kSecAttrAccess are mutually exclusive right?

Yes, but I don’t believe that this is the cause of your problem. IIRC the file-based keychain ignores attributes it doesn’t understand, and that includes kSecAttrAccessible.

Share and Enjoy

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

Keychain error -25295 and -25307 when using SecKeyGeneratePair on MacOS
 
 
Q