(57)【特許請求の範囲】
【請求項１】
コンピュータ装置であって、
安全プロセスおよび認証プロセスの命令を記憶するメモリ手段と、
前記安全プロセスおよび前記認証プロセスの実行を含めて前記コンピュータ装置の動作を制御するように構成された処理手段と、
ユーザ入力を受け取り、該ユーザ入力に応答して前記処理手段によって生成された情報をユーザに返すように構成されたユーザ・インタフェース手段と、
取り出し可能な主カードを受け取るためのカード・インタフェース手段と、を備え、
前記主カードは、前記カード・インタフェース手段に接続するためのインタフェースと、カード・プロセッサと、主カードを識別する識別情報および許可済みの１つまたは複数の補助カードを識別する補助カード識別情報を含むデータを記憶するメモリとを備え、
前記処理手段は、前記主カードから前記識別情報および前記補助カード識別情報を受け取り、前記認証プロセスを使用して該主カードを認証し、該主カードの認証が成功した場合、前記ユーザ・インタフェース手段を介してユーザと前記安全なプロセスとの間のセッションを可能にするように構成され、
前記処理手段は、前記主カードを繰り返して認証し、該主カードが取り出されたときは、前記補助カード識別情報によって識別される前記許可済みの補助カードによって前記主カードが置き換えられていなければ、前記セッションを前記コンピュータ装置に中止させ、前記許可済み補助カードによって前記主カードが置き換えられていれば、前記安全なプロセスと前記許可済みの補助カードとの間でセッションさせるよう構成されている、コンピュータ装置。
【請求項２】
前記コンピュータ装置は、該コンピュータ装置の完全性を表す情報を生成してこの完全性情報を前記主カードに送信するように構成され、
前記カード・プロセッサは、前記完全性情報の使用によることを含め前記コンピュータ装置の完全性を検証するようにプログラムされる、請求項１に記載のコンピュータ装置。
【請求項３】
前記補助カードはキャッシュ・カードであり、前記安全なプロセスが該カードからクレジットまたはデビットを取得するように構成された、請求項１または２に記載のコンピュータ装置。
【請求項４】
前記補助カードは、データを暗号化、解読または署名するようにプログラムされた暗号カードであり、
前記安全プロセスは、暗号化、解読または署名されるべきデータを前記暗号カードに送信し、暗号化、解読または署名されたデータを該暗号カードから受け取るように構成された、請求項１または２に記載のコンピュータ装置。
【請求項５】
補助カードが前記許可済み補助カードである場合にのみ、前記セッションを可能にするように構成された、請求項１から４のいずれかに記載のコンピュータ装置。
【請求項６】
前記コンピュータ装置は、あるタイムアウト間隔を持つようにプログラムされたタイマ手段を更に備え、
補助カードが前記許可済み補助カードである場合、前記コンピュータ装置は前記タイマをリセットし、前記タイムアウト間隔が経過するまで動作を継続し、その後、前記安全プロセスとのセッションを中止する、請求項１から４のいずれかに記載のコンピュータ装置。
【請求項７】
前記補助カードが前記主カードにより取り替えられかつ前記コンピュータ装置が前記主カードを認可可能である場合、前記セッションを再開するように構成された、請求項６に記載のコンピュータ装置。
【請求項８】
前記主カードの取り出しの後、前記安全なプロセスとただ１つの許可済み補助カードとの間のセッションを可能にするように構成された、請求項１から７のいずれかに記載のコンピュータ装置。
【請求項９】
前記主カードの取り出しの後、前記安全プロセスと複数の前記許可済み補助カードとの間のセッションを可能にするように構成された、請求項１から７のいずれかに記載のコンピュータ装置。
【請求項１０】
前記処理手段は主処理ユニットと安全処理ユニットとを備え、前記メモリ手段は主メモリと安全メモリとを備える、請求項１から９のいずれかに記載のコンピュータ装置。
【請求項１１】
前記コンピュータ装置は前記安全処理ユニットと前記安全メモリを組み入れた信頼された装置を含み、該信頼された装置は前記主カードを繰り返し認証するようにプログラムされた、請求項１０に記載のコンピュータ装置。
【請求項１２】
前記信頼された装置は前記コンピュータ装置の安全性メトリックを取得するように構成され、
前記主カードは前記完全性メトリックを少なくとも１度使用して前記コンピュータ装置の安全性を検証するように構成された、請求項１１に記載のコンピュータ装置。
【請求項１３】
前記主カードがスマートカードからなり、前記インタフェース手段は該スマートカードを受け取るように構成された、請求項１から１２のいずれかに記載のコンピュータ装置。
【請求項１４】
前記補助カード情報はユーザ・プロフィールに保存される、請求項１から１３のいずれかに記載のコンピュータ装置。
【請求項１５】
ユーザを認証するためにコンピュータ装置により実行される方法であって、
主カードを識別する識別情報および該主カードとともに使用することが許された許可済みの１つまたは複数の補助カードを識別する補助カード識別情報をメモリに含む取り出し可能な前記主カードを前記コンピュータ装置が受け取るステップと、
前記主カードが真正なものである場合、コンピュータ・プラットフォームにより実行可能である１つまたは複数の安全なアプリケーションと前記ユ−ザとの間のセッションを前記コンピュータ装置が許可するステップと、
周期的に前記主カードを前記コンピュータ装置が再認証するステップと、
前記主カードが取り出された場合、前記補助カード識別情報によって識別される前記許可済みの補助カードにより前記主カードが置き換えられていなければ、前記コンピュータ装置が前記セッションを中止させ、前記許可済みの補助カードにより前記主カードが置き換えられていれば前記安全なプロセスと前記許可済みの補助カードとの間でセッションさせるステップと、
を含むユーザ認証方法。
【請求項１６】
前記コンピュータ装置が完全性メトリック情報を前記主カードに提供するステップと、
前記主カードが前記完全性メトリック情報を使用して前記コンピュータ装置の完全性を検証するステップと、
前記主カードが前記コンピュータ装置の完全性を検証することができない場合、前記セッションを中止するステップと、
を更に含む、請求項１５に記載のユーザ認証方法。
【請求項１７】
前記コンピュータ装置が、限られた時間の間前記許可済み補助カードと対話する、請求項１５または１６に記載のユーザ認証方法。
【請求項１８】
前記主カードの取り出しの後、前記コンピュータ装置がただ１つの許可済み補助カードとのセッションを許可する、請求項１５から１７のいずれかに記載のユーザ認証方法。
【請求項１９】
前記主カードの取り出しの後、前記コンピュータ装置が複数の許可済み補助カードとの間のセッションを許可する、請求項１５から１７のいずれかに記載のユーザ認証方法。
【請求項２０】
請求項１５から１９のいずれかに記載の方法に従って動作するようにプログラムされたコンピュータ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータ装置に関し、特に、セキュリティ・トークンを使用する安全な環境におけるコンピュータ装置および該コンピュータ装置の動作方法に関する。
【０００２】
【従来の技術】
最近、コンピュータ・プラットフォーム(または"ホスト・プラットフォーム")へのアクセスおよび電子商取引を含む種々のセキュリティ機能のため例えばスマートカード(smart card)または暗号コプロセッサのようなセキュリティ・トークンが提唱されている。例えば、関連したユーザのみにアクセス可能な秘密情報を記憶するスマートカードは、コンピュータにログオンするため、文書に署名するため、または電子商取引のために必要とされる信用証明書を提供するため、当該ユーザによって使用されることができる。
【０００３】
いくつかのケースにおいて、ユーザがホスト・プラットフォームにログオンする時始まりユーザがログオフする時終了する単一対話セッションにおいて複数の異なるアプリケーションのため１つ以上のセキュリティ・トークンが使用される必要があることが予想される。
【０００４】
次のように動く１つのモデルが想定される。１人のユーザが多数のトークンを持ち、各セッションにおいて、ログオン処理においてのみホスト・プラットフォームへの認証のためこれらトークンのうちの１つ(例えばログオン・トークン)をこのユーザが使用する。同じセッションの間に、該ユーザは、他のセキュリティ機能(例えば電子支払または暗号化)のため他のトークン(例えば補助トークン)を別途使用する。
【０００５】
【発明が解決しようとする課題】
上記モデルに関して、以下のような３つの潜在的問題が認められる。
【０００６】
問題Ａ−ユーザがホスト・プラットフォームにログオンした後立ち去り、そのため詐称者がそのプラットフォームを使用することが可能となるという固有の危険がある。
【０００７】
問題Ｂ−偽のホスト・プラットフォームが機密に関わる情報を該ユーザから盗むことが可能である。
【０００８】
問題Ｃ−補助トークンの中には、その所有者の識別をログオン・トークンの所有者にまで追跡することができないものがある。すなわち、ログオン・トークンを所有しない詐称者が、詐称者自身の補助トークンを使用してログオン・トークンの所有者に扮することが可能である。
【０００９】
【課題を解決するための手段】
上記の問題の１つまたは複数に対処するため、本発明は、セキュリティ・リスクを減少し、ホスト・プラットフォームと複数のセキュリティ・トークンとの間に一層信頼できる関係を確立する新しい構成を提案する。該構成は、典型的には、周期的または反復的認証を含むセキュリティ制御ポリシを実行するものであり、このポリシは従来技術モデルにおけるポリシより一層洗練されたものである。本発明の好ましい実施形態は、相互認証および特権制限を実行する。従来技術に比べて、使い易さおよび実施の低コストという基準が特に重要である。
【００１０】
第１の側面において、本発明が提供するコンピュータ装置は、安全プロセスおよび認証プロセスの命令を記憶するメモリ手段、前記安全プロセスおよび前記認証プロセスの実行によることを含め当該コンピュータ装置の動作を制御するように構成された処理手段、ユーザ入力を受け取り、該ユーザ入力に応答して前記処理手段によって生成される情報を当該ユーザに返すように構成されたユーザ・インタフェース手段、取り出し可能な主トークンを受け取り該トークンと対話するためのインタフェース手段を備える。特に、前記トークンの基部（ぼでぃ、body）が、前記インタフェース手段と対話するためのトークン・インタフェース、トークン・プロセッサ、および、該トークンを識別するための情報を含むトークン・データおよび１つまたは複数の許可済み補助トークンを識別する補助トークン情報を記憶するトークン・メモリをサポートし、前記処理手段が、前記主トークンから前記識別情報および前記補助トークン情報を受け取り、前記認証プロセスを使用して該トークンを認証し、トークンの認証が成功すれば、前記ユーザ・インタフェース手段を通してユーザが安全プロセスと対話することを可能にするように構成されている。更に、前記処理手段は、繰り返して前記主トークンを認証し、主トークンの取り出しの結果として認証が可能でなくなれば主トークンが許可済み補助トークンと置き換えられない限り安全プロセスとユーザとの間の対話を計算プラットフォーム（computing platform）に停止させるように構成されている。
【００１１】
第２の側面において、本発明は、ユーザを認証するためコンピュータ装置を制御する方法を提供する。該方法は、該ユーザの主トークンを認証するために適する情報および１つまたは複数の許可済み補助トークンに関する情報を含む主トークンを該コンピュータ装置が受け取るステップ、受け取ったトークンが真正であれば、当該コンピュータ装置によって実行される可能性のある１つまたは複数の安全アプリケーションと前記ユーザが対話することを可能にするステップ、周期的に前記主トークンを再認証するステップ、および、主トークンを再認証することが可能でなければ主トークンが許可済み補助トークンと置き換えられてない限り該コンピュータ装置とユーザとの間の対話を停止させるステップを含む。
【００１２】
第３の面において、本発明は、前記方法に従って主トークンとして動作するようにプログラムされたスマートカードを提供する。
【００１３】
第４の面において、本発明は、前記方法に従って動作するように構成されたコンピュータ装置を提供する。
【００１４】
【発明の実施の形態】
本発明の概念は包括的なものではあるが、議論を容易にするため、下記において、好ましい実施形態に焦点が当てられる。本発明の好ましい実施形態において、スマートカードは、計算プラットフォーム（コンピュータ・プラットフォームまたは単にプラットフォームとも呼ばれる）と対話するセキュリティ・トークンである。本明細書の目的から、計算プラットフォームは、少なくとも１つのデータ・プロセッサおよび少なくとも１つのデータ記憶手段を示すように使用される。この計算プラットフォームは、必須とは限らないが通常は、複数のドライバ、関連するアプリケーションおよびデータ・ファイルのような通信と関連づけられ、例えばインターネットへの接続、外部ネットワークへの接続などの手段によって、あるいは、例えばＣＤ−ＲＯＭ、フロッピーディスク、リボン・テープなどのデータ記憶媒体上に記憶されているデータを受け取ることができる入力ポートを備えることによって、ユーザまたは別のコンピュータ・プラットフォームなどの外部エンティティと対話することができる。上記構成において、ユーザは、１つのログオン・スマートカードおよび多数の補助スマートカードを持ち、ただ１つのスマートカード読取装置を持つプラットフォームと対話する必要がある。本実施形態において、同時に２枚以上のスマートカードをスマートカード読取装置で読み取ることはできないと仮定している。
【００１５】
発明の課題において記述された問題Ａに対処するため、本実施形態は、前記プラットフォームに関連して動作するログオン・スマートカードを使用する首尾一貫したセキュリティ制御ポリシを実行する。具体的には、合法的ユーザの知識を持たないプラットフォームへのアクセスを行う詐称者に関する潜在的可能性を制限するため、単にセッションを開始する場合というよりはむしろセッションを通してログオン・スマートカードが存在しなければならない。換言すれば、ログオン・スマートカードは、ドアの鍵ではなく車の鍵のように使用される。
【００１６】
実際、ユーザはその行動に対して責任がある状態に置かれる。命令の実行の間スマートカードが存在しなければならないので、これは、効率的にかつ明確に、スマートカードの所有者をしてそのアクションに対して責任を持たせることができる。以下に記述されるように、好ましい実施形態において、認証は、プラットフォームによって自動的に行われ、ユーザからのアクションを概ね必要としない。この点は、ユーザの時間の節約に役立つので、非常に魅力的な機能である。
【００１７】
本発明が提案する方式の主要な利点はその直観的訴えにある。人々は、彼らの鍵を保護することの重要性を十分認識していて、鍵のそれぞれの誤用に対する全責任を受け入れる。セキュリティを大幅に強化する本方式は実施が容易である。付加されるセキュリティ機構として、ログオン・スマートカードがパスワードで保護されていることが好ましい。これは、カードが最初にスマートカード読取装置に挿入される時パスワードを入力することをユーザに要求するものである。パスワード技法はよく知られているので、本発明を不明確にすることを避けるため本明細書においてその説明は行わない。
【００１８】
一般的に述べれば、ログオン・スマートカードの存在を検査するため、プラットフォームは、ログオン・カードの認証を反復する必要がある。認証の実際の頻度は、システム管理者またはユーザによって設定されることができる。実際には、頻度は、ユーザまたは未許可ユーザがプラットフォームを破壊し認証と認証の間に未許可の処理を実行することができないような間隔に設定される。例えば、認証は２、３秒ごとに実行されるかもしれない。
【００１９】
セキュリティ・ポリシにおいて実行されることができる更なるセキュリティ機構は、補助スマートカードを使用する認証されたセッションの各々に対する制限時間である。あらかじめ設定された制限時間の範囲内で認証の新しいラウンドが実行されない限り、ユーザ・インタフェースはロックされる。更に、好ましくは、タイムスタンプ機能または一時的ワードの使用が、認証の間の"再実行攻撃"を防止するため使用される。
【００２０】
発明の課題において記述された問題Ｂすなわち偽ホスト・プラットフォーム問題に対処するため、本発明の好ましい実施形態は、プラットフォームに組み入れられる"信頼できる装置"の概念を使用して、ユーザがプラットフォームの信頼性を検証することを可能にする。そのような"信頼できる装置"の概念は、2000年２月１５日付の国際特許出願"Trusted Computing Platform"に記載されている。
【００２１】
発明の課題において記述された問題Ｃ、すなわち、補助スマートカードがログオン・スマートカードの所有者まで追跡することができないという問題に対処するため、本発明は、ユーザを多数の補助スマートカードに結合させるユーザ・プロフィールの概念を導入する。これによって、首尾一貫した、包括的で柔軟なセキュリティ制御ポリシの実施が、ユーザにとって非常に単純で廉価で透明なものとされる。
【００２２】
一般的に述べれば、好ましい実施形態において、ログオンはログオン・スマートカードによって行われ、セッションのどこかの時点で、ユーザ(または当該セッションの下で動くアプリケーション)が１つまたは複数の補助カードを挿入することを必要とし、その際ログオン・カードの取り出しが必要となるように仮定される。反復認証というセキュリティ・ポリシを維持するため、ログオン・スマートカードに対する信頼付与と他の補助スマートカードに対する信頼付与との間でプラットフォームに関するセキュリティ連鎖が存在する必要がある。ログオン・スマートカードをして例えば"ユーザ・プロフィール"の使用を通して補助カードをプラットフォームに"導入させる"ことによって、この連鎖が構築される。
【００２３】
記述の簡略化のため、以下の記述において、"キャッシュカード"および"暗号カード"という２種類の補助スマートカードだけが考慮される。"キャッシュカード"は、移転可能な現金額(すなわちクレジット額)を持つスマートカードであり、"暗号カード"は、その特権(例えば秘密鍵によってサポートされた暗号または署名)が移転可能とされてないスマートカードである。
【００２４】
本発明の実施形態において使用される"信頼できるプラットフォーム"をここで説明する。これは、物理的な信頼できる装置のコンピュータ・プラットフォームへの組込みによって達成される。この物理的な信頼できる装置は、プラットフォームの信頼性メトリックを提供する測定されたデータにプラットフォームの識別を結合する機能を有する。これら識別情報および信頼性メトリックが、プラットフォームの信頼性を保証するように準備されている信頼できる機関によって提供される期待値と比較される。(注：以下の記述において、"信頼できる機関"は、その英語表記である"trusted party"の頭文字をとって"ＴＰ"と略称される場合がある。) 一致すれば、信頼性メトリックの範囲に応じて、少なくともプラットフォームの一部が正しく動作していることを意味する。
【００２５】
ユーザは、他のデータをプラットフォームと交換する前にプラットフォームの正しい動作を検証する。これは、ユーザが信頼できる装置にその識別と信頼性メトリックを提供するように要求することによって行われる。(オプションとして、信頼できる装置自体がプラットフォームの正しい動作を検証することができなければ、信頼できる装置は識別の証拠を提供することを拒否するであろう)。ユーザは、識別の証明および識別メトリックを受け取って、それらを真実であると信じる値と比較する。そのような適切な値は、ユーザによって信頼されているＴＰまたは別のエンティティによって提供される。信頼できる装置によって報告されるデータがＴＰによって提供されるものと同じであれば、ユーザは、そのプラットフォームを信頼する。これは、ユーザが当該エンティティを信頼するからである。エンティティは、前もってその装置の識別の有効性を確認し、そのプラットフォームの適切な信頼性メトリックを決定しているので、そのプラットフォームを信頼する。
【００２６】
一旦ユーザがプラットフォームの信頼できる動作を確立すれば、ユーザはその他のデータをプラットフォームと交換する。ローカルのユーザについては、そのような交換は、プラットフォーム上で動くいくつかのソフトウェア・アプリケーションと対話することで行われるであろう。遠隔ユーザの場合、交換は安全なトランザクションを必要とするかもしれない。いずれにせよ、交換されるデータは、信頼できる装置によって"署名される"。このようにして、ユーザは、動作が信頼できるプラットフォームとそのデータが交換されているという一層大きい確信を持つことができる。
【００２７】
信頼できる装置は、暗号プロセスを使用するが、そのような暗号プロセスに対する外部インタフェースを必ずしも提供するというわけではない。また、一層望ましい実施形態は、信頼できる装置を不正操作不可能とし、他のプラットフォーム機能に対するアクセスを不可能にすることによって秘密保護を行い、未許可の修正に対して実質的に防護された環境を提供することである。不正操作防止は不可能であるので、不正操作に抵抗力のあるまたは不正操作検出可能な信頼できる装置が次善の策である。従って、信頼できる装置は、好ましくは、不正操作抵抗力のある１つの物理的コンポーネントから成る。
【００２８】
不正操作抵抗力に関連した技法は、セキュリティの分野の専門家には周知のものである。そのような技法は、(信頼できる装置の適切なカプセル化のような)不正操作抵抗方法、(仕様電圧、Ｘ線逸脱の検出、または信頼できる装置枠における物理的信頼性の喪失の検出のような)不正操作検出方法、および不正操作検出の時データを削除する方法などを含む。更に、いくつかの適切な技法が、"Tamper Resistance-a Cautionary Note, by Ross Anderson and Markus Kuhn, published in the Second USENIX Workshop on Electronic Commerce Proceedings, Oakland, California, November 1996, pp1-11, ISBN 1-80446-83-9"に記載されている。理解されることであろうが、不正操作抵抗方法は本発明の最も望ましい機能であるとはいえ、それは、本発明の通常の動作に含まれず、従って、本発明の適用範囲外にあり、ここで詳細な記述は行わない。
【００２９】
信頼できる装置は、製作が困難でなければならないので、好ましくは物理装置であり、また、偽造が困難でなければならないので、最も好ましくは、不正操作抵抗機能を持つ。信頼できる装置は、ローカルおよび遠隔の両方で識別を証明することが必要とされるので、典型的には、暗号化プロセスを使用する能力を持つエンジンを備え、関係するプラットフォームのなんらかの信頼性メトリックを測定する少なくとも１つの方法を含む。
【００３０】
図１には、信頼できるプラットフォーム１０が例示されている。プラットフォーム１０は、プラットフォームの物理的"ユーザ・インタフェース"を提供するため、キーボード１４、マウス１６および表示装置(ＶＤＵ)１８という標準的機構を含む。信頼できるプラットフォームの本実施形態は、また、スマートカード読取装置１２を含む。スマートカード読取装置１２は、すべての信頼できるプラットフォームの必須エレメントではないが(すべての信頼できるプラットフォームがスマートカードを使用するというわけではないが)、以下に記述される本発明にとって適切な種々の好ましい実施形態において用いられる。スマートカード読取装置１２の横には、スマートカード１７および(可能性としていくつかの)補助スマートカード１９が示されている。これらカードは、以下に記述されるように、信頼できるプラットフォームとのユーザ対話を可能にする。プラットフォーム１０には、複数のモジュール１５が含まれる。これらは、該プラットフォームにとって適切なその他の機能エレメントであり、本質的にどのような種類のものでもよい(そのようなエレメントの機能は本発明にとって重要な意味を持つものではないので、これ以上の記述は行わない)。
【００３１】
図２に示されているように、信頼できるコンピュータ・プラットフォーム１０のマザーボード２０は、主プロセッサ２１、メイン・メモリ２２、信頼できる装置２４、データ・バス２６、それぞれの制御線２７および線２８、プラットフォーム１０と入出力装置(ＩＯ)２３に関するＢＩＯＳプログラムを含むＢＩＯＳメモリ２９を含む。ＢＩＯＳプログラムは、マザーボード、スマートカード読取装置１２、キーボード１４、マウス１６およびＶＤＵ１８というコンポーネントの間の対話を制御する。メイン・メモリ２２は、典型的には、ランダム・アクセス・メモリ(ＲＡＭ)である。動作に関しては、プラットフォーム１０は、ハードディスク(図示されていない)からＲＡＭへオペレーティング・システム(例えばウインドウズＮＴ）をロードする。更に、プラットフォーム１０は、プラットフォーム１０によって実行されるプロセスまたはアプリケーションをハードディスク(図示されてない)からＲＡＭにロードする。
【００３２】
パーソナル・コンピュータにおいて、典型的には、ＢＩＯＳプログラムは、特別な予約メモリ領域に置かれる。特別な予約メモリ領域の最初の上位６４ＫＢは、システム・メモリ(アドレスF000hからFFFFh)であって、主プロセッサは、業界標準に従って、このメモリ位置を最初に見に行くように構成される。
【００３３】
当該プラットフォームと従来のプラットフォームとの重要な相違は、リセットの後、主プロセッサは信頼できる装置によって初期的に制御され、プラットフォーム固有のＢＩＯＳプログラムへ制御が渡され、次に、通常通りすべての入出力装置が初期化される点である。ＢＩＯＳプログラムの実行後、通常通り、典型的にはハードディスク装置(図示されてない)からメイン・メモリ２２にロードされるウインドウズＮＴのようなオペレーティング・システム・プログラムへＢＩＯＳプログラムによって制御が渡される。
【００３４】
明らかなように、このような通常手続きからの変更は、業界標準の実施形態に対する修正を必要とする。この修正は、主プロセッサ２１が信頼できる装置２４をアドレスしてその最初の命令を受け取るようにするものである。この変更は、単に、主プロセッサ２１に異なるアドレスをハードコードすることによって達成される。代替的方法としては、信頼できる装置２４に標準ＢＩＯＳプログラム・アドレスを割り当てることも可能であり、これは、主プロセッサ構成に何の変更をも必要としない。
【００３５】
ＢＩＯＳブート・ブロックが信頼できる装置２４の範囲内に含まれることは非常に望ましい。これは、(悪者ソフトウェア・プロセスが存在する場合発生するおそれのある)信頼性メトリックの取得の破壊を防止し、ＢＩＯＳが(たとえ正しいとしても)オペレーティング・システムのための適切な環境を構築することに失敗する状況を悪者ソフトウェア・プロセスが作り出すことを防止する。
【００３６】
以下に記述される好ましい実施形態において、信頼できる装置２４が単一の、離散的なコンポーネントであるとはいえ、代替的形態として信頼できる装置２４の機能をマザーボード上の複数の装置に分割することも、あるいは、プラットフォームの従来型標準装置の１つまたは複数に組み込むことさえ可能である。例えば、諸機能およびそれら対話が破壊されることができないと仮定すれば、主プロセッサに信頼できる装置の１つまたは複数の機能を主プロセッサに統合することは可能である。しかしながら、この構成は、プロセッサが信頼できる機能によってのみ使用されることを必要とすることになるであろう。更に、本実施形態において、信頼できる装置はマザーボード２０への統合に適応されるハードウェア装置であるが、代替的に、必要に応じてプラットフォームに接続することができるドングルのような"取り外し可能な"装置として実施することも可能である。信頼できる装置が統合された装置か取り外し可能な装置かは設計選択の問題である。しかしながら、信頼できる装置が分離できるものである場合、信頼できる装置とプラットフォームの間の論理的結合を提供するメカニズムが存在しなければならない。
【００３７】
図３に示されているように、信頼できる装置２４は多数のブロックを含む。システム・リセットの後、信頼できる装置２４は、安全なブーツ・プロセスを実行して、(システム・クロックおよび表示装置を含む)プラットフォーム１０のオペレーティング・システムが適切にかつ安全な形態で実行していることを確認する。安全ブーツ・プロセスの間、信頼できる装置２４は、コンピュータ・プラットフォーム１０の信頼性メトリックを取得する。信頼できる装置２４は、また、安全なデータ転送、および、例えば、暗号／解読および署名／検証を介して信頼できる装置とスマートカードの間の認証を実行することができる。信頼できる装置２４は、また、ユーザ・インタフェースのロックのような種々のセキュリティ制御ポリシを安全に実施することができる。
【００３８】
信頼できる装置は、具体的には、信頼できる装置２４の動作全体を制御し、信頼できる装置２４のその他の機能およびマザーボード２０のその他の装置と対話するようにプログラムされたコントローラ３０、プラットフォーム１０から信頼性メトリックを取得する測定機能３１、指定されたデータを署名、暗号化または解読する暗号機能３２、スマートカードを認証する認証機能３３、および、適切なポート(３６、３７、３８)を有し、マザーボード２０のデータ・バス２６、制御線２７、およびアドレス線２８のそれぞれに信頼できる装置２４を接続するインタフェース回路３４を備える。信頼できる装置２４におけるブロックの各々は、信頼できる装置２４の適切な揮発性メモリ領域４および不揮発性メモリ領域３に対する(典型的にはコントローラ３０経由の)アクセスを持つ。更に、信頼できる装置２４は、周知の形態で、不正抵抗性を持つように設計される。
【００３９】
パフォーマンス上の理由から、アプリケーション固有集積回路(すなわちＡＳＩＣ)として信頼できる装置２４を実施することもできる。しかし、柔軟性のため、信頼できる装置２４は、好ましくは、適切にプログラムされたマイクロコントローラである。ＡＳＩＣＳとマイクロコントローラは共に、マイクロ・エレクトロニクス技術分野において周知であるので、これ以上の詳細説明は行わない。
【００４０】
信頼できる装置２４の不揮発性メモリ３に保存されるデータの１つの項目は、認証書３５０である。認証書３５０は、少なくとも、信頼できる装置２４の公開暗号鍵３５１および信頼できる機関(ＴＰ)によって測定されたプラットフォーム信頼性メトリックの認証された値３５２を含む。認証書３５０は、信頼できる装置２４への保存に先立ちＴＰの秘密鍵を使用してＴＰによって署名される。後刻の対話セッションにおいて、プラットフォーム１０のユーザは、取得した信頼性メトリックを真正な信頼性メトリック３５２と比較することによってプラットフォーム１０の信頼性を検証することができる。一致すれば、ユーザは、プラットフォーム１０が破壊されなかったと確信することができる。ＴＰの一般に利用できる公開暗号鍵についての知識が、認証書３５０の単純な検証を可能にする。不揮発性メモリ３は、また、識別(ＩＤ)ラベル３５３を含む。ＩＤラベル３５３は、なんらかの文脈の範囲内でユニークである従来のＩＤラベル(例えばシリアル番号)である。ＩＤラベル３５３は、信頼できる装置２４に関連するデータのインデックス付けまたはラベル付けのために一般に使用されるが、信頼できる条件でプラットフォーム１０の識別性を証明するにはそれ自体では不十分である。
【００４１】
信頼できる装置２４は、関連コンピュータ・プラットフォーム１０の信頼性メトリックを取得または高い信頼度で測定する少なくとも１つの方法を備えている。本実施形態においては、信頼性メトリックは、ＢＩＯＳメモリにＢＩＯＳ命令のダイジェストを生成することによって測定機能３１によって取得される。そのように取得された信頼性メトリックは、上述のように検証されれば、プラットフォーム１０の潜在的ユーザにプラットフォーム１０がハードウェアまたはＢＩＯＳプログラムのレベルで破壊されなかったという高いレベルの信頼を与える。オペレーティング・システムおよびアプリケーション・プログラム・コードが破壊されなかったことを検査するため、ウィルス検査プログラムのようなその他の周知のプロセスが典型的には使用される。
【００４２】
測定機能３１は、ハッシュ・プログラム３５４および信頼できる装置２４の秘密鍵３５５を保存する不揮発性メモリ３および取得した信頼性メトリックをダイジェスト３６１の形態で保存する揮発性メモリ４にアクセスする。また、適切な実施形態において、揮発性メモリ４は、プラットフォーム１０へのアクセスを取得するために使用されることができる１つまたは複数の真正スマートカードの公開暗号鍵および関連ＩＤラベル３６０ａ−３６０ｎを記憶するためにも使用される。
【００４３】
１つの好ましい実施形態において、ダイジェストと同様に、信頼性メトリックは、測定機能３１によって揮発性メモリ４に保存される(詳細は後述)ブール値を含む。
【００４４】
図４を参照して、信頼性メトリックを取得する１つの好ましいプロセスを記述する。ステップ４００において、スイッチがオンされると、測定機能３１は、データ、制御およびアドレス線(２６、２７、２８)上の主プロセッサ２１の活動を監視して信頼できる装置２４がアクセスされる最初のメモリであるか否かを決定する。従来の動作の下では、主プロセッサは、ＢＩＯＳプログラムを実行するため最初にＢＩＯＳメモリに向けられる。しかしながら、本実施形態に従えば、主プロセッサ２１はメモリとして機能する信頼できる装置２４に向けられる。ステップ４０５において信頼できる装置２４がアクセスされる最初のメモリであれば、ステップ４１０において、測定機能３１は、信頼できる装置２４がアクセスされる最初のメモリであることを示すブール値を揮発性メモリ４に書く。そうでない場合、ステップ４１５において、測定機能３１は、信頼できる装置２４がアクセスされる最初のメモリでなかったことを示すブール値を揮発性メモリ４に書く。
【００４５】
信頼できる装置２４が最初にアクセスされるメモリでない場合は、当然のことながら、信頼できる装置２４が全くアクセスされない可能性がある。これは、例えば、主プロセッサ２１が最初にＢＩＯＳプログラムを実行するように取り扱われていたような場合である。そのような状況の下では、プラットフォームは、動作するであろうが、信頼性メトリックが利用できないので、要求に応じてその信頼性を検証することはできない。更に、ＢＩＯＳプログラムがアクセスされた後に信頼できる装置２４がアクセスされるとすれば、ブール値は、プラットフォームの信頼性の欠如を明示するであろう。
【００４６】
ステップ４２０において、主プロセッサ２１によってメモリとしてアクセスされると、主プロセッサ２１は、ステップ４２５において、記憶されているハッシュ命令３５４を測定機能３１から読む。ハッシュ命令３５４は、主プロセッサ２１による処理のためデータ・バス２６を経由して渡される。主プロセッサ２１は、ステップ４３０において、ハッシュ命令３５４を実行し、ステップ４３５において、それを使用してＢＩＯＳメモリ２９の内容を読み取り、ハッシュ・プログラムに従ってそれらの内容を処理することによってＢＩＯＳメモリ２９のダイジェストを計算する。ステップ４４０において、主プロセッサ２１は、信頼できる装置２４の中の該当する揮発性メモリ位置４に計算されたダイジェスト３６１を書き込む。次に、ステップ４４５において、測定機能３１はＢＩＯＳメモリ２９のＢＩＯＳプログラムを呼び出し、その後従来技術の方法で実行が続く。
【００４７】
明らかなように、信頼性メトリックの計算方法は、必要とされる信頼性の範囲に応じて、多数存在する。ＢＩＯＳプログラムの信頼性の測定は、プラットフォームの基礎をなす処理環境の信頼性に関する基本的検査を提供する。信頼性メトリックは、それがブーツ・プロセスの有効性について理由付けすることを可能にするような形式でなければならない。すなわち、正しいＢＩＯＳを使用してプラットフォームがブートされたか否かを検証するため信頼性メトリックの値を使用することができる形式でなければならない。オプションとして、ＢＩＯＳの範囲内の個々の機能ブロックがそれら自身のダイジェスト値を持つことができる。この場合、アンサンブルＢＩＯＳダイジェストがこれらの個々のダイジェストのダイジェストとなる。これによって、ポリシが、ＢＩＯＳ動作のどの部品が意図された目的のため重要でどの部分が無関係であるかを述べることが可能とされる(いずれの場合でもポリシの下の動作の有効性が確立されることができるような形態で個々のダイジェストは保管されなければならない)。
【００４８】
その他の信頼性検査は、プラットフォームに接続された種々のその他の装置、コンポーネントが存在し、正しい動作状態にあるように構成することを必要とするであろう。例えば、ＳＣＳＩコントローラと関連するＢＩＯＳプログラムは、周辺機器との通信が信頼できることを保証するように検査される。別の例をあげれば、プラットフォーム上のメモリ装置またはコプロセッサのような他の装置の信頼性は、固定的チャレンジ／応答対話を実施して一貫した結果を確認することによって検証することができる。信頼できる装置２４が分離できるコンポーネントである場合、信頼できる装置１４とプラットフォームの間の適切な論理的結合を与えるため、なんらかのそのような形式の対話が望まれる。また、本実施形態における信頼できる装置２４はプラットフォームの他の部品との通信の主要手段としてデータ・バスを利用するが、ハードワイア経路または光学経路のような代替的通信経路を(あまり便利ではないが)提供することも可能である。更に、本実施形態における信頼できる装置２４は他の実施形態における信頼性メトリックを計算するように主プロセッサ２１に命令するとはいえ、信頼できる装置自体は、一つまたは複数の信頼性メトリックを測定するように構成される。
【００４９】
好ましくは、ＢＩＯＳブーツ・プロセスは、ブーツ・プロセスの信頼性を検査するメカニズムを含む。そのようなメカニズムは、例えばインテル社ドラフト"Wired for Management baseline specification v 2.0 - BOOT Integrity Service"に記載されているようにすでに周知であり、ソフトウェアまたはファームウェアをロードする前にソフトウェアまたはファームウェアのダイジェストを計算することを必要とする。そのように計算されたダイジェストは、その公開暗号鍵がＢＩＯＳにとって既知である信頼できるエンティティによって提供された認証書に保存されている値と比較される。計算された値が認証書に基づく期待値と一致する場合だけ、ソフトウェア／ファームウェアがロードされ、信頼できるエンティティの公開暗号鍵の使用による認証書が有効であると証明されたことになる。一致しない場合、適切な例外処理ルーチンが呼び出される。
【００５０】
オプションとして、計算されたＢＩＯＳダイジェストを受け取った後、信頼できる装置２４は、認証書の中のＢＩＯＳダイジェストの適当な値を調べて、計算されたダイジェストがその適当な値に合致しないとすれば、ＢＩＯＳに制御を渡さないようにすることもできる。更に、代替的形態として、信頼できる装置２４は、ブール値を調べて、信頼できる装置２４がアクセスされる最初のメモリでなければ、ＢＩＯＳへ制御を渡さないようにすることもできる。これらのケースのいずれにおいても、適切な例外処理ルーチンが呼び出されるであろう。
【００５１】
図５は、ＴＰ、プラットフォームに組み込まれた信頼できる装置２４、および、信頼できるプラットフォームの信頼性の検証を望む(遠隔プラットフォームの)ユーザによる行動を示す流れ図である。ユーザがローカルに位置する場合でも図５に記載されたものと本質的に同じステップが必要とされる点は理解されることであろう。いずれにせよ、ユーザは、典型的には、検証を実施するため、なんらかの形式のソフトウェア・アプリケーションに依存する。遠隔プラットフォームまたは信頼できるプラットフォーム上でそのようなソフトウェア・アプリケーションを実行させることは可能である。しかしながら、遠隔プラットフォーム上でさえ、ソフトウェア・アプリケーションが破壊されるという可能性は存在する。従って、高レベルの信頼性のためには、そのソフトウェア・アプリケーションがユーザのスマートカード上に置かれ、ユーザは、検証の目的のため該当するスマートカード読取装置にカードを挿入することが期待される。
【００５２】
先ず、信頼できるプラットフォームを保証するＴＰ(信頼できる機関)が、保証すべきか否かを決定するためそのプラットフォームのタイプを調べる。これは、ポリシの問題である。すべてがよければ、ステップ５００において、ＴＰがプラットフォームの信頼性メトリックの値を測定する。次に、ＴＰは、ステップ５０５において、プラットフォームに関する認証書を生成する。認証書の生成は、信頼できる装置の公開暗号鍵およびオプションとしてそのＩＤラベルを測定された信頼性メトリックに追加し、ＴＰの秘密鍵でストリングスを署名することによって行われる。
【００５３】
その後、信頼できる装置２４は、秘密鍵についての知識なしにその入出力ペアを作成することは統計的に不可能である形態で、その秘密鍵を使用してユーザから受け取った入力データを処理し出力データを生成することによって、その識別性を証明することができる。このように、秘密鍵についての知識は、この場合における識別の基礎を形成する。明らかなように、識別の基礎を形成するため対称性暗号化を使用することは可能であるが、対称性暗号化を使用する欠点は、ユーザがその秘密を信頼できる装置と共有する必要があることである。更に、ユーザとの秘密の共有の必要性の結果、対称性暗号化が、原理的に識別性をユーザに証明するのに十分であるとはいえ、信頼できる装置またはユーザから発せられる検証を完全に確信することができない第三者に対して識別性を証明するには不十分である。
【００５４】
ステップ５１０において、信頼できる装置２４は、信頼できる装置２４の該当する不揮発性メモリ位置３に認証書３５０を書き込むことによって初期化される。これは、好ましくは、信頼できる装置がマザーボード２０に取り付けられた後、信頼できる装置２４との安全な通信によって実施される。信頼できる装置２４に認証書を書き込む方法は、秘密鍵を書き込むことによってスマートカードを初期化するために使用される方法と同様である。安全な通信は、ＴＰだけに知られている"マスタ鍵"によってサポートされる。マスタ鍵は、製造の間に信頼できる装置(またはスマートカード)に書き込まれ、信頼できる装置２４へのデータ書き込みを可能にするため使用される。すなわち、マスタ鍵についての知識なしに信頼できる装置２４にデータを書き込むことは不可能である。
【００５５】
プラットフォームの後刻の動作のどこかで、例えば、スイッチがオンにされるかリセットされる時、ステップ５１５において、信頼できる装置２４は、プラットフォームの信頼性メトリック３６１を取得して、保存する。
【００５６】
ユーザは、プラットフォームとの通信を望む時、ステップ５２０において、乱数のような一時的ワードを作成し、ステップ５２５において、信頼できる装置２４にチャレンジ(呼びかけ)を行う(プラットフォームのオペレーティング・システムまたは適切なソフトウェア・アプリケーションは、チャレンジを認識して適切な形態で典型的にはＢＩＯＳ呼び出しを介して信頼できる装置２４へそれを渡すように構成されている)。一時的ワードは、信頼できないプラットフォームによる古いが真正な署名に起因する欺瞞("返信攻撃"と呼ばれる)からユーザを保護するために使用される。一時的ワードを提供して応答を検証するプロセスは、周知の"チャレンジ／応答"プロセスの１例である。
【００５７】
ステップ５３０において、信頼できる装置２４は、チャレンジを受け取り、該当する応答を作成する。応答は、測定された信頼性メトリックと一時的ワードのダイジェスト、および、オプションとして、そのＩＤラベルである。次に、ステップ５３５において、その秘密鍵を使用して、信頼できる装置２４は、ダイジェストに署名し、認証書３５０と共に、署名されたダイジェストをユーザに送り返す。
【００５８】
ステップ５４０において、ユーザはチャレンジの応答を受け取り、ＴＰの既知の公開暗号鍵を使用して認証書を検証する。次に、ユーザは、ステップ５５０において、認証書から信頼できる装置２４の公開暗号鍵を抽出して、それを使用してチャレンジ応答から署名されたダイジェストを解読する。次に、ステップ５６０において、ユーザは、チャレンジ応答の中の一時的ワードを検証する。次に、ステップ５７０において、ユーザは、(チャレンジ応答から取り出した)計算された信頼性メトリックを(認証書から抽出した)該当するプラットフォーム信頼性メトリックと比較する。ステップ５４５、５５５、５６５または５７５における前記検証のいずれかが失敗すれば、全ステップはステップ５８０で終了しそれ以上の通信は行われない。
【００５９】
すべてがうまく行けば、ステップ５８５および５９０において、ユーザおよび信頼できるプラットフォームは、他のプロトコルを使用して、その他のデータに関する安全な通信を設定する。ここで、安全な通信においては、プラットフォームからのデータが、好ましくは、信頼できる装置２４によって署名される。この検証プロセスの一層の精練は可能である。望ましくは、チャレンジを送ったユーザは、プラットフォーム信頼性メトリックの値およびそれが取得された方法について認識するようになる。望ましくは、それらの情報は両方とも、チャレンジするユーザがプラットフォームの信頼性について適切な決定をすることを可能にする。チャレンジするユーザが利用できる多くの異なるオプションがある。すなわち、ユーザは、信頼性メトリックが信頼できる装置２４において有効であると認めることができ、あるいは、代替的に、信頼性メトリックの値が当該ユーザによって保持される値と等しければ、プラットフォームは適切なレベルの信頼性ベルを有することのみを認めることができる(またはこれらの２つのケースにおいて異なるレベルの信頼性があると考えることもできる)。
【００６０】
署名し、チャレンジ／応答を使用し、識別を証明する技法は、セキュリティ分野の専門家には周知であるので、これ以上の記述は行わない。
【００６１】
図６には、ログオン・スマートカード１９の処理部分６０が図示されている。図示されているように、ログオン・スマートカード１９の処理部分６０は、プロセッサ６１、メモリ６２およびインタフェース接触部６３という標準的機構を持つ。プロセッサ６１は、後述のように、ログオン・スマートカード１９の認証およびプラットフォーム１０の検証を伴う単純なチャレンジ／応答動作を行うようにプログラムされている。メモリ６２は、その秘密鍵６２０、その公開暗号鍵６２８、ユーザ・プロフィール６２１、ＴＰの公開暗号鍵６２２および識別情報６２７を保有する。ユーザ・プロフィール６２１は、ユーザによって使用可能な許容可能補助スマートカード１７ＡＣ１−ＡＣｎおよび該ユーザに関する個別セキュリティ・ポリシ６２４をリストする。ユーザ・プロフィールは、補助スマートカード１７の各々に関して、それぞれの識別情報６２３、スマートカード間の信頼構造６２５、および、オプションとしてスマートカードのタイプまたは製造記号６２６を含む。
【００６２】
ユーザ・プロフィール６２１において、補助スマートカード１７のエントリＡＣ１‐ＡＣｎの各々は、カードのタイプに応じて変わる関連識別情報６２３を含む。例えば、キャッシュカードのための識別情報は、典型的には、単純なシリアル番号を含むが、一方、暗号カードの場合、識別情報は、典型的には、暗号カードの公開鍵(あるいは認証書)を含む(秘密鍵は暗号カードそれ自体に秘密裡に記憶されている)。
【００６３】
"セキュリティ・ポリシ"６２４は、プラットフォーム１０上でユーザが補助スマートカード１７を使用する許可を指示する。例えば、補助スマートカード１７が使用中の間、補助スマートカード１７の機能に応じて、ユーザ・インタフェースはロックまたはロック解除される。更に、代替的に、特定の補助スマートカード１７が信頼される程度に応じて、プラットフォーム１０上の特定のファイルまたは実行可能プログラムをアクセス可能または不可とすることができる。更に、セキュリティ・ポリシ６２４は、"クレジット受領"または"一時的委任"(詳細は後述)のような、補助スマートカード１７に関する動作の特定のモードを指定することができる。
【００６４】
"信頼構造"６２５は、補助スマートカード１７それ自身が、ログオン・スマートカード１９を再使用することなく、更なる補助スマートカード１７をシステムに導入することができるか否かを定義する。本明細書において詳細に記述される実施形態においては、ログオン・スマートカード１９とそのログオン・スマートカード１９によってプラットフォーム１０に導入されることができる補助スマートカード１７の間にのみ信頼構造が定義される。導入は、後述されるように、"単一セッション"でも"マルチセッション"でもよい。しかしながら、特定の補助スマートカード１７が実際に更なる補助スマートカード１７を導入することができない理由はない。このためには、導入することができる補助スマートカードの各々をリストするユーザ・プロフィールと同等のものを補助スマートカード１７が持つことを必要とする。
【００６５】
図７を参照して、ログオン・スマートカード１９とプラットフォーム１０の間の認証に関する好ましいプロセスを記述する。このプロセスは、便宜上チャレンジ／応答ルーチンを実施する。利用できるチャレンジ／応答メカニズムは多数存在する。本実施形態に使用される認証プロトコルの実施形態は、ＩＳＯ／ＩＥＣ９７９８−３に記述されている相互(または３−ステップ)認証である。当然のことながら、ＩＳＯ／ＩＥＣ９７９８−３に記述されている２−ステップまたは４−ステップのような他の手続きを使用することができな理由はない。
【００６６】
先ず、ユーザが、ステップ７００において、プラットフォーム１０のスマートカード読取装置１２にそのログオン・スマートカード１９を挿入する。典型的には、プラットフォーム１０は、前もって、その標準オペレーティング・システムの制御の下で動作し、ユーザがログオン・スマートカード１９を挿入するのを待機する認証プロセスを実行している。このように活動状態にあるスマートカード読取装置１２は別として、プラットフォーム１０は、典型的には、ユーザ・インタフェース(表示画面、キーボード、マウスなど)をロックすることによってユーザがアクセスできない状態に置かれている。
【００６７】
ログオン・スマートカード１９がスマートカード読取装置１２に挿入されると、信頼できる装置２４は、ステップ７０５において、一時的ワードＡを生成してそれをログオン・スマートカード１９に送信することによって、相互認証手続きを始動する。乱数のような一時的ワードは、信頼できないプラットフォームによる古いが真正な署名に起因する欺瞞("返信攻撃"と呼ばれる)から作成元を保護するために使用される。
【００６８】
それに応じて、ログオン・スマートカード１９は、ステップ７１０において、一時的ワードＡ、ログオン・スマートカード１９によって生成された新しい一時的ワードＢ、信頼できる装置２４のＩＤ３５３および若干の冗長情報からなる平文；ログオン・スマートカード１９の秘密鍵を用いて署名することによって生成される前記平文の署名；ならびに、ログオン・スマートカード１９のＩＤおよび公開暗号鍵を含む認証書、を連結した応答を返す。
【００６９】
信頼できる装置２４は、ステップ７１５において、認証書の中の公開暗号鍵を使用して平文の署名を検証することによって応答を認証する。応答が真正でなければ、プロセスはステップ７２０で終了する。応答が真正であれば、信頼できる装置２４は、ステップ７２５において、一時的ワードＡ、一時的ワードＢ、ログオン・スマートカード１９のＩＤ６２７および取得した信頼性メトリックからなる平文；信頼できる装置２４の秘密鍵を用いて署名することによって生成される前記平文の署名；ならびに、ＴＰの秘密鍵によって署名された信頼できる装置２４の公開鍵および真正な信頼性メトリックを含む認証書、を連結した更なる応答を送る。
【００７０】
ログオン・スマートカード１９は、ステップ７３０において、ＴＰの公開暗号鍵を使用して取得した信頼性メトリックを真正な信頼性メトリックと比較することによって(一致は認証を意味する)、この応答を認証する。更なる応答が認証できなければ、プロセスはステップ７３５で終了する。
【００７１】
手続きが成功すれば、信頼できる装置２４がログオン・スマートカード１９を認証し、ログオン・スマートカード１９が信頼できるプラットフォーム１０の信頼性を検証したことになり、認証プロセスは、ステップ７４０において、当該ユーザのための安全なプロセスを実行する。次に、認証プロセスは、ステップ７４５において、インターバル・タイマを設定する。その後、認証プロセスは、ステップ７５０において、適切なオペレーティング・システム割り込みルーチンを使用して、インターバル・タイマがあらかじめ定められたタイムアウト間隔を越えているか否かを周期的に検査する。明らかなように、認証プロセスと内蔵タイマは、安全プロセスと並列して動作する。
【００７２】
タイムアウト間隔を越えると、認証プロセスは、ステップ７６０において、ログオン・スマートカード自体を識別させるためログオン・スマートカード１９にチャレンジを送信することによってログオン・スマートカード１９を再認証するように信頼できる装置２４を始動させる。ログオン・スマートカード１９は、ステップ７６５において、そのＩＤ６２７およびその公開暗号鍵６２８を含む認証書を返す。ステップ７７０において、(例えば、ログオン・スマートカード１９が取り除かれていたため)応答がない場合、または、何らかの理由で(例えばログオン・スマートカードがすでに他のカードと置き換えられているため)認証書がもはや有効でない場合、セッションは、ステップ７７５において、信頼できる装置２４によって終了される。さもなければ、ステップ７７０において、ステップ７４５からのプロセスが内蔵タイマをリセットすることによって反復される。
【００７３】
図８を参照して、補助スマートカード１７をプラットフォーム１０に導入するための好ましい一般的プロセスを以下に記述する。プラットフォーム１０上で動作している安全プロセスが、ログオン・スマートカード１９が補助スマートカード１７と置き換えられる必要がある時点に到達する時、例えば、遠隔トランザクションに関する資金をキャッシュカードがプラットフォーム１０にクレジットする必要があるような時、ステップ８０５において、安全プロセスによって、信頼できる装置２４がユーザ・プロフィールを取り出し、それをその揮発性メモリ３５に保存する。次に、信頼できる装置２４は、ステップ８１０において、ユーザ・プロフィールから補助スマートカード１７の詳細を抽出し、その詳細を安全プロセスに返す。ステップ８１５において、安全プロセスは、補助スマートカード１７のオプション・リストを表示して、ユーザに１つを選択するように求める。安全プロセスは、ステップ８２０において、ユーザ選択を受け取り、ステップ８２５において、ログオン・スマートカード１９を選択した補助スマートカード１７と取り替えるようにユーザに求めるメッセージを表示する。ユーザがログオン・スマートカード１９を取り出すと信頼できる装置は直ちにユーザ・インタフェースをロックし(ステップ８３０)、安全プロセスが、ステップ８３５において、補助スマートカード・セッションの許容可能継続期間を決定するため、認証プロセス・インターバル・タイマを新しいタイムアウト間隔に初期化する。
【００７４】
[図７を参照して記述された安全プロセスの動作と平行して、ログオン・スマートカード１９が再度挿入される前に、タイムアウト間隔が切れるとすれば、認証プロセスは、セッション(すなわち安全プロセス)を中止して、ユーザに適切なメッセージを提供する。認証プロセスは、安全プロセスを最初に実行したのであるから、安全プロセスを中止するための権限を持つ。明らかなように、新しいタイムアウト間隔は、必要とされる目的のため十分なものでなければならず、この理由のためにシステム管理者によって変更可能であることが望ましい。]
ユーザが選択された補助スマートカード１７を挿入すると、信頼できる装置２４は、ステップ８４０において、それ自体を確認するため補助スマートカード１７にチャレンジを送るように始動される。補助スマートカード１７は、ステップ８４５において、信頼できる装置２４にその識別情報を返すことによって応答する。次に、信頼できる装置２４は、ステップ８５０において、保存されているユーザ・プロフィール情報と比較することによって識別情報を検証する。
【００７５】
信頼できる装置２４が何らかの理由で補助スマートカード１７を検証することができなければ、セッションはステップ８５５で終了し、安全プロセスは、ユーザのために適切なメッセージを表示する。さもなければ、ステップ８６０および８６５において、安全プロセスは、必要に応じて補助スマートカード１７と対話する。
【００７６】
対話が完了すれば、安全プロセスは、ステップ８７０において、補助スマートカード１７をログオン・スマートカード１９と取り替えるようにユーザにプロンプトを表示する。ユーザが補助スマートカード１７を取り出し、スマートカード読取装置１２にログオン・スマートカード１９を挿入すると、信頼できる装置２４は、ログオン・スマートカード１９を認証するため、図７のステップ７６０から開始する上述のステップを実行し、その結果、セッションがステップ７７５で終了するか、または、ステップ７４５に続く。
【００７７】
更に、代替的に、いくつかの実施形態において、ユーザ・プロフィールが暗号化され秘密と信頼性を保護するように署名されることが必要とされる。もしそうであれば、信頼できる装置２４とログオン・スマートカード１９の間で安全なデータ転送プロトコルが必要とされるかもしれない。２つのエンティティの間で安全な信用証明書を転送するために利用できる多くのメカニズムが存在する。本実施形態において使用できる可能な実施形態の１つは、ＩＳＯ／ＩＥＣ  ＤＩＳ  １１７７０−３に従った安全な鍵伝送メカニズムである。
【００７８】
明らかなように、補助スマートカード１７を導入する前述のプロセスの動作は、補助スマートカード１７のタイプに従って、例えばカードがキャッシュカードか暗号カードかに応じて、変わり得る。異なるタイプの補助スマートカード１７のためのプロセスのバリエーションを以下に記述する。
【００７９】
クレジット受領モード
クレジット受領モードは、ユーザが短い時間(例えば２分、ただしこの時間はシステム管理者またはユーザによって設定可能である)スマートカード読取装置１２からログオン・スマートカード１９を取り出して、不当なセキュリティ・リスクなしにキャッシュカードからクレジット(すなわち現金価値)をプラットフォーム１０の信頼できる装置２４へ転送することを可能にするものである。
【００８０】
図９は、クレジット受領モードを実施するためのプロセスを示している。図８で記述された対応するステップはここで特にここで再記述しない。キャッシュカードを含む補助スマートカード１７をリストするユーザ・プロフィールはログオン・スマートカード１９に記憶されていると仮定する。ユーザが現金額を必要とするアプリケーションを呼び出すと、図８のステップと同様に、安全プロセスが、ユーザ・プロフィールのリストからキャッシュカードを選択するようにユーザに求める要求を表示する。
【００８１】
クレジット受領モード・プロセスと図８のプロセスの第１の相違は、安全プロセスが、ステップ９２１において、クレジット転送額を入力するようにユーザへの更なる要求を表示する点である。安全プロセスは、ステップ９２３において入力された額を受け取り、ステップ９２３において信頼できる装置２４に対応する額を送信する。信頼できる装置２４は、キャッシュカードが挿入され認証された後、ステップ９６０および９６５において、キャッシュカードから信頼できる装置２４へクレジット額を転送する。
【００８２】
代替的または付加的機能として、セキュリティ・ポリシに従って、未許可キャッシュカードも使用することができる。例えば、認可されたキャッシュカードのリストに"その他"というオプションを含めることもできる。明らかなように、補助スマートカード１７からクレジット受け取ることに関連するリスクは比較的低い。
【００８３】
典型的には、クレジット額を転送するプロセス全体を実施するために必要とされる時間は比較的短い。タイムアウト間隔の長さは、ユーザ・プロフィールにおけるセキュリティ・ポリシによって決定される。タイムアウトを越えれば、転送プロセスは中止され、ユーザ・インタフェースは一時的にロックされる。一方、ユーザが指定された制限時間の範囲内にログオン・スマートカード１９を再度挿入すれば、スマートカードとプラットフォーム１０の間で認証の新ラウンドが実行される。検証が成功すると、ユーザ・インタフェースのロックは解かれ、クレジット受領モードに入る前の元のセッションに復帰する。その場合、キャッシュ額はすでに信頼できる装置２４に保存されている。キャッシュ額は、例えば電子商取引に使用される。
【００８４】
基本的には、クレジット受領モードの間、ユーザ・インタフェースはロックされ、ログオン・スマートカード１９の再挿入の後にのみ再度活動状態にされるので、ホスト・プラットフォーム１０は、クレジット受領モードにおける深刻なリスクに苦しまない。更に、ユーザがログオン・カード１９を使用して、どのキャッシュカードを使用すべきかを認証しなければならいので、違法なユーザによるキャッシュカードの濫用もまた最小化される。
【００８５】
一時的委任モード
認められることであろうが、暗号カードが機能するためには(例えば暗号化、解読、署名および検証)、キャッシュカードの場合と違って、ログオン・カードに代わって暗号カードが相当長い時間挿入される必要が潜在的にある。暗号カードを使用する潜在的に長い時間の必要性に対処するため、本実施形態は、一時的委任モードと呼ばれるモードを含む。このモードは、ユーザが、可能なそれぞれのセキュリティ・ポリシ限度に従って、ログオン・カードに代えて暗号カードを不定時間使用することを可能にする。図１０を参照して一時的委任モードを以下に記述する。図８に示された対応するステップはここで特に再記述されない。
【００８６】
一時的委任モードを呼び出すため、ユーザ(または安全プロセス)は、ステップ１０００において、ログオン・スマートカード１９が使用されている間に一時的委任モードを選択する。それに応じて、ホスト・プラットフォーム１０が、補助スマートカード１７(この例では暗号カード)を受け取って認証するステップを実行する。
【００８７】
許容暗号カードのリストが与えられると、ユーザは、認可された暗号カードを指定する。セキュリティ・ポリシに従って、未認可暗号カードを使用することも使用しないこともできる。ユーザ・プロフィールが暗号化されていれば、この場合もＩＳＯ／ＩＥＣ  ＤＩＳ  １１７７０−３に従った安全伝送プロトコルを使用することができる。
【００８８】
ログオン・スマートカード１９が取り出された後、ユーザ・インタフェースはロックされ、安全プロセスは新しいスマートカードを要求するメッセージを表示する。指定された暗号カードの挿入および認証の後、安全プロセスは、ステップ１０３３において、暗号カードのセキュリティ・ポリシと整合するユーザ特権を起動する。例えば、ユーザは暗号カード操作に関連した一定情報の入力のためユーザ・インタフェースを使用する必要があるかもしれないが、いかなる他のプロセスを実行することも他のいかなる操作を実行することも可能であってはならない。暗号カードがスマートカード読取装置１２から取り出されると、ユーザ・インタフェースは、ログオン・スマートカード１９が挿入され認証されるまで、再びロックされる。
【００８９】
一時的委任モードの上述の例は、ログオン・スマートカード１９の代わりに単一補助スマートカード１７が、不定時間、"単一セッション"で使用されることを可能にする。代替的にまたは付加的に、一時的委任モードは、ログオン・スマートカード１９を元通りに挿入することを必要とせずに、ログオン・スマートカード１９の代わりに複数の補助スマートカード１７を"マルチセッション"で使用することを可能にする。図１１を参照して"マルチセッション"一時的委任モードを説明する。図８に記述されたものと同じステップは再記述されない。マルチセッションにおいては、複数の補助スマートカード１７が、ログオン・スマートカード１９の代わりに自由に使用されることができるので、最大限の使用の便宜性が提供される。
【００９０】
マルチセッション一時的委任モードを呼び出すため、ユーザ(または安全プロセス)は、ステップ１１００において、ログオン・スマートカード１９が使用されている間にマルチセッション一時的委任モードを選択する。マルチセッション一時的委任モードと単一セッション一時的委任モードとの間の大きな相違は、ステップ１１１５において利用できる認可された補助スマートカード１７のリストが提供される時、ユーザがステップ１１２０において複数の認可された補助スマートカード１７を選択することができる点である。選択された補助スマートカード１７は、ユーザの必要条件に従って、異なる種類を含むことができる。ホスト・プラットフォーム１０は、選択された補助スマートカード１７の任意の一つを受け取り認証するステップを実行する。
【００９１】
ログオン・スマートカード１９が取り出されると直ちにユーザ・インタフェースはロックされ、安全プロセスは、ステップ１１３３において、その補助スマートカード１７の操作と整合したユーザ特権を起動する。補助スマートカード１７が最終的に取り出されると、プロセスはステップ１１２５へ戻って、カードを取り替えるメッセージを作成し、ユーザ・インタフェースがステップ１１３０において再びロックされる。次の補助スマートカード１７が挿入されると、安全プロセスは、再び、ステップ１１３３において、その補助スマートカード１７の操作と整合したユーザ特権を起動する。
【００９２】
この手続きは、選択された補助スマートカード１７のいずれかに関して、ステップ１１７５においてセッションが終了するかログオン・スマートカードが元通り挿入されるまで、反復される。換言すれば、ユーザは、全マルチセッションの間ログオン・スマートカード１９の挿入を必要とすることなく、選択された補助スマートカード１７のいかなる組合せを使用することができる。明らかなように、そのようなマルチセッションはユーザにとって非常に便利であるが、その利益はそのような自由のリスクと比較考量される必要はある。
【００９３】
注意されるべき点であるが、ユーザ・プロフィールに記述されるセキュリティ制御ポリシは、時間制限と共に、マルチセッションにおいて許容されるスマートカードの番号、タイプ、製造記号に関する制約を与えることもできる。典型的には、異なる補助スマートカード１７は異なる特権セットをユーザに与える。例えば、現在使用されている補助スマートカード１７が十分に信頼することができないと見なされる時は必ず重要なファイルはロックされる。実際に、重要なアプリケーションは、再び認証するためログオン・スマートカード１９の挿入を必要とするかもしれない。
【００９４】
一時的委任モードがどれくらい続くかを推定するのは簡単ではないので、理論的には、上述の例の場合のように、タイムアウト時間を持たないことが許容されるかもしれない。しかしながら、そのようなポリシにはリスクがある。例えば、一時的委任モード・セッションの間に、ユーザがプラットフォーム１０を離れることもあり得る。従って、一時的委任モード・セッションに対して固定され、認証プロセスの通常の再認証タイムアウト間隔および各補助スマートカード１７に関連する個々のタイムアウト間隔の両方に優先する全般的タイムアウト間隔を持つことは好ましい。加えて、特定の補助スマートカード１７に関して個別のタイムアウト間隔を持つこともまた可能である。通常のように、タイムアウト間隔の指定は、補助スマートカード１７に関するセキュリティ・ポリシによって決定される。実際には、一時的委任モードに関するタイムアウト間隔は、認証プロセスに優先する安全プロセスによって実施される。一時的委任モードのための典型的な固定セッション・タイムアウト間隔の例は、３０分、１時間または２時間である。間隔は、ユーザまたはシステム管理者によって設定または修正されることができ、プラットフォーム１０の信頼性に依存する。
【００９５】
元々のログオン・カードの再挿入は、典型的には、一時的委任モード・セッションを延長するために必要とされ、一般に、安全プロセスが期間満了に先立ち警告メッセージをユーザに発する。これは、公衆電話ボックスで電話呼び出しの際にコインの挿入が求められることに類似している。期間が満了すると、ユーザ・インタフェースはロックされて、ログオン・カードによってのみロック解除が可能とされる。ユーザが一時的委任モードにおいて時間を要するアプリケーションの使用を試みるとすれば、アプリケーションの途中でユーザ・インタフェースをロックすることを避けるため、安全プロセスは、前もってログオン・スマートカード１９の挿入を要求するかもしれない。
【００９６】
一時的委任モードの間に許容される補助スマートカード１７およびアプリケーションのクラスを一般的に指定する種々の異なる一時的委任モードが存在する。例えば、一部のモードにおいては、おそらくただ１つの種類の補助スマートカード１７(そのようなカードは追跡可能なＩＤをおそらく有している)だけが許容される。別のモードにおいては、小さいクラスの補助スマートカード１７だけが許容される。更に別のモードにおいては、大きいクラスの補助スマートカード１７が許容される。
【００９７】
委任され得る特権の正確なセットは、システム・セキュリティ・ポリシと、(設定またはセッションそれ自体の間の)ユーザによる選択と、使用されている補助カードの種類および製造記号との関数である。いくつかの特権は一時的委任モードの間無効にされるかもしれない。例えば、一旦一時的委任モードが使用されると、一部のファイルはロックされるかもしれない。高いセキュリティのアプリケーションは、元々のログオン・カードの再挿入を要求するかもしれない。極端なケースでは、特定のアプリケーションを除くすべての特権が一時的委任モードの間中止されるかもしれない。
【００９８】
上述の実施形態に対する代替形態または付加的形態として、ログオン・スマートカード１９が異なるプラットフォーム１０を分類するようにログオン・スマートカード１９をプログラムすることができる。例えば、プラットフォーム１０のタイプに従って、プラットフォーム１０を、「まあまあ信頼できる」、「非常に信頼できる」、「最高に信頼できる」というプラットフォーム・カテゴリに分類することができる。この場合、プラットフォーム１０のタイプは、ログオン・スマートカード１９によってプラットフォーム１０から受け取られる識別情報によって明らかにされる。ログオン・スマートカード１９は、識別情報をあらかじめ定められ保存されている情報と比較するようにプログラムされる。特定の一致がそのプラットフォームのカテゴリを示す。便宜上、保存されているカテゴリ情報は、ユーザ・プロフィールの一部を形成する。
【００９９】
このようにして、ログオン・スマートカード１９が特定のプラットフォーム１０で採用するセキュリティ・ポリシは、プラットフォーム１０のカテゴリに依存することとなる。１つの例をあげれば、ログオン・スマートカード１９は、プラットフォーム１０のカテゴリに従って異なるユーザ・プロフィール情報をプラットフォーム１０に送ることができる。例えば、「まあまあ信頼できる」プラットフォーム１０であれば、スマートカードは、暗号カードに関する情報だけをプラットフォーム１０に渡して、暗号化された電子メールを送受信するかインターネットをサーフィンすることだけができるようにユーザを制限する。更に、「まあまあ信頼できる」プラットフォーム１０の場合、ユーザ・プロフィール情報は、"単一セッション"一時的委任モードに制限することもできる。対照的に、「非常に信頼できる」プラットフォーム１０であれば、このプラットフォームは、マルチセッションの一時的委任モードおよびキャッシュカード処理さえ可能にするユーザ・プロフィール情報を受け取ることができる。また、「最高に信頼できる」プラットフォーム１０であれば、このプラットフォームは、マルチセッションおよびキャッシュカード処理のみならずその他の管理機能を含むすべての可能なアクションを許容するユーザ・プロフィール情報を受け取ることができる。
【０１００】
「最高に信頼できる」プラットフォーム１０を必要とする管理機能の１つの例は、ログオン・スマートカード１９のユーザ・プロフィールの作成または修正能力である。ログオン・スマートカード１９が、プラットフォーム１０が「最高に信頼できる」プラットフォーム１０であることを検証する時、ログオン・スマートカード１９は、ユーザが安全プロセスからプロフィール修正オプションを選択することを可能にするオプションを含むユーザ・プロフィール情報をプラットフォーム１０に渡す。ユーザが登録プロセスを選択する時、特別なスマートカード登録プロセスである"ウィザード"が表示される。このウィザードは、ユーザが、新しい補助スマートカード１７を追加し、現行の補助スマートカード１７を削除し、公開暗号鍵または認証書のような各補助スマートカード１７のＩＤの詳細情報を見ることを可能にする。ユーザ・プロフィールにおいて、登録されたスマートカードの各々は、登録の間に与えられた固有の番号と名前を持つ。"ウィザード"は、コンピュータ・アプリケーションの分野において周知であるので、これ以上の記述は行わない。
【０１０１】
代替的実施形態において、ユーザ・プロフィール情報は、信頼できる装置２４または遠隔に位置する信頼できるプラットフォーム１０に保存されることができる。そのような構成は、典型的には、安全プロセスまたはプラットフォーム１０によるユーザ・プロフィール情報へのアクセスを制御するための異なるプロセスを必要とするが、一旦アクセスされた情報の使用は同じである。
【０１０２】
本発明は、プラットフォームと受動的に通信するスマートカード(または他のセキュリティ・トークン)にその適用を限定されるものではない。本発明は、プラットフォーム(またはプラットフォーム上の信頼できる装置)に対してコマンドを始動し、メッセージおよび情報の交換のため信頼できる装置と通信し、情報の要求を送信し、それらの要求に応じて信頼できる装置から結果を受け取ることができるスマートカードにも適用できる。スマートカードからのユーザ・コマンドの始動の実施実施形態は、"Smartcards - from Security Tokens to Intelligent Adjuncts"(by Boris Balacheff, Bruno Van Wilder and David Chan, published in CARDIS 1998 Proceedings)に記載されている。
【０１０３】
同様に、信頼できる装置によって提供される信頼性メトリックの解釈は、(スマートカードに代表される)ユーザによって実行されなくてもよい。適切な解決策は、ユーザ・スマートカードがこの機能性を提供する信頼できる第三者サーバに対する(典型的にはプラットフォーム経由の)アクセスを有することである。スマートカードの利用できる処理パワーとメモリは限られているので、これは有利な解決策である。この構成においては、信頼性メトリック・データは、スマートカードではなくスマートカードによって信頼されている遠隔サーバに送信される。遠隔サーバは、信頼できる装置によって提供された信頼性メトリック・データを信頼性メトリックの期待セットと比較することによって当該信頼性メトリックが正しいことを検証する。信頼性メトリックの期待セットは、信頼できる装置の範囲内に予め記憶されたデータから信頼できる装置自体によって供給されるか、または、プラットフォームが共有タイプの場合、信頼できるサーバが、そのタイプのコンピュータ・プラットフォームに関するる信頼性メトリックの期待セットを記憶する。いずれにせよ、信頼できるサーバは、信頼性メトリックの期待セットとの信頼性メトリックの検証のために必要な重いデータ処理を実行し、検証の結果にデジタル署名する。このデジタル署名が、スマートカードに送り返され、受け入れられるか拒絶され、検証結果となる。
【０１０４】
以上、本発明をいくつかの好ましい実施形態に関連して記述したが、本発明の理念および範囲から逸脱することなく本発明を構成する部分および方法に種々の修正を加えることは可能であることが認識されるであろう。
【図面の簡単な説明】
【図１】本発明の実施形態を実行することができるシステムを示すブロック図である。
【図２】スマートカード読取装置を介してスマートカードおよびモジュール・グループと対話するように構成された信頼できる装置を含むマザーボードを示すブロック図である。
【図３】信頼できる装置の更に詳細を示すブロック図である。
【図４】コンピュータ装置の信頼性メトリックの取得に関係するステップを示す流れ図である。
【図５】信頼できるコンピュータ・プラットフォームとその信頼性を検証する信頼できるプラットフォームを含む遠隔プラットフォームとの間の通信を確立することに関連するステップを示す流れ図である。
【図６】本発明の実施形態に従って使用されるログオン・スマートカードの動作部分を示すブロック図である。
【図７】ログオン・スマートカードとホスト・プラットフォームを相互認証するプロセスの流れ図である。
【図８】本発明の実施形態に従ったログオン・スマートカードを使用してホスト・プラットフォームに補助スマートカードを導入する１つの一般的な例を示す流れ図である。
【図９】導入されたキャッシュカードとホスト・プラットフォームの間の動作の１例を示す流れ図である。
【図１０】単一セッション一時的委任モードの１例を示す流れ図である。
【図１１】マルチセッション一時的委任モードの１例を示す流れ図である。
【符号の説明】
３、４  メモリ
１０    コンピュータ装置
１２    スマートカード読取装置
１７    補助トークンまたは補助スマートカード
１９    主トークンまたはログオン・スマートカード
２４    信頼できる装置
【図１】
0004091744.tif 000002
【図２】
0004091744.tif 000003
【図３】
0004091744.tif 000004
【図４】
0004091744.tif 000005
【図５】
0004091744.tif 000006
【図６】
0004091744.tif 000007
【図７】
0004091744.tif 000008
【図８】
0004091744.tif 000009
【図９】
0004091744.tif 000010
【図１０】
0004091744.tif 000011
【図１１】
0004091744.tif 000012