How is the System Keychain secured in OS X?

Solution 1:

The system keychain is stored in /Library/Keychains/System.keychain and the key to unlock it is stored in /var/db/SystemKey (its default file permissions are readable by root only). The location of these files is referenced in the security-checksystem script (from the security_systemkeychain source). It is even possible to test to automatic locking/unlocking of the system keychain by using

systemkeychain -vt

The keychain security framework allows non-privileged programs to make requests for information provided they are in the ACL stored within the keychain entry. Obviously if a user has root they on a system they can directly access both the file storing the system keychain and the key to unlock it, thus they do not have make requests via the security framework and are not beholden to the ACLs stored within the keychain itself.

(I didn't actually answer the original questions so let's give this another go)

How are the keys architected such that any administrative user can unlock the System Keychain?

The libsecurity keychain framework allows regular processes to interact with the system keychain in an authenticated manner using Apple's XPC interprocess communication framework (IPC).

Program A sends a request to access the system keychain information using IPC. A check is made that the requesting user is already in the wheel group and also knows the password of a user in the wheel group. Once authorization is confirmed, the privileged kcproxy daemon can be used to access material in /var/db/SystemKey, unlock the system keychain and return the requested information.

Are there cryptographic restrictions that limit what an administrative user can do with information in the System Keychain in any way?

No - an administrative user is allowed to access/change anything in the system keychain. Even if they couldn't, they could copy the underlying files to another machine on which they have complete control and just unlock/access it there.

Given an unencrypted system backup without /Users, how would you gain access to the keys in the System Keychain?

If the backup contained copies of /Library/Keychains/System.keychain and /var/db/SystemKey then I would copy them to their respective locations on a new OS X system and use systemkeychain to make the later unlock the former and dump the keychain database using security dump-keychain.

Solution 2:

System Keychain

The System Keychain has some unique capabilities. These are documented by the systemkeychain manual page. The mentions of the master password are likely to be your focus. The system keychain specific source code is small and available.

The System Keychain, /System/Library/Keychains/System.keychain, is a special Keychain for Apple and daemons to use. You should generally avoid using it for user level scripts.

Code Review: Keychain

Apple published the source code for the Keychain and security framework for Mac OS X 10.5; you can review this code to discover how it works.

Alternative Approach: Separate Keychain

You can create a separate Keychain to store your script's credentials. We recommend this practice to our customers. You can use the command line tool security to access, extract, and manage your Keychains without resorting to a graphical interface.

Consider storing the passwords for your automated scripts in a separate Keychain – and exclude this Keychain from your off-site back-up.

I appreciate removing the Keychain from your back-up is not ideal but it would address your concerns. On restoring the Mac, you would need to get the Keychain back from a different source; may be more trusted source or side channel.

You could always store the separate Keychain's password in the System Keychain. You could then unlock the separate Keychain from a script. If the back-up is attacked, you would only expose the password to the separate Keychain and not the Keychain itself as this file is not with the off-site back-up.

Solution 3:

Apple recently published a document outlining its security practices, you may find some answers there. The document is specific to iOS but a lot of the security features have much in common with OS X.