Apple

Appleの「探す」、Linuxからでも位置共有データを受信できた。22歳の研究者が実証

Appleが自社デバイスに限定してきた「探す」アプリの位置共有機能を、LinuxマシンでもAppleのネットワークに登録して受信・復号できることをセキュリティ研究者が実証した。

岬徹

2026年8月21日 09:4500

Appleだけの機能をLinuxでも

Appleの「探す」アプリには、家族や友人と互いの現在地をリアルタイムで共有する「人を探す」機能がある。AirTagやiPhoneの所在を探す機能とは別に、相手が許可すれば地図上にその人の居場所が表示される。

この機能はAppleデバイス同士でしか使えない。iCloudのWebサイトにもFind Devices（デバイスを探す）はあるが、「人を探す」には対応していない。Appleアカウントを持っていても、位置共有を受け取るにはiPhoneかMacが必要になる。

ゼロティスティック（Zerotistic）氏は、LinuxマシンをAppleの内部ネットワークに登録し、この制限を突破した。友人がすでに共有していた位置情報を、Linuxから暗号化データとして受信し、復号して座標・タイムスタンプ・精度情報を読み取ることに成功している。

重要な前提がある。これは任意のAppleユーザーの位置を盗み取る攻撃ではない。対象は「そのAppleアカウントの持ち主にすでに位置共有を許可している人」の位置データに限られる。自分のアカウントにログインし、相手が承諾済みの共有データを受け取っているだけで、共有関係のない第三者の位置は取得できない。

SHA-1とXMLが残っていた

ゼロティスティック氏はHiddenLayer所属の22歳の脆弱性研究者で、CTF（Capture The Flag）チームProjectSekaiおよびFriendly Maltese CitizensのメンバーとしてDEF CON 2024/2025のファイナリストでもある。手元にMacがなかったため、既存のオープンソースクライアントとAppleデーモンの逆コンパイル結果を手がかりに、1週間足らずで全工程を完成させた。

最初のハードルは、LinuxマシンをAppleのIDS（Apple Identity Services、デバイス間の暗号化メッセージ基盤）に正規のデバイスとして登録することだった。

Appleの標準認証プロトコルであるGrandSlamを経由してログインし、IDSのデバイス証明書を取得する。そのために証明書署名要求（CSR）をAppleのauthenticateDSエンドポイントに送るのだが、ここで試行錯誤が発生した。

CSRはSHA-1署名のPKCS#10形式でなければ受け付けられなかった。鍵は2048ビットRSA。しかもリクエスト全体をXML形式のplistにしてgzip圧縮する必要がある。SHA-256で署名してもエラーコード6001が返るだけだった。

ゼロティスティック氏はブログで、この仕様が残っている理由について、authenticateDSがレガシーなエンドポイントだからだろうと推測している。プロトコルバージョンとして「1660」を名乗る古いインフラが、いまも現役で動いている。

SHA-1は2017年にGoogleとCWIアムステルダムが現実的な衝突攻撃を実証して以降、暗号署名の用途では廃止が進んでいるハッシュ関数だ。Appleの内部プロトコルにSHA-1署名の要件が残っていたことは、このシステムの古さを示している。

6つのサブサービスと2層の暗号化

IDS証明書の取得だけでは終わらない。「探す」がこのデバイスを受信可能だと認識するには、さらに6つのサブサービスへの購読、対応する暗号化方式の宣言、NGM v13（Appleのデバイス間メッセージフォーマット）の公開鍵の提供が必要だった。すべてをIDS証明書とAPNs（Apple Push Notification service、Appleのプッシュ通知基盤）証明書で署名し、XML plistをgzip圧縮した上で送信する。

LinuxからAppleの位置共有データを取得するまで

※各段階でAppleの内部プロトコルに準拠した認証・署名・暗号処理が必要

ここまでで、LinuxマシンはAppleアカウントに紐づいたIDSデバイスとして登録され、APNsへの持続的なTLS接続を確立した状態になる。

しかし、新品のAppleデバイスのように、登録しただけで既存の位置共有データが自動的に届くわけではなかった。ゼロティスティック氏がSubscribeAndFetchリクエストを発行して初めて、友人のデバイスから暗号化された位置鍵が配信された。

位置データの暗号化は2つの層で構成されている。まず、NGM（P-256楕円曲線）がデバイス間の鍵ハンドオフを保護する。そしてSearchPartyサービスが返す位置レポートは、個別の共有鍵（P-224楕円曲線）で暗号化されている。NGMのP-256とSearchPartyのP-224は別のレイヤーであり、ゼロティスティック氏自身も当初はP-256だと思い込んでいたという。

最終的に、受信した暗号データからAppleのメッセージングエンベロープを解除し、共有位置鍵を抽出し、ECDH鍵交換とX9.63 SHA-256鍵導出を経てAES-GCMで復号するスクリプトを書き上げた。復号されたデータには座標、タイムスタンプ、精度情報が含まれている。

動機は「Discordに通知を飛ばしたかった」

研究の出発点は極めて日常的だった。友人と互いの位置を「探す」で共有していたゼロティスティック氏が、友人の許可を得た上で、特定の場所に着いたらDiscordに通知を送る自動化を作ろうとした。あらかじめ地図上に仮想的な境界線（ジオフェンス）を引いておき、そこへの出入りで通知が飛ぶようにする。iCloudのWeb APIでは自分のデバイスの位置は取得できたが、「人を探す」のデータは返ってこなかった。先行事例を探しても、Linuxからの完全な実現例はなかったという。

ゼロティスティック氏のブログ記事には、認証の各段階で使用したリクエスト構造、暗号化パラメータ、参照したオープンソースプロジェクト（FindMy.py、pypush、rustpush）のコード箇所が詳細に記録されている。

Appleの囲い込みに空いた穴

The Registerが報じたところでは、Appleにこの研究について対応予定があるかコメントを求めたが、回答はなかったという。

この研究が示しているのは、Appleのプロトコル上、デバイスの種別を検証する仕組みが暗号的な鍵の所持に依存しており、実際のハードウェアがApple製かどうかを判別していないということだ。認証手順とフォーマットさえ合っていれば、LinuxもApple端末として通る。

セキュリティ上の実害は限定的だ。攻撃者が他人のAppleアカウントの認証情報を持っていなければ成立しない。一方で、位置共有をAppleデバイスに限定する理由がプライバシーの保護にあるのか、エコシステムの囲い込みにあるのかについて、今回の研究は一つの材料を提示した。技術的にはAppleデバイスである必要がないにもかかわらず、その制限は維持されている。

SHA-1署名の要件が残るレガシーエンドポイントも含めて、Appleの内部プロトコルの古い層が、外部からの解析で露わになった。Appleがこの研究を受けて何らかの変更を加えるのか、あるいはこのまま放置するのかは分からない。位置共有を承諾した相手のデータを、承諾された本人が別のデバイスから見ているだけだという事実は、Appleにとって対処の優先度を下げる理由になりうる。