なんで他人のデバイスをAirTagにできちゃうのか

→ 与えられた公開鍵から秘密鍵を逆算する手法の実用性を示したから 。AppleのFindMyではBLEアドレスに公開鍵を埋め込んでいるため、常識的なセキュリティが導入されているBluetoothプラットフォームではアドレスを制御できず、よって公開鍵も制御できなかった。このため攻撃者が生成した鍵ペアを直接使用させる方法が無なかった。提案される nRootTag はこの点を改善している。
論文 https://www.usenix.org/system/files/conference/usenixsecurity25/sec25cycle1-prepub-1266-chen-junming.pdf では、攻撃を2種類に分けている:
- (従来のOpenHeystackはアドバタイズアドレス自体を自由に設定できる、つまり、攻撃者が鍵ペアを用意して被害者に直接使用させることが前提となっていた)
- Attack I: Public Address(EhternetのMACアドレスみたいにOUIを含む)でアドバタイズできる場合
- Attack II: アドバタイズされるBLEアドレスがランダムアドレスになる場合 (WindowsやAndroidでは、アドバタイズ用のランダムアドレスは定期的に変更され、アプリ側からは取得できない)
どちらのケースでもRainbow table(全ペアを事前導出)できるが、Attack IIでは空間が広く現実的でないためGPUを使ったオンライン探索を提案している(実装はリポジトリのseekerにある)。
論文はFindMy実装の不備(協力デバイスはrandom static address以外でもFindMyネットワークに位置情報をアップロードしてしまっている)も活用している。
他人の位置情報をデコードできるようになったわけではない
この手法は "本物の" AirTag には有効でない。本物のAirTagは15分で公開鍵 = アドバタイズするアドレスを "ランダム" に変更してしまうため、ある時期に標的の公開鍵を知ることができても、その標的の次の鍵を知る簡単な方法が無い。
この "ランダム" は実際には完全な乱数ではなく、一般的なTOTP手法と同じように事前に共有した秘密鍵を使って、それに時刻を与えて作成している。このため、この事前共有鍵を入手できれば鍵を予測できる。(この予測は秘密鍵と公開鍵の両方が得られるため、今回論文で示された手法は必要ない)
オンライン手法
本物のAirTagと異なり、 この手法はデバイスがネットワークに接続していないと成立しない 。特に、AndroidのようにAttack IIが必要なデバイスでは、ネットワークへの接続は攻撃中に常に維持されている必要がある。
被害者にインストールされるnRootTagが、攻撃者に自身の存在を知らせないと攻撃が成立しない。これはnRootTagが攻撃者に(nRootTagが動いているデバイスのBLEアドレスを元に)アサインされた公開鍵を知っている必要があるため。
このため、この攻撃が有効なのは:
- 被害者にnRootTagを含んだアプリケーションをインストールさせる
- そのアプリにBluetooth権限を与える
- にもかかわらず、アプリに位置情報権限を与えたくない
ケースに限定される。どっちにせよ攻撃者のサーバーへのアクセスができるのであれば、攻撃アプリ自体で位置情報を取得して送信させる方が簡単と言える。
prev

なんでこの攻撃が気付かれないのか
論文(7.2 Stealth Tracking)では、デバイスが移動しない限りストーカー警告は動作しないという点を指摘している。また、AirTagの警告を無視する手法はいくつか提唱されている。