How to write entries to the system keychain in macos 12+

Question

vamsig7 OP

Created Apr ’22

Replies 7

Boosts 1

Views 1.8k

Participants 5

We have an application that requires writing to the system keychain and we used SecKeychainOpen like this

var keychain: SecKeychain?
let path = "/Library/Keychains/System.keychain"
SecKeychainOpen(path, &keychain)

then in the query

baseQuery[kSecUseKeychain as String] = keychain

This approach solved my requirements, as we are able to read and write from the system keychain.

From macOS 12+ SecKeychainOpen API is getting deprecated. Is there any way to achieve the same now?

kSecUseKeychain is still allowed so, I need. a way to get the reference of system keychain am I wrong?

Minimum deployment version: 10.15+ Runs in root context , non sandboxed app

Thank you

Answered by DTS Engineer in 710160022

The System keychain should be in your search list by default. There’s no need to open it. Moreover, hard coding its path is less than ideal.

You can get a reference to the System keychain without such limitations with this code:

func systemKeychain() -> SecKeychain? {
    var searchListQ: CFArray? = nil
    let err = SecKeychainCopyDomainSearchList(.system, &searchListQ)
    guard err == errSecSuccess else {
        return nil
    }
    let searchList = searchListQ! as! [SecKeychain]
    return searchList.first
}

Still, there’s a bigger issue in play here. This isn't simply a case of SecKeychainOpen being deprecated. Rather, the deprecation of that API is the first step along a path to deprecate the whole concept of the file-based keychain. The data protection keychain is the way forward here. See On Mac Keychains for more background to this.

We have not fully deprecated the the file-based keychain yet because there are still places where it’s your only option. You wrote:

Runs in root context , non sandboxed app

That is one place where you have to continue using the file-base keychain. Right now the data protection keychain is not available to launchd daemons and similar code.

We hope to resolve that issue in the future. If and when that happens, you may end up needing to revisit this code. However, we haven’t announce any concrete plans for this.

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

Boost

Answer 1

Systems Engineer OP

Apple

Apr ’22

From macOS 12+ SecKeychainOpen API is getting deprecated. Is there any way to achieve the same now?

Right, the idea here is that an MDM configuration or a user would be interacting with the System Keychain and not a custom API. If your application needs to write an identity to the System Keychain then use an MDM configuration profile to do this and not a custom API.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

DTS Engineer OP

Apple

Apr ’22

back soon

0

Answer 3

DTS Engineer OP

Apple

Apr ’22

Accepted Answer

The System keychain should be in your search list by default. There’s no need to open it. Moreover, hard coding its path is less than ideal.

You can get a reference to the System keychain without such limitations with this code:

func systemKeychain() -> SecKeychain? {
    var searchListQ: CFArray? = nil
    let err = SecKeychainCopyDomainSearchList(.system, &searchListQ)
    guard err == errSecSuccess else {
        return nil
    }
    let searchList = searchListQ! as! [SecKeychain]
    return searchList.first
}

Still, there’s a bigger issue in play here. This isn't simply a case of SecKeychainOpen being deprecated. Rather, the deprecation of that API is the first step along a path to deprecate the whole concept of the file-based keychain. The data protection keychain is the way forward here. See On Mac Keychains for more background to this.

We have not fully deprecated the the file-based keychain yet because there are still places where it’s your only option. You wrote:

Runs in root context , non sandboxed app

That is one place where you have to continue using the file-base keychain. Right now the data protection keychain is not available to launchd daemons and similar code.

We hope to resolve that issue in the future. If and when that happens, you may end up needing to revisit this code. However, we haven’t announce any concrete plans for this.

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

0

Answer 4

DTS Engineer OP

Apple

Apr ’22

Are there any major differences rather than the fact just the first one has more control, as there is no need to change the preferred domain in total

Well, those a pretty big differences. I prefer kSecUseKeychain because a) it’s explicit, and b) it doesn’t change process-wide state. That does not, however, make it any more futureproof.

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

0

Answer 5

ramdittakavi OP

Jul ’23

@eskimo Looks like SecKeychainCopyDomainSearchList is deprecated as well.

What's the recommended approach to get a reference of system keychain?

My scenario is similar, I'm using SecPKCS12Import to import an identity into system keychain. It allows me access to System keychain only when I get a reference of it using SecKeychainRef as shown in the below code:

SecKeychainOpen is deprecated and also SecKeychainCopyDomainSearchList. How can I go about getting the reference now?

0

Answer 6

DTS Engineer OP

Apple

Jul ’23

What's the recommended approach to get a reference of system keychain?

I’m going to stand by the code snippet I posted above.

SecKeychainOpen is deprecated

You shouldn’t need that.

and also SecKeychainCopyDomainSearchList.

Yep.

How can I go about getting the reference now?

Using SecKeychainCopyDomainSearchList.

The issue here isn’t that this specific API is deprecated, but rather than the entire concept of the file-based keychain is on the road to deprecation. The deprecation of routines like SecKeychainCopyDomainSearchList is just the first step on that path.

We recommend that folks switch to the data protection keychain. Most app developers can do that just fine. However, there are cases where that’s not possible, for example, if you’re building a daemon. If you’re building a daemon you should continue using the file-based keychain until Apple has a data protection keychain solution that works for you. And that means that you’ll need to use this deprecated API.

You can find more backstory on this topic in TN3137 On Mac keychain APIs and implementations.

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

1

Answer 7

sky-lark OP

Aug ’24

We hope to resolve that issue in the future. If and when that happens, you may end up needing to revisit this code. However, we haven’t announce any concrete plans for this.

After almost 2 years and half, do you have any timing set for it? Do you have any rough idea when the deprecated API will be definitely removed?

0