23

I'm looking for something either like this security white paper for iOS except for OS X or even better, some kind of security audit report from an independent expert. After reading through documentation like the Keychain Services Programming Guide I'm even more confused about what is vulnerable to an adversarial attack on an unencrypted backup of an OS X System.

Last time I checked, the user's login keychain under OS X was about as secure as the password. I recall some issue that shrank the actual secrecy of the key to something like 111 bits (foggy memory, please feel free to correct me) due to some issue with how the password is converted to a key, but that was a long time ago and hopefully that's been fixed.

On the other hand, I've been told the System Keychain is inherently less secure because any administrator can access it and an intruder has many options for becoming an administrator besides guessing a single user's password.

In particular, I'm worried about storing passwords used in automated scripts in the System Keychain as the system files are backed up and stored off-site without further encryption. Documents and other user data are encrypted before being taken off-site, but I have a nagging suspicion that there's a path I'm overlooking that recovers those keys once the System Keychain is compromised (due to our procedures, not necessarily any cryptographic flaws). So I want to have a thorough understanding of how the System Keychain is simultaneously secured yet accessible to any administrator.

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

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

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

I'm interested in OS X 10.5 Leopard and later versions, but specifically limited to desktop or laptop Macs without a T2 chip or secure enclave. Apple's Spring 2020 Platform Security Whitepaper explains pretty well that the critical keys encrypting keychain data are stored on the T2 chip and the T2 chip itself manages and applies ACLs which restrict access to the decryption functionality. So on those computers, as with all iOS devices, the keychain database is tied to the hardware and cannot be used on a different device.

Improve this question
4
  • I don’t have an answer, but an anecdote: as a standard user with no admin privileges, I was once able to extract passwords from the System keychain with relative ease. I don’t remember the exact steps, but it was certainly possible. On a side note, might this be better on security.stackexchange.com? – alexwlchan Jun 16 '12 at 18:30
  • @Alex, I tried Security.SE first, but got no answers there. – Old Pro Jun 16 '12 at 23:16
  • 1
    Why not use a separate keychain altogether for what you're doing? Is there a good reason your script needs access to the system keychain? – Jay Thompson Jun 17 '12 at 4:51
  • @eyemyth, yes, the scripts need to be run by the system so they can access all the files on the disk regardless of user permissions. – Old Pro Jun 18 '12 at 23:16
12

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.

Improve this answer
3
  • 1
    There's a utility called dumpkeychain from GuidanceSoftware/EnCase, that allows a direct dump of a system keychain (with the SystemKey) in Windows (may be easier than setting up a fresh OS X install to dump it). – drfrogsplat Jun 8 '14 at 8:07
  • 1
    @Anon, how can I use the above information to access/unlock/dump a System.keychain from a Time Machine backup of another computer? That is, I have the System.keychain and SystemKey stored on an external disk so I guess I must specify the paths to both files respectively to avoid that it uses the files in the default location. – d-b Jan 16 '15 at 22:42
  • This post is related (how to use SystemKey to decrypt System.keychain from an old system). apple.stackexchange.com/questions/307189/… I am curious if there is a way with Keychain Access or the systemkeychain cli to unlock a recovered System.keychain (ie from an old crashed HDD) with the corresponding SystemKey from that same install. My goal being to unlock and migrate logins into the new System keychain on the new install. – mattpr Nov 1 '18 at 17:50
5

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.

Improve this answer
7
  • Thanks, but it's far too difficult for me to figure out from all that code how the System Keychain is secured and what keeps it secure. We need to use the System Keychain because we need the scripts to be run automatically in the background with root privileges regardless of who is logged in. – Old Pro Jun 18 '12 at 23:20
  • 1
    I recommend asking either on the Apple CDSA mailing list (lists.apple.com/mailman/listinfo/apple-cdsa) or using an Apple Technical Support Incident. Only through these means can you ensure you will reach the appropriate Apple engineers. – Graham Miln Jun 19 '12 at 5:18
  • Having scripts run in the background as root is launchd's job. What exactly are you trying to do? – Jay Thompson Jun 19 '12 at 20:28
  • 1
    Minor typo in "/System/Library/Keychains/System.keychain" (You forgot "Library"). Actually, you can get a list of the keychain locations in Keychain Access by choosing "Edit > Keychain List" – username Jun 20 '12 at 9:14
  • 1
    @OldPro Given your security concerns, why not use full disk encryption? – Graham Miln Jun 22 '12 at 8:42
2
+50

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.

Improve this answer
2
  • This is on the right track, and a good example of the kind of documentation I would find helpful, but iOS doesn't have the concept of the System Keychain so it doesn't answer my question. – Old Pro Jun 20 '12 at 17:13
  • Am happy to accept your bounty if this gets you in the right direction ;-) – Demian Turner Jun 21 '12 at 13:10
0

I don't have specific knowledge of Keychain* but this is a pretty standardized practice.

  1. You want to protect plain text file "foo". Foo may be of arbitrary size.
  2. Create a symmetric key to encrypt foo.
  3. Encrypt the symmetric key with a key seeded from a passphrase.

Once that's done you can change the "password" by entering the current passphrase, decrypting the symmetric key and then encrypting it with the new passphrase. This avoids lengthy decryption/encryption processes in the event that "foo" is very large.

So how does this work for multiple users who need to access the plaintext of foo? Pretty easy really, you simply create an encrypted copy of the symmetric key once for each user. In other words, do step three for each user.

In practice all of this is abstracted away from view and the end user only needs to deal with their own password.

With regard to part 3 of your questions, the users' keys are not stored in their home. They would most likely be stored in /private/var somewhere. So even without /Users someone who formerly had access would be able to unlock the system.

*It is possible that Keychain works different.

Improve this answer
2
  • What is different about the system keychain is that the system can access what's on the keychain regardless of who is logged in. For example, Time Machine can access the system keychain to mount a remote file share, even if the only user loggged is not an administrative user and therefore cannot access the system keychain. So something else is going on, and I'd like to know exactly what that is. – Old Pro Jun 19 '12 at 2:57
  • Again, I can only surmise, but IMO it's actually not that different. The system itself obviously can get at the key, that's granted. I would assume that there's a system key treated similar to user keys. But now we're at the heart of your question…what provides first access? – bahamat Jun 19 '12 at 17:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .