(57)【要約】ワイヤレス・バックホール・ネットワークにおけるネットワーク・セキュリティーのためのデジタル証明書の配布を管理するためのインフラストラクチャーが提供される。複数の実施形態においては、ルート証明書マネージメント・システム（ルートＣＭＳ）が、デジタル証明書を求める要求を処理し、ルート証明書を発行し、サロゲート証明書マネージメント・システム（ｓｕｒ−ＣＭＳ）を自動的に認証し、証明書要求を自動的に処理し、成功裏に認証されるｓｕｒ−ＣＭＳに証明書バンドルを発行する。このインフラストラクチャーは、複数のｓｕｒ−ＣＭＳを含み、それらのｓｕｒ−ＣＭＳに、それぞれの領域内で基地局が割り当てられている。それぞれのｓｕｒ−ＣＭＳは、自分自身の基地局を自動的に認証し、証明書要求を自動的に処理し、成功裏に認証される基地局に証明書バンドルを発行する。基地局に発行される証明書バンドルは、発行を行うｓｕｒ−ＣＭＳによって署名された、かかる基地局のパブリック・キーのデジタル証明書と、ルートＣＭＳの自己署名された証明書を含む少なくとも１つのさらなるデジタル証明書とを含む。
2014512120.tif 000002
【特許請求の範囲】
【請求項１】
デジタル・ストレージ・デバイスと、
前記デジタル・ストレージ・デバイスと通信状態にある１つまたは複数のプロセッサと
を含むシステムであって、前記１つまたは複数のプロセッサが、
デジタル証明書を求める要求を処理するように、およびルート証明書を発行するように構成され、サロゲート証明書マネージメント・システム（ｓｕｒ−ＣＭＳ）を自動的に認証するように構成され、証明書要求を自動的に処理するように、および成功裏に認証されるｓｕｒ−ＣＭＳに証明書バンドルを発行するように構成されているルート証明書マネージメント・システム（ルートＣＭＳ）と、
複数のｓｕｒ−ＣＭＳとを実施するように構成されており、前記複数のｓｕｒ−ＣＭＳのそれぞれが、それぞれの領域内で自分に割り当てられている１つまたは複数の基地局を有し、
前記複数のｓｕｒ−ＣＭＳのそれぞれが、自分自身の基地局を自動的に認証するように構成され、証明書要求を自動的に処理するように、および成功裏に認証される基地局に証明書バンドルを発行するように構成されており、
基地局に発行されるそれぞれの証明書バンドルが、発行を行うｓｕｒ−ＣＭＳによって署名された、かかる基地局のパブリック・キーのデジタル証明書と、前記ルートＣＭＳの自己署名された証明書を含む少なくとも１つのさらなるデジタル証明書とを含み、
前記複数のｓｕｒ−ＣＭＳのそれぞれが、証明書バンドルに関連する認証トランザクションの成功または失敗を示す信号を基地局から受信するように構成されている、システム。
【請求項２】
前記ルートＣＭＳと、前記複数のｓｕｒ−ＣＭＳのうちの少なくとも１つとが、前記それぞれの領域のうちの１つまたは複数における少なくとも１つのセキュリティー・ゲートウェイ・アグリゲータ（ＳＥＧ）を自動的に認証するように、および証明書要求を自動的に処理するように、および成功裏に認証されるＳＥＧに証明書バンドルを発行するようにさらに構成されている、請求項１に記載のシステム。
【請求項３】
前記ルートＣＭＳが、認証局（ＣＡ）によって認証されるように、および前記ＣＡによって発行されたデジタル証明書を受信するように構成されており、前記デジタル証明書が、パブリック・キーを前記ルートＣＭＳに結び付ける、請求項１に記載のシステム。
【請求項４】
基地局に発行されるそれぞれの証明書バンドルが、パブリック・キーを前記ルートＣＭＳに結び付ける前記デジタル証明書をさらに含み、前記ＣＡの自己署名された証明書をさらに含む、請求項３に記載のシステム。
【請求項５】
前記ルートＣＭＳが、前記ＣＡを認証するように、および証明書要求を処理するように、および前記ＣＡにデジタル証明書を発行するように構成されており、前記デジタル証明書が、パブリック・キーを前記ＣＡに結び付ける、請求項３に記載のシステム。
【請求項６】
デジタル証明書を配布するための証明書マネージメント・システム（ＣＭＳ）を使用する種類のワイヤレス・ネットワークにおいて実行される方法であって、
サロゲートＣＭＳ（ｓｕｒ−ＣＭＳ）によって、前記ｓｕｒ−ＣＭＳがルートＣＭＳからデジタル証明書を得る結果となる認証手順を実行するステップと、
前記ｓｕｒ−ＣＭＳによって、１つまたは複数の基地局を自動的に認証するステップと、
前記ｓｕｒ−ＣＭＳによって、それぞれの認証された基地局にデジタル証明書バンドルを自動的に発行するステップとを含み、前記バンドルが、前記発行するステップを行うｓｕｒ−ＣＭＳによって署名された、かかる基地局のパブリック・キーのデジタル証明書と、前記ルートＣＭＳの自己署名された証明書を含む少なくとも１つのさらなるデジタル証明書とを含み、
前記ｓｕｒ−ＣＭＳが、証明書バンドルに関連する認証トランザクションの成功または失敗を示す信号を基地局から受信するように構成されている、方法。
【請求項７】
前記ｓｕｒ−ＣＭＳによって、少なくとも１つのセキュリティー・ゲートウェイ・アグリゲータ（ＳＥＧ）を自動的に認証するステップと、
前記ｓｕｒ−ＣＭＳによって、それぞれの認証されたＳＥＧにデジタル証明書バンドルを自動的に発行するステップと
をさらに含む、請求項６に記載の方法。
【請求項８】
それぞれの認証された基地局に発行される前記デジタル証明書バンドルが、前記ルートＣＭＳによって発行された、前記ルートＣＭＳとは異なる認証局のデジタル証明書をさらに含む、請求項６に記載の方法。
【請求項９】
デジタル証明書を配布するための証明書マネージメント・システム（ＣＭＳ）を使用する種類のワイヤレス・ネットワークにおいて実行される方法であって、
基地局によって、前記基地局がサロゲートＣＭＳ（ｓｕｒ−ＣＭＳ）からデジタル証明書バンドルを受信する結果となる認証手順を実行するステップと、
前記基地局によって、前記基地局がセキュリティー・ゲートウェイ・アグリゲータ（ＳＥＧ）との間でセキュアなトンネルをセットアップする結果となる認証手順を実行するステップとを含み、
前記ｓｕｒ−ＣＭＳから受信される前記証明書バンドルが、前記ｓｕｒ−ＣＭＳによって署名されたデジタル証明書と、ルートＣＭＳによって自己署名されたデジタル証明書とを含み、
前記基地局が、証明書バンドルに関連する認証トランザクションの成功または失敗を示す信号を前記ｓｕｒ−ＣＭＳへ送信するように構成されている、方法。
【請求項１０】
前記ｓｕｒ−ＣＭＳから受信された前記証明書バンドルが、前記ルートＣＭＳによって発行された、前記ルートＣＭＳとは異なる認証局（ＣＡ）のデジタル証明書をさらに含み、
前記基地局と前記ＳＥＧとの間における前記認証手順が、少なくとも、
前記ルートＣＭＳによって自己署名された前記デジタル証明書と、
前記ルートＣＭＳによって発行された、前記ルートＣＭＳとは異なるＣＡの前記デジタル証明書と
を使用する、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セキュリティー・プロトコルを認証するためにワイヤレス・ネットワークにおいてネットワーク要素によって使用されるセキュリティー・デジタル証明書を管理するためのシステムおよび方法に関する。
【背景技術】
【０００２】
ワイヤレス・ネットワークにおける無線アクセス・ネットワーク（ＲＡＮ：Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）は、ワイヤレス高速パケット・データを搬送すること、ならびにその他のパケット・データ・ネットワークとインターフェースを取ること、およびその他のパケット・データ・ネットワークとともに機能することに対する高まる必要性に応えるために、回路交換ネットワークからパケット交換ネットワークへと進化してきている。４Ｇワイヤレス、および特にＬＴＥテクノロジーの出現によって、通信のためのオールＩＰベースのプロトコルを伴う、より高速な、よりフラットなネットワーク・アーキテクチャーが強いられてきた。より古いネットワークと比較して、ＬＴＥネットワークは、たとえば、より少ないアンカー・ポイントと、エッジにおけるコントロール・ロジックのより広い配布と、複数のオペレータの間におけるトランスポート共有を促進する高いセル帯域幅とを有する。１つの結果として、コンピュータ、サーバ、ルータ、および基地局などのＲＡＮネットワーク要素（ＮＥ：ｎｅｔｗｏｒｋ  ｅｌｅｍｅｎｔ）、ならびにそれらの間におけるインターフェースが、ＩＰトラフィックにさらされる。これは、ネットワーク・レイヤおよびより高位のレイヤにおけるＮＥにセキュリティー上の脅威および脆弱性をもたらす。そのような脅威および脆弱性を解消する必要がある。
【０００３】
そのような脅威および脆弱性からＲＡＮネットワーク要素を保護するためにネットワーク・オペレータたちが採用してきた１つの防御策は、ＲＡＮによって使用されている通信プロトコルのセキュアなバージョンを実施することであった。１つの例は、ＩＰセキュリティー（「ＩＰｓｅｃ」）として知られているセキュアなプロトコルのスイートであり、これは、ＩＰレイヤにおけるパケットのセキュアなやり取りをサポートするためにインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）によって開発された。
【０００４】
数ある有利な特性の中でも、ＩＰｓｅｃはスケーラブルであり、それによって、ＬＡＮからグローバル・ネットワークまでのすべてのサイズのネットワークにおいてサポートされることが可能である。ＩＰｓｅｃは、低位のネットワーク・レイヤにおいて機能し、したがって、ユーザ、アプリケーション、およびより高いレベルのプロトコルによって影響されない。ＩＰｓｅｃは、特定のアプリケーションには限定されない。ＩＰｓｅｃは、トランスポート・プロトコル（たとえばＴＣＰ、ＵＤＰ、ＳＣＴＰ）のアップグレード、またはより高位のレイヤのプロトコル（たとえばｈｔｔｐ、ｆｔｐ、ＳＳＨ）およびアプリケーションのアップグレードを必要としない。ＩＰｓｅｃは、ＩＰパケットどうしをカプセル化して、ＩＰｓｅｃトンネルを形成することができ、ＩＰｓｅｃトンネルは、それらのパケットの元の特性を保護し、ネットワーク・レイヤにおけるセキュアなＶＰＮを提供する。
【０００５】
ＩＰｓｅｃは、ソースの認証、インテグリティーの保護、およびパケットごとの暗号化をサポートする。それを行うために、ＩＰｓｅｃは、２つのＩＰｓｅｃピアの間において共有されるシークレット・キーと、ＩＰｓｅｃのアクティブ化中に２つのピアの間において合意されるいくつかの対称暗号化アルゴリズム（「対称暗号アルゴリズム」）の実行とに依存する。対称暗号アルゴリズムは、それぞれのＩＰｓｅｃピア内に格納されている事前に確立されたキーからＩＰｓｅｃが得るセッション・キーを使用する。インターネット・キー・エクスチェンジ（「ＩＫＥ」）と呼ばれるプロトコルは、ＩＰｓｅｃのアクティブ化中に、およびキーがリフレッシュされるときに、キー交渉およびキー合意を実施する。
【０００６】
ＩＫＥは、ＩＰｓｅｃがアクティブ化されるときに実行される最初のプロトコルである。ＩＫＥの現在の２つの標準バージョン、すなわちＩＫＥｖ１およびＩＫＥｖ２は、相互に互換性がないが、特定の特性を共通に有しており、ここでは、それらの特性について簡潔に説明する。ＩＫＥの両方のバージョンは、２つのフェーズにおいてメッセージのやり取りを実行する。第１のフェーズにおいては、ＩＫＥが、２つのＩＰｓｅｃピアの間においてセキュリティー・アソシエーションをセットアップするためにセキュアなチャネルを設定する。第２のフェーズにおいては、ＩＫＥピアどうしが互いを認証する。どちらかのフェーズが失敗した場合には、ＩＰｓｅｃ接続が終了される。
【０００７】
ＩＫＥ認証のいくつかの代替方法が知られている。１つの広く使用されている方法においては、ＩＫＥ認証フェーズ中に２つのＩＰｓｅｃピアの間においてＸ．５０９デジタル証明書がやり取りされる。よく知られている手順によれば、それらのデジタル証明書は、認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ）から得られる。デジタル証明書は、パブリック・キーを多くのＩＤタイプ、データ情報、およびフォーマットに結び付けるための高い柔軟性を提供する。Ｘ．５０９は、パブリック・キー・インフラストラクチャーに関するＩＴＵ−Ｔからの標準である。ＩＴＵ−Ｔは、国際電気通信連合の電気通信標準化部門である。
【０００８】
たとえば、基地局、ＬＴＥバックホール・ネットワーク内のサーバ、またはＩＰホストとして機能するその他の何らかのエンティティーが、パブリック・キーおよびホストＩＤをパラメータとしてホスト・デジタル証明書内に挿入することによってホスト・パブリック・キーをホストＩＤに結び付けることができ、それによってＩＰホスト証明書は、これらのパラメータの両方を含むことになる。
【０００９】
ＩＫＥ相互認証のためにデジタル証明書を使用する方法は有利である。なぜなら、数ある理由の中でも、それらはスケーラブルであるためである。複数のノードからなるネットワーク内でＩＰｓｅｃがアクティブ化されるときにそれぞれのノードを認証するために必要とされる証明書の数は、ノードの数に比例する。
【００１０】
ＩＫＥ認証中に、それぞれのピアは、自分のＩＤの証明を提供するために証明書バンドル（１つのバンドルは、典型的には、１〜３個の証明書を収納している）をやり取りする。このバンドルは、ＩＰホストのＩＤからスタートして、受信者によって信頼されるアンカーへと至る信頼されるパスを定義する証明書の委任の連鎖を形成する。証明書から証明書へ、信頼されるアンカーからピア証明書へ、委任の連鎖の妥当性を確認することができる場合には、ＩＫＥピアは認証される。認証手順を成功裏に完了させるためには、それぞれのＩＫＥピアには、証明書の正しいバンドルを供給する必要があり、さもないと、ＩＫＥ認証フェーズは失敗することになる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ワイヤレス・バックホールなどの大型のネットワークの需要を満たすことができるようにデジタル証明書を管理およびリフレッシュするための手順を自動化する必要がある。
【課題を解決するための手段】
【００１２】
我々は、大型のワイヤレス・バックホール・ネットワークにおけるデジタル証明書のマネージメントのための自動化された方法を開発した。我々は、我々の自動化された方法を階層的な方法と呼んでいる。なぜなら、この方法は、デジタル証明書を管理するノードの複数のレベルに依存するためである。後ほど、いくつかの実施態様について説明するが、それぞれの実施態様は、証明書の委任に関与するノードの特定のモデル階層を有している。説明する実施態様のそれぞれにおいては、証明書のマネージメントが、セキュアな認証されたチャネルを介して実行され、それによって、正当な認証情報のみがＩＫＥピアへ送信され、ＩＫＥピアによって受け入れられると想定される。
【００１３】
したがって、システムの実施態様においては、ルート証明書マネージメント・システム（ルートＣＭＳ：ｒｏｏｔ  ｃｅｒｔｉｆｉｃａｔｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）が、ルート証明書を発行する権限を与えられている。ルートＣＭＳは、サロゲート証明書マネージメント・システム（ｓｕｒｒｏｇａｔｅ  ｃｅｒｔｉｆｉｃａｔｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）（ｓｕｒ−ＣＭＳ）を自動的に認証するように、および成功裏に認証されるいかなるｓｕｒ−ＣＭＳにも証明書バンドルを自動的に発行するように構成されている。このシステムは、複数のｓｕｒ−ＣＭＳを含み、それらのｓｕｒ−ＣＭＳのそれぞれは、それぞれの領域内で自分に割り当てられている１つまたは複数の基地局を有する。それぞれのｓｕｒ−ＣＭＳは、自分自身の基地局を自動的に認証するように、および自分が成功裏に認証するそれぞれの基地局に証明書バンドルを自動的に発行するように構成されている。基地局に発行されるそれぞれの証明書バンドルは、発行を行うｓｕｒ−ＣＭＳによって署名された、かかる基地局のパブリック・キーのデジタル証明書を含む。基地局に発行されるそれぞれの証明書バンドルはまた、ルートＣＭＳの自己署名された証明書を含む少なくとも１つのさらなるデジタル証明書を含む。
【図面の簡単な説明】
【００１４】
【図１】典型的なＬＴＥネットワークのハイレベル概略図である。
【図２】ＬＴＥネットワークのうちでセキュリティー対策が実施されている部分のハイレベル概略図である。
【図３】ワイヤレス・ネットワークにおいてデジタル証明書を管理するためのさまざまなＣＭＳ階層アーキテクチャー・モデルの概略図である。それぞれの図の同様の要素は、同様の参照番号によって示されている。図３は、オペレータ認証局（ＣＡ）が存在せず、すべてのノードがＲＯＯＴ  ＣＭＳのＣＡを信頼しているモデルの概略図である。
【図４】ワイヤレス・ネットワークにおいてデジタル証明書を管理するためのさまざまなＣＭＳ階層アーキテクチャー・モデルの概略図である。それぞれの図の同様の要素は、同様の参照番号によって示されている。図４は、オペレータがＣＡを所有しており、すべてのノードがオペレータＣＡを信頼しているモデルの概略図である。
【図５】ワイヤレス・ネットワークにおいてデジタル証明書を管理するためのさまざまなＣＭＳ階層アーキテクチャー・モデルの概略図である。それぞれの図の同様の要素は、同様の参照番号によって示されている。図５は、オペレータＣＡが存在し、基地局がＲＯＯＴ  ＣＭＳのＣＡを信頼しており、ＳＥＧがオペレータＣＡを信頼している直接相互認証モデルの概略図である。
【図６】２つの信頼される当局が存在するモデルの概略図である。すなわち、基地局は、ＲＯＯＴ  ＣＭＳのＣＡを信頼しており、ＳＥＧは、外部のＣＡを信頼している。
【図７】本明細書において記載されているデジタル証明書マネージメントのいくつかのユース・ケースを示すプロトコル・メッセージング図（ｐｒｏｔｏｃｏｌ  ｍｅｓｓａｇｉｎｇ  ｄｉａｇｒａｍ）である。
【図８】本明細書において記載されているデジタル証明書マネージメントのいくつかのユース・ケースを示すプロトコル・メッセージング図（ｐｒｏｔｏｃｏｌ  ｍｅｓｓａｇｉｎｇ  ｄｉａｇｒａｍ）である。
【図９】本明細書において記載されているデジタル証明書マネージメントのいくつかのユース・ケースを示すプロトコル・メッセージング図（ｐｒｏｔｏｃｏｌ  ｍｅｓｓａｇｉｎｇ  ｄｉａｇｒａｍ）である。
【図１０】本明細書において記載されているデジタル証明書マネージメントのいくつかのユース・ケースを示すプロトコル・メッセージング図（ｐｒｏｔｏｃｏｌ  ｍｅｓｓａｇｉｎｇ  ｄｉａｇｒａｍ）である。
【図１１】本明細書において記載されているデジタル証明書マネージメントのいくつかのユース・ケースを示すプロトコル・メッセージング図（ｐｒｏｔｏｃｏｌ  ｍｅｓｓａｇｉｎｇ  ｄｉａｇｒａｍ）である。
【発明を実施するための形態】
【００１５】
図１を参照して、ＬＴＥネットワークの一般的な特徴について、はじめに簡潔に説明する。本発明については、ＬＴＥネットワークにおける本発明の実施態様を具体的に参照して説明するが、そのような説明は、純粋に例示を目的としたものであり、本発明の適用の範囲がそのように限定されることを意味することは意図されていない。たとえば、我々の方法をその一般的な態様において実施することができるその他の種類のネットワークとしては、ＷｉＦｉ、ＷＣＤＭＡ、ＣＤＭＡ／ＥＶＤＯ、およびＧＳＭが含まれる。
【００１６】
ＬＴＥは、オールＩＰのネットワーキング・アーキテクチャーを含むＵＭＴＳ電気通信に対する第４世代の機能強化である。ＬＴＥは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ：ｔｈｅ  ３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）による一連のリリースを通じて導入されている。ＬＴＥにおいては、ＧＰＲＳコア・ネットワークが、フラットなＩＰベースのネットワーク・アーキテクチャーであるシステム・アーキテクチャー・エボリューション（ＳＡＥ）によって取って代わられている。ＬＴＥは端から端までオールＩＰであるため、ＬＴＥ用のモバイル・ハンドセットおよびその他の端末デバイス１００は、組み込まれたＩＰ機能を有しており、Ｅｖｏｌｖｅｄ  ＮｏｄｅＢ（ｅＮｏｄｅＢ）と呼ばれる基地局１２０は、ＩＰベースである。
【００１７】
発展型パケット・コア（ＥＰＣ）１３０は、ＳＡＥのメイン・アーキテクチャー・コンポーネント（ｍａｉｎ  ａｒｃｈｉｔｅｃｔｕｒａｌ  ｃｏｍｐｏｎｅｎｔ）である。ＥＰＣは、サービング・ゲートウェイ（ＳＧＷ）１４０、パケット・データ・ネットワーク・ゲートウェイ（ＰＧＷ）１５０、モビリティー・マネージメント・エンティティー（ＭＭＥ）１６０、ならびにポリシーおよび課金ルール機能（ＰＣＲＦ：Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）１７０という４つの要素を含んでいることが、図から見て取れるであろう。ＳＣＷ、ＰＧＷ、およびＭＭＥは、３ＧＰＰリリース８において導入され、ＰＣＲＦは、３ＧＰＰリリース７において導入された。
【００１８】
ＳＧＷは、データ・プレーン要素である。その主要な機能は、ユーザプレーンのモビリティーを管理すること、および無線アクセス・ネットワーク（ＲＡＮ）とコア・ネットワークとの間における分界点として機能することである。ＳＧＷは、ｅＮｏｄｅＢとＰＧＷとの間におけるデータ・パスを保持する。
【００１９】
ＰＧＷは、パケット・データ・ネットワークへのパケット・データ・インターフェースの終端点である。したがってＰＧＷは、ＵＥに関する、すなわち、ユーザ端末に関するトラフィックのための入口点および出口点である。ＰＧＷは、リソースの割り当ておよび使用、パケットのフィルタリング、ならびに課金に関する、オペレータによって定義されたポリシーをサポートする。
【００２０】
ＭＭＥは、ネットワーク接続へのＵＥのアクセス、ネットワーク・リソースの割り当て、ならびにトラッキング、ページング、ローミング、およびハンドオーバをサポートするためのモビリティー状態のマネージメントを管理するためのシグナリング機能およびコントロール機能と、サブスクライバーおよびセッション・マネージメントに関連したその他のすべてのコントロールプレーン機能とを実行する。
【００２１】
ＰＣＲＦは、サービス・データ・フローの検知、ポリシーの実施、およびフローベースの課金をサポートする。（ＬＴＥにおいては、サービス・データ・フロー−ＳＤＦ−は、データプレーン・トラフィックを搬送する仮想接続である。）
【００２２】
ＩＭＳサービスをサポートするためのＩＭＳ管理ネットワーク１８０、およびホーム・サブスクライバー・サーバ（ＨＳＳ）１９０も、ＥＰＣに関連して図に示されており、ＨＳＳ１９０は、ユーザ・データベースを含み、数ある中でも、サブスクライバーの認証、位置特定、およびサブスクリプション・サービスを提供することによってコールを取り扱うＩＭＳネットワーク・エンティティーをサポートする。ＯＡＭサーバ２００も、図に示されており、ＯＡＭサーバ２００は、ＬＴＥネットワークに関するオペレーション機能、管理機能、およびメンテナンス機能を提供する。
【００２３】
図１をさらに参照すると、イーサネット・バックホール・ネットワーク２１０が、ｅＮｏｄｅＢどうしを互いに、およびＥＰＣに接続していることが見て取れるであろう。ｅＮｏｄｅＢ１２０を含む無線アクセス・ネットワークと、ネットワーク２１０との間におけるさまざまな相互接続を、ネットワークレベルのマルチレイヤ・スイッチ（ＭＬＳ）２２０によって仲介することができる。バックホールとＥＰＣサーバとの間における通信のために通信ネットワーク２３０を提供することができ、バックホールとＯＡＭサーバとの間における通信のために通信ネットワーク２４０を提供することができる。ネットワーク２３０および２４９などのネットワークは、典型的には、ネットワーク・オペレータによって所有されているプライベート・ネットワークである。
【００２４】
図２は、セキュリティー対策が実施されているＬＴＥネットワーク・アーキテクチャーの一例を示している。図１と共通の図要素は、同様の参照番号によって示されている。図２においては、ネットワークレベルのレイヤ間切り替えネットワーク（ｎｅｔｗｏｒｋ−ｌｅｖｅｌ  ｉｎｔｅｒｌａｙｅｒ  ｓｗｉｔｃｈｉｎｇ  ｎｅｔｗｏｒｋ）（図１においては、参照番号２２０によって示されている）が、今度はセキュリティー・ゲートウェイ（ＳＥＧ）２５０を含んでいることが見て取れるであろう。ＩＰｓｅｃプロトコル・スイートが実装されている場合には、ＳＥＧを代わりにＩＰｓｅｃゲートウェイと呼ぶこともできる。
【００２５】
モバイル・インフラストラクチャーは、典型的には非常に大きく、非常に多くのノードを含むため、ＲＡＮを図２の領域Ｒ１およびＲ２などの複数の領域へと細分することが、しばしば有利であろう。それぞれの領域は、複数の基地局を含み、それらの基地局は、典型的には、地理的に互いに対して相対的に近くに位置している。所与の領域内でのセキュアな通信のために、その領域内の基地局は、ＩＰｓｅｃトンネル２６０を介して直接セキュリティー・ゲートウェイ（ＳＥＧ）・アグリゲータに接続している。領域どうしの間におけるセキュアな通信のために、別々の領域に位置しているＳＥＧどうしの間における、ネットワーク２９０を横断するＩＰｓｅｃトンネル２８０が、それぞれの領域の周辺を保護する目的で使用されている。したがって、たとえばトンネル２８０は、サード・パーティーによって所有されているネットワーク上でのローミング中にトラフィックを保護する上で有用である場合がある。ネットワーク２３０を横断するＩＰｓｅｃトンネル２７０は、たとえば、ＩＭＳＩおよびその他の顧客秘密情報を含む、コントロールプレーンおよびユーザプレーンのトラフィックを保護する上で有用である。
【００２６】
我々の方法は、たとえば、Ｘ．５０９デジタル証明書を管理するアプリケーション・インフラストラクチャーとして実施される。このアプリケーション・インフラストラクチャーは、適切なハードウェア・マシン上で実行され、そうした適切なハードウェア・マシンは、たとえば、デジタル・シグナル・プロセッサ、または専用もしくは汎用のデジタル・コンピュータとすることができる。そのような目的で、このアプリケーション・インフラストラクチャーは、ソース・コードもしくはオブジェクト・コードでの命令のセットとして、またはマシン実行可能命令のセットとして提供することができる。上述のいずれも、光学ディスク、フィールドプログラマブル・ゲート・アレイ、またはコンピュータ・メモリ・デバイスなどの有形の一時的でないマシン可読メディアにおいて具体化されるものとして提供することができる。
【００２７】
理解できるであろうが、このアプリケーション・インフラストラクチャーは、オペレータ・コマンドに従ってデジタル証明書の要求をトリガーし、デジタル証明書に署名し、証明書のバンドルをワイヤレス・バックホール・ネットワーク内のＩＰノードに配布する。
【００２８】
このアプリケーション・インフラストラクチャーはさらに、自己構成シナリオをサポートするように有利に設計することができ、その自己構成シナリオによれば、たとえば、プラグ・アンド・プレイなどのための新たなＩＰノードは、そのＩＰノードの最初の認証を可能にする工場からの証明書を備えている場合には、技術者のサポートを伴わずに現場で展開することができる。
【００２９】
このアプリケーション・インフラストラクチャーはさらに、移行シナリオをサポートするために証明書をＩＰホスト内に取り込むように有利に設計することができ、その移行シナリオによれば、たとえば、証明書を伴わないレガシーＩＰノードは、以前のソフトウェア・リリースから新たなリリースへ移行する。それを行う際に、レガシーＩＰノードは、ＩＰＳｅｃにおいてＩＫＥプロトコルによって認証される上で必要となる証明書バンドルを、リモートで、かつ手動の介入を必要とせずに取得する。
【００３０】
このアプリケーション・インフラストラクチャーは、典型的には、ワイヤレス・ネットワーク内に固定されている集中化されたプラットフォーム内にホストされることになるが、ラップトップ・コンピュータなどのローカル・プラットフォーム内にインストールすることもできる。すなわち、ローカル・プラットフォームは、たとえば、工場において証明書を供給されていない、ひいては、最初に展開される際に自分自身を認証することができない、新たに展開される基地局におけるインストール用にＩＰホスト証明書をダウンロードする目的で、セル・サイトなどのローカル・サイトにおいて証明書を管理するように構成することができる。
【００３１】
ローカル・プラットフォームの別の例においては、このアプリケーション・インフラストラクチャーは、デジタル証明書バンドルをダウンロードするために、たとえば工場において使用される。
【００３２】
我々のアプリケーション・インフラストラクチャーは、複数の階層レベルを有する。複数のレベルの使用、とりわけ２つのレベルの使用は、証明書のマネージメントを簡略化し、その一方でまた、ルート認証局をユーザから隔離する目的で、ひいては、たとえばプライベート・キーを得ようとする攻撃者からルート認証局を保護する目的で少なくとも１つの介在するレイヤを提供するために、有利である。
【００３３】
より具体的には、それぞれのマネージメント・トランザクションは、ローカルで行われ、そのため、信頼されるパスを構築するには、限られた数の証明書をそれぞれのＣＭＳによって作成して、やり取りするだけでよい。したがって、階層レイヤは、隔離のレイヤを介してセキュリティーを付加するだけでなく、オンライン認証要求を実行するためのローカル機能も提供する。これは、ひいては、信頼される当局における認証および相互認証のプロセスを簡略化およびスピード・アップする。
【００３４】
この点については、我々のインフラストラクチャーには、２つ、３つ、またはさらに多くの階層レイヤが容易に収容されるということに留意されたい。しかし、設計上のトレードオフがある。階層レイヤの数が多すぎるならば、ＩＫＥ認証中の証明書および署名の妥当性確認の回数が非常に多くなって、許容できないレベルまでパフォーマンスが低下し、オーバーヘッドが増大する可能性がある。その一方で、階層レイヤが少なすぎるならば、ＣＭＳによるローカル機能の委任が不十分になり、それらのＣＭＳのうちのいくつかは、ネットワークのＩＰノードからの要求に応答して作成してやり取りすることが必要となる場合がある多数の証明書によって圧倒される可能性がある。
【００３５】
したがって、２つのレイヤ（またはいくつかのケースにおいては、いくぶん多くのレイヤ）を有する階層モデルは一般に、オーバーヘッドを最小限に維持しながら、当局のいくつかの異なる信頼モデルに合わせて調整するのに十分な順応性のあるものになるということに我々は気づいた。「順応性のある」インフラストラクチャーは、たとえば、複数の認証局および複数の信頼モデルをサポートすることができるであろう。そのような順応性のあるインフラストラクチャーを有して、それによって、外部の認証局を導入する必要があるサード・パーティーとの間でセキュアな通信を確立できることは、有利である。
【００３６】
図３は、ワイヤレス・バックホール・ネットワークにおいて我々のアプリケーション・インフラストラクチャーを実施するための１つの可能なアーキテクチャーを示している。このアーキテクチャーの１つの重要なコンポーネントは、デジタル証明書の管理を司るシステム・アプリケーションである。我々は、そのようなシステム・アプリケーションを証明書マネージメント・システム（ＣＭＳ：Ｃｅｒｔｉｆｉｃａｔｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）と呼んでいる。
【００３７】
図３を参照すると、ＲＯＯＴ  ＣＭＳアプリケーション３００がＣＭＳ階層の最上部に位置していることが見て取れるであろう。実際の実施態様においては、ＲＯＯＴ  ＣＭＳは、図１のネットワーク２４０などのＯＡＭネットワーク内のサーバ内に存在する。ＲＯＯＴ３００の下には、証明書を必要とするＩＰノードと直接、ローカルなまたはリモートからの様式でインターフェースを取る複数のｓｕｒ−ＣＭＳアプリケーション３１０がある。実際の実施態様においては、ｓｕｒ−ＣＭＳ機能は、ＲＯＯＴ  ＣＭＳのプラットフォームと類似したプラットフォーム上に存在する。図３は、ｓｕｒ−ＣＭＳアプリケーションを３つだけ示すように簡略化されているが、実際には、もちろん、はるかに多数のｓｕｒ−ＣＭＳアプリケーションが、１つの共通のＲＯＯＴ  ＣＭＳによってサービス提供されることが可能である。したがって、この図は、この点において例示的なものにすぎず、限定的なものではないと理解されるべきである。
【００３８】
２つのタイプのＩＰノードも、この図において示されている。基地局３２１〜３２３（ＬＴＥのコンテキストにおいては、ｅＮｏｄｅＢと呼ばれる）、およびＳＥＧ３３０である。以降でさらに詳細に説明するように、示されているアーキテクチャー内のＳＥＧ３３０どうしは、セキュアに相互接続されており、それぞれのＳＥＧは、たとえばＩＰＳｅｃトンネルによって、基地局３２１、３２２、または３２３のそれぞれのグループにセキュアに接続されている。セキュアな接続を確立する目的で、基地局どうしは、互いのＩＫＥピアであり、ＳＥＧどうしは、同様に互いのＩＫＥピアである。
【００３９】
この点について、本明細書においては、ＩＰｓｅｃは、ＲＡＮ通信のために選択されたセキュアなプロトコルであると想定しているが、ＩＰｓｅｃの選択は、例示的なものにすぎず、限定的なものではないということを理解されたい。このコンテキストにおいて役立つことができるその他のセキュアなプロトコルの例としては、ｈｔｔｐｓおよびＴＬＳが含まれる。
【００４０】
典型的な実施態様においては、モバイル・インフラストラクチャーの所有者、またはバックホール・ネットワークのオペレータなど、単一の信頼される当局が、単一のＲＯＯＴ  ＣＭＳに関連付けられることになる。
【００４１】
上述したように、大型のモバイル・インフラストラクチャーおよび多くのノードを前提とすると、ＲＡＮネットワークをいくつかの個別の領域へと細分することが有利であり、それぞれの領域は、地理的にクラスタ化された複数の基地局を含む。３つの領域３６１〜３６３が、図３において示されている。上で説明したように、図面が３つの領域に限られたのは、簡略化のためであり、限定の目的からではない。同様に、図面においてそれぞれの領域に関して示されている基地局の数が３つに限られたのは、図面を簡略化するためであり、限定の目的からではない。
【００４２】
上述したように、図３のＳＥＧ３３０は、セキュアに相互接続されており、ＳＥＧのうちのそれぞれは、基地局のそれぞれのグループにセキュアに接続されている。より具体的には、所与の領域内でセキュアな通信を提供するために、領域３６１〜３６３のそれぞれの中の基地局は、ＩＰｓｅｃトンネル３５１、３５２、または３５３を介して各自のＳＥＧ３３０に直接接続している。領域どうしの間におけるセキュアな通信のために、それらの領域を横断する、ＳＥＧどうしの間におけるＩＰｓｅｃトンネル３４０が、それぞれの領域の周辺を保護するために使用されている。
【００４３】
ＩＰｓｅｃトンネルは、たとえば、プロトコルのＩＰｓｅｃスイートによって規定されているような知られている方法を使用して確立される。ＩＰｓｅｃセットアップ手順については、よく知られており、ここで詳細に説明する必要はない。しかし便宜上、ここで簡潔な概説を提示することにする。
【００４４】
ＩＫＥは、２つのＩＰｓｅｃピア候補の間においてセキュアな認証された通信チャネルを確立するという目的を伴う第１のフェーズと、ＩＰｓｅｃまたはその他のサービスのためにピアどうしの間におけるセキュリティー・アソシエーション（ＳＡ）について交渉するという目的を伴う第２のフェーズとを有する。ＳＡについては、フェーズ１において確立されたセキュアなチャネルを使用して交渉が行われる。
【００４５】
ＩＫＥフェーズ１中にピアが自分自身を認証するために使用することができるいくつかの代替方法があり、それらの代替方法のうちの１つについて合意しなければならず、またはそれらの代替方法のうちの１つを事前に選択しなければならない。そのような１つの方法は、このコンテキストにおいては特に関心があるものであり、ＲＳＡ署名によって認証されたデジタル証明書を使用する。それぞれのピアは、自分自身のＩＤ値、自分のＩＤデジタル証明書、およびＲＳＡ署名値をその他のピアへ送信する。それぞれのピアは、認証局（ＣＡ）に登録すること、およびピアの認証情報が検証された後に証明書を発行させることによって、自分のデジタル証明書を得る。証明書の内容としては、典型的には、証明書所持者のＩＤおよびＩＰアドレス、証明書のシリアル・ナンバーおよび有効期日、ならびに所持者のパブリック・キーのコピーが含まれる。
【００４６】
上述したように、マルチレベル・ネットワークにおいては、証明書の委任の連鎖は、ネットワークの最下部のＩＰホストから、ネットワークの最上部のまたはその付近の信頼されるアンカーへと延びる信頼されるパスを定義する。したがって、ＩＫＥ認証中に、それぞれのピアは、証明書のバンドルをやり取りし、それによって、証明書の委任の連鎖が形成される。証明書から証明書へ、信頼されるアンカーからピア証明書へ、委任の連鎖の妥当性を確認することができる場合には、ＩＫＥピアは認証される。認証手順を成功裏に完了させるためには、それぞれのＩＫＥピアには、証明書の正しいバンドルを供給する必要があり、さもないと、ＩＫＥ認証フェーズは失敗することになる。
【００４７】
ＩＫＥフェーズ１は、成功した場合には、ピアどうしの間においてセキュアなトンネルを確立する。そのセキュアなトンネルを使用して、ＩＫＥフェーズ２は、ピアどうしの間におけるＳＡに関するパラメータについて交渉して、ＳＡを確立し、それによって、ＩＰｓｅｃトンネルを作成する。ＩＰｓｅｃトンネルを使用してピアどうしの間においてやり取りされるパケットは、確立されたＳＡパラメータに従って暗号化および復号される。
【００４８】
例示的な実施態様においては、ｅＮｏｄｅＢは、認証手順のイニシエータである。この手順は、たとえば、新たなｅＮｏｄｅＢがオンラインになったときに、またはシステム・ソフトウェアが、はじめて認証証明書をサポートするように更新されたときに、または公的なトランスポート・ネットワークを介して、もしくはバックホールを介して機密情報を送信するためにセキュアなチャネルがはじめて確立されているときに、開始することができる。
【００４９】
この点について、本明細書で説明するアーキテクチャーにおいては、ｅＮｏｄｅＢどうしは互いのＩＫＥピアではない、すなわち、ＩＰｓｅｃトンネルはｅＮｏｄｅＢどうしの間において確立されないということに留意されたい。この特定の設計上の選択は、例示的なものにすぎず、限定的なものではないと理解されるべきである。所望される場合には、我々のインフラストラクチャーは、トンネルを介して相互接続されているｅＮｏｄｅＢどうしの間における認証に容易に対応することができる。しかし、多くのケースにおいては、そのような相互接続は、好まれないであろう。なぜなら、ネットワーク・ノードどうしの間におけるリンクの激増によって、ネットワークが複雑になりすぎる可能性があり、したがって、ｅＮｏｄｅＢどうしが自分たちの共有しているＳＥＧを介して間接的に相互通信するネットワークよりも経済的でなくなる可能性がある。
【００５０】
認証局（ＣＡ）は、ＳＥＧおよび基地局にデジタル証明書を発行するために利用可能でなければならないということが、上述の論考から理解できるであろう。これは、それぞれの領域内で、ＩＰｓｅｃが初期化されてＩＫＥプロトコルが呼び出されるときにＳＥＧおよび基地局が互いを相互に認証できるように、および別々の領域の周辺に位置しているＳＥＧどうしが同様に互いを相互に認証できるように、必要となる。
【００５１】
図１の構成においては、基地局およびＳＥＧはすべて、同じＲＯＯＴ  ＣＭＳを信頼しており、したがってそのＲＯＯＴ  ＣＭＳは、認証局として機能することができる。これは、たとえば、単一の当局が基地局およびＳＥＧを所有して機能させているケースに当てはまる場合がある。
【００５２】
しかし、別々の当局がそれぞれ基地局およびＳＥＧを所有している状態も起こり得る。そのようなケースにおいては、それらの当局のうちの１つが、自分自身の外部の認証局（ＣＡ）を使用したいと望む場合があり、その一方で、その他の当局は、ルートＣＭＳを自分のＣＡとして使用する。そのような分割されたシナリオの一例が、図６において提供されている。
【００５３】
ＣＭＳ階層モデル
我々のインフラストラクチャーによってサポートすることができる、認証のマネージメントおよび委任のいくつかの異なる認証局（ＣＡ）階層モデルについて説明する。それぞれのモデルは、ワイヤレス・オペレータがサポートすることが必要となる可能性がある別々のシナリオに対処することを意図されている。
【００５４】
３つの例示的なモデルは、下記のとおりである。
１．オペレータＣＡを伴わない階層的なＣＭＳ：ワイヤレス・サービス・プロバイダは、オペレータＣＡを所有していない。基地局およびＳＥＧによって信頼されるアンカーは、ＲＯＯＴ  ＣＭＳである。
２．オペレータＣＡを伴う階層的なＣＭＳ：ワイヤレス・サービス・プロバイダは、オペレータＣＡを所有している。基地局およびＳＥＧによって信頼されるアンカーは、オペレータＣＡである。付加される価値は、このＣＭＳインフラストラクチャーによって、オペレータＣＡ証明書の基地局での証明書マネージメントの自動化が可能になるということである。
３．オペレータＣＡを伴う直接相互認証モデル：基地局およびＳＥＧは、別々の当局によって所有されており、別々のアンカーを信頼している。ＳＥＧオペレータは、オペレータＣＡを所有している。基地局は、ＲＯＯＴ  ＣＭＳを信頼しており、ＳＥＧは、オペレータＣＡを信頼している。付加される価値は、オペレータが、オペレータＣＡとＲＯＯＴ  ＣＭＳとの間における通信を橋渡しすることができ、基地局の証明書のマネージメントを自動化することができるということである。
【００５５】
上述のモデルどうしは、信頼されるパスを構築する方法において根本的に異なるが、それらのモデルのうちの１つのために開発されたＣＭＳインフラストラクチャーを、その他のモデルが同様にサポートされるように拡張するには、相対的に少量のさらなる開発しか必要とされないであろう。これは、それぞれのモデルは主に証明書バンドルの内容において異なるが、ＣＭＳインフラストラクチャーならびに配布のメカニズムおよび手順は実質的に同じであるという事実に起因する。
【００５６】
オペレータＣＡを伴わない階層モデル
図３は、単一の当局が基地局によって信頼されていてＳＥＧおよびオペレータが外部のＣＡを所有していない場合のＣＭＳハイ・レベル・アーキテクチャー・コンポーネントを示している。このモデルにおいては、ＣＭＳインフラストラクチャーは、ＳＥＧに対して基地局を認証するために、基地局内での証明書を求める要求および証明書の配布を自動化する。このモデルは、証明書が署名されて最も上から最も下のレベルへ渡されるという点で階層的である。階層の最上部には、ＲＯＯＴ  ＣＭＳ３００がある。これは、この階層的なインフラストラクチャーにおけるトラスト・アンカーＣＡである。ＲＯＯＴ  ＣＭＳのＣＡは、証明書を下位のｓｕｒ−ＣＭＳ  ＣＡ３１０に、およびＳＥＧ３３０に発行する。それぞれのｓｕｒ−ＣＭＳ  ＣＡは、それぞれ自分が担当する基地局エンド・エンティティー（ｂａｓｅ  ｓｔａｔｉｏｎ  ｅｎｄ  ｅｎｔｉｔｙ）３２１〜３２３に証明書を発行する。ｓｕｒ−ＣＭＳは、自分が関連付けられているＳＥＧにも証明書を発行する。
【００５７】
このモデルに関する下記の表においては、基地局およびＳＥＧごとに、トラスト・アンカーと、認証パスと、デジタル証明書の格納場所とが示されている。格納場所の行においては、次の表記が使用されている。Ｘ（Ｙ）とは、ＣＡ  ＸがＣＡまたはエンド・エンティティーＹのパブリック・キーのデジタル証明書を発行することを意味する。証明書は、その証明書の発行者と同じ当局のドメインに位置しているエンド・エンティティー内に格納される。
【００５８】
【表１】
2014512120.tif 000003
【００５９】
オペレータＣＡを伴う階層モデル
図４は、オペレータが外部のＣＡ４００を所有していて基地局およびＳＥＧがオペレータＣＡを信頼している場合のアーキテクチャーを示している。このモデルにおいては、基地局およびＳＥＧのトラスト・アンカーは、オペレータＣＡ４００である。ＲＯＯＴ  ＣＭＳ３００およびｓｕｒ−ＣＭＳ３１０は、信頼されるパスをオペレータＣＡに委任する下位のＣＡである。ＣＭＳによってこのモデルに付加される価値は、自動化された様式でＣＭＳインフラストラクチャーが基地局へと配布できる少数の証明書を付加することによって、オペレータが基地局の証明書マネージメントを自動化することができることである。
【００６０】
このモデルに関する下記の表においては、基地局およびＳＥＧごとに、トラスト・アンカーと、認証パスと、デジタル証明書の格納場所とが示されている。
【００６１】
【表２】
2014512120.tif 000004
【００６２】
オペレータＣＡを伴う直接相互認証モデル
図５は、オペレータＣＡ４００を伴う直接相互認証モデルを示している。このモデルにおいては、基地局およびＳＥＧは、２つの別個のネットワーク・セキュリティー・ドメインに属し、ＩＫＥピアに直接接続されていない別々の当局を信頼している。信頼される関係を確立するために、それぞれの当局は、ＲＯＯＴ  ＣＭＳ  ＣＡ３００とオペレータＣＡ４００との間において直接、双方向の相互証明書を発行することによって、その他の当局との信頼を確立する。２つの当局の間における合意を介して相互認証が達成される。
【００６３】
このモデルは、たとえば、モバイル・オペレータが基地局当局（ｂａｓｅ  ｓｔａｔｉｏｎ  ａｕｔｈｏｒｉｔｙ）であり、トランスポート・オペレータがＳＥＧ当局であり、それぞれの当局が、（ネットワーク・セキュリティーに関して）信頼の独立したドメインを保持したいと望むシナリオに適している。このモデルはまた、基地局およびトランスポートが、ネットワーク・セキュリティー・ドメインを共有していない別々のオペレータを有する場合に、バックホールの共有をサポートする上で有用である。
【００６４】
このモデルは、実施するのが簡単であり、認証パスを短くし、２つの独立したＣＡの間において迅速に信頼関係を確立することができるため、有利である。さらなる利点としては、たとえＳＥＧオペレータがＣＭＳインフラストラクチャーを信頼していなくても、基地局は、ｓｕｒ−ＣＭＳを介して、オペレータＣＡによって署名された相互証明書を含む証明書をダウンロードするためにＣＭＳインフラストラクチャーによって提供される自動化された機能を使用することができる。
【００６５】
このモデルの重要な側面として、ＳＥＧを認証するために、基地局は、自分自身のセキュリティー・ドメイン内のＣＡによって署名された証明書を信頼するだけでよい。すなわち、基地局は、ＲＯＯＴ  ＣＭＳ  ＣＡの自己署名された証明書を信頼するだけでよく、また、やはりＲＯＯＴ  ＣＭＳ  ＣＡによって発行されるオペレータＣＡのパブリック・キーの相互証明書を信頼するだけでよい。より具体的には、オペレータＣＡによって発行されてＩＫＥ中にＳＥＧから受信される証明書は、基地局のセキュリティー・ドメインにおいて発行されたそれらの２つの証明書を使用して基地局によって妥当性を確認することができる。同様に、ＳＥＧは、基地局を認証するために、自分自身のセキュリティー・ドメイン内のＣＡによって署名された証明書を信頼するだけでよい。
【００６６】
このモデルに関する下記の表においては、基地局およびＳＥＧごとに、トラスト・アンカーと、認証パスと、デジタル証明書の格納場所とが示されている。
【００６７】
【表３】
2014512120.tif 000005
【００６８】
さらなるモデルは、図６において示されているような、外部のＣＡを伴う相互認証である。このモデルはトポロジーの点で図５のモデルに類似しているということが、図から理解できるであろう。しかし、外部のＣＡ６００は、ネットワーク・オペレータによって所有されていない。その代わりに、たとえば、証明書マネージメント・サービスを提供することに合意しているのは、サード・パーティーである。このケースにおいては、関連するプライベート・キーは、外部のＣＡによって所有されており、ネットワーク・オペレータによって所有されてはいない。
【００６９】
例１
図７は、ＲＯＯＴ  ＣＭＳの自己署名された証明書とｓｕｒ−ＣＭＳの証明書とから構成されている証明書バンドルをｓｕｒ−ＣＭＳが得る結果となるトランザクションを示している。この図において見て取れるように、ブロック７１においては、ＲＯＯＴ  ＣＭＳアプリケーションが初期化され、ＲＯＯＴ  ＣＭＳにおいては、ＲＯＯＴ  ＣＭＳのパブリック・キーとプライベート・キーとのペアが（この例においては、ＲＳＡプロトコルに従って）生成され、ＲＯＯＴ  ＣＭＳの自己署名された証明書が生成される。
【００７０】
ブロック７２においては、ｓｕｒ−ＣＭＳアプリケーションが初期化され、ｓｕｒ−ＣＭＳアプリケーションは、ＲＳＡキー・ペアを生成する。ブロック７３においては、ｓｕｒ−ＣＭＳが、自分のＲＳＡパブリック・キーと基地局のＩＤとを含む証明書要求をＲＯＯＴ  ＣＭＳへ送信する。ブロック７４においては、ＲＯＯＴ  ＣＭＳが、ｓｕｒ−ＣＭＳの証明書を生成して、自分のプライベート・キーを用いてその証明書に署名する。ブロック７５においては、ＲＯＯＴ  ＣＭＳが、自分自身の自己署名された証明書と、ｓｕｒ−ＣＭＳの証明書とをｓｕｒ−ＣＭＳへ送信する。ブロック７６においては、ｓｕｒ−ＣＭＳが、受信された証明書バンドルを格納する。
【００７１】
例２
図８および図９は、基地局内の新たなまたはアップグレードされたバックホール・コントロール・ボードがデジタル証明書をダウンロードするトランザクションを示している。図８においては、ダウンロードは、ローカルのＣＭＳアプリケーションを介して新たなボードによって行われる。図９においては、ダウンロードは、リモートに配置されているＣＭＳアプリケーションを介して既存のボードによって行われる。
【００７２】
これらの図において見て取れるように、ｓｕｒ−ＣＭＳは、ＲＳＡキー・ペアを作成すること、ならびに基地局のパブリック・キーおよびＩＤを送信することを求める要求を基地局へ送信する（ブロック８１および９１）。基地局は、キー・ペアおよび基地局のＩＤを生成し（ブロック８２および９２）、パブリック・キーおよびＩＤをｓｕｒ−ＣＭＳへ送信する（ブロック８３および９３）。ｓｕｒ−ＣＭＳは、基地局の証明書を生成し、ｓｕｒ−ＣＭＳのプライベート・キーを用いてその証明書に署名し、その証明書を格納する（ブロック８４および９４）。ｓｕｒ−ＣＭＳは、基地局の証明書と、自分自身の証明書と、ＲＯＯＴ  ＣＭＳによって自己署名された証明書とを基地局へ送信する（ブロック８５および９５）。
【００７３】
図８のトランザクションにおいては、証明書の使用は、ＩＰｓｅｃプロトコルのもとで保護されているＯＡＭトラフィックに制限されている。図９のトランザクションにおいては、そのような制限はなく、ｓｕｒ−ＣＭＳはまた、ＲＯＯＴ  ＣＭＳによって署名された相互証明書を（もしあれば）証明書バンドル内に含む。
【００７４】
基地局は、トランザクションの成功または失敗について、必要に応じてエラー・コードとともに、ｓｕｒ−ＣＭＳに報告する（ブロック８６および９６）。
【００７５】
例３
図１０および図１１は、基地局内の新たなまたはアップグレードされたバックホール・コントロール・ボードがデジタル証明書をダウンロードするトランザクションを示している。図１０においては、ダウンロードは、リモートのＣＭＳアプリケーションを介して新たなボードによって行われる。図１１においては、ダウンロードは、オペレータの構内の中央の位置にあるがｅＲＡＮ（すなわち、ＬＴＥの次世代無線アクセス・ネットワーク）のバックホールに接続されていない既存のボードによって行われる。
【００７６】
これらの図において見て取れるように、ｓｕｒ−ＣＭＳは、ＲＳＡキー・ペアを作成すること、ならびに基地局のパブリック・キーおよびＩＤを送信することを求める要求を基地局へ送信する（ブロック１０１および１１１）。基地局は、キー・ペアおよび基地局のＩＤを生成し（ブロック１０２および１１２）、パブリック・キーおよびＩＤをｓｕｒ−ＣＭＳへ送信する（ブロック１０３および１１３）。ｓｕｒ−ＣＭＳは、基地局の証明書を生成し、ｓｕｒ−ＣＭＳのプライベート・キーを用いてその証明書に署名し、その証明書を格納する（ブロック１０４および１１４）。ｓｕｒ−ＣＭＳは、基地局の証明書と、自分自身の証明書と、ＲＯＯＴ  ＣＭＳによって自己署名された証明書と、ＲＯＯＴ  ＣＭＳによって署名された任意の相互証明書とを基地局へ送信する（ブロック１０５および１１５）。図１１のトランザクションにおいては、証明書の使用は、ＩＰｓｅｃプロトコルのもとで保護されているＯＡＭトラフィックに制限されている。
【００７７】
基地局は、トランザクションの成功または失敗について、必要に応じてエラー・コードとともに、ｓｕｒ−ＣＭＳに報告する（ブロック１０６および１１６）。
【図１】
2014512120.tif 000006
【図２】
2014512120.tif 000007
【図３】
2014512120.tif 000008
【図４】
2014512120.tif 000009
【図５】
2014512120.tif 000010
【図６】
2014512120.tif 000011
【図７】
2014512120.tif 000012
【図８】
2014512120.tif 000013
【図９】
2014512120.tif 000014
【図１０】
2014512120.tif 000015
【図１１】
2014512120.tif 000016
【国際調査報告】
2014512120.tif 000017
2014512120.tif 000018
2014512120.tif 000019