JP5027227B2 - 通信ネットワークにおける認証手順のための方法および装置 - Google Patents

Description

本発明は、加入者と信頼関係がある移動体オペレータおよび、重要なビジネスも、重要でないビジネスも行い、そして上記加入者へのサービスを活用するサービス・プロバイダを含む通信ネットワークにおける認証に関するものである。

ＩＥＴＦ公開鍵基盤ワーキンググループにより定義されている公開鍵基盤ＰＫＩ（Ｘ）標準http://www.ietf.org/html.charters/pkix-charter.htmlは、ディジタル証明書の発行から失効までのライフサイクルのための技術を定義している。いくつかの主体が、ＰＫＩ ＲＦＣ２５１０：インターネットＸ．５０９公開鍵基盤証明書管理プロトコル（Public Key Infrastructure Certificate Management Protocols）に定義されている。

・認証局（ＣＡ：Certify Authority）−ディジタル証明書を発行し、そして、ディジタル証明書の発行者欄に自身の名前を記載するエンティティ。

・登録局（ＲＡ：Registration Authority）−物理的な個人認証、トークン配布、失効情報報告、名称付与、鍵ペアのバックアップ等のような、支援タスクを取り扱いできる別のエンティティ。

周知のシステムでは、ＲＡおよびＣＡの役割は、ＰＫＩ管理の観点から簡単である同一の機関により行われる。たとえば、重要なビジネスを行うサービス・プロバイダＳＰ、たとえば、銀行は、両方の役割を有し、そして、ＲＡの役割では認証を行い、そして、ＣＡの役割では証明書を生成する。

周知のシステムでは、サービス・プロバイダＳＰは、書類の物理的な検証を含み、個人情報を用紙に記入し、そして場合によっては第三者の照会を要求する、対面による手順を使用して、エンドユーザを登録することによる（ブートストラップ（bootstraps））トラストを確立する。言い換えると、サービス・プロバイダＳＰは、登録局ＲＡの役割を果たすことを強いられる。登録手順に関連するコストは、大抵かなり高いが、しかし、他に実用的な解決策がないので避けることはできない。

一般に、ＲＡは、登録サービスを１つ以上のＣＡに提供する１つの異なる機関により運営されることができる。しかしながら、登録局ＲＡおよび認証局ＣＡというそのような分割を実装する方法に関する開示はない。

ＷＰＫＩは、銀行、オペレータおよび政府機関が関与するスウェーデンのプロジェクトである（ＷＰＫＩ．ＮＥＴ参照）。当該プロジェクトは、バンキング、２４番目の政府系オンライン・サービスへのアクセス、他との間での企業サービスで、使用できる安全確実な識別情報を定義し、そして仕様を定めているところである。ＷＰＫＩで重要な実現要因は、ＰＫＩ、安全な電話環境およびＳＷＩＭである。ウィルスにより容易に盗み取られた、ソフトによるＰＣベースの証明書に伴うこれまでの不備に起因している。

リバティ・アライアンスＬＡのプロジェクトは、インターネット・サービス・プロバイダ、移動体オペレータおよび金融機関にわたる１００以上の会社からの参加者があるビジネス主導のプロジェクトである。このプロジェクトの目的は、連合を構築できるようにするディジタル・エンティティ標準を定義することである。最も一般的なシナリオでは、１つの連合は、認証を集中化するアイデンティティ・プロバイダ（ＩｄＰ：Identity Provider）、および認証をＩｄＰに委任するいくつかのサービス・プロバイダ（ＳＰ：Service Provider）で構成される。

ＩｄＰの役割を果たす移動体ネットワークオペレータ（ＭＮＯ：Mobile Network Operator）の場合、これは、ＳＰにアクセスしたいユーザは、サービスが要求されるたびにオペレータに連絡して、＊ＳＩＭで認証し、そのときＳＰに提示される認証表明（authentication assertion）を取得する必要があるということである。リバティ・アライアンスにおけるこのモデルは、しかしながら、ユーザ／加入者がサービス・プロバイダＳＰとのアカウントを有することを要求し、ユーザ／加入者がオペレータの関与なしにＳＰとの信頼関係を個別に確立していることが必要である。これは、次善最適であり、そして使い易くはない。このように、リバティ・アライアンスのような連合モデルにおけるように集中化された委任認証は、上述の欠点があるので、すべてのサービス・プロバイダに対するすべての市場ニーズを満たすとは限らない。

３ＧＰＰ標準で定義されている汎用ブートストラッピング・アーキテクチャ（ＧＢＡ：Generic Bootstrapping Architecture）は、移動体ネットワークオペレータが認証及び暗号鍵配送方式（ＡＫＡ：Authentication and Key Agreement）手順中にユーザと調整し終えている共有鍵を使用して、アプリケーションがユーザを認証できるようにするメカニズムを提供する。ＧＢＡは、また、サービス・プロバイダが他のアプリケーションによって使用されるべき証明書を発行するＣＡである場合を想定している。リバティの場合におけるように、ＧＢＡは、ＳＰとの独立した信頼関係を必要とする。ＳＰは、ＭＮＯが独自に鍵生成器の機能を果たすので、加入者を依然として認証しなければならず、そして、このように認証表明は生成されない。一方、適切な鍵を生成するためにＭＮＯにより実行される認証は、ＡＫＡに限定される。

先行技術のシステムでは、厳格な認証の概念が使用されている。脆弱な認証方法、たとえば、使い易いパスワードが広く使用されているために、インターネット・サービスのユーザは、ハッキング、個人情報の盗難、なりすまし攻撃およびプライバシーの喪失のような増え続ける不正行為の標的になってきている。より厳格な認証方法の必要性が、様々な状況に対して時間とともに増大している。厳格な認証は、ソフトウェア・アプリケーションまたはネットワークにアクセスする場合、ユーザアイデンティティ（識別情報）を確認するために様々な認証メカニズムを組み合わせる厳しいレベルのセキュリティ（安全性）を暗に意味する。厳格な認証は、複数のビジネス・パートナーが安全に機密情報を共有可能な信頼できるネットワークの基盤的な要素に相当する。

本発明の目的は、サービス・プロバイダＳＰが、登録およびセキュリティブートストラッピング、認証の手順を、移動体オペレータに委任できるようにする方法および装置を提供することである。

この目的および他の目的は、添付の請求項によって定義されるように、本発明により満たされる。

本発明は、加入者の端末、オペレータノードおよびサービス・プロバイダ・ノードを含む通信システムにおける認証方法に関するものでる。この認証方法は、オペレータとサービス・プロバイダとの間のＳＬＡアグリーメント（合意）に基づいている。この方法は、以下のステップを含んでいる。加入者の端末は、登録局ＲＡとして機能するオペレータノードと厳密な認証を実行する。次に、オペレータノードは、厳密な移動体認証表明ＭＳＡＡを生成する。このＭＳＡＡは、サービス・プロバイダ・ノードに送信される。最後に、基本的な考えで、このＭＳＡＡは、サービス・プロバイダＳＰによって検証される。

第１の実施形態（証明書の実施形態）に従って、以下のステップが、厳密な表明ステップの実行に先立って実行される。サービス要求が、端末からサービス・プロバイダ・ノードに送信される。この要求には、オペレータがサービス・プロバイダとのＳＬＡアグリーメント（合意）を有していることをチェックすることができるようにするための、オペレータノードアイデンティティを含んでいる。ＳＬＡアグリーメント（合意）が存在する場合、サービス・プロバイダ・ノードアイデンティティが、端末に送信され、それによって、厳密な認証に対する要求が、端末からオペレータノードに送信されることになる。

ＭＳＡＡが有効である場合、本発明に従う認証方法は、更に、サービス・プロバイダ・ノード内で加入者を登録するステップ、およびサービス・プロバイダ・ノードから加入者の端末にサービスを配信するステップを含んでいる。

証明書の実施形態に従う認証方法は、登録ステップの後に、ユーザ証明書をサービス・プロバイダ・ノード内で生成するステップが続くということをさらに含み、ここで、ユーザ証明書は端末に送信され、そして、端末に記憶されることになる。

本発明の第２の実施形態（証明書の実施形態）に従って、以下のステップが、厳密な表明の実行ステップに先立って実行される。そのステップとは、サービスに対して加入するための提案をオペレータノードから端末に送信するステップと、応答として受諾情報を返信するステップがある。

本発明は、さらに、オペレータノードＯＰおよびサービス・プロバイダ・ノードＳＰと信頼関係を有する加入者を有する通信システムのオペレータノードＯＰにおける認証方法に関するものである。この認証方法は、オペレータノードＯＰとサービス・プロバイダＳＰとの間のＳＬＡアグリーメント（合意）に基づいている。オペレータノードは、サービス・プロバイダ・ノードアイデンティティを含む認証に対する要求を受信する。受信されたサービス・プロバイダ・ノードに対し、どのような認証コンテキストが使用されるかのチェックが実行される。この認証は、認証コンテキストに従って実行される。認証が実行された後、厳密な移動体認証表明ＭＳＡＡが生成され、そして、サービス・プロバイダ・ノードに送信され、それによって、オペレータノードは、サービス・プロバイダに対する登録局の役割を果たすことになる。

オペレータノードＯＰ（５２）内の装置は、オペレータノードにおける認証方法に対応しており、この装置は、サービス要求に対してどのような認証コンテキストが使用されるべきかをチェックするためのＳＬＡデータベースを含んでいる。当該装置内には、認証コンテキストに従って認証を実行するための認証部および、ＭＳＡＡを生成し、そしてＭＳＡＡをサービス・プロバイダ・ノードに送信するためのＭＳＡＡ生成器を含み、それによって、オペレータノードは、サービス・プロバイダ（ＳＰ）に対する登録局（ＲＡ）の役割を果たす。

請求項において、加入者の端末およびオペレータノードを含む通信システム内のサービス・プロバイダ・ノードにおける認証方法が、さらに定義されている。オペレータとのＳＬＡアグリーメント（合意）に基づいている方法は、以下のステップを含んでいる。端末からのサービス要求は、サービス・プロバイダ・ノードで受信される。当該要求は、オペレータノード識別情報ＯＰ Ｉｄを含む。それから、オペレータノードアイデンティティが、サービス・プロバイダＳＰとのアグリーメント（合意）を有しているオペレータに関するものであるということが、サービス・プロバイダ・ノード内でチェックされることになる。アグリーメント（合意）が存在する場合、サービス・プロバイダに関する情報が端末に送信され、そして、オペレータによって生成されたＭＳＡＡがサービス・プロバイダ・ノードで受信される。ここで、サービス・プロバイダ・ノードは、受信したＭＳＡＡを検証する。その結果、ユーザは登録されることになり、そして、サービスが端末に配信される。

第１の実施形態では、サービスは証明書であり、そして、第２の実施形態では、サービスは加入である。

さらにサービス・プロバイダ・ノード装置が、特許請求されており、そして、ＳＰノード装置は、受信した厳密な移動体認証表明を検証するための検証部、ＭＳＡＡの検証時に加入者を登録するための登録部を含み、これによって、加入者の認証がオペレータに委任されることになり、そして、検証がサービス・プロバイダ・ノード内で実行される。

本発明の主たる長所は、サービス・プロバイダが認証を実行する負担を、サービス・プロバイダＳＰの顧客と既に信頼関係を有している信頼できる相手に委任できることである。これは、オペレータは、大抵、サービス・プロバイダが有しうるものよりも加入者とより緊密な関係を有しているで、ビジネスの観点から、認証を実行する非常に効率のよい方法である。

更なる長所は、サービス・プロバイダによって使用できる新しい証明書を発行するために、オンラインでのトラスト・ブートストラッピング（trust bootstrapping）に対して、移動体オペレータによって実行される厳密な認証をＳＰによって再使用できることである。

第２の更なる長所は、本発明に従う方法および装置が、また、他のタスクに使用できることである。オペレータは、新しい登録を得るための新しい仲介としてサービス・プロバイダによって使用できる。

本発明は、これからより詳細に、それの典型的な実施形態を参照して、そしてまた添付の図面を参照して説明することとする。

本発明の証明書の実施形態において相互に作用するノードのブロック図である。 本発明の証明書の実施形態に関する第１の代替における信号を説明するシーケンス図である。 本発明の証明書の実施形態に関する第２の代替における信号を説明するシーケンス図である。 本発明のサービスの実施形態において相互に作用するノードのブロック図である。 本発明のサービスの実施形態における信号を示すシーケンス図である。 図１のＳＬＡデータベース６１ａの詳細図である。 図１のＳＬＡ／オペレータデータベース５５ａの詳細図である。 図３のＳＬＡデータベース６１ｂの詳細図である。 図３のＳＬＡ／オペレータデータベース５５ｂの詳細図である。

通信システムにおいて、いくつかの関係者がコンテンツプロバイダから移動体加入者にサービスを配信する場合に関与している。本発明に従うシステムに関与する関係者は、以下のとおりである。第１の部分は、オペレータＯＰまたはより具体的には少なくとも１つの端末を有する接続加入者を擁する移動体ネットワークオペレータＭＮＯである。第２の部分は、厳密なセキュリティ要件を有するサービス・プロバイダ、たとえば、銀行、金融機関または政府機関であり、そして第３の部分は、移動体加入者であり、これは、サービス・プロバイダによって提供されるサービスを使用することに関心がある。本発明の１つの長所は、サービス・プロバイダとのアカウントを有しない加入者が、サービス・プロバイダからサービスをとにかく受信できることである。これは、移動体オペレータがサービス・プロバイダに対して登録局ＲＡである役割をどのように引き受けるかを教示する、本発明を利用することにより可能である。これは、サービス・プロバイダが最初の認証および登録を行う先行技術に従って認証を扱うのではなく、移動体オペレータが認証を行っている方法で実現される。

本発明の様々な実施形態を、より詳細に図面を参照して説明する。

図１は、本発明システムの証明書の実施形態に関する基本部分を有する電気通信ネットワークおよび各部分がどのように相互に作用するかについて説明している。基本部分には、移動端末ＭＴ５１、オペレータノードＯＰ（ＲＡ）５２およびサービス・プロバイダ・ノードＳＰ（ＣＡ）５３を含み、これらは、すべてが電気通信ネットワーク内で互いに通信できる。

本発明を明確に理解するために、図２ａおよび図２ｂが、図１にある装置の説明と併せて説明されている。図２ａおよび図２ｂでは、加入者５０が最初に自身の身分証明書（アイデンティティカード）、運転免許証または同等物を提示することによって、ホームのオペレータとの物理的身元証明を行うことが点線を使用して開示されている。この身元証明は、オペレータＯＰとサービス・プロバイダＳＰとの間でのサービス・レベル協定ＳＬＡの一部となるものであるので、本発明が実装されるための必須条件である。この身元証明は、このようにサービス・プロバイダが登録局をオペレータに委任するための基礎となっている。本発明のさらなる必須条件は、オペレータＯＰおよびサービス・プロバイダＳＰが、サービス・プロバイダによって要求される認証コンテキストを含むサービス・レベルアグリーメント（協定）ＳＬＡ（Service Level Agreement）を有することである。ＳＬＡ合意には、また、サービス・プロバイダからのサービスについてのさらなる情報、たとえば、移動体オペレータによって行われる認証に対する継続時間を含むことができる。

図２ａおよび図２ｂにおけるシーケンス図の第１ステップで、サービス要求１が端末５１からサービス・プロバイダ・ノード５３に送信される。このサービス要求は、証明書要求で例示される第１の実施形態内にある。このサービス要求には、加入者のホームオペレータに対するオペレータノードアイデンティティ（識別情報）ＯＰ Ｉｄを含んでいる。図１では、このサービス要求１は、また、端末５１からサービス・プロバイダ・ノード５３内のＩＮ部への矢印で開示されている。シーケンス図の次のステップ２は、サービス・プロバイダＳＰとオペレータＯＰとの間にサービス・レベルアグリーメント（協定）ＳＬＡがあることを、サービス・プロバイダ・ノード５３でチェックすることである。これは、図１において、ＩＮ部からＳＬＡ／オペレータデータベース５５ａへの矢印２ａおよび２ｂで開示されている。ここで、ＳＬＡ／オペレータデータベース５５ａは、すべてのＳＬＡ合意に関する情報を含み、また、サービス・プロバイダが様々なオペレータに対して選択する状況では、オプションとして、また相当する認証コンテキストを含んでいる。チェック２が行われる場合、オペレータアイデンティティ（識別情報）ＯＰ Ｉｄがデータベース５５ａ内で検索され、そして、整合するＳＬＡアイデンティティ（識別情報）を有することがチェックされる。ＳＬＡ／オペレータデータベース５５ａは、図５ｂにおいて詳細に示されている。ＳＬＡ／オペレータデータベース５５ａは、移動体オペレータのオペレータアイデンティティ（識別情報）（オペレータＡ、オペレータＢおよびオペレータＣ）およびＳＬＡ合意（１、２、３）のアイデンティティ（識別情報）、そして、オプションとして、合意に従う認証コンテキスト（ｘｘｘｘ）を含んでいる。

チェックステップ２が合意があることを意味する肯定的応答をもたらすと、その場合、ステップ３で、サービス・プロバイダアイデンティティ（識別情報）ＳＰ Ｉｄがサービス・プロバイダ・ノード５３から端末５１に送信されている。このステップ３は、また、図１に示されている。受信したＳＰ Ｉｄは、今度は、ホームの移動体オペレータとの厳密な認証を開始するために加入者の移動端末５１により使用されることができ、この例では、ホームの移動体オペレータは参照番号５２で示されている。端末５１から厳密な認証の要求４がホームのオペレータノード５２に送信される。要求４には、いずれの認証コンテキストが使用されるべきかをステップ１０４ａで判定する場合に、オペレータＯＰによって使用できるサービス・プロバイダ・ノードアイデンティティ ＳＰ Ｉｄについての情報を含んでいる。

厳密な認証に対する要求４は、また、図１において矢印で開示されている。図１では、要求４は、オペレータノード５２の認証部６０に送信されるということが開示されている。認証部６０は、最初に、接続されているＳＬＡデータベース６１ａ（図５ａに詳細に示されている）から、いずれの認証コンテキストが、要求４で受信されたサービス・プロバイダ・ノードアイデンティティ ＳＰ Ｉｄに対して適用できるかを判定する（ステップ１０４ａ）。図５ａにおける例に従って、認証コンテキストは、この例では、ＳＰ５３となりうる第１のサービス・プロバイダＳＰ １に対してｘｘｘｘである。認証部６０は、図におけるステップ５で、判定されたｘｘｘｘの認証コンテキストに従って認証を実行する。これは、また、本発明に従って、オペレータＯＰが、先行技術のシステムではその役割をサービス・プロバイダが行っている登録局（ＲＡ）の役割を引き受けるというように表現できる。しかしながら、この認証は、認証が厳密であることを要求するサービス・プロバイダによって信用されなければならない。そのような厳密な認証は、本発明に従って、移動体オペレータにより実行されることができる。

ステップ５における厳密な認証の実行は、たとえば、認証部６０によって次のようになされる。この厳密な認証は、少なくとも３回の認証を実行することになる。これらは、たとえば、１つの例では、次の順１、２、３で行われ、そして以下で説明されるｘｘｘｘであることができる。

１．）ＰＩＮコード認証。これは既に正常に機能しているので、このＰＩＮコードは、加入者に自身の端末にアクセスすることを許可する。

２．）ＳＩＭに基づく認証。加入者５０のユーザは、オペレータのネットワークにおけるＳＩＭと認証センタの両方に含まれるセキュリティデータに従って、身元確認される。

３．）ＰＫＩに基づく認証。オペレータは、この加入者に対する局所的な認証局の役割を果たしている。このケースでは、ＳＩＭ（ＳＷＩＭ）はすでに、オペレータＯＰによって発行される鍵ペアおよび証明書を含んでいる。

他のメカニズムもまた、特に、ＰＫＩ認証の代わりに、（たとえば）生体認証も可能である。

すべてのこれらのメカニズム、および他の信用証明物および／またはオペレータが承知している識別子に基づいて、オペレータノード５２は、ユーザが確かに自称する本人であるということを証明する厳密な移動体認証表明（ＭＳＡＡ：Mobile Strong Authentication Assertion）を、ＭＳＡＡ生成器６２において生成することになる。この表明ＭＳＡＡには、少なくとも、実行され終えている認証の種類および表明の継続時間に関する情報を含んでいる。この表明には、認証がどのように、だれにより、いつ行われたか、そしてどのぐらいの期間有効であるかに関する情報を含むだけである。ＰＫＩが厳密な認証の一部として使用される場合、公開鍵はまた搬送されることができる。他の情報が、別に他の種類の表明を使用して提供される。

次のステップ８、８ａ、８ｂ、８ｃおよび８ｄでは、生成されたＭＳＡＡがサービス・プロバイダ・ノード５３に送信されている。ＭＳＡＡを送信する代替的な方法が２つ存在する。第１の代替的な方法は、端末経由で、ステップ８ａ、８ｂ、８ｃおよび８ｄとして図２ａに開示されており、そして第２の代替的な方法は、サービス・プロバイダ・ノード５３に直に、ステップ８として図２ｂおよび図１に開示されている。第１の代替的な方法では、ステップ８ａで、ＭＳＡＡ識別子ＭＳＡＡ Ｉｄがオペレータノード５２から端末５１に送信される。次のステップ８ｂで、同一のＭＳＡＡ Ｉｄが端末からサービス・プロバイダ・ノード５３に送信される。更なるステップ８ｃで、サービス・プロバイダ・ノードが識別子ＭＳＡＡ Ｉｄを含むメッセージＧｅｔ ＭＳＡＡを送信し、そして、それから最後の送信ステップ８ｄが続いて、ＭＳＡＡ自体がオペレータノード５２からサービス・プロバイダ・ノード５３に送信される。サービス・プロバイダ・ノード５３においてＭＳＡＡを受信すると、厳密な移動体認証表明ＭＳＡＡが、図２ａのステップ９で、検証を行うために検証部５６によって使用される。検証部５６は、図１に開示されている。検証が、適用できる認証コンテキストと関連があるセキュリティ期待を満足すると、その場合、サービス・プロバイダ・ノード５３は、当該加入者５０が確かに自称する本人であるという保証を得る。強調されるべきことは、この検証が上述のように、加入者５０に対するサービス・プロバイダＳＰとのアカウント無しに行われるということである。その代わりに、ＭＳＡＡ表明が、アカウントを開設し、そして、ユーザを登録するためにサービス・プロバイダによって使用されている。オペレータＯＰが認証を行い、そして、それからＭＳＡＡが検証されるサービス・プロバイダに、そのＭＳＡＡを送信する本発明の上述の手順の結果、サービス・プロバイダは十分な確信を持って認証手順をＳＬＡアグリーメント（合意）に従ってオペレータに委任できる。この委任は、サービス・プロバイダにはリソースの節約になるので非常に効率がよく、そして、委任がオペレータには新しい重要なタスクを作成する。サービス・プロバイダに代わって認証を実行するというオペレータのこの新しい機能は、オペレータに対してビジネスを生む可能性がある。

図２ａおよび図２ｂにおける検証ステップ９の後に、加入者５０がサービス・プロバイダ・ノード５３に登録される１つのステップ１０ａがある。図２ａおよび図２ｂに開示されている証明書の実施形態では、登録に続いて、ステップ１１で端末５１に送信／配信され、ＳＩＭカード１２に記憶されるユーザ証明書の生成を備える第２のステップ１０ｂがある。図１では、ユーザ証明書は、検証部５６からのメッセージ９ａを受けて登録および証明書部５７において生成される。図１のステップ１１は、生成された証明書が端末５１に送信されることを開示しており、この証明書は端末のＳＩＭカードに記憶される。

この時以降、加入者がサービス・プロバイダ・ノード５３からのサービスにアクセスしたい場合、加入者はサービス・プロバイダ・ノード５３に証明書を提示する。これが、図２ａおよび図２ｂにおけるステップ１３である。図１では、サービスノード５８が開示されており、そして、ステップ１３で、サービスがアクセスされる場合、コンタクトが取られるのはサービスノード５８であり、そして、証明書がサービスノードに開示される。このことは、先行技術に従っており、そして本明細書ではさらには開示しない。

鍵ペアがオペレータノード５２によって事前に生成されていて、そして、ＳＩＭカードに含まれている場合、ユーザは、サービス・プロバイダ・ノード５３に提示される情報にディジタル署名をすることができるようになる。ユーザの鍵ペアは、永続的とすることができる。この鍵ペアがオペレータにより事前に生成される場合、この公開鍵は、ＭＳＡＡの一部としてサービス・プロバイダに送信されるべきである。

証明書の実施形態で説明したように、重要なビジネスに係わらないいくつかのサービス・プロバイダは、サービス・プロバイダのユーザとの高い信頼モデルを依然として要求することになる。このサービス・モデルでは、また、エンド・ツー・エンドのセキュリティが要求される。サービスの実施形態を、図３および図４に関連して説明する。たとえば、サービス・プロバイダは、インターネット・マガジンに対する加入を提供する会社であることができ、そして、そのサービスはマガジンの配信である。

このサービスの実施形態で、必須条件は証明書の実施形態の必須条件と同一である。端末を有する加入者は、オペレータの加入者であり、そして、オペレータで物理的な身元証明を行っている。サービス・プロバイダとオペレータとの間に、ＳＬＡアグリーメント（合意）があることもまた、必須条件である。

サービス・プロバイダは、上記の例に従ってユーザの加入を要求する、判定されたサービスを提案する。サービス・プロバイダは、そのような登録を作成するために必要な身元証明および認証処理の負担をオペレータに進んで委任する。同時に、オペレータにこれらのサービスをオペレータの加入者に提案させることもまた可能である。

図３および図４に従って、オペレータノード５２が「宣伝」または「加入の提案」を、ステップ１０３で、提案送出部７０から端末５１に送信するサービスの実施形態を説明する。ステップ１０３におけるこの情報は、たとえば、ショート・メッセージ・サービスＳＭＳまたはマルチメディア・メッセージ・サービスＭＭＳを使用することによって送信されることができる。この場合、サービスである加入は、このようにサービス・プロバイダ・ノード５３からの加入である。オペレータＯＰの加入者５０が受諾応答を、ＳＭＳまたはＭＭＳ経由で、ステップ１０４においてオペレータノード５２に返信する。

サービス・プロバイダ・ノード５３において加入を作成するために、ユーザは、自身の移動体オペレータとの厳密な認証を実行するように要求されることになる。この厳密な認証は、図３および図５ｃにあるＳＬＡデータベース６１ｂ内の認証コンテキストに従って行われる。データベース６１ｂは、様々なサービス・プロバイダ（ＳＰ４、ＳＰ５、ＳＰ６）に対する認証コンテキストおよび様々なサービス・プロバイダの提案サービスについての情報を有する。ＳＬＡデータベース６１ｂは、図５ｃにおける個々の図面で説明されている。どの認証コンテキストを使用すべきかは、図３および図４で示されているステップ１０４ａで、ＳＬＡデータベース６１ｂを用いてチェックされる。認証コンテキストは、提案サービスの種類およびどの程度厳密な認証であるべきかに依存することになる。この例におけるように重要でない大抵の場合、上述のステップ１およびステップ２における認証コンテキスト、すなわち、ＰＩＮコード認証およびＳＩＭに基づく認証で十分間に合うであろう。オペレータが承知しているすべてのこれらのメカニズムおよび他の信用証明物および／または識別子に基づいて、オペレータノード５２は、ユーザが確かに自称する本人であるということを証明するために、厳密な移動体認証表明ＭＳＡＡを生成できることになる。ＭＳＡＡの生成は、図４においてステップ６で示されている。この表明には、実行されている認証の種類およびそのような表明が有効である継続時間についての情報を、少なくとも含むべきである。このように、この表明は、サービス・プロバイダＳＰがユーザに対してアカウントを開設するために利用できる純粋な認証表明である。そして、このアカウントを開設することは、ユーザを登録することと同等である。登録後、サービスを配信できる。

ＭＳＡＡは、サービス・プロバイダ・ノード５３に送信されることになる。このことは、ステップ８を備える図３および図４に示されている。しかしながら、このサービスの実施形態ではまた、図２ａの証明書の実施形態に関連して説明されるように、端末経由でＭＳＡＡを送信することも可能である。ＭＳＡＡを受信すると、サービス・プロバイダ・ノード５３の検証部５６が検証の実行を開始し、このことは図４におけるステップ９で示されている。この検証は、提案サービスおよび適用できる認証コンテキスト、たとえば、提案サービスが加入Ａである場合はオペレータＡに対するｑｑｑｑ、に関する情報を有するＳＬＡ／オペレータデータベース５５ｂに記憶されている情報に従って実行される。データベース５５ｂは、さらに、図５ｄにおける図面に説明されている。

検証が終了し、そして、検証がＯＫである場合、それからユーザは登録され、このことが図４におけるステップ２０で示されている。この登録は、図３で開示されているサービス・プロバイダ・ノード５３の登録部７２で行われる。

この時以降、ユーザはサービス・プロバイダとの加入を有し、そして、このように加入したサービスを使用して開始することができる。移動体オペレータは、サービスの使用中は他のいかなるセキュリティ上の働きもしないことになる。さらに、サービス・プロバイダは、自身の加入者に向けたサービスの通知（ステップ１０３）のために移動体オペレータを利用できる。

図４におけるステップ２０での登録後、サービスが、図３で開示されているサービス・プロバイダ・ノード５３にある、図３のサービス部７３から、ステップ２１で配信される。このサービスは、図３および図４で開示されている端末５１に配信される。ステップ２０の登録は、登録が終了し、そしてサービスが配信できるということを示す情報２０ａを送信するためのサービス部７３に接続されている登録部７２で行われる。提供されるサービスの種類に依存して、サービス・プロバイダは、ユーザがサービスにアクセスするために様々なエンド・ツー・エンドのセキュリティメカニズムを使用することになる。しかしながら、これらのセキュリティメカニズムは、先行技術のメカニズムに従っており、そして、本発明の一部ではなく、そしてそれ故、詳細には説明しない。

このサービスの本発明による実施形態は、セキュリティの責務を移動体オペレータに委任する目的でサービス・プロバイダによって効果的に使用されることができ、そして、同時に、サービス・プロバイダは新しい登録を取得すること、および身元証明処理を委任することのようないくつかの利点を得る。オペレータ役割の成功は、厳密な認証メカニズムを提供することに基づくであろうし、そして、それ故、オペレータはサービス・プロバイダにセキュリティパートナーとして認識される。

Claims (14)

1. 加入者の端末、オペレータノードおよびサービス・プロバイダ・ノードを含む通信システムにおいて、オペレータとサービス・プロバイダ間のＳＬＡアグリーメントに基づく認証方法であって、
   前記オペレータノードのアイデンティティを含むサービス要求を前記端末から前記サービス・プロバイダ・ノードに送信するステップと、
   前記サービス・プロバイダ・ノードにおいて、前記オペレータノードのアイデンティティが、前記サービス・プロバイダとのＳＬＡアグリーメントを有するオペレータに関連するかどうかをチェックするステップと、
   ＳＬＡアグリーメントが存在する場合、前記サービス・プロバイダ・ノードのアイデンティティを前記端末に送信するステップと、
   前記サービス・プロバイダ・ノードのアイデンティティを含む、厳密な認証に対する要求を、前記オペレータノードに送信するステップと、
   前記端末が、登録局として機能する前記オペレータノードと厳密な認証を実行するステップと、
   前記オペレータノードが、厳密な移動体認証表明ＭＳＡＡを生成するステップと、
   前記生成された移動体認証表明ＭＳＡＡを、前記サービス・プロバイダ・ノードに送信するステップと、
   前記サービス・プロバイダにおいて、前記移動体認証表明ＭＳＡＡを検証するステップと
   を備えることを特徴とする方法。
2. 前記実行するステップに先立って、
   サービスに対する加入の提案を、前記オペレータノードから前記端末へ送信するステップと、
   前記提案に対する受諾情報を、前記端末から前記オペレータノードへ送信するステップと
   を更に備えることを特徴とする請求項１に記載の認証方法。
3. 前記サービス・プロバイダ・ノードへの前記生成された移動体認証表明ＭＳＡＡの送信は、前記端末を介して実行される
   ことを特徴とする請求項１に記載の認証方法。
4. 前記厳密な認証は、前記サービス・プロバイダとの前記ＳＬＡアグリーメントに従う認証コンテキストに従って、実行される
   ことを特徴とする請求項１に記載の認証方法。
5. 前記移動体認証表明ＭＳＡＡが有効である場合、
   前記サービス・プロバイダ・ノードにおいて、前記加入者を登録するステップと、
   前記サービスを、前記サービス・プロバイダ・ノードから前記加入者の端末へ配信するステップと
   を更に備えることを特徴とする請求項１に記載の認証方法。
6. 前記登録するステップに先立って、
   前記サービス・プロバイダ・ノードにおいて、前記端末に送信され、かつ該端末に記憶される、ユーザ証明書を生成するステップを更に備える
   ことを特徴とする請求項５に記載の認証方法。
7. オペレータノードおよびサービス・プロバイダ・ノードとの信頼関係を有する加入者を含む通信システム内にある、前記オペレータノードにおける、前記オペレータと前記サービス・プロバイダとの間のＳＬＡアグリーメントに基づく認証方法であって、
   前記サービス・プロバイダ・ノードのアイデンティティを含む、認証要求を受信するステップと、
   どの認証コンテキストが、受信されたサービス・プロバイダ・ノードのアイデンティティに対して使用されるかをチェックするステップと、
   前記受信されたサービス・プロバイダ・ノードのアイデンティティに対する前記認証コンテキストに従って、認証を実行するステップと、
   厳密な移動体認証表明ＭＳＡＡを生成するステップと、
   前記生成した移動体認証表明ＭＳＡＡを前記サービス・プロバイダ・ノードに送信し、それによって、オペレータノードが、前記サービス・プロバイダに対する登録局の役割を果たすようにするステップと
   を備えることを特徴とする認証方法。
8. オペレータノードと、該オペレータノードとのＳＬＡアグリーメントを有するサービス・プロバイダ・ノードとの信頼関係を有する加入者を含む、通信システム内のオペレータノードにおける装置であって、
   サービス要求に対してどの認証コンテキストが使用されるべきかをチェックするためのＳＬＡデータベースと、
   前記認証コンテキストに従って認証を実行するための認証部と、
   厳密な移動体認証表明ＭＳＡＡを生成し、そして、前記厳密な移動体認証表明ＭＳＡＡを前記サービス・プロバイダノードに送信するためのＭＳＡＡ生成器とを備え、
   それによって、前記オペレータノードが、前記サービス・プロバイダに対する登録局としての役割を果たす
   ことを特徴とする装置。
9. 前記ＳＬＡデータベースは、特定のサービス・プロバイダのアイデンティティに対して使用されるべき前記認証コンテキストについての情報を含んでいる
   ことを特徴とする請求項８に記載の装置。
10. 加入者の端末およびオペレータノードを含む通信システム内のサービス・プロバイダ・ノードにおける、前記オペレータノードとのＳＬＡアグリーメントに基づく認証方法であって、
    前記端末から、前記オペレータノードのアイデンティティを含むサービスの要求を受信するステップと、
    前記サービス・プロバイダ・ノードにおいて、前記オペレータノードのアイデンティティが前記サービス・プロバイダとのアグリーメントを有するオペレータに関連するかどうかをチェックするステップと、
    アグリーメントが存在する場合、
    前記サービス・プロバイダに関する情報を前記端末に送信するステップと、
    前記オペレータによって生成される厳密な移動体認証表明ＭＳＡＡを受信するステップと、
    受信した前記移動体認証表明ＭＳＡＡを検証するステップと
    前記加入者を登録するステップと、
    前記サービスを前記端末へ配信するステップと
    を備えることを特徴とする認証方法。
11. 前記サービスは、証明書であり、前記加入者の登録は、前記端末へ配信されるユーザ証明書の生成に続いてなされる
    ことを特徴とする請求項１０に記載の認証方法。
12. 前記サービスは、加入である
    ことを特徴とする請求項１０に記載の認証方法。
13. オペレータとの信頼関係を有する加入者を含む通信システム内の、前記オペレータとのＳＬＡアグリーメントを有するサービス・プロバイダ・ノードであって、
    受信した厳密な移動体認証表明の検証用の検証部と、
    前記厳密な移動体認証表明の検証における前記加入者を登録するための登録部とを備え、
    これによって、前記サービス・プロバイダは、前記加入者の認証のために、前記オペレータを利用する
    ことを特徴とするサービス・プロバイダ・ノード。
14. 前記検証部は、適用可能なＳＬＡアグリーメントに対する認証コンテキストを判定するためのＳＬＡ／オペレータデータベースを含んでいる
    ことを特徴とする請求項１３に記載のサービス・プロバイダ・ノード。

Images