Tips

MacのセットアップでなぜかiPhoneのパスコードが求められる理由

Macのセットアップ中になぜかiPhoneのパスコードが求められました。iCloudのパスワードを聞かれるのはわかるのですが、なんで別のデバイスのパスコードが求められるのだろう?と疑問でした。色々調査して私なりの結論に至りましたのでご説明します。

Macのセットアップ中にiPhoneのパスコード?

M2 Macbook Air(2022)を購入し、セットアップをしていました。ちなみにOSは13.0です。ちょうどiCloudの設定の後だったと思います。

正確な表現を覚えていないのと、当方、言語を英語に設定していたのですが、日本語だとおそらく次の記事にあるものと同じものだと思います。

【iOS11】「ほかのiPhoneのパスコードを入力」に何を入力すれば良いの?について

ほかのiPhoneのパスコードを入力

iPhone〇〇のロック解除に使用するパスコードを入力してください。

Apple ID、保存済みパスワード、iCloudに保存されたその他のデータはこのパスコードによって保護されています。パスコードは暗号化されるためAppleが読み取ることはできません。

このようなプロンプトが表示されました。

これを見て非常に不可解な気持ちになりました。なんで、Macの設定をしているのに、iPhoneのパスコードが必要なんだろう。ウィルスにかかって、なんかのフィッシング詐欺でパスコードを不正に入手しようとされているのではないか?という疑念が湧きました。

また、仮に詐欺ではなくAppleの正規のプロセスだったとしても、なんでAppleにiPhoneのパスコードを渡さないといけないのだろうか?と思ってしまいました。

でも、早くMacを使いたかったので、流れに任せてiPhoneのパスコードを入力して先に進めてしまいました。

わからないことがあるとモヤモヤしてしまうタイプなので、後日じっくり時間をかけて調べることにしました。

なお、この事象はiCloudとAppleデバイスの全般で起こり得るので、

  • iPhoneの設定中に他のiPhoneのパスコードが求められる
  • iPhoneの設定中にMacのパスワードが求められる

などの事象も同じです。

ここからはネットで調べたのとAppleのサポートに問い合わせた結果からの私の推察にはなりますが、一応自分的には納得が行きました。とはいえ、Appleはセキュリティ周りの詳細はふわっとしか公表していないので、あくまで推察となるのをご了承ください。

結論から言っちゃいます

これが一番可能性が高い気がしています。

iCloudキーチェーンの復旧のプロセスが実行されていると思われます。公式ページの以下の部分で、

キーチェーンを復旧するには、ユーザが iCloud アカウントとパスワードで本人確認をし、登録済みの電話番号に送信された SMS に反応する必要があります。認証と反応を済ませたら、今度はデバイスのパスコードの入力が必要です。

パスキーのセキュリティについてより

デバイスのパスコードの入力が必要とあります。このデバイスが、iCloudキーチェーンを有効化したデバイスを意味するようです。

iCloudのエンドツーエンドの暗号化を開始するには、「暗号化キー」というのが必要になるのですが、暗号化キー自体もiCloudキーチェーンで管理されています。

なので、iCloudキーチェーンの利用を開始するには、通常のプロセスではなく抜け穴が必要になると推察されますが、それがこのiCloudキーチェーンの復旧のプロセスです。

このプロセスで、デバイスのパスコードが必要になる仕組みは、以下となります。ここは後述する理由で、「iCloudセキュリティコード」を「デバイスのパスコード」と置き換えて読んでください。

HSMクラスタはSRP(Secure Remote Password)プロトコルを使用して、ユーザがiCloudセキュリティコードを知っていることを確認します。コード自体はAppleに送信されません。クラスタの各メンバーは、ユーザがレコードを取得する際に許容される最大試行回数(後述)を超えていないことをそれぞれで確認します。超えていないという判断で過半数が一致した場合は、エスクローレコードがアンラップされ、レコードがユーザのデバイスに送信されます。

次に、デバイスがiCloudセキュリティコードを使用して、ユーザのキーチェーンの暗号化に使用したランダムな鍵をアンラップします。その鍵を使って、iCloudのキー値ストレージとCloudKitから取得されたキーチェーンが復号され、デバイス上に復元されます。

iCloudキーチェーンエスクローのセキュリティより

ポイントは、「コード自体はAppleに送信されません。」ということです。なので、Appleにパスコードを管理されてしまうのかな、とか、パスコードをネットを通じて送信するのは嫌だな、のような心配があって抵抗があった方は安心していいでしょう。

これが最終的に至った結論なのですが、その考えに至るまでの経過を以下に残しておきます。

私が私であることの確認ならiCloudのパスワードだけでいいじゃん

このプロンプトが私が私であることの確認をしたいだけなら、iCloudのIDとパスワードだけでできますよね。

また、パスワードが第三者に流出したり推測されたりするのを恐れるのであれば、2ファクタ認証の確認をすればいいです。

Apple ID の 2 ファクタ認証

それらで足りず、なぜ別デバイスであるiPhoneのパスコードを求めるのだろう?私が私であることの確認以上の目的があるんだろうと思いました。

ちなみに、上記のページに、以下のようにあります。

新しいデバイスや Web で確認コードを入力すると、サインインしているデバイスを本人が信頼したという確認になります。エンドツーエンドで暗号化され、iCloud に保存されているコンテンツにアクセスする際は、デバイスのパスコードの入力も別途求められる場合があります。

デバイスのパスコードの入力について触れられているんですよね。でも理由については全く説明がありません。

エンドツーエンドの同期を実現するため?

調べていくと、エンドツーエンド(end-to-end)の暗号化を実現するために、iPhoneのパスコードが求められたのではないかと思えてきました。以下の記事(英語)などが参考になりました。

Why Apple Asks for Your Passcode or Password with a New Login (and Why It’s Safe)

iCloudでは近年、情報の種類によっては実際のデータをApple側のサーバーには保存せずに、暗号化された情報しか保存しないようになっています。デバイスにある暗号化キーでしか復号化できないようになっています。このおかげで、Appleのサーバーがハッキングされて情報が流出したとしても、暗号化されたものしか流出しないので、私達の情報は守られます。また、仮に警察などの政府がAppleに特定の人物のデータを出せと要求したとしても、Appleは暗号化したデータしか出せないことになります。これをエンドツーエンドの暗号化と呼びます。「エンド」というのはMacやiPhoneなどの「デバイス」のことです。なので、デバイスからデバイスの間はずっとデータは暗号化されていて、デバイスに到着してようやく復号化されるということです。デバイスとデバイスの間に入るサーバーには暗号化されたデータしか残らない、という意味です。

Appleのサーバーはストレージというよりも同期サービスとして働くということです。とはいえ、iCloudを使う情報の全てがエンドツーエンドになるわけではなく、項目によります。例えば、iCloudキーチェーンはエンドツーエンドの暗号化の代表です。対象は以下の公式ページに詳しく説明されています。

iCloud のデータセキュリティの概要

このページを読むとわかるのですが、暗号化キーというのがあり、それが無いと暗号化されたデータは復号化できないようです。エンドツーエンドの暗号化の場合は、この暗号化キーがデバイスにしかありません。エンドツーエンドでは無い場合は、Appleのサーバーにも暗号化キーが保管されているということです。

文脈的にこの「暗号化キー」は復号に使われているので「復号キー」と呼ぶべきな気がします。英語版ページにも「encryption key」となっているのですが、同じく「decryption key」にした方がいいと思いました。とはいえ、公式ページの通りこの記事でも暗号化キーと呼びます。

暗号化キーをどうやって新参のデバイスに移動するかがポイント

この暗号化キー、エンドツーエンドの暗号化の場合は、デバイスにしか配置されていないということです。なので、新しいデバイスを同じiCloudアカウントに追加した場合、既存のデバイスにある暗号化キーを新参のデバイスに持ってくる必要があります。

それはそうですよね。鍵って同じものですもんね。同じ家に同居している家族なら、全員同じ鍵を持っているのと同じことです。

どうやって暗号化キーを新参のデバイスに持ってくるか、これが問題になります。公式ページの以下の部分には、

秘密鍵を含むサービスキーのペアは、ユーザの信頼できるデバイス上でローカルに作成され、iCloudキーチェーンのセキュリティを使用してユーザのほかのデバイスに転送されます。iCloudキーチェーンの復元と同期のフローはAppleのサーバによって仲介されますが、暗号化により、Appleのサーバがユーザのキーチェーンデータにアクセスすることはできません。

iCloudの暗号化より

とあります。

「iCloudキーチェーンのセキュリティを使用して」というのが不可解です。iCloudキーチェーン自体がこの暗号化キーで復号化する対象のはずなのに。ちょっとここがわわからなかったので、一旦無視します。

ただ、Appleのサーバーは中継するのは間違いないようです。

エンドツーエンドの暗号化の場合、Appleのサーバーは暗号化キーを保持しないのが前提です。では、どうやって暗号化キーを端末間で移行するのでしょうか。

この暗号化キーはおそらく既存のデバイスのパスコードで暗号化されている状態でAppleのサーバーに保管されていると推察します。生の暗号化キーは保管していないので、一応前提を崩していません。

なので、新しい端末ではAppleのサーバーから「既存のデバイスのパスコードで暗号化された暗号化キー」から落としてきて、当該のプロンプトが表示されます。そして、ユーザーが既存のデバイスの正しいパスコードを入力すると、正常な暗号化キーが新しい端末に配置され、エンドツーエンドの暗号化に参加することができるということだと考えます。

サービスごとに暗号化キーは違うってことか

一通りの流れは説明できたと思いますが、一つ疑問が生まれます。

細かい話になりますが、エンドツーエンドの暗号化の対象にならないサービスについては生の暗号化キーをAppleのサーバに保管していると前述しました。

では、Appleのサーバーからその生の暗号化キーが流出したら、どうなるのでしょうか?エンドツーエンドの対象のサービスのデータが復号化されてしまうのでは無いでしょうか?

ここまで考えて、思い至ったのが、あっ、サービスごとに暗号化キーは違うんだろうなということです。

あと、非エンドツーエンドサービスの生の暗号化キーと、エンドツーエンドサービスの暗号化された暗号化キーが両方流出した場合、後者の暗号化に使ったデバイスのパスコードを類推されちゃうかもなという疑問も出ました。

でも、サービスの暗号化キーごとに乱数も交えて生成してあるだろうからそれも大丈夫だろうと思えました。

このプロンプトで入力するパスコードは変えられない

ここまでお話しした仕組みからわかるように、このプロンプトで求められるパスコードは、最初にiCloudのエンドツーエンドの暗号化を使い始めた端末ということになります。

その使い始めた時に、暗号化キーを生成し、それをその端末のパスコードで暗号化し、Appleのサーバーに送り暗号化された状態で保管されます。

仮に、その後、何らかの理由でiPhoneのパスコードを変更した場合も、Appleのサーバーに保管された暗号化キーは、変更前のパスコードで暗号化されていることになります。

なので、この時点で新しいAppleのデバイスを購入し、iCloudにサインインすると求められるパスコードは、変更前のものということになります。

つまり、変更前のパスコードも忘れてはならないということになります。そうすると、変更する意味が無いので、デバイスのパスコードは安易に変えないことがおすすめになります。

どうしてもパスコードが思い出せない場合

パスコードを忘れてしまった場合、このプロンプトをスキップすればiCloudは一応使えます。ただし、エンドツーエンドの暗号化対象になっているサービスは使えないそうです。

その状態でエンドツーエンドの暗号化を使いたくなった場合、リセットすることができるようです。ただ、リセットすると、エンドツーエンドのサービスに保存されていたデータは破棄されてしまうとのことです。

キーチェーンの復旧のプロセスを利用しているだけか?

ここまで書いていて、やはり先程の無視した以下の部分が気になりもっと調べることにしました。

秘密鍵を含むサービスキーのペアは、ユーザの信頼できるデバイス上でローカルに作成され、iCloudキーチェーンのセキュリティを使用してユーザのほかのデバイスに転送されます。iCloudキーチェーンの復元と同期のフローはAppleのサーバによって仲介されますが、暗号化により、Appleのサーバがユーザのキーチェーンデータにアクセスすることはできません。

iCloudの暗号化より

「iCloudキーチェーンのセキュリティを使用して」とありますが、iCloudキーチェーン自体がこの暗号化キーで復号化する対象のはずなので矛盾しているように読めるんですよね。

でも、公式ページの「復旧のセキュリティ」という部分に

キーチェーンを復旧するには、ユーザが iCloud アカウントとパスワードで本人確認をし、登録済みの電話番号に送信された SMS に反応する必要があります。認証と反応を済ませたら、今度はデバイスのパスコードの入力が必要です。

パスキーのセキュリティについてより

とあります。まさにここにデバイスのパスコードの入力が必要って書いてあるんですよね。

iCloudのサービスは基本的にはエンドツーエンドでキーチェーンで管理される暗号化キーによって使うことができますが、キーチェーンだけは「復旧」という抜け穴のようなものがありこのプロセスで利用が開始される、ということかもしれません。

なお、このページからリンクされる以下のページにも似たような表現があります。

キーチェーンを復元するには、ユーザがiCloudアカウントとパスワードで認証し、登録済みの電話番号に送信されるSMSに返信する必要があります。そのあと、ユーザはiCloudセキュリティコードを入力する必要があります。

iCloudキーチェーンエスクローのセキュリティより

ほとんど同じなのですが、前者は「デバイスのパスコード」、後者は「iCloudセキュリティコード」を入力する、と書いてあるんですよね。

ページの公開日は、前者は2022年06月14日、後者は2021年5月17日となっています。

私は、後者の更新が遅れているのではないかとにらんでいます。現在はiCloudセキュリティコードではなくデバイスのパスコードを使う仕様になっているのではないかと推察します。

この後者のページを詳しく読んでいくと、そもそもキーチェーンの復旧でデバイスのパスコードが必要となる仕組みが見えてきます。ここは先程の理由で、「iCloudセキュリティコード」を「デバイスのパスコード」と置き換えて読んでください。

HSMクラスタはSRP(Secure Remote Password)プロトコルを使用して、ユーザがiCloudセキュリティコードを知っていることを確認します。コード自体はAppleに送信されません。クラスタの各メンバーは、ユーザがレコードを取得する際に許容される最大試行回数(後述)を超えていないことをそれぞれで確認します。超えていないという判断で過半数が一致した場合は、エスクローレコードがアンラップされ、レコードがユーザのデバイスに送信されます。

次に、デバイスがiCloudセキュリティコードを使用して、ユーザのキーチェーンの暗号化に使用したランダムな鍵をアンラップします。その鍵を使って、iCloudのキー値ストレージとCloudKitから取得されたキーチェーンが復号され、デバイス上に復元されます。

iCloudキーチェーンエスクローのセキュリティより

「デバイスがiCloudセキュリティコードを使用して、ユーザのキーチェーンの暗号化に使用したランダムな鍵をアンラップします。」とあります。この「ランダムな鍵」はこれまで話してきた「暗号化キー」とは違うものだと推察します。暗号化キーの生成を説明したページにはランダムという感じではなく、一定の秩序があるような形で書かれています。

つまりユーザのキーチェーンは暗号化キーではなく、それ専用に生成された「ランダムな鍵」によって暗号化されているということのようです。

そして、Appleのサーバからデバイスに送られた暗号化されたキーチェーンが、このランダムな鍵で復号化され、使うことができるようになる、ということです。このランダムな鍵自体もデバイスのパスコードで暗号化されているので、デバイスのパスコードが求められるということです。

この「ランダムな鍵」が「暗号化キー」と同一だったとしても同じことです。上述したように、サービスごとに暗号化キーが違うのであれば、それ専用と言えると思います。

キーチェーンは、サーバー上に「ランダムな鍵」で暗号化されたものと、「暗号化キー」で暗号化されたものが両方ある可能性もあります。そうなるとデータが重複して色々と無駄が多いですが。

すごくシンプルに、「ランダムの鍵」は「暗号化キー」を意味していて、エンドツーエンドの暗号化の対象となる全てのサービスのそれぞれの「暗号化キー」は単縦にデバイスのパスコードで暗号化されてサーバーに保管されているだけの可能性もあるかもしれません。

とはいえ、細かい仕様は公表されていないので、わかりませんが、私が妄想したプロセスよりはこのキーチェーンの復旧プロセスを利用している可能性が高い気がします。

これなら暗号化キーを別デバイスに移動するのに「iCloudキーチェーンのセキュリティを使用して」に感じた矛盾は無くなります。キーチェーンの復旧プロセスはキーチェーンのセキュリティに含まれるので。

さいごに

以上が、私が色々調べて推察した、Macのセットアップ中にiPhoneのパスコードが求められた理由とその背後にある仕組みです。

とはいえ、私の中で辻褄が合うように推察しただけの単なる妄想かもしれないですが、参考になれば嬉しいです。