特表 2023-544000 ５Ｇローミングなりすまし攻撃を緩和するための方法、システム、およびコンピュータ読み取り可能な媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-10-19

(54)【発明の名称】５Ｇローミングなりすまし攻撃を緩和するための方法、システム、およびコンピュータ読み取り可能な媒体

(51)【国際特許分類】

   H04W 12/108 20210101AFI20231012BHJP

   H04W 12/069 20210101ALI20231012BHJP

【ＦＩ】

H04W12/108

H04W12/069

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023519026

(86)(22)【出願日】2021-04-29

(85)【翻訳文提出日】2023-05-23

(86)【国際出願番号】 US2021029973

(87)【国際公開番号】W WO2022066227

(87)【国際公開日】2022-03-31

(31)【優先権主張番号】17/129,441

(32)【優先日】2020-12-21

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/095,420

(32)【優先日】2020-11-11

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】202041041754

(32)【優先日】2020-09-25

(33)【優先権主張国・地域又は機関】IN

(31)【優先権主張番号】202041047779

(32)【優先日】2020-11-02

(33)【優先権主張国・地域又は機関】IN

(81)【指定国・地域】

(71)【出願人】

【識別番号】502303739

【氏名又は名称】オラクル・インターナショナル・コーポレイション

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ラジプット，ジャイ

(72)【発明者】

【氏名】マハランク，シャシキラン・バラチャンドラ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA21

5K067BB21

5K067DD17

5K067EE02

5K067EE16

5K067FF02

5K067HH22

(57)【要約】

ローミングなりすまし攻撃は、５ＧネットワークにおけるＰＬＭＮ間通信のために用いられるＮ３２－ｃハンドシェイク手順の間に仕掛けられ得る。本明細書に記載の１つの例示的な解決法は、ＳＥＰＰを利用し、Ｎ３２－ｃハンドシェイクセキュリティ機能交換メッセージにある送信者属性を、ＴＬＳハンドシェイクの間に共有されるＸ．５０９ｖ３証明書にあるエンドポイントのアイデンティティ、およびＳＥＰＰのローカルデータベースにおいて構成されたリモートＳＥＰＰのアイデンティティに照らして交差検証することによって、Ｎ３２－ｃローミングなりすまし攻撃を緩和する。

【特許請求の範囲】

【請求項1】

５Ｇローミングなりすまし攻撃を緩和するための方法であって、
ＳＥＰＰ（セキュリティエッジ保護プロキシ）が、第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第１ノードの第１識別子を取得することと、
前記ＳＥＰＰが、前記第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第１ノードの第２識別子を取得することと、
前記第１ノードの前記第１識別子と前記第２識別子を比較することと、
第１識別子と第２識別子とは一致しないと判断し、これに応答して、前記第１ノードの第２識別子が無効であると判断することと、
前記第１ノードの前記第２識別子が無効であると判断したことに応答して、前記第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックすることとを含む、方法。

【請求項2】

ＴＬＳメッセージから前記第１ノードの前記第１識別子を取得することは、前記第１識別子をＴＬＳ証明書メッセージに含まれる証明書から取得することを含む、請求項１に記載の方法。

【請求項3】

前記証明書は、Ｘ．５０９証明書を含む、請求項２に記載の方法。

【請求項4】

前記第１ノードの前記第１識別子を取得することは、前記Ｘ．５０９証明書のサブジェクトの別名フィールドから前記第１ノードのＦＱＤＮ（完全修飾ドメイン名）を抽出することを含む、請求項３に記載の方法。

【請求項5】

前記ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における応答側ＳＥＰＰであり、前記第１ノードの前記第２識別子を取得することは、前記Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素の送信者属性から、前記第１ノードの前記第２識別子を抽出することを含む、先行する請求項のいずれか１項に記載の方法。

【請求項6】

前記ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における開始側ＳＥＰＰであり、前記第１ノードの前記第２識別子を取得することは、前記Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｉｏｎＲｓｐＤａｔａ情報要素の送信者属性から前記第１ノードの前記第２識別子抽出することを含む、請求項１～４のいずれか１項に記載の方法。

【請求項7】

前記ＳＥＰＰが、第２ノードからのＴＬＳハンドシェイクメッセージから、前記第２ノードの第１識別子を取得することと、
前記第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第２ノードの第２識別子を取得することと、
前記第２ノードの前記第１識別子と前記第２識別子を比較することと、
第１識別子と第２識別子が一致すると判断することと、
前記第２ノードの前記第１識別子および前記第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、前記ピアＳＥＰＰデータベースにおいて一致する識別子を探し出すことと、
前記第２ノードの前記第１識別子と前記第２識別子が一致し、前記ピアＳＥＰＰデータベースに一致する識別子が存在すると判断したことに応答して、前記第２ノードとのＰＬＭＮ間通信を許可することとを含む、先行する請求項のいずれか１項に記載の方法。

【請求項8】

前記ＳＥＰＰが、第２ノードからのＴＬＳハンドシェイクメッセージから、前記第２ノードの第１識別子を取得することと、
前記ＳＥＰＰが、前記第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第２ノードの第２識別子を取得することと、
前記第２ノードの前記第１識別子と前記第２識別子を比較することと、
第１識別子と第２識別子が一致すると判断することと、
前記第２ノードの前記第１識別子および前記第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、前記ピアＳＥＰＰデータベースにおいて一致する識別子を探し出せないことと、
前記第２ノードの前記第１識別子と前記第２識別子が一致し、前記ピアＳＥＰＰデータベースに一致する識別子が存在しないと判断したことに応答して、前記第２ノードからのＰＬＭＮ間通信をブロックすることとを含む、先行する請求項のいずれか１項に記載の方法。

【請求項9】

５Ｇローミングなりすまし攻撃を緩和するためのシステムであって、
少なくとも１つのプロセッサと、メモリとを含むＳＥＰＰ（セキュリティエッジ保護プロキシ）と、
前記少なくとも１つのプロセッサによって実装された５Ｇローミングなりすまし攻撃緩和モジュールとを備え、前記５Ｇローミングなりすまし攻撃緩和モジュールは、
第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第１ノードの第１識別子を取得し、
前記第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第１ノードの第２識別子を取得し、
前記第１ノードの前記第１識別子と前記第２識別子を比較し、
第１識別子と第２識別子とは一致しないと判断し、これに応答して、前記第１ノードの第２識別子が無効であると判断し、
前記第１ノードの前記第２識別子が無効であると判断したことに応答して、前記第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックするように構成される、システム。

【請求項10】

前記５Ｇローミングなりすまし攻撃緩和モジュールは、前記第１ノードの前記第１識別子を、ＴＬＳ証明書メッセージに含まれる証明書から取得するように構成される、請求項９に記載のシステム。

【請求項11】

前記証明書は、Ｘ．５０９証明書を含む、請求項１０に記載のシステム。

【請求項12】

前記５Ｇローミングなりすまし攻撃緩和モジュールは、前記証明書のサブジェクトの別名フィールドから抽出される前記第１ノードのＦＱＤＮ（完全修飾ドメイン名）を抽出することによって、前記第１ノードの前記第１識別子を取得するように構成される、請求項１１に記載のシステム。

【請求項13】

前記ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における応答側ＳＥＰＰであり、５Ｇローミングなりすまし攻撃緩和モジュールは、前記Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素の送信者属性から前記第１ノードの前記第２識別子を抽出することによって、前記第１ノードの前記第２識別子を取得するように構成される、請求項９～１２のいずれか１項に記載のシステム。

【請求項14】

前記ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における開始側ＳＥＰＰであり、前記５Ｇローミングなりすまし攻撃緩和モジュールは、前記Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素の送信者情報要素属性から前記第１ノードの前記第２識別子を抽出することによって、前記第１ノードの前記第２識別子を取得するように構成される、請求項９～１２のいずれか１項に記載のシステム。

【請求項15】

前記５Ｇローミングなりすまし攻撃緩和モジュールは、
第２ノードからのＴＬＳハンドシェイクメッセージから、前記第２ノードの第１識別子を取得し、
前記第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第２ノードの第２識別子を取得し、
前記第２ノードの前記第１識別子と前記第２識別子を比較し、
第１識別子と第２識別子が一致すると判断し、
前記第２ノードの前記第１識別子および前記第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、前記ピアＳＥＰＰデータベースにおいて一致する識別子を探し出し、
前記第２ノードの前記第１識別子と前記第２識別子が一致し、前記ピアＳＥＰＰデータベースに一致する識別子が存在すると判断したことに応答して、前記第２ノードとのＰＬＭＮ間通信を許可するように構成される、請求項９～１４のいずれか１項に記載のシステム。

【請求項16】

前記５Ｇローミングなりすまし攻撃緩和モジュールは、
第２ノードからのＴＬＳハンドシェイクメッセージから、前記第２ノードの第１識別子を取得し、
前記第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第２ノードの第２識別子を取得し、
前記第２ノードの前記第１識別子と前記第２識別子を比較し、
第１識別子と第２識別子が一致すると判断し、
前記第２ノードの前記第１識別子および前記第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、前記ピアＳＥＰＰデータベースにおいて一致する識別子を探し出せず、
前記第２ノードの前記第１識別子と前記第２識別子が一致し、前記ピアＳＥＰＰデータベースに一致する識別子が存在しないと判断したことに応答して、前記第２ノードからのＰＬＭＮ間通信をブロックするように構成される、請求項９～１５のいずれか１項に記載のシステム。

【請求項17】

実行可能な命令を格納した、非一時的なコンピュータ読み取り可能な媒体であって、前記実行可能な命令は、コンピュータのプロセッサによって実行されると、ステップを実行するように前記コンピュータを制御し、前記ステップは、
ＳＥＰＰ（セキュリティエッジ保護プロキシ）が、第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第１ノードの第１識別子を取得するステップと、
前記ＳＥＰＰが、前記第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、前記第１ノードの第２識別子を取得するステップと、
前記第１ノードの前記第１識別子と前記第２識別子を比較するステップと、
第１識別子と第２識別子とは一致しないと判断し、これに応答して、前記第１ノードの第２識別子が無効であると判断するステップと、
前記第１ノードの前記第２識別子が無効であると判断したことに応答して、前記第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックするステップとを含む、非一時的なコンピュータ読み取り可能な媒体。

【請求項18】

ＴＬＳメッセージから前記第１ノードの前記第１識別子を取得するステップは、前記第１識別子をＴＬＳ証明書メッセージに含まれる証明書から取得するステップを含む、請求項１７に記載の非一時的なコンピュータ読み取り可能な媒体。

【請求項19】

前記証明書は、Ｘ．５０９証明書を含む、請求項１８に記載の非一時的なコンピュータ読み取り可能な媒体。

【請求項20】

前記第１ノードの前記第１識別子を取得するステップは、前記証明書のサブジェクトの別名フィールドから前記第１ノードのＦＱＤＮ（完全修飾ドメイン名）を抽出するステップを含む、請求項１９に記載の非一時的なコンピュータ読み取り可能な媒体。

【発明の詳細な説明】

【技術分野】

【0001】

優先権の主張
本願は、２０２０年１２月２１日に出願された米国特許出願第１７／１２９，４４１号、２０２０年１１月１１日に出願された米国特許出願第１７／０９５，４２０号、２０２０年１１月２日に出願されたインド仮出願第２０２０４１０４７７７９号、および２０２０年９月２５日に出願されたインド仮出願第２０２０４１０４１７５４号の優先権の利益を主張するものであり、これらのすべての開示内容を引用により本明細書に援用する。

【0002】

技術分野
本明細書に記載の主題は、５Ｇ通信ネットワークにおけるセキュリティを向上させることに関する。特に、本明細書に記載の主題は、５Ｇローミングなりすまし攻撃を緩和するための方法、システム、およびコンピュータ読み取り可能な媒体に関する。

【背景技術】

【0003】

背景
５Ｇ電気通信ネットワークでは、サービスを提供するネットワークノードは、プロデューサーＮＦ（ネットワーク機能）と称される。サービスを利用するネットワークノードは、コンシューマーＮＦと称される。ネットワーク機能は、サービスを利用しているかサービスを提供しているかに応じて、プロデューサーＮＦにもコンシューマーＮＦにもなり得る。

【0004】

所与のプロデューサーＮＦは、多くのサービスエンドポイントを有し得る。ここで、サービスエンドポイントとは、プロデューサーＮＦがホストする１つ以上のＮＦインスタンスの接続ポイントである。サービスエンドポイントは、ＩＰ（インターネットプロトコル）アドレスとポート番号との組合せ、またはプロデューサーＮＦをホストするネットワークノード上のＩＰアドレスおよびポート番号に変換される完全修飾ドメイン名によって識別される。ＮＦインスタンスは、サービスを提供するプロデューサーＮＦのインスタンスである。所与のプロデューサーＮＦは、２つ以上のＮＦインスタンスを含み得る。なお、複数のＮＦインスタンスが同じサービスエンドポイントを共有できる。

【0005】

プロデューサーＮＦは、ＮＲＦ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ）に登録される。ＮＲＦは、各ＮＦインスタンスがサポートするサービスを識別する利用可能なＮＦインスタンスのサービスプロファイルを保持する。コンシューマーＮＦは、ＮＲＦに登録されているプロデューサーＮＦインスタンスについての情報を受信するようにサブスクライブできる。

【0006】

コンシューマーＮＦに加えて、ＮＦサービスインスタンスについての情報を受信するようにサブスクライブできる別の種類のネットワークノードは、ＳＣＰ（Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙ）である。ＳＣＰは、ＮＲＦを介してサブスクライブし、プロデューサーＮＦサービスインスタンスに関するリーチャビリティとサービスプロファイル情報とを取得する。コンシューマーＮＦは、Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙに接続し、Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙは、要求されたサービスを提供するプロデューサーＮＦサービスインスタンス間でトラフィックの負荷を分散する、または、宛先であるプロデューサーＮＦインスタンスにトラフィックを直接ルーティングする。

【0007】

ＳＣＰに加えて、プロデューサーＮＦとコンシューマーＮＦとの間でトラフィックをルーティング中間プロキシノードまたはネットワークノード群のその他の例として、ＳＥＰＰ（セキュリティエッジ保護プロキシ）、サービスゲートウェイ、および５Ｇサービスメッシュにあるノードなどが挙げられる。ＳＥＰＰは、異なる５Ｇ ＰＬＭＮ（公衆陸上移動体通信網）間で交換されるコントロールプレーントラフィックを保護するために用いられるネットワークノードである。このように、ＳＥＰＰは、すべてのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅメッセージについてメッセージフィルタリング、ポリシング、およびトポロジ隠蔽を実行する。

【0008】

現在の５Ｇネットワークアーキテクチャでは、ＳＥＰＰ間のインタフェースであるＮ３２インタフェース上で１つの脆弱性が存在する。上記の通り、ＳＥＰＰは、ＰＬＭＮ（公衆陸上移動体通信網）のセキュリティスクリーニングノードとして機能する。Ｎ３２コントロールまたはＮ３２－ｃインタフェースは、リモートＳＥＰＰと制御メッセージを交換するために用いられる。Ｎ３２－ｃインタフェース上での通信の開始は、ＴＬＳ（トランスポートレイヤーセキュリティ）ハンドシェイク手順を含み、ＴＬＳ接続を確立する。また、通信の開始は、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順も含む。Ｎ３２－ｃセキュリティ機能ネゴシエーション手順は、Ｎ３２－ｃメッセージの交換を含む。Ｎ３２－ｃセキュリティ機能ネゴシエーション手順の間、リモートエンドポイントのアイデンティティの検証は行われない。また、リモートエンドポイントも、開始側ＳＥＰＰのアイデンティティを検証しない。Ｎ３２－ｃインタフェース上で検証が行われないので、開始側ＳＥＰＰおよび応答側ＳＥＰＰは、サードパーティがＮ３２－ｃ通信の一方のエンドになりすましてＰＬＭＮに不正アクセスする、なりすまし攻撃に対して脆弱である。

【0009】

これらのおよびその他の問題点に鑑みて、５Ｇローミングなりすまし攻撃を緩和するための方法、システム、およびコンピュータ読み取り可能な媒体が必要とされている。

【発明の概要】

【課題を解決するための手段】

【0010】

概要
５Ｇローミングなりすまし攻撃を緩和するための方法は、ＳＥＰＰ（セキュリティエッジ保護プロキシ）が、第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第１ノードの第１識別子を取得することを含む。この方法は、ＳＥＰＰが、第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第１ノードの第２識別子を取得することをさらに含む。方法は、第１ノードの第１識別子と第２識別子を比較することをさらに含む。方法は、第１識別子と第２識別子とは一致しないと判断し、これに応答して、第１ノードの第２識別子が無効であると判断することをさらに含む。方法は、第１ノードの第２識別子が無効であると判断したことに応答して、第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックすることをさらに含む。

【0011】

本明細書に記載の主題の別の態様によると、ＴＬＳメッセージから第１ノードの第１識別子を取得することは、第１識別子をＴＬＳ証明書メッセージに含まれる証明書から取得することを含む。

【0012】

本明細書に記載の主題の別の態様によると、証明書は、Ｘ．５０９証明書を含む。
本明細書に記載の主題の別の態様によると、第１ノードの第１識別子を取得することは、Ｘ．５０９証明書のサブジェクトの別名フィールドから第１ノードのＦＱＤＮ（完全修飾ドメイン名）を抽出することを含む。

【0013】

本明細書に記載の主題の別の態様によると、ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における応答側ＳＥＰＰであり、第１ノードの第２識別子を取得することは、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素の送信者属性から、第１ノードの第２識別子を抽出することを含む。

【0014】

本明細書に記載の主題の別の態様によると、ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における開始側ＳＥＰＰであり、第１ノードの第２識別子を取得することは、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｉｏｎＲｓｐＤａｔａ情報要素の送信者属性から第１ノードの第２識別子抽出することを含む。

【0015】

本明細書に記載の主題の別の態様によると、５Ｇローミングセキュリティ攻撃を緩和するための方法は、ＳＥＰＰが、第２ノードからのＴＬＳハンドシェイクメッセージから、第２ノードの第１識別子を取得することと、第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第２ノードの第２識別子を取得することと、第２ノードの第１識別子と第２識別子を比較することと、第１識別子と第２識別子が一致すると判断することと、第２ノードの第１識別子および第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、ピアＳＥＰＰデータベースにおいて一致する識別子を探し出すことと、第２ノードの第１識別子と第２識別子が一致し、ピアＳＥＰＰデータベースに一致する識別子が存在すると判断したことに応答して、第２ノードとのＰＬＭＮ間通信を許可することとを含む。

【0016】

本明細書に記載の主題の別の態様によると、５Ｇローミングセキュリティ攻撃を緩和するための方法は、ＳＥＰＰが、第２ノードからのＴＬＳハンドシェイクメッセージから、第２ノードの第１識別子を取得することと、ＳＥＰＰが、第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第２ノードの第２識別子を取得することと、第２ノードの第１識別子と第２識別子を比較することと、第１識別子と第２識別子が一致すると判断することと、第２ノードの第１識別子および第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、ピアＳＥＰＰデータベースにおいて一致する識別子を探し出せないことと、第２ノードの第１識別子と第２識別子が一致し、ピアＳＥＰＰデータベースに一致する識別子が存在しないと判断したことに応答して、第２ノードからのＰＬＭＮ間通信をブロックすることとを含む。

【0017】

本明細書に記載の主題の別の態様によると、５Ｇローミングなりすまし攻撃を緩和するためのシステムは、少なくとも１つのプロセッサと、メモリとを含むＳＥＰＰ（セキュリティエッジ保護プロキシ）を備える。このシステムは、少なくとも１つのプロセッサによって実装された５Ｇローミングなりすまし攻撃緩和モジュールをさらに備える。５Ｇローミングなりすまし攻撃緩和モジュールは、第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第１ノードの第１識別子を取得し、第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第１ノードの第２識別子を取得し、第１ノードの第１識別子と第２識別子を比較し、第１識別子と第２識別子とは一致しないと判断し、これに応答して、第１ノードの第２識別子が無効であると判断し、第１ノードの第２識別子が無効であると判断したことに応答して、第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックするように構成される。

【0018】

本明細書に記載の主題の別の態様によると、５Ｇローミングなりすまし攻撃緩和モジュールは、第１ノードの第１識別子を、ＴＬＳ証明書メッセージに含まれる証明書から取得するように構成される。

【0019】

本明細書に記載の主題の別の態様によると、５Ｇローミングなりすまし攻撃緩和モジュールは、証明書のサブジェクトの別名フィールドから第１ノードのＦＱＤＮ（完全修飾ドメイン名）を抽出することによって、第１ノードの第１識別子を取得するように構成される。

【0020】

本明細書に記載の主題の別の態様によると、ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における応答側ＳＥＰＰであり、５Ｇローミングなりすまし攻撃緩和モジュールは、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素の送信者属性から第１ノードの第２識別子を抽出することによって、第１ノードの第２識別子を取得するように構成される。

【0021】

本明細書に記載の主題の別の態様によると、ＳＥＰＰは、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順における開始側ＳＥＰＰであり、５Ｇローミングなりすまし攻撃緩和モジュールは、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素の送信者情報要素属性から第１ノードの第２識別子を抽出することによって、第１ノードの第２識別子を取得するように構成される。

【0022】

本明細書に記載の主題の別の態様によると、５Ｇローミングなりすまし攻撃緩和モジュールは、第２ノードからのＴＬＳハンドシェイクメッセージから、第２ノードの第１識別子を取得し、第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第２ノードの第２識別子を取得し、第２ノードの第１識別子と第２識別子を比較し、第１識別子と第２識別子が一致すると判断し、第２ノードの第１識別子および第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、ピアＳＥＰＰデータベースにおいて一致する識別子を探し出し、第２ノードの第１識別子と第２識別子が一致し、ピアＳＥＰＰデータベースに一致する識別子が存在すると判断したことに応答して、第２ノードとのＰＬＭＮ間通信を許可するように構成される。

【0023】

本明細書に記載の主題の別の態様によると、５Ｇローミングなりすまし攻撃緩和モジュールは、第２ノードからのＴＬＳハンドシェイクメッセージから、第２ノードの第１識別子を取得し、第２ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第２ノードの第２識別子を取得し、第２ノードの第１識別子と第２識別子を比較し、第１識別子と第２識別子が一致すると判断し、第２ノードの第１識別子および第２識別子のうち一方を用いてピアＳＥＰＰデータベースでルックアップを実行し、ピアＳＥＰＰデータベースにおいて一致する識別子を探し出せず、第２ノードの第１識別子と第２識別子が一致し、ピアＳＥＰＰデータベースに一致する識別子が存在しないと判断したことに応答して、第２ノードからのＰＬＭＮ間通信をブロックするように構成される。

【0024】

本明細書に記載の主題の別の態様によると、実行可能な命令を格納した、非一時的なコンピュータ読み取り可能な媒体を提供する。実行可能な命令は、コンピュータのプロセッサによって実行されると、ステップを実行するようにコンピュータを制御する。当該ステップは、ＳＥＰＰ（セキュリティエッジ保護プロキシ）が、第１ノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第１ノードの第１識別子を取得するステップを含む。ステップは、ＳＥＰＰが、第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第１ノードの第２識別子を取得するステップをさらに含む。ステップは、第１ノードの第１識別子と第２識別子を比較するステップと、第１識別子と第２識別子とは一致しないと判断し、これに応答して、第１ノードの第２識別子が無効であると判断するステップとをさらに含む。ステップは、第１ノードの第２識別子が無効であると判断したことに応答して、第１ノードとのＰＬＭＮ（公衆陸上移動体通信網）間通信をブロックするステップをさらに含む。

【0025】

本明細書において説明する主題は、ハードウェア、ソフトウェア、ファームウェア、または、それらの任意の組合せで実現されてもよい。このように、「機能」、「ノード」、または「モジュール」という用語は、本明細書において用いられる場合、記載の特徴を実現するためのハードウェア（ソフトウェアおよび／またはファームウェアコンポーネントも含んでもよい）を指す。一例示的な実施態様では、本明細書において説明する主題は、コンピュータにより実行可能な命令を格納したコンピュータ読み取り可能な媒体を用いて実現されてもよい。当該命令は、コンピュータのプロセッサによって実行されると、ステップを実行させるようにコンピュータを制御する。本明細書において説明する主題を実現するのに適した例示的なコンピュータ読み取り可能な媒体として、ディスク記憶装置、チップ記憶装置、プログラム可能な論理回路、および特定用途向け集積回路など、非一時的なコンピュータ読み取り可能な媒体などが挙げられる。これに加えて、本明細書において説明する主題を実現するコンピュータ読み取り可能な媒体は、１つのデバイスまたは１つのコンピューティングプラットフォーム上に位置してもよいし、複数のデバイスまたは複数のコンピューティングプラットフォーム間で分散されてもよい。

【0026】

ここで、添付の図面を参照して本明細書に記載の主題を説明する。

【図面の簡単な説明】

【0027】

【図1】例示的な５Ｇネットワークアーキテクチャを示すネットワーク図である。

【図2】ＳＥＰＰ間のＴＬＳ（トランスポートレイヤーセキュリティ）メッセージおよびＮ３２－ｃメッセージの交換を示すメッセージフロー図である。

【図3】ＳＥＰＰになりすましているハッカーを示すネットワーク図である。

【図4】ＳＥＰＰ間で交換されたＮ３２－ｃメッセージにおいて提示されたアイデンティティの検証を示すメッセージフロー図である。

【図5】Ｎ３２－ｃインタフェース上での検証が失敗すると、応答側ＳＥＰＰによってメッセージがブロックされる様子を示す図である。

【図6】Ｎ３２－ｃインタフェース上での検証が失敗すると、開始側ＳＥＰＰによってメッセージがブロックされる様子を示す図である。

【図7】５Ｇローミングなりすまし攻撃を緩和するためのＳＥＰＰの例示的なアーキテクチャを示すブロック図である。

【図8】例示的な５Ｇローミングなりすまし攻撃を緩和するための方法を示すフローチャートである。

【発明を実施するための形態】

【0028】

詳細な説明
本明細書に記載の主題は、５Ｇローミングなりすまし攻撃を緩和するための方法、システム、およびコンピュータ読み取り可能な媒体に関する。図１は、例示的な５Ｇシステムネットワークアーキテクチャを示すブロック図である。図１のアーキテクチャは、同じＨＰＬＭＮ（ホーム側公衆陸上移動体通信網）に位置し得るＮＲＦ１００とＳＣＰ１０１とを備える。上述したように、ＮＲＦ１００は、利用可能なプロデューサーＮＦサービスインスタンスのプロファイルおよびこれらがサポートするサービスを保持し、コンシューマーＮＦまたはＳＣＰが新しい／更新されたプロデューサーＮＦサービスインスタンスをサブスクライブすることまたは新しい／更新されたプロデューサーＮＦサービスインスタンスの登録について通知されることを可能にする。また、ＳＣＰ１０１は、サービス検出およびプロデューサーＮＦインスタンスの選択をサポートし得る。ＳＣＰ１０１は、コンシューマーＮＦとプロデューサーＮＦとの接続の負荷分散を行い得る。これに加えて、本明細書に記載の技法を用いて、ＳＣＰ１０１は、ＮＦの位置に基づいた、好ましい選択およびルーティングを行い得る。

【0029】

ＮＲＦ１００は、ＮＦまたはプロデューサーＮＦインスタンスのサービスプロファイルのリポジトリである。プロデューサーＮＦインスタンスと通信を行うために、コンシューマーＮＦまたはＳＣＰは、ＮＦもしくはサービスプロファイル、またはプロデューサーＮＦインスタンスをＮＲＦ１００から取得しなければならない。ＮＦまたはサービスプロファイルは、３ＧＰＰ（登録商標）（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ＴＳ（技術仕様書）２９．５１０で規定されたＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）データ構造である。ＮＦまたはサービスプロファイルの規定は、ＦＱＤＮ（完全修飾ドメイン名）、ＩＰｖ４（ＩＰ（インターネットプロトコル）バージョン４）アドレスまたはＩＰｖ６（ＩＰバージョン６）アドレスのうち、少なくとも１つを含む。図１では、すべてのノード（ＮＲＦ１００以外）は、要求側サービスであるか提供側サービスであるかに応じて、コンシューマーＮＦまたはプロデューサーＮＦのいずれかであり得る。図示した例では、これらのノードは、ネットワークにおけるポリシー関連の操作を実行するＰＣＦ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）１０２と、ユーザデータを管理するＵＤＭ（Ｕｓｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）機能１０４、アプリケーションサービスを提供するＡＦ（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）１０６とを含む。図１に示すノードは、ＡＭＦ（Ａｃｃｅｓｓ Ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１０とＰＣＦ１０２との間のセッションを管理するＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１０８をさらに含む。ＡＭＦ１１０は、４ＧネットワークにおいてＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）が実行するモビリティ管理操作と同様のモビリティ管理操作を実行する。ＡＵＳＦ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）１１２は、ネットワークにアクセスしたいＵＥ（ユーザ機器）１１４など、ＵＥ（ユーザ機器）の認証サービスを実行する。

【0030】

ＮＳＳＦ（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）１１６は、ネットワークスライスに関連する特定のネットワーク機能および特性にアクセスしたいデバイスのためのネットワークスライシングサービスを提供する。ＮＥＦ（Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）１１８は、ネットワークにアタッチされているＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）デバイスおよびその他のＵＥについての情報を取得したいアプリケーション機能のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する。ＮＥＦ１１８は、４ＧネットワークにおけるＳＣＥＦ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）と同様の機能を実行する。

【0031】

ＲＡＮ（無線アクセスネットワーク）１２０は、ワイヤレスリンクを経由してＵＥ（ユーザ機器）１１４をネットワークに接続する。無線アクセスネットワーク１２０には、ｇＮＢ（ｇ－ＮｏｄｅＢ）（図１に図示せず）またはその他のワイヤレスアクセスポイントを用いてアクセスされ得る。ＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２２は、ユーザプレーンサービスに関する様々なプロキシ機能をサポートできる。このようなプロキシ機能の一例は、ＭＰＴＣＰ（Ｍｕｌｔｉｐａｔｈ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロキシ機能である。ＵＰＦ１２２は、パフォーマンス測定機能もサポートし得る。パフォーマンス測定機能は、ネットワーク性能の測定値を取得するためにＵＥ１１４によって用いられ得る。図１には、ＵＥがインターネットサービスなどのデータネットワークサービスにアクセスするＤＮ（データネットワーク）１２４も示されている。

【0032】

ＳＥＰＰ１２６は、別のＰＬＭＮからの受信トラフィックをフィルタリングし、ホーム側ＰＬＭＮから出るトラフィックのトポロジ隠蔽を実行する。ＳＥＰＰ１２６は、外部ＰＬＭＮのセキュリティを管理する、外部ＰＬＭＮにあるＳＥＰＰと通信し得る。よって、それぞれ異なるＰＬＭＮにおけるＮＦ間のトラフィックは、ホーム側ＰＬＭＮのためのＳＥＰＰ機能および外部ＰＬＭＮのためのＳＥＰＰ機能という２つのＳＥＰＰ機能を横断し得る。

【0033】

上記の通り、既存の５Ｇアーキテクチャの１つの問題は、Ｎ３２－ｃハンドシェイクがリモートエンドポイントのＩＤを検証しないことである。エンドポイントのＩＤを検証しない場合、悪意があるＳＥＰＰが別のＳＥＰＰのアイデンティティになりすましてセキュリティ攻撃を仕掛ける可能性がある。応答側ＳＥＰＰは、Ｎ３２ハンドシェイクメッセージを正規開始側ＳＥＰＰから受信しているかどうかを検証しない。同様に、開始側ＳＥＰＰは、Ｎ３２－ｃハンドシェイクメッセージが正規応答側ＳＥＰＰに送られるかどうかを検証しない。本明細書に記載の主題は、ＳＥＰＰのＮ３２－ｃアイデンティティを、ＴＬＳレイヤーのアイデンティティ、ならびに開始側ＳＥＰＰおよび応答側ＳＥＰＰが保持するピアＳＥＰＰデータベースに格納されているピアＳＥＰＰアイデンティティと交差検証することによって、これらのおよびその他の問題点に対処する。

【0034】

図２は、Ｎ３２インタフェース上のＳＥＰＰ間でハンドシェイクが生じている様子を示す図である。図２では、開始側ＳＥＰＰ１２６Ａと、応答側ＳＥＰＰ１２６Ｂは、ＴＬＳハンドシェイクメッセージングおよびＮ３２－ｃセキュリティ機能ネゴシエーションメッセージングを、Ｎ３２インタフェース上で交換する。ＴＬＳハンドシェイクには、証明書の交換が含まれる。証明書は、ＴＬＳレイヤーにおいて送信者のアイデンティティを検証するために使用され得、なりすますことが困難である。しかしながら、ＴＬＳハンドシェイクの間に交換されるアイデンティティと、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージングの間に交換されるアイデンティティとの間には交差検証が存在しない。その結果、開始側ＳＥＰＰ１２６Ａおよび応答側ＳＥＰＰ１２６Ｂの両方が、ローミングなりすまし攻撃に対して脆弱である。ローミングなりすまし攻撃とは、携帯電話加入者がローミング中のネットワークにおいて攻撃者がノードとして装う攻撃である。Ｎ３２－ｃセキュリティ機能ネゴシエーション手順の間にノードのアイデンティティになりすます場合、攻撃者は、サブスクライバがローミング中のネットワークにサービスを提供しているＳＥＰＰのアイデンティティになりすます。

【0035】

図３は、正規ＳＥＰＰを装うハッカーＳＥＰＰ３００の例を示す図である。図３では、ＰＬＭＮ１に位置するＳＥＰＰ１２６Ａは、ＰＬＭＮ２に位置するピアＳＥＰＰ１２６Ｂと通信していると信じている。しかしながら、ハッカーＳＥＰＰ３００が正規ＳＥＰＰ１２６ＢのフリをしてＳＥＰＰ１２６ＡとのＮ３２－ｃ通信を確立している可能性がある。このような通信が確立されると、ハッカーＳＥＰＰ３００は、ＰＬＭＮ１から機密であるサブスクライバ情報を取得することができるおよび／またはＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃などその他の種類の攻撃をＰＬＭＮ１上で引き起こすことができるようになるであろう。

【0036】

Ｎ３２－ｃインタフェース上でなりすまし攻撃が成功してしまうのを回避するまたはその可能性を低くするために、ＳＥＰＰ１２６Ａおよび１２６Ｂは、Ｎ３２－ｃアイデンティティをＴＬＳアイデンティティと交差検証し得、さらに、構成済みのピアＳＥＰＰデータベースを用いてＮ３２－ｃアイデンティティをピアＳＥＰＰアイデンティティと検証し得る。図４は、開始側ＳＥＰＰ１２６Ａおよび応答側ＳＥＰＰ１２６Ｂが実行し得る例示的な交差検証を示す図である。図４を参照すると、開始側ＳＥＰＰ１２６Ａと応答側ＳＥＰＰ１２６Ｂは、Ｎ３２－ｃインタフェース上でＴＬＳハンドシェイクメッセージを交換してＴＬＳ接続を確立する。ＴＬＳハンドシェイクは、クライアントのｈｅｌｌｏメッセージとサーバのｈｅｌｌｏメッセージとの交換、続いて、証明書メッセージの交換を含む。証明書メッセージには、送信者のＸ．５０９証明書が含まれる。送信者のアイデンティティは、Ｘ．５０９証明書に含まれており、なりすますことは困難である。なぜならば、認証局によってＸ．５０９証明書に署名されているためである。

【0037】

したがって、一例では、送信者のＮ３２－ｃアイデンティティを交差検証するためにＸ．５０９証明書から抽出した送信者のアイデンティティが用いられ得る。ＴＬＳハンドシェイクプロトコルは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）５２４６において規定されており、ＴＬＳ接続の両エンドによる証明書メッセージの交換を含む。ＩＥＴＦ ＲＦＣ５２４６において規定されているＴＬＳハンドシェイクメッセージの構造（証明書メッセージを含む）は、以下のように表示される。

【0038】

【表1】

【0039】

ＴＬＳハンドシェイクメッセージの構造によって示されているように、規定されたハンドシェイクメッセージの種類の１つは、証明書メッセージである。証明書メッセージは、送信者がクライアントとして機能しているかサーバとして機能しているかに応じて、クライアントの証明書またはサーバの証明書を含む。Ｎ３２－ｃインタフェースでセキュアなＴＬＳ通信を確立する際、ＴＬＳ接続の両エンドが他方のエンドのＸ．５０９証明書を受信および検証する共通のＴＬＳまたはｍ－ＴＬＳが使用される。ＩＥＴＦ ＲＦＣ５２４６は、明らかにネゴシエーションされない限り、証明書の種類がＸ．５０９ｖ３でなければならないことを示す。本明細書に記載の実施例では、例としてＸ．５０９ｖ３証明書を用いるが、本明細書に記載の主題は、Ｘ．５０９ｖ３から抽出した送信者のアイデンティティを用いて送信者のＮ３２－ｃアイデンティティを検証することだけに限られない。Ｘ．５０９ｖ３証明書のフォーマットは、ＩＥＴＦ ＲＦＣ３２８０で規定されている。ＩＥＴＦ ＲＦＣ３２８０によると、Ｘ．５０９ｖ３証明書が含み得る拡張子またはパラメータは、サブジェクトの別名拡張である。サブジェクトの別名拡張は、次のように定義される。

【0040】

サブジェクトの別名拡張により、証明書のサブジェクトに追加のアイデンティティをバインドできるようになる。定義済みオプションは、インターネット電子メールアドレスと、ＤＮＳ名と、ＩＰアドレスと、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）とを含む。完全にローカルな定義を含む、その他のオプションも存在する。複数の名前形式、および各名前形式の複数のインスタンスが含まれてもよい。このようなアイデンティティが証明書にバインドされる時はいつも、サブジェクトの別名（発行者の別名）拡張を使わなければならない。しかしながら、ＤＮＳ名は、４．１．２．４節に記載されているように、ｄｏｍａｉｎＣｏｍｐｏｎｅｎｔ属性を用いてサブジェクトフィールドで表されてもよい。

【0041】

サブジェクトの別名は、最終的に公開鍵にバインドされると考えられるので、サブジェクトの別名のすべての部分をＣＡによって確認しなければならない。

【0042】

上記の通り、Ｘ．５０９ｖ３証明書のサブジェクトの別名拡張は、証明書のサブジェクトを識別する、認証局によって確認されるＤＮＳ名、ＩＰアドレス、またはＵＲＩを含み得る。サブジェクトの別名は認証局によって確認されるので、サブジェクトの別名をなりすますことは困難である。しかしながら、送信者が有効なＸ．５０９証明書を有していることを確実にするだけでは、Ｎ３２－ｃアプリケーションレベルで送信者のアイデンティティを検証することにならない。このような交差検証を実行するために、開始側ＳＥＰＰ１２６Ａおよび応答側ＳＥＰＰ－１２６Ｂは、Ｎ３２－ｃメッセージからアイデンティティを抽出し、これらのアイデンティティを、ＴＬＳハンドシェイクの間に共有したＸ－５０９証明書から抽出したアイデンティティと比較し得る。これらのアイデンティティが一致した場合、ＳＥＰＰ１２６Ａおよび１２６Ｂは、Ｎ３２－ｃメッセージまたはＴＬＳメッセージのいずれかから抽出したアイデンティティを構成済みピアＳＥＰＰアイデンティティのデータベースと比較するさらなる検証ステップを実行し得る。いずれの検証も失敗した場合、ＳＥＰＰは、リモートノードとのＰＬＭＮ間通信をブロックし得、リモートノードを攻撃者として識別する。

【0043】

図４に戻ると、開始側ＳＥＰＰ１２６Ａと応答側ＳＥＰＰ１２６Ｂとの間でＴＬＳハンドシェイクメッセージが交換され、ＴＬＳ接続が確立された後、開始側ＳＥＰＰ１２６Ａは、ＨＴＴＰ ＰＯＳＴメッセージを応答側ＳＥＰＰ１２６Ｂに送る。ＨＴＴＰ ＰＯＳＴメッセージは、ＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素を含む。ＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素は、送信者のＦＱＤＮを含んだ送信者情報要素を含む。応答側ＳＥＰＰ１２６Ｂは、ＨＴＴＰ ＰＯＳＴメッセージを受信し、ＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素から送信者のＦＱＤＮを抽出し、送信者のＸ．５０９証明書から取得した送信者のアイデンティティに照らしてＦＱＤＮを検証する。この場合、これらのアイデンティティが一致すると仮定する。したがって、次のステップでは、応答側ＳＥＰＰ１２６Ｂは、応答側ＳＥＰＰ１２６Ｂが保持するピアＳＥＰＰデータベースでルックアップを実行し、送信者のアイデンティティを検索する。開始側ＳＥＰＰ１２６Ａのアイデンティティが応答側ＳＥＰＰ１２６ＢのピアＳＥＰＰデータベース上に存在すると仮定するので、応答側ＳＥＰＰ１２６Ｂの観点からは両方の検証が合格となり、その結果、応答側ＳＥＰＰ１２６Ｂは、開始側ＳＥＰＰ１２６ＡからのＰＬＭＮ間通信を許可する。

【0044】

図４のメッセージフローを引き続き参照すると、応答側ＳＥＰＰ１２６Ｂは、開始側ＳＥＰＰ１２６ＡにＨＴＴＰ ２００ ＯＫ メッセージを送る。ＨＴＴＰ ２００ ＯＫ メッセージは、送信者属性を含んだＮ３２－ｃＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素を含む。図５では、送信者属性は、応答側ＳＥＰＰ１２６ＢのＦＱＤＮを保持している。開始側ＳＥＰＰ１２６Ｂは、ＨＴＴＰ ２００ ＯＫ メッセージを受信し、ＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素の送信者属性から送信者のＦＱＤＮを抽出し、このＦＱＤＮをＴＬＳ証明書メッセージから抽出した送信者のＦＱＤＮと比較する。この場合、これらのＦＱＤＮが一致すると仮定する。したがって、開始側ＳＥＰＰ１２６Ａは、開始側ＳＥＰＰ１２６Ａが保持するピアＳＥＰＰデータベースに送信者のアイデンティティが存在するかどうかを判断するさらなる検証ステップを実行する。この例では、送信者のアイデンティティが存在すると仮定するので、開始側ＳＥＰＰ１２６Ａは、応答側ＳＥＰＰ１２６ＢとのＰＬＭＮ間通信を許可する。

【0045】

図５は、Ｎ３２－ｃセキュリティ機能ネゴシエーション手順に関してハッカーＳＥＰＰ３００が開始側ＳＥＰＰである場合を説明する図である。図５では、ハッカーＳＥＰＰ３００は、応答側ＳＥＰＰ１２６ＢとのＴＬＳハンドシェイクを開始する。応答側ＳＥＰＰ１２６Ｂは、ＴＬＳハンドシェイクメッセージからＸ．５０９証明書を抽出し、証明書においてハッカーＳＥＰＰ３００が提示するアイデンティティを抽出する。ハッカーＳＥＰＰ３００は、アイデンティティをＮ３２－ｃセキュリティ機能ネゴシエーションメッセージ（図示した例では、ＨＴＴＰ ＰＯＳＴメッセージ）のＮ３２－ｃＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素に含めて応答側ＳＥＰＰ１２６Ｂに伝達する。応答側ＳＥＰＰ１２６Ｂは、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＮ３２－ｃＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素にあるハッカーＳＥＰＰ３００が提示するアイデンティティを抽出し、Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素から抽出したアイデンティティをＴＬＳメッセージから取得した証明書から抽出したアイデンティティと比較する。この場合、これらのアイデンティティは一致しない。その結果、応答側ＳＥＰＰ１２６Ｂは、検証が失敗したと判断する。したがって、応答側ＳＥＰＰ１２６Ｂは、ハッカーＳＥＰＰ３００からのその後の通信をブロックする。

【0046】

図６は、Ｎ３２－ｃセキュリティ機能ネゴシエーショントランザクションにおいてＴＬＳのアイデンティティとＮ３２－ｃのアイデンティティの交差検証を実行するＳＥＰＰが、開始側ＳＥＰＰである場合を示す図である。図６では、開始側ＳＥＰＰは、ハッカーＳＥＰＰ３００からＴＬＳメッセージおよびＮ３２－ｃメッセージを受信する。開始側ＳＥＰＰ１２６Ａは、ＴＬＳハンドシェイクメッセージのうち１つからＸ．５０９証明書を取得する。開始側ＳＥＰＰ１２６Ａは、Ｘ．５０９証明書からアイデンティティを抽出し、このアイデンティティをＮ３２－ｃセキュリティ機能ネゴシエーションメッセージ（図示した例では、ＨＴＴＰ ２００ ＯＫ メッセージ）のＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素にあるハッカーＳＥＰＰ３００から受信したアイデンティティと比較する。この場合、これらのアイデンティティは、一致しない。したがって、開始側ＳＥＰＰ１２６Ａは、ハッカーＳＥＰＰ３００とのその後の通信をブロックする。

【0047】

図７は、ＳＥＰＰ１２６Ａまたは１２６Ｂの例示的なアーキテクチャを示すブロック図である。ＳＥＰＰ１２６Ａまたは１２６Ｂは、少なくとも１つのプロセッサ７００と、メモリ７０２とを備える。ＳＥＰＰ１２６Ａまたは１２６Ｂは、Ｎ３２－ｃメッセージにあるアイデンティティとＴＬＳメッセージから抽出したアイデンティティと交差検証するための本明細書に記載のこれらのステップを実行する５Ｇローミングなりすまし緩和モジュール７０４をさらに備える。ＳＥＰＰ１２６Ａまたは１２６Ｂは、ＰＬＭＮ間通信が許可されているピアＳＥＰＰのアイデンティティで構成されたピアＳＥＰデータベース７０６をさらに備える。５Ｇローミングなりすまし緩和モジュール７０４は、プロセッサ７００によって実装され得、また、データベース７０６に格納されているピアＳＥＰＰアイデンティティに照らして、リモートノードが提示するＮ３２－ｃアイデンティティのクロスチェックを実行し得る。Ｎ３２－ｃセキュリティ機能ネゴシエーションメッセージにおいて提示されたリモートノードのアイデンティティがデータベース７０６に存在しない場合、または、ＴＬＳアイデンティティとのクロスチェックが失敗した場合、５Ｇローミングなりすまし緩和モジュール７０４は、リモートノードとのＰＬＭＮ間通信をブロックし得る。両方のアイデンティティクロスチェックが合格であった、５Ｇローミングなりすまし緩和モジュール７０４は、リモートノードとのＰＬＭＮ間通信を許可し得る。

【0048】

図８は、５Ｇスピーキング攻撃を緩和するための例示的な方法を示すフローチャートである。図８を参照すると、ステップ８００では、ＳＥＰＰが、第１ノードからのＴＬＳメッセージから第１識別子を取得する。たとえば、開始側または応答側ＳＥＰＰ１２６Ａまたは１２６Ｂは、送信側ノードから受信したＴＬＳメッセージにあるＸ．５０９証明書の別ＩＤフィールドから、送信側ノードのアイデンティティを抽出し得る。ＴＬＳメッセージは、リモートノードとのＴＬＳ接続を確立するための用いられるＴＬＳハンドシェイク手順の一部としてリモートノードと交換しる証明書メッセージであり得る。

【0049】

ステップ８０２では、ＳＥＰＰは、第１ノードからのＮ３２－ｃセキュリティ機能ネゴシエーションメッセージから、第１ノードの第２識別子を取得する。たとえば、ＳＥＰＰがＮ３２－ｃセキュリティ機能ネゴシエーショントランザクションを目的とする開始側ＳＥＰＰである場合、開始側ＳＥＰＰは、リモートノードからのＨＴＴＰ ２００ ＯＫ メッセージのＮ３２－ｃＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素の送信者ＩＤ属性から、Ｎ３２ｃアイデンティティを抽出し得る。ＳＥＰＰがＮ３２－ｃセキュリティ機能ネゴシエーショントランザクションを目的とする応答側ＳＥＰＰである場合、応答側ＳＥＰＰは、リモートノードからのＨＴＴＰ ＰＯＳＴメッセージのＮ３２－ｃＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素の送信者ＩＤ属性から、Ｎ３２ｃアイデンティティを抽出し得る。以下に示す表１および表２は、Ｎ３２－ｃセキュリティ機能ネゴシエーションの一部であるＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａおよびＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素に含まれ得る属性を示す、３ＧＰＰ ＴＳ２９．５７３の表６．１．５．２．２．１および表６．５．１．２．２に対応する。

【0050】

【表2】

【0051】

【表3】

【0052】

表１および表２からわかるように、送信者属性は、ＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素およびＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素の必須パラメータであり、リクエストまたはレスポンスを送るＳＥＰＰのＦＱＤＮを含む。ＴＬＳレイヤーのアイデンティティと交差検証され得るのはこのＦＱＤＮである。

【0053】

ステップ８０４では、ＳＥＰＰは、第１ノードの第１識別子と第２識別子を比較する。たとえば、ＳＥＰＰは、Ｘ．５０９証明書から抽出したＴＬＳ識別子をＮ３２－ｃセキュリティ機能ネゴシエーションメッセージのＳｅｃＮｅｇｏｔｉａｔｅＲｓｐＤａｔａ情報要素またはＳｅｃＮｅｇｏｔｉａｔｅＲｅｑＤａｔａ情報要素から抽出したＮ３２－ｃ識別子と比較し得る。

【0054】

ステップ８０６では、これらの識別子が一致しなかった場合、制御は、ステップ８０８に進む。ステップ８０８では、ＳＥＰＰが、第１ノードの第２の（Ｎ３２－ｃ）アイデンティティを無効であると分類する。その後、制御は、ステップ８１０に進む。ステップ８１０では、ＳＥＰＰは、第１ノードからのＰＬＭＮ間通信をブロックする。

【0055】

ステップ８０６に戻ると、ＴＬＳのアイデンティティとＮ３２－ｃアプリケーションレイヤーのアイデンティティが一致した場合、制御は、ステップ８１２に進む。ステップ８１２では、ＳＥＰＰは、ピアＳＥＰＰデータベースでルックアップを実行し、第１ノードのアイデンティティを検索する。ステップ８０６においてＴＬＳレイヤーのアイデンティティとＮ３２ｃ（アプリケーション）レイヤーのアイデンティティが一致したので、ＴＬＳレイヤーのアイデンティティまたはＮ３２－ｃレイヤーのアイデンティティのいずれかを用いてルックアップが実行され得る。ネットワーク事業者のネットワークにある所与のＳＥＰＰが通信を許可されるＳＥＰＰのアイデンティティを有するピアＳＥＰＰデータベースが事業者によってプロビジョニングされ得る。このようなＳＥＰＰは、本明細書において、ピアＳＥＰＰと称する。なぜならば、ピアネットワーク事業者のＰＬＭＮと対応付けられ得るためである。

【0056】

ステップ８１４では、ピアＳＥＰＰデータベースにアイデンティティが存在する場合、制御は、ステップ８１６に進む。ステップ８１６では、ＳＥＰＰは、第１ノードとのＰＬＭＮ間通信を許可する。データベースにアイデンティティが存在しない場合、制御は、ステップ８１０に進む。ステップ８１０では、ＳＥＰＰは、第１ノードとのＰＬＭＮ間通信をブロックする。

【0057】

本明細書に記載の主題は、異なるネットワークプロトコルレイヤーにあるＳＥＰＰ間で交換されるアイデンティティの交差検証を実行することによって、ＳＥＰＰとＰＬＭＮとの間のネットワークセキュリティを改善する。Ｎ３２－ｃアイデンティティを、なりすますことが困難なＴＬＳレイヤーアイデンティティと比較することによって、本明細書に記載のＳＥＰＰは、Ｎ３２－ｃセキュリティ機能交換手順の間になりすまし攻撃が成功する可能性を低くする。これに加えて、本明細書に記載の交差検証ステップを、Ｎ３２セキュリティ機能ネゴシエーションにおける開始側ＳＥＰＰおよび応答側ＳＥＰＰの両方で実行できるので、攻撃者がＮ３２－ｃ接続のいずれのエンドになりすましてしまうことが成功する可能性を低くする。

【0058】

下記文献の各々の開示内容のすべてを引用により本明細書に援用する。
文献
1. IETF RFC5246; The Transport Layer Security (TLS) Protocol, Version 1.2; August 2008
2. IETF RFC3280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.
3. 3GPP TS 29.573; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07)
4. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07).
5. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16), V16.4.0 (2020-07).
今回開示した主題の様々な詳細は、今回開示した主題の範囲を逸脱することなく変更してもよいことが理解されるであろう。さらには、上記の説明は、あくまで例示にすぎず、限定ではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】