通信システムにおけるセキュリティ起動検出のための方法および構成
明示的なシグナリングが無いユーザ端末（１２）によるセキュアモードの開始を検出するための方法および装置が提供される。ネットワーク（３０）がユーザ端末に、セキュアモードに切り替え、ユーザ端末からデータパケットを受信するように命令した後で、受信側のネットワークノード（２２）は、ユーザ端末によって有効なセキュリティが受信されるデータパケットに対して適用されているかどうかを判定することにより、前記ユーザ端末のセキュリティモードを判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、移動体通信のためのセキュリティモードの手続きに関し、特に、ユーザ端末のセキュリティモードを検出するための手続きに関する。
【背景技術】
【０００２】
移動体通信ネットワークにおいて、ユーザ端末は、セキュアモード（ｓｅｃｕｒｅ ｍｏｄｅ）または非セキュアモード(ｉｎｓｅｃｕｒｅ ｍｏｄｅ)で作動することがある。セキュアモードでは、ユーザ端末は、アップリンク・トラフィックチャネルおよび制御チャネル上でネットワークへと転送されるデータパケットを暗号化（ｃｉｐｈｅｒ）またはエンクリプト(ｅｎｃｒｙｐｔ)することにより、送信されるパケットに対してセキュリティを適用する。シグナリングチャネル上では、ユーザ端末がさらに、送信されるデータパケットに対して完全性保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｉｏｎ）を追加する。非セキュアモードでは、暗号化および完全性保護が停止される。ネットワークノード（例えば、基地局またはＭＭＥ）がユーザ端末に対してセキュアモード命令（ＳＭＣ：ｓｅｃｕｒｅ ｍｏｄｅ ｃｏｍｍａｎｄ）を送信すると、ユーザ端末は、セキュアモードで作動し始める。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
現在、ユーザ端末がセキュアな（ｓｅｃｕｒｅ）送信を開始した場合に基地局が検出する方法はない。セキュアモードが開始される前に、ユーザ端末は、アップリンクで保護されていないデータパケットを送信する。基地局がＳＭＣを送信した後に、ユーザ端末は、ＳＭＣを受信する前またはセキュアモードがユーザ端末により起動される前に、アップリンクにおいて１つ以上の保護されていないパケットを送信する可能性がある。基地局は、ＳＭＣがユーザ端末に送信された後に、保護されていないデータパケットと、保護されたデータパケットとを区別する方法がない。
【０００４】
ユーザ端末によるセキュアモードの開始を検出する際の問題は、ＳＭＣ（３ＧＰＰ ＲＡＮ２ ｃｏｎｔｒｉｂｕｔｉｏｎ Ｒ２-０７３４６６、Ｓｅｃｔｉｏｎ２．２、ｏｐｔｉｏｎ１参照）を送信する前に、ユーザ端末からの全てのトラフィックを一時停止する（ｓｕｓｐｅｎｄ）ことによって解決されることもある。従って、ＳＭＣがダウンリンクで送信される時間から、セキュアモードがアップリンクで起動される時間の間に、アップリンク上に、暗号化されておらず保護されていないシグナリングは存在しない。この場合、ＳＭＣが送信された後の最初のアップリンク・シグナリングパケットは、暗号化されており完全性が保護されていることが見込まれる。しかし、このアプローチの欠点は、アップリンク送信がしばらくの間一時停止される必要があり、従って、幾つかのシグナリングを延期する／遅延させる必要があることもあるということである。
【０００５】
代替的な解決策は（３ＧＰＰ ＲＡＮ２ ｃｏｎｔｒｉｂｕｔｉｏｎ Ｒ２−０７３４６６、Ｓｅｃｔｉｏｎ２．２、ｏｐｔｉｏｎ２参照）、セキュアモードがユーザ端末で開始されているかどうかを示すために、アップリンクで送信される全てのパケットについて、パケットのヘッダにフラグを含めることであろう。このフラグによって、ネットワークは、セキュリティが開始されているかを検出し、パケットを適切に処理しうる。すなわち、暗号化されていないデータと、それを伝達する前に、解読および／または完全性検査のデータと、をそれぞれ伝達する。このアプローチによる欠点は、セキュリティの起動時にのみ必要とされるフラグが、最初の幾つかのパケットのみならず、セキュリティ起動された後に送信される全てのパケットについて余分なオーバーヘッドをもたらすことである。
【０００６】
同様の問題が、セキュリティが開始された後にユーザ端末がセキュリティ状態を変更する場合に発生することもある。例えば、障害イベントのために、ユーザ端末がセキュアモードを停止し、または、セキュリティ状態が無効になることがある。前者の場合には、受信機は、保護されていないデータパケットと保護されたデータとを区別することが出来できず、後者の場合には、受信機は、セキュリティ障害を検出することが出来ないであろう。ヘッダ圧縮が利用される場合には、受信機は、ＩＰヘッダを伸張するということの失敗と、セキュリティ障害と、を区別することが出来ないであろう。
【０００７】
セキュアモードが停止される場合に、この問題は、ユーザ端末からの全てのトラフィックを一時停止することにより、または、パケットのヘッド内でフラグを利用することによっても解決されうる。これら解決策は、先に述べたのと同じ欠点を持つ。セキュリティが機能しない場合、ＩＰヘッダが不要なデータ（ｇａｒｂａｇｅ）なのか、またはＩＰヘッダが意味的に正しいＩＰヘッダを表しているのかを検出することにより、セキュリティ障害を検出することが可能である。しかし、ヘッダ圧縮が利用される場合には、受信機は、ヘッダを伸張するということの失敗と、セキュリティ障害と、を区別することが不可能である。受信されるデータがほとんど無く、この検出を可能にするほどスタティック（ｓｔａｔｉｃ）であると考えられる、圧縮された情報の部分が無い（連続するＩＰヘッダ間のリダンダンシーが削除されている）。従って、伸張の失敗とセキュリティ障害とを区別するための、ヘッダ圧縮が利用される場合のための検査が存在しない。
【課題を解決するための手段】
【０００８】
本発明は、セキュアモード命令（ＳＭＣ）がユーザ端末に送信された後で、ユーザ端末によるセキュアモードの開始を検出するための方法および装置を提供する。セキュアモードでは、ユーザ端末は、アップリンク・トラフィックチャネルおよび制御チャネル上でネットワークへと送信されるパケットに対する暗号化および／または完全性保護の形態で、セキュリティを適用する。基地局または他のネットワークノードは、受信されるデータパケットが有効なセキュリティ（例えば、完全性保護および／または暗号化）を有するかどうかを判定することにより、ユーザ端末によるセキュアモードの開始をブラインド方式で（ｂｌｉｎｄｌｙ）検出し、このようなブラインド検出（ｂｌｉｎｄ ｄｅｔｅｃｔｉｏｎ）に基づいて適切な処理を決定することが出来る。
【０００９】
第１の例示的な実施形態において、ネットワークノードは、送信されるデータパケットに適用されている有効な完全性保護に基づいて、ユーザ端末がセキュリティを利用し始めたことを検出する。ネットワークがユーザ端末から送信されるアップリンク・データパケットの完全性保護を検証出来る場合には、ユーザ端末がセキュリティを利用し始めたことを推定しうる。ネットワークノードが、適用された有効な完全性保護をデータパケットが有することを検証出来ない場合には、ネットワークノードは、ユーザ端末がセキュリティを利用していないと推定しうる。保護されていないアップリンク送信の場合に、ネットワークノードは、パケットの（完全性保護のタグではない）幾つかのデータが、完全性保護のタグであると推定する可能性がある。任意のデータが、或るパケットのための完全性保護のタグであると確認される可能性は低いので、この実施形態は、ユーザ端末がセキュリティを利用し始めていないことを示すに十分に信頼性があるものと見なされうる。この手続きは、適切な長さの完全性保護のタグを選択することにより、任意の信頼度に設定されうる。
【００１０】
第２の例示的な実施形態において、ネットワークノードは、アップリンクパケットが、適用された有効な完全性保護を有するかどうかに基づいて、ユーザ端末がセキュリティ状態（例えば、保護の利用）を変更したことを検出する。この場合に、有効な完全性保護の欠如は、セキュリティがユーザ端末により停止されたという標識と見なされる。この場合、完全性保護を確認する試みは、存在しないまたは誤った完全性保護のデータを用いて行なわれ、従って、高い確率で失敗する可能性がある（例えば、正しい完全性保護データと推定される情報が、実際には、他のセキュリティ構成または他の種類のデータと一致する）。
【００１１】
第３の例示的な実施形態において、ネットワークノードは、ヘッダ圧縮処理の結果、または、セキュリティが解除された後に行なわれるチェックサムに基づいて、ユーザ端末がアップリンクでセキュリティを利用し始めたことを検出する。デコンプレッサ（ｄｅｃｏｍｐｒｅｓｓｏｒ）によるエラー回復の仕組みの初期化、および／または、スタティック・コンテキスト（ｓｔａｔｉｃ−ｃｏｎｔｅｘｔ）破損の推定が、アップリンクでユーザ端末によりセキュリティが利用されていないことを示すために利用される。検出は、データパケットに付与されるシーケンスの番号を利用することにより改善されうる。検出は、初期の繰り返される失敗に基づいて、または、圧縮アルゴリズムによる回復の試みが失敗した数に基づいて即座に推定される。
【００１２】
第４の例示的な実施形態において、ネットワークノードは、ヘッダ伸張処理の結果、または、セキュリティが解除された後に行なわれるチェックサムに基づいてセキュリティ障害を検出する。デコンプレッサによるエラー回復の仕組みの初期化、および／または、スタティック・コンテキストの被害の推定が、セキュリティ障害が起きていることを示すために利用される。検出は、データパケットに付与されるシーケンスの番号を利用することにより改善されうる。検出は、初期の繰り返される失敗に基づいて、または、圧縮アルゴリズムによる回復の試みが失敗した数に基づいて即座に推定される。
【００１３】
当然のことながら、本発明は、上記の特徴および効果に限定されない。当業者は、以下の詳細な記載を読めば、追加的な特徴および効果が分かるであろう。
【図面の簡単な説明】
【００１４】
【図１】例示的な通信システムを示す。
【図２】完全性保護の前に暗号化が適用される場合に、ユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図３】完全性保護の前に暗号化が適用される場合に、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図４】暗号化の前に完全性保護が適用される場合に、ユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図５】暗号化の前に完全性保護が適用される場合に、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図６】ヘッダ伸張の結果に基づいてユーザ端末によるセキュリティモードの検出するために実施される例示的な方法を示す。
【図７】エラーデコーディングの結果に基づいてユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図８】ヘッダ伸張および／または復号の結果に基づいて、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図９】セキュリティがユーザ端末により起動された後にセキュリティ障害を検出するために実施される例示的な方法を示す。
【発明を実施するための形態】
【００１５】
図面を参照すると、図１は、例示的な通信システム１０を示している。通信システム１０は、複数のユーザ端末１２と、１つ以上の基地局２２を有する無線アクセスネットワーク２０と、コアネットワーク３０と、を含む。ユーザ端末は、例えば、携帯電話、個人用デジタル補助装置（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、ラップトップコンピュータ、または、他の無線通信装置を含んでもよい。ユーザ端末１２は、無線を介して、ＲＡＮ２０内の基地局２２と通信する。基地局２０は、ユーザ端末１２へとデータを送信し、ユーザ端末１２からデータを受信するための送受信機２６と、基地局２２により送信および受信されるデータを処理するためのプロセッサ２４と、を含む。コアネットワーク３０は、ＲＡＮ２０を、インターネットのような外部のパケットデータネットワーク（図示せず）と接続する。基地局２２は、コアネットワーク３０から受信されたデータを、無線通信チャネルを介してユーザ端末１２１２へと送信し、ユーザ端末１２から受信されたデータを、無線通信チャネルを介してコアネットワーク３０へと転送する。通信ネットワーク１０は、任意の既知の通信規格、例えば、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）規格を実現しうる。
【００１６】
通信ネットワーク１０は、ネットワークのサービスへのセキュアなアクセスをユーザ端末１２に提供するために、幾つかのネットワークアクセスのセキュリティ処置を講じる。これらのセキュリティ処置は、完全性保護と暗号化を含む。完全性保護は、進行中の通話において望まれない効果を引き起こす意図を持って不正なネットワークが不必要なシグナリングメッセージを送信することを防止する、ＵＭＴＳネットワーク内の義務的なセキュリティ機能である。ＵＭＴＳネットワークでは、完全性保護は義務である。暗号化は、無線を介して送信される全てのシグナリングおよびデータメッセージが暗号化またはエンクリプトされることを保証することにより、第三者によって盗聴されることを防止するための、ＵＭＴＳネットワーク内の任意のセキュリティ機能である。完全性保護は、典型的に、シグナリングベアラを介して送信されるメッセージに対して行なわれ、暗号化は、シグナリングベアラとデータベアラの双方のために行なわれる。
【００１７】
ＵＭＴＳシステムでは、セキュアモード（完全性保護および暗号化が有効化）は、コアネットワークがセキュアモード命令（ＳＭＣ）をユーザ端末に対して送信する場合に開始される。ユーザ端末１２がコアネットワーク３０との無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）接続を確立した場合に、ユーザ端末１２は、コアネットワーク３０に対してユーザ端末の性能を送信する。この情報は、どのセキュリティアルゴリズムをユーザ端末１２がサポートしているのかをコアネットワーク３０に報知する。この交換の間に、セキュアモードは有効化されない。コアネットワーク３０がユーザ端末１２からベアラ確立要求を受信する場合に、コアネットワーク３０およびユーザ端末１２は、利用されるセキュリティパラメータ値（例えば、セキュリティ鍵）およびセキュリティアルゴリズムを交渉するために、認証および鍵照合（ＡＫＡ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）の手続きを行なう。ＡＫＡの手続きに続いて、コアネットワーク３０は、セキュアモードを開始するために、ユーザ端末１２にＳＭＣを送信する。ユーザ端末１２は、セキュリティコンテキスト（ｓｅｃｕｒｉｔｙ ｃｏｎｔｅｘｔ）と称されることもある、交渉されたセキュリティパラメータ値を用いた自身の暗号化および完全性保護アルゴリズムを初期化することにより応答し、その後、セキュリティモード応答をコアネットワーク３０に送信することにより、ＳＭＣを確認する。
【００１８】
セキュアモードが開始される前には、ユーザ端末１２は、保護されていないデータパケットをアップリンクで送信する。本明細書では、「データパケット」は、シグナリングおよび／またはトラフィックパケットを示している。ユーザ端末１２がアップリンクでセキュリティを起動する場合に、ユーザ端末１２は、送信されるパケットに対して暗号化と完全性保護を適用する。ＳＭＣがコアネットワーク３０により送信される時間から、ユーザ端末１２がセキュアモードを開始する時間の間に幾らかの遅延がある可能性があるので、基地局２２は、ＳＭＣがユーザ端末１２に送信された後に保護されていないデータと保護されたデータとを区別するために、幾つかのアルゴリズムを必要とする。以下に記載される実施形態において、基地局２２は、ユーザ端末１２のセキュリティ状態を検出するためのセキュリティプロセッサ２４を含む。
【００１９】
完全性保護および暗号化の形態でのセキュリティは、以下の順序のいずれかで適用されうる。
・最初に完全性保護、続いて暗号化
・最初に暗号化、続いて完全性保護
どちらの場合でも、基地局２２は、ＳＭＣの送信に続いてユーザ端末がセキュリティを開始したかどうかを検出するために、完全性保護の存在（又は不在）を利用しうる。
【００２０】
図２は、完全性保護の前に暗号化が適用される場合にセキュアモードの開始を検出するための方法１００を示している。方法１００は、ユーザ端末１２へのＳＭＣの送信に続いて、基地局２２がアップリンクでシグナリングパケットを受信する場合に開始する（ブロック１０２）。この場合に、受信されたシグナリングパケットを解読せずに、ユーザ端末１２でのセキュリティ利用の状態を検出するために、完全性保護が基地局２２によって利用されてもよい。鍵およびアルゴリズムを含む全てのセキュリティパラメータを既に有する基地局２２は、少なくともダウンリンクでＳＭＣを送信した時間から受信される、全ての受信されたアップリンクパケットの完全性を検査する（ブロック１０４）。セキュリティプロセッサ２４は、完全性検査の結果に基づいて、パケットの次の処理を決定する（ブロック１０６）。シグナリングパケットが完全性検査を通った場合に、基地局２２は、アップリンクでセキュリティが起動されていると推定し、パケットの解読に移る（ブロック１０８）。パケットが完全性検査に通らない場合には、基地局２２は、パケットを暗号化されていないものとして扱い、パケットがセキュリティ無しで送信されたという任意の標識と共に伝達する（ブロック１１０）。セキュリティが既に開始しており、かつパケットが完全性検査に通らない場合には、ネットワーク３０は、パケットを破棄し、または、パケットが完全性検査に通らなかったことを示しうる。
【００２１】
図３は、完全性保護の前に暗号化が適用される状況、すなわち完全性保護が暗号化されたデータパケットに対して適用される状況においてユーザ端末１２によるセキュリティの開始を検出するための、基地局２２内の例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、完全性検査ユニット４０と、解読ユニット４２と、を含む。完全性検査ユニット４０は、ＳＭＣがユーザ端末１２に送信された後に受信される全てのシグナリングパケットに対して完全性検査を行なう。解読ユニット４２は、完全性検査に通った、すなわち暗号化がユーザ端末１２により有効化されていることを意味する受信されたシグナリングパケットを解読する。完全性検査に落ちたシグナリングパケットは、セキュリティプロセッサ２４により、完全性保護が有効ではないという標識と共に出力される。図３がシグナリングパケットの処理を示すことに注意されたい。トラフィックパケットの処理は示されていない。セキュリティプロセッサ２４は、先に述べたようにユーザ端末１２によるセキュアモードの開始を検出した場合に、データ経路のための解読を有効化する。完全性保護は、トラフィックデータパケットに対しては行なわれない。
【００２２】
図４は、完全性保護が暗号化の前に適用され場合にユーザ端末１２によるセキュアモードの開始を検出するための代替的な方法１５０を示している。方法は、基地局２２がシグナリングパケットを受信した場合に開始する（ブロック１５２）。この場合、基地局２２は、セキュリティが開始していると推定する。基地局２２は、シグナリングパケットを一時的に格納し（ブロック１５４）、受信されたシグナリングパケットを解読し（ブロック１５６）、解読されたシグナリングパケットの完全性を検査する（ブロック１５８）。セキュリティプロセッサ２４は、完全性検査の結果に基づいて、シグナリングパケットの次の処理を決定する（ブロック１６０）。パケットが完全性検査に通った場合には、セキュリティが開始されていると見なされ、解読されたパケットがセキュアパケット（ｓｅｃｕｒｅ ｐａｃｋｅｔ）として処理される（ブロック１６２）。パケットが完全性検査に通らない場合には、基地局２２は、解読処理の前に格納された受信されたパケットの複写を呼び出し、受信されたパケットを、パケットがセキュリティ無しで送信されたという（任意の）標識と一緒に転送する（ブロック１６４）。この方式の欠点は、余分な記憶域を必要とし、さらに、解読が必要ではない幾つかの場合に解読のための不必要な処理を招くことである。
【００２３】
図５は、完全性保護が暗号化の前に適用される状況において、ユーザ端末１２によるセキュアモードの開始を検出するための、基地局２２における例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、完全性検査ユニット４０と、解読ユニット４２と、メモリ４４と、を含む。解読ユニット４２は、ＳＭＣがユーザ端末１２に送信された後に受信された、受信されたシグナリングパケットを解読し、解読されたシグナリングパケットを完全性検査ユニット４０へと伝達する。完全性検査ユニット４０は、解読されたシグナリングパケットに対して完全性検査を行なう。メモリ４４は、セキュリティ処理が行なわれる間、受信されたシグナリングパケットを格納する。解読されたシグナリングパケットが完全性検査に通った場合、このことはセキュリティがユーザ端末１２により有効化されていることを意味するのだが、完全性検査ユニット４０は、解読されたシグナリングパケットを出力する。解読されたシグナリングパケットが完全性検査に落ちた場合には、受信されたシグナリングパケットが、シグナリングパケットが保護されていないという任意の標識と共に出力される。図５は、シグナリングパケットの処理を示すことに注意されたい。トラフィックパケットの処理は示されていない。セキュリティプロセッサ２４は、先に述べたようにユーザ端末１２によるセキュアモードの開始を検出する場合に、データ経路のための解読を有効化する。完全性保護は、トラフィックデータパケットに対しては行なわれない。
【００２４】
本発明の他の実施形態において、ユーザ端末１２によるセキュリティの開始は、アップリンクで送信されるＩＰパケットについてのヘッダ圧縮の結果に基づいて検出されうる。ＩＰパケットのヘッダ圧縮は、通常、ユーザプレーンＩＰデータのための暗号化の前に行なわれる。完全性保護も、利用される場合には、圧縮の後に適用される。ヘッダ圧縮は、無線を介して送信されるデータの量を、情報のいかなる損失も無く低減するために有用である。
【００２５】
受信側では、受信される圧縮されたヘッダの伸張が、解読と完全性保護（利用される場合）の後に行なわれる。ＲＯＨＣ（例えば、ＩＥＴＦ ＲＦＣ３０９５、ＲＦＣ４９９５、ＲＦＣ４９９６）のようなヘッダ圧縮アルゴリズムは、通常、圧縮されたヘッダ内のＣＲＣを利用する。ＣＲＣにより、デコンプレッサは、伸張の試みの結果を検証し、検証が失敗した場合には、回復の仕組み（例えば、フィードバック、および、コンテキスト更新のための要求）を開始することが可能となる。
【００２６】
伸張が成功するか否かは、適切で一貫した（ｃｏｈｅｒｅｎｔ）コンテキスト状態（圧縮および伸張状態）と、圧縮された情報内にエラーが無いことに依存する。伸張中にデコンプレッサにより利用されるコンテキスト状態が、ヘッダを圧縮する際にコンプレッサにより利用されたコンテキスト状態と同じではない場合に、ヘッダの伸張は失敗する。ヘッダの伸張は、デコンプレッサに出力される圧縮されたデータに誤りがある場合（例えばデータが、エラーのある少なくとも１つのビットを有する）にも失敗する可能性がある。
【００２７】
解読の試みが失敗した場合、データパケットは通常デコンプレッサにより破棄される。従って、上位層はどの有用なデータも受信しない。失敗が繰り返されると、説明がつかないエラーが頻繁に起こることは予期されないので、デコンプレッサは典型的に、自身が伸張のために利用するコンテキスト状態に問題があると推定する。デコンプレッサは、自身のコンテキストが破損していると判定する場合に、例えば、破損している可能性があるコンテキスト状態を修復するために特定のアクションを要求するコンプレッサに対してフィードバックを送信することにより、エラー回復を開始する。
【００２８】
図６は、アップリンクで送信されるＩＰパケットのためのヘッダ伸張の結果に基づいて、ユーザ端末１２によるセキュアモードの開始を判定するための、例示的な方法２００を示している。本方法は、本明細書でデータパケットと総称される、シグナリングパケットとトラフィックパケットの双方のために利用されうる。ヘッダ圧縮が利用される場合には、ユーザ端末１２によるセキュリティ起動の検出は、圧縮されたデータ内で伝達されるＣＲＣを利用して伸張を成功裏に検証するということの１つ以上の失敗に基づいてもよい（ＩＥＴＦ ＲＦＣ３０９５、ＲＦＣ４９９５、ＲＦＣ４９９６参照）。先に述べたように、ヘッダ圧縮／伸張アルゴリズムは、典型的に、伸張の結果を検証するためにヘッダのＣＲＣを利用する。圧縮されたＩＰパケットが受信された場合（ブロック２０２）、受信されたパケットはメモリに格納される（ブロック２０４）。受信されたパケットは、その後、ユーザ端末１２がセキュリティを適用しているという推定に基づいて解読される（ブロック２０６）。解読に続いて、ヘッダが伸張され（ブロック２０８）、伸張の結果がヘッダのＣＲＣを用いて検査される（ブロック２１０）。伸張が成功した場合には、ユーザ端末１２がセキュリティを適用したと推定することが可能であり、解読されたパケットはセキュアデータパケット（ｓｅｃｕｒｅ ｄａｔａ ｐａｃｋｅｔ）として処理される（ブロック２１２）。伸張が失敗した場合には、ユーザ端末１２がセキュリティを適用しなかったと推定することが可能であり、受信されたパケットは非セキュアデータパケット（ｉｎｓｅｃｕｒｅ ｄａｔａ ｐａｃｋｅｔ）として処理される（ブロック２１４）。後に、セキュリティ起動が検出される前に最初に伸張に失敗したパケットについて、これらのパケットを検出処理中にバッファリングすることにより、伸張を再び試みてもよい。本実施形態では、完全性保護が利用されているか否かで違いはない。
【００２９】
他の形態のチェックサム、他の誤り検出符号が、暗号化の起動を検出するために同様に利用されうる。例えば、パケットが、暗号化されたチェックサムをパケットの一部として含む場合に、解読の後のチェックサム検証の結果が、ユーザ端末１２によるセキュアモード１２の開始を示すために利用されてうる。解読の後でチェックサムが有効である場合には、ユーザ端末１２がセキュリティを利用し始めたと推定することが可能である。反対に、解読の後にチェックサムが失敗する場合には、ユーザ端末１２はセキュリティを利用し始めていないと推定しうる。
【００３０】
図７は、誤り検出デコーディング（ｅｒｒｏｒ ｄｅｔｅｃｔｉｏｎ ｄｅｃｏｄｉｎｇ）の結果に基づいて、ユーザ端末１２によるセキュアモードの開始を判定するための例示的な方法２５０を示している。ＣＲＣまたは他の誤り検出符号が利用される場合に、ユーザ端末１２によるセキュリティ起動の検出は、データパケットを復号するということの１つ以上の失敗に基づいてもよい。符号化されたデータパケットが受信された場合（ブロック２５２）、受信されたデータパケットはメモリに格納される（ブロック２５４）。受信されたデータパケットは、その後、ユーザ端末１２がセキュリティを適用しているという推定に基づいて解読される（ブロック２５６）。解読に続いて、データパケットが復号される（ブロック２５８）。データパケットが成功裏に復号される場合に（ブロック２６０）、ユーザ端末１２はセキュリティを適用したと推定することが可能であり、解読されたデータパケットが処理される（ブロック２６２）。データパケットを成功裏に復号することに失敗した場合には、ユーザ端末１２はセキュリティを適用しなかったと推定することが可能であり、受信されたデータパケットは、非セキュアデータパケットとして処理される（ブロック２６４）。
【００３１】
図８は、ＩＰヘッダ圧縮が利用されている状況、または、受信されるデータパケットが暗号化より先に適用されるチェックサムまたは他の誤り検出符号を含む状況において、ユーザ端末１２によるセキュアモードの開始を検出するための、基地局２２における例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、解読ユニット４２と、セキュリティ検出ユニット４６と、メモリ４４と、を含む。解読ユニット４２は、ＳＭＣがユーザ端末１２に送信された後に受信されたデータパケットを解読し、解読されたデータパケットを、セキュリティ検出ユニット４６に伝達する。セキュリティ検出ユニット４６は、ＣＲＣ検査または他の誤り検出処理の結果に基づいて、ユーザ端末１２のセキュリティの状態を検出する。メモリ４４は、セキュリティ処理が行なわれている間に、受信されたデータパケットを格納する。受信されるデータパケットが圧縮されたＩＰパケットを含む場合には、セキュリティ検出ユニット４６は、解読されたパケットのヘッダを伸張し、伸張されたヘッダのＣＲＣを検査する。受信されるデータパケットがＣＲＣまたは他の誤り検出符号を含む場合には、セキュリティ検出ユニット４６は、ＣＲＣの有効性を検査する。どちらの場合でも、ＣＲＣが有効である場合には、セキュリティ検出ユニット４６は、解読されたパケットを出力する。一方、ＣＲＣが無効である場合には、セキュリティ検出ユニット４６は、受信されたデータパケットを出力する。
【００３２】
先に記載された例示的な実施形態において、完全性保護、ヘッダ伸張、チェックサム、または、他の誤り検出符号の検出は、一旦ユーザ端末１２によるセキュアモードの開始が検出された場合には中止されてもよい。一旦セキュリティが検出されると、後続の送信されるパケットがセキュアに（ｓｅｃｕｒｅｌｙ）、例えば、暗号化および／または完全性保護が有効化されて送信されると推定することが可能である。他の実施形態において、完全性保護、ヘッダ伸張、チェックサム、または他の誤り検出符号の検出は、セキュアモードが開始した後にセキュリティ障害を検出するために続けられてもよい。
【００３３】
一旦セキュリティがユーザ端末１２により起動されると、セキュリティにおける障害が、アップリンクで送信されるデータパケットの完全性保護を検証するということの１つ以上の失敗に基づいて検出されうる。一旦完全性保護がユーザ端末１２により開始されると、基地局２２は、アップリンクで送信される全ての後続のデータパケットが保護されていると推定する。複数のデータパケットについて、完全性保護が検証されえない場合には、セキュリティ障害が起きていると推定することが可能である。
【００３４】
ＩＰヘッダのためのヘッダ圧縮が利用されている場合には、セキュリティ障害が、圧縮されたデータ内で伝達されるＣＲＣを利用して伸張を成功裏に検証するということの１つ以上の失敗に基づいて検出されうる（ＩＥＴＦ ＲＦＣ３０９５、４９９５、４９９６参照）。受信されるデータパケットは解読され、その後、ＩＰヘッダが伸張される。伸張は、ヘッダのＣＲＣを利用して検証される。１つ以上のデータパケットについて伸張が失敗する場合には、セキュリティ障害が起きていると推定することが可能である。本実施形態において、完全性保護が利用されているか否かで違いはない。本技術は、基地局２２によって、またはユーザ端末１２によって、セキュリティ障害を検出するために利用されうる。
【００３５】
データパケットが、データパケットの一部として暗号化された誤り検出符号またはチェックサムを含む場合に、アクティブ（ａｃｔｉｖｅ）から非アクティブ(ｉｎａｃｔｉｖｅ)へのセキュリティ状態の変化、または、セキュリティ障害が、チェックサムの検証の１つ以上の失敗に基づいて検出されうる。チェックサムの検証の失敗が繰り返されると、セキュリティ障害の兆候として捉えられる。本技術は、基地局２２によって、またはユーザ端末１２によって、セキュリティ障害を検出するために利用されうる。
【００３６】
図９は、セキュアモードがユーザ端末１２により有効化された後にセキュリティ障害を検出するための１つの例示的な方法３００を示している。本方法３００は、基地局２２がユーザ端末１２によるセキュアモードの開始を検出した後に開始する。従って、全てのデータパケッにセキュリティが適用されていると推定される。データパケットが受信される場合に（ブロック３０２）、基地局２２は、適用されたセキュリティが有効であることを確認するためにセキュリティ検査を行なう（ブロック３０４）。パケットがセキュリティ検査に落ちた場合には（ブロック３０６）、基地局は、カウンタを増分し（ブロック３１０）、所定の閾値とカウント値とを比較する（ブロック３１２）。カウント値が閾値と等しい場合には、セキュリティ障害が示される（ブロック３１４）。データパケットに適用されたセキュリティが有効である場合には、基地局２２は、ゼロまでカウント値をリセットする（ブロック３０８）。
【００３７】
本明細書で記載される方法は、基地局２２および／またはユーザ端末１２内のプロセッサにより実行されるソフトウェアにより実施されうる。ソフトウェアは、コンピュータ読取りが可能な媒体に格納された、プロセッサにより実行可能な命令を含む。例示的なコンピュータ読取り可能な媒体は、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュ（ＦＬＡＳＨ）メモリ、または他の公知のメモリ装置を含んでもよい。
【００３８】
本発明の効果は、アップリンクのシグナリングがセキュアモードの起動中に一時停止される必要がないため、遅延を低減するということである。暗号化／完全性保護の状態の余分な標識がパケットのヘッダ内で必要でないため、オーバーヘッドが低減される。他の効果は、記憶域の要件が下げられること、および、処理が低減されることを含む。本発明はまた、ヘッダ圧縮が利用される場合にセキュリティ障害を検出するという問題を解決する。
【００３９】
本発明は、当然のことながら、本発明の基本的な特徴から逸脱することなく、本明細書で特に記載されるものとは他のやり方でも実施されうる。本実施形態は、あらゆる点で例示的なものであって限定的なものではないと見なされ、添付の請求項の意味および均等の範囲内で生じる全ての変更が、本明細書に含まれるものとする。
【技術分野】
【０００１】
本発明は、一般に、移動体通信のためのセキュリティモードの手続きに関し、特に、ユーザ端末のセキュリティモードを検出するための手続きに関する。
【背景技術】
【０００２】
移動体通信ネットワークにおいて、ユーザ端末は、セキュアモード（ｓｅｃｕｒｅ ｍｏｄｅ）または非セキュアモード(ｉｎｓｅｃｕｒｅ ｍｏｄｅ)で作動することがある。セキュアモードでは、ユーザ端末は、アップリンク・トラフィックチャネルおよび制御チャネル上でネットワークへと転送されるデータパケットを暗号化（ｃｉｐｈｅｒ）またはエンクリプト(ｅｎｃｒｙｐｔ)することにより、送信されるパケットに対してセキュリティを適用する。シグナリングチャネル上では、ユーザ端末がさらに、送信されるデータパケットに対して完全性保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｉｏｎ）を追加する。非セキュアモードでは、暗号化および完全性保護が停止される。ネットワークノード（例えば、基地局またはＭＭＥ）がユーザ端末に対してセキュアモード命令（ＳＭＣ：ｓｅｃｕｒｅ ｍｏｄｅ ｃｏｍｍａｎｄ）を送信すると、ユーザ端末は、セキュアモードで作動し始める。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
現在、ユーザ端末がセキュアな（ｓｅｃｕｒｅ）送信を開始した場合に基地局が検出する方法はない。セキュアモードが開始される前に、ユーザ端末は、アップリンクで保護されていないデータパケットを送信する。基地局がＳＭＣを送信した後に、ユーザ端末は、ＳＭＣを受信する前またはセキュアモードがユーザ端末により起動される前に、アップリンクにおいて１つ以上の保護されていないパケットを送信する可能性がある。基地局は、ＳＭＣがユーザ端末に送信された後に、保護されていないデータパケットと、保護されたデータパケットとを区別する方法がない。
【０００４】
ユーザ端末によるセキュアモードの開始を検出する際の問題は、ＳＭＣ（３ＧＰＰ ＲＡＮ２ ｃｏｎｔｒｉｂｕｔｉｏｎ Ｒ２-０７３４６６、Ｓｅｃｔｉｏｎ２．２、ｏｐｔｉｏｎ１参照）を送信する前に、ユーザ端末からの全てのトラフィックを一時停止する（ｓｕｓｐｅｎｄ）ことによって解決されることもある。従って、ＳＭＣがダウンリンクで送信される時間から、セキュアモードがアップリンクで起動される時間の間に、アップリンク上に、暗号化されておらず保護されていないシグナリングは存在しない。この場合、ＳＭＣが送信された後の最初のアップリンク・シグナリングパケットは、暗号化されており完全性が保護されていることが見込まれる。しかし、このアプローチの欠点は、アップリンク送信がしばらくの間一時停止される必要があり、従って、幾つかのシグナリングを延期する／遅延させる必要があることもあるということである。
【０００５】
代替的な解決策は（３ＧＰＰ ＲＡＮ２ ｃｏｎｔｒｉｂｕｔｉｏｎ Ｒ２−０７３４６６、Ｓｅｃｔｉｏｎ２．２、ｏｐｔｉｏｎ２参照）、セキュアモードがユーザ端末で開始されているかどうかを示すために、アップリンクで送信される全てのパケットについて、パケットのヘッダにフラグを含めることであろう。このフラグによって、ネットワークは、セキュリティが開始されているかを検出し、パケットを適切に処理しうる。すなわち、暗号化されていないデータと、それを伝達する前に、解読および／または完全性検査のデータと、をそれぞれ伝達する。このアプローチによる欠点は、セキュリティの起動時にのみ必要とされるフラグが、最初の幾つかのパケットのみならず、セキュリティ起動された後に送信される全てのパケットについて余分なオーバーヘッドをもたらすことである。
【０００６】
同様の問題が、セキュリティが開始された後にユーザ端末がセキュリティ状態を変更する場合に発生することもある。例えば、障害イベントのために、ユーザ端末がセキュアモードを停止し、または、セキュリティ状態が無効になることがある。前者の場合には、受信機は、保護されていないデータパケットと保護されたデータとを区別することが出来できず、後者の場合には、受信機は、セキュリティ障害を検出することが出来ないであろう。ヘッダ圧縮が利用される場合には、受信機は、ＩＰヘッダを伸張するということの失敗と、セキュリティ障害と、を区別することが出来ないであろう。
【０００７】
セキュアモードが停止される場合に、この問題は、ユーザ端末からの全てのトラフィックを一時停止することにより、または、パケットのヘッド内でフラグを利用することによっても解決されうる。これら解決策は、先に述べたのと同じ欠点を持つ。セキュリティが機能しない場合、ＩＰヘッダが不要なデータ（ｇａｒｂａｇｅ）なのか、またはＩＰヘッダが意味的に正しいＩＰヘッダを表しているのかを検出することにより、セキュリティ障害を検出することが可能である。しかし、ヘッダ圧縮が利用される場合には、受信機は、ヘッダを伸張するということの失敗と、セキュリティ障害と、を区別することが不可能である。受信されるデータがほとんど無く、この検出を可能にするほどスタティック（ｓｔａｔｉｃ）であると考えられる、圧縮された情報の部分が無い（連続するＩＰヘッダ間のリダンダンシーが削除されている）。従って、伸張の失敗とセキュリティ障害とを区別するための、ヘッダ圧縮が利用される場合のための検査が存在しない。
【課題を解決するための手段】
【０００８】
本発明は、セキュアモード命令（ＳＭＣ）がユーザ端末に送信された後で、ユーザ端末によるセキュアモードの開始を検出するための方法および装置を提供する。セキュアモードでは、ユーザ端末は、アップリンク・トラフィックチャネルおよび制御チャネル上でネットワークへと送信されるパケットに対する暗号化および／または完全性保護の形態で、セキュリティを適用する。基地局または他のネットワークノードは、受信されるデータパケットが有効なセキュリティ（例えば、完全性保護および／または暗号化）を有するかどうかを判定することにより、ユーザ端末によるセキュアモードの開始をブラインド方式で（ｂｌｉｎｄｌｙ）検出し、このようなブラインド検出（ｂｌｉｎｄ ｄｅｔｅｃｔｉｏｎ）に基づいて適切な処理を決定することが出来る。
【０００９】
第１の例示的な実施形態において、ネットワークノードは、送信されるデータパケットに適用されている有効な完全性保護に基づいて、ユーザ端末がセキュリティを利用し始めたことを検出する。ネットワークがユーザ端末から送信されるアップリンク・データパケットの完全性保護を検証出来る場合には、ユーザ端末がセキュリティを利用し始めたことを推定しうる。ネットワークノードが、適用された有効な完全性保護をデータパケットが有することを検証出来ない場合には、ネットワークノードは、ユーザ端末がセキュリティを利用していないと推定しうる。保護されていないアップリンク送信の場合に、ネットワークノードは、パケットの（完全性保護のタグではない）幾つかのデータが、完全性保護のタグであると推定する可能性がある。任意のデータが、或るパケットのための完全性保護のタグであると確認される可能性は低いので、この実施形態は、ユーザ端末がセキュリティを利用し始めていないことを示すに十分に信頼性があるものと見なされうる。この手続きは、適切な長さの完全性保護のタグを選択することにより、任意の信頼度に設定されうる。
【００１０】
第２の例示的な実施形態において、ネットワークノードは、アップリンクパケットが、適用された有効な完全性保護を有するかどうかに基づいて、ユーザ端末がセキュリティ状態（例えば、保護の利用）を変更したことを検出する。この場合に、有効な完全性保護の欠如は、セキュリティがユーザ端末により停止されたという標識と見なされる。この場合、完全性保護を確認する試みは、存在しないまたは誤った完全性保護のデータを用いて行なわれ、従って、高い確率で失敗する可能性がある（例えば、正しい完全性保護データと推定される情報が、実際には、他のセキュリティ構成または他の種類のデータと一致する）。
【００１１】
第３の例示的な実施形態において、ネットワークノードは、ヘッダ圧縮処理の結果、または、セキュリティが解除された後に行なわれるチェックサムに基づいて、ユーザ端末がアップリンクでセキュリティを利用し始めたことを検出する。デコンプレッサ（ｄｅｃｏｍｐｒｅｓｓｏｒ）によるエラー回復の仕組みの初期化、および／または、スタティック・コンテキスト（ｓｔａｔｉｃ−ｃｏｎｔｅｘｔ）破損の推定が、アップリンクでユーザ端末によりセキュリティが利用されていないことを示すために利用される。検出は、データパケットに付与されるシーケンスの番号を利用することにより改善されうる。検出は、初期の繰り返される失敗に基づいて、または、圧縮アルゴリズムによる回復の試みが失敗した数に基づいて即座に推定される。
【００１２】
第４の例示的な実施形態において、ネットワークノードは、ヘッダ伸張処理の結果、または、セキュリティが解除された後に行なわれるチェックサムに基づいてセキュリティ障害を検出する。デコンプレッサによるエラー回復の仕組みの初期化、および／または、スタティック・コンテキストの被害の推定が、セキュリティ障害が起きていることを示すために利用される。検出は、データパケットに付与されるシーケンスの番号を利用することにより改善されうる。検出は、初期の繰り返される失敗に基づいて、または、圧縮アルゴリズムによる回復の試みが失敗した数に基づいて即座に推定される。
【００１３】
当然のことながら、本発明は、上記の特徴および効果に限定されない。当業者は、以下の詳細な記載を読めば、追加的な特徴および効果が分かるであろう。
【図面の簡単な説明】
【００１４】
【図１】例示的な通信システムを示す。
【図２】完全性保護の前に暗号化が適用される場合に、ユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図３】完全性保護の前に暗号化が適用される場合に、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図４】暗号化の前に完全性保護が適用される場合に、ユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図５】暗号化の前に完全性保護が適用される場合に、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図６】ヘッダ伸張の結果に基づいてユーザ端末によるセキュリティモードの検出するために実施される例示的な方法を示す。
【図７】エラーデコーディングの結果に基づいてユーザ端末のセキュリティモードを検出するために実施される例示的な方法を示す。
【図８】ヘッダ伸張および／または復号の結果に基づいて、移動端末のセキュリティモードを検出するための基地局における例示的なプロセッサを示す。
【図９】セキュリティがユーザ端末により起動された後にセキュリティ障害を検出するために実施される例示的な方法を示す。
【発明を実施するための形態】
【００１５】
図面を参照すると、図１は、例示的な通信システム１０を示している。通信システム１０は、複数のユーザ端末１２と、１つ以上の基地局２２を有する無線アクセスネットワーク２０と、コアネットワーク３０と、を含む。ユーザ端末は、例えば、携帯電話、個人用デジタル補助装置（ＰＤＡ：ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、ラップトップコンピュータ、または、他の無線通信装置を含んでもよい。ユーザ端末１２は、無線を介して、ＲＡＮ２０内の基地局２２と通信する。基地局２０は、ユーザ端末１２へとデータを送信し、ユーザ端末１２からデータを受信するための送受信機２６と、基地局２２により送信および受信されるデータを処理するためのプロセッサ２４と、を含む。コアネットワーク３０は、ＲＡＮ２０を、インターネットのような外部のパケットデータネットワーク（図示せず）と接続する。基地局２２は、コアネットワーク３０から受信されたデータを、無線通信チャネルを介してユーザ端末１２１２へと送信し、ユーザ端末１２から受信されたデータを、無線通信チャネルを介してコアネットワーク３０へと転送する。通信ネットワーク１０は、任意の既知の通信規格、例えば、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）規格を実現しうる。
【００１６】
通信ネットワーク１０は、ネットワークのサービスへのセキュアなアクセスをユーザ端末１２に提供するために、幾つかのネットワークアクセスのセキュリティ処置を講じる。これらのセキュリティ処置は、完全性保護と暗号化を含む。完全性保護は、進行中の通話において望まれない効果を引き起こす意図を持って不正なネットワークが不必要なシグナリングメッセージを送信することを防止する、ＵＭＴＳネットワーク内の義務的なセキュリティ機能である。ＵＭＴＳネットワークでは、完全性保護は義務である。暗号化は、無線を介して送信される全てのシグナリングおよびデータメッセージが暗号化またはエンクリプトされることを保証することにより、第三者によって盗聴されることを防止するための、ＵＭＴＳネットワーク内の任意のセキュリティ機能である。完全性保護は、典型的に、シグナリングベアラを介して送信されるメッセージに対して行なわれ、暗号化は、シグナリングベアラとデータベアラの双方のために行なわれる。
【００１７】
ＵＭＴＳシステムでは、セキュアモード（完全性保護および暗号化が有効化）は、コアネットワークがセキュアモード命令（ＳＭＣ）をユーザ端末に対して送信する場合に開始される。ユーザ端末１２がコアネットワーク３０との無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）接続を確立した場合に、ユーザ端末１２は、コアネットワーク３０に対してユーザ端末の性能を送信する。この情報は、どのセキュリティアルゴリズムをユーザ端末１２がサポートしているのかをコアネットワーク３０に報知する。この交換の間に、セキュアモードは有効化されない。コアネットワーク３０がユーザ端末１２からベアラ確立要求を受信する場合に、コアネットワーク３０およびユーザ端末１２は、利用されるセキュリティパラメータ値（例えば、セキュリティ鍵）およびセキュリティアルゴリズムを交渉するために、認証および鍵照合（ＡＫＡ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ）の手続きを行なう。ＡＫＡの手続きに続いて、コアネットワーク３０は、セキュアモードを開始するために、ユーザ端末１２にＳＭＣを送信する。ユーザ端末１２は、セキュリティコンテキスト（ｓｅｃｕｒｉｔｙ ｃｏｎｔｅｘｔ）と称されることもある、交渉されたセキュリティパラメータ値を用いた自身の暗号化および完全性保護アルゴリズムを初期化することにより応答し、その後、セキュリティモード応答をコアネットワーク３０に送信することにより、ＳＭＣを確認する。
【００１８】
セキュアモードが開始される前には、ユーザ端末１２は、保護されていないデータパケットをアップリンクで送信する。本明細書では、「データパケット」は、シグナリングおよび／またはトラフィックパケットを示している。ユーザ端末１２がアップリンクでセキュリティを起動する場合に、ユーザ端末１２は、送信されるパケットに対して暗号化と完全性保護を適用する。ＳＭＣがコアネットワーク３０により送信される時間から、ユーザ端末１２がセキュアモードを開始する時間の間に幾らかの遅延がある可能性があるので、基地局２２は、ＳＭＣがユーザ端末１２に送信された後に保護されていないデータと保護されたデータとを区別するために、幾つかのアルゴリズムを必要とする。以下に記載される実施形態において、基地局２２は、ユーザ端末１２のセキュリティ状態を検出するためのセキュリティプロセッサ２４を含む。
【００１９】
完全性保護および暗号化の形態でのセキュリティは、以下の順序のいずれかで適用されうる。
・最初に完全性保護、続いて暗号化
・最初に暗号化、続いて完全性保護
どちらの場合でも、基地局２２は、ＳＭＣの送信に続いてユーザ端末がセキュリティを開始したかどうかを検出するために、完全性保護の存在（又は不在）を利用しうる。
【００２０】
図２は、完全性保護の前に暗号化が適用される場合にセキュアモードの開始を検出するための方法１００を示している。方法１００は、ユーザ端末１２へのＳＭＣの送信に続いて、基地局２２がアップリンクでシグナリングパケットを受信する場合に開始する（ブロック１０２）。この場合に、受信されたシグナリングパケットを解読せずに、ユーザ端末１２でのセキュリティ利用の状態を検出するために、完全性保護が基地局２２によって利用されてもよい。鍵およびアルゴリズムを含む全てのセキュリティパラメータを既に有する基地局２２は、少なくともダウンリンクでＳＭＣを送信した時間から受信される、全ての受信されたアップリンクパケットの完全性を検査する（ブロック１０４）。セキュリティプロセッサ２４は、完全性検査の結果に基づいて、パケットの次の処理を決定する（ブロック１０６）。シグナリングパケットが完全性検査を通った場合に、基地局２２は、アップリンクでセキュリティが起動されていると推定し、パケットの解読に移る（ブロック１０８）。パケットが完全性検査に通らない場合には、基地局２２は、パケットを暗号化されていないものとして扱い、パケットがセキュリティ無しで送信されたという任意の標識と共に伝達する（ブロック１１０）。セキュリティが既に開始しており、かつパケットが完全性検査に通らない場合には、ネットワーク３０は、パケットを破棄し、または、パケットが完全性検査に通らなかったことを示しうる。
【００２１】
図３は、完全性保護の前に暗号化が適用される状況、すなわち完全性保護が暗号化されたデータパケットに対して適用される状況においてユーザ端末１２によるセキュリティの開始を検出するための、基地局２２内の例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、完全性検査ユニット４０と、解読ユニット４２と、を含む。完全性検査ユニット４０は、ＳＭＣがユーザ端末１２に送信された後に受信される全てのシグナリングパケットに対して完全性検査を行なう。解読ユニット４２は、完全性検査に通った、すなわち暗号化がユーザ端末１２により有効化されていることを意味する受信されたシグナリングパケットを解読する。完全性検査に落ちたシグナリングパケットは、セキュリティプロセッサ２４により、完全性保護が有効ではないという標識と共に出力される。図３がシグナリングパケットの処理を示すことに注意されたい。トラフィックパケットの処理は示されていない。セキュリティプロセッサ２４は、先に述べたようにユーザ端末１２によるセキュアモードの開始を検出した場合に、データ経路のための解読を有効化する。完全性保護は、トラフィックデータパケットに対しては行なわれない。
【００２２】
図４は、完全性保護が暗号化の前に適用され場合にユーザ端末１２によるセキュアモードの開始を検出するための代替的な方法１５０を示している。方法は、基地局２２がシグナリングパケットを受信した場合に開始する（ブロック１５２）。この場合、基地局２２は、セキュリティが開始していると推定する。基地局２２は、シグナリングパケットを一時的に格納し（ブロック１５４）、受信されたシグナリングパケットを解読し（ブロック１５６）、解読されたシグナリングパケットの完全性を検査する（ブロック１５８）。セキュリティプロセッサ２４は、完全性検査の結果に基づいて、シグナリングパケットの次の処理を決定する（ブロック１６０）。パケットが完全性検査に通った場合には、セキュリティが開始されていると見なされ、解読されたパケットがセキュアパケット（ｓｅｃｕｒｅ ｐａｃｋｅｔ）として処理される（ブロック１６２）。パケットが完全性検査に通らない場合には、基地局２２は、解読処理の前に格納された受信されたパケットの複写を呼び出し、受信されたパケットを、パケットがセキュリティ無しで送信されたという（任意の）標識と一緒に転送する（ブロック１６４）。この方式の欠点は、余分な記憶域を必要とし、さらに、解読が必要ではない幾つかの場合に解読のための不必要な処理を招くことである。
【００２３】
図５は、完全性保護が暗号化の前に適用される状況において、ユーザ端末１２によるセキュアモードの開始を検出するための、基地局２２における例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、完全性検査ユニット４０と、解読ユニット４２と、メモリ４４と、を含む。解読ユニット４２は、ＳＭＣがユーザ端末１２に送信された後に受信された、受信されたシグナリングパケットを解読し、解読されたシグナリングパケットを完全性検査ユニット４０へと伝達する。完全性検査ユニット４０は、解読されたシグナリングパケットに対して完全性検査を行なう。メモリ４４は、セキュリティ処理が行なわれる間、受信されたシグナリングパケットを格納する。解読されたシグナリングパケットが完全性検査に通った場合、このことはセキュリティがユーザ端末１２により有効化されていることを意味するのだが、完全性検査ユニット４０は、解読されたシグナリングパケットを出力する。解読されたシグナリングパケットが完全性検査に落ちた場合には、受信されたシグナリングパケットが、シグナリングパケットが保護されていないという任意の標識と共に出力される。図５は、シグナリングパケットの処理を示すことに注意されたい。トラフィックパケットの処理は示されていない。セキュリティプロセッサ２４は、先に述べたようにユーザ端末１２によるセキュアモードの開始を検出する場合に、データ経路のための解読を有効化する。完全性保護は、トラフィックデータパケットに対しては行なわれない。
【００２４】
本発明の他の実施形態において、ユーザ端末１２によるセキュリティの開始は、アップリンクで送信されるＩＰパケットについてのヘッダ圧縮の結果に基づいて検出されうる。ＩＰパケットのヘッダ圧縮は、通常、ユーザプレーンＩＰデータのための暗号化の前に行なわれる。完全性保護も、利用される場合には、圧縮の後に適用される。ヘッダ圧縮は、無線を介して送信されるデータの量を、情報のいかなる損失も無く低減するために有用である。
【００２５】
受信側では、受信される圧縮されたヘッダの伸張が、解読と完全性保護（利用される場合）の後に行なわれる。ＲＯＨＣ（例えば、ＩＥＴＦ ＲＦＣ３０９５、ＲＦＣ４９９５、ＲＦＣ４９９６）のようなヘッダ圧縮アルゴリズムは、通常、圧縮されたヘッダ内のＣＲＣを利用する。ＣＲＣにより、デコンプレッサは、伸張の試みの結果を検証し、検証が失敗した場合には、回復の仕組み（例えば、フィードバック、および、コンテキスト更新のための要求）を開始することが可能となる。
【００２６】
伸張が成功するか否かは、適切で一貫した（ｃｏｈｅｒｅｎｔ）コンテキスト状態（圧縮および伸張状態）と、圧縮された情報内にエラーが無いことに依存する。伸張中にデコンプレッサにより利用されるコンテキスト状態が、ヘッダを圧縮する際にコンプレッサにより利用されたコンテキスト状態と同じではない場合に、ヘッダの伸張は失敗する。ヘッダの伸張は、デコンプレッサに出力される圧縮されたデータに誤りがある場合（例えばデータが、エラーのある少なくとも１つのビットを有する）にも失敗する可能性がある。
【００２７】
解読の試みが失敗した場合、データパケットは通常デコンプレッサにより破棄される。従って、上位層はどの有用なデータも受信しない。失敗が繰り返されると、説明がつかないエラーが頻繁に起こることは予期されないので、デコンプレッサは典型的に、自身が伸張のために利用するコンテキスト状態に問題があると推定する。デコンプレッサは、自身のコンテキストが破損していると判定する場合に、例えば、破損している可能性があるコンテキスト状態を修復するために特定のアクションを要求するコンプレッサに対してフィードバックを送信することにより、エラー回復を開始する。
【００２８】
図６は、アップリンクで送信されるＩＰパケットのためのヘッダ伸張の結果に基づいて、ユーザ端末１２によるセキュアモードの開始を判定するための、例示的な方法２００を示している。本方法は、本明細書でデータパケットと総称される、シグナリングパケットとトラフィックパケットの双方のために利用されうる。ヘッダ圧縮が利用される場合には、ユーザ端末１２によるセキュリティ起動の検出は、圧縮されたデータ内で伝達されるＣＲＣを利用して伸張を成功裏に検証するということの１つ以上の失敗に基づいてもよい（ＩＥＴＦ ＲＦＣ３０９５、ＲＦＣ４９９５、ＲＦＣ４９９６参照）。先に述べたように、ヘッダ圧縮／伸張アルゴリズムは、典型的に、伸張の結果を検証するためにヘッダのＣＲＣを利用する。圧縮されたＩＰパケットが受信された場合（ブロック２０２）、受信されたパケットはメモリに格納される（ブロック２０４）。受信されたパケットは、その後、ユーザ端末１２がセキュリティを適用しているという推定に基づいて解読される（ブロック２０６）。解読に続いて、ヘッダが伸張され（ブロック２０８）、伸張の結果がヘッダのＣＲＣを用いて検査される（ブロック２１０）。伸張が成功した場合には、ユーザ端末１２がセキュリティを適用したと推定することが可能であり、解読されたパケットはセキュアデータパケット（ｓｅｃｕｒｅ ｄａｔａ ｐａｃｋｅｔ）として処理される（ブロック２１２）。伸張が失敗した場合には、ユーザ端末１２がセキュリティを適用しなかったと推定することが可能であり、受信されたパケットは非セキュアデータパケット（ｉｎｓｅｃｕｒｅ ｄａｔａ ｐａｃｋｅｔ）として処理される（ブロック２１４）。後に、セキュリティ起動が検出される前に最初に伸張に失敗したパケットについて、これらのパケットを検出処理中にバッファリングすることにより、伸張を再び試みてもよい。本実施形態では、完全性保護が利用されているか否かで違いはない。
【００２９】
他の形態のチェックサム、他の誤り検出符号が、暗号化の起動を検出するために同様に利用されうる。例えば、パケットが、暗号化されたチェックサムをパケットの一部として含む場合に、解読の後のチェックサム検証の結果が、ユーザ端末１２によるセキュアモード１２の開始を示すために利用されてうる。解読の後でチェックサムが有効である場合には、ユーザ端末１２がセキュリティを利用し始めたと推定することが可能である。反対に、解読の後にチェックサムが失敗する場合には、ユーザ端末１２はセキュリティを利用し始めていないと推定しうる。
【００３０】
図７は、誤り検出デコーディング（ｅｒｒｏｒ ｄｅｔｅｃｔｉｏｎ ｄｅｃｏｄｉｎｇ）の結果に基づいて、ユーザ端末１２によるセキュアモードの開始を判定するための例示的な方法２５０を示している。ＣＲＣまたは他の誤り検出符号が利用される場合に、ユーザ端末１２によるセキュリティ起動の検出は、データパケットを復号するということの１つ以上の失敗に基づいてもよい。符号化されたデータパケットが受信された場合（ブロック２５２）、受信されたデータパケットはメモリに格納される（ブロック２５４）。受信されたデータパケットは、その後、ユーザ端末１２がセキュリティを適用しているという推定に基づいて解読される（ブロック２５６）。解読に続いて、データパケットが復号される（ブロック２５８）。データパケットが成功裏に復号される場合に（ブロック２６０）、ユーザ端末１２はセキュリティを適用したと推定することが可能であり、解読されたデータパケットが処理される（ブロック２６２）。データパケットを成功裏に復号することに失敗した場合には、ユーザ端末１２はセキュリティを適用しなかったと推定することが可能であり、受信されたデータパケットは、非セキュアデータパケットとして処理される（ブロック２６４）。
【００３１】
図８は、ＩＰヘッダ圧縮が利用されている状況、または、受信されるデータパケットが暗号化より先に適用されるチェックサムまたは他の誤り検出符号を含む状況において、ユーザ端末１２によるセキュアモードの開始を検出するための、基地局２２における例示的なセキュリティプロセッサ２４を示している。セキュリティプロセッサ２４は、解読ユニット４２と、セキュリティ検出ユニット４６と、メモリ４４と、を含む。解読ユニット４２は、ＳＭＣがユーザ端末１２に送信された後に受信されたデータパケットを解読し、解読されたデータパケットを、セキュリティ検出ユニット４６に伝達する。セキュリティ検出ユニット４６は、ＣＲＣ検査または他の誤り検出処理の結果に基づいて、ユーザ端末１２のセキュリティの状態を検出する。メモリ４４は、セキュリティ処理が行なわれている間に、受信されたデータパケットを格納する。受信されるデータパケットが圧縮されたＩＰパケットを含む場合には、セキュリティ検出ユニット４６は、解読されたパケットのヘッダを伸張し、伸張されたヘッダのＣＲＣを検査する。受信されるデータパケットがＣＲＣまたは他の誤り検出符号を含む場合には、セキュリティ検出ユニット４６は、ＣＲＣの有効性を検査する。どちらの場合でも、ＣＲＣが有効である場合には、セキュリティ検出ユニット４６は、解読されたパケットを出力する。一方、ＣＲＣが無効である場合には、セキュリティ検出ユニット４６は、受信されたデータパケットを出力する。
【００３２】
先に記載された例示的な実施形態において、完全性保護、ヘッダ伸張、チェックサム、または、他の誤り検出符号の検出は、一旦ユーザ端末１２によるセキュアモードの開始が検出された場合には中止されてもよい。一旦セキュリティが検出されると、後続の送信されるパケットがセキュアに（ｓｅｃｕｒｅｌｙ）、例えば、暗号化および／または完全性保護が有効化されて送信されると推定することが可能である。他の実施形態において、完全性保護、ヘッダ伸張、チェックサム、または他の誤り検出符号の検出は、セキュアモードが開始した後にセキュリティ障害を検出するために続けられてもよい。
【００３３】
一旦セキュリティがユーザ端末１２により起動されると、セキュリティにおける障害が、アップリンクで送信されるデータパケットの完全性保護を検証するということの１つ以上の失敗に基づいて検出されうる。一旦完全性保護がユーザ端末１２により開始されると、基地局２２は、アップリンクで送信される全ての後続のデータパケットが保護されていると推定する。複数のデータパケットについて、完全性保護が検証されえない場合には、セキュリティ障害が起きていると推定することが可能である。
【００３４】
ＩＰヘッダのためのヘッダ圧縮が利用されている場合には、セキュリティ障害が、圧縮されたデータ内で伝達されるＣＲＣを利用して伸張を成功裏に検証するということの１つ以上の失敗に基づいて検出されうる（ＩＥＴＦ ＲＦＣ３０９５、４９９５、４９９６参照）。受信されるデータパケットは解読され、その後、ＩＰヘッダが伸張される。伸張は、ヘッダのＣＲＣを利用して検証される。１つ以上のデータパケットについて伸張が失敗する場合には、セキュリティ障害が起きていると推定することが可能である。本実施形態において、完全性保護が利用されているか否かで違いはない。本技術は、基地局２２によって、またはユーザ端末１２によって、セキュリティ障害を検出するために利用されうる。
【００３５】
データパケットが、データパケットの一部として暗号化された誤り検出符号またはチェックサムを含む場合に、アクティブ（ａｃｔｉｖｅ）から非アクティブ(ｉｎａｃｔｉｖｅ)へのセキュリティ状態の変化、または、セキュリティ障害が、チェックサムの検証の１つ以上の失敗に基づいて検出されうる。チェックサムの検証の失敗が繰り返されると、セキュリティ障害の兆候として捉えられる。本技術は、基地局２２によって、またはユーザ端末１２によって、セキュリティ障害を検出するために利用されうる。
【００３６】
図９は、セキュアモードがユーザ端末１２により有効化された後にセキュリティ障害を検出するための１つの例示的な方法３００を示している。本方法３００は、基地局２２がユーザ端末１２によるセキュアモードの開始を検出した後に開始する。従って、全てのデータパケッにセキュリティが適用されていると推定される。データパケットが受信される場合に（ブロック３０２）、基地局２２は、適用されたセキュリティが有効であることを確認するためにセキュリティ検査を行なう（ブロック３０４）。パケットがセキュリティ検査に落ちた場合には（ブロック３０６）、基地局は、カウンタを増分し（ブロック３１０）、所定の閾値とカウント値とを比較する（ブロック３１２）。カウント値が閾値と等しい場合には、セキュリティ障害が示される（ブロック３１４）。データパケットに適用されたセキュリティが有効である場合には、基地局２２は、ゼロまでカウント値をリセットする（ブロック３０８）。
【００３７】
本明細書で記載される方法は、基地局２２および／またはユーザ端末１２内のプロセッサにより実行されるソフトウェアにより実施されうる。ソフトウェアは、コンピュータ読取りが可能な媒体に格納された、プロセッサにより実行可能な命令を含む。例示的なコンピュータ読取り可能な媒体は、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュ（ＦＬＡＳＨ）メモリ、または他の公知のメモリ装置を含んでもよい。
【００３８】
本発明の効果は、アップリンクのシグナリングがセキュアモードの起動中に一時停止される必要がないため、遅延を低減するということである。暗号化／完全性保護の状態の余分な標識がパケットのヘッダ内で必要でないため、オーバーヘッドが低減される。他の効果は、記憶域の要件が下げられること、および、処理が低減されることを含む。本発明はまた、ヘッダ圧縮が利用される場合にセキュリティ障害を検出するという問題を解決する。
【００３９】
本発明は、当然のことながら、本発明の基本的な特徴から逸脱することなく、本明細書で特に記載されるものとは他のやり方でも実施されうる。本実施形態は、あらゆる点で例示的なものであって限定的なものではないと見なされ、添付の請求項の意味および均等の範囲内で生じる全ての変更が、本明細書に含まれるものとする。
【特許請求の範囲】
【請求項１】
前記送信端末の前記セキュリティ状態が未知である場合に、受信されたデータパケットを処理する方法であって、前記方法は、
前記ユーザ端末にセキュアモード命令を送信する工程と、
前記セキュアモード命令の前記送信に続いて、前記ユーザ端末からデータパケットを受信する工程と、
を含み、
前記方法は、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定することにより前記ユーザ端末のセキュリティモードを判定する工程と、
前記受信されたデータパケットが有効なセキュリティを有する場合には、前記受信されたデータパケットをセキュアパケットとして処理する工程と、
前記受信されたデータパケットが有効なセキュリティを欠いている場合には、前記受信されたデータパケットを非セキュアパケットとして処理する工程と、
を特徴とする、方法。
【請求項２】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項１に記載の方法。
【請求項３】
前記完全性保護が有効である場合に、前記受信されたデータパケットを解読する工程と、前記解読されたデータパケットを転送する工程と、をさらに含む、請求項２に記載の方法。
【請求項４】
前記解読されたデータがセキュアに送信されたという標識と共に、前記解読されたデータパケットを転送する工程をさらに含む、請求項３に記載の方法。
【請求項５】
前記データパケットが有効な完全性保護を欠いている場合に、前記受信されたデータパケットを破棄する工程をさらに含む、請求項２に記載の方法。
【請求項６】
前記受信されたデータパケットが有効な完全性保護を欠いている場合に、前記受信されたデータパケットは非セキュアであるという標識と共に、前記受信されたデータパケットを転送する工程をさらに含む、請求項２に記載の方法。
【請求項７】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、
前記受信されたデータパケットを解読する工程と、
有効なセキュリティが前記解読されたデータパケットに適用されているかどうかを判定する工程と、
を含む、請求項１に記載の方法。
【請求項８】
前記受信されたデータパケットを解読する前に、前記受信されたデータパケットの複写をメモリに格納する工程と、前記解読されたデータパケットが有効なセキュリティを欠いている場合に、メモリに格納された前記受信されたデータパケットを処理する工程と、をさらに含む、請求項７に記載の方法。
【請求項９】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項８に記載の方法。
【請求項１０】
前記解読されたデータパケットが有効な完全性保護を有する場合に、前記解読されたデータパケットを転送する工程をさらに含む、請求項９に記載の方法。
【請求項１１】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットのヘッダと推定されるものを伸張する工程と、前記伸張されたデータパケットが有効かどうかを判定する工程と、を含む、請求項８に記載の方法。
【請求項１２】
前記伸張されたデータパケットが有効である場合に、前記伸張されたデータパケットを転送する工程をさらに含む、請求項１１に記載の方法。
【請求項１３】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号する工程を含む、請求項８に記載の方法。
【請求項１４】
前記解読されたデータパケットが前記有効な誤り保護符号を有する場合に、前記復号されたデータパケットを転送する工程をさらに含む、請求項１３に記載の方法。
【請求項１５】
前記ユーザ端末にデータを送信し、前記ユーザ端末からデータを受信する送受信機を備え、
前記送受信機に接続されたプロセッサであって、
前記セキュアモード命令の前記送信に続いて、前記ユーザ端末からデータパケットを受信し、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定することにより、前記ユーザ端末のセキュリティモードを判定する、
ように構成された、前記プロセッサを特徴とする、基地局。
【請求項１６】
前記プロセッサは、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項１５に記載の基地局。
【請求項１７】
前記プロセッサはさらに、前記完全性保護が有効である場合に、前記受信されたデータパケットを解読し、前記解読されたデータパケットを転送するように構成される、請求項１６に記載の基地局。
【請求項１８】
前記プロセッサはさらに、前記解読されたデータがセキュアに受信されたという標識と共に、前記解読されたデータを転送するよう構成される、請求項１７に記載の基地局。
【請求項１９】
前記プロセッサはさらに、有効な完全性保護を欠いている受信されたデータパケットを破棄するように構成される、請求項１６に記載の基地局。
【請求項２０】
前記プロセッサはさらに、受信されたデータパケットが有効なセキュリティを欠いている場合に、前記受信されたデータパケットが非セキュアに送信されたという標識と共に、前記受信されたデータパケットを転送するよう構成される、請求項１６に記載の基地局。
【請求項２１】
前記プロセッサは、前記受信されたデータパケットを解読し、有効なセキュリティが前記解読されたデータパケットに適用されているかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項１５に記載の基地局。
【請求項２２】
前記プロセッサはさらに、前記受信されたデータパケットを解読する前に、前記受信されたデータパケットの複写をメモリに格納し、前記解読されたデータパケットが有効なセキュリティを欠いている場合に、メモリに格納された前記受信されたデータパケットを転送するように構成される、請求項２１に記載の基地局。
【請求項２３】
前記プロセッサは、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２４】
前記プロセッサはさらに、前記解読されたデータパケットが有効な完全性保護を有する場合に、前記解読されたデータパケットを転送するように構成される、請求項２３に記載の基地局。
【請求項２５】
前記プロセッサは、前記解読されたデータパケットのヘッダと推定されるものを伸張し、前記伸張されたデータパケットが有効であるかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２６】
前記プロセッサはさらに、前記伸張されたデータパケットが有効である場合に、前記伸張されたデータパケットを転送するように構成される、請求項２５に記載の基地局。
【請求項２７】
前記プロセッサは、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２８】
前記プロセッサはさらに、前記解読されたデータパケットが前記有効な誤り保護符号を有する場合に、前記復号されたデータパケットを転送するように構成される、請求項２７に記載の基地局。
【請求項２９】
セキュリティ障害を検出する方法であって、
セキュアモードが前記ユーザ端末により有効化された後に、ユーザ端末から１つ以上のデータパケットを受信する工程を含む、前記方法であって、
前記方法は、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程と、
所定数の連続するデータパケットついて有効なセキュリティの欠如に基づいて、セキュリティ障害が起きたこということを判定する工程と、
を特徴とする、方法。
【請求項３０】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項２９に記載の方法。
【請求項３１】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットを解読する工程と、前記解読されたデータパケットが有効なセキュリティを有するかどうかを判定する工程と、を含む、請求項２９に記載の方法。
【請求項３２】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項３１に記載の方法。
【請求項３３】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットのヘッダと推定されるものを伸張する工程と、前記伸張されたデータパケットが有効であるかを判定する工程と、を含む、請求項３１に記載の方法。
【請求項３４】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号する工程を含む、請求項３１に記載の方法。
【請求項３５】
ユーザ端末と通信するための送受信機を備え、
前記送受信機に接続されたプロセッサであって、
受信されたデータパケットが有効なセキュリティを有するかどうかを判定し、
所定数の連続するデータパケットについて有効なセキュリティの欠如に基づいて、セキュリティ障害の発生を判定する、
ように構成された、前記プロセッサを特徴とする、基地局。
【請求項３６】
前記プロセッサは、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３５に記載の基地局。
【請求項３７】
前記プロセッサは、前記受信されたデータパケットを解読し、前記解読されたデータパケットが有効なセキュリティを有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３５に記載の基地局。
【請求項３８】
前記プロセッサは、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【請求項３９】
前記プロセッサは、前記解読されたデータパケットのヘッダと推定されるものを伸張し、前記伸張されたデータパケットが有効かどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【請求項４０】
前記プロセッサは、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【請求項１】
前記送信端末の前記セキュリティ状態が未知である場合に、受信されたデータパケットを処理する方法であって、前記方法は、
前記ユーザ端末にセキュアモード命令を送信する工程と、
前記セキュアモード命令の前記送信に続いて、前記ユーザ端末からデータパケットを受信する工程と、
を含み、
前記方法は、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定することにより前記ユーザ端末のセキュリティモードを判定する工程と、
前記受信されたデータパケットが有効なセキュリティを有する場合には、前記受信されたデータパケットをセキュアパケットとして処理する工程と、
前記受信されたデータパケットが有効なセキュリティを欠いている場合には、前記受信されたデータパケットを非セキュアパケットとして処理する工程と、
を特徴とする、方法。
【請求項２】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項１に記載の方法。
【請求項３】
前記完全性保護が有効である場合に、前記受信されたデータパケットを解読する工程と、前記解読されたデータパケットを転送する工程と、をさらに含む、請求項２に記載の方法。
【請求項４】
前記解読されたデータがセキュアに送信されたという標識と共に、前記解読されたデータパケットを転送する工程をさらに含む、請求項３に記載の方法。
【請求項５】
前記データパケットが有効な完全性保護を欠いている場合に、前記受信されたデータパケットを破棄する工程をさらに含む、請求項２に記載の方法。
【請求項６】
前記受信されたデータパケットが有効な完全性保護を欠いている場合に、前記受信されたデータパケットは非セキュアであるという標識と共に、前記受信されたデータパケットを転送する工程をさらに含む、請求項２に記載の方法。
【請求項７】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、
前記受信されたデータパケットを解読する工程と、
有効なセキュリティが前記解読されたデータパケットに適用されているかどうかを判定する工程と、
を含む、請求項１に記載の方法。
【請求項８】
前記受信されたデータパケットを解読する前に、前記受信されたデータパケットの複写をメモリに格納する工程と、前記解読されたデータパケットが有効なセキュリティを欠いている場合に、メモリに格納された前記受信されたデータパケットを処理する工程と、をさらに含む、請求項７に記載の方法。
【請求項９】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項８に記載の方法。
【請求項１０】
前記解読されたデータパケットが有効な完全性保護を有する場合に、前記解読されたデータパケットを転送する工程をさらに含む、請求項９に記載の方法。
【請求項１１】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットのヘッダと推定されるものを伸張する工程と、前記伸張されたデータパケットが有効かどうかを判定する工程と、を含む、請求項８に記載の方法。
【請求項１２】
前記伸張されたデータパケットが有効である場合に、前記伸張されたデータパケットを転送する工程をさらに含む、請求項１１に記載の方法。
【請求項１３】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号する工程を含む、請求項８に記載の方法。
【請求項１４】
前記解読されたデータパケットが前記有効な誤り保護符号を有する場合に、前記復号されたデータパケットを転送する工程をさらに含む、請求項１３に記載の方法。
【請求項１５】
前記ユーザ端末にデータを送信し、前記ユーザ端末からデータを受信する送受信機を備え、
前記送受信機に接続されたプロセッサであって、
前記セキュアモード命令の前記送信に続いて、前記ユーザ端末からデータパケットを受信し、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定することにより、前記ユーザ端末のセキュリティモードを判定する、
ように構成された、前記プロセッサを特徴とする、基地局。
【請求項１６】
前記プロセッサは、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項１５に記載の基地局。
【請求項１７】
前記プロセッサはさらに、前記完全性保護が有効である場合に、前記受信されたデータパケットを解読し、前記解読されたデータパケットを転送するように構成される、請求項１６に記載の基地局。
【請求項１８】
前記プロセッサはさらに、前記解読されたデータがセキュアに受信されたという標識と共に、前記解読されたデータを転送するよう構成される、請求項１７に記載の基地局。
【請求項１９】
前記プロセッサはさらに、有効な完全性保護を欠いている受信されたデータパケットを破棄するように構成される、請求項１６に記載の基地局。
【請求項２０】
前記プロセッサはさらに、受信されたデータパケットが有効なセキュリティを欠いている場合に、前記受信されたデータパケットが非セキュアに送信されたという標識と共に、前記受信されたデータパケットを転送するよう構成される、請求項１６に記載の基地局。
【請求項２１】
前記プロセッサは、前記受信されたデータパケットを解読し、有効なセキュリティが前記解読されたデータパケットに適用されているかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項１５に記載の基地局。
【請求項２２】
前記プロセッサはさらに、前記受信されたデータパケットを解読する前に、前記受信されたデータパケットの複写をメモリに格納し、前記解読されたデータパケットが有効なセキュリティを欠いている場合に、メモリに格納された前記受信されたデータパケットを転送するように構成される、請求項２１に記載の基地局。
【請求項２３】
前記プロセッサは、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２４】
前記プロセッサはさらに、前記解読されたデータパケットが有効な完全性保護を有する場合に、前記解読されたデータパケットを転送するように構成される、請求項２３に記載の基地局。
【請求項２５】
前記プロセッサは、前記解読されたデータパケットのヘッダと推定されるものを伸張し、前記伸張されたデータパケットが有効であるかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２６】
前記プロセッサはさらに、前記伸張されたデータパケットが有効である場合に、前記伸張されたデータパケットを転送するように構成される、請求項２５に記載の基地局。
【請求項２７】
前記プロセッサは、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する、請求項２２に記載の基地局。
【請求項２８】
前記プロセッサはさらに、前記解読されたデータパケットが前記有効な誤り保護符号を有する場合に、前記復号されたデータパケットを転送するように構成される、請求項２７に記載の基地局。
【請求項２９】
セキュリティ障害を検出する方法であって、
セキュアモードが前記ユーザ端末により有効化された後に、ユーザ端末から１つ以上のデータパケットを受信する工程を含む、前記方法であって、
前記方法は、
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程と、
所定数の連続するデータパケットついて有効なセキュリティの欠如に基づいて、セキュリティ障害が起きたこということを判定する工程と、
を特徴とする、方法。
【請求項３０】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項２９に記載の方法。
【請求項３１】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記受信されたデータパケットを解読する工程と、前記解読されたデータパケットが有効なセキュリティを有するかどうかを判定する工程と、を含む、請求項２９に記載の方法。
【請求項３２】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定する工程を含む、請求項３１に記載の方法。
【請求項３３】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットのヘッダと推定されるものを伸張する工程と、前記伸張されたデータパケットが有効であるかを判定する工程と、を含む、請求項３１に記載の方法。
【請求項３４】
前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定する工程は、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号する工程を含む、請求項３１に記載の方法。
【請求項３５】
ユーザ端末と通信するための送受信機を備え、
前記送受信機に接続されたプロセッサであって、
受信されたデータパケットが有効なセキュリティを有するかどうかを判定し、
所定数の連続するデータパケットについて有効なセキュリティの欠如に基づいて、セキュリティ障害の発生を判定する、
ように構成された、前記プロセッサを特徴とする、基地局。
【請求項３６】
前記プロセッサは、前記受信されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３５に記載の基地局。
【請求項３７】
前記プロセッサは、前記受信されたデータパケットを解読し、前記解読されたデータパケットが有効なセキュリティを有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３５に記載の基地局。
【請求項３８】
前記プロセッサは、前記解読されたデータパケットが有効な完全性保護を有するかどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【請求項３９】
前記プロセッサは、前記解読されたデータパケットのヘッダと推定されるものを伸張し、前記伸張されたデータパケットが有効かどうかを判定することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【請求項４０】
前記プロセッサは、前記解読されたデータパケットが有効な誤り保護符号を有するかどうかを判定するために前記解読されたデータパケットを復号することにより、前記受信されたデータパケットが有効なセキュリティを有するかどうかを判定するように構成される、請求項３７に記載の基地局。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２０１０−５４１４４０（Ｐ２０１０−５４１４４０Ａ）
【公表日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願番号】特願２０１０−５２７３７４（Ｐ２０１０−５２７３７４）
【出願日】平成２０年７月３０日（２００８．７．３０）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５９９９３
【国際公開番号】ＷＯ２００９／０４３６２２
【国際公開日】平成２１年４月９日（２００９．４．９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願日】平成２０年７月３０日（２００８．７．３０）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５９９９３
【国際公開番号】ＷＯ２００９／０４３６２２
【国際公開日】平成２１年４月９日（２００９．４．９）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]