LTESniffer: オープンソースのLTEダウンリンク／アップリンク盗聴ツール
(github.com/SysSec-KAIST)- LTESniffer は、LTE基地局とスマートフォンの間のダウンリンク・アップリンク無線メッセージをキャプチャし、PDCCHからDCIとRNTIを先に取得した後、PDSCH・PUSCHをデコードしてデータトラフィックを分析するオープンソースツール
- 暗号化されたメッセージを 復号することはできず、MAC・物理層ヘッダのような暗号化されていない部分や、基地局のブロードキャストメッセージ、接続初期の平文メッセージのみ分析可能
- セキュリティ研究向けAPIは identity mapping、IMSI collecting、UE capability profiling の3つをサポートし、既存のLTEセキュリティ研究が前提とする受動スニファ要件を、PDSCH・PUSCHプロトコルパケットのデコードで補おうとする実装
- 機能範囲には LTE Advanced・LTE Advanced Pro、アップリンク・ダウンリンク最大 256QAM、FDD、最大20MHz基地局、DCI formats 0/1A/1/1B/1C/2/2A/2B、transmission modes 1〜4 を含む
- リアルタイムデコードには複数の物理コアを持つCPUとSDR構成が必要で、アップリンクトラフィック収集ではUE信号が弱いため、スニファをスマートフォンの近くに置くか、指向性アンテナ・RFフロントエンド・増幅器のようなハードウェア強化が必要
LTESnifferが行うこと
- LTESniffer は、LTEダウンリンクとアップリンクの両方をキャプチャするオープンソースの盗聴ツール
- 動作フローは、まず PDCCH をデコードしてアクティブユーザーのDCIとRNTIを取得し、それを使ってPDSCHとPUSCHを追加でデコードし、アップリンク・ダウンリンクのデータトラフィックを取得する方式
- 一般ユーザーの観点では、基地局と接続されたスマートフォンの間を行き来するLTE無線メッセージを双方向にキャプチャするツール
- 暗号化されたメッセージは復号できない
- 暗号化されたメッセージでは、MAC・物理層ヘッダのような 暗号化されていない部分 を分析できる
- 平文で送信される基地局ブロードキャストメッセージや接続初期メッセージは完全に分析可能
セキュリティ研究APIと研究目的
- LTESniffer は、セキュリティアプリケーションと研究向けに 3つのAPI機能 を提供
- identity mapping
- IMSI collecting
- UE capability profiling
- 多くのLTEセキュリティ研究は、空中でプライバシー関連パケットをキャプチャできる受動スニファを前提としているが、既存のオープンソーススニファはPDSCHとPUSCHのプロトコルパケットをデコードできず、要件を満たしていないとされる
- 詳細は 論文 にまとめられている
- LTESniffer の主な目的は、セルラーネットワークの セキュリティ・分析研究 の支援
- アップリンク・ダウンリンクのユーザーデータを収集するため、LTEトラフィックスニッフィングに関する現地規制に従う必要がある
- ユーザープライバシーに関する情報を意図的に収集するなど、違法目的での利用について開発者は責任を負わない
対応機能と実装基盤
- LTESniffer は FALCON 上に実装され、srsRAN ライブラリを使用
- 主な対応範囲は以下の通り
- PDCCH、PDSCH、PUSCH 制御・データチャネルのリアルタイムなアップリンク・ダウンリンクデコード
- LTE Advanced と LTE Advanced Pro
- アップリンク・ダウンリンクともに最大 256QAM
- DCI formats 0, 1A, 1, 1B, 1C, 2, 2A, 2B
- transmission modes 1, 2, 3, 4
-
FDD のみサポート
- 最大20MHz基地局
- スマートフォンごとの最大UL/DL変調方式の自動検出
- UEごとの物理層構成の自動検出
- RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
- v2.1.0 アップデートでは、サブフレーム IQ raw data ファイル記録、記録ファイルを用いたオフラインデコード、ダウンリンクモードでのAPI有効化を追加
- ダウンリンクモードAPIは identity collecting と mapping API にのみ適用
- 関連内容は
LTESniffer-record-subframeブランチと README にある - v2.0.0 アップデートでは、アップリンクスニッフィングモードで 2台のUSRP B-series の使用をサポートし、バグを修正
- 関連内容は
LTESniffer-multi-usrpブランチと README にある
ハードウェア・ソフトウェア要件
- 安定動作OSは Ubuntu 18.04/20.04/22.04
- リアルタイムLTEトラフィックデコードには、基地局にアクティブユーザーが多いピーク時間帯で複数の物理コアを持つ高性能CPUが必要
- Intel i7-9700K PC で、アクティブユーザー150人の基地局トラフィックをリアルタイムデコードした事例がある
- 推奨仕様は、8個以上の物理コアを持つ Intel i7 CPU、16GB以上のRAM、256GB SSD
- ダウンリンクのみをスニッフィングする場合は、srsRAN がサポートする大半のSDRを使用できる
- 例は USRP または BladeRF
- SDR は USB 3.0 でPCに接続する必要がある
- transmission modes 3・4 のダウンリンクメッセージをデコードするには RXアンテナが2本必要
- RXアンテナが1本しかない場合は transmission mode 1 のダウンリンクメッセージのみデコードする
- GPSDO はダウンリンクスニッフィングで同期改善に役立つが必須ではない
- アップリンクスニッフィングでは、アップリンクとダウンリンクの 2つの周波数 を同時に受信する必要があるため、2つの構成をサポート
- 単一の USRP X310: RXチャネル2本を異なるアップリンク・ダウンリンク周波数に合わせられ、GPSDOは任意
- 2台の USRP B-Series: B210/B200 をアップリンク・ダウンリンクにそれぞれ使用し、GPSDO を clock source と time reference として使って2台のUSRPを同期
- 2台の USRP B-Series 構成では GPSDO が必須
インストールと実行フロー
- ソースビルド前に UHD 4.0 以上 のインストールが必要で、ソースビルドが推奨される
- srsRAN 依存関係と LTESniffer 依存関係をインストールした後、リポジトリをクローンし、
cmake、make -j 4でビルドする - ビルド後、実行ファイルは
<build-dir>/src/LTESnifferに配置される - 主な実行モードは3つ
- 基地局から来る LTE ダウンリンクトラフィックのスニッフィング
- スマートフォンから基地局へ向かう LTE アップリンクトラフィックのスニッフィング
- セキュリティAPI
- 商用網で使用する前に、LTEトラフィックスニッフィングに関する 現地規制 を確認する必要がある
- テスト用スマートフォンが接続している基地局とアップリンク・ダウンリンク帯域を確認するには、Android向け Cellular-Z を使える
- LTESniffer も同じセルと周波数に合わせる必要がある
出力と分析
- LTESniffer は出力として pcap ファイル を提供し、Wireshark で追加分析とパケット追跡ができる
- 生成ファイル名はモードごとに異なる
- ダウンリンク:
sniffer_dl_mode.pcap - アップリンク:
sniffer_ul_mode.pcap - API:
api_collector.pcap
- ダウンリンク:
- pcap ファイルは LTESniffer を実行した同じディレクトリに生成される
- Wireshark がデコード済みパケットを正しく分析するには、
pcap_file_example/README.mdの設定ガイドを参照する必要がある - アップリンク pcap ファイルにはアップリンクとダウンリンクのメッセージが両方含まれる
- アップリンクのみを見るには
mac-lte.direction == 0フィルタを使う - ダウンリンクのみを見るには
mac-lte.direction == 1フィルタを使う
- アップリンクのみを見るには
アップリンクスニッフィングの距離制約
- LTESniffer のアップリンク有効範囲は、SDR のような RFフロントエンド の性能によって制限される
- UE はバッテリー使用を最適化する携帯機器であり、アップリンク信号電力は基地局のダウンリンク信号よりはるかに弱い
- アップリンクトラフィックを正常にキャプチャするには、次の方法で受信信号電力を高められる
- UE に物理的に近い位置に置く
- 指向性アンテナ、専用RFフロントエンド、信号増幅器のような特殊ハードウェアを使う
FAQで明記された制限と代替案
- GPSDO はより安定した同期に有用だが、ダウンリンクスニッフィングでは GPSDO がなくても LTE 信号と同期してパケットをデコードできる
- アップリンクスニッフィングで GPSDO が必要なのは 2台の USRP B-series を使う場合のみ
- 単一の USRP X310 構成では GPSDO は不要
- ダウンリンクトラフィックは、srsRAN ライブラリがサポートする BladeRF のような SDR でも技術的には実行可能
- ただし LTESniffer のダウンリンク機能テストは USRP B210 と X310 でのみ実施されている
- LTESniffer 使用の適法性については、暗号化されていない LTE トラフィックスニッフィングに関する 現地規制 を確認する必要がある
- 別のテスト方法としては、Faraday cage 内で srsRAN ベースの個人用 LTE ネットワークを構築する方法が提示されている
- 2人のユーザー間のメッセージ内容は、暗号化されていない部分のみ見ることができる
- 基地局とユーザー間の無線トラフィックの大半は暗号化されている
- LTE ネットワークには、TMSI、GUTI、IMSI、RNTI のように平文で露出するさまざまな識別子が文献で示されている
1件のコメント
Hacker News のコメント
モバイルネットワーク標準は略語だらけで良い
知らなかった人のために言うと、PHICH の Q は “request” の意味
その中の “ARQ” はおそらく https://en.wikipedia.org/wiki/Automatic_repeat_request と展開できる
“ARQ” の “Q” は実際には “query” だと言う人もいるだろうし、“request” と展開する人は平均的な語彙レベルを低く見ているのだと言う人もいるだろう
個人的には、考えてみると Q は “request” や “query” ではなく、https://en.wikipedia.org/wiki/Q_code にある慣例的で不透明なQコードの別の名残である可能性が高いと思う
ここに PHICH 内の Q がある: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
兄弟コメントの通り、q は reQuest の Q
良さそう
FDD のみ対応で TDD はなく、20MHz に制限されているので、多少の制約はある
ある程度のリアルタイムデコードもできるようで興味深い。基地局では処理の大部分をかなり汎用的なプロセッサが担っているが、それでもこのソフトウェアよりはハードウェアとずっと密接に統合されている
これを動かすハードウェアが高すぎるのが残念 :'(
なので limesdr でも動くはず
もっと安いものなら antsdr や adalm-pluto を試せる: https://github.com/srsran/zynq_timestamping
良いメモもたくさんある: https://www.quantulum.co.uk/blog/private-lte-with-analog-ada...
一部の機能は安価な rtl-sdr ドングルでも動く。以前の https://github.com/Evrytania/LTE-Cell-Scanner のフォーク
少し脇道だが、DSL の盗聴を試した人がいるのか気になる
現代の DSL、特に VDSL2 は本質的にシールドされていないツイストペア上を伝わる高周波信号なので、ブリッジタップのようなものまであれば簡単に漏れて放射されるはず
実際、英国のアマチュア無線家たちがこれについてかなり不満を言っているほどらしい[1]。その信号をまだ復調できるのか、それともスペクトル上で厄介な基準ノイズにすぎないのか気になる
[1]: https://rsgb.services/public/publications/vdsl/measuring_and...
Adsl2 ハンドシェイク音もある: https://www.youtube.com/watch?v=foPGdfsrskA
DOCSIS ケーブルモデム版も見た覚えがあるが、見つけられない :(
あまり知られていない興味深い事実として、初期のデジタル携帯電話世代は解読難度の微妙な位置にある
まったく簡単ではないが、破れる程度には簡単。暗号化は実際に破られている
レインボーテーブルは 2TB で、作成に数か月かかった: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
今では、さらに後の世代にも何らかの理由や特定の国家アクターのために復号の穴が少しあるのか気になってくる
面白い取り組みで、こうしたオープンソースがまだ使われているのを見るとうれしい
10年ほど前、大学のネットワークセキュリティ研究室でダウンリンクの盗聴をやってみた
プロジェクトの一つは、春休み中にセルの活動量がどれだけ減るかを測定するもので、もう一つは、既知の位置にある既知の電話番号に対してタイミング攻撃を行い、一時 ID を抽出できるか確認し、繰り返し発呼することでまだその地域にいるかを見るものだった
その一時 ID は個人的には十分に一時的ではなかったと思う。また触ってみたくなった
情報抽出に使える、壊れたデバッグモードが知られている 4G ドングルもある
LTESniffer はオープンソースだというが、トップレベルの LICENSE ファイルも GitHub リポジトリのライセンス設定もないように見える
ビルドファイルやその他のサポートファイルまで含めるなら、トップレベルの LICENSE ファイルを追加するのが正しい