JP7450713B2

JP7450713B2 - ソフトウェア完全性保護方法および装置、ならびにソフトウェア完全性検証方法および装置

Info

Publication number: JP7450713B2
Application number: JP2022524002A
Authority: JP
Inventors: 斌曹; ▲海▼武 ▲陳▼; ▲艷▼ ▲陳▼; 博王
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-10-23
Filing date: 2020-10-21
Publication date: 2024-03-15
Anticipated expiration: 2040-10-21
Also published as: CN112699343A; US20220224546A1; CA3184034A1; JP2022553393A; WO2021078156A1; EP4047493A4; BR112022007652A2; EP4047493A1

Description

本出願は、２０１９年１０月２３日に中国国家知識産権局に提出された「ＤＥＶＩＣＥＩＮＴＥＧＲＩＴＹＰＲＯＴＥＣＴＩＯＮＭＥＴＨＯＤ，ＰＲＯＣＥＳＳＯＲ，ＮＥＴＷＯＲＫＤＥＶＩＣＥ，ＡＮＤＮＥＴＷＯＲＫＳＹＳＴＥＭ」と題された中国特許出願第２０１９１１０１２９４０．１号、および２０１９年１１月１５日に中国国家知識産権局に提出された「ＳＯＦＴＷＡＲＥＩＮＴＥＧＲＩＴＹＰＲＯＴＥＣＴＩＯＮＭＥＴＨＯＤＡＮＤＡＰＰＡＲＡＴＵＳ，ＡＮＤＳＯＦＴＷＡＲＥＩＮＴＥＧＲＩＴＹＶＥＲＩＦＩＣＡＴＩＯＮＭＥＴＨＯＤＡＮＤＡＰＰＡＲＡＴＵＳ」と題された中国特許出願第２０１９１１１２０９８７．Ｘ号の優先権を主張し、参照によりそれらの全体が本明細書に組み込まれる。

本出願は、セキュリティ技術の分野、特にソフトウェア完全性保護方法および装置、ならびにソフトウェア完全性検証方法および装置に関する。

通常、ソフトウェアパッケージのソフトウェア完全性を保証するために、ソフトウェア完全性保護と検証がソフトウェアパッケージにおいて実行され得、これは、具体的には以下を含む。ソフトウェアパッケージがデバイスにダウンロードされる前に、ソフトウェア製造業者によって提供された秘密鍵を使用することによってソフトウェアパッケージが署名される。ソフトウェアパッケージをロードする前に、デバイスは、秘密鍵に対応する公開鍵を使用することによってソフトウェアパッケージの署名を検証する。署名の検証が成功した場合は、ソフトウェアパッケージが攻撃者によって悪意を持って改ざんされておらず、ロードできることを示している。

現在、ソフトウェアパッケージは署名されており、デバイスにロードされたソフトウェアパッケージのソフトウェア完全性を保証するために、ソフトウェア製造業者によって提供された鍵のみを使用することによってソフトウェアパッケージに対して署名検証が実行される。したがって、ユーザの信頼の問題を解決することはできない。

これを考慮して、本出願の実施形態は、ユーザによって信頼されるソフトウェア完全性保護と検証の方法を提供し、それによってデバイスを使用するユーザエクスペリエンスを向上させるために、ソフトウェア完全性保護方法および装置、ならびにソフトウェア完全性検証方法および装置を提供する。

第１の態様によれば、ソフトウェア完全性保護方法が提供される。本方法は、第２のネットワークデバイスにダウンロードされ、インストールされる、第２のソフトウェアパッケージに対してソフトウェア完全性保護を実行するために使用される。本方法は、具体的には以下を含み得る。ステップ１：第１のデバイスは、ファーストパーティが第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行した後に取得される第１のソフトウェアパッケージを取得し、ここで、第１のソフトウェアパッケージは第２のソフトウェアパッケージおよび第１の署名を含む。ステップ２：第１のデバイスは、第２の署名を含む第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作を実行し、第１の秘密鍵は、ファーストパーティによって制御され、第２の秘密鍵はセカンドパーティによって制御される。

一例では、第１のデバイスは、ソフトウェア製造業者に対応する製造業者署名システムであり得る。この場合、ファーストパーティは第２のソフトウェアパッケージのユーザであり得、セカンドパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局である。ステップ１は具体的には次のようになり得る。第２のソフトウェアパッケージを取得した後、ユーザ署名システムは、第１の署名を取得するために、ユーザ署名システムによって提供される第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行し、第１の署名を含む第１のソフトウェアパッケージと第２のソフトウェアパッケージを第１のデバイスに送信する。

別の例では、第１のデバイスは、代替的に、ユーザ署名システムであり得る。この場合、ファーストパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局であり得、セカンドパーティは第２のソフトウェアパッケージのユーザである。ステップ１は具体的には次のようになり得る。第２のソフトウェアパッケージを取得した後、製造業者署名システムは、第１の署名を取得するために、製造業者署名システムによって提供される第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行し、第１の署名を含む第１のソフトウェアパッケージと第２のソフトウェアパッケージを第１のデバイスに送信する。

このようにして、本出願のこの実施形態において提供される方法によれば、ソフトウェアパッケージは、製造業者によって提供される鍵に基づいて署名できるだけでなく、ソフトウェアパッケージは、ユーザによって提供される鍵に基づいて署名することもでき、ユーザによって提供される鍵は、ユーザにとって絶対的に信頼できるものである。すなわち、本出願のこの実施形態は、製造業者を完全に信頼または依存することなく、ユーザによって信頼され得るソフトウェア完全性保護方法を提供する。これにより、ユーザの信頼の問題が解決し、それによってデバイスを使用するユーザエクスペリエンスが向上する。

第１の態様の可能な実装形態において、本方法はさらに以下を含み得る。第１のデバイスは、第３のソフトウェアパッケージを第２のデバイスに送信する。このようにして、第２のデバイスが第２のソフトウェアパッケージをロードする前に、第２のデバイスが、以下の第２の態様において提供されるソフトウェア完全性検証方法に従って第２のソフトウェアパッケージに対してソフトウェア完全性検証を実行するための信頼できる豊富なデータベーシスが提供される。

第１の態様の別の可能な実装形態では、第２のデバイスのソフトウェア完全性検証メカニズムを構成するために、第２のデバイスにおいて、スイッチングイネーブルビットおよびデュアルルートイネーブルビットがさらに構成され得る。第２のデバイスにおいて第２のソフトウェアパッケージに対してソフトウェア完全性検証が実行される場合、一例では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、第１の署名と第２の署名の両方が有効であることは、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。別の例では、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、有効である第１の署名は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。さらに別の例では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、有効である第２の署名は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。第２のデバイスにおけるスイッチングイネーブルビットの値とデュアルルートイネーブルビットの値の両方が有効である場合、スイッチングイネーブルビットの優先度がデュアルルートイネーブルビットの優先度よりも高く設定され得る。このようにして、２つのイネーブルビットのフィールドセグメントが第２のデバイスにおいて予約されるため、ユーザがデュアル署名検証メカニズムまたはユーザ署名検証メカニズムを使用する必要がある場合、ユーザは、２つのイネーブルビットの値を構成することによって、対応する署名検証メカニズムを有効にし得る。これにより、第２のデバイスのソフトウェアにおけるソフトウェア完全性検証の柔軟性が向上し、第２のデバイスを使用するユーザエクスペリエンスが向上する。

第１の態様の他のいくつかの可能な実装形態では、第２のデバイスを製造するプロセスにおいて、製造業者の公開鍵が第２のデバイスのＳｏＣで焼き付けられて（ｂｕｒｎｔｉｎ）よく、ユーザの公開鍵のフィールドセグメント、デュアルルートイネーブルビット、およびスイッチングイネーブルビットは予約されている。これにより、実際の要件に基づいてデュアル署名検証メカニズムまたはユーザ署名検証メカニズムを有効にすることと、対応するユーザ公開鍵の値、デュアルルートイネーブルビットの値、およびスイッチングイネーブルビットの値を１つまたは複数のファイル（焼付けファイル（ｂｕｒｎｆｉｌｅ）として記録される）にパッケージ化することと、ユーザによる第２のデバイスのその後の使用中に対応するフィールドセグメントの値を焼き付けることとが、本出願の実施形態において、以下の第２の態様において提供されるソフトウェア完全性検証のために準備されることが容易になる。焼付けファイルは、第２のデバイス、たとえば、ワンタイムプログラマブルメモリＯＴＰの信頼のｂｏｏｔルートに記憶され得ることが理解され得る。信頼のｂｏｏｔルートは、具体的には、第２のデバイスのシステムオンチップＳｏＣにおけるオンチップｂｏｏｔメディアＢｏｏｔＲＯＭである可能性がある。

一例では、焼付けファイルが信頼できることを保証するために、焼付けファイルのコンテンツが記憶される前に、第２のデバイスは、第２のデバイスの識別子およびデュアル署名検証デバイスリストをさらに事前に記憶する。第２のデバイスの識別子は、第２のデバイスを一意に識別することができる。デュアル署名検証デバイスリストは、製造業者によって記録され、デュアル署名検証メカニズムを有効にすることを許可されたデバイスのデバイス識別子のセットである。デュアル署名検証デバイスリストは、製造業者署名システムを使用することによって署名され、次いで、第２のデバイスに配信され得る。署名検証を通じて、デュアル署名検証デバイスリストが有効であると決定する場合、第２のデバイスは、第２のデバイスの識別子がデュアル署名検証デバイスリストに属するかどうかを決定し得、第２のデバイスの識別子がデュアル署名検証デバイスリストに属する場合、第２のデバイスはデュアル署名検証メカニズムを有効にすることを許可されたデバイスであると見なす場合がある。この場合、焼付けファイルが受信された後、焼付けファイルの内容に対応する保持値用に予約されたフィールドセグメントにおいて、第２のデバイスのソフトウェア完全性検証の構成が完了する。

元のルート秘密鍵が公開される回数を減らすために、本出願のこの実施形態における第１の公開鍵、第１の秘密鍵、第２の公開鍵、および第２の秘密鍵はすべて、元のルート公開鍵と元のルート秘密鍵が処理された後に取得されたセカンダリ鍵である可能性があることが理解されよう。

マルチレベルファームウェアを含むソフトウェアパッケージの場合、本出願のこの実施形態における各ステップは、ファームウェアの各レベルにおいて署名動作を実行するために同じまたは異なる秘密鍵を使用し得、それによってソフトウェアパッケージに対するソフトウェア完全性保護のセキュリティを向上させることができることが理解されよう。さらに、署名されたファームウェアの各レベルを含むソフトウェアパッケージ全体がさらに署名され得るので、第２のデバイスによるソフトウェアパッケージにおけるソフトウェア完全性検証を実行する効率をある程度改善することができる。

第２の態様によれば、本出願の実施形態は、第２のデバイスに適用されるソフトウェア完全性検証方法をさらに提供する。第１の態様において提供された方法を使用することによって保護された第３のソフトウェアパッケージは、第２のデバイスにダウンロードされ、インストールされる。本方法は、具体的には以下を含み得る。ステップ１：第２のデバイスは第１のソフトウェアパッケージを取得し、第１のソフトウェアパッケージは、第１の署名、第２の署名、および第２のソフトウェアパッケージを含む。ステップ２：第２のデバイスは、検証結果を取得するために、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ第１の署名と第２の署名を検証し、第１の公開鍵はファーストパーティによって制御され、第２の公開鍵はセカンドパーティによって制御される。

第１の署名は、ファーストパーティによって制御される第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行することによって取得され、第３のソフトウェアパッケージは、第１の署名および第２のソフトウェアパッケージを含み、第２の署名は、セカンドパーティによって制御される第２の秘密鍵を使用することによって第３のソフトウェアパッケージに対して署名動作を実行することによって取得され、第１の秘密鍵は第１の公開鍵と一致し、第２の秘密鍵は第２の公開鍵と一致することが理解されよう。ファーストパーティは第２のソフトウェアパッケージのユーザであり得、セカンドパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局である。代替で、ファーストパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局であり得、セカンドパーティは第２のソフトウェアパッケージのユーザである。

このようにして、本出願のこの実施形態において提供される方法によれば、製造業者とユーザによって提供された鍵を使用することによってソフトウェア完全性保護が実行されるソフトウェアパッケージの場合、ユーザにソフトウェア完全性検証の二重の信頼できる基盤を提供するために、製造業者によって提供された鍵に基づいてソフトウェアパッケージに対して署名検証を実行できるだけでなく、ユーザによって提供された鍵に基づいてソフトウェアパッケージに対して署名検証を実行することもでき、したがってソフトウェア完全性検証がより信頼できるものになり、ユーザは、製造業者を完全に信頼して依存する必要がなくなる。これにより、ユーザの信頼の問題が解決し、それによってデバイスを使用するユーザエクスペリエンスが向上する。

第２の態様の可能な実装形態では、第２のデバイスのソフトウェア完全性検証メカニズムを構成するために、第２のデバイスにおいて、スイッチングイネーブルビットおよびデュアルルートイネーブルビットがさらに構成され得る。第２のデバイスにおいて第２のソフトウェアパッケージに対してソフトウェア完全性検証が実行される場合、一例では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、第２の態様におけるステップ２は、具体的には以下を含み得る。第２のデバイスは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証し、第１の署名検証結果は、第１の署名が有効かどうかを表すために使用され、第２のデバイスは、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証し、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用され、第２のデバイスは、第１の署名検証結果および第２の署名検証結果に基づいて検証結果を生成し得、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表し、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。別の例では、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、第２の態様におけるステップ２は、具体的には、以下をさらに含み得る。第２のデバイスは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証し、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用され、第２のデバイスは、第１の署名検証結果に基づいて検証結果を生成し得、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。さらに別の例では、第１のデバイスにおけるスイッチングイネーブルビットが無効であり、第１のデバイスにおけるデュアルルートイネーブルビットが無効である場合、第２の態様におけるステップ２は、具体的には以下をさらに含み得る。第２のデバイスは、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証し、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用され、第２のデバイスは、第２の署名検証結果に基づいて検証結果を生成し得、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。このようにして、２つのイネーブルビットの値は第２のデバイスにおいて構成され、ユーザは実際の要件に基づいて対応する署名検証メカニズムを有効にし得る。これにより、第２のデバイスのソフトウェアにおけるソフトウェア完全性検証の柔軟性が向上し、第２のデバイスを使用するユーザエクスペリエンスが向上する。

第２の態様のいくつかの他の可能な実装形態では、第２のソフトウェアパッケージは、第１のファームウェアおよび第２のファームウェアを含む。

一例では、第１のファームウェアが、第２のデバイスのｂｏｏｔ中にロードされるソフトウェアファームウェアの第１の部分（ｔｈｅｆｉｒｓｔｐｉｅｃｅｏｆｓｏｆｔｗａｒｅｆｉｒｍｗａｒｅ）である場合、このアプリケーションのこの実施形態は、以下を含み得る。第２のデバイスにおける信頼のｂｏｏｔルートは、第１のルート証明書から第２のユーザの公開鍵を取得し、第２のユーザの公開鍵は、信頼のｂｏｏｔルートにおける信頼できるユーザルートの公開鍵であり、第５の検証結果を取得するために、第２のユーザの公開鍵を使用することによって第１のファームウェアにおける第３の署名を検証し、ここで、第５の検証結果は、第１のファームウェアのソフトウェア完全性を表すために使用され、第３の署名は、第２のユーザの秘密鍵を使用することによって第１のファームウェアに対して署名動作が実行された後に取得される署名であり、第２のユーザの公開鍵は、第２のユーザの秘密鍵に対応する。場合によっては、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、本方法は、第５の検証結果が第３の署名は有効であることを表す場合、第１のファームウェアが有効であると決定し、第１のファームウェアをロードするステップをさらに含む。別の場合では、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、本方法は、さらに以下を含む。第２のデバイスの信頼のｂｏｏｔルートは、第２のルート証明書から第２の製造業者の公開鍵を取得し、第２の製造業者の公開鍵は、信頼のｂｏｏｔルート内の信頼できる製造業者のルート公開鍵であり、第６の検証結果を取得するために、第２の製造業者の公開鍵を使用することによって、第１のファームウェアにおける第４の署名を検証し、第６の検証結果は、製造業者のレベルにおける第１のファームウェアのソフトウェア完全性を表すために使用され、第５の検証結果が第３の署名は有効であることを表し、第６の検証結果が第４の署名は有効であることを表す場合、第１のファームウェアが有効であると決定し、第１のファームウェアをロードする。

さらに、第１のファームウェアに対する検証は、さらに以下を含み得る。第２のデバイスにおける信頼のｂｏｏｔルートは第１のファームウェアを取得し、第１のファームウェアのハッシュ値を計算し、第１の比較結果を取得するために、信頼のｂｏｏｔルートに記憶されているハッシュ値と第１のファームウェアのハッシュ値を比較し、第１の比較結果は、第１のファームウェアのソフトウェア完全性を表すために使用され、第１の比較結果が、信頼のｂｏｏｔルートに記憶されたハッシュ値は第１のファームウェアのハッシュ値と一致することを表す場合、第１のファームウェアは有効であると決定し、第１のファームウェアをロードする。

別の例では、第１のファームウェアが第２のデバイスのｂｏｏｔ中にロードされる他のソフトウェアファームウェア（ソフトウェアファームウェアの第１の部分の前にある他のファームウェア）であり、第２のファームウェアが、第１のファームウェアのロード後に検証およびロードされるファームウェアである場合、本方法は、第１のファームウェアにおける第１の証明書から第１のユーザの公開鍵を取得するステップと、第１の署名検証結果を取得するために、第１のユーザの公開鍵を使用することによって第２のファームウェアにおける第１の署名を検証するステップであって、第１の署名検証結果は、第２のファームウェアのソフトウェア完全性を表すために使用されるステップとを含み、第１の署名は、第１のユーザの秘密鍵を使用することによって第２のファームウェアに対して署名動作が実行された後に取得される署名であり、第１のユーザの公開鍵は第１のユーザの秘密鍵に対応する。場合によっては、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、第１の署名検証結果が第１の署名が有効であることを表すとき、第２のファームウェアは有効であると決定され、第２のファームウェアがロードされる。別の場合では、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、本方法は、第１のファームウェアにおける第２の証明書から第２の製造業者の公開鍵を取得するステップと、第２の検証結果を取得するために、第２の製造業者の公開鍵を使用することによって第２のファームウェアにおける第２の署名を検証するステップとをさらに含み、第２の検証結果は、第２のファームウェアのソフトウェア完全性を表すために使用され、第２の署名は、第２の製造業者の秘密鍵を使用することによって第２のファームウェアに対して署名動作が実行された後に取得される署名であり、第２の製造業者の公開鍵は第２の製造業者の秘密鍵に対応し、第１の署名検証結果が第１の署名は有効であることを表し、第２の検証結果が第２の署名は有効であることを表す場合、第２のファームウェアは有効であると決定し、第２のファームウェアをロードする。このようにして、ソフトウェアファームウェアの第１の部分以外のファームウェアについては、ソフトウェアパッケージにおけるすべてのファームウェアがロードされるか、特定のファームウェア（ａｓｐｅｃｉｆｉｃｐｉｅｃｅｏｆｆｉｒｍｗａｒｅ）のソフトウェア完全性検証が失敗するまで、前述の方法を使用することによってソフトウェア完全性検証が実行される。

第２の態様の他のいくつかの可能な実装形態において、第１の署名および第２の署名が、セカンダリ秘密鍵を使用することによって署名動作が実行された後に得られる署名であり、第２のデバイスに事前に記憶されている第１の公開鍵および第２の公開鍵もまたセカンダリ公開鍵である場合、各署名が検証される前に、本出願のこの実施形態は、以下の２つのステップをさらに含み得る。ステップ１：ｆｌａｓｈメモリから元のルート公開鍵を読み取り、元のルート公開鍵のハッシュ値を計算し、ハッシュ値がプライマリ公開鍵の値と一致しているかどうかを検証し、ハッシュ値がプライマリ公開鍵の値と一致している場合、プライマリ公開鍵が有効であると決定する。ステップ２：証明書を読み取り、プライマリ公開鍵を処理することによって取得したセカンダリ公開鍵を使用することによって証明書に対して署名検証を実行し、署名検証が成功した場合は、証明書に事前に記憶されているセカンダリ公開鍵は有効であると決定し、セカンダリ公開鍵を使用することによってソフトウェアパッケージを検証する。このようにして、第２のデバイスにロードされる第２のソフトウェアパッケージに対してソフトウェア完全性検証を実行できるだけでなく、元のルート秘密鍵が公開される回数を減らすことができ、それによって、第２のデバイスのセキュリティと信頼性が向上する。さらに、ＳｏＣのストレージスペースも節約することができる。

第２の態様の他のいくつかの可能な実装形態では、本出願のこの実施形態では、第２の公開鍵は、代替でコードセグメントから抽出され、単一のファイル１の形式でコードセグメント２に付加され得、すなわち、第２のデバイスの配信前に、ｆｌａｓｈメモリにおけるレイアウトは、たとえば、「ヘッダファイル＋コードセグメント２＋ファイル１」として表され得る。このようにして、第２のデバイスの使用中にデュアル署名検証メカニズムが有効になっている場合、第１の公開鍵を記憶するためにファイル２のみをｆｌａｓｈメモリに個別に追加する必要がある。この場合、ｆｌａｓｈメモリにおけるレイアウトは、たとえば、「ヘッダファイル＋コードセグメント２＋ファイル１＋ファイル２」として表され得る。このようにして、ユーザの署名検証メカニズムにおける変更に起因する作業の困難さが大幅に軽減され、第２のデバイスを使用するユーザエクスペリエンスが向上する。

第３の態様によれば、本出願の実施形態は、ソフトウェア完全性保護装置をさらに提供する。装置は第１のデバイスにおいて使用され、装置は、取得ユニットおよび署名ユニットを含む。取得ユニットは、第１のソフトウェアパッケージを取得するように構成され、第１のソフトウェアパッケージは、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのためにファーストパーティによって作成された第１の署名を含む。署名ユニットは、第２の署名を含む第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作を実行するように構成され、第１の秘密鍵は、ファーストパーティによって制御され、第２の秘密鍵はセカンドパーティによって制御される。

ファーストパーティは第２のソフトウェアパッケージのユーザであり、セカンドパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局である。

可能な実装形態において、装置は、送信ユニットをさらに含む。送信ユニットは、第３のソフトウェアパッケージを第２のデバイスに送信するように構成されている。

別の可能な実装形態では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、第１の署名および第２の署名が両方とも有効であることは、第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、第１の署名が有効であることは、第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、第２の署名が有効であることは、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。

第３の態様において提供される装置は、第１の態様における動作を実行するように構成されることに留意されたい。装置の特定の実装形態および達成された効果については、第１の態様における関連する説明を参照されたい。詳細については、本明細書では再度説明しない。

第４の態様によれば、本出願の実施形態は、ソフトウェア完全性検証装置をさらに提供する。装置は第２のデバイスにおいて使用され、装置は取得ユニットおよび検証ユニットを含む。取得ユニットは第１のソフトウェアパッケージを取得するように構成され、第１のソフトウェアパッケージは、第１の署名、第２の署名、および第２のソフトウェアパッケージを含む。検証ユニットは、検証結果を取得するために、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ第１の署名と第２の署名を検証するように構成され、第１の公開鍵はファーストパーティによって制御され、第２の公開鍵はセカンドパーティによって制御される。

可能な実装形態では、第１の署名は、ファーストパーティによって制御される第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行することによって取得され、第１の署名と第２のソフトウェアパッケージは、第３のソフトウェアパッケージに含まれており、第２の署名は、セカンドパーティによって制御される第２の秘密鍵を使用することによって第３のソフトウェアパッケージに対して署名動作を実行することによって取得され、第１の秘密鍵は第１の公開鍵と一致し、第２の秘密鍵は第２の公開鍵と一致する。

別の可能な実装形態では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、検証ユニットは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証するように構成され、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される、第１の検証サブユニットと、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証するように構成され、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される、第２の検証サブユニットと、第１の署名検証結果および第２の署名検証結果に基づいて検証結果を生成するように構成された第１の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表し、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第１の生成サブユニットとを含む。あるいは、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、検証ユニットは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証するように構成され、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される、第３の検証サブユニットと、第１の署名検証結果に基づいて検証結果を生成するように構成された第２の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第２の生成サブユニットとを含む。あるいは、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第１のデバイスにおけるデュアルルートイネーブルビットが無効である場合、検証ユニットは、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証するように構成され、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される、第４の検証サブユニットと、第２の署名検証結果に基づいて検証結果を生成するように構成された第３の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第３の生成サブユニットとを含む。

第４の態様において提供される装置は、第２の態様における動作を実行するように構成されることに留意されたい。装置の特定の実装形態および達成された効果については、第２の態様における関連する説明を参照されたい。詳細については、本明細書では再度説明しない。

第５の態様によれば、本出願の実施形態は、デバイスをさらに提供する。デバイスは、メモリおよびプロセッサを含む。メモリはプログラムコードを記憶するように構成されている。プロセッサは、デバイスが、第１の態様または第２の態様の実装形態のうちのいずれか１つにおいて方法を実行できるように、プログラムコードまたはプログラム内の命令を実行するように構成されている。

第６の態様によれば、本出願の一実施形態は、コンピュータ可読ストレージ媒体をさらに提供する。コンピュータ可読ストレージ媒体は、プログラムコードまたは命令を記憶する。プログラムコードまたは命令がコンピュータ上で実行されるとき、コンピュータは、第１の態様または第２の態様の実装形態のうちのいずれか１つにおいて方法を実行することが可能になる。

第７の態様によれば、本出願の実施形態は、ネットワークシステムをさらに提供する。ネットワークシステムは、第３の態様において提供されるソフトウェア完全性保護と、第４の態様において提供されるソフトウェア完全性検証装置とを含む。

いくつかの実施形態では、ファーストパーティＣＡ、たとえば、サーバは、ソフトウェアパッケージにデジタル証明書を発行し得る。セカンドパーティまたはサードパーティのＣＡは、デジタル証明書を発行するように構成されたサーバの場合もある。

本出願の実施形態の技術的解決策をより明確に説明するために、以下は、実施形態を説明するための添付の図面を簡単に説明する。以下の説明の添付の図面は、本出願のいくつかの実施形態を示しているにすぎず、当業者は、これらの添付の図面から他の図面を導き出すことができることは明らかである。

本出願の実施形態による、アプリケーションシナリオにおけるネットワークシステムフレームワークの概略図である。本出願の実施形態による、ソフトウェア完全性保護方法の概略フローチャートである。本出願の実施形態による、第２のソフトウェアパッケージに対して署名動作を実行することによって第１のソフトウェアパッケージを取得する概略図である。本出願の実施形態による、第１のソフトウェアパッケージに対して署名動作を実行することによって第３のソフトウェアパッケージを取得する概略図である。本出願の実施形態による、ソフトウェア完全性検証方法の概略フローチャートである。本出願の実施形態による、第１のデバイスの概略図である。本出願の実施形態による、ソフトウェア完全性検証のためのシナリオの概略図である。本出願の実施形態による、ソフトウェア完全性検証の例の概略フローチャートである。本出願の実施形態による、ソフトウェア完全性検証の例の概略フローチャートである。本出願の実施形態による、ソフトウェア完全性検証の別の例の概略フローチャートである。本出願の実施形態による、ソフトウェア完全性検証のための別のシナリオの概略図である。本出願の実施形態による、ソフトウェア完全性検証の別の例の概略フローチャートである。本出願の実施形態による、ソフトウェア完全性保護装置の概略構造図である。本出願の実施形態による、ソフトウェア完全性検証装置の概略構造図である。本出願の実施形態による、デバイスの概略構造図である。本出願の実施形態による、ネットワークシステムの概略構造図である。

デジタル署名は通常、ソフトウェアパッケージやメッセージなどのデジタルダイジェストに署名するために使用される鍵と、ソフトウェアパッケージやメッセージなどの署名を検証するために使用される鍵とのペアを含む。一例では、ソフトウェアパッケージＸのデジタル署名プロセスは、以下の２つのプロセスを含み得ると仮定される。第１のプロセスは、ソフトウェアパッケージＸのデジタルダイジェストに署名することに対応する。具体的には、ソフトウェアパッケージＸをデバイスＹにダウンロードする前に、ハッシュアルゴリズムを使用することによってＸのデジタルダイジェストＸ１が第１に取得され、次いで秘密鍵ａを使用してｄｉｇｅｓｔＸ１に署名することによってｄｉｇｅｓｔＥｎｃｏｄｅＸ１が取得される。ソフトウェアパッケージＸがデバイスＹにダウンロードされると、ＸとｄｉｇｅｓｔＥｎｃｏｄｅＸ１がデバイスＹに送信される。第２のプロセスは、ソフトウェアパッケージＸの署名の検証に対応する。具体的には、ソフトウェアパッケージＸをロードする前に、デバイスＹは、Ｘの署名に使用されるものと同じハッシュアルゴリズムを使用することによってデジタルダイジェストｄｉｇｅｓｔＸ２を第１に生成し、次いで、ｄｉｇｅｓｔＤｅｃｏｄｅＸ３を取得するために、公開鍵Ａを使用することによってｄｉｇｅｓｔＥｎｃｏｄｅＸ１を検証し、ｄｉｇｅｓｔＤｅｃｏｄｅＸ３＝ｄｉｇｅｓｔＸ２である場合、ソフトウェアパッケージＸが改ざんされておらず、合法的な製造業者によってリリースされていると決定し得る。したがって、デバイスＹにロードされたソフトウェアパッケージＸは安全で信頼できることが保証される。秘密鍵ａと公開鍵Ａは、デバイスＡの製造業者から提供された鍵のペアである。公開鍵Ａは公開アクセス可能であり、秘密鍵ａは機密情報であり、製造業者に対応する署名システムによってのみアクセス可能である。たとえば、製造業者に対応する署名システムは、製造業者の認証局（英語：ＣｅｒｔｉｆｉｃａｔｅＡｕｔｈｏｒｉｔｙ、略してＣＡ）サーバであり、ＣＡサーバは、製造業者に対応するデバイスにダウンロードされるソフトウェアパッケージに署名する。

デジタル署名技術は、デジタルダイジェスト技術と公開鍵および秘密鍵の技術の組合せと見なされ得ることが理解されよう。ソフトウェアパッケージが改ざんされているかどうかは、デジタルダイジェスト技術を使用することによって検証され得、デジタルダイジェストが有効であるかどうかは、公開鍵および秘密鍵の技術を使用することによって検証され得る。デジタル署名技術は、ソフトウェアパッケージの高速で包括的なソフトウェア完全性保護と検証を提供する技術である。

現在、ソフトウェア完全性保護と検証は、製造業者の鍵（製造業者によって提供された公開鍵と秘密鍵を含む）を使用することによってソフトウェアパッケージに実装されている。一方で、特定の実装形態中に、製造業者の署名システムは、製造業者によって提供された秘密鍵を使用することによってソフトウェアパッケージに署名し、製造業者は、秘密鍵に対応する公開鍵を事前に記憶する。この場合、署名されたソフトウェアパッケージがデバイスにロードされる前に、ソフトウェアパッケージの署名を検証するために、事前に記憶された公開鍵が使用され得る。このようにして、デバイスにおいて実行されるソフトウェアパッケージのソフトウェア完全性は、製造業者によって提供された鍵を使用することによって保証される。デバイスにおいて実行されるソフトウェアのセキュリティと信頼性はある程度保証できるが、デバイスを使用するユーザは、製造業者を完全に信頼し、依存する必要がある。製造業者によって提供された鍵が無効である場合、ソフトウェア完全性保護と検証をデバイスに実装することができず、ユーザの信頼の問題を解決することができない。すなわち、ユーザは、製造業者によって提供された鍵がないと、ユーザによって購入されたデバイスにおけるソフトウェアを個別にアップグレードおよび維持することができず、デバイスを使用するユーザエクスペリエンスに影響を及ぼす。

これを考慮して、本出願の実施形態は、ソフトウェア完全性保護方法およびソフトウェア完全性検証方法を提供する。デバイス１は、デバイス１が属する製造業者によって提供される第１の公開鍵と、デバイス１に対応するユーザＡによって提供される第２の公開鍵とを記憶し得る。デュアル鍵は、ユーザによって購入されたデバイスにセキュリティ保証を提供し、それによってユーザの信頼の問題を解決し、デバイスを使用するユーザエクスペリエンスを向上させる。

一方では、ソフトウェア完全性保護プロセスは、署名ａを含むソフトウェアパッケージ２を取得するために、ユーザの署名システム１において、第２の公開鍵に対応する第２の秘密鍵を使用することによってソフトウェアパッケージ１に署名することと、ソフトウェアパッケージ２がデバイス１にダウンロードされる前に、署名ａおよび署名ｂを含むソフトウェアパッケージ３を取得するために、製造業者の署名システム２において、第１の公開鍵に対応する第１の秘密鍵を使用することによってソフトウェアパッケージ２に署名することとを含み得る。このようにして、ソフトウェアパッケージは、製造業者によって提供された鍵に基づいて署名できるだけでなく、ソフトウェアパッケージは、ユーザによって提供された鍵に基づいて署名することもでき、ユーザによって提供された鍵は、ユーザにとって絶対的に信頼できるものである。すなわち、本出願の実施形態は、製造業者を完全に信頼または依存することなく、ユーザによって信頼され得るソフトウェア完全性保護方法を提供する。これにより、ユーザの信頼の問題が解決し、それによってデバイスを使用するユーザエクスペリエンスが向上する。

他方、前述の実施形態において署名されたソフトウェアパッケージ３の場合、ソフトウェアパッケージ３がデバイス１にロードされる前に、ソフトウェアパッケージ３に対してソフトウェア完全性検証を実行するプロセスは、以下を含み得る。デバイス１は、署名検証結果１を取得するために、デバイス１に記憶されている第１の公開鍵に基づいてソフトウェアパッケージ３の署名ｂを検証し、デバイス１は、署名検証結果２を取得するために、デバイス１に記憶されている第２の公開鍵に基づいてソフトウェアパッケージ３の署名ａを検証する。デバイス１は、署名検証結果１および署名検証結果２に基づいて検証結果を生成し得、検証結果は、ソフトウェアパッケージ１のソフトウェア完全性を表すために使用され、署名検証結果１と検証結果２の両方が、対応する署名が有効であることを表す場合、検証結果は、ソフトウェアパッケージ１に対するソフトウェア完全性検証が成功したことを表すために使用され、または署名検証結果１と検証結果２のうちの少なくとも１つが、対応する署名が無効であることを表す場合、検証結果は、ソフトウェアパッケージ１に対するソフトウェア完全性検証が失敗したことを表すために使用される。このようにして、製造業者とユーザによって提供される鍵を使用することによってソフトウェア完全性保護が実行されるソフトウェアパッケージについては、製造業者によって提供される鍵に基づいてソフトウェアパッケージに対して署名検証を実行することができるだけでなく、製造業者を完全に信頼して依存することなく、ユーザによって提供される鍵に基づいてソフトウェアパッケージに対して署名検証を実行することもできる。これにより、ユーザの信頼の問題が解決され、ユーザにとってソフトウェア完全性検証の二重の信頼できる基盤が提供されるため、ソフトウェア完全性検証の信頼性が高まり、それによってデバイスを使用するユーザエクスペリエンスが向上する。

たとえば、本出願の実施形態におけるシナリオの１つは、図１に示されるシナリオであり得る。図１は、デバイス１００のｂｏｏｔプロセスにおいて実行されるソフトウェアパッケージ２００に対するソフトウェア完全性保護の概略図である。シナリオには、デバイス１００、製造業者署名システム３００、およびユーザ署名システム４００が含まれる。製造業者署名システム３００は、ソフトウェアパッケージ２００に署名し、製造業者公開鍵１を提供するために、デバイス１００のために製造業者によって提供される鍵１（公開鍵１および秘密鍵１を含む）を生成する。ユーザ署名システム４００は、ソフトウェアパッケージ２００に署名し、ユーザ公開鍵２を提供するために、デバイス１００のためにユーザによって提供される鍵２（公開鍵２および秘密鍵２を含む）を生成する。製造業者署名システム３００（たとえば、ＣＡサーバ）は、製造業者公開鍵１およびユーザ公開鍵２を受け取り、製造業者公開鍵１およびユーザ公開鍵２を、デバイス１００に含まれるステムオンチップ（英語：ＳｙｓｔｅｍｏｎＣｈｉｐ、略してＳｏＣ）１１０に事前に焼き付けるようにさらに構成される。デバイス１００は、具体的には、ルータまたはスイッチなどのネットワークデバイスであり得る。デバイス１００上のＳｏＣ１１０はハードウェアであり、オンチップｂｏｏｔ媒体（英語：ＢｏｏｔｏＲＯＭ）１１１は、ＳｏＣ１１０上のセキュリティサブシステムに統合され得る。ＢｏｏｔＲＯＭ１１１は、デバイス１００の電源がオンになったときに、ソフトウェアパッケージ２００に対するソフトウェア完全性検証を最初に開始するように構成されている。

デバイス１００のデバイス製造業者は、デバイス１００を提供する一方で、デバイス１００上にソフトウェアパッケージ２００を提供し、すなわち、デバイス製造業者とソフトウェア製造業者は同一のパーティである場合があることに留意されたい。この場合、製造業者署名システム３００は、デバイス製造業者およびソフトウェア製造業者に共同で対応する署名システムであり得る。別の場合では、デバイス１００のデバイス製造業者は、デバイス１００にソフトウェアパッケージ２００を提供せず、ソフトウェアパッケージ２００は、独立したソフトウェア製造業者によって提供される。この場合、製造業者署名システム３００は、ソフトウェア製造業者に対応する署名システム、またはソフトウェアパッケージ２００を提供するサードパーティのデジタル認証局であり得る。

一例では、ソフトウェアパッケージ２００に対するソフトウェア完全性保護を実行するプロセスは、たとえば、２つの署名を伴う（ｃａｒｒｙ）ソフトウェアパッケージ２００’を取得するために、ソフトウェア製造業者またはサードパーティプラットフォームに対応するサーバからソフトウェアパッケージ２００を取得することと、ユーザ署名システム４００における秘密鍵２を使用することによってソフトウェアパッケージ２００に署名することと、製造業者署名システム３００における秘密鍵１を使用することによってソフトウェアパッケージ２００に署名することとであり得る。この場合、デバイス１００によって要求されるとき、ソフトウェアパッケージ２００’は、デバイス１００、たとえば、デバイス１００のｆｌａｓｈメモリ（英語：ＦｌａｓｈＭｅｍｏｒｙ）にダウンロードされ得る。

別の例では、デバイス１００の電源がオンになっている場合、ソフトウェアパッケージ２００の実行を開始する前にソフトウェアパッケージ２００に対してソフトウェア完全性検証を実行するプロセスは、たとえば、以下のようになり得る。デバイス１００のＢｏｏｔＲＯＭ１１１は、検証結果を取得するために、ＳｏＣ１１０に記憶されている公開鍵１および公開鍵２にそれぞれ基づいて、ソフトウェアパッケージ２００’の２つの署名を検証し得る。検証結果が、ソフトウェアパッケージ２００’の両方の署名が有効であることを表す場合、デバイス１００は、ソフトウェアパッケージ２００が改ざんされておらず、合法的なソフトウェア製造業者によって提供されていると決定し、デバイス１００は、ソフトウェアパッケージ２００をロードする。

公開鍵１および公開鍵２は、ＳｏＣ１１０のワンタイムプログラマブルメモリ（英語：Ｏｎｅ－ＴｉｍｅＰｒｏｇｒａｍｍａｂｌｅ、略してＯＴＰ）、たとえば、電気ヒューズ（英語：ｅｌｅｃｔｒｉｃａｌＦＵＳＥ、略してｅＦｕｓｅ）に記憶され得ることが理解されよう。ｅＦｕｓｅに焼き付けられたコンテンツは変更できないため、公開鍵１と公開鍵２をｅＦｕｓｅに確実かつ安全に記憶することができる。

公開鍵１および公開鍵２は、ＳｏＣ１１０に独立して記憶されてもよく、公開鍵１および公開鍵２に対応するルート証明書１およびルート証明書２にそれぞれ記憶されてもよく、公開鍵１および公開鍵２は、それぞれルート証明書１およびルート証明書２から読み取られることに留意されたい。

本シナリオは、本出願の実施形態において提供される単なるシナリオ例であるが、本出願の実施形態は、本シナリオに限定されないことが理解されよう。

添付の図面を参照して、以下は、実施形態を使用することによって、本出願の実施形態におけるソフトウェア完全性保護方法およびソフトウェア完全性検証方法の特定の実装形態を詳細に説明する。

図２は、本出願の実施形態による、ソフトウェア完全性保護方法の概略フローチャートである。本方法は、第２のソフトウェアパッケージに対応する製造業者署名システムに適用されてもよく、第２のデバイスを使用するユーザが属するユーザ署名システムに適用されてもよい。たとえば、図１に示されるシナリオの場合、この実施形態は、製造業者署名システム３００またはユーザ署名システム４００によって実行され得る。署名システムは、証明書発行システムとも呼ばれ、署名システムに記憶されている秘密鍵を使用することによって、保護対象のソフトウェアパッケージまたはファイルに対して署名動作を実行するように構成されており、具体的には、たとえばＣＡサーバであり得る。製造業者署名システムは、ソフトウェア製造業者によって提供および維持される署名環境を指し、ユーザ署名システムは、ユーザによって提供および維持される別の署名環境を指す。

図２を参照する。この実施形態では、第２のデバイスにインストールされる第２のソフトウェアパッケージに対するソフトウェア完全性保護のための方法を説明するために、第２のソフトウェアパッケージに対応する製造業者署名システム（以下、第１のデバイスとして示される）を例として使用する。本方法は、具体的には次のステップ２０１およびステップ２０２を含み得る。

ステップ２０１：第１のデバイスは、第１のソフトウェアパッケージを取得し、第１のソフトウェアパッケージは、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのためにファーストパーティによって作成された第１の署名を含む。

第２のソフトウェアパッケージは、ソフトウェア製造業者によって提供され、ユーザの特定の要件を満たすことができるソフトウェアパッケージであり、第２のソフトウェアパッケージは、ソフトウェア製造業者のサーバまたはサードパーティのサーバに記憶され得ることが理解されよう。ユーザは、ソフトウェア製造業者のサーバに対応するウェブページ、サードパーティのサーバに対応するソフトウェアストア、あるいは別の信頼できるデバイスまたはシステムから第２のソフトウェアパッケージを取得し得る。

第１のソフトウェアパッケージは、第２のデバイスのユーザ（すなわち、ファーストパーティ）に対応するユーザ署名システムが、ユーザによって提供された第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行した後に取得されるソフトウェアパッケージである。第１のソフトウェアパッケージは、第１の署名および第２のソフトウェアパッケージを含み得る。第１の署名は、第２のソフトウェアパッケージに対応し、第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作が実行された後に取得される署名であり、第１の署名は、第２のソフトウェアパッケージに対する後続のソフトウェア完全性検証に使用される。第２のソフトウェアに対する署名動作については、前述のデジタル署名技術の説明を参照されたい。詳細については、本明細書では再度説明しない。

特定の実装形態中に、ユーザが第２のソフトウェアパッケージを第２のデバイスにダウンロードする必要がある場合、第２のソフトウェアパッケージに対してソフトウェア完全性保護を実行するために、すなわち、ダウンロードされた第２のソフトウェアパッケージが改ざんされておらず、信頼できるソースを有していることを保証するために、ステップ２０１の前に、ユーザ署名システムは、第１の署名を含む第１のソフトウェアパッケージを取得するために、第１に第２のソフトウェアパッケージを取得し、ユーザによって提供された第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行する。一例では、ユーザ署名システムは、第１のソフトウェアパッケージをサードパーティ管理プラットフォームに送信し得る。この場合、ステップ２０１は、具体的には次のようになり得る。第２のソフトウェアパッケージの製造業者に対応する製造業者署名システム（すなわち、第１のデバイス）は、サードパーティ管理プラットフォームから第１のソフトウェアパッケージを取得する。別の例では、ユーザ署名システムは、第１のソフトウェアパッケージを第１のデバイスに直接送信し得る。言い換えれば、ステップ２０１は、具体的には次のようになり得る。第１のデバイスは、ユーザ署名システムから第１のソフトウェアパッケージを直接取得する。

いくつかの可能な実装形態では、第２のソフトウェアパッケージは複数のｂｏｏｔを含み得、ｂｏｏｔは、第２のソフトウェアパッケージが実行されるときのロードシーケンスに基づいて異なるレベルに分類される。具体的には、ファーストパーティは、複数の第１の秘密鍵を使用することによって、第２のソフトウェアパッケージ内のｂｏｏｔに対して個別に署名動作を実行し得、それに応じて、ｂｏｏｔごとに１つの第１の署名が取得される。複数の第１の秘密鍵は、同じであってもよく、異なっていてもよい。一例では、第１の秘密鍵が同じである場合、各ｂｏｏｔは第１の証明書を含み得、ｂｏｏｔの次のレベルのｂｏｏｔにおいて署名検証動作を実行するために、第１の秘密鍵と一致する第１の公開鍵が第１の証明書から取得され得る。さらに、スペースを節約するために、各ｂｏｏｔは第１の証明書を含まない場合があり、ｂｏｏｔごとに、第１のデバイスに事前に記憶されている第１の公開鍵を使用することによって署名検証が実行され得る。別の例では、第１の秘密鍵が異なる場合、すなわち、ユーザが複数の鍵のグループを提供し、異なる鍵における第１の秘密鍵が異なるｂｏｏｔに署名するために使用される場合、各ｂｏｏｔは第１の証明書を含み、第１の公開鍵は第１の証明書から取得され得る。第１の公開鍵は、次のレベルのｂｏｏｔにおいて署名動作を実行するために使用される第１の秘密鍵と一致し、第１の公開鍵は、次のレベルのｂｏｏｔの第１の署名の有効性を検証するために使用される。

第１のソフトウェアパッケージにおける各レベルのｂｏｏｔは、対応する第１の署名を伴う場合があり、最後のｂｏｏｔ以外の他のｂｏｏｔもそれぞれ第１の証明書を伴う場合があることに留意されたい。

たとえば、図３は、第１のソフトウェアパッケージの概略図である。図３を例として使用する。第２のソフトウェアパッケージがＬ１ｂｏｏｔ、Ｌ２ｂｏｏｔ、およびＬ３ｂｏｏｔを含むと仮定すると、ユーザ署名システムは、署名１１、署名１２、および署名１３を取得するために、秘密鍵１１、秘密鍵１２、および秘密鍵１３を使用することによって、それぞれ３つのｂｏｏｔに対して署名動作を実行し得る。Ｌ１ｂｏｏｔは証明書１をさらに含み得、秘密鍵１２と一致する公開鍵１２は証明書１から取得され得る。同様に、Ｌ２ｂｏｏｔは証明書２をさらに含み得、秘密鍵１３と一致する公開鍵１３は証明書２から取得され得る。さらに、秘密鍵１１と一致する公開鍵１１は、ユーザルート公開鍵としてさらに使用され得、その後の署名検証に使用するために、第１のデバイスに事前に記憶される。

このようにして、ソフトウェア完全性検証が後で実行されるソフトウェアパッケージは、ユーザによって提供されたキーに基づいて署名動作が実行された後に取得されるソフトウェアパッケージであることが保証され、ユーザは、ソフトウェアパッケージの製造業者を完全に信頼して依存する必要がないため、ユーザによって絶対的に信頼され得るソフトウェア完全性保護方法を提供することが可能である。

ステップ２０２：第１のデバイスは、第２の署名を含む第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作を実行し、第１の秘密鍵は、ファーストパーティによって制御され、第２の秘密鍵はセカンドパーティによって制御される。

第３のソフトウェアパッケージは、第１のデバイスが、第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局（つすなわち、セカンドパーティ）によって提供された第２の秘密鍵を使用することによって、取得された第１のソフトウェアパッケージに対して署名動作を実行した後に取得されるソフトウェアパッケージであることが理解されよう。第３のソフトウェアパッケージは、第２の署名および第１のソフトウェアパッケージを含み得るか、または第３のソフトウェアパッケージは、第１の署名、第２の署名、および第２のソフトウェアパッケージを含むと見なされ得る。第２の署名は、第１のソフトウェアパッケージの署名であり、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作が実行された後に取得され、第２の署名は第２のソフトウェアパッケージに対する後続のソフトウェア完全性検証に使用される。第１のソフトウェアパッケージに対する署名動作については、前述のデジタル署名技術の説明を参照されたい。詳細については、本明細書では再度説明しない。

いくつかの可能な実装形態では、第２のソフトウェアパッケージが複数のｂｏｏｔを含む例が使用される。第１のデバイスは、複数の第２の秘密鍵を使用することによって、第２のソフトウェアパッケージにおけるｂｏｏｔに対して個別に署名動作を実行し得、それに応じて、各ｂｏｏｔに対して１つの第２の署名が取得される。複数の第２の秘密鍵は、同じであってもよく、異なっていてもよい。一例では、第２の秘密鍵が同じである場合、各ｂｏｏｔは第２の証明書を含み得、ｂｏｏｔの次のレベルのｂｏｏｔにおいて署名検証動作を実行するために、第２の秘密鍵と一致する第２の公開鍵が第２の証明書から取得され得る。さらに、スペースを節約するために、各ｂｏｏｔは第２の証明書を含まない場合があり、ｂｏｏｔごとに、第２のデバイスに事前に記憶されている第２の公開鍵を使用することによって署名検証が実行され得る。別の例では、第２の秘密鍵が異なる場合、すなわち、ソフトウェア製造業者が複数の鍵のグループを提供し、異なる鍵における第２の秘密鍵が異なるｂｏｏｔに署名するために使用される場合、各ｂｏｏｔは第２の証明書を含み、第２の公開鍵は第２の証明書から取得され得る。第２の公開鍵は、次のレベルのｂｏｏｔにおいて署名動作を実行するために使用される第２の秘密鍵と一致し、第２の公開鍵は、次のレベルのｂｏｏｔの第２の署名の有効性を検証するために使用される。

第３のソフトウェアパッケージにおける各レベルのｂｏｏｔは、対応する第１の署名および対応する第２の署名を伴う場合があり、最後のｂｏｏｔ以外の他のｂｏｏｔもそれぞれ第１の証明書と第２の証明書を伴う場合があることに留意されたい。

たとえば、図４は、第３のソフトウェアパッケージの概略図である。ステップ２０１において取得された第１のソフトウェアパッケージは図３に示されているものであると仮定すると、第１のデバイスは、署名２１、署名２２、および署名２３を取得するために、秘密鍵２１、秘密鍵２２、および秘密鍵２３を使用することによって、３つのｂｏｏｔに対してそれぞれ署名動作を実行し得る。Ｌ１ｂｏｏｔは、証明書１’をさらに含み得、秘密鍵２２と一致する公開鍵２２は、証明書１’から取得され得る。同様に、Ｌ２ｂｏｏｔは、証明書２’をさらに含み得、秘密鍵２３と一致する公開鍵２３は、証明書２’から取得され得る。さらに、秘密鍵２１と一致する公開鍵２１は、製造業者のルート公開鍵としてさらに使用され得、その後の署名検証に使用するために、第１のデバイスに事前に記憶される。

第２のソフトウェアパッケージに対してデュアル署名動作が実行された後、第３のソフトウェアパッケージが第２のデバイスにダウンロードされる前に、第３のソフトウェアパッケージは、第１のデバイスを使用することによって全体として署名され得るので、続いて第３のソフトウェアパッケージをダウンロードした後、第２のデバイスは、最初に第３のソフトウェアパッケージ全体に対する署名検証に成功し、第３のソフトウェアパッケージの全体的なソフトウェア完全性が有効であるかどうかを決定することが理解されよう。

いくつかの可能な実装形態では、第１の秘密鍵、第２の秘密鍵、第１の公開鍵、および第２の公開鍵は、ユーザによって提供された鍵および製造業者によって提供された鍵が処理された後に得られる鍵であり得、処理された鍵を使用することによってソフトウェアパッケージに対して署名動作および署名検証動作が実行され、元の秘密鍵（以下、プライマリ秘密鍵と呼ばれる）が公開される回数を効果的に減らすことができ、ソフトウェアパッケージのセキュリティを改善することができる。例として、第１の秘密鍵および第１の公開鍵が使用されていることが理解され得る。第１の秘密鍵が、プライマリ秘密鍵が処理された後に取得された秘密鍵である場合、第１の秘密鍵と一致する第１の公開鍵を取得するために、プライマリ秘密鍵と一致するプライマリ公開鍵も処理される必要がある。

さらに、本出願のこの実施形態では、ルート公開鍵は、セキュアハッシュアルゴリズム（英語：ＳｅｃｕｒｅＨａｓｈＡｌｇｏｒｉｔｈｍ、略してＳＨＡ）（たとえば、ＳＨＡ２５６）を使用することによってさらに処理され得る。このようにして、第２のデバイスのハードウェアレジスタに記憶する必要のあるルート公開鍵の場合、４０９６ビットのルート公開鍵が２５６ビットのプライマリ公開鍵に変換され得、それによって、第２のデバイスのハードウェアストレージリソースを大幅に節約できる。セカンダリ秘密鍵はプライマリ秘密鍵を処理することによって取得され、セカンダリ秘密鍵はセカンダリ公開鍵を含む証明書に対する署名動作を実行するために使用される。証明書の有効性が検証される必要がある場合、プライマリ公開鍵に対応するセカンダリ公開鍵を取得するために、プライマリ公開鍵が処理され得る。セカンダリ公開鍵は、証明書の有効性と証明書におけるセカンダリ公開鍵の有効性を決定するために、証明書の署名に対して署名検証動作を実行するために使用され得る。

ユーザは、デバイスの製造またはデバイスの使用のプロセスにおいて、実際の要件に基づいて、デュアル署名許可およびデュアル署名検証許可を有効にするように要求し得ることに留意されたい。ユーザがデュアル署名許可およびデュアル署名検証許可を有する場合、ソフトウェア完全性保護は、この実施形態を使用することによって実行され得る。あるいは、ユーザは、実際の要件に基づいて、ユーザ署名許可およびユーザ署名検証許可を有効にするように要求し得る。ユーザがユーザ署名許可およびユーザ署名検証許可を有する場合、ある意味で、ソフトウェア完全性保護は、この実施形態を使用することによって実行され得、別の方法ではステップ２０２を実行することなく、第１の署名を含む第１のソフトウェアパッケージを取得するために、第１の秘密鍵のみを使用することによって第２のソフトウェアパッケージに対して署名動作が代替で実行され得る。

本出願この実施形態は、代替で、ユーザ署名システムによって実行され得ることに留意されたい。この場合、ファーストパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局であり得、セカンドパーティは第２のソフトウェアパッケージのユーザであり得る。概念の特定の実装形態および関連する説明については、前述の実施形態における関連する説明を参照されたい。

このように、本出願のこの実施形態において提供されるソフトウェア完全性保護方法によれば、信頼できるデュアル署名メカニズムをソフトウェアパッケージに提供し、その後のソフトウェア完全性検証のためのデュアルデータベースも提供するために、ソフトウェアパッケージは製造業者によって提供された鍵に基づいて署名できるだけでなく、ソフトウェアパッケージはユーザによって提供された鍵に基づいて署名することもでき、したがって、ユーザは、製造業者を完全に信頼して依存する必要がなくなる。これにより、ユーザの信頼の問題が解決し、それによってデバイスを使用するユーザエクスペリエンスが向上する。

図２に示される前述の実施形態に従って、第２のソフトウェアパッケージに対してデュアル署名動作が実行された後、そして以下の図３に従って、ソフトウェアパッケージに対してソフトウェア完全性検証が実行される前に、一方では、第１の公開鍵および第２の公開鍵は第２のデバイスのＳｏＣに記憶され得、他方では、第２のデバイスは、デュアル署名検証許可を有するデュアル署名検証デバイスのリストを記憶する。

第２の公開鍵は、第２のデバイスが製造されるときに第２のデバイスのＳｏＣに記憶される公開鍵であり得る。さらに、第２のデバイスを配信する前に、第１の公開鍵、デュアルルートイネーブルビット、およびスイッチングイネーブルビットを記憶するためのフィールドセグメントがＳｏＣにおいて予約され得る。第１の公開鍵は、第２のデバイスが製造されるとき、または第２のデバイスが使用されるときに、製造業者署名システムを使用することによって、ユーザ署名システムによって第２のデバイスに送信され得、第２のデバイスのＳｏＣに記憶される。セキュリティを向上させるために、ユーザ署名システムまたは製造業者署名システムは、代替で、第１の公開鍵を含むファイルに対して署名動作を実行し得、次いで、そのファイルを第２のデバイスに送信し、第２のデバイスは、署名の検証が成功した後にのみ第１の公開鍵を記憶することが理解されよう。

第２のデバイスがデュアル署名検証許可を有し、デュアルルートイネーブルビットのフィールドセグメントが第２のデバイスのＳｏＣにおいて予約されている場合、第２のソフトウェアパッケージがロードされる前に、第２のソフトウェアパッケージに対してデュアル署名検証を実行することを示すために、デュアルルートイネーブルビットの値は有効であることが理解されよう。第２のデバイスがユーザ署名検証許可を有し、スイッチングイネーブルビットのフィールドセグメントは、第２のデバイスのＳｏＣにおいてさらに予約され、スイッチングイネーブルビットの優先度がデュアルルートイネーブルビットの優先度よりも高く設定されている場合、第２のソフトウェアパッケージがロードされる前にユーザ鍵を使用することによって第２のソフトウェアパッケージに対して署名検証を実行することを示すために、スイッチングイネーブルビットの値は有効である。デュアルルートイネーブルビットとスイッチングイネーブルビットのフィールドセグメントは、第２のデバイスの配信時に予約されており、ビットの値は、第２のデバイスが製造または使用されるときに構成され得る。言い換えれば、ユーザは、要件に基づいて、第２のデバイスによってソフトウェア完全性検証を実行する方法を柔軟に構成し得る。

ソフトウェア製造業者（またはデバイス製造業者）の場合、デュアルルートイネーブルビット（または、スイッチングイネーブルビット）および第１の公開鍵が同じファイルに含まれている場合があり、第２のデバイスに対応する署名システム（たとえば、ＣＡサーバ）は、ファイルに対して署名動作を実行し、次いで、ファイルを第２のデバイスに送信する。この場合、第１の公開鍵とデュアルルートイネーブルビットの値（または、スイッチングイネーブルビットの値）をファイルに記憶する前に、第２のデバイスは、ファイルの署名の検証に成功する必要があるだけでなく、第２のデバイスに対してデュアル署名検証許可が有効になっているかどうかを決定する必要もある。

第２のデバイスに対してデュアル署名検証許可が有効になっているかどうかを決定するために、デュアル署名検証デバイスリストが使用され得る。デュアル署名検証デバイスリストは、現在デュアル署名検証を実行することを許可されているデバイスを示すために使用され、デュアル署名検証を実行することを許可されている各デバイスの識別子を含み得る。具体的には、ソフトウェア製造業者は、デュアル署名検証を実行することを現在許可されているすべてのデバイスを収集することと、これらのデバイスの識別子に基づいてデュアル署名検証デバイスリストを生成することと、署名動作を実行するために、第２のデバイスに対応する署名システムにデュアル署名検証デバイスリストを送信することと、署名されたデュアル署名検証デバイスリストを取得することとを行うことができる。

特定の実装形態中に、第２のデバイスがデュアル署名検証機能を有効にする必要がある場合、第２のデバイスが第１の公開鍵とデュアルルートイネーブルビット（または、スイッチングイネーブルビット）を含むファイルを第２のデバイスに対応する署名システムからダウンロードする前に、またはダウンロードするときに、代替で、第２のデバイスは、第２のデバイスに対応する署名システムから署名されたデュアル署名検証デバイスリストをダウンロードし得る。一例では、第２のデバイスの中央処理装置（英語：ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、略してＣＰＵ）は、デュアル署名検証デバイスリストの署名を検証し得る。署名検証が成功した後、ＣＰＵは、第２のデバイスの識別子がデュアル署名検証デバイスリストにあるかどうかをチェックし、第２のデバイスのデバイス識別子は第２のデバイスのＳｏＣに記憶される。場合によっては、第２のデバイスのデバイス識別子がデュアル署名検証デバイスリストに属している場合、第２のデバイスがデュアル署名検証許可を有効にすることを許可されたデバイスであると決定されてよく、ＣＰＵはデュアル署名検証メカニズムを有効にして、第１の公開鍵とデュアルルートイネーブルビット（または、スイッチングイネーブルビット）を含むファイルを第２のデバイスのセキュリティハードウェアエンジンに送信し得、セキュリティハードウェアエンジンがファイルに対して署名検証を実行し、ファイルに基づいて第２のデバイスを構成できるようにする。別の場合では、第２のデバイスのデバイス識別子がデュアル署名検証デバイスリストに属していない場合、第２のデバイスがデュアル署名検証許可を有効にすることを許可されていないと決定され得る。この場合、第１の公開鍵とデュアルルートイネーブルビット（または、スイッチングイネーブルビット）を含むファイルのダウンロードが終了されてもよく、またはファイルに基づく第２のデバイスの構成が終了される。別の例では、デュアル署名検証デバイスリストの署名の検証、第２のデバイスの識別子がデュアル署名検証デバイスリストにあるかどうかのチェック、およびデュアル署名検証メカニズムの有効化などの前述の動作はすべて、第２のデバイスのセキュリティハードウェアエンジンによって実行され得る。すなわち、セキュリティハードウェアエンジンが、第２のデバイスがデュアル署名検証許可を有効にすることを許可されていると決定した場合、セキュリティハードウェアエンジンは、デュアル署名検証メカニズムを有効にすることと、第１の公開鍵およびデュアルルートイネーブルビット（またはスイッチングイネーブルビット）を含む受信ファイルに対して署名検証を実行することと、ファイルに基づいて第２のデバイスを構成することとを行い得る。

図３に示される実施形態に従って、第２のソフトウェアパッケージに対してデュアル署名動作を実行することによって第３のソフトウェアパッケージが取得された後、第３のソフトウェアパッケージは第２のデバイスにダウンロードされ、第２のソフトウェアパッケージをロードする前に、第２のデバイスは、ロードされたソフトウェアが信頼でき、安全であることを保証するために、図５に示される以下の実施形態に従ってソフトウェア完全性検証を実行し得ることが理解されよう。

図５は、本出願の実施形態による、ソフトウェア完全性検証方法の概略フローチャートである。本方法は、第２のデバイス、たとえば、図１に示される前述のシナリオにおけるデバイス１００に適用され、それは、具体的には、デバイス１００におけるＢｏｏｔＲＯＭ１１１であり得る。本方法は、たとえば、以下のステップ５０１およびステップ５０２を含み得る。

ステップ５０１：第２のデバイスは第３のソフトウェアパッケージを取得し、第３のソフトウェアパッケージは、第１の署名、第２の署名、および第２のソフトウェアパッケージを含む。

ステップ５０２：第２のデバイスは、検証結果を取得するために、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ第１の署名と第２の署名を検証し、第１の公開鍵はファーストパーティによって制御され、第２の公開鍵はセカンドパーティによって制御される。

場合によっては、ファーストパーティは第２のソフトウェアパッケージのユーザであり得、セカンドパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局である。別の場合では、代替で、ファーストパーティは第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局であり得、セカンドパーティは第２のソフトウェアパッケージのユーザである。

ファーストパーティが第２のソフトウェアパッケージのユーザであり、セカンドパーティが第２のソフトウェアパッケージの製造業者またはサードパーティのデジタル認証局である例が使用されることが理解されよう。第１の署名は、第１の秘密鍵を使用することによって第２のソフトウェアパッケージに対して署名動作を実行することによって取得され得、第１の署名および第２のソフトウェアパッケージは、第１のソフトウェアパッケージに含まれる。第２の署名は、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作を実行することによって取得され得る。第１の秘密鍵は第１の公開鍵と一致し、第２の秘密鍵は第２の公開鍵と一致する。

ステップ５０２の場合、一例では、デュアル署名検証メカニズムが使用される場合、第２のデバイスは、信頼できるストレージ領域（たとえば、ＯＴＰ）から第１の公開鍵および第２の公開鍵を取得し、第１の公開鍵と第２の公開鍵に基づいて、第３のソフトウェアパッケージの第１の署名と第２の署名をそれぞれ検証する。別の例では、ユーザ署名検証メカニズムが使用される場合、第２のデバイスは、信頼できるストレージ領域（たとえば、ＯＴＰ）から第１の公開鍵を取得し、第１の公開鍵に基づいて第３のソフトウェアパッケージの第１の署名を検証し得る。

デュアルルートイネーブルビットおよび／またはスイッチングイネーブルビットは、第２のデバイスのＳｏＣにおいてさらに構成され得、デュアルルートイネーブルビットおよび／またはスイッチングイネーブルビットの複数の値／１つの値は、ソフトウェア完全性検証に使用する必要がある検証メカニズムを示すために使用されることが理解されよう。デュアルルートイネーブルビットおよび／またはスイッチングイネーブルビットの複数の値／１つの値は、一度記憶すると修正することはできない。たとえば、デュアルルートイネーブルビットおよび／またはスイッチングイネーブルビットの複数の値／１つの値は、ＳｏＣのｅＦｕｓｅにおいて焼き付けられ得る。さらに、デュアルルートイネーブルビットとスイッチングイネーブルビットの値が同時に焼き付けられ、２つのビットの値が両方とも有効である場合、スイッチングイネーブルビットの優先度は、デュアルルートイネーブルビットの優先度よりも高くなるようにさらに構成され得、すなわち、スイッチングイネーブルビットが有効である場合に対応するユーザ署名検証メカニズムが使用される。

一例では、第２のデバイスがデュアルルートイネーブルビットのみを記憶し、デュアルルートイネーブルビットが有効である場合、または、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、たとえば、ステップ５０２は以下を含み得る。Ｓ１１：第２のデバイスは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証し、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される。Ｓ１２：第２のデバイスは、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証し、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される。Ｓ１３：第２のデバイスは、第１の署名検証結果および第２の署名検証結果に基づいて検証結果を生成し、検証結果は、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用される。場合によっては、第１の署名検証結果が第１の署名が有効であることを表し、第２の署名検証結果が第２の署名が有効であることを表す場合、検証結果は第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。別の場合では、第１の署名検証結果が第１の署名が無効であることを表す、および／または第２の署名検証結果が第２の署名が無効であることを表す場合、検証結果は第２のソフトウェアパッケージに対する完全性検証が失敗したことを表す。

別の例では、第２のデバイスがスイッチングイネーブルビットを記憶し、スイッチングイネーブルビットが有効である場合、第２のデバイスがデュアルルートイネーブルビットを記憶するかどうか、およびデュアルルートイネーブルビットが有効であるかどうかに関係なく、たとえば、ステップ５０２は、以下を含み得る。Ｓ２１：第２のデバイスは、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証し、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される。Ｓ２２：第２のデバイスは、第１の署名検証結果に基づいて検証結果を生成し、検証結果は、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用される。場合によっては、第１の署名検証結果が第１の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。別の場合では、第１の署名検証結果が第１の署名が無効であることを表す場合、検証結果は第２のソフトウェアパッケージに対する完全性検証が失敗したことを表す。

さらに別の例では、第２のデバイスがデュアルルートイネーブルビットまたはスイッチングイネーブルビットを記憶しない場合、または第２のデバイスにおけるデュアルルートイネーブルビットおよびスイッチングイネーブルビットが両方とも無効である場合、たとえば、ステップ５０２は以下を含み得る。Ｓ３１：第２のデバイスは、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証し、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される。Ｓ３２：第２のデバイスは、第２の署名検証結果に基づいて検証結果を生成し、検証結果は、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用される。場合によっては、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す。別の場合では、第２の署名検証結果が第２の署名が無効であることを表す場合、検証結果は第２のソフトウェアパッケージに対する完全性検証が失敗したことを表す。この実施形態において使用される署名検証メカニズムは、製造業者署名検証メカニズム（シングルルート署名検証メカニズムとも呼ばれることがある）と呼ばれることがあることに留意されたい。

検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したことを表す場合、第２のデバイスが第２のソフトウェアパッケージをロードし得ることが理解され得る。複数のｂｏｏｔを含むソフトウェアパッケージの場合、ソフトウェアパッケージにおけるｂｏｏｔは、本出願のこの実施形態における方法によるロードシーケンスに基づいて順次検証される。あるレベルのｂｏｏｔにおけるソフトウェア完全性検証が成功したと決定されると、このレベルでのｂｏｏｔがロードされる。ソフトウェア完全性検証は、特定のレベルのｂｏｏｔにおけるソフトウェア完全性検証が失敗するか、すべてのｂｏｏｔがロードされることを検証結果が表すまで、このレベルにおけるｂｏｏｔを使用することによって次のレベルのｂｏｏｔにおいて実行され続ける。

署名動作の後、複数のｂｏｏｔを含むソフトウェアパッケージは、ｂｏｏｔの署名およびｂｏｏｔ内のコードセグメントを含み得、さらに証明書を含み得ることが理解されよう。証明書は、次のレベルのｂｏｏｔを検証するために使用され、すなわち、次のレベルのｂｏｏｔの署名の有効性を検証するための公開鍵が証明書から取得され得る。この場合、図５に示される検証動作において、一例では、ｂｏｏｔ内の証明書とコードセグメントが一緒に署名されている場合、第１のデバイスは、１回の検証を通じて、ｂｏｏｔ内のコードセグメントが有効であり、ｂｏｏｔ内の証明書が有効であると決定し得る。別の例では、ｂｏｏｔ内の証明書とコードセグメントが別々に署名されている場合、第１のデバイスは、代替で、２つの検証を実行し得、すなわち、ｂｏｏｔ内のコードセグメントが有効であるかどうかを決定するために、ＳｏＣは第１にｂｏｏｔの署名１を検証し、次いで、ｂｏｏｔ内のコードセグメントが有効であると決定されると、ｂｏｏｔ内の証明書が有効であるかどうかを決定するために、ｂｏｏｔはｂｏｏｔの署名２を検証し、署名１と署名２は同じであり得る。特定の実装形態については、図７から図９に示される以下の実施形態を参照されたい。このようにして、ｂｏｏｔの証明書に基づいて次のレベルのｂｏｏｔの署名を検証するための信頼できる基盤を提供するために、ソフトウェアパッケージにおける各ｂｏｏｔが有効であるかどうかは、１回の検証または２回の検証を通じて決定され得る。

いくつかの可能な実装形態では、ＳｏＣは、代替で、デジタルダイジェスト技術を使用することによって、第２のソフトウェアパッケージについて計算された第１のダイジェストを記憶し得る。この場合、複数のｂｏｏｔを含む第２のソフトウェアパッケージにおいて、レベル１のｂｏｏｔ以外のｂｏｏｔに対して署名動作が実行され得る。レベル１のｂｏｏｔに対する検証は、以下を含み得る。第１に、第２のデバイスのＳｏＣは、レベル１のｂｏｏｔにおけるコードセグメントのみを取得し、ハッシュアルゴリズムを使用することによって、レベル１のｂｏｏｔにおけるコードセグメントに対応する第２のダイジェストを計算する。次いで、ＳｏＣは、比較を通じて、第１のダイジェストが第２のダイジェストと一致しているかどうかを決定し、第１のダイジェストが第２のダイジェストと一致している場合、レベル１のｂｏｏｔが有効であると決定し、レベル１のｂｏｏｔをロードする。特定の実装形態については、図１０および図１１に示される以下の実施形態を参照されたい。

他のいくつかの可能な実装形態において、第１の署名および第２の署名が、セカンダリ秘密鍵を使用することによって署名動作が実行された後に得られる署名であり、第２のデバイスに事前に記憶されている第１の公開鍵および第２の公開鍵もまたセカンダリ公開鍵である場合、各署名が検証される前に、本出願のこの実施形態は、以下の２つのステップをさらに含む。ステップ１：ｆｌａｓｈメモリから元のルート公開鍵を読み取り、元のルート公開鍵のハッシュ値を計算し、ハッシュ値がプライマリ公開鍵の値と一致しているかどうかを検証し、ハッシュ値がプライマリ公開鍵の値と一致している場合、プライマリ公開鍵が有効であると決定する。ステップ２：証明書を読み取り、プライマリ公開鍵を処理することによって取得したセカンダリ公開鍵を使用することによって証明書に対して署名検証を実行し、署名検証が成功した場合は、証明書に事前に記憶されているセカンダリ公開鍵は有効であると決定し、署名動作は、プライマリ秘密鍵を処理することによって取得されたセカンダリ秘密鍵を使用することによって、証明書に対して実行される。このようにして、第２のデバイスにロードされる第２のソフトウェアパッケージに対してソフトウェア完全性検証を実行できるだけでなく、元のルート秘密鍵が公開される回数を減らすこともでき、それによって、第２のデバイスのセキュリティと信頼性が向上する。さらに、ＳｏＣのストレージスペースも節約することができる。

現在、第２のデバイスの配信前に、第２のデバイスは通常、第２のデバイスのＳｏＣのコードセグメント１における第２の公開鍵に対してアイテムコーディングを実行する。この場合、第２のデバイスの配信および使用中に、デュアル署名検証メカニズムまたはユーザ署名検証メカニズムが必要とされる場合、コードセグメントを修正する必要があり、実装が困難である。第２のデバイスを使用するエクスペリエンスを改善するために、本出願のこの実施形態では、第２の公開鍵はコードセグメントから抽出され、単一のファイル１の形式でコードセグメント２に付加される。すなわち、第２のデバイスの配信前に、ｆｌａｓｈメモリにおけるレイアウトは、たとえば、「ヘッダファイル＋コードセグメント２＋ファイル１」として表され得る。このようにして、第２のデバイスの使用中にデュアル署名検証メカニズムが有効になっている場合、第１の公開鍵を記憶するためにファイル２のみをｆｌａｓｈメモリに個別に追加する必要がある。この場合、ｆｌａｓｈメモリにおけるレイアウトは、たとえば、「ヘッダファイル＋コードセグメント２＋ファイル１＋ファイル２」として表され得る。このようにして、ユーザの署名検証メカニズムにおける変更に起因する作業の困難さが大幅に軽減され、第２のデバイスを使用するユーザエクスペリエンスが向上する。

いくつかの他の可能な実装形態において、ｆｌａｓｈメモリにおけるレイアウト設計に基づいて、図６に示されるように、第２のデバイスの配信前に、第２のデバイスは第２の公開鍵のみを記憶するが、第１の公開鍵および２つのイネーブルビットを記憶するためのフィールドセグメントを予約する。配信後に第２のデバイスが使用される場合、場合によっては、デュアル署名検証メカニズムを使用する必要があるユーザの要求に応じて、第１の公開鍵とデュアルルートイネーブルビットの有効な値を予約された場所に構成され得る。別の場合には、第１の公開鍵とスイッチングイネーブルビットの有効な値が、ユーザ署名検証メカニズムを使用する必要があるユーザの要求に応じて、予約された場所で構成され得る。このようにして、ｆｌａｓｈメモリにおけるレイアウト設計と、第２の公開鍵のみが記憶されており、配信前にユーザが使用できるように他のスペースが予約されている場合の情報を焼き付けるための方法に基づいて、次の問題を解決することができる。ユーザおよび市場の要件が異なるため、製造業者からの配信後に異なるユーザによって異なる第２のデバイスが使用される場合、署名検証メカニズムを変更する必要があるが、アイテムコーディングはコードセグメントにおける第２の公開鍵に対して実行されるため、ＳｏＣにおけるアイテムコーディングは分割される必要がある。その結果、ユーザが署名検証メカニズムを変更することは困難である。これにより、第２のデバイスを使用するユーザエクスペリエンスが向上する。

このようにして、ソフトウェア製造業者（または、デバイス製造業者）とユーザにより提供された鍵を使用することによってソフトウェア完全性保護が実行されるソフトウェアパッケージの場合、ソフトウェア製造業者により提供された鍵に基づいてソフトウェアパッケージに対して署名検証を実行できるだけでなく、ソフトウェア製造業者を完全に信頼および依存することなく、ユーザにより提供された鍵に基づいてソフトウェアパッケージに対して署名検証を実行することもでき、ユーザは、ユーザの信頼の問題を解決するために、使用する署名検証メカニズムを柔軟に決定し得るため、第２のデバイスに対するソフトウェア完全性検証がより柔軟で信頼できるものになる。これにより、第２のデバイスを使用するユーザエクスペリエンスが向上する。

本出願の実施形態をより明確かつより詳細に説明するために、２つの例を使用することによって本出願の実施形態におけるソフトウェア完全性検証プロセスを説明するために第２のデバイスのｂｏｏｔ前のソフトウェア完全性検証を以下の例として使用する。

実施形態１：図７に示されるシナリオを例として使用する。このシナリオでは、第２のデバイス７００は、ＳｏＣ７１０およびｂｏｏｔソフトウェアパッケージを含み、ｂｏｏｔソフトウェアパッケージは、Ｌ１ｂｏｏｔ７２０およびＬ２ｂｏｏｔ７３０を含む。ＳｏＣ７１０は、ＢｏｏｔＲＯＭ７１１を含み、製造業者公開鍵１、ユーザ公開鍵１、デバイス識別子、デュアルルートイネーブルビットの値、およびスイッチングイネーブルビットの値を記憶する。Ｌ１ｂｏｏｔ７２０は、コードセグメント１、製造業者証明書１、ユーザ証明書１、製造業者署名１、およびユーザ署名１を含む。Ｌ２ｂｏｏｔ７３０は、コードセグメント２、製造業者署名２、およびユーザ署名２を含む。

一例では、図７に示される第２のデバイス７００において、デュアルルートイネーブルビットの値は、デュアルルートイネーブルビットが有効であることを示し、スイッチングイネーブルビットの値は、スイッチングイネーブルビットが無効であることを示し、デバイス識別子は、デュアル署名検証デバイスリストに含まれているものとする。各ｂｏｏｔにおける証明書とコードセグメントが別々に署名されている場合、すなわち、製造業者署名１がコードセグメント１に対応する製造業者署名１１と、製造業者証明書１に対応する製造業者署名１２を含む場合、ユーザ署名１は、コードセグメント１に対応するユーザ署名１１と、ユーザ証明書１に対応するユーザ署名１２とを含み、図８Ａおよび図８Ｂに示されるように、本出願のこの実施形態は、具体的には、以下のステップを含む。

ステップ８０１：ＢｏｏｔＲＯＭ７１１は、Ｌ１ｂｏｏｔ７２０におけるヘッダファイルから元の製造業者公開鍵０を読み取り、製造業者公開鍵０のハッシュ値を計算し、製造業者公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵３のハッシュ値と一致しているかどうかを検証し、製造業者公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵３のハッシュ値と一致している場合、製造業者ルート公開鍵３が有効であると決定する。

ステップ８０２：ＢｏｏｔＲＯＭ７１１は、製造業者ルート公開鍵３を使用することによって製造業者ルート証明書１に対して署名検証を実行し、製造業者ルート証明書１における製造業者公開鍵１が有効であると決定する。

製造業者ルート証明書１は、セカンダリルート秘密鍵４を使用することによって実行される署名動作を実行する証明書であり、セカンダリルート秘密鍵４は、プライマリルート秘密鍵５を処理することによって取得されることが理解されよう。製造業者ルート証明書１は、製造業者公開鍵１を含む。ステップ８０２において、製造業者ルート公開鍵３は、対応するセカンダリルート公開鍵４を取得するために第１に処理され得る。製造業者証明書１の署名は、セカンダリルート公開鍵４を使用することによって検証される。セカンダリルート公開鍵４がセカンダリルート秘密鍵４と一致し、製造業者証明書１が改ざんされていない場合、署名検証は成功し、製造業者ルート証明書１が有効であり、証明書における製造業者公開鍵１が有効であることを表す。

ステップ８０３：ＢｏｏｔＲＯＭ７１１は、署名検証結果１を取得するために、製造業者公開鍵１を使用することによって、Ｌ１ｂｏｏｔ７２０内のコードセグメント１における製造業者署名１１を検証する。

ステップ８０４：ＢｏｏｔＲＯＭ７１１は、Ｌ１ｂｏｏｔ７２０内のヘッダファイルから元のユーザ公開鍵０を読み取ることと、ユーザ公開鍵０のハッシュ値を計算することと、ユーザ公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵５のハッシュ値と一致するかどうかを検証することとを行い、ユーザ公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵５のハッシュ値と一致している場合、製造業者ルート公開鍵５が有効であると決定する。

ステップ８０５：ＢｏｏｔＲＯＭ７１１は、ユーザルート公開鍵５を使用することによってユーザルート証明書２に対して署名検証を実行し、ユーザルート証明書２におけるユーザ公開鍵１が有効であると決定する。

ステップ８０６：ＢｏｏｔＲＯＭ７１１は、署名検証結果２を取得するために、ユーザ公開鍵１を使用することによって、Ｌ１ｂｏｏｔ７２０内のコードセグメント１におけるユーザ署名１１を検証する。

ステップ８０４からステップ８０６の関連する説明については、ステップ８０１からステップ８０３を参照することに留意されたい。

ステップ８０４からステップ８０６およびステップ８０１からステップ８０３の実行シーケンスは特に限定されないことに留意されたい。ステップ８０４からステップ８０６は、ステップ８０１からステップ８０３の前に実行され得、ステップ８０１からステップ８０３は、ステップ８０４からステップ８０６の前に実行され得るか、またはステップ８０４からステップ８０６およびステップ８０１からステップ８０３は、同時に実行され得る。

ステップ８０７：ＢｏｏｔＲＯＭ７１１は、署名検証結果３を取得するために、製造業者公開鍵１を使用することによって、Ｌ１ｂｏｏｔ７２０内の製造業者証明書１が有効かどうかを検証する。

ステップ８０８：ＢｏｏｔＲＯＭ７１１は、署名検証結果４を取得するために、ユーザ公開鍵１を使用することによって、Ｌ１ｂｏｏｔ７２０内のユーザ証明書１が有効かどうかを検証する。

ステップ８０９：ＢｏｏｔＲＯＭ７１１は、署名検証結果１から４に基づいて、Ｌ１ｂｏｏｔ７２０のソフトウェア完全性を示すための検証結果１を決定する。検証結果１が、Ｌ１ｂｏｏｔ７２０に対するソフトウェア完全性検証が成功したことを表す場合、以下のステップ８１０からステップ８１６が実行され、または、検証結果１が、Ｌ１ｂｏｏｔ７２０に対するソフトウェア完全性検証が失敗したことを表す場合、ステップ８１７が実行される。

検証結果１は、署名検証結果１から４が、すべて署名検証が成功した状態を示している場合にのみ、Ｌ１ｂｏｏｔ７２０に対するソフトウェア完全性検証が成功したことを表すことができることが理解されよう。検証結果１は、署名検証結果１から４に署名検証が失敗した状態が存在するという条件で、Ｌ１ｂｏｏｔ７２０に対するソフトウェア完全性検証が失敗したことを表す。

ステップ８１０：Ｌ１ｂｏｏｔ７２０をロードする。

ステップ８１１：Ｌ１ｂｏｏｔ７２０は、署名検証結果５を取得するために、製造業者証明書１から製造業者公開鍵２を取得し、製造業者公開鍵２を使用することによって、Ｌ１ｂｏｏｔ７３０内のコードセグメント２における製造業者署名２１を検証する。

ステップ８１２：Ｌ１ｂｏｏｔ７２０は、署名検証結果６を取得するために、ユーザ証明書１からユーザ公開鍵２を取得し、ユーザ公開鍵２を使用することによって、Ｌ１ｂｏｏｔ７３０内のコードセグメント２におけるユーザ署名２１を検証する。

ステップ８１３：Ｌ１ｂｏｏｔ７２０は、署名検証結果７を取得するために、製造業者公開鍵２を使用することによって、Ｌ１ｂｏｏｔ７３０内の製造業者証明書２が有効であるかどうかを検証する。

ステップ８１４：Ｌ１ｂｏｏｔ７２０は、署名検証結果８を取得するために、ユーザ公開鍵２を使用することによって、Ｌ１ｂｏｏｔ７３０内のユーザ証明書２が有効であるかどうかを検証する。

ステップ８１５：Ｌ１ｂｏｏｔ７２０は、署名検証結果５から８に基づいて、Ｌ１ｂｏｏｔ７３０のソフトウェア完全性を示すための検証結果２を決定する。検証結果２がＬ１ｂｏｏｔ７３０に対するソフトウェア完全性検証が成功したことを表す場合、以下のステップ８１６が実行され、または、検証結果２がＬ１ｂｏｏｔ７３０に対するソフトウェア完全性検証が失敗したことを表す場合、ステップ８１７が実行される。

検証結果２は、署名検証結果５から８がすべて、署名検証が成功した状態を示している場合にのみ、Ｌ１ｂｏｏｔ７３０に対するソフトウェア完全性検証が成功したことを表すことができることが理解されよう。検証結果２は、署名検証結果５から８において署名検証が失敗した状態が存在するという条件で、Ｌ１ｂｏｏｔ７３０に対するソフトウェア完全性検証が失敗したことを表す。

ステップ８１６：Ｌ１ｂｏｏｔ７３０をロードし、第２のデバイス７００のｂｏｏｔを完了する。

ステップ８１７：ｂｏｏｔソフトウェアパッケージに対するソフトウェア完全性検証を終了し、第２のデバイス７００の現在のｂｏｏｔを終了する。

このようにして、第２のデバイスのｂｏｏｔ時にロードされるソフトウェアが安全で信頼できることを保証するために、ｂｏｏｔソフトウェアパッケージに対するソフトウェア完全性検証は、デュアル署名検証メカニズムを使用することによって完了し、それによって、ユーザが第２のデバイスを使用するための信頼できる環境を提供する。

別の例では、図７に示される第２のデバイス７００において、デュアルルートイネーブルビットの値は、デュアルルートイネーブルビットが有効であることを示し、スイッチングイネーブルビットの値は、スイッチングイネーブルビットも有効であることを示し、デバイス識別子は、デュアル署名検証デバイスリストに含まれているものとする。各ｂｏｏｔにおける証明書とコードセグメントが均一に署名されている場合、すなわち、製造業者署名１の署名検証結果が、コードセグメント１と製造業者証明書１の両方の有効性を表し得る場合、図９に示されるように、本出願のこの実施形態は、具体的には、以下のステップを含む。

ステップ９０１：ＢｏｏｔＲＯＭ７１１は、Ｌ１ｂｏｏｔ７２０内のヘッダファイルから元のユーザ公開鍵０を読み取ることと、ユーザ公開鍵０のハッシュ値を計算することと、ユーザ公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵５のハッシュ値と一致するかどうかを検証することとを行い、ユーザ公開鍵０のハッシュ値がＢｏｏｔＲＯＭ７１１に記憶されている製造業者ルート公開鍵５のハッシュ値と一致している場合、製造業者ルート公開鍵５が有効であると決定する。

ステップ９０２：ＢｏｏｔＲＯＭ７１１は、ユーザルート公開鍵５を使用することによってユーザルート証明書２に対して署名検証を実行し、ユーザルート証明書２におけるユーザ公開鍵１が有効であると決定する。

ステップ９０３：ＢｏｏｔＲＯＭ７１１は、署名検証結果２を取得するために、ユーザ公開鍵１を使用することによって、Ｌ１ｂｏｏｔ７２０におけるユーザ署名１を検証し、ユーザ署名１は、コードセグメント１およびユーザ証明書１に対応する。

ステップ９０４：署名検証結果２が、Ｌ１ｂｏｏｔ７２０に対するソフトウェア完全性検証が成功したことを表す場合、Ｌ１ｂｏｏｔ７２０をロードする。

ステップ９０５：Ｌ１ｂｏｏｔ７２０は、署名検証結果４を取得するために、ユーザ証明書１からユーザ公開鍵２を取得し、ユーザ公開鍵２を使用することによってＬ１ｂｏｏｔ７３０におけるユーザ署名２を検証し、ユーザ署名２は、コードセグメント２およびユーザ証明書２に対応する。

ステップ９０６：署名検証結果４が、Ｌ１ｂｏｏｔ７３０に対するソフトウェア完全性検証が成功したことを表す場合、Ｌ１ｂｏｏｔ７３０をロードする。

このようにして、第２のデバイスのｂｏｏｔ時にロードされるソフトウェアが安全で信頼できることを保証するために、ｂｏｏｔソフトウェアパッケージに対するソフトウェア完全性検証は、ユーザ署名検証メカニズムを使用することによって、またユーザによって提供された鍵を完全に使用することによって完了し、それによって、ユーザが第２のデバイスを使用するための信頼できる環境を提供する。

実施形態２：図１０に示されるシナリオを例として使用する。このシナリオでは、第２のデバイス１０００は、ＳｏＣ１０１０およびｂｏｏｔソフトウェアパッケージを含み、ｂｏｏｔソフトウェアパッケージは、Ｌ１ｂｏｏｔ１０２０およびＬ２ｂｏｏｔ１０３０を含む。ＳｏＣ１０１０は、ＢｏｏｔＲＯＭ１０１１を含み、ダイジェスト１、デバイス識別子、デュアルルートイネーブルビットの値、およびスイッチングイネーブルビットの値を記憶する。Ｌ１ｂｏｏｔ１０２０は、コードセグメント１、製造業者証明書１、およびユーザ証明書１を含む。Ｌ２ｂｏｏｔ１０３０は、コードセグメント２、製造業者署名２、およびユーザ署名２を含む。

特定の実装形態の間、図１０に示される第２のデバイス１０００において、デュアルルートイネーブルビットの値は、デュアルルートイネーブルビットが有効であることを示し、スイッチングイネーブルビットの値は、スイッチングイネーブルビットが無効であることを示し、デバイス識別子は、デュアル署名検証デバイスリストに含まれているものとする。各ｂｏｏｔにおける証明書とコードセグメントが均一に署名されている場合、すなわち、製造業者署名２の検証結果が、コードセグメント２と製造業者証明書２の両方の有効性を表し得る場合、図１１に示されるように、本出願のこの実施形態は、具体的には、以下のステップを含む。

ステップ１１０１：ＢｏｏｔＲＯＭ１０１１は、Ｌ１ｂｏｏｔ１０２０からコードセグメント１を読み取り、ハッシュアルゴリズムを使用することによってコードセグメント１のダイジェスト２を計算する。

ステップ１１０２：ＢｏｏｔＲＯＭ１０１１は、検証結果１を取得するために、ダイジェスト１とダイジェスト２を比較する。

ダイジェスト１がダイジェスト２と一致する場合、検証結果１は、Ｌ１ｂｏｏｔ１０２０に対するソフトウェア完全性検証が成功したことを表すために使用され、または、ダイジェスト１がダイジェスト２と一致しない場合、検証結果１は、Ｌ１ｂｏｏｔ１０２０に対するソフトウェア完全性検証が失敗したことを表すために使用されることが理解されよう。

ステップ１１０３：検証結果１が、Ｌ１ｂｏｏｔ１０２０に対するソフトウェア完全性検証が成功したことを表す場合、Ｌ１ｂｏｏｔ１０２０をロードする。

ステップ１１０４：Ｌ１ｂｏｏｔ１０２０は、署名検証結果４を取得するために、ユーザ証明書１からユーザ公開鍵２を取得し、ユーザ公開鍵２を使用することによってＬ１ｂｏｏｔ１０３０におけるユーザ署名２を検証し、ユーザ署名２は、コードセグメント２およびユーザ証明書２に対応する。

ステップ１１０５：Ｌ１ｂｏｏｔ１０２０は、署名検証結果６を取得するために、製造業者証明書１から製造業者公開鍵２を取得し、製造業者公開鍵２を使用することによってＬ１ｂｏｏｔ１０３０における製造業者署名２を検証し、製造業者署名２は、コードセグメント２および製造業者証明書２に対応する。

ステップ１１０６：署名検証結果４および署名検証結果６がそれぞれ、Ｌ１ｂｏｏｔ１０３０に対するソフトウェア完全性検証が成功したことを表す場合、Ｌ１ｂｏｏｔ１０３０をロードする。

このようにして、ダイジェストのみがＳｏＣに記憶され、それによって、第２のデバイスのハードウェアストレージリソースが節約される。さらに、第２のデバイスのｂｏｏｔ時にロードされるソフトウェアのセキュリティを保証するために、ｂｏｏｔソフトウェアパッケージに対するソフトウェア完全性検証は依然として、デュアル署名検証メカニズムを使用することによってソフトウェアパッケージ内で完了し、それによって、ユーザが第２のデバイスを使用するための信頼できる環境を提供する。

それに応じて、本出願の実施形態は、ソフトウェア完全性保護装置１２００をさらに提供する。図１２に示されるように、装置１２００は第１のデバイスにおいて使用され、装置１２００は、取得ユニット１２０１および署名ユニット１２０２を含む。

取得ユニット１２０１は、第１のソフトウェアパッケージを取得するように構成され、第１のソフトウェアパッケージは、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのためにファーストパーティによって作成された第１の署名を含む。署名ユニット１２０２は、第２の署名を含む第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって第１のソフトウェアパッケージに対して署名動作を実行するように構成され、第１の秘密鍵は、ファーストパーティによって制御され、第２の秘密鍵はセカンドパーティによって制御される。

装置１２００は、図２に示される実施形態において関連する動作を実行するように構成されることに留意されたい。装置１２００の特定の実装形態および達成された効果については、図２に示される実施形態における関連する説明を参照されたい。詳細については、本明細書では再度説明しない。

さらに、本出願の実施形態は、ソフトウェア完全性検証装置１３００をさらに提供する。図１３に示されるように、装置１３００は第２のデバイスにおいて使用され、装置１３００は、取得ユニット１３０１および検証ユニット１３０２を含む。

取得ユニット１３０１は第１のソフトウェアパッケージを取得するように構成され、第１のソフトウェアパッケージは、第１の署名、第２の署名、および第２のソフトウェアパッケージを含む。検証ユニット１３０２は、検証結果を取得するために、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ第１の署名と第２の署名を検証するように構成され、第１の公開鍵はファーストパーティによって制御され、第２の公開鍵はセカンドパーティによって制御される。

別の可能な実装形態では、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、検証ユニット１３０２は、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証するように構成され、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される、第１の検証サブユニットと、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証するように構成され、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される、第２の検証サブユニットと、第１の署名検証結果および第２の署名検証結果に基づいて検証結果を生成するように構成された第１の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表し、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第１の生成サブユニットとを含む。あるいは、第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、検証ユニット１３０２は、第１の署名検証結果を取得するために、事前に記憶された第１の公開鍵に基づいて第１の署名を検証するように構成され、第１の署名検証結果は、第１の署名が有効であるかどうかを表すために使用される、第３の検証サブユニットと、第１の署名検証結果に基づいて検証結果を生成するように構成された第２の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第１の署名検証結果が第１の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第２の生成サブユニットとを含む。あるいは、第２のデバイスにおけるスイッチングイネーブルビットが無効であり、第１のデバイスにおけるデュアルルートイネーブルビットが無効である場合、検証ユニット１３０２は、第２の署名検証結果を取得するために、事前に記憶された第２の公開鍵に基づいて第２の署名を検証するように構成され、第２の署名検証結果は、第２の署名が有効であるかどうかを表すために使用される、第４の検証サブユニットと、第２の署名検証結果に基づいて検証結果を生成するように構成された第３の生成サブユニットであって、検証結果が、第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、第２の署名検証結果が第２の署名は有効であることを表す場合、検証結果は、第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、第３の生成サブユニットとを含む。

装置１３００は、図５に示される実施形態において関連する動作を実行するように構成されることに留意されたい。装置１３００の特定の実装形態および達成された効果については、図５に示される実施形態における関連する説明を参照されたい。詳細については、本明細書では再度説明しない。

さらに、本出願の実施形態は、デバイス１４００をさらに提供する。図１４に示されるように、デバイス１４００は、メモリ１４０１およびプロセッサ１４０２を含む。メモリ１４０１は、プログラムコードを記憶するように構成されている。プロセッサ１４０２は、デバイス１４００が、図２または図５に示される前述の実施形態における実装形態のうちのいずれか１つにおける方法を実行できるように、プログラムコードまたは命令を実行するように構成されている。

さらに、本出願の一実施形態は、コンピュータ可読ストレージ媒体をさらに提供する。コンピュータ可読ストレージ媒体は、プログラムコードまたは命令を記憶する。プログラムコードまたは命令がコンピュータ上で実行されるとき、コンピュータは、図２または図５に示される前述の実施形態における実装形態のうちのいずれか１つにおける方法を実行することが可能になる。

さらに、本出願の実施形態は、ネットワークシステム１５００をさらに提供する。図１５に示されるように、ネットワークシステム１５００は、ソフトウェア完全性保護装置１２００と、ソフトウェア完全性検証装置１３００とを含む。

本出願の実施形態において言及される「第１の公開鍵」および「第１の秘密鍵」などの用語における「第１」は、単に名前識別子として使用され、順番における第１を表すものではない。このルールは「第２」などにも適用される。

実装形態の前述の説明から、当業者は、前述の実施形態の方法におけるステップのうちのいくつかまたはすべてが、ソフトウェアおよびユニバーサルハードウェアプラットフォームを使用することによって実装され得ることを明確に理解するであろう。このような理解に基づいて、本出願の技術的解決策は、ソフトウェア製品の形式で実装され得る。コンピュータソフトウェア製品は、ストレージ媒体、たとえば、読み取り専用メモリ（英語：ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）／ＲＡＭ、磁気ディスク、または光ディスクに記憶され得、コンピュータデバイス（パーソナルコンピュータ、サーバ、またはルータなどのネットワーク通信デバイスであり得る）に、本出願の実施形態または実施形態のいくつかの部分に記載されている方法を実行するように指示するためのいくつかのプログラムコード（ｓｅｖｅｒａｌｐｉｅｃｅｓｏｆｐｒｏｇｒａｍｃｏｄｅ）またはいくつかの命令を含む。

本明細書の実施形態はすべて、実施形態における同じまたは類似の部分について漸進的に説明され、これらの実施形態を参照し、各実施形態は、他の実施形態との違いに焦点を合わせている。特に、装置およびデバイスの実施形態は、基本的に方法の実施形態と類似しており、したがって、簡単に説明されている。関連部品については、方法の実施形態における部分的な説明を参照されたい。説明したデバイスおよび装置の実施形態は、単なる例である。別個の部品として説明されるモジュールは、物理的に別個である場合も、別個ではない場合もあり、モジュールとして表示される部品は、物理モジュールである場合も、そうではない場合もあり、１つの位置に配置されていてもよく、複数のネットワークユニットに分散されていてもよい。モジュールのうちのいくつかまたはすべては、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択され得る。当業者は、創造的な努力なしに実施形態を理解し、実装し得る。

前述の説明は、本出願の例示的な実装形態にすぎないが、本出願の保護範囲を限定することが意図されるものではない。当業者は、本出願から逸脱することなく、いくつかの改良および研磨を行うことができ、改良および研磨は、本出願の保護範囲に含まれることに留意されたい。

０製造業者公開鍵
０ユーザ公開鍵
１製造業者公開鍵
１秘密鍵
１ユーザ公開鍵
１コードセグメント
１製造業者証明書
１ユーザ証明書
１製造業者署名
１ユーザ署名
１ダイジェスト
１検証結果
１デバイス
１署名システム
１署名検証結果
１署名
１単一のファイル
１製造業者ルート証明書
２秘密鍵
２コードセグメント
２製造業者署名
２ユーザ署名
２ダイジェスト
２署名システム
２署名検証結果
２署名
２ユーザルート証明書
２製造業者公開鍵
２ユーザ公開鍵
２製造業者証明書
２ユーザ証明書
２検証結果
３製造業者ルート公開鍵
３署名検証結果
４セカンダリルート秘密鍵
４セカンダリルート公開鍵
４署名検証結果
５プライマリルート秘密鍵
５製造業者ルート公開鍵
５ユーザルート公開鍵
５署名検証結果
６署名検証結果
７署名検証結果
８署名検証結果
１１署名
１１製造業者署名
１１ユーザ署名
１１秘密鍵
１２署名
１２製造業者署名
１２ユーザ署名
１３署名
１２秘密鍵
１２公開鍵
１３秘密鍵
１３公開鍵
２１署名
２１秘密鍵
２１公開鍵
２１製造業者署名
２１ユーザ署名
２２署名
２２秘密鍵
２２公開鍵
２３署名
２３秘密鍵
２３公開鍵
１００デバイス
１１０ＳｏＣ
１１１ＢｏｏｔＲＯＭ
２００ソフトウェアパッケージ
２００’ ソフトウェアパッケージ
３００製造業者署名システム
４００ユーザ署名システム
７００第２のデバイス
７１０ＳｏＣ
７１１ＢｏｏｔＲＯＭ
７２０Ｌ１ｂｏｏｔ
７３０Ｌ２ｂｏｏｔ
７３０Ｌ１ｂｏｏｔ
１０００第２のデバイス
１０１０ＳｏＣ
１０１１ＢｏｏｔＲＯＭ
１０２０Ｌ１ｂｏｏｔ
１０３０Ｌ２ｂｏｏｔ
１０３０Ｌ１ｂｏｏｔ
１２００ソフトウェア完全性保護装置
１２０１取得ユニット
１２０２署名ユニット
１３００ソフトウェア完全性検証装置
１３０１取得ユニット
１３０２検証ユニット
１４００デバイス
１４０１メモリ
１４０２プロセッサ
１５００ネットワークシステム

Claims

第１のデバイスによって、第１のソフトウェアパッケージを取得するステップであって、前記第１のソフトウェアパッケージが、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのためにファーストパーティによって作成された第１の署名を備える、ステップであって、前記第１の秘密鍵が、前記ファーストパーティによって制御され、前記ファーストパーティが前記第２のソフトウェアパッケージのユーザであり、前記第１のデバイスが、前記第２のソフトウェアパッケージに対応する製造業者署名システムである、ステップと、
前記第１のデバイスによって、第２の署名を備える第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって前記第１のソフトウェアパッケージに対して署名動作を実行するステップであって、前記第２の秘密鍵がセカンドパーティによって制御され、前記セカンドパーティが前記第２のソフトウェアパッケージの製造業者もしくはサードパーティのデジタル認証局である、ステップと
を備える、ソフトウェア完全性保護方法。
前記第１のデバイスによって、前記第３のソフトウェアパッケージを第２のデバイスに送信するステップをさらに備える、請求項１に記載のソフトウェア完全性保護方法。
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、前記第１の署名および前記第２の署名が両方とも有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、前記第１の署名が有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、前記第２の署名が有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、請求項２に記載のソフトウェア完全性保護方法。
第２のデバイスによって、第１のソフトウェアパッケージを取得するステップであって、前記第１のソフトウェアパッケージが、第１の署名、第２の署名、および第２のソフトウェアパッケージを備える、ステップであって、前記第１の署名が、ファーストパーティによって、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのために作成され、前記第１の秘密鍵が、前記ファーストパーティによって制御され、前記ファーストパーティが前記第２のソフトウェアパッケージのユーザであり、第１のデバイスが、前記第２のソフトウェアパッケージに対応する製造業者署名システムである、ステップと、
検証結果を取得するために、前記第２のデバイスによって、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ前記第１の署名と前記第２の署名を検証するステップであって、前記第１の公開鍵が前記ファーストパーティによって制御され、前記第２の公開鍵がセカンドパーティによって制御され、前記セカンドパーティが前記第２のソフトウェアパッケージの製造業者もしくはサードパーティのデジタル認証局である、ステップと
を備える、ソフトウェア完全性検証方法。
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、検証結果を取得するために、前記第２のデバイスによって、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ前記第１の署名と前記第２の署名を検証する前記ステップが、
前記第２のデバイスによって、第１の署名検証結果を取得するために、前記事前に記憶された第１の公開鍵に基づいて前記第１の署名を検証するステップであって、前記第１の署名検証結果が、前記第１の署名が有効であるかどうかを表すために使用される、ステップと、
前記第２のデバイスによって、第２の署名検証結果を取得するために、前記事前に記憶された第２の公開鍵に基づいて前記第２の署名を検証するステップであって、前記第２の署名検証結果が、前記第２の署名が有効であるかどうかを表すために使用される、ステップと、
前記第２のデバイスによって、前記第１の署名検証結果および前記第２の署名検証結果に基づいて前記検証結果を生成するステップであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第１の署名検証結果が前記第１の署名は有効であることを表し、前記第２の署名検証結果が前記第２の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、ステップと
を備え、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、検証結果を取得するために、前記第２のデバイスによって、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ前記第１の署名と前記第２の署名を検証する前記ステップが、
前記第２のデバイスによって、第１の署名検証結果を取得するために、前記事前に記憶された第１の公開鍵に基づいて前記第１の署名を検証するステップであって、前記第１の署名検証結果が、前記第１の署名が有効であるかどうかを表すために使用される、ステップと、
前記第２のデバイスによって、前記第１の署名検証結果に基づいて前記検証結果を生成するステップであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第１の署名検証結果が前記第１の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、ステップと
を備え、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、検証結果を取得するために、前記第２のデバイスによって、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ前記第１の署名と前記第２の署名を検証する前記ステップが、
前記第２のデバイスによって、第２の署名検証結果を取得するために、前記事前に記憶された第２の公開鍵に基づいて前記第２の署名を検証するステップであって、前記第２の署名検証結果が、前記第２の署名が有効であるかどうかを表すために使用される、ステップと、
前記第２のデバイスによって、前記第２の署名検証結果に基づいて前記検証結果を生成するステップであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第２の署名検証結果が前記第２の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、ステップと
を備える、請求項４に記載のソフトウェア完全性検証方法。
前記第１の署名と前記第２のソフトウェアパッケージが、第３のソフトウェアパッケージに備えられており、前記第２の署名が、前記セカンドパーティによって制御される第２の秘密鍵を使用することによって前記第３のソフトウェアパッケージに対して署名動作を実行することによって取得され、前記第１の秘密鍵が前記第１の公開鍵と一致し、前記第２の秘密鍵が前記第２の公開鍵と一致する、請求項４または５に記載のソフトウェア完全性検証方法。
検証方法。
ソフトウェア完全性保護装置であって、
第１のソフトウェアパッケージを取得するように構成された取得ユニットであって、前記第１のソフトウェアパッケージが、第１の秘密鍵を使用することによって第２のソフトウェアパッケージのためにファーストパーティによって作成された第１の署名を備える、取得ユニットであって、前記第１の秘密鍵が、前記ファーストパーティによって制御され、前記ファーストパーティが前記第２のソフトウェアパッケージのユーザであり、第１のデバイスが、前記第２のソフトウェアパッケージに対応する製造業者署名システムである、取得ユニットと、
第２の署名を備える第３のソフトウェアパッケージを取得するために、第２の秘密鍵を使用することによって前記第１のソフトウェアパッケージに対して署名動作を実行するように構成された署名ユニットであって、前記第２の秘密鍵がセカンドパーティによって制御され、前記セカンドパーティが前記第２のソフトウェアパッケージの製造業者もしくはサードパーティのデジタル認証局である、署名ユニットと
を備え、前記第１のデバイスに適用される、ソフトウェア完全性保護装置。
前記第３のソフトウェアパッケージを第２のデバイスに送信するように構成された送信ユニットをさらに備える、請求項７に記載のソフトウェア完全性保護装置。
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、前記第１の署名および前記第２の署名が両方とも有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、前記第１の署名が有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表し、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、前記第２の署名が有効であることが、前記第２のソフトウェアパッケージに対する完全性検証が成功したことを表す、請求項８に記載のソフトウェア完全性保護装置。
ソフトウェア完全性検証装置であって、
前記ソフトウェア完全性検証装置が、
第１のソフトウェアパッケージを取得するように構成された取得ユニットであって、前記第１のソフトウェアパッケージが、第１の署名、第２の署名、および第２のソフトウェアパッケージを備え、前記第１の署名が、ファーストパーティによって、第１の秘密鍵を使用することによって前記第２のソフトウェアパッケージのために作成され、前記第１の秘密鍵が、前記ファーストパーティによって制御され、前記ファーストパーティが前記第２のソフトウェアパッケージのユーザである、取得ユニットと、
検証結果を取得するために、事前に記憶されている第１の公開鍵と第２の公開鍵に基づいて、それぞれ前記第１の署名と前記第２の署名を検証するように構成された検証ユニットであって、前記第１の公開鍵が前記ファーストパーティによって制御され、前記第２の公開鍵がセカンドパーティによって制御され、前記セカンドパーティが前記第２のソフトウェアパッケージの製造業者もしくはサードパーティのデジタル認証局である、検証ユニットと
を備える第２のデバイスに適用される、ソフトウェア完全性検証装置。
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが有効である場合、前記検証ユニットが、
第１の署名検証結果を取得するために、前記事前に記憶された第１の公開鍵に基づいて前記第１の署名を検証するように構成され、前記第１の署名検証結果が、前記第１の署名が有効であるかどうかを表すために使用される、第１の検証サブユニットと、
第２の署名検証結果を取得するために、前記事前に記憶された第２の公開鍵に基づいて前記第２の署名を検証するように構成され、前記第２の署名検証結果が、前記第２の署名が有効であるかどうかを表すために使用される、第２の検証サブユニットと、
前記第１の署名検証結果および前記第２の署名検証結果に基づいて前記検証結果を生成するように構成された第１の生成サブユニットであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第１の署名検証結果が前記第１の署名は有効であることを表し、前記第２の署名検証結果が前記第２の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、第１の生成サブユニットと、
を備え、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが有効である場合、前記検証ユニットが、
第１の署名検証結果を取得するために、前記事前に記憶された第１の公開鍵に基づいて前記第１の署名を検証するように構成され、前記第１の署名検証結果が、前記第１の署名が有効であるかどうかを表すために使用される、第３の検証サブユニットと、
前記第１の署名検証結果に基づいて前記検証結果を生成するように構成された第２の生成サブユニットであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第１の署名検証結果が前記第１の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、第２の生成サブユニットと、
を備え、または、
前記第２のデバイスにおけるスイッチングイネーブルビットが無効であり、前記第２のデバイスにおけるデュアルルートイネーブルビットが無効である場合、前記検証ユニットが、
第２の署名検証結果を取得するために、前記事前に記憶された第２の公開鍵に基づいて前記第２の署名を検証するように構成され、前記第２の署名検証結果が、前記第２の署名が有効であるかどうかを表すために使用される、第４の検証サブユニットと、
前記第２の署名検証結果に基づいて前記検証結果を生成するように構成された第３の生成サブユニットであって、前記検証結果が、前記第２のソフトウェアパッケージに対するソフトウェア完全性検証が成功したかどうかを表すために使用され、前記第２の署名検証結果が前記第２の署名は有効であることを表す場合、前記検証結果が、前記第２のソフトウェアパッケージに対する前記完全性検証が成功したことを表す、第３の生成サブユニットと
を備える、請求項１０に記載のソフトウェア完全性検証装置。
前記第１の署名と前記第２のソフトウェアパッケージが、第３のソフトウェアパッケージに備えられており、前記第２の署名が、前記セカンドパーティによって制御される第２の秘密鍵を使用することによって前記第３のソフトウェアパッケージに対して署名動作を実行することによって取得され、前記第１の秘密鍵が前記第１の公開鍵と一致し、前記第２の秘密鍵が前記第２の公開鍵と一致する、請求項１０または１１に記載のソフトウェア完全性検証装置。
請求項７から９のいずれか一項に記載の前記ソフトウェア完全性保護装置を備える、ネットワークシステム。
請求項１０から１２のいずれか一項に記載の前記ソフトウェア完全性検証装置を備える、ネットワークシステム。
プログラムコードまたは命令を記憶するように構成されたメモリと、
前記デバイスが請求項１から３のいずれか一項に記載の方法を実行できるように、前記プログラムコードまたは前記命令を実行するように構成されるプロセッサと
を備える、デバイス。
プログラムコードまたは命令を記憶するように構成されたメモリと、
前記デバイスが請求項４から６のいずれか一項に記載の方法を実行できるように、前記プログラムコードまたは前記命令を実行するように構成されるプロセッサと
を備える、デバイス。
コンピュータ可読ストレージ媒体がプログラムコードまたは命令を記憶し、前記プログラムコードまたは命令がコンピュータ上で実行されるとき、前記コンピュータが、請求項１から３のいずれか一項に記載の方法を実行することができる、コンピュータ可読ストレージ媒体。
コンピュータ可読ストレージ媒体がプログラムコードまたは命令を記憶し、前記プログラムコードまたは命令がコンピュータ上で実行されるとき、前記コンピュータが、請求項４から６のいずれか一項に記載の方法を実行することができる、コンピュータ可読ストレージ媒体。
プログラムコードまたは命令を備えるコンピュータプログラムであって、前記コンピュータプログラムがコンピュータ上で実行されるとき、前記コンピュータが、請求項１から３のいずれか一項に記載の方法を実行することができる、コンピュータプログラム。
プログラムコードまたは命令を備えるコンピュータプログラムであって、前記コンピュータプログラムがコンピュータ上で実行されるとき、前記コンピュータが、請求項４から６のいずれか一項に記載の方法を実行することができる、コンピュータプログラム。