パスキーを作るのに「iCloudキーチェーンが必要」とは？（Mac/iPhoneのパスキーの保存場所）

by

最近、MacBookでブラウザからあるウェブサービスにサインインしようとしたら、パスワード入力のあとに「パスキーを作成しますか？」という画面が表示されました。

セキュリティ的にも興味があったので、「せっかくだから作ってみよう」と思い、パスキーを作成することにしました。すると、次の画面で「iCloudキーチェーンを有効にしてください」と表示されました。

　パスキーを保存するには、iCloudキーチェーンを有効にする必要があります。

ここでちょっと引っかかりました。iCloudは、クラウド上のサービス。
なるべくならセキュリティ情報は端末内で管理したいと思ったからです。

今回は、「Macではパスキーをローカルに保存できないのか」「iCloudキーチェーンに保存する場合、端末ロック解除コードはどう扱われているのか」を整理してみます。

パスキーは本来“端末の中”にあるはず

一般的な「パスキー」の仕組みとAppleでの実装には、微妙な違いがあります。
この2つを区別して理解することが大切です。

まずは「パスキー（passkey）」の基本から確認しておきます。
パスキーは、パスワードをより安全に扱いやすくした仕組みで、その違いは、「認証の仕組み」と「管理の主体」にあります。

パスキーは”端末の中”に保存される パスワード ユーザーが覚える サーバーに送信 照合して認証 リスク：漏洩・使い回し パスキー 端末が秘密鍵保持 端末ロック解除で操作 秘密鍵は個人の端末内に保存されるのが基本
  • パスワードは、ユーザーが「自分で決めた文字列（秘密）」を覚え、毎回サーバーに送って照合する方式です。結果として「簡単すぎる」「使い回す」「漏えいする」などのリスクが生まれます。
  • パスキーは、人間ではなく端末が秘密を保持します。ログイン時には秘密鍵で署名を行い、サーバーは公開鍵で検証します。ユーザーは「生体認証」や「端末ロック解除」で操作するだけで済み、秘密文字列を覚える必要がありません。

「パスキー（passkey）」は、FIDO2（ファイド、Fast Identity Online）の規格に基づく仕組みです1。
この規格では、

  1. ユーザーがサイトにログインしているときに、端末の中で秘密鍵（パスキー）と公開鍵のペアを作ります。
  2. 次の認証のときには、サイトが出すチャレンジに対して、端末内の秘密鍵（パスキー）で署名を行います。
  3. これにより、サーバーは「確かにこの端末からのアクセスだ」と確認できるわけです。

サイトには公開鍵だけが登録されます。
秘密鍵は端末の安全な領域に保存され、外に出ることはありません2。
つまり、パスキーの秘密鍵は“外部に出さない”のが基本原則なのです。

パスキーはパスワードマネージャの延長

パスキーの導入前から、端末のパスワードマネージャ機能を使ってパスワードを保存し、利用することが一般的になっていました。パスキーは「パスワードマネージャ文化」の延長線上にある自然な進化形と言えます。

パスワードマネージャによって、ユーザーは「パスワードを覚える」負担から解放されました。しかし、
仕組みとしてはまだ「文字列の秘密をサーバーに送って照合する」という従来型認証の枠にとどまっていました。

ユーザーから見ると、パスキーも自動的に送られる点で似ています。
しかし、パスキーは、単なる文字列ではなく、公開鍵暗号のペア（秘密鍵＋公開鍵）です。
直接サーバーに「秘密の暗号鍵」を送るのではなく、秘密鍵で署名した情報を送ることで、さらに漏洩リスクを減らしているのです。

それでもAppleはiCloudキーチェーンを使う

そうそう。
パスキーは、端末内の安全な領域に保存されるんだよね。

それなら、どうしてMacでは、iCloudキーチェーンを有効にしないとパスキーを作成できないの？
iCloudから「外部」に出てしまうのでは？

Appleでは、原則としてパスキーをiCloudキーチェーンに保存・同期する方式を採用しています。

Apple端末のパスキーとiCloudキーチェーン Apple端末でのパスキーの仕組み FIDO規格 パスキー認証の仕組み 秘密鍵をユーザー側で保管 Apple実装 クラウドでの保存 複数端末での同期

iCloudキーチェーンのパスキーは端末間で同期され、たとえばiPhoneで作成したパスキーは、同じApple IDでログインしているMacでもそのまま使えます。FIDOのパスキーの仕様を元に、iCloud同期層を拡張した仕組みになっているのです。一台のMacだけで使うならローカルで十分かもしれませんが、iPhone・iPad・別のMacなど複数台を持っている環境では、同期／バックアップの観点から iCloudキーチェーンをオンにするメリットがあります。

もともとは“ローカル保存”でしたが、いまはユーザーインターフェース上では、iCloudを有効にしないとパスキー作成を完了できないようになっています。

秘密鍵は“クラウドにはあるけれど読めない”

ただし、iCloud上のパスキーはApple自身でも中身を見ることはできません3。
パスキーは端末の中で暗号化してから保存されるからです（エンドツーエンド暗号化）。
iCloud上のデータは「各デバイスに固有の鍵」で使って復号してないと利用できないのです。

つまり、この仕組みは、一見すると「クラウド保存」ですが、実際には「クラウド経由で暗号化データを同期している」にすぎません。もしiCloudサーバーが侵害されても、攻撃者は暗号文しか得られません。

ロック解除コードは“鍵を開ける鍵”

もう一つ気になっているのが、iCloudキーチェーンに保存されたパスキーを使うときに、毎回Touch IDやパスコードが求められることなんだよね。
Appleアカウントのパスワードではなく、端末のロック解除が必要なのはどうして？

まず、Appleアカウントのパスワードではないのは、すでにAppleアカウントにサインインしている端末で操作しているからです。
そして、端末のロック解除が必要なのは「Secure Enclave」の設計によるものです。

iPhone/MacBookでのパスキー認証の流れ 1 端末のロック解除 2 Secure Enclave 各デバイスに固有の鍵 3 暗号化してあるパスキーを復号 4 受信したチャレンジを 秘密鍵で署名して返す 5 サイトで認証

iCloud上のパスキーの暗号を解く鍵は、各デバイスの中だけにあります4。
この「各デバイスに固有の鍵」は、Secure Enclave（セキュアエンクレーブ）というハードウェア領域に保存されています5。

端末ロック解除コード（パスコードや生体認証）は、Secure Enclave内の鍵の「開放条件」に関係しているのです。

Appleアカウントは、クラウド上の本人認証を担う資格情報です。
しかし、Secure Enclaveは、iPhoneやMacBookなど、ローカルの保存領域。
そのため、端末ロック解除コードが「暗号鍵を使用してもよい」というトリガーの役割を果たしているのです。

つまり、ロック解除コードやTouch IDは「秘密鍵を取り出すための最後の鍵」なのです。

この入れ子構造によって、パスキーで認証しているほかのサービスは、たとえAppleアカウントの認証情報が漏れたとしても、不正アクセスの被害に合わないようになっています6。クラウドに暗号化されたデータがあっても、それを解読するための鍵はデバイスの中に閉じ込められているからです7。

【補足】iCloudキーチェーンの暗号構造（鍵の階層性）

ちなみに、「iCloudキーチェーン」では、「鍵の鍵の鍵の鍵」のように複数の層で鍵が保護されています。
この仕組みは、「Key Hierarchy（鍵の階層構造）」と呼ばれます。

  1. Data Encryption Key (DEK) – 実データ（パスキーなど）を暗号化
  2. Class Key – DEKを暗号化
  3. Master Key – Class Keyを暗号化
  4. iCloud Sync Circle Key – デバイス間での共有を安全にする鍵
  5. Secure Enclave Hardware UID Key – 各デバイス固有の物理鍵で最上位に位置する

データ（パスキーなど）を暗号化しているのは「Data Encryption Key（DEK）」で、それをさらに複数の鍵が包んでいます。
その最上位に位置するのが Secure Enclave Hardware UID Key です。

Appleは“利便性より均質性”を選んでいる

MacやiPhoneではパスキーを使うときにiCloudキーチェーンを求められます。パスキーをクラウド経由で同期する仕組みは、一見するとFIDOの思想から外れているように見えます。

しかし、Appleの哲学の中では筋が通っています。というのも、「すべてのデバイスで同じように安全に動くこと」。Appleはユーザー体験を「均質」に保つことをとても重視しているからです8。

確かに、設定や挙動に複数のパターンがあると、サポートも管理も難しくなり、結果として不具合も増える。そうしたリスクを避けるために、Appleはあえてパスキーのローカル保存という運用を選びにくくしているのです。

  1. パスキーはFIDO AllianceとW3Cが策定したFIDO2（WebAuthn + CTAP2）に準拠し、秘密鍵と公開鍵を利用して認証する仕組みです。 – FIDO Alliance: What is FIDO Authentication?
  2. パスキー認証では、サーバーが送信するランダムなチャレンジデータに対して、端末内の秘密鍵で「署名（digital signature）」を生成します。これは暗号化とは異なる操作で、公開鍵暗号方式における認証メカニズムです。サーバーは事前に登録された公開鍵を使って署名を検証することで、正当な秘密鍵の保持者であることを確認します。署名されたデータはサーバーに送信されますが、秘密鍵そのものは端末外に出ることはありません。 – How Passkeys Work | Passkey Central
  3. AppleのパスキーはiCloudキーチェーンを利用して暗号化されたままデバイス間で同期される。Appleはこのプロセスがエンドツーエンド暗号化（E2EE）であり、Appleも復号できないと明記している。 – Apple Platform Security: Passkeys Overview (2024)
  4. iCloudキーチェーン内のデータはAES-256-GCMで暗号化され、復号鍵はユーザーの各デバイス内のSecure Enclaveにのみ存在し、サーバー上には保存されない。 – Apple Platform Security: iCloud Keychain
  5. Secure EnclaveはAppleデバイス内に組み込まれた専用セキュリティコプロセッサで、暗号化や鍵管理をハードウェアレベルで処理し、システムやアプリから直接アクセスできないよう設計されている。 – Apple Platform Security: Secure Enclave
  6. Apple IDの二要素認証と端末ロック解除は別の層の認証であり、パスキーの利用時には必ずローカル認証（Touch ID／Face ID／パスコード）が必要とされる。 – Apple Developer Documentation: Passkeys
  7. Appleのパスキーシステムでは、Apple IDの二要素認証と端末ロック解除は異なる層の認証として扱われます。パスキーの利用時には、必ずローカル認証（Touch ID/Face ID/デバイスパスコード）が要求されます。これは、Apple IDアカウントが侵害された場合でも、物理的なデバイスと、そのデバイスのロック解除手段（生体認証またはパスコード）がなければパスキーを使用できないようにするための多層防御の仕組みです。 – About the security of passkeys – Apple Support
  8. Appleのデザイン原則は「一貫性」「単純さ」「統合性」に基づいており、UXの均質化を通じてセキュリティとサポートの効率を両立させることを目的としている。 – Apple Human Interface Guidelines