JP2005529569A - サービス合意の否認防止（ｎｏｎ−ｒｅｐｕｄｉａｔｉｏｎ） - Google Patents

Abstract

本発明は一般的には通信システムにおけるユーザ（１０）とサービスプロバイダ（２０）との間のサービス合意の効率的な否認防止に関するものである。所謂、サービス合意マネージャと呼ばれる付加的な信頼のおけるパーティ（３０）が導入され、本発明は、サービス合意マネージャ（３０）が秘密キー（Ｋ_i）をユーザ端末（１０）と共有し、サービスプロバイダ（２０）はサービス合意マネージャ（３０）と信頼関係にあるという考えに基づいている。本発明により提案される否認防止の方式はさらに、関連するサービス合意情報、共有秘密キー（Ｋ_i）に基づくこの情報の暗号化処理（１４／３４）に基づいて、ユーザ署名のサービス合意の検証情報を生成する。ユーザ署名の検証情報はその後、サービスプロバイダ（２０）に転送され、サービスプロバイダ（２０）とサービス合意マネージャ（３０）との間の信頼関係に基づいたサービス合意の検証（２６／３６）を可能にする。

Description

本発明は一般には移動体通信システムのような現代の通信システムにおける耐性があり安全な電子商取引に関するものである。

移動体通信システムを含む、今日の多くの通信システムは、システムの安全性と耐性とを改善するために認証と暗号化の手順を採用している。

移動体通信システムでは、例えば、ユーザはネットワークとサービスプロバイダとの内、少なくともいずれかに対して認証を行って基本的なネットワークサービスと他のサービスとに対するアクセスを取得し、また、その認証はユーザに対する課金のためのベースとしての役割を果たしている。現代の通信システムの基本的な機密保護プロトコルは通常、たいていは秘密キー暗号法に基づいたチャレンジ・レスポンス認証手順に関係している。チャレンジ・レスポンス認証はこの分野ではよく知られたものであり、基本的なチャレンジ・レスポンス認証手順についてはいくつかの標準が、例えば、ＧＳＭ（汎欧州デジタル移動電話方式）やＵＭＴＳ（地球規模の移動体通信システム）のネットワークについて存在している。

電子商取引、特に、小額の支払いシステムにおいて、サービスプロバイダはユーザがサービスへの支払いに同意したこと（サービス課金／サービス合意のユーザによる否認防止（non-repudiation））を証明できることが不可欠なことである。

否認防止（non-repudiation）についての知られた技術では通常、公開鍵暗号化方式に基づいたデジタル署名を採用している。これは計算上の観点からすると高価なものである。

本発明は従来技術の構成のこれらの欠点を克服するものである。

本発明の一般的な目的は、通信システムにおけるサービスプロバイダとユーザとの間のサービスの合意の否認を防止するための効率的で耐性のある機構を提供することである。

本発明の目的は、サービスプロバイダがユーザが与えられたサービス合意を全く受け入れたことを証明或いは検証できるようにする機構を提供することである。

例えば、サービスプロバイダにとって、ユーザがその受け入れたサービスの料金の検証を含めて、サービスへの支払いに同意したことを証明できることは関心のあることであるかもしれない。

本発明の別の目的は、通信システムにおける認証及びキー合致（ＡＫＡ）に基づいた改善されたチャレンジ・レスポンスに対する機構を提供することである。

これらの目的は添付した特許請求の範囲によって定義されるような本発明に合致している。

簡単に言えば、本発明は通常は、信用のおける第３者、所謂、サービス合意マネージャを関与させる。本発明はそのサービス合意マネージャがユーザ端末と秘密キーを共有し、サービスプロバイダはそのサービス合意マネージャと信頼関係をもつという考えに基づいたものである。またさらに、本発明によって提案されている否認防止（non-repudiation）方式は、ユーザ署名のサービス合意の検証情報を生成するために、関連するサービス合意の情報の準備と、共有秘密キーに基づくこの情報の暗号化処理とに基づいている。ユーザ署名の検証情報はその後、サービスプロバイダに転送され、サービスプロバイダとサービス合意マネージャとの間の信頼関係に基づいたサービス合意の検証を可能にする。

そのサービス合意マネージャは、サービスプロバイダとユーザとの間のサービス合意を管理するか、さもなければ、その管理に参画する何らかの信頼されたもので良く、例えば、通信システムにおけるネットワークオペレータ側で実施されるかもしれない。

そのサービス合意マネージャは、異なるノード間、或いはパーティ間に分散されることさえもあるかもしれず、例えば、ユーザ・アイデンティティ・ブローカーと、そのサービスプロバイダとそのアイデンティティ・ブローカーとの間に配置される支払いブローカーとを含んでも良い。この場合、信頼のきずなが、サービスプロバイダと、支払いブローカーと、アイデンティティ・ブローカーとの間に確立されており、そこでは、ユーザ端末は普通は秘密キーをアイデンティティ・ブローカーと共有する。

サービス合意の情報の準備は通常、サービスプロバイダによってなされるか、或いは初期化されるが、この情報は、ユーザとサービスプロバイダとの両者がその合意を受け入れる限りにおいては、関与する複数のパーティのいずれかによって準備されても良いことを理解すべきである。

サービス合意の情報の暗号化処理は通常、ユーザ側で実行されるが、ある場合には、サービス合意マネージャを同様に関与させても良い。好ましくは、ユーザ端末が、共有秘密キーから局所的に導出される否認防止キーに基づいて暗号化処理を実行し、要求される検証情報を生成する。

サービスプロバイダがユーザ署名の検証情報を受信し、この情報を格納するための能力をもっているという単なる事実があると、ユーザに加入したサービス合意を否認することを思いとどまらせることになる。もし望むなら、或いはさもなければ適切であれば、実際の検証が、サービス合意マネージャ、或いはサービスプロバイダによってさえも直接に、オンライン、或いはオフラインで実行される。

例えば、サービス合意マネージャは、少なくとも部分的にはその準備されたサービス合意の情報と共有秘密キーとに基づいて期待される検証情報を生成してもよく、必要とされるとき、サービスプロバイダから転送されたユーザ署名の検証情報が実際にその期待される検証情報に対応していることを検証する。

都合の良いことに、ユーザ署名の検証情報は、サービス合意マネージャからの始められたチャレンジにレスポンスして、或いは、ユーザ側で始められたチケットに基づいて、与えられたサービス合意の情報と関連して両方に場合に、ユーザ端末で生成されても良い。

その代わりに、しかしながら、サービス合意の情報の暗号化処理は、サービス合意マネージャ側とユーザ側の両方で実行される。この場合、サービス合意マネージャは、共有秘密キーに基づいたサービス合意の情報の暗号化表現を生成することが好ましく、この表現をユーザ端末に（普通はサービスプロバイダを介して）転送し、それから、受信した暗号化表現がユーザ側で共有秘密キーに基づいて処理されて、正しい検証情報を生成する。

例えば、チケットを基本にした解決策に関し、サービス合意マネージャ側での暗号化処理は、準備されたサービス合意の情報に基づいて生成されたチケットの暗号化を含むと良く、そして、ユーザ側での処理にはその時、一般にはその暗号化されたチケットの復号化を含む。

理解されるべきことであるが、サービス合意の情報は一般には電子契約で良い。しかしながら、本発明は、そのサービス合意の情報がサービス料金請求情報を含み、そのサービス合意マネージャが支払いプロバイダ或いはサービスプロバイダのための料金請求センタとして作用するアプリケーションにおいて特に有用となる。

一般的な契約署名について、サービスプロバイダによるオフライン検証を可能にする特別に設計された実施例は、サービス合意マネージャにより生成された期待される検証情報と同じマスク関数の局所的な実例によるユーザ署名の検証情報との両方に関与させる。共有秘密キーに基づいて生成される期待される検証情報と一般的な契約とは、サービス合意マネージャによりマスクされ、サービスプロバイダに転送される。ユーザ署名の検証情報がユーザ側から受信されて、サービスプロバイダによりマスクされ、従って、サービスプロバイダ側ではサービス合意の検証を、そのマスクされた期待された検証情報とそのマスクされたユーザ署名の検証情報とを比較することにより可能にする。

都合の良いことに、サービス合意マネージャは期待されるサービス合意の検証情報を、認証及びキー合致手順に基づいた通常のチャレンジ・レスポンスにおけるランダムなチャレンジとして契約の暗号化ハッシュを適用することにより生成する。

一連の特に有用な実施例において、サービス合意の否認防止は、認証及びキー合致（ＡＫＡ）に対して通常は採用される同じ共有秘密キーを用いて、ネットワークアクセス（例えば、ＧＭＳ／ＵＭＴＳ ＡＫＡ）に対してチャレンジ・レスポンスを基本としたＡＫＡ手順に組み込まれる。このことは現存するインフラストラクチュアを再利用できることを意味する。

本発明とは明瞭に異なり、サービス合意の否認防止を提供する従来の技術は、非対称な鍵のペアを採用した、サービスプロバイダとユーザ端末との間での直接的な公開鍵暗号化方式に基づいている。

必ずしも必要のないことであるが、サービス合意の否認防止のための鍵をかけるデータを通常のＡＫＡのための鍵をかけるデータ（keying material）から孤立させることは有益であることが分かった。この点に関して、否認防止のための鍵をかけるデータは、認証マネージャと相互動作する具体的な支払いブローカーと結合さえしても良く、この場合には、ユーザ端末は秘密キーを認証マネージャと共有する。

本発明の他の関係した側面から見ると、上記の孤立化機構の基本的な原理は、チャレンジ・レスポンスを基本とした認証及びキー合致（ＡＫＡ）を改善するために採用されている。要するに、通常のＡＫＡ手順は、ネットワークオペレータにより管理されるネットワークへのアクセスのための第１のセットのＡＫＡパラメータを入力として、第１のセットのＡＫＡパラメータの少なくとも一部の表現を用いて、例えば、擬似ランダム関数のような所定の関数によりサービスプロバイダによるサービスへのアクセスのための第２のセットのＡＫＡパラメータから孤立させ、第２のセットのＡＫＡパラメータを生成することにより改善される。これは、たとえサービスアクセスのための鍵をかけるデータが失われたり盗まれたりしたとしても、基本的なネットワークアクセスのために用いることができないという利点をもつ。

本発明は次のような利点を提供している。
・通信システムにおけるサービス合意の効率的で耐性のある否認防止。
・ユーザに加入したサービス合意を否認することを思いとどまらせる。
・ネットワークオペレータが信頼されるサービス合意マネージャとして振舞うための新しいビジネスの可能性を提供する。例えば、オペレータが支払いプロセスにける当然の役割を獲得することもある。
・ＵＭＴＳ／ＧＳＭ ＡＫＡのような基本的なチャレンジ・レスポンス手順を拡張して、支払いの合意にユーザ認証を結合させることを可能にする効率的な方法。
・現存するインフラストラクチュアからの容易な移行。
・新しいＧＳＭ或いはＵＭＴＳ加入者アイデンティティモジュール（ＳＩＭ）を導入することなく、容易に実施可能。端末は新しい支払いプロトコルを組み込むためにどうにかして変更しなければならない。

本発明により提供されるその他の利点については、以下の本発明の実施例の説明を読むときに認識されるであろう。

本発明と、その更なる目的と利点とは共に、添付図面と共にとられた説明を参照することで最良の理解が得られる。

図面全体を通じて、同じ参照記号は対応する或いは類似の要素に対して用いられる。

概要
提案された発明に従う通信システムの概要を示す図である図１に関して、基本的な参画者とその相互関係について概観することで説明を始めることは有益であるかもしれない。

基本的な参画者はユーザ１０、サービスプロバイダ２０、トラスト（trust）プロバイダ３０と一般には呼ばれる付加的なパーティを含む。トラストプロバイダ３０はサービスプロバイダとユーザとの内、少なくともいずれかのために種々のタスクを実行する。トラストプロバイダ３０は、共有秘密キーを介して確立されたユーザ（或いは、むしろ正しく構成されたユーザ端末）との信頼関係がある。トラストプロバイダ３０とサービスプロバイダとは契約上の信頼関係として明白にされた合意があるかもしれない。ユーザ１０とサービスプロバイダ２０との間の関係は通常は、帰納された（induced）信頼関係とみなされ、それはサービスプロバイダによって提供されるサービスが要求されたとき、さもなければそれが始められたときに確立される。

トラストプロバイダは例えば、ユーザが、例えば、加入或いは前払い口座によって確立された信頼関係をもっているネットワークオペレータと関係付けられても良い。

この確立された信頼関係は通常は、ＧＭＳ／ＵＭＴＳのためのＡＫＡ（認証及びキー合致）手順のようなチャレンジ・レスポンス手順と類似の手順との内の少なくともいずれかを可能にする共有秘密キー（対象性暗号化処理）を介した暗号処理の関係で明白にされる。ネットワークオペレータはサービスプロバイダとの合意があるかもしれない。その合意は通常は、類似の暗号化処理の関係で明白にされる。サービスプロバイダはその時、ＧＳＭ／ＵＭＴＳ ＡＫＡのようなチャレンジ・レスポンスをそのサービスのエンドユーザとの間接的な相互認証のために採用するかもしれない。

図２と図３に図式的に例示されているように、所謂訪ねた（visited）オペレータにより管理される別のネットワークに移動体ユーザがローミングするとき、ユーザ認証のための信頼のベースとしてホームオペレータを用いることは知られている。

図２は移動体ユーザが訪ねたネットワークにローミングするとき、移動体通信システムにおいてホームオペレータによるオンライン検証をともなうユーザ認証についての信号交換を模式的に示した図である。

基本的なＵＭＴＳ ＡＫＡ手順は、ユーザ−オペレータ加入に関係した加入者キー或いはそれに由来するキーのような共有秘密キーＫ_iを採用し、チャレンジと２つのセションキーに対する応答を生み出している。それら２つのキーの１つは、秘密保護（Ｃ_k）のためのものであり、もう１つはユーザと訪ねたオペレータとの間のトラフィックの完全性保護（Ｉ_k）のためのものである。ホームオペレータ、或いは、より具体的にはＨＳＳ／ＡｕＣ（ホーム加入者サーバ／認証センタ）とＨＬＲ／ＡｕＣ（ＨＬＲ：ホームロケーションレジスタ）はランダムチャレンジ（ＲＡＮＤ）を認証トークン（ＡＵＴＮ）とともに生成する。認証トークンは後になってユーザにより用いられ、そのチャレンジが新しいもので、ホームオペレータにより生成されたものであることを検証する。このチャレンジから、レスポンス（ＲＥＳ／ＸＲＥＳ）とキー（Ｃ_k、Ｉ_k）が共有秘密キーを用いて計算される。ＧＳＭ ＡＫＡにおいて、完全性キーや認証トークンが生成されることはないが、基本的なチャレンジ・レスポンス手順は同じである。共有秘密キーは伝統的には、ＡＫＡ実施に依存するが、ＧＳＭの移動体ユニットで用いられるＳＩＭカード或いはＵＭＴＳ移動体ユニットで用いられるＵＭＴＳ ＳＩＭカード（ＵＳＩＭ）で実施される。

多かれ少なかれ標準化された拡張認証プロトコル（Extensible Authentication Protocol：ＥＡＰ）に対応している図２において、必要な信号発信を実施する１つの方法は以下のように要約される。

初期フェーズにおいて、ユニットは識別子を訪ねたオペレータに送信すると、その訪ねたオペレータはその識別子をホームオペレータに転送する。この識別子に基づいて、ホームオペレータにおけるＨＳＳ／ＡｕＣ或いはその同等物が対応する秘密キーを取り出して、５つの組の情報（ＲＡＮＤ、ＡＵＴＮ、Ｃ_k、Ｉ_k、ＸＲＥＳ）を生成し、訪ねたオペレータに送信する。

１．チャレンジ（ＲＡＮＤ）、認証トークン（ＡＵＴＮ）
これらのパラメータはユーザに対して訪ねたオペレータにより転送される。

２．チャレンジ（ＲＡＮＤ）、認証トークン（ＡＵＴＮ）
ユーザはＡＵＴＮをチェックし、もし、それがＯＫであれば、レスポンス（ＲＥＳ）、秘密キー（Ｃ_k）、及び完全性キー（Ｉ_k）を計算する。そのレスポンスはホームオペレータに対して訪ねたオペレータを介して返信される。

３．レスポンス（ＲＥＳ）
４．レスポンス（ＲＥＳ）
ホームオペレータはＲＥＳが期待されるレスポンス（ＸＲＥＳ）と等しいかどうかをチェックする。もし、そうであればキーは訪ねたオペレータに安全に転送される。

５．安全性と秘密キー（Ｉ_kとＣ_k）
ホームオペレータはエンドユーザからのＲＥＳを見て、そのエンドユーザが訪ねたオペレータを介して認証されたことを検証できる。しかしながら、ホームオペレータはどんなサービス合意をユーザが受け入れたのかの証拠はもっていない。

もし今日のセルラシステムでなされているような方法で信号発信が実施されるなら、ホームオペレータはユーザ認証のどんな証拠さえももつことはないであろう。この場合、図３を参照すると、その信号発信は以下のとおりである。

１．ＲＡＮＤ、ＡＵＴＮ、Ｉ_k、Ｃ_k、ＸＲＥＳ
２．ＲＡＮＤ、ＡＵＴＮ
ユーザはＡＵＴＮをチェックし、もし、それがＯＫであれば、レスポンスＲＥＳ、秘密キーＣ_k、及び完全性キー（Ｉ_k）を計算する。

３．ＲＥＳ
訪ねたオペレータはＲＥＳが期待されるレスポンス（ＸＲＥＳ）と等しいかどうかをチェックする。もし、そうであればユーザは認証されたのである。

サービス合意の否認防止のための代表的な方式概略
図４は本発明の好適な実施例に従うサービス合意の否認防止のために提案された方式概要についての全体的な構造と基本とを例示した図である。

発明者は、サービスプロバイダにとってユーザが与えられたサービス合意を受け入れたこと、特に、ユーザが受け入れたサービス請求料金の検証を含むサービスに対する支払いに同意したこと（サービス合意／サービス料金のユーザによる否認防止）を証明できることは不可欠なことであると理解している。このことは、ユーザ認証と支払い／料金請求がネットワークオペレータやそれと同等のもののような信頼できる第３者の援助を介して／を伴って実行されるときには、特に重要である。

それ故に、トラストプロバイダ３０が一般的なサイズ合意マネージャとしてサービスプロバイダとユーザとの内少なくともいずれかのために、サービスプロバイダとユーザとの間のサービス合意の否認防止のために作用することが提案される。本発明の好適で基本的な実施例に従う否認防止方式は、関係するサービス合意の情報の準備と、サービス合意マネージャとユーザ端末との間で共有される秘密キーに基づいて準備された情報を暗号化処理することとを含み、ユーザ署名のサービス合意の検証情報を生成する。ユーザ署名の検証情報は後で、サービスプロバイダに転送されて、サービスプロバイダとサービス合意マネージャとの間の信頼関係に基づいたサービス合意の検証を可能にする。

適切な電子的形式（電子契約）におけるサービス合意情報の準備は通常、契約準備／初期化ユニット２２においてサービスプロバイダにより実行されるか、或いは少なくとも初期化される。しかしながら、この情報は、ユーザとサービスプロバイダの両者がその合意を受け入れる限り、複数の関係するパーティのいずれかにより準備されても良い。例えば、サービス合意マネージャ３０は随意的にサービスプロバイダ２０のためにサービス合意の情報を準備できる。

サービス合意の情報の暗号化処理は通常、ユーザ側のユーザ端末１０の耐タンパー性のモジュール１２で実行される。好適には、ユーザ端末１０は、共有秘密キーから局所的に導出された否認防止キーに基づいて暗号化エンジン１４で暗号化処理を実行し、必要な検証情報を生成する。しかしながら、ある実施形では、その暗号化処理がユーザ端末１０の暗号化エンジン１４とサービス合意マネージャ３０の暗号化エンジン３４の両方により実行されても良い。

ユーザ署名の検証情報が安全にユーザ端末１０からサービスプロバイダ２０に転送されるという単なる事実は、否認を阻止する効果があるかもしれない。しかしながら、好適には、検証はオンライン或いはオフラインでサービス合意マネージャにより、或いはその代わりにサービスプロバイダにより直接的にさえ実行される。オフライン手順では、少なくともユーザ署名の検証部分を含む検証情報と、また好適には対応するチャレンジ或いはユーザアイデンティティを伴う他の入力が通常は、記憶場所に格納され、そこから後でサービスプロバイダ２０により取り出されて、ユーザがサービス合意を受け入れたという証拠として呈示される。オンライン手順では、その検証情報は通常、多かれ少なかれサービスプロバイダ２０からサービス合意マネージャ３０に直接転送され、オンライン証明を可能にしている。呈示された検証情報に基づいて、そのとき、サービス合意マネージャ３０は、検証ユニット３６において、ユーザが実際にサービス合意を受け入れたことを検証するために、関係する計算と比較との内、少なくともいずれかを実行する。

サービス合意マネージャは、ユーザＩＤと複数のユーザのセットについての関連秘密キーＫ_iとを含むデータベースと都合よく関係付けられても良い。これにより、サービス合意マネージャは、ユーザ認証パラメータの生成、サービス合意の情報とサービス合意の検証との少なくともいずれかの暗号化処理のような種々の目的のために、対応するユーザＩＤに基づいた与えられたユーザのための関連する秘密キーへのアクセスを取得できる。

後述のように、検証はその代わりに、サービスプロバイダ２０の検証ユニット２６により直接実行されても良い。

サービスプロバイダ２０とサービス合意マネージャ３０との間の信頼関係は、サービス合意マネージャによりなされた陳述或いは提供されたデータについて、そのサービスプロバイダに対する保証を提供すべきである。送信される情報（例えば、サービス合意情報と、料金請求データと、認証パラメータと、他の適切な情報との内、少なくともいずれか）は一般には注意を払うべきものと考えられており、通信を行うパーティのアイデンティティは、上述した保証のためには欠くことのできないものであるので、サービスプロバイダとサイズ合意マネージャとの間の通信リンクは安全に保護されるべきである。このことは、例えば、ＴＬＳ、或いはＩＰＳｅｃにより、或いは個々のメッセージを暗号化して署名することによりなされる。

ＡＫＡ内蔵のサービス合意の否認防止／検証の例
ＡＫＡ内蔵のサービス合意の否認防止／検証の環境下で本発明の説明を始めることは有益であるかもしれない。

一連の好適な実施例において、サービス合意と特にサービス料金請求の否認防止は、通常はＡＫＡに対して採用された同じ共有秘密キーを用いて、ネットワークアクセス（例えば、ＧＭＳ／ＵＭＴＳ ＡＫＡ、或いは類似の認証）のために認証とキー合致（ＡＫＡ）に基づくチャレンジ・レスポンスとともに組み込まれる。ＡＫＡ内蔵の否認防止による大きな利点は既存のインフラストラクチュアを再利用できる点である。

この環境下では、通常は、信頼されたサービス合意マネージャが、ユーザを認証すること、サービスに対するユーザのアクセスを認可すること、ユーザがサービスを利用するための条件に同意したことの証明を確立することの少なくともいずれかを行うための認証／支払いマネージャとして作用すると仮定している。典型的なシナリオでは、ネットワークオペレータが、ユーザとアクセスポイントとの安全で信頼のおける通信を確立するセキュリティシステムとして認証／支払いマネージャの機能を実現するかもしれない。そのオペレータはまた、サービスプロバイダと信頼関係をもち、これらと保護されたリンクにより通信を行う。サービスアクセス要求に応答して、認証／支払いマネージャは、要求を行ったユーザと共有する秘密キー（一般にはＫ_iと記載される）を用い、認証と、認可と、否認防止と、支払い或いは料金請求手順の内、少なくともいずれかを支援する。

サービス料金請求に関して、サービス料金の支払いのユーザ合意はＵＭＴＳ／ＧＳＭ ＡＫＡ或いは類似の認証と結合されても良い。このことは好適には、ユーザが後の段階でサービス合意を否定できないことがサービスプロバイダには保証されるようにして実行されるべきである。

図５は専用の否認防止キーを用いたサービス合意の否認防止についての代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。この例においては、通常のチャレンジ・レスポンス（ＡＫＡ）方式が、ユーザ側とオペレータ側との間で共有される付加的なセションキーから導出された物とともに、付加的なサービス合意の情報で拡張される。

サービスプロバイダにより提供されるサービスにアクセスしたいユーザのことを考慮してみる。そのユーザは通常は、そのサービスが提供される前に認証されねばならない。そのユーザＩＤは公開された識別子ではあってはならず、ユーザに関連した秘密キーＫ_iへのマッピングを可能にすべきである。そのキーにより料金請求が正しく、例えば、正しいアカウントに対して実行される。例えば、もしユーザがホームオペレータに加入しているか、或いは前払いのアカウントに関連した暗号化キーをもっているなら、キーＫ_iは、加入者キーで良い。ユーザＩＤの転送は一般には破線で示されている。なぜなら、これが初期化フェーズとみなされ、また部分的にはこれがおそらくはサービスプロバイダとオペレータとの間の認証ベクトルのバッチ処理の一部であるからである。通常、サービスプロバイダは、そのユーザが関係している認証／支払いマネージャのアイデンティティ、例えば、ユーザのホームオペレータのアイデンティティを決定するのに用いられるユーザからの情報を受信することが必要である。これにより、サービスプロバイダはユーザＩＤをＡＫＡパラメータの要求において、関連する認証／支払いマネージャに転送することが可能になる。受信ユーザＩＤに基づいて、認証／支払いマネージャは秘密キーＫ_iを識別し、適切なＡＫＡパラメータを生成する。認証／支払いマネージャはランダムチャレンジＲＡＮＤを生成し、秘密キーＫ_iに基づいた期待されるレスポンスＸＲＥＳと、与えられる関数ｇに対する入力としてランダムチャレンジＲＡＮＤを計算し、また、Ｋ_iとＲＡＮＤとに基づいた通常の完全性と秘密キーＩ_kとＣ_kとを生成する。

また、ユーザはサービスに対する支払いに同意すべきである。その合意はサービスプロバイダが後でユーザが確かに同意したことを証明できるようになされるべきである。ここでの考えは、ユーザ認証とキーの合致とが実行され、そして、ＲＡＮＤやＸＲＥＳのような認証パラメータ、また、（完全性）と秘密キーＩ_kとＣ_kが生成されるのと同時に、サービス合意の否認防止について、Ｒ_kと表記される付加的なキーを生成することにある。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ，Ｉ_k，Ｃ_k，ＸＲＥＳ
サービスプロバイダは、サービスの識別、サービス料金、有効時間、サービスプロバイダ識別子などの１つ以上の情報項目を含むサービス合意の情報を生成する。次に、サービス合意情報が、与えられた値、サービスユニットのコストを示すコストパラメータＣＯＳＴ＿ＵＮＩＴにより例証される。このコストパラメータは望むなら、それを乱数化する臨時の機器（nonce）、有効時間を示すタイムスタンプ、サービス識別子、及びサービスプロバイダ識別子が伴っても良い。

２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
ユーザはＡＵＴＮをチェックし、もしそれがＯＫであれば、レスポンスＲＥＳ、秘密キーＣ_k、完全性キーＩ_kを標準のＡＫＡ方式のように計算する。これに加えて、拡張ＡＫＡ方式は、共有秘密キーＫ_iとＲＡＮＤとにも基づいた否認防止キーＲ_kを生成する。それから、Ｒ_kが用いられてＭＡＣ（メッセージ認証コード）、ＲＡＮＤによるＣＯＳＴ＿ＭＡＣ、及びＣＯＳＴ＿ＵＮＩＴを計算する。ＣＯＳＴ＿ＭＡＣ＝ＭＡＣ（Ｒ_k，ＲＡＮＤ||ＣＯＳＴ＿ＵＮＩＴ）。ＣＯＳＴ＿ＭＡＣは認証レスポンスＲＥＳと共にサービスプロバイダに返却される。サービスプロバイダは、システムが否認防止の目標を達成するためにＣＯＳＴ＿ＭＡＣを偽造することができてはならない。

３．ＲＥＳ，ＣＯＳＴ＿ＭＡＣ
サービスプロバイダはＲＥＳがＸＲＥＳと合致することをチェックする。また、サービスプロバイダは、例えば、ユーザＩＤ、ＲＡＮＤ、ＣＯＳＴ＿ＵＮＩＴ、ＣＯＳＴ＿ＭＡＣのような検証情報をユーザ合意の後での証拠のために保持する。

もし望むなら、或いは要求されるなら。サービスプロバイダは後でその検証情報をオペレータ側の認証／支払いマネージャに転送しても良い。

４．ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ，ＵＳＥＲ ＩＤ，ＲＡＮＤ
その時、オペレータ側の認証／支払いマネージャは、検証器として動作し、ユーザがサービス合意とサービスコストとを受け入れたことを検証するために、ＣＯＳＴ＿ＭＡＣが期待されたＸＭＡＣ＝ＭＡＣ（Ｒ_k，ＲＡＮＤ||ＣＯＳＴ＿ＵＮＩＴ）に等しいことをチェックする。

もちろん、ＣＯＳＴ＿ＭＡＣを偽造するリスクはある。結局のところ、ＣＯＳＴ＿ＭＡＣのランダムなオンラインテストのためのいくつかの方針が用いられ、ユーザにそのような行動をとらせるのをためらわせるようにしても良い。

本質的には、この代表的なやり方は基本的なＡＫＡをオペレータとユーザとの間で共有するが、サービスプロバイダには分配されていない否認防止キーで拡張することに基づいている。この否認防止キーは、オペレータが検証のできる“署名”メッセージに対してユーザにより用いられる。上述のように、代表的な解決策は、ＲＡＮＤから導出されるキーを用いてＲＡＮＤと共にユーザに送信されるＭＡＣデータに対してであり、そのデータの正当性を検証する。

理解すべきことであるが、第１に通常のＡＫＡシグナリングを実行して、ＲＥＳがＸＲＥＳと等しいことをサービスプロバイダで検証し、後で、ユーザが安全に保護されたリンクによりサービスプロバイダにサービスを要求するときに、否認防止シグナリングを実行することも同じように可能である。このことは、ユーザ認証が成功した後に、サービスプロバイダがコストパラメータＣＯＳＴ＿ＵＮＩＴと関連情報をユーザからのサービス要求時にそのユーザに送信することを意味している。その時、ユーザはＣＯＳＴ＿ＭＡＣを計算し、そのＣＯＳＴ＿ＭＡＣをサービスプロバイダに返送し、サービス合意の検証を可能にする。

図６Ａは専用の否認防止キーを用いたサービス合意のオンライン検証について代表的な信号交換を模式的に示した図である。この例にはオンラインのユーザ認証とサービス合意の検証とを関与させる。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ
サービスプロバイダは、サービスコストパラメータＣＯＳＴ＿ＵＮＩＴのような関連するサービス合意をユーザへの転送のために生成する。

２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
ユーザはＡＵＴＮをチェックし、もしそれがＯＫであれば、レスポンスＲＥＳ、秘密キーＣ_k、完全性キーＩ_k、そして否認防止キーＲ_kを計算する。ＣＯＳＴ＿ＭＡＣが計算され、認証レスポンスＲＥＳと共にサービスプロバイダに返却される。

３．ＲＥＳ，ＣＯＳＴ＿ＭＡＣ
オンライン認証のために、サービスプロバイダはＲＥＳをオペレータ側に転送する。また、ＣＯＳＴ＿ＵＮＩＴ、及びＣＯＳＴ＿ＭＡＣの情報が同時にＲＥＳに付加されても良い。

４．ＲＥＳ，ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ
認証／支払いマネージャは、ＲＥＳが期待されたレスポンス（ＸＲＥＳ）に等しく、ＣＯＳＴ＿ＭＡＣが期待されたＸＭＡＣに等しいことをチェックする。もし、ユーザが前払いのアカウントをもっているなら、そのマネージャはユーザがそのアカウントに十分な資金があることもチェックするかもしれない。これらの条件が合致するなら、キーがサービスプロバイダに送信される。

５．Ｉ_k，Ｃ_k
サービスプロバイダがユーザとサービスプロバイダとの間のセションを保護するためのキーを受信するとき、このことはまた、サービス合意がＯＫであることを示す。

或いは、オフラインの場合に関して前に検討したように、第１に通常のＡＫＡシグナリングを実行して、後で、ユーザが安全に保護されたリンクによりサービスプロバイダにサービスを要求するときに、否認防止シグナリングを実行することが可能である。このことは一般に、ＲＥＳが検証され、キーＩ_kとＣ_kとがサービスプロバイダに送信され、その後に、特別な否認防止シグナリングがサービス要求時にサービスプロバイダにより開始されることを意味している。次に、しかしながら、ＡＫＡが内蔵された例を、主として、内蔵ＡＫＡと否認防止シグナリングと共に説明する。

図６Ｂは否認防止キーとして現存するＡＫＡキーを用いたサービス合意のオンライン検証についての代表的な信号交換を模式的に示した図である。もし、サービスプロバイダが常にキーがオペレータ側がら送信される前にサービス合意のオンライン検証を実行するなら、ＣＯＳＴ＿ＭＡＣが否認防止キーとしてＩ_kとともに生成され、ＡＫＡを拡張して特別な否認防止キーＲ_kを生成する必要はない。しかしながら、サービスプロバイダは、後でセションの完全性の保護のために用いられるキーＩ_kを受信するので、サービス合意の証明を記録し保持する能力をもっていない。オペレータがその合意のハッシュを保持し、サービスプロバイダがデータを過去を振り返って変更できないようにしても良い。

マスクされた認証データと結合した否認防止
図７Ａと図７Ｂとに例示されているように、マスクされた検証データを導入することによりユーザ認証が変形されて識別証明を可能にし、サービスプロバイダがユーザが実際に認証されたことの正当な証拠を呈示するようにできる。

全体的な認証は、認証／支払いマネージャが期待されたレスポンスＸＲＥＳを生成し、ユーザがその後で対応するレスポンスＲＥＳを生成するというチャレンジ・レスポンス手順に基づいている。ここでの基本的な考えは、生成された期待されたレスポンスをマスクし、初期の期待されたレスポンスＸＲＥＳの代わりにマスクされた期待されたレスポンスＸＲＳ′をサービスプロバイダに送信するマスキング関数ｆを導入することにある。ユーザは従来の方法で対応するユーザレスポンスＲＥＳを生成し送信する。そして、サービスプロバイダはオペレータ側からマスクされた期待されたレスポンスＸＲＥＳ′とともにユーザから通常のユーザレスポンスＲＥＳを受信する。その時、サービスプロバイダは、オペレータ側で用いられた同じマスキング関数の実例によってマスクされたユーザレスポンスＲＥＳ′を計算する。ユーザを認証するために、サービスプロバイダは単純に計算されたマスクされたユーザレスポンス′がオペレータ側から受信されたマスクされた期待されたレスポンスＸＲＥＳ′に対応していることを検証する。マスキング手順により、サービスプロバイダはユーザが正しく認証されたことを証明することができ、同時に、通信を傍受した攻撃を防止或いはその攻撃を和らげたりすることの少なくともいずれかのことを行う。

それから、サービスプロバイダは、支払いが転送される前に、レスポンス値或いは好ましくはチャレンジ・レスポンスのペアと、ユーザが実際にネットワークに存在するか或いは他のサービスを利用したかの少なくともいずれかを証明するためのサービス合意の検証情報との少なくともいずれかを提供するようにチャレンジを受けるかもしれない。

明らかに認証／支払いマネージャとサービスプロバイダとは、マスキング関数が認証／支払いマネージャとサービスプロバイダとの間で交換されたことを示唆する関係にある。また、このことは、２つのパーティに対して共通でなければならない類似の情報と関数との少なくともいずれかに対して真実でもある。

図７Ａはサービス合意のオフライン検証と結合したマスクされた認証データによりユーザ認証の証明を確立するための代表的な信号交換を模式的に示した図である。通常のＡＫＡパラメータに加えて、認証／支払いマネージャはＸＲＥＳの関数としてマスクされた期待されたレスポンスＸＲＥＳ′と随意的なマスキングランダムチャレンジＳＡＬＴとを生成する。例えば、マスキングランダムチャレンジはランダムチャレンジＲＡＮＤに基づいているかもしれないし、或いは完全に独立なランダム値として生成されるかもしれない。その後で、マスクされた期待されたレスポンスＸＲＥＳ′とランダムチャレンジＲＡＮＤとが、おそらくは随意的なマスキングランダムＳＡＬＴとともに、サービスプロバイダに送信される。もし、Ｒ_kをもつサービス合意のオフライン検証が用いられるなら、Ｉ_kとＣ_kとはＲＡＮＤ、ＡＵＴＮ、及びＸＲＥＳ′とともに分配される。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ，ＸＲＥＳ′，Ｉ_k，Ｃ_k，［ＳＡＬＴ］
２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
３．ＲＥＳ，ＣＯＳＴ＿ＭＡＣ
サービスプロバイダは同じマスキング関数ｆと同じランダム入力ＲＡＮＤ／ＳＡＬＴとの実例を用いてＲＥＳ′を生成し、マスクされたレスポンスＲＥＳ′がマスクされた期待されたレスポンスＸＲＥＳ′に等しいことをチェックする。サービスプロバイダは、必要であれば、ユーザ認証とサービスの合意の証拠として、後での取り出しのために適切な場所にサービス合意の検証情報としてのＣＯＳＴ＿ＵＮＩＴとＣＯＳＴ＿ＭＡＣと共に認証証明情報としてＲＥＳ，ＲＡＮＤ，及びＵＳＥＲ ＩＤを格納することが好ましい。あるユーザの認証と受け入れたサービス合意の証明とを提供するために、認証／支払いマネージャ或いは何か他の関係するパーティによりチャレンジを受けたなら、サービスプロバイダはその情報をオペレータ側に送信できる。

４．ＲＥＳ，ＲＡＮＤ，ＵＳＥＲ ＩＤ，ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ
なお、サービスプロバイダによって提供された数多くのサービスについてのランダム化されたサービス合意の検証情報のバッチは何の再認証なくオフラインで転送される。

好適には、その時、認証／支払いマネージャはそのユーザに関連した秘密キーＫ_iを取り出して、受信されたＲＡＮＤと秘密キーＫ_iとに基づいて期待されたレスポンス値ＸＲＥＳを計算し、最後に受信ＲＥＳ値と計算されたＸＲＥＳ値とを比較してユーザが実際にサービスプロバイダで認証されたかどうかを検証する。もし、ＲＥＳ値がＸＲＥＳ値と合致しているなら、証明情報は正当であると考えられる。同じようにして、認証／支払いマネージャが、否認防止キーＲ_kとサービスプロバイダから受信したＲＡＮＤ、ＣＯＳＴ＿ＵＮＩＴに基づいて、期待されたサービス合意の検証情報ＸＭＡＣを計算する。それから、認証／支払いマネージャはＣＯＳＴ＿ＭＡＣとＸＭＡＣとを検証してサービスの合意を検証する。

またその代わりに、サービスプロバイダは単純にＲＥＳ値とユーザのユーザＩＤとを送信する。この場合には、認証／支払いマネージャは通常、そのユーザ用のＸＲＥＳ値（或いは、対応するＸＲＥＳ値の再計算を可能にするＲＡＮＤ値）を格納して、ＲＥＳとＸＲＥＳとの比較が実行できるようにする必要がある。

もし随意的なマスキングランダムチャレンジＳＡＬＴが認証／支払いマネージャから明瞭に送信されなかったのであれば、サービスプロバイダは、認証の検証に先立って、好ましくはランダムチャレンジＲＡＮＤに基づいてそれを導出しても良い。その時、マスクされたユーザレスポンスＲＥＳ′が、マスキング関数ｆに対する入力としてのユーザレスポンスＲＥＳと、随意的か受信されたか或いは導出されたマスキングランダムチャレンジＳＡＬＴとにより、サービスプロバイダによって計算される。

上述のように、マスキングランダムチャレンジＳＡＬＴはオプションであり、認証手順から省略されても良い。そのような場合、ランダムチャレンジＳＡＬＴは、マスクされた期待されたレスポンスＸＲＥＳ′とマスクされたユーザレスポンスＲＥＳ′とを夫々計算するマスキング関数ｆに入力される。しかしながら、機密保護を強化するために、そして、計算前の攻撃（pre-computation attack）を打ち負かすために、マスキングランダムチャレンジＳＡＬＴはマスキング関数入力として含まれることが好ましい。従って、マスキングランダムチャレンジＳＡＬＴは認証／支払いマネージャにより完全なランダム値として生成され、その後、マスクされた期待されたレスポンスＸＲＥＳ′とランダムチャレンジＲＡＮＤと共にサービスプロバイダに送信される。しかしながら、オペレータ側とサービスプロバイダとの間の余分なシグナリングを避けるために、マスキングランダムチャレンジＳＡＬＴが代替的にランダムチャレンジＲＡＮＤから導出されても良い。この場合、認証／支払いマネージャは、ランダムチャレンジＲＡＮＤのある関数ｈによりマスキングランダムチャレンジＳＡＬＴを生成する。それ故に、特別なマスキングランダムチャレンジＳＡＬＴがサービスプロバイダに送信される必要があり、そのサービスプロバイダはその代わりに同じ関数ｈを用いてランダムチャレンジＲＡＮＤからマスキングランダムチャレンジＳＡＬＴを生成する。有用なマスクされたランダムチャレンジＳＡＬＴの例は、マスクされたランダムチャレンジＳＡＬＴとして、統一関数（unity function）として表現されるｈと共にランダムチャレンジＲＡＮＤを単純に再利用することである。

関数ｈは公開関数でも良いし、或いはサービスプロバイダと認証／支払いマネージャの（例えば、ホームオペレータのような）法的パーティ(legal party)との間の業務合意に関連して配布された関数でも良い。

マスクされた期待されたレスポンスを生成する認証／支払いマネージャにより一方では用いられ、他方ではマスクされたユーザレスポンスを計算するためにサービスプロバイダにより用いられるマスキング関数ｆは、一方向関数とハッシュ関数との少なくともいずれかで良い。好適には、マスキング関数は、共通値に対してハッシュを実行する、一方向関数性と２つの明瞭な入力を見出すことを不可能にする特性とをもつ暗号化ハッシュ関数である。

マスキング関数ｆは公開関数でも良いし、或いは、認証／支払いマネージャとサービスプロバイダとによって知られるプライベート関数でも良い。後者の場合には、プライベートマスキング関数は、与えられたホームオペレータのような、認証／支払いマネージャの法的なパーティとサービスプロバイダとの間の業務合意に関係している。もし、認証／支払いマネージャの法的パーティ、例えば、ホームオペレータがいくつかの異なるサービスプロバイダとのそのような業務合意をしているなら、対応するプライベート関数が、各プロバイダについてそのオペレータにより用いられる。即ち、各オペレータ−プロバイダ合意がプライベートマスキング関数において明白にされる。

現存するインフラストラクチュアとの関係で円滑な移行を可能にするために、サービスプロバイダは、分配される期待されたレスポンスを計算するときにマスキング関数が用いられたかどうかを通知されるのが好ましい。従って、認証パラメータを分配するプロトコルはそのような指示とともに拡張されるのが好ましい。同様に、異なるマスキング関数の間での選択があるなら、どのマスキング関数を用いるのかの指示がそのプロトコルに含まれていても良い。

図７Ｂに例示されているように、オンライン手順が望まれるなら、認証証明情報とサービス合意の検証情報とが多かれ少なかれ、直接にサービスプロバイダから認証／支払いマネージャに転送される。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ，ＸＲＥＳ′，［ＳＡＬＴ］
２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
３．ＲＥＳ，ＣＯＳＴ＿ＭＡＣ
ＲＥＳ′を生成し、マスクされたレスポンスＲＥＳ′がマスクされた期待されたレスポンスＸＲＥＳ′に等しいことをチェックする。それからシグナリングが進行する。

４．ＲＥＳ，ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ
オペレータ側では、ＲＥＳとＣＯＳＴ＿ＭＡＣとがＸＲＥＳとＸＭＡＣと夫々比較される。もし、その検証がうまくいくなら、そのキーは安全にサービスプロバイダに転送される。

５．Ｉ_k，Ｃ_k
前に検討したように、サービス合意のオンライン検証に関し、専用の否認防止キーＲ_kか或いは完全性キーＩ_kをＣＯＳＴ＿ＭＡＣとＸＭＡＣパラメータを計算するための否認防止キーとして用いることができる。

マスキング手順についてのもっと多くの情報については、ここで本願に組み込まれる２００２年１０月２２日出願の係属中の米国特許出願シリアル番号第１０／２７８，３６２号を参照すると良い。

代表的なチケットを基本としたアプローチ
次にチケットを基本としたアプローチでＡＫＡ内蔵のサービス合意の否認防止についてのいくつかの例を説明する。

チケットをべースにした支払いシステムは一般には、この分野では良く知られたものであり、その例については例えば米国特許第５，７３９，５１１号を見られたい。

特定のチケットシステムは、ＢＡＳＥ＿ＴＩＣＫＥＴは繰り返し所定の回数Ｎだけ知られたハッシュ関数によりＳＴＡＲＴ＿ＴＩＣＫＥＴへとハッシュされるという考えに基づいている。

ＳＴＡＲＴ＿ＴＩＣＫＥＴ：
ＳＴＡＲＴ＿ＴＩＣＫＥＴ＝
ＨＡＳＨ（ＨＡＳＨ（..ＨＡＳＨ（ＢＡＳＥ＿ＴＩＣＫＥＴ）））
ここで、ＢＡＳＥ＿ＴＩＣＫＥＴは通常はＴＩＣＫＥＴ＿Ｎに対応しており、ＳＴＡＲＴ＿ＴＩＣＫＥＴはＴＩＣＫＥＴ＿０に対応する。支払いをするパーティは用いられるＳＴＡＲＴ＿ＴＩＣＫＥＴ或いは最後のＴＩＣＫＥＴのプリイメージを生成する。支払いを受けるパーティはそれから、そのプリイメージがそのチケットへとハッシュすることをチェックできる。そのチケットはハッシュ関数或いは他の適切な１方向関数により相互関係をもつので、ＳＴＡＲＴ＿ＴＩＣＫＥＴは何らかのさらなるチケットからその関数を繰り返し適用することにより取得できる。このことは、支払取引の進行を複雑で時間を消費する検証過程を繰り返し実行する必要なく、チェックできることを意味している。ハッシュ関数が最初のチケットを取得するために適用されねばならない回数は、サービスのユーザによって消費されるチケットの数に直接関係している。

そのようなチケットをベースにしたシステムが安全であるための条件は、べースチケットが予測不可能であることである。ベースチケットは従って、いくつかのランダムなエンティティと他の知られた情報要素のハッシュとのつながりにより形成される。

本発明に従えば、変形例（variant）をもつ前述の否認防止の方式が、ユーザがＳＴＡＲＴ＿ＴＩＣＫＥＴと、ＴＩＣＫＥＴ＿ＭＡＣと表記されるＳＴＡＲＴ＿ＴＩＣＫＥＴの鍵がかけられた（keyed）否認防止ＭＡＣと、ＣＯＳＴ＿ＵＮＩＴとを返却して、オペレータと繰り返し接触したり、或いは新しいユーザ認証を実行することなく、いくつかのイベント／サービスについての否認できない支払いを可能するように拡張される。

どのようにＳＴＡＲＴ＿ＴＩＣＫＥＴが生み出されるのかについてはいくつかの変形例がある。主要な特徴はサービスプロバイダがＳＴＡＲＴ＿ＴＩＣＫＥＴが真正なものであり、認証されたユーザにより、或いは認証されたユーザのための発行されたものであることを検証することが可能であるべきことである。

チケット生成についての特別な解決策は、ユーザがＢＡＳＥ＿ＴＩＣＫＥＴを生成し、ＳＴＡＲＴ＿ＴＩＣＫＥＴを生じさせることである。それから、ユーザはＲ_kのような否認防止キーを利用し、否認防止ＴＩＣＫＥＴ＿ＭＡＣをＳＴＡＲＴ＿ＴＩＣＫＥＴとＣＯＳＴ＿ＵＮＩＴとにより計算し、そのＳＴＡＲＴ＿ＴＩＣＫＥＴとＴＩＣＫＥＴ＿ＭＡＣとをサービスプロバイダに送信する。サービスプロバイダはオフライン手順における随意的な後での検証のために検証情報を格納したり、或いは、そのチケットを受け入れるために、ＴＩＣＫＥＴ＿ＭＡＣの検証のためにオペレータ側にオンラインでメッセージを送信する。

図８Ａはチケットを基本にした否認防止について代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ，Ｉ_k，Ｃ_k，ＸＲＥＳ
サービスプロバイダは、ここではコストパラメータＣＯＳＴ＿ＵＮＩＴにより例証されている関連しるサービス合意情報を生成し、好適にはこの情報を必要なＡＫＡパラメータとともにユーザへと転送する。

２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
ユーザはＡＵＴＮをチェックし、もしそれがＯＫであれば、ＲＥＳ、キーＩ_k、Ｃ_kを、好ましくはＲ_kも計算する。ユーザはＢＡＳＥ＿ＴＩＣＫＥＴを生成し、選択された回数だけハッシュを繰り返すことにより、ＳＴＡＲＴ＿ＴＩＣＫＥＴを導出する。それから、Ｒ_kが用いられてＳＴＡＲＴ＿ＴＩＣＫＥＴとＣＯＳＴ＿ＵＮＩＴとによりＴＩＣＫＥＴ＿ＭＡＣを計算する。ＴＩＣＫＥＴ＿ＭＡＣ＝ＭＡＣ（Ｒ_k，ＳＴＡＲＴ＿ＴＩＣＫＥＴ||ＣＯＳＴ＿ＵＮＩＴ）。もし、明瞭な乱数化が望まれるなら、ＴＩＣＫＥＴ＿ＭＡＣが代わりにＭＡＣ（Ｒ_k，ＳＴＡＲＴ＿ＴＩＣＫＥＴ||ＣＯＳＴ＿ＵＮＩＴ||ＲＡＮＤ）として計算される。ＴＩＣＫＥＴ＿ＭＡＣとＳＴＡＲＴ＿ＴＩＣＫＥＴはＲＥＳと共にサービスプロバイダに返却される。

３．ＲＥＳ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ，ＴＩＣＫＥＴ＿ＭＡＣ
サービスプロバイダは検証情報、例えば、ユーザＩＤ、ＲＡＮＤ、ＣＯＳＴ＿ＵＮＩＴ、及びＣＯＳＴ＿ＭＡＣをユーザ合意の後での証拠のために保持する。

チケットがユーザによって消費されるので、サービスプロバイダは各チケットに対して、ＴＩＣＫＥＴ＿ｉ−１＝ＨＡＳＨ（ＴＩＣＫＥＴ＿ｉ）或いはＳＴＡＲＴ＿ＴＩＣＫＥＴがハッシュ関数を繰り返し適用することにより得られることをチェックする。

もし望まれるなら、或いは要求されるなら、サービスプロバイダは後で、ＣＯＳＴ＿ＵＮＩＴ、ＳＴＡＲＴ＿ＴＩＣＫＥＴ、ＬＡＳＴ＿ＴＩＣＫＥＴ、及びＴＩＣＫＥＴ＿ＭＡＣのような検証情報をオペレータ側の認証／支払いマネージャに対して転送しても良い。これにより、認証／支払いマネージャはＴＩＣＫＥＴ＿ＭＡＣを検証し、消費されたチケットの数を決定して、ユーザに対して正しい金額で請求することが可能になる。

図８Ｂはチケットを基本にした否認防止について代表的な信号交換を、オンライン検証とともに、模式的に示した図である。この例にはオンラインユーザ認証と、サービス合意のチケットを基本とした検証とを関与させる。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ
サービスプロバイダは、ユーザへの転送のために、サービスコストパラメータＣＯＳＴ＿ＵＮＩＴのような関係するサービス合意情報を生成する。

２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ
ユーザはＡＵＴＮをチェックし、もしそれがＯＫであれば、ＲＥＳ、キーＩ_k、Ｃ_kを、好ましくはＲ_kも計算する。ユーザはＢＡＳＥ＿ＴＩＣＫＥＴを生成し、ＳＴＡＲＴ＿ＴＩＣＫＥＴを導出し、それから、ＴＩＣＫＥＴ＿ＭＡＣが計算される。ＴＩＣＫＥＴ＿ＭＡＣとＳＴＡＲＴ＿ＴＩＣＫＥＴはＲＥＳと共にサービスプロバイダに返却される。

３．ＲＥＳ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ，ＴＩＣＫＥＴ＿ＭＡＣ
オンラインの認証と検証とのために、サービスプロバイダはＲＥＳをオペレータ側に転送する。ＣＯＳＴ＿ＵＮＩＴ、ＳＴＡＲＴ＿ＴＩＣＫＥＴ、及びＴＩＣＫＥＴ＿ＭＡＣ情報は同時にＲＥＳに付加されても良い。

４．ＲＥＳ，ＣＯＳＴ＿ＵＮＩＴ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ，ＴＩＣＫＥＴ＿ＭＡＣ
認証／支払いマネージャは、ＲＥＳが期待されたレスポンス（ＸＲＥＳ）と等しいかどうかをチェックし、ＴＩＣＫＥＴ＿ＭＡＣが期待されたＸＭＡＣと等しいことをチェックする。もし、これらの条件に合致するなら、キーがサービスプロバイダに送信される。

５．Ｉ_k，Ｃ_k
ユーザはそれからチケットを消費することを開示し、サービスプロバイダはそのチケットをチェックする。受信されたＬＡＳＴ＿ＴＩＣＫＥＴは最後にはサービスプロバイダからオペレータ側に検証と支払いのこれに続く処理のために転送される。

図９は基本チケットがユーザのために認証／支払いマネージャにより準備された場合のチケットを基本にした否認防止について代表的な信号交換を模式的に示した図である。この例では、オペレータ側はＣＯＳＴ＿ＵＮＩＴに基づいたＢＡＳＥ＿ＴＩＣＫＥＴとサービスプロバイダから受信された（或いは、サービスプロバイダのためにオペレータによって準備された）他の関連データとを生成し、ＳＴＡＲＴ＿ＴＩＣＫＥＴを導出する。オペレータはそれから、Ｒ_kのような否認防止キーをもつＢＡＳＥ＿ＴＩＣＫＥＴをＥＮＣ＿ＴＩＣＫＥＴ＝ＥＮＣ（Ｒ_k，ＢＡＳＥ＿ＴＩＣＫＥＴ）へと暗号化し、それをＳＴＡＲＴ＿ＴＩＣＫＥＴとともにサービスプロバイダへと送信する。それから、サービスプロバイダはＥＮＣ＿ＴＩＣＫＥＴを好ましくはＲＡＮＤとＡＵＴＮと共に、ユーザへと転送する。ユーザは復号化によりそのＢＡＳＥ＿ＴＩＣＫＥＴを取り出すかもしれない。その時、ユーザはＳＴＡＲＴ＿ＴＩＣＫＥＴを導出可能であり、一度サービスプロバイダが必要なセションキーＩ_kとＣ_kとへアクセスするなら、チケットの消費を開始できる。ユーザだけがＢＡＳＥ＿ＴＩＣＫＥＴを復号化でき、従って正しいプレイメージを生成するので、否認防止は確実なものとされる。

基本的な代表的な信号交換は以下のように要約される。

１．ＲＡＮＤ，ＡＵＴＮ，ＥＮＣ＿ＴＩＣＫＥＴ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ
２．ＲＡＮＤ，ＡＵＴＮ，ＥＮＣ＿ＴＩＣＫＥＴ
ユーザはＡＵＴＮをチェックし、もしそれがＯＫであれば、ＲＥＳ、キーＩ_k、Ｃ_kを、好ましくはＲ_kも計算する。都合よく、ユーザはＲ_kを用いてＥＮＣ＿ＴＩＣＫＥＴを復号化することにより、ＢＡＳＥ＿ＴＩＣＫＥＴを再生成し、それからＳＴＡＲＴ＿ＴＩＣＫＥＴを導出する。ユーザはＲＥＳをサービスプロバイダに返却する。

３．ＲＥＳ
オンライン認証のために、サービスプロバイダはＲＥＳをオペレータ側に転送する。

４．ＲＥＳ
認証／支払いマネージャは、ＲＥＳが期待されたレスポンスＸＲＥＳと等しいかどうかをチェックし、認証が成功するとき、セションキーをサービスプロバイダに送信する。

５．Ｉ_k，Ｃ_k
それから、ユーザはチケットの消費を開始し、サービスプロバイダはチケットをチェックする。受信されたＬＡＳＴ＿ＴＩＣＫＥＴは最後に検証とこれに続く支払いの処理のためにサービスプロバイダからオペレータ側に転送される。

なお、チケット発行手順は全体的なシグナリングの認証に含まれなければならないのではなく、後で実行しても良い。

一般的な契約の署名
以前に示唆したように、サービス合意の情報は、一般的な電子的契約でよい。一般的な契約の署名に関し、サービスプロバイダによるオフライン検証を可能する特別に設計された実施例は、サービス合意マネージャにより生成された期待された検証情報と同じマスキング関数の局所的な実例によるユーザ署名の検証情報との両方のマスキングに関与する。

種々のサービス合意情報を含む契約に署名する以下に示す解決策は、上述した支払いについてのチケットを基本としたシステムと類似性があり、また、その基本的な形式において、ユーザ認証の否認防止のために用いられたのと類似のマスキング機構を利用する。

その解決策はユーザと一般的なサービス合意マネージャとは共有する秘密をもつという仮定に基づいている。全体的な手順の支払い部分に少し多く焦点を合わせるとき、サービス合意マネージャはしばしば次の支払いプロバイダとして言及される。もし、その支払いプロバイダがセルラのＧＳＭ／ＵＭＴＳオペレータであれば、そのような共有する秘密が存在し、それはユーザ側では（Ｕ）ＳＩＭに格納される。図１０には相対的には一般的な設定が例示されている。

好適には、サービスプロバイダ２０或いは支払いプロバイダ３０はユーザ１０により署名される契約を準備する。通常、その契約はそれから安全に全ての関係するパーティに配布される。オペレータ側の支払いプロバイダ３０は鍵がかけられた（keyed）ハッシュ関数で共有する秘密を用いて、契約の署名ハッシュと表記される鍵がかけられたハッシュを計算する。鍵のかけられた（keyed）ハッシュ関数は、トゥルー・キード・ハッシュ（true keyed hash）或いは鍵がかけられた関数が続くハッシュとして実行される。ＡＫＡと（Ｕ）ＳＩＭの場合に適合する特別な解決策は、契約を、ＡＫＡ手順における通常のＲＡＮＤに対応する可変ＲＡＮＤ＿ＣＯＮＴへとハッシュし、このＲＡＮＤ＿ＣＯＮＴをＡＫＡ手順へフィードし、このようにして、通常のＲＥＳに対応する署名ＭＡＣを生成することである。署名ＭＡＣはまた、ＡＫＡ手順から生まれる複数のキーの１つの助けを借りて生成されても良い。これは通常、正しいＡＵＴＮ変数が利用可能であるか、或いはメカニズムをチェックするシーケンス番号が不能とされることを仮定している。

署名ＭＡＣはそれから、（公開）マスキング関数（これは前述のマスキング関数ｆの一般化したものを指している）を通過する。そのマスキング関数は暗号化ハッシュ関数である。即ち、実際上は、その関数から出力のプレイメージを見出すことは不可能である。マスクされた署名ＭＡＣは使用されることになるサービスプロバイダ２０へと送信されて、契約のユーザ署名を検証する。

ユーザが契約に署名するとき、その人はまた共有秘密を用い、鍵がかけられたハッシュ関数により署名ＭＡＣを計算する。ユーザは署名ＭＡＣを、公開マスキング関数を知り、従ってその署名をチェックできるサービスプロバイダに送信する。

ユーザに契約の正当性をチェックするための簡単な手順を与えるために、マスクされた署名ＭＡＣが契約それ自身と同時にユーザに送信される。その契約にはまた、例えば、公開マスキング関数において用いられるＳＡＬＴのような、完全な支払い手順で用いられる他の情報を含んでいても良い。

ＡＫＡ手順が用いられるとき、契約に署名するという考えはＡＫＡ手順におけるＲＡＮＤをユーザが署名しなければならない契約のハッシュにさせるところまで要約される。

図１１は図１０の契約署名の実施のため、ＡＫＡ手順を再利用するときの代表的な信号交換を示す図である。

ユーザからのサービス要求時、サービスプロバイダは受信したＵＳＥＲ ＩＤを、そのサービスプロバイダにより準備されているならばおそらくは契約ＣＯＮＴとともにサービス合意マネージャに転送する。そのサービス合意マネージャは契約ＣＯＮＴの関数ｙとしてＲＡＮＤ＿ＣＯＮＴを生成すると良い、それから、サービス合意マネージャは、Ｋ_iとＲＡＮＤ＿ＣＯＮＴ：ＸＭＡＣ＝ｇ（Ｋ_i，ＲＡＮＤ＿ＣＯＮＴ）に基づいて、ＸＭＡＣと表記される期待された署名ＭＡＣを計算する。この署名ＭＡＣは、その時、汎用マスキング関数ｍにより、随意的にそのマスキング関数への付加的な入力としてランダムマスキングチャレンジＲＡＮＤ／ＳＡＬＴを用いて、ＸＭＡＣ′と表記される、マスクされた期待された署名ＭＡＣへとマスクされる。

１．ＸＭＡＣ′，ＲＡＮＤ／ＳＡＬＴ
サービスプロバイダはその時、契約ＣＯＮＴをユーザに転送する。

２．ＣＯＮＴ
関数ｙの実例を用いて、ユーザは、もし、このパラメータがオペレータ側から転送されていないなら、ＲＡＮＤ＿ＣＯＮＴを生成し、また、Ｋ_iとＲＡＮＤ＿ＣＯＮＴ：ＸＭＡＣ＝ｇ（Ｋ_i，ＲＡＮＤ＿ＣＯＮＴ）に基づいて、ユーザ署名ＭＡＣを計算する。このＭＡＣはサービスプロバイダに転送される。

３．ＭＡＣ
サービスプロバイダはそれから、汎用マスキング関数ｍの実例を用いて、ＸＭＡＣ′と表記される、マスクされたユーザ署名ＭＡＣを計算し、そして、最後に計算されたＸＭＡＣ′とオペレータ側から準備したＸＭＡＣ′とを比較してその契約を検証する。好ましくは、サービスプロバイダはＭＡＣ、ＲＡＮＤ＿ＣＯＮＴ／ＣＯＮＴ、及びＵＳＥＲ ＩＤのような検証情報を保持する。もし、サービス合意マネージャによりチャレンジを受けるならば、或いはサービス合意マネージャをもつオンライン手順が望まれるなら、サービスプロバイダはこの検証情報をサービス合意マネージャに転送しても良い。

サービス合意マネージャはその時、ＭＡＣがＸＭＡＣと等しいことを検証する。このことは、契約に基づくサービス合意が最後には検証され、ユーザは少なくとも暗に認証されていることを意味する。

一般的な検証署名手順の新規性とは、サービスプロバイダによるオフライン検証がマスクされた検証データの導入により可能となる点である。言い換えると、サービスプロバイダ（ＳＰ）とオペレータとの間で実行される契約準備は、時間的にユーザとサービスプロバイダ（ＳＰ）との間で実行される契約署名／検証と分離されても良い。この方式の自然な適用は、数多くの契約が異なる条件で（例えば、異なる時間やサービスレベルで）同じユーザに対し、或いは、類似の条件で（例えば、加入の提案を提供するとき）多数のユーザに対して１つのＳＰ−オペレータセションで準備されるときの場合を含む。

鍵をかけるデータ（keying material）の孤立化
別のアプローチでは、ＡＫＡ内蔵のサービス合意の否認防止に再び戻ると、ＡＫＡデータは擬似ランダム関数（ＰＲＦ）への秘密入力として用いられ、新しいセットのＡＫＡデータと否認防止キーとの内少なくともいずれかを導出することができる。

例えば、ＡＫＡ手順の直接的な拡張を行って付加的なキーＲ_kを生成する代わりに、キーＣ_kとＩ_kとが擬似ランダム関数への秘密入力として用いられる。その関数は新しい機密性（Ｃ^' _k）と完全性キー（Ｉ^' _k）と否認防止キー（Ｒ_k）と新しいレスポンス（ＲＥＳ′）とを導出する。Ｃ^' _kとＩ^' _kとが用いられて、Ｃ_kとＩ_kとの代わりに分配される。このようにして、スマートカードで通常実施されている元々のＡＫＡ方式が変更される必要はない。

主要な利点は、サービスにアクセスするとき、ＧＳＭ／ＵＭＴＳでの使用のための鍵をかけるデータと、ユーザ認証と否認防止とに用いられる鍵をかけるデータとを孤立させることができる点にある。従って、サービスのための鍵をかけるデータがたとえ失われても、或いは盗まれても、それが基本的な通信サービスにアクセスするために用いられない。

孤立化のステップを利用することの変形例は、それを用いて完全なＡＫＡ方式で用いられる新しい共有秘密を生成することである。

一般に鍵をかけるデータ（keying material）をＫ（ｉ）と表記するなら、導出工程はＫ（ｉ＋１）＝ＰＲＦ（Ｋ（ｉ），ＳＡＬＴ）と表記される。ここで、ＰＲＦは擬似ランダム関数である。ＳＡＬＴはランダム情報を含むべきであり、例えば、サービスとサービスプロバイダとの内の少なくともいずれかに対してユニークな情報を含んでも良い。例えば、ＰＲＦは機密保護された実時間転送プロトコル（Secure Real-Time Transport Protocol：ＳＲＴＰ）におけるように実施されても良い。

Ｋ（ｉ）は通常基本的なＡＫＡから出力されるが、他のデータはＰＲＦ関数への引数として用いられても良いことが理解されるべきである。加えて、入力引数と結果変数の数は手近な特定のアプリケーションに従って変動しても良い。

図１２Ａは異なる孤立した鍵をかけるセットに基づいたＡＫＡが組み込まれたサービス合意の否認防止について代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。

認証／支払いマネージャは、秘密キーＫ_iとランダムチャレンジＲＡＮＤとに基づいた通常のＡＫＡデータを生成する。Ｋ（０）＝［Ｃ_k，Ｉ_k，ＸＲＥＳ］とする。認証／支払いマネージャは、Ｋ（１）＝［Ｃ^' _k，Ｉ^' _k，Ｒ_k，ＸＲＥＳ′］＝ＰＲＦ（Ｋ（０），ＲＡＮＤ／ＳＡＬＴ）を計算する。ＳＡＬＴはサービスプロバイダＩｄ，ＳＰ＿ＩＤと結合したＲＡＮＤと等しくても良い。

１．ＲＡＮＤ，ＡＵＴＮ，Ｉ^' _k，Ｃ^' _k，ＸＲＥＳ′，［ＳＡＬＴ］
２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ，［ＳＡＬＴ］
ユーザはＡＵＴＮをいつものようにチェックする。それから、ＡＫＡを実行し、Ｋ（０）＝Ｉ_k，Ｃ_k，ＸＲＥＳを導出し、Ｋ（０）におけるＰＲＦを適用してＫ（１）＝Ｃ^' _k，Ｉ^' _k，Ｒ_k，ＲＥＳ′を導出する。ユーザはまた、Ｒ_kを用いて、ＲＡＮＤとＣＯＳＴ＿ＵＮＩＴによるＣＯＳＴ＿ＭＡＣを生成する。

３．ＲＥＳ′，ＣＯＳＴ＿ＭＡＣ
サービスプロバイダはＲＥＳ′がオペレータから受信したＸＲＥＳ′と合致していることをチェックし、もし必要なら、後での取り出しのために検証情報を格納する。もし、チャレンジを受けたりするなら、或いは自己主導で、サービスプロバイダは検証情報をサービス合意の検証のためにオペレータ側に転送しても良い。

図１２Ｂは異なる孤立した鍵をかけるセットに基づいたＡＫＡが組み込まれたサービス合意の否認防止について代表的な信号交換を、可能なオンライン検証とともに、模式的に示した図である。

１．ＲＡＮＤ，ＡＵＴＮ，ＸＲＥＳ′，［ＳＡＬＴ］
２．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ，［ＳＡＬＴ］
ユーザはＡＵＴＮをいつものようにチェックする。それから、ＡＫＡを実行し、Ｋ（０）＝Ｉ_k，Ｃ_k，ＸＲＥＳを導出し、Ｋ（０）におけるＰＲＦを適用してＫ（１）＝Ｃ^' _k，Ｉ^' _k，Ｒ_k，ＲＥＳ′を導出する。ユーザはまた、Ｒ_kを用いて、ＲＡＮＤとＣＯＳＴ＿ＵＮＩＴによるＣＯＳＴ＿ＭＡＣを生成する。

３．ＲＥＳ′，ＣＯＳＴ＿ＭＡＣ
サービスプロバイダはＲＥＳ′がオペレータ側から受信したＸＲＥＳ′と合致していることをチェックし、サービス合意の検証のために検証情報をオペレータ側に転送する。

４．ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ
もしＣＯＳＴ＿ＭＡＣとＸＭＡＣとが合致するなら、セションキーＩ^' _k，Ｃ^' _kが、サービスプロバイダとユーザとの間の通信での利用のためにサービスプロバイダに転送される。

５．Ｃ^' _k，Ｉ^' _k
もちろん、上述のチケットをベースにした解決策も、初期のＡＫＡパラメータから生じる鍵をかけるデータに基づいていても良い。

なお、認証からの通常のネットワークアクセスのための鍵をかけるデータと、サービスプロバイダによって提供されたサービスに対するアクセスのための鍵をかけるデータとを孤立化することは本発明の概念的な独立的な特徴であり、それはサービス合意の否認防止との何らかの組み合わせに限定されるものではない。

上述の手順において、ＳＡＬＴはオペレータでもユーザでも利用可能であると仮定されている。もしＳＡＬＴがＲＡＮＤと等しいなら、このことは取るに足らないことであるが真実である。しかし、タイムスタンプやＲＡＮＤ値に独立なＳＡＬＴのような他の情報が用いられるべきであれば、これらの値は合致して／ユーザに送信されねばならない。特に重要な場合とは、ユーザがコンテキストから本当のＳＰ＿ＩＤ（サービス・プロバイダ・アイデンティティ）を決定できないのではなく、受信情報を当てにしなければならず、そして、このＳＰ＿ＩＤが異なるサービスプロバイダのためのパラメータを孤立化させるために用いられるときである。この場合、情報は標準的なＡＫＡ手順のＡＵＴＮパラメータで転送されるか、或いは上述の契約署名について説明したようなＭＡＣ化されたメッセージ、即ち、機密扱いのパラメータを保護する鍵がかけられたＭＡＣにおいて送信される。鍵のかけられたＭＡＣに用いられるキーは、オペレータとユーザとによりだけ共有されるキー、例えば、Ｉ_k或いはＲ_kであるべきである。

これは一般には、基本的なＡＫＡ手順からのサービスに依存したＡＫＡパラメータを生成することに対応する。

支払いブローカーが関与する代表的なアプリケーション
図１３はアイデンティティ・ブローカーと支払いブローカーとサービスプロバイダとの間の確立された信頼のきずなを採用した、アイデンティティ・ブローカーと支払いブローカーとを関与させた分散実施における代表的なブロック図である。

ここで説明するシナリオでは、付加的な参画者、即ち、支払いブローカー４０を導入する。従って、図１３のセットアップでは、ユーザ１０と、サービスプロバイダ２０と、ユーザと秘密を共有する認証マネージャ３０と、支払いブローカー４０とを含む。支払いブローカーはいくつかのオペレータ／認証マネージャとの関係をもち、オペレータとサービスプロバイダとの間のユーザ認証情報を仲介し、支払いのための支払い／ユーザ能力を検証することの支援を行い、支払い／料金請求のデータを処理する。支払いブローカーは、ユーザのサービス合意を検証できる信頼のおける第３者の役割を果たすかもしれない。

支払いはユーザが既に支払いの関係があるオペレータにリンクされていても良いし、或いは独立のパーティにリンクされて、そのパーティを介して或いは支払いブローカー自身により実行されても良い。

また、通常は認証マネージャと関連したオペレータ側に構成される、ユーザ・アイデンティティ・ブローカーの概念を導入する。ユーザは異なるサービスに対して異なるアイデンティティを用いることを望むかもしれない。アイデンティティ・ブローカーは通常、サービスアクセスについてのユーザ・アイデンティティを、オペレータについてのユーザ・アイデンティティ（即ち、ＩＭＳＩ）にマップする。アイデンティティの仲介を行うことは幾つかのステップにおいて生じる。

ユーザサービスＩＤとオペレータにおけるユーザのＩＤとの間の関係は、アイデンティティ・ブローカーに与えられねばならない。通常、アイデンティティ・ブローカーを実行するオペレータはこのペアリングを生成する。機密保護のため、オペレータによって実行された最後のアイデンティティ・ブローカー関数をもつことは当然である。

そのサービスＩＤはいつかの部分をもっている。個々の部分は支払いブローカーと用いられるアイデンティティ・ブローカーとを示しているかもしれない。もちろん、１つのユーザが幾つかの支払いブローカーを与えられたオペレータ・アイデンティティに対して使用しても良い。支払いブローカーは、与えられたユーザサービスＩＤがどのオペレータに関連付けられているのかを示す記録を、もし、その情報がユーザサービスＩＤから導出されないのであれば、保持しても良い。

以下、２つのシグナリング方式を図１３に示したシナリオを参照して説明する。最初の方式は後払い方式で加入したユーザのためのものであり、第２の方式は前払いサービスに関するものである。

後払いシナリオ
図１４は図１３に示されたセットアップにおける後払いのシナリオにおけるサービス合意の否認防止についての代表的な信号交換を模式的に示した図である。

１．支払いブローカーのＩＤ、ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＰＢ＿ＩＤを含むユーザサービスＩＤ
２．ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＳＰ＿ＩＤ
支払いブローカーは、ユーザサービスｉｄがどのオペレータ／アイデンティティ・ブローカーに関連付けられるのかを知っている。

３．ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＳＰ＿ＩＤ，ＰＢ＿ＩＤ
アイデンティティ・ブローカーの役割を果たしているオペレータはＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤをオペレータ内部のＩＤ（ＩＭＳＩ）にマップして、対応するＡＫＡパラメータＲＡＮＤ、ＡＵＴＮ、Ｋ（０）＝［Ｃ_k，Ｉ_k，ＸＲＥＳ］を取り出す。オペレータは、Ｋ（１）＝［Ｃ^' _k，Ｉ^' _k，ＸＲＥＳ′］＝ＰＲＦ（Ｋ（０），［ＲＡＮＤ，ＰＢ＿ＩＤ］）を導出する。ここで、ＰＢ＿ＩＤは支払いブローカーＩＤであり、ＲＡＮＤはオプションである。明らかにＫ（１）をＰＢ＿ＩＤに依存させることにより、鍵をかけるデータは具体的な支払いブローカーに結合される。

４．ＲＡＮＤ，ＡＵＴＮ，Ｃ^' _k，Ｉ^' _k，（ＳＰ＿ＩＤ||ＰＢ＿ＩＤ，keyedＭＡＣ（Ｉ_k，ＳＰ＿ＩＤ||ＰＢ＿ＩＤ）
キーＣ^' _k，Ｉ^' _kが支払いブローカーとユーザとの間の機密保護された通信のために用いられる。従って、Ｉ^' _kは、例えば、ＣＯＳＴ＿ＭＡＣを計算するときに否認防止キーとして用いられても良いし、Ｃ^' _kは、例えば、ＥＮＣ＿ＴＩＣＫＥＴを導出するために用いられても良い。

支払いブローカーはそれから、Ｋ（２）＝［Ｃ^" _k，Ｉ^" _k，ＸＲＥＳ"］＝ＰＲＦ（Ｋ（１），［ＲＡＮＤ，ＳＰ＿Ｉｄ］）を導出する。

５．ＲＡＮＤ，ＡＵＴＮ，Ｃ^" _k，Ｉ^" _k，ＸＲＥＳ"，（ＳＰ＿ＩＤ||ＰＢ＿ＩＤ，keyedＭＡＣ（Ｉ_k，ＳＰ＿ＩＤ||ＰＢ＿ＩＤ）
６．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ，（ＳＰ＿ＩＤ||ＰＢ＿ＩＤ，keyedＭＡＣ（Ｉ_k，ＳＰ＿ＩＤ||ＰＢ＿ＩＤ））
ユーザはＡＵＴＮをチェックし、共有秘密キーＫ_i、受信したＲＡＮＤ、擬似ランダム関数を用いてＫ（０）、Ｋ（１）、及びＫ（２）を計算する。

７．ＲＥＳ"
サービスプロバイダはＲＥＳ"をチェックして、ユーザの認証レベルを決定する。サービスプロバイダは今やＣ^" _kとＩ^" _kとを用いてユーザへの機密保護された接続の使用を開始する。

ユーザが支払いをしなければならないサービスが求められるとき、ユーザはＣＯＳＴ＿ＭＡＣを送信すべきである。

８．ＣＯＳＴ＿ＭＡＣ
９．ＣＯＳＴ＿ＵＮＩＴ，ＣＯＳＴ＿ＭＡＣ
支払いブローカーはそのＣＯＳＴ＿ＭＡＣを検証し、支払い手順を開始する。

１０．ＯＫ
前払いのシナリオ
図１５は図１３に示されたセットアップにおける前払いのシナリオにおけるサービス合意の否認防止についての代表的な信号交換を模式的に示した図である。

この場合では、ユーザがプリペイドのアカウントを利用し、支払いブローカーによって生成されたチケットを取得する場合について例示する。ここで、孤立したＡＫＡパラメータの導出のためのコンテキスト情報の要求される転送は省略した。

１．ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＰＢ＿ＩＤ
２．ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＣＯＳＴ＿ＵＮＩＴ，ＳＰ＿ＩＤ
支払いブローカーは、ユーザサービスｉｄがどのオペレータ／アイデンティティ・ブローカーに関連付けられるのかを知っている。

３．ＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤ，ＣＯＳＴ＿ＵＮＩＴ，ＳＰ＿ＩＤ，ＰＢ＿ＩＤ
オペレータはＵＳＥＲ＿ＳＥＲＶＩＣＥ＿ＩＤをオペレータ内部のＩＤ（ＩＭＳＩ）にマップして、対応するＡＫＡパラメータＲＡＮＤ、ＡＵＴＮを取り出し、Ｋ（０）＝［Ｃ_k，Ｉ_k，ＸＲＥＳ］を生成する。オペレータは、Ｋ（１）＝［Ｃ^' _k，Ｉ^' _k，ＸＲＥＳ′］＝ＰＲＦ（Ｋ（０），［ＲＡＮＤ，ＰＢ＿Ｉｄ］）を導出する。ここで、ＰＢ＿ＩＤは支払いブローカーＩｄであり、ＲＡＮＤはオプションである。明らかにＫ（１）をＰＢ＿Ｉｄに依存させることにより、鍵をかけるデータは具体的な支払いブローカーに結合される。

オペレータはまた、ユーザのプリペイドのアカウントをチェックする。採用されたポリシーに依存して、オペレータはユーザアカウントのＣＯＳＴ＿ＵＮＩＴの数Ｎ＃を予約して、Ｎ＃を支払いブローカーに送信する。

４．ＲＡＮＤ，ＡＵＴＮ，Ｃ^' _k，Ｉ^' _k，Ｎ＃
支払いブローカーはＢＡＳＥ＿ＴＩＣＫＥＴを生成して、暗号化キーとしてＣ^' _kを用いてＳＴＡＲＴ＿ＴＩＣＫＥＴとＥＮＣ＿ＴＩＣＫＥＴとを計算する。ＳＴＡＲＴ＿ＴＩＣＫＥＴは、それが、ＣＯＳＴ＿ＵＮＩＴＳのある数Ｎ'＃≦Ｎ＃に対して妥当であるように生成される。

支払いブローカーはそれから、Ｋ（２）＝［Ｃ^" _k，Ｉ^" _k，ＸＲＥＳ"］＝ＰＲＦ（Ｋ（１），［ＲＡＮＤ，ＳＰ＿Ｉｄ］）を導出する。

５．ＲＡＮＤ，ＡＵＴＮ，Ｃ^" _k，Ｉ^" _k，ＸＲＥＳ"，ＥＮＣ＿ＴＩＣＫＥＴ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ
６．ＲＡＮＤ，ＡＵＴＮ，ＣＯＳＴ＿ＵＮＩＴ，ＳＴＡＲＴ＿ＴＩＣＫＥＴ，ＥＮＣ＿ＴＩＣＫＥＴ
ユーザはＡＵＴＮをチェックし、共有秘密キーＫ_i、受信したＲＡＮＤ、擬似ランダム関数を用いてＫ（０）、Ｋ（１）、及びＫ（２）を計算する。

７．ＲＥＳ"
サービスプロバイダはＲＥＳ"をチェックして、Ｃ^" _kとＩ^" _kとを用いてユーザへの機密保護された接続の使用を開始する。

ユーザが支払いをしなければならないサービスが求められるとき、ユーザはＴＩＣＫＥＴをサービスプロバイダに送信すべきである。このことを行うことができるために、ユーザはＥＮＣ＿ＴＩＣＫＥＴを復号化し、ＨＡＳＨ関数を反復（iterate）してユーザがもっているチケットの数をチェックし、ＳＴＡＲＴ＿ＴＩＣＫＥＴが正当なものであることをチェックする。

それから、ＴＩＣＫＥＴ、即ち、ＴＩＣＫＥＴ＿ｉを送信する。

８．ＴＩＣＫＥＴ＿ｉ
サービスプロバイダは受信したチケットをチェックする、そのセションがクローズするとき、サービスプロバイダは受信した最後のチケットを支払いブローカーに送信する。

９．ＬＡＳＴ＿ＴＩＣＫＥＴ
支払いブローカーはその受信したチケットし、オペレータに送信される料金請求の記録を生成する。

１０．料金請求の記録
最後に、ユーザのアカウントはそれに従って調整される。

再認証
サービスプロバイダは異なる理由のために、ユーザを再認証する可能性をもつことを望むかもしれない。これを成し遂げる１つの方法は、Ｋ（ｎ）生成を反復することである。即ち、ｎ番目の認証が発生するとき、鍵をかけるデータＫ（ｎ＋１）＝ＰＲＦ（Ｋ（ｎ），［ＲＡＮＤ，ＳＰ＿ＩＤ］）が用いられる。このことは、サービスプロバイダが擬似ランダム関数ＰＲＦの実例にアクセスし、必要な認証パラメータとセションキーとを生成することができることを意味する。要するに、サービスプロバイダは新しいセションキーとｎ＋１のオーダの期待されたレスポンスを擬似ランダム関数を用いて生成し、再認証要求においてユーザにＲＡＮＤを送信する。そのとき、ユーザは、擬似ランダム関数を用いて新しいセションキーとｎ＋１のオーダのユーザレスポンスを生成し、その生成されたｎ＋１のオーダのユーザレスポンスをサービスプロバイダに返却する。それから、サービスプロバイダは受信レスポンスを検証し、新しいセションキーに基づいてユーザとの通信を開始する。

好ましくは、ｎがユーザに送信され，ユーザではリプレイ攻撃に対する保護のために簡単なリプレイリストを保持すると良い。

実施上の側面からの更なる特徴
上述の工程、動作、及びアルゴリズムは、ソフトウェア／ハードウェア、或いはその組み合わせで実施されると良い。ハードウェアで実施する場合、ＡＳＩＣ（アプリケーション専用集積回路）の技術や何らかの他の従来の回路技術が用いられると良い。特別な耐タンパー性のあるハードウェアが安全上の理由から好ましいかもしれず、正しく保護されたソフトウェアによる実施がしばしば、より都合が良いものである。

図１６は本発明の好適な実施例に従うサービス合意マネージャの例を図示したブロック図である。図１６のサービス合意マネージャ３０は基本的には、外部通信リンク用の通信インタフェース３１、データベース３２、認証及びキーイングユニット３３、検証ユニット３６、オプションのチケット発行ユニット３７、及び支払い／料金請求ユニット３８を含んでいる。データベース３２は、ユーザＩＤや関連する秘密キーＫ_i情報のような情報を含む。認証及びキーイングユニット３３は、関連する認証及びキーパラメータを生成するのに動作し、また、種々の実施例で用いられるオプションのマスキング関数と擬似ランダム関数とを保持しても良い。検証ユニット３６は、関連する計算と比較との少なくともいずれかを実行し、ユーザが与えられたサービス合意を受け入れたことを検証する。オプションのチケット発行ユニット３７は、ユーザのために関連するチケットを生成するか、チケット検証を実行するかの少なくともいずれかを行うと良い。その名称が示唆するように、支払いユニット３８は、支払いの転送を処理し、例えば、料金請求が正しく、例えば、正しいアカウントに対して実行されることを確認する。

図１７は本発明の好適な実施例に従うサービスプロバイダの例を図示したブロック図である。図１７のサービスプロバイダ２０は基本的には、外部通信リンク用の通信インタフェース２１、契約準備ユニット２２、オプションの認証ユニット２３、情報の転送或いは格納の少なくともいずれかを行うユニット２５、及びオプションの認証ユニット２６を含んでいる。契約準備ユニット２２において、サービスプロバイダは通常、要求されたサービスに従って関連するサービス合意情報とそのサービス利用のための現在の条件とを準備する。その代わりに、契約準備はサービスプロバイダのためにある別のパーティによって実行されても良いが、しかし、普通は、そのような外部での契約準備はとにかく、そのサービスプロバイダから初期化される。マスクされた契約署名とユーザ認証との少なくともいずれかに関し、サービスプロバイダは受け入れたサービス合意の検証とユーザ認証との内の少なくともいずれかを、検証ユニット２６と認証ユニット２３との少なくともいずれかにおいて実行すると良い。オフライン手順では、サービスプロバイダは後でサービス合意マネージャ３０或いはそのサービス合意マネージャにより割当てられた他のパーティへの転送のために、ユニット２５に検証情報を格納することを望むかもしれない。

図１８は本発明の好適な実施例に従うユーザ端末の例を図示したブロック図である。図１８のユーザ端末１０は基本的には、外部通信リンク用の通信インタフェース１１と耐タンパー性モジュール１２を含んでいる。取り外し可能に構成されたＳＩＭ或いはＵＳＩＭカードに似ているかもしれない耐タンパー性モジュール１２は、Ｉ／Ｏユニット１０１、ＡＫＡアルゴリズムユニット１０２、安全に組み込まれた（カプセル化された）共有秘密キーＫ_i１０３、ＭＡＣ／復号化のような目的のための暗号化処理ユニット１０４、及びチケットを基本とした否認防止のためのオプションのチケット発行ユニット１０５とを含んでいる。ＡＫＡユニットとアプリケーション・ツールキット環境との間に適切なインタフェースがあれば、暗号処理やチケット発行のような機能をソフトウェアとして（Ｕ）ＳＩＭカードの（Ｕ）ＳＩＭアプリケーション・ツールキット環境に組み込むことにより、現存する（Ｕ）ＳＩＭカードを変更することさえも可能であるかもしれない。

上述の実施例は単に例として与えられたものであり、本発明はそれに限定されるものではないことを理解されたい。ここで開示され請求されている請求の範囲の基本的な基幹となる原理を留める更なる変形、変更、改善は、本発明の範囲と精神との中にあるものである。

本発明の好適な実施例に従う基本的な参画者とその相互関係の概要を示す図である。 移動体ユーザが訪ねたネットワークにローミングするときの移動体通信システムにおけるホーム認証についての信号交換を模式的に示した図である。 今日のセルラシステムで通常実施されている方法で委任された検証を伴う認証のための信号交換を模式的に示した図である。 本発明の好適な実施例に従うサービス合意の否認防止のために提案された方式概要についての全体的な構造と基本とを例示した図である。 専用の否認防止キーを用いたサービス合意の否認防止について代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。 専用の否認防止キーを用いたサービス合意のオンライン検証について代表的な信号交換を模式的に示した図である。 否認防止キーとして現存するＡＫＡキーを用いたサービス合意のオンライン検証について代表的な信号交換を模式的に示した図である。 サービス合意のオフライン検証と結合したマスクされた認証データによりユーザ認証の証明を確立するための代表的な信号交換を模式的に示した図である。 認証とサービス合意の両方のオンライン検証と結合したマスクされた認証データによるユーザ認証の証明を、専用キーか或いはサービス合意の否認防止のための現存するＡＫＡキーを用いて、確立するための代表的な信号交換を模式的に示した図である。 チケットを基本にした否認防止について代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。 チケットを基本にした否認防止について代表的な信号交換を、オンライン検証とともに、模式的に示した図である。 基本チケットがユーザのために認証／支払いマネージャにより準備された場合のチケットを基本にした否認防止について代表的な信号交換を模式的に示した図である。 サービスプロバイダによるオフライン検証を可能にするマスクされた検証データの導入に基づく契約署名についての代表的なブロック図である。 図１０の契約署名のための代表的な信号交換を示す図である。 異なる孤立したキーイング（keying）セットに基づいたＡＫＡが組み込まれたサービス合意の否認防止について代表的な信号交換を、可能なオフライン検証とともに、模式的に示した図である。 異なる孤立したキーイングセットに基づいたＡＫＡが組み込まれたサービス合意の否認防止について代表的な信号交換を、可能性のあるオンライン検証とともに、模式的に示した図である。 アイデンティティ・ブローカーと支払いブローカーとサービスプロバイダとの間の確立された信頼のきずなを採用した、アイデンティティ・ブローカーと支払いブローカーとを関与させた分散実施における代表的なブロック図である。 図１３に示されたセットアップにおける後払いのシナリオにおけるサービス合意の否認防止についての代表的な信号交換を模式的に示した図である。 図１３に示されたセットアップにおける前払いのシナリオにおけるサービス合意の否認防止についての代表的な信号交換を模式的に示した図である。 本発明の好適な実施例に従うサービス合意マネージャの例を図示したブロック図である。 本発明の好適な実施例に従うサービスプロバイダの例を図示したブロック図である。 本発明の好適な実施例に従うユーザ端末の例を図示したブロック図である。

Claims (47)

1. 通信システムにおけるユーザとサービスプロバイダとの間のサービスの合意を否認防止（non-repudiation）の方法であって、前記方法は
   ユーザ端末と、前記サービスプロバイダとの信頼関係をもっているサービス合意マネージャとの間の秘密キーを安全に共有する工程と、
   サービスの合意情報を準備する工程と、
   前記共有秘密キーに基づいて前記サービスの合意情報を暗号処理して、ユーザ署名のサービス合意の検証情報を生成する工程と、
   前記ユーザ署名の検証情報を前記サービスプロバイダに転送して、前記サービスプロバイダと前記サービス合意マネージャとの間の信頼関係に基づいた前記サービスの合意の検証を可能にする工程とを有することを特徴とする方法。
2. 前記サービスの合意情報を暗号処理する工程は、前記ユーザ端末において安全に実行されて前記ユーザ署名の検証情報を生成することを特徴とする請求項１に記載の方法。
3. 前記サービスの合意情報を暗号処理する工程は、前記共有秘密キーから局所的に導出される否認防止キーに基づいて実行されることを特徴とする請求項１又は２に記載の方法。
4. 前記サービス合意マネージャにおいて、少なくとも部分的には前記サービスの合意情報と前記共有秘密キーとに基づいて、期待される検証情報を生成する工程と、
   前記サービス合意マネージャにおいて、前記ユーザ署名の検証情報が前記期待される検証情報に対応していることを検証する工程とを有することを特徴とする請求項２に記載の方法。
5. 前記ユーザ署名の検証情報は、前記サービス合意マネージャから開始されるランダムチャレンジと前記サービスの合意情報とにレスポンスして、前記ユーザ端末において生成されることを特徴とする請求項２に記載の方法。
6. 前記ユーザ署名の検証情報は、ユーザ側で初期化されたチケットと前記サービスの合意情報とに基づいて、前記ユーザ端末において生成されることを特徴とする請求項２に記載の方法。
7. 前記サービスの合意情報を準備する工程は、前記サービスプロバイダによって初期化されることを特徴とする請求項１に記載の方法。
8. 前記サービスの合意情報を暗号処理する工程は、
   前記サービス合意マネージャが、前記共有秘密キーに基づいて前記サービスの合意情報の暗号処理を実行し、前記ユーザに転送される、前記サービスの合意情報の暗号化表現を生成する工程と、
   前記ユーザ端末が、前記共有秘密キーに基づいて前記暗号化表現の暗号処理を実行して前記ユーザ署名の検証情報を生成する工程とを有することを特徴とする請求項１に記載の方法。
9. 前記サービスの合意マネージャが暗号処理を実行する工程は、
   前記サービスの合意情報に基づいてチケットを生成する工程と、
   前記共有秘密キーから局所的に導出される否認防止キーに基づいて前記チケットを暗号化する工程とを有し、
   前記ユーザ端末が暗号処理を実行する工程は、
   前記共有秘密キーから局所的に導出される前記否認防止キーに基づいて前記暗号化されたチケットを復号化する工程を有することを有することを特徴とする請求項１に記載の方法。
10. 前記サービスの合意情報は一般的な電子契約であり、
    前記方法はさらに、
    前記サービス合意マネージャが前記共有秘密キーと前記電子契約とに基づいて、期待されるサービス合意の検証情報を生成する工程と、
    前記サービス合意マネージャが前記期待される検証情報をマスク関数によりマスクする工程と、
    前記サービス合意マネージャが前記マスクされた期待される検証情報を前記サービスプロバイダに転送する工程と、
    前記サービスプロバイダが前記ユーザ署名の検証情報を前記同じマスク関数の実例によりマスクして、マスクされたユーザ署名の検証情報を生成する工程と、
    前記サービスプロバイダが前記マスクされたユーザ署名の検証情報が前記サービス合意マネージャから取得された前記マスクされた期待される検証情報に対応していることを検証する工程とをに有することを特徴とする請求項１に記載の方法。
11. 前記サービス合意マネージャが期待されるサービス合意の検証情報を生成する工程は、認証及びキー合致手順に基づいて、通常のチャレンジ・レスポンスにおけるランダムチャレンジとして前記契約のハッシュを適用することを特徴とする請求項１０に記載の方法。
12. 前記マスク関数は、暗号化ハッシュ関数であることを特徴とする請求項１０に記載の方法。
13. 前記方法は、ネットワークアクセスに対する認証及びキー合致（ＡＫＡ）手順に基づいたチャレンジ・レスポンスに組み込まれ、前記共有秘密キーはＡＫＡに対して用いられる秘密キーと同じであることを特徴とする請求項１に記載の方法。
14. 前記サービス合意の否認防止のために鍵をかけるデータ（keying material）は、前記ＡＫＡ手順に基づくチャレンジ・レスポンス手順に対して鍵をかけるデータからは孤立させられることを特徴とする請求項１３に記載の方法。
15. 前記否認防止のために鍵をかけるデータは、擬似ランダム関数に対する入力としてＡＫＡに対して鍵をかけるデータに基づいた前記擬似ランダム関数により生成されることを特徴とする請求項１４に記載の方法。
16. 前記否認防止のために鍵をかけるデータは、認証マネージャと相互動作する具体的な支払いブローカーに結合されており、
    前記認証マネージャと前記ユーザ端末とは前記秘密キーを共有することを特徴とする請求項１４に記載の方法。
17. 前記否認防止のために鍵をかけるデータは前記サービスプロバイダに結合され、前記鍵をかけるデータを別のサービスプロバイダのための対応する鍵をかけるデータから孤立させることを特徴とする請求項１４に記載の方法。
18. 前記サービスの合意情報はサービス料金請求情報を含み、
    前記サービス合意マネージャは、前記ユーザのために前記サービスの支払いを処理する支払いプロバイダであることを特徴とする請求項１に記載の方法。
19. 前記サービス合意マネージャは、ユーザ・アイデンティティ・ブローカーと、前記サービスプロバイダと前記アイデンティティ・ブローカーとの間に配置される支払いブローカーとを含み、
    信頼のチェインが、前記サービスプロバイダと、前記支払いブローカーと、前記アイデンティティ・ブローカーとの間に確立されており、
    前記アイデンティティ・ブローカーは前記秘密キーを前記ユーザ端末と共有することを特徴とする請求項１に記載の方法。
20. 前記共有秘密キーに基づいて導出され、前記アイデンティティ・ブローカーから得られる否認防止キーに基づいて、前記ユーザ署名の検証情報を前記支払いブローカーが検証する工程をさらに有することを特徴とする請求項１９に記載の方法。
21. 通信システムにおけるユーザとサービスプロバイダとの間のサービスの合意を否認防止のシステムであって、前記システムは
    ユーザ端末と、前記サービスプロバイダとの信頼関係をもっているサービス合意マネージャとの間の秘密キーを安全に共有する手段と、
    サービスの合意情報を準備する手段と、
    前記共有秘密キーに基づいて前記サービスの合意情報を暗号処理して、ユーザ署名のサービス合意の検証情報を生成する手段と、
    前記ユーザ署名の検証情報を前記サービスプロバイダに転送して、前記サービスプロバイダと前記サービス合意マネージャとの間の信頼関係に基づいた前記サービスの合意の検証を可能にする手段とを有することを特徴とするシステム。
22. 前記サービスの合意情報を暗号処理する手段は、前記ユーザ端末において安全に実施されることを特徴とする請求項２１に記載のシステム。
23. 前記サービスの合意情報を暗号処理する手段は、前記共有秘密キーから局所的に導出される否認防止キーに基づいて動作することを特徴とする請求項２１又は２２に記載のシステム。
24. 前記サービス合意マネージャに、少なくとも部分的には前記サービスの合意情報と前記共有秘密キーとに基づいて、期待される検証情報を生成する手段と、
    前記サービス合意マネージャに、前記ユーザ署名の検証情報が前記期待される検証情報に対応していることを検証する手段とをさらに有することを特徴とする請求項２２に記載のシステム。
25. 前記ユーザ署名の検証情報は、前記サービス合意マネージャから開始されるランダムチャレンジと前記サービスの合意情報とにレスポンスして、前記ユーザ端末において生成されることを特徴とする請求項２２に記載のシステム。
26. 前記ユーザ署名の検証情報は、ユーザ側で初期化されたチケットと前記サービスの合意情報とに基づいて、前記ユーザ端末において生成されることを特徴とする請求項２２に記載のシステム。
27. 前記サービスの合意情報は、前記サービスプロバイダによって準備されることを特徴とする請求項２１に記載のシステム。
28. 前記サービスの合意情報を暗号処理する手段は、
    前記サービス合意マネージャにおける、前記共有秘密キーに基づいて前記サービスの合意情報の暗号処理を実行し、前記ユーザに転送される、前記サービスの合意情報の暗号化表現を生成する手段と、
    前記ユーザ端末における、前記共有秘密キーに基づいて前記暗号化表現の暗号処理を実行して前記ユーザ署名の検証情報を生成する手段とを有することを特徴とする請求項２１に記載のシステム。
29. 前記サービスの合意マネージャにおいて暗号処理を実行する手段は、
    前記サービスの合意情報に基づいてチケットを生成する手段と、
    前記共有秘密キーから局所的に導出される否認防止キーに基づいて前記チケットを暗号化する手段とを有し、
    前記ユーザ端末において暗号処理を実行する手段は、
    前記共有秘密キーから局所的に導出される前記否認防止キーに基づいて前記暗号化されたチケットを復号化する手段を有することを有することを特徴とする請求項２１に記載のシステム。
30. 前記サービスの合意情報は一般的な電子契約であり、
    前記システムは、
    前記サービス合意マネージャに、前記共有秘密キーと前記電子契約とに基づいて、期待されるサービス合意の検証情報を生成する手段と、
    前記サービス合意マネージャに、前記期待される検証情報をマスク関数によりマスクする手段と、
    前記サービス合意マネージャに、前記マスクされた期待される検証情報を前記サービスプロバイダに転送する手段と、
    前記サービスプロバイダに、前記ユーザ署名の検証情報を前記同じマスク関数の実例によりマスクして、マスクされたユーザ署名の検証情報を生成する手段と、
    前記サービスプロバイダに、前記マスクされたユーザ署名の検証情報が前記サービス合意マネージャから取得された前記マスクされた期待される検証情報に対応していることを検証する手段とをさらに有することを特徴とする請求項２１に記載のシステム。
31. 前記期待されるサービス合意の検証情報を生成する手段は、認証及びキー合致手順に基づいて、通常のチャレンジ・レスポンスにおけるランダムチャレンジとして前記契約の暗号化ハッシュを適用する手段を有することを特徴とする請求項３０に記載のシステム。
32. 前記マスク関数は、暗号化ハッシュ関数であることを特徴とする請求項３０に記載のシステム。
33. 前記システムは、ネットワークアクセスに対する認証及びキー合致（ＡＫＡ）手順に基づいたチャレンジ・レスポンス用のシステムに組み込まれ、
    前記共有秘密キーはＡＫＡに対して用いられる秘密キーと同じであることを特徴とする請求項２１に記載のシステム。
34. 前記サービス合意の否認防止のために鍵をかけるデータを、前記ＡＫＡ手順に基づくチャレンジ・レスポンス手順に対して鍵をかけるデータからは孤立させる手段をさらに有することを特徴とする請求項３３に記載のシステム。
35. 前記否認防止のために鍵をかけるデータは、擬似ランダム関数に対する入力としてＡＫＡに対して鍵をかけるデータに基づいた前記擬似ランダム関数により生成されることを特徴とする請求項３４に記載のシステム。
36. 前記否認防止のために鍵をかけるデータは、認証マネージャと相互動作する具体的な支払いブローカーに結合されており、
    前記認証マネージャと前記ユーザ端末とは前記秘密キーを共有することを特徴とする請求項３４に記載のシステム。
37. 前記否認防止のために鍵をかけるデータは前記サービスプロバイダに結合され、前記鍵をかけるデータを別のサービスプロバイダ用の対応する鍵をかけるデータから孤立させることを特徴とする請求項３４に記載のシステム。
38. 前記サービスの合意情報はサービス料金請求情報を含み、
    前記サービス合意マネージャは、前記ユーザのために前記サービスの支払いを処理する支払いプロバイダであることを特徴とする請求項２１に記載のシステム。
39. 前記サービス合意マネージャは、ユーザ・アイデンティティ・ブローカーと、前記サービスプロバイダと前記アイデンティティ・ブローカーとの間に配置される支払いブローカーとを含み、
    信頼のチェインが、前記サービスプロバイダと、前記支払いブローカーと、前記アイデンティティ・ブローカーとの間に確立されており、
    前記アイデンティティ・ブローカーは前記秘密キーを前記ユーザ端末と共有することを特徴とする請求項２１に記載のシステム。
40. 前記支払いブローカーに、前記共有秘密キーに基づいて導出され、前記アイデンティティ・ブローカーから得られる否認防止キーに基づいて、前記ユーザ署名の検証情報を検証する手段をさらに有することを特徴とする請求項３９に記載のシステム。
41. サービスプロバイダとの信頼関係をもっている外部のサービス合意マネージャと共有する秘密キーを安全に保持する手段と、
    ユーザとサービスプロバイダとの間のサービスの合意を表す情報を受信する手段と、
    前記共有秘密キーに基づいて前記サービスの合意を表す情報の暗号処理を安全に実行して、ユーザ署名のサービス合意の検証情報を生成する手段と、
    前記ユーザ署名の検証情報を前記サービスプロバイダに転送して、前記サービスプロバイダと前記サービス合意マネージャとの間の信頼関係に基づいた前記サービスの合意の検証を可能にする手段とを有することを特徴とするユーザ端末。
42. 通信システムにおけるユーザとサービスプロバイダとの間のサービスの合意の管理を支援するサービス合意マネージャであって、前記サービス合意マネージャは、
    前記サービスプロバイダとの信頼関係をもっており、ユーザ端末と共有する秘密キーを安全に保持する手段と、
    前記サービスの合意を表す情報と前記共有秘密キーとに基づいて、前記ユーザ端末により生成されるユーザ署名のサービス合意の検証情報を受信する手段と、
    前記共有秘密キーに基づいて、前記ユーザ署名のサービス合意の検証情報を検証し、前記サービス合意のユーザによる受け入れを確認する手段とを有することを特徴とするサービス合意マネージャ。
43. 通信システムにおけるユーザとサービスプロバイダとの間での与えられたサービスの合意に従って前記ユーザにサービスを提供するサービスプロバイダであって、前記サービスプロバイダは、
    ユーザ端末と秘密キーを共有するサービス合意マネージャとの信頼関係を確立する手段と、
    前記ユーザ端末から、少なくとも部分的には、前記サービスの合意を表す情報と前記共有秘密キーとに基づいて生成されるユーザ署名のサービス合意の検証情報を受信する手段と、
    マスク関数によりマスクされたユーザ署名の検証情報を生成する手段と、
    前記サービス合意マネージャから、前記同じマスク関数の実例によりマスクされた、少なくとも部分的には、前記サービスの合意の情報と前記共有秘密キーとに基づいて生成された、期待される検証情報を受信する手段と、
    前記マスクされたユーザ署名の検証情報が前記マスクされた期待される検証情報に対応していることを検証し、前記サービスの合意のユーザによる受け入れを確認する手段とを有することを特徴とするサービスプロバイダ。
44. ユーザと、サービスプロバイダと、前記サービスプロバイダと信頼関係にあり、認証及びキー合致（ＡＫＡ）パラメータの相互生成のために前記ユーザと秘密キーを共有するネットワークオペレータとが関与するＡＫＡに基づくチャレンジ・レスポンスの改善された方法であって、
    前記改善は、前記ネットワークオペレータによって管理されるネットワークへのアクセスのための第１のセットのＡＫＡパラメータを入力として、前記第１のセットのＡＫＡパラメータの少なくとも一部の表現を用いた所定の関数により前記サービスプロバイダによるサービスへのアクセスのための第２のセットのＡＫＡパラメータから孤立させて、前記第２のセットのＡＫＡパラメータを生成することにより定められることを特徴とする方法。
45. 前記第１のセットのＡＫＡパラメータと前記第２のセットのＡＫＡパラメータとが、前記共有秘密キーと前記ネットワークオペレータ側で始めに生成されたチャレンジとに基づいて、前記ネットワークオペレータ側でも前記ユーザ側でも生成され、
    前記第２のセットのＡＫＡパラメータは前記ネットワークオペレータから前記サービスプロバイダに安全に転送されることを特徴とする請求項４４に記載の方法。
46. 前記サービスプロバイダは、入力として前記第２のセットのＡＫＡパラメータの少なくとも一部を用いて、前記所定の関数の実例により、再認証のために、ＡＫＡパラメータのさらなるセットを生成することを特徴とする請求項４５に記載の方法。
47. 前記所定の関数は擬似ランダム関数であることを特徴とする請求項４４に記載の方法。
    

Images