JP2008532419A - 安全なソフトウェア通信方法及びシステム - Google Patents

Abstract

信頼のない実行環境で安全な通信を実施する方法及びシステムである。この方法は、第１のコンポーネントと第２のコンポーネントとの間でそれぞれ第１及び第２の証明書を送信することを有し、第１の証明書及び第２の証明書は、第１のコンポーネントと第２のコンポーネントとを有するソフトウェアコード内にそれぞれ隠蔽される。第２のコンポーネントが第１の証明書の第１の公開鍵を使用し、第１のコンポーネントが第２の証明書の第２の公開鍵を使用することにより、第１のコンポーネントと第２のコンポーネントとの間に安全な通信チャネルが生成される。第１のコンポーネントの識別情報は、第２のコンポーネントが証明機関に対して第１の証明書を検査することにより確認される。第２のコンポーネントの識別情報は、第１のコンポーネントが証明機関に対して第２の証明書を検査することにより確認される。第１の証明書及び第２の証明書の確認の成功時に、安全な通信チャネルを介してデータ交換が実施される。

Description

この記載は、概してコンピュータ実行ソフトウェアに関する。特に、この記載は、ソフトウェアコンポーネントの実行のセキュリティを対象とする。この記載は、信頼のない環境で実行するソフトウェアコンポーネント間の認証された秘密の通信を開示する。

ソフトウェア型プロダクトの未許可の配布及び／又は使用（例えばソフトウェアの不正コピー等）は、コンピュータソフトウェア業界にとってますます重要な問題になっている。未許可の配布／使用は、一般的にソフトウェアプロダクト、アプリケーション、サービス等の不正のコピー、配布又は使用を示す。ソフトウェア及びコンピュータ企業団体（例えばビジネスソフトウェア同盟（Business Software Alliance）等）によれば、現在使用中の全てのソフトウェアのうち、かなりの割合（例えば30〜36%）が未許可、無認可又は盗難のものであり、これによって、発行者にかなりの収益の損失をもたらしている。次に、発行者はユーザに高い価格をもたらす。

未許可の配布／使用の問題は多くの異なる種類の商用ソフトウェアにも当てはまる。このようなソフトウェアは、事前インストール又は専門家のインストールを通じて得られる全機能型商用ソフトウェア、“パッケージ”ソフトウェア等を含む。このようなソフトウェアはまた、商用ソフトウェアの期限版又は機能制限版を含み得る。例えば、未許可の配布／使用の問題は、同僚からのソフトウェアアプリケーションのコピーの借用及びインストール、ソフトウェアのコピーが許可されたもの以上にインストールされる乱用問題、改装又は新しいコンピュータに配布される未許可のソフトウェアのコピー、著作権のあるプログラムが複製されて販売されるあからさまな模倣の問題を含む。

ソフトウェアプロダクトの未許可の配布／使用により提示される問題を低減するために、多数の従来技術の対策が展開されている。これらの従来技術の対策の多くは、ソフトウェアの実行環境を物理的に安全にすること、又は適切に未許可の使用を検査するために様々な暗号化及び符号化方式を使用することを有する。コンピュータ環境を物理的に安全にすることは、一般的にコンピュータ環境へのアクセスの厳密な制御を必要とする。例えば、安全なネットワークのワークステーションは、閉じた部屋の厳密に制御された出入口の背後に物理的に配置され得る。このような物理的な制御は、十分に厳しく適用されると、ほとんどの配布／使用の問題を回避するのに効率的になり得る。しかし、典型的な商用ソフトウェアプロダクト発行者にとって、顧客のコンピュータ環境でこのような物理的な制御を要求することは実用的ではない。

従って、ほとんどの従来技術のソフトウェアプロダクトの保護方式は、未許可の配布／使用を妨げるために、何らかの形式の暗号化及び／又は符号化を使用する。典型的な従来技術の方式は、何らかのバージョンのSSL（Secure Sockets Layer）又はトランスポートレベルのセキュリティ（例えば、IETF RFC 2246に詳細に記載されたTLS（Transport Level Security））を使用し、コンポーネント間の通信セッション中にクライアントコンポーネント、サーバコンポーネント又はこれらの双方の認証及び暗号化を実施する。他の従来技術の例は、Kerberos及びSESAME,のような対策であり、相互に信頼を受けた第三者を用いて安全な認証された通信リンクを確立する。しかし、このことは、第三者がランタイム環境で継続して利用可能になることを必要とし、第三者は信頼を受けた環境で実行されなければならない。更に、このようなシステムの構成はかなりの量になる。これらが、２つの通信関係者だけが関与する対策が広まっている主な理由である。

典型的には、ソフトウェアコンポーネント間の認証された秘密の通信の従来技術での確立は、少なくとも１つの実行環境が信頼を受けていることを必要とする。認証された手段を介して通信がソフトウェアコンポーネントのユーザのみにより行われ得る場合に、環境は信頼される。しかし、２つのソフトウェアコンポーネントが通信しようとしており、例えば半公共環境又は容易に安全にできないコンピュータ環境で容易に危うくなり得る実行環境で１つ以上のソフトウェアコンポーネントが動作している場合、通信のセキュリティは容易に危うくなり得る。例えば、危うくなった通信は、他のソフトウェア保護機構を無効にすることがある（例えば、プロダクトアクティベーションキーのクラック等）。

認証された通信を確保するために標準的なPKI（Public Key Infrastructure）技術を使用することは、ソフトウェアコンポーネントの初期構成を必要とするため、これらのような場合に十分に適していない。構成が未許可の関係者又は悪意の意図のある認証された関係者（例えばハッカー等）により実行されると、通信の内容が改ざんされ得る。

（例えば、強力で頻繁に変更されるパスワードを使用することにより）コンピュータ環境への物理的アクセスを制限し、ネットワークアクセスを制限するために更なる従来技術の方式が使用される場合であっても、これらの制限された物理的アクセス及びネットワークアクセスは、悪意の意図のある関係者にとって利用可能になることがあり、これによって、適切な構成により確保された何らかのセキュリティ手段が無効になる。多くの場合には、これらの手段の多くはソフトウェアコンポーネントのユーザにとって負担になり、非常にリソース集中的である。

他の側面は、安全な接続の構成についての高い管理負荷である。SSLを含むほとんどの場合には、証明書が生成され、署名され、配備され、更新される必要がある。（例えば人間の誤りのため）このことが正確に行われない場合、接続のセキュリティが危うくなり得る。必要なものは、ソフトウェアコンポーネント間で認証された秘密の通信を効率的に促進する対策である。

従って、ソフトウェアコンポーネント間の認証された秘密の通信の必要性を考えて、予めインストールされて予め構成された組み込み式の安全な通信機能を有するソフトウェアコンポーネントを提供する対策は、従来技術に比較して多数の利点を提供する。このような対策は、ソフトウェアコンポーネントのユーザとは対照的に、ソフトウェアコンポーネントの作者／設計者にロバストで安全な通信インフラストラクチャを実装する負荷をかける。

一実施例では、本発明は、信頼のない実行環境で実行するソフトウェアコンポーネントの間で安全な通信を提供するコンピュータ実装方法として実施される。安全な通信は、第１のソフトウェアコンポーネントと第２のソフトウェアコンポーネントとの間で実施される。この方法は、第１の証明書を第２のコンポーネントに送信し、第２の証明書を第１のコンポーネントに送信することを有する（例えば、証明書の交換）。第１の証明書及び第２の証明書は、第１のコンポーネントと第２のコンポーネントとを有するソフトウェアコード内にそれぞれ隠蔽されてもよい。同様に、それぞれの第１及び第２の秘密鍵が、第１のコンポーネントと第２のコンポーネントとを使用するソフトウェアコード内に隠蔽されてもよい。双方の証明書は相互に信頼を受けた証明機関により署名されなければならない。

次に、第２のコンポーネントが第１の証明書（例えば第１の公開鍵）を使用し、第１のコンポーネントが第２の証明書（例えば第２の公開鍵）を使用することにより、第１のコンポーネントと第２のコンポーネントとの間に安全な通信チャネルが生成される。第１の証明書が信頼を受けた証明機関により署名されていることを第２のコンポーネントが検査することにより、第１のコンポーネントの識別情報が確認される。ここで使用される“識別情報”は、証明書の署名要求が発行される前に関係者自体について関係者（例えばコンポーネント構築者）により提供された情報である。識別情報は、秘密鍵と共に証明書内に存在する。第２のコンポーネントの識別情報は、同様に有効な証明機関の署名を有する第２の証明書を第１のコンポーネントが検査することにより確認される。第１及び第２の証明書の確認の成功時に、安全な通信チャネルを介してデータ交換が実施される。

１つの代替実施例では、第１の証明書及び第２の証明書は、受託実行環境（entrusted execution environment）内でも実行する別々に信頼を受けた認証記憶装置内にそれぞれ格納され、これからアクセスされ得る。同様に、第１及び第２の秘密鍵はまた、信頼を受けた認証記憶装置内に格納され、これからアクセスされ得る。

一実施例では、第１の証明書及び第２の証明書は、X509符号化標準のバージョンに従って提供される。安全な通信チャネルは、TLS（Transport Level Security）標準のバージョンに従って確立され得る。

このように、本発明の実施例は、同じ作者／設計者からのソフトウェアコンポーネントを安全に予め構成するだけでなく、異なる作者／設計者からのソフトウェアコンポーネントが相互に認証することを可能にし、これから認証された秘密のデータ交換を行うことを可能にする方法を記載する。共通の証明機関は、委託実行環境内で双方共に実行するという事実にもかかわらず、これらの異なるコンポーネント間の相互作用が信頼を受け得ることを相互に確保する。

要約すると、この記載は、信頼のない実行環境で安全な通信を実施する方法及びシステムを開示する。この方法は、第１のコンポーネントと第２のコンポーネントとの間でそれぞれ第１及び第２の証明書を送信することを有し、第１の証明書及び第２の証明書は、第１のコンポーネントと第２のコンポーネントとを有するソフトウェアコード内にそれぞれ隠蔽される。第２のコンポーネントが第１の証明書の第１の公開鍵を使用し、第１のコンポーネントが第２の証明書の第２の公開鍵を使用することにより、第１のコンポーネントと第２のコンポーネントとの間に安全な通信チャネルが生成される。第１のコンポーネントの識別情報は、第２のコンポーネントが証明機関に対して第１の証明書を検査することにより確認される。第２のコンポーネントの識別情報は、第１のコンポーネントが証明機関に対して第２の証明書を検査することにより確認される。第１の証明書及び第２の証明書の確認の成功時に、安全な通信チャネルを介してデータ交換が実施される。

添付図面において、本発明について限定ではなく、一例として説明する。添付図面では同様の参照符号は同様の要素を示す。

本発明の好ましい実施例について詳細に言及が行われる。この例が添付図面に図示されている。好ましい実施例に関して本発明を説明するが、これらは本発明をこれらの実施例に限定することを意図しないことがわかる。これに対して、本発明は、特許請求の範囲により定められる本発明の要旨及び範囲内に含まれ得る代替形態、変更形態及び均等形態をカバーすることを意図する。更に、本発明の実施例の以下の詳細な説明では、本発明の完全な理解を提供するために多数の特定の詳細が示されている。しかし、本発明はこれらの特定の詳細なしに実施され得ることが、当業者にわかる。他にも、本発明の実施例の態様をあいまいにしないように、周知の方法、手順、コンポーネント及び回路は詳細には記載されていない。

（注釈及び用語）
以下の詳細な説明のいくつかの部分は、コンピュータメモリ内のデータビットでの動作の手順、ステップ、論理ブロック、処理、及び他のシンボル表示に関して提示されている。これらの説明及び表示は、これらの作用の実体を当業者に最も効率よく伝えるためにデータ処理分野の当業者により使用される手段である。手順、コンピュータ実行のステップ、論理ブロック、処理等は、ここでは所望の結果をもたらすステップ又は命令の首尾一貫したシーケンスであり、一般的にそのように考えられる。ステップは、物理量の物理的な操作を必要とするものである。通常では、必ずしも必要ではないが、これらの量はコンピュータシステムに格納、伝達、結合、比較、又は操作可能である電気又は磁気信号の形式をとる。基本的には共通の使用の理由で、これらの信号をビット、値、要素、シンボル、文字、用語、数字等として示すことが、時には便宜であることがわかる。

しかし、前記及び同様の用語の全てが適切な物理量に関連付けられ、単にこれらの量に適用される便宜的なラベルであることが考えられるべきである。特に言及しない限り、以下の説明から明らかなように、本発明を通じて、“処理”、“アクセス”、“実行”、“格納”、“させる”等のような用語を利用した説明は、コンピュータシステム（例えば、図９のコンピュータシステム912）又は同様の電子コンピュータ装置の動作及び処理を示すことがわかる。この電子コンピュータ装置は、コンピュータシステムのレジスタ及びメモリ内で物理（電気）量として表されたデータを操作して、同様にコンピュータシステムのメモリ若しくはレジスタ又は他のこのような情報記憶、送信若しくは表示装置内の物理量として表される他のデータに変換する。

（本発明の実施例）
本発明の実施例は、２つ以上のソフトウェアコンポーネントの間で認証された秘密の通信を提供する。本発明の実施例は、埋め込まれた安全な構成機能を予めインストールしたソフトウェアコンポーネントを提供する対策を実装する。予めインストールされた安全な構成機能は、安全な通信のサポートが設計者／ソフトウェアエンジニアにより内蔵されるため、容易に使用され得る例えばロバストで安全な通信インフラストラクチャの実装を含み、従来技術に比較して複数の利点を提供する。

更に、本発明の実施例は、同じ作者／設計者からのソフトウェアコンポーネントを安全に予め構成するだけでなく、異なる作者／設計者からのソフトウェアコンポーネントが相互に認証することを可能にし、動作する実行環境の状態にかかわらず、これから認証された秘密のデータ交換を行うことを可能にする方法を記載する。本発明による方法は、実行環境にかかわらず異なるコンポーネント間の相互作用が信頼され得ることを確保するために、共通の証明機関（例えば、相互に信頼を受けた関係者）に頼る。本発明の実施例及びこれらの利点について、更に以下に説明する。

図１は、本発明の一実施例によるコンポーネント構築処理100のステップのフローチャートを示している。図１に示すように、処理100は、本発明の一実施例によるソフトウェアコンポーネントを１つ以上構築するときに、システム設計者、ソフトウェアエンジニア、コンポーネント作者等により実行される基本ステップを示している。

図２は、図１の処理100を示す図を示している。処理100について図２を参照して説明する。

処理100は、ステップ101で始まり、ソフトウェア設計者／ソフトウェア作者（例えば図２の構築エージェント201）は、ソフトウェアコンポーネント又はソフトウェアアプリケーションに組み込まれる公開秘密鍵の対（例えば、公開鍵202及び秘密鍵203）を生成する。

一実施例では、暗号化のために鍵の対（一方は公開鍵で一方は秘密鍵）を使用する非対称暗号化アルゴリズムが使用される。一般的に、公開鍵202は、データ／情報を暗号化し、対応する秘密鍵203がこれを復号化する。ユーザは、秘密鍵203を秘密に保持し、デジタル署名を暗号化して受信メッセージを復号化するためにこれを使用する。ユーザは、公開鍵202を公衆に解放し、公衆は、ユーザに送信されるメッセージを暗号化してユーザのデジタル署名を復号化するためにこれを使用する。デジタル署名では、処理は反対になり、これによって、送信者は秘密の秘密鍵203を使用して、対応する公開鍵202を保有する誰かにより読み取られ得る固有の電子番号を生成する。対応する公開鍵202は、メッセージが本当に送信者からのものであることを確認する。例えば、RSAアルゴリズム（米国特許4,405,829）は、発行可能な公開鍵と安全な秘密鍵とを生成する確立した機構について記載している。

ステップ102において、ソフトウェア設計者／コンポーネント作者（例えば構築エージェント201）は、公開鍵202と特定の識別情報データとを使用して、証明機関（例えば証明機関210）に対して証明書要求を生成する。識別情報データは、（例えば、ソフトウェアコンポーネントを作る数百の構築エージェントから）構築エージェント210を一意に特定するのに十分な情報を有する。このような情報は、例えば、構築エージェント201の名前及び住所、ライセンス番号等を有してもよい。このような証明書の共通フォーマットは、X.509符号化フォーマット（IETF RFC 2459）である。

ステップ103において、結果の証明書要求が構築エージェント210から証明機関210に送信される。典型的には、証明機関は、構築エージェント210から離れた何らかの遠隔位置にある周知のエンティティであり、証明書要求は、公衆ネットワーク215（例えばインターネット）を介して送信される。送信要求の共通に使用されるフォーマットはPKCS#7である。

一般的に、証明機関210は、デジタル証明書の信頼のある署名者として動作する。証明機関は、外部の発行会社（例えばVeriSign, Inc.等）でもよく、又は証明書を発行して確認する自分のサーバ（例えば全社的な“証明書サーバ”）にインストールされている会社内部の機関でもよい。証明機関は、認証用にデジタル証明書で使用され、注意すべき入出力情報又は秘密の入出力情報を暗号化及び復号化するために使用される“鍵”（例えば公開鍵202及び秘密鍵203）を構成する固有の数字列を提供して割り当てる役目をする。

ステップ104において、ソフトウェア設計者／コンポーネント作者（例えば構築エージェント201）は、ネットワーク215を介して証明機関210から結果の署名付き証明書を受信する。証明機関からの証明書（例えばCA証明書）は、CA証明書を組み込んだソフトウェアコンポーネントが信頼できるソースから生じているという保証を表す。CA証明書は、ソフトウェアコンポーネントについての情報（例えば、作者／設計者の識別情報、ソフトウェアコンポーネントが証明機関（CA）に登録された日付、不正防止の指標等）を提供する。一実施例では、CA証明書は、公開鍵暗号化技術（例えばX.509符号化標準（IETF RFC 2459）等）に基づく。

図３は、本発明の一実施例によるコンポーネント構築処理300のステップのフローチャートを示している。図３に示すように、処理300は、本発明の一実施例に従ってシステム設計者、ソフトウェアエンジニア、コンポーネント作者等により実行される証明書及び鍵隠蔽ステップを示している。

図４は、図３の処理300を示す図を示している。処理300について図４を参照して説明する。

証明機関210からの署名付き証明書により、構築エージェント201は埋め込まれた安全な構成機能を予めインストールしたソフトウェアコンポーネントを構築することが可能になる。前述のように、予めインストールされた安全な構成機能は、容易に使用され得るロバストで安全な通信機能を提供する。

処理300はステップ301で始まり、構築エージェント201は、リリース及び配布のためにビルドタイム環境401内でアプリケーションを用意する。典型的には、アプリケーションは、コンピュータ実行可能ソフトウェアコード（例えばアプリケーションコード410）の単位を有し、コンポーネント、モジュール、ルーチン等でもよい。例えば、コンポーネントは、一般的にはコンパイルされて動的にリンクされている個々のモジュール式ソフトウェアルーチンであり、他のコンポーネント又はプログラムと共に使用するできる状態にある。一般的に、“モジュール”という用語は、全体のプログラムを形成するように他のコンポーネントと結合され得るソフトウェアルーチン又はコンポーネントを示す。一般的に、“ルーチン”は、プログラム内で起動（例えば実行）され得るコードの何らかの部分を示す。

ステップ302において、秘密鍵203はアプリケーションコード410を有するソフトウェア内に“隠蔽”される。秘密鍵203は、例えば秘密鍵203を有するコードを隠すことにより、アプリケーションコード410内に隠蔽されてもよい。秘密鍵203を有するコードは、アプリケーション410を有するソフトウェアコード内に展開することにより隠されてもよい。例えば、アプリケーション410のみが部分を取り出して秘密鍵203を再び組み立てることができるように（例えばアプリケーション410のみが部分を探す場所を認識しているため）、秘密鍵203を有するコードは、複数の部分に分割され、アプリケーションコード410内に展開されてもよい。この分割及び展開は、秘密鍵203を効果的に隠蔽する。同様に、ステップ303において、（例えば公開鍵202を有する）CA証明書415がアプリケーションコード410を有するソフトウェア内に隠されて隠蔽される。

ステップ304において、隠蔽された秘密鍵203はアプリケーションコード410に埋め込まれる。ステップ305において、隠蔽された署名付き証明書（例えばCA証明書415）も同様にアプリケーションコード410内に埋め込まれる。ステップ306において、アプリケーションコード410が完成する。ステップ307において、（例えば、埋め込まれて隠蔽された秘密鍵202と埋め込まれて隠蔽されたCA証明書415とを有する）完成したアプリケーションが分配される。

図５は、本発明の一実施例による外部の信頼を受けた認証記憶装置コンポーネントの構築処理500のステップのフローチャートを示している。図５に示すように、処理500は、本発明の一実施例に従ってシステム設計者、ソフトウェアエンジニア、コンポーネント作者により実行される外部の信頼を受けた認証記憶装置の証明書及び鍵格納ステップを示している。

図６は、図５の処理500を示す図を示している。処理500について図６を参照して説明する。

前述のように、秘密鍵及びCA証明書の組み込みにより、構築エージェント210は、安全な構成機能を予めインストールしたソフトウェアコンポーネントを構築することが可能になる。しかし、処理500は代替実施例を記載しており、秘密鍵203及びCA証明書415は外部の信頼を受けた認証記憶装置615内に格納される。

処理500はステップ501で始まり、構築エージェント201は、リリース及び分配のためにビルドタイム環境401内でアプリケーションを用意する。ステップ502において、外部の信頼を受けた認証記憶装置615を有するソフトウェアコード（例えば、モジュール、コンポーネント等）が構築エージェント201により用意される。一実施例では、構築エージェント201は共有ライブラリ611を構築する。共有ライブラリ611は、ソフトウェア発行者（例えば構築エージェント201）が結果の完成したアプリケーションをパッケージ化する便利な方法を提供するように、信頼を受けた認証記憶装置615と共に機能する。共有ライブラリは、信頼を受けた認証記憶装置に格納された証明書415及び秘密鍵203に安全にアクセスすることができる。共有ライブラリ611は、アプリケーション610の不可欠な部分を有する。ステップ503において、秘密鍵203は信頼を受けた認証記憶装置615内に格納される。同様に、ステップ504において、（例えば公開鍵202を有する）CA証明書415が信頼を受けた認証記憶装置615内に格納される。ステップ505において、ソフトウェアコンポーネントを有するアプリケーションコード610が完成して分配される。ステップ506において、（例えば、埋め込まれて隠蔽された秘密鍵202と埋め込まれて隠蔽されたCA証明書415とを有する）信頼を受けた認証記憶装置615が完成して分配される。代替実施例では、署名付き証明書415と秘密鍵203とをアプリケーションコード610内に隠蔽する又は隠す代わりに、セキュリティを維持するために別々の信頼を受けた認証記憶装置が使用される。

図７は、本発明の一実施例による安全な通信処理700のステップのフローチャートを示している。図７に示すように、処理700は、本発明の一実施例に従って信頼のない実行環境内で安全な通信を確立する際に２つのソフトウェアコンポーネントにより実行されるステップを示している。

図８は、図７の処理700を示す図を示している。処理700について図８を参照して説明する。

処理700はステップ701で始まり、起動コンポーネント（例えば図８のアプリケーション410）は、その署名付き証明書（例えばCA証明書415）を応答コンポーネント（例えば図８のアプリケーション820）に伝送又は送信する。起動コンポーネントは、ユーザ要求又は他の要件／ニーズに応じてその証明書415を送信し、応答コンポーネントとの通信を確立する。例えば、これは、DVD映画を処理するために協力する必要のある２つの別々に許可された機能モジュールでもよい。前述のように、証明書415は隠蔽されており、（例えばアプリケーション410を具現するソフトウェアコード内の）隠蔽された位置から取り出すために、（例えば何らかの特別なアクセス手段を使用して）アプリケーション410によりアクセスされなければならない。例えば、異なる関係者から生じたソフトウェアコンポーネントの相互認証が必要な場合でもよい。例えば、これは、起動アプリケーションが応答アプリケーションから注意すべき情報を要求し、応答アプリケーションがその情報を提供して提供された情報を信頼するために認証による相互の信頼が必要になることでもよい。

ステップ702において、応答コンポーネント（例えばアプリケーション820）は、その署名付き証明書（例えばCA証明書821）を送信コンポーネントに伝送又は送信する。前述のように、証明書415及び821の双方は、それぞれの公開鍵（例えば公開鍵202及び公開鍵822）とそれぞれの識別情報とを有する。更に、証明書415と同様に、証明書821は隠蔽されており、取り出すためにアプリケーション820によりアクセスされなければならない。

ステップ703において、起動コンポーネント及び応答コンポーネント（例えばアプリケーション410及び820）は、通信セッションの持続時間に有効な秘密セッション鍵825を導く。アプリケーション410及び820は、CA証明書415及び821内で公開鍵202及び822を使用し、セッション鍵825を確立する。セッション鍵285は、双方のアプリケーション410及び820に共通の“共有の秘密”を表す。その後、ステップ704において、アプリケーション410及び820の間に安全なチャネル830を確立するために秘密セッション鍵825が使用される。チャネル830を介してアプリケーション410及び820の間で交換されるデータは暗号化されているため、チャネル830は安全である。それぞれの秘密鍵203及び823により、アプリケーション410及び820は相互に送信されるデータを復号化することが可能になる。

ステップ705において、起動コンポーネント（例えばアプリケーション410）は、証明機関を検査することにより、換言すると、証明機関（例えば証明機関210）の署名を暗号で確認することにより、応答コンポーネントの識別情報を確認する。起動コンポーネントが証明機関210の有効な署名を検出すると、応答コンポーネント（例えばアプリケーション820）の識別情報が有効であることを認識する。

ステップ706において、応答コンポーネント（例えばアプリケーション820）は、証明機関の署名を確認することにより、起動コンポーネントの識別情報を同様に確認する。応答コンポーネントが証明機関210の有効な署名を検出すると、起動コンポーネント（例えばアプリケーション410）の識別情報が有効であることを認識する。

ステップ707において、安全な通信チャネル830が確立されており、起動コンポーネント及び応答コンポーネントの識別情報が確認されているため、応答コンポーネントと起動コンポーネントとの間の秘密のデータ交換が安全な通信チャネル830を通じて実施される。

次に、ステップ708において、秘密の通信セッションが終了する。一実施例では、予め設定された期間の後に終了が生じてもよい。この期間の終了後に、（例えばステップ701〜707を繰り返すことにより）新しい秘密の通信セッションがネゴシエーションされて設定されてもよい。他の実施例では、アプリケーションによりもはや必要なくなるまで、秘密の通信セッションが存在し続けてもよい。

前述のように、TLS（transport level security）プロトコルは、認証された接続を確立する１つの共通のプロトコルを有する点に留意すべきである。TLSプロトコルは、証明書が交換されることにより、交換された証明書が有効であることを確保し、ルートレベルの証明書が実際に予め登録された証明書であることを規定する。TLSはまた、共有のセッション鍵を導き、そのセッション鍵で通信を暗号化する処理も規定する。

一実施例では、標準のTLSプロトコルが終了した後に、更なる特別の確認が生じ、（例えば、証明書の識別文字列及び信頼のある証明書のフィンガープリント／要約と予め構成されたデータとを比較することにより）信頼のあるルートレベルの証明書が実際に証明機関からのものであるか否かについて検査される。（例えば信頼のある証明書が同一であるという）この厳しい要件は、信頼機関により署名された証明書を得ることができる登録された関係者のみが認証可能であることを確保する。

（コンピュータシステムのプラットフォーム）
図９を参照すると、コンピュータシステム912が図示されている。本発明の以下の説明では、システム912のコンピュータ可読メモリユニット内に存在してシステム912のプロセッサにより実行される一連の命令（例えばソフトウェアプログラム）として一実施例で実現される特定の処理及びステップが説明される。実行されると、命令は、コンピュータシステム912に特定の動作を実行させ、ここで説明した特定の動作を提示させる。

一般的に、本発明のコンピュータシステム912は、情報を通信するアドレス／データバス900と、バス900に結合され、情報及び命令を処理する１つ以上の中央プロセッサ901と、バス900に結合され、中央プロセッサ901の情報及び命令を格納するコンピュータ可読揮発性メモリユニット902（例えば、ランダムアクセスメモリ、静的RAM、動的RAM等）と、バス900に結合され、プロセッサ901の静的な情報及び命令を格納するコンピュータ可読不揮発性メモリユニット903（例えば、読み取り専用メモリ、プログラム可能ROM、フラッシュメモリ、EPROM、EEPROM等）とを有する。任意選択で、コンピュータシステム912は、バス900に結合され、情報及び命令を格納する大容量コンピュータ可読データ記憶装置904（磁気又は光ディスク、ディスクドライブ等）を有してもよい。任意選択で、コンピュータシステム912はまた、バス900に結合され、コンピュータユーザに情報を表示する表示装置905と、バス900に結合され、中央プロセッサ901に情報及びコマンド選択を通信する英数字及び機能キーを有する英数字入力装置906と、バスに結合され、中央プロセッサ901にユーザ入力情報及びコマンド選択を通信するカーソル制御装置907と、バス900に結合され、プロセッサ901に及びプロセッサ901からメッセージ、コマンド選択、データ等を通信する信号入出力装置908とを有してもよい。コンピュータシステムにより実行されるプログラム命令は、RAM902、ROM093又は記憶装置904に格納されてもよく、グループで実行されたときに、ソフトウェアコンポーネント、論理ブロック、手順、ルーチン等と呼ばれ得る。

本発明の特定の実施例の前述の説明は、例示及び説明の目的で示されている。これらは網羅的であることを意図せず、又は開示された正確な形式に本発明を限定することを意図しない。前述の教示を鑑みて、多数の変更及び変形が可能である。本発明の原理及びその実用的な用途を最も良く説明するように、これによって、考えられる特定の仕様に適した様々な変更を有して本発明及び様々な実施例を当業者が最も良く利用することができるように、実施例が選択されて記載されている。本発明の範囲は特許請求の範囲及びその均等によって規定されることを意図する。

本発明の一実施例による鍵の対の生成処理のステップのフローチャート 本発明の一実施例による鍵の対の生成処理を示す図 本発明の一実施例によるコンポーネント構築処理のステップのフローチャート 本発明の一実施例によるコンポーネント構築処理を示す図 本発明の一実施例による外部認証コンポーネント構築処理のステップのフローチャート 本発明の一実施例による外部認証コンポーネント構築処理を示す図 本発明の一実施例による例示的な安全な通信処理のステップのフローチャート 本発明の一実施例による例示的な安全な通信処理を示す図 本発明の一実施例によるコンピュータシステムを示す図

Claims (22)

1. 信頼のない実行環境でのソフトウェアコンポーネントの安全な通信方法であって、
   第１の証明書にアクセスし、
   前記第１の証明書を応答ソフトウェアコンポーネントに送信し、
   前記応答ソフトウェアコンポーネントから第２の証明書を受信し、
   前記応答ソフトウェアコンポーネントと安全な通信チャネルを生成し、
   証明機関に対して前記第２の証明書を検査することにより、前記応答ソフトウェアコンポーネントの識別情報を確認し、
   前記応答ソフトウェアコンポーネントと安全な通信を実施することを有する方法。
2. 秘密鍵にアクセスし、
   前記秘密鍵に基づいてセッション鍵を導き、
   前記セッション鍵を使用することにより、前記応答ソフトウェアコンポーネントと前記安全な通信チャネルを生成することを更に有する、請求項１に記載の方法。
3. 前記秘密鍵及び前記第１の証明書は、前記ソフトウェアコンポーネントを有するソフトウェアコード内に隠蔽される、請求項２に記載の方法。
4. 前記第１の証明書及び前記秘密鍵は、外部の信頼を受けた認証記憶装置に格納される、請求項２に記載の方法。
5. 所定の期間の後に、前記安全な通信チャネルを終了させることを更に有する、請求項１に記載の方法。
6. 前記安全な通信の完了後に、前記安全な通信チャネルを終了させることを更に有する、請求項１に記載の方法。
7. 前記第１の証明書及び前記第２の証明書は、X509符号化標準のバージョンに従う、請求項１に記載の方法。
8. 前記安全な通信チャネルは、TLS（Transport Level Security）標準のバージョンに従って確立される、請求項１に記載の方法。
9. コンピュータシステムのプロセッサにより実行されると、前記コンピュータシステムに対して信頼のない実行環境でソフトウェアコンポーネントの安全な通信を確立する方法を実施させるコンピュータ可読コードを格納するコンピュータ可読媒体であって、
   前記方法は、
   応答ソフトウェアコンポーネントと通信する要求を受信し、
   前記応答に応じて、
   第１の証明書にアクセスし、
   前記第１の証明書を応答ソフトウェアコンポーネントに送信し、
   前記応答ソフトウェアコンポーネントから第２の証明書を受信し、
   前記応答ソフトウェアコンポーネントと安全な通信チャネルを確立し、
   証明機関に対して前記第２の証明書を検査することにより、前記応答ソフトウェアコンポーネントの識別情報を確認し、
   前記安全な通信チャネルを使用して、前記応答ソフトウェアコンポーネントと安全な通信を実施する
   ことにより、前記応答ソフトウェアコンポーネントと安全な通信チャネルを確立することを有するコンピュータ可読媒体。
10. 秘密鍵にアクセスし、
    前記秘密鍵に基づいてセッション鍵を導き、
    前記セッション鍵を使用することにより、前記応答ソフトウェアコンポーネントと前記安全な通信チャネルを生成することを更に有する、請求項９に記載のコンピュータ可読媒体。
11. 前記秘密鍵及び前記第１の証明書は、前記ソフトウェアコンポーネントを有するソフトウェアコード内に隠蔽される、請求項１０に記載のコンピュータ可読媒体。
12. 前記第１の証明書及び前記秘密鍵は、外部の信頼を受けた認証記憶装置に格納される、請求項１０に記載のコンピュータ可読媒体。
13. 前記安全な通信チャネルは、所定の期間の後に終了する、請求項９に記載のコンピュータ可読媒体。
14. 前記安全な通信チャネルは、前記安全な通信の完了後に終了する、請求項９に記載のコンピュータ可読媒体。
15. 前記第１の証明書及び前記第２の証明書は、X509符号化標準のバージョンに従う、請求項９に記載のコンピュータ可読媒体。
16. 前記安全な通信チャネルは、TLS（Transport Level Security）標準のバージョンに従って確立される、請求項９に記載のコンピュータ可読媒体。
17. 信頼のない実行環境で第１のソフトウェアコンポーネントと第２のソフトウェアコンポーネントとの間で安全な通信を実施する方法であって、
    第１の証明書を前記第２のコンポーネントに送信し、
    第２の証明書を前記第１のコンポーネントに送信し、
    前記第２のコンポーネントが前記第１の証明書の第１の公開鍵を使用し、前記第１のコンポーネントが前記第２の証明書の第２の公開鍵を使用することにより、前記第１のコンポーネントと前記第２のコンポーネントとの間に安全な通信チャネルを生成し、
    前記第２のコンポーネントが証明機関に対して前記第１の証明書を検査することにより、前記第１のコンポーネントの識別情報を確認し、
    前記第１のコンポーネントが前記証明機関に対して前記第２の証明書を検査することにより、前記第２のコンポーネントの識別情報を確認し、
    前記第１の証明書及び前記第２の証明書の確認の成功時に、前記安全な通信チャネルを介してデータ交換を実施することを有する方法。
18. 前記第１の秘密鍵及び前記第１の証明書は、前記第１のコンポーネントを有するソフトウェアコード内に隠蔽され、
    前記第２の秘密鍵及び前記第２の証明書は、前記第２のコンポーネントを有するソフトウェアコード内に隠蔽される、請求項１７に記載の方法。
19. 前記第１の秘密鍵及び前記第１の証明書並びに前記第２の秘密鍵及び前記第２の証明書は、外部の信頼を受けた認証記憶装置に格納される、請求項１７に記載の方法。
20. 前記第１の証明書及び前記第２の証明書は、X509符号化標準のバージョンに従う、請求項１７に記載の方法。
21. 前記安全な通信チャネルは、TLS（Transport Level Security）標準のバージョンに従って確立される、請求項１７に記載の方法。
22. 信頼のない実行環境での安全な通信を行うように構成されたソフトウェアコンポーネントを構築する方法であって、
    第１の証明書を生成し、
    ソフトウェアコンポーネントを構築し、前記ソフトウェアコンポーネントを有するソフトウェアコードで前記第１の証明書を隠蔽し、
    前記第１の証明書にアクセスし、
    前記第１の証明書を応答ソフトウェアコンポーネントに送信し、
    前記応答ソフトウェアコンポーネントから第２の証明書を受信し、
    前記応答ソフトウェアコンポーネントと安全な通信チャネルを生成し、
    証明機関に対して前記第２の証明書を検査することにより、前記応答ソフトウェアコンポーネントの識別情報を確認し、
    前記応答ソフトウェアコンポーネントと安全な通信を実施する
    ことにより、前記信頼のない実行環境でランタイムでの安全な通信を実施するように前記ソフトウェアコンポーネントを構成することを有する方法。

Images