JP6033291B2 - サービスアクセス認証方法およびシステム - Google Patents

Description

本発明は、サービスへのアクセスを認証するシステムおよび対応する方法に関する。

多くの通信ネットワークは、加入者が通信ネットワークにアクセスするのを制御および許可する機能を備えている。通常、そのようなアクセスは、加入者デバイスを認証するために、加入者の認証情報（クレデンシャル）を検証して加入者デバイスに許可される。例えば、移動通信ネットワークシステムの様な多くの通信システムへのアクセスは、その通信ネットワークを利用する通信サービスの加入者に限定されている。

ＧＳＭ（登録商標）／ＣＤＭＡシステムおよび類似の移動通信システムに関しては、移動通信交換局（ＭＳＣ）が主要なサービス配信ノードであり、音声呼およびＳＭＳに加えて（電話会議、ＦＡＸ、および回線交換データなどの）他のサービスについても、ルーティングを担当している。ＭＳＣは、端末間接続を設定および解除し、通信中にモビリティおよびハンドオーバの要件を扱い、料金および即時プリペイド取引監視の処理をする。

ＧＳＭシステムにおける他の重要なエンティティは、ＭＳＣに接続されているホームロケーションレジスタ（ＨＬＲ）および認証センタ（ＡｕＣ）である。無線ネットワークにおいては、ＨＬＲは、アカウント番号、特徴、優先度、許可などのユーザ情報を格納する中心の場所である。ホームロケーションレジスタ（ＨＬＲ）は、移動ネットワークの加入者を管理及び調査するために必要な機能を有するエンティティとして、ＧＳＭに導入された。ビジタロケーションレジスタ（ＶＬＲ）および移動通信交換局（ＭＳＣ）とともに、ＨＬＲは、加入者に、ホームネットワーク内で呼の発信および受信をすることと、使い慣れた所望のサービスへのアクセスを依然として維持しながら、他のネットワーク内を移動（ローミング）することとができるようにする。

ＧＳＭシステムがＵＭＴＳ（３Ｇ）システムに進化し、最近はＬＴＥシステムにさえ進化しているが、ＨＬＲは、その役割を維持している。ＡＭＰＳ、ＤＡＭＰＳ、ＣＤＭＡなどのような他の移動ネットワークシステムも、同様のネットワークエンティティを有している。

移動ネットワークにおける別の重要な機能は、認証センタ（ＡｕＣ）である。ＡｕＣは、ＨＬＲに接続され、各ＳＩＭカードを認証する機能を提供する。このＳＩＭカードを用いて、移動電話機は、（通常、電話機の電源が入れられたとき、および／または電話をかけるとき）ＧＳＭコアネットワークに接続を試みる。認証にいったん成功すると、ＳＩＭおよび上述のサービスを管理するために、ＨＬＲが使用される。また、暗号鍵も生成され、この暗号鍵は、移動電話機とＧＳＭコアネットワークとの無線通信（音声、ＳＭＳ等）を保護（暗号化）するために使用される。

ＡｕＣは、ＡｕＣ内に存在する加入者データと、加入者のＳＩＭカード（ＵＭＴＳおよびＬＴＥの場合、ＵＳＩＭカードと呼ばれる）に存在するデータとを使用して、ネットワークがその加入者を認証することができる認証メカニズムを提供する。さらに、ＡｕＣとＳＩＭカードは、認証手順中に使用する認証アルゴリズムおよびそのパラメータの知識を共有する。本明細書に関しては、（例えば加入者識別子などを含む）加入者データおよび認証アルゴリズム／パラメータを、加入者の認証情報（クレデンシャル）と呼ぶ。

この仕組みは、移動ネットワークにおいてネットワークアクセス制御を実施する安全なやり方を与えると長年にわたって証明されており、ＩＭＳなどのサービスにセキュリティを提供するようにさえ拡張されている。ＩＭＳの主要コンポーネントは、ホーム加入者サーバ（ＨＳＳ）であり、このホーム加入者サーバ（ＨＳＳ）は、ＨＬＲの進化形と見なしてもよく、はるかに広い範囲の機能を提供し、全ての加入者およびサービス固有の情報の主貯蔵庫としての役割を果たすようになされている。ホーム加入者サーバ（ＨＳＳ）は、ＧＳＭネットワークのＨＬＲ／ＡｕＣ（認証センタ）の両方の機能を兼ね備え、ＩＭＳネットワークが特に必要としている情報も提供する。また、ＳＩＭベースの認証は、例えば、ＡｕＣ機能がいわゆるＡＡＡサーバ（認証、認可、課金）によって提供される無線ＬＡＮなどの、他のアクセス技術においても使用されてもよい。

しかし、上記の仕組みには、大規模ソリューションプロバイダが特定のサービス用の消費者向けデバイスを売り出すのを難しくする、物流とのある種の関係がある。主な問題は、加入者の認証情報がＡｕＣとデバイスの両方に供給されなければならないことである。実際面では、加入者の認証情報のデバイスへの供給の問題は、加入者に事業者からＳＩＭカードを取得させて、そのカードをデバイスに挿入させることによって解決される。加入者は、事業者を変更したいとき、別の事業者からＳＩＭカードを取得して、最初のＳＩＭカードを取り去り、新しいＳＩＭカードで置き換える。これは、個別の加入者に対しては、うまく機能する方式であることが分かっている。しかし、（遠隔）検針デバイスのようなマシン対マシン（Ｍ２Ｍ）向けの移動ネットワーク技術の使用が増加するに連れて、ＳＩＭカードのデバイスへの供給と、融通性の高い事業者の最初の選択および変更をサポートすることができるやり方とに起因して、上記の仕組みは多くの欠点を有する。

ユーザが自分で直接修正できるパーソナルホームロケーションレジスタにアクセスして、自分の加入者プロファイルを修正することができるメカニズムが、特許文献１に記載されているが、このアプローチは、別の事業者ネットワークに対しての認証の問題に取り組んでいない。この従来技術は、既に存在する加入契約をユーザが管理することだけを可能にする。ユーザが新規または既存のデバイスに関する全部の契約状況（識別子および認証情報）を遠隔で便利に追加することができるようになるであろう、いかなるメカニズムも提供しない。

先に説明したように、ＡｕＣは、加入者の認証情報を備え、この認証情報は、デバイスに挿入されるＳＩＭカードに反映されている。加入者の認証情報の例には、ＩＭＳＩ（国際移動電話加入者識別番号）、１つ以上の暗号鍵、１つ以上の認証アルゴリズム、１つ以上のセッション鍵アルゴリズム、１つ以上のアルゴリズムパラメータを含む。事業者は、通常、第三者（例えば、ＳＩＭカードベンダ）にＳＩＭカードのセットを作成するように依頼し、次いで、事業者のＡｕＣにそれらのカード上の認証情報を格納する。デバイスの所有者がこの事業者のネットワークを使用したいとき、所有者は、事業者のＳＩＭカードの１つを受け取るか、または買い取る（プリペイド）。これは、個人用のデバイスに関してはうまく働くが、デバイスによっては、ＵＩＣＣ技術に基づく取り外し可能なＳＩＭカードは、費用が高くなる要因であり、固定搭載ＳＩＭで置換されている。

米国特許第７１４９５１６号明細書

３ＧＰＰ ＴＲ３３．８１２ ３ＧＰＰ ＴＳ３３．２０４、２００９年１２月 ＴＰＭの主な仕様レベル２バージョン１．２修正１０３（国際標準ＩＳＯ／ＩＥＣ１１８８９としても入手可能） ３ＧＰＰ ＴＳ３３．２３４ ＴＣＧ仕様、「アーキテクチャ概観」、仕様、修正１．３、２００７年３月 「ＡＲＭセキュリティ技術、ＴｒｕｓｔＺｏｎｅ（登録商標）技術を使用する安全なシステムの構築」、ＡＲＭ白書、ｈｔｔｐ：／／ｉｎｆｏｃｅｎｔｅｒ.ａｒｍ.ｃｏｍ／ｈｅｌｐ／ｔｏｐｉｃ／ｃｏｍ.ａｒｍ.ｄｏｃ.ｐｒｄ２９−ｇｅｎｃ−００９４９２ｃ／ＰＲＤ２９−ＧＥＮＣ−００９４９２Ｃ＿ｔｒｕｓｔｚｏｎｅ＿ｓｅｃｕｒｉｔｙ＿ｗｈｉｔｅｐａｐｅｒ.ｐｄｆ ＲＦＣ２５６０、Ｘ．５０９

しかし、従来技術のメカニズムが深刻な制約を有する多くのシナリオがある。例えば、公益事業会社が移動ネットワークでデータを報告する検針デバイスを配備したい場合、そのデバイスの製造業者は、公益事業会社がどの事業者を使用したいかを知ることができないという問題が生じる。従って、デバイス製造業者は、事業者固有の認証情報をデバイスの中に予め供給しておくことはできず、従来の移動デバイスと同様に、この場合は公益事業会社であるデバイスのユーザにこの仕事を任せなければならない。次いで、公益事業会社は、選択した事業者のネットワークでデバイスが利用可能になるように、デバイスに何か（ＳＩＭカードの挿入、またはデバイスのリプログラミング）をしなければならない。デバイスが事業者のネットワークと連絡を取れると直ぐに、必要があれば（すなわち、最初の連絡が予備およびまたはグループの認証情報に基づいていた場合）、最終の認証情報を供給するために、他の手順が使用されてもよい。

同様の問題は、通信するために移動ネットワークを使用するパーソナルデバイス（電話機、デジタルカメラ、ＴＶ受像機、ＰＣ等）のセットをエンドユーザが所有している場合に、ネットワークに接続された家庭用電化製品においても見られる。ほんの少数のデバイスしかない場合でさえ、ユーザが各デバイスに対して個別のＳＩＭカードを取得することは非常に厄介なことである。

提案されている１つの解決手段は、いわゆるＭＣＩＭ（Ｍａｃｈｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）またはソフトＳＩＭに関する。非特許文献１を参照されたい。この解決手段は、デバイスの供給の問題を解決するが、依然としてユーザ／ネットワーク側に幾つかの欠点を有する。例えば、ユーザがデバイスの事業者を変更したい場合、デバイスごとに一回、事業者変更プロトコルを実行しなければならない。ユーザが、例えば公益事業会社の数百または数千もの遠隔検針デバイスのように、多くのデバイスを有する場合、これは、非常に難しい仕事である。

本明細書は、サービスの加入者を認証するアクセス認証システムの実施形態を開示する。このアクセス認証システムは、事業者アクセス認証システムと、１つ以上の個人アクセス認証システムを備えている。各個人アクセス認証システムは、事業者アクセス認証システムと通信可能に接続することができる。事業者アクセス認証システムは、加入者の複数の認証情報に関連するそれぞれの加入者認証データアイテムに基づいて、サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成されている。各個人アクセス認証システムは、１つ以上の加入者認証データアイテムを前述の事業者アクセス認証システムに伝達するように構成されている。各個人アクセス認証システムは、少なくとも１つの所定の状態で動作している個人アクセス認証システムを示す１つ以上の検証データアイテムを、伝達するようにさらに構成されている。

従って、本明細書に開示するアクセス認証システムの実施形態は、認証データを事業者認証システムに提供しうる１つ以上の個人アクセス認証システムの安全な供給を促進する。その結果として、加入者は、自分の個人アクセス認証システムを設置して、その個人アクセス認証システムに加入者デバイス認証情報を供給してもよい。次いで、個人アクセス認証システムは、認証情報に関連する認証データアイテムを、サービスを提供するサービス事業者が運用する事業者アクセス認証システムに伝達する。これにより、事業者アクセス認証システムは、個別の加入者デバイスおよびそれに関連する認証情報を事業者アクセス認証デバイスに登録する必要なく、かつ個別の加入者デバイスを修正する必要なく、加入者のデバイスの認証を促進することができる。さらに、事業者は、個人アクセス認証システムが信頼できる、例えば認証情報の処理を信頼できることを証明してもよい。

本明細書で使用する加入者および加入者デバイスという用語は、サービスへのアクセスを認可された全てのユーザまたはユーザデバイス、例えばサービスへのアクセスを認可された通信デバイスまたは他の任意の電子デバイスなどを指す。通信デバイスという用語は、固定用および携帯用の通信装置を含むものである。携帯用通信装置という用語は、固定／有線（例えば、ｘＤＳＬ、イーサネット（登録商標）、光）または無線（例えば、ＣＤＭＡ、ＧＳＭ、ＬＴＥ、ＵＭＴＳ、ＷＬＡＮ、ＷｉＭＡＸ）アクセス技術を使用する移動電話機、ページャ、コミュニケータ、電子オーガナイザ、スマートフォン、携帯情報端末（ＰＤＡ）、ハンドヘルドコンピュータ、ラップトップコンピュータなどの全ての装置を含む。

サービスは、通信ネットワークによって提供される電気通信サービスなどの通信サービスであってもよい。従って、幾つかの実施形態においては、サービスへのアクセスは、移動通信ネットワークなどの通信ネットワークへのアクセスを含んでいてもよい。それに応じて、事業者アクセス認証システムまたは事業者サービス認証システムは、ＧＳＭシステムに適合する認証センタ機能、または通信ネットワークなどのサービスの加入者の認証を促進する他の任意の適切な機能を備えていてもよい。事業者アクセス認証システムの実施形態は、例えば事業者ＨＬＲなどの、加入者データの格納および／または管理機能が一例である追加の機能を有してもよい。

同様に、個人アクセス認証システムは、ＧＳＭシステムに適合する認証センタ機能、または通信ネットワークなどのサービスの加入者の認証を促進する他の任意の適切な機能を備えていてもよい。個人アクセス認証システムの実施形態は、例えば個人ＨＬＲなどの、加入者データの格納および／または管理機能が一例である追加の機能を有してもよい。

例えば、加入者は、加入者自身のＨＬＲに接続された加入者自身のＡｕＣが一例である、自分の個人アクセス認証システムを設置して、加入者の認証情報の供給を行ってもよい。その結果として、事業者を変更するとき、認証情報を交換する必要がなくなる。事業者のネットワークにアクセスするために、加入者は、ネットワーク事業者に自分のＨＬＲ／ＡｕＣを登録する。その事業者の既存のＨＬＲ／ＡｕＣは、加入者に関係しているデバイスの１つがネットワークまたは他のサービスにアクセスしたいときに、代わりに加入者のＨＬＲ／ＡｕＣを使用するように修正されている。

一般に、アクセス認証システムという用語は、コンピュータネットワークまたは電気通信システムの１つ以上のデバイスなどの、サービス配信システムの１つ以上のデバイスを備えるシステムを含むものである。ここで、アクセス認証システムは、例えばサービス配信システムが提供するサービスにアクセスしようとしている加入者デバイスに応えて、加入者認証を促進する機能を備えている。特に、認証システムは、認証データアイテム、および／または例えば加入者データと認証手順中に用いる認証アルゴリズムおよびそのパラメータを示すデータとを備える証明書などの加入者の認証情報を、使用するかまたは中に格納していてもよい。

移動通信システムに関するアクセス認証システムの実施形態は、適切に構成されたＡｕＣ、ＨＬＲ、ＭＳＣ／ＶＬＲ、および／またはこれらの組み合わせによって具現されてもよい。

事業者アクセス認証システムという用語は、サービス配信システムの事業者が運用するアクセス認証システムを指すことを意図しているのに対して、個人アクセス認証システムという用語は、サービス配信システムの事業者とは異なるエンティティ、例えばサービスの加入者などが運用するアクセス認証システムを指すことを意図している。従って、事業者アクセス認証システムは、例えば通信サービスプロバイダなどのサービスプロバイダのところに設置されているのに対して、個人アクセス認証システムは、サービスプロバイダのところには設置されない。従って、移動通信システムに関する事業者アクセス認証システムの実施形態は、ＭＳＣ／ＶＬＲ、事業者ＡｕＣ、事業者ＨＬＲ、移動管理エンティティ（ＭＭＥ）、またはこれらの組み合わせとして具現されてもよい。

認証データアイテムという用語は、アクセス認証システムが格納している加入者の認証情報から引き出せる全てのデータ、および／またはその加入者の認証情報に関連している全てのデータを指すことを意図しており、このデータにより、受信エンティティは、サービスにアクセスしようとしている加入者を認証できる。特に、認証データアイテムは、認証手順中に使用される加入者データ、認証アルゴリズム、およびそのパラメータから導き出せてもよい。認証データアイテムの一例には、例えばアクセス認証システムと加入者デバイスの加入者識別子モジュールとの間などの、チャレンジレスポンスメカニズムのチャレンジまたはレスポンスを含んでいてもよい。例として、認証データアイテムは、例えば身元確認のためにチャレンジ／レスポンスを生成するために、および例えば状況に応じてそれに続く通信に用いる暗号鍵を生成するために、共有する秘密および加入者識別子識別子から導き出されてもよい。

現在の標準（例えば、非特許文献２）は、２つの事業者が安全な通信を通じてどのようにデータを交換することができるかを述べているが、個人アクセス認証システムがあるところでは、セキュリティの強化が必要である。

幾つかの実施形態においては、検証データアイテムは、例えば遠隔証明メカニズムなどの、証明データアイテムであってもよい。検証データアイテムは、個人アクセス認証システムが少なくとも１つの所定のハードウェアおよび／またはソフトウェアのコンポーネントを動作させていることを示してもよい、および／または個人アクセス認証システムが少なくとも別の信頼状態で動作していることを示してもよい。しかし、個人アクセス認証システムの状態についての状態パラメータの全てを検証する必要はなくてもよいことが分かるであろう。幾つかの実施形態においては、個人アクセス認証システムが取りうる幾つかの信頼状態の１つで動作していることを証明するのに十分な、ただ１つまたは複数の状態パラメータが検証される。代替または追加で、各個人アクセス認証システムは、事業者アクセス認証システムによる個人アクセス認証システムの検証を可能にする事業者アクセス認証システムに、安全に接続されている。

個人アクセス認証システムが事業者アクセス認証システムの基準に合ったハードウェアおよび／またはソフトウェアを動作させていることを示す１つ以上の証明データアイテム、および／または個人アクセス認証システムが少なくとも１つの所定の状態で動作していることを示す別の検証データアイテムを、個人アクセス認証システムが伝達すると、ネットワークの悪用を防ぐ追加の措置が提供されて、加入者の個人アクセス認証システムの検証および監視が可能になる。従って、幾つかの実施形態においては、個人アクセス認証システムをその上で動作させているエンティティ（例えば、サーバコンピュータ）を、そのエンティティが正しく起動され、許可された（安全な）ソフトウェアを実行するように、選択された事業者が（遠隔から）検証することができる。代替または追加で、事業者アクセス認証システムは、個人アクセス認証システムが実行するソフトウェアの少なくともサブセットを、事業者アクセス認証システムが許可しているかまたは信頼できるかを、検証してもよい。一般に、本明細書に記載の方法の実施形態においては、事業者アクセス認証システムおよび／または別の検証システムは、検証データアイテムを受信して、個人アクセス認証システムが信頼状態で動作しているかどうかを検証してもよい。

例として、本明細書に記載のネットワークアクセス認証システムの実施形態は、個人認証センタを状況に応じて個人ＨＬＲと一緒に導入するために、事業者のネットワークのローミング能力を使用してもよい。本明細書に関しては、個人ＨＬＲはｐＨＬＲとも呼び、個人認証センタはｐＡｕＣとも呼ぶ。ｐＡｕＣは、認証に必要な加入者資格証明データを備え、ｐＨＬＲは、サービス種別およびたぶんデバイスの詳細に関する他の加入者データを有していてもよい。さらに、ｐＡｕＣの実施形態は、ネットワーク事業者がｐＡｕＣを検証できるようにする機能を提供する。ｐＨＬＲおよび／またはｐＡｕＣは、管理インタフェースを備えていてもよく、この管理インタフェースによって、ｐＨＬＲ／ｐＡｕＣの所有者は、ｐＨＬＲ／ａＡｕＣを制御することができ、かつ安全に（例えば、ＳＳＨが一例である暗号的に安全な接続、またはＩＲ、ＮＦＣもしくはＵＳＢケーブルが例である物理的に安全な接続を使用して）、新しい認証情報を追加、交換／更新、削除することができる。例えば、ｐＡｕＣ／ｐＨＬＲに追加される（入れられる）加入者デバイスは、このインタフェースによって、その認証情報のコピーまたは他の情報をエクスポートすることができる。

個人認証システムは、起動を安全に実施しうる、および許可された（例えば、正しく署名された）コードだけを実行しうるように強要しうる信頼できるプラットフォーム上で動作されてもよい。これは、例えば、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）技術を使用することによって達成されてもよく、このＴＣＧ技術では、ＴＰＭ（信頼できるプラットフォームモジュール）または別の適切な信頼できるコンピュータプラットフォームを、正しいソフトウェアコンポーネントだけを開始するように制御することができる。例えば、非特許文献３を参照されたい。一般に、信頼できるコンピュータプラットフォームは、個人データまたは秘密データの保護および処理に適したコンピュータプラットフォームである。このコンピュータプラットフォームは、隔離された実行環境を提供し、ソフトウェア／データを外部の妨害から保護し、その動作（ハードウェアおよびソフトウェアの環境）について保証を提供することができる。従って、信頼できるコンピュータプラットフォームの実施形態は、（例えば、前述のデバイスの認証情報などの）密封（例えば暗号化）されたストレージ、または遠隔証明の機能を有していてもよい。

遠隔証明という用語は、プラットフォームの現在の状態を認可された遠隔エンティティに確実に報告して、遠隔エンティティが、信頼できるプラットフォームを備えるコンピュータにおける変化を検出できるようにするプロセスを指す。遠隔証明は、どのソフトウェアを現在実行しているかを提示する証明書を、ハードウェアに生成させることによって実施されてもよい。次いで、コンピュータは、この証明書を遠隔エンティティに提出して、改ざんされていないソフトウェアを現在実行していることを示すことができる。遠隔証明は、送信情報を、認証を要求したプログラムおよび提出したプログラムだけが読むことができ、盗聴者が読むことができないように、公開鍵暗号と組み合わされてもよい。例えば、ＴＣＧ技術は、個人アクセス認証システムが正しく動作しているか検査するために、選択された事業者が使用することができる遠隔証明をサポートしている。このために、事業者のアクセス認証システムは、そのようなプラットフォーム検証手順をサポートするように増強されてもよい。例えばＧＳＭおよび類似の移動通信ネットワークに関しては、修正事業者アクセス認証システムは、修正ＨＬＲおよび／または修正ＡｕＣを備えてもよく、本明細書においては、それらをそれぞれｏＨＬＲおよびｏＡｕＣとも呼ぶ。従って、検証データアイテムは、例えば信頼できるプラットフォームが生成したデジタル証明書、または信頼できるプラットフォームの他の任意の適切な署名などの、信頼できるプラットフォームが生成した遠隔証明結果を備えていてもよい。

前述の例においては、公益事業会社は、自社が所有（または別のやり方で管理／運用）するデバイス用に、自社のｐＨＬＲまたはｐＡｕＣを設置してもよく、デバイス製造業者は、デバイスを予め供給して、公益事業会社が、デバイスの購入後に、ｐＨＬＲおよびｐＡｕＣ用のデータを（例えば、ウェブのポータルを介して）利用できるようにしてもよい。あるいは、デバイスを利用可能にするちょうどそのとき、デバイスおよび／またはｐＡｕＣからの要求に応じて、認証情報の少なくとも一部が（例えば局所的に生成された乱数値／疑似乱数値を使用して）生成されてもよい。その後、デバイスとｐＡｕＣは、既に検討したように、安全なインタフェースによって認証情報を同期させてもよい。次に、公益事業会社は、選択した事業者にそのｐＨＬＲおよびｐＡｕＣを登録してもよく、事業者は、契約に従って、ローミング加入者に対するのと同じメカニズムを使用して、または事業者自体の加入者に対するのと同じメカニズムを使用して、ネットワークの使用に対して公益事業会社に料金を請求してもよい。公益事業会社が事業者を変更したい場合／とき、公益事業会社は、新しい事業者と契約の交渉をしてから、そのデバイスにこの新しい事業者のネットワークを選択するように命令する。従来技術の処理とは対照的に、この命令を、デバイスごとに事業者を変更しないで、ただ１つの（安全な）マルチキャストメッセージによって実行することができる。ネットワーク側で必要なことは単に、認証データシグナリングを公益事業会社のｐＨＬＲおよびｐＡｕＣに向けるかまたは向け直すように、新しい事業者が、事業者アクセス認証システム（例えば、新しいｏＨＬＲ／ｏＡｕＣ）を再設定することである。公益事業会社が選択した事業者は、他方において、公益事業会社のｐＨＬＲ／ｐＡｕＣが信頼しうることを検証できることを望む。

本発明は、上述の相互に作用する事業者と個人のＨＬＲ／ＡｕＣの仕組みと、以下に述べる対応するシステム、方法および製品とを含む様々な態様に関し、それぞれの態様が、上述の態様の１つとの関連で述べた１つ以上の便益および利点を生じ、かつ、それぞれの態様が、上述の態様の少なくとも１つとの関連で述べた実施形態に対応する１つ以上の実施形態を有する。

より具体的には、別の態様によれば、事業者アクセス認証システムによって、サービスへのアクセスを要求している加入者デバイスの認証を促進する方法を開示する。この事業者アクセス認証システムは、それぞれの加入者認証データアイテムに基づいて、サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成されている。この方法は、
・事業者アクセス認証システムと通信可能に接続された個人アクセス認証システムから、１つ以上の加入者の認証情報を示す加入者認証データアイテムを受信する工程と、
・受信した加入者認証データアイテムに対応して、および個人アクセス認証システムが動作している状態の検証に対応して、前述の加入者の認証情報に関係する加入者の認証を促進する１つ以上の認証機能を提供する工程と
を有する。

事業者認証システムが提供する加入者の認証を促進する１つ以上の認証機能は、認証プロセスの実行、および／または例えば受信した認証データアイテムもしくはそれから導出したデータなどの認証データを、認証プロセスを実際に実行して前述のサービスへのアクセスを提供しうる別のエンティティへの転送を有していてもよい。個人アクセス認証システムの動作状態の検証は、例えば個人アクセス認証システムから受信した検証データアイテムに対応して、事業者アクセス認証システムが少なくとも一部を行ってもよい。代替または追加で、検証は、例えば検証結果または中間結果を事業者アクセス認証システムに伝達しうる検証システムなどの別のエンティティによって、少なくとも一部が行われてもよい。

さらに、本明細書は、事業者アクセス認証システムに接続された個人アクセス認証システムによって、サービスへのアクセスを要求している加入者デバイスの認証を促進する方法を開示する。この事業者アクセス認証システムは、それぞれの加入者認証データアイテムに基づいて、サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成されている。この方法は、
・１つ以上の加入者の認証情報を示し、加入者デバイスの通信ネットワークへのアクセスを事業者アクセス認証システムが選択的に許可または拒否するように促す加入者認証データアイテムを、事業者アクセス認証システムに伝達する工程と、
・個人アクセス認証システムの動作状態を示す少なくとも１つの検証データアイテムを伝達する工程と、事業者アクセス認証システムによる、前述の状態が信頼できるかどうかの判定を促進する工程と
を有する。

個人認証システムは、加入者認証データアイテムを、事業者アクセス認証システムに直接または別のエンティティを介して伝達してもよい。個人認証システムは、個人アクセス認証システムの状態の検証のために、検証データアイテムを、事業者アクセス認証システムおよび／または別のシステムに伝達してもよい。

さらに、本明細書に規定するサービスアクセス認証システムで用いる、事業者アクセス認証システムおよび個人アクセス認証システムを開示している。事業者アクセス認証システムおよび個人認証システムのそれぞれは、例えばサーバコンピュータ、または他のデータ処理システムなどのサーバとして、当該技術分野で仮想化メカニズムとして公知の適切なハードウェア仮想化メカニズムを使用する仮想サーバとして具現されてもよい。

上記および他の態様は、図を参照して以下に説明する実施形態から明白かつ明瞭になる。

認証システムの一例の略ブロック図。 アクセス認証およびプラットフォーム検証プロセスの一実施形態の図。 個人認証システムへの認証データアイテム要求のルーティングプロセスの例を示すフロー図。

図１は、アクセス認証システムの一例の略ブロック図を示す。図１のアクセス認証システムは、移動通信ネットワークなどの通信ネットワークへのアクセスを要求する加入者デバイスの、認証を促進するネットワークアクセス認証システムである。このネットワーク認証システムは、事業者認証センタ（ｏＡｕＣ）として具体化されている事業者アクセス認証システム１０１と、個人認証センタ（ｐＡｕＣ）として具体化されている個人アクセス認証システム１０２とを備えている。しかし、事業者アクセス認証システム１０１は、事業者認証センタ（ｏＡｕＣ）、ＭＳＣ／ＶＬＲ、事業者ＨＬＲ（ｏＨＬＲ）、またはこれらの組み合わせとして具体化されてもよく、個人アクセス認証システム１０２は、個人認証センタ（ｐＡｕＣ）、個人ＨＬＲ、またはこれらの組み合わせとして具体化されてもよいことが分かるであろう。

ｐＡｕＣは、個人ホームロケーションレジスタ（ｐＨＬＲ）１０３に接続されていてもよい。あるいは、ｐＡｕＣは、加入者が運用する個人ホームロケーションレジスタｐＨＬＲのコンポーネントとして具体化されてもよい。同様に、図１のｏＡｕＣは、ネットワーク事業者によって運用され、事業者ホームロケーションレジスタ（ｏＨＬＲ）１０４に接続されていてもよい。上記エンティティのそれぞれのただ１つのエンティティだけが図１に示されているが、アクセス認証システムの実施形態が、これらのエンティティの１つに対して複数、幾つかに対して複数、または１つずつに対して複数のエンティティをそれぞれ備えてもよいことが分かるであろう。さらに、幾つかの実施形態においては、加入者は、事業者のｏＨＬＲと通信することができるｐＡｕＣだけを運用していてもよい。この場合、ＩＭＳＩは、このｏＨＬＲと関係していてもよく、関係している場合、認証データ要求は、まずｏＨＬＲに送信されるであろう。この場合、ｏＨＬＲは、認証データアイテムをｐＡｕＣに要求すべきであるという情報を有していてもよい（例えば、ｐＡｕＣのＵＲＬ、ＩＰアドレス、または類似のものが、ｏＨＬＲに構成されている）、しかし他の全ての機能はｏＨＬＲで行われてもよい。

ｐＡｕＣは、例えばデバイスまたはデバイスのハードウェアコンポーネントおよび／またはソフトウェアコンポーネントなどのシステムであり、基地局１０６および移動通信交換局（ＭＳＣ）１０７を介して、例えばＧＳＭネットワークなどの移動通信ネットワークに接続しようとする加入者デバイスの、認証を促進する機能を提供する。幾つかの実施形態においては、認証システムは、認証を直接行ってもよいのに対して、他の実施形態においては、代わりに認証プロセスで用いるデータを生成してもよい。例えば、ＧＳＭに関しては、ｐＡｕＣは、ＭＳＣが認証手順中に使用する、いわゆるトリプレットまたはベクトルを生成してもよい。他方、例えば、非特許文献４に準拠して動作する無線ＬＡＮアクセスの場合は、認証の判定（許可／拒否）の少なくとも一部をｐＡｕＣ自体が行ってもよい。

例えば移動電話機、コンピュータ、または通信ネットワークにアクセスできる他の任意の電子デバイスなどの加入者デバイス１０５は、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）１０８を備えている。ＳＩＭは、認証プロセスで用いる加入者の認証情報を備えている。しかし、加入者デバイスは、加入者の認証情報を安全に格納する他の任意の適切な記憶媒体を備えていてもよいことが分かるであろう。加入者の認証情報を格納する適切なメカニズムの例には、「ソフトＳＩＭ」タイプの解決手段、物理的ＵＩＣＣカード、デバイス製造業者によってデバイスに組み込まれる「ハードワイヤード」認証情報、またはデバイスの（保護された）ファイルに格納される認証情報さえ含む。ただ１つの加入者デバイスだけが図１に示されているが、ネットワークアクセス認証システムの実施形態は、自デバイスの認証情報と認証情報の記憶手段とをそれぞれが有する複数の加入者デバイスに、アクセス認証を提供しうることが分かるであろう。

認証プロセスのセキュリティは、ｐＡｕＣとＳＩＭとの間の共有の秘密によって決まることがある。従って、ｐＡｕＣは、加入者の認証情報を格納する記憶媒体１１０も備えていてもよい。共有の秘密は、製造中にＳＩＭに安全に焼き付けられるか、または他のやり方でプログラムされてもよく、また、安全にｐＡｕＣ上に複製もされる。この共有の秘密は、その後は、通常、ｐＡｕＣとＳＩＭとの間を決して伝送されず、むしろ身元証明のためのチャレンジ／レスポンス、および無線通信で用いる暗号鍵を作成するために、ＩＭＳＩと組み合わされる。

従って、上記から分かるように、ｐＡｕＣの認証能力は、従来技術の通信ネットワークの通常のＡｕＣの認証能力と同様であってもよい。しかし、ｐＡｕＣは、今や、事業者ではなく加入者によって所有され運用されている。けれども、ｐＡｕＣは、ローミング設定の場合と同じように、移動ネットワークへのアクセスをもたらす認証データアイテムを提供する責任がある。加入者は、自分のＡｕＣを運用するので、加入者の認証情報の供給を行うことができ、事業者を変更するとき、認証情報を交換する必要がない。事業者のネットワークにアクセスするために、加入者は、ネットワーク事業者に自分のｐＡｕＣを登録する。この事業者の既存のｏＨＬＲおよび／またはｏＡｕＣは、加入者デバイスの１つがネットワークにアクセスしたいとき、代わりに加入者ｐＡｕＣを使用するように修正されている。従って、幾つかの実施形態においては、ｏＨＬＲは、要求する加入者デバイスの識別子に応じて選択的に前述の加入者デバイスの認証データを取得するために、ｏＡｕＣまたはｐＡｕＣと連絡を取ってもよい。代替実施形態においては、ｏＨＬＲは、常にｏＡｕＣと連絡を取ってもよく、このｏＡｕＣが、加入者デバイスの識別子に応じて、認証データ要求を対応するｐＡｕＣに転送してもよい。

ｐＡｕＣは、信頼できる（実行）プラットフォーム１０９上で実行される。ｐＨＬＲも、同じまたは類似の信頼できるプラットフォーム１１１上で実行されてもよい。プラットフォームは、例えばプラットフォームの信頼機能の不変のルート（例えば、仮想コンピュータプラットフォームのハードウェア）に基づいて、認可された（例えば、正しく署名された）ソフトウェアを安全に実行できる能力がある場合、「信頼できる」と呼ばれる。一実施形態においては、信頼できるプラットフォームは、プラットフォームが、正しく開始され正しいソフトウェアを実行している、および／または他のやり方によって信頼状態で動作していることを、遠隔エンティティが確実に検証できるようにする機能をさらに提供する。このような機能は、（プラットフォーム）証明と呼ばれることが多い。信頼のルートに基づいて安全に起動する技術が複数存在する。

例えば、信頼できるプラットフォームは、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）技術を実施する信頼できるプラットフォームモジュール（ＴＰＭ）を備えていてもよい。ＴＰＭ（信頼できるプラットフォームモジュール）は、正しいソフトウェアコンポーネントだけを開始するように制御してもよい。また、ＴＣＧ技術は、ｐＡｕＣが正しく動作しているかどうかを検査するために、選択された事業者が使用してもよい遠隔証明もサポートする。特に、ＴＰＭは、開始されるソフトウェアコンポーネントおよびＴＰＭの状態の証明を行うソフトウェアコンポーネントの検証のための、鍵およびメカニズムを有する（例えば非特許文献５参照）。代替または追加で、他の解決手段、例えばＴｒｕｓｔＺｏｎｅ技術（例えば非特許文献６参照）が、安全に起動するために使用されてもよい。代替または追加で、独自仕様の証明プロトコルもまた使用されてもよい。証明機能は、例えばプラットフォームの暗号証明書の有効性の検証などと、組み合わされてもよい。そのような解決手段の１つ以上の組み合わせは、一般に、プラットフォーム検証と呼ばれることがある。本明細書に関しては、プラットフォーム検証という用語は、例えばＯＣＳＰを使用した、プラットフォーム証明書の検証を少なくとも備えていてもよい（例えば非特許文献７を参照）。

別の選択肢として、事業者は、ｐＡｕＣ機能を実施する実行可能コードを提供してもよい。これは、シーリングとして知られている、ＴＰＭ標準の他の技術部分を使用することによって行われてもよい。ここで、コードは、暗号形態で（例えば、ｏＨＬＲ１０４から）ｐＡｕＣ１０２に送信される。コードは、ＴＰＭ１０９（だけ）が知っている鍵によってだけ解読することができる。さらに、ＴＰＭ１０９は、ｐＡｕＣによるコードの解読およびそれに続く実行を許可する前に、ｐＡｕＣが信頼状態にあることを局所的に検証する。この実施形態においては、事業者は、（事業者がコードを書いたので）コードが信頼できることを知っており、許可できる／信頼できる状態の場合だけ、コードが実行されると確信できる。

上記のプラットフォーム検証メカニズムは、より一般的に、利用可能性の視点からは個人ユーザに特に有利なことがある「クラウド」での、ｐＡｕＣの実行を可能にすることが分かるであろう。この場合、ｐＡｕＣは、本明細書で検討したように、プラットフォームの信頼を遠隔から検証することができている間に、様々な物理プラットフォームの間を移動しうる仮想マシン（ＶＭ）であってもよい。例えば、いわゆるハイパバイザまたは仮想マシンモニタ（例えば、ＸＥＮまたはＫＶＭ）を使用して、ｐＡｕＣ／ｐＨＬＲだけを実行する自分のオペレーティングシステムを有する仮想マシンを提供し、それによって、ｐＡｕＣ／ｐＨＬＲを同じ物理ホストコンピュータ上で動作している他の（潜在的に誤りや悪意のある）ソフトウェアから隔離して、セキュリティをさらに向上させてもよい。

信頼できるプラットフォーム１０９（および必要に応じてプラットフォーム１１１）のプラットフォーム検証プロセスを実行する遠隔エンティティは、ｏＡｕＣ、または例えば、事業者ＨＬＲまたは例えばポリシ実施機能などのセキュリティ管理を担当するノードなどの、事業者ネットワークインフラストラクチャの他の適切なコンポーネントであってもよい。従って、ｏＡｕＣおよび／または他の事業者ネットワーク・インフラストラクチャ・コンポーネントは、そのようなプラットフォーム検証手順をサポートするように構成されていてもよい。証明は、ポリシおよび／またはユーザと事業者の契約に応じて、ｐＡｕＣおよび／またはｐＨＬＲが最初にｏＡｕＣ／ｏＨＬＲに接続されるときに行われてもよい、および／または例えば認証データアイテム要求ごとに１回、追加の認証情報／デバイスごとに１回、１日に１回等、間欠的に繰り返されてもよい。

加入者デバイス１０５が基地局１０６を介して事業者のネットワークへのアクセスを要求し、加入者デバイスの認証をｏＡｕＣで管理していない加入者デバイスに、その契約が関連していると事業者が検出すると、事業者は、ｐＡｕＣに連絡して、加入者デバイス１０５の加入者の認証情報に関連する認証ベクトルを要求する。契約がｐＡｕＣ／ｐＨＬＲに関連していることの検出は、ＭＳＣによって、またはｏＨＬＲによって、またはｏＡｕＣによって行われてもよい。ｐＡｕＣ／ｐＨＬＲに関連している契約に、特別なＩＭＳＩフォーマットが使用されている場合、ＭＳＣが検出してもよい。他方、ＩＭＳＩが事業者の通常のＩＭＳＩ空間に関連している場合、ｏＨＬＲまたはｏＡｕＣが検出する必要があってもよい。いずれにしても、契約がｐＡｕＣ／ｐＨＬＲに関していることを検出するエンティティは、関連しているｐＡｕＣ／ｐＨＬＲのアドレス（例えば、ＵＲＬまたはＩＰアドレス）を用いて構成されてもよい。

効率的なシステムを実現するためには、このアクセス要求は、信頼できるプラットフォーム１０９の証明能力を使用しうる、プラットフォーム検証要求と組み合わされてもよい。組み合わされた認証ベクトル要求は、次のように形成されてもよい。
新しい認証ベクトル要求＝｛古い認証ベクトル要求，ナンス，証拠＿要求｝ （１）
上式で、証拠＿要求は、ｏＡｕＣ（または一般に、証明を要求するエンティティ）がｐＡｕＣから受信したい証拠の種類を示す。上式は、ｐＡｕＣが要求元を検証できるように、ｏＡｕＣによって署名されていることが好ましい。ナンスは、リプレイ攻撃を防ぐために導入されている。古い認証ベクトル要求は、そのようなものとして知られているＡｕＣからの従来の認証ベクトル要求であってもよい。

次いで、ｐＡｕＣは、上記の要求に次の組み合わせの認証応答で答えてもよい。
新しい認証ベクトル応答＝｛認証ベクトル，証拠＿回答，署名＿ｐＡｕＣ｝ （２）
ｐＡｕＣの署名である署名＿ｐＡｕＣは、認証ベクトル、証拠＿回答、およびナンスの上にあってもよい。これにより、受信エンティティは、データの正しい発信元およびデータが繰り返し出ないことを検証できる。証拠＿回答は、（実際の証拠＿要求に応じて）潜在的な証明要求のＴＰＭ署名を有していてもよいことに留意されたい。しかし、証拠＿要求および証拠＿回答の実際の詳細は、ｐＡｕＣが本物で、正しいソフトウェアを実行していることを、ｐＡｕＣがどのように証明することができるかによって決まることが分かるであろう。署名は、例えばＲＳＡまたは楕円曲線に基づく、任意の公開鍵暗号署名方法を使用して行われてもよい。ｐＡｕＣは、プラットフォーム検証を実行する機能を備えていてもよいｏＨＬＲに、上記の応答を送信してもよいことがさらに分かるであろう。幾つかの実施形態においては、応答は、ｐＡｕＣに関連しているｐＨＬＲを介して、ｏＨＬＲに送信されてもよい。

図２は、認証ベクトル要求とｐＨＬＲ／ｐＡｕＣ検証を組み合わせて使用する、アクセス認証およびプラットフォーム検証のプロセスの一実施形態を示す。このプロセスは、例えば図１に示すｏＡｕＣ１０１、ｏＨＬＲ１０４、およびｐＡｕＣ１０２を備えるシステムなどの、ネットワーク認証システムによって行われてもよい。図２の例においては、プラットフォーム検証は、ＴＣＧのＴＰＭ技術に基づいて、ｏＨＬＲ１０４が行う。従って、ｐＡｕＣ１０２は、ＴＰＭ１０９上で実行される。あるいは、プラットフォーム検証は、例えばｏＡｕＣなどの別のネットワークエンティティが行ってもよい。

プロセスは、既存のＨＬＲの新しい下位機能として実施されてもよいが、ｏＨＬＲが開始してもよいし、またｏＡｕＣの一部にさえされてもよい。本明細書に関しては、ｏＨＬＲ自体がプロセスを始めると想定している。

ｏＨＬＲは、例えば上述の形式（１）などの検証要求を含む認証データ要求２２１を、ネットワークへのアクセスを要求している加入者デバイスに関係するｐＡｕＣに送信する。上述のように、この要求には、証拠を作成するために、ｐＡｕＣへの、証拠＿要求で表わされるコマンドの形態の検証要求を含む。例えば、要求は、ｐＡｕＣ内にある種のサブシステムが存在する証拠を依頼してもよい。本明細書を簡潔にするために、要求は、ｐＡｕＣが、正しく起動されており、かつｐＡｕＣ認証サブシステムの秘密鍵の知識を有することを示す証拠に関するものであると想定する。幾つかの実施形態においては、証明要求は、高レベルのセキュリティを提供するために、認証データ要求ごとに出されてもよいのに対して、他の実施形態においては、証明要求は、代わりに間欠的に、および／または認証データ要求と関連する要求に加えて、出されてもよいことが分かるであろう。

要求２２１の受信時、ｐＡｕＣは、正しく起動されている証拠を生成するために、ＴＰＭ１０９を使用する。図２では、これは、ｐＡｕＣからＴＰＭ１０９に伝達される証明要求２２２によって示されている。これは、そのようなものとして公知の手順であり、ＴＣＧ仕様書に定められている（例えば非特許文献５参照）。証拠は、ＴＰＭからｐＡｕＣへ証明結果２２３として返される。証明結果は、ｏＨＬＲが送信したメッセージ２２１からのナンスであってもよいランダムチャレンジを備えてもよいし、また、このナンスおよび認証ベクトルデータの関数であってもよい。

ここで、ｐＡｕＣは、タプルである証拠＿回答を作成する。
証拠＿回答＝｛
起動＿証拠：証明結果；
ｐＡｕＣ＿認証＿秘密＿鍵＿証拠：ＲＳＡ＿署名
｝；
上式で、ＲＳＡ＿署名は、先述のナンスの署名である。

図２に示す署名＿ｐＡｕＣは、認証サブシステムの秘密鍵以外の秘密鍵に基づいてもよい。例えば、ｐＨＬＲとｏＨＬＲとのローミング協定に関する秘密鍵に基づいてもよい。

次いで、ｐＡｕＣは、証拠＿回答を含む、例えば上述の形式（２）の認証応答２２４をｏＨＬＲに返す。

次いで、ｏＨＬＲはＯＣＳＰサーバ２２５を使用して、メッセージ２２６および２２７によって示されるように、証明書が取り消されているかどうかを確認する。あるいは、ｏＨＬＲは、配信されている配信用証明書取り消しリストに頼ってもよい。

ｐＡｕＣの検証に成功した場合、ｏＨＬＲは、例えばローミングユーザに対して通常行われるなどの、それ自体が公知のやり方で、認証＿ベクトルを処理してもよい。

加入者が運用する認証システムの供給を促進するために、ネットワークインフラストラクチャは、加入者認証データ要求の正しいｐＨＬＲ／ｐＡｕＣへのルーティングを提供するように修正されてもよい。例えば、このプロセスは、前述のように、加入者デバイスがネットワークにアクセスを試みるときに使用する基地局の事業者のＭＳＣ／ＶＬＲによって行われてもよい。ルーティングには、それに続く、例えばＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲなどを使用する認証データ（いわゆる認証ベクトル）の転送のために、安全な接続（例えば、ＩＰｓｅｃまたはＴＬＳ／ＳＳＬ）設定が付随してもよい。

事業者は、どのＩＭＳＩ番号がどのｐＡｕＣに関係しているかを知っているであろう。非ローミングデバイスの場合は、図３に示す簡単な解決手段が使用されてもよい。この方法は、ルーティングソリューションに、登録されているｐＡｕＣの１つに属するＩＭＳＩを特定する追加のステップ３３１を導入している。例えばハッシュ表を使用することによって、この検索は、基本的に一定の時間複雑さで効率的に実施されてもよい。図３の例では、プロセスは、ステップ３３０において、ＩＭＳＩのＭＣＣ（Ｍｏｂｉｌｅ Ｃｏｕｎｔｒｙ Ｃｏｄｅ）部分およびＭＮＣ（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｃｏｄｅ）部分が別の事業者を指すかどうかを最初に判断する。別の事業者を指す場合、プロセスは、特定された事業者に連絡を取る。そうでない場合、ステップ３３１において、プロセスは、ＩＭＳＩに関連するｐＡｕＣを特定する。

全てのユーザがｐＡｕＣおよびそのｐＡｕＣに関係する多くのデバイスを有してもよいとき、１５桁のＩＭＳＩでは十分ではないかもしれないことに留意されたい。それ故、１つの意見として、次のアプローチが使用されてもよい。

ＶＰＬＭＮ（Ｖｉｓｉｂｌｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）は、ＭＣＣ＋ＭＮＣがｐＡｕＣ／ｐＨＬＲを指すことを検出すると、ｐＡｕＣ／ｐＨＬＲを特定するためにＭＳＩＮ部分を使用し、このｐＡｕＣ／ｐＨＬＲ内のデバイスを特定するために、第２の識別子要求（ネットワークが３ＧＰＰ仕様書に従って加入者を識別するのに十分な情報を有さないとき、ＩＭＳＩ要求はいつ出されてもよい）も出す。この意味することは、数十億のデバイスをそれぞれ備える、最大１０億のｐＡｕＣ／ｐＨＬＲをサポートすることができるということである。

ｐＡｕＣの検出は、既存の手順の前に置かれてもよいことに留意されたい。デバイスが他のネットワークにローミングする必要もあるとき、同じルーティング情報が他の事業者に配信されてもよい。

幾つかの実施形態について詳細に図示し説明しているが、本発明はそれらに限定されず、以下の特許請求の範囲に規定される主題の範囲内の他のやり方でも具現されてもよい。

本明細書に記載の方法、製品手段およびデバイスは、幾つかの個別の要素を備えるハードウェア手段、および適切にプログラムされたマイクロプロセッサによって実施されてもよい。幾つかの手段を挙げるデバイス請求項において、これらの手段の幾つかは、例えば、適切にプログラムされたマイクロプロセッサ、１つ以上のデジタル信号プロセッサなどの同一のハードウェア製品によって具体化されてもよい。ある措置が互いに異なる従属請求項の中で列挙されている、または異なる実施形態の中で述べられているということだけで、これらの措置の組み合わせを有利に使用することができないということを示すものではない。

本明細書で使用するとき、「備える（ｃｏｍｐｒｉｓｅｓ／ｃｏｍｐｒｉｓｉｎｇ）」という用語は、述べられた特徴、整数、ステップまたはコンポーネントの存在を指定すると解釈され、１つ以上の他の特徴、整数、ステップ、コンポーネントまたはこれらのグループの存在または追加を排除するものではないことを強調しておく。

留意すべきことは、ネットワークへのアクセスを制御および許可する仕組みにおいて、着想について述べているが、開示の方法およびシステムを、サービス一般へのアクセスの制御および許可に使用しうることが分かるであろう。

Claims (19)

1. サービスの加入者を認証するアクセス認証システムであって、
   該アクセス認証システムは、事業者アクセス認証システムと、１つ以上の個人アクセス認証システムを備え、
   各個人アクセス認証システムは、前記事業者アクセス認証システムと通信可能に接続することができ、
   前記事業者アクセス認証システムは、前記加入者の認証情報に関連する各加入者認証データアイテムに基づき、前記サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成され、
   各個人アクセス認証システムは、１つ以上の加入者認証データアイテムを前記事業者アクセス認証システムに伝達するように構成され、
   各個人アクセス認証システムは、前記個人アクセス認証システムの動作状態を示し、前記事業者アクセス認証システムが前記動作状態を信頼できるかの判定を促進する、１つ以上の検証データアイテムを伝達するようにさらに構成されていることを特徴とするアクセス認証システム。
2. 各個人アクセス認証システムは、前記事業者アクセス認証システムよる前記個人アクセス認証システムの検証を可能にする前記事業者アクセス認証システムと安全に接続されていることを特徴とする請求項１に記載のアクセス認証システム。
3. 前記個人アクセス認証システムは、信頼されたプラットフォームを含むことを特徴とする請求項１又は２に記載のアクセス認証システム。
4. 前記信頼されたプラットフォームは、安全な起動動作を実行する様に動作可能であることを特徴とする請求項３に記載のアクセス認証システム。
5. 前記信頼されたプラットフォームは、デジタル的に署名されたプログラムコードの実行に制限する様に動作可能であることを特徴とする請求項３又は４に記載のアクセス認証システム。
6. 前記検証データアイテムは、前記信頼されたプラットフォームの少なくとも１つの署名、或いは、前記信頼されたプラットフォームにより生成された少なくとも１つの証明結果を含むことを特徴とする請求項３から５のいずれか１項に記載のアクセス認証システム。
7. 前記個人アクセス認証システムは、前記加入者認証データアイテム及び１つ以上の検証データアイテムを含む認証メッセージを伝達する様に構成されていることを特徴とする請求項１から６のいずれか１項に記載のアクセス認証システム。
8. 前記個人アクセス認証システムは、前記事業者アクセス認証システムから認証データの要求を受信し、前記認証データの要求の応答として前記認証メッセージを伝達する様に構成されていることを特徴とする請求項７に記載のアクセス認証システム。
9. 前記認証データの要求はナンスを含み、
   前記個人アクセス認証システムは、前記認証メッセージに、少なくとも前記受信したナンスに関する少なくとも１つのデジタル署名を含める様に構成されていることを特徴とする請求項８に記載のアクセス認証システム。
10. 前記認証データの要求は、前記個人アクセス認証システムが少なくとも１つの所定の状態で動作していることを示すために、前記事業者アクセス認証システムが要求する証明の種別を示すデータアイテムを含むことを特徴とする請求項８又は９に記載のアクセス認証システム。
11. 前記認証メッセージは、デジタル署名を含むことを特徴とする請求項７から１０のいずれか１項に記載のアクセス認証システム。
12. 前記少なくとも１つの所定の状態は、前記個人アクセス認証システムが、前記事業者アクセス認証システムにより信頼される予め決められたソフトウェアコンポーネントを実行している状態を含むことを特徴とする請求項１０に記載のアクセス認証システム。
13. 事業者アクセス認証システムによって、サービスへのアクセスを要求している加入者デバイスの認証を促進する方法であって、
    前記事業者アクセス認証システムは、各加入者認証データアイテムに基づき、前記サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成され、
    前記方法は、
    前記事業者アクセス認証システムと通信可能に接続された個人アクセス認証システムから、１つ以上の加入者認証情報を示す加入者認証データアイテムを受信するステップと、
    前記個人アクセス認証システムから、前記個人アクセス認証システムの動作状態を示し、前記事業者アクセス認証システムが前記動作状態を信頼できるかの判定を促進する検証データアイテムを受信するステップと、
    前記受信した加入者認証データアイテムと、前記検証データアイテムの検証に応答して、前記加入者認証情報に関連する加入者の認証を促進する１つ以上の認証機能を提供するステップと、
    を含むことを特徴とする認証を促進する方法。
14. 前記個人アクセス認証システムに認証データの要求を送信するステップと、
    前記要求の応答として、前記加入者認証データアイテムを受信するステップと、
    を含むことを特徴とする請求項１３に記載の認証を促進する方法。
15. 前記事業者アクセス認証システムが、前記個人アクセス認証システムから、前記個人アクセス認証システムの動作状態を示す、少なくとも１つの検証データアイテムを受信するステップと、
    前記事業者アクセス認証システムが、前記受信した検証データアイテムに基づき、前記動作状態が信頼できるかを判定するステップと、
    をさらに含み、
    前記１つ以上の認証機能を提供するステップは、前記判定の応答であることを特徴とする請求項１３又は１４に記載の認証を促進する方法。
16. アクセス認証システムのための事業者アクセス認証システムであって、
    前記事業者アクセス認証システムは、各加入者認証データアイテムに基づき、サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成され、
    前記事業者アクセス認証システムは、請求項１３から１５のいずれか１項に記載の認証を促進する方法のステップを実行する様に構成されていることを特徴とする事業者アクセス認証システム。
17. 加入者デバイスからサービス要求を受信し、
    前記受信したサービス要求に基づき、個人アクセス認証システムのセットの１つを識別し、
    前記識別した個人アクセス認証システムに、当該個人アクセス認証システムの動作状態を示す少なくとも１つの検証データアイテムと、前記加入者デバイスに関連する１つ以上の加入者認証情報を示す前記加入者認証データアイテムを要求する、
    様にさらに構成されていることを特徴とする請求項１６に記載の事業者アクセス認証システム。
18. 事業者アクセス認証システムに接続された個人アクセス認証システムによって、サービスへのアクセスを要求している加入者デバイスの認証を促進する方法であって、
    前記事業者アクセス認証システムは、各加入者認証データアイテムに基づき、前記サービスの加入者の認証を促進する１つ以上の認証機能を提供するように構成され、
    前記方法は、
    １つ以上の加入者認証情報を示し、加入者デバイスの通信ネットワークへのアクセスを前記事業者アクセス認証システムが選択的に許可または拒否することを促進する加入者認証データアイテムを、前記事業者アクセス認証システムに伝達するステップと、
    前記個人アクセス認証システムの動作状態を示し、前記事業者アクセス認証システムが前記動作状態を信頼できるかの判定を促進する、少なくとも１つの検証データアイテムを伝達するステップと、
    を含むことを特徴とする認証を促進する方法。
19. アクセス認証システムのための個人アクセス認証システムであって、
    前記アクセス認証システムは、事業者アクセス認証システムと、少なくとも１つの前記個人アクセス認証システムを備え、
    前記個人アクセス認証システムは、請求項１８に記載の認証を促進する方法のステップを実行する様に構成されていることを特徴とする個人アクセス認証システム。

Images