JP2009500905A - セキュアパッチシステム - Google Patents

Abstract

秘密保護及び鍵紛失耐性を高めることができるパッチサーバ、パッチクライアント、及び対応する方法が提供される。パッチサーバは、第１の鍵生成プラットフォーム、及び第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォームを備える。複数の第１の秘密鍵又は第２の秘密鍵をそれぞれ含む第１の秘密鍵群及び第２の秘密鍵群が、第１の鍵生成プラットフォーム又は第２の鍵生成プラットフォームを使用してそれぞれ生成される。第１の秘密鍵のうちの１つが第１の秘密鍵群から選択され、第２の秘密鍵のうちの１つが第２の秘密鍵群から選択される。第１のデジタル署名が、パッチ及び第１の秘密鍵に基づいて生成される。第２のデジタル署名が、パッチ及び第２の秘密鍵に基づいて生成される。パッチは、第１のデジタル署名及び第２のデジタル署名と共にパッチクライアントに送信される。

Description

本発明は、包括的にはソフトウェアアップデートに関し、特に、分散システムでのソフトウェアアップデートの安全な配信に関する。

多くのコンピュータメディア又は通信システムは、不正データアクセス又はワームの拡散を許し得るセキュリティホールの問題を有する。それにより、相当なダメージが発生し得る。通常、このようなセキュリティホールは、パッチとも呼ばれるセキュリティ関連ソフトウェアアップデートにより塞がれる。分散システムでは、パッチサーバによりパッチを生成し、それから複数のパッチクライアント、例えば、通信システムのモバイルユニット又は埋め込みプロセッサを有する消費者機器に配信することができる。

しかし、安全ではないシステムからロードされるパッチもやはり、悪意のある改竄から保護する必要がある。そうしなければ、ウィルス又はワームがやはり有効な攻撃を行い得る。例えば、サービス拒絶（ＤｏＳ）攻撃をＧＳＭ（移動通信用グローバルシステム）ネットに対して実行し得るため、１無線セル当たりたった１つのアクティブ装置が感染するだけで、システム全体をブロックするのに十分である。

従来技術によるシステムでは、多くの場合、非対称暗号法とも呼ばれる公開鍵暗号法（ＰＫＣ）が使用されて、安全ではないネットワークを介して秘密鍵を送信することを回避することにより、パッケージの配信を保護する。基本概念は、２つの鍵、すなわち暗号化のみに適用可能であると共に一般に公開される公開鍵（ＰＫ）及びメッセージを復号化するために知らなければならない復号鍵とも呼ばれる秘密鍵（ＳＫ）があることである。セキュリティは、公開鍵から秘密鍵を導出することの困難さ及び秘密鍵を知ることなく暗号化されたメッセージを復号化することの困難さに頼っている。

ＰＫＣの特殊な応用例がデジタル署名である。デジタル署名では、或る文書の暗号ハッシュ値が計算され、次いでこのハッシュ値が、作成者の秘密鍵を使用して暗号化され、デジタル署名が作成される。署名は、或る形態で文書に添付される。作成者の公開鍵を知る者は誰でも、文書のハッシュ値を計算し、公開鍵を使用して添付された署名を復号化し、その結果をハッシュ化された文書と比較することができる。別法として、デジタル署名は、作成者の秘密鍵を使用してハッシュ値を復号化することにより生成することもできる。検証のために、文書の受信者は再びハッシュ値を計算し、公開鍵を使用して復号化し、その結果を提供された署名と比較することができる。

正しいデジタル署名は、作成者が秘密鍵を知っていること（真正性）、署名が作成されてから、追加、削除、又は内容の変更により、又は内容の順番を部分的に入れ替えることにより文書が変更されていないこと（完全性）を証明する。後者は、利用される暗号ハッシュ関数、例えば、ＭＤ５（メッセージダイジェストアルゴリズム５）、ＳＨＡ−１（セキュアハッシュアルゴリズム１）、又はＲＩＰＥＭＤ−１６０（Ｒａｃｅ Ｉｎｔｅｇｒｉｔｙ Ｐｒｉｍｉｔｉｖｅｓ Ｅｖａｌｕａｔｉｏｎ Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ １６０）のプロパティにより提供される。しかし、例えば、秘密鍵が署名作成中に盗まれたか否かを調べることはできない。

信頼できない相手、すなわち秘密を知らない相手もデジタル署名をチェックすることができるため、非対称暗号化がデジタル署名に使用されることが多い。しかし、ＰＫＣには、気付かれるという欠点及び遅いという欠点がある。さらに、ＰＫＣシステムのセキュリティホールは介入者攻撃によるものであり得る。これは、公開鍵の真正性を何等かの方法で証明することができる場合に回避することができる。状況によっては、公開鍵の暗号チェックサム、いわゆるフィンガープリントを計算し、例えば、電話を介して受信者に直接伝えることで十分である。しかし、複雑で動的に変化する環境では、これは不可能である。したがって、公開鍵が信頼できる階層組織によりデジタル署名される公開鍵基盤（ＰＫＩ）がこのために使用される。しかし、ＰＫＩ基盤の実施及び保守は高価である。さらに、例えば、ＲＳＡ（リベスト−シャミール−アドルマン）暗号が使用される場合、ＰＫＣからいくつかのさらなる危険性及び問題が生じる。ＰＫＣの遅さの他に、平文の部分部分にランダムビットが埋められる。その理由は、そうしなければ数種類の攻撃が可能であるためである。したがって、平文は通常、公開鍵で直接暗号化されない。直接暗号化されることに代えて、ランダムセッション鍵が生成されて、例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）又はトゥーフィッシュ（Two-fish）を使用する従来の対称暗号法に使用される。ハイブリッドプロトコルと呼ばれるこういったプロトコルでは、セッション鍵のみが、公開鍵を使用して暗号化され、暗号文に追加される。

しかし、ハイブリッドプロトコルを使用する場合であってもやはり、セッション鍵を、例えば５１２ビット長又は１０２４ビット長にランダムに追加する必要がある。パディングが不十分であると、セキュリティが低減する。

さらに、秘密ＲＳＡ鍵内のビットがハードウェア又は攻撃者により反転され、この秘密鍵がメッセージの定義に使用される場合、公開鍵を因数分解することが可能であり、そのため、セキュリティが完全に崩壊する。これはＰＫＣシステムでの相当な危険性に繋がる。

さらに、トラップドアを公開鍵の生成に組み入れることができる。作成アルゴリズムの変更を知っている攻撃者は、公開鍵から秘密鍵を容易に推測することが可能であるため、この場合でもセキュリティが完全に崩壊する。

したがって、従来技術による多くのパッチシステムはＰＫＣを回避しようとする。信頼できるサーバと埋め込みプロセッサのようなクライアントとの間にダイアログがあるシステム（例えば、ＧＳＭ電話）では、（おそらくスマートカード内の）シリアル化鍵及びチャレンジ応答プロトコルが簡易で堅牢な解決策を提供するであろう。しかし、多くのシステムでは、これは適用不可能である。例えば、受信者がブート時間中に固定されており、且つ受動的である場合、シリアル化は不可能である。

別法として、当事者が秘密を共有する従来技術によるシステムは、ＨＭＡＣ（メッセージ認証のための鍵付きハッシング）のような暗号チェックサムを使用する。したがってその一例が、鍵がＳＩＭ（加入者識別モジュール）カードにより配布されるＧＳＭ／ＵＭＴＳ（移動通信用グローバルシステム／ユニバーサル移動通信システム）携帯電話における認証及び鍵処理である。この解決策はＰＫＣよりも簡易であり、高速であり、且つ堅牢である。しかし、ＨＭＡＣ暗号チェックサムにより完全性を提供することができるが、対応する秘密鍵はＥＰ（埋め込みプロセッサ）受信者のファームウェア内に固定される。したがって、この秘密ＨＭＡＣ鍵が漏れると、すべてのチェックサムの価値が無くなることになる。

したがって、多くの従来技術によるパッチシステムはデジタル署名を使用する。しかし、完全性の保証が十分ではないことが多い。パッチがリバースエンジニアリングされた場合、セキュリティホールをやはり見つけることが可能である。署名付きパッチはその信頼性しか保証せず、セキュリティを保証しない。セキュリティは、作成者の信頼によってのみ提供される。さらに、すべてのパッチクライアントのパッチに同じ公開鍵を使用して署名することには、安全性が著しく低いという欠点がある。秘密鍵が漏れると、すべてのセキュリティが失われる。さらに発生する可能性の高い状況は、秘密鍵が失われる状況である。この場合、それ以上のパッチをリリースすることができず、すべてのパッチクライアントはますます安全でなくなる。

したがって、従来技術の欠点を解消することができる改良されたパッチサーバ、パッチクライアント、及び対応する方法が提供される。実施の形態は、秘密保護及び鍵紛失耐性を高めることができる。そして、これは資産保護を強化する。さらに、鍵の暴露に対する保護を向上させることができる。他の実施の形態は、鍵生成に依然としてセキュリティホールがある場合に弱い鍵の危険性を低減することができる。

一態様によれば、パッチサーバは、パッチクライアントに接続され、パッチクライアントにパッチを提供する。パッチサーバは、第１の鍵生成プラットフォーム、第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォーム、第１の鍵セレクタ、第２の鍵セレクタ、第１の署名生成器、第２の署名生成器、及び送信器を含む。第１の鍵生成プラットフォームは、複数の第１の秘密鍵を含む第１の秘密鍵群を生成するように構成される。第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォームは、複数の第２の秘密鍵を含む第２の秘密鍵群を生成するように構成される。第１の鍵セレクタ及び第２の鍵セレクタは、第１の秘密鍵群及び第２の秘密鍵群から第１の秘密鍵及び第２の秘密鍵のうちの１つをそれぞれ選択するように構成される。第１の署名生成器は、パッチ及び選択された第１の秘密鍵に基づいて第１のデジタル署名を生成するように構成される。第２の署名生成器は、パッチ及び選択された第２の秘密鍵に基づいて第２のデジタル署名を生成するように構成される。送信器は、第１のデジタル署名及び第２のデジタル署名と共にパッチをパッチクライアントに送信するように構成される。

さらなる実施の形態では、パッチサーバは、ランダムセッション鍵を生成するように構成されるセッション鍵生成器と、対称暗号アルゴリズムを使用してランダムセッション鍵でパッチを暗号化するように構成される第１の暗号化構成要素と、マスタ鍵でランダムセッション鍵を暗号化するように構成される第２の暗号化構成要素とをさらに備え、上記送信器は、上記第１のデジタル署名及び上記第２のデジタル署名並びに上記暗号化されたランダムセッション鍵と共に上記パッチを暗号化された形態で上記パッチクライアントに送信するようにさらに構成される。

さらなる実施の形態では、パッチサーバの上記第１の暗号化構成要素は、上記対称暗号アルゴリズムを使用して、上記ランダムセッション鍵で上記第１のデジタル署名及び上記第２のデジタル署名を暗号化するようにさらに構成され、上記送信器は、暗号化された形態の上記第１のデジタル署名及び上記第２のデジタル署名並びに上記暗号化されたランダムセッション鍵と共に上記パッチを暗号化された形態で上記パッチクライアントに送信するようにさらに構成される。

別の態様によれば、パッチをパッチクライアントに提供する方法が提供される。複数の第１の秘密鍵を含む第１の秘密鍵群が、第１の鍵生成プラットフォームを使用して生成される。複数の第２の秘密鍵を含む第２の秘密鍵群が、第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォームを使用して生成される。第１の秘密鍵のうちの１つが第１の秘密鍵群から選択され、第２の秘密鍵のうちの１つが第２の秘密鍵群から選択される。第１のデジタル署名が、パッチ及び選択された第１の秘密鍵に基づいて生成される。第２のデジタル署名が、パッチ及び選択された第２の秘密鍵に基づいて生成される。パッチは、第１のデジタル署名及び第２のデジタル署名と共にパッチクライアントに送信される。

さらなる実施の形態では、本方法は、上記パッチに基づいて第１のハッシュ値を計算すること、及び上記第１のハッシュ値に基づいて第２のハッシュ値を計算することをさらに含み、上記第１のデジタル署名を生成することは、上記第２のハッシュ値及び上記選択された第１の秘密鍵に基づいて当該第１のデジタル署名を生成することを含む。

さらなる実施の形態では、本方法は、上記第２のハッシュ値に基づいて第３のハッシュ値を計算することをさらに含み、上記第２のデジタル署名を生成することは、上記第３のハッシュ値及び上記選択された第２の秘密鍵に基づいて当該第２のデジタル署名を生成することを含む。

さらなる実施の形態では、本方法は、複数のハッシュ値を計算することをさらに含み、上記パッチは複数の記録を含み、上記複数のハッシュ値を計算することは、上記パッチに含まれる最後の記録に基づいて当該複数のハッシュ値の第１のハッシュ値を計算することを含み、上記複数のハッシュ値を計算することは、上記パッチに含まれる最後から次の各記録及び当該複数のハッシュ値の最後に計算された各ハッシュ値に基づいて、当該複数のハッシュ値のさらなる各ハッシュ値を計算することをさらに含む。

さらなる実施の形態では、上記第１のデジタル署名を生成することは、上記複数のハッシュ値の最後に計算されたハッシュ値に基づいて当該第１のデジタル署名を生成することを含み、上記パッチを送信することは、当該パッチを上記第１のデジタル署名及び上記第２のデジタル署名並びに上記複数のハッシュ値と共に上記パッチクライアントに送信することを含む。

さらなる実施の形態では、上記第２のデジタル署名を生成することは、上記複数のハッシュ値の最後に計算されたハッシュ値に基づいて当該第２のデジタル署名を生成することを含み、上記パッチを送信することは、当該パッチを上記第１のデジタル署名及び上記第２のデジタル署名並びに上記複数のハッシュ値と共に上記パッチクライアントに送信することを含む。

さらなる実施の形態では、本方法は、どの第１の秘密鍵が上記第１の秘密鍵群から選択されたかを示す第１の鍵インジケータ及びどの第２の秘密鍵が上記第２の秘密鍵群から選択されたかを示す第２の鍵インジケータを含む鍵インジケータを生成することをさらに含み、上記パッチを送信することは、当該パッチを上記第１のデジタル署名及び上記第２のデジタル署名並びに上記鍵インジケータと共に上記パッチクライアントに送信することを含む。

さらなる実施の形態では、上記鍵インジケータを生成することは、上記第１のデジタル署名及び上記第２のデジタル署名のうちの一方をダミー署名として識別するダミーインジケータをさらに含む当該鍵インジケータを生成することを含む。

さらなる実施の形態では、本方法は、ランダムセッション鍵を生成すること、対称暗号アルゴリズムを使用して、上記パッチを上記ランダムセッション鍵で暗号化すること、及び上記ランダムセッション鍵をマスタ鍵で暗号化することをさらに含み、上記パッチを送信することは、上記第１のデジタル署名及び上記第２のデジタル署名並びに上記暗号化されたランダムセッション鍵と共に上記パッチを暗号化された形態で上記パッチクライアントに送信することを含む。

さらなる実施の形態では、本方法は、上記対称暗号アルゴリズムを使用して、上記第１のデジタル署名及び上記第２のデジタル署名を上記ランダムセッション鍵で暗号化すること、及び上記ランダムセッション鍵をマスタ鍵で暗号化することをさらに含み、上記パッチを送信することは、上記暗号化された第１のデジタル署名及び上記暗号化された第２のデジタル署名並びに上記暗号化されたランダムセッション鍵と共に当該パッチを暗号化された形態で上記パッチクライアントに送信することを含む。

さらなる態様は、パッチサーバに接続されてパッチサーバからパッチを受信するパッチクライアントに関連する。パッチクライアントは、第１の記憶手段及び第２の記憶手段、第１の鍵セレクタ及び第２の鍵セレクタ、並びに第１の署名検証構成要素及び第２の署名検証構成要素を備える。第１の記憶手段は、第１の鍵生成プラットフォームにより生成された複数の第１の公開鍵を含む第１の公開鍵群を記憶する。第２の記憶手段は、第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォームにより生成された複数の第２の公開鍵を含む第２の公開鍵群を記憶する。第１の鍵セレクタ及び第２の鍵セレクタは、第１の公開鍵群及び第２の公開鍵群から第１の公開鍵及び第２の公開鍵のうちの１つをそれぞれ選択するように構成される。第１の署名検証構成要素は、選択された第１の公開鍵を使用して、パッチと共にパッチサーバから受信する第１のデジタル署名を検証するように構成される。第２の署名検証構成要素は、選択された第２の公開鍵を使用して、パッチと共にパッチサーバから受信する第２のデジタル署名を検証するように構成される。パッチクライアントは、第１のデジタル署名及び第２のデジタル署名の検証結果が第１のデジタル署名及び第２のデジタル署名の真正性並びに完全性をそれぞれ示す場合のみ、パッチをインストールするように構成される。

さらなる実施の形態では、パッチクライアントは、上記パッチに基づいて第１のハッシュ値を計算するように構成される第１のハッシャと、上記第１のハッシュ値に基づいて第２のハッシュ値を計算するように構成される第２のハッシャとをさらに備え、上記第１の署名検証構成要素は、上記第２のハッシュ値に基づいて上記第１のデジタル署名を検証するようにさらに構成される。

さらなる実施の形態では、パッチクライアントは、上記第２のハッシュ値に基づいて第３のハッシュ値を計算するように構成される第３のハッシャをさらに備え、上記第２の署名検証構成要素は、上記第３のハッシュ値に基づいて上記第２のデジタル署名を検証するようにさらに構成される。

さらなる実施の形態では、上記第１の署名検証構成要素は、上記パッチと共に上記パッチサーバから受信される第１のハッシュ値に基づいて、上記第１のデジタル署名を検証するようにさらに構成され、上記第２の署名検証構成要素は、上記第１のハッシュ値に基づいて上記第２のデジタル署名を検証するようにさらに構成される。

さらなる実施の形態では、上記第１の鍵セレクタは、上記パッチと共に上記パッチサーバから受信される第１の鍵インジケータに従って上記第１の公開鍵のうちから上記１つの第１の公開鍵を選択するようにさらに構成され、上記第２の鍵セレクタは、上記パッチと共に上記パッチサーバから受信される第２の鍵インジケータに従って上記第２の公開鍵のうちから上記１つの第２の公開鍵を選択するようにさらに構成される。

さらなる実施の形態では、パッチクライアントは、上記パッチと共に上記パッチサーバから受信されるダミーインジケータが、上記第１のデジタル署名又は上記第２のデジタル署名をダミー署名としてそれぞれ識別する場合、当該第１のデジタル署名又は当該第２のデジタル署名を検証する結果を無視するようにさらに構成される。

さらなる実施の形態では、パッチクライアントは、マスタ鍵を記憶する第３の記憶手段と、上記パッチと共に上記パッチサーバから受信される暗号化されたランダムセッション鍵を復号化して、ランダムセッション鍵を得るように構成される第１の復号化構成要素と、上記ランダムセッション鍵を使用して対称復号化アルゴリズムを適用することにより上記パッチを復号化するように構成される第２の復号化構成要素とをさらに備える。

さらなる実施の形態では、上記第２の復号化構成要素は、上記ランダムセッション鍵を使用して上記対称復号アルゴリズムを適用することにより、上記第１のデジタル署名及び上記第２のデジタル署名を復号化するようにさらに構成される。

さらなる実施の形態では、上記マスタ鍵は、上記第３の記憶手段に記憶されている他の情報の中に隠されて上記第３の記憶手段に記憶される。

さらなる実施の形態では、上記マスタ鍵は、パッチクライアントの製造工程中に上記第３の記憶手段に入力される。

さらなる実施の形態では、上記第１の公開鍵群及び上記第２の公開鍵群は、パッチクライアントの製造工程中に上記第１の記憶手段及び上記第２の記憶手段にそれぞれ入力される。

さらに別の態様によれば、パッチをパッチクライアントにインストールする方法が提供される。パッチは、第１のデジタル署名及び第２のデジタル署名と共にパッチクライアントに接続されたパッチサーバから受信される。第１の鍵生成プラットフォームにより生成された複数の第１の公開鍵を含む第１の公開鍵群が、パッチクライアントに記憶される。さらに、第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォームにより生成された複数の第２の公開鍵を含む第２の公開鍵群が、パッチクライアントに記憶される。第１の公開鍵のうちの１つの鍵及び第２の公開鍵のうちの１つの鍵が、第１の公開鍵群及び第２の公開鍵群からそれぞれ選択される。第１のデジタル署名が選択された第１の公開鍵を使用して検証され、第２のデジタル署名が選択された第２の公開鍵を使用して検証される。パッチは、第１のデジタル署名及び第２のデジタル署名の検証結果が、第１のデジタル署名及び第２のデジタル署名の真正性並びに完全性をそれぞれ示す場合のみ、パッチクライアントにインストールされる。

さらなる実施の形態では、本方法は、上記パッチに基づいて第１のハッシュ値を計算すること、及び上記第１のハッシュ値に基づいて第２のハッシュ値を計算することをさらに含み、上記第１のデジタル署名を検証することは、上記第２のハッシュ値に基づいて当該第１のデジタル署名を検証することを含む。

さらなる実施の形態では、本方法は、上記第２のハッシュ値に基づいて第３のハッシュ値を計算することをさらに含み、上記第２のデジタル署名を検証することは、上記第３のハッシュ値に基づいて当該第２のデジタル署名を検証することを含む。

さらなる実施の形態では、本方法は、上記パッチと共に上記パッチサーバから第１のハッシュ値を受信することをさらに含み、上記第１のデジタル署名を検証することは、上記第１のハッシュ値に基づいて当該第１のデジタル署名を検証することを含み、上記第２のデジタル署名を検証することは、上記第１のハッシュ値に基づいて当該第２のデジタル署名を検証することを含む。

さらなる実施の形態では、本方法は、上記パッチと共に上記パッチサーバから第１の鍵インジケータ及び第２の鍵インジケータを受信することをさらに含み、上記第１の公開鍵のうちの上記１つの鍵を選択することは、上記第１の鍵インジケータに従って上記第１の公開鍵のうちの当該１つの鍵を選択することを含み、上記第２の公開鍵のうちの上記１つの鍵を選択することは、上記第２の鍵インジケータに従って上記第２の公開鍵のうちの当該１つの鍵を選択することを含む。

さらなる実施の形態では、本方法は、上記パッチと共に上記パッチサーバからダミーインジケータを受信すること、及び上記ダミーインジケータが、上記第１のデジタル署名又は上記第２のデジタル署名をそれぞれダミー署名として示す場合、当該第１のデジタル署名又は当該第２のデジタル署名の検証結果を無視することをさらに含む。

さらなる実施の形態では、本方法は、上記パッチサーバから上記パッチと共に暗号化されたランダムセッション鍵を受信すること、マスタ鍵を上記パッチクライアントに記憶すること、上記マスタ鍵を使用して上記暗号化されたランダムセッション鍵を復号化することであって、それにより、ランダムセッション鍵を得る、復号化すること、及び上記ランダムセッション鍵を使用して対称復号化アルゴリズムを適用することにより、上記パッチを復号化することをさらに含む。

さらなる実施の形態では、本方法は、上記ランダムセッション鍵を使用して、上記対称復号化アルゴリズムを適用することにより上記第１のデジタル署名及び上記第２のデジタル署名を復号化することをさらに含む。

さらなる実施の形態では、上記マスタ鍵を上記パッチクライアントに記憶することは、当該マスタ鍵を当該パッチクライアントに記憶されている他の情報の中に隠して記憶することを含む。

さらなる実施の形態では、本方法は、上記パッチクライアントの製造工程中に、上記マスタ鍵を当該パッチクライアントに入力することをさらに含む。

さらなる実施の形態では、本方法は、上記パッチクライアントの製造工程中に、上記第１の公開鍵群及び上記第２の公開鍵群を当該パッチクライアントに入力することをさらに含む。

添付図面は、本発明の原理を説明するために本明細書に組み込まれてその一部を成す。図面は、本発明を、本発明をどのように作って使用することができるかについて例示され説明される例のみに限定するものとして解釈されるべきではない。さらなる特徴及び利点が、添付図面に示される本発明の以下のより具体的な説明から明らかになるであろう。

本発明の例示的な実施形態について、図面を参照してこれより説明する。パッチクライアント、例えば或る装置の埋め込みプロセッサのソフトウェアは、パッチを安全ではないシステムから得る可能性がある。本実施形態は、これらパッチが適用されるときに改竄されないことを保証することができる。例えば、或るウィルス又はワームにより悪意のあるパッチが行われ得る。ソフトウェア又はパッチ自体の未発見のセキュリティホールが同じ影響を有することも可能であり得る。本実施形態は、パッチクライアントをこのような状況の悪影響から保護することができる。

図１に、一実施形態によるパッチシステムの構成要素を示す。パッチサーバ１００は複数のパッチクライアント１４０に接続されて、セキュリティ関連ソフトウェアアップデート、すなわちパッチをパッチクライアントに提供する。パッチクライアントは、例えば、埋め込みシステム、パーソナルコンピュータ、又はメディア／通信装置であってもよい。パッチクライアントは、任意の種類の適した接続、例えば、無線又は有線接続を通じてパッチサーバ１００に接続することができる。パッチサーバ１００はコンピュータ又は分散コンピュータシステムであってもよい。

図示の実施形態によれば、パッチサーバ１００は３つの鍵生成プラットフォーム１１０、１２０、１３０を含む。プラットフォーム１１０、１２０、１３０は互いに別個であることができ、鍵の生成及び処理の両方の機能を提供することができる。一般に、プラットフォームは、ソフトウェアを実行できるようにするハードウェア、ソフトウェア、又はハードウェア及びソフトウェアの両方の或る種の枠組みを表す。本実施形態の鍵生成プラットフォーム１１０、１２０、１３０は、異なるアプリケーション及びハードウェアに基づき、並列に使用することができる。これは、鍵生成装置に組み込まれたトラップドアに関してセキュリティを向上させることができる。しかし、ＨＳＭ（ハードウェアセキュリティモジュール）が許容できる唯一のベースである実施形態では、鍵生成に異なるソフトウェア及びハードウェアを使用することは重要ではない可能性がある。

実施形態によれば、第１の鍵生成プラットフォーム１１０は、ｎＣｉｐｈｅｒのｎＳｈｉｅｌｄ ＨＳＭのいくらかの助けにより鍵を生成して記憶する。第２の鍵生成プラットフォーム１２０は、Ｋｎｏｐｐｉｘ Ｌｉｎｕｘの下で鍵を生成して使用することができる。Ｋｎｏｐｐｉｘ Ｌｉｎｕｘは、ＲＡＭ（ランダムアクセスメモリ）のみで動作し、ハードディスクにトレースを残さない。生成された鍵は、暗号化された形態で外部に記憶することができる。第２の鍵生成プラットフォーム１２０での鍵処理は、ＯｐｅｎＳＳＬにより達成することができる。さらに、秘密鍵をアンロックして使用するには２人の異なる人が順にタイプしなければならないように、長いパスフレーズを分割することができる。第３の鍵生成プラットフォーム１３０は、従来通りにＯｐｅｎＳＳＬにより鍵を処理するが、ＳＥＬｉｎｕｘ（セキュリティ強化Ｌｉｎｕｘ）システム又は或る等価の高セキュリティオペレーティングシステムの下でそれを行う。別法として、第３の鍵生成プラットフォーム１３０はクリプトカードを使用することができる。

秘密鍵の漏出を防ぐことに関する信頼性を高めるために、秘密共有法（「（ｋ，ｎ）閾値法（ｋ ｏｆ ｎ ｏｐｅｒａｔｏｒ ｃａｒｄｓ）」）をｎＳｈｉｅｌｄに使用することができる。独立した当事者を署名プロセスに含め、鍵を第１の鍵生成プラットフォーム１１０の２人の管理者又は管理者群に分けることができる。

本実施形態のパッチシステムは、鍵生成プラットフォーム１１０、１２０、１３０により生成されて管理される秘密鍵の様々なサブセットを使用する複数の署名でパッチに署名する。対応する公開鍵も鍵生成プラットフォーム１１０、１２０、１３０によりそれぞれ生成し、パッチクライアント１４０の製造中にパッチクライアント１４０に入力することができる。次いで、公開鍵をパッチクライアント１４０の公開鍵行列１５０に記憶する。

パッチは、パッチクライアント１４０に送信される前に、ランダムセッション鍵を使用して対称暗号化することができる。そして、ランダムセッション鍵を、すべてのパッチクライアント１４０に一般的に使用することができる、鍵暗号鍵（ＫＥＦ）１６０とも呼ばれる秘密マスタ鍵を使用して暗号化することができる。これは、従来技術によるＰＫＣシステムからの速度及び簡易さの増大を提供することができる。さらに、暗号化アルゴリズムの未知の弱点に対する保護を増大させることができる。同じ鍵で暗号化される平文の部分がより小さいため、攻撃者がこれらの弱点を利用することが難しくなり得る。ＫＥＫ鍵１６０は、パッチサーバ１００により安全に記憶することができる。

パッチクライアント１４０では、ＫＥＫ鍵１６０を隠れた形態で記憶してセキュリティを向上させることができる。このために、ハードウェア手段及びソフトウェア手段を組み合わせることができる。例えば、１２８ビット鍵を、いくつかの１２８ビット部分からのＸＯＲ（排他的ＯＲ）ゲーティング（秘密分割）を介して構築することができる。データをプログラムにわたって分散させることができ、これを見つけることは困難である。

さらに、例えば、プログラムのいくつかのまったく異なる場所にあるマクロにより行われたクレイジー計算を介して動的に割り当てられる関数ポインタを使用することにより、リバースエンジニアリングへの対策を提供すると共に、デバッガを使用できないようにすることができる。このような秘密分割は、実際に誰にも鍵を知られずに、プログラムのみが実行中に一時的に鍵を構築できるように、暗号化中に利用することができる。

公開鍵行列１５０及び鍵暗号鍵１６０は、各パッチクライアント１４０がユーザに販売される前にベンダーによりパッチクライアント１４０にプラグインすることができる。対応する秘密鍵は、ベンダー側の安全な場所に残すことができる。本実施形態でのように、公開鍵は固定であり、秘密鍵の変更は不可能であり、破棄のみが可能である。したがって、秘密鍵をパッチサーバ１００内に隠すことができる。

各パッチクライアント１４０は、リプレイ攻撃を防ぐために、最後に受信したパッチのシーケンス番号を記憶するリセット不可能カウンタを含むことができる。これにより、既知のセキュリティホールを有するより古いパッチが適用されるのを防ぐことができる。このために、パッチクライアント１４０は、例えば、パッチと共に受信するタイムスタンプを無線受信する時刻と突き合わせてチェックすることができる。

各パッチは複数のパッチ記録を含むことができる。オーバーフローを使用した攻撃を防ぐために、パッチ記録の数及びサイズはソフトウェアにより制限することができる。パッチングが完了している限り、パッチ記録をアクティブ化しなくてもよい。したがって、単一のパッチ記録のチェックサムを計算する必要がなくてもよい。

本実施形態によれば、１２個の鍵ペアがパッチの署名に使用される。各パッチは３つの署名を含むことができ、各署名は、より詳細に後述するように、４個から成る群からの１つの鍵に基づく。根本的な原理を図２及び図３に示す。

図２は、パッチサーバ１００により生成され管理される１組の秘密鍵２００〜２５５を示す。第１の秘密鍵群２６０は４つの秘密鍵２００〜２１５を含むことができる。同様に、第２の秘密鍵群２７０は４つの他の秘密鍵２２０〜２３５を含むことができ、第３の秘密鍵群２８０はさらなる４つの秘密鍵２４０〜２５５を含むことができる。第１の鍵生成プラットフォーム１１０、第２の鍵生成プラットフォーム１２０、及び第３の鍵生成プラットフォーム１３０が、第１の秘密鍵群２６０、第２の秘密鍵群２７０、及び第３の秘密鍵群２８０をそれぞれ生成し処理することができる。一実施形態によれば、３つの秘密鍵群２６０、２７０、２８０は異なる信用レベルを有し得る。

鍵生成プラットフォーム１１０、１２０、１３０では、ＨＳＭを使用して、秘密鍵２００〜２５５の違法抽出を防ぐことができる。別法として、例えば、安全な記憶並びに完全な信頼性という利点を提供することができる、ＨＳＭ及びＫｎｏｐｐｉｘ／ＯｐｅｎＳＳＬに基づく「混合鍵」を使用してもよい。さらに、これにより、別のＨＳＭ装置を必要とすることなく鍵の生成及び鍵の復元を制御することができる。秘密鍵２００〜２５５へのアクセス権は、協働しない群に分割することができる。さらに、秘密共有（ＨＳＭの場合には（３,５）閾値法）の原理を利用することができる。

対応する公開鍵は、図３により詳細に示す、パッチクライアント１４０の行列１５０に記憶することができる。

第１の公開鍵群３６０は、第１の秘密鍵群２６０の秘密鍵２００〜２１５のそれぞれに対応する４つの公開鍵３００〜３１５を含むことができる。第１の公開鍵群３６０は、第１の鍵生成プラットフォーム１１０により生成されて、製造中にパッチクライアント１４０に入力しておくことができる。第２の鍵生成プラットフォーム１２０により生成されて、且つベンダーによりパッチクライアント１４０に入力された第２の公開鍵群３７０は、第２の秘密鍵群２７０の秘密鍵に対応する４つの公開鍵３２０〜３３５を含むことができる。最後に、第３の公開鍵群３８０は、第３の秘密鍵群２８０の４つの秘密鍵２４０〜２５５に対応する４つの公開鍵３４０〜３５５から成ることができる。第３の公開鍵群３８０は、第３の公開鍵生成プラットフォーム３８０により生成され、販売前にパッチクライアント１４０に記憶しておくことができる。

秘密鍵２００〜２５５は標準化されたフォーマットで生成することができる。これは、鍵のバックアップ及び惨事復元を提供することができる。さらに、鍵生成は、任意のセキュリティプロバイダに依存しなくてもよい。ＲＳＡ暗号を適用する実施形態では、公開鍵３００〜３５５は、モジュラス（すなわち、秘密鍵素数の積ｐ^＊ｑ）及び公開鍵指数を介してＣ個のヘッダとして直接処理することができる。署名は、ＲＳＡのＣｒｙｐｔｏＣＭＥ及びＢＳＡＦＥライブラリ並びにＨＳＭ装置と協働するＯｐｅｎＳＳＬによりサポートされるＰＫＣＳ＃１（公開鍵暗号化標準＃１）において生成することができる。

一実施形態では、公開鍵３００〜３５５は１０２４ビット長であることができる。しかし、他の実施形態では、他の鍵長を使用してもよい。例えば、５１２ビットＲＳＡ又はＤＳＡ（デジタル署名アルゴリズム）鍵を使用して、記憶容量及び署名チェックの計算時間を節減することができる。ＫＥＫ鍵１６０とは対照的に、公開鍵３００〜３５５はパッチクライアント１４０内に隠さなくてもよい。本実施形態によれば、ＫＥＫ鍵１６０はすべてのパッチクライアント１４０のマスタ鍵であり、ビット長１２８ビットを有する。例えば、ＫＥＫ鍵１６０は１２８ビットＡＥＳ鍵であることができる。別法として、１２８ビットトゥーフィッシュ鍵又は２５６ビットＡＥＳ鍵、又は他の任意の適した鍵をＫＥＫ鍵１６０に使用してもよい。

１２個の鍵ペアをパッチの署名に使用することが単なる特定の例にすぎないことに留意されたい。別法として、より少数又は多数の鍵群を利用してもよく（この場合、パッチサーバ１００はそれぞれ、より少数又はより多数の鍵生成プラットフォームを含む）、各公開／秘密鍵群が４つよりも少数又は多数の公開／秘密鍵を含んでもよい。さらに、行列内の鍵の配置は、例示だけのために選択されたものである。公開鍵及び秘密鍵を記憶するために他の様々な形態を使用してもよい。特に、３つの秘密鍵群２６０、２７０、２８０は、３つの鍵生成プラットフォーム１１０、１２０、１３０を使用して別個に記憶して処理することができる。セキュリティのために、各秘密鍵群２６０、２７０、２８０の個々の秘密鍵２００〜２５５でさえも別個に記憶することができる。

これより、図４〜図８、図１１および図１４を参照して、第１の実施形態によるパッチサーバ１００の動作について説明する。この実施形態では、パッチクライアント１４０は、パッチ全体を読み取った後に、パッチと共にパッチサーバ１００から提供される署名を検証することができる。

図４は、実施形態によるパッチサーバ１００の全体的な動作を示す。ステップ４００において、ハッシュチェインを行うことができる。ハッシュチェイン４００は、図５に示すような４つのステップを含み得る。

最初に、ステップ５１０において、パッチをハッシングすることにより、基本ハッシュ値Ｈを計算することができる。その後、ステップ５２０において、基本ハッシュ値Ｈと値０を有するバイトとの結合（Ｈ｜‘０’）をハッシングすることにより、第１のハッシュ値Ｈ_１を計算することができる（ここで、「｜」は結合を意味し、‘０’は値０を有するバイトである）。次いで、ステップ５３０において、ステップ５２０において計算された第１のハッシュ値Ｈ_１と値１を有するバイト‘１’との結合（Ｈ_１｜‘１’）をハッシングすることにより、第２のハッシュ値Ｈ_２を計算することができる。最後に、ステップ５３０から得られる第２のハッシュ値Ｈ_２と値２を有するバイト‘２’との結合（Ｈ_２｜‘２’）をハッシングすることにより、第３のハッシュ値Ｈ_３を計算することができる（ステップ５４０）。

本実施形態によれば、各パッチは、ステップ４２０において３つのハッシュ値Ｈ_１、Ｈ_２、及びＨ_３に基づいて計算される（以下参照）３つの署名を含むことに留意されたい。他の実施形態では、パッチはより少数又はより多数の署名を含んでもよい。これら実施形態では、ハッシュチェイン４００はそれに応じてより短い場合もあれば、より長い場合もある。

図４に戻ると、ここで、ステップ４２０において署名を作成するための秘密鍵をステップ４１０において選択することができる。本実施形態による秘密鍵選択４１０の個々のステップを図６に示す。

秘密鍵は、ステップ６１０において、第１の秘密鍵群２６０から選択することができる。次いで、ステップ６２０において、第２の秘密鍵を第２の秘密鍵群２７０から選択することができる。同様に、ステップ６３０において、第３の秘密鍵を第３の秘密鍵群２８０から選択することができる。

図示するステップの順番は単に例示のためだけに選択されたことを理解されたい。もちろん、秘密鍵は任意の他の順序で選択してもよい。別法として、ステップ４００においてハッシュチェインを実行する前に、秘密鍵のいくつか又はすべてを選択してもよい。さらに、異なる数の秘密鍵群２６０〜２８０を使用する実施形態では、秘密鍵の選択４１０は、それに応じて図６に示す３つのステップ６００〜６３０よりも少数又は多数の選択ステップを含み得る。

秘密鍵の選択４１０の後、ステップ４２０において、３つのデジタル署名Ｄ_１〜Ｄ_３を生成することができ、これらを後に、真正性及び完全性をチェックできるように、パッチクライアント１４０に送信されるパッチに追加することができる。秘密鍵の選択４１０を図７により詳細に示す。

ステップ７１０において、ステップ６１０において選択された第１の秘密鍵を使用して、ステップ５２０において計算された第１のハッシュ値Ｈ_１に署名することにより、第１のデジタル署名Ｄ_１を計算することができる。次いで、ステップ７２０において、ステップ６２０において第２の秘密鍵群２７０から選択された第２の秘密鍵を使用して、ステップ５３０から得られる第２のハッシュ値Ｈ_２に署名することにより、第２のデジタル署名Ｄ_２を計算することができる。最後に、ステップ７３０において、ステップ６３０において選択された第３の秘密鍵を使用して、ステップ５４０において計算された第３のハッシュ値Ｈ_３に署名することにより、第３のデジタル署名Ｄ_３を計算することができる。したがって、本実施形態は各種類の１つの鍵に基づく三重署名（signature triples）を利用する。

それにより、ハッシュ値Ｈ_１〜Ｈ_３のそれぞれを署名することは、選択された各秘密鍵を使用しての暗号化（又は利用される署名アルゴリズムに応じて復号化）が後に続く別のハッシュ演算を含み得る。別法として、単に、対応する選択された秘密鍵で各ハッシュ値Ｈ_１〜Ｈ_３を暗号化又は復号化することにより、デジタル署名Ｄ_１〜Ｄ_３を計算してもよい。鍵生成プラットフォーム１１０〜１３０にどの実施が使用されるかに応じて、デジタル署名Ｄ_１〜Ｄ_３の作成に他のアルゴリズムを使用することができる。ここでも、図７に示すステップの特定の順番は単に例示的な性質を有するにすぎない。他の実施形態では、デジタル署名Ｄ_１〜Ｄ_３は任意の他の順番で作成してもよく、又は署名作成ステップ４２０を、ハッシュチェインステップ４００及び／又は秘密鍵選択ステップ４１０に差し込むこともできる。例えば、第１のハッシュ値Ｈ_１が計算され（ステップ５２０）、第１の秘密鍵が選択された（ステップ６１０）直後に、第１のデジタル署名Ｄ_１を計算するステップ７１０を実行してもよい。第２のデジタル署名Ｄ_２の計算７２０も同様に前に持ってくることができる。さらに、より多数又はより少数のデジタル署名がパッチに追加される実施形態では、署名作成４２０はそれに応じてより多数又はより少数の計算ステップを含み得る。

ステップ４２０において署名が作成された後、ステップ４３０において、署名のうちの１つをダミー署名とすべきか否かを判断することができる。ダミー署名の使用により、侵害された鍵又は失われた鍵を安全にスキップすることが可能になる。例えば、仮にステップ６１０〜６３０のうちの１つのステップにおいて、侵害されていることが分かっている秘密鍵が選択された場合、ステップ４３０において、対応するデジタル署名をダミー署名にすべきであると判断することができる。このために、パッチサーバ１００は、秘密鍵２００〜２５５のどれが盗まれたか、又は失われたこと、すなわちこれ以上使用すべきではないことを何等かの適当な形態で記憶することができる。これは、例えば、対応するルックアップテーブルを保持することにより行うことができる。したがって、本実施形態によれば、失われた鍵、又は盗まれた鍵を安全にスキップすることができる。そのような鍵を取り消して交換する必要はなくてもよい。

ダミー署名を使用すべき場合、ステップ４４０において、ステップ４２０において作成された各デジタル署名をダミーで置き換えることができる。別法として、署名をダミー署名にすべきか否かの判断４３０は、署名作成前にしてもよく、署名をダミー署名とすべき場合、各署名にダミーを直接使用して、対応する署名作成ステップ７１０、７２０、７３０をスキップすることができる。

ステップ４５０において、鍵インジケータを作成することができる。鍵インジケータは、３つの秘密鍵群２６０、２７０、２８０からどの鍵がステップ４１０において選択されたかを特定することができる。鍵インジケータの例示的な構成を図１１に示す。

本実施形態によれば、鍵インジケータは８ビット整数値である。最初の２ビットは、第１の秘密鍵群２６０の４つの秘密鍵２００〜２１５のうちのどれが、第１のデジタル署名Ｄ_１の作成用に選択されたかを指定する第１の鍵インジケータ１２１０を表すことができる。例えば、これら最初の２ビットの値が３である場合、これは、第３の秘密鍵２１０がステップ６１０において選択され、ステップ７１０において適用されたことを示すことができる。次の２ビットは、第２の秘密鍵群２７０の４つの秘密鍵２２０〜２３５のうちのどれが、第２のデジタル署名の作成（ステップ７２０）用に選択された（ステップ６２０）かを示す第２の鍵インジケータ１２２０を構築することができる。同様に、第５のビット及び第６のビットを第３の鍵インジケータ１２３０に使用して、ステップ７３０での第３のデジタル署名の生成用に、４つの秘密鍵２４０〜２５５のうちのどれがステップ６３０において選択されたかを特定することができる。

より多数又はより少数の秘密鍵群が使用される実施形態では、鍵インジケータはそれに応じてより多数又はより少数の個々の鍵インジケータ１２１０〜１２３０を含むことができる。さらに、各秘密鍵群２６０、２７０、２８０が４つよりも多数又は少数の秘密鍵を含む実施形態があってもよい。この場合、第１の鍵インジケータ１２１０〜第３の鍵インジケータ１２３０はそれに応じてより長くてもよく、又はより短くてもよい。さらに、個々の鍵インジケータ１２１０〜１２３０は異なる順序であってもよい。

鍵インジケータは、ダミー署名が使用されたか否か、使用された場合、署名のどれがダミー署名であるかをさらに特定することができる。このために、図１１に示す鍵インジケータの最後の２ビットは、ダミーインジケータ１２４０を表す。本実施形態によれば、ダミーインジケータ１２４０は、その２ビットの値が０である場合、３つすべての署名Ｄ_１〜Ｄ_３が有効な署名であることを特定する。値が１、２、又は３の場合、それにより第１の署名、第２の署名、又は第３の署名がそれぞれダミー署名であることを示すことができる。別法として、もちろん、ダミーインジケータの値を別様に割り当ててもよい。

他の実施形態では、３つよりも多数又は少数の署名を使用して、パッチを署名してもよい。その場合、ダミーインジケータ１２４０はそれに応じて２ビットよりも長くてもよく、又は短くてもよい。さらに、２つ以上の署名がダミー署名であってもよい。このような実施形態では、ダミーインジケータ１２４０も２ビットよりも長くなり得る。

鍵インジケータが作成されると、ステップ４６０において、パッチブロックを組み立てることができる。本実施形態によれば、パッチブロックは図１１に示すフォーマットを有する。

図１１に示すように、パッチブロック１１００は、ステップ７１０において作成された第１のデジタル署名１１１０で開始することができ、その後、ステップ７２０及び７３０においてそれぞれ生成された第２のデジタル署名１１２０及び第３のデジタル署名１１３０に続く。署名１１１０〜１１３０に続き、パッチブロック１１１０はステップ４５０から得られる鍵インジケータ１１４０を含むことができる。最後に、パッチ１１５０自体をパッチブロック１１４０に含めることができる。図１１に示すパッチブロック１１００の特定の構成を、本発明を限定するものとして解釈すべきではない。他の実施形態では、パッチブロック１１００は別の方法で配置することができる。

パッチブロックの組み立て後、ステップ４７０において、ＫＥＫ暗号化を行うことができる。本実施形態によるＫＥＫ暗号化４７０を図８により詳細に示す。

ステップ８１０において、以下において対称鍵とも呼ばれるランダムセッション鍵を生成することができる。セッション鍵の生成は、例えば、ｎＣｉｐｈｅｒ ＨＳＭ装置のオペレータカード上で共有される秘密鍵により、パスフレーズの分割された部分によりセキュア化することができる。他の実施形態では、対称鍵をパッチ送信処理中に生成しなくてもよく、それに代えて、予め生成してパッチサーバ１００に記憶してもよい。このような実施形態では、対称鍵をハードウェア内で隠すことができる。これは様々な方法で達成することができる。例えば、コードは通常、多くの人々に見られることになるため、分散ソースからの鍵生成がこの目的を果たすことができる。これにより、鍵がどのように作成されたかのすべての詳細を誰にも知られずに、必要な場合にはすべての情報を再構築することができるようになる。別法として、対称鍵を或るＨＳＭ内に隠すことができる。さらに、このような実施形態のパッチサーバ１００は、対称鍵が失われた場合に対称鍵を再構築するための何等かの堅牢な方法を含むことができる。

ステップ８２０において、ランダムセッション鍵を使用して、ステップ４６０において組み立てられたパッチブロック１１００を暗号化することができる。これは、ＡＥＳ暗号化を使用して達成することができる。最後に、ステップ８３０において、ＫＥＫ鍵１６０を使用してランダムセッション鍵を暗号化することができる。他の実施形態では、ステップ８２０及び８３０は逆順に実行してもよい。

ＫＥＫ暗号化４７０中、すべての情報（いくつかの理由により平文である必要があり得るヘッダ部を除く）を出力フィードバックモード（ＯＦＢ）で暗号化することができる。これにより、パッチを後にパッチクライアント１４０においてストリームとして復号化することができるようになる。パディングは必要でなくてよく、何等問題なく、記録毎の復号化が可能であり得る。代替の実施形態では、代わりに、暗号フィードバックモード（ＣＦＢ）をストリーム暗号化に使用してもよい。ＣＦＢモードは平文依存であり、エラーが少なくとも１ブロックにわたって拡散する。しかし、ＯＦＢモードを使用する場合、或る攻撃者による１ビットの反転又は追加であっても、ブロック破損と同じ致命的な影響を有し、パッチクライアント１４０でのデジタル署名検証は両方の場合で失敗することになる。したがって、ＯＦＢモードを使用する場合、セキュリティが強化される。

デジタル署名Ｄ_１〜Ｄ_３は、ＫＥＫ暗号化ステップ４７０を実行する前にパッチブロック１１００（ステップ４６０）に含められるため、デジタル署名も、本実施形態による暗号化により保護される。これは、攻撃者がセキュリティホールを見つける危険性を低減することができる。

対称ＫＥＫ暗号化４７０をさらに安全にするために、ＯＦＢモードで使用される初期化ベクトルを一意に、すなわちすべてのパッチ間で決して繰り返すことができないように選択することができる。これは、例えば、初期化ベクトルの固定部にシーケンス番号を含めることにより達成することができる。別法として、タイムスタンプをこのために使用してもよい。

ここで図４に戻り、ステップ４８０において、送信ブロックを組み立てることができる。本実施形態の送信ブロックの構成を図１４に示す。

特に、送信ブロック１４００は、暗号化されたパッチ１４２０が後に続く暗号化されたセッション鍵１４１０から成ることができ、これらはそれぞれステップ８３０及び８２０から生成される。本実施形態によれば、暗号化されたセッション鍵は１２８ビット長である。他の実施形態では、別法として他のセッション鍵長を使用してもよい。最後に、ステップ４９０において、送信ブロックをパッチクライアント１４０に送信することができる。

すでに述べたように、署名中のハードウェア故障は秘密鍵を暴露し得る。この危険性を回避するために、ステップ４２０において作成された署名を、パッチクライアント１４０に送信する（ステップ４９０）前にチェックすることができる。それにより、各署名Ｄ_１〜Ｄ_３を異なるプログラムによりチェックすることができる。例えば、（まだ販売されていない）パッチクライアント１４０が、チェックすべき署名を含む実際のパッチで起動するか否かをベンダーにより検証することができる。

上記実施形態によれば、パッチクライアント１４０のデジタル署名Ｄ_１〜Ｄ_３の検証は、パッチ１１５０の全体を読み取った後でのみ可能であり得る。しかし、他の実施形態では、パッチのあらゆる記録の真正性及び完全性を復号化直後にチェックすることが望ましいことがある。これにより、図９、図１０、及び図１３を参照してこれより説明する第２の実施形態を可能にすることができる。

この実施形態では、パッチサーバ１００の全体の動作が図４に示す動作に対応することができ、秘密鍵選択４１０、ダミー処理４３０及び４４０、鍵インジケータ作成４５０、ＫＥＫ暗号化４７０、送信ブロック組み立て４８０並びに送信ブロック送信４９０は上述したものと同じであり得る。しかし、変更されたハッシュチェイン４００及び署名作成４２０を利用することができる。さらに、パッチブロック組み立て４６０により、上記とは異なる構成を有するパッチブロックを生成することができる。

まず、パッチブロックを扱い、本実施形態によるその構成を図１３に示す。第１の実施形態のパッチブロック１１００と同様に、パッチブロック１３００は３つのデジタル署名（Ｄ_１〜Ｄ_３）１３１０、１３２０、１３３０で始まり、その後に鍵インジケータ１３４０が続くことができる。鍵インジケータ１３４０は、図１１を参照して上述した鍵インジケータ１１４０に対応することができる。しかし、デジタル署名１３１０、１３２０、１３３０は、図１０を参照して後述するように、第１の実施形態のデジタル署名とは異なる方法で計算することができる。さらに、パッチの各記録（Ｒ_１〜Ｒ_ｎ）１３５５、１３６５、１３７５、１３８５の前に、暗号ハッシュ値（Ｈ_１〜Ｈ_ｎ）１３５０、１３６０、１３７０、１３８０を配置することができる。

本実施形態によるハッシュ値１３５０、１３６０、１３７０、１３８０の計算は、図４のステップ４００において実行され、図９により詳細に示される。

まず、ステップ９１０において、送信すべきパッチのｎ番目の記録Ｒ_ｎ１３８５と０ビットから成るハッシュ値“０”との結合（Ｒ_ｎ|0）をハッシングすることにより、ハッシュ値Ｈ_ｎ１３８０を計算することができる。代替の実施形態では、ステップ９１０において記録Ｒ_ｎのみをハッシングすることができる。次いで、ステップ９２０において、（ｎ−１）番目の記録Ｒ_ｎ−１１３７５と先に計算されたハッシュ値Ｈ_ｎ１３８０との結合（Ｒ_ｎ−１｜Ｈ_ｎ）をハッシングすることにより、ハッシュ値Ｈ_ｎ−１１３７０を計算することができる。続けて、ステップ９３０〜９４０と同様にしてハッシュ値Ｈ_ｎ−２〜Ｈ_１を計算することができる。他の実施形態では、最後のステップ９４０をスキップして、ステップ９４０から得られるハッシュ値Ｈ_１に代えて第１の記録Ｒ_１を後続ステップに使用してもよい。しかし、図９に示す実施形態は、より簡易且つより堅牢なプログラミングを可能にすることができる。

本実施形態により変更された書名作成４２０を図１０に示す。
ステップ１０１０において、図６のステップ６１０において選択された第１の秘密鍵を使用して第１のハッシュ値Ｈ_１１３５０を署名する（すなわち、図７に関連して上述したように、ハッシングして暗号化／復号化するか又は単に復号化／暗号化する）ことにより、第１のデジタル署名Ｄ_１１３１０を計算することができる。それに応じて、ステップ１０２０において、ステップ６２０において選択された第２の秘密鍵を使用して第１のハッシュ値Ｈ_１１３５０を署名することにより、第２のデジタル署名Ｄ_２１３２０を計算することができる。最後に、ステップ１０３０において、ステップ６３０から得られる第３の秘密鍵を使用して第１のハッシュ値Ｈ_１１３５０を署名することにより、第３のデジタル署名Ｄ_３１３３０を生成することができる。

ステップの図示された順番は、本発明を限定するものとして解釈されるべきではない。例えば、デジタル署名Ｄ_１〜Ｄ_３は異なる順序で計算されてもよい。さらに、計算ステップ１０１０〜１０３０を図６に示す秘密鍵選択ステップ及び／又は図９に示すハッシュチェインステップに差し込んでもよい。例えば、第１のハッシュ値Ｈ_１が計算され、対応する秘密鍵が選択された直後にデジタル署名Ｄ_１〜Ｄ_３を計算してもよい。

パッチサーバ１００が、暗号化されたパッチを含む送信ブロック１４００をパッチクライアント１４０に送信すると、公開鍵行列１５０及びＫＥＫ鍵１６０を使用して、パッチをパッチクライアント１４０に安全にインストールすることができる。一実施形態による、パッチクライアント１４０により実行される安全なパッチインストールプロセスについて、図１５〜図１７を参照してこれより説明する。このパッチインストールプロセスは、デジタル署名Ｄ_１〜Ｄ_３１１１０、１１２０、１１３０がパッチ全体を復号化した後でのみ検証される一実施形態において利用することができる。

まず図１５を参照すると、ステップ１５００において、送信ブロック１４００をパッチクライアント１４０で受信することができる。次いで、ステップ１５１０において、ＫＥＫ鍵１６０を使用して、暗号化されたランダムセッション鍵１４１０を復号化することができる。ステップ１５２０において、ステップ１５１０において先に得られたランダムセッション鍵を使用して、暗号化されたパッチブロック１４２０をＡＥＳアルゴリズム下で復号化することができる。ステップ１５１０及び１５２０での復号化は、図８に関連して上述したＯＦＢモードを使用して達成することができる。

ステップ１５３０において、署名の検証に使用すべき公開鍵を選択することができる。これを図１６により詳細に示す。

まず、ステップ１６１０において、ステップ１５２０において先に復号化された第１の鍵インジケータ１２１０を使用して、第１の公開鍵を第１の公開鍵群３６０から選択することができる。特に、第１の鍵インジケータ１２１０が指す、公開鍵３００〜３１５の中の鍵を第１の公開鍵として選択することができる。選択された第１の公開鍵は、ステップ６１０（図６参照）においてパッチサーバ１００により選択された第１の公開鍵に対応することができる。したがって、ステップ１６２０及び１６３０は、第２の鍵インジケータ１２２０及び第３の鍵インジケータ１２３０をそれぞれ使用して、第２の公開鍵群３７０及び第３の公開鍵群３８０から第２の公開鍵及び第３の公開鍵をそれぞれ選択することを含むことができる。第２の公開鍵及び第３の公開鍵は、ステップ６２０及び６３０においてパッチサーバ１００によりそれぞれ選択された第２の公開鍵及び第３の公開鍵にそれぞれ対応することができる。

もちろん、公開鍵選択ステップ１６１０〜１６３０は、任意の他の順序で実行してもよい。さらに、３つよりも多数又は少数の公開鍵群３６０〜３８０（及びそれに応じて３つよりも多数又は少数の秘密鍵群２６０〜２８０）が使用される実施形態では、公開鍵選択１５３０はそれに応じてより多数又はより少数の選択ステップを含み得る。

公開鍵を選択した後、ステップ１５４０において、署名１１１０〜１１３０を検証することができる。本実施形態による署名検証のサブステップを図１７に示す。

最初に、ステップ７００において、ハッシュチェインを実行することができる。実施形態によれば、パッチクライアント１４０により実行されるハッシュチェイン７００は、図５を参照して上述したパッチサーバ１００により形成されるハッシュチェインに対応する。

次いで、ステップ７１０において、ステップ５２０、５３０、及び５４０から得られるハッシュ値Ｈ_１、Ｈ_２及びＨ_３のそれぞれを再びハッシングすることができる。ステップ７１０〜７３０においてパッチサーバ１００により実行される署名がさらなるハッシングを含まず、復号化／暗号化のみを含む実施形態では、ステップ１７１０をスキップすることができる。

ステップ１７１０に続き、ステップ１５２０において暗号化されたパッチブロック１４２０を復号化したときに得られるデジタル署名（Ｄ_１〜Ｄ_３）１１１０、１１２０、１１３０を、第１の公開鍵、第２の公開鍵、及び第３の公開鍵のそれぞれを使用して復号化することができる。

次いで、ステップ１７５０〜１７７０において、ステップ１７２０〜１７４０から得られる復号化されたデジタル署名を、ステップ１７１０において得られた、再びハッシングされたハッシュ値Ｈ_１〜Ｈ_３のそれぞれと比較することができる。ステップ１７１０がスキップされる実施形態では、復号化されたデジタル署名をハッシュ値Ｈ_１〜Ｈ_３のそれぞれと直接比較することができる。

ステップ１７８０において、デジタル署名（Ｄ_１〜Ｄ_３）１１１０、１１２０、１１３０の中にダミー署名があるか否かを判断することができる。これは、鍵インジケータ１１４０のダミーインジケータ１２４０をチェックすることにより達成することができる。

ダミー署名がある場合、ステップ１７９０において、セキュアパッチインストールプロセスの残りの過程中に、ダミーインジケータ１２４０によりダミー署名として識別されるデジタル署名を無視することを確定することができる。他の実施形態では、上述したように２つ以上のデジタル署名がダミー署名であってもよい。このような実施形態では、それ以降のパッチインストールプロセス中にすべてのダミー署名を無視することができる。

ステップ１７８０において、ダミーインジケータ１２４０がすべてのデジタル署名１１１０〜１１３０が有効な署名である、すなわちダミー署名がないことを特定することが明らかになった場合、ステップ１７９０を行わず、セキュアパッチインストールの後続ステップ中に、すべてのデジタル署名１１１０、１１２０、１１３０を考慮することができる。

署名がステップ１５４０において検証されると、ステップ１５５０において、すべてのデジタル署名１１１０、１１２０、１１３０が順序通りか否かを判断することができる。本実施形態によれば、これは、比較ステップ１７５０〜１７７０により身元が明らかになった場合である。順序通りの場合、ステップ１５６０において、パッチをパッチクライアント１４０にインストールすることができる。ステップ１５６０は、パッチインストールの成功のリポートをパッチクライアント１４０のユーザに提供すること、及び／又はパッチサーバ１００にそれに応じて通知することを含み得る。

しかし、ステップ１７５０〜１７７０のうちの少なくとも１つにより、復号化されたデジタル署名が対応する（ハッシングされた）ハッシュ値と同一ではないことが明らかになった場合、ステップ１５７０において、受信したパッチをパッチクライアント１４０にインストールすべきではないと判断することができる。これは、例えば、エラーメッセージをユーザに提供すること、及び／又はパッチサーバ１００にパッチインストール失敗を通知することを含むことができる。

図１５〜図１７に示すステップの特定の順序は単に例示だけのために選択されたことを理解されたい。他の実施形態では、個々のサブステップは異なる順序に配置されてもよく、例えば、復号化ステップ１７２０〜１７４０を比較ステップ１７５０〜１７７０に差し込んでもよい。さらに、ハッシングステップ１７１０を３つの異なる個々のサブステップに分け、これを比較ステップ１７２０〜１７７０における復号化に差し込んでもよい。さらに、ハッシュチェイン１７００の個々のステップ５１０〜５４０をハッシング復号化ステップ及び比較ステップ１７１０〜１７７０に分散させてもよい。

さらに、より多数又はより少数の秘密鍵群及び公開鍵群が使用される実施形態では、署名検証１５４０はそれに応じてより多数又はより少数のハッシングステップ、復号化ステップ、及び比較ステップ１７１０〜１７７０を含み得る。

さらに、ステップ１７８０及び１７９０におけるダミー処理を、第１の復号化ステップ１７２０の前に、又はさらには署名検証１５４０が開始されるとき、又は公開鍵選択１５３０の前に持ってきてもよい。このような実施形態のステップ１７８０において、特定の署名１１１０、１１２０、１１３０がダミー署名であると判断される場合、対応する公開鍵選択ステップ１５３０及び署名検証ステップ１７００〜１７７０をスキップすることができる。例えば、第３のデジタル署名Ｄ_３がダミー署名である場合、必ずしも、ステップ５４０において第３のハッシュ値Ｈ_３を計算し、ステップ１６３０において第３の公開鍵を選択し、ステップ１７１０において第３のハッシュ値Ｈ_３をハッシングし、ステップ１７４０において第３のデジタル署名を復号化し、且つ／又はステップ１７７０の比較ステップを必ずしも実行しなくてもよい。

すでに上述したように、本実施形態のパッチインストール方式では、暗号化されたパッチブロック１４２０の全体を復号化した後でのみ、署名を検証することができる。しかし、パッチの個々の記録を復号化した直後にパッチをインストールすべきか否かを検証することが望ましい実施形態があり得る。このような実施形態でのパッチサーバ１００の動作については、図９、図１０、及び図１３に関連して上述した。パッチクライアント１４０が実行する、対応するセキュアパッチインストールについて、図１８〜図２０を参照しながらこれより説明する。

図１８のステップ１８００において、送信ブロック１４００をパッチクライアント１４０において受信することができる。ステップ１８１０において、送信ブロック１４００に含まれる暗号化されたランダムセッション鍵１４１０を、ＫＥＫ鍵１６０を使用して復号化することができる。このステップは図１５のステップ１５１０に対応することができる。

その後、ステップ１８２０において、ステップ１８１０において得られたランダムセッション鍵を使用して、暗号化されたパッチブロック１４２０に含まれる情報を復号化することができる。ステップ１８２０において実行される復号化は、ステップ１５２０において実行される復号化と同じように達成することができる。しかし、本実施形態によれば、暗号化された署名及び暗号化された鍵インジケータのみをステップ１８２０において復号化し得る。暗号化されたパッチブロック１４２０の残りの部分は、ステップ１８４０及び１８５０において後で記録毎に復号化することができる。

ステップ１８３０において、ステップ１８２０において検索された鍵インジケータ１３４０に基づいて、公開鍵を選択することができる。これは、図１５を参照して上述した公開鍵選択１５３０に対応することができる。次いで、ステップ１８４０において、ステップ１８２０において得られたデジタル署名（Ｄ_１〜Ｄ_３）１３１０、１３２０、１３３０を検証することができる。これを図１９により詳細に示す。

最初に、ステップ１９００において、両方とも送信ブロック１４００で受信されたパッチの暗号化された第１のハッシュ値及び暗号化された第１の記録を、ステップ１８１０において得られたランダムセッション鍵を使用して復号化することができる。これは、図１５に関連して上述したステップ１５２０における復号化と同じように達成することができる。その後、ステップ１９１０において、ステップ１９００で復元された第１のハッシュ値Ｈ_１１３５０をハッシングすることができる。他の実施形態、特に、ステップ１０１０〜１０３０においてパッチサーバ１００により実行される署名がいかなるハッシングも含まない実施形態では、ステップ１９１０をスキップすることができる。

その後、ステップ１９２０〜１９４０において、ステップ１８３０においてそれぞれ選択された第１の公開鍵〜第３の公開鍵を使用して、ステップ１８２０から得られるデジタル署名（Ｄ_１〜Ｄ_３）１３１０〜１３３０を復号化することができる。次いで、ステップ１９２０〜１９４０の各結果をステップ１９５０〜１９７０において、ステップ１９１０の結果とそれぞれ比較することができる。ステップ１９１０がスキップされる実施形態では、ステップ１９２０〜１９４０から得られる復号化された署名を、代わりにステップ１９００から得られるハッシュ値Ｈ_１と比較することができる。

最後に、ステップ１９８０及び１９９０においてダミー署名処理を実行することができる。これは、図１７のステップ１７８０及び１７９０に関連して上述したダミー署名処理に対応することができる。

ここでも、図１８及び図１９に示すステップの特定の順序は単なる例示にすぎず、本発明を限定するものとして理解されるべきではない。他の実施形態では、各ステップを異なる順序にしてもよく、例えば、差し込みが可能である。さらに、ステップ１９８０及び１９９０のダミー署名処理を前に、例えば、署名検証１８４０が始まるとき、又は公開鍵選択１８３０の前に持ってきてもよい。このような実施形態では、ダミーインジケータ１２４０によりダミー署名として識別されたデジタル署名に関連する公開鍵選択ステップ１８３０及び署名検証ステップ１９００〜１９７０をすべて、スキップすることができる。

ここで図１８に戻ると、ステップ１８５０において、暗号化されたパッチブロック１４２０の残りを記録毎に復号化することができる。本実施形態による記録毎のパッチ復号化方式を図２０に示す。

これにより、まず、ステップ２０００において、すべての署名Ｄ_１〜Ｄ_３が順序通りであるか否かをチェックすることができる。ステップ２０００は、すべての比較ステップ１９５０〜１９７０により身元が明らかにされているか否かを判断することを含むことができる。上述したように、結果としてダミーの署名はこの判断において無視することができる。

そうではない場合、すなわち復号化された署名Ｄ_１〜Ｄ_３（ハッシングされた）ハッシュ値Ｈ_１と同一ではない場合、ステップ２０５０において、そのパッチはインストールすべきではないと判断することができる。これは図１５のステップ１５７０に対応することができる。

しかし、すべての署名が順序通りである場合、暗号化されたパッチブロック１４２０に含まれる暗号化された第２のハッシュ値及び暗号化された第２のパッチ記録を、ステップ１８１０において得られたランダムセッション鍵を使用して復号化することができる。ステップ２００５の復号化は、上述したステップ１８２０の復号化と同じように実行することができる。次いで、ステップ２０１０において、第１の記録Ｒ_１１３５５（ステップ１９００においてすでに得られている）とステップ２００５において得られる第２のハッシュ値Ｈ_２１３６０との結合（Ｒ_１｜Ｈ_２）をステップ２０１０においてハッシングすることができる。

その結果を、先に得られている（復号化ステップ１９００において）ハッシュ値Ｈ_１１３５０と比較することができる。ステップ２０２０において、これら２つのハッシュ値が同一ではないと判断される場合、パッチ復号化方式はステップ２０５０に進み、パッチをインストールすべきか否かを判断する。その他の場合、ステップ２００５〜２０２０を適宜、第３のハッシュ値〜最後のハッシュ値と暗号化されたパッチブロック１４２０内の各記録とに対して繰り返すことができる。

ステップ２０２０での比較の答えが復号化されたすべてのハッシュ値及び記録で肯定である場合、ステップ２０３５において、最後のパッチ記録Ｒ_ｎ１３８５とゼロビットから成るハッシュ値“０”との結合(Ｒ_ｎ|0) を計算することができる。この値は、ステップ２０４５において、パッチブロック１３００の最後のハッシュ値Ｈ_ｎ１３８０と比較することができる。

ステップ２０４０において、２つの値が同一であると判断される場合、ステップ２０４５においてパッチをインストールし、ユーザ及び／又はパッチサーバ１００にパッチインストール成功を通知することができる。その他の場合、ステップ２０４０において、パッチをインストールすべきではないと判断することができる。

図１８〜図２０に示す実施形態によれば、たった１つのパッチ記録が破損している場合であっても、受信されたパッチはステップ２０４５において全体的にインストールされるか、又はまったくインストールされないかのいずれかである。このような一実施形態では、パッチ内で、１ビットが反転されたか、又は１バイトが削除／挿入されただけで、パッチクライアント１４０の起動を阻止するのに十分である。これは、セキュリティの向上、例えば、ユーザが単に先天的に異常なパッチを受信したという印象を得るようにパッチを変更するワームに対する保護を提供することができる。

しかし、セキュリティがこの程度まで要求されない他の実施形態では、ステップ２０００、２０２０、又は２０４０の各答えが肯定であるパッチの記録１３５５、１３６５、１３７５、１３８５をインストールしてもよい。したがって、ステップ２０００、２０２０、又は２０４０の否定の答えがステップ２０５０でのパッチ全体の無視に繋がらず、現在チェックされている記録１３５５、１３６５、１３７５、１３８５のみの無視に繋がり得る。このようなシステムでは、それでもやはり、例えば、パッチを受信したときにＭＤ５和をチェックするようにユーザに強制するか、又はパッチインストールプロセスに何等かの予備チェックを含むときに、セキュリティを強化することができる。ＯＦＢモードはエラーを局所に留めるため、パッチの個々の記録１３５５、１３６５、１３７５、１３８５のみの考慮（regarding）はＯＦＢ暗号モードの使用により可能にすることができる。

説明した実施形態によれば、パッチクライアント１４０により自動的にセキュアパッチインストールプロセスが達成され、ユーザはプロセスにいかなる影響も有さない。さらに、ユーザはまた、パッチクライアント１４０内で何が起こっているのかを見る可能性をまったく有さない。しかし、ステップ１５７０又は２０５０においてユーザにエラーメッセージを提供するか、又はパッチがステップ１５６０又は２０４５において正しくインストールされたことを報告することができる。

さらに、本実施形態によれば、上述したセキュリティ機能をオフにすることは不可能であり得る。これは、セキュリティディセーブルピンの状態について報告する「シャドウ」変数による攻撃を防ぐことができる。

セキュリティ機能のオフが性能のために望ましい実施形態では、この変数がいかなるソフトウェアによっても変更不可能なことを保証することができる。これは、このような変数を設定するソフトウェアも攻撃される恐れがあるためである。

実施形態の上記説明から明らかなように、秘密鍵保護及び鍵紛失耐性を増大させたソフトウェアアップデート方法及びシステムが提供される。特に、異なる鍵生成プラットフォーム１１０、１２０、１３０を使用することにより、セキュリティを大幅に増大させることができる。

異なる作成プラットフォーム１１０、１２０、１３０からの鍵を組み合わせることにより、鍵生成に使用されるプラットフォーム１１０、１２０、１３０がセキュリティホールを有する場合に生じる弱い署名鍵の危険性が低減される。通常、この危険性は、非常に高価な、新しい鍵を埋め込むようなシリコンでのハードウェア変更の問題に繋がる。したがって、提案される、異なるプラットフォーム１１０、１２０、１３０で生成される鍵の組み合わせは、製造費及びメンテナンス費も低減する。

鍵紛失、すなわち、鍵がもはや利用できない場合に対する保護は、行列１５０から選択すべき鍵を指すビットインジケータ１１４０、１３４０を使用することにより達成することができる。それにより、鍵を紛失した場合にハードウェア又はユーザ廃棄リストを変更する必要をなくすことができる。

さらに、提案される、３つのデジタル署名Ｄ_１〜Ｄ_３のために１２個の鍵を含む行列から３つの鍵を使用することにより、鍵が明らかにされるか、又は盗まれ、それにより公衆に知られた場合に対する保護を増大させることができる。これは、攻撃者が偽のパッチを挿入するのをより困難にすることができる。攻撃をセットアップするには、（異なる方法又はエンティティにより保護することができる）少なくとも完全な組の秘密鍵を得て鍵行列の３つすべての列２６０、２７０、２８０からの鍵組を形成する必要がある。このような場合であっても、漏洩が知られないと仮定して、すべてのパッチクライアント１４０のたった約１／６４が偽のパッチに感染するだけである。漏洩が知れた場合、理論上、セキュリティは最大で１０個までの鍵が侵害されても破壊されず、上記鍵インジケータ１１４０、１３４０の２ビットを含むダミーインジケータ１２４０により、秘密鍵群２６０、２７０、２８０のうちの１つの群の４つすべての鍵が侵害されてもかまわない。４つの署名が使用され、ダミー署名が許されない代替の実施形態では、確率は１／６４から１／２５６にさらに低減する（この場合少なくとも４つの秘密鍵が漏出しなければならない）。しかし、このような実施形態では、セキュリティを維持するために、各秘密鍵群に少なくとも１つの有効な鍵がなければならない。

図５及び図９に関連して上述したハッシュチェインにより、誰も同じパッチパッケージに署名したか否かを述べることができない署名プロセスに異なる当事者を含めることができる。これは、コストを同レベルに保ちながら、いくつかの状況においてさらなるセキュリティを提供することができる。

さらに、図５及び図９のハッシュチェインは、重要なセキュリティの勝利を提供する。最新の結果により、ＭＤ５及びＳＨＡ−０（セキュアハッシュアルゴリズム０）のような暗号ハッシュ関数の致命的な欠陥についてのヒントが提供されている。ＳＨＡ−１を破ることができるか否か、さらには使用可能なように破ることができるか否かは明らかではない。しかし、同じＳＨＡ−１ハッシュ値を有する意味のある異なるテキストを構築することができる場合であっても、これが図５及び図９に示すハッシュチェインにより提供されるような２つ、又はさらには３つ以上に連鎖したハッシュに対して可能であることはまったく現実的ではない。

提案される概念は、入念な鍵管理と組み合わせられた異種の（heterogeneous）公開鍵を使用するいくつかのデジタル署名Ｄ_１〜Ｄ_３を使用してパッチの完全性を非常に良好に保証する。ＨＳＭ鍵のみが使用される実施形態であっても、セキュリティは依然として高い。パッチの内容は、パッチクライアントのファームウェアに隠すことができるＫＥＫ鍵での暗号化により保護することができる。

信頼できる第三者（ＴＴＰ）がセキュリティプロセスに関与する実施形態では、署名する必要があるのはハッシュ値のみであってもよい。それにより、パッチソースを示す危険性を回避することができるため、セキュリティをさらに強化することができる。提案される解決策のコストは、得るものと比較して低い。パッチの作成及び配信は、いくつかのインスタンスがこのプロセスに関与する実施形態であっても、鍵の処理、バックアップ、デジタル署名、及び暗号化よりもはるかに高価である。パッチクライアント１４０の製造費は略固定され、上記セキュアパッチ機能を追加することによる変化はほんのわずかであり得る。パッチクライアント１４０の起動中に復号化及び署名のチェックに必要な時間は最小であり得る。しかし、従来技術による平凡なパッチサーバに勝るセキュリティの獲得は相当なものである。したがって、提案される実施形態は、対応するコストを過度に増大させることなく、パッチシステムのセキュリティ、信頼性、及び効率を大幅に増大させることができる。

本発明を、本発明により構築される物理的な実施形態に関連して説明したが、上記教示に鑑みて、本発明の範囲から逸脱することなく添付の特許請求の範囲内で本発明の各種の変更、変形、及び改良を行い得ることが当業者には明らかであろう。さらに、当業者が精通していると確信される分野については、本明細書において述べる本発明を不必要に曖昧にしないように説明しなかった。したがって、本発明が特定の例示的な実施形態により限定されるべきではなく、添付の特許請求の範囲によってのみ限定されるべきであることを理解されたい。

本発明の実施形態はコンピュータ技術の分野において適用可能であり、ひいては産業分野において使用することができる。

一実施形態によるパッチシステムの構成要素を示すブロック。 一実施形態による秘密鍵管理を示すブロック図。 一実施形態による公開鍵管理を示すブロック図。 一実施形態によるパッチ送信を示す流れ図。 一実施形態によるハッシュチェインのステップを示す図。 一実施形態による秘密鍵選択を示す流れ図。 一実施形態による署名作成を示す流れ図。 一実施形態によるＫＥＫ暗号化のステップを例証する図。 別の実施形態によるハッシュチェインのステップを示す流れ図。 他の実施形態による署名作成を示す流れ図。 一実施形態によるパッチブロックおよび鍵インジケータの構成を示すブロック図。 別の実施形態によるパッチブロックの構成を示すブロック図。 一実施形態による送信ブロックを示すブロック図。 一実施形態によるパッチインストールプロセスを示す流れ図。 一実施形態による公開鍵選択を示す流れ図。 一実施形態による署名検証を例証する流れ図。 別の実施形態によるパッチインストールを示す流れ図。 他の実施形態による署名検証を示す図。 他の実施形態による記録毎のパッチ復号化を示す流れ図。

Claims (10)

1. パッチクライアント（１４０）に接続され、前記パッチクライアントにパッチ（１１５０、１３５５、１３６５、１３７５、１３８５）を提供するパッチサーバ（１００）であって、
   複数の第１の秘密鍵（２００〜２１５）を含む第１の秘密鍵群（２６０）を生成するように構成される第１の鍵生成プラットフォーム（１１０）と、
   複数の第２の秘密鍵（２２０〜２３５）を含む第２の秘密鍵群（２７０）を生成するように構成され、前記第１の鍵生成プラットフォームとは異なる、第２の鍵生成プラットフォーム（１２０）と、
   前記第１の秘密鍵群から前記第１の秘密鍵のうちの１つを選択する（４１０、６１０）ように構成される第１の鍵セレクタと、
   前記第２の秘密鍵群から前記第２の秘密鍵のうちの１つを選択する（４１０、６２０）ように構成される第２の鍵セレクタと、
   前記パッチ及び前記選択された第１の秘密鍵に基づいて第１のデジタル署名（１１１０、１３１０）を生成する（４２０、７１０、１０１０）ように構成される第１の署名生成器と、
   前記パッチ及び前記選択された第２の秘密鍵に基づいて第２のデジタル署名（１１２０、１３２０）を生成する（４２０、７２０、１０２０）ように構成される第２の署名生成器と、
   前記第１のデジタル署名および前記第２のデジタル署名と共に前記パッチを前記パッチクライアントに送信する（４９０）ように構成される送信器とを備える、パッチサーバ。
2. 前記パッチに基づいて第１のハッシュ値を計算する（４００、５１０）ように構成される第１のハッシャと、
   前記第１のハッシュ値に基づいて第２のハッシュ値を計算する（４００、５２０）ように構成される第２のハッシャと、
   をさらに備え、
   前記第１の署名生成器は、前記第２のハッシュ値に基づいて前記第１のデジタル署名を生成する（４２０、７１０）ようにさらに構成される、請求項１に記載のパッチサーバ。
3. 前記第２のハッシュ値に基づいて第３のハッシュ値を計算する（４００、５３０）ように構成される第３のハッシャをさらに備え、
   前記第２の署名生成器は、前記第３のハッシュ値に基づいて前記第２のデジタル署名を生成する（４２０、７２０）ようにさらに構成される、請求項２に記載のパッチサーバ。
4. 複数のハッシュ値を計算する（４００、９１０〜９４０）ように構成されるハッシャをさらに備え、
   前記パッチは複数の記録（１３５５、１３６５、１３７５、１３８５）を含み、
   前記ハッシャは、前記パッチに含まれる最後の記録（１３８５）に基づいて前記複数のハッシュ値の第１のハッシュ値を計算する（４００、９１０）ようにさらに構成され、
   前記ハッシャは、前記パッチに含まれる最後から次の各記録及び前記複数のハッシュ値の最後に計算された各ハッシュ値に基づいて、前記複数のハッシュ値のさらなる各ハッシュ値を計算する（４００、９２０〜９４０）ようにさらに構成される、請求項１に記載のパッチサーバ。
5. 前記第１の署名生成器は、前記複数のハッシュ値の前記最後に計算されたハッシュ値に基づいて前記第１のデジタル署名を生成する（４２０、１０１０）ようにさらに構成され、
   前記送信器は、前記パッチを前記第１のデジタル署名及び前記第２のデジタル署名並びに前記複数のハッシュ値と共に前記パッチクライアントに送信するようにさらに構成される、請求項４に記載のパッチサーバ。
6. 前記第２の署名生成器は、前記複数のハッシュ値の前記最後に計算されたハッシュ値に基づいて前記第２のデジタル署名を生成する（４２０、１０２０）ようにさらに構成され、
   前記送信器は、前記パッチを前記第１のデジタル署名及び前記第２のデジタル署名並びに前記複数のハッシュ値と共に前記パッチクライアントに送信するようにさらに構成される、請求項４または５に記載のパッチサーバ。
7. どの第１の秘密鍵が前記第１の秘密鍵群から選択されたかを示す第１の鍵インジケータ（１２１０）およびどの第２の秘密鍵が前記第２の秘密鍵群から選択されたかを示す第２の鍵インジケータ（１２２０）を含む鍵インジケータ（１１４０、１３４０）を生成するように構成される鍵インジケータ生成器
   をさらに備え、
   前記送信器は、前記パッチを前記第１のデジタル署名及び前記第２のデジタル署名並びに前記鍵インジケータと共に前記パッチクライアントに送信するようにさらに構成される、請求項１乃至６のいずれか１項に記載のパッチサーバ。
8. 前記鍵インジケータ生成器は、前記第１のデジタル署名または前記第２のデジタル署名のうちの一方をダミー署名として識別するダミーインジケータ（１２４０）をさらに含む前記鍵インジケータを生成するようにさらに構成される、請求項７に記載のパッチサーバ。
9. パッチクライアント（１４０）にパッチ（１１５０、１３５５、１３６５、１３７５、１３８５）を提供する方法であって、
   第１の鍵生成プラットフォーム（１１０）を使用して、複数の第１の秘密鍵（２００〜２１５）を含む第１の秘密鍵群（２６０）を生成するステップ、
   前記第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォーム（１２０）を使用して、複数の第２の秘密鍵（２２０〜２３５）を含む第２の秘密鍵群（２７０）を生成するステップ、
   前記第１の秘密鍵群から前記第１の秘密鍵のうちの１つを選択するステップ（４１０、６１０）、
   前記第２の秘密鍵群から前記第２の秘密鍵のうちの１つを選択するステップ（４１０、６２０）、
   前記パッチおよび前記選択された第１の秘密鍵に基づいて第１のデジタル署名（１１１０、１３１０）を生成するステップ（４２０、７１０、１０１０）、
   前記パッチおよび前記選択された第２の秘密鍵に基づいて第２のデジタル署名（１１２０、１３２０）を生成するステップ（４２０、７２０、１０２０）、および
   前記第１のデジタル署名および前記第２のデジタル署名と共に前記パッチを前記パッチクライアントに送信するステップを含む方法。
10. パッチサーバ（１００）に接続され、前記パッチサーバからパッチ（１１５０、１３５５、１３６５、１３７５、１３８５）を受信する（１５００、１８００）パッチクライアント（１４０）であって、
    第１の鍵生成プラットフォーム（１１０）により生成された複数の第１の公開鍵（３００〜３１５）を含む第１の公開鍵群（３６０）を記憶する第１の記憶手段と、
    前記第１の鍵生成プラットフォームとは異なる第２の鍵生成プラットフォーム（１２０）により生成された複数の第２の公開鍵（３２０〜３３５）を含む第２の公開鍵群（３７０）を記憶する第２の記憶手段と、
    前記第１の公開鍵群から前記第１の公開鍵のうちの１つを選択する（１５３０、１６１０、１８３０）ように構成される第１の鍵セレクタと、
    前記第２の公開鍵群から前記第２の公開鍵のうちの１つを選択する（１５３０、１６２０、１８３０）ように構成される第２の鍵セレクタと、
    前記選択された第１の公開鍵を使用して、前記パッチと共に前記パッチサーバから受信される第１のデジタル署名（１１１０、１３１０）を検証する（１５４０、１７２０、１７５０、１８４０、１９２０、１９５０）ように構成される第１の署名検証構成要素と、
    前記選択された第２の公開鍵を使用して、前記パッチと共に前記パッチサーバから受信される第２のデジタル署名（１１２０、１３２０）を検証する（１５４０、１７３０、１７６０、１８４０、１９３０、１９６０）ように構成される第２の署名検証構成要素とを備え、
    前記パッチクライアントは、前記第１のデジタル署名および前記第２のデジタル署名の検証結果が、前記第１のデジタル署名及び前記第２のデジタル署名のそれぞれの真正性及び完全性を示す場合のみ、前記パッチをインストールする（１５６０、２０４５）ように構成される、パッチクライアント。

Images