SDRに基づいてGSM電話を組み立てる方法

メインプロセッサに加えて、ほとんどの人にとって既に馴染みのあるスマートフォンには、別個の通信モジュールがあり、そのおかげでスマートフォンはまだ電話になっているのは秘密ではありません。 メインのオペレーティングシステム（AndroidまたはiOS）に関係なく、このモジュールはほとんどの場合、独自のクローズドソースオペレーティングシステムで実行され、音声通話、SMSメッセージ、モバイルインターネットに関連するすべての作業を行います。



プロプライエタリなソフトウェアとは異なり、オープンソースプロジェクトは常にセキュリティ研究者からより多くの注目を集めています。 「内部」を見て、プログラムの1つまたは別のコンポーネントがどのように機能するかを調べる機能により、あらゆる種類のエラーを見つけて修正できるだけでなく、コードにいわゆる「ブックマーク」がないことを確認できます。 さらに、オープンソースを使用すると、初心者は自分の仕事の結果を柱として、より経験豊富な人から学ぶことができます。

OsmocomBBプロジェクトの概要

それが、遠い2008年に、Osmocomプロジェクトであるオープンソースモバイルコミュニケーションが出現し始めた理由です。 当初、開発者の注目はすべて、OpenBSCの唯一の補助プロジェクトに集中していました。これにより、数キログラムの商業基地局でセルラー通信を開始でき、2008年に毎年開催されるChaos Communication Congressで発表されました。



時間が経つにつれて、Osmocomは1つのプロジェクトの範囲を超え、今日では、オープンソースの携帯電話用のGSMスタックの無料実装であるOsmocomBBのような多数の補助プロジェクトを統合しています。 TSM30、Nokia 33XX用MADos、Airprobeなどの前身とは異なり、検討中のプロジェクトは研究者や開発者からより多くの注目を集めており、さらに現在も開発を続けています。



当初、OsmocomBBの主なタスクは、グラフィカルインターフェイスやその他の特定のコンポーネントを含むオープンソースの携帯電話向けの本格的なファームウェアを作成し、GSMプロトコルスタックの代替実装に焦点を当てることでした。 しかし、このアイデアは潜在的なユーザーからの強い反応とは一致しなかったため、今日、OsmocomBBは不可欠な研究ツールのセットであると同時に、GSMの初心者にとって優れた知識ベースでもあります。



OsmocomBBを使用すると、特定のGSM標準ネットワークのセキュリティを評価したり、セルラーネットワークで無線インターフェイス（Umインターフェイス）がどのように機能するかを実際に学ぶことができます。 どの暗号化が使用され、それはまったく使用されていますか？ 暗号化キーと一時的な発信者IDはどのくらいの頻度で変更されますか？ 音声通話またはSMSメッセージが攻撃者によって傍受される、または改ざんされる可能性はどのくらいですか？ OsmocomBBを使用すると、これらすべての質問や他の多くの質問に対する回答をすばやく見つけることができます。これは、使用可能な方法の一例です。 典型的な例としては、小型のGSM基地局の立ち上げ、SIMカードのセキュリティおよびトラフィックスニッフィングの研究があります。



Aircrack-ngプロジェクトおよびネットワークカードと同様のメインハードウェアプラットフォームOsmocomBBは、主にMotorola C1XXのCalypsoチップセットに基づく携帯電話です。 電話を使用するという決定は、新しい機器の設計と製造に時間がかかる可能性があるため、プロジェクトの開発の初期段階で、主に実装の速度を優先して行われました。 さらに、当時、Calypsoチップセットのソースコードと仕様の一部が既に無料であったため、ファームウェアのリバースエンジニアリングとすべてのさらなる開発に貢献しました。







ただし、このソリューションには独自の価格があります。 上記のチップセットに基づいた電話機は製造されなくなったため、使用されているモデルを探す必要があります。 さらに、GSMスタックの物理層の現在の実装は、DSP（デジタルシグナルプロセッサ）に大きく依存しています。DSP（デジタルシグナルプロセッサ）は、まだ完全には調査されていない独自のコードを実行します。 これらの要因はどちらもプロジェクトの開発に悪影響を及ぼし、潜在的な機能を制限し、サードパーティの開発者とプロジェクト全体のユーザーの両方の参入しきい値を複雑にします。 たとえば、DSPファームウェアを変更しないと、GPRSサポートの実装は不可能です。

変化の風-新しいハードウェアプラットフォーム

プロジェクトのソフトウェア部分は、多くの個別のアプリケーションで構成されており、各アプリケーションには固有の目的があります。 一部のアプリケーションは、UNIXに似た環境のコンピューターで直接動作します。 他の部分は、電話機にダウンロードされたファームウェアの形式で表示されます。 そして、それらの間の関係は、ヘッドセットジャックと組み合わされた電話機のシリアルポートを介しています。 つまり、TRSコネクタ（マイクロジャック、2.5 mm）は、音声伝送だけでなくデータにも使用できます！ 同様の技術が最新のスマートフォンで使用されており、ボタン付きヘッドフォン、自撮り用の一脚、その他のアクセサリーを接続できます。



USBなどの他のインターフェイスがなく、シリアルポートを使用する必要があるため、特定の制限が課せられますが、最も重要なのはデータ転送速度です。 たとえば、インターフェイスの帯域幅が狭いため、基地局をスニッフィングして起動する機能は部分的に制限されています。 さらに、電話機をUSBに接続するための既成のケーブルを見つけることは非常に難しく、ほとんどの場合、自分で行う必要があり、ユーザーが入力するしきい値も複雑になります。



ある時点でこれらの要因を組み合わせることで、別のハードウェアプラットフォームに切り替えるというアイデアが生まれました。これにより、プロジェクトはソフトウェアでもハードウェアでも制限されず、生産面でも価格面でも誰でもアクセスできます。 また、SDR（Software Defined Radio）テクノロジーは、その人気と可用性の急速な成長に関連して、これらの要件を満たしています。







SDRの概念は、汎用無線機器を開発することです。 特定の通信規格に縛られていません。 このおかげで、この技術は、アマチュア無線と商用機器のメーカーの両方で広く普及しています。 現在、SDRはセルラー通信、つまりGSM、UMTS、およびLTEネットワークの展開で積極的に使用されています。



OsmocomBBプロジェクトによって実装された、SDRに基づくGSM携帯電話の開発と発売のアイデア自体は新しいものではありません。 この方向はかつてOsmocom開発者によって開発されましたが、放棄されました。 さらに、残念なことに概念実証レベルで停止したスイスの研究室による同様の研究作業についても知られています。 しかし、それでもこの分野での作業を再開することを決定し、SDRに基づいたOsmocomBBの新しいハードウェアプラットフォームのサポートを実装するタスクを設定しました。



この記事の以降の部分では、新しいプラットフォームの開発プロセス、発生した問題、およびそれらを解決する方法について簡単に説明します。 結論として、達成された結果、現在の実装の制限、さらなる開発のアイデア、およびSDRでOsmocomBBを実行する手順を説明する小さなヒントを提供します。

プロジェクトの歴史

前述のように、OsmocomBBは2種類のアプリケーションを提供します。一部はコンピューター側で動作し、他は代替ファームウェアの一部として電話にダウンロードされます。 そして、それらの間の相互作用は小さなosmoconプログラムによって実装され（接続という言葉から）、シリアルポートを介した相互接続を保証します。 対話自体は、単純なバイナリプロトコルL1CTL（GSMレイヤー1コントロール）を介して実行されます。メッセージには、要求（REQ）、応答（CONF）、および通知（IND）の3つのタイプしかありません。



既存のアプリケーションとの「透過的な」互換性を確保するために、そのような調停のアイデアとプロトコル自体を保存することが決定されました。 その結果、新しいアプリケーションが実装されました-ブリッジのように、高レベルのアプリケーション（モバイルやccch_scanなど）とトランシーバー間で動作するtrxcon-SDRを制御する別個のアプリケーション。 これがtrxcon（トランシーバー接続）という名前の由来です。







トランシーバーは、ネットワークとの時間周波数同期、信号検出と復調、発信信号の変調と送信など、GSM物理層の低レベルのタスクを実行する別個のプログラムです。 既製のソリューションから、OsmoTRXとGR-GSMの2つの適切なプロジェクトがあります。 1つ目は、OpenBTSプロジェクトのトランシーバーの改良版であり、現在はOsmocomプロジェクトがベースステーションの起動に使用しています。 2番目は、GSM信号を受信およびデコードするためのGNU Radioブロックのセットを提供します。



実装の完全性と「すぐに使える」信号伝送のサポートにもかかわらず、OsmoTRXは、CとC ++の爆発的な混合物であるソースコードのクリーンさと読みやすさを開発者に喜ばせることはできません。 たとえば、コードの比較的小さなセクションを変更するには、クラス階層全体を調査する必要がある場合がありますが、GR-GSMはOsmoTRXに匹敵するモジュール性と変更の自由を提供します。 それでも、OsmoTRXには多くの利点がありますが、その中で最も重要なのは、パフォーマンス、システムリソース要件の低さ、実行可能コードのサイズの比較的小ささ、およびその依存関係です。 これにより、プロジェクトはリソースが限られたシステムに統合するのに十分なほどフレンドリーになり、GNU Radioは巨大で貪欲なモンスターのように見えます。 当初、開発全体は特にOsmoTRXに焦点を当てていましたが、最終的な選択は2番目のプロジェクトをトランシーバーとして使用することを支持して行われました。



下位互換性を確保するために、TRXインターフェイスはtrxconバインディングアプリケーションに実装されており、OsmoTRX、OsmoBTS、およびOpenBTSプロジェクトでも使用されています。 各接続のこのインターフェースは、3つのUDPソケットの使用を暗示しており、各ソケットには固有のタスクがあります。 それらの1つはCTRLインターフェイスで、これを使用してトランシーバー（周波数、ゲインなど）を制御できます。 もう1つはDATAと呼ばれ、名前に応じて、送信する必要がある情報（アップリンク）またはすでに受け入れられている情報（ダウンリンク）の交換を提供します。 後者のCLCKは、トランシーバーからタイムスタンプを送信するために使用されます。







GR-GSMの場合、新しいgrgsm_trxアプリケーションが実装されました。そのタスクは、ブロックの基本セット（フローグラフ）を初期化し、外部制御アプリケーション（この場合はtrxcon）にTRXインターフェイスを提供することです。 フローグラフ自体は、最初は受信用のブロックのみで構成されていました。 検出と復調、物理GSMインターフェイスの最小情報-バースト。 復調器の出力の各バーストは、主にペイロードとミッドアンブルで構成されるビットシーケンスであり、これにより受信機は送信機と同期できますが、プリアンブルとは異なり、中央にあります。







プロジェクト開発のこの段階で、ccch_scanなどの高レベルアプリケーションは、すでにSDRを特定の周波数に設定し、基地局との同期プロセスを開始し、受信信号を復調できます。 しかし、最初の成功とともに、最初の困難が現れました。 OsmocomBBの物理層の実装のほとんどは、以前は電話DSPに「依存」していたため、GSM 05.03仕様によるパケットのエンコードとデコードは個別に実装されず、独自のコードによって実行されました。



その結果、新しく実装されたトランシーバーは、情報のビット部分を実装の上位層に転送します。 バースト、および現在の上位層の実装では、物理層からのバイトLAPDmパケット（基本的には各23バイト）が必要です。 さらに、トランシーバーの動作は、基地局との正確な時間同期（TDMA-時分割多元接続）を意味しますが、高レベルのアプリケーションはそれを「疑い」なく、必要なときに発信パケットを送信します。



結果の「失敗」を排除するために、TDMAスケジューラーが実装に実装されました。これは、高レベルアプリケーションからLAPDmパケットを受信し、バーストでエンコードしてトランシーバーに送信し、フレームとタイムスロット番号を使用して送信時間を決定し、またからのバーストを収集しますトランシーバー、それらをデコードし、上位層に送信します。 GSM 05.03に準拠したエンコードとデコードは、ビタビアルゴリズムを使用して、受信したノイズの多いシーケンスからLAPDmパケットを復元するだけでなく、（冗長情報を追加することで）エラー耐性ビットシーケンスを作成することを意味します。







紛らわしいように聞こえますが、LAPDmパケットをエンコード/デコードする同様のプロセスが携帯電話側と基地局側の両方で行われます。 幸いなことに、無料のオープンソース実装であるOsmoBTS（Osmocom Base Transceiver Station）を自由に使用できました。 GSM 05.03に関連するこのプロジェクトのすべてのコードは、libosmocodingライブラリの子として、Osmocomプロジェクトのメインライブラリであるlibosmocoreに再設計、文書化、および転送されました。 これにより、OsmocomBB、GR-GSM、OsmoBTSなどを含む多くのプロジェクトで、コードを重複させることなく共通の実装を使用できます。 TDMAスケジューラー自体は、OsmoBTSとの類推によって実装されましたが、携帯電話の機能を考慮しています。



その後、レセプションはまだ機能しました！ しかし、携帯電話が機能するために単に必要な最も重要な機会はまだ十分ではありませんでした-データを転送する能力。 問題は、最初はGR-GSMに信号の変調と送信を許可するブロックがなかったことです。 そして幸いなことに、プロジェクトの作者であるPiotr Krysikは、その実装のアイデアを支持しました。その結果、プロジェクトのさらなる作業が彼と共に続きました。



データ転送の可能性がなく、実装の作業が進行中に無駄に時間を無駄にしないために、一時的ですが、後に判明したように、非常に有用なソリューションが開発されました-トランシーバーをエミュレートするためのツールのセット、すなわち 仮想Umインターフェイス。 OsmoBTSはOsmoBTSと同様にTRXインターフェイスをサポートするようになったため、両方のプロジェクトを簡単に相互接続できます：OsmoBTS側からの各ダウンリンクバーストはtrxconアプリケーションに送信でき、OsmocomBB側からの各アップリンクバーストはOsmoBTSに転送できます。 Pythonで書かれたFakeTRXと呼ばれるシンプルなアプリケーションで、機器なしで仮想GSMネットワークを実行できます。







この一連のツールのおかげで、TDMAスケジューラーの実装におけるかなり多数のバグが後で発見され、修正されました。また、SDCCHやTCHなどの専用チャネルのサポートもありました。 GSMの最初のタイプの論理チャネルは、主にSMS、USSD要求の送信、および（場合によっては）音声通話の確立に使用されます。 そして2つ目-通話中の音声用。 さらに、GAPK（GSM Audio Packet Knife）プロジェクトに基づいて、OsmocomBBでの音声の録音とエンコード、およびデコードと再生の基本的なサポートが実装されました。それ以前は、このタスクも電話のDSPによって実行されていました。







一方、Piotr Krysikは、信号伝送に必要なすべての欠落ブロックを開発し、正常に実装しました。 GSMはGMSK（ガウス最小シフトキーイング）変調を使用するため、GNU Radioの一部である既存のGMSK Modulatorブロックを使用しました。 ただし、主な問題は、基地局との同期を確保することでした。 送信された各バーストは、タイムスロットと呼ばれる基地局によって割り当てられた許可期間に従って、時間通りに送信する必要があります。 TDMAシステムの保護期間によって補償される小さなエラーを考慮に入れていますが、早くも遅くもありません。 状況は、ほとんどのSDRデバイスに正確なマスターオシレーターがないために複雑になりました。その結果、無線アマチュアが言うように、システム全体が「時間通りにフロートします」。







ただし、この問題の解決策はまだ見つかっており、USRPなどのハードウェア時間（ハードウェアクロック）SDRデバイスの使用に基づいています。これに基づいて、受信した各バーストは現在のハードウェア時間の「スタンプ」を受け取ります。 これらのスタンプとSCHバーストからデコードされた現在のフレーム番号を比較することにより、補正を実行し、発信情報の正確な送信タイミングを割り当てることができます。 唯一の問題は、SDRとの対話用に設計されたGNU Radio標準ユニットがタイムスタンプをサポートしないため、UHD SourceとSinkに置き換える必要があり、USRPファミリのデバイスのサポートに限定されることです。







その結果、トランシーバーの作業準備が整ったとき、仮想Umインターフェースの範囲を超える時が来ました。 しかし、彼らが言うように、最初のパンケーキはゴツゴツしているので、「すべてをまとめて」プロジェクトを実際の機器で立ち上げる最初の試みは、もちろん失敗しました。 GSMの時分割技術の機能が失われました。電話によって送信される信号のカウントダウン、つまり アップリンク、特に受け入れられたものに比べて遅くなった、すなわち 3つのタイムスロットのダウンリンク。これにより、半二重通信モジュールを備えた電話に、周波数調整に必要な時間の余裕が与えられます。 小さな修正の後、プロジェクトはまだ機能しました！ OsmocomBBとSDRを初めて使用して、SMSメッセージを送信し、最初の音声通話を行うことができました。

結果

行われた作業の結果、UHD（Universal Hardware Driver）ドライバーを介して動作するOsmocomBBとSDRトランシーバーの間に一種のブリッジを作成することができました。 GSM物理層の主要コンポーネントが実装されました。これらは、ccch_scan、cbch_scan、mobileなどの高レベルアプリケーションの動作に必要です。 すべてのプロジェクトの成果は、メインのOsmocomBBリポジトリの一部としてパブリックドメインで公開されました。



現在、SDRをOsmocomBBのハードウェアプラットフォームとして使用することにより、カリプソチップセットに基づくDSP電話などのクローズドソースコードを持つ独自のコンポーネントなしで、完全に「透明な」GSMプロトコルスタックを起動すると同時に、特定の各実装要素をデバッグおよび変更することが可能になります「その場で。」 さらに、開発者や研究者に新しい視野が開かれています。例えば：

• 他の周波数範囲（2.4 GHzなど）でネットワークと電話を開始します。
• 代替オーディオコーデックの統合（例：SpeexまたはOpus）
• GPRS / EGPRSスタックの実装。

仮想Umインターフェイスを作成するための前述のツールは、プロジェクトリポジトリにも公開されており、たとえば、セルラーネットワークインフラストラクチャのさまざまなコンポーネントに必要な負荷レベルをシミュレートして安定性をテストする経験豊富な開発者と、GSMの学習を開始できる初心者ユーザーの両方に役立ちますこのためにさまざまな機器を検索して購入することなく練習します。



ただし、OsmocomBBの新しいハードウェアプラットフォームの現在の実装にはまだ特定の制限がないわけではなく、そのほとんどはSDRテクノロジ自体に由来しています。 たとえば、USRP、UmTRX、LimeSDRなどのほとんどの利用可能なSDRカードは、従来の電話の最大送信電力と比較すると、比較的低い送信電力を持っています。 実装におけるもう1つの「ギャップ」は、周波数ホッピングテクノロジーのサポートの欠如です。これは、異なる周波数の複数の基地局の加入者による同時使用を含み、干渉のレベルを下げ、信号傍受を複雑にします。 それは、ほとんどの現代の事業者のネットワークで見つけることができます。さらに、GSM仕様では、すべての電話に必須のこの技術のサポートについて説明しています。 また、増幅器を使用して信号電力の問題を解決できる場合や、実験用基地局の使用に限定できる場合は、周波数ホッピングサポートの実装にさらに多くの労力が必要になります。



プロジェクトのさらなる開発のための計画の中で：

• 物理（非仮想）SIMカードのサポートの実装。
• サポートされているSDRデバイスのリストを展開します。
• CSDサポートの実装（回線交換データ）;
• OsmoTRXに基づく組み込みトランシーバの実装。
• GPRS / EDGEのサポートの実装。

このプロジェクトは、第34回Chaos Computer Clubの年次総会でも発表されました。

結論の代わりに

最後に、SDRで行われた作業の結果を実行する方法に関するいくつかのヒント。 まず、開発したTRX Toolkitを使用して仮想Umインターフェイスを試すことをお勧めします。



これには、OsmocomBBだけでなく、Osmocomの中央ネットワークインフラストラクチャのコンポーネントセット全体（OsmoNiTB（Network in The Box）またはBTS、BSC、MSC、MGW、HLRなどを含むすべてのコンポーネント）が必要です。 ソースコードのビルド手順は、プロジェクトのWebサイトで見つけるか、Debian、Ubuntu、またはOpenSUSEディストリビューションの既製パッケージを使用できます。



独自のネットワークから実装をテストするには、GSMネットワークスタックの利用可能な実装（Osmocom、OpenBTS、YateBTSなど）が適しています。 ネットワークを起動するには、別個のSDRデバイス、またはnanoBTSなどの商用ベースステーションが必要です。 上記の制限と考えられる欠点のために、事業者の実際のネットワークでプロジェクトをテストすることは強く推奨されません。



トランシーバをビルドするには、GNU Radioをインストールし、ソースコードからGR-GSMプロジェクトの別のブランチをビルドする必要があります。 トランシーバーの組み立てと使用の詳細は、 Osmocomプロジェクトのウェブサイトでも見つけることができます 。



頑張って！