(57)【要約】チャレンジ／レスポンス方式の認証手続には、認証センターにより生成される予測レスポンス（ＸＲＥＳ）の隠蔽関数（ｆ）を使用した隠蔽処理と、隠蔽処理された予測レスポンス（ＸＲＥＳ’）を、実際にユーザー認証処理を実行する介在者に送信する処理とが含まれる。介在者はさらに、ユーザーからユーザーレスポンス（ＲＥＳ）を受信し、認証センターが使用したのと同一の隠蔽関数（ｆ）を使用して、隠蔽されたユーザーレスポンス（ＲＥＳ’）を生成する。介在者は、認証センターから受信した隠蔽処理された予測レスポンス（ＸＲＥＳ’）と、隠蔽されたユーザーレスポンス（ＲＥＳ’）とが対応するものであるかを検証することでユーザーを認証する。
2005530429.tif 000002
【特許請求の範囲】
【請求項１】
チャレンジ／レスポンス方式によるユーザー認証方法であって、
認証センターにおいて、秘密鍵と乱数チャレンジとからレンスポンス関数によって予測レスポンスを生成するステップと、
前記認証センターにおいて、前記予測レスポンスに応じて、隠蔽された予測レスポンスを生成するステップと、
前記隠蔽された予測レスポンスと前記乱数チャレンジとを介在者の装置に送信するステップと、
前記乱数チャレンジをユーザーの装置に送信するステップと、
前記ユーザーの装置において、前記秘密鍵と前記乱数チャレンジとに応じて前記レンスポンス関数によってユーザーレスポンスを生成するステップと、
前記ユーザーレスポンスを前記介在者の装置に送信するステップと、
前記介在者の装置において、前記認証センターが使用したものと同一の前記レスポンス関数によって、前記ユーザーレスポンスに応じた隠蔽されたユーザーレスポンスを生成するステップと、
前記介在者の装置において、前記隠蔽されたユーザーレスポンスと、前記隠蔽された予測レスポンスとが対応するかを検証するステップと
を含むユーザー認証方法。
【請求項２】
前記ユーザーが既に認証済みであることを前記介在者の装置が証明すべく、前記介在者の装置において、前記ユーザーの装置から受信した前記ユーザーレスポンスと、対応するユーザー識別情報とを少なくとも含む認証証明情報を管理するステップをさらに含む、請求項１に記載のユーザー認証方法。
【請求項３】
前記認証証明情報には、さらに、前記乱数チャレンジが含まれる、請求項２に記載のユーザー認証方法。
【請求項４】
前記隠蔽された予測レスポンスを生成するステップと、前記隠蔽されたユーザーレスポンスを生成するステップは、共通隠蔽乱数チャレンジに応じて実行されることで安全性を向上させる、請求項１に記載のユーザー認証方法。
【請求項５】
前記共通隠蔽乱数チャレンジは、受信された前記乱数チャレンジから導出される、請求項４に記載のユーザー認証方法。
【請求項６】
前記介在者の装置において、前記認証センターに前記認証証明情報を送信するステップと、
前記認証センターにおいて、受信した前記認証証明情報に基づき、前記ユーザーが前記介在者の装置において既に認証済みであるかどうかを検証するステップと
がさらに含まれる、請求項２に記載のユーザー認証方法。
【請求項７】
前記検証のステップには、受信した前記認証証明情報に含まれる前記ユーザーレスポンスを、前記認証センターから提供された対応する予測レスポンスと比較するステップが含まれる、請求項６に記載のユーザー認証方法。
【請求項８】
前記認証証明情報には、前記乱数チャレンジがさらに含まれ、
前記ユーザー認証方法には、前記認証センターにおいて、前記ユーザーの識別情報に基づいて前記秘密鍵を抽出するステップと、前記抽出された秘密鍵と前記乱数チャレンジとから前記予測レスポンスを再計算するステップとがさらに含まれる、請求項７に記載のユーザー認証方法。
【請求項９】
対応する前記認証証明情報を前記介在者に結び付けるために、前記認証センターにおいて所与のユーザー用に生成された認証データを前記介在者の装置へと関連付けるステップをさらに含む、請求項２に記載のユーザー認証方法。
【請求項１０】
前記認証センターにおいて、前記認証データが前記介在者を識別するための識別情報と相互に関連付けられ、前記認証センターにおいて、前記認証証明情報が前記介在者に関連付けられたものであるかを検証すべく、前記認証データと前記受信した認証証明情報とが比較される、請求項９に記載のユーザー認証方法。
【請求項１１】
少なくともひとつの前記乱数チャレンジと、前記予測レスポンスと、前記隠蔽された乱数チャレンジとが、前記隠蔽された予測レスポンスと前記隠蔽されたユーザーレスポンスとを生成するために使用されるべく、前記認証データに含まれている、請求項１０に記載のユーザー認証方法。
【請求項１２】
前記認証データには、乱数チャレンジデータを含み、前記乱数チャレンジデータの生成ステップは、前記介在者への関連付け処理に相当するステップである、請求項１０に記載のユーザー認証方法。
【請求項１３】
前記チャレンジデータは、前記介在者に対して固有の関数によって生成される、請求項１２に記載のユーザー認証方法。
【請求項１４】
前記チャレンジデータは、前記介在者を識別するための識別情報に基づいて生成される、請求項１２に記載のユーザー認証方法。
【請求項１５】
前記認証センターから前記介在者の装置へと送信されてきたデータを前記予測レスポンスによって暗号化するステップと、
前記暗号化されたデータを前記介在者の装置において前記受信したユーザーレスポンスによって復号化するステップと
をさらに含む、請求項１に記載のユーザー認証方法。
【請求項１６】
前記認証センターと前記介在者の装置とは、移動通信システムのネットワークノード内に配置されている、請求項１に記載のユーザー認証方法。
【請求項１７】
前記認証センターは、一般の認証センターまたはアイデンティティセンターとして動作しているブローカーである、請求項１に記載のユーザー認証方法。
【請求項１８】
チャレンジ／レスポンス方式によるユーザー認証システムであって、
認証センターにおいて、秘密鍵と乱数チャレンジとからレンスポンス関数によって予測レスポンスを生成する手段と、
前記認証センターにおいて、前記予測レスポンスに応じて、隠蔽された予測レスポンスを生成する手段と、
前記隠蔽された予測レスポンスと前記乱数チャレンジとを介在者の装置に送信する手段と、
前記乱数チャレンジをユーザーの装置に送信する手段と、
前記ユーザーの装置において、前記秘密鍵と前記乱数チャレンジとに応じて前記レンスポンス関数によってユーザーレスポンスを生成する手段と、
前記ユーザーレスポンスを前記介在者の装置に送信する手段と、
前記介在者の装置において、前記認証センターが使用したものと同一の前記レスポンス関数によって、前記ユーザーレスポンスに応じた隠蔽されたユーザーレスポンスを生成する手段と、
前記介在者の装置において、前記隠蔽されたユーザーレスポンスと、前記隠蔽された予測レスポンスとが対応するかを検証する手段と
を含む、ユーザー認証システム。
【請求項１９】
前記ユーザーが既に認証済みであることを前記介在者の装置が証明すべく、前記介在者の装置において、前記ユーザーの装置から受信した前記ユーザーレスポンスと、対応するユーザー識別情報とを少なくとも含む認証証明情報を管理する手段をさらに含む、請求項１８に記載のユーザー認証システム。
【請求項２０】
前記認証証明情報には、さらに、前記乱数チャレンジが含まれる、請求項１９に記載のユーザー認証システム。
【請求項２１】
前記隠蔽された予測レスポンスを生成する手段と、前記隠蔽されたユーザーレスポンスを生成する手段は、共通隠蔽乱数チャレンジに応じて動作することで安全性を向上させる、請求項１８に記載のユーザー認証システム。
【請求項２２】
前記介在者の装置において、前記認証センターに前記認証証明情報を送信する手段と、
前記認証センターにおいて、前記認証証明情報に基づき、前記介在者の装置において前記ユーザーが既に認証済みであるかどうかを検証する手段と
がさらに含まれる、請求項１９に記載のユーザー認証システム。
【請求項２３】
前記検証する手段には、受信した前記認証証明情報に含まれる前記ユーザーレスポンスを、前記認証センターから提供された対応する予測レスポンスと比較する手段が含まれる、請求項２２に記載のユーザー認証システム。
【請求項２４】
前記認証証明情報には、前記乱数チャレンジがさらに含まれ、
前記ユーザー認証システムには、前記認証センターにおいて、前記ユーザーの識別情報に基づいて前記秘密鍵を抽出する手段と、前記抽出された秘密鍵と前記乱数チャレンジとから前記予測レスポンスを再計算する手段とがさらに含まれる、請求項２３に記載のユーザー認証システム。
【請求項２５】
対応する証明情報を前記介在者に結び付けるために、前記認証センターにおいて所与のユーザー用に生成された認証データを前記介在者の装置へと関連付ける手段をさらに含む、請求項１９に記載のユーザー認証システム。
【請求項２６】
前記認証センターから前記介在者の装置へと送信されてきたデータを前記予測レスポンスによって暗号化する手段と、
前記暗号化されたデータを前記介在者の装置において前記受信したユーザーレスポンスによって復号化する手段と
をさらに含む、請求項１８に記載のユーザー認証システム。
【請求項２７】
介在者の装置において実行される関連付けられたユーザーの認証処理を補助するための認証センターであって、
前記ユーザーと共有している秘密鍵に少なくとも部分的に基づいて予測レスポンスを生成する手段と、
隠蔽関数によって前記予測スポンスを隠蔽することで隠蔽された予測レスポンスを生成する手段と、
前記隠蔽された予測レスポンスを前記介在者の装置に送信する手段と
を含む、ユーザー認証システム。
【請求項２８】
前記隠蔽する手段は、共通隠蔽乱数チャレンジに応じて動作することで安全性を向上させる、請求項２７に記載の認証センター。
【請求項２９】
前記認証センターから前記介在者の装置へと送信されるデータを前記予測レスポンスによって暗号化による保護を施す手段をさらに含む請求項２７に記載の認証センター。
【請求項３０】
所与のユーザー用に生成された認証データを、前記介在者を識別するための識別情報と相互に関連付ける手段と、
前記認証証明情報が前記介在者に関連付けられたものであるかを検証すべく、前記介在者の装置から受信した前記認証証明情報と、前記認証データとを比較する手段と、
をさらに含む、請求項２７に記載の認証センター。
【請求項３１】
前記認証センターは、一般の認証センターまたはアイデンティティセンターとして動作しているブローカーである、請求項２７に記載の認証センター。
【請求項３２】
サービスプロバイダによって管理され、認証センターに関連するユーザーを認証するネットワークノードであって、
隠蔽関数によって隠蔽された予測レスポンスを受信する手段と、
前記隠蔽された予測レスポンスに対応するユーザーレスポンスを受信する手段と、
前記隠蔽関数によって、隠蔽されたユーザーレスポンスを生成する手段と、
前記隠蔽されたユーザーレスポンスと、前記隠蔽された予測レスポンスとが対応するかを検証する手段と
を含む、ネットワークノード。
【請求項３３】
前記ユーザーが既に認証済みであることを前記ネットワークノードが証明できるようにすべく、前記ユーザーの装置から受信した前記ユーザーレスポンスと、対応するユーザー識別情報とを少なくとも含む認証証明情報を管理する手段をさらに含む、請求項３２に記載のネットワークノード。
【請求項３４】
前記認証証明情報には、さらに、前記ユーザーが既に認証済みであることの証明を補助するための乱数チャレンジが含まれる、請求項３３に記載のネットワークノード。
【請求項３５】
前記生成する手段は、隠蔽された乱数チャレンジに基づいて前記隠蔽されたユーザーレスポンスを生成するように動作し、前記隠蔽された乱数チャレンジは、前記認証センターにおいて前記予測レスポンスを生成するために使用される、請求項３２に記載のネットワークノード。
【請求項３６】
前記認証証明情報を前記ネットワークノードから前記認証センターへと送信する手段をさらに含む、請求項３２に記載のネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に通信システムにおける認証手続きに関し、特に、ユーザー及びユーザーが関連している認証センターの他に第三者が介在するチャレンジ／レスポンス方式のユーザー認証に関する。
【背景技術】
【０００２】
移動通信システム、ページングシステム、並びに無線データネットワーク及びワイヤラインデータネットワークを含めて、今日の多くの通信システムは、システムのセキュリティ及び堅牢性を向上させる目的のために認証及び暗号化の手続きを採用している。
【０００３】
例えば、移動通信システムでは、ユーザーはネットワークサービスに対するアクセスを獲得するためにネットワーク及びサービスプロバイダの少なくとも一方に向かって認証を実行する。認証はユーザーに課金するための基礎としても利用される。最新の通信システムの基本的なセキュリティプロトコルは、通常、チャレンジ／レスポンス方式の認証手続きを含む。このチャレンジ／レスポンス方式の認証手続きは、秘密鍵暗号方式をベースとする場合が最も多い。チャレンジ／レスポンス方式の認証は当業界において良く知られている。例えば、ＧＳＭ（Global System  for  Mobile Communications、移動通信用グローバルシステム）ネットワーク用及びＵＭＴＳ（Universal Mobile Telecommunications System、ユニバーサルモバイルテレコミュニケーションシステム）ネットワーク用など、基本的なチャレンジ／レスポンス方式の認証について、いくつかの規格が存在している。
【特許文献１】米国特許第５，５９６，６４１号
【特許文献２】米国特許第５，５３７，４７４号
【特許文献３】米国特許第５，６６８，８７５号
【特許文献４】米国特許第５，９９１，４０７号
【特許文献５】米国特許第６，３８９，５３６Ｂ１号
【発明の開示】
【発明が解決しようとする課題】
【０００４】
図１に示されるように、最新の通信システムにおける典型的なシナリオには、ユーザー及びユーザーが関連している認証センターのみならず、別個のネットワークオペレータまたは他のサービスプロバイダなどの介在者がさらに含まれる。通常、認証センターはホームオペレータに関連している、ホームオペレータは、ユーザーとの間に、例えば、加入または前納アカウントを通して信頼関係を築いている。この信頼関係は、通常、例えば、共有秘密鍵を介した暗号関係として証明される。これは、対称暗号方式と呼ばれる。ホームオペレータ認証センター、特に、ホームネットワークオペレータは介在者との間にサービス契約を有していてもよい。このサービス契約は、通常、同様の暗号関係により証明される。しかし、ユーザーと介在者との関係は、通常、介在者により提供されるサービスが要求されるか、またはその他の理由で開始されるときに確立される誘発信頼関係としてみなされる。
【０００５】
図２は、ユーザー、関連するホームオペレータ認証センター及び介在者を含む典型的な従来のチャレンジ／レスポンス方式の認証手続きの概略図である。例えば、ＧＳＭネットワーク及びＵＭＴＳネットワークなどの通信システムで使用される従来のＡＫＡ（Authentication and Key Agreement、認証及び鍵契約）プロセスは、秘密鍵に基づくチャレンジ／レスポンス方式の手続きを含む。Ｋｉと表される秘密鍵は、通常、ユーザーのオペレータへの加入と関連する加入鍵またはそこから派生する鍵である。例えば、介在者は、ユーザーがローミングしているネットワークを管理するネットワークノードまたはユーザーに関連するサービスを提供する他の種類のサービスプロバイダであってもよい。
【０００６】
介在者において所定のユーザーの認証を行うために、通常、ユーザーは介在者へユーザーＩＤを送信することを要求され、介在者は認証データを求めて、このＩＤをホームオペレータ認証センターへ送信する。ユーザーの認証を援助するために、ホーム認証センターはこの特定のユーザーと関連する秘密鍵Ｋｉに基づく予測レスポンスＸＲＥＳと、所定の関数ｇに対する入力であるランダム（乱数）チャレンジＲＡＮＤとを生成する。通常、認証センターは機密性鍵、保全性鍵及び認証トークンなどの追加情報をさらに生成してもよい。ＧＳＭのＡＫＡにおいては、保全性鍵または認証トークンは使用されないが、基本的なチャレンジ／レスポンス方式の手続きは同じである。チャレンジＲＡＮＤ及び予測レスポンスＸＲＥＳは、追加情報とともに、ユーザーを認証することを望む介在者へ送信される。介在者はチャレンジＲＡＮＤと、おそらくは認証トークンとをユーザーへ送信する。ユーザーは、好ましくは加入者アイデンティティモジュール（ＳＩＭまたはＵＳＩＭ）を利用して、共有秘密鍵Ｋｉ（ＳＩＭまたはＵＳＩＭに機密に格納されている）及び認証センターにより使用されるのと同じ関数ｇに対する入力である受信されたチャレンジＲＡＮＤに基づいて、レスポンスＲＥＳを生成する。そこで、ユーザーは介在者へレスポンスＲＥＳを返送する。ユーザーを認証するために、介在者は、単に、ユーザーから受信されたレスポンスＲＥＳが認証センターから受信された予測レスポンスＸＲＥＳと等しいことを検証すればよい。
【０００７】
認証センターと介在者との間の認証パラメータの送信は暗号により保護されている。例えば、ＵＭＴＳでは、セキュリティプロトコルＭＡＰＳｅｃを使用できるであろう。ＭＡＰＳｅｃプロトコルは３ＧＰＰで規格化されているが、まだ有効には採用されていない。
【０００８】
通常、認証データを事前に配信できることや、後に認証センターと改めてコンタクトせずに認証手続きを実行できることが要求される。
【０００９】
上記の基本的なチャレンジ／レスポンス方式の認証手続きを脅かす主要な問題が２つある。第１の脅威は、別個のネットワークオペレータまたは他のサービスプロバイダなどの不正な介在者が認証センターから認証データを要求し、後に、ユーザーがネットワークにローミングしていたまたはその他の方法により提供されるサービスを使用していたという偽った主張をし、最終的にはそれらのサービスに対する支払いを要求することである。今日のシステムは何らかの裏付け証拠を出すという機能をサポートしていないため、認証センターはそのような証拠を求めることができない。
【００１０】
第２の脅威は、認証パラメータが認証センターから介在者へ送信されるときに傍受されるか、または介在者のノードのハッキングによって読み取られることである。その後、盗まれた認証パラメータを使用して、それらのパラメータに関連付けられているユーザーとして認証を受けられるという詐欺行為が起こりうる。そのような攻撃は、認証データを盗むことができ、かつ、真正なユーザーが使用する前にそれらのデータを使用することができるかどうかに依存している。例えば、ユーザーがネットワーク間でローミングしているが、ユーザーがそのネットワークを離れようとしている場合、後で当該ネットワークに戻ってきた際に、認証パラメータを再使用できるようにするためには、予め当該ネットワークに認証パラメータを格納しておくことがあるが、この場合にはそのような攻撃が実行されうる。
【００１１】
＜関連技術＞
米国特許第５，５９６，６４１号には、移動通信システムにおけるローミング中のモバイルユニットの認証方法が記載されている。この方法は２つのステップ、すなわち、予備認証ステップと、主認証ステップとを含む。予備ステップでは、ホームネットワークからローミング対象ネットワークへと、複数ペアの第１のチャレンジ及び予測レスポンスが送信される。第２のチャレンジと第１のチャレンジを結合することにより形成される第３のチャレンジがローミング中のモバイルユニットへ送信され、モバイルユニットはレスポンスを計算し、ローミング対象ネットワークへ送信する。次に、主認証ステップで、モバイルユニットは第２のチャレンジと計算されたレスポンスのペアを使用して認証される。
【００１２】
通信システムにおいてローミング中の加入者を認証する方法及び装置が米国特許第５，５３７，４７４号及び米国特許第５，６６８，８７５号に記載されている。加入者とそれに関連するホームシステムは、ホームシステム認証プロトコルのチャレンジとレスポンスを使用し、一方で、ローミング対象システムは、対応するローカル認証プロトコルを使用する。加入者はローミング対象システムから受信されるあらゆるチャレンジをホームシステムプロトコルに適合するフォーマットに変換する。生成されたユーザーレスポンスは、ローミング対象システムへ送信される前にローカル認証プロトコルに変換される。次に、チャレンジとユーザーレスポンスはローミング対象システムからホームシステムへ送信され、ユーザーレスポンス及び予測レスポンスに基づいて加入者を認証する前に同様の変換が実行される。
【００１３】
米国特許第５，９９１，４０７号は、モバイルユニットにおいてチャレンジからの符号付きレスポンス及び認証鍵を計算するためにＡ３アルゴリズムを使用するＧＳＭ方式の移動通信システムにおける認証手続きを説明している。Ａ３アルゴリズムとして、ＣＡＶＥ（Cellular Authentication  and  Voice Encryption、セルラー認証及び音声暗号方式）アルゴリズムが採用される。ＣＡＶＥアルゴリズムの入力機能とチャレンジ及び認証鍵入力機能との間、並びにＣＡＶＥアルゴリズムの出力機能と符号付きレスポンス出力機能との間にパラメータ適応機能が提供される。
【００１４】
米国特許第６，３８９，５３６Ｂ１号は、コンテンツプロバイダからユーザー装置に配信されるソフトウェアを使用するための資格を検証する装置を開示している。獲得したソフトウェアを実行可能にするために、まず、ユーザー装置は検証装置に含まれる３つの機器によって認証される。コンテンツプロバイダに配置された証拠支援情報発行機器は、例えば、ソフトウェア実行要求に対してユーザー装置の証明機器へと送信されるチケットの形態をとる証拠支援情報を発行する。証明機器は、ソフトウェアに埋め込まれている検証機器から獲得されるチャレンジとともに証拠支援情報に基づいてレスポンス情報を生成する。このレスポンス情報は検証機器へ送信され、認証目的で使用される。正しく認証されれば、検証機器はユーザー装置にソフトウェアを実行させる。
【００１５】
上記の特許は、図２に関連して先に論じた従来の技術のチャレンジ／レスポンス方式の手続きと同じまたはそれに類似する問題を抱えている。
【００１６】
本発明は従来の構成に関するこれらの欠点及びその他の欠点を克服する。
【００１７】
本発明の一般的な目的は、改善されたチャレンジ／レスポンス方式の認証手続きを提供することである。特に、ユーザーが実際に認証されたという有効な証拠を介在者が提示できるような認証手続きを提供することが望ましい。これは、不正なサービスプロバイダのサービスをユーザーが受け取り、それを利用したと偽った主張を行うのを有効に防止し、また、ユーザーからの認証の否認を防止することに寄与しよう。さらに、傍受攻撃を防止ししたり無効にしたりすることも重要であろう。
【００１８】
本発明の目的は、秘密鍵（対称暗号方式）チャレンジ／レスポンス方式の手続きに基づいて介在者においてユーザーを認証する改善された方法及びシステムを提供することである。
【００１９】
本発明の別の目的は、介在者における関連するユーザーの認証を補助する改善された認証センターを提供することである。
【００２０】
本発明のさらに別の目的は、認証センターと関連するユーザーを認証するための改善されたサービスプロバイダネットワークノードを提供することである。
【００２１】
これらの目的及びその他の目的は添付の特許請求の範囲により定義されるように本発明により達成される。
【課題を解決するための手段】
【００２２】
基本的な秘密鍵（対称暗号方式）チャレンジ／レスポンス方式の認証手続きを改善するための基本的な概念は、認証センターにより生成される予測レスポンスを隠蔽（マスク）関数によって隠蔽し、予測レスポンス自体ではなく、隠蔽された（マスク処理された）予測レスポンスを介在者へ送信し、介在者において実際の認証を実行することである。介在者は対応するユーザーからユーザーレスポンスを受信し、同様に認証センターと同じ隠蔽関数を使用して隠蔽ユーザーレスポンスを生成する。そこで、ユーザーを認証するために、介在者は隠蔽ユーザーレスポンスが認証センターから受信された隠蔽予測レスポンスに対応することを検証する。
【００２３】
上記のチャレンジ／レスポンス方式の手続きにより、介在者はユーザーが適正に認証されたことを証明することが可能になり、それと同時に、予測レスポンスの隠蔽によって、傍受攻撃は防止ないし無効化される。
【００２４】
提案される解決方法の背後にある概念は、認証パラメータを傍受する無許可のユーザーまたは不正な介在者などの攻撃者が事前にレスポンスを知っていてはならないということである。最初にレスポンス及び予測レスポンスを知るのは、それぞれ、正当なユーザーと認証センターだけである。従って、この概念は、傍受攻撃者並びに介在者の双方が予測レスポンスに対するアクセスを獲得することを防止するが、それでも、介在者が後にユーザーから送信されてくるユーザーレスポンスに基づいてユーザーを認証することは可能にするというものである。先に説明した通り、これは、予測レスポンスを介在者へ送信する前に認証センターで予測レスポンスを隠蔽し、認証を可能にするために介在者において対応する隠蔽ユーザーレスポンスを生成することにより実現できるであろう。この手続きによって、介在者はその時点でユーザーから受信されたレスポンス及び対応するユーザー識別情報を、好ましくはレスポンスを生成するために使用された関連するチャレンジとともに使用して、この特定のユーザーが実際に認証されていることを証明できる。従って、介在者、例えば、サービスプロバイダは、支払いが転送される前に、レスポンス値またはレスポンス／チャレンジペアを提供するためにチャレンジされてもよい。これにより、ユーザーは、実際にネットワークに存在していたことや他のサービスを利用していることを証明できるであろう。
【００２５】
前述のように、認証センターと介在者との間で認証パラメータを傍受する攻撃者が正当なユーザーであると見せかけるためにそれらのパラメータを直接使用できないことは明らかであろう。
【００２６】
ユーザー認証の証拠はオフライン手続きまたはオンライン手続きで管理されることが可能である。前者の場合、少なくともユーザーから受信されるユーザーレスポンスを含み、好ましくは対応するチャレンジをさらに含む認証証拠情報が記憶場所に格納され、後に、介在者はそれを検索し、ユーザー認証の証拠として提示することができる。後者の場合には、認証証拠情報は介在者から認証センターへほぼ直接的に送信されるので、オンライン証明が可能である。提示された認証証拠情報に基づいて、認証センターは、介在者が実際に所定のユーザーを認証したか否かを検証するために、関連する計算や比較処理などを実行できるであろう。
【００２７】
隠蔽機能は、認証センター及び介在者のみに知られている専用機能であってもよいし、あるいは公に知られた機能であっても良いが、一般には、一方向性およびハッシュ特性の少なくとも一方を有する。セキュリティを向上させるために、特に事前計算攻撃を打破するために、隠蔽予測レスポンスの計算及び隠蔽ユーザーレスポンスの計算は、ＳＡＬＴと名づけられた共通隠蔽ランダムチャレンジに基づいて実行される。隠蔽ランダムチャレンジＳＡＬＴは完全に無作為であり、ユーザーレスポンス／予測レスポンスを生成するために使用される、ＲＡＮＤと名づけられたランダムチャレンジとは無関係であるため、ＲＡＮＤとともに介在者へ送信されることが可能であろう。
【００２８】
しかし、関連するエンティティの間において追加の信号送信を回避するために、隠蔽ランダムチャレンジＳＡＬＴはランダムチャレンジＲＡＮＤから取り出されることが可能である。この場合、ランダムチャレンジＲＡＮＤは通常通り介在者へ送信され、ユーザーへと送り出される。そこで、隠蔽ランダムチャレンジＳＡＬＴは介在者において送信されてきたＲＡＮＤから計算され、その後、隠蔽ユーザーレスポンスを生成するために使用される。この点に関して、有効な方式は単純にランダムチャレンジＲＡＮＤを隠蔽ランダムチャレンジＳＡＬＴとして再利用する方法である。
【００２９】
既存のインフラストラクチャに関連してスムースな移行を可能にするために、配信された予測レスポンスを計算するときに隠蔽関数が採用されたか否かを介在者に通知することが推奨される。従って、認証パラメータを配信するためのプロトコルはそのような表示を含められるよう拡張されるのが好ましい。
【００３０】
付加的な脅威は、不正な介在者が別の関係者へ証拠情報を送信し、その関係者が（おそらくはより高額なサービスに関連して）支払いを要求するために認証センターにその証拠情報を提示してしまうおそれがあることである。さらに、攻撃者が、ハッキングされたサービスプロバイダノードから証拠情報を読み取り、その情報を使用してサービスの支払いを要求することも起こりうるだろう。この特定の問題は、対応する証拠情報を介在者に結び付けるために、所定のユーザーに関して認証センターにより生成される認証データをユーザー認証に関与する介在者に関連付けることにより解決できるであろう。認証センターにおいて、認証データは介在者のＩＤと相関がとられ、その後、認証センターにおいて、証拠情報が介在者と関連していることを検証するために、認証データが受信された証拠情報（またはその表現）と比較されるのが好ましい。
【００３１】
本発明は、ＧＳＭネットワークまたはＵＭＴＳネットワークなどの移動通信システムで特に有用であると思われるが、それらにのみ限定されるわけではない。
【００３２】
本発明は実にすぐれた解決方法であり、次のような利点を提供する：
−  ユーザが実際に認証されたことをサービスプロバイダなどの介在者が証明することを可能にする；
−  不正なサービスプロバイダが偽って、ユーザーがそのプロバイダのサービスを受け取ったと主張するのを防止する；
−  ユーザによるユーザー認証の否認を防止する；
−  隠蔽関数により、真正の認証データを盗むことが実質的に不可能になるため、傍受攻撃を有効に無効化する；
−  証拠情報を所定の介在者に結び付けることが可能である；及び
−  既存の装置設備からの容易な移行を可能にする。
【発明を実施するための最良の形態】
【００３３】
本発明により提供される他の利点は、以下に示す本発明の実施例に関する説明を読むことにより理解されるであろう。
本発明の実施例の詳細な説明
図面を通して、対応する要素または類似の要素に対しては、同じ参照符号が使用されている。
【００３４】
本発明の基本的かつ直感的な理解を得るために、まず、図３を参照して一般的なチャレンジ／レスポンス方式の認証手続きを説明する。ここで、関係者には、ユーザー（装置）と、ユーザーが関連している認証センター（装置）と、ユーザーを認証することを望む介在者（装置）とが含まれるものと仮定する。この例においては、さらに、認証処理は、認証センターが予測レスポンスを生成し、その後、ユーザーが対応するレスポンスを生成するというチャレンジ／レスポンス方式の手続きに基づいているものと仮定する。基本概念は、生成された予測レスポンスを隠蔽する隠蔽関数を導入することである（Ｓ１）。次に、隠蔽予測レスポンスは介在者の装置へ送信される（Ｓ２）。ユーザーの装置は従来のように対応するユーザーレスポンスを生成し、送信する（Ｓ３）。従って、介在者は認証センターの装置から隠蔽予測レスポンスを受信するとともに、ユーザーの装置から通常のユーザーレスポンスを受信する。そこで、介在者の装置は同じ隠蔽関数によって隠蔽ユーザーレスポンスを生成し（Ｓ４）、最後に、ユーザー認証を検証するために隠蔽予測レスポンスと隠蔽ユーザーレスポンスとを比較する（Ｓ５）。このように、介在者の装置は、最初にレスポンス／予測レスポンスを知るのは正当なユーザー／認証センターのみであることに留意しつつ、ユーザーが認証されていることを証明することが可能となる。不正なサービスプロバイダまたは無許可のユーザーが、前もってレスポンスを知ることは不可能である。従って、予測レスポンスを介在者へ送信する前に認証センターで予測レスポンスを隠蔽することにより、介在者並びに傍受攻撃者が隠蔽されていない予測レスポンスに対するアクセスを獲得することは防止される。しかし、それでも、対応する隠蔽ユーザーレスポンスの生成によって、介在者がユーザーを認証することは可能である。すなわち、介在者はユーザーから受信されるレスポンスを、好ましくはレスポンスを生成するために使用された関連するチャレンジとともに使用して、この特定のユーザーが実際に認証されていたことを証明することができる。従って、例えば、サービスプロバイダなどの介在者は、支払い指示が転送される前に、ユーザーが実際にネットワークに存在していたことや他のサービスを利用したことを証明するために、レスポンス値または好ましくはレスポンス／チャレンジのペアを提供するためにチャレンジされることになろう。
【００３５】
認証センターと介在者は、見掛け上、認証センターと介在者との間で隠蔽関数が交換されたことを示唆する関係を有する。これは、それら２つの関係者について共通していなければならない同様の情報や機能に関しても当てはまる。
【００３６】
「認証センター」という用語は総称用語であり、最新の移動通信システムで一般に見られる認証センター（ＡｕＣ）ノードに限定されないことを理解すべきである。本発明による認証センターは、実際には、ここで説明する方式によりユーザーを認証することを管理するか、またはそれに関与するどのようなセンターであってもよい。例えば、認証センターがおそらくは認証センターと同一の場所に配置されるか、または異なる場所に配置されるＡＡＡ（Authorization, Authentication and Accounting、許可、認証及び課金）サーバを含むホームオペレータ認証センターであってもよいことは言うまでもない。しかし、複数の異なるネットワークオペレータまたはサービスプロバイダに対して一般認証センター、またはアイデンティティセンターとして機能するブローカーであってもよい。
【００３７】
介在者は、ユーザーがローミングしている「在圏」ネットワークを管理するネットワークノード、ウェブサービスプロバイダ、コンテンツプロバイダ、さらに、実際にはホームオペレータ自体のＭＳＣ／ＶＬＲ（Mobile Switching Center/Visited Location Register、移動交換局／在圏ロケーションレジスタ）など、本発明に従ってユーザーが認証されるどのような介在者やその装置であってもよい。
【００３８】
ユーザーがローミングしている在圏ネットワークの場合、在圏ネットワークのオペレータは、基本ネットワークアクセスサービスに加えて、ウェブサービスまたはデジタルコンテンツなどの他のサービスをさらに提供することがある。しかし、ウェブサービスプロバイダ及びコンテンツプロバイダの少なくとも一方が在圏ネットワークオペレータとは異なる場合には、状況は幾分複雑になる。言うまでもなく、在圏ネットワークのオペレータは、その他のサービスプロバイダに対して何らかの関係を有していてもよい。他のプロバイダは、所定のユーザーが既にオペレータにより認証されていたことの確認をオペレータに求めるであろう。しかし、その代わりに、ネットワークアクセスプロバイダ、ウェブサービスプロバイダ及びコンテンツプロバイダなどの独立した介在者ごとに、本発明により提案されるチャレンジ／レスポンス方式の認証手続きが繰り返される。後者の場合、各サービスプロバイダはその時点で独自の認証証拠情報を獲得する。
【００３９】
ホームオペレータ自身のＭＳＣ／ＶＬＲが、ネットワークに対するアクセスを望むユーザーの認証に際して、ホームオペレータ認証センターまたは一般アイデンティティセンターなどの認証センターと対話通信する介在者として動作してもよい。ＭＳＣ／ＶＬＲ及び認証センターが同じホームオペレータにより管理されている場合、一般に、ＭＳＣ／ＶＬＲが認証証拠情報を格納している必要はない。隠蔽の主な目的は、むしろ、認証センターとＭＳＣ／ＶＬＲノードとの間で送信される予測レスポンスを傍受攻撃から保護することである。これに対し、認証センターがユーザーのホームオペレータに対して認証センターブローカーとして機能する一般アイデンティティセンターである場合には、ホームオペレータのＭＳＣ／ＶＬＲがユーザー認証証拠情報を格納することは非常に重要であり、後に、その情報を使用して、所定のユーザーがＭＳＣ／ＶＬＲで実際に認証されていたことを証明することができる。また、介在者がホームオペレータにより管理されているかまたは外部関係者により管理されているかに関わらず、同様の規格化された認証手続きを具備することも好都合であろう。
【００４０】
基本ネットワークアクセスサービス以外のサービスの場合、要求される信号の送信は、一般にプロトコルスタックのアプリケーションレベルで起こる。この場合、認証（及び鍵契約）手続きを開始するのは、通常、ユーザー端末のアプリケーションである。ＡＫＡを開始するために、端末においてアプリケーションをイネーブルするためのメカニズムに関する一般的な情報は、H. Haverinenの「EAP SIM Authentication」（Internet Draft of the Internet Engineering Task Force）に記載されている。
【００４１】
前述のように、介在者はウェブサービスプロバイダ、または音声、映像、画像、電子ブック及びソフトウェアなどのデジタルメディアデータをユーザーに配信するコンテンツプロバイダであってもよい。コンテンツプロバイダの場合、本発明に係る認証は、実際にユーザーへとメディアがダウンロードまたはストリーミングされる前に実行されるのが好ましい。
【００４２】
実際には、ネットワークアクセスサービス、ウェブサービス、コンテンツサービスまたは支払いブローカーサービスなどのサービスを提供するどのような関係者でも、本発明の説明で使用されるような介在者として機能できるであろう。
【００４３】
本発明をさらに良く理解するために、次に、関係者間における認証情報の送信を示す図４、並びに図５Ａ〜図５Ｅのフローチャートを参照して、本発明による認証手続きの他の例を説明する。
【００４４】
一般に、全体的な認証は、ユーザーが介在者へとユーザーＩＤを送信することにより開始され、次に、介在者は、認証データを求めるための要求として関連する認証センターへとユーザーＩＤを送信する。受信されたユーザーＩＤに基づいて、認証センターは、特定のユーザーと関連する対称／共有秘密鍵Ｋｉを識別する。例えば、ユーザーがホームオペレータのサービスに加入している場合、鍵Ｋｉは加入鍵であってもよいし、あるいは前納アカウントと関連する暗号鍵であってもよい。認証センターは、ランダムチャレンジＲＡＮＤを生成し（Ｓ１１）、所定の関数ｇへの入力として秘密鍵Ｋｉ及びランダムチャレンジＲＡＮＤに基づいて予測レスポンスＸＲＥＳを計算する（Ｓ１２）。次に、認証センターは、例えば、全く独立したランダム値としてまたはランダムチャレンジＲＡＮＤに基づいて隠蔽ランダムチャレンジＳＡＬＴを生成するのが好ましい（Ｓ１３）。この隠蔽ランダムチャレンジＳＡＬＴ及び計算された予測レスポンスＸＲＥＳを隠蔽関数ｆへの入力として使用して、隠蔽予測レスポンスＸＲＥＳ’を計算する（Ｓ１４）。その後、隠蔽予測レスポンスＸＲＥＳ’とランダムチャレンジＲＡＮＤは、おそらくはオプションである隠蔽ランダムＳＡＬＴとともに（Ｓ２２）介在者へ送信される（Ｓ２１）。
【００４５】
認証センターの完全に外部にあるかまたは認証センターから独立している介在者の場合、通常、ユーザーが関連している認証センターのアイデンティティなど、特にユーザーのホームオペレータのアイデンティティを判定するために使用されうる情報を、介在者がユーザーから受信することも要求される。これにより、介在者は、認証センターが特定のホームオペレータの認証センターであるか、一般認証センターまたはアイデンティティセンターとして機能するブローカーであるかに留意しつつ、認証データを求めるための要求を関連する認証センターやホームオペレータへ送信することが可能となる。後者の場合、ホームオペレータのアイデンティティは、後に図１１を参照して説明するように、通常、関連する秘密鍵情報を発見することを要求される。
【００４６】
ランダムチャレンジＲＡＮＤを受信した後、介在者はランダムチャレンジＲＡＮＤをユーザーへ送信する（Ｓ３１）。次に、ユーザーは、予測レスポンスＸＲＥＳを計算するために使用された認証センターと同じ関数ｇに対する入力として、ランダムチャレンジＲＡＮＤ及び共有秘密鍵Ｋｉのユーザーのコピーを用いて、ユーザーレスポンスＲＥＳを計算する（Ｓ３２）。獲得されたユーザーレスポンスＲＥＳは後の認証で使用するために介在者へ送信される（Ｓ３３）。
【００４７】
オプションである隠蔽ランダムチャレンジＳＡＬＴが認証センターから証明された上で送信されなかった場合、介在者は、認証の検証に先立って、好ましくはランダムチャレンジＲＡＮＤに基づいて、隠蔽ランダムチャレンジＳＡＬＴを取り出してもよい（Ｓ４１）。隠蔽関数ｆに対する入力としてのユーザーレスポンスＲＥＳ及びオプションである、受信されたまたは取り出された隠蔽ランダムチャレンジＳＡＬＴによって、隠蔽ユーザーレスポンスＲＥＳ’が介在者により計算される（Ｓ４２）。その後、介在者は計算された隠蔽ユーザーレスポンスＲＥＳ’を認証センターから獲得された隠蔽予測レスポンスＸＲＥＳ’と比較する（Ｓ５１）。隠蔽ユーザーレスポンスＲＥＳ’が隠蔽予測レスポンスＸＲＥＳ’に対応するならば、介在者はユーザーを認証している（Ｓ５２）。
【００４８】
以上、簡単に述べたように、隠蔽ランダムチャレンジＳＡＬＴはオプションであり、認証手続きから省略されてもよい。そのような場合には、隠蔽予測レスポンスＸＲＥＳ’及び隠蔽ユーザーレスポンスＲＥＳ’をそれぞれ計算するために、隠蔽関数ｆにランダムチャレンジＳＡＬＴは入力されない。しかし、セキュリティを向上させ、特に事前計算攻撃を打破するためには、隠蔽関数入力として隠蔽ランダムチャレンジＳＡＬＴが含まれているのが好ましい。従って、隠蔽ランダムチャレンジＳＡＬＴは認証センターにおいて全く無作為の値として計算され、その後、隠蔽予測レスポンスＸＲＥＳ’及びランダムチャレンジＲＡＮＤとともに送信されることが可能であろう。しかし、認証センターと介在者との間において追加の信号の送信を回避するためには、その代わりに、隠蔽ランダムチャレンジＳＡＬＴをランダムチャレンジＲＡＮＤから取り出すことも可能であろう。この場合、認証センターはランダムチャレンジＲＡＮＤの何らかの関数ｈにより、隠蔽ランダムチャレンジＳＡＬＴを生成するのが好ましい。従って、介在者へ隠蔽ランダムチャレンジＳＡＬＴが送信される必要はなく、その場合に、介在者は、同じ関数ｈを使用してランダムチャレンジＲＡＮＤから隠蔽ランダムチャレンジＳＡＬＴを生成できるであろう。使用可能な隠蔽ランダムチャレンジＳＡＬＴの一例は、単純にランダムチャレンジＲＡＮＤを隠蔽ランダムチャレンジＳＡＬＴとして再利用するものである。従って、ｈは恒等関数として表現される。
【００４９】
関数ｈは公開関数であっても良く、あるいは介在者と認証センターの適法な関係者（ホームオペレータなど）との間の業務契約と関連し、それとともに配信される関数であってもよいが、その様々な面については以下に詳細に説明する。
【００５０】
一方で隠蔽予測レスポンスを生成するために認証センターにより使用され、他方では隠蔽ユーザーレスポンスを計算するために介在者により使用される隠蔽関数ｆは、一方向関数及びハッシュ関数の少なくとも一方であってもよい。隠蔽関数は、共通の１つの値にハッシュする２つの明確に異なる入力を発見することを実行不可能にする一方向の機能性及び特性を有する暗号ハッシュ関数であるのが好ましい。
【００５１】
一方向関数及びハッシュ関数の詳細に関しては、A. J. Menezes、P. C. van Oorschot及びS. C. Vanstoneの「Handbook of Applied Cryptography」（CRC Press、第１章、１〜４８ページ）が詳しい。
【００５２】
隠蔽関数ｆは、公開関数であってもよいし、あるいは認証センター及び介在者により知られている専用関数であってもよい。後者の場合、専用隠蔽関数は、認証センターに係る所定のホームオペレータなどの適法関係者と、サービスプロバイダなどの介在者との間の業務契約と関連付けられうる。例えば、ホームオペレータなど、認証センターの適法関係者がいくつかの異なるサービスプロバイダとの間にそのような業務契約を締結している場合、サービスプロバイダごとに対応する専用関数がホームオペレータにより使用されるであろう。すなわち、各々のオペレータ‐プロバイダ間契約が専用隠蔽関数として証明される。しかし、その代わりに、全てのサービスプロバイダに対して全く同一の公開隠蔽関数が使用されることも可能であろう。
【００５３】
隠蔽関数がわかっている場合、隠蔽関数に認証センターから受信された隠蔽予測レスポンスを評価させるためのユーザーレスポンスを検索することは、少なくとも理論上は可能である。サービスプロバイダなどの不正な介在者がそのような攻撃を利用して、ユーザー認証が実行されていないにもかかわらず、ユーザーが認証されたと「証明」するかもしれない。これは、認証パラメータの特性を慎重に選択することにより単純に解決される。例えば、ｎ＞ｍとし、ユーザーレスポンスをｎビットとし、隠蔽予測レスポンスをｍビットに選択すると、現在隠蔽予測レスポンスと関連している１つを発見するまでに試験されることになるユーザーレスポンスの平均数は、約２ｍ−１である。加えて、これが正しいユーザーレスポンスである確率は、わずか２−（ｎ−ｍ）である。ＵＭＴＳ移動通信システムの場合、規格化パラメータサイズにより、ｎは９６、ｍは８０になるため、２７９通りの異なるユーザーレスポンスを試験するというタスクは実行不可能である。正しいユーザーレスポンスの確率はわずか２−１６である。
【００５４】
また、例えば、介在者から獲得される実際のサービスに応じて、ユーザーレスポンス／予測レスポンスを異なる方式で隠蔽することも可能である。すなわち、あるサービスに対しては、ある１つの種類の隠蔽、例えば、第１の隠蔽関数を使用し、他のサービスに対しては別の隠蔽である第２の隠蔽関数を採用するのである。そのような場合、特定のユーザー認証においてどの隠蔽関数が使用されるべきかを通知するために、認証センターと介在者との間の送信に何らかの形態の情報が含まれているのが好ましい。
【００５５】
既存のインフラストラクチャに関連してスムースな移行を可能にするために、介在者は、配信される予測レスポンスを計算するときに隠蔽関数が採用されたか否かを通知されるのが好ましい。従って、認証パラメータを配信するためのプロトコルはそのような表示情報によって拡張されるのが好ましい。同様に、先に論じたように、異なる隠蔽関数の間の選択がある場合には、どの隠蔽関数を使用すべきかの指示がプロトコルに含まれていてもよい。
【００５６】
介在者は、ユーザーから受信されたレスポンス及びユーザーＩＤなどの何らかのユーザー識別情報を、好ましくはレスポンスを生成するために使用されたランダムチャレンジとともに証拠情報として使用して、この特定のユーザーが実際に認証されていたことを証明できる。従って、介在者は受信されたユーザーレスポンス、ユーザーＩＤ及びランダムチャレンジを、必要に応じて、ユーザー認証の証拠として後の検索に備えて適切な記憶場所に格納しておくのが好都合である。ユーザー認証の証明のためのこのオフライン手続きにおいては、ユーザーレスポンス及びユーザーＩＤは、好ましくは対応するランダムチャレンジとともに、介在者がアクセス可能な他の何らかの記憶場所に格納されることが可能であろう。
【００５７】
所定のユーザーに関する認証の証拠を提供するために、認証センターまたは他の何らかの関係者によりチャレンジされたとき、介在者は、ユーザーレスポンスＲＥＳ、対応するランダムチャレンジＲＡＮＤ及びユーザーＩＤなどの証拠情報を認証センターへ送信することができる。次に、認証センターは、所定のユーザーと関連する秘密鍵Ｋｉを検索し、受信されたＲＡＮＤ及び秘密鍵Ｋｉに基づいて予測レスポンス値ＸＲＥＳを計算し、最後に、介在者でユーザーが実際に認証されていたか否かを検証するために受信されたＲＥＳ値を計算されたＸＲＥＳ値と比較することが好ましい。ＲＥＳ値がＸＲＥＳ値と一致すれば、証拠情報は有効と考えられる。
【００５８】
【数１】
2005530429.tif 000003
【００５９】
あるいは、介在者は単純に所定のユーザーのＲＥＳ値及びユーザーＩＤを介在者へ送信する。この場合、ＲＥＳとＸＲＥＳの比較を実行できるように、ユーザーに関して、認証センターは、通常、ＸＲＥＳ値を格納するかまたは対応するＸＲＥＳ値を計算できるようにＲＡＮＤ値を格納することを必要とする。
【００６０】
オンライン手続きが望まれる場合には、ユーザーレスポンス及びユーザーＩＤは、好ましくは対応するランダムチャレンジとともに、介在者から認証センターへ事実上直接的に送信されるので、認証の証明が可能になる。
【００６１】
＜認証証拠情報と特定の介在者の関連付け＞
付加的な脅威は、不正な介在者が証拠情報を別の関係者へ送信することが可能であり、その関係者が証拠情報を認証センターに提示して支払いを要求する（例えば、他の関係者のサービスが介在者のサービスより高価であると仮定して）ことである。さらに、例えば、ユーザーＩＤ、ユーザーレスポンスＲＥＳ及び対応するランダムチャレンジＲＡＮＤを含めて、攻撃者が介在者のハッキングされたノードから証拠情報を読み取ることも可能であろう。そこで、この攻撃者は、受信された証拠情報を認証センターに提示して、ユーザーが何らかのサービスをアクセスしたと偽って主張し、支払いを要求することが可能であろう。必要であるかまたは重要であると考えられる場合には、所定のユーザーに関して認証センターで生成される認証データをユーザー認証に関与する介在者と関連付けることで、対応する証拠情報が介在者に結び付けられるため、この特定の問題は解決できるであろう。
【００６２】
本発明に係る認証手続き全体における初期の工程では、介在者は認証データを求めるための要求とともにユーザーＩＤを認証センターへ送信する。一般に、ユーザーＩＤには認証データを要求する介在者を識別するための情報が付随している。後に認証証拠情報を特定の介在者に結び付けることができるようにするために、認証センターは、ユーザーＩＤと、認証データが送信される介在者に対する参照を含むＲＡＮＤ、ＳＡＬＴやＸＲＥＳなどの生成された認証データを格納していてもよい。認証センターで、所定のユーザーに関して生成された認証データの少なくとも一部を、認証データを要求した介在者のＩＤと相関させることにより、他の関係者により対応する証拠情報が使用されることは不可能になる。
【００６３】
認証センターの前に、証拠情報を提供するために介在者がチャレンジされると、介在者は、ＩＤＳＰと表されるとともに、サービスプロバイダアイデンティティとも呼ばれる独自のアイデンティティも、認証センターに送信する。証拠情報を受信すると、認証センターは、介在者から獲得されたユーザーレスポンスＲＥＳを格納されている予測レスポンスＸＲＥＳ、または再び生成された予測レスポンスＸＲＥＳと比較して、ユーザーが認証されていたことを検証する。しかし、ここで、認証センターは、受信された証拠情報がその証拠情報を提示している介在者と本当に関連しているか否かを検証するために、証拠情報を、格納されている認証データと比較してもよい。認証データは、当該認証データを送信してきた介在者への参照を有している。
【００６４】
証拠情報を介在者に結び付けるもう１つの可能な解決方法は、認証センターにおける隠蔽ランダムチャレンジＳＡＬＴの生成を介在者ＩＤＳＰと関連付ける方法である。認証センターはＲＡＮＤからＳＡＬＴを生成するために使用される１組の異なる関数ｈを有していてもよい。各介在者に独自の関数ｈＳＰを割り当てるのが好ましい。この関数ｈＳＰは、認証センターにより、ＲＡＮＤから隠蔽ランダムチャレンジＳＡＬＴを生成するために使用され、生成されたＳＡＬＴは介在者へ送信される。ＳＡＬＴ値が認証センターで対応するＩＤＳＰへの参照とともに格納されていない限り、関数ｈＳＰは認証センターにより秘密に保たれるのが好ましい。ＲＥＳ、ＲＡＮＤ及びユーザーＩＤを含めて証拠情報を認証センターに提示するとき、介在者は関連するＩＤＳＰ及び以前に受信された隠蔽ランダムチャレンジＳＡＬＴを送信することも要求される。受信されたＩＤＳＰに基づいて、認証センターは関連する関数ｈＳＰを識別し、受信されたランダムチャレンジＲＡＮＤに基づいて予測隠蔽ランダムチャレンジＸＳＡＬＴを計算する。証拠情報が正しい介在者から発したことを検証するために、ＸＳＡＬＴは介在者から受信されたＳＡＬＴと比較される。それらの一致は証拠情報の出所が正しいことの証明である。一意性を持つ介在者特定関数を秘密にしておくことにより、別の関係者が証拠情報を使用することが不可能になる。
【００６５】
【数２】
2005530429.tif 000004
【００６６】
隠蔽ランダムチャレンジＳＡＬＴを生成するときに介在者ごとに独自の関数ｈＳＰを使用するのではなく、いくつかのまたは全ての介在者に対して認証センターにより共通の関数ｈが使用されることも可能であろう。しかし、関数ｈは入力としてランダムチャレンジＲＡＮＤと介在者ＩＤＳＰの双方を有する。従って、認証センターは、認証手続きの初期の過程でユーザーＩＤとともに受信されたＩＤＳＰにも基づいてＳＡＬＴを計算する。先に説明したのと同様に、介在者はＩＤＳＰと受信されたＳＡＬＴのコピーを証拠情報に含めることを要求される。受信したならば、認証センターは受信されたＩＤＳＰ及びＲＡＮＤと、関数ｈに基づいて予測隠蔽ランダムチャレンジＸＳＡＬＴを計算する。そこで、ＸＳＡＬＴは介在者から送信されたＳＡＬＴと比較され、その一致は証拠情報の出所が正しいことの証明である。共通関数ｈを秘密に保つことにより、別の関係者がＲＥＳ及びＲＡＮＤのみに基づいて有効な証拠情報を提示することは不可能になる。
【００６７】
【数３】
2005530429.tif 000005
【００６８】
さらに別の実施例では、ランダムチャレンジＲＡＮＤの生成は、介在者ＩＤＳＰを基礎とすることも可能であろう。ユーザー認証の要求を受けて、認証センターはランダム事前チャレンジＲＡＮＤ’を生成し、関数ｒ：
ＲＡＮＤ＝ｒ（ＩＤＳＰ，ＲＡＮＤ’）
に対する入力であるＲＡＮＤ’及び介在者ＩＤＳＰによって、チャレンジＲＡＮＤを計算する。
【００６９】
このランダムチャレンジＲＡＮＤはその後、予測レスポンスＲＥＳを生成するために使用され、隠蔽予測レスポンスＸＲＥＳ’とともに介在者へ送信される。認証センターは、ＲＡＮＤ’を関連するユーザーＩＤ及び介在者ＩＤＳＰに対する参照とともに格納する。ユーザーが実際に介在者により認証されていたことを検証するとき、認証センターは関数ｒに対する入力であるＩＤＳＰ及び格納されているＲＡＮＤ’によって予測ランダムチャレンジＸＲＡＮＤを計算する。次に、ＸＲＡＮＤは介在者から受信されたＲＡＮＤと比較され、それらが一致すれば、認証センターは証拠情報が正しい介在者から送信されたことを立証できる。また、ＲＥＳ及びＸＲＥＳによるユーザー認証の検証は先に説明したように実行される。この解決方法は、特にユーザー認証手続きで隠蔽ランダムチャレンジＳＡＬＴが採用されない場合に適用可能である。
【００７０】
【数４】
2005530429.tif 000006
【００７１】
以上論じた関数ｈ、ｈＳＰ及びｒは、共通の値にハッシュする２つの明確に異なる入力を見出すことを実行不可能にする特性を伴う一方向機能性を有するのが好ましい。
【００７２】
一般に、ＸＲＥＳとＲＥＳの比較はユーザーＩＤを有する所定のユーザーが認証されたか否かを検証し、ＸＳＡＬＴとＳＡＬＴ／ＸＲＡＮＤとＲＡＮＤの比較はユーザーがアイデンティＩＤＳＰを有する介在者により認証されていたか否かを検証する。
【００７３】
＜オプションの暗号について＞
図４には示されていないが、認証センターで機密性鍵、保全性鍵及び認証トークンなどの追加情報を生成し、介在者へ送信することができる。そのような場合、この追加情報、例えば、機密性鍵及び保全性鍵が使用前にレスポンスにより変形される可能性がある。例えば、認証センターは計算された予測レスポンスに基づいて、暗号方式により機密性鍵及び保全性鍵を保護することができる。その後、鍵は暗号化された形で介在者へ送信されるため、盗聴や解読のために、配信される鍵を傍受することは無駄になる。そこで、介在者は、ユーザーから受信されたレスポンスを使用して暗号化情報から機密性鍵及び保全性鍵を取り出す。
【００７４】
さらに、ＡＫＡ派生鍵以外の情報が認証センターと介在者との間で送信される前に予測レスポンスによって暗号方式で保護されてもよい。
【００７５】
一般に、隠蔽予測レスポンス、ランダムチャレンジ及び隠蔽ランダムチャレンジを含めて、認証センターと介在者との間の認証パラメータの送信は暗号方式により保護されてもよい。例えば、ＵＭＴＳアプリケーションでは、パラメータ保護のためにＭＡＰＳｅｃプロトコルが使用される。
【００７６】
＜実装に関して＞
以上説明した過程、アクション及びアルゴリズムはソフトウェア／ハードウェアまたはその何らかの組み合わせで実現されればよい。ハードウェアで実現する場合、ＡＳＩＣ（Application Specific Integrated Circuit、特定用途向け集積回路）技術や他の何らかの従来の回路技術を使用することができる。セキュリティ上の理由から、不正防止可能な特殊のハードウェアが好ましいであろうが、多くの場合、適正に保護されたソフトウェアでの実現がより好都合である。
【００７７】
図６は、本発明の好ましい一実施例による認証センターの一例を概略的に示す。認証センター５０は、一般に、ユーザーを認証するために採用される認証データを生成する認証アルゴリズムユニット１０と、証拠検証ユニット２０と、データベース３０とを含む。認証アルゴリズムユニット１０は、チャレンジデータ発生器１２と、ＸＲＥＳ発生器１４と、隠蔽関数ユニット１６とを具備する。名称が示す通り、チャレンジデータ発生器１２は、ランダムチャレンジと、オプションである隠蔽ランダムチャレンジを含めて、チャレンジデータを生成する。ＸＲＥＳ発生器１４はチャレンジデータ及びデータベース３０からの秘密ユーザー関連鍵に基づいて予測レスポンスＸＲＥＳを生成する。隠蔽関数ユニット１６は、チャレンジデータ発生器１２及びＸＲＥＳ発生器１４からのオプションである隠蔽ランダムチャレンジ及び予測レスポンスにそれぞれ基づいて隠蔽予測レスポンスを生成する。介在者から受信される証拠情報を検証するために、証拠検証ユニット２０も認証センター５０に実装されるのが好ましい。この証拠検証ユニット２０は、証拠検証のためにデータベース３０に格納されているデータを利用するのが好ましい。データベース３０は、ユーザーＩＤ及び関連する秘密鍵Ｋｉの情報に加えて、オプションとして認証データを含んでいても良く且つ／またはそのようなデータは介在者識別情報ＩＤＳＰに対する参照とともに格納されていてもよい。認証センター５０は、介在者及びユーザーと通信するための送信器／受信器４０を関連回路とともにさらに具備する。
【００７８】
図７は、本発明の好ましい一実施例による介在者の一例を概略的に示す。介在者２００は、ユーザーを認証するための認証アルゴリズムユニット２１０を含む。認証アルゴリズムユニット２１０は隠蔽レスポンス発生器２１２及び比較ユニット２１４を具備する。隠蔽レスポンス発生器２１２は、隠蔽関数及びユーザーから受信されるユーザーレスポンスに基づいて隠蔽ユーザーレスポンスを生成する。比較ユニット２１４は、発生器２１２からの隠蔽ユーザーレスポンスを認証センターから送信される隠蔽予測レスポンスと比較するために採用される。ユーザーレスポンス及びユーザーＩＤと、好ましくはさらに認証センターから受信されるかまたは認証アルゴリズムユニット２１０により生成されるチャレンジデータとを含めて、証拠情報を格納したり送信したりするために、記憶・送信ユニット２７０が介在者２００に配置されているのが好ましい。この記憶・送信ユニット２７０からの証拠情報は、例えば、要求に応じて、または介在者２００により証拠情報が獲得された時点で直ちに、認証センターへ送信される。介在者２００は、認証センター及びユーザーとの通信のために、送信器／受信器２４０を関連回路とともにさらに具備する。
【００７９】
＜応用例  ―  移動通信システム＞
本発明は、一般にどのような秘密鍵チャレンジ／レスポンス方式のシステムにも適用可能であるが、本発明は移動通信システムにおいて特に有用であることがわかっている。次に、特定の応用例及び実施例として、すなわち、移動通信システムに関連して本発明を説明するが、このシステムで、介在者は、モバイルユニット（ユーザー）がローミングしているモバイル／セルラーネットワークを管理するネットワークノードである。この特定の例においては、認証センターはホームオペレータ認証センター（ＡｕＣ）である。モバイルユニットは、例えば、加入または前納アカウントを介して、ホームネットワークシステムを管理するホームオペレータと関連付けられている。このユーザーとオペレータの関係は、通常、ＧＳＭモバイルユニットで使用されるＳＩＭカード、またはＵＭＴＳモバイルユニットで使用されるＵＭＴＳ用ＳＩＭカード（ＵＳＩＭ）により保証されている。しかし、より一般的な移動通信アプリケーションでは、介在者は、在圏ネットワークノード、ホームオペレータ自体のＭＳＣ／ＶＬＲノード、ウェブサービスプロバイダ、メディアコンテンツプロバイダ及び支払いブローカーを含めたどのような種類のサービスプロバイダであってもよいことを理解すべきである。
【００８０】
図８は、在圏ネットワークシステムへローミングしている関連モバイルユニットを含めた、ホームネットワークシステムとして示される認証システムの一実施例の概略ブロック図である。ホームシステム１００は、一般に１つ以上のネットワークノード１６０を具備し、その１つが図示されている。例えば、ネットワークノード１６０は、ＭＳＣ（Mobile Switching Center、移動交換局）または基地局（ＢＳ）であってもよい。図８の例では、ネットワークノード１６０は、ＨＬＲ（Home Location Register、ホームロケーションレジスタ）１３０を具備する。このＨＬＲ１３０は、ホームシステム１００に関連するユーザーの情報、例えば、ユーザーＩＤ及び対応する秘密加入鍵Ｋｉを含む。ＨＬＲ１３０は、オプションとして認証データを含むことが可能であり、且つ／またはそのようなデータは介在者ＩＤに対する参照とともに格納されていることが可能であろう。さらに、ネットワークノード１６０は、ユーザーの認証を管理し、それに関与する認証センター（ＡｕＣ）１５０を具備する。ＡｕＣ１５０は、認証アルゴリズムを実現する認証アルゴリズムユニット１０と、在圏システム２００からの証拠情報を検証するための証拠検証ユニット２０とを具備する。実行されると、認証アルゴリズムは、本発明の関連認証データを生成する。ホームネットワークノード１６０は、生成されるランダムチャレンジ、隠蔽予測レスポンス及びおそらくは隠蔽ランダムチャレンジをローミング先システムまたは在圏システム２００のネットワークノード２６０へ送信するために、送信器／受信器１４０を関連回路とともにさらに具備している。
【００８１】
在圏システム２００も同様に１以上のネットワークノード２６０を具備し、その１つが図８に示されている。在圏システム２００のネットワークノード２６０は、ＶＬＲ（Visited Location Register、在圏ロケーションレジスタ）２３０及び認証アルゴリズム２１０を具備するのが好ましい。さらに、ホームシステム１００から認証パラメータを受信し、受信されるランダムチャレンジをローミング中であるモバイルユニット４００へ送り出すとともに、証拠情報をホームシステムの認証センター１５０へ送信するために、送信器／受信器２４０が配置されている。
【００８２】
在圏ネットワークノード２６０は、モバイルユニット４００から受信されるユーザーレスポンス及びおそらくはホームシステム１００からのランダムチャレンジを格納するための記憶及び／または送信ユニット２７０をさらに具備するのが好ましい。しかし、それに代わる構成または補足する構成として、ユーザーレスポンスの格納は、ユーザー認証証明手続きにおいてその情報を後に検索するために、在圏システム２００のオペレータによりアクセス可能である別の記憶場所で行われることも可能であろう。このユニット２６０に格納されるデータは、認証センターからの要求に応じて認証センターへ送信される。
【００８３】
図８の特定の例においては、ユーザーは在圏ネットワークシステムまたはローミング対象ネットワークシステム２００のネットワークノード２６０により認証されるべきローミング中のモバイルユニット４００である。先に述べた通り、モバイルユニット４００は秘密鍵Ｋｉ４１５を具備するＳＩＭ（ＵＳＩＭ）４８０及び認証アルゴリズムユニット４１０を具備するのが好ましい。ユニット４１０で実現されるこの認証アルゴリズムは、例えば、ＧＳＭ及びＵＭＴＳにおけるＡＫＡプロトコルのＡ３アルゴリズムであってもよい。実行されると、認証アルゴリズムは、好ましくは在圏システム２００から送出されるランダムチャレンジ及びＳＩＭ４８０の秘密鍵Ｋｉ４１５に基づいて、ユーザーレスポンスを計算する。そこで、モバイルユニット４００は、ユーザーレスポンスを在圏システムネットワークノード２６０へ送信し、そこで最終的な認証が実行される。
【００８４】
図９は、本発明によるＡｕＣ１５０を含むホームネットワークシステム３００の別の実施例を示す。この実施例では、ホームシステム３００は、各々が対応する送信器／受信器３４０、３４５を具備する２つのネットワークノード３６０、３６５を有するものとして示されている。第１のノード３６０はＨＬＲ１３０を具備するが、第２のノード３６５には、認証アルゴリズムユニット１０及び証拠検証手段２０を有するＡｕＣ１５０が配置されている。第１のノード３６０は、ＢＳとして第２のノード３６５を有するＭＳＣであってもよい。あるいは、第１のノード３６０と第２のノード３６５の双方がＭＳＣまたはＢＳであってもよいし、または第１のノード３６０はＭＳＣとして第２のノード３６５を有するＢＳであってもよい。
【００８５】
図１０は、いくつかのネットワークノードの間でホーム認証アルゴリズムが分散されるような、本発明に係るホームネットワークシステムのさらに別の実施例の概略ブロック図である。図１０には、２つのネットワークノード５６０、５６５が明確に示されている。この実施例では、ＡｕＣ５５０は、２つのノード５６０、５６５の間で分散配置されている。すなわち、認証アルゴリズム全体のうちの一部５１０が第１のノード５６０で実現され、認証アルゴリズムの残りの部分５１５が第２のノード５６５または他のいくつかのノードで実現される。ＡｕＣ５５０の証拠検証ユニット２０は、ＨＬＲ１３０を内蔵しているネットワークノード５６０で実現されるのが好ましく、これにより、ＨＬＲ１３０に格納されているデータへのアクセスが可能になる。
【００８６】
在圏システムも同様に複数の異なるネットワークノードで分割されたＶＬＲ及び認証アルゴリズム及び／または複数の異なるノードの間で分散された認証アルゴリズムを有していてもよい。
【００８７】
移動通信システムにおける一般的な認証手続きの詳細については、J. Arkko、H. Haverinenの「EAP AKA Authentication」（Internet Draft of the Internet Engineering Task Force）及び先に挙げたH. HaverinenによるInternet Draft「EAP SIM Authentication」が詳しい。
【００８８】
＜例  ―  認証センターとして機能するブローカーについて＞
先に指示したように、認証センターは必ずしも特定のホームオペレータの認証センターではなく、図１１に概略的に示されるように、複数の異なるネットワークオペレータに対して一般の認証センターまたはアイデンティティセンターとして機能するブローカー７５０であってもよい。この場合、認証センターまたはアイデンティティセンターであるブローカー７５０は、一般に異なるネットワークオペレータからのユーザー識別情報及び秘密鍵情報７３０、７３５を委託されているので、ブローカー７５０は様々な介在者２００‐１〜２００‐Ｎにおいてユーザーの認証を補助することが可能になる。
【００８９】
一般に、ユーザー４００が所定の介在者２００の前で自身を認証することを望む場合、ユーザーは介在者へユーザーＩＤを送信するとともに、要求に応じてホームオペレータのアイデンティティＩＤＯＰを表す何らかの情報を送信する。そこで、介在者は、認証データを求める要求の中でユーザーＩＤ及びＩＤＳＰを介在者ＩＤＳＰを識別する情報とともに認証センターブローカー７５０へ送信する。認証センターブローカー７５０は、受信されたＩＤＯＰ及びユーザーＩＤに基づいて、ユーザー４００と関連する秘密鍵Ｋｉを識別し、次に本発明の認証アルゴリズムに従って（隠蔽）認証データを生成する。残る認証（及び証拠検証）手続きは本発明の先の説明とほぼ同じである。
【００９０】
典型的なシナリオにおいては、まず、ユーザー４００は、そのホームオペレータの前で認証することを必要とし、従って、ユーザーＩＤをホームオペレータのＭＳＣ／ＶＬＲノード（この場合には介在者として機能している）へ送信し、介在者は、ユーザーＩＤと介在者のＩＤを、認証データを求める要求に含めて認証センターブローカー７５０へ送信する。認証センターブローカー７５０は、認証のために要求される認証データを生成する。ユーザーが最終的に認証されたならば、ＭＳＣ／ＶＬＲは、必要に応じて、ユーザー認証の証拠として、後の検索に備えて対応する証拠情報を格納してもよい。その後、ユーザーが、例えば、ウェブサービスプロバイダにより提供される何らかのウェブサービスをアクセスすることを望んだ場合、ユーザーは、ユーザーＩＤと、ホームオペレータのアイデンティティＩＤＯＰを表す情報をウェブサービスプロバイダへ送信することを要求される。ウェブサービスプロバイダがホームオペレータとは無関係である（別の介在者）場合でも、ホームオペレータと関連性を有しており、ホームオペレータにユーザーが認証されているか否かの情報を照会できるであろう。あるいは、ウェブサービスプロバイダは認証データを求める独自の要求の中でＩＤＯＰ及びユーザーＩＤをブローカー７５０へ送信し、後に独自の証拠情報を格納する。それに対応して、コンテンツプロバイダ、在圏ネットワークノードまたは他の何らかの介在者に対しても同様の手続きが実行されればよい。
【００９１】
一般認証センターとして機能するブローカーは、ユーザーと介在者との間のエンドツーエンド暗号化の鍵を取り出すために採用されることも可能であろう。そのような場合、取り出される鍵はネットワークオペレータに対して秘密に保持されてもよい。そこで、ユーザーは、例えば、介在者により提供されるサービスへの加入または利用するサービスの支払いに際してエンドツーエンド暗号鍵を獲得できるであろう。
【００９２】
以上説明した実施例は単に例として示されているにすぎず、本発明がそれらにのみ限定されないことを理解すべきである。例えば、認証センターにおける証拠評価ステップは絶対的に必要とは限らないことを理解すべきである。認証証拠情報を提供するために介在者がチャレンジされているかもしないという事実だけでも、ユーザー認証の不正な主張を防止することは十分だからである。ここで開示され且つ特許請求の範囲に記載された基本原理に沿った他の変形例、変更例及び改善例はすべて本発明の技術的範囲に属する。
【図面の簡単な説明】
【００９３】
本発明は、その別の目的及び利点とともに、添付の図面に関連する上述の詳細な説明を参照することにより良く理解されるであろう。
【図１】図１は、認証手続きの関係者及びそれらの相互関係を示す通信システムの概要を示す図である。
【図２】図２は、関係者間における情報の送信を示す典型的な従来のチャレンジ／レスポンス方式の認証手続きの概略図である。
【図３】図３は、本発明による一般的なチャレンジ／レスポンス方式の認証手続きのフローチャートである。
【図４】図４は、関係者間における情報の送信を示す、本発明によるチャレンジ／レスポンス方式に係る認証手続きの一例を示す概略図である。
【図５Ａ】図５Ａは、図３の予測レスポンス生成及び隠蔽過程をさらに詳細に示すフローチャートである。
【図５Ｂ】図５Ｂは、図３の隠蔽予測レスポンス送信過程をさらに詳細に示すフローチャートである。
【図５Ｃ】図５Ｃは、図３のユーザーレスポンス生成送信過程をさらに詳細に示すフローチャートである。
【図５Ｄ】図５Ｄは、図３の隠蔽ユーザーレスポンス生成過程をさらに詳細に示すフローチャートである。
【図５Ｅ】図５Ｅは、図３の検証過程をさらに詳細に示すフローチャートである。
【図６】図６は、本発明の好ましい一実施例による認証センターの一例の概略ブロック図である。
【図７】図７は、本発明の好ましい一実施例による介在者の一例の概略ブロック図である。
【図８】図８は、関連モバイルユニットが在圏ネットワークシステムでローミング中であるホームネットワークシステムとして示される認証システムの一実施例の概略ブロック図である。
【図９】図９は、ホーム認証アルゴリズムと、ＨＬＲ（Home Location Register、ホームロケーションレジスタ）が異なるネットワークノードで実現されている、本発明によるホームネットワークシステムの別の実施例に関する概略ブロック図である。
【図１０】図１０は、ホーム認証アルゴリズムがいくつかのネットワークノードの間で分散されている、本発明によるホームネットワークシステムのさらに別の実施例の概略ブロック図である。
【図１１】図１１は、複数の異なるネットワークオペレータに対して認証センターとして機能するブローカーを示す概略図である。
【図１】
2005530429.tif 000007
【図２】
2005530429.tif 000008
【図３】
2005530429.tif 000009
【図４】
2005530429.tif 000010
【図５Ａ】
2005530429.tif 000011
【図５Ｂ】
2005530429.tif 000012
【図５Ｃ】
2005530429.tif 000013
【図５Ｄ】
2005530429.tif 000014
【図５Ｅ】
2005530429.tif 000015
【図６】
2005530429.tif 000016
【図７】
2005530429.tif 000017
【図８】
2005530429.tif 000018
【図９】
2005530429.tif 000019
【図１０】
2005530429.tif 000020
【図１１】
2005530429.tif 000021
【国際調査報告】
2005530429.tif 000022
2005530429.tif 000023