메뉴
HN
Hacker News • 15일 전

macOS 타호에서 시큐어 앤클레이브 맥 간 로그인 키체인 복사 불가

IMP
6/10
핵심 요약

macOS Tahoe부터 애플 실리콘 등 시큐어 앤클레이브(Secure Enclave) 탑재 맥에서는 로그인 키체인 파일을 다른 맥으로 복사해도 더 이상 열 수 없습니다. 키체인 암호화 키가 원본 맥의 시큐어 앤클레이브에 저장되기 때문에, 비밀번호가 맞더라도 다른 맥에서는 복호화 키 자체를 사용할 수 없기 때문입니다. 기존의 키체인 마이그레이션 방식을 쓰던 IT 관리자들에게 중요한 변화입니다.

번역된 본문

최근 macOS의 로그인 키체인과 관련된 문제를 겪었다. 로그인 키체인에 익숙하지 않은 분들을 위해 설명하자면, 이것은 macOS가 맥의 각 사용자 계정에 자동으로 생성하는 키체인이다. 사용자의 로그인 키체인 비밀번호는 맥에 로그인할 때 사용하는 비밀번호와 일치한다. 로그인 키체인은 암호화된 데이터베이스 파일로 저장되며, 기본적으로 로그인 비밀번호와 키체인 비밀번호가 같기 때문에 사용자가 로그인하면 자동으로 잠금 해제된다.

macOS Tahoe 기준으로 로그인 키체인은 login.keychain-db라는 이름의 SQLite 데이터베이스 파일이며, 사용자의 홈 폴더 내 다음 디렉터리에 저장된다: /Users/username_goes_here/Library/Keychains

지금까지는 로그인 키체인 파일을 한 맥에서 다른 맥으로 복사한 후, 해당 키체인의 비밀번호를 입력하면 대상 맥에서 열 수 있었다. 그러나 macOS Tahoe부터는 시큐어 앤클레이브(Secure Enclave)를 사용하는 맥에서는 더 이상 작동하지 않는 것으로 보인다. 이러한 맥에서는 로그인 키체인의 비밀번호만으로는 부족하다. 그 이유는 애플의 플랫폼 보안(Platform Security) 문서의 '키체인 데이터 보호' 섹션에 설명되어 있다:

키체인 항목은 두 개의 서로 다른 AES-256-GCM 키로 암호화된다: 테이블 키(메타데이터)와 행별 키(시크릿 키)이다. 키체인 메타데이터(kSecValue를 제외한 모든 속성)는 검색 속도를 높이기 위해 메타데이터 키로 암호화되며, 시크릿 값(kSecValueData)은 시크릿 키로 암호화된다. 메타데이터 키는 시큐어 앤클레이브가 보호하지만 키체인의 빠른 조회를 위해 애플리케이션 프로세서에 캐시된다. 시크릿 키는 항상 시큐어 앤클레이브를 거쳐야 한다.

위 인용문에서 중요한 부분은 다음과 같다:

메타데이터 키는 시큐어 앤클레이브가 보호하지만 키체인의 빠른 조회를 위해 애플리케이션 프로세서에 캐시된다. 시크릿 키는 항상 시큐어 앤클레이브를 거쳐야 한다.

이를 통해 볼 때, 로그인 키체인의 잠금을 해제하려면 비밀번호만으로는 부족하다. 잠금 해제에 필요한 키들이 키체인이 생성된 맥의 시큐어 앤클레이브에 묶여 있기 때문이다. 복호화 키가 원본 맥의 시큐어 앤클레이브에 저장되어 있으므로, 키체인을 다른 맥에 수동으로 복사한 후 잠금을 해제하는 것은 작동하지 않는다. 키체인의 비밀번호가 올바르더라도, 그 내용을 복호화하는 데 실제로 필요한 키를 대상 맥에서 사용할 수 없는 것이다.

나는 Apple Silicon 맥에서 login.keychain-db 파일을 두 번째 맥(이 경우 macOS 가상 머신)으로 복사한 뒤, 계정의 올바른 비밀번호로 잠금 해제를 시도함으로써 이를 직접 확인할 수 있었다.

참고: macOS 가상 머신을 테스트에 사용한 이유는 가상 머신에는 시큐어 앤클레이브가 없기 때문이다. 이를 통해 키가 원본 맥의 시큐어 앤클레이브에 저장되고 있다면, 가상 머신에서는 그 키에 접근할 수 없다는 것을 검증할 수 있다.

사용한 테스트 절차는 다음과 같다:

  1. Apple Silicon 맥에 username이라는 사용자 계정을 생성한다.
  2. Apple Silicon 맥의 username 계정에 로그인한다.
  3. /Users/username/Library/Keychains에서 login.keychain-db 파일을 찾는다.
  4. login.keychain-db 파일을 편리한 위치로 복사한다.
  5. 새로운 macOS 가상 머신을 설치한다.
  6. macOS 가상 머신에 Apple Silicon 맥의 username 계정과 동일한 비밀번호로 username 사용자 계정을 생성한다.
  7. macOS 가상 머신의 username 계정에 로그인한다.
  8. /Users/username/Library/Keychains에서 login.keychain-db 파일을 찾는다.
  9. macOS 가상 머신의 /Users/username/Library/Keychains에서 기존 login.keychain-db 파일을 제거한다.
  10. login.keychain-db 파일을 복사한다.
원문 보기
원문 보기 (영어)
Der Flounder Seldom updated, occasionally insightful. Home About Contact Home > Mac administration , macOS > Manually copying login keychain files from one Mac to another no longer works on Secure Enclave-equipped Macs running macOS Tahoe Manually copying login keychain files from one Mac to another no longer works on Secure Enclave-equipped Macs running macOS Tahoe September 8, 2026 rtrouton Leave a comment Go to comments 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: 1. Create a user account on an Apple Silicon Mac with the following username: username 2. Log into the username account on the Apple Silicon Mac. 3. Locate the login.keychain-db file in /Users/username/Library/Keychains . 4. Copy the login.keychain-db file to a convenient location. 5. Set up a new macOS VM 6. 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. 7. Log into the username account on the macOS VM. 8. Locate the login.keychain-db file in /Users/username/Library/Keychains . 9. Remove the existing login.keychain-db file from /Users/username/Library/Keychains on the macOS VM 10. Copy the login.keychain-db file from the Apple Silicon Mac to /Users/username/Library/Keychains in the macOS VM. 11. Restart the macOS VM 12. 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: This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters log show -predicate 'subsystem == "com.apple.securityd" && category == "KCLogin"' -last 1h view raw gistfile1.txt hosted with ❤ by GitHub The logs showed the following: This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters 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: loginDLDbIdentifier is /Users/username/Library/Keychains/login.keychain 2026-09-08 11:50:53.497759-0400 0x338 Default 0x2d4a 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] Attempting to unlock login keychain "/Users/username/Library/Keychains/login.keychain-db" 2026-09-08 11:50:53.713693-0400 0x338 Default 0x2d4a 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] SecKeychainLogin failed: -2147413984, password was supplied 2026-09-08 11:50:54.014314-0400 0x338 Default 0x2d4d 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] StorageManager::login: loginDLDbIdentifier is /Users/username/Library/Keychains/login.keychain 2026-09-08 11:50:54.014418-0400 0x338 Default 0x2d4d 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] Creating login keychain /Users/username/Library/Keychains/login.keychain 2026-09-08 11:50:54.240675-0400 0x338 Default 0x2d4d 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] Login keychain created successfully 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. This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters 2026-09-08 11:50:53.713693-0400 0x338 Default 0x2d4a 170 0 loginwindow: (Security) [com.apple.securityd:KCLogin] SecKeychainLogin failed: -2147413984, password was supplied view raw gistfile1.txt hosted with ❤ by GitHub B. Checking the file system afterward showed the copied keychain file had be
macOS 보안 키체인 시큐어 앤클레이브 애플