Understanding Keychain Security

The Mac OS X Keychain mechanism is an often-misunderstood, underutilized component of security. The Keychain infrastructure allows a user to store passwords in a 3DESencrypted, OS-level password database, so that users do not have to enter passwords each time they are needed. Instead, the OS will, for Keychain-aware applications, search through the user's keychains to see if the password already exists.

Keychain-aware applications utilize the Apple-provided Keychain Services, provided in the Security Framework. The Security Framework is maintained by Apple to provide convenience wrappers around the CDSA (www.opengroup.org/security/cdsa.htm) library included with MacOS X, facilities for manipulating keychains, and more. Programmers who include support for Keychain Services in their applications can then leverage the power of Mac OS X security.

Keychain-aware applications that are included in Mac OS X include Safari, iTunes, Mail, and the Finder's Go > Connect to Server command. If a Keychain-aware application finds a valid keychain entry in any of the keychains in the search path, it will then attempt to use that password automatically to authenticate the user. If the password is correct, the user will be automatically logged in; if it is not correct, or if no keychain entry exists for that password, the user will be given the opportunity to enter the password (and, optionally, save that password in the keychain to prevent having to enter it again).

The application Keychain Access allows a user to manipulate his or her keychains (as you shall see in a later example) and also create new keychains (both on a per-user and global basis).

Mac OS X has a set of core OS keychains it uses to store SSL certificate authority information (located in /System/Library/Keychains) and also global keychains that apply to all users on the system (in /Library/Keychains). Each individual user's keychain is stored in his or her home folder (~/Library/Keychain) with the name login.keychain.

Note

In the version of Mac OS X prior to 10.3, each user's personal keychain would be named with his or her associated short name, for instance osxuser1. keychain. You may run across this naming convention for accounts that have been updated from older version of Mac OS X.

A default installation of Mac OS X would show the following keychains in those locations:

powerbook:~ local$ ls /System/Library/Keychains/ X509Anchors X509Certificates powerbook:~ local$ ls /Library/Keychains/ System.keychain powerbook:~ local$ ls ~/Library/Keychains/ login.keychain

Each keychain is password-protected and must be unlocked by the OS before the entries contained within can be used. The OS will attempt to unlock the keychains it uses automatically if it knows the password (which it does for the System and X509 keychains).

When a new account is created, the login keychain is created and password-protected with the exact same password as used for the user's login. So, when the OS attempts to utilize an entry within a user's login.keychain, it will attempt to unlock it with the user's login password (entered at the login window). If the user has not changed the password on the keychain, the OS will be able to unlock it without user intervention; if the user has changed the keychain password, the user will be asked to enter the keychain password to unlock the keychain.

A user may add other keychains, both global and local. A custom global keychain can be used to store passwords for all users on the system, but it can be password-protected so that it is not automatically unlocked like the default System.keychain is. A custom local keychain can be used for more sensitive information that the user does not want to have in his or her default local.keychain, because it will not be unlocked automatically by the OS.

A system administrator can prepopulate a global or local keychain, and then place it into the correct place for usage: /Library/Keychains for global keychains and ~/Library/Keychains for user-specific ones.

Keychain-Aware Applications in Action

When a Keychain-aware application wants to search for keychain entries that are appropriate to it, it will follow this flow:

Assuming that an entry does not previously exist in any keychain, the user will hit the section of the flowchart that states "App asks user for user name and password." If the user enters the correct password, the entry is now stored in the user's login.keychain.

Look at the diagram again, knowing that there is a valid keychain entry. At the "Keychain entry found?" question, we now have a Yes, and proceed to the next question: "App always has access to entry?" The first time through this flow, this will not be the case, so you can proceed to "Keychain API asks user to allow access?", which appears as a dialog to the user.

If the user clicks Deny, the keychain entry, even though it exists, will not be utilized. If the user clicks Allow Once, the keychain entry is used this one time, and the next time through the flowchart, the user will be presented with this dialog again. If the user clicks Always Allow, that keychain entry will be marked as always available in a Keychain ACL list.

Modifying Keychain ACLs

Each keychain entry has a separate access control list with three possible levels of strictness:

• Always allow access: Applications can always read this item without any additional authentication or warning. This setting is generally not recommended.

• Confirm before allowing access: Before an application can read this item, the user will be presented with a dialog that asks whether the application should be denied access to the item, given access to the item once, or always given access to the item. Recommended for lower security passwords where convenience is more important than high security, such as a server in another department that the user may access once in a while.

• Confirm before allowing access and ask for keychain password: In addition to asking the user to deny, allow access once, or always allow access to the item, the user will also be asked for the keychain's password. This is the most secure option and is recommended for most uses.

In addition, applications may be given access to an item without requiring user interaction on an application-by-application basis. When a user clicks the Always Allow button in the access confirmation dialog, that application requesting access is added to the item's "Always allow access" list automatically. Once this is done, it is as though the item had the "Always allow access" option selected for that particular application, but any other applications still need to ask for confirmation before they can access the item. You can also add and remove applications from this list by using the Keychain Access application.

Controlling Keychains With Keychain Access

To control how your keychains function, use the Keychain Access application (located in /Applications/Utilities/Keychain Access).

View and Modify Keychain Entries

You can add as many keychains as you like and move items from one keychain to another to increase security. These keychains can all have different passwords and contain different items. For example, you can have one keychain for your Web forms, one for your certificates, one for servers, email, VPN, and so on. Each keychain will have a different password and can be locked separately. Use the Keychain Access application to create each keychain.

Perform Keychain First Aid

Sometimes keychains can start acting crazy and they need to be repaired. Corrupted keychains reveal themselves in many ways, including you being naggingly asked to use or store an entry in a keychain, even though you know you have done it at least once already. Another potential problem is a keychain password for local.keychain getting out of sync with the login password, and then forgetting the original local.keychain password (which prevents you from changing it).

Within Keychain Access is a menu item called Keychain First Aid (which was formerly a separate application), which can be used to repair keychains gone awry. In Keychain Access, choose Window > Keychain First Aid to enable this repair.