JP4651197B2 - デジタル情報を転送するデバイスにおける、セキュアなマイクロプロセッサを用いた証明書の自己生成 - Google Patents

Description

【０００１】
（発明の背景）
本発明は概して、デジタルシステムにおけるデータ転送をセキュアにすることに関し、より詳細には、証明書をセキュアな様式で自己発行する能力を有するようなデジタルシステムにおけるデバイスに関する。
【０００２】
公開鍵システムは、デジタルシステムにセキュリティを提供する手段として既に広く普及している。公開鍵システム（ＰＫＳ）は、２つの異なる鍵を有し、１つは暗号化または署名用であり、もう１つは解読または照合用である。このように鍵の用途を分けることにより、署名／解読機能を照合／暗号化機能からセキュアに独立させることが可能である点において、極めてセキュリティ性に優れた有用性が得られ、このような有用性は、これらの鍵の典型的用途に適切である。公開鍵システムはまた、非対称システムまたは暗号システムとしても公知であり、このようなシステムは、対称システムまたは秘密鍵システムとして公知の非公開鍵システムと対照的である。
【０００３】
公開鍵システムにおいてメッセージを送る場合、送信者は、受信者の公開鍵を入手する。送信者は、その公開鍵を用いて、メッセージを暗号化する。次いで、暗号化されたメッセージは、受信者に送られる。プライベート鍵に対応する公開鍵／プライベート鍵のペアを所持しているのは受信者のみであるため、意図された受信者だけが、暗号化されたメッセージを解読し、見ることができる。
【０００４】
しかし、送信者が、受信者の公開鍵を最初に正確に入手できたかどうか確信できない点において、問題が生じている。例えば、受信者の公開鍵に見せかけて、不正な公開鍵が与えられている可能性がある。このような問題を防ぐために、「証明書」を用いて、公開鍵の正当性（ｌｅｇｉｔｉｍａｃｙ）に信頼性を生成する。証明書は典型的には、署名入りメッセージと共に含まれる情報であり、メッセージ上の署名を照合するために必要な公開鍵を含む。証明書は、認証当局のプライベート鍵で署名され、認証当局の公開鍵を用いることにより、証明書情報の受領者によって照合され得る。もちろん、公知の認証当局の公開鍵を最初に正確に入手するという同種の問題もある。認証を受けた公開鍵のシーケンスは、信頼性を漸進的に高くして、先行の各々の証明書公開鍵になるほどソースの信頼性を高くしたソースから入手可能である。ある時点で、証明書の公開鍵のユーザが、オリジナルの一連の証明書用の公開鍵が実際に適切なソースから来たものでありかつ有効なものであることを信用し、確信できるようにする必要がある。
【０００５】
ユーザ認証活動（ユーザの自己同一性の照合）は通常、ユーザの証明書を照合する工程を含む。このような証明書は通常、送信者の自己同一性、証明書発行者の自己同一性、送信者の公開鍵および証明書の有効期間などを含む。
【０００６】
あるデバイスから別のデバイスに新規の鍵ペアを送ることにより、鍵ペアを更新する必要が生じる場合がある。このプロシージャは、証明書により有効化されている場合は恩恵を受け得るが、更新を頻繁に行う場合、証明書の処理が必要であると、関与するシステムににとって大きな負担となり得る。また、「解読（ｂｒｅａｋ）された」または「盗まれた」プライベート鍵がシステムに与え得る影響を最小限に食い止めるためには、証明書の生成、署名および転送は不可欠である。公開鍵方式、証明書、認証等に基づいてセキュリティを維持する様式を、システムの公開鍵インフラストラクチャ（ＰＫＩ）と呼ぶ。従来からのＰＫＩを実施すると問題または負担が大きくなり得るテレコミュニケーションシステムの一例として、インターネット等のデジタルネットワークがある。このようなネットワークの場合、転送対象データは、サイズの小さなトランザクションを多く用いる高帯域のものであり、個別にやり取りされるデータの数も、対応する暗号化、解読、認証等を含めると、莫大な量となる。しかし、ＰＫＩ等によって提供されるようなセキュリティも、特に電話法または他のセキュアなデータ転送（例えば、バンキング（ｂａｎｋｉｎｇ））等のアプリケーションにおいて、大きく必要とされている。
【０００７】
大型であり、かつ融通性に富むプロトコル（例えば、インターネットプロトコル（ＩＰ））に基づくテレコミュニケーションシステムでは典型的には、データを転送する際、多くの、サーバ、スイッチ、ルータおよび他のデバイスを使用する。各デバイスは通常、ハードウェアとソフトウェアとの組み合わせを用いることが可能な個別のボックスである。このようなデバイスの大半は、多数のマイルの間隔で離れた多様な位置に配置される。これらのデバイス間の通信をセキュアに維持することだけでなく、各デバイス内での処理を、セキュリティへの攻撃に対して高い免疫性を以って行うことも確実にすることが必要である。
【０００８】
鍵の長さを短くすると、鍵が長い場合よりも、セキュリティ機能（すなわち、符号化／暗号化または復号化／解読）が少量ですむため、有用であることが多い。しかし、鍵の長さが短い場合、提供されるセキュリティレベルも、鍵の長さが長い場合に比べて低くなるため、鍵および証明書の交換を頻繁に行う必要が出てくる。初期の鍵および証明書をユニット（例えば、ケーブル電話法アダプタ）の製造業者単位でインストールし、かつ、交換鍵および証明書をネットワークサービスプロバイダから転送する場合、信頼性が一ヶ所にまとめられた（ｓｉｎｇｌｅ ｔｒｕｓｔ）アプローチの場合よりも、ロバスト性に乏しい「２重信頼性」階層が生成される。
【０００９】
そのため、認証を効率的に処理するテレコミュニケーションシステムにおいて用いられるセキュリティシステムを提供することが所望されている。
【００１０】
（発明の要旨）
本発明は、ＩＰ電話法アダプタ等の消費者向け通信デバイスが公開鍵ペアおよび証明書を自己生成することを可能にする。これにより、このような鍵および証明書を外部ソースからデバイスに送る必要が無くなり、そのため、信頼性を一ヶ所にまとめた（ｓｉｎｇｌｅ−ｔｒｕｓｔ）アプローチを維持することが可能となる。別の実施形態において、公開鍵ペアをサーバによって生成し、生成された公開鍵ペアを、暗号化されかつ署名がなされたメッセージとして、消費者デバイスに配信することができる。配信される公開鍵用の証明書は、引き続きこの消費者向けデバイスの内部で生成される。デバイスの製造時に、消費者向けデバイスの証明書に大型の公開鍵に関する製造業者の署名を付けて、デバイスにインストールする。このデバイスは、外部サーバからの署名付きリクエストに基づいて、（新規生成された短い鍵ペアに対し）証明書を発行するだけである。デバイスが自己発行した証明書は、プロフィール中のサーバから入手された情報を反映する。これにより、デバイスが自己発行した証明書に対し、サーバが制御を行うことが可能となる。自己発行された証明書が不正行為および解読を受ける事態を防ぐために、証明書発行プロセスを、セキュアなマイクロプロセッサ中で行う。
【００１１】
本発明は、テレコミュニケーションシステム中のデバイス中の自己発行証明書を提供する方法を開示する。この方法は、外部ソースからリクエストを受けとって新規証明書を生成する工程であって、上記リクエストは、証明書パラメータを含む、工程と、セキュアなマイクロプロセッサを用いて、上記証明書パラメータを用いる新規証明書を生成する工程と、データ転送の際に上記新規証明書を用いる工程と、を含む。
【００１２】
好適な実施形態は、外部ソースから新規証明書を生成するリクエストを受け取る工程であって、上記リクエストは、上記新規証明書において現れるべきパラメータの署名付きプロフィールを含む、工程を含む。このデバイスは、新規公開鍵／プライベート鍵のペアを生成し、次いで、新規証明書に署名する−これらの工程は全て、セキュアなマイクロプロセッサ内において、組み合わされた単一のオペレーションとして実行される。別の実施形態において、上記リクエスト自身は、公開鍵および暗号化されたプライベート鍵を含む。その場合、デバイスは、プライベート鍵を解読し、新規証明書に署名する。これらの工程もまた、全て、セキュアなマイクロプロセッサ内で、組み合わされた単一のオペレーションとして実行される。用いられる解読化鍵は、製造時にデバイスにインストールされた（より長い）プライベート鍵である。
【００１３】
どちらの実施形態においても、デバイスは、製造時にデバイスにインストールされた（より長い）プライベート鍵を用いて、新規証明書に署名を行うことが可能である。これらの新規鍵ペアおよび新規証明書と、デバイスの証明書署名鍵用の事前にインストールされた証明書とを用いて、セキュアなコールサインおよび他の通信を行うことが可能となる。
【００１４】
（具体的な実施形態の説明）
本発明は好適には、本明細書の冒頭部分において引用した先行文献において詳細に記載されているケーブル電話法システムに含まれる。本発明は、ケーブル電話法システムに関して具体的に説明しているものの、セキュアなトランザクションを用いるテレコミュニケーションシステムならば、実質的に任意のテレコミュニケーションシステムに適合可能である。
【００１５】
（ケーブル電話法アダプタ）
図２Ａは、本発明に従って構築されたＩＰ電話法ネットワーク１００の一部分を示す。ネットワーク１００は、ソースＣＴＡ１０４に結合された第１のユーザ１０２を含む。さらに、ソースＣＴＡ１０４は、ソースゲートウェイコントローラ１０６およびＩＰ電話法ネットワークバックボーン１１０に結合される。
【００１６】
ネットワーク１００はまた、宛先ＣＴＡ１１４に結合された第２のユーザ１１２も含む。さらに、宛先ＣＴＡ１１４は、宛先ゲートウェイコントローラ１１６およびＩＰ電話法ネットワークバックボーン１１０に結合される。加えて、ネットワーク１００はまた、カスタマーサービス代理人（ＣＳＲ）センター１２０、供給（ｐｒｏｖｉｓｉｏｎｉｎｇ）サーバ１２２および課金ホスト１２４も含む。
【００１７】
ネットワーク１００の各ユーザは、初期設定プロセスを通じて、ネットワークサービスを起動する。例えば、ユーザ１０２および関連するＣＴＡ１０４がネットワークに結合されている場合、ＣＴＡ１０４と、ゲートウェイコントローラ１０６と、ＣＳＲ１２０との間で、一連のメッセージのやり取りが行われる。これらのメッセージは、ユーザ１０２用の電話法サービスの起動と、アカウント情報の確立と、ネットワークを介してやり取りされるメッセージの暗号化および解読を行うＣＴＡによって用いられる暗号化鍵の生成とを提供する。課金ホスト１２４を用いて、各ユーザに関するアカウント情報を設定し、ネットワークの利用量に対して課金する。供給サーバ１２２を用いて、特定のＩＰ電話法ネットワーク中にあるＣＴＡデバイスの初期設定および登録を行う。
【００１８】
図２Ｂは、本発明によって構築されたＣＴＡ１０４の例示的実施形態を示す。ＣＴＡ１０４は、ケーブル入力インターフェース（Ｉ／Ｆ）２０２と、ケーブル出力Ｉ／Ｆ２０４と、ユーザ出力Ｉ／Ｆ２０６と、ユーザ入力Ｉ／Ｆ２０８と、ホストプロセッサ２１０と、メモリ２１２と、公開鍵／プライベート鍵のペア２２４をプロテクトするために用いられる追加のセキュアなプロセッサ２２０およびセキュアなメモリ２２２とを含む。証明書２１４は、署名付きであり、それ以上のプロテクトを必要としないため、通常のメモリに格納される。
【００１９】
ケーブル入力Ｉ／Ｆ２０２は、ケーブル電話法入力２１６に結合される。ケーブル出力Ｉ／Ｆ２０４は、ケーブル電話法出力２１８に結合される。これらのケーブル電話法入力およびケーブル電話法出力Ｉ／Ｆは、自身をケーブル電話法ネットワークに結合されたケーブルモデム（図示せず）接続するなどして、ＣＴＡ２００をケーブル電話法ネットワークに結合させる。別の実施形態において、ケーブルモデムはＣＴＡ中に収容され、これにより、ケーブル電話法ネットワークを直接ＣＴＡに接続することが可能となる。
【００２０】
プロセッサ２１０は、ケーブル入力Ｉ／Ｆ２０２およびケーブル出力Ｉ／Ｆ２０４に結合し、これにより、電話法ネットワークにおいて受信および転送された情報の各々の処理を行う。ライン２１６は、暗号鍵へのアクセス権を持たないため、ホストプロセッサが直接処理することが不可能な、セキュアな暗号化された情報および／または署名付き情報を搬送する。ホストプロセッサは、この情報を、暗号オペレーションを行うために必要な鍵へのアクセス権を有するセキュアなプロセッサに送らなければならない。ケーブルＩ／ＦモジュールとユーザＩ／Ｆモジュールとの間の接続部分は、未暗号化情報を搬送する。この未暗号化情報は通常、クリアテキストと呼ばれ、この情報から、ユーザをたどることが可能である。同様に、ユーザが入力したクリアテキストに暗号化および／または署名が必要な場合、このような動作をホストプロセッサを用いて直接行うことは不可能である。クリアテキストは、暗号オペレーションを行うセキュアなプロセッサへの情報上を通過する（ｐａｓｓ ｏｎ）。このようにして、暗号化されたおよび／または署名付きのデータが、ライン２１８上に現れる。
【００２１】
２１４中の証明書は、各公開鍵を、自己同一性に暗号法的に結びつける。このように公開鍵を短くし、自己署名を付けると、公開鍵をデバイスの自己同一性またはユーザの自己同一性のどちらにでも結合させることが可能となる。一方、製造時にインストールされた公開鍵が長いと、（製造時にはユーザ自己同一性が不明であるために）公開鍵を、デバイスの自己同一性に結合させなければならない。これらの証明書は、デジタル署名によって既に暗号法的にプロテクトされているため、セキュアなメモリにおいてプロテクトされない。
【００２２】
（証明書の自己発行）
図１は、本発明の基本工程を示すフローチャートである。
【００２３】
図１において、供給中、ＣＴＡがサーバからのリクエストを入手して、新規公開鍵用の証明書を自身で発行すると、フローチャート１０が開始する。例えば、好適な実施形態では、７６８ビットのＲＳＡ鍵ペアを、自己発行証明書を用いて、「小規模な」鍵ペアとして用いる。工場においてＣＴＡが作製される際、大規模な２０４８ビットのＲＳＡ公開鍵／プライベート証明書署名鍵のペアと、対応する公開鍵証明書とが、ＣＴＡに提供される。工場において、大規模な鍵交換公開鍵／プライベート鍵のペア（例えば、２０４８ビットのＲＳＡ鍵のペア）および対応する証明書も、ＣＴＡにインストールされる。
【００２４】
工程１４、１８および２０は、ＣＴＡ内のセキュアなマイクロプロセッサによって行なわれる。従って、小規模な公開鍵用の証明書および証明書を発行するために必要な工程は全て、セキュアなマイクロプロセッサ内部で行なわれる。工程１４において、署名を照合することにより、サーバからのリクエストを認証する。好適な実施形態において、工程１８において、セキュアなマイクロプロセッサ内部において、「短い」（例えば、７６８ビット）ＲＳＡ鍵ペアを生成する。別の実施形態において、工程１８を行った結果、証明書リクエストで送られた「短い」ＲＳＡプライベート鍵が解読される。工程２０において、ＣＴＡは、これもやはりサーバリクエスト中に含まれる対応する公開鍵に対し、自身で新規証明書を発行する。この新規証明書を、ＣＴＡの大規模な証明書署名鍵で署名する。この新規証明書中のパラメータ（例えば、有効期間）を、サーバによって送られる証明書リクエストからコピーし、自己発行証明書において用いる。表Ｉは、サーバリクエストのプロフィール中の異なるパラメータのリストを示す。表ＩＩは、リクエスト中のプロフィールから証明書にコピーされるパラメータをリスト化したものである。
【００２５】
・７６８ビットのＲＳＡプライベート鍵（デバイス自身が鍵のペアを生成しない場合、オプションで使用する）
・７６８ビットの公開鍵（デバイス自身が鍵のペアを生成しない場合、オプションで使用する）
・鍵／証明書の有効期間（開始時期および終了時期）
・ネットワークＩＤ
・ＣＴＡ ＩＤ
・署名アルゴリズム（例えば、ＳＨＡ−１を介したＲＳＡ）
・証明書リクエストを介した署名
・ネットワーク証明書（２０４８ビット）
・ネットワーク機器製造業者証明書
表Ｉ
・公開鍵（デバイス自身が鍵のペアを生成しない場合、オプションで使用する）
・鍵／証明書の有効期間（開始時期および終了時期）
・ネットワーク（またはサービスプロバイダ）ＩＤ
・ＣＴＡ（またはユーザ）ＩＤ
表ＩＩ
新規証明書および対応する鍵ペアを作成した後、ＣＴＡは、これらの新規証明書および対応する鍵ペアを用いて、自身を認証するか、または、セキュアな鍵交換に対し認証を行う。新規証明書の発行をセキュアなマイクロプロセッサ内部で行うため、ハッカーが証明書発行プロセスに不正行為を行うことが不可能となる。証明書は、サーバ証明書リクエスト中の情報に基づく。また、サーバ証明書リクエストをサーバのプライベート鍵で署名しなければならないため、ハッカーがサーバ証明書リクエストを偽造することも困難になる。
【００２６】
上述した特定の実施形態を改変することも可能である点に留意されたい。例えば、別の鍵サイズおよび公開鍵技術（例えば、ＲＳＡ、楕円曲線、Ｅｌ Ｇａｍａｌ等）も、利用可能である。従って、本発明を特定の実施形態に関して説明してきたが、これらの実施形態は、例示的なものに過ぎず、本発明を限定するものではない。本発明の範囲は、本明細書中の特許請求の範囲のみによって決定される。
【図面の簡単な説明】
【図１】 図１は、本発明の基本的工程を示すフローチャートである。
【図２Ａ】 図２Ａは、ケーブル電話法アダプタを含む電話法ネットワーク１００の一部を示す。
【図２Ｂ】 図２Ｂは、ＣＴＡの例示的実施形態を示す。

Claims (10)

1. テレコミュニケーションシステム中のデバイスにおいて、証明書の自己発行を提供する方法であって、該デバイスは、セキュアなメモリと、該セキュアなメモリに格納された証明書署名用の鍵と、セキュアなマイクロプロセッサとを含み、
   該方法は、
   該デバイスが、新規証明書を生成するためのリクエストを外部ソースから受け取ることであって、該リクエストは、暗号化された公開鍵を含み、該公開鍵は、該証明書署名用の鍵よりもサイズが小さい、ことと、
   該セキュアなマイクロプロセッサが、該公開鍵に基づいて新規証明書を生成することと、
   該デバイスが、該証明書署名用の鍵を用いて該新規証明書にデジタル署名することと、
   該デバイスが、データ転送において該新規証明書を用いることと
   を包含する、方法。
2. 前記リクエストは、有効期間を含み、前記セキュアなマイクロプロセッサは、前記新規証明書を生成するときに、該新規証明書中に該有効期間を含める、請求項１に記載の方法。
3. 前記デバイスが受け取るステップが、該デバイスが新規証明書を生成するための証明書のリクエストを受け取るサブステップを包含し、該証明書のリクエストが、該新規証明書に現れるパラメータの少なくとも一部についての署名されたプロフィールを含み、
   該デバイスが該新規証明書にデジタル署名するステップにおいて、前記証明書署名用の鍵は、該署名されたプロフィールに基づいている、請求項１に記載の方法。
4. 前記方法は、前記デバイスが新しい公開鍵ペアを生成することをさらに包含する、請求項３に記載の方法。
5. 前記リクエストが、暗号化されたプライベート鍵を含む、請求項１に記載の方法。
6. 前記方法は、前記デバイスが前記プライベート鍵を解読することをさらに包含する、請求項５に記載の方法。
7. 前記デバイスが前記新規証明書にデジタル署名するステップおよび該デバイスが前記プライベート鍵を解読するステップは、前記セキュアなマイクロプロセッサ内で実行される、請求項６に記載の方法。
8. 前記デバイスが前記新規証明書にデジタル署名するステップおよび該デバイスが前記プライベート鍵を解読するステップは、１つの組み合わされた動作として前記セキュアなマイクロプロセッサ内で実行される、請求項６に記載の方法。
9. 前記証明書署名用の鍵は、前記デバイスの製造時にインストールされている、請求項３に記載の方法。
10. 証明書の自己発行を提供する装置であって、
    該装置は、
    証明書署名用の鍵を格納するセキュアなメモリと、
    新規証明書を生成するためのリクエストを受け取るケーブル入力インターフェースであって、該リクエストは公開鍵を含み、該公開鍵は、該証明書署名用の鍵よりもサイズが小さい、ケーブル入力インターフェースと、
    該公開鍵に基づいて新規証明書を生成し、かつ、該証明書署名用の鍵を用いて該新規証明書にデジタル署名するセキュアなマイクロプロセッサと、
    データ転送において該新規証明書を用いる処理回路と
    を備える、装置。

Images