JP2015035224A - 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム - Google Patents

汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム Download PDF

Info

Publication number
JP2015035224A
JP2015035224A JP2014213476A JP2014213476A JP2015035224A JP 2015035224 A JP2015035224 A JP 2015035224A JP 2014213476 A JP2014213476 A JP 2014213476A JP 2014213476 A JP2014213476 A JP 2014213476A JP 2015035224 A JP2015035224 A JP 2015035224A
Authority
JP
Japan
Prior art keywords
key
code
hardware
secure
security
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2014213476A
Other languages
English (en)
Inventor
ブイ. オックスフォード ウィリアム
V Oxford William
ブイ. オックスフォード ウィリアム
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CRIMMENI TECHNOLOGIES Inc
Original Assignee
CRIMMENI TECHNOLOGIES Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CRIMMENI TECHNOLOGIES Inc filed Critical CRIMMENI TECHNOLOGIES Inc
Publication of JP2015035224A publication Critical patent/JP2015035224A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/125Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
    • G06F21/126Interacting with the operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891Revocation or update of secret information, e.g. encryption key update or rekeying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60Digital content management, e.g. content distribution

Abstract

【課題】汎用コードブロックの実行に対する高度に特有の制御を提供する好適なシステムおよび方法を提供すること。
【解決手段】汎用コードブロックの実行に対する高度に特有の制御を提供するシステムおよび方法の実施形態が開示される。これらの実施形態は、所与のコードブロックが特異性によって決定されるように実行されるまさにその環境を可能にし得る。そのような制御メカニズムは、例えば、再帰的実行を介して実装されるコードセグメントの集合の順序付けられた実行に基づくデータ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されることのない普遍性だけではなく、多くの他のセキュリティシステムに勝る、攻撃に対する一定レベルの保護が取得され得る。
【選択図】図2

Description

(発明の分野)
この開示は、汎用コンピュータにおいて任意のコード実行を制御する方法に関する。具体的には、この開示は、コードの実行をコンピューティングデバイスとリンクさせて、コードの実行を制御する効果的な方法に関する。さらに、より具体的には、この開示は、再帰的セキュリティプロトコルの実装と併用してコードの実行を制御することに関する。
コンピュータウイルスおよび他の悪質なソフトウェアは、情報技術業界にとって大きな問題となっている。汎用コンピュータは、定義によれば、任意のコードを起動可能であるので、所与の汎用コンピュータプラットフォーム上において、部分的または全体的に、どのソフトウェアの起動が許容されるかを正確に制御することが非常に困難であって、したがって、マルウェアまたは他の種類の望ましくないソフトウェアの実行を防止することが困難であり得る。現在、このレベルの制御が試みられているいくつかの方法が存在するが、攻撃からプロセッサを隔離するための大部分の努力は、2つの基礎的な問題、すなわち、プロセッサプラットフォームにおける汎用性の損失または性能の損失に悩まされている。これらの損失は、承認と未承認の使用モードとをどのように迅速かつ明確に区別するかの基礎的な問題から生じる。
第2の、しかし、関連する問題は、著作権管理の問題である。今日作成されている文書、音声、および視覚的芸術作品の大部分は、元々デジタルフォーマットであるか、または最終的にデジタルフォーマットとなる。デジタルデータの特徴の1つは、容易に、実質的に正確に複製可能なことである。この特性は、多種多様な安価な配信メカニズムを促進し、その大部分は容易に制御されるものではない。デジタルコンテンツの配信特有の制御不能性は、過去数十年にわたって著作権法の分野に広範囲に及ぶ関連事項をもたらした。あるシステムおよび方法が、そのような複製されたデータのコピーならびに配信を制御するために開発されたが、これらのシステムおよび方法が有する問題の1つは、これらのシステムおよび方法と併用したある種類のソフトウェア、例えば、システムおよび方法を修正するか、またはそのようなシステムおよび方法によって利用されるデータを取得するコードの実行を介して、回避され得ることである。
したがって、汎用コンピューティングデバイスにおけるコードの実行に対するある程度の制御が行使され得、セキュリティプロトコルと併用して、それを利用することによって、そのようなシステムの有効性が向上され得るシステムおよび方法を見つける必要性が存在する。
汎用コードブロックの実行に対して高度に特有の管理を提供するシステムおよび方法の実施形態が開示される。これらの実施形態は、所与のコードブロックが特異性によって決定されるように実行されるまさにその環境を可能にし得る。そのような制御メカニズムは、例えば、再帰的実行を介して実装されるコードセグメントの集合の順序付けられた実行に基づくデータ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されない普遍性だけではなく、多くの他のセキュリティシステムに勝る、攻撃に対する一定レベルの保護が獲得され得る。
特に、一実施形態では、実行に対する条件付き制御のためのシステムおよび方法とともに、特定のコンピュータ操作において使用されるデータを難読化しつつ、依然として、そのデータの使用を可能にするシステムおよび方法が開示される。制御または難読化のためのこれらのシステムおよび方法は、デジタルセキュリティ、著作権管理、条件付きアクセス、望ましくないコンピュータウイルスに対する保護等を包含し得るが、それらに限定されないセキュリティの分野を含む、多数の潜在的用途分野において使用可能である。具体的には、実施形態は、再帰的セキュリティプロトコルと併用して利用され、そのようなセキュリティプロトコルを強化し得る。
加えて、これらの種類の方法論をコンピュータシステム、ハードウェア、およびソフトウェアにおいて具現化するシステムの実施形態が提示される。全く同一のハードウェア実装は、潜在的に、ソフトウェアの要件に応じて、解決策の全範囲のうちの任意の1つまたは組み合わせを実装するために使用され得ることに留意されたい。
本明細書は、例えば、以下の項目も提供する。
(項目1)
終点デバイスでのコードの実行を制御する方法であって、
第1のビットストリームをデバイスにおいて受信することと、
該第1のビットストリームに対応する第1のキーを取得することであって、該第1のキーは、該第1のビットストリームをハッシュし、該ハッシュされた第1のビットストリームを暗号化することによって作成された、ことと、
該デバイス特有の第1の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第1のビットストリームを認証することであって、該第1の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュアモードで実行しているときにアクセス可能であり、該第1のビットストリームを認証することは、
該第1のビットストリームをハッシュすることと、
該ハッシュされた第1のビットストリームを暗号化することによって第2のキーを生成することであって、該ハッシュされた第1のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第2のキーを該第1のキーと比較することと
を含む、ことと
を含み、該第2のキーと該第1のキーとが整合する場合、該プロセッサにおいて該第1のビットストリームをセキュア化モードで実行する、方法。
(項目2)
前記第1のビットストリームは、第1の暗号化エンジンを含み、該第1のビットストリームを実行することは、該第1の暗号化エンジンおよび前記デバイス特有の第1の秘密キーを使用して、該第1のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第1のビットストリームの実行は、セキュアモードで行われる、項目1に記載の方法。
(項目3)
前記第2のキーと前記第1のキーとが整合しない場合、
前記第1のビットストリームが暗号化されているか否かを決定することを含み、該第1のビットストリームが暗号化されているとき、
第2のビットストリームを取得することと、
該ハードウェアの中に格納される前記デバイス特有の第1の秘密キーにアクセスするように動作可能な前記デバイスにおける前記ハードウェアを使用して、該第2のビットストリームを認証することであって、該第2のビットストリームを認証することは、
該第2のビットストリームに対応する第3のキーを取得することであって、該第3のキーは、該第2のビットストリームをハッシュし、該ハッシュされた第2のビットストリームを暗号化することによって作成される、ことと、
該第2のビットストリームをハッシュすることと、
該ハッシュされた第2のビットストリームを暗号化することによって第4のキーを生成することであって、該ハッシュされた第2のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第4のキーを該第3のキーと比較することであって、該第4のキーと該第3のキーとが整合するとき、該第2のビットストリームを該プロセッサにおいてセキュア化モードで実行する、ことと
含む、ことと
を含む、項目2に記載の方法。
(項目4)
前記第2のビットストリームをハッシュすることは、前記第1のビットストリームから生成された前記第2のキーをシード値として利用する、項目3に記載の方法。
(項目5)
前記第2のビットストリームは、第2の暗号化エンジンを含み、該第2のビットストリームを実行することは、前記デバイス特有の第1の秘密キーを使用して、前記第1のビットストリームおよび該第2の暗号化エンジンを用いて暗号化されたデジタルコンテンツの両方を復号化することを含み、該第2のビットストリームの実行は、セキュアモードで行われる、項目3に記載の方法。
(項目6)
前記第2のビットストリームの認証および前記第2のビットストリームの実行は、前記第1のビットストリームの実行の前に行われる、項目5に記載の方法。
(項目7)
前記第2のビットストリームの実行後、前記第1のビットストリームの実行前に、該第1のビットストリームを認証することをさらに含む、項目6に記載の方法。
(項目8)
前記第1のビットストリーム、第2のビットストリーム、暗号化されるデジタルコンテンツ、第1のキー、および第3のキーは、メッセージの中に受信されており、該メッセージは、
該第1のビットストリームの第1の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第1のビットストリームをハッシュし、前記デバイス特有の第1の秘密キーを用いて、該ハッシュされた第1のビットストリームを暗号化することによって、該第1のキーを生成することと、
該第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第2のビットストリームの第2の暗号化エンジンを用いて、該関連付けられた該第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第2のビットストリームをハッシュし、該デバイス特有の第1の秘密キーを用いて、該ハッシュされた第2のビットストリームを暗号化することによって、該第3のキーを生成することと、
第1の復号化アルゴリズムを該第1の暗号化されたビットストリームと関連付けることと、
該第3のキーと第2のビットストリームと暗号化された関連付けられた第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目7に記載の方法。
(項目9)
コードの実行を制御するシステムであって、該システムは、
デバイスであって、
プロセッサと、
第1の秘密キーを格納する第1のハードウェアと、
第2のハードウェアであって、該プロセッサがセキュア化モードで実行しているときに、該第1の秘密キーにアクセスし、該第1の秘密キーを使用して、暗号化アルゴリズムを実装するように動作可能である第2のハードウェアと、
該プロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体であって、該命令は、
第1のビットストリームを該デバイスにおいて受信することと、
該第1のビットストリームに対応する第1のキーを取得することであって、該第1のキーは、該第1のビットストリームをハッシュし、該ハッシュされた第1のビットストリームを暗号化することによって作成された、ことと、
該デバイスにおける該第2のハードウェアを使用して、該第1のビットストリームを認証することであって、該第1のビットストリームを認証することは、
該第1のビットストリームをハッシュすることと、
該ハッシュされた第1のビットストリームを暗号化することによって、第2のキーを生成することであって、該ハッシュされた第1のビットストリームの暗号化は、該デバイスの第2のハードウェアの中で行われ、該第2のハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第2のキーを該第1のキーと比較することと
を含む、ことと
該第2のキーと該第1のキーとが整合する場合、該プロセッサにおいて該第1のビットストリームをセキュア化モードで実行することと
を行うためのものである、コンピュータ可読記憶媒体と
を含む、デバイスを含む、システム。
(項目10)
前記第1のビットストリームは、第1の暗号化エンジンを含み、該第1のビットストリームを実行することは、該第1の暗号化エンジンおよび前記デバイス特有の第1の秘密キーを使用して、該第1のビットストリームと関連付けられ暗号化されたデジタルコンテンツを復号化することを含み、該第1のビットストリームの実行は、セキュアモードで行われる、項目9に記載のシステム。
(項目11)
前記第2のキーと前記第1のキーとが整合しない場合、前記命令は、
前記第1のビットストリームが暗号化されているか否かを決定することと、該第1のビットストリームが暗号化されているときは、
第2のビットストリームを取得することと、
該第1のハードウェアの中に格納される、前記デバイス特有の第1の秘密キーにアクセスするように動作可能である前記デバイスにおける前記第2のハードウェアを使用して、該第2のビットストリームを認証することであって、該第2のビットストリームを認証することは、
該第2のビットストリームに対応する第3のキーを取得することであって、該第3のキーは、該第2のビットストリームをハッシュし、該ハッシュされた第2のビットストリームを暗号化することによって生成される、ことと、
該第2のビットストリームをハッシュすることと、
該ハッシュされた第2のビットストリームを暗号化することによって、第4のキーを生成することであって、該ハッシュされた第2のビットストリームの暗号化は、該デバイスの該第2のハードウェアの中で行われ、該第2のハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第4のキーを該第3のキーと比較することと
を含む、ことと、
該第4のキーと該第3のキーとが整合する場合、前記プロセッサにおいて該第2のビットストリームをセキュア化モードで実行することと
を行うようにさらに動作可能である、項目10に記載のシステム。
(項目12)
前記第2のビットストリームをハッシュすることは、前記第1のビットストリームから生成された前記第2のキーをシード値として利用する、項目11に記載のシステム。
(項目13)
前記第2のビットストリームは、第2の暗号化エンジンを含み、該第2のビットストリームを実行することは、前記デバイス特有の第1の秘密キーを使用して、前記第1のビットストリームおよび該第2の暗号化エンジンを用いて前記暗号化されたデジタルコンテンツの両方を復号化することを含み、該第2のビットストリームの実行は、セキュアモードで行われる、項目11に記載のシステム。
(項目14)
前記第2のビットストリームの認証および前記第2のビットストリームの実行は、前記第1のビットストリームの実行の前に行われる、項目13に記載のシステム。
(項目15)
前記命令は、前記第2のビットストリームの実行後、前記第1のビットストリームの実行前に、該第1のビットストリームを認証するように動作可能である、項目14に記載のシステム。
(項目16)
前記第1のビットストリーム、第2のビットストリーム、暗号化されるデジタルコンテンツ、第1のキー、および第3のキーは、メッセージにおいて受信されており、該メッセージは、
該第1のビットストリームの第1の暗号化エンジンによって、該デジタルコンテンツを暗号化することと、
該第1のビットストリームをハッシュし、前記デバイス特有の第1の秘密キーを用いて該ハッシュされた第1のビットストリームを暗号化することによって、該第1のキーを生成することと、
該第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第2のビットストリームの第2の暗号化エンジンを用いて、該関連付けられた該第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第2のビットストリームをハッシュし、該デバイス特有の第1の秘密キーを用いて該ハッシュされた第2のビットストリームを暗号化することによって、第3のキーを生成することと、
第1の復号化アルゴリズムを該第1の暗号化されたビットストリームと関連付けることと、
該第3のキーと第2のビットストリームと暗号化され関連付けられた第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目15に記載のシステム。
(項目17)
終点デバイスにおけるコードの実行を制御するプロセッサによって実行可能な命令を含むコンピュータ可読媒体であって、
第1のビットストリームをデバイスにおいて受信することと、
該第1のビットストリームに対応する第1のキーを取得することであって、該第1のキーは、該第1のビットストリームをハッシュし、該ハッシュされた第1のビットストリームを暗号化することによって作成される、ことと、
デバイス特有の第1の秘密キーにアクセスするように動作可能である該デバイスにおけるハードウェアを使用して、該第1のビットストリームを認証することであって、該デバイス特有の第1の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第1のビットストリームを認証することは、
該第1のビットストリームをハッシュすることと、
該ハッシュされた第1のビットストリームを暗号化することによって、第2のキーを生成することであって、該ハッシュされた第1のビットストリームの暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第2のキーを該第1のキーと比較することと
を含む、ことと、
該第2のキーと該第1のキーとが整合する場合、該第1のビットストリームを該プロセッサにおいてセキュア化モードで実行することと
を行うための実行可能な命令を含む、コンピュータ可読媒体。
(項目18)
前記第1のビットストリームは、第1の暗号化エンジンを含み、該第1のビットストリームを実行することは、該第1の暗号化エンジンおよび前記デバイス特有の第1の秘密キーを使用して、該第1のビットストリームと関連付けられ暗号化されたデジタルコンテンツを復号化することを含み、該第1のビットストリームの実行は、セキュアモードで行われる、項目17に記載の方法。
(項目19)
前記第2のキーと前記第1のキーとが整合しない場合、前記命令は、
前記第1のビットストリームが暗号化されているか否かを決定することと、該第1のビットストリームが暗号化されている場合、
第2のビットストリームを取得することと、
前記ハードウェアの中に格納される前記デバイス特有の第1の秘密キーにアクセスするように動作可能である前記デバイスにおける該ハードウェアを使用して、該第2のビットストリームを認証することであって、該第2のビットストリームを認証することは、
該第2のビットストリームに対応する第3のキーを取得することであって、該第3のキーは、該第2のビットストリームをハッシュし、該ハッシュされた第2のビットストリームを暗号化することによって作成される、ことと、
該第2のビットストリームをハッシュすることと、
該ハッシュされた第2のビットストリームを暗号化することによって、第4のキーを生成することであって、該ハッシュされた第2のビットストリームの暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第1の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第4のキーを該第3のキーと比較することと
を含む、ことと、
該第4のキーと該第3のキーとが整合する場合、該第2のビットストリームを該プロセッサにおいてセキュア化モードで実行することと
を行うようにさらに動作可能である、項目18に記載のコンピュータ可読媒体。
(項目20)
前記第2のビットストリームをハッシュすることは、前記第1のビットストリームから生成された前記第2のキーをシード値として利用する、項目19に記載のコンピュータ可読媒体。
(項目21)
前記第2のビットストリームは、第2の暗号化エンジンを含み、該第2のビットストリームを実行することは、前記デバイス特有の第1の秘密キーを使用して、該第1のビットストリームおよび該第2の暗号化エンジンを用いて前記暗号化されたデジタルコンテンツの両方を復号化することを含み、該第2のビットストリームの実行は、セキュアモードで行われる、項目19に記載のコンピュータ可読媒体。
(項目22)
前記第2のビットストリームの認証および前記第2のビットストリームの実行は、前記第1のビットストリームの実行の前に行われる、項目21に記載のコンピュータ可読媒体。
(項目23)
前記前記第2のビットストリームの実行後、前記第1のビットストリームの実行前に、該第1のビットストリームを認証することをさらに含む、項目22に記載のコンピュータ可読媒体。
(項目24)
前記第1のビットストリーム、第2のビットストリーム、暗号化されたデジタルコンテンツ、第1のキー、および第3のキーは、メッセージにおいて受信されており、該メッセージは、
該第1のビットストリームの第1の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第1のビットストリームをハッシュし、前記デバイス特有の第1の秘密キーを用いて、該ハッシュされた第1のビットストリームを暗号化することによって、該第1のキーを生成することと、
該第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第2のビットストリームの第2の暗号化エンジンを用いて、該関連付けられた第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第2のビットストリームをハッシュし、該デバイス特有の第1の秘密キーを用いて該ハッシュされた第2のビットストリームを暗号化することによって、第3のキーを生成することと、
第1の復号化アルゴリズムを該第1の暗号化されたビットストリームと関連付けることと、
該第3のキーと第2のビットストリームと暗号化され関連付けられた第1のキーと第1のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目23に記載のコンピュータ可読媒体。
本発明のこれらおよび他の側面は、以下の説明ならびに添付図面と併用して検討されることによって、さらに認識および理解されるであろう。しかしながら、本発明の種々の実施形態およびそれらの多数の特有の詳細を示す以下の説明は、限定ではなく、例示として与えられることを理解されたい。多くの解決策、修正、追加、および/または再配設が、その精神から逸脱することなく発明の範囲内で行われ得、本発明は、あらゆるそのような解決策、修正、追加、および/または再配設を含んでいる。
本明細書に付随かつその一部を形成する図面は、本発明のある側面を図示するために含まれる。本発明ならびに本発明が提供されるシステムの構成要素および動作のより明確な概念は、例示的であって、したがって、限定ではない、図面に例示される実施形態を参照することによって、より容易に明白となるであろう(同一の参照番号は、同一の構成要素を示す)。本発明は、本明細書に提示される説明と組み合わせて、これらの図面のうちの1つ以上を参照することによって、さらに理解され得る。図面に例示される特徴は、必ずしも、正確な縮尺で図示されていないことに留意されたい。
図1は、コンテンツ配信のためのアーキテクチャの一実施形態を図示する。 図2は、標的ユニット汎用コンピューティングデバイスの一実施形態を図示する。 図3は、複合キーの作成の一実施形態を図示する。 図4Aおよび図4Bは、デジタル署名またはそれらの同等物の作成の実施形態を図示する。 図4Aおよび図4Bは、デジタル署名またはそれらの同等物の作成の実施形態を図示する。 図5Aおよび5Bは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。 図5Aおよび5Bは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。 図6は、複合メッセージダイジェストの使用の一実施形態を図示する。 図7A、7Bおよび7Cは、セキュア化コードブロックメッセージの実施形態を図示する。 図7A、7Bおよび7Cは、セキュア化コードブロックメッセージの実施形態を図示する。 図7A、7Bおよび7Cは、セキュア化コードブロックメッセージの実施形態を図示する。 図8は、復号化動作のある実施形態を図示する。 図9は、複合キーの使用の一実施形態を図示する。 図10は、候補コードブロックの承認における複合キーの使用の一実施形態を図示する。 図11は、復号化動作の一実施形態を図示する。 図12は、コードブロックの照合の一実施形態を図示する。 図13は、再帰的セキュリティプロトコルを使用して行われる、復号化動作の一実施形態を図示する。 図14は、コード照合の動作の一実施形態を図示する。 図15は、デジタル署名機能ブロックの一実施形態を図示する。
本発明および種々の特徴ならびにそれらの有利な詳細は、添付の図面に例示され、以下の説明において詳述される非限定的な実施形態を参照して、より完全に説明される。周知の開始材料、処理技術、構成要素、および機器の説明は、詳細において、本発明を不必要に曖昧化しないために省略される。しかしながら、本発明の好ましい実施形態を示す、発明を実施するための形態および特有の実施例は、限定としてではなく、例示としてのみ与えられることを理解されたい。基礎となる本発明の概念の精神および/または範囲内の種々の代用、修正、追加、および/または再配設は、本開示から、当業者には明白となるであろう。本明細書に論じられる実施形態は、コンピュータ可読媒体(例えば、HD)、ハードウェア回路等、または任意の組み合わせ上に常駐し得る、好適なコンピュータ実行可能命令として実装可能である。
特有の実施形態について論じる前に、ある実施形態を実装するためのハードウェアアーキテクチャの実施形態が、本明細書において説明される。一実施形態は、ネットワークに通信可能に結合される1つ以上のコンピュータを含むことが可能である。当業者に周知のように、コンピュータは、中央処理装置(「CPU」)、少なくとも1つの読取専用メモリ(「ROM」)、少なくとも1つのランダムアクセスメモリ(「RAM」)、少なくとも1つのハードドライブ(「HD」)、および1つ以上の入/出力(「I/O」)デバイスを含むことが可能である。I/Oデバイスは、キーボード、モニタ、プリンタ、電子ポイントデバイス(マウス、トラックボール、スタイレット等)等を含むことが可能である。種々の実施形態では、コンピュータは、ネットワーク上の少なくとも1つのデータベースへのアクセスを有する。
ROM、RAM、およびHDは、CPUによって、コンピュータ実行可能な命令(すなわち、直接実行可能である、または、例えば、コンパイル、変換等によって、実行可能となる)を格納するためのコンピュータメモリである。本開示では、用語「コンピュータ可読媒体」とは、ROM、RAM、およびHDに限定されず、プロセッサによって読取可能な任意の種類のデータ記憶媒体を含むことが可能である。いくつかの実施形態では、コンピュータ可読媒体は、データカートリッジ、データバックアップ磁気テープ、フロッピー(登録商標)ディスク、フラッシュメモリドライブ、光学データ記憶ドライブ、CD−ROM、ROM、RAM、HD等を指し得る。
本明細書に説明される機能またはプロセスの少なくとも一部は、好適なコンピュータ実行可能命令として実装可能である。コンピュータ実行可能命令は、1つ以上のコンピュータ可読媒体上のソフトウェアコード構成要素またはモジュールとして格納され得る(不揮発性メモリ、揮発性メモリ、DASDアレイ、磁気テープ、フロッピー(登録商標)ディスク、ハードドライブ、光学記憶デバイス等、あるいは任意の他の適切なコンピュータ可読媒体または記憶デバイス等)。一実施形態では、コンピュータ実行可能命令は、一連のコンパイルされたC++、Java(登録商標)、HTML、あるいは任意の他のプログラミングまたはスプリプティングコードを含み得る。
加えて、開示される実施形態の機能は、1つのコンピュータ上に実装されるか、あるいはネットワーク内またはネットワークを介して、2つ以上のコンピュータ間で共有/分散されてもよい。実施形態を実装するコンピュータ間の通信は、既知のネットワークプロトコルに準拠して、任意の電子、光学、無線周波数信号、または他の好適な通信の方法およびツールを使用して、達成可能である。
本明細書で使用されるように、用語「comprises(備える)」、「comprising(備えている)」、「includes(含む)」、「including(含んでいる)」、「has(有する)」、「having(有している)」、またはそれらの任意の他の変形例は、非排他的包含を網羅することが意図される。例えば、要素の列挙を備える、プロセス、工程、物品、または装置は、必ずしも、それらの要素のみに限定されず、明示的に列挙されない、あるいはそのようなプロセス、工程、物品、または装置に付随しない他の要素を含んでもよい。さらに、そうではない旨が明示的に記述されない限り、「or(または)」とは、包含的「or」を指し、排他的「or」を指すわけではない。例えば、条件AまたはBは、以下のうちの任意の1つによって充足される。Aは真(または、存在する)であって、Bは偽である(または、存在しない)、Aは偽であって(または、存在しない)、Bは真である(または、存在する)、ならびにAおよびBの両方が、真である(または、存在する)。
加えて、本明細書において与えられる任意の実施例または例示は、それらが利用される任意の用語または複数の用語の定義に関する制限、限定、あるいはそれらの表明として、いかようにもみなされるものではない。代わりに、これらの実施例または例示は、1つの特定の実施形態に関して、例示のみとして説明されるものとみなされるべきである。当業者は、これらの実施例または例示が利用される、任意の用語あるいは複数の用語が、それらとともに、または明細書内のいずれかに与えられ得る、あるいは与えられ得ない、他の実施形態をも包含し、あらゆるそのような実施形態は、その用語または複数の用語の範囲内に含まれることが意図されることを理解するであろう。そのような非限定的実施例および例示を指す言葉として、「for example(例えば)」、「for instance(例えば)」、「e.g.(例えば)」、「in one embodiment(一実施形態では)」を含むが、それららに限定されない。
上述のように、プロセッサに、所定の方法において、任意のコードのセグメントを実行させることが望ましい。この制御の問題は、合法ソフトウェアでさえ、操作するか、意図しないか、またはさらに悪質な結果をもたらし得る、多くの多様な方法によって悪化する。これらの攻撃の方法として、入力データの稀なケースまたはさらに他のアルゴリズムの欠損を悪用するために、偽引数を入力としてルーチンにフィードすることによって、不完全に書き込まれてはいるが、その他の点においては有効なコードを利用することを含み得る。他の可能性のある攻撃の手段として、不適切または意図的に誤った結果をもたらすように、その他の点においては合法的であるコードによって参照される種々のプロセッサレジスタ(スタックポインタ等)あるいは外部記憶場所内に格納されているデータを個別に書き換えることを含む。
この種類の制御が影響を受け得るいくつかのメカニズムが存在する。これらのシステムは、この種類の意図しない使用からプロセッサを保護することを試みる、単純な方式だけではなく、複雑な方式も含む。合理的にセキュアではあるが、複雑なメカニズムの1つとして、その実行に先立って、コードセグメントを事前に暗号化することを含む。コードセグメントが、メモリからプロセッサにロードされると、注意深く制御された環境下において復号され、次いで、セキュアな態様で実行されなければならない(言い換えると、復号化動作と後続の実行との間において書き換えまたは改ざんされてはならない)。このメカニズムは、プロセッサが、当該コードセグメントが、実行開始可能となることに先立って、復号されるまで、待機しなければならないために被り得る性能上の非効率性に悩まされる。実行される特定のコードセグメントの選択と、実際の復号化後の実行との間のこの待ち時間は、プロセッサパイプラインの失速およびデータパスの非効率性を含むが、それらに限定されない多くの問題を生じさせるだけではなく、潜在的攻撃のための別の手段を提供し得る(復号化と実行動作との間に、何らかの形でコードを奪取することによる)。
また、この暗号化されたコードメカニズムは、表面上保護されている暗号化コードセグメントを適切に復号化しようとする(または、復号化されたコピーを取得する)ハッカーの不測の事態からプロセッサを保護するものでは全くない。その場合、次いで、彼らは、標的プロセッサまたはある他の非承認プロセッサのいずれかにおいて、その非保護コードを非制御態様で起動し得る。したがって、コードが、暗号化されていない状態(すなわち、プレーンテキスト形式)において、または暗号化された形式で配信されているかどうかにかかわらず、どのコードセグメントが、特定のプロセッサまたは複数のプロセッサにおいて起動可能であるかを正確に制御する方法を見出すことが好ましい。一方、特定のプロセッサにおいて起動可能なコードが、ある事前に選択されたサブ集合に限定される場合、プロセッサ自体の汎用的性質が侵害され得る。これは、可能性として、プロセッサの汎用性が低くなり、したがって、その潜在的応用の余地における柔軟性がほとんどなくなるようにアーキテクチャを制約する影響を有し得る。最大限に柔軟性のある汎用プロセッサアーキテクチャが、常に、強く求められているが、マルウェア攻撃を最も受けやすいのは、正にそれらのプロセッサである。
したがって、任意の特定のプロセッサアーキテクチャに依存しない、十分に汎用性のあるコード実行の制御のための方法の必要性が存在する。また、そのような方法が、標的プロセッサのオブジェクトコード密度または実行パイプラインのいずれにも悪影響を及ぼさないかどうかも有用であろう。同時に、そのようなシステムおよび方法が、オリジナルの標的プロセッサまたはある他の意図されない標的プロセッサのいずれかにおける、その他の点において合法的であるコードセグメントの無許可使用に対する保護を提供することが望ましい。そのような方法は、ソフトウェアウイルスおよびマルウェアの制御のための競争における貴重なツールとなるだけではなくデジタルコンテンツの世界において、著作権を保護するための一意的強力なメカニズムとなるであろう。
これを受けて、汎用コードブロックの実行に対する高度に特有の制御を提供し、それによって、所与のコードブロックが実行されるまさにその環境下においてプログラマが決定することを可能にするシステムおよび方法の実施形態に焦点が向けられる。これらの条件として、コードブロックが実行を試みる個々のデバイス、コードブロックが呼び出される環境、実行の時間、実行の順序だけではなく、コードブロックが特定の実行スレッドにおいて呼び出された回数等の制約を含み得る(しかしながら、それらに限定されない)。
そのような制御メカニズムは、例えば、一実施形態では、再帰的実行を介して実装される、呼び出されたコードセグメント集合の明示的に順序付けられた実行に基づいて、データ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されることのない普遍性だけではなく、多くの他のセキュリティシステムに勝る攻撃に対する一定レベルの保護が得られ得る。
実施形態をより詳細に論じる前に、本発明の実施形態が効果的に利用され得るアーキテクチャの一般的概要を与えることが、有用となるであろう。図1は、そのようなトポロジの一実施形態を図示する。ここでは、コンテンツ配信システム101は、プロトコルエンジンを備える1つ以上の標的ユニット100(また、本明細書では、終点デバイスとも呼ばれる)にデジタルコンテンツ(例えば、音声または映像データ、ソフトウェアアプリケーション等を備える、ビットストリームであってもよい)を配信するように動作し得る。これらの標的ユニットは、例えば、有線または無線ネットワーク、あるいはネットワークで結ばれていないコンピュータデバイス上のコンピューティングデバイスの一部であってもよく、そのようなコンピューティングデバイスとして、例えば、ネットワークを介して、または、例えば、メール等を介して送達され得るコンピュータ可読記憶媒体上で、ビットストリームとして送達されるコンテンツを再生し得る、パーソナルコンピュータ、携帯電話、携帯端末、メディアプレーヤを含む。後述のように、このデジタルコンテンツは、デジタルコンテンツの実行の制御が、デジタルコンテンツに関して制御され、セキュアに実装され得るように、構成または配信されてもよい。
図2は、受信したデジタルコンテンツと併せて、デジタルコンテンツの実行の制御またはセキュリティプロトコルの実装が可能な標的ユニットの一実施形態のアーキテクチャを図示する。標的ユニットの要素は、標的ユニット100のプロトコルエンジン上にセキュアな態様でプロトコルを実装するブロック集合を含んでもよい。これらのブロックは、この実施形態において、ハードウェアとして説明されるが、ソフトウェアを利用し、同様の効果を有する類似機能を達成してもよいことに留意されたい。また、ある実施形態は、ここに説明される全ブロックを含んでもよい一方で、他の実施形態では、より少ないか、または付加的なブロックを利用してもよいことに留意されたい。
これらのブロックの第1は、リアルタイムクロックまたは日付/時間レジスタ102である。これは、中央サーバとのセキュアな交信によって設定またはリセット可能な自走タイマである。時間は、セキュアな時間標準についてクエリを行うことによって確立され得るので、この機能を内蔵することはより便宜的となり得る。また、標的ユニット100は、十分にランダムな数の並びを生成するように構成され得るか、または、次に疑似乱数発生システムに対するシード値を供給するために使用可能である乱数発生器180を備えてもよい。また、この疑似乱数発生器は、潜在的に、ハードウェア、ソフトウェア、または「セキュアな」ソフトウェアの中に実装可能である。
一方向ハッシュ関数ブロック160は、ハッシュ機能を実質的にハードウェアの中に実装するように動作可能であってもよい。標的ユニット100の別の部分は、ハードウェア支援暗号化/復号化システム170であって、これは、実行可能コードブロックに変換するために、標的ユニット100の秘密キーまたは公開/個人キー(後述)を使用して、暗号化されたメッセージに作用するか、あるいは非暗号化データに作用し、暗号化されたメッセージに変換する。この復号化システム170は、いくつかの方法で実装可能である。また、一方向ハッシュ関数と後続の暗号化/復号化システムとの組み合わせは、任意のデジタルデータが暗号化形式またはプレーンテキスト形式で配信されているかどうか、そのデータの照合のために使用可能なデジタル署名発生器を備えてもよいことに留意されたい。プロトコル全体の速度およびセキュリティは、このブロックの構造に応じて変動してもよく、したがって、セキュリティシステムのアップデートに対応するために十分に柔軟であるだけでなく、システムに、時間クリティカルなメッセージのリアルタイム復号化を行わせることに十分に高速であるように構成され得る。
これに留意すると、正確にどの暗号化アルゴリズムが、このハードウェアブロック170に対して使用されるかは、プロトコルの実施形態にとって重要ではない。最大の柔軟性を促進するために、実際のハードウェアは、非アルゴリズム的に特有の態様で使用されることに十分に汎用性であることが想定されるが、このメカニズムを実装可能な多くの異なる手段が存在する。この点において、用語「暗号化」および「復号化」とは、暗号化/復号化を行うためのエンジン(アルゴリズム、ハードウェア、ソフトウェア等)を指す場合、本明細書では互換可能に利用されることに留意されたい。理解されるように、対称暗号化が、ある実施形態で使用される場合、同一または類似の暗号化あるいは復号化エンジンが、暗号化と復号化の両方のために使用されてもよい。
別のブロックは、実行されるコードを記憶可能であるメモリ110である。これは、一般的には、命令キャッシュ(I−キャッシュ)として知られている。いくつかの実施形態では、このI−キャッシュ110の一部の重要な特徴は、あるブロック内に含有されるデータが、CPU実行ユニット120によってのみ可読であることである。言い換えると、I−キャッシュメモリ130のこの特定のブロックは、任意のソフトウェアによる実行専用であって、そこからの読取り、またはそこへの書込みができない。また、I−キャッシュのこのブロックは、本明細書では、「セキュア化I−キャッシュ」130と呼ばれる。実行されるコードが、このセキュア化I−キャッシュブロック130内に格納される態様は、図示され得るか、またはされ得ない別のブロックを経由してもよい。通常、当技術分野において知られるように、I−キャッシュ150を利用して通常実行されるコードを格納してもよい。
加えて、いくつかの実施形態では、あるブロックを使用して、セキュアなコードブロックの動作を加速してもよい。故に、CPUレジスタ集合140は、CPU120が、セキュアなコードを実行中、アクセスのみ可能、またはセキュアなコードブロック(セキュアモードと呼ばれるセキュア化コードブロック130内の命令)の実行の完了に応じて、あるいは、何らかの理由から、セキュア化I−キャッシュ130内に格納されるコードの実行の際に、非セキュアまたは「通常」のI−キャッシュもしくは他のエリア内に位置するコードの任意のセクションへのジャンプが生じる場合、消去されるように規定されてもよい。
一実施形態において、CPU実行ユニット120は、どのレジスタ140が、セキュア化コードブロック130内に格納されたコードを実行中に、読み取られるか、または書き込まれるかを追跡し、次いで、「セキュア化実行」モードの終了に対応してこれらのレジスタを自動的に消去するように構成されてもよい。これは、セキュア化コード自体に、2つの種類のコードブロック間で共有が許可されているデータのみが保全されるように、迅速に「後始末」を行わせる。別の可能性は、セキュア化コードブロック130内で実行されるコードの著者が、どのレジスタ140が消去されるべきかを明示的に識別可能であることである。
セキュアと非セキュアなコードセグメントとの間のレジスタ140内に格納されたデータの「漏洩」に対処するための別の潜在的態様は、CPU120がセキュア化コードを実行中にのみ使用されるレジスタ集合140を識別することである。一実施形態では、これは、多くの最新CPU設計において実践されるレジスタリネームおよびスコアボードメカニズムの一種を利用して達成されてもよい。セキュア化コードブロックの実行が、アトミックアクション(すなわち、割込み不可能である)として処理される場合、このリネームおよびスコアボードの実装をより容易にし得る。
CPU120が、「セキュア化」コード(セキュア化コードブロック130内のコード)と「非セキュア化コード」(通常I−キャッシュ150等の別の場所またはメモリの別の場所内のコード)との混合を実行する可能性はほとんどないように思われ得るが、そのような環境は、割込みルーチン内にジャンプする場合等、コンテキストを切り替えるプロセスにおいて、またはCPU120のコンテキストが格納される場所に応じて生じ得る(大部分のCPUは、潜在的に、メインメモリ内にコンテキストを格納し、そこでは、非セキュア化コードブロックによる発見および操作を被る)。
この不測の事態に対する保護を支援するために、一実施形態では、実行中に割り込まれたセキュア化コードブロックの実行の際に得られた結果がシステム内の他の実行スレッドに曝露されることを防止するために利用され得る別の方法は、プロセッサがセキュア化実行モードで動作中、スタックプッシュを無効にすることである。このスタックプッシュの無効化は、セキュア化コードブロックが、その通常完了に先立って、割り込まれる場合、再開不可能であって、したがって、最初から再開されなければならないという点において、セキュア化コードブロックが、このように、割込み不可能であるということを意味するであろう。ある実施形態では、「セキュア化実行」モードが、プロセッサ割込みの際に無効化される場合、また、セキュア化コードブロックは、潜在的に、呼出し連鎖全体が再開されない限り、再開不可能であり得ることに留意されたい。
また、各標的ユニット100は、秘密キー定数104の2つの集合(そのうちのいずれの値も、ソフトウェア読取り不可能である)を有してもよい。これらのキー(一次秘密キー)の第1のものは、秘密キー集合として体系化されてもよく、そのうちの1つだけが、任意の特定の時間に可読である。ユニットの「所有権」が変更される場合(例えば、プロトコルエンジンを含有する機器が販売されるか、またはその所有権が、別様に譲渡される)、現在アクティブな一次秘密キーは「消去される」か、または異なる値によって上書きされてもよい。この値は、セキュアな態様でユニットに転送可能であるか、またはこの第1のキーが消去されるときにのみ使用されるような態様でユニットに既に格納され得る。事実上、これは、その所有権が変更されるとき、またはそのような変更のある他の理由が存在する場合(危殆化キー等)、その特定のユニットに対して新しい一次秘密キーを発行することに相当する。二次秘密キーは、標的ユニット100自体と併用されてもよい。標的ユニット100のCPU120は、一次または二次秘密キーのいずれかの値にそもそもアクセス不可能であるため、ある意味、標的ユニット100は、その独自の秘密キー104を「把握」さえしていないことになる。これらのキーは、標的ユニットのCPU120のセキュリティブロックの中に格納され、その中で使用されるだけである。
さらに別のキー集合が、一時的公開/個人キーシステム(また、非対称キーシステムまたはPKIシステムとしても知られる)の一部として動作してもよい。この対のキーは、高速で生成され、中央サーバの介入なく、類似ユニット間のセキュアな通信リンクを確立するために使用されてもよい。そのようなシステムのセキュリティは、一般的には、同等キー長の対称キー暗号化システムより低いため、これらのキーは、上述の秘密キー集合よりサイズが大きくなり得る。これらのキーは、特に、「リプレー攻撃」に対して防護するために、オンチップタイマブロック内に存在する値と併用されてもよい。これらのキーは、高速で生成されるので、それらが生成される態様は、乱数発生システム180に依存し得る。
一実施形態では、特定の標的ユニットの「所有権」の変更に影響を及ぼすために使用可能な方法の1つは、タイムスタンプまたはタイムスタンプ値と呼ばれる別のキー107と併せて、一次秘密キーを複合キーとして常に使用することである(このキーの値は、変更され得(言い換えると、異なる時間で異なる値を有し得る)、必ずしも、現在の日時を反映し得ないため)。このタイムスタンプ値自体は、構造上可視であってもよく、またはそうでなくてもよい(すなわち、必ずしも、秘密キーではあり得ない)が、それでもなお、標的ユニットが、セキュア化実行モードで動作中でない限り、書換え不可能となるであろう。そのような場合、一次秘密が使用される場合は常に、複合キーの構成要素として、タイムスタンプ値を一貫して使用することは、本質的に、別個の値に切り替えられた場合と同一効果をもたらすことが可能であって、したがって、一次秘密キー自体を書き換える必要なく、効果的に、特定の標的終点ユニットの「所有権の変更」を可能にする。
ここで、標的ユニットの一方向ハッシュ関数ハードウェアに関する更なる詳細を述べることが有用となるであろう。次に、図15を参照すると、後続の反復における一方向ハッシュ関数のためのシード値として、再帰的セキュリティプロトコルの1回の反復において生成されたデジタル署名動作の結果を使用可能な一方向ハッシュ関数ブロックの一実施形態が、図示されている。一実施形態では、標的ユニットの状態は、セキュア化実行モードで動作中であるかどうかに関連する限り、本明細書で「セキュア化モード有効化」ビットと呼ばれる、ハードウェアビット1570の値に反映可能である。
ここでは、このハードウェアビットのデフォルト状態は消去されてもよい(すなわち、標的プロセッサのデフォルト状態は、セキュア化実行モードにおいて動作することができない)。ある実施形態における、一方向ハッシュ関数ハードウェアブロック1561とのこのビットの交信は、2つに分けて説明されてもよい。第1の(非セキュア化)場合、「セキュア化モード有効化」ビットが、このハードウェアビットが設定されると(例えば、「1」に、しかしながら、また、あるアーキテクチャでは、ビットは、「0」の値を有するときに「設定された」とみなされてもよいことに留意されたい)、秘密ハードウェアキーの使用のみを可能にするゲートキーパーとして作用するため、秘密ハードウェアキー1540へのアクセスはすべて阻止される。また、この場合、デジタル署名レジスタ1564の出力がフィードバックされ、一方向ハッシュ関数1561の入力「シード」1510を形成する。したがって、プロセッサが、この「非セキュア化実行」モードにおいて実行中、一方向ハッシュ関数演算のいずれかの中間結果がフィードバックされ、任意の後続の一方向ハッシュ関数演算のためのシードを形成する。これは、ネスト化または連結された機能集合の呼出し連鎖全体に相当する自走チェックサムを維持可能にする。実行が試みられる各コードブロックが、実行が可能になることに先立って、この一方向ハッシュ関数によって、最初に評価される場合、任意の所与のコードブロックの呼出し連鎖全体が、実質的に、この単一メカニズムによって明確に決定可能である。
同様に、「セキュア化モード有効化」ビットが設定される場合(すなわち、プロセッサが、「セキュア化実行モード」で動作中の場合)、秘密ハードウェアキーは、アクセス可能である(言い換えると、直接アクセス可能、またはその値がプロセッサ自体によって直接アクセス可能ではない場合でも、少なくともその値は、計算動作において使用可能である)。加えて、セキュア化実行モードで動作時に、デジタル署名レジスタの出力は、一方向ハッシュ関数の後続の評価のためのシード値を形成するために、フィードバックされない。このデジタル署名発生器ブロックのまさにその実装については、後にさらに詳細に論じられる。次いで、理解されるように、ある実施形態では、特定のコードブロックの呼出し連鎖全体が、システム全体のソフトウェアまたはハードウェア照合(または、認証)動作等の手段を利用する必要なく、そのセキュアな実行に先立って照合可能である。タイムスタンプレジスタに関して上述の場合のように、ある実施形態では、この「セキュア化モード有効化」ビットは、プロセッサに対して構造上可視であってもよく、またはそうでなくてもよいが、その状態は、プロセッサによって、明示的に設定されなくてもよいことに留意されたい。このハードウェアビットは、非セキュア化コードセグメントを読み出すことによって、デフォルト値にリセットされ得るが、一実施形態では、このビットが設定可能な唯一の態様は、ハードウェアの一部への直接作用を介してである。ビットが、構造上可視である場合、プロセッサが、セキュア化実行モードで動作中であるかどうかを明示的に決定可能である。構造上可視ではない場合、それでもなお、決定は、その値がハードウェア秘密キーに何らかの形で依存する何らかの式を評価することによって、黙示的に可能である。
ここで、コード実行の制御およびセキュリティプロトコルの実装と密接な関係があり得る、主題に内在する基本的問題について、さらに詳細に説明することは、有用となるであろう。次いで、上述のハードウェアの実施形態を使用して、任意の汎用プロセッサ上の任意コードの実行の制御をどのように実装するか、ならびにこれらのシステムおよび方法の実施形態が、どのようにセキュリティプロトコルおよびシステムと効果的に併用され、効果的セキュリティシステム全体を構築し得るかを示すことが可能となる。
(秘密キーの隠蔽)
市販のデジタルコンテンツ送達システムの大部分は、デジタルメディアデータが自由に複製および配信されることを保護しようとする、ある形式の暗号化またはデータ隠蔽を含む。大部分の場合、データ隠蔽戦略は、最終的には、コンテンツ保護の完全に非効果的な手段であることがわかる。この隠蔽が不成功であることがわかる主要な理由の1つは、曝露から保護されるべきまさにそのデータが、それでもなお、任意の承認された当事者による使用に対して自由に利用可能でなければならないことである。したがって、一見矛盾した要件集合が、デジタルコンテンツの配信には存在する。
オリジナルデジタルコンテンツが、意図された受信者すべてに対して、別個に暗号化可能であって、意図された受信者のみが、配信されたデジタルコンテンツを利用し得る場合、システムのセキュリティは、潜在的に、非常に優れたものとなることが可能である。しかしながら、いくつかの特有の条件が合致しない限り、この種類のシステムのセキュリティは、いくつかの点において、不完全があることが示され得る。第1に、そのようなシステムは、配信されたデータ集合全体が、各意図された受信者に対して、別個に再暗号化されなければならないことを必要とする点において、あまり効率的ではない。第2に、配信者は、汎用プロセッサ上において、いかなる未承認の復号化も不可能であることを保証する必要があり得る。第3に、各個々の受信デバイスが、別の終点デバイスにおいては容易に複製(または、汎用プロセッサ上でエミュレート)できない、ある属性を保有しなければならないという点において、一意的でなければならない。これらの最後の2つの条件のうちのいずれかが侵害される場合、このシステムは、個々に暗号化されたデータだけではなく、そのデータと関連付けられたデバイス特有のキーの両方を傍受することによって簡単に攻撃を受けやすくなる。
実際、そのようなシステムのセキュリティは、受信デバイスのそれぞれの一意的な属性のセキュリティに基づき得ることが分かる。この一意的な属性は、一般的には、配信者および承認受信者のみに知られている秘密キーを使用して実装される。原則として、この種類の設定は、効果的セキュリティシステムであり得るが、オリジナルデジタルコンテンツが、各受信者に対して別個に暗号化されるという要件は、大部分の目的に対して現実の実装を非実用的にする。オリジナルデジタルコンテンツが一度暗号化され、潜在的に承認された当事者すべてに完全に同じように配信されることが望ましいならば、問題はデータ隠蔽へと逆戻りする。これらの種類の問題は、ブロードキャスト暗号化の分野として知られている。
ほとんどのあらゆる種類の配信された秘密データシステムが有する基礎的問題の1つは、大部分の場合、セキュリティシステムの別個のエンティティ間を行き来するメッセージおよびデータがすべて、通常、公に伝送され、したがって、盗聴者によって観察可能であることである。したがって、そのようなシステムの個々の構成要素間で伝送される、任意のメッセージまたはデータは、暗号化され、未承認当事者による傍受に対して保護されなければならない。そのようなシステムにおいて対処されなければならない別の問題は、任意のそのような秘密データ伝送において、送信者だけではなく、受信者の両方の身元の照合である。2人の当事者が相互に知らない場合、相互に信頼される媒介戦略が、一般的に採用される。
しかしながら、加えて、秘密データがその宛先に到達したときに対処されなければならない同様に困難な問題は、危殆化されない態様において、その秘密データをどのようにセキュアに使用するかである。この予防措置は、通常、合法的な終点であっても、それに偽情報を提供することによって、セキュリティを傷つけられ得る可能性があるので必要である。したがって、配信の際の未承認発見に対する保護に加え、時として、その他の点では承認されているユーザによってその秘密データが発見されることから、秘密データを保護することが望ましい。
一実施形態では、そのような望ましい制御は、構造上隠蔽されている秘密キーの単純な時間依存的な使用、または実行に先立ってリアルタイムで復号化されなければならない暗号化オブジェクトコードブロックを利用して、実装されてもよい。前者の場合、コードブロック実行は、制御メカニズムに対して完全に透明であり得、実行速度が最小の影響を受けるはずであることを意味する。後者の場合、起動されるコードブロックは、実行に先立って復号化されてもよく、したがって、復号化プロセスの呼出し時間に起因する性能の同時損失の可能性が最も高い。しかしながら、この後者の場合、オブジェクトコードは、分解されるおそれが比較的なく、したがって、潜在的に、可能性のある攻撃者による妨害はより困難である。後に本明細書において論じられる実施形態は、高度にセキュアな暗号化されたオブジェクトコードの方法から、比較的高度な性能であるが、それでもなお、依然として非常にセキュアな選択的に利用可能な秘密キーの方法に及ぶ、一連の可能性のある解決策において実装可能なシステムおよび方法を開示する。
一実施形態では、そのような秘密キーのユーザからの秘密キーの隠蔽は、ハーバードアーキテクチャメモリ空間分岐に類似する方法で達成されてもよい。しかしながら、本実施形態では、秘密キーが、暗号化/復号化計算において使用されてもよいが、プロセッサによって実際に直接読み取られることが決してないように区別がなされ得る。この区別は、ハードウェア内に実装されたもの、またはハードウェアの設計時に定められた所定のソフトウェアマクロ(また、マイクロコードとしても知られる)に、暗号化/復号化動作を限定することによって実施されてもよい。例えば、ハードウェア秘密キーが、任意のコードによって使用され得る場合、プロセッサによって直接読取り可能でない場合でも、それでもなお、単純計算によって容易に決定可能である。したがって、セキュリティ関連計算のみ、ハードウェア秘密キーにアクセスし、そのようなコードセグメントをより汎用的ではあるが、あまりセキュアではないコードブロックから差別化し得るように規定することが望ましいであろう。
この区別は、ある実施形態では、この明細書に説明されるものに本質的に類似する照合方法を利用して達成されてもよい。上述の適応デジタル署名方法の実施形態が、ハードウェア秘密キーがアクセスされ得るかどうかを決定するために利用される場合、標的プロセッサが、セキュリティ関連計算(すなわち、標的プロセッサが、「セキュア化実行」モードで動作時に行われる計算)およびセキュア化されていないものを実行中であるかどうかを容易かつ確実に決定可能である。加えて、上述のものに実質的に類似する再帰的方法を利用して、最終計算が完了し、完全に解読された結果が報告されるまで、任意の中間キー結果が発見されないように隠蔽されてもよい。したがって、本明細書に説明される実施形態は、同一ビットストリームを発生させるために使用される、秘密グローバルキーを曝露することなく、暗号化されたデジタルビットストリームを解読する能力を有してもよい。
(コード実行の制御)
特定のコードセグメントが、所与のプロセッサにおいてセキュアに実行されることを保証するための方法は、長年、広範囲に研究されている。セキュアなコード実行の保護をもたらすための以前の試みのいくつかとして、「特権的」命令集合を確立するために、プロセッサアーキテクチャに書換えを行うことが挙げられる。これらの特権的命令は、プロセッサが「監視者」または「カーネル」モードとして知られる、特定のモードで起動中にのみ、これらの特権的命令が実行可能であるようにアーキテクチャを設計することによってセキュア化されていた。この種類のプロセッサアーキテクチャの分岐は、プロセッサの汎用性の潜在的損失だけではなく、潜在的性能の劣化を含むいくつかの欠点を有する。これらの欠点に加え、そのような保護手段は、多くの場合、プロセッサが監視者モードで実行中、想定外の実行パスを利用するように、標準システムルーチンに対して、特異的に設計されたソフトウェア読み出しを使用することによって迂回可能である。そのような特異的に設計されたマルウェア攻撃の実施例として、いわゆる「スタックオーバーフロー」、「スタックオーバーラン」、および「コードインジェクション」攻撃が挙げられる。
これらの種類のセキュリティ上の弱点に対する保護を支援するための試みにおいて、主に、チェックサム照合または引数上下限検査の種々の手段に基づいて、いくつかの戦略が考案されている。これらの種類の保護手段にもかかわらず、多形性ウイルス(すなわち、自己書換えコード)を含む、種々の対対抗手段が進化している。上下限検査にもかかわらず、プロセッサの脆弱性を悪用するための別の戦略として、上下限検査「監視者」ルーチン自体を単純に迂回することが挙げられる。また、この種類の搾取は、種々のコピー保護システムを回避する際に、頻繁に使用される。結局、監視ルーチンを奪取する戦略は、コンピュータセキュリティの世界にとって一意的ではなく、全く新しい概念ではない。実際、正にこの問題は、種々の用途において類似点を有し、Platoの文献「The Republic」にまで遡って参照されている。基本的問題は、任意の所与のシステムにおいて、最終的なセキュリティまたは構造の安定性が委ねられるある種類のグローバルな監視者を常に識別可能であることである。あらゆる後続のセキュリティ機能に対するグローバルな基礎についてのそのような概念は、「Root−of−Trust(信頼の基点)」として、セキュリティシステムの最新の研究において知られている。
より最近では、プロセッサが、本質的に読取り専用である命令をそこから取り出すメモリセグメントを制限することによって、プロセッサを監視ルーチン攻撃から保護する試みがなされている(これは、いわゆるW^Xまたは「write−XOR−execute」アプローチを含む)。データベースのパーティションと、コードベースのパーティションとに、その他の点では汎用であるコンピュータのメモリ空間を分割する概念は、いわゆる「Harvard Architecture(ハーバードアーキテクチャ)」の変形例として示され得る。この方法は、保護メカニズムだけではなく、メモリ利用の同時増加と関連付けられたある性能に不利な条件を有する。最後に、最近、これらの種類の防護でさえも、いわゆる「戻り値ベース」のプログラミングのセキュリティ上の弱点の使用によって、または2つの別個の実行スレッドが、異なるモード(一方は、「データモード」、他方は、「実行モード」)において、メモリの同一ブロックを参照可能である、単純なメモリ−エイリアシングのセキュリティ上の弱点によってさえ回避可能であることも示されている。
プロセッサの実行スレッドが奪取されることを保護する別の提案される手段として、暗号化されたコードブロックの使用が挙げられる。この方法では、実行されるコードセグメントは事前に暗号化され、したがって、プロセッサへのそれらのロードの前には読取り不可能である(おそらく、さらにより重要なこととして、改ざん不可能である)。また、この方法は、いくつかの脆弱性を有する。第1に、コードセグメント自体が、保護され得るが、引数は、必ずしも同一レベルのセキュリティを備えていない。したがって、完全に合法かつセキュアなコードセグメントは、それでもなお、予想外の方式で挙動させることが可能な、その呼出しルーチンからの偽引数を備え得る。第2に、ある場合には、実行スレッドは、必ずしも、上述の戻り値ベースのプログラミング攻撃に対して保護されていない。また、プロセッサバスが、攻撃者によって容易に観察可能である場合、正確に実行される(暗号化されていても)コードセグメントの長期観察だけではなく、実行可能ストリームに投入される不適切に暗号化されたコードセグメントによって生じる例外欠陥の観察が、書き換えられた辞書攻撃方法を使用して、暗号化キーを明らかにすることに有用となり得る。最後に、そのようなシステムにおけるプロセッサ性能は、必然的に、類似するが、暗号化されていないコードシステムよりも大きく低下させられる。この性能上の不利な条件は、いくつかの問題によって生じ得、その最も重要なものは、メモリから取り出されるときと、実行されるために利用可能となるときとの間のコードブロックの必須復号化によって被る待ち時間である。最新のプロセッサは、パイプライン方式メカニズムを使用して、並行して実行可能な命令の数を増加させようとするが(種々の手段によって)、暗号化されたコードのブロックは、最初に復号化されるまで、そのようなパイプラインに読み込まれることは不可能である。コードが頻繁に分岐する場合、復号化プロセスは、潜在的に、ハードウェア支援復号化によってさえ、コード実行自体よりもさらに時間がかかり得る。
本発明に説明されるシステムおよび方法の実施形態は、非暗号化コードブロックの利用を可能にし得、したがって、暗号化された実行ファイルと関連付けられた性能上の不利な条件は、あまり問題とならない。しかしながら、実行効率が重大な懸念ではない場合、暗号化されたコードブロックが、依然として利用されてもよい。したがって、本明細書に開示される実施形態は、プレーンテキスト実行ファイルの効率だけではなく、同一または類似の方法およびシステムを利用して、暗号化されたコードセグメントの追加のセキュリティの両方を有し得る。加えて、本明細書に説明されるセキュリティシステムおよび方法の実施形態は、その場でアップデートされ、新しく発見されたセキュリティ上の懸念を解決するだけではなく、実施形態が既に配備された後においても新しい機能を追加することが可能である。
本発明の実施形態は、とりわけ、「セキュア化コードセグメント」が、暗号学的ハッシュ関数によって、実行に先立って照合されることを保証することによって、これらの利点を成就し得る。この照合は、例えば、そのようなセキュア化コードセグメントのために生成されたメッセージダイジェストまたはデジタル署名を認証することによって達成されてもよい。この暗号学的ハッシュ関数の評価が、デジタル署名を形成するために、上述のように、複合キー構造を使用して、結果として生じるメッセージダイジェストの暗号化と併せて生じる場合、特定のコードブロックは、特有の標的ユニットまたはプロセッサと一意的に関連付けられることが可能である。このプロセスは、ある実施形態において、このセキュア化コードブロックが、デジタル署名に基づく複合キーを使用して、特定の標的ユニットに暗号学的に結合することが可能であるという事実に基づいて、本明細書では、「セキュア化コード結合」と呼ばれる。
そのようなハッシュ関数の実行は、リソースフリーであってもよいが、このアプローチの利点は、セキュア化コードセグメントが、その暗号学的照合の完了の前に、実行パイプラインに導入可能であることである。したがって、ハッシュ関数は、潜在的に、セキュア化コードセグメント自体の実行と並行して評価可能である(推論的分岐実行に類似する方式において)。この実施形態では、セキュア化コードセグメントの結果は、結果として生じるメッセージダイジェストが本物であると決定される場合にのみ利用されてもよい。しかしながら、別の実施形態では、セキュア化コードセグメントの結果は、後続の動作において利用されてもよいが、結果自体が、プロセッサがセキュア化実行モードで動作しているかどうかに応じて、異なってもよい。この実施形態は、デジタル署名において使用するための複合キーの評価に関して上述のプロセスに実質的に類似し、図15に図示されるようなハードウェアの使用によって生成することが可能である。
しかしながら、暗号学的照合の使用は、暗号化されたコードセグメントの使用を妨げるものではない。実際、正確に復号化されたコード(任意の種類の暗号化を適用する前のそのオリジナル状態において、セキュア化されているコードセグメント)のメッセージダイジェストまたはデジタル署名の使用は、付加的レベルの保護を提供し得る。これは、潜在的な攻撃者が、偽造メッセージダイジェストを生成するためには、正確に復号化されたコードブロックの演繹的知識を有する必要があるだろうという事実によるものである。したがって、コードセグメント照合だけではなく、暗号化されたコード方法の両方が同時に使用可能である場合に、攻撃に対してより高いロバスト性が実現され得る。
しかしながら、また、理解され得るように、そのようなハッシュ照合を迂回可能ないくつかの方法が存在し、その最も単純なものは、ハッシュ関数自体を妨害することであろう。この戦略が、ある実施形態について不可能であることが想定される場合でも(例えば、ハードウェアハッシュ関数を利用することについて)、適切に照合されたメッセージダイジェストとともに偽りのコードセグメントを提供することによって、依然として、そのような実施形態のセキュリティを攻撃することが可能であり得る。多くのメッセージダイジェストは、実際に、暗号化され、デジタル署名を形成するので、表面上、この攻撃戦略は、一見、困難であることがわかるであろう。しかしながら、デジタル署名メカニズムでさえ、デジタル署名の公開キー検索部分をスプーフィングし、したがって、偽りのデジタル署名の人為的照合を提供することによって、または代替として、署名照合ルーチン自体の悪質な破壊によって、潜在的に攻撃され得る。
これらの制限は、セキュア化コードセグメントと関連付けられたメッセージダイジェストを二重に暗号化することによって、本明細書に開示されるシステムおよび方法の実施形態において克服される(一度目は、(グローバルな)「著者の」秘密キーによって、次いで、再度、終点「製造業者」(実際には、オリジナルチップ製造業者ではなく、二次レベルの配信者、システムインテグレータ、サービスプロバイダ等であり得る)および当該コードセグメントが実行される特定の終点デバイスにのみ知られている秘密キーによって)。この実施形態の利点は、上述のデジタル署名が、類似した終点デバイス間で共有される場合でも、異なる標的ユニットの秘密キーが異なるので、その意図された標的ユニットにおいてのみ正確に機能することである。したがって、任意のそのようなデジタル署名は、暗号化されていない状態で伝送かつ格納可能である。
秘密キーを二重に暗号化する技術(いわゆる「階層化キー」システムだけではなく、再帰的セキュリティシステムにおいても使用され得る)の実施形態は、不正確に使用される場合、ある問題を有し得る。第1に、そのような階層化暗号化プロセスの中間結果が傍受されると、この中間キーを使用してそのようなシステムの一部または全部のより高いレベルのセキュリティを迂回可能である。また、そのような階層化システムの「最下層」においては、この中間結果が、実際に発見されると実質的に類似した終点デバイスすべてに対するセキュリティシステム全体を迂回するために使用可能である「グローバル」復号化キーであることに留意されたい。この種類の「傍受」攻撃が、復号化プロセスの際に、任意のメモリトランザクションを単に注視し、次いで、潜在的グローバル復号化キーのそのような記憶場所すべてを検証することによって、1回以上生じ得る。復号化プロセスの際のメモリアクセスすべてを注視するプロセスは、最初は、煩わしく思われ得るが、ほぼ確実に、そのような秘密キーの値の総当たりによる推測よりも効率的な攻撃戦略である。階層化キーシステムにおける第2の潜在的な脆弱性が、リプレー攻撃の改良型によって悪用可能である。階層化キーシステムのセキュリティが危殆化され、そのキーがアップデートされなければならない場合、古い(危殆化された)キーは、依然として、オリジナルシステムがその以前の状態にリセットされるとき、またはその以前の状態が、偽りのユニットによってクローン化されるとき、使用され得る。
これらの脆弱性は、「階層化キー」構造とは対照的に、「複合キー」と呼ばれるものを使用して、本明細書に論じられる実施形態において解決され得る。複合キーと階層化キーとの間の主要な相違の1つは、前者のセグメントがすべて単一モノリシックパスにおいて評価され得ることである。対照的に、階層化キーシステムでは、「最外」層キーを最初に評価することが可能であって、次の最内キー(これは、次に、引数として使用され、キースタック全体がトラバースされるまで次の層のキーを生成する)に戻る。このシステムに伴う問題は、より低いレベルのキーが傍受かつ後に使用され、効果的に最外セキュリティ層を迂回可能であることである。したがって、そのような階層化キー実施形態においては、最も重要な(この場合、グローバル)キーは、連鎖内において最後に生成され、使用されるものであって、ここにおいて、任意の付加的な(または、より新しい)層のセキュリティは完全に欠如している。
この理由から、そのようなセキュリティスタックをトラバースするためのよりロバストな方法が利用されて、「インサイドアウト」からトラバースされ得る。これは、セキュリティ連鎖への最も新しい追加物が、順序通り最初に実行されるが、実際は、セキュリティシステムの最内層に位置するものであることを意味する。故に、実施形態を使用して、そのような「インサイドアウト」の実行順序が実施され得る。この特定のコードスタックトラバーサルの順序は、単純反復アプローチを使用して達成可能であって、そこでは、コードループは、最初に現在のセキュリティレベルを評価し、次いで、それに従って、分岐する。しかしながら、反復方法では、セキュリティシステムトラバーサルの中間結果は、上述のように、攻撃者が、次のより低いレベルのキーが合法セキュリティシステムトラバーサルにおいて曝露されることを単に待機し、次いで、その傍受したキーを使用して、システムの偽造「初期」バージョンをクローン化し得るので、潜在的に、迂回可能である。したがって、システムおよび方法の実施形態は、この「インサイドアウト」実行順序を実施するだけではなく、また、中間結果が悪質なコードまたは他の周知のセキュリティシステムのセキュリティ上の弱点によって傍受されることから保護可能であるように説明される。
そのような「インサイドアウト」セキュリティアプローチを使用する場合の別の主要利点は、呼出し引数のシーケンス全体が、セキュリティシステムの最内層(したがって、最も新しいバージョン)に対して可視であり得ることである。この「インサイドアウト」実行シーケンスが、適切に実装される場合、そのようなシステムで採用される正確に構築された上下限検査メカニズムが、呼出し連鎖全体にわたって可視性を有し得ることが分かる。したがって、実施形態は、通常、そのような機能と関連付けられる任意の付加的性能上の不利な条件を被ることなく、相当量のシステム認証機能を行うための内蔵メカニズムを有してもよい。
故に、ある実施形態は、中間キーがより高いレベルの(したがって、あまりセキュアではない)セキュリティシステムルーチンに曝露されることを防止するだけではなく、適切なセキュリティスタックトラバーサル方法を保証するための手段を利用してもよい。これを達成するためのそのような方法の1つは、再帰的セキュリティ構造の使用であって、その一実施形態は、2003年6月19日に出願され、その後、2007年4月10日に米国特許出願公開第7,203,844号として発行されている、William V. Oxfordによる米国特許出願公開第10/465,274号「Method and System for a Recursive Security Protocol for Digital Copyright Control」に図示されており、あらゆる目的のために、参照することによって本明細書に組み込まれる。
そのような再帰的セキュリティプロトコルの実施形態が利用される場合、ある利点が実現され得る。第1に、スタック順序トラバーサルは、「インサイドアウト」から評価されなければならないように設計可能である。これは、最も新しいセキュリティシステムの追加が、最初に実行され、システムは、「途中から開始」不可能であることを意味する(例えば、「戻り値ベース」のプログラミングのセキュリティ上の弱点において使用されるように)。再帰的システムの第2の利点は、セキュリティシステムへの任意のアップデートの追加が、セキュリティシステム自体において、オリジナル呼出し引数を変更できないことである。故に、従来のリプレーベースの攻撃メカニズムを使用することによって、セキュリティシステムをスプーフィングすることはより困難となり得る。本明細書に開示される実施形態の場合、反復方式において、逆の順序でインライン実行スタックを採用することが確実に可能であるが、反復メカニズムは、割り込みを受け得、したがって、また、セキュリティスタックの部分的評価が行われる環境をもたらすことも可能であり得る。これは、潜在的に、外部観察者によって、1つ以上の中間結果が傍受されることを可能にするであろう。本明細書の実施形態によって利用され得るように、再帰を介して実装されるインサイドアウトセキュリティシステムでは、中間結果は、引数として、任意の時点において、次のレベルのルーチンにパス不可能であって、現在実行されているセキュリティシステム層の最終結果のみが、セキュリティシステムスタックの次の上位レベルで利用可能である。
また、複合キー構造は、ある実施形態では、標的ユニットの秘密キーへのアクセスを厳密に制御することによって、部分的評価から保護されてもよい。例えば、秘密キーが、構造上可視ではないアクセス不可能な記憶場所内に格納されている場合、特定のセキュリティ関連命令または機能の一部としてのみアクセスされてもよい。ある実施形態では、この機能または命令は、非自明な一方向変換等、容易に反転され得ないものである。そうすることによって、偽造セキュリティシステムさえ、秘密キーの値を明らかにすることが不可能であるはずである。その結果、一方向機能の一部として、秘密キーを間接的に参照のみさせることによって、秘密キーは、数学的動作の一部として、それ自体では決して使用可能ではなく、単独で、またはある別のデータとともに、ハッシュ動作の一部としてのみ使用可能であって、そこでは、ハッシュ関数の結果のみが観察可能であり得るので、秘密キーは保護され得る。
また、秘密キーを保護するための付加的メカニズムが、ある実施形態では、有用であることがわかり得る。そのような潜在的メカニズムの1つは、複合キーの使用であって、そこでは、標的ユニットの秘密キーは、ある別の制約または付加的オペランド集合に厳密に結合される。そのような二次オペランドの実施例として、別個の秘密キー、グローバル的可視レジスタ(タイムスタンプまたはシステムバージョン番号等)、秘密キーにアクセスするコードのメッセージダイジェスト等を含んでもよい。そのようなシステムの実施形態では、この最後の実施例は、秘密キーが、その全く同一キーを使用するために承認される、コードのセグメントによってのみアクセスされてもよいことを保証し得る。さらに、メッセージダイジェストが暗号化され、デジタル署名を形成する場合、かつそのメッセージダイジェストを暗号化するために使用されるキーが、秘密キー自体である場合、秘密キーにアクセスする唯一の方法が、その秘密キーが何であったかを既に知っている者によって作成されたコードセグメントを使用することであることを保証可能なように、依存性の循環を生成することが可能である。
この場合、複合キー構造の使用は、そのキーを使用可能にする前に、標的ユニットの秘密キーの使用を要求する、コードの一部の「権限」を照合させる。「階層化キー」構造と「複合キー」構造との間の差異は、ある実施形態においては、後者は、それ自体が再帰的手段によって達成可能である解剖学的方式で評価され得ることであることを思い起こされたい。再帰的構造とは対照的に、反復アプローチを使用して類似構造のアセンブルを試みる場合、キー評価プロセスの中間結果を曝露する(したがって、潜在的に、秘密キーを曝露する)危険性があり得る。この「曝露」は、秘密キー(または、それらの原体)が、割り込みが生じるとメインメモリに押し出される、汎用レジスタ等の公的に利用可能な場所に格納されるときに(または、直接メモリ自体内でさえ)生じ得る。
ある実施形態において解決され得る潜在的セキュリティの崩壊は、セキュリティスタック動作が、評価中に割り込まれ、次いで、標的ユニットのプロセッサの状態が、外部観察者によって検証を受けやすいメインメモリに書き出されるときの部分的結果の保護である。一実施形態では、このメモリ「曝露」を防止するために、プロセッサがセキュア化実行モードにある間、ヒーププッシュは拒否される。その条件が実施される場合、再帰的セキュリティプロトコルは、その現在の状態を損失することなく、割り込みは不可能である(中間引数が存在しないため)。再帰的セキュリティプロトコルの実施形態では、セキュリティプロトコル全体は、再帰が終了し、プロセッサがセキュア化実行モードで起動しているときにトラバースされ、したがって、割り込み以外のいかなる場合でも、ヒープへの任意の引数のさらなるプッシュは存在し得ないことに留意されたい。したがって、複合キー評価が、任意の時点で割り込まれる場合、かつ、ヒーププッシュがセキュア化実行モードにおいて拒否される場合、セキュリティシステムスタックトラバーサルは、実行中に再開できない(すなわち、計算は、最初から再開しなければならない)。したがって、再帰的セキュリティプロトコルは、任意の中間結果がシステムヒープ上に格納される(したがって、潜在的に、未承認観察者に曝露される)ことを防止するように使用可能である。当然ながら、ある実施形態では、反復セキュリティシステム評価の際、ヒープ動作を無効にすることが可能であって、したがって、効果的に、そのような割り込されたセキュリティシステム動作が、最初から再開されなければならないことを要求する。しかしながら、そのような反復アプローチは、「インサイドアウト」実行順序、「戻り値ベースの」プログラミングのセキュリティ上の弱点に対する保護、オリジナル機能に対して、呼出し引数を改善しないように、後続のセキュリティ層に追加する能力だけではなく、中間結果および最終機能出力結果の隔離等、再帰的構造が提供する条件のすべてを施行しない場合がある。セキュリティシステム再帰が終了し、プロセッサがセキュア化実行モードに入ることが許可されるメカニズムについては、より詳細に後述される。
(再帰の終了)
一実施形態では、再帰は、所与のコードセグメントのメッセージダイジェストが、コードセグメント自体とともに供給されたものと整合すると、終了するように信号伝達可能である。この方法論は、メッセージダイジェストが、ハードウェアハッシュ関数によって計算される場合、攻撃に対してよりロバストになり得る。また、ある実施形態では、デジタル署名が利用されてもよい。デジタル署名メカニズムは、1)コードセグメントが改ざんされていないことの保証と、2)コードセグメント著者の即時識別の少なくとも2つの主要属性を提供する潜在性を有する。しかしながら、そのようなデジタル署名が、公的に可視または書換え可能場所にキャッシュされる実施形態の場合、デジタル署名自体が、任意の時間に書き換えられ、したがって、必ずしも、本物ではない可能性があるので、付加的セキュリティが望ましいであろう。したがって、これらの種類の実施形態においては、公開キーシステムを使用して、デジタル署名を照合してもよく、または複合キー構造(上述のように)を使用して、当該コードセグメントを備えるデジタル署名が、標的ユニットの秘密キーを所有していたある当事者によって作成されていることを保証してもよい。後者の場合、また、複合キーの使用は、単一終点またはある終点集合に限定されてもよい。加えて、公開キーだけではなく、複合キーアプローチの両方を併用してもよい。その態様では、コードセグメントが本物であることだけではなく、コードセグメントが複合デジタル署名の受信者のために意図されたものであることの両方を保証可能である。
また、ある実施形態においては、標的ユニット上のセキュリティメカニズムを照合することが望ましいであろう。標的デバイス上のセキュリティシステムの任意の1つのセグメントに対して、ハードウェア生成デジタル署名が利用されてもよいが、セキュリティシステムが再帰的である場合、個別デジタル署名が、セキュリティシステム自体がトラバースされることに伴って、実質的に、自動的に生成され得る。上述のように、再帰的セキュリティプロトコルの実行が終了すると、呼出し連鎖全体が曝露される。したがって、セキュリティプロトコルの最内(したがって、最も新しい)部分は、潜在的に、スタック上に格納された呼出し引数だけではなく、システムヒープ(または、さらにメモリ内のいずれかの場所)内に格納される別の環境変数を含む、呼び出される環境全体へのアクセスを有する。この内蔵システム認証メカニズムは、特に、セキュリティプロトコル自体のトラバーサルと同時に評価されるので、効率的であるだけではなく、攻撃に対してロバストである。
一実施形態においては、次いで、セキュリティシステムスタックトラバーサルの「実行段階」の前に導入されていなければならない条件集合が、規定され得る。一実施形態では、これらの条件は、個々に要求されるセキュリティ条件のすべての「共通集合」として表現可能である。そうすることによって、新しいセキュリティの危険性が発見されるとき、それらの危険性を考慮する付加的条件が、容易に導入され得る。これらの条件は、セキュリティシステムのいかなる部分も、新しいのも、古いのも、条件すべてが合致するまで、実行されないように保証可能である。種々のセキュリティシステム条件のこの「共通集合」は、上述のように、複合キー構造メカニズムの使用を通して達成可能である。例えば、そのような複合キー構造の構成要素の1つが、部分的に、標的ユニットの秘密キーに基づく場合、この秘密キーは、セキュリティシステム全体の「信頼の基点」の1つとしてみなされ得る。さらに、ハードウェアベースのタイムスタンプメカニズムが、複合キーの他の構成要素の1つとして利用される場合、システムは、リプレー攻撃に対してより保護され得る。ある実施形態では、他の条件を実施するために、上述に加え、ある実施形態において採用され得るいくつかの構成要素が存在する。そのような構成要素は、コードが改ざんされている場合、キーを適切に評価されることを防止するために、複合キーの一部として、コードブロックのメッセージダイジェストのハードウェアベースのハッシュ計算の使用を含む。一実施形態では、別のそのような構成要素は、スタックオーバーフロー型攻撃に対して保護し得る、実行されるコードブロックの呼出し引数のある選択されたサブ集合のデジタル署名であってもよい。
コードセグメントが、タイムスタンプまたは使用関連制限等、その実行に関する他の制約を有する場合、ある実施形態においては、さらなる条件が複合デジタル署名に追加され、それらの制約もまた適切に実施されていることを保証することが可能である。また、この同一メカニズムを使用して、中間セキュリティトークンの正確な評価に基づいて、システムの各層内で適切なコード分岐を実施することによって、種々のセキュリティスタック層を通して、特有の複数の反復を強いることが可能であることに留意されたい。
上述のように、再帰的セキュリティシステムの実施形態は、条件のすべてが、セキュリティトークンの評価開始に先立って導入されていることを保証することが望ましいある実施形態において、有利である。したがって、インサイドアウトセキュリティスタックトラバーサルを実施するその能力および中間結果の可視性に関する制限を有する再帰的システムは、最小に破壊的な方式において、セキュリティシステム評価に関してより制約を追加することが望ましいとき、外部攻撃に対する向上したロバスト性だけではなく、柔軟性を提供することが可能である。
ここでは、セキュリティシステムスタックの再帰的トラバーサルは、必ずしも、アルゴリズム的フロー全体に対する再帰的形式と等しいわけではないことに留意されたい。したがって、セキュリティシステムの論理的フローおよびシステムのセキュリティシステムを利用するコードスレッドの論理的フローは、完全に異なってもよい。
加えて、ある実施形態では、特定のコードセグメントが解析されることに伴って、デジタル署名がどのように書き換えられるかを規定する機能集合を含むことによって、デジタル署名がどのように使用されるかの柔軟性が向上させられ得る。例えば、コードセグメントが、第1の反復後、デジタル署名を不変のまま解析プロセスを通過させる場合、そのコードセグメントは、セキュリティシステムが何回特定のコードブロックを循環するかを事前に規定する必要なく、照合可能である。同様に、デジタル署名は、特定のコードセグメントに直面することに伴って、既知の「シード」状態にリセットされるように規定可能である。したがって、単に、単一の一意的数(暗号化されていない状態で格納可能)を供給することによって、セキュリティシステムの種々の部分が、何回およびどの順序でトラバースされるかの一意的変動が、規定されてもよい。実際、そのようなコード照合プロセスを使用して、種々の有用な機能を実装可能であって、したがって、この技術は、必ずしも、セキュリティシステム自体の排他的使用に限定される必要はない。
適切なデジタル署名が、一般的コード(セキュリティの実装に関連し得る、またはし得ないコード)を備える場合、コードのその特定のブロックが、特有の標的ユニット上で実行される態様は、非常に特異的に制御されてもよい。これは、一般的コードを標的デバイス集合にセキュアに分配するために使用可能な、非常に強力なメカニズムである。この分配方法は、例えば、効果的にアプリケーションへの無料または有料アップグレードに、またはソフトウェアウイルスおよび他の望ましくないマルウェアの拡散を管理するために効果的に適用されてもよい。この後者の実施形態では、再帰的セキュリティシステムを使用して、標的デバイス上での実行のための候補であるあらゆるコードブロックを照合可能である。したがって、マルウェアアプリケーションまたは以前に認証されたコードセグメント上の多形性ウイルス攻撃さえ実行が防止され得る。
ハードウェア依存性をセキュリティシステム評価に組み込む能力を提供するために、ある実施形態においては、ハードウェア実装バージョン番号が、デジタル署名評価の複合構成要素の1つとして利用されてもよい。セキュリティシステムが書き換えられる度に、ハードウェアバージョン番号が、アップデートされる場合(かつ、そのアップデートがセキュアである場合)、セキュリティシステムが、実行されている標的ユニットと整合されることを保証することが可能である。これは、上述のタイムスタンプメカニズムと異なるが、複合キー評価において、2つを併用し、リプレー攻撃シナリオまたは他の侵害に対して保護し得ることに留意されたい。
例えば、我々の複合キー構造の一部として、JTAG署名等のハードウェア導出チェックサムを使用する場合、ハードウェア実装自体が認証されてもよい。次いで、この種類のメカニズムは、ソフトウェアおよびハードウェアが整合された対であって、ハードウェアが本物である(または、改ざんされていない)ことを保証し得る。さらに、複合キー評価の一部として使用されるJTAG署名が、直接観察可能ではない場合(例えば、その状態が、外的に可視でもなく、構造上可視でもない場合、スキャン連鎖のある時点から求められる)、ハードウェアのクローン化に基づく潜在的攻撃をマウントする困難性は、数倍も高まり得る。この戦略は、例えば、デバイスの個々の通し番号が、このスキャン連鎖に含まれる場合、効果的となり得る。
ここでは、プロセッサの観点から、本質的に、暗号化されたコードブロック(直接実行可能ではない)と「アップデートされていない」コードブロック(正確なデジタル署名整合を前提として、可能性として同時に実行可能であり得るが、そのデジタル署名は、もはや有効ではないので、もはや実行可能ではない)と間に論理的差異は存在し得ないことに留意されたい。このシナリオは、例えば、標的デバイスのタイムスタンプレジスタが変更されたため、または代替として標的デバイスのハードウェアがある未承認態様において書き換えられた場合に生じ得る。
したがって、特定のコードブロックが、アップデートされたバージョンと置換される場合(両方とも、潜在的に、実行可能であっても)、一実施形態では、これを達成するための単純ではあるが、さらに効果的方法は、最初に、当該コードブロックのための復号化キーポインタを、コードブロックの古いバージョンをアップデートされたバージョンと置換するための手段につながる新しいポインタと置換し、次いで、標的終点デバイスのタイムスタンプレジスタをアップデートすることであり得る。ここでは、アップデートされたタイムスタンプレジスタ値は、古い値を使用して生成された以前のデジタル署名すべてを無効にし、したがって、セキュリティシステム全体が更新され(理想的には、セキュアな態様において)、最新の状態にし、古いデジタル署名(または、キー)を新しいキー/デジタル署名値およびアップデートされた機能と置換することを伴い得る。これは、終点デバイスのタイムスタンプレジスタ内に格納された値への単一の変更によって容易に影響を受け得る、非常に強力な(かつ、潜在的に、非常に広範囲に及ぶ)メカニズムである。この場合、終点タイムスタンプレジスタ値が、非セキュアまたは無謀な態様において変更されないように注意を払う必要がある。そのような強制アップデートシナリオの一実施形態は、暗号化の層をその他の点では直接実行可能なコードブロックに追加する(単に、単一デジタル署名不整合を強いることによって)ことと論理的に同等とみなされ得る。
(セキュア化モードおよびセキュア化コード結合)
システムが、上述のように、構造上不可視である秘密キーの1つを利用する実施形態では、そのようなキーを利用するコードは、これらの秘密キーが危殆化されることを防止するように設計されなければならない。上述のように、セキュア化コード結合メカニズムを使用して未承認態様で使用される際に、特定の終点デバイスにおいてその他の点では合法であるコードブロックの正確な実行を防止可能である。
一実施形態では、このセキュア化コード結合は、特有の種類のハッシュ関数を候補コードセグメントに適用する結果が、コードセグメントが実行可能となる前に、そのコードセグメントを備えた特別に事前に決定されたメッセージダイジェストと整合しなければならないという要件に基づいている。このハッシュ関数は、候補コードセグメントが読み出された後、実行が可能となる前に適用されてもよい。このハッシュ関数が開始されると、候補コードセグメントを備える、その特定のメモリ空間へのいかなる書き込みも、無効化または無視され得る。候補コードセグメントが、CPUの命令キャッシュ内等のCPU実行ユニットと同一チップ上に位置する場合、これは、容易に実装され得る。しかしながら、マルチプロセッサシステムでは、例えば、I−キャッシュが、同一チップ上に常駐する2つ以上のプロセッサ間に共有され得る場合、見た目ほど実装は単純ではないであろう。メッセージダイジェストが算出された後に、コードが書き換えら得ることを防止するための別の潜在的方法は、ハッシュ関数が開始された後に生じる、そのメモリ空間へのいかなる書き込みの試みも、プロセッサ割り込みを生じさせるように、システムを構成することである。上述のように、これは、プロセッサのセキュアな実行モードをそのデフォルトの初期「非セキュア」モードにリセットし得る。そのような侵入に対する別の対応は、例えば、メモリセグメンテーション違反を開始することによって、エラーによってセキュア化実行スレッドを決定させることであろう。
候補コードセグメントの計算されたメッセージダイジェストが、候補コードセグメントとともに受信した事前に決定されたメッセージダイジェストと整合する場合、候補コードセグメントは、「セキュア化モード」または「セキュア化実行モード」と呼ばれるもので実行可能となる。上述のように、セキュア化モードで動作中のコードのみ、構造上不可視の秘密キーを利用可能である。特定のコードセグメントが、セキュア化モードで動作していない場合、秘密キーは、無効化され、それらの1つに対する任意の参照は、ある他の値(ゼロ等)を返すであろう。
ある実施形態においては、候補コードセグメントのためのメッセージダイジェストを計算する差異に利用されるハッシュ関数は、ある特性を有し得る。第1の特性は、ハッシュ関数が、標的ユニットのハードウェア内に実装され得ることである。これは、この機能が、このオリジナルハードウェアハッシュ関数のある別の(おそらく破壊された)バージョンによって、完全に置換できないことを意味する。このハッシュ関数は、所望に応じて、オリジナル機能の改良バージョンによって補完(または、条件付き完全置換さえ)されてもよいことに留意されたい。一実施形態では、ハードウェアハッシュ関数を改良バージョンと置換する方法は、セキュリティシステムの構造の再帰的定義を介して新しい層をセキュリティシステム内に挿入するために使用される、上述の手順と実質的に類似するであろう。しかしながら、この場合、新しいハッシュ関数が、あらゆる後続のセキュリティシステム動作の目的のために、オリジナル機能を置換可能である場合でも、この新しいハッシュ関数自体は、依然として、その信頼の基点の基礎として、オリジナルハードウェアハッシュ関数に依存し得ることに留意されたい。したがって、用語「条件付き完全置換」が使用される。一実施形態では、オリジナルのハードウェアベースの信頼の基点は、一定のままであってもよい。これは、そのようなハードウェアベースのセキュリティシステムを攻撃することが非常に難しくなり得るという点において、望ましいであろう。しかしながら、オリジナルハードウェアハッシュ関数における欠点が、標的デバイスが現場に配備された後に見つかる場合、そのような欠点は、潜在的に、呼出し引数を効果的に制限可能な単一アプリケーション内においてオリジナルハッシュ関数を使用することによって含有され得る。
ハードウェアハッシュ関数の第2の特性は、構造上不可視の秘密キーをそのシード値として使用し得ることである。したがって、同一入力引数を前提とする場合でも、そのようなハードウェアハッシュ関数のメッセージダイジェスト結果は、ユニット毎に異なり得る。この差異は、あらゆる標的ユニットに対して一意的なメッセージダイジェストをもたらし得るという点において活用されることが可能である。この特性は、デジタル署名の概念と類似するが、必ずしも、ハードウェアハッシュ関数に対して、別個の暗号化/復号化ブロックの追加を要求しない。次いで、候補コードセグメントは、ハードウェア生成メッセージダイジェストが、候補コードセグメントとともに分配されるものと整合するユニット上のみでの実行(少なくとも、セキュア化モードにおいて)に制約されるので、循環依存関係が生成される。この循環依存関係は、そのメッセージダイジェストが、正確な標的ユニットの秘密キーによって生成されたコードのみが、実際に、この同一秘密キーを利用可能であることを意味する。この特性は、標的デバイス上においてセキュア化モードで実行可能となるコードセグメントを生成する、可能性のある攻撃者の能力を実質的に損なわせる。
コードセグメントは、特定の標的デバイス(または、さらに特有の終点デバイス集合)に「結合」可能であるので、上述のメカニズムは、「セキュア化コード結合」と呼ばれる。上述のように、セキュア化コードの実行ブロックが割り込まれると、コンテキストは保存されず、したがって、このコードセグメントの実行は中止されるか、または最初から再開されなければならない。また、セキュア化モードにおけるコードセグメントの実行が割り込まれると、プロセッサは、もはやセキュア化モードで動作せず、構造上不可視の秘密キーへの任意のアクセスは、プロセッサがセキュア化モードに戻るまで、遮断され得る。また、ある実施形態においては、任意のオフチップ格納動作は、プロセッサがセキュア化モードで動作中は、制御されるか、または禁止され得る。
論じられるように、ある実施形態においては、各標的ユニットは、構造上不可視の一意的な秘密キー集合を有してもよい。しかしながら、別の実施形態においては、これらのキーのあるサブ集合が、いくつかの同等のデバイスに対して共通であってもよい。したがって、特定のコードセグメントは、キーの共通サブ集合によって、特定の種類の終点デバイスに結合可能である一方で、依然として、そのようなデバイス間で共通に保持される、この構造上不可視の秘密キー集合を保護する。したがって、ハードウェアハッシュ関数と1つ以上の構造上不可視の秘密キーの組み合わせは、高度に効果的かつロバストな再帰的セキュリティプロトコルのための信頼の連鎖の基礎を提供し得る。
次に、種々の実施形態の実装の詳細について、添付図面を使用して、さらに説明される。これらの実施例のすべてにおいて、用語「デジタルビットストリーム」とは、デジタルデータの一般的集合を指し、したがって、この用語は、デジタルコンテンツ、コードブロック、またはデジタルデータ集合等の用語と交換可能に使用されてもよいことに留意されたい。コードブロック用語の場合、参照データは、さらに、実行可能ファイル、実行可能スクリプト、あるいはアルゴリズム的記述または疑似コードのブロックさえ表すものと想定され得る。
図3は、デジタルコンテンツのための複合キー作成の一実施形態を図示する。この複合キー310は、特定の終点デバイス(標的ユニット)と関連付けられた構造上不可視の秘密キー(上述のような)であり得る終点特有のハードウェアキー340を利用して、暗号化エンジン320をグローバルコンテンツキー330(デジタルコンテンツの所有者または著者によって提供あるいは決定されてもよい)を適用することによって、作成されてもよい。特定の終点およびデジタルコンテンツの両方に特有である、結果として生じる複合キーは、複合キーが提供される終点デバイス上に伝送および格納され、そこに暗号化されていない状態で格納されてもよい。
図4Aは、セキュア化デジタルデータブロック構造の作成の一実施形態を図示する。この実施形態では、デジタルデータブロック410は、暗号化されなくてもよいが、デジタル署名420は、1つ以上のトークン440または450によって、デジタルデータブロックからのハッシュ関数430によって計算されたメッセージダイジェストを暗号化することによって形成される。これらのトークンは、タイムスタンプ等の秘密キーまたは公的に利用可能なデータであってもよい。暗号化エンジン460および461を通過するデータを暗号化するために採用される方法は、同じであっても、またはそうでなくてもよいことに留意されたい。秘密キーが、暗号化キーの1つとして使用される場合、その秘密キー値の知識なく、デジタル署名を偽造することはより困難となり得る。また、暗号化動作460および461の順序は、結果のセキュリティ全体に関連しないが、結果として生じるデジタル署名420は、動作の順序が変更されると異なるであろうことに留意することは有益である。
図4Bは、セキュア化コードブロックデータ構造の作成の代替実施形態を図示する。この場合、秘密キー470は、デジタルデータブロック471に付加され、メッセージ480全体を形成する。上述のように、この付加作用が、オリジナルデジタルデータ集合471の前または後に秘密キー470を置くかは、必ずしも、得られたセキュリティのロバスト性に関連しないが、順序が変更されると最終結果は異なるであろう。また、セキュリティを保証するために、秘密キー470は、オリジナルデジタルデータ集合471とともに公開されるべきであることに留意されたい。したがって、公開されるデータ集合は、データ構造480全体ではなく、デジタルデータ集合471だけに制限されるであろう。次いで、このデータ構造480全体は、図4Aに関して上述のものと本質的に同一態様で、ハッシュ関数430にかけられる。しかしながら、本実施形態では、最終出力490は、図4Aに示されるデジタル署名420の特徴の多くを有するが、暗号化エンジン460または461の使用を必要とし得ない。したがって、この動作の結果490は、デジタル署名同等物と呼ばれるであろう。このデジタル署名同等物490は、各一意的データ構造480全体に対して、一意的である(ハッシュ関数430が、適切に構築されていると想定して)ことに留意されたい。したがって、秘密キー470が、デジタルデータ集合471の著者およびそのデジタルデータ集合の消費者(終点デバイスまたは標的デバイス)によってのみ共有される場合、これらの2人の当事者のみが、同一の正確なデジタル署名同等物490を再作成することが可能であるはずである。この場合、デジタルデータブロック471は、その秘密キー470(したがって、標的デバイス)に「結合」されているとみなされ得る。
図5Aは、本明細書に説明されるもの等のセキュリティシステムを使用して、どのように暗号化されたデータブロック510を特有の復号化エンジンコードブロック562に暗号学的に結合し、次いで、ハッシュ関数540および暗号化エンジン561によって計算されるデジタル署名524を使用して、その組み合わせ530を特有の終点のハードウェア秘密キー523に結合し得るかの一実施形態を図示する。この実施例では、公開キー522(グローバルコンテンツ秘密キー520によって、復号化エンジンコードブロック562のメッセージダイジェスト521を暗号化することによって構築される)は、単一の連結されたデータ集合530として、オリジナルの暗号化されたデータブロック510とともに公的に分配されることに留意されたい。組み合わせられたメッセージ530(公開キー522と組み合わせられたオリジナルの暗号化されたデータブロック510を備える)のメッセージダイジェストから、デジタル署名524を作成する作用は、適切に承認された終点デバイスのみが、オリジナルの暗号化されたデータブロック510を復号化可能であるだけでなく、この復号化プロセスが、復号化エンジン562の所定の方法を使用することによってのみ達成可能であることを保証する。暗号化エンジン連鎖560により多くの構成要素(例えば、多項複合暗号化等)を追加することによって、より多くの制約が、復号化承認手順に容易に追加可能であることに留意されたい。
図5Bは、図5Aに示される実施形態の変形例を図示する。この実施形態においては、特定の暗号化されたメッセージ511の著者は、特有の終点デバイス上においてのみ明確に認証可能である。ここでは、オリジナルの暗号化されたデータブロック511は、上述のように、特有の復号化ルーチン562に暗号学的に結合される。この時点では、復号化ルーチン562は、非対称暗号化エンジンであって、入力は、著者の秘密個人キー525であり得、出力は、著者の公開キーを使用してのみ、正確に復号化されるであろうことが、さらに規定され得る。非対称暗号化ルーチン562のメッセージダイジェスト527は、デジタル署名526とともに、オリジナルの暗号化されたデジタルデータ511に付加され、データ構造531全体を形成する。次いで、データ構造531は、その終点デバイスの秘密キー523、ハッシュ関数544、および暗号化エンジン561を使用して、デジタル署名528を形成することによって、特有の終点デバイスに暗号学的に結合可能である。この実施形態の場合、暗号化されたメッセージ511が、本物であって、その著者が、既知であるだけではなく、著者がハードウェア秘密キー523を所有しているという事実を保証可能である。ここでは、本明細書において使用されるように、著者という用語は、必ずしも、データの創設者を意味するわけではなく、また、使用許諾者、配信者、あるいはそのようなデータの配信または別様に通信を所望する別の種類のエンティティをも指し得ることに留意されたい。この特定の信頼の連鎖の使用が重要となり得る一実施例は、終点デバイスのセキュリティシステムが、セキュア化コードブロック(オリジナルデータブロック511内に、暗号化された形式で含有されるであろう)を使用して、アップデートされるべき場合である。
図6は、セキュア化コードブロック620の実行を制御するために、カスケード式ハッシュ方法を利用する一実施形態を図示する。この場合、2つの独立コードブロック610、620が存在する。本実施例では、第1のコードブロック(セキュア化コードブロック610)は、第2のルーチン(セキュア化コードブロック620)に対する埋め込みサブルーチン呼出しを含む。したがって、セキュア化コードブロック610のためのハッシュ関数640によって算出されたメッセージダイジェスト630は、セキュア化コードブロック610内に含有される、セキュア化コードブロック620への参照に依存する。次いで、このメッセージダイジェスト630は、セキュア化コードブロック610の観点から、2つのセキュア化コードブロックをともにリンクする。次に、メッセージダイジェスト650は、ハッシュ関数670を使用して、コードブロック620のために構築されてもよい。しかしながら、メッセージダイジェスト650をセキュア化コードブロック620だけではなく、その呼出し親ルーチン(この場合、セキュア化コードブロック610)の両方に結び付けるために、オリジナルメッセージダイジェスト630は、ハッシュ関数670によって算出されるメッセージダイジェスト650へのシードとして使用されてもよい。そのようなシード値は、多くの方法において実装可能であるが、しかし、1つのそのような方法は、単に、オリジナルメッセージダイジェスト630を第2のデジタルデータ集合(例えば、この場合、セキュア化コードブロック620)に連結し、メッセージ660全体を形成することであることを思い起こされたい。次いで、メッセージ660全体は、ハッシュ関数670(ハッシュ関数640と同一である、またはある別の独立ハッシュ関数であることが可能である)にかけられ、第2のメッセージダイジェスト650を形成し、したがって、セキュア化コードブロック620だけではなく、オリジナルメッセージダイジェスト630(それ自体、セキュア化コードブロック610および620の両方に依存する)の両方に依存する。図4Bの議論に記載したように、これらの連結された要素620および630の順序は、結果として生じるメッセージダイジェスト650に重要であり得るが、ハッシュ関数670の場合、メッセージ660全体を備える要素の順序は、ハッシュ関数670のセキュリティに実質的な影響を及ぼし得ない。
次いで、この第2のメッセージダイジェスト650は、セキュア化コードブロック620が、コードブロック610から呼び出される場合にのみ正確に実行され得ることを保証する、上述と実質的に類似する態様で使用可能である。コードブロック620は、実際に、コードブロック610の正確な複製(または、同等参照)であり得、これは、再帰的システムの実施形態となるであろうことに留意されたい。同一コードブロックの2つの事例間の唯一の相違は、セキュア化コードブロックメッセージダイジェストを形成するために、コードブロックに付加される特定のメッセージダイジェストであり得る。
この特定の実施形態においては、任意の秘密キーを使用しておらず、したがって、この種類の構造は、本明細書において説明されるものと同一のセキュリティシステム全体を使用する、任意の終点デバイス上で適切な実行順序を実施するための特異性を伴わずに使用可能であることに留意されたい。また、上述のように、類似の実施例は、加えて、セキュア化コードブロック610または620のいずれかの実行が、それぞれ、メッセージダイジェスト630または650の代わりに、複合キーベースのデジタル署名構造あるいはその同等物を利用することによって、ある特有の終点デバイスもしくはデバイスの集合に制約されるように構築されてもよい。
図7Aは、セキュア化コードブロックメッセージの構築の実施形態を図示する。一実施形態では、暗号化されたデジタルデータ集合711は、ポインタ720によって識別される暗号化アルゴリズムを使用して暗号化されている。データ構造730は、デジタルデータ集合711およびポインタ720の連結によって形成される。データ構造730のメッセージダイジェスト750は、ハッシュ関数740によって生成される。この配設は、暗号化されたデータ集合およびその関連付けられた復号化ルーチンの暗号学的結合を可能にする。
第2の実施形態では、付加的条件が、連結されたデータ構造731に、すなわち、ポインタ721が復号化キー760に追加される。このキー760は、この特定の実施形態に図示されるように、必ずしも、ハードウェアベースの秘密キーではないことに留意されたい。実際、ポインタ721によってポイントされるキー760は、以下の図7Cの説明に論じられるように、それ自体がデータ構造であってさえよい。その他の点では、この実施形態は、上述の実施形態に実質的に類似する。暗号化されたデジタルデータ集合711は、オリジナルの非暗号化データ集合710に作用する暗号化エンジン770および1つ以上のキー760を使用する結果として作成される。メッセージダイジェスト751は、連結されたデータ構造731にハッシュ関数741を使用して生成される。この場合、現状では、非暗号化データ集合710を暗号化エンジン770だけではなく、暗号化されたデータ集合711から非暗号化データ集合710を再作成するために使用することが可能な一意的キー760の両方に暗号学的に関連付けるためのメカニズムが存在する。上述の実施形態と同様に、構造全体を所与の終点デバイスおよびその一意的秘密ハードウェアキー760に関して充足されているべき特有の条件集合に暗号学的に結合するために、付加的条件が、暗号化連鎖に追加されてもよい。デジタルデータ集合710および711のフォーマットおよび暗号化状態(すなわち、暗号化されているか、またはそうでないか)は、これらの詳細が、ポインタ720、721から推測可能であるので、このプロセスに関連し得ないことは着目に値する。
この点を考慮して、図7Bは、このように、再帰的セキュリティシステムにおいて使用可能なユニバーサル暗号化データ構造のための基本的な汎用フォーマットの1つの可能性のある実施形態を図示する。この構造の実施形態は、単純かつ強力であり得、一般的データブロック712、復号化ポインタ720、および復号化キーポインタ721の3つの基本的要素の単純にリンクされたリストとして実装可能である。リンクされたリスト全体は、データ構造732内でともにバンドルされる。リンクされたリストを使用することによって、連結されたデータ構造732内の要素の順序が、その機能に関連しないが、データ構造の動作または評価に影響を及ぼし得ることが容易に分かる。一般的(例えば、所定ではない)データブロック構造およびリンクされたリストのフォーマットを使用する、別の興味深い側面は、3つの要素712、720、ならびに721もまた、必ずしも、線形または連続的にさえ、順序付けられる必要がないことである。したがって、一実施形態は、データ構造732全体と併せて格納される、独立しているが、恐らく、関連している、ある他のデータを含む、補助データ構造713を備えてもよい。この概念の一実施形態は、図7の補助データ構造713内のポインタ720によってポイントされるもの等、実際の復号化エンジンコードブロック771を特定することであろう。別のそのような実施例は、この補助データブロック内のポインタ721によって規定される、実際のキー値を格納し得る。
これら両方の場合、そのような補助データブロック内に含有される実際のデータは、図4A、4B、5A、5B、6、および7Aに提示される、実施形態の実施例に様々に図示されるように、メッセージダイジェストまたはデジタル署名を生成するプロセスにおいて使用されてもよい。この開示に記載されるように、連結されたデータ集合内に格納される種々のデータフィールドの順序は、ハッシュ関数が適切に設計される場合、結果として生じるメッセージダイジェスト(または、デジタル署名)に影響を及ぼし得る。
したがって、また、類似ブロック構造を使用して、ある実施形態で利用されるキーをセキュア化してもよいことは、明白であろう。図7Cは、キーのみを備える、そのようなセキュア化データブロック733の一実施形態を図示する。ここでは、データブロックは、デバイス特有のキー714、715、716(または、所望に応じて、その他)のリストを備えてもよい。この実施例では、これらのキーのいずれも、(例えば)終点デバイス760の秘密キーと、それぞれ、暗号化エンジン771および772を使用して暗号化された終点デバイスタイムスタンプレジスタ790を使用して作成されてもよい。セキュリティシステムのロバスト性の観点からのそのような動作の上述の説明と同様、暗号化エンジン771および772が、個別またはさらに異なっているべきであるという要件は存在せず、暗号化連鎖におけるある数のこれらの暗号化動作に対して、基礎的限度がなくてもよい一方、これらの動作の順序は、結果として生じる複合キーに重要でなくてもよく、暗号化動作のための特定の順序に対する要件は存在しない。この場合に留意すべき他の特徴の1つは、連結されたキーリストデータ構造733のキーリストポインタ要素721が、さらに別の連結されたキーリストデータ構造734をポイントし得ることである。これらのデータ構造は両方とも、図7Bに図示されるように、同一ユニバーサル暗号フォーマットであるため、キーリストデータ構造は、再帰的態様で形成可能である。故に、そのような再帰的セキュリティシステムにおける実施形態で使用するためのキー733は、そのようなセキュリティプロトコルの実施形態が適用され得る、任意の他のデータと同一態様および同一構造を使用して、保護されてもよく、同様に、これらの保護されたキーは、また、本明細書に開示されるシステムおよび方法の実施形態によってセキュア化された他のデータと同一態様において、終点デバイス上で復号化および認証されてもよい。
次に図8を参照すると、複合キーがどのように暗号化されたコンテンツを復号化するために利用され得るかについての一実施形態が図示されている。この復号化動作は、上述のように、「セキュア化モード」において生じてもよい。ここでは、コンテンツ810は、複合キー830とともに、終点デバイスに提供されてもよく、そこでは、コンテンツは、最初に、グローバルコンテンツキーを使用して暗号化される。複合キー830は、図3に上述のように、作成されてもよい。故に、暗号化されたコンテンツ810が、終点デバイスで受信されると、関連付けられた複合キー830とともに受信され得る。デバイスにおける秘密キー840が、アクセスされ得るように、セキュア化モードで実行することによって、複合キー830は、セキュア化コードブロック860内で復号化され、グローバルコンテンツキーをもたらし得る。グローバルコンテンツキーは、次に、セキュア化コードブロック860内で使用され、オリジナルの暗号化されたコンテンツ810を復号化し、復号化されたコンテンツ880をもたらしてもよい。
図9は、コードブロックが、実行前に特定の終点デバイスにおいて起動するために承認されていることを照合するために、どのように秘密キーが利用され得るかの一実施形態を図示する。実行のための候補コードブロック910は、終点デバイスに提供されてもよく、または受信された暗号化されたデジタルコンテンツを復号化することによって得られてもよい(例えば、図8に上述のように)。加えて、終点デバイスは、候補コードブロック910に相当する、対応するデジタル署名920を受信してもよい。このデジタル署名920は、終点デバイスハードウェア特有の秘密キー930を使用して暗号化されているコードブロックから作成される(例えば、そのコードブロックをハッシュすることによって)、メッセージダイジェストを備えてもよい。したがって、候補コードブロック910が実行され得るかどうかを照合するために、認証動作が、セキュア化モードで実装されてもよく、それによって、候補コードブロック910が、メッセージダイジェスト(912)を作成するためにハッシュされる。次いで、このメッセージダイジェスト912は、終点デバイスの終点デバイスハードウェア特有のキー930(照合がセキュア化モードで生じるため、アクセス可能であってもよい)を使用して暗号化され、ステップ914において、オリジナルとして供給されたデジタル署名920と比較される、デジタル署名を作成可能である。このデジタルハードウェア生成デジタル署名が、候補コードブロック910に対応する、受信したデジタル署名920と整合する場合、候補コードブロック910は、照合され、考えられ、実行可能であるとみなされてもよく、そうでなければ、例外エラーが生じ得る(ステップ916)。
図10は、コードブロックが、どのように「セキュア化実行」モードにおいて、特定の終点プロセッサ(所定の環境下)上で起動可能となり得るかの一実施形態のブロック図である。この特定の場合、コードブロック1011の事前に算出されたデジタル署名1030(また、終点特有の復号化キーとも称され得る)は、コードブロックのメッセージダイジェストを使用し、承認標的終点デバイスの秘密キー1040、承認標的終点デバイスの最も新しいタイムスタンプ値1041、または上述のような任意の数の制約条件の1つ以上(この特定の実施形態では図示せず)の1つ以上によって暗号化することによって構築される。
また、これらの条件の任意の1つも、マスク機能を条件自体のサブ集合に適用することによって事前に条件付けられ得ることに留意されたい。例えば、タイムスタンプフィールドのいくつかの最小有効ビットのマスクが、外されている場合(したがって、デジタル署名の計算では考慮され得ない)、そのタイムスタンプ値の有効粒度は、ハードウェアにおける任意の変更を伴わずに、コードセグメント基準によって、コードセグメント上で容易に制御可能である。この同一原理は、ある実施形態において、デジタル署名の計算において使用される、任意の数の条件に提供可能である。
図7に図示されるキーリストデータ構造と同様、コードブロック1011を含有する、連結されたデジタルデータ集合1010は、また、少なくとも1つの復号化ポインタ1012および少なくとも1つの復号化キーまたはキーリストポインタ1013を含む。また、上述のように、これらのいずれか1つは、外部データ構造(終点特有のデジタルキーまたはデジタル署名1030等)、あるいは連結されたデータ集合1010内に全体として含有される、埋め込みデータ構造を参照してもよい。
図10に示される実施形態を説明する目的として、コードブロック1011は、暗号化されていない(したがって、潜在的に、終点デバイス標的プロセッサ上で実行可能である)ことを前提する。この場合、復号化ポインタは、その使用に先立って、コードブロック1011のためにさらなる復号化が要求されないため、空値であってもよい。この場合のように、コードブロックが、暗号化されていない場合、その対応する復号化キー(ポインタ)1013は、関連付けられた終点またはハードウェア特有のデジタル署名1030をポイントしてもよい。したがって、図4A、4B、5A、および5Bに上述のもの等のデータ構造ならびに方法の実施形態を使用して、ブロック1011に図示されるような非暗号化データ集合の使用に関する、多種多様な認証、暗号学的結合、または他の制約を施行してもよい。
終点特有のデジタル署名(または、復号化キー)1030が、ハードウェア秘密キー1040のみ、または代替として、ハードウェア秘密キー1040および終点デバイスタイムスタンプレジスタ1041のみをポイントする場合、セキュリティシステム関連呼出しが、呼出し連鎖の「最下層」に到達し、この特定の呼出し連鎖におけるセキュリティシステムの付加的層へのさらなる呼出しが存在しないことを決定可能となる。したがって、セキュリティシステム再帰は、この時点で「終了」する。この再帰終了条件は、終点特有のハードウェア秘密キー1040の値へのアクセスを選択的に許可または拒否する「ゲートキーパー」として、したがって、ハードウェアハッシュ関数ブロック1061の使用する暗号化機能への入力成分としてのみ作用する、ハードウェアブロック1050によって検出される。図10に示される実施例では、ハードウェア特有の秘密キー1040およびハードウェアハッシュ関数ブロック1061の(メッセージダイジェスト)出力は、暗号化エンジン1062および1063への入力引数として使用される。
最後に、そこで、暗号化エンジン1063の出力(オリジナルの連結されたデータ構造1010のデジタル署名である)が、供給されたデジタル署名1030の値と整合する場合、「セキュア化モード有効化」ハードウェアビット1070が、設定される。この条件は、終点ハードウェアI−キャッシュ1020にロードされた候補コードブロック1011が、現時点において、「セキュア化」モードで実行することが承認されていることを示す。I−キャッシュ1020内に常駐する候補コードブロック1011への物理的変更、またはI−キャッシュ1020自体への任意の変更が存在しないことに留意されたい。この時点で変更されている唯一のものは、「セキュア化モード有効化」ハードウェアビット1070の値である。
図11は、再帰的セキュリティシステムによって行われ得る、復号化動作の一実施形態を図示する。この復号化動作は、配信されたコンテンツを復号化または別様に操作および利用するプロセスにおいて、使用されるべきセキュア化コードブロックを照合してもよい。上述のように、終点デバイスは、暗号化されたコンテンツ1111を含有するデータ構造1110、復号化エンジン1120へのポインタ1112(または、復号化エンジン自体)、および終点特有の複合キー1130へのポインタ1113(図9に関して上述のように)を受信してもよい。セキュア化モードにおいて実行可能にされる前に、ポイントまたは受信される複合復号化エンジン1140が認証されるであろう。この認証は、終点デバイス内に常駐するハッシュ関数1121を使用して、複合復号化エンジン1140コードブロックのメッセージダイジェスト1122を計算することによって、達成されてもよい。ハッシュ関数1121は、本実施例では、ハードウェアブロックとして図示されているが、このハッシュ関数1121は、上述のように、例えば、終点デバイスの内蔵ハードウェアハッシュ関数の代わりに使用可能なセキュア化ソフトウェアコードブロックであってもよいことに留意されたい。しかしながら、この場合、ハッシュ関数のソフトウェアバージョンは、依然として、最終的には、認証または承認目的のために、内蔵ハードウェアハッシュ関数に依存し得、したがって、この場合の最終的信頼の基点は、依然として、終点の内蔵ハードウェアハッシュ関数ブロック1121とともに常駐する。
次いで、このハッシュブロック1121によって生成されるメッセージダイジェスト1122は、ステップ1123において、復号化エンジン1140に対応する、事前に算出されたメッセージダイジェスト1150と比較されてもよい。この事前に算出されたメッセージダイジェスト1150は、例えば、セキュアな方式において、終点デバイスに提供されるか、または終点デバイス自体で事前に算出され、格納されてもよい。メッセージダイジェストが整合する場合、複合復号化エンジン1140は、終点デバイス(ステップ1125)上で実行可能となってもよい。メッセージダイジェストが、実質的に等しくない場合、無効なコード例外が生じ得る(ステップ1126)。
しかしながら、メッセージダイジェストが、実質的に等しい場合、終点デバイスのプロセッサは、セキュア化実行モードを入力し、複合復号化エンジン1140内に含有されるコードを実行してもよい。この複合復号化エンジン1141の第1の部分は、複合キーからグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェア特有の秘密キー1131を利用して達成されてもよい(ステップ1132)。次いで、第2の復号化動作1142は、得られたグローバルコンテンツ特有のキーを使用して、暗号化されたコンテンツ1110から復号化されたコンテンツ1152を生成するために、復号化動作1141によって生成された中間結果を使用してもよい。ここでは、復号化エンジン1140は、一対の復号化アルゴリズム(1141および1142)として図示されるが、オリジナルの暗号化されたデータ集合1110に適用される、セキュア化コードブロック1140の種々の個々の構成要素(1141、1142等)の動作の最終結果が、所望の復号化されたコンテンツ結果1152を生成するように、任意のより少ないまたはより多い数のカスケード式復号化段階を包含してもよいことに留意されたい。また、これらの種々の個々の復号化構成要素の任意の2つは、同一または異なるアルゴリズムであってもよいことに留意されたい。
ある実施形態では、加えて、さらなるセキュリティを層状にすることが所望さ得、したがって、いくつかの実施形態では、複合キーは、図4A、7C、および10に関して上述のように、実質的に同一態様において、終点デバイス特有のハードウェアキーおよび終点特有のタイムスタンプ値を使用して、事前に算出されたメッセージダイジェストから形成されてもよい。
図12は、終点デバイスにおける、再帰的セキュリティプロトコルの実装の一実施形態を図示する。具体的には、セキュア化コードブロックの照合のためだけではなく、配信されたデジタルビットストリームの実際の復号化/または他の使用のための複合キー集合の使用の一実施形態について図示される。本実施形態は、多くの側面において、図11に図示される実施形態に類似しており、したがって、実施形態の異なるそれらの側面のみ、図12に関して焦点が当てられる。暗号化されたコンテンツ1211を備えるメッセージ1210は、復号化エンジン1240(または、復号化エンジン自体)、コンテンツ特有の複合キー1231(図8に関して上述のように)、ならびに終点およびタイムスタンプ特有の複合キー1232へのポインタ1212を含め、受信されてもよい。暗号化されたコンテンツ1211は、終点デバイスにおけるメモリ内にロード可能であって、また、復号化エンジン1240へのポインタ1212も、メモリ(例えば、終点デバイスにおける命令キャッシュまたは命令キャッシュのセキュア化部分)内にロードされてもよい。次いで、ポイントされる復号化エンジン1240が認証されるであろう。この認証は、図11に関して上述のものと実質的に類似態様において、終点デバイス内に常駐するハッシュ関数1221を使用して、暗号化エンジン1240のメッセージダイジェストを算出することによって達成されてもよい。
次いで、本実施例では、ハードウェア生成メッセージダイジェストは、ハードウェアまたは終点デバイス上のソフトウェアの中に実装されてもよく、算出されたメッセージダイジェストおよび終点デバイスハードウェア特有の秘密キー1270または終点デバイスタイムスタンプレジスタ1260の値等のハードウェア特有のキーあるいはレジスタの1つ以上に作用する、1つ以上のカスケード式複合暗号化エンジン段階1224、1225等を備える暗号化エンジンを使用して、暗号化されてもよい。生成される、結果として生じる複合デジタル署名1226は、復号化エンジンコードブロック1240に正確に対応してもよく、したがって、また、特有の終点デバイスに暗号学的に結合されてもよい(1つ以上の暗号化段階1224、1225と、1260および1270等の種々の秘密または公開変数あるいは定数を使用することによって)。上述のように、この生成されたデジタル署名は、随意に、この複合デジタル署名の可用性をさらに制限するために、他の制約変数または定数とともに、さらに暗号化されてもよい(同一または異なる暗号化エンジンを使用して)。また、例えば、このデジタル署名1232と関連付けられたコードブロック1240の用途が、単一の一意的終点ユニットを超えて、拡張することが所望される場合、暗号化段階の1つ以上は、随意に潜在的に生成された複合デジタル署名整合のフィールドを拡大するために制限されてもよい。
次いで、生成された複合デジタル署名1226は、ステップ1223において、オリジナルとして終点デバイスに提供され得る(例えば、事前に、終点コード使用許諾プロセスの一部として、使用許諾権限者によって)、その暗号化エンジン1240に対応する終点およびタイムスタンプ特有の複合デジタル署名1232と比較されてもよい。データ構造は、このトークン1232が、デジタル署名またはキーであるかにかかわらず、等しくあり得、したがって、用語「キー」および「デジタル署名」は、それらの場合、可能性として、互換可能に使用されてもよいことに留意されたい。
複合デジタル署名1226および1232が、実質的に同じである場合、終点デバイスのプロセッサは、復号化エンジンコードブロック1240内に含有されるコードをセキュア化実行モードで起動することが可能となり得る。セキュア化実行モードで起動すると、復号化エンジン1240は、復号化エンジン1241または1242を使用して、デバイス特有の複合キー1231からグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェアキー1270を利用してもよい。したがって、グローバルコンテンツ特有のキーは、中間結果であってもよく、故に、複合復号化エンジンコードブロック1240以外の任意のソフトウェアまたはハードウェアエンティティに決してキャッシュされないか、あるいは別様に可視となり得ない。次いで、このグローバルコンテンツ特有のキーは、復号化エンジン1243によって使用され、オリジナルの暗号化されたコンテンツ1211から、最終復号化コンテンツ1250を生成する。
しかしながら、生成されたデジタル署名1226が、供給されたデジタル署名1232と実質的に整合しない場合、復号化エンジンコードブロック1240利用の試みが、未承認当事者によって行われる場合を含む不整合が生じ得る、いくつかの可能性のある理由が存在するであろう。しかしながら、不整合の別の可能性のある理由は、復号化エンジンのためのソフトウェアがアップデートされた(および、終点のタイムスタンプレジスタが、同様に、漸増または別様に変更された)場合であろう。この場合、2つのデジタル署名は整合し得ず、ステップ1281において、暗号化エンジンコード1240自体が、暗号化されている(例えば)か、または別様に置換を必要としているかどうかチェックされてもよい。本明細書に論じられる実施形態は、再帰的セキュリティプロトコルのために効果的に利用され得、したがって、多くの場合、暗号化アルゴリズム(ポイントされるか、または暗号化されたコンテンツとともに含まれてもよい)自体が暗号化される、これらの暗号化された暗号化アルゴリズム自体が暗号化される等であってもよいことを思い起こされたい。したがって、暗号化アルゴリズムのための生成された終点およびタイムスタンプ特有の複合キー1226と、受信した終点およびタイムスタンプ特有の複合キー1232が整合しない場合、少なくとも1つ以上の層の間接参照または暗号化が利用されている場合であり得る。
上述のように、特定の実行可能コードブロックに暗号化の層を追加する概念は、特定のコードブロックのアップデートされていないバージョンをそのコードブロックのより新しいバージョンと置換する作用と論理的に同等であり得る。故に、終点およびタイムスタンプ特有の複合デジタル署名1232、コードブロックの復号化ポインタ(図示せず)、またはコードブロックの復号化キーポインタ(同様に、図示せず)といった、そのコードブロックと関連付けられたトークンの1つ以上を検証することによって示されるように、復号化エンジン1240自体が、暗号化されているか、または別様に置換を必要とするか(ステップ1282に示されるように)どうかを決定可能である。一実施例では、コードブロック1240の関連付けられた復号化ポインタが、空値をポイントする場合、暗号化エンジン1240が、暗号化されていない、または別様にアップデートされておらず、したがって、生成されたデジタル署名1226および供給されたデジタル署名1232が、実質的に等しくないが、コードブロックを正確なデジタル署名を可能性として生成し得る異なるバージョンと置換するための他のリソースが存在し得ないため、例外エラーが生じ得る結果(ステップ1283)ことを示すであろう。しかしながら、復号化エンジンコードブロック1240の復号化ポインタが、別のコードブロック(別の(可能性として、アップデートされている)暗号化エンジン(図示せず)またはある他のコードブロック)をポイントする場合、この新しいコードブロックがロードされ、上述の認証ステップが、この次の暗号化エンジンに適用されてもよい(言い換えると、別の再帰層が導入されてもよい)。この再帰的実行メカニズムは、生成された終点およびタイムスタンプ特有の複合デジタル署名1226と供給された終点およびタイムスタンプ特有の複合デジタル署名1232との間に整合が生じると決定される(ステップ1227)、または整合が存在せず、復号化エンジン1240自体が、暗号化されておらず、その時点で、例外エラーが生じ得ると決定される(ステップ1283)まで、継続してもよい。
生成された終点およびタイムスタンプ特有の複合デジタル署名1226と、供給された終点およびタイムスタンプ特有の複合デジタル署名1232が整合すると決定される場合に、再帰が終了され、巻き戻されてもよい。これは、再帰的呼出し連鎖全体を通しての初期順方向パスの際に直面し、スタックに保存される、コードブロックのそれぞれの認証および実行を伴ってもよい。これらのコードブロックの一部または恐らく全部さえ、必ずしも、暗号化または復号化エンジンでなくてもよいことに留意されたい。いずれの場合も、これらのコードブロックはそれぞれ、標的終点デバイスのプロセッサがセキュア化実行モードで動作中に認証され得る。
この実行は、再帰的セキュリティシステムによって行われ得る復号化動作の一実施形態を図示する、図13を参照することによって、より詳細に説明されるであろう。説明されるように、終点デバイスは、特に、暗号化されたコンテンツ1312とともに、コンテンツ特有の複合キー1316(図8を参照して論じられるように)、復号化エンジンデータ構造1320へのポインタ1313、またはオリジナルメッセージ1310内に埋め込まれる場合、復号化エンジン自体、およびキーまたはキーリストデータ構造1318をポイントするキーリストポインタ1314を含有し得る、メッセージ1310を受信してもよい。上述のように、このデータ構造は、キーまたはキーリスト1316あるいはデジタル署名1317を含んでもよい。同様に、復号化エンジンデータ構造1320は、暗号化されたコードブロック1321、暗号化された(または代替として、置換を必要とする古い)復号化コードブロック1321と関連付けられた後続の復号化ポインタ1322、および関連付けられた復号化キーリストポインタ1323を含有してもよい。後続の復号化ポインタ1322は、復号化コードブロックデータ構造1320のものと実質的に類似する構造を有するが、データ構造1330の場合、復号化コードブロック1331自体は、暗号化された形式ではない最終復号化コードブロックデータ構造1330をポイントしてもよい。
図13に図示される実施形態の動作は、以下のように説明可能である。暗号化されたコンテンツデータ構造1310が、その中に含有される暗号化されたコンテンツ1312を復号化することを予測して、終点プロセッサのメモリ空間内にロードされる。データ構造1310は、復号化ポインタ1313を含有するので関連付けられた復号化エンジンコードブロックデータ構造1320は、メモリ内にロードされ、読み込まれる。また、この後続のデータ構造1320は、復号化ポインタ1322を含有するため、次いで、ポインタ1322と関連付けられた復号化エンジンコードブロックデータ構造1330が特定され、メモリ内にロードされる。データ構造1330の場合、本実施例の埋め込み復号化ポインタ1332は、空値ポインタであると決定され、したがって、標的終点デバイスのセキュリティシステムは、現在の復号化再帰連鎖が終了し(例えば、図10に論じられるように)、したがって、データ構造1330の一部として、メモリにちょうど読み込まれた復号化エンジン1331が、非暗号化(したがって、潜在的に、実行可能)コードブロックを含有し得ることを決定可能である。
デジタルコンテンツ1331が、コードブロックであって、データではないことが決定可能であるため(呼び出された態様によって)、また、復号化キーリストポインタ1333(データ構造1330の一部として、メモリに内に読み込まれた)によってポイントされるキーリストデータ構造1338が、デジタル署名1337(複合キー1336に加え)を含有し得ることも決定可能である。また、本実施例におけるキーリストデータ構造(1318、1328、および1338)は、図7Bに関して上述のように、ユニバーサル暗号化データ構造を使用して実装されてもよいことに留意されたい。したがって、これらのキーリストデータ構造1318、1328、および1338内の引数の順序は、必ずしも、固定ではなく、したがって、データ構造自体がトラバースされるのに伴って、ランタイム時に解釈されてもよい。実際、これらのキーリストデータ構造(1318、1328、および1338)自体、補助的復号化ポインタおよびキーリストポインタをこれらのキーリストデータ構造(1318、1328、および1338)自体の一部または全部内に組み込ことによって、さらなる復号化または後続の解釈への参照を含んでもよいが、この特定の選択肢は、単純化を目的として、図13の実施形態には図示されないことに留意されたい。
さらに、キーリストデータ構造1338内のキーポインタ1336の少なくとも1つが、終点のハードウェア秘密キー1392への参照に対応することを決定可能である。終点のハードウェア秘密キー1392へのこの参照は、適切に確保された記憶場所(プロセッサのアーキテクチャの中に規定され得るが、決して、プロセッサによって直接読み取られ得ず、したがって、構造上直接不可視である場所)へポイントすることによって明示的に、またはポインタのためにある特別に確保された値を使用することによって暗示的に達成されてもよい。いずれの場合も、この参照は、種々の手段を使用して実装されてもよいが、1つのそのような実施形態の実施例は、キーリストデータ構造内の「0」の値(「空値」とは別として)を終点のハードウェア秘密キー1392への参照と一致させることであろう。キーリストデータ構造の少なくとも一部は、終点のハードウェア秘密キー1392を参照するという事実は、復号化エンジンコードブロック1331が、標的終点デバイスのプロセッサ上において、セキュア化実行モードで起動することが意図されることをさらに示し得る。したがって、ハードウェアベースのデジタル署名発生器ブロック1390の出力は、データ構造1337内に格納された値と比較される。2つの値が実質的に整合する場合、プロセッサは、セキュア化実行モードに入ることが可能となる。
ここでは、ハードウェアベースのデジタル署名発生器ブロック1390(その一実施形態の詳細は、図15に関して、より包括的に提示される)は、一実施形態では、1つ以上のソフトウェアベースの要素を備えてもよいが、また、上述のように、直接または間接的に、少なくとも1つのハードウェアベースのセキュリティ構成要素を備えてもよいことに留意されたい。そのハードウェア構成要素は、本明細書に含有される上述の説明の多くにおいて参照され、標的終点ユニットのセキュリティシステムの信頼の基点全体を成す、ハードウェアベースのハッシュ関数である。
この時点では、次いで、復号化エンジンコードブロック1331が、セキュア化実行モードで起動可能となり、終点プロセッサが、潜在的に、セキュリティ関連動作の一部として、終点のハードウェアデバイス特有の秘密キー1392を利用可能となる(本明細書で上述のように)。プロセッサが、セキュア化実行モードで動作していない場合、秘密キー1392の値は、そのようなセキュリティ関連動作における使用のために利用可能とならないであろう。この概念は、プロセッサがセキュア化実行モードにおいて起動中の場合にのみ、秘密キー1392の値を後続の使用(例えば、復号化エンジンコードブロック1331における)に通過させる、ハードウェアアクセス制御ブロック1343として、図13に関して図示される。
加えて、ハードウェアアクセス制御ブロック1343への入力パラメータの1つは、アクセス制御ブロック1341の出力であることが分かる。このように、ハードウェアアクセス制御ブロック1343の状態(事実上、復号化コードブロック1321のための「セキュア化実行モード有効化」インジケータである)は、復号化コードブロック1331もまた、セキュア化実行モードで起動中であるという事実に依存する。これは、復号化コードブロック1331(例えば、ハードウェアアクセス制御ブロック1341の出力)のための「セキュア化実行モード有効化」インジケータの状態によって示されてもよい。この依存性は、復号化エンジンコードブロック1321の能力を、復号化コードブロック1331が、またセキュア化実行モードで起動中である場合にのみ、セキュア化実行モードで機能可能となるように制約する。本質的に同様の態様において、ハードウェアアクセス制御ブロック1343の出力は、復号化コードブロック1311のための「セキュア化実行モード有効化」インジケータである、ハードウェアアクセス制御ブロック1345への入力の1つとして使用される。したがって、両方が適切に認証され(図14に関して、より詳細に説明されるように)、再帰的呼出し連鎖内の下位のセキュリティ連鎖の適切に承認された部分からの認証復号化結果が供給されている場合のみ、先行する親コードブロックがセキュア化実行モードで起動することを許可する目的として、呼出し連鎖を逆方向に後退して、「セキュア化実行モード有効化」ビットを伝播させるメカニズムとなる。上述のように、いくつかの条件の任意の1つは、「セキュア化実行モード有効化」ビットのいずれかを「非セキュア化」デフォルト状態にリセットさせてもよい(したがって、潜在的に、セキュリティ連鎖全体を再開させることを必要とする)ことに留意されたい。そのような条件は、プロセッサ割り込みまたは後続のデジタル署名比較不整合を含んでもよい。これらのハードウェアアクセス制御ブロック1341、1343、および1345は、図13において、明確性を目的として、別個のエンティティとして図示されるが、それらは、実際、単一ハードウェアユニット(図15に関して説明されるような)に埋め込まれてもよく、したがって、その出力は、その独自入力条件と1つとして、フィードバックされることが分かる。最終的には、連鎖全体における最高レベルまたは最終「セキュア化実行モード有効化」ビットの出力(本実施形態では、ハードウェアアクセス制御ブロック1345の出力)は、制御メカニズムの一部として使用され、標的デバイスに対するある外部可視出力を有効または無効にしてもよい(例えば、音声または映像出力を有効にする)。
ステップ1370における復号化エンジンコードブロック1331の作用は、データ構造1320の復号化エンジンコードブロック部分1321内に格納されたデータ集合を、オリジナルデータのアップデートおよび/または適切に実行可能バージョンと置換または別様に補完することである。この作用は、1321内に格納されたオリジナルデータを利用して、キーリストデータ構造1328内に格納されたか、またはポイントされた1つ以上の復号化キーによって復号化することによって達成されてもよい。代替として、上述のように、復号化エンジンコードブロック1331の作用1370は、復号化コードブロック1321をアップデートされたバージョンと置換するか、またはさらに復号化エンジンコードブロック1321の代わりに直接実行することであってもよい。いずれの場合も、復号化エンジンコードブロック1331は、最初、(本実施形態では)標的終点デバイスのタイムスタンプレジスタ1394内に含有される値、標的終点デバイスのハードウェア特有の秘密キー1392(ハードウェアアクセス制御1342を通過することによって書き換えられるような)、ならびに終点およびタイムスタンプ特有の複合デジタルキー1326を含む、種々の入力データを使用して動作してもよい。復号化エンジンコードブロック1331が、続いて、復号化エンジンコードブロック1321の直接置換として動作する場合に、第2の入力データ集合(例えば、この実施形態においては、標的終点デバイスのタイムスタンプレジスタ1394内に含有される値、標的終点デバイスのハードウェア特有の秘密キー1392(ハードウェアアクセス制御1344を通過することによって書き換えられるような)、ならびに終点およびタイムスタンプ特有の複合デジタルキー1316)を利用してもよい。
ステップ1371におけるアップデートされた復号化エンジンコードブロック1321のさらなる作用は、所望の出力データ1380を生成するために、オリジナルの暗号化されたコンテンツデータ1312を置換または別様に解釈することである。本作用は、1312内に格納されたオリジナルデータを利用して、キーリストデータ構造1318内に格納またはそれによってポイントされた1つ以上の復号化キーによって復号化することによって達成されてもよい。復号化エンジンコードブロック1321および1331両方の作用は、性質上類似するので、復号化エンジンコードブロック1331の動作の説明において上述の選択肢のいずれかが、復号化エンジンコードブロック1321のアップデートされたバージョンの動作に等しく適用可能であることは明白であるはずである。また、復号化エンジンコードブロック1321の動作の場合、いくつかの実施形態では、関連付けられたハードウェアアクセス制御ブロック1344は、ハードウェアアクセス制御ブロック1342と異なることに留意されたい。しかしながら、これらの2つのハードウェアアクセス制御ブロック1342および1344の作用は、それらの目的が、それぞれ、それらの関連付けられた復号化エンジン1331または1321によって、標的終点デバイスのハードウェア特有の秘密キー1392の使用を有効あるいは無効にするという点において、性質上類似しており、したがって、他の実施形態では、異なっていなくてもよい。
最後に、上述の図13の実施形態に図示される動作すべてにおいて、標的終点デバイスのタイムスタンプレジスタ1394の使用は、他の実施形態に対して本明細書に上述のそれらの実施例と本質的に類似する。したがって、レジスタ1394内に格納された値は、図13に図示される特定の実施形態に記載される異なる承認ならびに復号化動作で採用される、種々の複合キーおよび/またはデジタル署名の発生において、付加的要素として使用されてもよいということになる。
図14は、再帰的呼出し連鎖が、そのようにトラバースおよび終了され、プロセッサが、どのように1つ以上の埋め込みコードブロックのメッセージ−ダイジェストベースの認証を使用して、セキュア化実行モードに入ることが可能となり得るかの一実施形態を図示する。本実施形態では、2つの候補コードブロック1412および1422の動作が説明され得、その両方とも、図7Bに関して上述のように、ユニバーサル暗号化データ構造(それぞれ、1411および1421)内に含有されてもよい。
図14では、コードブロックデータ構造1421が、2回現れていることに気付かれたい。この重複は、明確にすることを目的として、別個の反復を表すように例示されるが、これは、両方の事例において、正確に同一のデータ構造であることに留意されたい。しかしながら、気付かれ得る差異の1つは、キーリストポインタ1421の事例によってポイントされるのはキーリストデータ構造1428および1438であることである。キーリストポインタ1421の値は、この図に示される2つの事例間で変動しないが、キーリストデータ構造1428内に含有される(または、それによってポイントされる)値は、2つの反復間で変化してもよく、したがって、この詳細は、データ構造(および、その種々の構成要素)を、それぞれ、1426、1427、および1428から、1436、1437、および1438に再ナンバリングすることによって示される。この構造が再ナンバリングされるという事実は、必ずしも、データ構造の実際の場所が移動したことを示すものではなく、そのコンテンツが変化した可能性があるにすぎない。同様に、また、ハードウェアハッシュ関数1480が、本図では、明確性を増大させるという同一理由から、複数化図示される。最後に、2つの候補コードブロック1412または1422のいずれも、暗号化されておらず、したがって、それらの関連付けられた復号化ポインタ1416、1426、および1436はすべて、空値ポインタであってもよいことに留意されたい。
本実施形態では、候補コードブロック1412に対する読み出しが、開始されてもよい。上述と同一態様において、コードブロックデータ構造1411が、メモリ内に読み込まれてもよく、そのメッセージダイジェスト1441は、ハッシュ関数1480によって算出されてもよい(上述のように、ハードウェア内で全体的または部分的に実現されてもよい)。しかしながら、本実施形態では、ハッシュ関数は、初期シード値1440が与えられてもよい(すべてゼロに設定されてもよく、またはそうでなくてもよい)。上述のように、このハッシュ関数シード値特徴は、いくつかの方法の1つを使用して実装されてもよいが、本実施形態では、シード値1440は、既知であって、ハッシュ関数ブロック1480のメッセージダイジェスト出力1441に影響を及ぼす方法は、反復可能かつ決定性である。
ハッシュ関数の結果1441が生成されると、プロセッサは、コードブロック1412内に含有されるコードの実行を開始可能となる。図14に示される実施形態では、復号化ポインタ1413ならびにキーリストポインタ1414によってポイントされる両場所1416および1417(キーリストデータ構造1418内に含有される)の両方の値がすべて、空値である場合、コードブロック1412は、セキュア化実行モードで起動するように設計されなくてもよく、したがって、標的終点ユニットのセキュリティハードウェア特徴のいずれかの使用を必要としない。したがって、プロセッサは、コードブロック1422をポイントする埋め込みサブルーチン呼出しに到達するまで、コードブロック1412内に含有される命令の実行を開始する。
その時点で、コードブロックデータ構造1421は、メモリ内にロードされ、次のメッセージダイジェスト1442を生成するプロセスが、ハッシュ関数ブロック1480によって繰り返される。しかしながら、この特定の事例では、ハッシュ関数シード値は、もはや初期シード値1440ではなく、以前に生成された結果1441であり得る。したがって、メッセージダイジェスト1442の値は、コードブロック1411および1421の両方のメッセージダイジェストに確定的に依存することが分かる。しかしながら、上述の場合のように、復号化ポインタ1423の値およびキーリストポインタ1424によってポイントされるキーリストデータ構造1428内に含有される値は、依然として、空値であってもよく、したがって、プロセッサは、上述のように、非セキュア化実行モードで継続する。
後に、プロセッサは、別のサブルーチン呼出しに直面するが、本実施例では、コードブロック1422は、再帰的呼出し(例えば、それ自体に対するサブルーチン呼出し)を含有する。ある実施形態では、そのような再帰的呼出し構造は、例示にすぎず、標的終点デバイスのセキュリティシステムの正確な動作は、他の手段、例えば、セキュリティシステムに対する任意の呼出しが、コードの単一層内に含有されることを保証する、他の手段によって達成されてもよいことに留意されたい。しかしながら、多重レベルのセキュリティシステムがトラバースされると、再帰的呼出し形式は、上述のように、比較的によりセキュアであって、図示された実施形態と併せて、セキュリティシステムを実装するために、効果的に利用され得る。
いずれの場合も、プロセッサが、コードブロック1422内に埋め込まれたサブルーチン呼出し(それ自体を参照する)に直面すると、コードブロックデータ構造1421は、再び、メモリ内にロードされ(例えば、最新システムでは、データ構造1421は、フェッチされる2度目は、異なる物理的場所にロードされてもよい)、ハッシュ関数1480は、新しいメッセージダイジェスト1443を計算する。この新しいメッセージダイジェスト1443は、初期メッセージダイジェストシード値1440、(コードブロック1412の)メッセージダイジェスト1441だけではなく、コードブロック1422の2つの別個の反復のメッセージダイジェストに依存することに気付かれたい。
また、この2度目は、キーリストポインタは、非空値デジタル署名値1437を含有する、新しいデータ構造1438をポイントすることに留意されたい。この非空値は、コードブロック1422のこの反復が、標的終点ハードウェア特有のセキュリティシステムへの参照を含有する、セキュリティシステムに対するインジケータである。したがって、本実施形態では、そのような参照が、適切に動作するために、プロセッサは、ある時点において、セキュア化実行モードに入らなければならない。したがって、次いで、コードブロックデータ構造1421が、メモリ内に最も新しくロードされた時に生成されたデジタル署名1443が、キーリストデータ構造1438内に含有されるデジタル署名1437と比較されてもよい。ステップ1491において、2つの値が、実質的に類似することが分かった場合、標的終点プロセッサは、セキュア化実行モードに入ることが可能となる。しかしながら、2つのデジタル署名値1437および1443が、整合しない場合(デジタル署名1437が、この時点では、非空値であることが分かっていることを前提とする)、ステップ1492の結果は、プロセッサに、セキュリティシステムの適切な例外エラーハンドラ部分1470を実行させることになる。
図15は、デジタル署名発生器ブロック1560が、どのように上述の特徴をサポートするために、ハードウェア内に実装され得るかの一実施形態を図示する。図15に図示される実施形態は、図10に図示され、例えば、図11、12、13、および14に関して、動作の詳細において説明された機能特徴をサポートする、デジタル署名発生器ブロックの機能に類似する機能のハードウェア実装を示す。
ハッシュ関数シードレジスタ1510は、図14のブロック1440として標識されたものと類似機能を備えてもよく、ハッシュ関数ブロック1561にフィードされる、初期値を保持するように動作可能であってもよい。ハッシュ関数ブロック1561の出力は、複合暗号化エンジンの第1の段階1562への入力の1つとしてフィードされる。暗号化エンジン1562への他の入力は、標的終点デバイスのタイムスタンプレジスタ1541の出力である。次いで、第1の段階の暗号化エンジン1562の結果として生じる出力は、第2の段階の暗号化エンジン1563への入力の1つとして供給される。第2の段階の暗号化エンジン1563への他の入力は、セキュア化実行モードアクセスポイント1566の出力である。
アクセスポイント1566は、標的終点デバイスが、セキュア化実行モードで起動中であるとき、または図14に関して上述のように、「再帰終了」条件が検出されるときにのみ、標的終点のハードウェア特有の秘密キー1540の値を通過するように動作可能である。次いで、第2の段階の暗号化エンジン1563からの結果として生じる出力値は、この生成されたデジタル署名を候補コードブロックとともに供給されるデジタル署名と比較する際に使用するために、デジタル署名レジスタ1564内に格納される(例えば、図9、10、11、12、13、および14の説明において参照されるように)。
デジタル署名レジスタ1564の出力は、その作用が、標的終点デバイスがセキュア化実行モードで起動中ではないとき、デジタル署名レジスタ1564の値を通過させることであるアクセスポイント1565によってゲートされる。次いで、アクセスポイント1565の出力は、図14に関する説明において詳述されたカスケード式メッセージダイジェスト特徴を作成するために、ハッシュ関数シードレジスタ1510の入力にフィードバックされる。標的終点デバイスが、セキュア化実行モードで起動中の時、ハッシュ関数シードレジスタ1510への入力は、デジタル署名レジスタ1564の値に依存せず、したがって、ある初期値に(図14に関する説明において詳述されるように)、またはある他の手段(例えば、特有の記憶場所へのプロセッサ書き込み等)によって、設定可能である。
上述の明細書では、本発明は、特有の実施形態を参照して説明された。しかしながら、当業者は、記載される本発明の範囲から逸脱することなく、種々の修正および変更が成され得ることを理解するであろう。故に、明細書、付属書、および図面は、限定的意味ではなく、例示としてみなされ、そのような修正はすべて、任意の制限的用語の使用に関わらず、発明の範囲内に含まれることが意図される。
効果、他の利点、および問題の解決策について、特有の実施形態に関して上述された。しかしながら、任意の効果、利点、または解決策を生じさせるか、あるいはより顕著となり得る、効果、利点、問題の解決策、および任意の構成要素は、請求項の一部または全部の決定的、必要、あるいは必須特徴もしくは構成要素と解釈されるべきではない。
(付属書A)
本発明ならびにその種々の特徴および利点の詳細は、付随の図面に例示され、以下の説明に詳述される、非限定的な実施形態を参照してより完全に説明される。周知の開始材料、処理技術、構成要素、および機器の説明は、本発明を細部において不必要に曖昧にしないように省略される。しかしながら、発明を実施するための形態および特有の実施例は、本発明の好ましい実施形態を示すが、限定としてではなく、例示のみとして与えられることを理解されたい。根底にある発明の概念の精神および/または範囲内における、種々の代用、修正、追加、および/または再配設は、この開示から、当業者には明白となるであろう。
ここで、デジタルコンテンツを保護するために意図されたセキュリティプロトコルのためのシステムおよび方法に注意が向けられる。これらのセキュリティプロトコルは、任意のデジタルコンテンツのために使用可能であって、また、実際のデジタルコンテンツが改変されることを必要とすることなく、通常、従来の電子透かし方式と関連付けられている、身元追跡の概念をサポート可能である。これらのプロトコルは、全デジタルビットストリームが等しいという前提に基づいているため、プロトコル自体に対するアップデートへのアクセスを制御するために、再帰的方式でも使用可能である。言い換えると、プロトコルは、データが、保護されるべきメディアストリーム、それらのストリームを再生するために必要とされる実行可能コード、それらのストリームを再生するために必要とされる暗号化された実行可能コード、それらのストリームを再生するために必要とされる暗号化されたコードを復号化するために必要とされる実行可能コード、復号化コード等とともに使用されるべきキー等であるかどうかにかかわらず、デジタルデータの種類を区別しない。これらのデータのデジタル性質はすべて、プロトコルに重要なものである。したがって、デジタルデータの性質および/または使用は、セキュリティプロトコルに対して懸念とはならないため、プロトコル自体を保護可能である。
この能力は、セキュリティプロトコルが実行の間においてさえ、起動中のハードウェアに対する任意の変更を必要とすることなく、アップデート可能であることを意味する(例えば、最近発見されたセキュリティホールを修復するために)。「より古い」セキュリティシステムは、より新しいセキュリティシステムの一部として、「組み込まれる」(すなわち、新しく、潜在的に、よりセキュアなレベルの保護をシステム全体に追加するために、古い保護「ラッパ」を除去する必要はない)。したがって、システム全体が、最新の最もセキュアな暗号化および/またはアクセス制御システム内に封入される。新しいキーが追加され得るだけではなく、同様に、完全に新しいセキュリティおよび/または暗号化アルゴリズムが、既存のシステム上に追加可能である。
この柔軟性によって、プロトコルは、時間制限レンタル、番組有料視聴、多重バージョニング、機械依存的使用許諾権の取消、およびユーザ間の所有権の永久譲渡を含む、いくつかのビジネルモデルをサポート可能となる。
著作権のあるソフトウェアアプリケーションが、例示的実施形態において利用されるが、同一方法およびシステムを使用して、テキスト、映像および音声データ、ソース、ならびにオブジェクトコード等を含む何であれ、任意のビットストリームにセキュリティを提供可能であることが、当業者によって理解されるであろう。
セキュリティプロトコルの実施形態が、提供するように設計される、基本的機能は、以下;
公正使用(「時間シフト」、「空間シフト」、および保存用バックアップ)
増分アップグレード
所有権の一時的譲渡
所有権の永久譲渡
時間制限アクセス
使用制限アクセス(使用回数)
デバイス特有の使用許諾権の取消
データまたはストリーム特有の使用許諾権の取消
を含む(しかしながら、それらに限定されない)。
多くのセキュリティシステムの場合、著作権のある作品内に含有される知的特性の保護のための一次メカニズムの1つは、単純アクセス制御である。しかしながら、そのようなメカニズムが、そもそも迂回される場合、最も高度なアクセス制御メカニズムによって供与される保護さえ、ほとんど価値がなくなる。これは、アクセス制御が、無益なメカニズムであるというわけではないが、単に、それ自体が総合的セキュリティシステムではないということである。いくつかの著作権のあるメディアストリームが、インターネット上で公開消費のために自由に利用可能であるという事実は、そのようなセキュリティシステムが、ほぼ常に迂回可能であるということの証拠である。また、この種類のアクセス制御は、オリジナルがそもそも破壊される危険性がある場合に必要である、合法的に購入された著作権のある作品のバックアップコピーを作成するためのメカニズムを確立することをより困難にする。したがって、本明細書に説明されるセキュリティプロトコルは、それを有用にするための任意の種類のアクセス制御システムを必要としない。
説明されるセキュリティプロトコルは、作品自体を成すデジタルデータではなく、著作権のある作品の表現を制御することに焦点を合わせる。したがって、プロトコルは、著作権のある作品を封入するために使用されるデジタルデータ、またはその作品が解釈されるべき方法を記述するために使用される他のデジタルデータを区別しない。その結果、プロトコルは、他のセキュリティプロトコルを封入するためにさえ使用可能である。
(基本的動作の説明:)
セキュリティプロトコルの実施形態は、ある1本のソフトウェアの著者が、それらのコードが、そのアルゴリズムのコピーまたは別様に不正流用を所望する者による分解から保護されているという十分な信頼性を持てるように設計される。また、本コードが、その機能を改変しようとする者による書換えから保護するように設計される。これらの主要特徴が、その他の点では汎用であるコンピューティングシステム内に実装可能である方法の1つは、以下のセクションで論じられる。これらの2つの主要機能の副産物として生じる付加的特性は、ソフトウェアが起動可能な条件(すなわち、コードを実行可能な時、方法、および機械または複数の機械)を制御する能力である。これらの機能の第1は、改ざん防止タイマ要素をシステムに追加することによって達成されてもよい。その他は、当該コードブロックを実行するために満たされなければならない所望の条件を示すために使用されるセキュアなデータ構造を実装することによって達成される。このデータ構造は、ハードウェア特有ではないので、種々の方法において使用可能であって、それを解釈するために使用されるソフトウェアをアップデートすることによって書換え可能である。プロトコルをより効率的に実装するために利用されるハードウェア特有の特徴について論じられ、これらの特徴が、どのようにプロトコルをサポートするために利用可能であるかの実施例が与えられる。最後に、プロトコルが、どのように使用され、著作権のある作品を保護可能であるかを示す。
セキュリティプロトコルの実施形態は、その意図された受信者による復号化のみを可能にするためにデジタルビットストリームを暗号化する能力に依存する。これは、良く理解されている問題であって、多数の業界標準暗号化アルゴリズムの基本である。しかしながら、セキュリティプロトコルの実施形態と併用するために、一般的オンチップ命令キャッシュ(I−キャッシュ)の(比較的に)小範囲内に適合可能な場合に有用であるという事実と、半自律態様で起動可能であるという事実の考慮されるべき2つの付加的要因が存在する。言い換えると、プロトコルが小さく、通常の日々の動作のために、中央セキュリティサーバの使用を必要としない場合、有用である。
(ハードウェア:)
次に図1を参照すると、このセキュリティプロトコルを実行可能なデバイスの例示的全体のブロック図が示される。セキュリティプロトコルシステムの要素として、プロトコルエンジン(また、「標的ユニット」としても知られる)100上において、セキュアな態様がプロトコルを実装するハードウェアブロック集合を含んでもよい。これらのブロックは、プロトコルが正確に動作するために、ハードウェア内でキャストされる必要がない。しかしながら、後述のハードウェア要素のすべてを含むデバイスは、最小オーバーヘッドによってプロトコルを実装可能であろう。
これらのハードウェアブロックの第1は、リアルタイムクロック102である。これは、中央サーバとのセキュアな更新によって設定またはリセット可能である、自走タイマである。セキュアな時間標準のクエリを行うことによって時間が確立され得るため、これは、完全に必須のブロックではないが、この機能をオンチップとして有することは、より便宜的となるであろう。これは、時間依存ソフトウェアライセンスと関係があり、そのような実施例は、本書の後のセクションに与えられる。
別のハードウェア要素は、メモリ110のブロックであって、そこでは、実行されるコードが、オンチップとして格納可能である。これは、一般的には、命令キャッシュ(I−キャッシュ)と知られるが、いくつかの実施形態では、このI−キャッシュ110の一部の重要な特性は、あるブロック内に含有されるデータが、CPU実行ユニット120によってのみ可読であることである。言い換えると、I−キャッシュメモリ130のこの特定のブロックは、実行専用であって、任意のソフトウェアによっては、読取りまたは書込みできない。I−キャッシュのこの特別セクションを「セキュア化コードブロック」130と称する。実行されるコードが、このセキュア化I−キャッシュブロック130内に実際に置かれる態様は、別のハードウェア要素によるものであってもよい。
加えて、セキュアなコードブロックの動作を加速させるために使用可能な可能性のある「拡張」の他のカテゴリが存在する。これらの1つは、CPU120がセキュアなコードで実行中、アクセスのみ可能である、および/またはセキュアなコードブロックの実行の完了に応じて消去される(すなわち、ある理由から、実行ユニットが、非セキュアなまたは「正常」I−キャッシュ内に位置する、コードの任意のセクションにジャンプする場合)、CPUレジスタ140の(サブ)集合を指定する能力である。CPU120が、「セキュア化」コードと「非セキュア化コード」の混合を実行する可能性はないと考えられ得るが、割り込みルーチン内にジャンプする際、コンテキストを切り替えるプロセスにおいて何が生じ得るか、およびCPU120コンテキストが格納される場所(大部分のCPUは、潜在的に、非セキュア化コードブロックによって、後に発見を被る、メインメモリ内にコンテキストを格納する)を、常に考慮しなければならない。
別の可能性(セキュア化コードブロックの著者が、どのレジスタ140が消去されるべきかを明示的に識別することを必要とする以外)は、自動的にそれを行わせることである。これは、CPU実行ユニット120が、セキュア化コードブロック内で実行中、どのレジスタ140が、読み取りまたは書き込まれるかを記録し、次いで、「セキュアな」モードの終了に応じて、それらを自動的に消去することになる。これによって、セキュア化コードは、2種類のコードブロック間で共有が許可されているデータのみをそのままにするために、その後、迅速に「クリーンアップ」可能となる。「自動」プロセスは、潜在的に、「明示」手順よりもセキュアであり得るが、コード著者が、セキュア化と非セキュア化コードブロックとの間で情報を共有することを所望する場合、より複雑となるであろう。
セキュアと非セキュアなコードセグメントとの間のレジスタ格納データの「漏洩」に対処するための別の潜在的態様は、CPU120が、セキュア化コードで実行中にのみ使用される一意的集合のレジスタを識別することである。大きい汎用レジスタ集合140を有するあるCPUアーキテクチャの場合、これは、一見、非常に高価であると考えられ得る。しかしながら、同一効果は、多くの最新CPU設計において実践されている、レジスタリネームおよびスコアボードメカニズムの書き換えられたバージョンを使用することによって、過度の量のオーバーヘッドを必要とすることなく(すなわち、物理的に個別の集合の「セキュアな」レジスタを実装する際に伴う、シリコンオーバーヘッドがなく)、達成可能である。セキュア化コードブロックの実行をアトミックアクション(すなわち、割込み不可能)として処理する場合、これらの問題は、より対処しやくなるが、この便宜性は、性能および潜在的コード全体の複雑性を犠牲にし得る。I−キャッシュ130の「セキュア化」部分は、必ずしも、I−キャッシュ150の「正常」部分として、CPUに対する異なるデータパスを必要としないことに留意されたい。実際、2つは、完全に同義的であり得る。
また、一方向ハッシュ関数ブロック160も図示されている。ハードウェア内にこの機能を実装する必要なく、セキュリティプロトコルの実施形態を実行可能なエンジンを構築可能である。しかしながら、ハッシュアルゴリズムのある部分のためのハードウェアアクセラレータは、当然ながら、望ましい特徴である。この機能ブロックのハードウェアとソフトウェア実装との間のトレードオフについては、後述される。
標的ユニット100の別の部分は、標的ユニット100の秘密キーおよび公開/個人キー(後述)を使用して、実行可能コードブロックに変換するために、暗号化されたメッセージに作用する、ハードウェア支援復号化システム170であってもよい。この復号化システム170は、いくつかの方法で実装可能である。プロトコル全体の速度およびセキュリティは、このブロックの構造に依存してもよく、したがって、セキュリティシステムアップデートに対応するために十分柔軟性があるだけではなく、システムが時間クリティカルなメッセージのリアルタイム復号化を行うために十分高速であるべきである。
それらの2つの制約を考慮すると、正確にどの暗号化アルゴリズムが、このハードウェアブロック170のために使用されるかは、プロトコルにとって重要ではない。最大の柔軟性を促進するために、実際のハードウェアは、非アルゴリズム的に特有の態様で使用可能であるために十分汎用性であることが想定されるが、このメカニズムを実装可能な多くの異なる手段が存在する。
また、点線でブロック図内に示される、オンチップ乱数発生器180が存在することに留意されたい。このブロックは、任意である。加えて、次いで、ソフトウェアベースの疑似乱数発生システムのためのシード値を供給するために使用可能な、十分に乱数であるシーケンスを生成する好適なオフチップ方法と置換可能でもある。また、この疑似乱数発生器は、潜在的に、ハードウェアまたは「セキュアな」ソフトウェア内に実装可能である。当然ながら、ソフトウェアベースのシステムの柔軟性とハードウェア実装との間の同一原理トレードオフが、この場合にも当てはまる。しかしながら、標的デバイス100が、乱数を生成しなければならない場合は、このプロトコルでは、頻繁に発生しないため、この特定の機能が、ハードウェアによって加速されない場合、性能全体に影響を及ぼす可能性は低い。
(秘密キー:)
各プロトコルエンジン(「標的」ユニット)100は、オンチップとして格納される、2つの秘密キー定数集合104を有してもよい(いずれも、ソフトウェア不可読値)。これらのキーの第1(一次秘密キー)は、実際には、秘密キー集合として編成可能であって、その1つのみ、任意の特定の時間に可読である。ユニットの「所有権」が変更される(例えば、プロトコルエンジンを含有する機械が販売されるか、またはその所有権が別様に譲渡される)場合、現在アクティブな一次秘密キーは、「消去」あるいは異なる値によって上書きされてもよい。この値は、セキュアな方法でユニット譲渡可能であるか、またはこの第1のキーが消去されるときにのみ使用されるような方法で、ユニット内に既に格納されていることが可能である。事実上、これは、その所有権が変更されるときか、またはそのような変更に対するある他の理由が存在する場合(危殆化キー等)、新しい一次秘密キーをその特定のユニットに発行することに相当する。この一次秘密キー値(または、値集合)が格納される唯一の他の場所は、中央サーバ上である。
一次秘密キーは、中央サーバのデータベース内の特定の標的ユニット100の通し番号106と関連付けられてもよい。通し番号106は、標的デバイス100上のいずれかの場所に格納可能であって、ソフトウェアアクセス可能であってもよく、一次秘密キーと他の関係を有さない。ユニットの動作上の側面に対する任意のアップデート(セキュリティシステムのアップデート等)は、一次秘密キーを使用することによって達成されてもよい。このキーの値が、標的ユニット100および使用許諾権限者以外の任意の当事者によって既知ではない場合、セキュアな中央サーバを介したリンクを伴わない、任意のセキュアなトランザクションのために使用不可能である。しかしながら、この一次キーのセキュリティは最も重要であるので、絶対的に必要であるときにのみ使用されるべきである。したがって、可能性として、例えば、中央の使用許諾権限者のサーバと標的ユニットとの間のセキュアなトランザクションのための通信リンクを暗号化するためには、使用されるべきではない。このリンクは、現在容認されている標準的実践に従って、高速で生成される、一時的キーを使用する標準的キー交換プロトコルを利用して、セキュア化可能である。
二次秘密キーは、標的ユニット100自体にのみ既知であってもよい(したがって、使用許諾権限者には既知ではない)。標的ユニット100のCPU120は、そもそも、一次または二次秘密キーのいずれの値にもアクセス不可能であるので、ある意味において、標的ユニット100はその独自の秘密キー104さえ「知らない」ことになる。これらのキーは、標的ユニットのCPU120のセキュリティブロック内にのみ、格納および使用される。これらの秘密キーの両方の組み合わせは、標的ユニットのセキュリティ全体を向上させる。その使用方法については、後述される。
さらに別のキー集合が、一時的公開/個人キーシステム(また、非対称キーシステムまたはPKIシステムとしても知られる)の一部として動作してもよい。この対にあるキーは、高速で生成され、中央サーバの介入を伴わずに、類似ユニット間のセキュアな通信リンクを確立するために使用される。そのようなシステムのセキュリティは、一般的には、同等キー長の対称キー暗号化システムのものより低いため、これらのキーは、上述の秘密キー集合のものよりサイズが大きくなければならない。これらのキーは、特に、「リプレー攻撃」に対して防護するために、オンチップタイマブロック内に存在する値と併用されてもよい。これらのキーは、高速で生成されるため、生成される態様は、ある種類の乱数発生システム180に依存する。最後に、生成されたキーが、いわゆる「脆弱」キーの種類に含有されないことを確実にするように配慮しなければならないことに留意されたい。「脆弱」とみなされる、特有のキー集合は、使用される特有の暗号化アルゴリズムに依存する。
(動作詳細:)
セキュリティプロトコルの実施形態が動作する態様は、システム初期化、セキュアなコード生成および一斉配信、セキュアなコードロードおよび実行、キーリストデータ構造構築、一時的使用許諾権譲渡、永久使用許諾権譲渡、システム所有権譲渡、使用許諾権の取消、およびセキュリティシステムアップデートと、いくつかの離散プロセスに分解可能である。これらは、それぞれ、次に論じられる。しかしながら、後述の実施例は、議論の簡略化を目的として選択され、必ずしも、このプロトコルを実装可能な最も効率的な(または、唯一の)態様であるわけではないことに留意されたい。
(システム初期化)
これは、標的ユニットの秘密キー104が、ある初期値に設定されるステップである。この手順は、いくつかの場所の1つ内で達成可能である(2つの秘密キーのいずれかの場合、論理的理由を別にすれば、通し番号または秘密キーが、可能性として変更され得る、アセンブリプロセス内の最終ステップであるべきである)。ユニット100の通し番号が、オフチップとして格納される場合、この手順は、最終アセンブリの時点で行われる可能性が高い。ユニットのための通し番号106が、オンチップとして格納される場合、任意の生産後またはバーンイン副産物が、非機能部分から選別される機会を有するように、チップ製造プロセスの最終時点で(すなわち、チップがパッケージ化された後に)、この手順を行うことが最も実践的であろう。このようにして、セキュアに維持しなければならないデータの量が最小となる。プロトコル全体のセキュリティは、ユニットの秘密キー104のものに基づき得るため、初期化手順は、物理的セキュリティが可能な時点で行われるべきである。
一次秘密キーは、二次秘密キーを供給するために使用されるものと異なる手順において、初期化される(または、デバイスに「焼き付けられる」)べきである。実際は、この二次キーは、ある時点で既知となるが(製造プロセスの際のある時点において、ユニット内にプログラムされるため)、標的デバイス100上に格納されると、関連付けられるユニットは、いずれの場所にも記録されるべきではない。監査目的の場合、総二次秘密キー値集合が、どの部分が、どのキーを保持するかを知らずに、検証されることが望ましいであろう(配信の無作為性を試験するため、またはある他の理由のため)。しかしながら、システムのセキュアな性質を維持するために、この第2の秘密キーをユニット内にプロググラムするデバイスが、二次秘密キーを第1の秘密キーまたは標的デバイス通し番号106のいずれにも関連付ける任意の手段を有していないことが望ましい。また、これらの秘密キーは両方とも、後述の理由から、改ざん防止態様で実装されるべきである。どの順序で、これらの2つの秘密キーが初期化されるかは重要ではない。例示的実施形態に記載の初期化手順後に、標的デバイスの通し番号106およびそれらの関連付けられた一次秘密キーが、共に置かれる唯一の場所(実際のチップ上以外)は、使用許諾権限者のセキュアなサーバ上であるべきである。
(セキュアなコード生成および一斉配信)
図5を簡単に参照すると、例示的シナリオでは、開発者520は、合理的に、分解を受けるおそれがなく、特有のデバイス上でのみ実行可能である、このプロトコル下で起動するためのアプリケーションを生成することを所望すると仮定する。各登録開発者520は、使用許諾権限者のサーバと通信するだけではなく、任意の公開コードブロックまたは他のビットストリームを認証するために使用可能な署名されたメッセージ認証コードまたはMAC(一般的には、デジタル署名と呼ばれる)を作成するために使用する、任意のメッセージを認証するために使用される、公開キー/個人キーの対を有するであろう。
アプリケーションがデバッグされた後、オリジナル開発者にのみ既知である、アプリケーション特有の暗号化アルゴリズムおよびキーを使用してエンコードされる。本願の特有のアルゴリズムおよびキーは、対称(秘密)キーシステムまたは非対称(PKI)キーベースのシステムのいずれかであり得る。コードの暗号化されたブロックの末端に付随するのは、次いで、それらの公開された公開キー/個人キー対(したがって、暗号化されたコードブロックのための一義的デジタル署名を形成する)の個人キーを使用して、開発者520によって署名される、MACである。デジタル署名またはオリジナルMACのいずれかおよび対応するコード特有のID番号は、使用許諾権限者に供給されてもよい。また、アプリケーション開発者520は、適切なデコードキーも同様に供給するように選択してもよい(この決定のトレードオフについては、本書の後のセクションに論じる)。
アプリケーション特有のアルゴリズムが、非対称暗号化システムである場合、必ずしも、署名されたメッセージ認証コード(デジタル署名)を生成するために使用される同一公開PKIキー対を使用して、暗号化される必要はないことに留意されたい。しかしながら、コードブロックの末端に格納されるMACは、既知のハッシュアルゴリズムを使用して生成されるべきであって、また、開発者の公開された公開キーの1つを使用して署名されなければならない(したがって、デジタル署名を形成する)。これによって、標的は、既知のハッシュ関数および既知の公開キーを使用して、MACの真正性を照合可能となる。
次に図2を参照すると、全アプリケーション特有の暗号化キーデータ構造210は、いくつかの余剰フィールド(復号化キー自体220に加え)を含有してもよい。これらのフィールドの1つは、タイムスタンプ230および関連付けられたマスク値240を備えてもよい。第2は、「カウントダウン値」250を含有してもよい。マスク値240は、キーが有効である時を決定するために、他の2つのフィールド230、250と併用されてもよい。また、正確にいくつのビットが、フィールドのそれぞれに分配されるかは、プロトコルに関連しないことに留意されたい。
タイムスタンプ値230は、タイムスタンプマスク240フィールド内に格納されるビットパターンに応じて、いくつかの方法で使用可能であることに留意されたい。タイムスタンプマスク240値によって、開発者520は、標的ユニット100の現在の時間との比較を行う際に無視される、あるサブ集合のタイムスタンプ値を選択可能である。しかしながら、実施例として、タイムスタンプフィールド230によってサポートされる最小分解能が1秒であると仮定する場合、タイムスタンプデータ230の下位5ビットからマスクを除去することによって、特定のキーデータ構造210は、タイムスタンプフィールド230内に格納される時間から開始して、約32秒にわたって使用されるときにのみ有効であるように生成可能である。セキュリティプロトコルの機能全体は、タイムスタンプフィールド230の最下位ビットの実際の分解能に依存しない。
マスクフィールド240と関連付けられる他のビットが存在してもよく、その一部は、タイムスタンプ230内に規定される値の前または後に、キーが有効であるかどうかを示すために使用可能である。さらに別のマスクフィールド240ビットは、タイムスタンプ230および「カウントダウン」値250がどのように関連付けられるかを示すために使用可能である。例えば、これは、アプリケーション開発者520の意図が、ある日付および時間窓に限定するのではなく、ある日付前または後のいずれかにおいて、ソフトウェアの使用をある反復数に制限することである場合に有用であろう。当然ながら、これらの条件の任意の組み合わせが構築可能であって、したがって、プロトコルは、この点において、非常に柔軟性である。加えて、さらに、フラッグをこのデータ構造に含み、いくつのキーの法的コピーが、オリジナル標的ユニット100から他に同時に配信されてもよいか等、他の特性を示すことが可能である。これは、例えば、デジタルライブラリに見られるような多重コピー使用許諾権が所望される場合に有用であろう。
暗号化プロセスの一実施形態を表す工程図が図3に見られる。デジタルメディアストリームまたはソフトウェアアプリケーション(そのメディアストリームを解釈するために使用される、復号化命令等)を配信するために使用されるであろうプロセス間に実質的差異は存在しないことに留意されたい。いずれの場合も、オンラインサーバまたはシリアル番号が付与されたディスク(標準的DVD等)のいずれかを介して暗号化されたコードブロック310、320を配信するために、いくつかの異なる選択肢が存在する。後者の場合、次いで、開発者520は、使用許諾権限者510によって(または、そうではなく)、大量生産されたディスクの個々の通し番号を事前に登録することを選択可能である。その場合、通し番号は、バーストカッティングエリアへの焼き付け(DVDの場合)またはインクジェット印刷(標準的CDの場合)によって、ディスクに永久に固定され得る。開発者520は、同一通し番号が、大量生産されたディスクのすべてにおいて複製されるため、CDまたはDVDのデータエリアにこれらの通し番号を埋め込むことはできないことに留意されたい。ディスクの一部が大量生産され、別の部分が一度書き込み可能であるある種類のハイブリッドフォーマットが使用される場合、これは、個々の通し番号とともに、ディスクを配信する別の潜在的方法となるであろう。いずれの場合も、登録プロセスの際にエラーを受けにくいので、機械可読の通し番号が当然ながら好ましい。
開発者520が、使用許諾権限者によって、メディア通し番号を登録しないことを選択する場合、適切な暗号化キーをアプリケーションまたはメディアストリームファイルと関連付け可能なある他の態様が存在し得る。したがって、アプリケーション開発者520は、コード特有のIDまたは関連付けられたメディア通し番号のいずれかを登録してもよい。前者の場合、アプリケーションは、自由に配信可能である(すなわち、特有のリリースフォーマットおよびメディアに限定されない)。
個々の通し番号メカニズムの場合、使用許諾権限者510は、どのアプリケーション(または、メディアストリーム)が、どの通し番号と関連付けられているかを知る必要(潜在的に、その意図)がないため、エンドユーザのプライバシーは、維持される。開発者520が、アプリケーションID(または、メディアストリームID)とともに、その関連付けられたキーを登録する場合、使用許諾権限者510は、どのアプリケーションまたはメディアストリームが、特定のエンドユーザによって「所有」されているかを知ることが可能である。一方、この潜在的プライバシーの欠如は、開発者520が物理的メディアを製造および配信することを必要としないという、付加的便宜性および費用の節約によって相殺される。用語「物理的メディア」は、必ずしも、ディスクを意味するものではないことに留意されたい。この機能は、それに貼付された個々の通し番号ステッカーとともに、印刷されたマニュアル(またはさらに単純登録形式)を使用することによって、同様に達成され得る。必要とされるものは、開発者520が、エンドユーザに供給される一意的な通し番号とともに、あるオブジェクトを生産しなければならないことだけである。この通し番号の目的は、ビットストリーム登録番号として作用することである。この通し番号が、どのようにプロトコル内で使用されるかについては、以下のセクションで論じられる。
図3に示される実施例の場合、暗号化されたソフトウェアアプリケーション(または、メディアストリーム)310および機械依存性復号化ソフトウェア330は両方とも、同一メカニズムを使用して配信される。これが該当し、暗号化されたコードブロック310、330の一方または両方が、オンラインあるいはディスクをプレスすることによって配信可能であることは、プロトコルの要件ではない。しかしながら、デジタルメディアストリームの場合、メディアストリーム自体が、2つのブロック310、330より数倍大きい可能性が高いことに留意されたい。したがって、その場合、大量生産されたディスクフォーマットとして、少なくとも本ブロックの配信をもたらすことが、最も有用である。多くの場合、そのようなディスク上には、随伴暗号化コードブロック(その1つは、第1のブロックをデコードする方法の命令を含有する)だけではなく、一次暗号化コードブロックに適合する、十分な余地が存在し得る。また、2つのデータ集合のいずれも、公開後、任意の変化を受ける可能性がなく、したがって、オンラインで配信されなければならないという基礎的要件が存在しないことに留意されたい。したがって、両方とも、大量生産されたディスクベースの配信メカニズムに好適である。また、同一ディスク上に両方を有することは、一義的方式において、一方を他方と関連付けることをより容易にする。
(セキュアなコードロードおよび実行)
配信メカニズムが、実際のディスクを介して達成される場合、消費者は、従来のソフトウェア購入と正確に同一態様において、アプリケーションを含有するディスクを購入可能である。当然ながら、エンドユーザは、「標的」ユニットのプロセッサ上で書き換えられていない暗号化されたコードブロックを起動することは不可能であろう。ユーザが、それらの機械上でアプリケーションを起動しようとすると、CPU120は、暗号化されたソフトウェアブロックをロードし、コードブロックの末端に格納されたデジタル署名(「署名された」MAC)とともに、ソフトウェア開発者の公開キーを使用して、当該コードブロックが本物であることを照合する。ここで、その他の点では汎用であるCPU120への最初のハードウェア書換えが、作用し始め得る。セキュア化コードのそのようなブロックをロードおよび復号化するためのプロセスは、図4に示される。
ハッシュ関数が正確に算出される(さらに、生成されたメッセージダイジェストと「実」メッセージダイジェストとの間の比較が有効である)ことを確実にするために、CPU120は、セキュアな態様において、このハッシュ関数を行わなければならない。したがって、ハッシュ関数は、デコーダユニットのハードウェアによって、直接生成されるか、またはハッシュ関数自体が、「セキュアな」コードのブロックを使用して算出されなければならず、その動作は、その他の点では「非セキュアな」プログラムによって改ざん不可能である。
ソフトウェアベースのハッシュの場合、セキュアなコードのこのブロックは、ユニット100のセキュリティシステムの一部としてみなされるべきであって、したがって、ユニット100と使用許諾権限者510とのセキュアなトランザクションを介して、プレーヤに対して、ダウンロードのみ可能であってもよいことに留意された。大変興味深いことに、「セキュアな」ハッシュ関数の確立は、本明細書に説明される同一のセキュアなプロトコルを介して達成可能である。セキュリティシステムのあらゆる側面に対するこの再帰的挙動は、その暗号化/復号化アーキテクチャにおいて、このプロトコルのソフトウェアベースのバージョンを非常に柔軟性のあるものにするものである(したがって、アップデート可能)。
メッセージダイジェスト計算が、ハードウェア内に固定される場合、潜在的に、ある程度のセキュリティを得ることが可能であるが、これは、柔軟性を犠牲にする。専用ハードウェアブロックが、ハッシュ値を生成するために使用され、次いで、チップが製造された後、ハッシュアルゴリズムにおけるある脆弱性が、ある時点で発見される場合(または、その実装内にあるバグが存在する場合)、事後に問題を解決する機会は存在しない。これは、プロセスを加速するために、ソフトウェアベースのハッシュ関数(プログラム可能S−Box構造等)のある種類のハードウェア加速の使用が不可能であるというわけではない。しかしながら、その場合、ハードウェアは、理想的には、多種の一方向ハッシュ関数をサポートするために十分に汎用性であるべきである。
しかしながら、このプロトコルのセキュリティは、最終的には、このセキュアなコードロード手順の一部として提供される最下位機能に依存することに留意されたい。下位特徴(ハッシュ関数において使用される秘密キーまたは初期動作等)は、異なる方法で組み合わせられ、署名されたメッセージダイジェスト等のより高位の機能をもたらす。次に、これらの高位機能ブロックは、身元照合等のさらに高位の可用性を提供するために使用される。より多くの初期層の上部に、より高位の機能を構築するこのプロセスは、「信頼の連鎖」の構築として知られている。システムの柔軟性は、セキュリティ関連機能が、この階層内の可能な限り低位の書換え可能な時点に置くことにかかっている。しかしながら、ある時点において、この連鎖が基づく基礎的な初期動作は、性質上アトミックでなければならない(すなわち、これは、ハードウェア内に実装されなければならない最小レベルの機能である)。ハードウェア粒度のこの時点の正確な選択は、大部分は、実装上の詳細であって、このプロトコルの動作全体は、上述の条件を考慮して、この側面に依存しない。
暗号化されたコードブロック310が、標的のメモリ空間110内にロードされ、メッセージダイジェストが計算されると、次いで、結果が、開発者の公開キーによって暗号化されたコード310とともに格納されたデジタル署名340を復号化することによって計算される、メッセージダイジェストと比較される。2つが整合する場合、標的ユニット100は、暗号化されたコードブロック310が本物である(または、少なくとも、コードが、その公開キーがデジタル署名を復号化するために使用された開発者520によって配信された)ことが確実であり得る。
この時点では、標的100は、次いで、新しく照合された暗号化コードブロックと併用される復号化キーのコピーを要求する、セキュアなメッセージを使用許諾権限者510に送信する。使用許諾権限者とのセキュアな接続を設定する一部として、標的ユニット100は、一時的公開/個人キー対を生成する(その公開部分は、使用許諾権限者510のサーバに供給される)。キー交換手順の詳細は周知であって、この議論では、これが達成される正確なメカニズムについて詳述する必要はない。いずれの場合も、標的ユニット100と使用許諾権限者510の中央サーバとの間のネットワークトラフィック全体が、数回のキー譲渡、コード特有のID、およびそれとともに格納されるMACから成るので、合理的に小データ集合に制限されることに留意されたい。
コード特有のID260が、使用許諾権限者510が認識するものであると仮定すると、アプリケーション著者が、使用許諾権限者510に、要求された復号化キーの「純正」コピーを既に提供しているかどうかに応じて、2つの可能性のある一連の作用が存在し得る。開発者520が、使用許諾権限者510に、そのような情報を提供していない場合、中央サーバは、標的デバイスの一時的公開キーのコピー(同様に、当該コード特有のID260)をアプリケーション開発者のサーバに伝送する。この時点で、開発者のサーバは、要求された復号化キー(標的の一時的公開キーによって暗号化されている)および適切に復号化されたコードから生成されたメッセージダイジェストを含有するメッセージによって、使用許諾権限者510サーバに応答する。このように、標的デバイス100のみ、メッセージを復号化し、アプリケーション特有の復号化キーを得ることが可能であって、使用許諾権限者510は、そもそも、純正形式にある復号化キーへのアクセスを有していない。
メッセージダイジェストは、事前に算出され、使用許諾権限者のサーバに格納可能であるが、トランザクションの際に、開発者520によって提供され得るという事実は、ハッシュ関数(メッセージダイジェストを生成するために使用される)が、そもそも、変更するはずである場合、潜在的に有用である。これが生じる場合、開発者520は、標的デバイス100との実際のトランザクションに先立って、またはその間に、アップデートされたバージョンの復号化されたコードメッセージダイジェストを使用許諾権限者510に提供する必要であろう。使用許諾権限者510は、オリジナル(復号化された)コードへのアクセスを有するべきではないため、開発者520は、この情報を提供しなければならない。上述のように、使用許諾権限者のサーバと開発者のサーバとの間のネットワークトラフィックの量は、依然として、非常に小さい。次いで、開発者520から受信された暗号化されたキーは、使用許諾権限者510から標的への伝送に先立って、標的デバイスの一次秘密キーによって、再び、さらに暗号化される。この第2の暗号化は、実際には、他のトランザクションの一部として、開発者側で行われ得るが、その場合、開発者は、潜在的に、エンドユーザの潜在的プライバシー問題の損失をもたらす、標的ユニットの一次キーへのアクセスを有するであろう(両方のキーが、何らかの形で組み合わされていない限り)。
アプリケーション開発者520が、使用許諾権限者510と標的デバイス100との間のトランザクションに対して、「ループ外」に留まることを所望する場合、単に、使用許諾権限者510に、純正(非暗号化)形式にある関連復号化キーのコピーおよび復号化されたコードブロックのための関連付けられたMAC(その値は、ハッシュアルゴリズムが変更される度に、アップデートされなければならない)を提供することが可能であることに留意されたい。したがって、使用許諾権限者510の中央サーバは、自律的に作用可能であって、標的ユニット100からのキー要求を充足するために、開発者のサーバとの通信リンクを確立する必要はないであろう。しかしながら、これは、この「純正キー」情報が、そもそも、使用許諾権限者によって、意図的または非意図的に、危殆化される場合、潜在的セキュリティの危険性を開発者にもたらす。
キー暗号化/復号化プロセス全体の工程図が、図5に概略される。この場合、純正キーは、依然として、伝送(上述のように)に先立って、標的デバイスの一時的公開キーと、次いで、再び、標的の一次秘密キーの両方によって、暗号化されるであろう。この時点で、標的デバイス100は、二重に暗号化されたフォーマットにおける適切な復号化キーを有する。使用許諾権限者510が、暗号化されていない状態のアプリケーション特有のキー550情報へのアクセスを有していない場合、各ユニット100のための秘密キーは、使用許諾権限者510にのみ既知であって、伝送のための個人キーが、標的100によってのみ知られているため、意図された標的デバイス100以外の任意の者が、純正形式におけるこのキーデータを複製することが可能となることは不可能であるはずである。
しかしながら、この時点では、標的100がアプリケーション開発者520から受信する、エンコードされた復号化キーは、未だ、標的100において、公に安全に格納不可能である(例えば、フラッシュROM内またはハードドライブ上のバックアップ)。問題は、標的デバイス100が、また、使用許諾権限者510から伝送された、エンコードされた復号化キーとともに、一時的個人キーのコピーを格納する必要があることである。次いで、使用許諾権限者510の任意の者が、ある手段によって、これらの2つのデータへのアクセスを得ることになる場合、潜在的に、復号化されたアプリケーション特有のキー550を再構築可能となるであろう(標的デバイス100の一次秘密キーへのアクセスも同様に有すると仮定して)。
ここで、標的デバイスの二次秘密キーが使用されるようになる。この二次秘密キーは、標的ユニットの復号化ユニット以外のいずれの者にも未知であることを思い起こされたい。したがって、標的100に使用許諾権限者から供給されたキーを復号化するために、一時的個人キーが使用されると、二次秘密キーは、その使用(および/またはアーカイブ)に先立って、アプリケーション特有のキーを再暗号化するために使用される。
次いで、標的は、コードブロック(または、メディアストリーム)を復号化するために、アプリケーション特有の(純正)キー550を使用可能となる。したがって、アプリケーションコードが純正形式において存在する、唯一の2つの場所は、オリジナル開発者520自体と、標的デバイスのI−キャッシュ110の「セキュア化」部分内(実行のみ可能であって、純正形式におけるメモリへの書き込みは不可能である)である。これは、ユーザと使用許諾権限者510との間のプライバシーを可能にする。言い換えると、使用許諾権限者510は、ユーザが使用許諾権を有するのは何なのか(計り知れないプライバシー上の利点)を知る必要はないが、依然として、そのユニット100が損傷を受けるか、または盗まれるか、あるいは別様に動作不可能にされる場合のユーザのキーリストのためのリポジトリ(または、バックアップ)として作用可能である。
復号化プロセスが正確に行われたかを検証するための確認として、次いで、適切に復号化されたコードのメッセージダイジェストが、オリジナル開発者520から、使用許諾権限者510を介して標的ユニット100に転送されたデジタル署名を復号化することによって生成されたメッセージダイジェストと比較される。上述のように、このデジタル署名は、非暗号化コードブロックのメッセージダイジェストをアプリケーション開発者の個人キーによって暗号化することによって作成される。代替として、また、このデジタル署名は、開発者520によって、接続が確立された時、使用許諾権限者510に供給された、別の一時的公開キー530を使用して、再び、暗号化可能である。いずれの場合も、次いで、正確なメッセージダイジェストは、開発者の公開キーによって、デジタル署名を復号化することによって、標的デバイス100によってデコード可能である。このメッセージダイジェストが、復号化されたコードブロックのMACと整合する場合、コードは、本物であるとみなされ、標的100上で実行可能となる。次いで、このメッセージダイジェストは、再暗号化されたアプリケーション特有のキー550とともにアーカイブのために、標的ユニットの二次キー540によって、再暗号化されてもよい。
この手順における最終ステップは、新しく暗号化された(標的デバイスの二次キー540によって)バージョンのアプリケーション特有のキー560が、アーカイブ目的のために、使用許諾権限者510サーバに再伝送されることである。この伝送は、いくつかの目的を果たす。第1に、標的デバイス100が、コードブロックを適切に復号化可能であったことの確認応答である。第2に、エンドユーザが、ある種類の壊滅的データ故障を被り、それらのアクセスキーの独自のバックアップコピーの作成を怠った場合に対処するために、使用許諾権限者510は、この暗号化されたキー560のコピーを有することが必要とである。次いで、使用許諾権限者510は、任意の特定のユーザのためのバックアップ記憶施設として作用可能である。この手順のさらに別の理由は、特定の標的デバイス100が、あるユーザから別のユーザに所有権を変更する場合、またはユーザが、それらの標的デバイス100のアップグレードを所望する場合に対処するためにある。この種類の所有権の永久譲渡は、そのユニット100のための使用許諾のあるアプリケーションキーのすべての譲渡を伴い得る(その場合、新しい所有者の名前下のユニットを再登録する以外行う必要はない)。しかしながら、ユーザが、第1から第2のデバイスへのそれらのキーデータの永久所有権の譲渡を所望する場合、これは、使用許諾権限者510と両方の標的デバイスとの間のセキュアなトランザクションによって達成されてもよい。
標的デバイス100が、使用許諾権限者510のサーバに返送する他の情報は、標的デバイスの新しくアップデートされたキーリストデータ構造610のメッセージダイジェストである(図6に図示されるように)。これは、新しくアップデートされたキーリストデータ610構造の確認応答でもあり、また、使用許諾権限者510のサーバおよび標的デバイス100上のその特定の標的デバイス100と関連付けられたキーリストデータ構造610の等価性を検証するためにも使用される。このデータ構造の正確な構造については、以下のセクションで後述される。また、後のセクションにおいて、特定のキーまたはキー集合の所有権の永久譲渡が達成される方法についても論じる。
この時点では、上述のプロセスが、プロトコルが、開発者520から標的デバイス100に、アプリケーション特有のキー550を譲渡するために使用可能な唯一の態様ではないことに留意されたい。例えば、実際のキー譲渡トランザクションは、標的100とアプリケーション開発者520との間のみの直接接続を伴うことが可能である。しかしながら、その場合、接続は、デバイス特有の暗号化情報をトランザクションに寄与するために、開発者のサーバと使用許諾権限者のサーバとの間で確立されなければならない。このプロトコルがセキュアな態様で作用可能ないくつかのメカニズムが存在するが、上述の実施例は、これらの1つにすぎない。しかしながら、共通の特徴は、標的100に譲渡されるキーデータが、その標的デバイス100のためにのみ使用可能であることを保証するために、3当事者すべてが、ともに作用しなければならないことである。
キーの構造は、ハードウェア特有の部分だけではなく、アプリケーション特有の部分の2つの部分を有するように設定可能であることに留意されたい。これらの2つの部分が、完全に非分離であることは要件ではない。非分離である場合、上述のように、その特性を正確に得る。しかしながら、キー部分を独立して動作可能にする方法が存在する場合、グローバルコピー集合を有効化し、実際のコードまたは実際の標的デバイス100から独立し得る、制約を使用可能である。言い換えると、任意の開発者520は、配信に関する制約を有さないが、読取不可能であって、実行のみ可能なアプリケーションまたはメディアストリームを公開し得る。これは、使用許諾権限者510が、製造業者にかかわらず、あらゆるデバイス上で起動するであろう、セキュリティシステムアップデートの送信を所望する場合、有用となり得る。これの別の実施例は、公的に利用可能である一方、依然として、そのストリームに対する著作権の制御を維持するメディアストリームのブロードキャストであろう。同様に、公開者は、任意の者が、読取および/またはコピー可能であるが、1つの特有の標的デバイス100またはデバイス集合上でのみ実行する、アプリケーションを配信し得る。これは、例えば、「この特有の種類のデバイスのアップデート」メッセージを送信するために有用であり得る。別の可能性のある用途は、どこでも起動され、配信に関する制約を有さない、アプリケーションを送信することである。これは、特定のアプリケーションのためのソースコードの公開に性質上類似するであろう(すなわち、オープンソース配信)。分離可能H/W特有のおよびS/W特有のキー構造によって有効化される、異なる種類のセキュリティは、表1に例示される。
Figure 2015035224
(キーリストデータ構造構築)
次に図6を参照すると、特定の標的デバイス100に使用許諾されているアプリケーションまたはメディア特有のキーのリストを含有するデータ構造610は、有益な利点であって、したがって、所有者によってバックアップ可能であるべきである。個々のキーは、標的の二次秘密キーによって暗号化されているため(上述のように)、リストは、キーが使用許諾されているユニットに対してのみ有用である。しかしながら、このデータ構造610が、改ざん、破損、および/または完全な損失に対してセキュアであることが、確証可能である必要がある。キーリストデータ構造が損失される場合、データ構造610全体が、上述のように、使用許諾権限者510から、その特定の標的デバイス100のためのキーリストの新しいコピーを要求することによって復元可能である。一時的変化がキーリストデータ構造に成される場合(そのようなシナリオの理由については、以下のセクションにおいて論じる)、プロトコルは、そのような変化を一時的として識別するための手段を講じてもよい。最後に、キーリストデータ構造610の真正性、適時性、および有効性を検証するためのある改ざん防止メカニズムを含む。
これらの要件を考慮して、図6に示されるような態様において、これらの品質すべてを呈するセキュアなキーリストデータ構造610を構築可能である。これまでのように、示される実施例は、所望の特性すべてがそのようなデータ構造内に含まれ得る唯一の方法ではない。しかしながら、図6に例示される特定のデータ構造は、実際、プロトコルの基本的要件のすべてを充足するものである。
上述の概略図において留意されるべきいくつかの基本的指針が存在する。第1は、キーリストデータ構造610の上位暗号化が、標的デバイスの一次秘密キーによって行われなければならないことである。この特定のキーを使用するためのいくつかの理由が存在するが、主要な問題は、このデータ構造のローカルコピーが復元されなければならない場合、使用許諾権限者510が、標的デバイス100から独立して、このデータ構造の暗号化された形式を再生成可能でなければならないことである。任意の他のキーが、このデータ構造(例えば、標的の二次秘密キー等)を暗号化するために使用される場合、標的が、データ構造に変更を行う必要があると(キーがリストに追加される場合のように)、リスト全体が、バックアップ目的のために、使用許諾権限者510に譲渡されなければならない。これは、潜在的に、使用許諾権限者510に返送されなければならない、ネットワークトラフィックの量を大幅に増加させ得、必ずしも、チャネル帯域幅の最も効率的使用ではない。
また、このキーリストデータ構造610は、標準的アプリケーションまたはメディアストリーム特有の使用許諾キーの記憶のために使用されるのに加え、セキュリティシステム関連キーの記憶のために使用されることが望ましい。このデータ構造は、使用許諾権限者510によって再生成可能であるため、標的デバイス100上で起動する、セキュリティソフトウェアをアップデートすることが望ましい場合には、同一キーリストデータ構造610が、両機能のために使用され得る場合、よりセキュアかつより効率的となるであろう(標的デバイス100上のコード記憶要件の観点から)。
第2の問題は、暗号化されたバージョンのキーリストデータ構造610が、オリジナルキーリストデータ構造610のメッセージダイジェストを含むことである。個々のキーそれぞれが、暗号化されるが、リスト自体の他の部分は、メッセージダイジェストが計算される時に別個に暗号化されないことに留意されたい。メッセージダイジェスト計算後、キーリストデータ構造610全体(メッセージダイジェストを含む)は、次いで、上位(または、マスタ)キーによって識別される、キー値およびアルゴリズムによって暗号化される。これは、悪質な第三者が、リストを改ざんし、新しいメッセージダイジェストを計算し、次いで、書き換えられたリストを本物の代わりに代用することを防止ために行われる。キーリストデータ構造610が、標的ユニット100のメモリ空間内に読み込まれると、この(復号化された)メッセージダイジェストは、MACが、任意の他のセキュアな暗号化されたコードブロックのために使用される方法と同一態様において、キーリスト自体の真正性および有効性を検証するために使用される。個々のキー以外の要素はすべて、マスタキーによってのみ暗号化されるという事実は、上位キー以外の任意のキーへのアクセスを有する必要なく、リストがトラバース(さらに、リストが維持)可能であることを意味する。また、キーリスト一覧は、復号化ブロックを通る唯一の単一パスとともにコンパイル可能である。
着目される第3の原理は、個々のアプリケーションコードまたはメディアストリーム特有のキーが、各標的デバイス100のための個別のキーに対応するために十分大容量に作成され得ることである。コードまたはメディアストリームが、大量生産されたディスクを介して配信される場合、これは、アプリケーション開発者520が、新しいコード特有のIDとともに、個々の復号化キーを発行する必要があることを意味するであろう。これは、使用許諾プロセスに関与する当事者すべて間で譲渡されなければならないデータ量を最小に使用とする観点から、あまり効率的であり得ないが、危殆化復号化キーを追跡する能力を含め(しかしながら、これに限定されない)、プロトコルに機能を追加することになる。また、これについても、キー取消の対処に関する後のセクションにおいて論じられる。
留意すべき次の問題は、キーリストデータ構造610ヘッダが、リストの残りを編成する、アプリケーション特有のキーと同一特徴集合を共有することである。実際、ヘッダは、キーリストデータ構造610自体の残りのためのマスタキー620と考えられ得る。したがって、このキーが、どのようにリストの残りの管理を決定するために使用可能であるかに関する限り、同一動作原理が適用され得る。これは、標的デバイス100のセキュリティシステムの時間依存性管理を含む。したがって、標的ユニット100は、事前に決定された間隔において、そのセキュリティシステムをアップデートするよう強制され得、これは、それ自体、非常に強力な概念である。
また、キーリストが、それぞれ、その独自のマスタキー620(リストヘッダ)と、したがって、その独自の独立暗号化メカニズムを伴う、いくつかのセクションを含有し得る可能性が存在する。任意の他のキーと同様に、リストヘッダは、キーリストデータ構造610を解釈するために使用される、暗号化されたコードブロックをポイント可能なコード特有のIDフィールド260を含有する。次いで、リスト全体が、その独自のマスタキー(さらに別のリストヘッダである)を含む、さらに別のマスタリスト内に含有され得る。したがって、キーリストデータ構造610全体を再帰的に画定可能である。上述のように、この再帰的特性は、新しいキーリストデータ構造を作成し、同一データ構造の以前のバージョンの欠点を解決することによって、セキュリティシステムをアップデートするために使用可能である。リスト全体のセキュリティは、「最外」(または、最も新しい)セキュリティ層内に含有されるため、キーリストデータ構造610全体のセキュリティは、常に、セキュリティソフトウェアの最新の反復に基づく。
したがって、キーリストデータ構造610の再帰的特性は、有力な特徴である。また、上述のセクションにおいて論じられたデータ構造のまさにその実装が、それほど重要ではない理由でもある。上述の説明は、単に、プロトコルの再帰的性質を作用させるために必要とされる機能の最小サブ集合である特徴が含まれる、実施例である。
どのように構築されるかに関わらず、キーリスト610は、いくつかの共通環境下、維持および/またはアップデートされてもよい。これらの環境として、リスト内に含有されるキーの1つ以上の状態が書き換えられる場合を含む(しかしながら、それらに限定されない)特定のキー210の所有権が、あるユニットから別のユニットに譲渡され得る、いくつかの基本的メカニズムが存在するが、これらについては、後のセクションで論じられる。しかしながら、いずれの場合も、改訂されたキーリストが維持されるメカニズムは、使用許諾権限者510の介入を必要とするものと、独立して実行可能であるものの、2つの種類に分割可能である。
このプロトコルが基づく、主要動作概念の1つは、使用許諾権限者510の中央サーバと個々の標的ユニットとの間の必要とされるネットワークトラフィックの量を最小に低減させることである。したがって、キーリストデータ構造610への任意の一時的変更(その理由については、後述される)は、標的ユニット100によって、独立して維持可能であるべきである。これに対する主要理由は、これらの変更が、表面上は、デバイスのセキュリティシステムへの永久変更(標的デバイス100と使用許諾権限者510との間の交信によってのみ、常に、達成されるべきである)より頻繁に、生じるであろうことである。
いずれの場合も、標的デバイス100が、一義的態様においてマスタキーリストデータ構造の現在の状態を記録可能なあるメカニズムが存在しなければならない。これは、2つの「マスタ」リストを有することによって達成可能である。これらの2つのリストの第1(永久キーリストと称する)は、使用許諾権限者510によって維持される。このリストは、当該標的ユニット100と関連付けられる、アプリケーション特有のキーの「永久」所有権に関係している。第2のリストは、同様に重要であるが、「永久」キーリストデータ構造への一時的書換えに関係しているものである。これらの書換えは、リストへの追加またはリストからの削除のいずれかであり得ることに留意されたい。2つのリスト自体のデータ構造の実装に必要な差異は存在しない。主要な差異は、それらがどのように維持されるかに関して生じる。これらのリストの一方または両方のデータが損失する場合から、標的ユニット100が回復するためのある方法が存在することが望ましい。この損失は、ある壊滅的故障により得る、またはリストの1つ内に含有される情報が、何らかの形で破損した場合により得る(無意識または故意に)。そのような「キーリスト破損」事象の関連事項については、後のセクションで論じられる。永久リストが、使用許諾権限者との接続によって復元可能であることは必要であるが、使用許諾権限者510が、特定の標的デバイスの一時的キーリストを復元可能であることは必要ではない(または、望ましくさえない)。この点に関して、多くの理由が存在するが、主要理由は、一時的キーリストが、永久キーリストより遥かに頻繁にアップデートされる可能性が高いことであって、中央使用許諾権限者510と標的ユニットとの間で必要とされるネットワークトラフィックの量を絶対最小値に維持することが所望される。しかしながら、潜在的に、いくつかの理由から、使用許諾権限者510が、特定の標的の一時的キーリストに書換えを行うことが可能であることが望ましい場合がある(その一部は、後に論じられる)。この場合、標的デバイスの一次秘密キー(使用許諾権限者510に既知である)を使用して、このリストを暗号化することが望ましいであろう。
上述のように、キーリストデータ構造の両方の完全性は、リスト自体とともに格納される、署名されたメッセージダイジェスト(デジタル署名)を使用することによって照合可能である。このメッセージダイジェストを生成するために使用される、セキュアなコードメカニズムの実装については、上述のセクションで説明されており、再び、その手順に言及する必要はない。また、損失および/または破損の場合に、永久キーリストデータ構造610を復元するための手順についても、既に説明されている。解決しなければならない唯一の残っている問題は、一時的キーリストデータ構造の時間依存性部分を、どのように解釈するかということと、一時的キーリストが、何らかの形で使用不可になる場合にどのように対処するかということである。
(一時的使用許諾権譲渡)
これは、タイムスタンプフィールド230の使用が、最も重要である、セキュリティプロトコルのセクションの1つである。上述のように、一時的キーリストデータ構造は、標的デバイスの永久キーリストと正確に同一態様で構築される。しかしながら、2つには、いくつかの差異が存在する。第1の差異は、一時的キーリストが、潜在的に、標的ユニットの秘密キー104のいずれか1つによって暗号化可能なことである。使用許諾権限者510は、通常環境下、このデータ構造を再構築可能である必要はないため、表面上は、どの標的ユニットのキーが、それを暗号化するために使用されるかは関係ない。しかしながら、潜在的に、このリストが、また、標的ユニットの一次秘密キーを使用して暗号化される場合は、使用許諾権限者510に有用となるであろう。これに対する理由は、使用許諾権の取消と関係があり、その環境については、後のセクションで論じられる。
一時的と永久キーリストとの間の第2の(かつ、より重要な)区別は、最も新しい一時的キーリストデータ構造と関連付けられる、タイムスタンプ値230のコピーもまた、標的デバイス100内に格納されることである(すなわち、オンチップ)。このレジスタは、ソフトウェア可読ではなく、セキュリティブロックの一部であるため、セキュアなコードによってのみ上書き可能である。このレジスタ内の値は、一時的キーリストデータ構造が、何らかの形で損失および/またはは損される場合にどうすべきかを決定するために使用される。その手順については、このセクションに後述される。
一時的キーリストと永久キーリストとの間のさらに別の区別は、標的ユニット100が、その永久リストから別のユニット100の一時的リストに、特定のキーの所有権を(一時的に)譲渡可能であるが、いかなる(正確に動作する)デバイスも、その一時的キーリストから任意の他のキーリストに、特定のキーの所有権を譲渡不可能であることである。これはは、当然ながら、他のユニットの一時的キーリストだけではなく、また、標的100の独自の永久キーリストも同様に含む。これは、永久所有者のみ、どのデバイスが、任意の特定のキーを「貸出」可能であるか(かつ、いつ可能であるか)を決定可能であることを意味する。しかしながら、この「貸与」期間は、不定にすることが可能である(かつ、このトランザクションは、使用許諾権限者と接触する必要なく実行可能である)ことに留意されたい。この「永久貸与」特徴は、最新のデジタル著作権管理情報(CCI)システムの一部である、標準的「一世代コピー可(Copy Once)」機能要件に匹敵する。
次に、図7を参照すると、一時的「キー借用」手順を図示する、詳細な工程図が示される。「キー所有権」譲渡手順は、図書館から1冊の書籍を借りる手順に若干類似する。「借り手720」が、永久所有者(「貸し手」710)からの特定のアプリケーション特有のキー550の一時的使用を要求すると、貸し手710は、最初に、アップデートされた一時的キーリストを生成し、それ自体が、キー借用交渉プロセスの期間の間、その特定のキーを使用することを禁止する。この作用は、2つ以上の借り手720ユニットが、同一キーを要求することを禁止する。貸し手ユニット710の一時的キーリスト上の「借用されたキー」の存在は、任意の特定のキーへのアクセスを制御するためのセマフォとして、効果的に使用される。しかしながら、キーが「制限」された状態に置かれる初期の時間は、比較的に短い期間に限定されるべきである。これは、借り手720デバイスが、長期間の間、特定のキーへのアクセスを要求し、次いで、ある理由から、トランザクションを完了できず、特定のキーの使用を不公平に独占する場合を防止することである。また、この比較的に短い借用交渉段階のタイムアウトは、貸し手ユニット710に対する「サービス妨害」攻撃の同等物をマウントしようし得る、悪意のあるデバイスに対抗する際に有用である。実際、貸し手ユニット710は、随意に、その「承認された借り手」リスト上に存在しない、またはそれらのユニットの任意の1つが、ある時間期間内に多過ぎる要求を行おうとする場合、デバイスからの要求を無視可能である。この一時的ブロックがキーに設定される正確な時間長は、重要ではないが、任意の所与の借用手順が完了まで進むことが可能な十分な時間であるべきである。高ネットワークトラフィック量または待ち時間の場合、この期間は、延長され得る。
所与のキーの2つ以上のコピーが、同時に借用可能である場合、貸し手デバイス710の一時的キーリスト内の適切なフィールドは、時間内の任意のある時点において、所与のキーのいくつのコピーが借用されているかを示すために使用可能であることに留意されたい。借り手720および貸し手710が、所与のキーのための特有の借用期間を交渉すると、貸し手710は、キー740の暗号化されたコピーを借り手720に送信する。この暗号化は、貸し手デバイス710にのみ既知である、一時的秘密キー730を使用して行われる。次いで、借り手720が、暗号化されたキーの確実な受信を確認応答すると(暗号化されたメッセージから計算される、メッセージだイジェクトによって)、貸し手710は、借用されたキーの「貸与期間」を延長し、次いで、一時的秘密キー730を借り手デバイス720に送信する。この貸与プロセスの最長期間は、プロトコルの動作にとって重要ではなく、この値の選択において行われなければならない、あるトレードオフが存在する。それらの特定の問題については、このセクションに後述される。上述の実施例では、「借り手720」および「貸し手710」デバイスは、キー対キーベースで、借用期間の実際の長さを交渉可能であることが想定されるが、これは、当然ながら、プロトコルの要件ではない。
借り手720または貸し手710のいずれかの一時的キーリストがアップデートされる直前に、この新しい一時的リストと関連付けられたタイムスタンプ値230のコピーは、不揮発性方式において、標的100上に格納される。その時点で、一時的キーリストデータ構造の暗号化されたバージョンは、メモリに安全に書き出される(あるいは、搭載NVRAM、フラッシュROM等のある他のより多くの永久場所内に保存される、またはさらにあるハードディスク750上のバックアップファイルに書き出される)ことが可能となる。一時的キーリストは、潜在的に、永久キーリストより遥かに頻繁に、読み出され、アップデートされるため、このリストは、標的ユニットに迅速にアクセス可能であることが望ましく、したがって、このリストが、アクセス待ち時間が比較的に短い、少なくとも1つの場所内に格納されることが推奨される(しかしながら、これは、プロトコルの実際の要件ではない)。一方、電源異常によって、潜在的に、途中でユニット100の機能の損失が生じ得るため、このリストが格納される唯一の場所は、ある揮発性記憶媒体(DRAM等)だけではないことが推奨される。この問題については、このセクションで後に詳述される。
特定のキーのための借用期間の時間が満了すると、借り手720および貸し手710デバイスは両方とも、それらのそれぞれの一時的キーリストデータベースを独立してアップデート可能となる。したがって、借り手720が、「貸出のために、特定のキーを返却」するために、貸し手710ユニットと接触することは、要件ではない。これは、借り手720および貸し手710デバイスが、広範囲にわたって分離されている場合、主要な便宜的要因である。当然ながら、この動作のセキュリティは、キータイムスタンプ記録を生成および制御するために使用される、オンチップクロック間の非常に密接な相関に依存し得る。したがって、時間/日付クロックは、セキュリティシステムの一体部分でなければならず、したがって、中央サーバとのトランザクションによって上書き可能であるべきである。また、クロックは、悪質なユーザが、内部タイムスタンプ値230を書き換えようとする場合、改ざんを抑止するために十分にロバストであって、また、通常生じるシステムの電源異常を克服可能なように設計されなければならない。このクロックが、バッテリ駆動であって、バッテリが、除去される、または経時的に停止し得ることは、あり得ないことではないため、システムは、クロックが、潜在的に、使用許諾権限者とのセキュアな交信によって、再開およびリセットされ得るように、設計されるべきである。
このように、特定のアプリケーション特有のキー550の所有権が、あるユニットから別のユニットに、一時的に譲渡可能な環境について説明された。「貸与期間」の終了時、「借り手720」および「貸し手710」ユニットは両方とも、それらの一時的キーリストデータ構造をアップデートし、そのオリジナル所有者へのキーの「返却」を反映可能である。この手順は、両ユニット上で独立して実行可能であって、したがって、2つのデバイス間の任意の交信を必要としないことに留意されたい。
次に、1つ以上のキーが「借用」あるいは「貸与」されている間、一時的キーリストデータ構造の一方もしくは他方が、破損および/または損失される場合に対処しなければならない。「貸し手710」ユニット側では、任意のキーが借用されると、最初に行うことは、「貸与」期間の終了の決定である。この値は、貸与期間の持続時間を現在の時間/日付フィールドの値に追加することによって、明白に構築される。次いで、この時間/日付値は、デバイスの一時的キーリストがアップデートされた最終時間の結果として、チップ上に格納される値と比較される。新しい値が古い値より大きい(より最近である)場合、新しい値は、古い値の代わりに上書きされる。「借り手720」側では、結果として、任意の所与の標的ユニットにおいて、一時的キーリストタイムスタンプが、常に、その特定のユニット100の一時的キーリストの一部として格納される、タイムスタンプのいずれかの最新のものであるように、この同一プロセスが使用される。
ユニット100の一時的キーリストが、損失または別様に不適切に書き換えられる場合、一時的キーリストおよび永久リストの両方とも、この「最新タイムスタンプ」値が満了する時点(事実上、「タイムアウト」期間)まで、無効とされる。次いで、この時点で、ユニットは、永久キーリストの使用に戻ることができ、新しい一時的キーリストを再構築するプロセスを開始可能となる。
したがって、デバイスの一時的リストが、そもそも、改ざんまたは削除される場合、ユニットは、タイムアウト期間が満了するまで、事実上、動作不能である。このタイムアウト手順は、不必要に制限的であるように考えられ得るが、ある悪質な行為の結果として、あるいはあるユニットから別のユニットへのキーの譲渡の際に生じ得る、ある誤作動(停電またはネットワーク接続のダウン等)のため、これまで存在している任意の特定のアプリケーション特有のキーの複数のコピーの潜在的な問題を回避する。また、一時的なキーリストデータ構造の改ざんの結果としてのそのような深刻な影響の潜在性は、すべてではないが、より巧妙な攻撃者を除いた全攻撃者による実践を阻止するのに有用であるはずである。
この点に関して、プロトコルの動作を向上させるために使用され得る、いくつかの任意の付加的特徴が存在する。そのような可能性のある選択肢の1つは、暗号化されたキーリストデータ構造の一方(または、両方)から生成される署名されたメッセージダイジェスト(デジタル署名)を、標的ユニットのオンチップセキュリティセクション内に格納される値に追加することである。デジタル署名の復号化から生じるMAC値は、復号化プロセス全体を経る必要なく、任意の特定のキーリストの有効性を迅速に検証するために使用され得る。しかしながら、複数のネスト化されたキーリストの問題は、この復号化手順が、非暗号化キーを最終的に生成するために、ある時点で複数回行われなければならない可能性が高いことを意味し、したがって、これらのデジタル署名がオンチップとして格納されることは、プロトコルの動作に重要ではない。
向上のための別の可能性は、1つのみではなく、一対のオンチップタイムスタンプ値を格納することである。付加的タイムスタンプは、一時的キーリストがアップデートされなければならない最短(次の)時間を示すために使用され得る。これは、リスト全体を定期的にチェックする(復号化プロセスを踏むことを伴う)必要がないため、標的デバイス100が、その一時的キーリストを改訂する必要がある時を決定することをより容易にするであろう。この特徴は、非常に有用となるであろうが、同様に、ユニットが、このプロトコルを実行可能となるための基礎的要件ではない。しかしながら、この第2のタイムスタンプを含有するシステムが実装される場合、2つのタイムスタンプが、ある理由から「非同期」となる場合には、混乱の潜在性をもたらす。思い浮かぶ、そのような実施例の1つは、そのようなタイムスタンプの1つが書き出された直後、第2がアップデートされる前の時点で、電力以上が生じる場合である。
解決されるべき最後の問題は、どのような最小限界および最大限界がこれらの一時的キーリストタイムスタンプの値に対するものであるかということである。一方では、最長の「一時的貸与期間」に対する限度が大きいほど、ユーザは、合理的に長期間の間、あるユニットから別のユニットに特定のデータアプリケーション(または、メディアストリーム)の使用を譲渡可能となり得る。これは、潜在的に、ユーザがその「ホームユニット」からポータブルユニットに、メディアストリームの所有権を譲渡することを所望する場合に有用となるであろう長期「借用期間」を有することによって、ユーザは、オリジナル「貸し手」ユニット710と接触することを必要とせずに、長期間の旅行の際に、ポータブルユニットを(その関連付けられた一時的キーとともに)携行可能となるであろう。長い「借用」期間のマイナス面は、オリジナルユニット上の一時的キーリストデータ構造に何らかが生じる場合、ユニットは、潜在的に、長時間、無効となることである。
また、この最後の問題は、悪質なコードが、オンチップタイムスタンプレジスタの値をある中間値に設定可能である場合の標的ユニット100に対する潜在的危険性を指摘する。これは、潜在的に、攻撃の標的を無効にすることに等しく、したがって、このタイムスタンプレジスタの値は、「セキュアな」コードブロックによってのみ書き込み可能であるべきである。同様に、各ユニットは、個別の秘密キー集合を有するため、1つの特定のユニットの秘密キー104データの発見は、任意の他のユニットに対する懸念を生じさせるはずはないが、但し、悪意のあるデバイスが、事実上、合法ユニットになりすますことが可能である場合を除く。攻撃のモードは、身元照合関連問題に対処する、後のセクションで論じられる。
(永久使用許諾権譲渡)
この手順の要素の多くは、本書の上述のセクションにおいて論じられた。特有のキーが、あるユニットから別のユニットに永久に譲渡される基本的プロセスは、図5において上述された。多くの方法では、この手順は、直前のセクションに説明されるように、キー所有権の一時的譲渡に本質的に類似する。
2つの手順の間の主要な差異は、永久譲渡が、一時的譲渡より単純なプロセスであって、永久キー所有権譲渡手順が、使用許諾権限者510と標的ユニット100との間の交信を利用すべきことである。永久譲渡プロセスが、より単純である理由は、一時的キーの借用手順の前提条件である、借用時間期間交渉を必要としないという事実に依るものである。永久譲渡機能が、使用許諾権限者510と標的ユニット100との間の交信を利用する理由は、アップデートされたキーリストデータ構造が、トランザクションの両終点において、再構築可能でなければならないという事実のためである。
永久使用許諾権譲渡は、通常、使用許諾権限者510との交信によって生じるため、どのアプリケーションまたはメディアストリーム特有のキーが、どの標的ユニットに属するかの記録が存在する。上述のように、これは、標的ユニット100のキーリストが、ある壊滅的データ損失環境後に復元されなければならない場合、または特定の標的ユニット100の所有権が、異なるエンティティに譲渡される場合、必要である。また、使用許諾権限者510側のこの介入は、特有のキーの永久所有権が、ある標的ユニット100から別のユニットに譲渡される場合にも必要である。別のエンティティから元々購入された資産を再販する、所有者のこの能力は、「一次販売権」として知られ、この特定の機能をサポートするために、本明細書に説明されるプロトコルにとって重要な能力である。
標的ユニット100の永久キーリストが、使用許諾権限者510によって維持されるという事実の別の重要な側面は、ユニット100が、何らかの形で危殆化されていることが証明される場合、またはキーの1つが、危殆化されていると識別される場合、個々の標的ユニット100の使用許諾権キーの一部あるいは全部を取り消す能力をこのメカニズムが有することである。キーの一意的リストを各すべての標的ユニット100に与える潜在性が存在するため(上述のように)、また、使用許諾権限者510が、任意の危殆化キーの源を追跡する機会を提供し得る。そのような環境では、このプロトコルは、通常、「透かし」特徴の機能と関連付けられる、機能を充足し得るが、従来の透かしプロセスの欠点(メディアストリームの品質に悪影響を及ぼす、透かしの潜在性等)を伴わない。
該当しないと考えられ得るが、アプリケーションコードまたはメディアストリーム特有のID情報は、アプリケーション開発者520に由来し、使用許諾権限者510は、必ずしも、任意の特定のアプリケーションまたはメディアストリームとその使用許諾権のある所有者との間の関連付けを成すことが可能な十分な情報を有しているわけではないため、デジタルコンテンツ所有者のプライバシーは、依然として、このプロセスによって維持される。また、ユーザのプライバシーを保護するこの能力は、このプロトコルの重要な側面である。
永久キー譲渡プロセスに関して留意されるべき最後の問題は、実際は、一時的キー使用許諾権譲渡によって、永久キー譲渡が行う同一機能すべてを達成可能であることである。しかしながら、標的ユニットのセキュリティシステムの維持は、理想的には、中央のセキュアなサーバによって制御されるべき機能であって、したがって、連鎖内のいずれかの場所の定位置にそのようなメカニズムを有することが必要である。また、ユーザが、それらのプライバシーの維持に関して懸念する場合、中央サーバが、著作権保有者と標的ユニット100との間のバッファとして作用可能であるという事実は、非常に有用である。最後にまた、使用許諾権限者510が、一時的キー譲渡メカニズムに加えて、この機能を設定する、特定の標的ユニット100の永久キーリストのための中央バックアップ記憶メカニズムとして作用可能であることも魅力である。
(システム所有権譲渡、使用許諾権の取消、およびセキュリティシステムアップデート)
標的ユニット100の使用許諾権(または、キー)の1つ以上が取り消され得る、いくつかの異なる手段が存在する。最も簡単な方法は、単に、標的100の一次秘密キーをアップデートすることである。次いで、この時点で、標的100は、その永久キーリストへのアクセスが不可能となり、したがって、新しいリストを作成するプロセスを開始しなければならないであろう。一次秘密キーが、一時的キーリストデータ構造のための暗号化プロセスで使用されない場合、この一時的キーリストは、潜在的に、依然として、アクセス可能であるが、永久キーリストは、別様にはアクセス不可能であり得ることに留意されたい。
このポイントは、一時的キーリストのための暗号化プロセスの説明において記載された。この理由から、標的ユニット100の一次秘密キーを永久および一時的キーリストデータ構造の両方のための暗号化キーとして使用することは、可能性として、最良の考えである。
標的ユニット100の所有権が、ある個人から別の個人に変更する場合、この所有権変更を発効させる最も単純な態様は、ユニット100の一次秘密キーをある新しい値に設定することである。しかしながら、オリジナル所有者が、標的からそれらの永久キーすべてを復元する機会を有する前に、これが生じる場合、それらの使用許諾権を失うであろう。オリジナル所有者が、関連付けられた永久キーリストの所有権とともに、標的ユニットの譲渡を所望する場合、その特定のデバイスと関連付けられた所有権情報(使用許諾権限者510において格納される)の変更以外、標的ユニット100に何も行う必要はない。
使用許諾権の取消が生じ得る別の態様は、特定の標的ユニット100の永久キーリストのためのマスタキーが「満了」する場合である。ユニット100のセキュリティシステムへのアップデートは、永久キーリストの一部として格納されるため、この環境は、潜在的に、壊滅的な影響を有し得る。
潜在的に、この窮地から回復することは可能であろうが、標的100に、完全に新しい「信頼の連鎖」を初めから作り直す必要があることを要求することになる。この環境では、新しく初期化されたセキュリティシステムのコアは、標的100の一部上で、アトミックに起動可能であると検証され得る、動作にのみ基づく必要があるであろう。したがって、これは、その他の点では汎用であるコード(潜在的に、疑わしい可能性がある)の最小量であっても必要とする、任意のハッシュ関数の使用を妨げるであろう。幸いにも、この環境は、失効しない永久キーリストデータ構造の一部として、検証可能なセキュアなコードフラグメントの永久コアを常に維持するという単純な事によって回避可能である。しかしながら、これは、上述の理由から、それ自体、セキュリティの危険性であって、したがって、この永久コードコアのコンテンツは、可能な限り限定されるべきである。
使用許諾権の取消のさらに別の態様は、使用許諾権限者510が、標的ユニット100の永久または一時的キーリスト内の特定のキーの入力を上書きすることを選択する場合に生じ得る。これは、セキュリティシステムアップグレードが必要とされる場合、あるいは特定の標的ユニット100が、特定のアプリケーションまたはメディアストリームの使用許諾権のないコピーを有すると識別される場合に使用され得る。標的ユニット100は、通常、その独自のキーリストデータ構造を維持するため、この手順は、使用許諾権限者510と標的ユニットとの間のネットワークトラフィックが通常より大きくなることを伴うであろう。したがって、この一連の作用は、極端な場合に確保されるべきである。
しかしながら、そのような手順は、当該標的デバイス100に、疑問視されるキーを検索し、無効にする、および/または、次いで、より古いソフトウェアをアップデートされたバージョンと置換するように設計される、標的特有のカスタムバージョンによって、そのセキュリティシステムソフトウェアを改訂させることによって達成可能である。当然ながら、この手順は、標的デバイス100が、使用許諾権限者の中央サーバとの接続を開始する時点においてのみ、作動可能である。通常環境下では、任意の特定の標的ユニット100が、任意の特定のスケジュールにおいて、使用許諾権限者510と接触を開始することは保証不可能である。幸いにも、標的デバイス100は、その永久キーリストへの任意の新しい追加を承認するために、使用許諾権限者510(直接または間接的に)と接続しなければならず、したがって、任意のキー取消作用は、新しいキー使用許諾手順の一部として達成可能である。また、上述の「セキュリティシステムタイムアウト」メカニズムは、この「リスト監視」作用をサポートするために使用され得ることも可能性として考えられる。しかしながら、これに該当することは、このプロトコルの要件ではなく、そのようなシステムは、ユーザのプライバシー権の侵害をもたらす可能性が高い。
(他の懸念:)
必ずしも、プロトコル自体の一部ではないが、それでもなお、本明細書に説明されるプロトコルを適切に実行可能な実践的システムを作製するプロセスにおいて解決されなければならない、いくつかの問題が存在する。これらの問題の一部は、実際のプロセッサデバイス実装に依存し、その他は、大部分が、アプリケーション特有のものである。この情報は、好適な標的デバイス100の適切な構築に密接な関係があるため、これらの問題の一部については、以下のセクションで論じられる。
(相互運用可能なユニットの数の制限)
著作権保有者が、主要標的が所有権を一時的に譲渡可能なデバイスの総数を限定することを所望する場合、これは、任意のある時間にアクティブとなり得る、限定数の公開/個人キー対を確立することによって達成されてもよい。これは、上述のセクションで説明された、同一アプリケーション特有のキーの複数のコピーが、同時に「貸与」される場合と異なることに留意されたい。特定の標的デバイス100からアプリケーション特有のキーのいずれかを「借用」可能なデバイスのリストが、ある通し番号集合に限定可能であるという、他のシナリオも可能である。使用許諾権限者510は、標的ユニット100のセキュリティシステムが管理されるのと正確に同一態様において、そのような「承認された借り手」リストを運営可能である。したがって、使用許諾権限者510は、例えば、「承認された借り手」リスト上の通し番号集合を、オリジナル標的デバイス100と同一所有権情報を有する者に限定可能である。この問題に対する別の可能性のある解決策は、中央使用許諾権限者510の公開キーによって証明書を復号化することによってのみ照合可能である、資格証明書(署名された証明書等)を貸し手に提示することによって、任意の「借り手」デバイス720が「権限のある」借り手として照合されることを要求することである。また、このシナリオは、当然ながら、使用許諾権限者510が、特定のユニットが危殆化されていると決定される場合、そのような証明書を取り消す能力も伴うであろう。この証明書取消プロセスが達成され得る、周知の方法の1つとして、定期的に公開される「取消リスト」を介して達成可能である。
(秘密キー発見および身元照合問)
特定のプレーヤのための一次秘密キーが、物理的分解およびチップダイ検証によって発見される場合、各デバイスは、個別の秘密キー104集合を有するため、これは、任意の他のデバイスのセキュリティを危殆化することにはならないはずである。しかしながら、特定のプレーヤのための一次キーが、何らかの形で危殆化される場合、潜在的に、使用許諾がないデバイスは、合法標的ユニットになりすますことが可能である。この問題が検出されない場合、この知識を備えた使用許諾がないデバイスは、その特定の標的ユニットに発行されたアプリケーション特有の復号化キーのいずれかを危殆化させ得る可能性が存在する。最初に、標的ユニット100の通し番号106は、使用許諾権限者510が、復号化キーをデバイスに発行するために、登録される必要があるため、この目的に関する問題は、表面上は、使用許諾がないデバイスによる、その他の点では合法である標的ユニット100の模倣に限定されるであろう。
しかしながら、ユニット100の秘密キーの両方が、そのようなプロセスによって発見される場合、以前にバックアップされた暗号化されたキーリストダイジェストのコピーの検証に基づいて、そのユニットに使用許諾が付与されたアプリケーション特有のキーすべてのセキュリティを危殆化させる可能性がある。この理由から、一次および二次秘密キーの両方とも、これらのキーの値を発見しようとするいかなる試みも、キーデータの損失をもたらすような「改ざん防止」態様において、標的チップ上に実装されるべきである。
この改ざん防止特徴が標的デバイス100上に実装され得るいくつかの手段が存在するが、その正確な実装は、本書に説明されるプロトコルに重要ではない。「秘密キー損失」環境が、ユーザ側のある悪意のない過失行為(または、不正使用)を通して生じる場合、合法ユーザは、それらの損傷ユニットを、損傷ユニットのアプリケーション特有のキーを新しいデバイスに譲渡させように手配可能な使用許諾権限者510に返却可能であるべきである。しかしながら、オリジナル標的デバイス100が、機能しない場合、新しい標的デバイス100へのキーの譲渡は、アプリケーション開発者520とのトランザクションを伴わなければならない(少なくとも、そもそも、暗号化されていない状態で使用許諾権限者510に供給されていないキーのために)ことに留意されたい。
しかしながら、その他の点では本物である標的ユニット100になりすますことが可能なデバイスは、表面上、疑いのない合法的に使用許諾のあるデバイスに、そのアプリケーション特有のキーの1つ以上の所有権を一時的に断念させる、または動作を一時停止させることが可能であり得ることに留意されたい(上述のように)。後者が生じる場合、そこからキーを借用しようとするユニットすべてを無効にし得る、「不正ユニット」を有する可能性が存在する。前者が生じる場合、任意の数のアプリケーションまたはメディア特有のキーは、潜在的に、危殆化され得る。
したがって、特定の標的ユニット100に対する潜在的「使用許諾のある借り手」の数を、使用許諾権限者510サーバからのセキュアなアップデートによってのみ、合法ユニットに供給可能であったリストに限定する上述の概念は、賢明である。前者の場合、これは、その他の点では疑いのないユニットの所有者が、そのユニットが、そもそも、実際に彼らに属していない限り、機能ユニットを分解し、その秘密キーへのアクセスを得るハッカーによってそれらの合法デバイスを無効にされることを防止するであろう。後者の場合、これは、アプリケーションまたはメディア特有のキーの譲渡を、ある時点において、使用許諾権限者によって、適切に登録された使用許諾のあるデバイスにのみに限定するであろう。しかしながら、執拗なハッカーは、依然として、合法ユニットを購入し、それをこじ開け、何らかの形で、その秘密キーデータへのアクセスを得、次いで、この情報を使用して、合法デバイスになりすまし得る。
したがって、どのようにこの種類のなりすまし事象を検出しようとするかという問題が残存する。非常に資金力のあるこの性質の敵を打ち負かすたまの唯一の成功する戦略は、潜在的入手が、少なくとも、費用トレードオフの観点から、必要とされる努力に値しないように、システムを設計することである。
通信中である、その他の点では未知のデバイスの真正性を証明しようとする、いくつかの手段が存在する。しかしながら、あるデバイスが、実際に、要求されるものであることを証明するための最も成功する方法は、このデバイスを他のデバイスから一意的にする特徴に焦点を当てることである。本書によって説明されるデジタル復号化メカニズム等の特殊用途装置の場合、セキュリティプロトコルを適切に実行し、所与の入力変数集合に基づいて、正確な結果を計算するデバイスの能力であろう。しかしながら、本明細書に説明されるセキュリティプロトコルは、公知のアルゴリズムに基づくため、これは、表面上は、動作を完了するために十分な時間を有することを前提として、任意の汎用コンピューティングデバイスによって達成され得る。実際、デバイスを一意的にする秘密キー情報が、何らかの形で危殆化される場合、この問題は、公的に利用可能な技術に基づく、任意のデバイスにとって、潜在的問題となるであろう。したがって、最終的には、合法標的デバイスのすべてに対して、オンチップとして格納される秘密キー情報が、分解およびチップダイ検査に直面する場合でも、秘密のままでなければならないという指針に依存する必要がある。
当然ながら、一定時間内に、検証可能なMAC値を正確に見出す能力等、標的識別および照合プロセスに要件を追加可能である。最終MAC値が複数回暗号化されることを要求することによって、手順をさらに困難にすることも可能である。したがって、潜在的に、通常、単に、使用許諾権自体の合法コピーを購入する費用より遥かに高価である、(より汎用性の)動作上のリソースへのアクセスを有することが必要とされるという点において、合法デバイスを模倣する攻撃者の能力を制限し得る。また、メディアストリームプレーヤの場合、プレーヤが、表面上、対応するように設計される、メディアストリームの1つ以上の一部を正確にデコードする能力を含み得る。
しかしながら、いずれの場合も、デジタル著作権保護のプロセス全体は、チューリング(Turing)問題である。したがって、十分な時間およびリソースを前提として、任意のデジタル著作権保護方式は、執拗な敵に敗れる可能性がある。これは、当然ながら、秘密キー情報へのアクセスが、可能性のある攻撃者にとって、確実に大きな利点となるであろうという事実とは無関係でさえある。したがって、ユニットの秘密キーが危殆化されることを防止する能力は、このセキュリティプロトコルの重要な部分である。
(結論:)
上述の著作権保護プロトコルは、いくつかの点において、一意的である。第1は、ユーザが、それらの法的に購入されたアプリケーションまたはメディア特有のキーデータのバックアップコピーを作成する能力を禁止しようとしないという事実である。2つ目は、このプロトコルが、任意の種類のデジタルデータを区別せず、したがって、セキュリティプロトコルを保護するように設計されるデータストリームとして、容易にアップデート可能であることである。3つ目は、このプロトコルによって、ユーザは、それらのアプリケーションまたはメディア特有のキーの所有権を、プロトコルを実行可能な別のユニットに一時的に譲渡可能となることである。また、このプロトコルは、被許諾者に、ある標的ユニット100から別のユニットに所有権の永久譲渡を発効させるための能力を提供する。この最後の特性によって、このプロトコル下の消費者の法的「一次販売権」の実装が可能となる。
実際、本書に説明されるプロトコルと、他のコピー保護方式との間の基礎的差異の1つは、本システムのセキュリティが、特定のデータ集合にアクセスする能力を制御することではなく、むしろ、そのデータ集合内に含有されるアイディアを表現する作用を制御する能力に依存することである。
上述の明細書において、本発明が、特有の実施形態を参照して説明された。しかしながら、当業者は、以下の請求項に記載される本発明の範囲から逸脱することなく、種々の修正および変更を行うことが可能であることを理解されたい。故に、明細書および図は、限定的意味ではなく、例示としてみなされるべきであって、そのような修正はすべて、発明の範囲内に含まれるものと意図される。
効果、他の利点、および問題の解決策について、特有の実施形態に関して、上述された。しかしながら、効果、利点、問題の解決策、および任意の利益、利点、または解決策を生じさせる、あるいはそれらがより顕著となり得る、任意の構成要素は、請求項の一部または全部の必須、必要、あるいは不可欠な特徴もしくは構成要素と解釈されるべきではない。
Figure 2015035224
Figure 2015035224
Figure 2015035224
Figure 2015035224
Figure 2015035224
Figure 2015035224
Figure 2015035224

Claims (1)

  1. 本明細書に記載の発明。
JP2014213476A 2008-11-10 2014-10-20 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム Pending JP2015035224A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11311108P 2008-11-10 2008-11-10
US61/113,111 2008-11-10

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2011535761A Division JP5636371B2 (ja) 2008-11-10 2009-11-10 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム

Publications (1)

Publication Number Publication Date
JP2015035224A true JP2015035224A (ja) 2015-02-19

Family

ID=42153308

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2011535761A Expired - Fee Related JP5636371B2 (ja) 2008-11-10 2009-11-10 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム
JP2014213476A Pending JP2015035224A (ja) 2008-11-10 2014-10-20 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2011535761A Expired - Fee Related JP5636371B2 (ja) 2008-11-10 2009-11-10 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム

Country Status (4)

Country Link
EP (1) EP2340631A1 (ja)
JP (2) JP5636371B2 (ja)
KR (1) KR20110106849A (ja)
WO (1) WO2010054369A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7352182B2 (ja) 2020-02-14 2023-09-28 コニカミノルタ株式会社 画像形成装置、画像処理システム、およびプログラム

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5411282B2 (ja) * 2009-09-17 2014-02-12 パナソニック株式会社 情報処理装置、管理装置、不正モジュール検知システム、不正モジュール検知方法、不正モジュール検知プログラムを記録している記録媒体、管理方法、管理プログラムを記録している記録媒体および集積回路
US8468365B2 (en) * 2010-09-24 2013-06-18 Intel Corporation Tweakable encryption mode for memory encryption with protection against replay attacks
US8930676B2 (en) * 2010-12-22 2015-01-06 Via Technologies, Inc. Master core discovering enabled cores in microprocessor comprising plural multi-core dies
KR101577886B1 (ko) * 2011-06-29 2015-12-15 인텔 코포레이션 무결성 검사 및 리플레이 공격들에 대한 보호를 이용하는 메모리 암호화를 위한 방법 및 장치
KR101380895B1 (ko) 2012-06-12 2014-04-10 한국전자통신연구원 보안 서비스 제공 장치 및 이를 이용한 보안 서비스 방법
US8984331B2 (en) * 2012-09-06 2015-03-17 Triumfant, Inc. Systems and methods for automated memory and thread execution anomaly detection in a computer network
US9753863B2 (en) * 2014-12-27 2017-09-05 Intel Corporation Memory protection with non-readable pages
US10020934B2 (en) * 2015-11-05 2018-07-10 Intel Corporation Hardware accelerator for cryptographic hash operations
WO2017083311A1 (en) * 2015-11-09 2017-05-18 Secure Content Storage Association, Llc Timed release of decryption keys for access to distributed encrypted content
US11213773B2 (en) 2017-03-06 2022-01-04 Cummins Filtration Ip, Inc. Genuine filter recognition with filter monitoring system
US10555210B2 (en) * 2017-03-15 2020-02-04 Qualcomm Incorporated Group indicator for code block group based retransmission in wireless communication
US10805163B2 (en) * 2018-08-21 2020-10-13 Hewlett Packard Enterprise Development Lp Identifying device types based on behavior attributes
DE102019128528A1 (de) 2019-10-22 2021-04-22 Infineon Technologies Ag Datenkryptografievorrichtungen und speichersysteme
US11431510B1 (en) * 2020-04-30 2022-08-30 Wells Fargo Bank, N.A. Code-sign white listing (CSWL)
CN115955309B (zh) * 2023-03-13 2023-06-02 浙江华创视讯科技有限公司 一种加密推理方法及其系统、设备、存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5875267A (ja) * 1981-10-09 1983-05-06 ブル・エス・アー 署名入りメツセ−ジの署名を認証するための方法および装置
JP2000155735A (ja) * 1998-11-20 2000-06-06 Mitsubishi Electric Corp ディジタルコンテンツ配布システム装置
JP2001160003A (ja) * 1999-09-17 2001-06-12 Internatl Business Mach Corp <Ibm> 電子配布システム内で顧客購入を一意に識別するための方法および装置
JP2002372910A (ja) * 2001-06-18 2002-12-26 Victor Co Of Japan Ltd コンテンツ情報の認証再生方法、及びコンテンツ情報認証再生装置
JP2005346182A (ja) * 2004-05-31 2005-12-15 Fujitsu Ltd 情報処理装置、耐タンパ方法、耐タンパプログラム
US20080240420A1 (en) * 2002-06-20 2008-10-02 Oxford William V Method and system for a recursive security protocol for digital copyright control
JP2009181238A (ja) * 2008-01-29 2009-08-13 Fujitsu Ltd ファイルアクセス方法およびファイルシステム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
MXPA04002721A (es) * 2001-09-27 2004-07-05 Matsushita Electric Ind Co Ltd Un dispositivo de cifrado, un dispositivo de descifrado, un dispositivo de generacion de claves secretas, un sistema de proteccion de derechos de autor y un dispositivo de comunicacion cifrada.
US7480385B2 (en) * 2004-11-05 2009-01-20 Cable Television Laboratories, Inc. Hierarchical encryption key system for securing digital media

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5875267A (ja) * 1981-10-09 1983-05-06 ブル・エス・アー 署名入りメツセ−ジの署名を認証するための方法および装置
JP2000155735A (ja) * 1998-11-20 2000-06-06 Mitsubishi Electric Corp ディジタルコンテンツ配布システム装置
JP2001160003A (ja) * 1999-09-17 2001-06-12 Internatl Business Mach Corp <Ibm> 電子配布システム内で顧客購入を一意に識別するための方法および装置
JP2002372910A (ja) * 2001-06-18 2002-12-26 Victor Co Of Japan Ltd コンテンツ情報の認証再生方法、及びコンテンツ情報認証再生装置
US20080240420A1 (en) * 2002-06-20 2008-10-02 Oxford William V Method and system for a recursive security protocol for digital copyright control
JP2005346182A (ja) * 2004-05-31 2005-12-15 Fujitsu Ltd 情報処理装置、耐タンパ方法、耐タンパプログラム
JP2009181238A (ja) * 2008-01-29 2009-08-13 Fujitsu Ltd ファイルアクセス方法およびファイルシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7352182B2 (ja) 2020-02-14 2023-09-28 コニカミノルタ株式会社 画像形成装置、画像処理システム、およびプログラム

Also Published As

Publication number Publication date
JP2012508529A (ja) 2012-04-05
KR20110106849A (ko) 2011-09-29
JP5636371B2 (ja) 2014-12-03
EP2340631A1 (en) 2011-07-06
WO2010054369A1 (en) 2010-05-14

Similar Documents

Publication Publication Date Title
JP5636371B2 (ja) 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム
US7203844B1 (en) Method and system for a recursive security protocol for digital copyright control
JP2015511050A (ja) プロセス作業セット隔離のための方法およびシステム
US9705677B2 (en) Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol
JP4702957B2 (ja) 耐タンパ・トラステッド仮想マシン
US6330670B1 (en) Digital rights management operating system
US8418259B2 (en) TPM-based license activation and validation
US20050060568A1 (en) Controlling access to data
US20060021064A1 (en) Key-based secure storage
US20060064756A1 (en) Digital rights management system based on hardware identification
WO2004006075A1 (ja) 開放型汎用耐攻撃cpu及びその応用システム
US8656190B2 (en) One time settable tamper resistant software repository
JP2010520703A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
JP2015135703A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
JP2013084294A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
KR20080008328A (ko) 보호 컴퓨팅 환경의 갱신 가능하고 개별화 가능한 요소
JP2014017871A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141128

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151211

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160119

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20160809