JP6175490B2 - クライアントシステムを認証するための方法およびコンピュータ通信システム - Google Patents

Description

本発明は請求項１の特徴を備えた方法と請求項１２のコンピュータ通信システムに関するものである。

電子商取引の分野など、多くの利用分野では、今後顧客となる人のクライアント機器などをサービス提供システムで識別する必要があることが必須である。

サービス提供者と顧客にとって関心があるのは、顧客のＩＤが本人だけによって使用されているということである。特に、携帯電話などの中で動作する移動クライアントの場合には正確な認証が重要である。

クライアントシステムは、移動電話システムなど人間に対応付けることのできるデータ処理システムと、直接人間と対応のないデータ処理システムのいずれでもよいと理解できる。後者の場合の例としては、人間が関与することなく別の物理装置とデータを交換できる物理装置という形態のクライアントシステムがある。いずれの場合も、クライアントシステムは他のシステムと通信する能力を備えたものである。

請求項１の方法は、クライアントシステムのための安全な認証を提供することによってこの問題に対処するものである。

ＩＤ提供システムが生成した少なくとも１つのＩＤトークンは、データベース、特にセキュアストレージシステムのような暗号化データベースに記憶させるか、あるいはあらかじめ記憶させておく。生成すること自体は必ずしも認証手順の一部ではないが、この方法の以下の手順では、少なくとも一つのＩＤトークンが存在している必要がある。

次に、クライアントシステムによって、サービスの要求をサービス提供システムに送信する。この文脈における要求は、サービス提供システムの提供するサービスを受ける目的でクライアントシステムからサービス提供システムに送られるコマンドであれば（例えばブラウザからのＧＥＴやＰＯＳＴなど）いかなるものでもよいことが理解できる。

続いて、サービス提供システムはＩＤ提供システムによるＩＤトークンの有効性検査を含むＩＤ認証プロセスを開始し、ＩＤ提供システムにより検査されたＩＤトークンの有効性検査の結果に応じて、要求されたサービスを提供あるいは拒否する。

ひとつの実施例として、セキュアストレージシステムの機能は、以下の機能をもつデータベース管理システム（特に以下の機能のみをもつもの）に結合する。
ａ）データベースにアクセスするためのユーザーの認証を行う。
ｂ）データベースに格納されたＩＤトークンのリストを呼び出す。
ｃ）データベースにＩＤトークンを格納する。
ｄ）一意の識別子を用いて、データベースに格納されているＩＤトークンを呼び出す。
ｅ）一意の識別子を用いて、データベース内のＩＤトークンを削除する。

ひとつの実施例として、少なくとも１つのＩＤトークンをもつセキュアストレージシステムを、携帯電話、特に携帯電話、メモリスティック、ＲＦＩＤデバイスなどを特に含むモバイルデバイスに格納する。この実施例では他に本人確認物件を必要とせず、ＩＤが持ち運びしやすいものとなる。

別の実施例として、少なくとも１つのＩＤトークンをもつセキュアストレージシステムをパーソナルコンピュータや乗り物（特に車）に格納する。原理的にはセキュアストレージシステムは、ＣＰＵと通信インターフェース（イーサネット（登録商標）、ＧＰＲＳ等）をもつあらゆるデバイスと共に使用することができる。

さらなる実施例として、セキュアストレージシステムは実行可能ファイルの少なくとも一部とする。

また別の実施例として、セキュアストレージシステムは鍵導出関数手段を備えたものとする。

特に柔軟な実施例は、名前、ＩＤ番号、クレジットカード番号、指紋、生体認証記録など、複数のＩＤ項目を含むＩＤトークンを用いるものである。原理的には、特定の事業についての任意の識別機能を識別機能として使用することができる。ＩＤトークンの識別項目（あるいは複数の項目の組み合わせ）は署名、暗号化、各種レベルのセキュリティなどを特に含むセキュリティ対策に関連付けることもできる。

ひとつの実施例として、セキュアストレージシステムはデータベースを部分的に復号化できるよう出力フィードバックモードを使用した暗号化法ないし復号化法を用いる。

さらなる実施例として、サービスの要求は、ブラウザ、ＨＴＴＰ対応ブラウザ、電子メール、ＦＴＰクライアントなどを特に含む、伝送プロトコルによって有効となるエンティティを介して送信される。

別の実施例では、クライアントシステムはユーザーが携帯する装置に対応付けられたものとする。

さらにひとつの実施例として、クライアントシステムを経由して、あるいは直接ＩＤ提供システムに、あるいはその両方で要求をＩＤ提供システムに送信することによって、サービス提供システムでＩＤ提供システムによるＩＤトークンの有効性検査を含むＩＤ認証プロセスを開始することも可能である。したがってシステム間の通信には３種類の経路が存在する。

クライアントシステム、サービス提供システム、ＩＤ提供システムの間の通信は、少なくとも部分的にインターネットや電話網や高周波数ネットワークのいずれかまたは複数を介して実行する。それらの伝送経路およびそれらの組み合わせを介して効率的な通信が可能である。

請求項１２の特徴を備えたコンピュータ通信システムによっても問題を解決することができる。

コンピュータ通信システムではクライアントシステムがあり、１つ以上のＩＤトークンを、暗号化されたデータベースなどのセキュアストレージシステムのデータベースに記憶し、あらかじめ記憶しておき、特に、ＩＤ提供システムによって生成される。
ａ）クライアントシステムによりサービス提供システムからサービスの要求を送信する手段。
ｂ）サービス提供システムがＩＤ認証プロセスを開始してＩＤ提供システムにＩＤトークンの有効性を検査させることができるようにするための手段。
ｃ）ＩＤ提供システムにより検査されたＩＤトークンの有効性検査の結果によって、要求されたサービスを提供するか拒否するかについてのサービス提供システムの決定を受信するための手段。

図面では以下の通り本発明のさまざまな実施例を例示的な方法で説明している。
図１は本方法の第１の実施例のシーケンス図を示す。 図２は本方法の第２の実施例のシーケンス図を示す。 図３は建物への出入りを制御する際に使用される本方法の実施例を示す図である。 図４はオンラインショッピングの処理における本方法の実施例を示す図である。 図５はセキュアストレージシステムの一部を復号化するための出力フィードバックモードの仕組みを示している。

図１には、クライアントシステム１０とサービス提供システム２０とＩＤ提供システム３０との間での基本的なデータとコマンドのやりとりを示している。

サービス提供システム２０（一般的には固定のコンピュータシステム）は、一般に、ＩＤ提供システム３０によって提供される識別データのＩＤコンシューマ（固定のコンピュータシステムと考えることができる）。サービス提供システム２０とＩＤ提供システム３０との信頼関係性があるものとする、サービス提供システム２０が各クライアントシステム１０の電子ＩＤの正当性に依存することができるように。一般的に、ＩＤ消費者からのＩＤ認証の要求には、ＩＤ提供システム３０を要求が有効であるかどうかを検査できるようににする属性が含まれる。

クライアントシステム１０は、例えば、デスクトップコンピュータ、組み込みシステム、タブレットコンピュータ、携帯電話などのデータ処理システム上で実行することができる。クライアントシステムは、例えば車の中に埋め込んで車中や車外のエンティティと通信できるようにすることができる。

以下の実施例では、主に、移動システム５０にあるクライアントシステム１０を用いて説明するが、本発明はこの具体的な実施例に限定するものではない。

後でも述べるが、このクライアントシステム１０には、例えば、セキュリティプロトコルを扱うことのできるソフトウェアコンポーネントを含めることもできる。あるいは、クライアントシステム１０は少なくとも部分的にコンピュータチップなどのハードウェアシステムに組み込むことができる。

クライアントシステム１０は、クライアントシステム１０で動作しているセキュアストレージシステム１２と接続する。セキュアストレージシステム１２には、複数のＩＤ項目１１Ａ、１１Ｂ、１１Ｃを含むＩＤトークン１１が少なくともひとつ格納されている。

データベースはセキュアストレージシステム１２として機能する。この実施例ではセキュアストレージシステム１２は実行可能ファイルであり、符号化された命令に従って特定のタスクを実行する。セキュアストレージシステム１２は、データベースを備えた（構造化）ファイルである。

この文脈でいうデータベースとは、データベース管理システムを用いて管理される論理的なコヒーレントな方法でデータを集めたものという意味である。認証済ユーザーにより実行可能ファイルが呼び出されると、データベース管理システムは、ファイルシステムをマウントすることなくデータベースへのアクセスを可能にする。セキュアストレージシステム１２のデータベースは、データベース管理システムの提供するインターフェースを介してしかアクセスすることができず、ひとつの実施例としては、ＳＱＬコマンドを受け付けてデータベースを照会する。

データベースによって特に要素（ここではＩＤトークン１１など）の記憶ができるようになり、その結果その要素に一意の識別子を割り当て、その要素を呼び出すために使用することができる。

セキュアストレージシステム１２を取り扱うためのデータベース管理システム７２（図６参照）には以下の機能をもたせることができる。
・データベースにアクセスするユーザーを認証する。ユーザーの認証を行うには、本方法の開始時に要求されていたとおり、ユーザーがＰＩＮコードを入力する必要がある。このＰＩＮコードは鍵導出関数（ＫＤＦ）に使用してＡＥＳ鍵などを計算し、これをセキュアストレージシステム１２の暗号化／復号化（下記参照）で使用する。
・データベースに格納されたＩＤトークン１１のリストを呼び出す。このリストには、ＩＤトークン１１の名前、ＩＤトークン１１のデータベース内ＩＤコード、ＩＤトークン１１のタイプのひとつ以上を含めることができる。リストの作成は、SELECT ID, Type, Name FROM databaseというＳＱＬコマンドによって達成することができる。
・データベース内にＩＤトークン１１を保存する。ＩＤトークン１１を保存する場合は、INSERT INTO database (Type, Name, Content) VALUES ("my datatype", "Name XY", "FOO")というＳＱＬコマンドに類似するコマンド。データベース内ＩＤはセキュアストレージシステム１２によって自動的に生成する。
・一意の識別子を使用してデータベースに格納されているＩＤトークン１１を呼び出す。この機能はＩＤトークン１１の保存と類似の方法で動作する。
・一意の識別子を使用してデータベースからＩＤトークン１１を削除する。この機能はＩＤトークン１１の保存と類似の方法で動作する。

セキュリティ上の理由から、セキュアストレージシステム１２のデータベース管理システムに設定される機能はこれらの機能に制限したほうが有用なこともある。

データベースは、物理的な形としては暗号化されたファイルである。すなわち、正しい鍵が認証中に供給されている場合は、データベースの内容のみ検索可能である。ここで説明している実施例では、１２８ビットの鍵長でＡＥＳアルゴリズムでＯＦＢ（出力帰還型）モードでファイルを暗号化することができる。別の実施例として、他の暗号化アルゴリズムや、他の鍵長（特により長いもの）を使用することもできる。

ＯＦＢモードは、データベースの区切りごとの復号化を可能にする、俗に言うブロックモードである。利点は、完全なデータベースは、ユーザーがデータベースの内容にアクセスしたいときに復号化される必要があることである。ＯＦＢモードの適用は、図５に関連して説明する。

ＩＤトークン１１は、個人または装置（この場合はクライアントシステム１０のユーザー）を識別する情報の電子的表現である。ＩＤトークン１１には、名前、電話番号等の情報など、人間の電子ＩＤに関連するデータを用いる。ＩＤトークン１１は電子署名で保護することができるし、暗号化することもできる。ＩＤトークン１１の異なる実施例に関するさらなる詳細は後で説明する。ＩＤトークン１１の受信者（例えばサービス提供システム２０）は、ＩＤトークン１１の有効性を検討する。

クライアントシステム１０は、商品を購入したり、保護されたリソースへのアクセス権を得たりするなど、ある種の保護されている資源を獲得するためにサービス提供システム２０へのアクセスを必要とする。ひとつの実施例として、サービス提供システム２０はウェブ店舗の一部としてもよい。

クライアントシステム１０はＩＤトークン１１を使用して認証が必要である。

認証はＩＤ提供システム３０を使用することによって達成される。これは、他のシステムに信頼できるＩＤ情報を与えることができる、信頼性のあるシステムであると考えるべきである。電子的に配信されたＩＤトークンの形式のＩＤ情報は、サービス提供システム２０がクライアントデバイス１０にサービスを提供するかクライアントシステム１０に対しサービスを保留するかを決定するための基礎となりうる。

図１に示したシーケンス図を見ながら説明するが、認証方法の実施例のひとつの前提条件は、何らかの時点でＩＤ提供部３０がＩＤトークン１１を生成１５することである。

図１は、ＩＤトークン１１に名前や電話番号などの複数のＩＤ項目１１Ａ、１１Ｂ、１１Ｃを含めることができることを示している。一人の人間あるいはひとつの装置について、各ＩＤがＩＤ項目１１Ａ、１１Ｂ、１１Ｃの組み合わせが異なるという意味で、何種類ものＩＤをもつことができるため、あらゆる取り引きにおいて例えば全ＩＤ情報の組み合わせを使用する必要はない。

ＩＤトークン１１はセキュアストレージシステム１２、すなわちデータベースを含む（構造化された）ファイルに格納する。これはＩＤトークン１１を個々のファイルとして見ることができないことを意味する。ＩＤトークン１１へのアクセスを得るために、セキュアストレージシステム１２を実行しなければならない。

セキュアストレージシステム１２は、クライアントシステム１０と接続する。すなわち、モバイル装置と同じハードウェア機器内に格納することができる。別の実施例としては、セキュアストレージシステム１２とクライアントシステム１０を異なる装置に格納する。

本方法の実施例はそれ自体がＩＤトークン１１を必要とするが、これはそれぞれの認証要求ごとに新しいＩＤトークン１１を生成しなければならないという意味ではない。認証方法の以下の手順では、ＩＤトークン１１がセキュアストレージシステム１２に存在している必要がある。

まずクライアントシステム１０はサービス提供システム２０にサービスを要求する。これは例えばオンライン販売者から書籍を注文する要求２１としてもよい。これはクライアントシステム１０で実行されるブラウザ４０（図２参照）から行うこともできる。

サービス提供システム２０はその要求２１を処理し、ＩＤトークン１１のあるセキュアストレージシステム１２を備えたクライアントシステム１０にメッセージを送信して認証プロセス２２を開始する。認証プロセス２２はこのＩＤトークン１１を使用して適切なＩＤ提供システム３０を照会２３する。

ＩＤ提供システム３０はＩＤトークン１１が有効であるかどうかを決定し、有効性についての情報をサービス提供部２０に返す。検査の有効性の結果に応じてサービスを提供するか、拒否する。

この方法では、ユーザーのクライアントシステム１０の電子ＩＤが提供される。ユーザーのＩＤの表現がクライアントシステム１０に格納されることで、ＩＤの分散型ストレージが実現できるようになる。これには、ＩＤデータを集中保管する必要がなく、システム全体のセキュリティが強化されるという利点がある。ＩＤ提供システム３０は個別のデータやＩＤトークン１１を何ら格納しない。ただＩＤ提供システム３０によってＩＤトークン１１が発行された（または発行されなかった）ということを述べることができるのみである。

図２には、図１で示したものにさらに特徴を加えた実施例が説明されている。特に、ブラウザシステム４０が追加のインスタンスとして示されている。電子ＩＤクライアント（ｅＩＤクライアント）１３とブラウザシステム４０はクライアントシステム１０の一部となっている。

１で示す工程では保護されたページを呼び出すＧＥＴ要求がサービス提供システム２０に送られる。サービス提供システム２０はＳＡＭＬ（Security Assertion Markup Language）要求1.1でブラウザシステム４０に応答し、その後ＳＡＭＬ要求1.1.1としてＩＤ提供システム４０に転送される。

ＳＡＭＬは、ＯＡＳＩＳ（構造化情報標準化推進機関）によって明確に定義された標準に従っているが、特別な使用シナリオを可能にするのに十分な柔軟性があるという利点がある。

ＩＤ提供システム３０はＳＡＭＬ要求を処理してアクティベーションリンクを含むページを送ってブラウザシステム４０に応答し（1.1.1.1）、ブラウザシステム４０はクライアントシステム１０内のＩＤクライアント１３を起動するための要求1.1.1.1.1を送信する。クライアントシステム１０内のＩＤクライアント１３は、ＨＴＴＰ応答コード１０２を送ってブラウザシステム４０に応答する。

次に、クライアントシステム１０内のＩＤクライアント１３とＩＤ提供システム３０との間でＥＡＣプロトコルを用いて通信を行う。要求に関連するＩＤがＩＤ提供システム３０に認識されている場合、この通信にはＩＤ提供システム３０への要求が用いられる。この場合、通信はブラウザシステム４０とＩＤ提供システム３０との間で継続される。これと並行して、ブラウザシステム４０とＩＤクライアント１３との間でポーリング作業を行い、処理の状態を確認する。

図示の実施例では、クライアントシステム１０内のＩＤクライアント１３との間の通信は、ＥＡＣ（拡張アクセス制御）プロトコルを使用する。ＥＡＣの認証し通信が完了した後、クライアントシステム１０のＩＤクライアント１３はブラウザシステム４０にステータス応答（2: REDIRECT）を送り、ＩＤ提供システム３０へリダイレクトさせる（1.1.1.1.2: Get Result）。

ＥＡＣ認証についてはドイツ連邦情報技術保安局(Bundesamt fur Sicherheit in der Informationstechnik)の発行する「ＢＳＩ ＴＲ−０３１１０機械可読旅行文書のためのの高度なセキュリティメカニズム」という文書に説明がある。

サービス提供システム３０はＳＡＭＬ応答（1.1.1.1.2.1）を送って応え、これが次にサービス提供システム２０（1.1.1.1.2.1.1）に転送される。

ＩＤトークン１１の正当性に基づいて、サービス提供システム２０は、保護されたリソースへのアクセスを許可するか拒否するかを自動的に決定する（1.1.1.1.2.1.2）。

以下では、ＩＤトークン１１の実施例に関するいくつかの詳細を与える。

ひとつの実施例として、ＩＤトークン１３はＸＭＬ構造化コードを含む。

以下のデータは、例えばＩＤトークン１３に格納することができる。バージョン番号、セキュリティレベル、ＩＤトークン１１の発行者の名前、データフィールド、ＩＤトークン１１の所有者によるＩＤトークン１１の電子署名、および／または発行者（すなわちＩＤ提供システム３０）によるＩＤトークン１１の電子署名。

ひとつの実施例として、例えば次の３種類のレベルのセキュリティを使用することができる。
ａ）人物を現実的に特定できる情報は提供しない。
ｂ）ＩＤトークン１１の作成中に、新しい電子ＩＤカードなど、何らかのＩＤドキュメントが使用されていた。
ｃ）ＩＤトークン１１の作成中に、資格のある署名付きのチップカードが使用されていた。

アップデートの場合の相互運用性を確保するために、バージョン番号を使用することもできる。

ＩＤトークン１１の発行者の名前はＵＵＩＤ（汎用一意識別子）、すなわち一意のＩＤトークン１１に固有のコードで表される。これはグローバルロック機構として機能する。ＵＵＩＤには程よい匿名性があるため、ＵＵＩＤからクライアントシステム１０の所有者まで逆にたどることは非常に困難であろう。

ユーザーデータはデータフィールドに格納する。これはタグ／値の構造で行うことができる。

ＩＤトークン１１の所有者の署名は、それぞれのデータが正しいと本物であることを保証する。

ＩＤ提供システム３０の署名は、サービス提供システム２０に対しそれが本物のＩＤトークン１１であることを保証する。サービス提供システム２０は、完全な電子署名を確認しなければならない。つまり、単に暗号的な正しさを検証するだけでは十分でない可能性がある。

ここで説明した方法とシステムの実施例は、さまざまなシナリオで使用することができる。

重要な用途のグループとして、クライアントシステム１０を備えている装置の識別がある。この装置は携帯電話などの移動可能なポータブルな装置とすることができる。しかし、パーソナルコンピュータ、自動車、メモリスティックなど、他の装置にもクライアントシステム１０を備え付けることができる。これらの装置は、ユーザーが使用することでサービス提供部との相互作用を支援することもできるが、自律的に使用することもできる。例えば、自動車であれば、サービス提供部２０と接続されたスキャナを通過することによって自身を識別することができる。あるいは人間がクライアントシステム１０を備えた装置を持ち運び、その装置でサービス提供部２０を利用して建物または領域への出入りを制御することができる。この用途は図３に一例として示す。

図３は、データを転送するためワイヤレス受信機／送信機に接続されたクライアント１０を備えた自動車６０を示している。自動車６０の運転手が要求するサービスは建物への出入りであり、自動車６０のＩＤに応じて開閉するバリア６１を用いてこれを表現している。

初めに、車６０のクライアントシステム１０は、バリア６１と接続されているサービス提供システム２０にサービスの要求２１を送信する。

次に、ＩＤ提供システム３０に要求することによって認証プロセスが開始されるが、その要求はクライアントシステム１０を介して送信される。要求２２はまずクライアントシステム１０に送信され、その後、この要求２３はどこか他の場所にあるＩＤ提供システム３０に送信される。

ＩＤ提供システム３０は入ってきたデータを検査し、受け取ったＩＤトークン１１を認証する。ＩＤトークンはＩＤ項目をひとつ以上含むものであるが、この例では自動車６０のナンバープレートに関する情報を含めることもできる。

ＩＤ提供システム３０は、ＩＤトークン１１が実際にシステムによって作成されたか（否か）を判定する。ＩＤトークン１１がＩＤ提供システム３０によって生成された場合にのみ、サービスを実際に提供することができることを示す返信２４がサービス提供部２０に送信される。今回の例では、バリアが持ち上げられて、制限エリアに車６０が入ることができるようになる（すなわちサービスが提供される）。

別の用途として、割り当てられた駐車時間を超過した車に用いる車輪止めにクライアント装置１０を埋め込むこともできる。ナンバープレート情報を伴うこともある適切な識別があるという条件で、サービス提供部２０で所定の車輪止め解除手数料を支払った後に車輪止めが取り外されるようにすることもできる。

これらの又は他の用途では、認証方法の実施例は、二者を拘束する法的な契約の決済手続に使用することも可能である。

図４ではオンラインショッピングを想定した認証処理を実証する。

ここでは人間がクライアントシステム１０を備えた携帯電話５０を使用する。クライアントシステム１０は携帯電話５０内に埋め込むか、携帯電話５０に接続するか、あるいはその両方とすることができる。いずれの場合でも、その人は、無線でデータを送信することができるクライアントシステム１０を制御できるのみである。

人間がサービス提供システム２０に対しサービスを要求２１する。この例でのサービスはその人に本を販売することである。

サービス提供システム２０はＩＤ提供システム３０にＩＤ情報を要求２２、２３する。そこでＩＤトークン１１が評価される。その結果はＩＤ提供部３０からサービス提供部２０に送信２４される。このサービス提供部２０は評価結果に基づいて販売を開始することもできる。

さらに、ソーシャルネットワークの文脈でも用途を見出すことができる。この場合、少なくともソーシャルネットワークの提供者にユーザーＩＤという明確な概念があることが重要である。

さらに、この方法の実施例は、携帯電話の契約などのようなオンライン加入を管理する文脈でも使用することができる。ここでは、すべてのデータは概してインターネット経由のみで利用可能である。安全な認証であるため、ユーザーとそのようなサービスの提供者にとって安全性が高まる。

図５では、セキュアストレージシステム１２の復号化での出力フィードバック（ＯＦＢ）モードの処理をさらに詳細に説明する。

ここでは、セキュアストレージシステム１２、すなわちデータベースファイルが長さ１２８ビットの鍵で暗号化される。暗号化あるいは復号化の各ステップでは１６バイトの区切りを暗号化または復号化することができる。続いて、ＡＥＳ規格に従って新たな鍵処理が行われ、次の１６バイトのブロックが暗号化あるいは復号化される。これはデータがブロック単位で処理されるためブロック暗号である。

図５は、平文からなる２個のブロック２０１、２０２を暗号化する場合におけるこのアルゴリズムの働きを示している。

最初の平文ブロック１０１（長さ１６バイト）に対し暗号鍵１０３を使用して最初の暗号化ステップ１０５を適用する。その結果が最初の暗号文ブロック１１１である。

しかし、同じ暗号鍵１０３を別の暗号化ステップ、すなわち二つ目の平文１０２を暗号化して二つ目の暗号文ブロック１１２を得る第二の暗号化ステップ１０６で使用することもできる。この第二の暗号化ステップ１０６は、最初の暗号化ステップ１０５と連続している必要はなく、図５に示すように双方は独立している。

それに加えて、暗号化ステップ１０５は、暗号化されたデータのエントロピーを増大させる初期化ベクトルに読み取ることができる可能性がある。

図５に示すように、ブロック単位で行われる暗号文ブロック１１１、１１２の復号は逆方向に働く。

図６では、セキュアストレージシステム１２と（クライアントシステム１０内の）電子ＩＤクライアント１３との接続をさらに詳細に示している。

データベースはＩＤトークン１１が格納されるセキュアストレージシステム１２のための構造となる。電子ＩＤクライアント１３はセキュアストレージシステム１２の入力と出力、特にＩＤ提供システム３０との通信を処理する。これによりＥＡＣプロトコルを実現でき、セキュアストレージシステム１２と通信するため、本実施例ではいくつもの層を含む。

通信の中心となるのはデータバンク管理システム７２であり、上述した機能の組を使用してセキュアストレージシステム１２へのアクセスを可能とする。

データベース管理システム７２は、ＡＰＩ（アプリケーションプログラミングインターフェイス）７１と接続する。さらに、それが暗号化層７３（上述のように例えばＡＥＳ ＯＦＢ １２８）に接続する。この階層構造は、セキュアストレージシステム１２の内容へのアクセスを得るにはどの層を用いなければならないかを示す。

特に、ＡＰＩ７１を介してセキュアストレージシステム１２にアクセスすることのみが可能である。

ＩＤクライアントシステム１３はセキュアストレージシステム１２から抽出することのみにより、ＩＤトークン１３へのアクセスを得ることができる。内部インターフェース７１（すなわちセキュアストレージシステムへのインターフェース）完全に機能を遮蔽するため、この抽出はＩＤクライアントシステム１３の論理層に対して透明である。

１０ クライアントシステム
１１ ＩＤトークン
１１Ａ、Ｂ、Ｃ ＩＤ項目
１２ クライアントシステムのセキュアストレージシステムであるデータベース
１３ 電子ＩＤクライアント（クライアントシステム内）
１５ ＩＤトークンの生成
２０ サービス提供システム
２１ サービス提供システムへのサービスの要求
２２ 認証プロセス、ＩＤ提供システムへの要求
２３ 認証プロセス、ＩＤ提供システムへの問合せ
２４ 認証プロセス、ＩＤ提供システムからの返信
３０ ＩＤ提供システム
４０ ブラウザシステム
５０ 可動ユニット
６０ 自動車
６１ バリア
７１ アプリケーションプログラミングインタフェース層
７２ データベース管理システム
７３ 暗号化層
１０１ 第一平文
１０２ 第二平文
１０３ 暗号鍵
１０５ 第一暗号化ステップ
１０６ 第二暗号化ステップ
１１１ 第一暗号ブロック
１１２ 第二暗号ブロック

Claims (12)

1. サービス提供システム（２０）に対してクライアントシステム（１０）を認証する方法であって、
   ａ）ＩＤ提供システム（３０）によって生成され、名前、ＩＤ番号、クレジットカード番号、指紋、生体認証記録などのＩＤ項目（１１Ａ、１１Ｂ、１１Ｃ）からなる少なくとも１種のＩＤトークン（１１）がセキュアストレージシステム（１２）としての暗号化データベースに記憶されているかあるいはあらかじめ記憶させておき、
   ｂ）クライアントシステム（１０）によってサービス提供システム（２０）にサービスを要求する要求（２１）を送り、
   ｃ）サービス提供システム（２０）がＩＤ提供システム（３０）による少なくとも１種のＩＤトークン（１１）の有効性検査を含むＩＤ認証処理（２２、２３）を開始し、
   ｄ）ＩＤ提供システム（３０）が検査した少なくとも１種のＩＤトークン（１１）の有効性検査に基づいてサービス提供システム（２０）が要求されたサービスを提供または拒否（２４）し、
   前記セキュアストレージシステム（１２）が、
   １）ユーザーがデータベースにアクセスするのを認証する機能と、
   ２）データベースに格納されたＩＤトークンのリスト（１１）を呼び出す機能と、
   ３）ＩＤトークン（１１）をデータベースに格納する機能と、
   ４）一意の識別子を使用してデータベースに格納されたＩＤトークン（１１）を呼び出す機能と、
   ５）一意の識別子を使用してデータベース内のＩＤトークン（１１）を削除する機能
   を備えたデータベース管理システム（７２）に、あるいは特にこれらの機能のみを備えたデータベース管理システム（７２）に接続されていることを特徴とする方法。
2. 請求項１の方法であって、少なくとも１種のＩＤトークン（１１）を含んだセキュアストレージシステム（１２）が携帯電話、メモリスティック、ＲＦＩＤ機器などを特に含む移動可能な装置（５０）に保存されていることを特徴とする方法。
3. 請求項１または２の方法であって、ＩＤトークン（１１）を含むセキュアストレージシステム（１２）がパーソナルコンピュータ、自動車などの車両のいずれかに格納されていることを特徴とする方法。
4. 請求項１〜３のいずれかの方法であって、セキュアストレージシステム（１２）が実行可能ファイルの一部であることを特徴とする方法。
5. 請求項１〜４のいずれかの方法であって、セキュアストレージシステム（１２）が鍵導出関数手段を含むことを特徴とする方法。
6. 請求項１〜５のいずれかの方法であって、１種以上のＩＤトークン（１１）のＩＤ項目（１１Ａ、１１Ｂ、１１Ｃ）が署名、暗号化、各種レベルのセキュリティなどを特に含むセキュリティ対策に関連付けられたものであることを特徴とする方法。
7. 請求項１〜６のいずれかの方法であって、データベースの部分的な復号化ができるようセキュアストレージシステム（１２）が出力フィードバックモードを使用した暗号化法ないし復号化法を用いることを特徴とする方法。
8. 請求項１〜７のいずれかの方法であって、サービスの要求（２１）が、ブラウザ（４０）、ＨＴＴＰ対応ブラウザ（４０）、電子メール、ＦＴＰクライアントなどを特に含む、伝送プロトコルによって有効となるエンティティの少なくともひとつを介して送信されることを特徴とする方法。
9. 請求項１〜８のいずれかの方法であって、クライアントシステム（１０）がユーザーの携帯する装置と対応付けられていることを特徴とする方法。
10. 請求項１〜９のいずれかの方法であって、クライアントシステム（１０）を介して、あるいは直接ＩＤ提供システム（３０）に、あるいはその両方でＩＤ提供システム（３０）に要求を送信することによって、サービス提供システム（２０）がＩＤ提供システム（３０）によるＩＤトークン（１１）の有効性検査を含むＩＤ認証プロセス（２２、２３）を開始することを特徴とする方法。
11. 請求項１〜１０のいずれかの方法であって、クライアントシステム（１０）、サービス提供システム（２０）、ＩＤ提供システム（３０）のうちの少なくとも二者間の通信が少なくとも部分的にインターネット、電話網、高周波数ネットワークの少なくともひとつで行われることを特徴とする方法。
12. クライアントシステム（１０）とのコンピュータ通信システムであって、
    ＩＤ提供システム（３０）によって生成され、名前、ＩＤ番号、クレジットカード番号、指紋、生体認証記録などのＩＤ項目（１１Ａ、１１Ｂ、１１Ｃ）からなる少なくとも１種のＩＤトークン（１１）がセキュアストレージシステム（１２）としての暗号化データベースに記憶されているかあるいはあらかじめ記憶させてあり、
    ａ）クライアントシステム（１０）によってサービス提供システム（２０）へのサービスの要求（２１）を送る手段と、
    ｂ）ＩＤ提供システム（３０）による少なくとも１種のＩＤトークン（１１）の有効性検査を含むＩＤ認証プロセス（２２、２３）を開始させ、サービス提供システム（２０）にできるようにする手段と、
    ｃ）ＩＤ提供システム（３０）によって検査された少なくとも１種のＩＤトークン（１１）の有効性検査に基づいてサービス提供システム（２０）が要求されたサービスを提供するか拒否するか（２４）の決定を受信するための手段
    を備えており、
    前記セキュアストレージシステム（１２）が、
    １）ユーザーがデータベースにアクセスするのを認証する機能と、
    ２）データベースに格納されたＩＤトークンのリスト（１１）の呼び出す機能と、
    ３）ＩＤトークン（１１）のデータベースへの格納する機能と、
    ４）一意の識別子を使用してデータベースに格納されたＩＤトークン（１１）の呼び出す機能と、
    ５）一意の識別子を使用してデータベース内のＩＤトークン（１１）を削除する機能
    を備えたデータベース管理システム（７２）に、あるいは特にこれらの機能のみを備えたデータベース管理システム（７２）に接続されている
    ことを特徴とするコンピュータ通信システム。

Images