JP2014161027A - 安全なパケット伝送のための暗号化方法 - Google Patents

Abstract

【課題】現存するホップバイホップセキュリティアソシエーションを使用してエンドツーエンドキーを確立する方法を提供する。また、パケット固有暗号化キーＰＥＫがパケットｐを暗号化するのに使用される方法を提供する。
【解決手段】キーＰＥＫの署名は、２つのノードで共有される完全性キーを使用して２つのノードのそれぞれで別々に計算される。署名は、２つのノードのうちの一方から他方に対して、パケットｐに関連付けて送信される。受信するノードは、署名を使用して、パケットｐがＰＥＫを所有するエンティティによって発信されたことを検証する。
【選択図】図４

Description

本発明は、無線システムにおけるセキュリティおよび認証に関し、より詳細にはパケットデータを送信および受信するように構成された無線システムに関する。

現代の無線システム、例えば第３世代およびそれを超える無線システムは、１秒あたり数百キロビット、むしろ数千キロビットの転送速度でパケットデータを送信および受信するように構成されている。実例として図１は、「国際移動体通信システム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）」の略称である「ＵＭＴＳ」と呼ばれる一種の第３世代無線システムのハイレベルなアーキテクチャを示す。図に示すように、モバイルユーザ端末１０は無線インターフェイスで基地局２０と通信する。基地局はこの環境では「ノードＢ」と呼んでもよい。基地局２０はバックホールネットワーク３０と通信し、バックホールネットワーク３０は、無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）４０、認証センター（ＡｕＣ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ）５０、移動通信交換局（ＭＳＣ：Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）６０、および図に示すようにＳＧＳＮおよびＧＧＳＮの機能をあわせ持つ要素７０を含む。

ＲＮＣはＲＮＣに接続する１セットの基地局を制御する。ＲＮＣの機能は無線資源を管理することである。例えばＲＮＣは、呼のセットアップおよびティアダウン、ならびに音声およびデータトラフィックの処理のセットアップおよびティアダウンを制御する。また、ＲＮＣはセル間のハードハンドオフおよびソフトハンドオフを管理する。

ＡｕＣはネットワークにログオンしようとしている各ユーザを認証する。より詳細には、ＡｕＣは入ってくるユーザの端末に設置されているＳＩＭカードを認証する。各加入者について、一意の秘密キーが加入者とＡｕＣの間で共有される。ＡｕＣは、共有されるキーでハッシュされるかまたは暗号化されるランダムな数を入ってくる加入者に送信することにより、加入者を調査し、その結果はＡｕＣに戻される。戻された結果が同じ操作からのＡｕＣ自身の結果と一致する場合、ユーザはネットワークに入ることを許可される。ＡｕＣとユーザの間で共有される秘密情報は、ユーザおよび基地局が互いに無線で通信するときセキュリティを実現する秘匿キー（ｃｉｐｈｅｒｉｎｇ ｋｅｙ）ＣＫを作成することにも使用される。

この点に関して、いくつかの北アメリカのＣＤＭＡ標準などの他の標準によると、ユーザ端末として機能する携帯電話はＳＩＭカードを含まないことに留意されたい。その代わりに、電子シリアル番号（ＥＳＮ：ｅｌｅｃｔｒｏｎｉｃ ｓｅｒｉａｌ ｎｕｍｂｅｒ）が製造業者により携帯電話のハードウェアに刻印される。さらに、無線通信事業者はモバイル識別番号（ＭＩＮ：ｍｏｂｉｌｅ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ）により携帯電話を識別することが可能である。ＥＳＮおよびＭＩＮは識別のために一緒に使用可能であり、認証およびセキュリティのための手続きに使用可能である。３ＧＰＰ２のいくつかの北アメリカの標準を含むいくつかの標準によると、ＡｕＣの機能と同様の機能は、「ＡＡＡサーバ」（「ＡＡＡ」は「認証、許可、アカウンティング（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，Ａｕｔｈｏｒｉｚａｔｉｏｎ，ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）」の略語である）と呼ばれるネットワーク要素により実行可能であることに、さらに留意されたい。

再び図１に目を向けると、ＭＳＣはそのサービスエリア内で移動しているユーザのために回路交換方式の呼び出しおよびモビリティ管理を特に支援する電話交換局である。データはディジタル方式でエンコードされた形式で有線ネットワークからＭＳＣに対して直接配信可能である。図で示すように、ＭＳＣは公衆交換電話網（ＰＳＴＮ：ｐｕｂｌｉｃ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋ）に接続する。ＡｕＣは、その認証機能を実行するためＭＳＣを介して間接的に動作する。

ＳＧＳＮ（サービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ））はそのサービスエリア内のユーザ端末の位置を追跡し、課金機能およびセキュリティ機能を支援し、ダウンリンクパケットをＲＮＣの方へトンネルし、アップリンクパケットをＲＮＣからディトンネルする。パケットのトンネリングおよびディトンネリングは、モバイルユーザがあちこち移動する間インターネットへの接続を維持することを特に可能にするＧＰＲＳトンネリングプロトコル（ＧＴＰ：ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）に従っている。

ＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ））は、外部パケットデータネットワークに関してＩＰルータとして機能する。図で示すように、例えばＧＧＳＮは「ＩＰネットワーク」に接続する。また、ＧＧＳＮはセキュリティ機能および課金機能も支援する。ＧＴＰに従ってＧＧＳＮは、外部のパケットネットワーク上で移送される通常のＩＰパケットと、ＵＭＴＳコアネットワーク内でトンネルされるＧＴＰパケットとの間の変換を行う。外部パケットネットワークにとって、ユーザはあちこち移動している可能性があるにも関わらず、ＧＧＳＮに固定されているかのように見える。

この点に関して、いくつかの北アメリカのＣＤＭＡ標準などの他の標準によると、ＲＮＣはＳＧＳＮの代わりにＰＤＳＮに接続されることに留意されたい。次に、ＰＤＳＮはホームエージェント（ＨＡ：Ｈｏｍｅ Ａｇｅｎｔ）に接続される。また、ＰＤＳＮとＲＮＣの間の通信、ならびに基地局に対する通信に使用されるトンネリングプロトコルはＧＴＰを含まない。ＩＥＥＥ ８０２．１６ベースのＷｉＭＡＸシステムなどの他のシステムおよび標準は、アクセスゲートウェイ（ＡＧＷ：Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）に接続された基地局から構成される異なる階層構造を使用する。全体として、詳細が異なっていても機能は同様である。

基地局は一般には露出した位置にあり、それゆえ物理的な侵入に対して比較的安全でない。一方、ＲＮＣ、ＭＳＣ、ＳＧＳＮおよびＧＧＳＮは典型的には、盗聴、改竄、破壊活動および窃盗に対して機密に属するネットワーク情報が保護可能である中央局に位置している。

したがって、セキュリティ関連機能の実行は物理的に安全なそれらのネットワーク要素に限定されるが、基地局は暗号化されたデータを転送するためにのみ動作し、暗号化されたメッセージをデコードすることはない。物理的に安全なネットワーク要素が同様に安全なネットワークに相互接続されると仮定されるので、一般にそれらのネットワーク要素間の安全なトンネルをさらにセットアップするために必須の要件はない。

多様な高度のアーキテクチャが提案されてきており、それらのアーキテクチャはいくつかのネットワーク要素でより広く露出され、物理的なセキュリティが低下することにつながりうる。例えばＢＳＲ（基地局ルータ（Ｂａｓｅ Ｓｔａｔｉｏｎ Ｒｏｕｔｅｒ））アーキテクチャなどのフラットなＩＰアーキテクチャは、ＲＮＣ、ＳＧＳＮおよびＧＧＳＮのほとんどの機能を基地局に統合している。（別の種類のＢＳＲアーキテクチャはＵＭＴＳアーキテクチャよりもむしろＳＡＥ／ＬＴＥアーキテクチャに関連がある。この第２のタイプのＢＳＲにおいてｅＮＢ、ＭＭＥおよびＵＰＥは基地局に統合されている。前述の略語はそれぞれ「拡張されたノードＢ（ｅｎｈａｎｃｅｄ Ｎｏｄｅ Ｂ）」、「移動管理エンティティ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）」、および「ユーザプレーンエンティティ（Ｕｓｅｒ Ｐｌａｎｅ Ｅｎｔｉｔｙ）」の略称である）。

したがって例えば図２は、ＢＳＲ９０と無線通信しているモバイルユーザ８０を示しており、次にＢＳＲ９０はＡｕＣ１００、ＳＩＰサーバ１１０、ＩＰネットワークおよびＰＳＴＮを含むバックホールネットワークに接続する。図で示すように、ＩＰネットワークはＢＳＲをＡｕＣおよびＳＩＰサーバに接続する。ＳＩＰ（セッションイニシエーションプロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ））は、ＶｏＩＰ（ボイスオーバーＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ））、および複数の種類の媒体を含む、他のタイプの対話形式ユーザセッションのためのインターネットシグナリングプロトコルである。図ではＳＩＰサーバブロックはＶｏＩＰなどのための支援機能全てを表すことを意味している。

ＢＳＲおよび同様のアーキテクチャでは、暗号化機能および他のセキュリティ関連機能、ならびにキー情報および他の機密に属する情報でさえ、物理的に露出した位置に存在しうる。さらに、ＢＳＲは、盗聴および改竄に対して脆弱な公衆ＩＰネットワークを介して外部接続を行うことがある。このように露出が増大するので、悪質な行為に対する新しい予防措置が必要である。

しかし、バックホールネットワークの物理的な保護が保証できないので、この新しい予防措置が少なくとも部分的には論理的に根拠があることが望ましい。一方、論理的に根拠のある新しい予防措置は、例えばその予防措置がいくつかの無線標準と矛盾するため、または無線標準には従っているがその予防措置がインターネット標準と矛盾するため、障害に直面する可能性がある。

それゆえ、エンドツーエンドで、すなわち無線ユーザ端末とＩＰネットワークのノードの間で、またはＩＰネットワークを経由して接続された２つの無線ユーザ端末間で効果的であり、さらに現行のＩＰ標準を大きく変更することなく実行可能である、悪質な攻撃に対する予防措置が特に必要である。

本発明者はこの種の予防措置を開発した。したがって、本発明は、リンクによって相互接続されたノードのネットワークにおいてＡおよびＢで指定される２つのエンドポイントノード間でパケットｐを伝送することを含む。

第１の広範な例によれば、エンドツーエンドキーが、現存するホップバイホップセキュリティアソシエーションを使用して確立される。この点に関して「エンドツーエンド」で情報を送信することは、１つのタイプのネットワークもしくはプロトコルから別のネットワークもしくはプロトコルに対して、１つの加入者ネットワークから別の加入者ネットワークに対して、または１つのサービスプロバイダから別のサービスプロバイダに対しての遷移がある場合に、あるいはユーザ端末が位置している場合に、あるいはメッセージについて任意の他の種類のエンドポイントがある場合に、任意のペアのネットワークエンティティ間で情報を送信することを意味する。

例えば、Ａは、Ｂに対するエンドツーエンドキーのパケット暗号化キー（ＰＥＫ：Ｐａｃｋｅｔ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を確立する。キーを確立するのに必要な情報は、現存するホップバイホップセキュリティアソシエーションを使用してＡとＢの間で安全に転送される。キーＰＥＫはパケット固有である。パケットｐはキーＰＥＫで暗号化され、ＡからＢに対して伝送される。

具体的な例では、キーＰＥＫはＡで生成され、ネットワークを介してＢに対して伝送される。

他の具体的な例では、ＡはＢとのセッションを確立する。「セッション」とは、別個のＩＰアドレスを有するエンティティの間で、開始および終了を有する時間帯の間でのデータパケット交換についての相互の了解を意味する。ＡおよびＢは両方とも、少なくとも１つのセッションキーＳＥＫを所有する。例えば、ＡはセッションキーＳＥＫを作成し、それをＢに対して送信することが可能である。次にＡおよびＢはそれぞれ別々に、知られているアルゴリズムを使用して、少なくともセッションキーＳＥＫから、かつパケットｐの一意のプロパティから、パケット固有暗号化キーＰＥＫを作成する。セッションキーは現存するホップバイホップセキュリティアソシエーションを使用してＡからＢに対して安全に送信される。

ＡからＢに対するネットワークパスの少なくとも１つのホップは、完全性キーを共有する１つのペアのノード間で起こることがある。例えばＡは、Ａのサービスをする基地トランシーバノードと完全性キーを共有する無線ユーザ端末であってよい。同様にＢもまた、Ｂのサービスをする基地トランシーバノードと完全性キーを共有する無線ユーザ端末であってよい。「基地トランシーバノード」とは、基地局、ノード−Ｂ、基地トランシーバ局、ＢＳＲまたは同様の機能を有する無線ネットワークの他の任意の要素を意味する。

第２の広範な例は、パケット固有暗号化キーＰＥＫがパケットｐを暗号化するのに使用される方法を含む。キーＰＥＫの署名は、２つのノードで共有される完全性キーを使用して、２つのノードのそれぞれで別々に計算される。署名は２つのノードのうちの一方から他方に対してパケットｐに関連付けて送信される。受信するノードは署名を使用してパケットｐを検証する。

この点に関してパケットを「検証する」ことは、パケットの送信元がＰＥＫを所有していたことを検証することを意味する。この意味でのパケットの検証は、パケットが例えば改竄などによる許可されていない改変がないことを必ずしも保証しないことに留意されたい。

具体的な例において、完全性キーを共有するノードは、無線ユーザ端末および無線ユーザ端末にサービスをする基地トランシーバノードである。

具体的な例において、パケットｐは、第１の無線ユーザＡからネットワークを介して第２の無線ユーザＢに対して送信される。ユーザＡおよびユーザＡのサービスをする基地トランシーバノードは、キーＰＥＫの署名を使用してパケットｐの真正性を検証し、ユーザＢおよびユーザＢのサービスをする基地トランシーバノードについても同様である。

先行技術のＵＭＴＳシステムのアーキテクチャのハイレベルなブロック図である。 ＢＳＲを使用する無線システムのハイレベルなブロック図である。 ＩＰネットワークを介し複数のホップを経由して互いに通信するそれぞれのＢＳＲを介して、２台のモバイルユーザ端末が互いに接続されているハイレベルなブロック図である。 ユーザがセッションを開始し、セッションコードをターゲットユーザに配信する例示的な手続きの流れ図である。 開始ユーザがパケットをターゲットユーザに対して送信する例示的な手続きの流れ図である。 ターゲットユーザおよびターゲットユーザにサービスをするＢＳＲが、開始ユーザによって送信されるパケットを認証する例示的な手続きの流れ図である。 下記のいくつかの方法に関連して使用可能であるパケットフォーマットの概略図である。

説明の目的のために、ＵＭＴＳネットワークの環境で本発明の新しい方法が適用されている例を記載する。しかし、説明されるべきそれらの方法は適用例においてより大まかなものであることに留意されたい。例えばそれらの方法は、広範囲の標準のいずれかに従う無線サービスの環境で適用可能であり、それらの標準の中でＧＳＭ標準およびＵＭＴＳ標準は２つの例にすぎない。さらに、それらの方法はアクセス技術が有線である環境、およびアクセス技術が無線である環境に適用可能である。またさらに本発明の方法は、例えば従来の無線サービスおよびボイスオーバーＩＰ（ＶｏＩＰ：Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）などのアプリケーションレベルのサービスを含みうる多様な種類のサービス環境に有効に適用される。またさらに本発明の方法が提供可能であるセキュリティの拡張は、ハードウェアエンティティとしてのアクセス端末間のセキュリティに関連することが可能であるか、またはそのセキュリティの拡張は、ユーザ間、すなわちサービスに対する加入者として認識される人々の間のセキュリティに、同じくらい有利に関連することが可能である。

上述のようにＵＭＴＳネットワークにおける認証センター（ＡｕＣ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｅｎｔｅｒ）は、ネットワークにサインオンしようとしている加入者の端末に設置されているＳＩＭカードを認証する。認証処理は加入者とＡｕＣの間で共有される秘密キーに依拠する。より詳細には、「ルートキー」と呼ばれる固定キーが加入者のＳ１Ｍカード内に格納され、無線ネットワーク内にも格納される。典型的なＵＭＴＳネットワークでは、ルートキーはＡｕＣに格納されるが、ホームロケーションレジスタ（ＨＬＲ：Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）などの他のネットワーク要素にも格納可能である。ユーザ端末およびネットワークはそれぞれ、ルートキーから秘匿キーＣＫおよび完全性キー（ｉｎｔｅｇｒｉｔｙ ｋｅｙ）ＩＫをローカルに生成する。ＧＳＭ、ＴＤＭＡおよびＣＤＭＡシステムのための標準などの多様な他の無線標準は、認証およびセキュリティのための同様の手続きを記載していることに留意されたい。

例示のシナリオでは、図３に示すようにユーザ端末１２０は、例えば上述のようにＢＳＲＩ３０に対する無線通信を経由してネットワークに対してユーザ端末１２０自身を認証する。次に端末１２０は、ＢＳＲ１５０によりサービスされるユーザ端末１４０とのセッションを確立する。セッションが確立される手続きはよく知られている標準に従って典型的に行われるので、本明細書で詳細に説明する必要はない。ブロードバンド無線環境におけるこれらの標準の例は、３ＧＰＰおよび３ＧＰＰ２の標準ならびにＩＥＥＥ ８０２．１６ ＷｉＭａｘ標準である。

図ではＢＳＲが互いに通信するのに経由するＩＰネットワークが、３台のサーバ１６１、１６２、１６３で表されている。図は純粋に教示的な目的のために与えられており、ＩＰネットワークにおけるノードもしくはサーバの数またはＢＳＲもしくはユーザの数について、あるいは他のいかなる意味においても限定するものとして理解されるべきではない。

ユーザ端末１２０とＢＳＲ１３０の間の通信は暗号化により保護されるので有利である。上記で説明したようにＵＭＴＳシステムにおいて、例えばこの通信は典型的には、その通信を秘匿キーＣＫで暗号化し、ユーザ端末とＢＳＲの間で交換されるメッセージの完全性を確実なものにするために追加のキーＩＫを使用することにより保護される。同様に、無線ユーザ端末および無線ユーザ端末にサービスをするＢＳＲからなる他のノードペアはそれら自身の秘匿キーおよび完全性キーを有する。したがって、例えば端末１２０とＢＳＲ１３０の間のリンクは、より大まかにはキーのベクトルであってよいキー１７１によって保護されるものとして図に示される。同様に、端末１４０とＢＳＲ１５０の間のリンクはキー１７２によって保護される。

また、ＢＳＲＩ３０およびＢＳＲ１５０が通信するのに経由するＩＰネットワークまたは他のネットワークも、暗号化を使用してそのネットワークを介して送信されるメッセージを保護することが可能である。例えば、この目的のために暗号化の使用を記載している、多様なＩＥＴＦ標準がある。例えば、ＩＥＴＦ標準文書に記載されているＩＰＳｅｃ（インターネットセキュリティ（Ｉｎｔｅｒｎｅｔ Ｓｅｃｕｒｉｔｙ））アーキテクチャは、パケットペイロード内のデータを暗号化するためのカプセル化セキュリティペイロード（ＥＳＰ：Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ）などのプロトコルを含む。

典型的には各ホップは異なる秘匿キーによって保護される。したがって、一例として図３は、キー１７３−１７６のそれぞれのキーによって保護されるものとして、ＩＰネットワークの各リンクを示す。

図３のユーザ端末１２０および１４０などのネットワークノード間の通信が上述のホップバイホップセキュリティ対策を使用することは概して有利である。ネットワークで露出された地点で盗聴および改竄に対する拡張された保護を提供するセキュリティ対策を、ここでさらに説明する。

図４に記載されている手続きを見ると、ここで「ユーザＡ」と命名される開始ユーザは、ここで「ユーザＢ」と命名されるターゲットユーザとのセッションを確立することを望んでいることがわかる。より大まかには、開始ノードおよびターゲットノードはネットワークにおける任意のノードであってよく、無線ユーザ端末などに限定されない。ブロック１８０で、よく知られている方法に従ってセッションが確立される。ブロック１９０で、秘匿キーＣＫ_{Ａ，ＢＳＲ−Ａ}および完全性キーＩＫ_{Ａ，ＢＳＲ−Ａ}が、ユーザＡとユーザＡにサービスをするＢＳＲ（上述のようにここで「ＢＳＲ−Ａ」と命名される）との間に確立される。この点に関して、この手続きが限定する目的のためにではなく、純粋に説明の目的のためにＢＳＲネットワークの環境で説明されており、多様な種類の通信ネットワークにおいて有益な適用例を見いだせることに留意されたい。

ブロック２００で示すように、セッションキーＳＥＫはここで生成され、ユーザＡとＢＳＲ−Ａの間で交換される。より大まかには、セッションキーは２つ以上のキーのベクトルであってよい。例えば、キーのベクトルはセッションを暗号化するための１つまたは複数のキー、およびパケットを認証するための１つまたは複数の他のキーを含んでよい。話を簡単にするために、単一のセッションキーＳＥＫに言及するが、実際は２つ以上のキーのベクトルが使用可能であることに留意されたい。

セッションキーＳＥＫは典型的にユーザＡにより生成され、ユーザＡとＢＳＲ−Ａの間で確立された秘匿キーの保護の下でＢＳＲ−Ａに伝送される。しかし、他の構成も可能である。例えば、ＢＳＲ−Ａがキーを生成してそれをユーザＡに送信することが可能であるか、またはサードパーティがユーザＡおよびＢＳＲ−Ａの両方にキーを配信することが可能であるか、または事前に構成されたアルゴリズムおよび共有されたデータを使用してユーザＡおよびＢＳＲ−Ａがそれぞれローカルにキーを計算することが可能である。いずれにしてもセッションキーを生成するアルゴリズムはよく知られており、本明細書で詳細に説明する必要はない。例えば、適切なアルゴリズムは３ＧＰＰおよび３ＧＰＰ２の標準に記載されている。具体的な一例は３ＧＰＰ２標準に記載されている拡張暗号アルゴリズム（ＥＣＡ：Ｅｎｈａｎｃｅｄ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｌｇｏｒｉｔｈｍｓ）により与えられる。

図４のブロック２１０および２２０で示すように、セッションキーはホップバイホップ暗号化の保護の下でＢＳＲ−ＢおよびユーザＢに対して転送される。すなわちセッションキーは、各ホップ上でそのホップのエンドポイント間のセキュリティアソシエーションに従って与えられる秘匿キーにより保護される。結果としてセッションキーは図３のノード１６１−１６３などの各中間ノードで復号化されてよく、次に現在のノードと次のノードの間のセキュリティアソシエーションに従って再度暗号化されてよい。ＢＳＲ−ＢからユーザＢに対する最後のホップまで、ユーザＢがネットワークに対してユーザＢ自身を認証したとき確立された秘匿キーを使用して、セッションキーは典型的に暗号化される。

図５を見ると、ブロック２３０で、ユーザＡがここでユーザＢに伝送されるべきパケットを生成することがわかる。伝送されるべきこの各パケットに対してユーザＡは、他のパケットではなくそのパケットに固有のパケット暗号化キーＰＥＫを計算する。例えばキーＰＥＫは、セッションキーおよびパケットの一意のプロパティを含む入力から計算されてよい。使用されうるパケットの１つのプロパティは、シーケンス番号または同期をとったカウンタ値である。したがって例えば、カウンタ値とセッションキーの間でＸＯＲなどの論理演算を実行することにより、キーＰＥＫは生成可能である。複数のセッションキーがある場合には、１つのセッションキーがキーＰＥＫを生成するのに使用されるものとして特に指定されてよい。理解されるように、各パケットについてのキーＰＥＫもまた、ＢＳＲ−Ａ、ＢＳＲ−ＢおよびユーザＢでローカルに計算される。

図５のブロック２４０で示すように、ユーザＡも本明細書では

で示されるキーＰＥＫの署名を計算する。当然、例えばランダム数、暗号同期パラメータ、加入者プロファイルＩＤ（ＳＰＩＤ：ｓｕｂｓｃｒｉｂｅｒ ｐｒｏｆｉｌｅ ＩＤ）などの他の入力も署名の計算に含まれてよい。特に、必ずしも機密ではないが時間に依存したパラメータが含まれることもある。

ブロック２５０で示すように、ユーザＡは、対応するパケットに関連付けてその署名をＢＳＲ−Ａに対して送信する。署名はパケット、例えばヘッダ部分に添付されてよい。別法として署名は、帯域外伝送、例えば制御チャネルで送信可能である。ブロック２６０で示すように、ＢＳＲ−Ａは単独で

のローカルな計算を実行する。

上述のように

は、関連する２つのノード間で共有される完全性キーを使用して計算されてよく、この完全性キーはこの場合には、ユーザＡとＢＳＲ−Ａの間で共有される完全性キーである。署名

は典型的にはＰＥＫより短い。例えば、署名は暗号化圧縮またはハッシュ関数の結果であってよい。この関数は、ＰＥＫの知識を正当に共有するエンティティに知られているランダムノンス（ｒａｎｄａｍ ｎｏｎｃｅ）およびカウンタ値などの他の数量と一緒に、ＰＥＫを入力として取り込むことが可能である。この関数は当技術分野でよく知られており、本明細書で詳細に説明する必要はない。この環境で有益な関数の一例は、ＩＥＴＦのＨＭＡＣ標準に使用されているセキュアハッシュ関数１（ＳＨＡ−１：Ｓｅｃｕｒｅ Ｈａｓｈ Ｆｕｎｃｔｉｏｎ １）である。

などの署名の目的は、所与のリンクを介してのパケット送信者が、パケットだけでなくキーＰＥＫ、および署名を作成するのに使用されたキーを所有していたことを検証することである。パケットペイロードなどのデータのより大きなブロックの署名を計算することは、もちろん可能である。しかし、ＰＥＫ署名はユーザ端末およびＢＳＲで計算資源に対する要求を著しく減少させながら、効果的なパケット検証を実行するので、有利である。

上述の例のネットワークでは、所与のリンクはユーザＡからＢＳＲ−Ａに対するリンクであってよいし、または、理解されるように、ＢＳＲ−ＢからユーザＢに対するリンクであってよい。これらのリンクは無線なので、偽のパケットがセッションに投入されるか、または例えばパケットが改変された後に古いパケットがセッションに再投入される攻撃に特に脆弱でありうる。ＰＥＫは伝送されないので、攻撃者によってインターセプトされる可能性はない。その代わり、攻撃者はＰＥＫを計算する必要があるが、セッションコードが他の情報と一緒にインターセプトされるという起こりそうにない場合にのみ、このことは可能である。それゆえ、侵入するパケットはリンクの受信側で検出され、拒絶されることが可能である。したがってブロック２７０で示すように、ローカルに計算された

の値がユーザＡから受信した値に一致する場合にのみ、ＢＳＲ−Ａはパケットを真正なものとして受け付ける。ブロック２８０で示すように、パケットが受け付けられる場合、ＢＳＲ−Ａはネットワークを介してパケットをＢＳＲ−Ｂに転送する。ネットワークを介してパケットが通るパス上の隣接するノードの各ペアは、一意の秘匿キーを共有することが可能である。したがってパケットは各ホップの後に復号化され、次のホップの前に新しいキーで再度暗号化されることが可能である。

典型的にパケットの内容はユーザＡによりキーＰＥＫを使用して暗号化されているので、全中間ノードにとってアクセスできないものとなる。すなわち、キーＰＥＫが（直接的に、またはＰＥＫを生成するためのＳＥＫなどの入力を配信することによって）ネットワークを介して配信されても、ＰＥＫの知識は中間ノードに対して拒否されることが可能である。例えば安全なＩＰＳｅｃトンネルはＢＳＲ−ＡとＢＳＲ−Ｂの間で確立されることが可能であるか、またはＢＳＲ−ＡおよびＢＳＲ−Ｂは中央セキュリティサーバ（Ｃｅｎｔｒａｌ Ｓｅｃｕｒｉｔｙ Ｓｅｒｖｅｒ）を共有することが可能である。それらまたは同様の手段により、安全なキーの配信が容易に遂行される。もちろん、ＩＰＳｅｃトンネルなどはセッションの全パケットの安全な伝送に使用されることが可能である。しかし、暗号化プロトコルをこのように極度に使用することは、中間ノードでの計算資源に対して過度の負荷をかけるおそれがある。この負荷は、例えばセッションにつき１回のみ、キーの配信に対してだけＩＰＳｅｃトンネルを使用することにより避けられる。

上述のように中央セキュリティサーバまたはＩＰＳｅｃトンネルの使用は、現存するホップバイホップセキュリティアソシエーションを使用するキーの配信の一例である。この点に関して、キーの配信が完了した後、中央セキュリティサーバが適切なセッションに属するパケットのルーティングに携わる必要がないことは、注目に値する。それゆえ、限定された使用だけが中央セキュリティサーバでなされる。

次に図６に注目し、この図６で示す一連のステップは、ブロック２９０でＢＳＲ−Ｂによるパケットの受信から始まる。パケットは典型的にＢＳＲ−Ｂが先行するノードと共有する秘匿キーで暗号化されたものとして到達する。したがってブロック３００で示すように、ＢＳＲ−Ｂはその秘匿キーに関連してパケットを復号化する。

さらにブロック３００で示すように、ＢＳＲ−Ｂは単独で

のローカルな計算を実行する。典型的にこの計算は

の計算と同様である。しかしＢＳＲ−ＢとユーザＢの間の完全性キーは、ＢＳＲ−ＡとユーザＡの間の完全性キーの代わりに入力として使用される。

ブロック３１０でＢＳＲ−Ｂは、ユーザＢと共有する秘匿キーを使用してパケットを再度暗号化し、それをユーザＢに転送する。ブロック３２０で示すように、ＢＳＲ−Ｂはまた、前述のように、帯域内伝送または帯域外伝送を介して、パケットに関連付けて

をユーザＢに送信し、この際、署名

が参照される。ブロック３３０で、ＢＳＲ−Ｂはパケットを復号化し、

の単独でローカルな計算を実行する。ローカルに計算された値がＢＳＲ−Ｂによって送信された値と一致する場合、パケットは検証されたものとして、すなわち、ＰＥＫを所有するエンティティによって発信されたことを検証されたパケットとして受け付けられる。

上述のように、各パケットに対するＰＥＫは、最初のホップの始点ノードおよび終点ノード、ならびに最後のホップの始点ノードおよび終点ノードでローカルに計算されてよい。セッションキーはＰＥＫを計算するための入力として使用される。セッションキーは、現存するホップバイホップセキュリティアソシエーションを使用して、暗号化された形式でネットワークを介して伝送される。

しかし他の例ではセッションキーは任意であり、ＰＥＫがホップバイホップ暗号化を使用してネットワークを介して転送される。例えば、ユーザＡ（起動ノードの例として）は、パケットまたは少なくともパケットペイロードをＰＥＫで暗号化する。またユーザＡは、ＢＳＲ−Ａ（最初のホップの終点ノードの例として）と共有する秘匿キーを使用してＰＥＫを暗号化し、ＢＳＲ−Ａと共有する完全性キーを使用してＰＥＫに署名する。暗号化されたＰＥＫおよびその署名は、ユーザＡからＢＳＲ−Ａに対してパケットに関連付けて、上述のように署名

を参照して送信される。

図７を参照して、例えばパケット４００はＩＰヘッダ４１０、ペイロード４２０およびＰＥＫフィールド４３０を含む。ペイロード４２０はエンドツーエンドでＰＥＫで暗号化される。

ＰＥＫはＢＳＲ−ＡからＢＳＲ−Ｂに対してネットワークを介して、ホップバイホップ暗号化を使用して、パケットとともに送信される。それゆえ、ＰＥＫは各中間ノードで復号化され再度暗号化されることが可能であるが、中間ノードでパケットの復号化はなされない。典型的なパケットにおいて、フィールド４３０における暗号化されたＰＥＫがたった１２８ビットの長さでありうるのに対し、フィールド４２０におけるペイロードは１５００バイトの長さであることがある。それゆえ、ＰＥＫのみを復号化し再度暗号化することが大量の計算資源を節約することは明らかである。

図７の例では、ＰＥＫフィールド４３０の内容は最初のホップ、すなわちユーザＡからＢＳＲ−Ａに対するホップ上で秘匿キーＣＫ_{Ａ，ＢＳＲ−Ａ}で暗号化される。ＢＳＲ−ＡからＢＳＲ−Ｂに対するパスの各ホップ上で、フィールド４３０の内容は例えば適切なＩＰＳｅｃキーで暗号化される。それゆえ、このホップが２つ以上ある場合、一連のＩＰＳｅｃアソシエーションはＰＥＫを保護するために使用可能である。

ＢＳＲ−ＢでＰＥＫは、ＢＳＲ−ＢがユーザＢと共有する秘匿キーＣＫ_{Ｂ，ＢＳＲ−Ｂ}を使用して暗号化され、ＢＳＲ−ＢがユーザＢと共有する完全性キーを使用して署名される。暗号化されたＰＥＫはＢＳＲ−ＢからユーザＢに対してフィールド４３０で送信され、ＰＥＫ署名はＢＳＲ−ＢからユーザＢに対してパケットに関連付けて送信される。

ＳＥＫがネットワークを介して転送されるべき場合、その転送は多様で可能な任意の技術によって実行可能である。このような技術の一つによると、新しいセッションの最初のトラフィックパケットは、適切なＰＥＫで暗号化された少なくともそのペイロードと一緒に送信される。ユーザＡがパケットをＢＳＲ−Ａに対して送信するとき、ユーザＡはＳＥＫを、ユーザＡがＢＳＲ−Ａと共有する秘匿キーにより暗号化されたものとして、添付する。ＢＳＲ−ＡはＳＥＫを復号化し、現存するセキュリティアソシエーションを使用してＳＥＫをＢＳＲ−Ｂに対して配信する。ＢＳＲ−ＢがパケットをユーザＢに対して送信するとき、ＢＳＲ−ＢはＳＥＫを、ユーザＢがＢＳＲ−Ｂと共有する秘匿キーにより暗号化されたものとして、添付する。

多様な代替の技術の１つによると、ＳＥＫは呼をセットアップする間に適切なプロトコルを使用して配信される。例えばＳＥＫは、ＶｏＩＰ呼または例えばＩＭＳ（ＩＰマルチメディアサブシステム（ｌＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ））に基づいたサービスをセットアップするためのＳＩＰ（セッションイニシエーションプロトコル）メッセージとともに配信可能である。

Claims (4)

1. 完全性キーを共有する第１のノードおよび第２のノードを含むネットワークにおいてパケットを処理する方法であって、
   少なくともパケットのペイロード部分がパケット固有暗号化キーで暗号化されるように第１のノードから第２のノードに対してパケットを伝送するステップと、
   パケットを検証するために使用されるべきパケット固有暗号化キーの署名を計算するステップであって、前記署名の計算が完全性キーを使用して実行されるステップと、
   パケット固有暗号化キー署名を第２のノードに対してパケットに関連付けて伝送するステップと
   を含む、方法。
2. 完全性キーを共有する第１のノードおよび第２のノードを含むネットワークにおいてパケットを処理する方法であって、
   少なくともパケットのペイロード部分がパケット固有暗号化キーで暗号化されるように第１のノードからパケットを受信するステップと、
   第１のノードからパケット固有暗号化キーの署名を受信するステップと、
   パケット固有暗号化キーの署名を計算するステップであって、前記計算が完全性キーを使用して実行されるステップと、
   計算されたキー署名を受信されたキー署名と比較するステップと、
   計算されたキー署名が受信されたキー署名と一致する場合、パケットを検証されたものとして受け付けるステップと
   を第２のノードにおいて含む、方法。
3. パケット固有暗号化キーを使用してパケットを復号化するステップをさらに含む、請求項２に記載の方法。
4. パケットが検証されたものとして受け付けられた場合、パケットを送信先に対して転送するステップをさらに含む、請求項２に記載の方法。

Images