New keychain for Mac App

We have a developer-id application which includes a LaunchAgent, couple of LaunchDaemon and a system extension. We want to store our secure data in keychain that can read by any of our processes or at least by LaunchDaemons. We would also prefer for our data to not be visible to users, not be accessible to other processes and we did not want to use system keychain because of our prior experience where one of our app data on update corrupted the system keychain for one customer.

Therefore, we have decided to create our own keychain file and store our data there. However, we noticed that SecKeychainCreate and related file based keychain APIs are deprecated. This led me to below threads:

https://developer.apple.com/forums/thread/685546

https://developer.apple.com/forums/thread/712875

https://developer.apple.com/forums/thread/696431

And now I am confused. It is suggested that we should use data protection based keychain because file based keychains are on path to deprecation. However, it is also noted that data protection keychains do not work with LaunchDaemons. So which keychain is the right choice for our requirements? Also,

One tricky aspect of this is that the SecItem API supports both keychain implementations

I do not see any option to use file based keychain using SecItem API. How can I create a new keychain file at a given path and add data in it using SecItem APIs? Can someone please elaborate on this with example?

Answered by DTS Engineer in 805330022
So which keychain is the right choice for our requirements?

TN3137 On Mac keychain APIs and implementations is pretty clear about this:

Programs that run outside of a user context, like a launchd daemon, must target the file-based keychain.

So, while everyone’s life would be better if you could use the data protection keychain, you can’t, and that’s really the end of the story.

I do not see any option to use file based keychain using SecItem API.

You target the file-based keychain by not specifying kSecUseDataProtectionKeychain (or the older kSecAttrSynchronizable).

To target a specific keychain:

  • Use kSecUseKeychain for an add dictionary.

  • And kSecMatchSearchList for query dictionaries.

Also, make sure you read SecItem: Fundamentals and SecItem: Pitfalls and Best Practices. It’s easy to get lost in the weeds with the SecItem API, especially when targeting the file-based keychain.

How can I create a new keychain file at a given path … ?

You’ll have to use the deprecated API to actually create and open the keychain file.

These are deprecated but still work as well as they ever did. There is no direct replacement because the eventual goal is to allow daemons to use the data protection keychain. Once that happens, you’ll have a path forward.

Share and Enjoy

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

Accepted Answer
So which keychain is the right choice for our requirements?

TN3137 On Mac keychain APIs and implementations is pretty clear about this:

Programs that run outside of a user context, like a launchd daemon, must target the file-based keychain.

So, while everyone’s life would be better if you could use the data protection keychain, you can’t, and that’s really the end of the story.

I do not see any option to use file based keychain using SecItem API.

You target the file-based keychain by not specifying kSecUseDataProtectionKeychain (or the older kSecAttrSynchronizable).

To target a specific keychain:

  • Use kSecUseKeychain for an add dictionary.

  • And kSecMatchSearchList for query dictionaries.

Also, make sure you read SecItem: Fundamentals and SecItem: Pitfalls and Best Practices. It’s easy to get lost in the weeds with the SecItem API, especially when targeting the file-based keychain.

How can I create a new keychain file at a given path … ?

You’ll have to use the deprecated API to actually create and open the keychain file.

These are deprecated but still work as well as they ever did. There is no direct replacement because the eventual goal is to allow daemons to use the data protection keychain. Once that happens, you’ll have a path forward.

Share and Enjoy

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

New keychain for Mac App
 
 
Q