HN 日本語サマリー

← 一覧へ戻る
セキュリティ

macOS TahoeのSecure Enclave搭載MacでログインキーチェーンをMac間でコピーすると失敗する

Copying login keychains between Macs fails on Secure Enclave Macs with Tahoe (derflounder.wordpress.com)

65 pointsby zdw47 コメント

要約

macOS Tahoe以降、Secure Enclaveを搭載したMacでは、ログインキーチェーンファイルを別のMacにコピーしても、パスワードが正しくても正常に機能しなくなりました。これは、キーチェーンの暗号化キーがSecure Enclaveに紐づけられているため、コピー先のMacでは復号に必要なキーが利用できないことが原因です。

全文翻訳

Secure Enclave搭載MacでmacOS Tahoe上のログインキーチェーンのコピーに失敗する

最近、macOSのログインキーチェーンに関する問題に遭遇しました。ログインキーチェーンに馴染みのない方のために説明すると、これはmacOSが各ユーザーアカウントに対して自動的に作成するキーチェーンです。ユーザーのログインキーチェーンのパスワードは、Macにログインするために使用するパスワードと同じです。これは暗号化されたデータベースファイルとして保存され、デフォルトではログインパスワードとキーチェーンパスワードが同じであるため、ユーザーがログインすると自動的にアンロックされます。

macOS Tahoe以降、ログインキーチェーンは/Users/username_goes_here/Library/Keychainsディレクトリに保存されるlogin.keychain-dbという名前のSQLiteデータベースファイルです。

[画像]

従来は、ログインキーチェーンファイルをあるMacから別のMacにコピーし、そのパスワードを提供することで、宛先のMacで開くことができました。macOS Tahoe以降では、Secure Enclaveを使用するMacでは、これは機能しないようです。これらのMacでは、Appleのプラットフォームセキュリティドキュメントのキーチェーンデータ保護セクションで説明されている理由により、ログインキーチェーンのパスワードを持っているだけでは十分ではなくなりました。

キーチェーン項目は、テーブルキー(メタデータ)と行ごとのキー(秘密キー)の2つの異なるAES-256-GCMキーを使用して暗号化されます。キーチェーンメタデータ(kSecValue以外のすべての属性)は、検索を高速化するためにメタデータキーで暗号化され、秘密の値(kSecValueData)は秘密キーで暗号化されます。メタデータキーはSecure Enclaveによって保護されますが、キーチェーンの高速クエリを可能にするためにアプリケーションプロセッサにキャッシュされます。秘密キーは常にSecure Enclaveを介した往復が必要です。

[画像]


更新 – 2026年10月2日:Appleは、ファイルベースのキーチェーンのバックアップに関するドキュメントを公開しました。このドキュメントでは、macOS Tahoe 26.4以降でログインキーチェーンをMac間でどのようにコピーすべきかも説明されています。この投稿を執筆・調査する際に私が到達したいくつかの結論とは異なる情報が含まれているため、このドキュメントをお読みください。


詳細については、以下の「続きを読む」セクションをご覧ください。

上記の抜粋で関連する部分は次のとおりです。

メタデータキーはSecure Enclaveによって保護されますが、キーチェーンの高速クエリを可能にするためにアプリケーションプロセッサにキャッシュされます。秘密キーは常にSecure Enclaveを介した往復が必要です。

これによると、ログインキーチェーンのアンロックにはパスワード以上のものが必要であるようです。なぜなら、それがアンロックするキーは、キーチェーンが作成されたMacのSecure Enclaveに紐づけられているからです。復号キーがソースMacのSecure Enclaveに保存されているため、キーチェーンを手動で別のMacにコピーしてからアンロックしても機能しません。持っているキーチェーンのパスワードは正しいかもしれませんが、その内容を復号するために必要な実際のキーは、宛先のMacでは利用できません。

私は、Apple Silicon Macから2台目のMac(この場合はmacOS仮想マシン)にlogin.keychain-dbファイルをコピーし、アカウントの正しいパスワードを使用してアンロックを試みることで、これをテストできました。

注意: macOS VMを使用してテストすることにした理由は、VMにはSecure Enclaveがないためです。これにより、キーがソースMacのSecure Enclaveに保存されている場合、VMはそれらにアクセスできないことを確認できます。

使用したテスト手順は次のとおりです。

  1. Apple Silicon Macに以下のユーザー名でユーザーアカウントを作成します。

username

  1. Apple Silicon Macでusernameアカウントにログインします。
  2. /Users/username/Library/Keychainsにあるlogin.keychain-dbファイルを見つけます。
  3. login.keychain-dbファイルを便利な場所にコピーします。
  4. 新しいmacOS VMをセットアップします。
  5. Apple Silicon Macのusernameアカウントと同じパスワードで、macOS VMにusernameユーザーアカウントを作成します。
  6. macOS VMでusernameアカウントにログインします。
  7. /Users/username/Library/Keychainsにあるlogin.keychain-dbファイルを見つけます。
  8. macOS VMの/Users/username/Library/Keychainsにある既存のlogin.keychain-dbファイルを削除します。
  9. Apple Silicon Macからlogin.keychain-dbファイルをmacOS VMの/Users/username/Keychainsにコピーします。
  10. macOS VMを再起動します。
  11. macOS VMでusernameアカウントにログインします。

私が期待していた動作:

  • macOS VMでusernameアカウントとしてログインしたときに、ログインキーチェーンが自動的にアンロックされる。

実際の結果:

  • macOS VMでusernameアカウントとしてログインしたときに、新しいログインキーチェーンファイルが自動的に作成された。

なぜこうなったのか?ログを確認する時間です。

ログを確認したところ、正しいパスワードが提供されたにもかかわらず、アンロックの試行が失敗したことがわかりました。関連するログを取得するために、次のコマンドを実行してこれを裏付けることができました。

log show –predicate 'subsystem == "com.apple.securityd" && category == "KCLogin"' –last 1h

ログは次のとおりを示していました。

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

A. ログは、アンロックの試行にパスワード値が提供されたことを確認しています。テスト設定からキーチェーンのパスワードが別途正しいことが確認されているため、単純なパスワードの不一致がアンロック失敗の原因である可能性は排除されるはずです。

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

B. その後ファイルシステムを確認したところ、コピーされたキーチェーンファイルがlogin.keychain-dbからlogin_renamed_1.keychain-dbという名前のファイルに変更され、ログはmacOSがその場所に新しいlogin.keychain-dbファイルを作成したことを確認しています。新しいログインキーチェーンを作成するのは、ログインウィンドウでログインに使用したパスワードでログインした際にログインキーチェーンをアンロックできない場合の標準的なmacOSのフォールバック動作です。

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

[画像]