macOS Security

macOS Secure Enclave Prevents Keychain Copying Between Macs

New security measures in macOS Tahoe tied to the Secure Enclave now prevent the traditional method of copying login keychain files between Macs.

News AutomationCompiled 17:05 UTC · 1 min read

A close-up of an Apple MacBook Pro keyboard with the screen displaying code. · Photo by Slejven Djurakovic on Unsplash

1 sources

Pipeline ingest

3 reads

Positive / Neutral / Negative

0 countries

Related coverage

Manually copying login keychain files from one Mac to another no longer works on Secure Enclave-equipped Macs running macOS Tahoe

I recently encountered an issue with the login keychain on macOS. For those not familiar with the login keychain, it’s a keychain that macOS automatically creates for each user account on a Mac. The password for a user’s login keychain matches the password used to log in to the Mac. It is stored as an encrypted database file and unlocks automatically when the user logs in, since the login password and keychain password are the same by default.

As of macOS Tahoe, the login keychain is a SQLite database file named login.keychain-db. It is stored in the user’s home folder in the following directory:

/Users/username_goes_here/Library/Keychains

Historically, you could copy the login keychain file from one Mac to another and be able to open it on the destination Mac by providing the password to that keychain. As of macOS Tahoe, this does not appear to work for Macs which use Secure Enclave. For those Macs, only having the password to the login keychain is no longer sufficient for reasons discussed in the Keychain data protection section of Apple’s Platform Security documentation:

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.

For more details, please see below the jump.

The relevant section of the passage above is this:

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.

From that, it appears that unlocking the login keychain requires more than the password because the keys it unlocks are tied to the Secure Enclave of the Mac where the keychain was created. With the decryption keys stored in the source Mac’s Secure Enclave, manually copying the keychain to another Mac and then unlocking it won’t work. The password you have for the keychain may be correct, but the actual keys needed to decrypt its contents won’t be available on the destination Mac.

I was able to test this by copying a login.keychain-db file from an Apple Silicon Mac to a second Mac (in this case, a macOS virtual machine) and attempted to unlock it using the account’s correct password.

Note: The reason I chose to test using a macOS VM is that VMs don’t have a Secure Enclave. This allows us to verify that if keys are being stored in the source Mac’s Secure Enclave, then the VM won’t be able to access them in the VM.

Here’s the test procedure used:

Create a user account on an Apple Silicon Mac with the following username:

username

Log into the username account on the Apple Silicon Mac.
Locate the login.keychain-db file in /Users/username/Library/Keychains.
Copy the login.keychain-db file to a convenient location.
Set up a new macOS VM
Create a username user account on the macOS VM with an identical password to the one used for the username account on the Apple Silicon Mac.
Log into the username account on the macOS VM.
Locate the login.keychain-db file in /Users/username/Library/Keychains.
Remove the existing login.keychain-db file from /Users/username/Library/Keychains on the macOS VM
Copy the login.keychain-db file from the Apple Silicon Mac to /Users/username/Library/Keychains in the macOS VM.
Restart the macOS VM
Log into the username account on the macOS VM.

The behavior I expected:

The login keychain would unlock automatically when I logged in as the username account on the macOS VM.

What actually happened:

A new login keychain file was created automatically when I logged in as the username account on the macOS VM.

Why did this happen? Time to check the logs.

What I found was that the unlock attempt failed even though the correct password was supplied. I was able to confirm this by running the following command to get the relevant logs:

view raw gistfile1.txt hosted with ❤ by GitHub

The logs showed the following:

view raw gistfile1.txt hosted with ❤ by GitHub

A. The log confirms a password value was supplied to the unlock attempt. As the keychain’s password was separately verified to be correct from the test setup, this should rule out a simple password mismatch causing the unlock failure.

view raw gistfile1.txt hosted with ❤ by GitHub

B. Checking the file system afterward showed the copied keychain file had been renamed from login.keychain-db to a file named login_renamed_1.keychain-db and the logs confirm macOS created a new login.keychain-db file in its place. Creating a new login keychain is the standard macOS fallback behavior when a login keychain can’t be unlocked on login with the password used to log in at the login window.

view raw gistfile1.txt hosted with ❤ by GitHub