macOS Keychain Forensics: Concepts and Metadata
Understand macOS keychains for DFIR: login and System keychains, the data protection keychain, iCloud Keychain, metadata value and legal limits.
The macOS keychain is Apple's credential store: it holds website and application passwords, Wi-Fi keys, certificates, private keys and secure notes. For a forensic examiner, the keychain is interesting for two very different reasons. The first is metadata: even without touching a single secret, the list of items tells you which accounts, services, networks and applications a user has interacted with, and when those items were created or changed. The second is content, which is heavily protected and must only be accessed under a clear legal authority and with appropriate methods. This article explains where keychains live, what each format exposes, which read-only commands are safe to use, and why Apple Silicon changes the acquisition picture. It deliberately does not describe how to extract or decrypt credentials.
The different keychains on a Mac
Modern macOS uses two families of keychain side by side: the legacy file-based keychains and the newer data protection keychain shared with iOS.
| Keychain | Location | Format | Notes |
|---|---|---|---|
| Login keychain | ~/Library/Keychains/login.keychain-db | File-based keychain database | Unlocked with the user's login password at login; named login.keychain before macOS Sierra |
| System keychain | /Library/Keychains/System.keychain | File-based | Machine-wide items: system certificates, some network credentials, items used before login |
| System roots | /System/Library/Keychains/SystemRootCertificates.keychain | File-based | Apple-shipped trust anchors on the sealed system volume |
| Data protection keychain ("Local Items" / "iCloud") | ~/Library/Keychains/<UUID>/keychain-2.db | SQLite | Same design as iOS; items can sync via iCloud Keychain |
| Other per-user files | ~/Library/Keychains/ | Various | May include additional keychains created by apps or the user, and metadata files; inventory the folder rather than assuming its content |
The <UUID> directory name is tied to the hardware, which matters when a user profile has been migrated between Macs: you may find more than one UUID directory, and only one is active on the current machine.
Applications increasingly store items in the data protection keychain rather than the login keychain. The Passwords app introduced with macOS Sequoia and the Passwords section of System Settings are front ends to this store. As a result, the login keychain on a recent Mac may look sparse while the user still has hundreds of saved credentials.
What metadata exists
Every keychain item belongs to a class, and each class has attributes. The secret, such as the password itself or the private key material, is stored separately from most of these attributes and is always encrypted.
| Item class | Typical attributes | Investigative value |
|---|---|---|
Generic password (genp) | Service, account, label, description, creator, creation date, modification date, access group | Application accounts, Wi-Fi networks, app tokens by service name |
Internet password (inet) | Server, account, protocol, port, path, authentication type, dates | Websites and servers the user saved credentials for |
Certificate (cert) | Subject, issuer, serial number, label | Corporate identities, VPN or client certificates, suspicious root certificates |
Key (keys) | Label, key class, key type, application tag | Presence of private keys (for example SSH or signing identities) |
| Identity | Certificate plus matching private key | Client authentication capability |
In a file-based keychain such as login.keychain-db, many of these attributes are stored in a readable form while the secret data is encrypted. Dates are stored as timestamp strings in UTC, for example 20260927143012Z. In the data protection keychain (keychain-2.db), the tables are named after the classes (genp, inet, cert, keys), and dates, when available, use Mac Absolute Time (seconds since 2001-01-01 00:00:00 UTC, or Unix time minus 978307200). On recent releases, many attributes in keychain-2.db are themselves protected inside encrypted blobs, so an offline SQLite query may reveal the structure and a few columns but not the full set of service and account names. Inspect the schema and actual column population on your copy rather than assuming that a column is filled.
# Inspect the structure of a copied data protection keychain (read-only, on a copy)
sqlite3 -readonly ./case/keychain/keychain-2.db ".tables"
sqlite3 -readonly ./case/keychain/keychain-2.db ".schema genp"
Read-only commands on a live system
On a live system, in the context of the user whose keychain you are documenting, the security tool can enumerate keychains and their attributes. The commands below show metadata and settings; they do not display secrets.
# Keychains in the user's search list, and the default keychain
security list-keychains
security default-keychain
# Lock settings (timeout, lock on sleep) of the login keychain
security show-keychain-info ~/Library/Keychains/login.keychain-db
# Attributes of items in a file-based keychain (no secret data without -d)
security dump-keychain ~/Library/Keychains/login.keychain-db > login_keychain_attributes.txt
# Certificates in the System keychain
security find-certificate -a /Library/Keychains/System.keychain | grep -E 'labl|"alis"'
Some precise behaviour to keep in mind:
security dump-keychainwithout-dprints item classes and attributes (service, account, label, dates) but not the secret data. The-doption requests the decrypted data, prompts for authorization for each item and is outside the scope of a metadata review.security find-generic-passwordandsecurity find-internet-passwordwithout-gor-walso print attributes only. Those two options request the secret and should not be used without explicit authorization.- The
securitycommands above work against file-based keychains. They do not give a complete view of the data protection keychain, so a shortdump-keychainoutput does not mean the user stored few credentials. - Running these commands on a live system generates activity, and access prompts may appear to the user. Document every command, as you would any live response action.
Keychain Access (the GUI) shows the same metadata, including creation and modification dates in the item's Get Info window, and can be useful for screenshots in a report.
Investigative value of keychain metadata
Without reading a single password, keychain attributes can support a number of findings:
- Accounts and services: internet password items show which websites and servers the user saved credentials for; generic password items show which applications stored tokens, identified by service names such as a vendor's bundle identifier.
- Wi-Fi history: saved Wi-Fi networks are represented by keychain items (commonly with an "AirPort" service and the SSID as account) in the System keychain or the data protection keychain, depending on version. Correlate with the known networks preference file,
/Library/Preferences/com.apple.wifi.known-networks.pliston recent releases. - Timelines: creation and modification dates show when an account was first saved and when a password was last changed. These dates can anchor activity in a timeline with unified logs and browser history (see Safari and browser forensics).
- Suspicious certificates: an unexpected root certificate in the System or login keychain may indicate interception proxies, adware or a malicious configuration profile. Cross-check with
sudo profiles list. - Malware footprint: some macOS malware families create keychain items or request access to existing ones. Unexpected generic password items with odd service names, or items created at the same time as a new LaunchAgent (see launchd persistence), deserve attention.
Acquisition, Apple Silicon and the Secure Enclave
The login keychain is protected by a key derived from the user's login password. The data protection keychain goes further: each item is encrypted with a per-item key wrapped by a class key, and class keys are protected by keys held by the Secure Enclave on Apple Silicon and T2 Macs. In practice this means:
| Scenario | What is realistically available |
|---|---|
| Dead-box copy of keychain files, no credentials | File structure, some attributes of file-based keychains; no secrets; little or nothing from the data protection keychain |
| Files copied to another Mac | Secrets in the data protection keychain remain unreadable because the keys are bound to the original device |
| Live, unlocked device with the user's cooperation and password | Full review is technically possible using Apple's own interfaces, subject to authorization |
| Approved commercial or law enforcement tooling | Capabilities vary by product, macOS version and hardware; validate claims before relying on them |
Because the keys never leave the Secure Enclave, the traditional "image first, analyze later" approach does not apply to keychain secrets on modern hardware. If keychain content is within scope, the decision must be made before the device is powered down or the user is unavailable. See Apple Silicon forensics and macOS forensic acquisition for the broader strategy.
iCloud Keychain adds another dimension. Items marked as synchronizable are replicated to the user's other devices via iCloud, and Apple states that iCloud Keychain data is end-to-end encrypted, so it is not available from Apple as readable content. The presence of synced items can still show that other devices share the same account, which may widen the scope of an investigation.
Legal and ethical considerations
The keychain is one of the most sensitive stores on a Mac. It routinely contains credentials for banking, personal email, health services and third parties who are not part of the investigation. Before touching it:
- Confirm that the authority under which you operate (warrant, consent, employment policy, contract) explicitly covers stored credentials, not merely the device.
- Prefer metadata review when it answers the question. Most corporate investigations need to know that an account existed, not its password.
- Never use recovered credentials to access online accounts unless that access is separately and explicitly authorized; doing so may be unlawful even when the device examination is lawful.
- Record every action, including commands run on a live system and any prompts accepted by the user.
Caveats
- Version differences: file names, the split between login and data protection keychains, and which attributes are readable change across releases. Verify on the target version.
- Multiple UUID folders: migrated profiles may contain stale data protection keychains from previous hardware.
- Live-system side effects: keychain queries can trigger prompts and update access-related state. Collect other volatile data first.
- Absence is not evidence: a sparse login keychain is normal on recent macOS; credentials may live in the data protection keychain, in iCloud Keychain, or in third-party password managers.
- Attribution: an item's creator or access group indicates which app stored it, not which person typed the credential.
Frequently asked questions
Where is the login keychain stored on macOS?
The login keychain is stored at ~/Library/Keychains/login.keychain-db for each user. Modern macOS also keeps a data protection keychain, shown as Local Items or iCloud in Keychain Access, in an SQLite database at ~/Library/Keychains/<UUID>/keychain-2.db.
Can an investigator see keychain metadata without the user's password?
Partly. For the file-based login keychain, attributes such as item class, label, service, account and creation and modification dates can often be listed without revealing secrets. The secret data itself is encrypted, and the data protection keychain protects much more of its content, so meaningful access generally requires the user's credentials, the live unlocked device, or approved tooling within a lawful authorization.
Does Apple Silicon change keychain forensics?
Yes. On Apple Silicon and T2 Macs, keys protecting the data protection keychain are bound to the Secure Enclave and the specific device, so copying keychain files to another machine does not make their secrets readable. Acquisition planning must assume that secrets are only accessible on the original, unlocked device with proper authorization.