Appleの「探す」をLinuxで動かした研究者、暗号を破らず位置情報を受信

Zerotistic氏の実装は、通常は表に出てこないAppleの複数の仕組みをつないでいた。

1. アカウント認証：Appleのアカウントログインプロトコル「GrandSlam」を利用した。報告された手順では、Secure Remote Password（SRP）による交換と2要素認証を経て、アカウント識別子と短期間だけ有効なパスワード相当トークンを取得した。

2. デバイス登録：2048ビットRSA鍵とSHA-1署名を含むPKCS#10形式の証明書署名要求（CSR）を生成した。これをAppleの従来型プロファイル登録エンドポイント「authenticateDS」へ送信し、Apple Identity Servicesの証明書を受け取った。

3. IDSへの登録：証明書などのデバイス情報を使い、LinuxをIdentity Services（IDS）対応デバイスとして登録した。IDSはiMessageなどにも使われるAppleのメッセージング基盤で、実装は対応する暗号方式を申告し、必要なサブサービスを購読し、Apple Push Notification Service（APNs）の配信用認証情報も取得した。

4. 「探す」の同期：ネイティブクライアントが行う「探す」の初期化や更新処理を再現し、

   intent: distributeKeys

   、

   mode: proactive

   を指定したSubscribeAndFetchリクエストを送信した。するとAppleは、位置情報を共有している相手のデバイスに対し、IDSとAPNsを通じて、新たに登録されたIDへ現在の位置情報復号用鍵を送るよう指示した。

5. Linux側で復号：暗号化されたIDSペイロードには、共有関係を示す情報とSearchPartyの鍵素材が含まれていた。オープンソースのpypushがプッシュ通知とIDSの処理を担い、FindMy.pyが取得した「探す」のレポートを問い合わせて復号し、位置座標、時刻、精度情報に変換した。

これはAppleの証明書を偽造した攻撃ではない。アカウント認証と登録の手順を完了した後、サーバーから実際に認証情報が発行されている。

IDSのペイロードから見えた鍵の配布と更新

実証されたSubscribeAndFetchの挙動からは、Appleが、すでに共有関係が成立している相手に対して、新たに認証されたデバイスへ現在の位置情報用鍵を後から配布できることがうかがえる。新しいiPhoneや別のデバイスを追加するたびに、連絡先全員へ共有を停止・再開してもらう必要がないようにするには、こうした同期機能が必要になる。

報告されたペイロードには、共有関係の識別子、鍵のインデックス、32バイトのハッシュ化された広告用鍵、85バイトの秘密鍵表現が含まれていた。これらは、「探す」の位置情報レポートの復号が、共有関係と鍵のバージョンに紐づく情報に依存し、その現在の状態をIDS経由で再配布できることを示している。

一方、公開された技術解説から、鍵が必ず何時間ごと、何日ごとに更新されるのかという普遍的なローテーション間隔まで確定したわけではない。明らかになったのは現在の鍵状態がどのように同期・配布されるかであり、Appleの鍵管理スケジュール全体ではない。

できたこと、できなかったこと

検証されたクライアントの機能は意図的に限定されていた。研究者のApple Accountですでに受け入れ済みとなっている位置情報共有を読み取り、復号したデータをLinux上で処理できた。位置情報のジオフェンス判定もApple側ではなく、復号後にローカルで実行された。

技術解説によれば、次の機能は備えていなかった。

• 新たな位置情報共有の招待を送る
• 既存の共有権限を変更する
• ファミリー共有のメンバーを追加する
• Apple側でジオフェンスを作成する
• デバイスへの操作命令を発行する

したがって、これは遠隔から任意の人物を追跡できる脆弱性というより、相互運用性と信頼境界に関する発見と見るのが適切だ。より現実的な懸念は、Apple Accountや信頼済みデバイスが侵害された場合に、そのアカウントがすでに閲覧できる位置情報共有が流出する可能性だ。

2025年のnRootTag研究との違い

Zerotistic氏の実証とnRootTagは、同じ「探す」に関係していても、対象となる仕組みと脅威モデルが異なる。

Zerotistic氏の研究は「人を探す」が対象だ。 既存の、本人が許可した位置情報共有の受信側を再現したもので、Appleにアカウントとデバイスが受け入れられている必要がある。また、相手の位置情報がそのアカウントに共有されていなければならない。

nRootTagは「探すネットワーク」とオフライン探索が対象だった。 研究者らは、Appleのサービスが想定されていたランダム静的アドレス以外のBluetoothアドレス種別も受け入れることを報告した。この問題を利用すると、Bluetooth対応コンピューターをAirTagのような追跡ビーコンとして動作させ、近くにあるAppleデバイスに位置情報を中継させられる可能性がある。対象デバイスの所有者の同意は必要とされない。

要するに、Zerotistic氏のプロジェクトは「アカウントがすでに閲覧を許可されているデータを受信する」ものだったのに対し、nRootTagは「許可なく追跡するための仕組みを作る」ことを目指した。両者を混同すると、今回のLinux実証を実際以上に強力なものと誤解してしまう。

当初の目的と、想定を超えた開発規模

発端は、同意に基づく自動化だった。すでに位置情報を共有していた友人の了承を得たうえで、Linuxシステムがローカルのジオフェンスを管理し、特定の場所への到着・退出時にDiscordへ通知する仕組みを作ろうとしたという。

Zerotistic氏は当初、認証済みのWebリクエストを組み立てれば済むと考え、作業時間を「一晩ほど」と見積もっていた。しかし実際のリバースエンジニアリングは、その予想を大きく超えて広がった。公開されている報告からは、完成までにかかった正確な総時間は確認できないため、より具体的な期間を断定することはできない。

Appleの対応は？

引用されている報道はLinuxからの実証と、その限定された範囲を確認しているが、この特定の「探す」実装についてAppleが公に説明したこと、修正を確認したこと、報奨金の結果を開示したことまでは示していない。

今回の研究が示す教訓は明快だ。ある機能をApple製ハードウェアに限定して提供していても、ハードウェア自体が必ずしもセキュリティ境界になるとは限らない。サーバー側が主に認証情報、証明書、対応機能、プロトコル上の振る舞いを根拠に信頼を与える設計なら、十分に互換性のある別OSのクライアントが製品上の境界を越える可能性がある。

ただし、そのクライアントが取得できるのは、アカウントの権限と正規に受け取った暗号鍵が許す範囲に限られる。今回のケースは、暗号を破った話ではなく、Appleの「対応機器」という製品上の制限と、サーバーが実際に信頼を判断する仕組みの間に、ずれが存在していたことを示したものだ。