私たちは、リークの多い Apple Find My を通じて、iPhone から悪いものをすべてドラッグします。

Apple の AirTags テクノロジーが最近リリースされた後、「探す」オフライン検索システムを悪用して、WiFi またはモバイル インターネットに接続されていないデバイスから任意のデータをインターネットにアップロードできないかと考えました。このデータは、Bluetooth Low Energy を介してブロードキャストされ、近くの Apple デバイスによって取得される可能性があります。これらのデバイスは、インターネットに接続するとすぐにこのデータを Apple サーバーに転送し、後で取得できるようにします。このような技術は、モバイルインターネットを使用して余分なエネルギーを無駄にしないように、制御されていない環境の小さなセンサーで使用できます。さらに、ファラデー ケージで保護された場所からデータを盗むと、iPhone を持っている人がそこに目を向けるだけで面白いかもしれません。 



理論的には、これは可能です。2 つの AirTags をエミュレートできれば、一度に 1 つだけをアクティブにすることでデータをエンコードできます。この場合、受信側デバイスは、どの AirTag がいつアクティブだったかを確認し、データをデコードして元の形式に戻す必要があります。ただし、そのようなスキームは非常に信頼性が低いようであり、データ送信帯域幅が非常に狭いため、おそらく実際の実際の状況での使用には適していません (特に、Apple ID での 16 AirTagの制限を考慮に入れると、  データの量は転送は 1 時間あたり数ビットを超えることはできません)。



したがって、このアイデアの実現可能性は、システムがどのように設計および実装されるかに依存します。オフラインの仕組みを設計する際にセキュリティとプライバシーを確​​保するという決定は、私たちが提案したケースが侵入の方法として非常に効果的であることを示しており、それを防御することはほとんど不可能であることがわかりました。





‍結果: 専用の Mac アプリを使用して、以前に転送/ダウンロードしたデータを抽出します。

• あなたはできる任意のデータをダウンロードするから 、インターネットに接続されていないデバイスBLE（Bluetoothの低エネルギー）技術を介して、私のメッセージを探すブロードキャストすることによって 近くのAppleデバイスに、その後あなたのためのデータをダウンロードします
•  ESP32, ( )  macOS, , : https://github.com/positive-security/send-my
• ,   - Find My,  ,  

モデムの検索 (ESP32) //



近くの Apple デバイス // 近くの Apple



Mobile Tower または Wifi アクセス ポイント // セル タワーまたは Wifi アクセス ポイント



macOS デバイスとデータ取得アプリ // データ取得アプリを備えた macOS デバイス



データフロー // データフロー



.

オフライン検索ネットワークの説明

幸いなことに、このプロトコルは、ダルムシュタット工科大学の研究者グループによってすでに大部分がリバース エンジニアリングされており、 「誰が私の デバイスを見つけることができ ますか?「2021 年 3 月に、概念実証のためにOpenHaystack のオープン ソース実装を  リリースしました。この実装により、Apple Find My ネットワークで追跡される独自のコンポーネントを作成できます。このチームに感謝します！私たちの仕事が実現できたのは彼らのおかげであり、ファームウェア (概念実証のためにも行われました) と Mac アプリの両方が OpenHaystack に基づいています。



少し簡略化した形式で、Find My オフライン検索システムの原理は次のとおりです。

1. AirTag Apple, , , AirTag ( )
2. 2 AirTag Bluetooth, , ( 15 )
3. , , .., Find My, , (  ECIES)  
4. デバイスを検索するとき、ペアリングされた所有者のデバイスは、AirTag が最近使用したはずの交換可能な公開鍵のリストを生成し、Apple に SHA256 ハッシュを要求します。Apple バックエンドは、ID が要求されたキーの暗号化されたロケーション レポートを返します。 
5. 所有者のデバイスは、位置レポートをデコードし、おおよその位置を出力します。 

Apple のサーバー // Apple サーバー



Finder デバイス // デバイスの検索 



所有者のデバイス // 所有者のデバイス



紛失したデバイス // 紛失したデバイス

1. // 初期設定時のペアリング
2. // ブロードキャストします。Bluetooth 公開鍵のプレゼンテーション
3. // 暗号化された位置レポートをダウンロード
4. // ロケーション レポートをダウンロードして復号化する

図。1. オフラインでデバイスを見つけたときに解決されるタスクの簡略化されたフロー図 



この非常に美しいデザインには、特に次の特徴的なセキュリティ プロパティがあります。

• 取り外し可能な公開鍵による近くの攻撃者に対する追跡保護 
• Apple ユーザーの位置を特定できない 

ただし、この場合の私たちにとって最も興味深いのは、Apple はどの公開鍵が AirTag に属しているか、したがって、どのロケーション レポートがあなたに宛てられているかを知りません。したがって、特定のキー ID のロケーション レポートを要求するエンドポイントは、承認を実行しません (ただし、エンドポイントにアクセスするには、Apple ID で認証する必要があります)。 



すべてのセキュリティは、位置レポートの暗号化のレベルで保証されます: 位置は正しい秘密鍵でのみ復号化でき、ペアになっている所有者のデバイスにのみ保存され、単純なブルートフォースでそれを拾うことは不可能です攻撃。

データ盗難プロトコルの設計 

これは、データの暗号化に使用できる唯一の媒体がブロードキャスト EC 公開鍵であることを示唆しています (たとえば、「検索」デバイスが GPS 座標を追加するため、GPS 座標に影響を与えることはできません)。



次のセクションでは、Apple バックエンドを公開キー値の共有ストアと見なします。SHA256 ハッシュがキーとして使用され、暗号化された位置レポートが値として使用されます。さらに、主な操作は次のとおりです。

• 特定のハッシュの位置レポートが存在するかどうかを確認できますか SHA256 
• 対応する公開鍵をブロードキャストすることで、特定の SHA256 ハッシュに位置レポートを追加できます。 

すでにイベントの流れを理解していると思います。共有キーと値ストアに任意のビットを設定して、再度クエリを実行できます。送信者と受信者の両方がそのような暗号化方式に同意すると、それを使用して任意のデータを送信できます。



シリアル インターフェイスを介してメッセージを受け取り、新しいメッセージが受信されるまでそのデータをループするモデムを構築することにしました。 「0」ビットと設定されていないビットを区別できるようにするために、ビット値に応じて異なる公開鍵をブロードキャストし、受信者に両方の可能な公開鍵を照会します。



特定のブロードキャスト メッセージが位置レポートとして Apple バックエンドにアップロードされる時期 (またはあれば) についての保証はありません。ポイントは、一部のパケットが Apple デバイスに到達しない可能性があり、デバイスを検索する場合、ブロードキャスト メッセージの受信とロケーション レポートのダウンロードの間に非常にばらつきのある遅延が発生する可能性があることです。これは、アップストリーム接続または電力モードに依存する可能性があります。したがって、データ エンコーディングは、どの位置レポートがどの順序で到着するかに依存せず、部分的に受信したデータ ストリーム (一部のビットが完全に失われたもの) の回復も可能にする必要があります。これを実現するために、ブロードキャストごとに 1 ビットのデータを暗号化することに決めました。どのメッセージ ビットが設定されているか。追加のメッセージとモデム ID のおかげで、システムは複数のメッセージを処理する複数のユーザーによる複数の使用に適しています。



そこで、特定のビットを送信することで、「[4bビットインデックス] [4bメッセージID] [4bモデムID] [ゼロパディング...] [ビット値]」のように28バイトの配列を作成し、パブリックとして運用しますたとえば、「メッセージ 0 のビット 0 は 1」という情報をブロードキャストするためのキーと送信の表現 BLE。



完全なメッセージを送信するために、プログラムは単純にそのすべてのビットを繰り返し、その表現を公開鍵でビットに送信します。このビットのインデックスと値は暗号化されます。







エンコードするメッセージ // エンコードするメッセージ



ブロードキャストする 生成された公開キー // ブロードキャスト用に生成された公開キー



ビット インデックス // ビット インデックス



ビット値 // ビット値



 



メッセージ ビットをブロードキャスト ペイロードにエンコード



する データをフェッチするとき、受信側アプリケーションは同じ 28 を生成します-バイト配列 (ビットごとに 2 つ、可能なビット値は 0 と 1) で、これらの「公開キー」の SHA256 ハッシュを使用して Apple サービスを要求します。これらのキーの 1 つだけにロケーション レポートを添付する必要があります。これにより、解釈できます (たとえば、インデックス 0 のビットは 1 です)。







クエリする可能性のあるビット // クエリする可能性のあるビット



テストする可能性のある公開鍵 // テストする可能性のある公開鍵



クエリ Apple バックエンド // Apple



Decodeバックエンドの公開鍵の存在を元のデータにクエリ // によって公開鍵を復号化する生データの





取得 インターネットに接続された macOS デバイスから以前に送信されたデータを 取得します



注: メッセージごとに 1 ビットだけでなく、たとえば、公開鍵の最後の 8 ビットを含むバイト全体を送信することもできます。これにはより広いデータ送信帯域幅が必要ですが、受信者は 1 バイトを選択/ブルート フォースするために 255 の異なるキー ID を要求する必要があります (ビットごとのエンコードの場合の 16 キー ID と比較してください)。

実装

送信側

送信側では、まったく普通で安価なマイクロコントローラーである ESP32 を使用することにしました (簡単なテストでは、BT MAC アドレスを、たとえば Linux ベースの Raspberry Pi よりもはるかに速く変更できることが示されました)。起動時に、OpenHaystack ベースのファームウェアはハードコードされたデフォルト メッセージをブロードキャストし、シリアル インターフェイスを (ループとして) リッスンして、新しいブロードキャスト データが到着するかどうかを確認します。公開鍵をブロードキャストする場合、Bluetooth MAC アドレスの最初の 6 バイトで分割してエンコードする必要があります (Bluetooth 規格では最初の 2 ビットを 1 に設定する必要があるため、最初の 2 ビットを除くすべて)。私たちはあなたを参照します ダルムシュタット工科大学の記事のセクション 6.2 を参照してください。この自家製のエンコーディングについて詳しく説明しています。



BT 仕様で問題が発生しないように、ペイロードに静的プレフィックスを追加し、公開キーの最初の 6 バイトに増分ビット インデックスも含めたので、送信される各ビットには独自の BT MAC があります。スタック内のどこかに MAC アドレス ベースのレート制限がある場合に備えて、アドレスを指定します。





シリアルコンソールでESP32モデム出力A

データ取り出し側

Mac アプリも OpenHaystack に基づいており、AppleMail プラグインで同じトリックを使用して、適切に認証された位置取得リクエストを Apple バックエンドに送信します。ユーザーは 4 バイトのモデム ID (ESP ファームウェア中に設定できます) を入力するように求められます。その後、アプリケーションは ID 0 のメッセージを自動的に選択、デコード、表示します。その後、ユーザーは他のメッセージを選択するか、モデムを変更できます。 .



メッセージは、(バイト全体の) レポートがなくなるまで、一度に 16 バイト (128 ビット) フェッチされます (256 個のキー ID が要求されます)。

マイナーな問題: 公開鍵の有効期限

 

送信側と受信側の両方を実装した後、ブロードキャストして 32 ビット値を取得しようとする最初のテストを実行しました。数分後、32 ビットのうち 23 ビットを取得できました。それぞれが間違いなく正しく、約 100 の位置レポートが含まれていますが、残りの 9 ビットについてはそのようなレポートは取得できませんでした。



生成された公開鍵の一部が、ECIES 暗号化フェーズ中に近くの Apple デバイスによって無効な公開鍵として拒否された疑いがあります。 Python fastecdsa パッケージ: ロケーション レポートがないビットごとに、マイクロコントローラは公開キーをブロードキャストし、fastecdsa キーをインポートするときに InvalidSEC1PublicKey 例外をスローしました。



ここで使用される暗号化のコンテキスト:

• 28 バイトの EC パブリックは、SEC1 でエンコードされた特定の点の X 座標を表します。 
• SEC1 公開鍵には、通常、指定された X 座標に対して可能な 2 つの Y 座標のどちらをエンコードするかを決定する「符号」ビットもあります。このビットはブロードキャスト中には送信されず、公開鍵の有効期限には重要ではありません。 
• 圧縮された公開鍵をデコードするとき、対応する Y 座標は固定曲線パラメータを使用して計算され、鍵が有効かどうかが検証されます。生成された公開鍵の一部は、このテストに失敗します。詳細については、記事「楕円曲線上の公開鍵の検証」のセクション 3.2.2 を参照してください。

この無効な公開鍵の問題は、少なくとも 2 つの方法で解決できます。

1. , , , . , , . , , , id  
2. ( ). 28- X , 28- , , , , ( )

2 番目のオプションの利点は、受信したビットごとに位置レポートを復号化して、特定のビットが受信されたポイントを特定できることですが、これにはもう少し計算処理が必要です。このオプションを実装しているときに 、これに使用される uECC ライブラリでの楕円曲線乗算の実装のバグにより  、一部の秘密鍵について、ESP が Mac の BoringSSL および Python の fastecdsa とは異なる公開鍵を計算することがわかりました (差分ファジングが誤って忍び込みましたか? )。これらの公開鍵は、uECC 自身の uECC_valid_public_key () 関数によっても無効と見なされていました。したがって、このパイロット プロジェクトでは、オプション 1 に落ち着きました。







エンコード//エンコードされたメッセージへのメッセージは、



エンコードに公開鍵を生成//エンコードに公開鍵を生成



BT MACアドレス// BT MACアドレス



テスト妥当性、他のインクリメントカウンタ//キーが有効であるかどうかをチェックし、そうでない場合、によってカウンタを増加します1 つの



広告ペイロード // プレゼンテーションのペイロード



メッセージのエンコードと送信

試験・性能

公開鍵の検証チェックを実装すると、すべてが問題なく機能します。大規模なパフォーマンス テストや測定は行っていませんが、いくつかの推定値を次に示します。

•     ~3 . ,  
•     - Mac.  16    ~5
•     1 60 , , , . . , , , , ( , Apple)

CDF // 累積分布関数



中央値… 分 // 中央値… 26.3 分



公開遅延 (分) // 公開までの遅延 (分)



図 8. §7.1 で累積分布関数と見なされるすべてのレポートの受信の





遅延 ダルムシュタット工科大学のチームによって測定された、「誰が私のデバイスを見つけることができますか?」という資料に基づいて測定したレポートの受信の遅延 。

潜在的な用途

私は主に私が説明したものの実現可能性をチェックすることに興味がありましたが、おそらく最も一般的な実用的なアプリケーションは、ブロードバンド モデム、SIM カード、データ プラン、または Wi-Fi 接続なしで、センサー読み取り値またはIoT デバイスから データをダウンロードすることだと思います 。 AmazonがEchoデバイスを使用してSidewalkと呼ばれる同様のネットワークを使用していることを考える  と、  そのような技術に対する需要があるかもしれません。サーチャーのキャッシュは受信したブロードキャストを蓄積し、インターネット接続が確立されるまでそこにあるため、デバイスを持った人がそのような場所を歩いていれば、センサーはモバイル ネットワークの到達範囲外のエリアからでもデータを送信できます。 レーザーとスキャナーを組み合わせた技術が エアギャップを埋めるための有望なトリックであるように見える 高度なセキュリティ ネットワークの



世界  では、訪問者が持っている Apple デバイスは、エアギャップ システムから  データを盗むための実行可能な仲介者として機能することもでき  ます。またはファラデーケージで保護された部屋。 



また、オフライン検出プロトコルを使用して、無制限の関税に接続されている近くの iPhone のトラフィックを流出させる可能性があるよう です。1 人のシーカーから送信できる位置レポートの数を制限し (カウント バイトが 1 であるため、255 のレポート/送信)、各レポートが 100 バイトを超えるため、多数の一意の公開鍵をブロードキャストすると、送信トラフィックが大幅に増加する可能性があります。スマートフォンから。ロケーション レポートの送信頻度の制限には気付きませんでしたが、消費できるデータ量のテストも行いませんでした。

問題を解決する方法

最初に述べたように、もしそうすることを選択した場合、Apple がこの種の悪用に対して防御することは困難です。



Apple は、データ経済を念頭に置いてシステムを設計しました。暗号化されていない場所を読み取ることはできず、AirTag に属する公開鍵や、特定の暗号化された場所レポートが関連付けられている公開鍵さえもわかりません (公開鍵の SHA256 ハッシュのみを受け取るため)。



これに照らして、Apple ID の AirTags の上限が 16 に規定されていることは興味深いことです。なぜなら、現時点では Apple はそれを使用する義務を負うことができないように思われるからです。 



ただし、たとえば次の 2 つの領域では、このシステムをさらに強化することができます。

• BLE.  , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
•   Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .

この記事では、他のユーザーが所有する Apple デバイスを使用して任意のデータをダウンロードできるかどうかという質問に答えました。



ESP32 モデムのファームウェアと macOS 用のデータを抽出するためのアプリケーションが実装されており、 Githubに投稿されているので、試すことができます。



この実装は単なる「実現可能性の証明」であり、「プロトコル」自体は暗号化も認証もされていないことに注意してください。たとえば、ID 0x42424242 のモデムの詳細は、その ID を入力するだけで調べることができます (おそらく、このプロトコルには認証がないことを証明できる人もいるでしょう)。



最後に 1 つ注意してください。この投稿を準備しているときに、BLE ビューに含まれる「ステータス バイト」が、たとえばバッテリー レベル インジケーターとして明らかに使用されていることに気付きました。ローテーションされる決定論的に生成された秘密鍵と組み合わせると、おそらく別のデータ漏洩ホール (ビューあたりのバイト数) が開く可能性がありますが、このアプローチはテストしていません。

---

Macleod のクラウド サーバー は高速で安全です。



上記のリンクを使用するか、バナーをクリックして登録すると、任意の構成のサーバーをレンタルした最初の 1 か月間が 10% 割引になります。