SEPP(Security Edge Protection Proxy)についての整理

この記事は5Gローミング接続において重要なNFであるSEPPについて、GSMAおよび3GPPのドキュメントをもとに整理します。下記のAdvent Calendarに参加しております。

EPCローミングにおいてHPMN,VPMN間制御プレーンのメッセージは暗号されていなかったが、SEPPで暗号化することで、データの改ざんや盗聴を防ぎ、異なる事業者間の安全な通信が可能になる。

この記事では、主にGSMA NG.113および3GPP TS 33.501を参照し、以下の内容を整理しています：

• 5G SAローミングの構成
• SEPPのセキュリティ機能
• SEPP間接続の流れ

5G SAローミング構成

Local breakoutとHome-routed構成

EPCで使用されていたlocal breakout（LBO）およびS8 home routed（HR）の概念は、5G SAにおいても基本的に変わらない。ただし、5GCでは以下の違いが存在する。

• C-plane間通信にSEPP（Security Edge Protection Proxy）が追加され、N32インターフェースを介して接続される
• CUPSの採用により、SGWおよびPGWのU-plane機能が分離され、Home-routed構成ではU-plane間通信がN9インターフェースで実現される

NG.113 Fig.1 LBO roaming architecture

図1: NG.113 Fig.4 N9HR roaming architecture
N9HRはVPMN側のvSMF/UPF経由で、HPMN側のhSMF/UPFを利用。

中継事業者を考えた構成

GSMA NG.113 v11 Section 4.2では、中継事業者や外部ネットワークによるSEPP提供、および複数事業者との接続・信号の統計処理や加工機能を備えたHubを考慮し、実装構成を大きく4つのモデルに分類している。

これらのモデルについての詳細な説明は割愛しますが、MNOのSEPP実装形態（自社ネットワーク内での実装、中継事業者による提供、グループ会社での一括管理）に基づいて細分化されている。
また、HPMNとVPMN間で交換されるメッセージを、中継事業者が一部加工できる仕組みも存在します。このようなサービスを提供する場合、Model 3/4に該当するService HubまたはRoaming Hub（ローミング契約形態が異なる）を利用する。

NF間接続構成

GSMA NG.113ではローミング接続における下記NF間相互接続Modelの推奨も記載されている：

※NRF：NF Producerの発見を実現するための登録・情報提供装置
※SCP：NF間が直接通信する代わりの信号の中継を行う装置。信号のRoutingのほか、サービスの発見を行うこともある

• 通信モデルAでは、VPLMN内で関連する全てのHPMN NFsを設定する必要があるため、複雑である
• VPLMNとHPMNの両方で、NRFによるNFの発見と選択をサポートすることが推奨される。これにより、VPLMN内のV-NRFおよびHPMN内のH-NRFを使用して効率的なNFの発見と選択が可能になる

SEPPの機能

SEPPの概要

non-transparent proxy ノードとして、SEPPは下記の機能が定義されている

• PLMN間アプリケーションレイヤ C-Planeの保護
• ローミングNWにおける相互認証と暗号化
• 暗号化鍵の管理
• 外部に対して網内トポロジーの隠蔽性保証
• 内部NFへのアクセス提供とコントロール
• そのほか、送信元の認証および誤ったメッセージの廃棄、不正なメッセージに対してrate-limiting機能やanti-spoofing機能も想定されている

SEPP間のインタフェースはN32が定義されてるが、N32はさらに暗号化ハンドシェイク時用のN32-cと、実際のNF間メッセージを送信用のN32-fで細分されている。

• N32-c：Control Plane interface between the SEPPs. 暗号化ためのハンドシェイクを行い、N32-f上で実際のN32メッセージ転送に適用するパラメータの交渉
• N32-f：Forwarding interface between the SEPPs.　SEPP間の転送IFであり、HTTP/2メッセージをTLSまたはPRINSによって転送するために使用される。

SEPPセキュリティ機能

SEPP間のN32-c接続は、TLS（Transport Layer Security）による暗号化が適用される。一方、N32-f接続ではTLSに加え、PRINS（Protocol for N32 INterconnect Security）が使用可能です。
TLSはHTTPメッセージ全体を暗号化するため、中継事業者が信号内容を確認または変更する場合、ホップごと暗号化解除・再暗号化することとなる。暗号化解除の際に、センシティブ内容も明文となってしまう。これをGSMAのガイドラインNG.113では「Hop-by-Hop TLS」と呼んでいるが、この仕様は3GPPでは標準化されていない。

PRINSは、Application Layerでメッセージの一部を選択的に暗号化することを可能にして、また、中継事業者が必要な変更を加えられるように設計されている。以下では、中継事業者を考慮しないPLMN間の直接接続（direct TLS接続）と、IPXを利用したPRINS接続について説明します。

TLS

TLSを用いて事業者間direct接続の場合下記のように特徴づけられる：

• メッセージの内容について、送信側のMNOが完全なコントロールを持ち、受信側のMNOはローミング契約に基づくポリシーチェックのみを必要とする
• 両MNO間の信号情報はE2Eでセキュアに保たれる
• UEのキーや認証トークンを中間者に公開する意思がない限り、中間者を使用することはできない

また、N32-cとN32-fは異なるTLS接続が使用される

• SEPPはN32-cおよびN32-f接続の確立に使用されるTLS証明書に含まれるPLMN-IDを比較する。N32-fの証明書にN32-cの証明書に含まれていないPLMN-IDが含まれている場合、そのN32-f証明書は拒否される

PRINS

本章冒頭に説明したように、PRINSによって中継事業者を経由する際に、機密情報要素の機密性と完全性を確保しつつ、必要に応じて一部パラメターの統計・加工を可能とする。

PRINSの動作イメージ：

cSEPP: 送信する情報をJWEで暗号化する

→ cIPX (サービスの提供に伴う変更をJWSでサインして、元情報にappend)

→ pIPX (サービスの提供に伴う変更をJWSでサインして、元情報にappend) 　

→ pSEPP (暗号化解除、元情報とcIPX・pIPXからの差分を取得する。JWSを確認後、認めた変更内容をcSEPPからの元情報に適用する）

※cSEPP/cIPX: consumer SEPP/IPX
※pSEPP/pIPX: producer SEPP/IPX
※JWE: JSON Web Encryption
※JWS: JSON Web Signatures

PRINSにおける実装課題

PRINSにおける実装の問題についてはGSMA NG.132にて、下記のようにディスカッションされている。

• 運用の複雑性: シグナリングを受信するMNOは、広範なポリシーチェックを実行する必要があり、運用が複雑になる。パートナーMNOごとに保護ポリシーが異なる可能性

• パートナーMNOごとにローミング契約が異なる可能性

• VPMNおよびHPMN IPXキャリア双方に対してJSONパッチ制御が必要

• IPXの管理: オペレーターはどのIPXがメッセージの修正を許可されているか、またこれらの仲介者の公開鍵を把握しておく必要がある

参考：TLSとPRINS運用における総務省の推奨：

https://www.soumu.go.jp/main_content/000750257.pdf
N32 インタフェースに関して以下の注意事項を遵守することが望ましい。

　- PRINS または TLS セキュリティプロトコルを使用すること。中間者がメッセージの内容にアクセスする必要がない場合は、TLS によるエンドツーエンドの保護が強く推奨される。

　- N32 メッセージの保護に TLS を使用する場合：

• 組織の暗号化ポリシー(4.5.1.1 参照)に従って、安全な暗号アルゴリズムを使用した暗号ス イートの使用を確実にすること。

　- N32 メッセージの保護に PRINS を使用する場合：

• SEPP 保護ポリシーでは、仲介者がアクセスすることが明示的に要求されている情報要素を除き、すべての情報要素の暗号化を確実に行うこと。

• SEPP が、SEPP 保護ポリシーで指定された要件に準拠しない、またはメッセージ検証に失敗したすべての受信メッセージを拒否することを確実にすること。

　- 受信 N32 メッセージのレート制限を実施すること。

　- 受信 N32 メッセージのためのクロスレイヤーのなりすまし防止メカニズムを実施すること。

　- 外部エンティティとの通信において、SEPP によるトポロジーの秘匿化を実施すること。

SEPP間接続の流れ

GSMA NG.113 Annex B~Eにて各構成の接続プロシージャを詳細まとまっているので、そちらを参照するのが一番わかりやすいと思います。ここは一番シンプルなdirect TLSの場合だけ簡単に説明します

全体の流れ：

SEPP FQDN/IP discovery

⇓

TLS(N32) handshake ~ N32-c connection

⇓

N32-f connection establishment

SEPP FQDN/IP discovery

接続において最初のステップとしては、ローミング接続相手SEPPの発見とFQDN/IPアドレスの取得である。

Peer SEPP FQDN(s) discovery

• STEP 0: PLMN BのNFへのリクエストが自ネットワークのSEPPに送信される

• STEP 1～4: iSEPP（Initiating SEPP）は、DNSに対してWell-known SEPP FQDNを使用してDNS NAPTRクエリを送信する。このクエリの送信先DNSは、IPXセカンダリDNSを経由するか、直接PLMN BのAuthoritative DNSに送信するかは運用ポリシーに依存する
  ※Well-known FQDNは、0.で送信されたリクエストの3gpp-Sbi-Target-ApiRootから導き出される（例：nrf.5gc.mnc002.mcc001.3gppnetwork.org）。形式は以下の通り：　

  • sepp.5gc.mnc.mcc.3gppnetwork.org

• STEP 5～8: iSEPPはDNS SRVクエリを送信し、候補となるrSEPP（Responding SEPP）のリストを取得する。その中から一つまたは複数のSEPPを選択し、最終的に以下の例のようにIPアドレスを取得する

    sepp1.5gc.mnc345.mcc012.3gppnetwork.org        AAAA 2001:db80::1321:abcd
  
    sepp2.5gc.mnc345.mcc012.3gppnetwork.org           AAAA 2001:db80::5e0d:00de
  
    sepp3.5gc.mnc345.mcc012.3gppnetwork.org         AAAA 2001:db80::3900:0164
  

  • ※各SEPP ServerそれぞれのFQDNが利用される。形式は下記となる
    • (MNO SEPP) sepp.5gc.mnc.mcc.3gppnetwork.org
    • (non-MNO SEPP) sepp.5gc.mnc.mcc.< UNIQUE-IPX-PROVIDER-ID>.ipxnetwork.org

これでN32 handshake (TLS handshake)が可能になる

TLS handshake ~ N32-c connection

r-SEPPが発見されると、i-SEPPはTLS接続の確立を開始する。
TLS ハンドシェイク手順 (RFC8446) はN32-cとN32-fで同じ。ただし、使用される FQDN と証明書は異なる場合がある。
下記STEP9~12のように、iSEPPとrSEPP間の認証・鍵交換が行われる。

N32-c handshake (Security Capability Negotiation Procedure)
N32-cためのmTLSトンネル確立後、セキュリティ能力に関する情報が交換される

• STEP13: i-SEPP は mTLS トンネル内で HTTP/2 による N32-c 交換メッセージを r-SEPP に送信する。この際、サポートするセキュリティ能力（TLSなど）、PLMN IDリスト、およびN32-f接続確立に必要な情報（異なるFQDNを利用する場合のFQDN情報など）が含まれ送られる。受信した情報は r-SEPP 側で N32-f コンテキストとして保存される
• STEP14: r-SEPP は i-SEPP に HTTP/2 メッセージで応答し、FQDN や選択したセキュリティ能力（例: TLS）を送信する。PLMN ID の検証に失敗した場合は接続が終了され、受信した情報は i-SEPP 側で N32-f コンテキストとして保存される
• STEP15: N32-c ハンドシェイクが完了したら、mTLS 接続は切断される

N32-f connection

N32-c ハンドシェイクの後、長期間の mTLS 接続（N32-f）が、PLMN A の i-SEPP から PLMN B の r-SEPP に確立される。

• Step 16: N32-f用のFQDN/PortがN32-cと異なる場合、再度DNS解決が必要となる

• Step 17~18: N32-f用のTLSトンネルが確立され、認証・鍵交換が行われる。N32-f 証明書に N32-c 証明書に含まれていない PLMN ID がある場合、その証明書は拒否される。これで、PLMNAからPLMNBのHTTPリクエストが送信される

• Step 19以降：逆にPLMN B がPLMN AにNFサービス要求を送信する必要がある場合、同じくDNS discoveryおよびTLS connectionの確立が必要である