(57)【要約】本発明は、端末にダウンロードされたソフトウェアを認証する、前記端末に一体化されたソフトウェアにより前記ダウンロードされたソフトウェアを証明書により認証するステップと、前記ダウンロードされたソフトウェアの実行中、前記ダウンロードされたソフトウェアに関連する認証ソフトウェアモジュールにより前記一体化されたソフトウェアを証明書により認証するステップとを有することを特徴とする方法に関する。
2006501735.tif 000002
【特許請求の範囲】
【請求項１】
端末にダウンロードされたソフトウェアを認証する、前記端末に一体化されたソフトウェアにより前記ダウンロードされたソフトウェアを証明書により認証するステップを有する方法であって、
前記ダウンロードされたソフトウェアの実行中、前記ダウンロードされたソフトウェアに関連する認証ソフトウェアモジュールにより前記一体化された第１のソフトウェアを証明書により認証するステップを有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、
前記一体化された第１のソフトウェアは、認証ライブラリと第１証明書により前記ダウンロードされたソフトウェアを認証し、
前記一体化された第１のソフトウェアと前記認証ライブラリは、書き込み保護されたメモリの第１部分を構成し、
前記ダウンロードされたソフトウェアと前記第１証明書は、ロード可能メモリの第２部分を構成する、
ことを特徴とする方法。
【請求項３】
請求項２記載の方法であって、
前記第１部分はまた、第２証明書を有し、
前記第２部分はまた、検証ソフトウェアを有し、
前記ダウンロードされたソフトウェアが認証されると、前記検証ソフトウェアは、前記認証ライブラリ及び前記第２証明書により前記一体化された第１のソフトウェアを認証する、
ことを特徴とする方法。
【請求項４】
請求項１記載の方法であって、
前記２つの連続した認証は、初期化において実行されることを特徴とする方法。
【請求項５】
請求項２記載の方法であって、
前記第２部分は、ダウンロードされることを特徴とする方法。
【請求項６】
第１ソフトウェアと、認証ライブラリと第２証明書とを有する第１書き込み保護されたメモリ部分と、
アプリケーションソフトウェアと、第１証明書と検証ソフトウェアとを有する第２メモリ部分と、
から構成される統合ソフトウェアであって、
該ソフトウェアがコンピュータ上で実行されると、該ソフトウェアは、請求項１乃至５何れか一項記載の方法の各ステップを実行することを特徴とするソフトウェア。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
［発明の背景］
本発明は、特にデジタルテレビデコーダの技術分野における後者を認証する統合ソフトウェア及び方法に関する。
［従来技術の説明］
従来技術による装置では、統合ソフトウェアの完全性テストは、通常は外部ツールを用いて、後者を表すソフトウェアの参照署名を計算し、後者を当該ソフトウェアに挿入することにより実行される。ソフトウェアの初期化段階において、ソフトウェアは、自身の署名を計算し、この署名と参照署名を比較する。これらの署名が異なる場合、ソフトウェアは、防護手続きに特化したソフトウェアルーチンを実行し、そうでない場合には、通常通り継続する。
【０００２】
このようなソフトウェアの認証の場合、後者のソースをチェックすることが望ましい。既知の解決策は、完全性テストの原理を適用し、それを非対称暗号化アルゴリズムと合成することから構成される。参照署名は、秘密鍵により暗号化され、この結果がソフトウェアに証明書の形式により統合される。チェック段階では、参照署名は、参照署名との比較前に、ソフトウェアに組み込まれた公開鍵により解読される。
【０００３】
従来技術の第１の文献である、「Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔｉｎｇ（ＤＶＢ）  Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ（ＭＨＰ）  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  １．０」（２０００−０７）というタイトルのＥＴＳＩ規格ＴＳ１０１
８１２ Ｖ１−１−１は、特にセクション１２．２と１２．７において、端末に一体化されたソフトウェアにより、ダウンロードしたソフトウェアの証明書による認証を実行することによって、端末にダウンロードされたソフトウェアを認証する方法の実現形態を記載している。
【０００４】
従来技術の第２の文献である米国特許第６，１６７，５２１号は、新たなソフトウェアをシステムにダウンロードする方法を記載している。当該方法の目的は、このダウンロードされた新しいソフトウェアが当該システムにすでにインストールされているソフトウェアを攻撃するのを回避したり、あるいは逆に、すでにインストールされているソフトウェアが、特に各自のソフトウェア所有者が互いに信頼し合っていないとき、新しいソフトウェアを攻撃することを回避するためのものである。
【０００５】
より詳細には、ソフトウェア認証を実行するため、第１の固定された書き込み保護部分１０のメモリに含まれるソフトウェアを利用して、ダウンロード可能な第２部分１１のアプリケーションソフトウェアを、当該第２部分１１にある証明書１２を用いて認証することは、図１に示されるように既知である。
【０００６】
従って、デコーダの側では、顧客が新しいアプリケーションソフトウェアによりサービス提供者を求めるとき、後者は当該顧客にこのアプリケーションソフトウェと当該アプリケーションソフトウェアに関連する証明書を検証するためのソフトウェを提供する。
【０００７】
しかしながら、このような解決策では、第１ソフトウェアの提供者が認証手続きの完了をチェックする方法はない。
【０００８】
本発明の課題は、当該認証が完了し、この提供者の権利が顧客により尊重されたことを提供者がチェックするのを可能にすることである。
［発明の概要］
従って、本発明は、端末にダウンロードされたソフトウェアを認証する、前記端末に一体化されたソフトウェアにより前記ダウンロードされたソフトウェアを証明書により認証するステップを有する方法であって、前記ダウンロードされたソフトウェアの実行中、前記ダウンロードされたソフトウェアに関連する認証ソフトウェアモジュールにより前記一体化された第１のソフトウェアを証明書により認証するステップを有することを特徴とする方法を提案する。
【０００９】
効果的には、前記一体化された第１のソフトウェアは、認証ライブラリと第１証明書により前記ダウンロードされたソフトウェアを認証し、前記一体化された第１のソフトウェアと前記認証ライブラリは、書き込み保護されたメモリの第１部分を構成し、前記ダウンロードされたソフトウェアと前記第１証明書は、ロード可能メモリの第２部分を構成する。
【００１０】
効果的には、前記第１部分はまた、第２証明書を有し、前記第２部分はまた、検証ソフトウェアを有し、前記ダウンロードされたソフトウェアが認証されると、前記検証ソフトウェアは、前記認証ライブラリ及び前記第２証明書により前記一体化された第１のソフトウェアを認証する。
【００１１】
効果的には、前記２つの連続した認証は、初期化において実行される。前記第２部分は、ダウンロード可能である。
【００１２】
本発明はまた、第１ソフトウェアと、認証ライブラリと第２証明書とを有する第１書き込み保護されたメモリ部分と、アプリケーションソフトウェアと、第１証明書と検証ソフトウェアとを有する第２メモリ部分とから構成される統合ソフトウェアであって、該ソフトウェアがコンピュータ上で実行されると、該ソフトウェアは、請求項１乃至５何れか一項記載の方法の各ステップを実行することを特徴とするソフトウェアに関する。
【００１３】
本ソフトウェアは、例えば、デジタルテレビデコーダ、ＰＣ（パーソナルコンピュータ）タイプの端末、あるいは他の任意の集積装置において利用可能である。
［好適実施例の詳細な説明］
図１に示される従来技術による方法と同様に、本発明の方法では、書き込み保護されるメモリの第１部分１０に含まれる第１ソフトウェアは、例えば、初期化段階において、第１部分１０の認証ライブラリと第２ロード可能部分１１の証明書１２を用いて、第２部分１１にあるアプリケーションソフトウェアである第２ソフトウェアを認証する。
【００１４】
「証明書」という用語は、特有の意味（ユーザやネットワークエンティティに対し信頼された第三者により電子識別であり、各証明書は認証局の秘密署名鍵により署名される）を有し、認証技術では限定的なものでありすぎるため、本開示で用いられる「証明書」という用語は、より一般的な署名、ＣＲＣまたはソフトウェアの真正性/完全性を検証するのに必要とされる他のデータをもカバーするものとする。
【００１５】
本発明の方法では、第１部分１０はまた、図２に示されるような第２証明書１３を有する。第２部分１１はまた、検証ソフトウェアを有する。この検証ソフトウェアは、アプリケーションソフトウェアが認証されると、認証ライブラリ及び第２証明書により第１ソフトウェアを認証する。
【００１６】
このような方法は、第１ソフトウェアの供給者によるアプリケーションソフトウェアを利用する顧客がその権利を尊重していることをチェックするのを可能にする。
【００１７】
一実施例では、図３に示される証明書の形式は以下のようになる。
・ヘッダ：
−ＣＬＰ（「証明書位置パターン」）：メモリにおいて認証証明書を探すための証明書の位置を与えるパターン（例えば、８バイト）
−ＲＦＵ（「以降の利用のための予約」）：以降の利用のための予約（例えば、１バイト）
−Ｋ：使用される鍵番号（例えば、１バイト）
・図４に示されるメッセージの１０２４ビットの秘密鍵によるＲＳＡ暗号化の結果である署名（例えば、１２８バイト）
１０２４ビットの署名は、ＲＳＡ暗号化を可能にするよう０のバイトから始まり、残りの２０は、各暗号化前に異なる方法によりランダムに充填される。
【００１８】
メッセージの開始からオフセットＨ＿ＣＯＤＥ＿ＯＦＦＳＥＴにおいて、２０バイトのハッシュコードＳＨＡ１がある。このＨ＿ＣＯＤＥは、ＣＨＥＣＫ＿ＰＡＴＴＥＲＮに後続し、その機能は、誤った解読（公開鍵番号または値、アルゴリズム、矛盾した証明書）と完全性チェック中の誤ったＨ＿ＣＯＤＥとの区別を可能にすることである。
【図面の簡単な説明】
【００１９】
【図１】図１は、従来技術による認証方法を示す。
【図２】図２は、本発明による認証方法を示す。
【図３】図３は、証明書の一例を示す。
【図４】図４は、署名の一例を示す。
【図１】
2006501735.tif 000003
【図２】
2006501735.tif 000004
【図３】
2006501735.tif 000005
【図４】
2006501735.tif 000006
【国際調査報告】
2006501735.tif 000007
2006501735.tif 000008
2006501735.tif 000009
2006501735.tif 000010
2006501735.tif 000011
2006501735.tif 000012