(57)【要約】      （修正有）【課題】複数の公開認証鍵（ＰＵＡＫ）を格納および使用できる限定受信（ＣＡ）のための受信機を提供する。【解決手段】受信機がオンにされる、またはリセットされると（Ｓ２１）、ソフトウェアまたは第２段階の鍵および署名が、第１のメモリからロードされる（Ｓ２３）。セキュリティプロセッサは次に、ＰＵＡＫをロードし（Ｓ２４）、これを使用して署名を検証する（Ｓ２５）。検証に成功した場合、ソフトウェアコードまたは第２段階の鍵は使用され（Ｓ２７）、検証方法は終了し、その後受信機においてＣＡ特定機能を起動することができる。しかしながら、検証が成功しない場合、試していないＰＵＡＫがあるかどうかを確認する（Ｓ２８）。試していない署名がない場合、検証は失敗し（Ｓ２９）、ソフトウェアを検証することができず、検証方法は終了する。試していない署名がある場合、次のＰＵＡＫがロードされる（Ｓ２５）。【選択図】図２
2013128280.tif 000002
【特許請求の範囲】
【請求項１】
デジタルデータのデジタル署名を検証するための装置であって、
第１の検証鍵を格納するように構成された第１のメモリと、
デジタルデータを格納するように構成された第２のメモリであって、前記デジタルデータは、装置のブートコードまたは別のデジタルデータを認証するために使用されることになる第２段階の認証鍵を含む、第２のメモリと、
装置の電源を入れた、または装置をリセットしたとき、前記デジタルデータおよび前記デジタル署名を受信し、前記第１の検証鍵を用いて前記デジタル署名を処理することによって、前記デジタル署名を検証するように構成された処理手段と
を備え、
前記第１のメモリがさらに、第２の検証鍵も格納するように構成され、前記第１の検証鍵および前記第２の検証鍵はそれぞれ第１の署名エンティティの署名鍵および第２の署名エンティティの署名鍵に対応し、
前記処理手段がさらに、前記第２の検証鍵を用いて前記デジタルデータを処理することによって前記デジタル署名を検証するように構成される
ことを特徴とする装置。
【請求項２】
前記第１のメモリは、複数の検証鍵を格納するように構成されることを特徴とする請求項１に記載の装置。
【請求項３】
前記処理手段は、前記デジタル署名が検証に成功するまで、またはデジタル署名が格納されたすべての検証鍵を使用して不成功になるまで、前記デジタル署名および前記格納された検証鍵のそれぞれを使用して、前記デジタル署名を検証するように構成されることを特徴とする請求項２に記載の装置。
【請求項４】
前記処理手段は、前記第１の検証鍵を用いて前記デジタル署名が検証に成功しない場合、前記第２の検証鍵を用いて前記デジタル署名を処理することによって前記デジタル署名を検証するように構成されることを特徴とする請求項１に記載の装置。
【請求項５】
前記処理手段は、前記第１の検証鍵および前記第２の検証鍵を並行して使用して前記署名を検証するように構成されることを特徴とする請求項１に記載の装置。
【請求項６】
前記ブートコードが組み込まれることを特徴とする請求項１に記載の装置。
【請求項７】
前記デジタル署名が認証に成功した場合に前記ブートコードを実行するように構成された第２の処理手段をさらに備えることを特徴とする請求項６に記載の装置。
【請求項８】
前記処理手段はさらに、前記デジタルデータの検証に成功すると、現在のＣＡシステムを識別し、ＣＡ特定機能を起動するように構成されることを特徴とする請求項１に記載の装置。
【請求項９】
前記第１のメモリは書込み不可能であることを特徴とする請求項１に記載の装置。
【請求項１０】
装置のブートコードまたは別のデジタルデータを認証するために使用されることになる第２段階の認証鍵を含むデジタルデータのデジタル署名を検証するための方法であって、処理手段において、前記装置に電源を入れた、または前記装置をリセットしたとき、
前記デジタルデータおよび前記デジタル署名を受信するステップと、
検証鍵を取得し、
前記取得した検証鍵を用いて前記デジタル署名を処理することによって前記デジタル署名を検証すること
によって前記デジタル署名を複数回検証するステップと
を含み、
前記複数回のそれぞれに、異なる検証鍵が取得され、使用されることを特徴とする方法。
【請求項１１】
前記取得するステップおよび前記検証するステップは、並行して行われることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記取得するステップおよび前記検証するステップは、前記デジタル署名が検証に成功するまで、または前記プロセッサが利用可能なすべての検証鍵を試して不成功になるまで、繰り返して行われることを特徴とする請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にセキュリティに関し、詳細にはデジタル署名の検証に関する。
【背景技術】
【０００２】
この節は、以下に説明するおよび／または特許請求されている本発明の様々な態様に関連する可能性がある当技術分野の様々な態様を読者に紹介することを目的としている。この説明は、本発明の様々な態様をより良く理解する助けとなるように、読者に背景情報を提供するのに役立つと考えられる。したがって、これらの記述は、従来の技術の承認としてではなく、このような観点で読まれるべきであることを理解されたい。
【０００３】
例えば高い価値のあるテレビ番組などの、デジタルコンテンツを保護するために、いわゆる限定受信（Ｃｏｎｄｉｔｉｏｎａｌ  Ａｃｃｅｓｓ、ＣＡ）技術を使用することが、当技術分野ではよく知られている。このような技術は、様々な暗号プロトコルを使用してデジタルコンテンツを暗号化し、後に復号化し、さらに無許可の使用から端末を守る。
【０００４】
ＣＡ技術は、ＣＡプロバイダによってユーザに直接または間接的に提供された何らかの（通常、取り外し可能な）セキュリティ要素を使用して、例えばテレビおよびいわゆるセットトップボックス（ＳＴＢ）などの受信機に実装される。このようなセキュリティ要素の好ましい実装がスマートカードであり、これは当技術分野でよく知られているものである。
【０００５】
ＣＡ保護されたデジタルコンテンツを受信するためには一般に料金を支払う必要があること、および代金を支払わずにＣＡ保護されたデジタルコンテンツを受信するために、著作権侵害者がＣＡシステムを「ハッキング」しようとすることは非常によく起こることであると理解されるであろう。スマートカードがますます安全になる、すなわちますますハッキングしづらくなるにつれて、著作権侵害者は受信機を直接攻撃する傾向にある。
【０００６】
当然ながら、受信機製造業者は、サポートするＣＡプロバイダによって要求され、指定される一定のセキュリティ機能を実装すること、および特に以下を実装するメインＩＣのＣＡ専用版を使用することによって、その受信機のセキュリティを向上させることに取り組んできた。すなわち、
・  １２８ビットの対称鍵として実装することができる、秘密ルート鍵（ＳＲＫ）。
・  有利には非対称の１０２４または２０４８ビットＲＳＡ鍵として実装することができる、公開認証鍵（ＰＵＡＫ）。
【０００７】
チッププロバイダによって実装することができるこうしたセキュリティ機能は、提供される特定のＣＡのセキュリティ要件を満たさなければならない。第１のＣＡプロバイダＡが第２のＣＡプロバイダＢとは異なるセキュリティ要件を有する可能性は非常に高い。これは、Ａのためにカスタマイズされたコンポーネントが、Ｂには役に立たない、またはＢには受け入れられない可能性があることを意味する可能性があり、さらに、ＣＡプロバイダは通常その解決策を他のＣＡプロバイダに伝えない。
【０００８】
さらに、ＣＡプロバイダは商業上の競争相手であることが多いので、ＣＡプロバイダが共通のセキュリティ要件のセットに同意することは難しい可能性がある。この商業上の対抗意識にこのように後押しされてＣＡプロバイダはそのセキュリティ要件を向上させ、それを非公開にしている。
【０００９】
このために、あるＣＡプロバイダは、チッププロバイダの「標準的」セキュリティ機能の代わりに使用するようにチッププロバイダに独自のセキュリティブロックを提供する。
【００１０】
このように様々なＣＡプロバイダが様々なセキュリティ機能を提供することがわかる。
【００１１】
またペイＴＶオペレータのようなＣＡプロバイダの顧客は、複数のＣＡプロバイダからの製品を利用できることに関心があることが理解されるであろう。しかしながらこれまでのところ、オペレータがＣＡプロバイダを選択すると、次の理由により新しいＣＡプロバイダに切り替えることは困難である。すなわち、
・  導入した受信機を交換するには費用がかかる。古い受信機と新しい受信機の両方が同じように機能できることを保証するようにこれを行うべきである。
・  セキュリティを低下させる危険を冒すことなく、要求されるセキュリティ機能を有効にするプラットフォームを新しいＣＡプロバイダに提供することは困難である。
【００１２】
このために、ペイＴＶオペレータは、同じ受信機ハードウェアが異なるＣＡシステムで使用できるように、ＣＡプロバイダからできるだけ独立していることができることを希望し、したがって、様々なセキュリティ要件が個々にサポートされる。
【００１３】
各ＣＡプロバイダのセキュリティ機能、すなわちセキュリティブロックが、チップ製造業者によって提供されるチップに統合される場合、受信機が複数のＣＡプロバイダに対応しているという要件を満たすことができる。
【００１４】
ＳＷ認証チェーン
例えば受信機に組み込まれたソフトウェア（または第２段階の認証鍵）が有効であることを、電源を入れたときに検証することによって、許可されたソフトウェアのみが受信機にインストールされることを保証するために、有利にはＣＡプロバイダによって保持されるプライベート非対称鍵（ＰＲＡＫ）を使用してソフトウェア（または第２段階の認証鍵）をデジタル署名することが知られている。電源を入れると、受信機は、当技術分野でよく知られているように、ＰＲＡＫに対応するその公開認証鍵（ＰＵＡＫ）を使用して、受信機に組み込まれたソフトウェア（または第２段階の認証鍵）の署名を確認する。
【００１５】
ＣＡプロバイダにとってのＰＵＡＫは、ＣＡプロバイダのセキュリティ要件を満たすためのチップのカスタマイズの一部である。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
これまでのところ、単一ＣＡプロバイダのＰＵＡＫはチップに格納される。これは、別のＣＡプロバイダの他のすべてのセキュリティ機能がチップに実装されても、チップが複数のＣＡシステムに対応することはできないことを意味する。
【００１７】
したがって、受信機が複数のＰＵＡＫを格納および使用できるようにする解決策の必要がある。本発明は、このような解決策を提供する。
【課題を解決するための手段】
【００１８】
第１の態様では、本発明は、デジタルデータのデジタル署名を検証するための装置を対象とする。この装置は、第１の検証鍵を格納するように構成された第１のメモリと、デジタルデータを格納するように構成された第２のメモリであって、デジタルデータは、装置のブートコードまたは別のデジタルデータを認証するために使用されることになる第２段階の認証鍵を含む、第２のメモリと、装置の電源を入れた、または装置をリセットしたとき、デジタルデータおよびデジタル署名を受信して、第１の検証鍵を用いてデジタル署名を処理することによってデジタル署名を検証するように構成された処理手段とを備える。さらに第１のメモリは、第２の検証鍵もまた格納するように構成され、第１の検証鍵および第２の検証鍵は、それぞれ第１の署名エンティティおよび第２の署名エンティティの署名鍵に対応し、さらに処理手段は、第２の検証鍵を用いてデジタルデータを処理することによってデジタル署名を検証するように構成される。
【００１９】
第１の好ましい実施形態では、第１のメモリは、複数の検証鍵を格納するように構成される。処理手段は、デジタル署名が検証に成功するまで、またはデジタル署名が格納されたすべての検証鍵を使用して不成功になるまで、デジタル署名および格納された検証鍵のそれぞれを使用してデジタル署名を検証するように構成されることが有利である。
【００２０】
第２の好ましい実施形態では、処理手段は、第１の検証鍵を使用してデジタル署名が検証に成功しない場合、第２の検証鍵を用いてデジタル署名を処理することによって、デジタル署名を検証するように構成される。
【００２１】
第３の好ましい実施形態では、処理手段は、第１の検証鍵および第２の検証鍵を並行して使用して署名を検証するように構成される。
【００２２】
第４の好ましい実施形態では、ブートコードが組み込まれる。装置はさらに、デジタル署名が認証に成功した場合にブートコードを実行するように構成された第２のプロセッサを備えることが有利である。
【００２３】
第５の好ましい実施形態では、プロセッサはさらに、デジタルデータの検証に成功すると、現在のＣＡシステムを識別して、ＣＡ特定機能を起動するように構成される。
【００２４】
第６の好ましい実施形態では、第１のメモリは書込み不可能である。
【００２５】
第２の態様では、本発明は、装置のブートコードを含むデジタルデータのデジタル署名、または別のデジタルデータを認証するために使用される第２段階の認証鍵を検証するための方法を対象とする。装置の電源を入れた、または装置をリセットしたとき、処理手段がデジタルデータおよびデジタル署名を受信し、検証鍵を取得すること、および取得した検証鍵を用いてデジタル署名を処理することによりデジタル署名を検証することによって、複数回、デジタル署名を検証する。複数回のそれぞれには、異なる検証鍵が取得され、使用される。
【００２６】
第１の好ましい実施形態では、取得するステップおよび検証するステップは、並行して行われる。
【００２７】
第２の好ましい実施形態では、取得するステップおよび検証するステップは、デジタル署名の検証に成功するまで、またはプロセッサが利用可能なすべての検証鍵を試して失敗するまで、繰り返して行われる。
【００２８】
次に、本発明の好ましい特徴について、非限定的な例として、添付の図面を参照して説明する。
【図面の簡単な説明】
【００２９】
【図１】本発明の好ましい実施形態に係る受信機を示す図である。
【図２】本発明の好ましい実施形態により、ソフトウェアまたは第２段階の認証鍵の署名の検証のための方法を示す図である。
【発明を実施するための形態】
【００３０】
本発明の主要な発明の概念は、複数の限定受信（ＣＡ）プロバイダから発信される署名を検証することができるように複数の認証鍵（ＰＵＡＫ）を格納するＣＡシステムの受信機を提供することである。この受信機は、好ましくはセットトップボックス（ＳＴＢ）であるが、テレビなど、他のいかなる好適な装置であることも可能である。
【００３１】
図１は、本発明の好ましい実施形態による受信機を示している。受信機１００は、セキュアチップ（ｓｅｃｕｒｅｄ  ｃｈｉｐ）１０２と、第１の（好ましくは不揮発性）メモリ１０６とを備えている。図には本発明に必要とされる特徴のみを示していることを理解されたい。
【００３２】
第１のメモリ１０６は、好ましい実施形態ではソフトウェア（以下、一例として使用する）であり、有利には受信機がオンにされるときに、または受信機がリセットされるときに使用されるいわゆるブートコードである、デジタルデータ１０７と、ソフトウェアのデジタル署名１０８とを格納する。ソフトウェア１０７および署名１０８は、単一ファイルの一部であることが好ましい。またデジタルデータ１０７は、第２段階の認証鍵である場合もある。
【００３３】
効率の理由から、セキュアチップ１０２は、セキュリティプロセッサ１０３と、メインプロセッサ１０４とを備えることが好ましい。セキュリティプロセッサ１０３は、以下に説明するように、ソフトウェアの署名１０８を検証するように構成される。セキュアチップ１０２はさらに、第２のメモリ１０５、好ましくは複数の認証鍵（ＰＵＡＫ）を保持する書込み不可能な、すなわちリードオンリメモリ（ＲＯＭ）を備える。図１では、２つのＰＵＡＫ、すなわちＰＵＡＫ  ＡおよびＰＵＡＫ  Ｂのみがある。しかしながら、少なくともセキュアチップを使用することができるＣＡプロバイダと同数のＰＵＡＫを格納することが有利であることは理解されるであろう。一部のＣＡプロバイダは、そのソフトウェアに複数の署名を提供するために、複数の鍵を使用することができる。
【００３４】
セキュリティプロセッサ１０３には、署名１０８の検証にどのＰＵＡＫを使用すべきかがわからないので、これまでの説明の受信機１００は、複数のＣＡプロバイダに対応するには十分ではない。
【００３５】
図２は、本発明の好ましい実施形態によるソフトウェアの署名１０８の検証の方法を示している。
【００３６】
ステップＳ２１では、受信機は、オンにされ、またはリセットされ、受信機は、第１のメモリ１０６に格納された、認証されることになるソフトウェア１０７に注意を向けることを要求される。この時点の受信機は、どのエンティティがソフトウェアの署名１０８を提供したかがわからず、そのためどのＰＵＡＫを使用すべきかがわからないことを理解されるであろう。
【００３７】
セキュリティプロセッサ１０３は、セキュアチップ１０２の制御を行う（ステップＳ２２）。ソフトウェア１０７および署名１０８は、次に第１のメモリ１０６からセキュアチップ１０２へロードされる（ステップＳ２３）。
【００３８】
セキュリティプロセッサ１０３は次に、第２のメモリ１０５からＰＵＡＫをロードし（ステップＳ２４）、これを使用して署名１０８を検証する（ステップＳ２５）。
【００３９】
ステップＳ２６において検証が成功する、すなわち「Ｙ」の場合、次にソフトウェアコードはステップＳ２７において使用され、検証方法は終了する。
【００４０】
一方、ステップＳ２６において検証が成功しない、すなわち「Ｎ」の場合、さらなるＰＵＡＫ、すなわち署名１０８の検証に使用されていないＰＵＡＫがあるかどうかが検証される。
【００４１】
ステップＳ２８においてそれ以上署名がない、すなわち「Ｎ」の場合、検証は失敗し（ステップＳ２９）、このソフトウェアを検証することができないのでこれを使用すべきではなく、検証方法は終了する。ステップＳ２８において試されていない署名がある、すなわち「Ｙ」の場合、ステップＳ２５において第２のメモリから次のＰＵＡＫがロードされる。
【００４２】
検証方法が終了すると、セキュリティプロセッサ１０３は、セキュアチップの制御をメインプロセッサ１０４に戻すことができる。データが第２段階の認証鍵である場合、セキュアチップは、認証された第２段階の認証鍵を使用して、第２段階の認証を行うことができる。
【００４３】
言い換えれば、この方法は、格納されたＰＵＡＫ鍵を続けて（繰り返して）試して、ソフトウェアの署名を検証する。ＰＵＡＫが署名を検証する場合、ソフトウェアは検証に成功し、署名を検証するＰＵＡＫがない場合、ソフトウェアは検証に成功しない。
【００４４】
当業者は理解するであろうが、少なくとも２つのＰＵＡＫを並行して試すことも可能であり、重要な点は、１つのＰＵＡＫがソフトウェアの署名を検証する場合、ソフトウェアは検証に成功するということである。
【００４５】
したがって、本発明は、ソフトウェアの署名が複数の署名者のいずれかによって提供された可能性があるとき、受信機がソフトウェアの署名を検証する方法を提供することができるということが理解されるであろう。どの鍵を使用すべきかを知る方法はないと考えられていたので、これまでのシステムではこれは可能ではなかったこともまた理解されるであろう。したがって本発明は、これまで未解決の重要な技術的問題に斬新で驚くべき解決策を提供する。さらに、本発明は、使用されるＣＡシステムを識別できるようにすることもでき、次に受信機１００においてＣＡ特定機能の起動を可能にする。
【００４６】
この方法は、ソフトウェアコードの検証、または実際には内部メモリからダウンロードされるデジタルデータに、決して限定されないことを理解されるであろう。
【００４７】
この説明および（必要に応じて）特許請求の範囲および図面に開示する各特徴は、個々に、または任意の適切な組合せで提供されることが可能である。ハードウェアに実装されるように記載した特徴は、ソフトウェアに実装されることも可能であり、逆もまた同様である。特許請求の範囲に表示する参照符号は、説明のためにすぎず、特許請求の範囲への制限的効果はないものとする。
【図１】
2013128280.tif 000003
【図２】
2013128280.tif 000004
【外国語明細書】
2013128280000001.pdf