ICS OT
重要インフラのオープン化：5G通信で注目を集めるオープンRAN(O-RAN)におけるセキュリティの現状
オープンRAN（O-RAN：Open Radio Access Network）のアーキテクチャは、従来の閉ざれたシステムに対し、標準化されたインターフェースやプロトコルを提供することが期待されています。しかし、今回のO-RANに関する調査では、不正なxAppによってRIC（Ran Intelligent Controller）のサブシステム全体が侵害されるリスクが示されました。
無線アクセスネットワーク（RAN：Radio Access Network）のアーキテクチャ「オープンRAN（O-RAN）」は、従来の閉じたRANに対して標準化されたインターフェースやプロトコルを導入し、より開かれたアクセス手段を提供します。O-RAN上では、xApp（xApp：eXtended Applications）と呼ばれるコンポーネントが稼働します。xAppはさまざまなベンダーから提供され、事業者側でインストールされる想定となっています。そのため、攻撃者の目には侵入経路として映りやすく、不備があった場合には重要な通信ノードの内部に侵入され、足場を構築される恐れがあります。今回の調査では、不正なxAppによってRANインテリジェント・コントローラ（RIC：RAN Intelligent Controller）のサブシステム全体に障害が発生するリスクが示されました。O-RANのセキュリティに関する理論的な調査は以前からありましたが、O-RANソフトウェアコミュニティ（SC：Software Community）の実装リファレンスにまで踏み込んだ実践的な調査は、今回が初めてのことと考えられます。
5Gネットワーク
図1に、5G無線ネットワークの一般的な構成を示します。図中、コアネットワーク部に若干の修正を加えることで、3Gや4Gを含む過去の通信システムにも対応可能です。本図の左側はユーザ機器（UE：User Equipment）に相当し、携帯電話や無線ルータ、5G接続が可能なコンピュータ、ロボット用アームなどが挙げられます。UEが発する情報は電波に乗って基地局に伝わり、そこでIPパケットに変換され、IPバックボールを通じてコアネットワーク側に届けられます。それ以降は、ITネットワークの領域となります。
基地局
図2の基地局（Radiallの解説に基づく）は、下記の要素から構成されます。
- アンテナ：無線信号を送受信する。
- リモート無線ヘッド（RRH：Remote Radio Head）：無線周波数（RF：Radio Frequency）のトランシーバを備え、これによってデジタル信号と無線信号を相互に変換する。
- ベースバンドユニット（BBU：Baseband Unit）：デジタルデータの変調、エンコード、デコード、高レイヤー用プロトコルに関する処理を行う。BBUは、複数のRRHやアンテナをまとめて管理できる。
RRHは多くの場合、中継塔のアンテナ近くに設置されています。BBUも、以前は中継塔に共同設置されていましたが、現在では遠く離れた集約拠点に移されています。RANの進化については、「Analysys Mason」の比較図に示されています。
仮想RAN（vRAN：virtual RAN）では、市販の既製ハードウェアを用いてBBUを仮想的に動作させます。vRANには分離化モデルも存在し、この場合はBBUを集中ユニット（CU：Central Unit）と分散ユニット（DU：Distributed Unit）の2機能に分割します。
オープンRAN
上記の仮想化や分離化といった方針にも関わらず、RANのアーキテクチャは依然として閉ざされた状態にあります（互換性を保つために大半のコンポーネントを同一ベンダーから入手する必要がある）。このような場合、事業者は機器や技術を使用するために、同一ベンダーに対して高額な費用を支払う必要があります。
一方、オープンRAN（O-RAN）では、標準的な規約やインターフェース、プロトコルの公開、導入により、相互運用性や柔軟性の向上が図られています。これによって従来の閉ざされたRANが広く開放され、事業者側でさまざまなサプライヤの機器やソフトウェアを選択し、より柔軟にネットワークをカスタマイズすることが可能となります（例えば、CUとDUのそれぞれを別ベンダーから購入するなど）。結果、業界の門戸が開かれ、第2、第3レベルの機器メーカーも参入しやすくなるでしょう。
O-RANは、ただの共通インターフェースに留まるものではなく、特にAI（Artificial Intelligence：人口知能）で制御された次世代型RANへのアクセスを提供する点が重要です。ローカルネットワークの構成要素とRICを繋ぐ共通インターフェースには、無線リソースの検知、管理、応答をリアルタイムに近い状態で行うための仕組みが備わっています。しかし、共通の標準仕様という性質上、攻撃などの脅威にも晒されやすくなります。そのため、セキュリティに配慮した設計が強く求められます。
O-RANアライアンス
「O-RANアライアンス」は、オープンRANによる理念の推進を目指すモバイル事業者やベンダー、研究機関、学術機関によって構成されたオープン技術の業界団体です。同アライアンスは、オープンRANに関するさまざまな仕様を策定しました。
同アライアンスは以前、Linux Foundationと提携してO-RANソフトウェアコミュニティ（O-RAN SC）を結成し、O-RANのリファレンス実装を開発しました。O-RAN SCの仕様はオープンソースであり、そのコードはEricssonやNokia、Samsung、Radisys、AT&Tなどの主要なRANベンダーから提供されました。その成果もあり、今後、多くのベンダーがO-RAN SCのコードを製品内に取り込んでいくと考えられます。
O-RANのアーキテクチャ
O-RANアライアンスのWebサイトには、O-RANアーキテクチャの概要が示されています。本稿の内容を扱う上で、その全要素を理解する必要はありません。図3に、5GネットワークにおけるO-RANの位置付けを示します。
準リアルタイムRIC（near-RT RIC）およびRICメッセージルータ（RMR）
O-RANアーキテクチャの重要な構成要素として、準リアルタイムRIC（near-RT RIC）が挙げられます。その主な働きは、ネットワーク内にあるRFリソースを監視、管理し、ネットワークのパフォーマンスを最適化することです。ネットワークのデータをリアルタイムに収集、分析した上で、知的な判定処理を用いて無線リソースの設定を最適化することで、さまざまな端末やサービスの要求に対処することが可能となります。
near-RT RICの内部には、E2Term、E2Mgr、xAppsなど、さまざまなサブコンポーネントが存在します。これらサブコンポーネント間の通信は、RICメッセージルータ（RMR：RIC Message Router）の表に基づいて行われます。RMR表には通常、メッセージのルーティングや管理に関する情報が記載されています。具体例として、メッセージの宛先、優先度、キュー情報などが挙げられます。
RMR表に含まれる情報を下記に示します。
- メッセージの宛先：メッセージの送信先や、それを処理すべきハンドラを指定する。
- 優先度：重要なメッセージに対する応答が早く得られるように、メッセージの対応優先度を指定する。
- キュー情報：後続処理のためにメッセージを保持する。
- メッセージタイプ：正しいハンドラが当該メッセージを処理できるように、メッセージのタイプを指定する。
- メッセージ識別子：メッセージを識別する一意な値であり、メッセージのステータスや処理状況を追跡確認するために使用される。
RMR表へのアクセスに必要なAPIはRMRライブラリに用意され、near-RT RICのサブコンポーネント「xApp」や「E2Term」から呼び出されます。例えば、2つの異なるxApp間で通信を行う際には、RMRがその仲介役を担います。この場合、xApp_AがKPI情報に基づいて判定処理を行い、RMRを経由してxApp_Bを呼び出します。
図4に、near-RT RICのサブコンポーネント同士がRMRライブラリやルーティング表を用いて通信する際の様子を示します。
今回の調査では、near-RT RICのメッセージ用インフラから複数の脆弱性が発見されました。
攻撃経路
xAppsはnear-RT RICの中で稼働するソフトウェアコンポーネントの1つであり、無線リソースの最適化、ネットワークの監視、パフォーマンスの向上などに貢献します。ネットワーク管理者やサードパーティの開発者、ネットワーク機器のベンダーは、さらに本コンポーネントに対して固有のパラメータや機能を追加できます。この点でxAppsは、O-RAN用コンポーネントの中でも特にオープン化されたものと見なせるでしょう。
xAppsのように多くのベンダーを受け入れるエコシステムにより、さらなるイノベーションが生み出されると期待されます。その一方で、下記のような課題についても検討する必要があります。
- xAppsの搭載工程におけるセキュリティの確保
- 相互運用性の実現
- 堅牢性の維持
一般的に、xAppsはさまざまなベンダーから提供されることが期待されます。そのため今回は、xAppsが攻撃経路に利用されるリスクを念頭に調査を行いました。xAppが侵害される際の状況として、そのサプライチェーンや搭載工程への不正な介入が考えられます。また、xApp自体が正常であっても、想定外または異常なメッセージを送信すれば、害を及ぼす可能性があります。実際に以上のことは、調査結果によって確認されました。
RMRの脆弱性
CVE-2023-40998：xAppから送信された不正なパケットによってRT RICのE2Termがクラッシュする
脆弱性「CVE-2023-40998」では、不正に細工されたパケットによってデコード後のパケットサイズがマイナス値となり、後続のmemcpy操作でシステムがクラッシュします。
メッセージのサイズは、パケットの先頭4バイトによって決まります。従って、この部分にマイナス値が埋め込まれていれば、システムクラッシュに至る可能性があります。
CVE-2023-40997：形式不正のメッセージ送信によってnear-RT RICのE2Termがクラッシュする
脆弱性「CVE-2023-40997」では、正常にデコードできないパケットの送信により、異常なメモリアドレスが算出され、E2Termがクラッシュします。
CVE-2023-41627：RMR表に偽装
E2Termは、RICシステム内にある他のコンポーネントと通信する際に、ルーティングマネージャから定期的に届くルーティング表の情報を用います。しかし、当該情報の送信元を検証する機能が欠落しています。これに起因する脆弱性が「CVE-2023-41627」です。本脆弱性に目を付けた攻撃者は、ルーティングマネージャを利用して不正なルーティング表の情報をE2Termに送り付けようとします。E2Term側では、高頻度に到来する不正な情報に欺かれ、他コンポーネントとの通信に障害をきたす可能性があります。
RMRハイジャック：2つのxAppが同一タイプ、同一サブスクライブIDのメッセージを送信
xApp_AがE2ノードにサブスクライブするために機能IDを送信した際に、別のxApp_Bによって同一の機能IDが当該のE2ノードに送信されるケースを考えます。この場合、RMR表のxApp_Aに対応するエントリが上書きされ、xApp_AではE2ノードからメッセージを受信できないようになります。代わりに、E2ノードはxApp_Bの方にメッセージを送るようになります。この問題については、別の開発者からも指摘が上がっています。
攻撃の影響
O-RANは、そのノードによって暗号鍵の保管やユーザ通信データの処理を行うなど、通信ネットワークの基幹的な一部分を占めています。
今回挙げた脆弱性のうち、その2つはサービス拒否（DoS：Denial of Service）のインシデントを引き起こします。本脆弱性に関与するxAppやRMR、near-RT RICなどのコンポーネントは、RFリソースの最適化や通信トラフィックの管理など、付加価値の高いサービスを提供するものです。
O-RANは、仮にRICやE2コンポーネントが利用できない場合でも、通信トラフィックを処理するように設計されています。そのため、理論的には、RICコンポーネントがクラッシュしても、無線接続が途絶えるわけではありません。しかし、リソースの利用効率やサービスの品質が下落する可能性があります。
一方、RMRの偽装やハイジャックは、RICのコンポーネントを停止させるものではありませんが、xAPPのエコシステムを混乱させます。結果は先程と同様であり、リソースの利用効率やサービスの品質に悪影響が出ます。
xApp自体が正常でも、実装法に不備があれば、被害に発展する可能性があります。こうした性質は、さまざまなベンダーから提供されるO-RANコンポーネント間の相互運用性に悪影響を及ぼすと考えられます。
セキュリティ対策
不正なxAppがシステムに混入する事態を阻止する上では、機能の検証や搭載に関わるプロセスの厳格化が有効です。また、RICコンポーネントの故障に際してもO-RAN側で通信トラフィックを処理できるように制御することで、攻撃の影響を軽減することが可能です。
この他にも、O-RANプロトコルに対応したディープパケットインスペクション（DPI：Deep Packet Inspection）の導入を推奨します。これにより、コンポーネント間の通信データを監視し、必要次第で緊急にパッチを適用することが可能となります。
謝意
本調査は、「National Taiwan University of Science and Technology」と「TrendMicro/CTOne」の提携によって実施されました。
参考記事：
Opening Critical Infrastructure: The Current State of Open RAN Security
By: Salim S.I., Richard Y Lin
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）