
2026/01/15 5:00
オフライン検索ネットワーク上でのデータ送信
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
概要:
Apple の Find My ネットワークは、Apple 装置が Bluetooth Low Energy(BLE)または Ultra‑Wideband(UWB)を介してブロードキャストするロールリング公開鍵にペイロードを乗せることで、潜伏型低帯域データチャネルへと変換できます。システムは各ブロードキャストをログし、ユーザーは近隣装置の暗号化レポートをアップロードします。リクエストごとに最大 256 個の鍵を照会することで、研究者は 28 バイト長のプライベートキー領域を復元でき、Reed–Solomon エラー訂正で各広告に 8〜16 ビットの情報を埋め込むことが可能です。このプロトコルは一方向のみです:ローカル BLE/UWB 接続を必要とするコマンド(音声再生やデバイス消去など)は Find My ネットワーク経由で送信できません(Key Point 4)。複数の伝送間で同期を取るために「メールボックス」メッセージが使用されます—特殊な鍵ペアがメッセージ開始を示すので、クライアントは事前知識なしに取得するデータを検出できます(Key Point 8)。
Apple の Finders は1日あたり約 48 kB のデータをアップロードし、期待されるダウンロードスループットは約 60 bits/s です。Google の Find Hub ネットワークも位置情報をクラウドソースしますが、より厳格な制限があります:登録済み EID のみ保存され、クエリはレートリミットされ、ステータスバイトは利用できません(Key Points 9–10)。これらの制御にもかかわらず、同じ BLE データ‑over‑key 技術は多くのデバイスを登録し、Google の GRPC サービス(DeleteBleDevice、ListEidsForBleDevices)を自動化して削除/リストアップすることで機能します(Key Point 10)。
この方法は低エネルギー消費、小規模コスト、高いステルス性を提供し、ESP32、Linux、nRF52、TI などのプラットフォーム間で潜伏データ転送に適しています。また、キーが高速回転するため Apple のアンチ・ストーカー警告をトリガーしません(Key Point 12)。
本文
プロジェクト概要 – Hudson H. & Andrew G.
目標
- Find My ネットワークは、AirTag、iPhone、AirPodsなどの10億台規模のデバイスを対象に、Bluetoothと超広帯域(UWB)を使って紛失したデバイスを位置特定し、Apple のサーバーへ報告するシステムです。
- Google が運営する別々の Find Hub ネットワークも同様に、Android デバイス向けにクラウドソースデータを利用しています。
調査課題
- 紛失したデバイスが通信できない場合、位置情報はどのように報告されるか?
- 情報を紛失デバイスへ送信することは可能か?
- Apple と Google はそれぞれネットワーク(ストーキングアラート・ユーザー個人情報)をどの程度厳格に管理しているか?
究極的な疑問
- 任意の Bluetooth デバイスがこれらのネットワークを無料で位置特定に利用できるか?
- 安全な通信チャネルを確立することは可能か?
抽象(Abstract)
本プロジェクトでは、オフライン検索ネットワーク上で任意データを送受信する方法を示します。
カスタムプロトコルにより、Apple の Find My と Google の Find Hub それぞれの違いを明らかにしつつ、サードパーティ製デバイスが両方に乗っ取り可能な堅牢で移植性・安全性の高い一方向通信チャネルを構築します。
Find My プロトコル
| フェーズ | 主なポイント |
|---|---|
| ペアリング | ECC(楕円曲線暗号)により公開鍵/秘密鍵/対称鍵が生成されます。デバイスは対称鍵と公開鍵のみを保持し、iCloud キーチェーンには秘密鍵が保管されます。 |
| 紛失 | デバイスが紛失した際、BLE を介して 28 バイトのロールリング公開鍵(24 時間ごとに更新)をブロードキャストします。鍵の一部は MAC アドレスにエンコードされており、ランダム/静的/NRPA など任意のビーコンタイプで機能します。ステータスバイトはユーザーが自由に設定できます。 |
| 検索 | Apple デバイス(“Finders”)は有効なビーコンを検出し、自身の位置情報を暗号化したパケットを作成して公開鍵とともに Apple にアップロードします。Apple はこれらの報告を Find My アプリで集約します。 |
| 取得 | ユーザーは時間窓内の予測ロールリングキーを算出し、SHA256 ハッシュを用いて Apple のサーバ(キーバリューストア)へクエリします。1 回のリクエストで最大 256 個の鍵を検索でき、各鍵に対して最大 20 件の報告が返されます。報告は 7 日間保存されます。 |
結論
- 双方向通信 – ローカル BLE/UWB 接続のみでコマンド(例:音声再生)を送ることができます。ネットワーク経由の遠隔双方向制御は不可能です。
- ユーザー個人情報 – 報告データはエンドツーエンド暗号化され、秘密鍵でのみ復号可能です。Finders は Apple の署名を用いて認証しますが、Apple ID を明らかにしません。
- 認証の欠如 – 形式に合致する任意の BLE ビーコンは受理されるため、紛失デバイスが正当な Apple デバイスであることを確認できません。
- ストーキングアラート – 同一公開鍵が 24 時間継続(10 分間で 840 m)しているとトリガされます。ステータスバイトに Apple/Find‑My と示す値が設定されていたり、鍵が頻繁に変わる場合はアラートが失敗します。
データ転送
| ツール | 機能 | 制限 |
|---|---|---|
| OpenHaystack | AirTag のブロードキャストをエミュレートし、静的公開鍵の送信を確認。 | Ubertooth が必要で、報告取得は ESP32 でのみ可能。 |
| Send My (Positive Security) | Find My ネットワーク経由で POC データを送信。 | 広告あたり 1 ビット、ESP32 限定、MacBook 必須、ペイロードは暗号化されずステータスバイトが露出。 |
プロトコルアップグレード
- ペイロードを公開鍵ではなく秘密鍵に格納し、各チャンクを新しい ECC 鍵対で構成。
- スキーマ例:
- 4 バイト – チャンクインデックス
- 2 バイト – メッセージ ID
- 20 バイト – デバイス ID(共有シークレット)
- 2 バイト – データビット(広告あたり n ビット、ステータスバイトを含め最大 16 ビット)。
- クライアントは n ビットだけをブルートフォースし、公開鍵のハッシュを生成して Apple にクエリ。
- 誤り訂正 – Reed–Solomon ブロックで ≥80 % のチャンクが受信された場合に復元可能。
同期
- デバイスは各メッセージ前に 2 通の “sync” パケット(メッセージ ID=0)を送信。
- クライアントはレイヤー 1 とレイヤー 2 の同期チャンネルをスキャンし、新規メッセージを検出、内容をクエリ。
- 連続チャンク失敗が起きたらメッセージ終了と判断。
スループット
- Apple Finder は約 15 分ごとに 512 バイトのアップロードを行い、追加データ 500 バイトごとに約 15 分の遅延。
- 最大スループットは広告保存後で ≈60 ビット/秒。
ポータビリティ
| プラットフォーム | アプローチ |
|---|---|
| ESP32 | VHCI(UART 上 HCI)を使用して BLE 広告を作成。 |
| Linux | 原始 HCI ソケットで root 権限で実行。 |
| nRF52‑DK | Zephyr RTOS のネイティブ HCI API を利用。 |
| TI デバイス | PlatformIO → CCS IDE → TI SDK、カスタム CMakeLists でフラッシュ。 |
全プラットフォームは共通のハードウェア抽象化層(HAL)を介して生 HCI パケットを送信し、デバイス間で BLE 広告構築が一貫します。
Google Find Hub
-
Find My との違い
- 登録済みデバイスの鍵のみ保存。
- ユーザーは自分のトラッカーだけをクエリ。
- 厳しいレート制限、ステータスバイトなし。
-
Find Hub ツール –
は GRPC サービス(例:DeleteBleDevice, ListEidsForBleDevices)の protobuf を提供。GoogleFindMyTools -
データ転送 – 各チャンクは推測鍵でデバイス登録が必要、典型的に n = 2 ビット/鍵。
-
自動化 – バルクデバイス登録(約 100 件/バーナーアカウント)と
による削除。DeleteBleDevice -
Tor ブロック – Google は Tor exit ノードをブロック;直接接続へ切替。
デプロイメントシナリオ
- キーロガ、音声→テキストレコーダー、パッシブ BLE/WiFi スニファー、画像転送(圧縮 JPEG + ZIP)、その他組み込みデバイス。
- 両ネットワークを併用:Apple を主スループットとし、Google は冗長性やバックアップとして活用。
セキュリティ FAQ
| 質問 | 回答 |
|---|---|
| サードパーティがペイロードを見ることはできるか? | ペイロードは ECC 秘密鍵であり、BLE 広告の公開鍵は逆算不可。ステータスバイト(8 ビット)はスニファ可能だが無効化可。 |
| リプレイ攻撃はあるか? | 攻撃者が偽のステータスバイトを持つビーコンを再送すれば可能。ただし、ステータスバイト無効化やデータレート低減で緩和。 |
| ストーキングアラートはトリガされるか? | キーが頻繁に変わり 24 時間同一鍵を保持しないため、通常は発生しません。 |
| 攻撃者がデータクエリできるか? | 20 バイトの共有シークレット(デバイス ID)を知っている場合のみ。 |
| 実際の AirTag と競合するか? | キースペースは十分大きく、報告は 1 週間だけ保存されるため問題なし。 |
| 個人情報への関連付けは可能か? | バーナーアカウントを使用し、Apple は復号できず Google はスパムとみなす場合があるが、トレーサビリティは低い。 |
参考資料
- OpenHaystack ツール
- Who Can Find My Device?
- Positive Security’s Send My
- FindMy.py ライブラリ
- Who Tracks the Trackers?(Apple アラート迂回)
- Track You: A Deep Dive into Safety Alerts for Apple AirTags
- ESP32 HCI 構造ガイド
- iPhone vs Android ユーザー統計(2025 データ)
- Okay Google, Where’s My Tracker?(Google Find Hub 評価)
- TagAlong – 無料広域データ転送サービス
- Where Is My Tag? – Apple FindMy の代替用途
- AirGuard – Android ユーザーを Apple ストーキング攻撃から保護
- 「ユーザーセキュリティとプライバシーを重視した新 Find Hub ネットワーク構築」
- Android で新 Find My デバイスを活用する 5 通りの方法
結論
- Apple の Find My と Google の Find Hub 上で一方向、低ビットレートデータ転送は実現可能です。
- カスタム ECC ベースプロトコル、Reed–Solomon 誤り訂正、およびオフバンド同期により、約 60 ビット/秒の堅牢なメッセージ配信が達成されます。
- この手法は隠密性を保ちつつ、多数のハードウェアプラットフォームで移植可能であり、既存のストーキング防止機構を回避しながらユーザー個人情報を尊重します。