Copying Login Keychains Between Macs Fails on Secure Enclave Macs with Tahoe

Author: rtrouton | Date: September 8, 2026 | Source: Der Flounder

Manually migrating login keychain files from one machine to another is no longer a viable strategy for Macs equipped with a Secure Enclave running macOS Tahoe.

---

Understanding the Login Keychain

For those unfamiliar, the login keychain is a specialized keychain that macOS generates automatically for every user account.

• Password Sync: By default, the keychain's password is identical to the user's account login password.
• Automation: Because the passwords match, the keychain unlocks automatically upon user authentication.
• Storage: It exists as an encrypted database.

In macOS Tahoe, this is implemented as a SQLite database file named login.keychain-db. You can find it located at: /Users/username_goes_here/Library/Keychains

Historically, you could simply copy this file to a new Mac and unlock it using the original password. This is no longer possible on Secure Enclave-enabled hardware.

---

The Technical Hurdle: Secure Enclave Integration

The failure occurs because the password alone is no longer the sole requirement for decryption. According to Apple's Platform Security documentation regarding Keychain data protection:

Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key).

Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key to speed searches, and the secret value (kSecValueData) is encrypted with the secret key.

The metadata key is protected by the Secure Enclave but is cached in the Application Processor to allow fast queries of the keychain.

The secret key always requires a round trip through the Secure Enclave.

Key Encryption Breakdown

The encryption utilizes $\text{AES-256-GCM}$. The following table illustrates the difference between the two keys involved:

The Bottom Line: Because the decryption keys are physically tied to the Secure Enclave of the original Mac, the destination Mac lacks the hardware-bound keys necessary to decrypt the contents, even if the user provides the correct password.

---

Experimental Verification

To prove this, a test was conducted by moving a keychain from an Apple Silicon Mac (which has a Secure Enclave) to a macOS Virtual Machine (which does not).

Testing Workflow

Step-by-Step Process

• Create a user account on an Apple Silicon Mac (Username: username).
• Locate the login.keychain-db file in /Users/username/Library/Keychains.
• Create a matching user account on a macOS VM with the same password.
• Locate the VM's /Users/username/Library/Keychains directory.
• Delete the VM's default login.keychain-db.
• Paste the login.keychain-db from the Apple Silicon Mac into the VM.

Expected Result: The keychain should unlock automatically upon login. Actual Result: The unlock failed, and macOS automatically generated a brand new, empty login keychain.

---

Analyzing the Logs

To confirm the failure, the following command was used to extract the security logs:

log show --predicate 'subsystem == com.apple.securityd category == KCLogin' --last 1h

The resulting output confirmed that while the password was accepted, the process did not complete successfully:

Timestamp Thread Type Activity PID TTL 
2026-09-08 11:49:11.321174-0400 0x33c Default 0x2fb6 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] StorageManager::login: loginDLDbIdentifier is /Users/username/Library/Keychains/login.keychain 
2026-09-08 11:49:11.321284-0400 0x33c Default 0x2fb6 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] Attempting to unlock login keychain /Users/username/Library/Keychains/login.keychain-db 
2026-09-08 11:49:11.466352-0400 0x33c Default 0x2fb6 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] SecKeychainLogin result: 0, password was supplied 
2026-09-08 11:50:53.497587-0400 0x338 Default 0x2d4a 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] StorageManager::login: loginDLDbIdentif

Visual Evidence