Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://patents.google.com/patent/KR20110106849A/en below:

KR20110106849A - Method and system for controlling code execution on a computing device using recursive security protocol

본 발명 및 그 각종 특징과 유리한 세부는 첨부 도면에 도시되고 이하의 설명에서 상세화되는 비제한적인 실시예를 참조하여 더욱 완전하게 설명된다. 잘 알려져 있는 시작 물질, 처리 기술, 컴포넌트 및 설비에 관한 설명은 본 발명의 세부를 불필요하게 불명료하게 하는 것을 방지하기 위해 생략한다. 그러나, 본 발명의 양호한 실시예를 표시하는 것이지만, 그 실시예에 대한 상세한 설명 및 특수한 예는 제한하는 의도가 없이 단지 예시하는 용도로만 주어진다는 것을 이해하여야 한다. 근원적인 발명 개념의 정신 및/또는 범위 내에서의 각종 치환, 수정, 추가 및/또는 재구성이 이 기술에 숙련된 사람에게는 이 명세서의 설명으로부터 명백할 것이다. 여기에서 설명하는 실시예들은 컴퓨터 판독가능 매체(예를 들면, HD)에 존재할 수 있는 적당한 컴퓨터 실행가능 명령어로, 하드웨어 회로 등으로, 또는 이들의 임의의 조합으로 구현될 수 있다.The invention and its various features and advantageous details are explained more fully with reference to the non-limiting embodiments shown in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted to avoid unnecessarily obscuring the details of the present invention. However, while indicating a preferred embodiment of the present invention, it is to be understood that the detailed description and specific examples thereof are given for purposes of illustration only and are not intended to be limiting. Various substitutions, modifications, additions, and / or reconfigurations within the spirit and / or scope of the underlying inventive concept will be apparent to those skilled in the art from the description herein. The embodiments described herein may be implemented in suitable computer executable instructions that may be present in a computer readable medium (eg, HD), in hardware circuitry, or in any combination thereof.

특정 실시예를 설명하기 전에, 특정 실시예를 구현하기 위한 하드웨어 아키텍쳐의 실시예를 여기에서 설명한다. 일 실시예는 네트워크에 통신적으로 결합된 하나 이상의 컴퓨터를 포함할 수 있다. 이 기술에 숙련된 사람이라면 알고 있는 바와 같이, 컴퓨터는 중앙 처리 장치("CPU"), 적어도 하나의 읽기 전용 메모리("ROM"), 적어도 하나의 랜덤 액세스 메모리("RAM"), 적어도 하나의 하드 드라이브("HD") 및 하나 이상의 입력/출력("I/O") 장치를 포함할 수 있다. I/O 장치는 키보드, 모니터, 프린터, 전자식 포인팅 장치(마우스, 트랙볼, 스타일리스트 등) 등을 포함할 수 있다. 각종 실시예에 있어서, 컴퓨터는 네트워크를 통해 적어도 하나의 데이터베이스에 액세스한다.Before describing a particular embodiment, an embodiment of a hardware architecture for implementing a particular embodiment is described herein. One embodiment may include one or more computers communicatively coupled to a network. As will be appreciated by those skilled in the art, a computer may include a central processing unit ("CPU"), at least one read-only memory ("ROM"), at least one random access memory ("RAM"), at least one It may include a hard drive ("HD") and one or more input / output ("I / O") devices. I / O devices may include keyboards, monitors, printers, electronic pointing devices (mouse, trackball, stylist, etc.) and the like. In various embodiments, the computer accesses at least one database over a network.

ROM, RAM 및 HD는 CPU에 의해 (예를 들면, 컴파일, 번역 등에 의해 직접 실행되거나 실행가능으로 되는 다른 것에서) 실행가능한 컴퓨터 명령어를 저장하기 위한 컴퓨터 메모리이다. 이 명세서에서, 용어 "컴퓨터 판독가능 매체"는 ROM, RAM 및 HD로 제한되는 것이 아니고, 프로세서에 의해 판독가능한 임의 유형의 데이터 기억 매체를 포함할 수 있다. 일부 실시예에서, 컴퓨터 판독가능 매체는 데이터 카트리지, 데이터 백업용 자기 테이프, 플로피 디스켓, 플래시 메모리 드라이브, 광학 데이터 기억장치 드라이브, CD-ROM, ROM, RAM, HD 등을 인용할 수 있다.ROM, RAM, and HD are computer memory for storing computer instructions executable by the CPU (eg, in something else that is directly executable or executable by compilation, translation, and the like). In this specification, the term “computer readable medium” is not limited to ROM, RAM, and HD, and may include any type of data storage medium readable by a processor. In some embodiments, computer readable media may refer to data cartridges, magnetic tape for data backup, floppy diskettes, flash memory drives, optical data storage drives, CD-ROMs, ROMs, RAMs, HDs, and the like.

여기에서 설명하는 기능 또는 처리의 적어도 일부는 적당한 컴퓨터 실행가능 명령어로 구현될 수 있다. 컴퓨터 실행가능 명령어는 하나 이상의 컴퓨터 판독가능 매체(비휘발성 메모리, 휘발성 메모리, DASD 어레이, 자기 테이프, 플로피 디스켓, 하드 드라이브, 광학 기억 장치 등, 또는 임의의 다른 적당한 컴퓨터 판독가능 매체 또는 기억 장치 등)에 소프트웨어 코드 성분 또는 모듈로서 저장될 수 있다. 일 실시예에 있어서, 컴퓨터 실행가능 명령어는 컴파일드 C++의 행(lines), 자바, HTML, 또는 임의의 다른 프로그래밍 또는 스크립팅 코드를 포함할 수 있다.At least some of the functions or processes described herein may be implemented with appropriate computer executable instructions. The computer executable instructions may include one or more computer readable media (such as nonvolatile memory, volatile memory, DASD array, magnetic tape, floppy diskette, hard drive, optical storage device, or any other suitable computer readable medium or storage device, etc.). Can be stored as software code components or modules. In one embodiment, the computer executable instructions may include lines of compiled C ++, Java, HTML, or any other programming or scripting code.

게다가, 개시된 실시예의 기능들은 하나의 컴퓨터에서 구현되거나, 네트워크 내의 또는 네트워크에 걸친 2개 이상의 컴퓨터 사이에서 공유/분산될 수 있다. 실시예를 구현하는 컴퓨터들 간의 통신은 임의의 전자 신호, 광학 신호, 고주파수 신호를 이용하여, 또는 공지의 네트워크 프로토콜과 호환하는 다른 적당한 방법 및 통신 도구를 이용하여 달성될 수 있다.In addition, the functions of the disclosed embodiments may be implemented in one computer or shared / distributed between two or more computers in or across a network. Communication between the computers implementing the embodiments may be accomplished using any electronic signal, optical signal, high frequency signal, or other suitable methods and communication tools compatible with known network protocols.

여기에서 사용되는 용어 "포함한다", "포함하는", "구비한다", "구비하는", "갖는다", "갖는" 또는 이들의 임의의 다른 변형 용어는 비배타적 내포를 포괄하는 것으로 의도된다. 예를 들면, 요소들의 리스트를 포함하는 프로세스, 처리, 물품 또는 장치는 단지 그 요소로만 제한될 필요가 없고, 명시적으로 리스트되지 않은 다른 요소 또는 그러한 프로세스, 처리, 물품 또는 장치에 고유한 다른 요소들을 포함할 수 있다. 또한, 명시적으로 다르게 설명되지 않는 한, "또는"은 총괄적 또는(inclusive or)을 인용하는 것이고 배타적 또는(exclusive or)을 의미하는 것이 아니다. 예를 들면, 조건 A 또는 B는 하기의 것 중 임의의 하나에 의해 만족된다; A는 참(또는 존재)이고 B는 거짓(또는 부재)이다; A는 거짓(또는 부재)이고 B는 참(또는 존재)이다; 및 A와 B가 둘 다 참(또는 존재)이다.As used herein, the terms “comprises”, “comprising”, “comprises”, “comprises”, “haves”, “haves”, or any other variations thereof are intended to encompass non-exclusive inclusions. . For example, a process, process, article, or apparatus that includes a list of elements need not be limited to only that element, but other elements not explicitly listed or other elements specific to such process, process, article, or apparatus. Can include them. Also, unless expressly stated otherwise, “or” refers to an inclusive or does not mean an exclusive or. For example, condition A or B is satisfied by any one of the following; A is true (or present) and B is false (or absent); A is false (or absent) and B is true (or present); And A and B are both true (or present).

추가적으로, 여기에서 주어진 임의의 예 또는 설명은 어떻게든 이들이 사용하는 임의의 용어 또는 용어들로 구속되는 것으로서, 제한되는 것으로서, 또는 용어들의 정의를 표현하는 것으로서 간주되지 않는다. 그 대신에, 이들 예 및 설명은 하나의 특수한 실시예와 관련하여 설명하고 단지 예시하는 것으로서 간주되어야 한다. 이 기술에 숙련된 사람이라면, 이들 예 및 설명에서 사용하는 임의의 용어 또는 용어들이 이 명세서의 어딘가에서 제시하거나 제시하지 않을 수 있는 다른 실시예에도 적용된다는 것을 알 것이며, 그러한 모든 실시예는 그 용어 또는 용어들의 범위에 내포된 것으로 의도된다. 그러한 비제한적인 예 및 설명을 지시하는 용어는, 비제한적인 예를 들자면, "예를 들면", "예로서", "예컨대", "일 실시예에 있어서" 등이 있다.In addition, any examples or descriptions given herein are in no way to be construed as being limited to, or limited to, any term or terms that they use. Instead, these examples and descriptions should be regarded as being described and merely illustrative in connection with one particular embodiment. Those skilled in the art will appreciate that any term or terminology used in these examples and descriptions applies to other embodiments that may or may not be presented elsewhere in this specification, and all such embodiments are those terms. Or it is intended to be within the scope of the terms. Terms referring to such non-limiting examples and descriptions include, by way of non-limiting examples, "for example", "as an example", "such as", "in one embodiment," and the like.

전술한 바와 같이, 프로세서가 미리 규정된 방식으로 임의의 코드 세그멘트를 실행하게 하는 것이 바람직하다. 이 제어 문제는 적법한 소프트웨어까지도 조작하여 의도하지 않은 또는 오히려 유해한 결과를 생성할 수 있는 많은 변형 방법에 의해 조성될 수 있다. 이러한 공격 방법은 입력 데이터 코너 케이스 또는 다른 알고리즘적 결함을 이용하기 위해 루틴에 대한 입력으로서 가짜 아규멘트(bogus argument)를 공급함으로써 빈약하게 기록되었지만 유효한 코드를 이용하는 것을 포함할 수 있다. 다른 가능한 공격 방법은 각종 프로세서 레지스터(스택 포인터 등), 또는 부적당하거나 의도적으로 잘못된 결과를 산출시키는 방법으로 다른 합법적 코드에 의해 참조되는 외부 메모리 위치에 저장된 데이터를 독립적으로 수정하는 것을 포함한다.As noted above, it is desirable to have the processor execute any code segment in a predefined manner. This control problem can be created by a number of variations in which even legitimate software can be manipulated to produce unintended or rather harmful results. Such attack methods may include using poorly written but valid code by supplying bogus arguments as input to the routine to exploit input data corner cases or other algorithmic flaws. Other possible attack methods include independently modifying data stored in various processor registers (such as stack pointers) or external memory locations referenced by other legitimate code in a manner that yields inappropriate or intentionally wrong results.

이러한 종류의 제어에 영향을 줄 수 있는 다수의 메카니즘이 있다. 이러한 시스템들은 프로세서를 이러한 종류의 비의도적 사용으로부터 보호하는 단순한 방식 및 복잡한 방식 둘 다를 포함한다. 한가지 상당히 안전하지만 복잡한 메카니즘은 코드 세그멘트를 그 실행 전에 선암호화(pre-encryption)하는 것이다. 일단 코드 세그멘트가 메모리로부터 프로세서로 로드되면, 코드 세그멘트는 신중하게 제어된 환경하에서 복호되고 안전한 방식으로 실행되어야 한다(다시 말해서, 코드 세그멘트는 복호 동작과 후속 실행 동작 사이에서 수정되거나 고쳐지지 않아야 한다). 이 메카니즘은 당해 코드 세그멘트가 실행될 수 있기 전에 복호될 때까지 프로세서가 대기해야 하기 때문에 발생할 수 있는 성능 비효율성이 있다. 실행 대상의 특수 코드 세그멘트의 선택과 복호후 실제 실행 사이의 이러한 대기시간(latency)은, 비제한적인 예를 들자면, 프로세서 파이프라인 스톨(stall) 및 데이터 경로 비효율성을 포함한 많은 문제점을 야기할 뿐만 아니라 (복호 동작과 실행 동작 사이에 어떻게든지 코드를 강탈(hijacking)함으로써) 잠재적 공격을 위한 다른 수단을 제공할 수 있다.There are a number of mechanisms that can affect this kind of control. Such systems include both simple and complex ways of protecting the processor from this kind of unintentional use. One fairly secure but complicated mechanism is to pre-encrypt the code segment before executing it. Once the code segment is loaded from the memory into the processor, the code segment must be executed in a decrypted and secure manner under a carefully controlled environment (in other words, the code segment must not be modified or fixed between the decryption operation and subsequent execution operations). . This mechanism is a performance inefficiency that can occur because the processor must wait until the code segment is decoded before it can be executed. This latency between the selection of special code segments to be executed and the actual execution after decryption can cause many problems, including but not limited to processor pipeline stalls and data path inefficiencies. Rather, it can provide another means for a potential attack (by hijacking the code somehow between the decryption and execution operations).

상기 암호화 코드 메카니즘은 명시적으로 보호된 암호화 코드 세그멘트를 적절히 복호하도록 관리하는(또는 상기 암호화 코드 세그멘트의 복호된 복사본을 획득한) 해커의 우발성(eventuality)으로부터 프로세서를 또한 보호할 수 없다. 그 경우, 해커는 보호되지 않은 코드를 목표 프로세서에서 또는 어떤 다른 인증되지 않은 프로세서에서 비제어 방식으로 동작시킬 수 있다. 따라서, 코드가 명문(clear)으로(즉 평문 형태로) 또는 암호화 형태로 분배되는지 여부에 관계없이, 코드 세그멘트가 특수한 프로세서 또는 프로세서들에서 동작할 수 있도록 정확히 제어하는 방법을 찾는 것이 바람직하다. 반면에, 만일 특수한 프로세서에서 동작할 수 있는 코드가 어떤 미리 선택된 부분 집합으로 제한되면, 프로세서 자체의 범용성이 위배될 수 있다. 이것은 아마도 프로세서가 덜 범용적으로 되고 따라서 그 잠재적 응용 공간에서 훨씬 덜 융통성있게 하는 방법으로 아키텍쳐를 속박하는 효과를 가질 수 있다. 최대로 유통성있는 범용 프로세서 아키텍쳐에 대한 강한 희망이 항상 있지만, 그러한 프로세서는 엄밀히 말해서 대부분 멀웨어 공격에 취약하다.The cryptographic code mechanism also cannot protect the processor from the eventuality of hackers managing to properly decrypt explicitly protected cryptographic code segments (or obtaining a decrypted copy of the cryptographic code segment). In that case, the hacker can run the unprotected code in a uncontrolled manner on the target processor or on some other unauthorized processor. Thus, it is desirable to find a way to precisely control the code segment to operate on a particular processor or processors, regardless of whether the code is distributed in clear (ie plain text) or in encrypted form. On the other hand, if the code that can operate on a particular processor is limited to some preselected subset, the generality of the processor itself may be violated. This may have the effect of constraining the architecture, perhaps in a way that makes the processor less general and thus much less flexible in its potential application space. There is always a strong hope for the most circulating general purpose processor architecture, but such processors are, strictly speaking, mostly vulnerable to malware attacks.

따라서, 임의의 특수 프로세서 아키텍쳐에 의존하지 않을 정도로 충분한 범용인 코드 실행을 제어하는 방법이 필요하다. 그러한 방법이 목적 코드(object code) 밀도 또는 목표 프로세서에 악영향을 주지 않는다면 또한 유용할 것이다. 동시에, 그러한 시스템 및 방법이 원래의 목표 프로세서 또는 어떤 다른 의도하지 않은 목표 프로세서에서 다른 적법한 코드 세그멘트의 허가되지 않은 사용에 대한 보호를 제공하는 것이 바람직하다. 그러한 방법은 소프트웨어 바이러스 및 멀웨어를 제어하기 위한 싸움에서 가치있는 도구일 뿐만 아니라 디지털 콘텐트의 세계에서 저작권을 보호하는 유일하게 강력한 메카니즘이다.Thus, there is a need for a way to control general-purpose code execution that is sufficient to not depend on any special processor architecture. It would also be useful if such a method did not adversely affect the object code density or the target processor. At the same time, it is desirable for such systems and methods to provide protection against unauthorized use of other legitimate code segments on the original target processor or any other unintended target processor. Such a method is not only a valuable tool in the fight to control software viruses and malware, but also the only powerful mechanism for copyright protection in the world of digital content.

이 때문에, 이제 범용 코드 블록의 실행에 대한 고도의 특수한 제어를 제공하여 프로그래머가 주어진 코드 블록이 실행될 수 있게 하는 정확한 환경을 결정할 수 있게 하는 시스템 및 방법의 실시예에 주의가 기울여지고 있다. 이 조건들은 코드 블록이 실행하려고 하는 개별 장치, 코드 블록이 호출되는 환경, 실행 시간, 실행 순서, 및 코드 블록이 특수한 실행 스레드(execution thread)에서 호출된 횟수와 같은 제약들(그러나 상기의 것들로 제한되는 것은 아님)을 포함할 수 있다.Because of this, attention is now paid to embodiments of systems and methods that provide a highly specialized control over the execution of general purpose code blocks to allow a programmer to determine the exact environment in which a given code block can be executed. These conditions include, but are not limited to, such as the individual devices the code block is about to execute, the environment in which the code block is called, the execution time, the order of execution, and the number of times the code block has been called in a special execution thread. But not limited to.

이러한 제어 메카니즘은 예를 들면 회귀적 실행을 통하여 일 실시예로서 구현되는 호출된 코드 세그멘트 집합의 명시적으로 순서정해진 실행에 기초하여 데이터 은닉 시스템 및 방법의 실시예와 결합될 수 있다. 이러한 시스템 및 방법의 실시예가 방해없는 일반성 및 공격에 대한 보호 레벨과 함께 사용될 때 많은 다른 보안 시스템을 능가하는 시스템 및 방법이 얻어질 수 있다.Such control mechanisms may be combined with embodiments of data hiding systems and methods based on explicitly ordered execution of a set of called code segments implemented as an embodiment, for example, via recursive execution. Systems and methods that outperform many other security systems can be obtained when embodiments of such systems and methods are used in combination with uninterrupted generality and protection against attack.

실시예를 상세히 설명하기 전에, 본 발명의 실시예가 효과적으로 활용될 수 있는 아키텍쳐의 일반적 개관을 제공하는 것이 도움이 될 수 있다. 도 1은 그러한 토폴로지의 일 실시예를 묘사한 것이다. 여기에서, 콘텐트 분배 시스템(101)은 프로토콜 엔진을 포함하는 하나 이상의 목표 유닛(100)(엔드포인트 장치라고도 부름)에 디지털 콘텐트(예를 들면, 오디오 또는 비디오 데이터를 포함한 비트 스트림, 소프트웨어 애플리케이션 등일 수 있음)를 분배하도록 동작한다. 상기 목표 유닛은 예를 들면 유선 또는 무선 네트워크상의 컴퓨팅 장치 또는 네트워크가 없는 컴퓨터 장치의 일부일 수 있고, 상기 컴퓨팅 장치는 예를 들면 네트워크를 통해 비트스트림으로서 전달된 콘텐트 또는 예컨대 메일을 통해 전달될 수 있는 컴퓨터 판독가능 기억 매체상의 콘텐트를 재생할 수 있는 퍼스널 컴퓨터, 셀룰러 폰, 개인용 정보 단말기, 미디어 플레이어 등을 포함한다. 뒤에서 설명하는 바와 같이, 상기 디지털 콘텐트는 디지털 콘텐트의 실행에 대한 제어가 조절될 수 있고 보안이 디지털 콘텐트와 관련하여 구현될 수 있는 그러한 방법으로 구성 또는 분배될 수 있다.Before describing an embodiment in detail, it may be helpful to provide a general overview of the architecture in which embodiments of the present invention may be effectively utilized. 1 depicts one embodiment of such a topology. Here, the content distribution system 101 may be digital content (eg, a bit stream containing audio or video data, software applications, etc.) in one or more target units 100 (also called endpoint devices) that include a protocol engine. To distribute). The target unit may be, for example, a computing device on a wired or wireless network or part of a computer device without a network, the computing device being able to be delivered via e.g. mail or content delivered as a bitstream over the network, for example. Personal computers capable of playing back content on computer readable storage media, cellular phones, personal digital assistants, media players and the like. As described below, the digital content can be configured or distributed in such a way that control over the execution of the digital content can be adjusted and security can be implemented in connection with the digital content.

도 2는 디지털 콘텐트의 실행을 제어하거나 수신된 디지털 콘텐트와 함께 보안 프로토콜을 구현할 수 있는 목표 유닛의 일 실시예의 구조를 묘사하고 있다. 목표 유닛의 요소들은 목표 유닛(100)의 프로토콜 엔진에서 보안 방식으로 프로토콜을 구현하는 블록들의 집합을 포함할 수 있다. 이 블록들은 이 실시예에서 하드웨어로서 묘사되어 있지만, 소프트웨어를 이용하여 동일한 효력을 가진 유사한 기능을 달성할 수 있다는 것을 알 것이다. 또한, 어떤 실시예는 여기에서 설명한 블록들을 모두 포함할 수 있지만, 다른 실시예는 더 적거나 더 많은 블록들을 이용할 수 있다는 것을 알 것이다.2 depicts the structure of one embodiment of a target unit that can control the execution of digital content or implement a security protocol with the received digital content. The elements of the target unit may comprise a set of blocks that implement the protocol in a secure manner in the protocol engine of the target unit 100. Although these blocks are depicted as hardware in this embodiment, it will be appreciated that similar functionality with the same effect can be achieved using software. Also, while some embodiments may include all of the blocks described herein, it will be appreciated that other embodiments may use fewer or more blocks.

이 블록들 중 첫번째는 실시간 클럭 또는 날짜/시간 레지스터(102)이다. 이것은 자유 동작 타이머(free-running timer)이고 중앙 서버와의 보안적 상호작용에 의해 세트 또는 리세트될 수 있다. 시간이 보안 시간 표준에 대한 질의를 행함으로써 확립될 수 있기 때문에, 이 기능을 온칩(on-chip)으로 하는 것이 더 편리하다. 목표 유닛(100)은 난수 발생기(180)를 또한 포함할 수 있으며, 난수 발생기(180)는 충분한 난수의 열(sequence)을 생성하도록 구성되고, 또는 의사 난수 발생 시스템에 종자값(seed value)을 공급하기 위해 사용될 수 있다. 상기 의사 난수 발생기는 잠재적으로 하드웨어, 소프트웨어 또는 "보안" 소프트웨어로 또한 구현될 수 있다.The first of these blocks is a real time clock or date / time register 102. This is a free-running timer and can be set or reset by secure interaction with the central server. Since time can be established by making a query to a secure time standard, it is more convenient to turn this function on-chip. The target unit 100 may also include a random number generator 180, the random number generator 180 being configured to generate a sequence of sufficient random numbers, or providing a seed value to the pseudo random number generation system. Can be used to feed The pseudo random number generator can potentially also be implemented in hardware, software or "secure" software.

일방향(one-way) 해싱 함수 블록(160)은 실질적으로 하드웨어로 해싱 함수를 구현할 수 있다. 목표 유닛(100)의 다른 부분은 하드웨어 조력 암호화/복호 시스템(170)이고, 이것은 목표 유닛(100)의 비밀키 또는 공개/개인키(뒤에서 설명함)를 이용하여 키들을 실행가능 코드 블록으로 변환하기 위해 암호화 메시지에서 동작하거나 키들을 암호화 메시지로 변환하기 위해 비암호화 데이터에서 동작한다. 상기 복호 시스템(170)은 다양한 방법으로 구현될 수 있다. 이러한 일방향 해싱 함수 및 후속하는 암호화/복호 시스템의 조합은 임의의 디지털 데이터의 유효화를 위해 사용되는 디지털 서명 발생기를 구성할 수 있고, 데이터는 암호화 형태로 또는 평문 형태로 분배된다. 전체 프로토콜의 속도 및 보안은 이 블록의 구성에 따라 변할 수 있고, 따라서 보안 시스템 갱신을 수용하도록 충분한 융통성이 있고 시스템이 시간 임계(time-critical) 메시지의 실시간 복호를 수행하도록 충분히 빠르게 구성할 수 있다.The one-way hashing function block 160 may implement the hashing function in substantially hardware. Another part of the target unit 100 is the hardware assisted encryption / decryption system 170, which converts the keys into executable code blocks using the private or public / private key (described later) of the target unit 100. To the encrypted message to convert the key to an encrypted message. The decoding system 170 may be implemented in various ways. This combination of one-way hashing function and subsequent encryption / decryption system may constitute a digital signature generator used for validating any digital data, the data being distributed in encrypted form or in plain text form. The speed and security of the overall protocol can vary depending on the configuration of this block, so it is flexible enough to accommodate secure system updates and can be configured fast enough to allow the system to perform real-time decryption of time-critical messages. .

이것을 염두에 두고 있으면 어떤 암호화 알고리즘이 이 하드웨어 블록(170)에 대하여 사용되는지에 관한 프로토콜의 정확한 구체화는 중요하지 않다. 최대의 융통성을 촉진하기 위하여, 실제 하드웨어는 비알고리즘적으로 특수한 방법으로 사용되도록 충분히 범용이라고 추정되지만, 이 메카니즘을 구현할 수 있는 많은 다른 수단이 있다. 이 점에서, 용어 암호화 및 복호는 암호화/복호를 수행하는 엔진(알고리즘, 하드웨어, 소프트웨어 등)을 지칭할 때 여기에서 상호 교환적으로 사용된다는 점에 주목하여야 한다. 알 수 있는 바와 같이, 특정 실시예에서 대칭 암호화가 사용되는 경우, 동일하거나 유사한 암호화 또는 복호 엔진이 암호화 및 복호 둘 다를 위해 사용될 수 있다.With this in mind, the exact specification of the protocol as to which encryption algorithm is used for this hardware block 170 is not important. To facilitate maximum flexibility, the actual hardware is assumed to be general enough to be used in a non-algorithmically specific way, but there are many other means of implementing this mechanism. In this regard, it should be noted that the terms encryption and decryption are used interchangeably herein when referring to an engine (algorithm, hardware, software, etc.) that performs encryption / decryption. As can be seen, where symmetric encryption is used in certain embodiments, the same or similar encryption or decryption engine can be used for both encryption and decryption.

다른 블록은 실행될 코드를 저장할 수 있는 메모리(110)이다. 이것은 전형적으로 명령어 캐시(I-캐시)라고 알려져 있다. 일부 실시예에 있어서, 상기 I-캐시(110) 부분들의 중요한 특성은 특정 블록에 내포된 데이터가 CPU 실행 유닛(120)에 의해서만 판독될 수 있다는 것이다. 다시 말해서, I-캐시 메모리(130)의 상기 특수 블록은 실행만 가능하고 임의의 소프트웨어에 의해 판독 또는 기록될 수 없다. 이 I-캐시 블록은 여기에서 "보안 I-캐시"(130)라고도 부른다. 실행 대상 코드를 상기 보안 I-캐시 블록(130)에 저장하는 방법은 묘사되거나 묘사되지 않은 다른 블록에 의해서 수행될 수 있다. 정상 I-캐시(150)는 잘 알려져 있는 바와 같이 정상적으로 실행되는 코드를 저장하기 위해 사용된다.Another block is memory 110, which can store code to be executed. This is typically known as an instruction cache (I-cache). In some embodiments, an important characteristic of the portions of I- cache 110 is that the data contained in a particular block can only be read by CPU execution unit 120. In other words, the special block of I- cache memory 130 is executable only and cannot be read or written by any software. This I-cache block is also referred to herein as "secure I-cache" 130. The method of storing the code to be executed in the secure I- cache block 130 may be performed by another block that is depicted or not depicted. Normal I- cache 150 is used to store code that executes normally, as is well known.

게다가, 일부 실시예에서, 특정 블록을 사용하여 보안 코드 블록의 동작을 가속화할 수 있다. 따라서, CPU(120)가 보안 코드를 실행하는 동안 액세스만 가능한 CPU 레지스터(140)의 집합이 지정될 수 있고 보안 코드 블록이 실행 종료시에 CPU 레지스터가 클리어되며(보안 코드 블록(130) 내의 명령어는 보안 모드라고 부른다), 또는 보안 I-캐시(130)에 저장된 코드의 실행 중에 어떤 이유로 비보안 즉 "정상" I-캐시 또는 다른 영역에 위치된 임의의 코드 섹션으로의 점프가 발생한다.In addition, in some embodiments, certain blocks may be used to speed up the operation of secure code blocks. Thus, a set of CPU registers 140 accessible only while the CPU 120 executes the security code can be specified and the CPU register is cleared at the end of execution of the security code block (instructions in the security code block 130 are Or execution of code stored in secure I- cache 130, for some reason a jump to an insecure or " normal " I-cache or any code section located in another area occurs.

일 실시예에 있어서, CPU 실행 유닛(120)은 보안 코드 블록(130)에 저장된 코드를 실행하는 동안 어떤 레지스터(140)가 판독 또는 기록되는지를 추적하고, 그 다음에 "보안 실행" 모드를 빠져나갈 때 상기 레지스터를 자동으로 클리어하도록 구성될 수 있다. 이것은 보안 코드가 그 자체 후에 신속히 "청소(clean-up)"되어 2종류의 코드 블록들 간에 공유되도록 허용된 데이터만이 본래대로 유지되게 한다. 다른 하나의 가능성은 보안 코드 블록(130) 내에서 실행되는 코드의 창조자(author)가 어떤 레지스터(140)가 클리어되어야 하는지를 명시적으로 식별할 수 있다는 것이다.In one embodiment, CPU execution unit 120 tracks which registers 140 are read or written while executing code stored in secure code block 130 and then exits the "secure execution" mode. It may be configured to automatically clear the register upon exit. This allows the security code to be "clean-up" quickly after itself so that only the data allowed to be shared between the two types of code blocks remains intact. Another possibility is that the author of code executing within secure code block 130 can explicitly identify which register 140 should be cleared.

보안 코드 세그멘트와 비보안 코드 세그멘트 사이에서 레지스터(140)에 저장된 데이터의 "누설"을 취급하는 다른 잠재적인 방법은 CPU(120)가 보안 코드를 실행할 때만 사용되는 레지스터(140)의 집합을 식별하는 것이다. 일 실시예에 있어서, 이것은 많은 현대의 CPU 설계에서 실시되고 있는 레지스터 리네이밍(renaming) 및 스코어보딩(scoreboarding) 메카니즘의 버전을 이용하여 달성될 수 있다. 만일 보안 코드 블록의 실행이 원자 동작(atomic action)으로 취급되면(즉, 중단할 수 없으면), 이것은 상기 리네이밍 및 스코어보딩의 구현을 더 쉽게 할 수 있다.Another potential way of dealing with the "leakage" of data stored in register 140 between secure code segments and non-secure code segments is to identify a set of registers 140 that are used only when CPU 120 executes secure code. . In one embodiment, this may be accomplished using a version of the register renaming and scoreboarding mechanisms implemented in many modern CPU designs. If the execution of the secured code block is treated as an atomic action (ie, it cannot be stopped), this may make the implementation of the renaming and scoreboarding easier.

CPU(120)가 "보안" 코드(보안 코드 블록(130) 내의 코드)와 "비보안 코드"(정상 I- 캐시(150)와 같은 다른 위치 또는 메모리의 다른 위치 내의 코드)의 혼합물을 실행할 가능성이 거의 없어보인다 할지라도, 그러한 상황은 인터럽트 루틴으로 점프할 때와 같이 콘텍스트를 스위칭하는 처리에서, 또는 CPU(120) 콘텍스트가 어디에 저장되어 있는가에 따라서 발생할 수 있다(대부분의 CPU는 메인 메모리에 콘텍스트를 저장하지만, 메인 메모리는 잠재적으로 비보안 코드 블록에 의해 발견 및 조작되기 쉽다). CPU 120 is likely to execute a mixture of "secure" code (code in secure code block 130) and "non-secure code" (code in another location, such as normal I- cache 150, or in another location in memory) Although rarely seen, such a situation can occur in a process of switching contexts, such as when jumping to an interrupt routine, or depending on where the CPU 120 context is stored (most CPUs have a context in main memory. Store, but main memory is potentially susceptible to discovery and manipulation by insecure code blocks).

이러한 우발성에 대한 보호를 돕기 위해, 일 실시예에 있어서, 중간 실행(mid-execution)이 시스템 내의 다른 실행 스레드에 노출되는 것이 금지되고 있는 보안 코드 블록의 실행 중에 얻어진 결과를 보호하기 위해 사용될 수 있는 다른 방법은 프로세서가 보안 실행 모드에서 동작중인 동안 스택 푸시(stack push)를 디스에이블 하는 것이다. 이러한 스택 푸시의 디스에이블은 만일 보안 코드 블록이 그 정상적인 종료 전에 인터럽트되면 보안 코드 블록은 재개시(resume)될 수 없고 따라서 처음부터 다시 시작되어야 한다는 점에서 보안 코드 블록이 인터럽트 불능이라는 것을 의미한다. 특정 실시예에서, 만일 "보안 실행" 모드가 프로세서 인터럽트 중에 디스에이블되면 보안 코드 블록은 전체 호출 사슬(calling chain)이 재시작되지 않는 한 잠재적으로 재시작될 수 없다.To help protect against this contingency, in one embodiment, a mid-execution can be used to protect the results obtained during execution of a block of secure code that is prohibited from exposing to other executing threads in the system. Another way is to disable stack push while the processor is operating in secure execution mode. Disabling this stack push means that the security code block is non-interruptible in that if the security code block is interrupted before its normal termination, the security code block cannot be resumed and therefore must be restarted from the beginning. In certain embodiments, if the "secure execution" mode is disabled during processor interrupts, the secure code block cannot potentially be restarted unless the entire calling chain is restarted.

각 목표 유닛(100)은 2세트의 비밀키 상수(104)를 또한 가질 수 있고, 그들의 값은 어느 것도 소프트웨어에 의해 판독될 수 없다. 이들 키의 첫번째(1차 비밀키)는 비밀키의 집합으로서 구성될 수 있고, 그들 중에서 하나만이 임의의 특정 시간에 판독될 수 있다. 만일 유닛의 "소유권"이 바뀌면(예를 들면, 프로토콜 엔진을 내포한 설비가 판매되거나 그 소유권이 다른 방식으로 이전되면), 현재 활성인 1차 비밀키는 "클리어"되거나 다른 값으로 덮어쓰기 될 수 있다. 이 값은 보안 방식으로 유닛에 전달될 수도 있고, 또는 상기 제1 키가 클리어된 때에만 사용되는 방식으로 유닛에 이미 저장되어 있을 수도 있다. 사실, 이것은 유닛의 소유권이 변경되었을 때 또는 그러한 변경에 관한 어떤 다른 이유가 있는 경우(절충키(compromised key)와 같이) 새로운 1차 비밀키를 상기 특수 유닛에 발행하는 것과 등가이다. 2차 비밀키는 목표 유닛(100) 자체와 함께 사용될 수 있다. 목표 유닛(100)의 CPU(120)는 1차 또는 2차 비밀키의 값에 액세스할 수 없으므로, 어떤 면에서 목표 유닛(100)은 그 자신의 비밀키(104)까지도 알지 못한다. 이 키들은 목표 유닛 CPU(120)의 보안 블록 내에 저장되어 사용될 뿐이다.Each target unit 100 can also have two sets of secret key constants 104, and none of their values can be read by software. The first of these keys (the primary secret key) can be configured as a set of secret keys, and only one of them can be read at any particular time. If the unit's "ownership" is changed (for example, a facility containing a protocol engine is sold or its ownership is transferred in another way), the currently active primary secret key will be "cleared" or overwritten with another value. Can be. This value may be delivered to the unit in a secure manner, or may already be stored in the unit in a manner used only when the first key is cleared. In fact, this is equivalent to issuing a new primary secret key to the special unit when the ownership of the unit changes or if there is any other reason for such a change (such as a compromised key). The secondary secret key may be used with the target unit 100 itself. Since the CPU 120 of the target unit 100 cannot access the value of the primary or secondary secret key, the target unit 100 does not know even its own secret key 104 in some respects. These keys are only stored and used in the security block of the target unit CPU 120.

다른 키 집합은 임시 공개/개인키 시스템(비대칭 키 시스템 또는 PKI 시스템이라고도 알려져 있다)의 일부로서 동작할 수 있다. 이 쌍의 키들은 급하게(on the fly) 생성되고, 중앙 서버의 개입없이 유사한 유닛들 간의 보안 통신 링크를 확립하기 위해 사용될 수 있다. 이러한 시스템의 보안성이 등가 키 길이 대칭 키 암호화 시스템의 보안성보다 전형적으로 더 낮기 때문에, 이 키들은 전술한 비밀키 집합보다 사이즈가 더 크다. 이 키들은 다른 무엇보다도 "재전송 공격"에 대하여 보호하기 위해 온칩 타이머 블록에서 제시되는 값과 함께 사용될 수 있다. 이 키들은 급하게 생성되기 때문에, 키들이 생성되는 방법은 난수 발생 시스템(180)에 의존할 수 있다.The other key set may operate as part of a temporary public / private key system (also known as asymmetric key system or PKI system). These pairs of keys are generated on the fly and can be used to establish a secure communication link between similar units without the intervention of a central server. Since the security of such a system is typically lower than that of an equivalent key length symmetric key encryption system, these keys are larger in size than the secret key set described above. These keys can be used in conjunction with the values presented in the on-chip timer block to, among other things, protect against "retransmission attacks." Since these keys are generated in a hurry, how the keys are generated may depend on the random number generation system 180.

일 실시예에 있어서, 특수 목표 유닛의 "소유권" 변경에 영향을 줄 수 있는 하나의 방법은 우리가 타임스탬프 또는 타임스탬프 값이라고 부르는 다른 키(107)와 함께하는 합성키(compound key)로서 1차 비밀키를 항상 사용하는 것이다. 왜냐하면, 상기 다른 키의 값은 변경될 수 있고(다시 말해서 다른 시간에 다른 값을 가질 수 있음), 반드시 현재 일시를 반영하지 않기 때문이다. 이 타임스탬프 값 자체는 구조적으로 가시적일 수도 가시적이 아닐 수도 있지만(즉, 반드시 비밀키일 필요가 없다), 그럼에도 불구하고 목표 유닛이 보안 실행 모드에서 동작하지 않는 한 수정될 수 없다. 그 경우에, 1차 비밀키가 사용될 때마다 합성 키의 성분으로서 타임스탬프 값의 일관된 사용은 본질적으로 마치 1차 비밀키가 별도의 값으로 전환된 것과 동일한 효과를 만들 수 있고, 따라서 1차 비밀키 자체를 수정할 필요없이 특수 목표 엔드포인트 유닛의 "소유권 변경"을 효과적으로 가능하게 한다.In one embodiment, one way that may affect the "ownership" change of a special target unit is a primary key as a compound key with another key 107, which we call a timestamp or timestamp value. The secret key is always used. This is because the value of the other key can be changed (that is, have a different value at different times) and does not necessarily reflect the current date and time. This timestamp value itself may or may not be structurally visible (ie it does not necessarily have to be a secret key), but nevertheless cannot be modified unless the target unit is operating in secure execution mode. In that case, consistent use of the timestamp value as a component of the composite key whenever the primary secret key is used can essentially produce the same effect as if the primary secret key was converted to a separate value, and thus primary secret key. It effectively enables "change of ownership" of special target endpoint units without having to modify the keys themselves.

이제, 목표 유닛의 일방향 해싱 함수 하드웨어에 대하여 더 상세히 설명한다. 이제 도 15를 참조하면, 후속되는 반복에서 일방향 해싱 함수를 위한 종자값으로서 회귀형 보안 프로토콜의 1회 반복시에 생성된 디지털 서명 동작의 결과를 이용할 수 있는 일방향 해싱 함수 블록의 일 실시예가 도시되어 있다. 일 실시예에 있어서, 목표 유닛의 상태는, 목표 유닛이 보안 실행 모드에서 동작하는지 아닌지에 관계가 있는 한, 여기에서 "보안 모드 인에이블" 비트라고 부르는 하드웨어 비트(1570)의 값에 의해 반영될 수 있다.Now, the one-way hashing function hardware of the target unit will be described in more detail. Referring now to FIG. 15, there is shown one embodiment of a one-way hashing function block that can use the result of a digital signature operation generated at one iteration of a recursive security protocol as a seed value for the one-way hashing function in a subsequent iteration. have. In one embodiment, the state of the target unit is to be reflected by the value of a hardware bit 1570, referred to herein as a "secure mode enable" bit, as long as it relates to whether the target unit is operating in secure execution mode or not. Can be.

여기에서, 이 하드웨어 비트의 디폴트 상태는 클리어될 수 있다(즉, 목표 프로세서의 디폴트 상태는 보안 실행 모드에서 동작하지 못하게 한다). 특정 실시예에서 이 비트와 일방향 해싱 함수 하드웨어 블록(1561)과의 상호작용은 2개의 부분으로 나누어 설명할 수 있다. 첫번째(비보안) 경우에, 하드웨어 비트가 세트(예를 들면 "1"로 되는 것, 그러나 특정의 아키텍쳐에서는 이 비트가 "0"의 값을 가질 때 "세트"로 간주될 수 있다)일 때에만 비밀 하드웨어 키의 사용을 허용하도록 "보안 모드 인에이블" 비트가 문지기로서 작용하기 때문에, 비밀 하드웨어 키(1540)에 대한 모든 액세스는 차단된다. 또한, 이 경우에, 디지털 서명 레지스터(1564)의 출력은 피드백되어 일방향 해싱 함수(1561)의 입력 "종자"(1510)를 형성한다. 따라서, 프로세서가 "비보안 실행" 모드에서 동작하는 동안 임의의 일방향 해싱 함수 동작의 중간 결과가 피드백되어 임의의 후속 일방향 해싱 함수 동작을 위한 종자를 형성한다. 이것은 네스트된(nested) 또는 연쇄 기능(concatenated function)의 집합의 전체 호출 사슬(calling chain)과 동일한 가동 체크섬(running checksum)이 유지될 수 있게 한다. 실행을 시도하는 각 코드 블록의 실행이 허용되기 전에 상기 일방향 해싱 함수로 먼저 평가된 경우에, 임의의 주어진 코드 블록의 전체 호출 사슬은 이 단일 메카니즘으로 실질적으로 명확하게 결정될 수 있다.Here, the default state of this hardware bit can be cleared (ie, the default state of the target processor prevents it from operating in secure execution mode). In a particular embodiment, the interaction of this bit with the one-way hashing function hardware block 1561 can be described in two parts. In the first (non-secure) case, only when the hardware bit is a set (eg going to be "1", but on certain architectures it can be considered "set" when this bit has a value of "0"). Since the "Secure Mode Enable" bit acts as a gatekeeper to allow the use of the secret hardware key, all access to the secret hardware key 1540 is blocked. Also in this case, the output of the digital signature register 1564 is fed back to form an input “seed” 1510 of the one- way hashing function 1561. Thus, while the processor is operating in "non-secure execution" mode, the intermediate result of any one-way hashing function operation is fed back to form a seed for any subsequent one-way hashing function operation. This allows a running checksum equal to the entire calling chain of a nested or concatenated set of functions to be maintained. If first evaluated with the one-way hashing function before execution of each block of code that attempts to execute, the entire call chain of any given block of code can be determined substantially clearly with this single mechanism.

마찬가지로, "보안 모드 인에이블" 비트가 세트인 경우(즉, 프로세서가 "보안 실행 모드"에서 동작하는 경우)에, 비밀 하드웨어 키는 액세스 가능하다(다시 말해서, 그 값이 프로세서 자체에 의해 직접 액세스할 수 없는 경우에도 직접 액세스가능하거나, 적어도 그 값이 계산 동작에서 사용될 수 있다). 게다가, 보안 실행 모드에서 동작할 때, 디지털 서명 레지스터의 출력은 피드백되지 않고 일방향 해싱 함수의 후속 평가를 위한 종자 값을 형성한다. 이 디지털 서명 발생기 블록의 정확한 구현은 뒤에서 더 자세히 설명한다. 이제 알 수 있는 바와 같이, 특정 실시예에서, 특수 코드 블록의 전체 호출 사슬은 시스템 와이드 소프트웨어 또는 하드웨어 유효화(또는 인증) 동작과 같은 수단을 사용할 필요없이 그 보안 실행 전에 유효화될 수 있다. 타임스탬프 레지스터와 관련하여 위에서 설명한 경우에서처럼, 특정 실시예에 있어서, 이 "보안 모드 인에이블" 비트는 프로세서에 대해 구조적으로 가시적이거나 가시적이 아닐 수 있지만, 그 상태는 프로세서에 의해 명시적으로 세트되지 않을 수 있다는 점에 주목한다. 이 하드웨어 비트는 비보안 코드 세그멘트를 호출함으로써 디폴트 값으로 리세트될 수 있지만, 일 실시예에 있어서, 이 비트가 세트될 수 있는 유일한 방법은 하드웨어 부분에서의 직접 동작을 통하는 것이다. 비트가 구조적으로 가시적인 경우에, 프로세서가 보안 실행 모드에서 동작중인지 아닌지는 명시적으로 결정될 수 있다. 비트가 구조적으로 가시적이지 않은 경우에, 결정은 그럼에도 불구하고 그 값이 어쨋든 하드웨어 비밀키에 의존한다는 어떤 표현을 평가함으로써 암시적으로 행하여질 수 있다.Similarly, if the "secure mode enable" bit is set (ie, the processor is operating in "secure execution mode"), the secret hardware key is accessible (that is, the value is directly accessed by the processor itself). Even if it is not possible, it is directly accessible, or at least its value may be used in the calculation operation). In addition, when operating in secure execution mode, the output of the digital signature register is not fed back and forms a seed value for subsequent evaluation of the one-way hashing function. The exact implementation of this digital signature generator block is discussed in more detail later. As can now be seen, in certain embodiments, the entire call chain of a special code block can be validated prior to its security execution without the need to use means such as system wide software or hardware validation (or authentication) operations. In certain embodiments, as in the case described above with respect to the timestamp register, this "secure mode enable" bit may or may not be structurally visible to the processor, but its state is not explicitly set by the processor. Note that it may not. This hardware bit can be reset to its default value by calling an unsecure code segment, but in one embodiment, the only way this bit can be set is through direct operation in the hardware portion. If the bit is structurally visible, it can be explicitly determined whether the processor is operating in secure execution mode. If the bit is not structurally visible, the decision can be made implicitly by evaluating any representation that the value nevertheless depends on the hardware secret key.

이제, 코드 실행의 제어 및 보안 프로토콜의 구현에 밀접한 관계가 있는 주제(subject) 하의 기본적인 문제점에 대하여 구체적으로 설명한다. 그래서 전술한 하드웨어의 실시예를 이용하여 임의의 범용 프로세서에서 임의 코드의 실행을 제어하는 법 및 이들 시스템 및 방법의 실시예가 보안 프로토콜 및 시스템과 함께 어떻게 효과적으로 사용되어 효과적인 전체 보안 시스템을 구성하는지를 알 수 있다.Now, the basic problem under the subject that is closely related to the control of code execution and the implementation of the security protocol will be described in detail. Thus, using the embodiments of the hardware described above, it can be seen how to control the execution of arbitrary code on any general purpose processor and how the embodiments of these systems and methods are effectively used with security protocols and systems to form an effective overall security system. have.

비밀키 은닉Secret key concealment

상업적 디지털 콘텐트 전송 시스템의 대부분은 디지털 미디어 데이터가 자유롭게 복제 및 분배되는 것으로부터 보호하기 위해 소정 형태의 암호화 또는 데이터 은닉(data hiding)을 포함한다. 대부분의 경우에, 데이터 은닉 전략은 콘텐트 보호와 관련하여 완전히 비효과적인 수단이라는 것이 결국 입증되었다. 이러한 은닉이 비성공적인 것으로 입증된 중요 이유중의 하나는 노출로부터 보호되어야 할 정확한 데이터가 그럼에도 불구하고 임의의 인증된 당사자에게는 자유롭게 이용할 수 있어야 한다는 것이다. 따라서, 디지털 콘텐트의 분배에 있어서 외관상 모순이되는 일련의 필요조건이 존재한다.Most commercial digital content delivery systems include some form of encryption or data hiding to protect digital media data from being freely copied and distributed. In most cases, the data hiding strategy has eventually proved to be a completely ineffective means with regard to content protection. One of the key reasons why such concealment has proved unsuccessful is that the exact data to be protected from exposure should nevertheless be freely available to any authorized party. Thus, there is a set of requirements that seemingly contradictory in the distribution of digital content.

모든 의도된 수령자에 대하여 원래의 디지털 콘텐트가 별도로 암호화될 수 있는 경우 및 의도된 수령자만이 분배된 디지털 콘텐트를 실제로 사용할 수 있는 경우에, 시스템의 보안성은 잠재적으로 아주 양호할 수 있다. 그러나, 다수의 특수한 조건들이 부합되지 않으면, 이러한 종류의 시스템의 보안성은 몇 가지 점에서 불충분한 것으로 보여질 수 있다. 첫째로, 이러한 시스템은 분배된 데이터 집합 전체가 각각의 의도된 수령자에 대하여 별도로 재암호화될 것을 필요로 한다는 점에서 덜 효율적이다. 둘째로, 분배자는 범용 프로세서에서 인증되지 않은 복호가 불가능하다는 것을 보장할 필요가 있다. 셋째로, 각각의 개별 수신 장치는 일부 다른 엔드포인트 장치에서 쉽게 복제(또는 범용 프로세서에서 에뮬레이트)될 수 없는 일부 속성을 가져야 한다는 점에서 유일한 것이어야 한다. 만일 상기 마지막 2가지 조건 중의 어느 하나가 위배되면, 이 시스템은 개별적으로 암호화된 데이터 뿐만 아니라 그 데이터와 관련된 장치 지정 키 둘 다를 단순히 가로챔(intercepting)으로써 공격을 받기 쉽다.If the original digital content can be separately encrypted for all intended recipients, and only the intended recipients can actually use the distributed digital content, then the security of the system can potentially be quite good. However, if many special conditions are not met, the security of this kind of system can be seen as insufficient in some respects. First, such a system is less efficient in that the entire distributed data set needs to be re-encrypted separately for each intended recipient. Second, the distributor needs to ensure that unauthorized decryption is not possible in a general purpose processor. Third, each individual receiving device must be unique in that it must have some attributes that cannot be easily replicated (or emulated in a general purpose processor) on some other endpoint device. If either of the last two conditions are violated, the system is susceptible to attack by simply intercepting both individually encrypted data as well as device-specific keys associated with that data.

사실, 이러한 시스템의 보안성은 각 수신 장치의 유일한 속성(unique attribute)의 보안성에 기초를 두는 것으로 보여질 수 있다. 이 유일한 속성은 전형적으로 분배자 및 인증된 수령자에게만 공지된 비밀키를 이용하여 구현된다. 비록, 원칙적으로, 이러한 종류의 셋업은 유효한 보안 시스템이 될 수 있지만, 각 수령자에 대하여 원래의 디지털 콘텐트를 별도로 암호화하는 필요조건은 대부분의 용도에서의 실제 구현을 비실용적으로 만든다. 최초의 디지털 콘텐트를 1회만 암호화하고 모든 잠재적인 인증된 당사자에게 동일하게 분배되는 것이 바람직하다면, 문제점은 데이터 은닉의 문제로 되돌아간다. 이러한 종류의 문제점은 방송 암호화 분야에서 공지되어 있다.In fact, the security of such a system can be seen to be based on the security of the unique attribute of each receiving device. This unique attribute is typically implemented using a private key known only to the distributor and authorized recipient. Although, in principle, this kind of setup can be a valid security system, the requirement to separately encrypt the original digital content for each recipient makes the practical implementation impractical for most purposes. If it is desirable to encrypt the original digital content only once and distribute it equally to all potential authorized parties, the problem reverts to the problem of data concealment. This kind of problem is known in the field of broadcast encryption.

거의 모든 종류의 분배형 비밀 데이터 시스템과 관련된 기본적인 문제점들 중의 하나는, 대부분의 경우에, 보안 시스템의 별도의 엔티티들 사이에서 이리저리로 흐르는 모든 메시지 및 데이터가 일반적으로 개방 상태로 전송되고 따라서 도청자(eavesdropper)에 의해 포착될 수 있다는 것이다. 따라서, 그러한 시스템의 개별 컴포넌트 사이에서 전송되는 임의의 메시지 및 데이터는 인증되지 않은 당사자에 의해 가로채는 것으로부터 보호하기 위해 암호화되어야 한다. 이러한 시스템에서 고려해야 할 다른 하나의 문제점은 임의의 이러한 비밀 데이터 전송시에 전송자 뿐만 아니라 수신자 둘 다의 신원을 검증하는 것이다. 두 당사자가 서로 알지 못하는 경우에, 전형적으로 상호 신뢰되는 매개 전략이 사용된다.One of the basic problems associated with almost all types of distributed secret data systems is that in most cases, all messages and data flowing back and forth between separate entities in the security system are generally sent open and thus eavesdroppers can be captured by (eavesdropper). Thus, any messages and data transmitted between individual components of such a system must be encrypted to protect them from being intercepted by unauthorized parties. Another problem to consider in such a system is to verify the identity of both the sender as well as the receiver in any such secret data transmission. In cases where the two parties do not know each other, a mutually trusted intermediary strategy is typically used.

그러나, 비밀 데이터가 그 목적지에 도달하면, 취급되어야 할 동일하게 어려운 문제점은 절충되지 않은 방식으로 그 비밀 데이터를 어떻게 안전하게 사용할 것인가이다. 이러한 예방책은 적법한 엔드포인트마저도 잘못된 정보가 제공됨으로써 절충되는 보안성을 가질 수 있기 때문에 일반적으로 필요하다. 그래서, 분배중에 인증되지 않은 발견에 대한 보호 외에도, 가끔은 비밀 데이터가 그 비밀 데이터에 대해 다른 인증되지 않은 사용자에 의해 발견되는 것으로부터 보호하는 것이 요구된다.However, once the secret data reaches its destination, the equally difficult problem to be dealt with is how to safely use the secret data in an uncompromising manner. This precaution is generally necessary because even legitimate endpoints can be compromised by providing false information. Thus, in addition to protection against unauthorized discovery during distribution, it is sometimes required to protect secret data from being discovered by other unauthorized users for that secret data.

일 실시예에 있어서, 이러한 요구되는 제어는 구조적으로 은닉된 비밀키 또는 실행 전에 실시간으로 복호되어야 하는 암호화 목적 코드 블록의 단순한 시간 의존성 사용을 이용하여 구현될 수 있다. 첫번째 경우에, 코드 블록 실행은 제어 메카니즘에 완전하게 투명할 수 있고, 이것은 실행 속도가 최소로 영향을 받아야 한다는 것을 의미한다. 후자의 경우에, 동작 대상의 코드 블록은 실행 전에 복호되어 복호 처리의 대기 시간에 기인하는 동시 성능 손실을 받을 가능성이 높다. 그러나, 이 후자의 경우에, 목적 코드는 분해(disassembly)로부터 비교적 안전하고, 따라서 예비(would-be) 공격자에 의해 파괴되기가 잠재적으로 더 어렵다. 나중에 여기에서 설명하는 실시예는 고도로 안전한 암호화 목적 코드 방법으로부터 비교적 높은 성능이지만 여전히 매우 안전하고 선택적으로 이용가능한 비밀키 방법까지에 걸치는 가능한 솔루션의 큰 연속체로 구현될 수 있는 시스템 및 방법을 개시한다.In one embodiment, this required control can be implemented using a structurally hidden secret key or a simple time dependent use of a cryptographic purpose code block that must be decrypted in real time before execution. In the first case, code block execution can be completely transparent to the control mechanism, which means that execution speed should be minimally affected. In the latter case, the block of code to be operated is likely to be decoded before execution and suffer simultaneous performance loss due to the latency of the decoding process. In this latter case, however, the object code is relatively safe from disassembly and is therefore potentially more difficult to be destroyed by a would-be attacker. Embodiments described later herein disclose systems and methods that can be implemented in large continuum of possible solutions ranging from highly secure cryptographic object code methods to relatively high performance but still very secure and optionally available secret key methods.

일 실시예에 있어서, 비밀키의 사용자로부터 비밀키를 은닉하는 것은 하버드 아키텍쳐 메모리 스페이스 분기(Harvard Architecture memory space bifurcation)와 유사한 방법으로 달성될 수 있다. 그러나, 이 실시예에서, 비밀키가 암호화/복호 계산에서 사용될 수 있지만 실제로는 프로세서에 의해 직접 판독되지 않는 차이점이 있다. 이러한 차이는 하드웨어의 설계시에 고정된, 하드웨어로 구현되거나 소프트웨어 매크로(마이크로 코드라고도 알려져 있음)를 미리 결정한 것에 대한 암호화/복호 동작을 제한함으로써 시행될 수 있다. 예를 들면, 하드웨어 비밀키가 임의 코드에 의해 사용되는 경우, 비밀키가 프로세서에 의해 직접 판독될 수 없다 하더라도 비밀키는 단순한 계산에 의해 쉽게 결정될 수 있다. 따라서, 단지 보안 관련 계산이 하드웨어 비밀키에 액세스하여 코드 세그멘트를 더 범용이지만 덜 안전한 코드 블록으로부터 구별하는 것이 요구될 수 있다.In one embodiment, concealing the secret key from the user of the secret key may be accomplished in a similar manner to the Harvard Architecture memory space bifurcation. However, in this embodiment, the difference is that the secret key can be used in encryption / decryption calculations but is not actually read directly by the processor. This difference can be enforced by limiting encryption / decryption operations to hardware-implemented or predetermined software macros (also known as microcodes) that are fixed at the time of design of the hardware. For example, if a hardware secret key is used by any code, the secret key can be easily determined by simple calculation even if the secret key cannot be read directly by the processor. Thus, only security-related calculations may be required to access the hardware secret key to distinguish code segments from more general but less secure code blocks.

이러한 구별은 특정 실시예에서 여기에서 설명한 것과 실질적으로 유사한 유효화 방법을 이용하여 달성될 수 있다. 위에서 설명한 적응 디지털 서명 방법의 실시예가 하드웨어 비밀키의 액세스 가능성을 결정하기 위해 사용된 경우 목표 프로세서가 보안 관련 계산(즉, 목표 프로세서가 "보안 실행" 모드에서 동작할 때 수행하는 계산) 및 보안되지 않은 계산을 실행하는지를 쉽고 신뢰성있게 결정할 수 있다. 또한, 위에서 언급한 것과 실질적으로 유사한 회귀적 방법을 이용하여 최종 계산이 완료되고 완전히 디코드된 결과가 보고될 때까지 복구로부터 숨겨진 임의의 중간 키 결과를 유지할 수 있다. 따라서, 여기에서 설명한 실시예들은 동일한 비트스트림을 생성하기 위해 사용된 비밀 글로벌 키를 노출시키지 않고 암호화 디지털 비트스트림을 디코드하는 능력이 있다.This distinction can be achieved using a validation method substantially similar to that described herein in certain embodiments. When the embodiment of the adaptive digital signature method described above is used to determine the accessibility of the hardware secret key, the target processor does not have security-related calculations (ie, the calculations performed when the target processor operates in "secure execution" mode) and is not secured. You can easily and reliably decide whether or not to run uncomputed calculations. In addition, a regression method substantially similar to that mentioned above can be used to keep any intermediate key results hidden from recovery until the final calculation is completed and the fully decoded result is reported. Thus, the embodiments described herein have the ability to decode the encrypted digital bitstream without exposing the secret global key used to generate the same bitstream.

코드 실행 제어Code execution control

주어진 프로세서에서 특수 코드 세그멘트가 안전하게 실행되는 것을 보장하는 방법은 수년 동안 폭넓게 연구되어 왔다. 보안 코드 실행 보호를 생성하기 위한 일부 초기의 시도는 "특권(privileged)" 명령어 집합을 확립하기 위해 프로세서 구조를 변경하는 것을 포함하였다. 이 특권 명령어는 프로세서가 "수퍼바이저(supervisor)" 또는 "커넬(kernel)" 모드라고 알려져 있는 특수 모드에서 동작할 때에만 상기 특권 명령어가 실행될 수 있도록 구조를 설계함으로써 안전하게 되었다. 이러한 종류의 프로세서 구조의 분기는 프로세서 일반성의 잠재적 손실 및 잠재적 성능 감퇴를 포함한 많은 단점이 있다. 이러한 단점 외에도, 상기 보호 수단은 프로세서가 수퍼바이저 모드에서 실행하는 동안 예기치않은 실행 경로의 잇점을 취하는 방식으로 표준 시스템 루틴에 대한 특수 설계된 소프트웨어 콜을 사용함으로써 가끔 우회될 수 있다. 이러한 특수 설계된 멀웨어 공격의 예로는 소위 "스택 오버플로우", "스택 오버런" 및 "코드 주입" 공격이 있다.How to ensure that special code segments run safely on a given processor has been extensively studied for many years. Some early attempts to create secure code execution protection included modifying the processor structure to establish a "privileged" instruction set. This privileged instruction has been secured by designing the architecture so that the privileged instruction can only be executed when the processor is operating in a special mode known as "supervisor" or "kernel" mode. Branching of this kind of processor architecture has many disadvantages, including potential loss of processor generality and potential performance degradation. In addition to these drawbacks, the safeguards can sometimes be bypassed by using specially designed software calls to standard system routines in a way that takes advantage of unexpected execution paths while the processor is running in supervisor mode. Examples of such specially designed malware attacks are so-called "stack overflow", "stack overrun" and "code injection" attacks.

체크섬 검증 또는 아규멘트 바운즈(argument bounds) 체킹의 각종 수단에 주로 기초해서 상기 종류의 익스플로잇(exploit)에 대한 보호를 돕는 시도에서 많은 전략이 고안되었다. 이러한 종류의 보호 수단에도 불구하고, 다형 바이러스(polymorphic viruses)(즉, 자기 수정 코드)를 포함한 다양한 카운터-카운터-방책이 안출되었다. 바운즈-체킹에도 불구하고 프로세서 약점을 이용하는 다른 전략은 바운즈 체킹 "수퍼바이저" 루틴 자체를 단순히 우회하는 것을 포함한다. 이러한 종류의 익스플로잇은 우회하는 각종 복사 보호 시스템에서 아주 가끔 사용된다. 이것이 발표됨으로써, 수퍼바이저 루틴을 강탈하는 전략은 컴퓨터 보안 세계에서 유일한 것이 아니고 전혀 새로운 개념이 아니다. 사실, 이 정확한 문제는 다양한 애플리케이션에서 유사체(analog)를 가지며 플라토 시절까지 그의 저서 "더 리퍼블릭(The Republic)"에서 참조되었다. 기본적인 문제점은 임의의 주어진 시스템에서 글로벌 수퍼바이저의 일부 종류를 항상 식별할 수 있고, 이것으로 궁극적인 보안 또는 구조의 안정성이 신뢰된다는 것이다. 후속하는 모든 보안 기능에 대한 이러한 총체적 토대의 개념은 보안 시스템에 관한 현대의 연구에서 "신뢰의 근간(Root-of-Trust)"이라고 알려져 있다.Many strategies have been devised in an attempt to help protect against this kind of exploit based primarily on various means of checksum verification or argument bounds checking. Despite this kind of protection, a variety of counter-counter-measures have been devised, including polymorphic viruses (ie, self-modifying code). Despite bounce-checking, another strategy that exploits processor weakness involves simply bypassing the bounce checking "supervisor" routine itself. This kind of exploit is very often used in bypassing copy protection systems. As it is announced, the strategy of stealing supervisor routines is not unique in the world of computer security and is not a new concept at all. In fact, this exact problem has analogues in various applications and has been referenced in his book "The Republic" until Plato's time. The basic problem is that some kind of global supervisor can always be identified in any given system, and that the ultimate security or stability of the structure is trusted. This collective concept of all subsequent security functions is known as the "root-of-trust" in modern research on security systems.

더 최근에는 프로세서가 본래 읽기만 되는 명령어를 인출하는 메모리 세그멘트를 제한함으로써 수퍼바이저 루틴 공격에 대해 프로세서를 보호하려는 일부 시도가 있었다(이것은 소위 W^X 또는 "기록-XOR-실행" 방법을 포함한다). 다른 범용 컴퓨터의 메모리 스페이스를 데이터 기반 및 코드 기반 파티션으로 분할하는 개념은 소위 "하버드 아키텍쳐"의 변형체로 보여질 수 있다. 이 방법은 보호 메카니즘과 관련된 특정의 성능 페널티뿐만 아니라 메모리 활용에서의 동시 증가를 갖는다. 마지막으로, 최근에는 이러한 종류의 방어조차도 소위 "복귀 기반(return-based)" 프로그래밍 익스플로잇의 사용에 의해 또는 단순한 메모리 앨리어싱 익스플로잇에 의해 교묘히 피할 수 있는 것으로 또한 보여지고, 2개의 별도의 실행 스레드는 다른 모드에 있는 동일한 메모리 블록(예를 들면, 하나는 "데이터 모드"에 있고 다른 하나는 "실행 모드"에 있는 것)을 참조할 수 있다.More recently, there have been some attempts to protect the processor against supervisor routine attacks by limiting the memory segments from which the processor originally fetches only read instructions (this includes the so-called W ^ X or "write-XOR-execute" methods). The concept of dividing the memory space of other general-purpose computers into data-based and code-based partitions can be seen as a variant of the so-called "Harvard Architecture". This method has a simultaneous increase in memory utilization as well as certain performance penalties associated with the protection mechanism. Finally, it has also recently been shown that even this kind of defense can be circumvented by the use of so-called "return-based" programming exploits or by simple memory aliasing exploits, and two separate execution threads It may refer to the same memory block in mode (eg, one in "data mode" and the other in "execution mode").

프로세서의 실행 스레드가 강탈되는 것으로부터 보호하는 다른 제안된 수단은 암호화 코드 블록의 사용을 포함한다. 이 방법에서, 실행되는 코드 세그멘트는 미리 암호화되고, 따라서 프로세서에 로딩되기 전에는 판독할 수 없다(아마도 더 중요한 것은 변경할 수 없다는 것이다). 이 방법은 또한 몇 가지 약점을 갖는다. 첫째로, 코드 세그멘트 자체는 보호될 수 있지만, 아규멘트에는 반드시 동일 수준의 보안이 제공되지 않는다. 따라서, 완전히 적법하고 안전한 코드 세그멘트는 그럼에도 불구하고 코드 세그멘트가 예기치 않은 형태로 행동하게 할 수 있는 호출 루틴으로부터 가짜 아규멘트가 제공될 수 있다. 둘째로, 일부 경우에, 실행 스레드는 전술한 복귀 기반 프로그래밍 공격에 대하여 반드시 보호되지 않는다. 또한, 프로세서 버스가 공격자에게 쉽게 관찰될 수 있는 경우에는 올바르게 실행된(암호화되었다 하더라도) 코드 세그멘트의 장기 관찰 및 실행가능 스트림에 주입된 부적절하게 암호화된 코드 세그멘트에 의해 야기되는 실행 오류의 관찰이 수정된 사전 공격(dictionary attack) 방법을 이용하여 암호화 키의 누설을 도울 수 있다. 마지막으로, 이러한 시스템에서의 프로세서 성능은 유사하지만 암호화되지 않은 코드 시스템을 통해 반드시 심각하게 감퇴된다. 이러한 성능 페널티는 많은 이슈에 의해 야기될 수 있는데, 그 중 가장 중요한 것은 코드 블록이 메모리로부터 인출될 때와 코드 블록이 실행 가능으로 될 때 사이에 코드 블록의 필수적인 복호에 의해 초래되는 대기시간(latency)이다. 비록 대부분의 현대 프로세서가 (각종 수단에 의해) 병렬로 실행될 수 있는 명령어의 수를 증가시키기 위해 파이프라인 메카니즘을 이용하지만, 암호화 코드의 블록은 먼저 복호되기 전에 파이프라인에 읽어들일 수 없다. 코드가 빈번하게 분기하는 경우에는 복호 처리가 하드웨어 조력 복호를 이용하는 경우에도 코드 실행 자체보다 훨씬 더 오래 걸릴 수 있다.Another proposed means of protecting the processor's execution thread from being robbed includes the use of cryptographic code blocks. In this way, the code segment that is executed is pre-encrypted, and therefore cannot be read (perhaps more importantly, it cannot be read) before it is loaded into the processor. This method also has some drawbacks. First, the code segment itself can be protected, but the arguments do not necessarily provide the same level of security. Thus, fully legitimate and secure code segments may nevertheless be provided with bogus arguments from a calling routine that can cause the code segment to behave in unexpected ways. Second, in some cases, execution threads are not necessarily protected against the return based programming attacks described above. Also, if the processor bus can be easily observed by an attacker, long-term observation of correctly executed code segments (even if encrypted) and execution errors caused by improperly encrypted code segments injected into the executable stream are fixed. A dictionary attack method can be used to help leak encryption keys. Finally, processor performance in such systems is necessarily severely degraded through similar but unencrypted code systems. This performance penalty can be caused by a number of issues, the most important of which is the latency caused by the required decoding of the code block between when it is fetched from memory and when the code block becomes executable. )to be. Although most modern processors use pipeline mechanisms to increase the number of instructions that can be executed in parallel (by various means), blocks of cryptographic code cannot be read into the pipeline before they are first decoded. If the code branches frequently, the decoding process may take much longer than the code execution itself, even if hardware assisted decoding is used.

본 발명에 따른 시스템 및 방법의 실시예는 비암호화 코드 블록의 활용을 가능하게 하고, 그래서 암호화 실행가능과 관련된 성능 페널티가 더 적은 이슈로 된다. 그러나, 실행 효율이 실질적인 관심사가 아닌 경우에는 암호화 코드 블록이 여전히 활용될 수 있다. 따라서, 여기에서 설명하는 실시예는 평문 실행가능의 효율뿐만 아니라 동일하거나 유사한 방법 및 시스템을 활용한 암호화 코드 세그멘트의 추가된 보안성을 둘 다 가질 수 있다. 또한, 여기에서 설명하는 보안 시스템 및 방법의 실시예는 새로 발견된 보안 관심사를 취급하기 위해서 및 실시예가 이미 전개된 후에 새로운 기능을 추가하기 위해서 원위치(in-situ)로 갱신될 수 있다.Embodiments of the system and method according to the present invention enable the utilization of non-encrypted code blocks, which results in a lesser performance penalty associated with cryptographic feasibility. However, if execution efficiency is not a real concern, encryption code blocks may still be utilized. Thus, embodiments described herein may have both the efficiency of plain text executables as well as the added security of encrypted code segments utilizing the same or similar methods and systems. In addition, embodiments of the security systems and methods described herein may be updated in-situ to address newly discovered security concerns and to add new functionality after embodiments have already been deployed.

본 발명의 실시예는 암호적 해싱 함수에 의한 실행 전에 "보안 코드 세그멘트"가 유효화되는 것을 보장함으로써 상기 장점을 획득할 수 있다. 이 유효화는 예를 들면 보안 코드 세그멘트용으로 생성된 메시지 다이제스트 또는 디지털 서명을 인증함으로써 달성될 수 있다. 이러한 암호적 해싱 함수의 평가가 위에서 설명한 합성키 구조를 이용한 결과적인 메시지 다이제스트의 암호화와 함께 발생하여 디지털 서명을 형성하는 경우에는 특수 코드 블록이 특정 목표 유닛 또는 프로세서와 관련하여 유일하게 될 수 있다. 이 프로세스는 특정 실시예에서 보안 코드 블록이 합성키 기반 디지털 서명을 이용하여 특정 목표 유닛에 암호적으로 결합될 수 있다는 사실에 기초하여, "보안 코드 결합"이라고 여기에서 인용된다.Embodiments of the present invention can achieve this advantage by ensuring that the "secure code segment" is validated before execution by a cryptographic hashing function. This validation can be accomplished, for example, by authenticating the message digest or digital signature generated for the secure code segment. If such an evaluation of the cryptographic hashing occurs with the encryption of the resulting message digest using the composite key structure described above to form a digital signature, then a special code block may be unique with respect to a particular target unit or processor. This process is referred to herein as "secure code association" based on the fact that in certain embodiments a security code block can be cryptographically coupled to a particular target unit using a composite key based digital signature.

비록 이러한 해싱 함수의 실행이 리소스 없이 될 수 있지만, 이 방법의 장점은 보안 코드 세그멘트가 그 암호적 유효화를 완료하기 전에 실행 파이프라인에 도입될 수 있다는 점이다. 따라서, 해싱 함수는 (투기적 분기 실행과 유사한 방법으로) 보안 코드 세그멘트 자체의 실행과 나란하게 평가될 수 있다. 이 실시예에서, 보안 코드 세그멘트의 결과는 결과적인 메시지 다이제스트가 진정한 것으로 판정된 경우에만 활용될 수 있다. 그러나, 다른 실시예에서, 보안 코드 세그멘트의 결과가 후속 동작에서 활용될 수 있지만, 그 결과들은 프로세서가 보안 실행 모드에서 동작하는지 아닌지에 따라서 달라질 수 있다. 이 실시예는 디지털 서명의 사용을 위해 합성키의 평가에 대하여 위에서 설명한 프로세스와 실질적으로 유사하고, 도 15에 도시한 것과 같은 하드웨어를 사용함으로써 생성될 수 있다.Although the execution of such a hashing function can be done without resources, the advantage of this method is that the security code segment can be introduced into the execution pipeline before completing its cryptographic validation. Thus, the hashing function can be evaluated alongside the execution of the secure code segment itself (in a similar way to speculative branch execution). In this embodiment, the result of the security code segment can only be utilized if the resulting message digest is determined to be true. However, in other embodiments, the result of the secure code segment may be utilized in subsequent operations, but the results may vary depending on whether or not the processor is operating in secure execution mode. This embodiment is substantially similar to the process described above for the evaluation of a composite key for the use of a digital signature, and can be generated by using hardware as shown in FIG.

그러나, 암호적 유효화의 사용은 암호화 코드 세그멘트의 사용을 배제하지 않는다. 사실, 올바르게 복호된 코드(임의 유형의 암호화를 적용하기 전의 최초 상태의 보안 코드 세그멘트)의 메시지 다이제스트 또는 디지털 서명의 사용은 추가적인 수준의 보호를 제공할 수 있다. 이것은 장래의 공격자가 모조 메시지 다이제스트를 생성하기 위해 올바르게 복호된 코드 블록에 대한 선험적 지식(a-priori knowledge)을 갖고 있어야 한다는 사실에 기인한다. 따라서, 코드 세그멘트 유효화뿐만 아니라 암호화 코드 메서드가 동시에 사용될 수 있다면, 공격에 대한 더 높은 강함(robustness)을 실현할 수 있다.However, the use of cryptographic validation does not preclude the use of cryptographic code segments. In fact, the use of message digests or digital signatures of correctly decrypted codes (secure code segments in their initial state before applying any type of encryption) can provide an additional level of protection. This is due to the fact that future attackers must have a-priori knowledge of correctly decoded code blocks in order to generate a fake message digest. Thus, if encryption code methods as well as code segment validation can be used at the same time, higher robustness to attack can be realized.

그러나, 역시 실현될 수 있는 것처럼, 상기 해싱 유효화를 우회할 수 있는 몇 가지 방법이 있고, 그 중 가장 간단한 것은 해싱 함수 자체를 파괴하는 것이다. 이 전략이 특정 실시예에서는 가능하지 않다 하더라도(예를 들면, 하드웨어 해싱 함수를 활용함으로써), 적절히 유효화된 메시지 다이제스트와 함께 사기(impostor) 코드 세그멘트를 제공함으로써 상기 실시예의 보안성을 공격하는 것이 여전히 가능하다. 많은 메시지 다이제스트가 실제로 암호화되어 디지털 서명을 형성하기 때문에, 외관상으로 이 공격 전략은 어려워보인다. 그러나, 디지털 서명 메카니즘조차도 디지털 서명의 공개키 조사 부분을 눈속임하고 그에 따라서 사기 디지털 서명의 인위적인 유효화를 제공함으로써, 또는 대안적으로 서명 유효화 루틴 자체의 악의적인 파괴에 의해 잠재적으로 공격받을 수 있다.However, as can also be realized, there are several ways to bypass the hashing validation, the simplest of which is to destroy the hashing function itself. Although this strategy is not possible in certain embodiments (for example, by utilizing hardware hashing functions), it is still possible to attack the security of this embodiment by providing an impostor code segment with a properly validated message digest. It is possible. Apparently this attack strategy seems difficult because many message digests are actually encrypted to form digital signatures. However, even a digital signature mechanism can be potentially attacked by cheating the public key investigation portion of the digital signature and thus providing artificial validation of a fraudulent digital signature, or alternatively by malicious destruction of the signature validation routine itself.

이러한 제한은 보안 코드 세그멘트와 관련된 메시지 다이제스트를 이중 암호화, 즉 한번은 (총체적인) "창조자"의 비밀키를 이용해서 암호화하고 그 다음에 엔드포인트 "제조자"(실제로 최초의 칩 제조자는 아닐지라도 2차 레벨 분배자, 시스템 통합자, 서비스 공급자 등일 수 있음) 및 당해 코드 세그멘트가 실행되는 특수 엔드포인트 장치에만 공지된 비밀키를 이용하여 다시 암호화함으로써, 여기에서 설명하는 시스템 및 방법의 실시예로 극복된다. 이 실시예의 장점은 상기 디지털 서명이 유사한 엔드포인트 장치들 간에 공유된다 하더라도 상이한 목표 유닛의 비밀키가 서로 다르기 때문에 의도된 목표 유닛에서 올바르게 기능한다는 점이다. 따라서, 임의의 이러한 디지털 서명은 명문으로 전송 및 저장될 수 있다.This restriction double-encrypts the message digest associated with the security code segment, that is, once encrypted with the (general) "creator" private key, and then the endpoint "manufacturer" (which is not actually the first chip manufacturer, at the second level). (Which may be distributors, system integrators, service providers, etc.) and the private key known only to the particular endpoint device on which the code segment is executed, thereby overcoming the embodiments of the systems and methods described herein. The advantage of this embodiment is that even though the digital signature is shared between similar endpoint devices, it functions correctly at the intended target unit because the secret keys of the different target units are different. Thus, any such digital signature may be transmitted and stored in the clear.

비밀을 이중으로 암호화하는 기술의 실시예(이것은 소위 "층을 이룬 키(layered key)" 시스템에서뿐만 아니라 회귀형 보안 시스템에서 사용될 수 있다)는 만일 올바르게 사용되지 않는 경우 특정의 이슈를 가질 수 있다. 첫째로, 만일 상기 층을 이룬 암호화 처리의 중간 결과가 인터셉트되면, 이 중간키는 임의의 또는 모든 시스템에서 더 높은 수준의 보안을 우회하도록 사용될 수 있다. 또한, 층을 이룬 시스템의 "최저층"에서 상기 중간 결과는 실제로 "글로벌" 복호키이고, 이 복호키는, 만일 발견되면, 모든 실질적으로 유사한 엔드포인트 장치용의 전체 보안 시스템을 우회하도록 사용될 수 있다. 이러한 종류의 "인터셉트" 공격은 복호 처리중에 임의의 메모리 트랜잭션을 단순히 주시하고 그 다음에 잠재적인 글로벌 복호키의 모든 메모리 위치를 시험함으로써 1회 이상 발생된다. 복호 처리 중에 모든 메모리 액세스를 주시하는 처리는 먼저 귀찮아 보일 수 있지만, 이것은 비밀키의 가치에 대한 무차별적 추측(brute-force guessing)보다 거의 확실히 더 효율적인 공격 전략이다. 층을 이룬 키 시스템의 제2의 잠재적 약점은 재전송 공격(replay attack)의 변형체에 의해 이용될 수 있다. 층을 이룬 시스템의 보안이 절충되고 그 키가 갱신되어야 하는 경우에, 오래된 (절충된) 키는 만일 최초 시스템이 그 이전 상태로 다시 리세트되거나 그 이전 상태가 사기 유닛에 의해 복제(clone)되었으면 여전히 사용될 수 있다.Embodiments of the technique of double encrypting secrets (which can be used in so-called "layered key" systems as well as in recursive security systems) can have certain issues if not used correctly. First, if an intermediate result of the layered encryption process is intercepted, this intermediate key can be used to bypass the higher level of security in any or all systems. Furthermore, the intermediate result in the "lowest layer" of the layered system is actually a "global" decryption key, which, if found, can be used to bypass the entire security system for all substantially similar endpoint devices. . This kind of "intercept" attack occurs one or more times by simply watching for any memory transaction during the decryption process and then examining all the memory locations of the potential global decryption key. The process of watching for all memory accesses during the decryption process may seem cumbersome at first, but it is almost certainly a more efficient attack strategy than brute-force guessing of the value of the secret key. A second potential weakness of the layered key system can be exploited by a variant of the replay attack. In cases where the security of a layered system is compromised and the key needs to be updated, the old (negotiated) key may be reset if the original system was reset back to its previous state or if the previous state was cloned by a fraud unit. Can still be used.

이러한 약점은 "층을 이룬 키" 구조와 대조적으로 우리가 "합성키"라고 부르는 것을 이용하여 여기에서 설명하는 실시예에서 취급될 수 있다. 합성키와 층을 이룬 키의 중요한 차이점 중의 하나는 전자의 모든 세그멘트가 단일의 모노리식 패스(monolithic pass)로 평가될 수 있다는 점이다. 대조적으로, 층을 이룬 키 시스템에서는 "최외측" 층 키가 먼저 평가되고 그 다음에 최내측 키(이것은 다음 층 키를 생성하기 위한 아규멘트로서 사용되는 등으로 전체 키 스택이 관통될 때까지 계속된다)로 복귀한다. 이 시스템과 관련된 문제점은 하위 레벨의 키가 인터셉트되고 나중에 사용되어 최외측 보안층을 효과적으로 우회할 수 있다는 점이다. 따라서, 이러한 층을 이룬 키 실시예에서는 가장 중요한(이 경우에는 글로벌) 키가 사슬에서 마지막으로 생성 및 사용되는 것이고, 이때 임의의 추가적인(또는 더 최근의) 보안층은 완전히 없다.This weakness can be handled in the embodiments described herein using what we call "synthetic keys" in contrast to the "layered key" structure. One important difference between layered keys and composite keys is that all segments of the former can be evaluated in a single monolithic pass. In contrast, in a layered key system, the "outermost" layer key is evaluated first and then continues until the entire key stack is penetrated, such as the innermost key (which is used as an argument to generate the next layer key). Return to the The problem with this system is that low-level keys can be intercepted and later used to effectively bypass the outermost security layer. Thus, in this layered key embodiment, the most important (in this case global) key is the last generated and used in the chain, with no additional (or more recent) security layer completely.

이 때문에, 이러한 보안 스택을 관통하는 더 강력한 방법은 스택이 "인사이드 아웃(inside out)"으로부터 관통되도록 활용될 수 있다. 이것은 보안 사슬에 대한 가장 최근의 추가가 시퀀스에서 최초로 실행된 것이지만 사실상 보안 시스템의 최내측 층에 위치된 것임을 의미한다. 따라서, 실시예는 상기 "인사이드 아웃" 실행 순서화(ordering)를 시행하도록 사용될 수 있다. 코드 스택 관통의 이러한 특수 순서화는 단순한 반복 방법을 이용하여 달성될 수 있고, 이때 코드 루프는 먼저 현재 보안 수준을 평가하고 그 다음에 그에 따라서 분기한다. 그러나, 반복적 방법에 있어서, 보안 시스템 관통의 중간 결과는 위에서 설명한 것처럼 공격자가 적법한 보안 시스템 관통에서 다음 하위 레벨 키가 노출되기를 단순히 기다리고 그 인터셉트한 키를 시스템의 가짜 "초기" 버전을 복제하기 위해 사용하기 때문에 잠재적으로 우회될 수 있다. 따라서, 시스템 및 방법의 실시예는 이러한 "인사이드 아웃" 실행 순서화를 시행할 수 있을 뿐만 아니라 중간 결과가 악성 코드 또는 다른 잘 알려진 보안 시스템 익스플로잇에 의해 인터셉트되는 것으로부터 보호할 수 있는 것을 설명한다.Because of this, a more powerful way of penetrating such a secure stack can be utilized to allow the stack to penetrate from “inside out”. This means that the most recent addition to the security chain is the first one executed in the sequence, but in fact is located at the innermost layer of the security system. Thus, embodiments can be used to enforce the " inside out " execution ordering. This special ordering of code stack traversal can be accomplished using a simple iteration method, where the code loop first evaluates the current security level and then branches accordingly. However, in an iterative method, the intermediate consequences of a security system piercing are simply waiting for an attacker to expose the next lower level key in a legitimate security system piercing as described above and using that intercepted key to replicate a fake "early" version of the system. This could potentially be bypassed. Thus, embodiments of the systems and methods illustrate that not only can implement this “inside out” execution sequencing but also protect intermediate results from being intercepted by malicious code or other well-known security system exploits.

"인사이드 아웃" 보안 방법을 이용할 때의 다른 중요한 장점은 호출 아규멘트의 전체 시퀀스가 보안 시스템의 최내측 층(및 대부분의 최근 버전)에 보여질 수 있다는 점이다. 만일 이 "인사이드 아웃" 실행 시퀀스가 적절히 구현되면, 그 시스템에서 사용되는 올바르게 구성된 바운즈-체킹 메카니즘은 전체 호출 사슬에 대하여 가시성을 갖는다는 것을 알 수 있다. 따라서, 실시예는 시스템 인증 기능의 상당량을 일반적으로 그 기능과 관련된 임의의 추가적인 성능 페널티의 발생없이 수행하기 위한 내장(built-in) 메카니즘을 구비할 수 있다.Another important advantage of using an "inside out" security method is that the entire sequence of call arguments can be seen in the innermost layer (and most recent versions) of the security system. If this "inside out" execution sequence is implemented properly, it can be seen that the correctly configured bounce-checking mechanism used in the system has visibility over the entire call chain. Accordingly, embodiments may have a built-in mechanism for performing a substantial amount of system authentication functionality generally without incurring any additional performance penalty associated with that functionality.

따라서, 특정 실시예는 중간 키를 상위 레벨(및 그에 따라서 보안성이 약한) 보안 시스템 루틴에 노출되는 것으로부터 지키고 적절한 보안 스택 관통 방법을 보장하는 수단을 활용할 수 있다. 이것을 달성하는 한가지 방법은 회귀형 보안 구조를 이용하는 것이고, 그 일 실시예가 "디지털 저작권 제어를 위한 회귀형 보안 프로토콜의 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"이라는 명칭으로 윌리엄 브이. 옥스포트가 2003년 6월 19일에 출원한 미국 특허 출원 제10/465,274호에 개시되어 있고, 이 특허 출원은 그 후 2007년 4월 10일에 미국 특허 제7,203,844호로 특허되었으며, 모든 목적으로 인용에 의해 여기에 통합된다.Thus, certain embodiments may utilize means to protect intermediate keys from being exposed to higher level (and therefore less secure) security system routines and to ensure proper security stack traversal methods. One way to accomplish this is to use a recursive security architecture, one embodiment of which is entitled "Method and System for a Recursive Security Protocol for Digital Copyright Control." William V. Oxford is disclosed in US Patent Application No. 10 / 465,274, filed June 19, 2003, which patent was subsequently issued on April 10, 2007, US Patent No. 7,203,844, cited for all purposes. By here it is incorporated.

이러한 회귀형 보안 프로토콜의 실시예를 활용하면, 특정의 장점들이 실현될 수 있다. 첫째로, 스택 순서 관통을 "인사이드 아웃"으로부터 평가되도록 설계할 수 있다. 이것은 최근 보안 시스템 추가가 먼저 실행되고 시스템이 "중간에서 시작"될 수 없다는 것을 의미한하(예를 들면, "복귀 기반" 프로그래밍 익스플로잇에서 사용된 것처럼). 회귀형 시스템의 두번째 장점은 보안 시스템에 대한 임의 갱신의 추가가 보안 시스템 자체에서 최초의 호출 아규멘트를 변경시키지 않는다는 점이다. 따라서, 전통적인 재생 기반 공격 메카니즘을 이용하여 보안 시스템을 눈속임하기가 더 어렵다. 여기에서 설명하는 실시예가 역순서의 반복 형식으로 인라인 실행 스택을 사용하는 것이 가능하지만, 반복 메카니즘은 인터럽트를 받기 쉽고, 따라서 보안 스택의 부분 평가가 수행되는 상황을 생성하는 것이 또한 가능하다. 이것은 하나 이상의 중간 결과가 외부 관측자에 의해 인터셉트되는 것을 잠재적으로 허용한다. 여기에서의 실시예에 의해 활용될 수 있는 것처럼 회귀를 통하여 구현되는 인사이드 아웃 보안 시스템에 있어서, 중간 결과는 임의의 지점에서 다음 레벨 루틴에 아규멘트로서 통과될 수 없고, 현재 실행되고 있는 보안 시스템의 최종 결과만이 보안 시스템 스택의 다음 레벨로 통과할 수 있다.By utilizing this embodiment of the recursive security protocol, certain advantages can be realized. First, stack order penetration can be designed to be evaluated from “inside out”. This means that recent security system additions are executed first and the system cannot be "started in the middle" (as used in "return-based" programming exploits, for example). The second advantage of regression systems is that the addition of random updates to the security system does not change the original call arguments in the security system itself. Thus, it is more difficult to cheat a security system using traditional replay-based attack mechanisms. While the embodiments described herein can use an inline execution stack in a reversed iteration format, the iteration mechanism is susceptible to interruption, and thus it is also possible to create situations in which partial evaluation of the security stack is performed. This potentially allows one or more intermediate results to be intercepted by external observers. In an inside out security system implemented through regression as may be utilized by the embodiments herein, intermediate results may not be passed as arguments to the next level routine at any point, and may be Only the end result can pass to the next level of the security system stack.

합성키 구조는 특정 실시예에서 목표 유닛의 비밀키에 대한 액세스를 엄격하게 제어함으로써 부분적 평가로부터 또한 보호될 수 있다. 예를 들어서, 비밀키가 구조적으로 가시적이지 않은 액세스불능의 메모리 위치에 저장되어 있으면, 비밀키는 특수한 보안 관련 명령어 또는 기능의 일부로서만 액세스될 수 있다. 특정 실시예에서 이 기능 또는 명령어는 평범하지 않은 일방향 변환과 같이 쉽게 역으로 되지 않는 것이다. 이 방법은 모조 보안 시스템의 경우에도 비밀키의 값을 드러낼 수 없어야 한다. 결국, 비밀키를 일방향 함수의 일부로서 간접적으로 참조되게 함으로써 비밀키는 비밀키가 수학적 연산의 일부로서 그것만으로 절대 사용될 수 없지만 단독으로 또는 어떤 다른 데이터와 함께 해싱 동작의 일부로서만 사용할 수 있을 때 보호될 수 있고, 이때 해싱 함수의 결과만이 관측될 수 있다.The composite key structure may also be protected from partial evaluation by strictly controlling access to the target unit's private key in certain embodiments. For example, if a secret key is stored in an inaccessible memory location that is not structurally visible, the secret key can only be accessed as part of special security-related commands or functions. In certain embodiments this function or instruction is not easily reversed, such as an unusual one-way transformation. This method should not be able to reveal the value of the secret key even in the case of a fake security system. After all, by making a secret key indirectly referenced as part of a one-way function, the secret key can never be used by itself as part of a mathematical operation, but can be used alone or as part of a hashing operation. Can be protected, where only the result of the hashing function can be observed.

비밀키를 보호하는 추가적인 메카니즘은 특정 실시예에서 유용한 것으로 또한 입증할 수 있다. 이러한 한가지 잠재적 메카니즘은 합성키를 사용하는 것이고, 이때 목표 유닛의 비밀키는 어떤 다른 제약 또는 추가적인 오퍼랜드의 집합에 단단하게 결합된다. 이러한 2차 오퍼랜드의 예로는 별도의 비밀키, 총체적 가시성 레지스터(타임스탬프 또는 시스템 버전 번호 등), 비밀키에 액세스하는 코드의 메시지 다이제스트 등이 있다. 이러한 시스템의 실시예에서, 이 최종 예는 비밀키가 동일한 키를 사용하도록 인증된 코드의 세그멘트에 의해서만 액세스되는 것을 보장할 수 있다. 또한, 메시지 다이제스트가 암호화되어 디지털 서명을 형성하는 경우 및 상기 메시지 다이제스트를 암호화하기 위해 사용한 키가 비밀키 자체인 경우, 비밀키에 액세스하는 유일한 방법이 그 비밀키가 무엇이었는지를 이미 알고 있는 누군가에 의해 인증된 코드 세그멘트를 이용하는 것임을 보장할 수 있는 의존성의 사이클(circle of dependencies)이 생성될 수 있다.Additional mechanisms to protect the private key may also prove useful in certain embodiments. One such potential mechanism is to use a synthetic key, where the target unit's private key is tightly bound to any other constraint or set of additional operands. Examples of such secondary operands include a separate secret key, a global visibility register (such as a timestamp or system version number), and a message digest of the code that accesses the secret key. In embodiments of such a system, this final example may ensure that the private key is only accessed by a segment of code authorized to use the same key. Also, if the message digest is encrypted to form a digital signature, and if the key used to encrypt the message digest is the secret key itself, then the only way to access the secret key is by someone who already knows what the secret key was. A cycle of dependencies can be created that can be guaranteed to use authenticated code segments.

이 경우에, 합성키 구조의 사용은 목표 유닛의 비밀키 사용이 허용되기 전에 그 비밀키의 사용을 요청하는 코드 부분의 "권한(authority)"을 유효화하는 것을 허용한다. "층을 이룬 키" 구조와 "합성키" 구조 간의 차이는, 특정 실시예에서, 후자가 원자 형태로 평가되고 그 자체는 회귀 수단에 의해 달성될 수 있는 것임을 상기하자. 회귀형 구조와 대조적으로 반복 방법을 이용한 유사한 구조의 어셈블(assemble)이 시도되면, 키 평가 처리의 중간 결과를 노출시킬 위험성이 있다(따라서 비밀키를 잠재적으로 노출시킨다). 이 "노출"은 인터럽트가 발생한 때(또는 메모리 자체에서 직접) 메인 메모리에 밀어내어지는 범용 레지스터와 같은 공개적으로 이용가능한 위치에 비밀키(또는 그 원본)가 저장된 때 발생할 수 있다.In this case, the use of the composite key structure allows validating the "authority" of the portion of code that requests the use of the secret key before the target unit's use of the secret key is allowed. Recall that the difference between the "layered key" structure and the "synthetic key" structure is that, in certain embodiments, the latter can be evaluated in atomic form and itself can be achieved by regression means. In contrast to recursive structures, attempts to assemble a similar structure using an iterative method are at risk of exposing intermediate results of the key evaluation process (and thus potentially revealing secret keys). This "exposure" may occur when the secret key (or its original) is stored in a publicly available location, such as a general purpose register that is pushed into main memory when the interrupt occurs (or directly from the memory itself).

특정 실시예에서 취급될 수 있는 잠재적 보안 파괴는 보안 스택 동작이 중간 평가(mid-evaluation)에서 중단된 때 부분 결과의 보호이고, 목표 유닛 프로세서의 상태는 그 다음에 외부 관측자에 의한 시험을 위해 개방되어 있는 메인 메모리에 기록된다. 일 실시예에 있어서, 이 메모리 "노출"을 방지하기 위해, 프로세서가 보안 실행 모드에 있는 동안 힙 푸시(heap push)는 허용되지 않는다. 만일 그 조건이 시행되면, 회귀형 보안 프로토콜은 그 현재 상태를 상실하지 않고 중단될 수 없다(중간 아규멘트가 없기 때문에). 회귀형 보안 프로토콜의 실시예에 있어서, 전체 보안 프로토콜은 회귀가 종료되고 프로세서가 보안 실행 모드에서 동작할 때 관통되고, 따라서 중단이 아닌 다른 임의의 경우에 임의의 아규멘트를 힙에 밀어내는 것은 더 이상 없다. 따라서, 만일 합성키 평가가 임의의 지점에서 중단되면, 및 힙 푸시가 보안 실행 모드에서 금지되면, 보안 시스템 스택 관통은 중간 실행에서 재시작된다(즉, 계산이 처음부터 재시작하여야 한다). 따라서, 회귀형 보안 프로토콜을 이 방법으로 사용하여 임의의 중간 결과가 시스템 힙에 저장되는 것(및 따라서 인증되지 않은 관측자에게 잠재적으로 노출되는 것)을 방지할 수 있다. 물론, 특정 실시예에서, 반복적인 보안 시스템 평가 중에 힙 동작을 디스에이블하고 그러한 중단된 보안 시스템 동작이 처음부터 재시작되어야 한다는 것을 효과적으로 요구할 수 있다. 그러나, 이러한 반복적인 방법은 "복귀 기반" 프로그래밍 익스플로잇에 대한 보호를 순서정하는 "인사이드 아웃" 실행, 호출 아규멘트를 원래 함수로 변경하지 않는 방식으로 후속 보안층을 추가하는 능력, 및 중간 결과와 최종 함수 출력 결과의 격리와 같이, 회귀형 구조가 제공하는 모든 조건에 대하여 시행할 수 없다. 보안 시스템 회귀가 종료하고 프로세서가 보안 실행 모드로 진입하게 하는 메카니즘에 대해서는 뒤에서 더 자세하게 설명될 것이다.The potential security breach that can be handled in certain embodiments is the protection of the partial result when the security stack operation is interrupted in mid-evaluation, and the state of the target unit processor is then open for testing by an external observer. Is written to the main memory. In one embodiment, to prevent this memory "exposure", a heap push is not allowed while the processor is in secure execution mode. If the condition is enforced, the recursive security protocol cannot be stopped without losing its current state (because there is no intermediate argument). In an embodiment of a regressive security protocol, the entire security protocol is penetrated when regression terminates and the processor is operating in secure execution mode, thus pushing any argument to the heap in any case other than abort. Nothing is wrong. Thus, if synthetic key evaluation is interrupted at any point, and if heap push is inhibited in secure execution mode, security system stack traversal is restarted in the intermediate execution (ie, computation must restart from the beginning). Thus, a recursive security protocol can be used in this way to prevent any intermediate results from being stored in the system heap (and thus potentially exposed to unauthorized observers). Of course, in certain embodiments, it may effectively require that a heap operation be disabled during an iterative security system evaluation and that such a suspended security system operation must be restarted from the beginning. However, this iterative approach involves "inside out" execution, ordering protection for "return-based" programming exploits, the ability to add subsequent layers of security in a way that does not change the calling argument to the original function, and intermediate results and final Like isolation of function output, it cannot be enforced for all conditions provided by regression structures. The mechanism by which secure system regression terminates and causes the processor to enter secure execution mode will be described in more detail later.

회귀 종료End regression

일 실시예에 있어서, 회귀는 주어진 코드 세그멘트의 메시지 다이제스트가 코드 세그멘트 자체와 함께 공급된 것과 일치할 때 종료하도록 신호될 수 있다. 이 방법은 만일 메시지 다이제스트가 하드웨어 해싱 함수에 의해 계산되면 공격에 대하여 더 강하게 될 수 있다. 특정 실시예에서는 디지털 서명이 또한 활용될 수 있다. 디지털 서명 메카니즘은 적어도 2가지의 주요 속성, 즉 1) 코드 세그멘트가 부정하게 변경되지 않았다는 보증 및 2) 코드 세그멘트 창조자의 즉시 식별을 제공하는 잠재성을 구비하고 있다. 그러나, 이러한 디지털 서명이 공개적으로 가시성이거나 수정가능한 위치에 캐시되는 실시예의 경우에는 디지털 서명 자체가 언제든지 수정될 수 있고 따라서 반드시 진정한 것이라고 할 수 없기 때문에 추가적인 보안이 요구될 수 있다. 따라서, 이러한 유형의 실시예에서는 공개키 시스템을 이용하여 디지털 서명을 유효화할 수 있고, 또는 합성키 구조(위에서 설명함)를 이용하여 당해 코드 세그멘트가 제공된 디지털 서명이 목표 유닛의 비밀키를 소유하고 있는 어떤 당사자에 의해 생성되었음을 보증할 수 있다. 후자의 경우에, 합성키의 사용은 단일 엔드포인트에 대하여 또는 일부 엔드포인트 집합에 대하여 또한 제한될 수 있다. 게다가, 공개키 방법과 합성키 방법을 함께 활용할 수 있다. 이러한 방법으로 코드 세그멘트의 진정성 및 코드 세그멘트가 합성 디지털 서명의 수령자용으로 의도된 것을 보증할 수 있다.In one embodiment, the regression may be signaled to end when the message digest of a given code segment matches that supplied with the code segment itself. This method can be stronger against attacks if the message digest is computed by a hardware hashing function. In certain embodiments digital signatures may also be utilized. The digital signature mechanism has at least two main properties: 1) the guarantee that the code segment has not been tampered with and 2) the potential to provide instant identification of the code segment creator. However, for embodiments where such digital signatures are cached in publicly visible or modifiable locations, additional security may be required because the digital signatures themselves may be modified at any time and thus may not necessarily be true. Thus, in this type of embodiment, the digital signature can be validated using a public key system, or the digital signature provided with the corresponding code segment using the composite key structure (described above) owns the private key of the target unit. It can be guaranteed that it was created by any party that is present. In the latter case, the use of the composite key may also be restricted for a single endpoint or for some set of endpoints. In addition, the public key method and the composite key method can be used together. In this way it is possible to ensure the authenticity of the code segment and that the code segment is intended for the recipient of the composite digital signature.

특정 실시예에 있어서, 목표 유닛에서 보안 메카니즘을 유효화하는 것이 또한 요구될 수 있다. 목표 장치에서 보안 시스템의 임의의 하나의 세그멘트에 대한 하드웨어 생성 디지털 서명이 활용될 수 있지만, 보안 시스템이 회귀형인 경우에, 보안 시스템 자체가 관통될 때 별개의 디지털 서명이 실질적으로 자동으로 생성될 수 있다. 위에서 언급한 바와 같이, 회귀형 보안 프로토콜이 종료되면 전체 호출 사슬이 노출되었다. 따라서, 보안 프로토콜의 최내측(따라서 최근) 부분이 스택에 저장된 호출 아규멘트뿐만 아니라 시스템 힙에(또는 메모리의 어디에든) 저장된 다른 환경 변수를 비롯해서 그것이 호출된 전체 환경에 액세스한다. 이 내장 시스템 인증 메카니즘은 보안 프로토콜 자체의 관통과 동시에 평가되기 때문에 공격에 대하여 특히 효율적일 뿐만 아니라 강력하다.In certain embodiments, it may also be required to validate the security mechanism at the target unit. Hardware-generated digital signatures for any one segment of the security system can be utilized on the target device, but if the security system is recursive, a separate digital signature can be generated substantially automatically when the security system itself is penetrated. have. As mentioned above, when the regression security protocol terminates, the entire call chain is exposed. Thus, the innermost (and thus most recent) part of the security protocol accesses the entire environment in which it is invoked, including the call arguments stored on the stack as well as other environment variables stored on the system heap (or anywhere in memory). This embedded system authentication mechanism is not only particularly efficient against attacks, but also powerful because it is evaluated simultaneously with the penetration of the security protocol itself.

일 실시예에 있어서, 그 다음에, 보안 시스템 스택 관통의 "실행 단계" 전에 적소에 있어야 하는 조건들의 집합이 특정될 수 있다. 일 실시예에 있어서, 이 조건들은 개별적으로 요구되는 모든 보안 조건의 "교집합"이라고 표현할 수 있다. 즉, 새로운 보안 리스크가 발견된 때, 그러한 리스크를 책임지는 추가의 조건들이 쉽게 적소에 놓여질 수 있다. 이 조건들은 신조건 및 구조건의 모든 조건들이 충족될 때까지 실행이 허용되는 보안 시스템 부분은 없다는 것을 확실히 한다. 각종 보안 시스템 조건들의 이러한 "교집합"은 위에서 설명한 것처럼 합성키 구조 메카니즘을 이용함으로써 달성될 수 있다. 예를 들어서, 만일 그러한 합성키 구조의 컴포넌트들 중 하나가 부분적으로 목표 유닛의 비밀키에 기초하고 있으면, 이 비밀키는 전체 보안 시스템의 "신뢰의 근간(Roots-of-Trust)" 중의 하나로서 생각할 수 있다. 더 나아가, 만일 하드웨어 기반 타임스탬프 메카니즘이 합성키의 다른 컴포넌트들 중의 하나로서 활용되면, 시스템은 재전송 공격에 대하여 더 잘 보호될 수 있다. 다른 조건들을 시행하기 위해 특정 실시예에서 사용될 수 있는 다수의 컴포넌트들이 상기의 것 외에도 있다. 이러한 컴포넌트들은 코드가 부정하게 변경된 경우 키가 적절히 평가되는 것을 금지하기 위하여 합성키의 일부로서 코드 블록의 메시지 다이제스트의 하드웨어 기반 해시 계산을 이용하는 것을 포함한다. 일 실시예에 있어서, 다른 하나의 컴포넌트는 실행 대상 코드 블록의 호출 아규멘트의 어떤 선택된 부분집합의 디지털 서명일 수 있고, 이것은 스택 오버플로우 스타일 공격에 대하여 보호할 수 있다.In one embodiment, then a set of conditions that must be in place before the "execution phase" of penetrating the security system stack can be specified. In one embodiment, these conditions can be expressed as "intersections" of all the security conditions individually required. In other words, when new security risks are discovered, additional conditions responsible for such risks can easily be put in place. These conditions ensure that no part of the security system is allowed to run until all the conditions of the new condition and structure are met. This "intersection" of various security system conditions can be achieved by using the composite key structure mechanism as described above. For example, if one of the components of such a composite key structure is based in part on the secret key of the target unit, the secret key is one of the "roots-of-trust" of the entire security system. I can think of it. Furthermore, if a hardware based timestamp mechanism is utilized as one of the other components of the composite key, the system can be better protected against retransmission attacks. In addition to the above there are a number of components that can be used in certain embodiments to enforce other conditions. These components include using hardware-based hash calculation of the message digest of the code block as part of the composite key to prevent the key from being properly evaluated if the code is tampered with. In one embodiment, the other component can be a digital signature of any selected subset of the calling arguments of the code block to be executed, which can protect against stack overflow style attacks.

코드 세그멘트가 타임스탬프 또는 사용량 관련 제한과 같은 그 실행상의 다른 제약을 갖는 경우, 특정 실시예에서, 추가의 조건들이 합성 디지털 서명에 추가되어 상기 제약들이 또한 적절히 시행되는 것을 보장할 수 있다. 이러한 동일한 메카니즘을 이용해서, 중간 보안 토큰의 정확한 평가에 기초하여 시스템의 각 층 내에서의 적당한 코드 분기를 시행함으로써 각종 보안 스택 층을 통한 특정의 복수의 반복을 강제할 수 있다.If the code segment has other executional constraints, such as time stamps or usage-related restrictions, in certain embodiments, additional conditions may be added to the composite digital signature to ensure that the constraints are also enforced properly. Using this same mechanism, it is possible to enforce certain multiple iterations through the various security stack layers by enforcing proper code branching within each layer of the system based on accurate evaluation of the intermediate security token.

위에서 설명한 것처럼, 회귀형 보안 시스템은 모든 조건들이 보안 토큰의 평가를 시작하기 전에 적소에 있는 것을 보증하도록 요구되는 특정 실시예에서 유리하다. 인사이드 아웃 보안 스택 관통의 시행 능력 및 중간 결과의 가시도(visibility)에 대한 제한이 있는 회귀형 시스템은 따라서 최소 방해 형식으로 보안 시스템 평가에 대한 더 많은 제약을 추가하도록 요구된 때 외부 공격에 대한 향상된 강력함 및 융통성을 제공할 수 있다.As described above, a regressive security system is advantageous in certain embodiments where it is required to ensure that all conditions are in place before the evaluation of a security token begins. Regressive systems with limited enforcement of inside-out security stack traversal and visibility of intermediate results are thus improved against external attacks when required to add more constraints on security system evaluation in the least disruptive form. It can provide strength and flexibility.

여기에서, 보안 시스템 스택의 회귀형 관통은 모든 연산 흐름에 대한 회귀 형태와 반드시 동일할 필요는 없다는 것에 주목하여야 한다. 따라서, 보안 시스템의 논리 흐름 및 시스템 보안 시스템의 사용을 가능하게 하는 코드 스레드의 논리 흐름은 완전히 별개이다.Here, it should be noted that the regression traversal of the security system stack does not necessarily have to be the same as the regression form for all computational flows. Thus, the logic flow of the security system and the logic flow of the code thread enabling the use of the system security system are completely separate.

게다가, 특정 실시예에서, 특수 코드 세그멘트가 분석됨에 따라 디지털 서명이 어떻게 수정되는지를 특정하는 함수들의 집합을 포함함으로써, 디지털 서명이 어떻게 사용되는지에 관한 융통성이 증가될 수 있다. 예를 들면, 코드 세그멘트가 최초의 반복 후에 변경되지 않은 분석 처리를 통하여 디지털 서명을 통과하도록 허용되는 경우, 그 코드 세그멘트는 보안 시스템이 그 특수 코드 블록을 통하여 몇 번이나 순환하는지를 먼저 특정할 필요없이 유효화될 수 있다. 유사하게, 특수 코드 세그멘트가 조우될 때 디지털 서명이 공지의 "종자" 상태로 리세트되는 것을 특정할 수 있다. 따라서, 단일의 유일한 번호(이것은 명문으로 저장될 수 있다)를 단순히 공급함으로써, 보안 시스템의 각종 부분이 몇 번 및 어떤 순서로 관통되는지에 관한 유일한 변형체가 특정될 수 있다. 사실, 이러한 코드 유효화 처리를 이용하여 각종 유용한 기능을 구현할 수 있고, 따라서 이 기술은 보안 시스템 자체의 배타적 사용에 대하여 반드시 제한할 필요가 없다.In addition, in certain embodiments, the flexibility of how digital signatures are used may be increased by including a set of functions that specify how the digital signature is modified as the special code segment is analyzed. For example, if a code segment is allowed to pass a digital signature through an unaltered analysis process after the first iteration, the code segment does not have to first specify how many times the security system cycles through the special code block. Can be validated. Similarly, it can specify that the digital signature is reset to a known " seed " state when a special code segment is encountered. Thus, by simply supplying a single unique number (which can be stored in the clear), a unique variant of how many times and in what order the various parts of the security system are penetrated can be specified. In fact, such a code validation process can be used to implement a variety of useful functions, and thus this technique does not necessarily limit the exclusive use of the security system itself.

적당한 디지털 서명이 일반 코드(generic code)(보안 구현과 관련되거나 관련되지 않은 코드)와 함께 공급되는 경우에, 특수 코드 블록이 특정의 목표 유닛에서 실행하는 방법이 매우 특별하게 제어될 수 있다. 이것은 일반 코드를 목표 장치의 집합에 안전하게 분배하기 위해 사용될 수 있는 매우 강력한 메카니즘이다. 이 분배 방법은 예를 들면 애플리케이션에 대한 무료 또는 유료 업그레이드에 대하여 또는 소프트웨어 바이러스 및 다른 바람직하지 않은 멀웨어의 확산을 관리하기 위해 효과적으로 적용될 수 있다. 상기 후자의 실시예에서, 회귀형 보안 시스템을 이용하여 목표 장치에서의 실행 후보인 각각의 모든 코드 블록을 유효화할 수 있다. 따라서, 멀웨어 애플리케이션 또는 미리 인증되어 있는 코드 세그멘트에 대한 다형태 바이러스성 공격조차도 실행이 금지된다.In the case where a suitable digital signature is supplied with generic code (code related or not related to a security implementation), the way in which a special code block executes on a particular target unit can be very specially controlled. This is a very powerful mechanism that can be used to safely distribute generic code to a set of target devices. This distribution method can be effectively applied, for example, for free or paid upgrades to applications or to manage the spread of software viruses and other undesirable malware. In this latter embodiment, a regression security system may be used to validate each and every code block that is an execution candidate in the target device. Thus, even polymorphic viral attacks against malware applications or pre-authenticated code segments are prohibited.

하드웨어 의존성을 보안 시스템 평가에 통합하는 능력을 제공하기 위해, 특정 실시예에서, 하드웨어 구현 버전 번호가 디지털 서명 평가의 합성 컴포넌트 중의 하나로서 활용될 수 있다. 만일 하드웨어 버전 번호가 보안 시스템이 수정될 때마다 갱신되면(및 그 갱신이 안전하면), 보안 시스템은 보안 시스템이 실행하는 목표 유닛에 정합되는 것으로 보장될 수 있다. 이것은 위에서 설명한 타임스탬핑 메카니즘과 다른 것이지만, 이 둘을 합성키 평가에서 함께 사용하여 재전송 공격 시나리오 또는 다른 위배에 대하여 보호할 수 있다는 점에 주목한다.In order to provide the ability to incorporate hardware dependencies into the security system assessment, in certain embodiments, a hardware implementation version number may be utilized as one of the composite components of the digital signature assessment. If the hardware version number is updated each time the security system is modified (and the update is secure), the security system can be guaranteed to match the target unit on which the security system executes. This is different from the time stamping mechanism described above, but note that the two can be used together in synthetic key evaluation to protect against replay attack scenarios or other violations.

예를 들어서 합성키 구조의 일부로서 JTAG 서명과 같은 하드웨어 유도형 체크섬을 사용하면, 하드웨어 구현 자체가 인증될 수 있다. 이런 종류의 메카니즘은 소프트웨어 및 하드웨어가 정합 쌍(matched pair)이고 하드웨어가 믿을만한 것(즉, 부정하게 변경되지 않았다는 것)임을 보증할 수 있다. 더 나아가, 합성키 평가의 일부로서 사용되는 JTAG 서명이 직접 관찰될 수 없으면(예를 들어서, 그 상태가 외부적으로도 보여질 수 없고 구조적으로도 보여질 수 없는 스캔 사슬의 한 지점으로부터 취해진 것이면), 하드웨어 복제에 기초하여 잠재적 공격을 탑재시키는 어려움은 수 배 증가될 수 있다. 이 전략은, 예를 들어서 장치의 개별 일련 번호가 상기 스캔 사슬에 포함되어 있으면, 효과적으로 될 수 있다.For example, using hardware-derived checksums such as JTAG signatures as part of the composite key structure, the hardware implementation itself can be authenticated. This kind of mechanism can guarantee that software and hardware are matched pairs and that the hardware is reliable (ie, has not been tampered with). Furthermore, if the JTAG signature used as part of the composite key evaluation cannot be directly observed (e.g., the state is taken from a point in the scan chain that cannot be seen externally or structurally) The difficulty of loading a potential attack based on hardware replication can be increased several times. This strategy can be effective, for example, if the device's individual serial number is included in the scan chain.

여기에서, 프로세서의 시각에서, 본질적으로, 암호화 코드 블록(직접 실행될 수 없는 것)과 "구식" 코드 블록 간의 논리적 차이는 없을 수 있고, 이것은 아마도 한번에 실행되어 정확한 디지털 서명 정합을 제공할 수 있지만, 그 디지털 서명이 더 이상 유효하지 않기 때문에 더 이상 실행될 수 없다는 점에 주목하여야 한다. 이 시나리오는 예컨대 목표 장치의 타임스탬프 레지스터가 변경되었기 때문에, 또는 대안적으로 목표 장치의 하드웨어가 어떤 인증되지 않은 방식으로 수정된 경우에 발생할 수 있다.Here, from the processor's point of view, in essence, there may be no logical difference between the cryptographic code block (which cannot be executed directly) and the "old" code block, which may be executed at once to provide accurate digital signature matching, It should be noted that because the digital signature is no longer valid, it can no longer be executed. This scenario can occur, for example, because the timestamp register of the target device has changed, or alternatively if the hardware of the target device has been modified in some unauthorized manner.

따라서, 특수 코드 블록이 갱신 버전으로 교체된 경우에(비록 둘 다 잠재적으로 실행가능이라 하더라도), 일 실시예에 있어서, 이것을 달성하는 간단하지만 효과적인 방법은 당해 코드 블록의 복호 키 포인터를 구 버전의 코드 블록을 갱신 버전으로 교체하는 수단을 유도하는 새로운 포인터로 먼저 교체하고 그 다음에 목표 엔드포인트 장치의 타임스탬프 레지스터를 갱신하는 것일 수 있다. 여기에서, 갱신된 타임스탬프 레지스터 값은 오래된 값을 이용하여 생성된 이전의 모든 디지털 서명을 무효화하고, 그에 따라서 보안 시스템을 최신식으로 하기 위해서 및 오래된 디지털 서명(또는 키)을 새로운 키/디지털 서명 값 및 갱신된 기능으로 교체하기 위해 보안 시스템 전체를 개조(이상적으로는 안전한 방법으로)하는 것을 수반할 수 있다. 이것은 엔드포인트 장치의 타임스탬프 레지스터에 저장된 값에 대하여 단일 변경으로 쉽게 영향을 줄 수 있는 매우 강력한(및 잠재적으로 매우 중요한) 메카니즘이다. 이 경우에, 엔드포인트 타임스탬프 레지스터 값은 안전하지 않거나 무모한 방식으로 변경되지 않도록 주의해야 한다. 이러한 강제 갱신 시나리오의 일 실시예는 (단순히 단일 디지털 서명을 불일치하게 함으로써) 다른 직접 실행가능한 코드 블록에 암호화 층을 추가하는 것과 논리적 등가물로서 인용될 수 있다.Thus, in the case where a special code block has been replaced with an updated version (although both are potentially executable), in one embodiment, a simple but effective way to achieve this is to replace the decryption key pointer of the code block with the old version. It may be to first replace it with a new pointer that induces a means of replacing the code block with an updated version and then update the timestamp register of the target endpoint device. Here, the updated timestamp register value invalidates all previous digital signatures created using the old values, and therefore to bring the security system up to date and replace the old digital signatures (or keys) with the new key / digital signature values. And modifying the entire security system (ideally in a secure way) to replace it with updated functionality. This is a very powerful (and potentially very important) mechanism that can easily affect a single change to the value stored in the endpoint device's timestamp register. In this case, care must be taken not to change the endpoint timestamp register value in an unsafe or reckless manner. One embodiment of this forced update scenario may be cited as a logical equivalent to adding an encryption layer to another directly executable code block (by simply making a single digital signature inconsistent).

보안 모드 및 보안 코드 결합Combine security mode and security code

시스템이 전술한 구조적으로 비가시성인 비밀키 중의 하나를 활용하는 실시예에 있어서, 그러한 키를 사용하게 하는 코드는 비밀키가 절충되는 것을 금지하는 방식으로 설계되어야 한다. 위에서 언급한 바와 같이, 특수 엔드포인트 장치의 다른 적법한 코드 블록이 인증되지 않은 방식으로 사용되는 경우 그 코드 블록의 정확한 실행을 금지하는 보안 코드 결합 메카니즘을 사용할 수 있다.In embodiments in which the system utilizes one of the structurally invisible secret keys described above, the code that makes use of such a key should be designed in a manner that prevents the secret key from being compromised. As mentioned above, if another legitimate code block of a particular endpoint device is used in an unauthorized manner, a security code binding mechanism may be used that prohibits the correct execution of that code block.

일 실시예에 있어서, 이 보안 코드 결합은 특수 종류의 해싱 함수를 후보 코드 세그멘트에 적용한 결과가 그 코드 세그멘트의 실행이 허용되기 전에 그 코드 세그멘트가 제공된 특수하게 미리 결정된 메시지 다이제스트와 정합하는 필요조건에 기초를 둔다. 이 해싱 함수는 후보 코드 세그멘트가 호출된 후이지만 실행이 허용되기 전에 적용될 수 있다. 이 해싱 함수가 개시되면 후보 코드 세그멘트를 포함하는 특수 메모리 스페이스에 대한 임의의 기록이 디스에이블 또는 무시될 수 있다. 후보 코드 세그멘트가 CPU의 명령어 캐시에서와 같이 CPU 실행 유닛과 동일한 칩에 위치되어 있으면, 이것은 쉽게 구현될 수 있다. 그러나, 예를 들어서 I-캐시가 동일 칩상에 있는 하나 이상의 프로세서 간에 공유되는 멀티프로세서 시스템에서, 이것은 표면상으로 보이는 것처럼 구현하기가 간단하지 않을 수 있다. 메시지 다이제스트가 계산된 후에 코드가 수정되는 것을 금지하는 다른 잠재적인 방법은 해싱 함수가 설치된 후에 발생하는 메모리 스페이스에 대한 임의의 시도된 기록이 프로세서 인터럽트를 야기하도록 시스템을 구성하는 것이다. 위에서 설명한 것처럼, 이것은 프로세서의 보안 실행 모드를 그 디폴트 초기 "보안 아님" 모드로 리세트할 수 있다. 이러한 명령어에 대한 다른 응답은 보안 실행 스레드가 예컨대 메모리 세그멘트화 오류를 개시함으로써 에러를 가지고 종료되게 한다.In one embodiment, this secure code combination is based on the requirement that the result of applying a special kind of hashing function to the candidate code segment matches the special predetermined message digest provided by the code segment before execution of that code segment is allowed. Based. This hashing function can be applied after the candidate code segment is called but before execution is allowed. Once this hashing function is initiated, any writes to the special memory space containing candidate code segments can be disabled or ignored. This can be easily implemented if the candidate code segment is located on the same chip as the CPU execution unit, such as in the CPU's instruction cache. However, for example in a multiprocessor system in which the I-cache is shared between one or more processors on the same chip, this may not be as simple to implement as it appears on the surface. Another potential way to prohibit code from being modified after the message digest is calculated is to configure the system so that any attempted write to memory space that occurs after the hashing function is installed causes a processor interrupt. As described above, this may reset the processor's secure execution mode to its default initial "non-secure" mode. Another response to this instruction causes the secure execution thread to terminate with an error, for example by initiating a memory segmentation error.

후보 코드 세그멘트의 계산된 메시지 다이제스트가 후보 코드 세그멘트와 함께 수신된 미리 결정된 메시지 다이제스트와 일치하면, 후보 코드 세그멘트는 "보안 모드" 또는 "보안 실행 모드"라고 명명된 곳에서 실행이 허용된다. 위에서 설명한 것처럼, 보안 모드에서 동작하는 코드만이 구조적 비가시성 비밀키를 활용할 수 있다. 특수 코드 세그멘트가 보안 모드에서 동작하지 않으면, 비밀키는 디스에이블되고, 그들 중 임의의 하나에 대한 임의의 참조는 어떤 다른 값(예를 들면, 제로)으로 복귀할 것이다.If the calculated message digest of the candidate code segment matches the predetermined message digest received with the candidate code segment, then the candidate code segment is allowed to run in what is termed "secure mode" or "secure execution mode". As described above, only code running in secure mode can utilize a structured invisible secret key. If the special code segment does not operate in secure mode, the secret key is disabled and any reference to any one of them will return to some other value (eg, zero).

특정 실시예에 있어서, 후보 코드 세그멘트의 메시지 다이제스트를 계산할 때 사용한 해싱 함수는 소정의 특성을 가질 수 있다. 제1 특성은 해싱 함수가 목표 유닛의 하드웨어에서 구현되는 것이다. 이것은 이 함수가 최초 하드웨어 해싱 함수의 어떤 다른(아마도 파괴된) 버전으로 완전히 교체될 수 없다는 것을 의미한다. 이 해싱 함수는 필요할 때 최초 함수의 정제된 버전(또는 조건부 완전 교체)에 의해 보충될 수 있다는 점에 주목하여야 한다. 일 실시예에 있어서, 하드웨어 해싱 함수를 정제된 버전으로 교체하는 방법은 보안 시스템 구조의 회귀적 정의를 통하여 보안 시스템에 새로운 층을 삽입하기 위해 사용되는 위에서 설명한 절차와 실질적으로 유사하다. 그러나, 이 경우에, 비록 새로운 해싱 함수가 모든 후속하는 보안 시스템 동작의 용도로 최초 함수를 교체할 수 있다 하더라도, 이 새로운 해싱 함수 자체는 그 신뢰의 근간의 토대로서 최초의 하드웨어 해싱 함수에 여전히 의존할 수 있다는 점에 주목하여야 한다. 따라서, "조건부 완전 교체"의 용어를 사용한다. 일 실시예에 있어서, 최초의 하드웨어 기반인 신뢰의 근간은 일정하게 유지될 수 있다. 이것은 하드웨어 기반 보안 시스템을 손상시키기가 매우 어렵다는 점에서 바람직하다. 그러나, 최초 하드웨어 해싱 함수의 단점이 목표 장치가 현장에서 전개된 후에 발견되면, 그러한 단점은 호출 아규멘트를 효과적으로 제한할 수 있는 단일 애플리케이션에서 최초 해싱 함수를 이용함으로써 잠재적으로 억제될 수 있다.In a particular embodiment, the hashing function used to calculate the message digest of the candidate code segment may have certain characteristics. The first property is that the hashing function is implemented in the hardware of the target unit. This means that this function cannot be completely replaced by any other (possibly destroyed) version of the original hardware hashing function. It should be noted that this hashing function can be supplemented by a refined version (or conditional complete replacement) of the original function when needed. In one embodiment, the method of replacing the hardware hashing function with a refined version is substantially similar to the procedure described above used to insert a new layer into the security system through a recursive definition of the security system structure. However, in this case, although the new hashing function can replace the original function for the purpose of all subsequent security system operations, this new hashing function itself still depends on the original hardware hashing function as the basis of its trust. It should be noted that it can be done. Thus, the term "conditional complete replacement" is used. In one embodiment, the basis of trust, which is the original hardware base, may remain constant. This is desirable in that it is very difficult to compromise a hardware based security system. However, if the shortcomings of the original hardware hashing function are found after the target device has been deployed in the field, such a disadvantage can be potentially suppressed by using the initial hashing function in a single application that can effectively limit the calling arguments.

하드웨어 해싱 함수의 제2 특성은 해싱 함수가 그 종자 값으로서 구조적으로 비가시성인 비밀키를 이용할 수 있다는 것이다. 따라서, 동일한 입력 아규멘트가 주어진다 하더라도, 그러한 하드웨어 해싱 함수의 메시지 다이제스트 결과는 유닛마다 다를 수 있다. 이 차이는 모든 목표 유닛 각각에 대해 유일한 메시지 다이제스트를 야기할 수 있다는 점에서 이용될 수 있다. 이 특성은 디지털 서명과 개념상으로 유사하지만, 하드웨어 해싱 함수에 대한 별도의 암호화/복호 블록의 추가를 반드시 요구하는 것은 아니다. 이때, 후보 코드 세그멘트는 하드웨어 생성 메시지 다이제스트가 후보 코드 세그멘트와 함께 분배된 것과 일치하는 유닛에서만 실행하도록(적어도 보안 모드에서) 구속되기 때문에, 순환 의존성이 생성되었다. 이 순환 의존성은 그 메시지 다이제스트가 올바른 목표 유닛의 비밀키로 생성된 코드만이 실제로 동일한 비밀키를 사용할 수 있게 한다는 의미이다. 이 특성은 목표 장치에서 보안 모드로 실행이 허용된 코드 세그멘트를 예비 공격자가 생성하는 능력을 실질적으로 손상시킨다.A second property of the hardware hashing function is that the hashing function can use a structurally invisible secret key as its seed value. Thus, even if given the same input arguments, the message digest result of such a hardware hashing function may vary from unit to unit. This difference can be used in that it can cause a unique message digest for each and every target unit. This feature is conceptually similar to digital signatures, but does not necessarily require the addition of a separate encryption / decryption block to the hardware hashing function. At this point, a circular dependency has been created because the candidate code segment is constrained to run (at least in secure mode) only in units where the hardware generated message digest matches the one distributed with the candidate code segment. This circular dependency means that only code generated by the message digest with the correct target unit's private key can actually use the same private key. This property substantially compromises the ability of a prospective attacker to generate code segments that are allowed to run in secure mode on the target device.

전술한 메카니즘은 코드 세그멘트가 특수한 목표 장치에(또는 특수한 엔드포인트 장치의 집합에) "결합"될 수 있기 때문에 "보안 코드 결합"이라고 부른다. 위에서 언급한 바와 같이, 보안 코드의 실행 블록이 인터럽트된 경우에, 콘텍스트는 세이브되지 않고, 따라서 이 코드 세그멘트의 실행은 포기되거나 처음부터 재시작되어야 한다. 또한, 코드 세그멘트의 보안 모드에서의 실행이 인터럽트되면 프로세서는 더 이상 보안 모드에서 동작할 수 없고, 구조적으로 비가시성인 비밀키에 대한 임의의 액세스는 프로세서가 보안 모드로 복귀할 때까지 차단된다. 특정 실시예에서, 임의의 오프칩(off-chip) 저장 동작은 프로세서가 보안 모드에서 동작하는 동안 통제되거나 금지된다.The mechanism described above is called "secure code association" because the code segment can be "coupled" to a particular target device (or a set of special endpoint devices). As mentioned above, when the execution block of the secure code is interrupted, the context is not saved, so execution of this code segment must be abandoned or restarted from the beginning. In addition, if execution of the code segment in the secure mode is interrupted, the processor can no longer operate in the secure mode and any access to the structurally invisible secret key is blocked until the processor returns to the secure mode. In certain embodiments, any off-chip storage operation is controlled or inhibited while the processor is operating in secure mode.

전술한 바와 같이, 특정 실시예에서, 각 목표 유닛은 구조적 비가시성 비밀키의 유일한 집합을 가질 수 있다. 그러나, 다른 실시예에서, 이러한 키의 일부 부분집합은 다수의 동일한 장치에 공통일 수 있다. 따라서, 특수한 코드 세그멘트는 키들의 공통 부분집합을 가진 특수한 엔드포인트 장치 부류에 결합될 수 있고, 그러한 장치들 간에 공통으로 유지되는 구조적 비가시성 비밀키의 상기 집합을 여전히 보호한다. 따라서, 하드웨어 해싱 함수와 하나 이상의 구조적 비가시성 비밀키의 조합은 고도로 효과적이고 강한 회귀형 보안 프로토콜에 신뢰 사슬의 기초를 제공한다.As mentioned above, in certain embodiments, each target unit may have a unique set of structural invisible secret keys. However, in other embodiments, some subset of these keys may be common to many of the same devices. Thus, a special code segment can be coupled to a special endpoint device class with a common subset of keys, and still protect the set of structural invisible secret keys that are maintained in common among such devices. Thus, the combination of a hardware hashing function and one or more structural invisible secret keys provide the basis of a chain of trust in a highly effective and strong regressive security protocol.

이제, 각종 실시예의 구현 세부에 대하여 첨부 도면을 참조하면서 설명한다. 모든 예에 있어서 용어 "디지털 비트스트림"은 디지털 데이터의 포괄적 집합을 말하고, 따라서 이 용어는 디지털 콘텐트, 코드 블록 또는 디지털 데이터 집합과 상호교환적으로 사용될 수 있다. 코드 블록 용어의 경우에, 인용된 데이터는 실행가능 파일, 실행가능 스크립트 또는 의사코드의 알고리즘 설명 또는 블록을 나타내는 것으로 또한 추정할 수 있다.Embodiments of various embodiments will now be described with reference to the accompanying drawings. In all instances, the term "digital bitstream" refers to a comprehensive set of digital data, and thus the term may be used interchangeably with digital content, code blocks, or digital data sets. In the case of code block terminology, the quoted data may also be assumed to represent an algorithmic description or block of an executable file, executable script, or pseudocode.

도 3은 디지털 콘텐트의 합성키의 생성에 대한 일 실시예를 보인 도이다. 이 합성키(310)는 전술한 바와 같이 특수 엔드포인트 장치(목표 유닛)와 관련된 구조적 비가시성 비밀키일 수 있는 엔드포인트 지정 하드웨어 키(340)를 활용하는 글로벌 콘텐트 키(330)(이것은 디지털 콘텐트의 소유자 또는 창조자에 의해 제공되거나 결정될 수 있음)에 암호화 엔진(320)을 적용함으로써 생성될 수 있다. 특수 엔드포인트 및 디지털 콘텐트 둘 다에 특수한 결과적인 합성키는 합성키가 제공된 엔드포인트 장치에 전송되어 저장되고, 명문으로 저장된다.3 is a diagram illustrating an embodiment of generation of a composite key of digital content. This composite key 310 is a global content key 330 that utilizes an endpoint specific hardware key 340, which may be a structural invisible secret key associated with a special endpoint device (target unit) as described above (this is the And may be provided or determined by the owner or creator). The resulting composite key that is specific to both the special endpoint and the digital content is sent to and stored in the endpoint device provided with the composite key, and stored in a prestigious manner.

도 4a는 보안된 디지털 데이터 블록 구조의 생성에 대한 일 실시예를 보인 도이다. 이 실시예에서, 디지털 데이터 블록(410)은 암호화되지 않을 수 있지만, 디지털 서명(420)은 하나 이상의 토큰(440 또는 450)을 가진 디지털 데이터 블록으로부터 해싱 함수(430)에 의해 계산된 메시지 다이제스트를 암호화함으로써 형성된다. 상기 토큰은 비밀키 또는 타임스탬프와 같이 공개적으로 이용가능한 데이터일 수 있다. 암호화 엔진(460, 461)을 통과한 데이터를 암호화하기 위해 사용하는 방법은 동일할 수도 있고 동일하지 않을 수도 있다. 비밀키를 암호화 키 중의 하나로서 사용하는 경우에는 그 비밀키의 값을 모른 채 디지털 서명을 위조하는 것이 더 어렵다. 또한, 암호화 동작(460, 461)의 순서는 결과의 전체 보안성에 관련이 없지만, 결과적인 디지털 서명(420)은 동작의 순서가 변경되면 달라진다는 것을 아는 것도 교훈적이다.4A illustrates one embodiment for the generation of a secure digital data block structure. In this embodiment, the digital data block 410 may not be encrypted, but the digital signature 420 takes the message digest computed by the hashing function 430 from the digital data block with one or more tokens 440 or 450. Formed by encryption. The token can be publicly available data, such as a secret key or a timestamp. The method used to encrypt the data passed through the encryption engines 460 and 461 may or may not be the same. When using a secret key as one of the encryption keys, it is more difficult to forge a digital signature without knowing the value of that secret key. It is also instructive to know that the order of encryption operations 460 and 461 is not related to the overall security of the result, but that the resulting digital signature 420 will change if the order of the operations is changed.

도 4b는 보안 코드 블록 데이터 구조의 생성에 대한 다른 실시예를 보인 도이다. 이 경우에, 비밀키(470)는 디지털 데이터 블록(471)에 첨부되어 전체 메시지(480)를 형성한다. 앞에서처럼, 상기 첨부 동작이 비밀키(470)를 최초 디지털 데이터 집합(471)의 앞에 두는지 또는 뒤에 두는지는 결과적인 보안성의 강함에 반드시 관련이 있는 것은 아니지만, 최종 결과는 만일 순서가 변경되면 달라질 것이다. 보안성을 보장하기 위해, 비밀키(470)는 최초 디지털 데이터 집합(471)과 함께 공개되어서는 안된다는 점에 또한 주목한다. 그러므로, 공개된 데이터 집합은 전체 데이터 구조(480)보다는 디지털 데이터 집합(471)으로 한정될 것이다. 그 다음에, 상기 전체 데이터 구조(480)는 도 4a와 관련하여 위에서 설명한 것과 본질적으로 동일한 방법으로 해싱 함수를 통과한다. 그러나, 이 실시예에 있어서, 최종 출력(490)은 도 4a에 도시한 디지털 서명(420)의 특성들 중 많은 것을 갖지만, 암호화 엔진(460 또는 461)의 사용을 요구하지 않을 수 있다. 따라서, 이 동작의 결과(490)는 디지털 서명 등가물이라고 인용될 것이다. 이 디지털 서명 등가물(490)은 각각의 유일한 전체 데이터 구조(480)에 대하여 유일하다(해싱 함수(430)가 적절히 구성되었다는 가정하에)는 점에 주목해야 한다. 따라서, 만일 비밀키(470)가 디지털 데이터 집합(471)의 창조자 및 그 디지털 데이터 집합의 소비자(엔드포인트 장치 또는 목표 장치)에 의해서만 공유되면, 이들 두 당사자만이 동일한 올바른 디지털 서명 등가물(490)을 재생성할 수 있을 것이다. 이 경우에, 디지털 데이터 블록(471)은 그 비밀키(470)에(및 그에 따라서 목표 장치에) 결합된 것으로 생각할 수 있다.4B illustrates another embodiment of the generation of a secure code block data structure. In this case, the private key 470 is attached to the digital data block 471 to form the entire message 480. As before, whether the attachment operation places the secret key 470 in front of or behind the original digital data set 471 is not necessarily related to the resulting strength of security, but the final result will vary if the order is changed. will be. Note also that to ensure security, the secret key 470 should not be released with the original digital data set 471. Therefore, the published data set will be limited to the digital data set 471 rather than the entire data structure 480. The entire data structure 480 then passes through a hashing function in essentially the same manner as described above with respect to FIG. 4A. However, in this embodiment, the final output 490 has many of the characteristics of the digital signature 420 shown in FIG. 4A, but may not require the use of the encryption engine 460 or 461. Thus, the result 490 of this operation will be referred to as a digital signature equivalent. It should be noted that this digital signature equivalent 490 is unique for each unique overall data structure 480 (assuming that the hashing function 430 is properly configured). Thus, if the secret key 470 is shared only by the creator of the digital data set 471 and the consumer (endpoint device or target device) of the digital data set, only these two parties are the same correct digital signature equivalent 490. You will be able to recreate it. In this case, the digital data block 471 can be thought of as being coupled to its secret key 470 (and thus to the target device).

도 5a는 암호화 데이터 블록(510)을 특정의 복호 엔진 코드 블록(562)에 암호적으로 결합하고 그 다음에 그 조합(530)을 해싱 함수(540) 및 암호화 엔진(561)에 의해 계산된 디지털 서명(524)을 이용하여 특정 엔드포인트의 하드웨어 비밀키(523)에 결합하기 위해, 여기에서 설명한 바와 같은 보안 시스템이 어떻게 이용될 수 있는지에 대한 일 실시예를 보인 도이다. 이 예에서, 공개키(522)(글로벌 콘텐트 비밀키(520)로 복호 엔진 코드 블록(562)의 메시지 다이제스트(521)를 암호화함으로써 구성된 것)는 최초의 암호화 데이터 블록(510)과 함께 단일 연쇄 데이터 집합(530)으로서 공개적으로 분배된다. 결합된 메시지(530)(공개키(522)와 결합된 최초 암호화 데이터 블록(510)을 포함함)의 메시지 다이제스트로부터 디지털 서명(524)을 생성하는 동작은 적절하게 인증된 엔드포인트 장치만이 최초 암호화 데이터 블록(510)을 복호할 수 있게 하고, 이 복호 처리는 복호 엔진(562)의 미리 규정된 방법을 이용하여 달성될 수 있을 뿐이다. 암호화 엔진 사슬(560)(예를 들면, 멀티텀(multi-term) 합성 암호화 등)에 더 많은 컴포넌트를 추가함으로써 더 많은 제약이 복호 인증 절차에 쉽게 추가될 수 있다는 점에 주목한다.5A cryptographically combines an encrypted data block 510 to a particular decryption engine code block 562 and then combines the combination 530 with the digital computed by the hashing function 540 and the encryption engine 561. One example of how a security system as described herein can be used to bind to the hardware secret key 523 of a particular endpoint using signature 524. In this example, the public key 522 (configured by encrypting the message digest 521 of the decryption engine code block 562 with the global content private key 520) is a single chain with the original encrypted data block 510. It is publicly distributed as data set 530. The operation of generating a digital signature 524 from the message digest of the combined message 530 (including the original encrypted data block 510 associated with the public key 522) can only be performed by the first properly authenticated endpoint device. Decryption of the encrypted data block 510 is possible, and this decryption process can only be achieved using a predefined method of the decryption engine 562. Note that by adding more components to the encryption engine chain 560 (eg, multi-term synthetic encryption, etc.), more constraints can be easily added to the decryption authentication procedure.

도 5b는 도 5a에 도시한 실시예의 변형예를 보인 도이다. 이 실시예에서, 특수한 암호화 메시지(511)의 창조자는 명백하게 인증될 수 있지만 특정의 엔드포인트 장치에서만 그렇다. 여기에서, 최초 암호화 데이터 블록(511)은 위에서 설명한 것처럼 특정 복호 루틴(562)에 암호적으로 결합된다. 이 점에서, 복호 루틴(562)은 비대칭 암호화 엔진이고, 입력은 창조자의 비밀 개인키(525)이며, 출력은 창조자 개인키를 이용하는 경우에만 정확하게 복호된다는 것을 추가로 특정할 수 있다. 비대칭 암호화 루틴(562)의 메시지 다이제스트(527)는 디지털 서명(526)과 함께 최초 암호화 디지털 데이터(511)에 첨부되어 전체 데이터 구조(531)를 형성한다. 데이터 구조(531)는 그 다음에 엔드포인트 장치의 비밀키(523), 해싱 함수(544) 및 암호화 엔진(561)을 이용하여 특정 엔드포인트 장치에 암호적으로 결합되어 디지털 구조(528)를 형성할 수 있다. 이 실시예에 의해, 암호화 메시지(511)가 진정한 것임이 보증될 수 있고, 그 창조자는 창조자가 하드웨어 비밀키(523)를 소유하고 있다는 사실을 알게 된다. 여기에서 주목할 것은 여기에서 사용하는 용어 창조자(author)는 반드시 데이터의 창시자(originator)를 의미하는 것이 아니고, 허가자, 분배자, 또는 이러한 데이터를 분배하거나 다른 방식으로 통신하기 원하는 다른 유형의 엔티티를 또한 인용할 수 있다. 이러한 특수한 신뢰 사슬이 중요한 용도로 될 수 있는 일 예는 엔드포인트 장치의 보안 시스템이 보안 코드 블록(최초 데이터 블록(511)에 암호화 형태로 내포되어 있는 것)을 이용하여 갱신되어야 하는 경우이다.5B is a view showing a modification of the embodiment shown in FIG. 5A. In this embodiment, the creator of the special encrypted message 511 can be explicitly authenticated, but only on certain endpoint devices. Here, the original encrypted data block 511 is cryptographically coupled to a specific decryption routine 562 as described above. In this regard, the decryption routine 562 may further specify that the decryption routine 562 is an asymmetric encryption engine, the input is the creator's secret private key 525, and the output is correctly decrypted only when using the creator private key. The message digest 527 of the asymmetric encryption routine 562 is attached to the original encrypted digital data 511 along with the digital signature 526 to form the overall data structure 531. The data structure 531 is then cryptographically coupled to a specific endpoint device using the endpoint device's secret key 523, hashing function 544, and encryption engine 561 to form a digital structure 528. can do. By this embodiment, it can be assured that the encrypted message 511 is true, and the creator knows that the creator owns the hardware secret key 523. Note that the term author, as used herein, does not necessarily mean the originator of data, but may also refer to an authorizer, distributor, or other type of entity that wishes to distribute or otherwise communicate such data. You can quote. One example of where this special chain of trust can serve a critical purpose is when the security system of an endpoint device needs to be updated using a secure code block (which is originally embedded in the data block 511 in encrypted form).

도 6은 보안 코드 블록(620)의 실행을 제어하기 위해 직렬 해시 방법을 활용하는 일 실시예를 보인 도이다. 이 경우에는 2개의 독립 코드 블록(610, 620)이 있다. 이 예에서, 제1 코드 블록(보안 코드 블록(610))은 제2 코드 블록(보안 코드 블록(620))에 대한 매립(embedded) 서브루틴 호출을 포함한다. 따라서, 보안 코드 블록(610)에 대하여 해싱 함수(640)에 의해 계산된 메시지 다이제스트(630)는 보안 코드 블록(610) 내에 포함된 보안 코드 블록(620)에 대한 참조에 의존한다. 그 다음에, 이 메시지 다이제스트(630)는 보안 코드 블록(610)의 시각으로부터 2개의 보안 코드 블록을 함께 연결한다. 다음에, 메시지 다이제스트(650)는 해싱 함수(670)를 이용하여 코드 블록(620)에 대하여 구성될 수 있다. 그러나, 메시지 다이제스트(650)를 보안 코드 블록(620)뿐만 아니라 그 호출하는 부모 루틴(이 경우에는 보안 코드 블록(610)) 둘 다에 결합하기 위하여, 최초 메시지 다이제스트(630)는 해싱 함수(670)에 의해 계산된 메시지 다이제스트(650)에 대한 종자로서 사용될 수 있다. 이러한 종자 값은 여러 가지 방법으로 구현될 수 있고, 그러한 방법 중의 하나는 최초의 메시지 다이제스트(630)를 제2 디지털 데이터 집합(예를 들면, 이 경우에 보안 코드 블록(620))에 단순히 연결하여 전체 메시지(660)를 형성하는 것임을 상기하자. 그 다음에, 전체 메시지(660)는 해싱 함수(670)(이것은 해싱 함수(640)와 동일한 것일 수도 있고 또는 어떤 다른 독립 해싱 함수일 수도 있다)를 통과하여 제2 메시지 다이제스트(650)를 형성하고, 이것은 따라서 보안 코드 블록(620)뿐만 아니라 최초 메시지 다이제스트(630)(이것 자체는 2개의 보안 코드 블록(610, 620)에 의존하는 것임) 둘 다에 의존한다. 도 4b와 관련하여 위에서 설명한 바와 같이, 상기 연결된 요소들(620, 630)의 순서는 결과적인 메시지 다이제스트(650)에 중요할 수 있지만, 해싱 함수(670)의 경우에는 전체 메시지(660)를 구성하는 요소들의 순서가 해싱 함수(670)의 보안에 실질적으로 영향을 주지 않는다.6 illustrates one embodiment utilizing a serial hash method to control the execution of secure code block 620. In this case, there are two independent code blocks 610 and 620. In this example, the first code block (secure code block 610) includes an embedded subroutine call to the second code block (secure code block 620). Thus, the message digest 630 calculated by the hashing function 640 for the security code block 610 relies on a reference to the security code block 620 contained within the security code block 610. This message digest 630 then concatenates the two security code blocks together from the time of the security code block 610. Message digest 650 may then be configured for code block 620 using hashing function 670. However, in order to couple the message digest 650 to both the security code block 620 as well as its calling parent routine (in this case security code block 610), the original message digest 630 is a hashing function 670. May be used as the seed for the message digest 650 calculated by This seed value can be implemented in a number of ways, one of which simply connects the original message digest 630 to a second set of digital data (e.g., security code block 620 in this case). Recall that it forms the entire message 660. The entire message 660 then passes through a hashing function 670 (which may be the same as the hashing function 640 or any other independent hashing function) to form a second message digest 650, This thus depends not only on the security code block 620 but also on the original message digest 630 (which itself depends on the two security code blocks 610, 620). As described above with respect to FIG. 4B, the order of the concatenated elements 620, 630 may be important for the resulting message digest 650, but in the case of the hashing function 670 make up the entire message 660. The order of the elements does not substantially affect the security of the hashing function 670.

상기 제2 메시지 다이제스트(650)는 그 다음에 위에서 설명한 것과 실질적으로 유사한 방법으로 사용되어 보안 코드 블록(620)이 보안 코드 블록(610)으로부터 호출된 경우에만 정확하게 실행되는 것을 보증할 수 있다. 코드 블록(620)은 실제로 코드 블록(610)의 정확한 복제품(또는 등가 참조)일 수 있고, 이것이 회귀 시스템의 실시예를 구성한다. 동일한 코드 블록의 2개의 사례(instantiation) 간의 유일한 차이점은 보안 코드 블록 메시지 다이제스트를 형성하기 위해 코드 블록에 첨부되는 특수한 메시지 다이제스트일 것이다.The second message digest 650 may then be used in a substantially similar manner as described above to ensure that the secure code block 620 is executed correctly only when called from the secure code block 610. Code block 620 may actually be an exact duplicate (or equivalent reference) of code block 610, which constitutes an embodiment of a regression system. The only difference between two instances of the same code block would be the special message digest appended to the code block to form a secure code block message digest.

이 특수한 실시예에 있어서, 우리는 임의의 비밀키를 사용하지 않았고, 그래서 이런 종류의 구조는 여기에서 설명하는 동일한 전체 보안 시스템을 이용하는 임의의 엔드포인트 장치에서 적당한 실행 순서를 시행하는 특이성없이 사용될 수 있다는 점에 주목한다. 또한, 앞에서와 같이, 유사한 예를 구성할 수 있고, 그 경우 보안 코드 블록 중의 어느 하나(610 또는 620)의 실행은 메시지 다이제스트(630 또는 650) 대신에 합성키 기반 디지털 서명 구조 또는 그 등가물을 각각 활용함으로써 특정 엔드포인트 장치 또는 장치들의 집합에 추가로 구속된다.In this particular embodiment, we did not use any secret keys, so this kind of structure could be used without the specificity of enforcing the proper order of execution on any endpoint device using the same overall security system described herein. Note that there is. Also, as before, similar examples can be constructed, in which case the execution of either of the security code blocks 610 or 620 replaces the composite key based digital signature structure or equivalent thereof, instead of the message digest 630 or 650, respectively. Utilization in addition to the particular endpoint device or set of devices.

도 7a는 보안 코드 블록 메시지의 구성에 관한 실시예를 보인 도이다. 일 실시예에 있어서, 암호화 디지털 데이터 집합(711)은 포인터(720)에 의해 식별된 암호화 알고리즘을 이용하여 암호화되었다. 데이터 구조(730)는 디지털 데이터 집합(711)과 포인터(720)의 연결에 의해 형성된다. 데이터 구조(730)의 메시지 다이제스트(750)는 해싱 함수(740)에 의해 생성된다. 이 구성은 암호화 데이터 집합과 그 관련 복호 루틴의 암호적 결합을 가능하게 한다.7A illustrates an embodiment of a configuration of a security code block message. In one embodiment, encrypted digital data set 711 has been encrypted using an encryption algorithm identified by pointer 720. The data structure 730 is formed by the connection of the digital data set 711 and the pointer 720. The message digest 750 of the data structure 730 is generated by the hashing function 740. This configuration enables cryptographic combinations of encrypted data sets and their associated decryption routines.

제2 실시예에 있어서, 추가의 텀이 연쇄 데이터 구조(731)에 추가된다. 즉 포인터(721)가 복호키(760)에 추가된다. 이 키(760)는 반드시 이 특수 실시예에서 묘사하는 하드웨어 기반 비밀키일 필요는 없다는 점에 주목하여야 한다. 사실, 포인터(721)에 의해 지적된 키(760)는 뒤에서 도 7c와 관련하여 설명하는 바와 같이 데이터 구조 자체일 수 있다. 그렇지 않으면, 이 실시예는 위에서 설명한 실시예와 실질적으로 유사하다. 암호화 디지털 데이터 집합(711)은 최초의 비암호화 데이터 집합(710)에 대하여 동작하는 암호화 엔진(770) 및 하나 이상의 키(760)를 사용한 결과로서 생성된다. 메시지 다이제스트(751)는 연쇄 데이터 구조(731)에서 해싱 함수(741)를 이용하여 생성된다. 이 경우에, 이제 암호화 데이터 집합(711)으로부터 비암호화 데이터 집합(710)을 재생성하기 위해 사용될 수 있는 유일키(760) 및 암호화 엔진(770) 둘 다에 비암호화 데이터 집합(710)을 암호적으로 연관시키는 메카니즘이 있다. 위에서의 실시예와 같이, 추가의 텀은 주어진 엔드포인트 장치 및 그 유일한 하드웨어 비밀키(760)에서 만족되어야 하는 특수한 조건들의 집합에 전체 구조를 암호적으로 결합하기 위해 암호화 사슬에 추가될 수 있다. 디지털 데이터 집합(710, 711)의 포맷 및 암호화 상태(즉, 암호화되었는지 아닌지)는 그 세부가 포인터(720, 721)로부터 추론될 수 있기 때문에 이 처리에 관련되지 않을 수 있다는 점에 주목한다.In the second embodiment, additional terms are added to the concatenation data structure 731. That is, the pointer 721 is added to the decryption key 760. It should be noted that this key 760 need not necessarily be the hardware based secret key described in this particular embodiment. In fact, the key 760 pointed to by the pointer 721 may be the data structure itself, as described below with respect to FIG. 7C. Otherwise, this embodiment is substantially similar to the embodiment described above. Encrypted digital data set 711 is generated as a result of using cryptographic engine 770 and one or more keys 760 that operate on the first unencrypted data set 710. Message digest 751 is generated using hashing function 741 in concatenation data structure 731. In this case, encrypting the non-encrypted data set 710 to both the unique key 760 and the encryption engine 770 can now be used to regenerate the non-encrypted data set 710 from the encrypted data set 711. There is a mechanism to associate with. As with the embodiment above, additional terms may be added to the cryptographic chain to cryptographically combine the entire structure into a set of special conditions that must be satisfied at a given endpoint device and its unique hardware secret key 760. Note that the format and encryption status (ie, encrypted or not) of the digital data set 710, 711 may not be relevant to this process because the details can be inferred from the pointers 720, 721.

이것을 염두에 두고, 도 7b는 회귀형 보안 시스템에서 사용될 수 있는 범용 암호 데이터 구조의 기본 일반화 포맷의 한가지 가능한 실시예를 도시한 것이다. 이 구조의 실시예는 단순하고 강력하며, 3개의 기본 요소, 즉 일반 데이터 블록(712), 복호 포인터(720) 및 복호 키 포인터(721)의 단순한 연결 리스트로서 구현될 수 있다. 전체적인 연결 리스트는 데이터 구조(732)에 함께 묶여진다. 연결 리스트를 사용함으로써 연쇄 데이터 구조(732) 내의 요소들의 순서화는, 비록 데이터 구조의 동작 또는 평가에 영향을 줄 수 있다 하더라도, 그 기능에 관계가 없다는 것을 쉽게 알 수 있다. 일반(예를 들면, 미리 규정되지 않은) 데이터 블록 구조 및 연결 리스트 포맷을 이용하는 다른 중요한 태양은 3개의 요소(712, 720, 721)가 반드시 선형으로 또는 연속적으로 순서정해질 필요가 없다는 것이다. 따라서, 일 실시예는 전체적 데이터 구조(732)와 함께 저장되는 어떤 다른 독립적이지만 아마도 관계가 있는 데이터를 포함한 보조 데이터 구조(713)를 포함할 수 있다. 이 개념의 일 실시예는 도 7의 보조 데이터 구조(713) 내측에 있는 포인터(720)에 의해 지적된 것과 같이, 실제 복호 엔진 코드 블록(771)을 위치시키는 것이다. 다른 예는 이 보조 데이터 블록 내측에 있는 포인터(721)에 의해 특정된 실제 키 값을 저장하는 것일 수 있다.With this in mind, FIG. 7B illustrates one possible embodiment of the basic generalization format of a general cryptographic data structure that can be used in a recursive security system. Embodiments of this structure are simple and powerful and can be implemented as a simple linked list of three basic elements: a generic data block 712, a decrypt pointer 720, and a decryption key pointer 721. The entire linked list is tied together in data structure 732. By using a linked list it can be readily seen that the ordering of the elements in the concatenated data structure 732 is not related to its function, although it may affect the operation or evaluation of the data structure. Another important aspect of using a generic (eg, not predefined) data block structure and linked list format is that the three elements 712, 720, 721 do not necessarily have to be linearly or sequentially ordered. Thus, one embodiment may include an auxiliary data structure 713 including any other independent but possibly related data stored with the global data structure 732. One embodiment of this concept is to locate the actual decoding engine code block 771, as indicated by the pointer 720 inside the auxiliary data structure 713 of FIG. Another example may be storing the actual key value specified by the pointer 721 inside this auxiliary data block.

상기 2가지 경우에, 보조 데이터 블록에 포함된 실제 데이터는 도 4a, 도 4b, 도 5a, 도 5b, 도 6 및 도 7a의 실시예에서 다양하게 묘사된 메시지 다이제스트 또는 디지털 서명의 생성 과정에서 사용될 수 있다. 이 명세서 설명에서 주지된 바와 같이, 연쇄 데이터 집합에 저장된 각종 데이터 필드는 해싱 함수를 적절히 설계하면 결과적인 메시지 다이제스트(또는 디지털 서명)에 영향을 줄 수 있다.In both cases, the actual data contained in the supplementary data block may be used in the process of generating the message digest or digital signature variously depicted in the embodiments of FIGS. 4A, 4B, 5A, 5B, 6 and 7A. Can be. As is well known in the description of this specification, various data fields stored in a concatenated data set can affect the resulting message digest (or digital signature) with proper design of the hashing function.

특정 실시예에서 활용되는 키를 보호하기 위해 유사한 블록 구조가 또한 사용될 수 있다는 것이 명백하다. 도 7c는 키들만을 포함하는 보안 코드 블록(733)의 일 실시예를 도시한 것이다. 여기에서, 데이터 블록은 장치 지정 키(714, 715, 716)(또는 필요하다면 다른 것)의 리스트를 포함할 수 있다. 이 예에서, 이들 키 중 임의의 키는 암호화 엔진(771, 772)을 이용하여 각각 암호화된 엔드포인트 장치(760) 및 엔드포인트 장치 타임스탬프 레지스터(790)의 비밀키(예를 들면)를 이용하여 생성될 수 있다. 보안 시스템의 강력함의 시각에서 이러한 동작에 대해 위에서 설명한 경우처럼, 암호화 엔진(771, 772)이 별개의 것이거나 달라야 한다는 필요조건은 없고, 암호화 사슬에서 이러한 암호화 동작의 특정 수에 대한 기본적인 제한이 없으며, 이러한 동작의 순서가 결과적인 합성키에 문제가 될 수 있지만 암호화 동작에 대한 특정 순서에 대한 필요조건은 없다. 이 경우에 주지되는 다른 하나의 특징은 연쇄 키 리스트 데이터 구조(733)의 키 리스트 포인터 요소(721)가 또다른 연쇄 키 리스트 데이터 구조(734)를 지적할 수 있다는 것이다. 이들 데이터 구조는 둘 다 도 7b에 도시한 것과 동일한 범용 암호 형식을 갖기 때문에, 키 리스트 데이터 구조는 회귀적 방법으로 형성될 수 있다. 따라서, 이러한 회귀형 보안 시스템의 실시예에서 사용하는 키(733)는 보안 프로토콜의 실시예가 적용될 수 있는 임의의 다른 데이터와 동일한 구조를 이용하여 동일한 방법으로 보호될 수 있으며, 마찬가지로, 이러한 보호된 키는 여기에서 설명하는 시스템 및 방법의 실시예에 의해 보호된 다른 데이터와 같은 방법으로 엔드포인트 장치에서 또한 복호 및 인증될 수 있다.It is apparent that similar block structures may also be used to protect the keys utilized in certain embodiments. 7C illustrates one embodiment of a secure code block 733 that includes only keys. Here, the data block may include a list of device specific keys 714, 715, 716 (or others if necessary). In this example, any of these keys uses a secret key (e.g.,) of endpoint device 760 and endpoint device timestamp register 790, respectively, encrypted using cryptographic engines 771 and 772. Can be generated. There is no requirement that the cryptographic engines 771 and 772 be separate or different, as described above in terms of the strength of the security system, and there is no fundamental restriction on the specific number of such cryptographic operations in the cryptographic chain. However, the order of these operations can be a problem for the resulting composite key, but there is no requirement for a specific order for the cryptographic operations. Another feature noted in this case is that the key list pointer element 721 of the concatenated key list data structure 733 can point to another concatenated key list data structure 734. Since these data structures both have the same general cryptographic format as shown in Fig. 7B, the key list data structure can be formed in a recursive manner. Thus, the key 733 used in embodiments of such a recursive security system can be protected in the same way using the same structure as any other data to which embodiments of the security protocol can be applied, and likewise, such protected keys May also be decrypted and authenticated at the endpoint device in the same manner as other data protected by embodiments of the systems and methods described herein.

이제 도 8을 참조하면, 암호화 콘텐트를 복호하기 위해 합성키가 어떻게 활용될 수 있는지에 대한 일 실시예가 도시되어 있다. 이 복호 동작은 위에서 설명한 것처럼 "보안 모드"에서 발생할 수 있다. 여기에서, 콘텐트(810)는 합성키(830)와 함께 엔드포인트 장치에 제공되고, 이때 콘텐트는 초기에 글로벌 콘텐트 키를 이용하여 암호화된 것이다. 합성키(830)는 도 3을 참조하여 위에서 설명한 것처럼 생성될 수 있다. 따라서, 암호화 콘텐트(810)가 엔드포인트 장치에 수신된 때, 암호화 콘텐트는 관련된 합성키(830)와 함께 수신될 수 있다. 장치의 비밀키(840)가 액세스될 수 있도록 보안 모드에서 실행하면, 합성키(830)는 보안 코드 블록(860)의 내측에서 복호되어 글로벌 콘텐트 키를 산출할 수 있다. 글로벌 콘텐트 키는 그 다음에 최초 암호화 콘텐트(810)를 복호하도록 보안 코드 블록(860) 내에서 사용되어 복호 콘텐트(880)를 산출할 수 있다.Referring now to FIG. 8, one embodiment of how a composite key can be utilized to decrypt encrypted content is shown. This decryption operation can occur in "secure mode" as described above. Here, the content 810 is provided to the endpoint device with the composite key 830, where the content is initially encrypted using the global content key. The composite key 830 may be generated as described above with reference to FIG. 3. Thus, when encrypted content 810 is received at the endpoint device, the encrypted content may be received with an associated composite key 830. When executed in a secure mode such that the secret key 840 of the device can be accessed, the composite key 830 can be decrypted inside the secure code block 860 to yield a global content key. The global content key may then be used within the secure code block 860 to decrypt the original encrypted content 810 to yield the decrypted content 880.

도 9는 코드 블록이 실행 전에 특수 엔드포인트 장치에서 동작하도록 인증되는 것을 검증하기 위해 비밀키가 어떻게 활용될 수 있는지에 대한 일 실시예를 보인 도이다. 실행을 위한 후보 코드 블록(910)이 엔드포인트 장치에 제공될 수 있고, 또는 수신된(예를 들면, 도 8을 참조하여 위에서 설명한 것처럼) 암호화 디지털 콘텐트를 복호함으로써 얻어질 수 있다. 게다가, 엔드포인트 장치는 후보 코드 블록(910)에 대응하는 대응 디지털 서명(920)을 수신할 수 있다. 이 디지털 서명(920)은 엔드포인트 장치 하드웨어 지정 비밀키(930)를 이용하여 암호화된 코드 블록으로부터 (예를 들면, 이 코드 블록을 해싱함으로써) 생성된 메시지 다이제스트를 포함할 수 있다. 따라서, 후보 코드 블록(910)이 실행될 수 있는지를 검증하기 위해, 인증 동작이 보안 모드에서 구현되고, 이것에 의해 후보 코드 블록(910)이 해시되어 메시지 다이제스트(912)를 생성한다. 이 메시지 다이제스트(912)는 그 다음에 엔드포인트 장치(검증이 보안 모드에서 이루어졌기 때문에 액세스 가능함)의 엔드포인트 장치 하드웨어 지정 비밀키(930)를 이용하여 암호화되어 디지털 서명을 생성할 수 있고, 이 디지털 서명은 단계 914에서 최초 공급된 디지털 서명(920)과 비교된다. 만일 이 디지털 하드웨어 발생 디지털 서명이 후보 코드 블록(910)에 대응하는 수신 디지털 서명(920)과 일치하면, 후보 코드 블록(910)은 검증된 것으로 보아서 실행가능으로 간주할 수 있고, 그렇지 않으면 예외 에러(exception error)가 발생한다(단계 916).9 illustrates one embodiment of how a secret key can be utilized to verify that a code block is authorized to operate on a special endpoint device prior to execution. Candidate code block 910 for execution may be provided to the endpoint device, or may be obtained by decrypting the received digital content (eg, as described above with reference to FIG. 8). In addition, the endpoint device may receive a corresponding digital signature 920 corresponding to candidate code block 910. This digital signature 920 may include a message digest generated from (eg, by hashing this code block) a code block encrypted using the endpoint device hardware specific secret key 930. Thus, to verify that candidate code block 910 can be executed, an authentication operation is implemented in secure mode, whereby candidate code block 910 is hashed to generate message digest 912. This message digest 912 may then be encrypted using the endpoint device hardware-specific secret key 930 of the endpoint device (accessible because the verification was done in secure mode) to generate a digital signature. The digital signature is compared with the digital signature 920 originally supplied in step 914. If this digital hardware-generated digital signature matches the received digital signature 920 corresponding to the candidate code block 910, the candidate code block 910 may be considered executable and considered executable, otherwise an exception error (exception error) occurs (step 916).

도 10은 코드 블록이 (미리 규정된 환경하에서) 특수 엔드포인트 프로세서에서 "보안 실행" 모드로 동작하도록 어떻게 허용되는지에 대한 일 실시예를 보인 블록도이다. 이 특수 경우에, 코드 블록(1011)의 미리 계산된 디지털 서명(1030)(이것은 엔드포인트 지정 복호키라고도 불리운다)은 코드 블록의 메시지 다이제스트를 이용하여 구성되고, 인증된 목표 엔드포인트 장치의 비밀키(1040), 인증된 목표 엔드포인트 장치의 최근 타임스탬프 값(1041), 및 위에서 설명한 하나 이상 임의 갯수의 제약 조건들(이 특수 실시예에서는 도시 생략함) 중에서 하나 이상을 이용하여 암호화된다.FIG. 10 is a block diagram illustrating one embodiment of how a code block is allowed to operate in a "secure execution" mode in a special endpoint processor (under a predefined environment). In this special case, the precomputed digital signature 1030 of code block 1011 (also called an endpoint specific decryption key) is constructed using the message digest of the code block and the secret key of the authenticated target endpoint device. 1040, encrypted using one or more of the last timestamp value 1041 of the authenticated target endpoint device, and one or more of any number of constraints described above (not shown in this particular embodiment).

이 텀들 중의 임의의 하나는 텀 자체의 부분집합에 마스킹 함수를 적용함으로써 미리 조건지어질 수 있다는 점에 또한 주목해야 한다. 예를 들어서, 타임스탬프 필드의 다수의 최하위 비트가 마스크 오프되면(따라서 디지털 서명의 계산에서 고려될 수 없으면), 그 타임스탬프 값의 유효 입상(effective granularity)이 하드웨어의 어떠한 변경도 없이 코드 세그멘트마다 쉽게 제어될 수 있다. 이러한 동일한 원리는 특정 실시예에서 디지털 서명의 계산에 사용되는 임의 갯수의 텀에 적용될 수 있다.It should also be noted that any one of these terms can be preconditioned by applying a masking function to a subset of the term itself. For example, if many of the least significant bits of a timestamp field are masked off (and therefore cannot be taken into account in the calculation of a digital signature), the effective granularity of that timestamp value is code-segmented without any change in hardware. Can be easily controlled. This same principle can be applied to any number of terms used to calculate the digital signature in certain embodiments.

도 7에서 설명한 키 리스트 데이터 구조에서와 같이, 코드 블록(1011)을 내포하는 연쇄 디지털 데이터 집합(1010)은 적어도 하나의 복호 포인터(1012) 및 적어도 하나의 복호 키 또는 키 리스트 포인터(1013)를 또한 포함한다. 또한, 위에서 설명한 것처럼, 이들 중의 임의의 하나는 외부 데이터 구조(엔드포인트 지정 디지털 키 또는 디지털 서명(1030)) 또는 연쇄 데이터 집합(1010)에 전체적으로 내포된 내장 데이터 구조를 인용할 수 있다.As in the key list data structure described with reference to FIG. 7, the concatenated digital data set 1010 containing the code block 1011 may include at least one decoding pointer 1012 and at least one decoding key or key list pointer 1013. Also includes. In addition, as described above, any one of these may refer to an embedded data structure entirely contained in an external data structure (endpoint specific digital key or digital signature 1030) or concatenated data set 1010.

도 10에 도시한 실시예를 설명하기 위하여, 코드 블록(1011)은 암호화되지 않았다고 가정한다(따라서 엔드포인트 장치 목표 프로세서에서 잠재적으로 실행가능하다). 이 경우에, 복호 포인터는 사용 전에 코드 블록(1011)에 대해 요구되는 추가의 복호가 없기 때문에 무효(null)이다. 이 경우에서처럼 코드 블록이 암호화되지 않으면, 그 대응하는 복호키(포인터)(1013)는 관련 엔드포인트 또는 하드웨어 지정 디지털 서명(1030)을 지적할 수 있다. 따라서, 도 4a, 도 4b, 도 5a 및 도 5b를 참조하여 위에서 설명한 것과 같은 데이터 구조 및 방법의 실시예를 사용하여 블록 1011에 묘사된 것과 같은 비암호화 데이터 집합의 사용에 대한 매우 다양한 인증, 암호적 결합 또는 기타 제약들을 시행할 수 있다.To illustrate the embodiment shown in FIG. 10, assume that code block 1011 is not encrypted (and therefore potentially executable in the endpoint device target processor). In this case, the decoding pointer is null because there is no additional decoding required for the code block 1011 before use. If the block of code is not encrypted as in this case, its corresponding decryption key (pointer) 1013 may point to the associated endpoint or hardware-specific digital signature 1030. Thus, a wide variety of authentication, encryption, for use of an unencrypted data set as depicted in block 1011 using embodiments of data structures and methods as described above with reference to FIGS. 4A, 4B, 5A, and 5B. Combinations or other constraints may be enforced.

엔드포인트 지정 디지털 서명(또는 복호키)(1030)이 하드웨어 비밀키(1040)만을 또는 대안적으로 하드웨어 비밀키(1040)와 엔드포인트 장치 타임스탬프 레지스터(1041)만을 지적하는 경우에, 우리는 보안 시스템 관련 호출이 호출 사슬의 "바닥"에 도달하는 것 및 이 특수한 호출 사슬에서 보안 시스템의 추가적인 층에 대한 추가의 호출이 없을 것이라는 것을 결정할 수 있다. 따라서, 보안 시스템 회귀는 이 지점에서 "종료"된다. 이 회귀 종료 조건은 엔드포인트 지정 하드웨어 비밀키(1040)의 값에 대한 액세스를 선택적으로 허용 또는 거부하는 "문지기"로서, 및 하드웨어 해싱 함수 블록(1061)의 출력을 이용하는 암호 함수에 대한 입력 성분으로서만 작용하는 하드웨어 블록(1050)에 의해 검출된다. 도 10에 도시한 예에서, 하드웨어 지정 비밀키(1040) 및 하드웨어 해싱 함수 블록(1061)의 (메시지 다이제스트) 출력은 암호화 엔진(1062, 1063)에 대한 입력 아규멘트로서 사용된다.If the endpoint-specific digital signature (or decryption key) 1030 points only to the hardware secret key 1040 or alternatively only the hardware secret key 1040 and the endpoint device timestamp register 1041, we secure It can be determined that system related calls reach the "bottom" of the call chain and that there will be no further calls to additional layers of the security system in this particular call chain. Thus, security system regression is "ended" at this point. This regression termination condition is a "gatekeeper" that selectively allows or denies access to the value of the endpoint-specified hardware secret key 1040, and as an input component to the cryptographic function using the output of the hardware hashing function block 1061. Only acting by hardware block 1050 is detected. In the example shown in FIG. 10, the (message digest) output of the hardware-specific secret key 1040 and the hardware hashing function block 1061 are used as input arguments to the crypto engines 1062 and 1063.

마지막으로, 암호화 엔진(1063)의 출력(이것은 최초 연쇄 데이터 구조(1010)의 디지털 서명임)이 전에 공급된 디지털 서명(1030)의 값과 일치하면, "보안 모드 인에이블" 하드웨어 비트(1070)가 세트된다. 이 조건은 엔드포인트 하드웨어 I-캐시(1020)에 로드된 후보 코드 블록(1011)이 이제 "보안" 모드에서 실행하도록 인증되었음을 표시한다. I-캐시(1020)에 상주하는 후보 코드 블록(1011)에 물리적인 변화가 없고 I-캐시(1020) 자체에 어떠한 변화도 없다는 점에 주목한다. 이 지점에서 변경이 있는 유일한 것은 "보안 모드 인에이블" 하드웨어 비트(1070)의 값이다.Finally, if the output of the cryptographic engine 1063 (which is the digital signature of the original concatenation data structure 1010) matches the value of the digital signature 1030 supplied previously, then the "Secure Mode Enable" hardware bit 1070. Is set. This condition indicates that the candidate code block 1011 loaded in the endpoint hardware I- cache 1020 is now authorized to run in "secure" mode. Note that there is no physical change in the candidate code block 1011 residing in the I- cache 1020 and no change in the I- cache 1020 itself. The only thing that changes at this point is the value of the "Secure Mode Enable" hardware bit 1070.

도 11은 회귀형 보안 시스템에 의해 수행되는 복호 동작의 일 실시예를 보인 도이다. 이 복호 동작은 분배된 콘텐트의 복호 또는 다른 방식의 조작 및 사용하는 처리에서 사용할 보안 코드 블록을 유효화하기 위해 합성키를 사용할 수 있다. 위에서 설명한 것처럼, 엔드포인트 장치는 암호화 콘텐트(1111), 복호 엔진(1120)에 대한 포인터(1112)(또는 복호 엔진 자체) 및 엔드포인트 지정 합성키(1130)에 대한 포인터(1113)(도 9를 참조하여 위에서 설명함)를 내포한 데이터 구조(1110)를 수신한다. 보안 모드에서의 실행을 허용하기 전에, 지적된 또는 수신된 합성 복호 엔진(1140)은 인증될 것이다. 이 인증은 엔드포인트 장치에 상주하는 해싱 함수(1121)를 이용하여 합성 복호 엔진(1140) 코드 블록의 메시지 다이제스트(1122)를 계산함으로써 달성될 수 있다. 비록 이 예에서 해싱 함수(1121)가 하드웨어 블록으로서 묘사되고 있지만, 이 해싱 함수(1121)는 예를 들면 위에서 설명한 것처럼 엔드포인트 장치의 빌트인(built-in) 하드웨어 해싱 함수 대신에 사용될 수 있는 보안 소프트웨어 코드 블록일 수 있다. 그러나, 이 경우, 해싱 함수의 소프트웨어 버전은 궁극적으로 인증 또는 권한 부여 목적의 빌트인 하드웨어 해싱 함수에 여전히 의존하고, 그래서 이 경우의 종국적인 신뢰의 근간은 엔드포인트의 빌트인 하드웨어 해싱 함수 블록(1121)에 여전히 존재한다.11 is a diagram illustrating an embodiment of a decryption operation performed by a regression security system. This decryption operation may use a composite key to validate a security code block for use in decryption or other manner of manipulation and use of distributed content. As described above, the endpoint device may include encrypted content 1111, a pointer 1112 to the decryption engine 1120 (or the decryption engine itself), and a pointer 1113 to the endpoint-specific synthesized key 1130 (FIG. 9). And a data structure 1110 containing the information described above with reference to). Before allowing execution in secure mode, the noted or received synthetic decryption engine 1140 will be authenticated. This authentication can be accomplished by calculating the message digest 1122 of the synthesis decryption engine 1140 code block using a hashing function 1121 residing at the endpoint device. Although the hashing function 1121 is depicted as a hardware block in this example, this hashing function 1121 can be used instead of the built-in hardware hashing function of the endpoint device, for example, as described above. It may be a code block. However, in this case, the software version of the hashing function ultimately still depends on the built-in hardware hashing function for authentication or authorization purposes, so the root of the final trust in this case is in the built-in hardware hashing function block 1121 of the endpoint. Still exists.

이 해싱 블록(1121)에 의해 발생된 메시지 다이제스트(1122)는 그 다음에, 단계 1123에서, 복호 엔진(1140)에 대응하는 미리 계산된 메시지 다이제스트(1150)와 비교된다. 상기 미리 계산된 메시지 다이제스트(1150)는 예를 들면 안전한 방식으로 엔드포인트 장치에 제공되거나, 미리 계산되어 엔드포인트 장치 자체에 저장된다. 만일 메시지 다이제스트가 일치하면, 합성 복호 엔진(1140)은 엔드포인트 장치에서의 실행이 허용된다(단계 1125). 만일 메시지 다이제스트가 실질적으로 동일하지 않으면, 무효 코드 예외가 발생한다(단계 1126).The message digest 1122 generated by this hashing block 1121 is then compared with the precalculated message digest 1150 corresponding to the decryption engine 1140 at step 1123. The precalculated message digest 1150 may be provided to the endpoint device, for example in a secure manner, or may be precomputed and stored on the endpoint device itself. If the message digest matches, the synthesis decryption engine 1140 is allowed to run on the endpoint device (step 1125). If the message digest is not substantially the same, an invalid code exception is raised (step 1126).

그러나, 만일 메시지 다이제스트가 실질적으로 동일하면, 엔드포인트 장치의 프로세서는 이제 보안 실행 모드로 진입하여 합성 복호 엔진(1140)에 내포된 코드를 실행한다. 이 합성 복호 엔진(1140)의 제1 부분은 엔드포인트 장치의 하드웨어 지정 비밀키(1131)를 활용하여 달성되어 합성키로부터 글로벌 콘텐트 지정 키를 발생한다(단계 1132). 제2 복호 동작(1142)은 획득한 글로벌 콘텐트 지정 키를 이용하여 암호화 콘텐트(1110)로부터 복호 콘텐트(1152)를 발생하기 위해 복호 동작(1141)에 의해 발생된 중간 결과를 이용할 수 있다. 여기에서 주목할 것은 복호 엔진(1140)이 복호 알고리즘의 쌍(1141, 1142)으로서 묘사되어 있지만, 최초 암호화 데이터 집합(1110)에 적용된 보안 코드 블록(1140)의 각종 개별 컴포넌트(1141, 1142 등)의 동작의 최종 결과가 필요한 복호 콘텐트 결과(1152)를 생성하도록 임의의 더 적거나 더 많은 수의 직렬 복호 스테이지를 포함할 수 있다는 것이다. 이러한 각종 개별 복호 컴포넌트 중의 임의의 2개는 동일하거나 다른 알고리즘일 수 있다는 점에 또한 주목하여야 한다.However, if the message digests are substantially the same, the processor of the endpoint device now enters secure execution mode and executes the code contained in the synthesis decryption engine 1140. The first portion of the synthesis decryption engine 1140 is achieved utilizing the hardware-designated secret key 1131 of the endpoint device to generate a global content designation key from the synthesis key (step 1132). The second decryption operation 1142 may use the intermediate result generated by the decryption operation 1141 to generate the decrypted content 1152 from the encrypted content 1110 using the obtained global content designation key. Note that although the decryption engine 1140 is depicted as a pair of decryption algorithms 1141, 1142, the various individual components 1141, 1142, etc. of the security code block 1140 applied to the original encrypted data set 1110. The final result of the operation may include any fewer or more serial decoding stages to produce the decoded content result 1152 as needed. It should also be noted that any two of these various separate decoding components may be the same or different algorithms.

특정 실시예에 있어서, 층에 대한 추가의 보안성을 추가로 요구할 수 있고, 따라서, 일부 실시예에서, 합성키는 도 4a, 도 7c 및 도 10을 참조하여 위에서 설명한 것과 실질적으로 동일한 방법으로 엔드포인트 장치 지정 하드웨어 키 및 엔드포인트 지정 타임스탬프 값을 이용하여 미리 계산된 메시지 다이제스트로부터 형성될 수 있다.In certain embodiments, additional security may be further required for the layer, and in some embodiments, the composite key ends in substantially the same manner as described above with reference to FIGS. 4A, 7C, and 10. It can be formed from a precalculated message digest using a point device specific hardware key and an endpoint specific timestamp value.

도 12는 엔드포인트 장치에서 회귀형 보안 프로토콜을 구현하는 일 실시예를 보인 도이다. 구체적으로, 보안 코드 블록의 유효화를 위해서 및 분배된 디지털 비트스트림의 실제 복호 및/또는 다른 사용을 위해서 합성키 집합을 사용하는 일 실시예를 묘사한다. 이 실시예는 많은 점에서 도 11에 도시한 실시예와 유사하고, 따라서 실시예의 상이한 태양에 대해서만 도 12와 관련하여 설명한다. 암호화 콘텐트(1211)를 포함한 메시지(1210)는 복호 엔진(1240)에 대한 포인터(1212)(또는 복호 엔진 자체), 콘텐트 지정 합성키(1231)(도 8과 관련하여 설명한 것처럼), 및 엔드포인트 및 타임스탬프 지정 합성키(1232)와 함께 수신될 수 있다. 암호화 콘텐트(1211)는 엔드포인트 장치의 메모리에 로드될 수 있고, 복호 엔진(1240)에 대한 포인터(1212)는 메모리(예를 들면, 엔드포인트 장치의 명령어 캐시 또는 명령어 캐시의 보안된 부분)에 또한 로드될 수 있다. 그 다음에, 지적된 복호 엔진(1240)이 인증될 것이다. 이 인증은 도 11을 참조하여 설명한 것과 실질적으로 유사한 방법으로, 엔드포인트 장치에 존재하는 해싱 함수(1221)를 이용하여 암호화 엔진의 메시지 다이제스트를 계산함으로서 달성될 수 있다.12 illustrates an embodiment for implementing a regression security protocol in an endpoint device. Specifically, one embodiment depicts an embodiment of using a composite key set for validation of secure code blocks and for actual decoding and / or other use of the distributed digital bitstream. This embodiment is similar to the embodiment shown in FIG. 11 in many respects, and therefore only different aspects of the embodiment will be described with reference to FIG. 12. The message 1210 including the encrypted content 1211 includes a pointer 1212 to the decryption engine 1240 (or the decryption engine itself), the content specific synthesis key 1231 (as described in connection with FIG. 8), and the endpoint. And a timestamp specified combination key 1232. Encrypted content 1211 may be loaded into the endpoint device's memory, and pointer 1212 to decryption engine 1240 may be stored in memory (eg, the secured portion of the instruction device's instruction cache or instruction cache). It can also be loaded. The pointed decryption engine 1240 will then be authenticated. This authentication can be accomplished by computing the message digest of the crypto engine using a hashing function 1221 present in the endpoint device in a substantially similar manner as described with reference to FIG.

이 예에서, 하드웨어 발생 메시지 다이제스트는 암호화 엔진을 이용하여 암호화된다. 상기 암호화 엔진은 엔드포인트 장치에서 하드웨어 또는 소프트웨어로 구현될 수 있고, 엔드포인트 장치 하드웨어 지정 비밀키(1270) 또는 엔드포인트 장치 타임스탬프 레지스터(1260)의 값과 같이, 계산된 메시지 다이제스트 및 하나 이상의 하드웨어 지정 키 또는 레지스터에서 동작하는 하나 이상의 직렬 접속된 합성 암호화 엔진 스테이지(1224, 1225 등)를 포함한다. 발생된 결과적인 합성 디지털 서명(1226)은 복호 엔진 코드 블록(1240)에 정확히 대응하고, 따라서 특정 엔드포인트 장치에 (하나 이상의 암호화 스테이지(1224, 1225) 및 각종 비밀 또는 공개 변수 또는 상수(예를 들면 1260, 1270)를 이용하여) 암호적으로 결합될 수 있다. 위에서 설명한 바와 같이, 상기 발생된 디지털 서명은 (동일하거나 상이한 암호화 엔진을 이용해서 및 상기 합성 디지털 서명의 응용성을 추가로 제한하기 위해 다른 제약 변수 또는 상수를 이용해서) 선택적으로 추가로 암호화될 수 있다. 또한, 이 디지털 서명(1232)과 관련된 코드 블록(1240)의 응용을 단일의 유일한 엔드포인트 장치를 넘어서까지 연장하기 원하는 경우에, 예를 들면, 잠재적인 발생된 합성 디지털 서명 정합의 분야를 넓히기 위해 하나 이상의 암호화 스테이지가 선택적으로 제한될 수 있다.In this example, the hardware generated message digest is encrypted using an encryption engine. The cryptographic engine may be implemented in hardware or software on an endpoint device, and may include computed message digests and one or more hardware, such as the value of an endpoint device hardware specific secret key 1270 or an endpoint device timestamp register 1260. One or more serially connected synthetic crypto engine stages (1224, 1225, etc.) operating on a designated key or register. The resulting composite digital signature 1226 corresponds exactly to the decryption engine code block 1240 and thus corresponds to a particular endpoint device (one or more cryptographic stages 1224 and 1225 and various secret or public variables or constants (e.g., For example, 1260, 1270). As described above, the generated digital signature may optionally be further encrypted (using the same or different encryption engine and using other constraint variables or constants to further limit the applicability of the composite digital signature). have. In addition, if one wishes to extend the application of code block 1240 associated with this digital signature 1232 beyond a single unique endpoint device, for example, to broaden the field of potential generated synthetic digital signature matching. One or more cryptographic stages may optionally be limited.

발생된 합성 디지털 서명(1226)은 그 다음에, 단계 1223에서, (예를 들면, 이전 지점에서 엔드포인트 코드 허가 처리의 일부로서 허가 기관에 의해) 엔드포인트 장치에 최초로 제공된 암호화 엔진(1240)에 대응하는 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1232)과 비교된다. 이 토큰(1232)이 디지털 서명이든 키든 상관없이 데이터 구조는 동일하며, 따라서, 용어 "키"와 "디지털 서명"은 이 경우에 상호 교환적으로 사용될 수 있다는 점에 주목한다.The generated synthetic digital signature 1226 is then sent to the encryption engine 1240 first provided to the endpoint device (eg, by the authorization authority as part of the endpoint code authorization process at the previous point), at step 1223. The corresponding endpoint and timestamp specified composite digital signature 1232 are compared. Note that the data structure is the same whether this token 1232 is a digital signature or a key, so the terms "key" and "digital signature" can be used interchangeably in this case.

합성 디지털 서명(1226, 1232)이 실질적으로 동일한 경우, 엔드포인트 장치의 프로세서는 복호 엔진 코드 블록(1240)에 내포된 코드를 보안 실행 모드로 동작시키도록 허용될 수 있다. 보안 실행 모드에서 동작할 때, 복호 엔진(1240)은 엔드포인트 장치의 하드웨어 키(1270)를 사용할 수 있고, 복호 엔진(1241 또는 1242)을 이용하여 장치 지정 합성키(1231)로부터 글로벌 콘텐트 지정 키를 발생할 수 있다. 따라서, 글로벌 콘텐트 지정 키는 중간 결과일 수 있고, 따라서 캐시되거나 또는 다른 방식으로 합성 복호 엔진 코드 블록(1240)이 아닌 다른 임의의 소프트웨어 또는 하드웨어 엔티티에게 보여질 수 없다. 이 글로벌 콘텐트 지정 키는 그 다음에 복호 엔진(1243)에 의해 사용되어 최초 암호화 콘텐트(1211)로부터 최종 복호 콘텐트(1250)를 발생한다.If the composite digital signatures 1226 and 1232 are substantially the same, the processor of the endpoint device may be allowed to operate the code contained in the decryption engine code block 1240 in a secure execution mode. When operating in secure execution mode, the decryption engine 1240 can use the hardware device 1270 of the endpoint device and uses the decryption engine 1241 or 1242 to decode the global content designation key from the device specific synthesis key 1231. May occur. Thus, the global content designation key may be an intermediate result and therefore cannot be cached or otherwise shown to any software or hardware entity other than the synthetic decryption engine code block 1240. This global content designation key is then used by decryption engine 1243 to generate final decrypted content 1250 from original encrypted content 1211.

그러나, 만일 발생된 디지털 서명(1226)이 공급된 디지털 서명(1232)과 실질적으로 일치하지 않으면, 복호 엔진 코드 블록(1240)의 사용 시도가 비인증 당사자에 의해 이루어진 경우를 포함해서 불일치가 발생하는 몇 가지 가능한 이유가 있다. 그러나, 불일치에 대한 다른 가능한 이유는 복호 엔진의 소프트웨어가 갱신된 경우(및 엔드포인트의 타임스탬프 레지스터가 마찬가지로 증분되거나 다른 방식으로 변경된 경우)일 수 있다. 이 경우에, 2개의 디지털 서명은 일치하지 않을 수 있고, 암호화 엔진 코드(1240)가 (예를 들면) 자기 암호화되었는지 다른 방식으로 교체의 필요성이 있는지를 단계 1281에서 체크할 수 있다. 여기에서 설명하는 실시예는 회귀형 보안 시스템에서 효과적으로 활용될 수 있고, 따라서 많은 경우에 암호화 알고리즘(암호화 콘텐트로 지적된 것 또는 포함된 것)은 그 자신이 암호화될 수 있고 이 암호화된 암호화 알고리즘 자체가 암호화될 수 있다는 것을 상기하자. 그래서, 만일 암호화 알고리즘의 발생된 엔드포인트 및 타임스탬프 지정 합성키(1226)와 수신된 엔드포인트 및 타임스탬프 지정 합성키(1232)가 일치하지 않으면, 이것은 부정 수단(indirection) 또는 암호화의 적어도 하나 이상의 층이 활용된 경우이다.However, if the generated digital signature 1226 does not substantially match the supplied digital signature 1232, there are some inconsistencies that may occur, including when an attempt to use the decryption engine code block 1240 is made by an unauthorized party. There are two possible reasons. However, another possible reason for the mismatch can be if the software of the decryption engine is updated (and if the endpoint's timestamp register is likewise incremented or otherwise changed). In this case, the two digital signatures may not match, and at step 1281 it may be checked whether the encryption engine code 1240 is self-encrypted (eg) or if there is a need for replacement in another way. The embodiments described herein can be effectively utilized in a recursive security system, so in many cases an encryption algorithm (pointed out or included as encrypted content) can itself be encrypted and this encrypted encryption algorithm itself Recall that can be encrypted. Thus, if the generated endpoint and timestamp specified composite key 1226 and the received endpoint and timestamp specified composite key 1232 of the encryption algorithm do not match, this is at least one of indirection or encryption. This is the case when layers are utilized.

위에서 언급한 바와 같이, 특수 실행가능 코드 블록에 암호화 층을 추가하는 개념은 특수 코드 블록의 구식 버전을 그 코드 블록의 새로운 버전으로 교체하는 동작과 논리적으로 등가일 수 있다. 따라서, 복호 엔진(1240) 자체가 암호화되었는지 또는 (단계 1282에서 표시한 것처럼) 다른 방식으로 교체의 필요성이 있는지를, 그 코드 블록과 관련된 하기의 토큰, 즉 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1232), 코드 블록의 복호 포인터(도시 생략) 또는 코드 블록의 복호키 포인터(도시 생략) 중 하나 이상을 시험함으로써 결정할 수 있다. 일 예로서, 만일 코드 블록(1240)의 관련 복호 포인터가 무효값(null value)을 지적하면, 이것은 암호화 엔진(1240)이 암호화되지 않았거나 또는 다른 방식으로 구식으로 되지 않았음을 표시하고, 따라서 발생된 디지털 서명(1226)과 공급된 디지털 서명(1232)이 실질적으로 동일하지 않지만, 코드 블록을 정확한 디지털 서명을 생성할 수 있는 다른 버전으로 교체하기 위한 다른 의지(recourse)가 없기 때문에 예외 에러가 발생할 수 있다(단계 1283). 그러나, 만일 복호 엔진 코드 블록(1240)의 복호 포인터가 다른 코드 블록, 즉 다른(아마도 갱신된) 암호화 엔진(도시 생략) 또는 어떤 다른 코드 블록을 지적하면, 이 새로운 코드 블록이 로드되고 위의 인증 단계들이 다음 암호화 엔진에 적용될 수 있다(다시 말하면, 다른 하나의 회귀층이 도입될 수 있다). 이 회귀형 실행 메카니즘은 발생된 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1226)과 공급된 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1232) 간의 일치가 발생(단계 1227에서)하였다고 결정되거나 또는 일치가 없고 복호 엔진(1240) 자체가 암호화되지 않았다고 결정될 때까지 계속되고, 그 지점에서 예외 에러가 발생할 수 있다(단계 1283).As mentioned above, the concept of adding an encryption layer to a special executable code block may be logically equivalent to replacing the old version of the special code block with a new version of that code block. Thus, whether the decryption engine 1240 itself has been encrypted or otherwise needs to be replaced (as indicated in step 1282), the following tokens associated with the code block, i.e. the endpoint and timestamp specified synthetic digital signatures ( 1232), by testing one or more of a decoding block (not shown) of the code block or a decoding key pointer (not shown) of the code block. As an example, if the associated decryption pointer of code block 1240 indicates a null value, this indicates that cryptographic engine 1240 was not encrypted or otherwise outdated. The generated digital signature 1226 and supplied digital signature 1232 are not substantially the same, but there is no exception error because there is no other recourse to replace the code block with another version that can generate the correct digital signature. May occur (step 1283). However, if the decryption pointer of decryption engine code block 1240 points to another code block, that is, another (possibly updated) encryption engine (not shown) or any other code block, then this new code block is loaded and the above authentication The steps may be applied to the next encryption engine (in other words, another regression layer may be introduced). This regression execution mechanism determines that a match has occurred (at step 1227) between the generated endpoint and timestamp specified composite digital signature 1226 and the supplied endpoint and timestamp specified composite digital signature 1232, or the match is not found. And continue until it is determined that the decryption engine 1240 itself has not been encrypted, at which point an exception error may occur (step 1283).

만일 발생된 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1226)과 공급된 엔드포인트 및 타임스탬프 지정 합성 디지털 서명(1232)이 일치한다고 결정되면, 회귀가 종료되고 언운드(unwound)될 수 있다. 이것은 전체적인 회귀형 호출 사슬을 통한 초기의 순방향 통과 중에 스택에서 조우되어 세이브된 각 코드 블록의 인증 및 실행을 수반한다. 이들 코드 블록의 일부 또는 아마도 모두는 반드시 암호화 엔진 또는 복호 엔진일 필요가 없다는 것에 주목하여야 한다. 어느 경우이든, 이들 각 코드 블록은 목표 엔드포인트 장치가 보안 실행 모드에서 동작하는 동안 인증될 수 있다.If it is determined that the generated endpoint and timestamp specified composite digital signature 1226 and the supplied endpoint and timestamp specified composite digital signature 1232 match, then the regression can be terminated and unwound. This involves authenticating and executing each block of code encountered and saved on the stack during the initial forward pass through the entire recursive call chain. It should be noted that some or perhaps all of these code blocks need not necessarily be encryption engines or decryption engines. In either case, each of these code blocks can be authenticated while the target endpoint device is operating in secure execution mode.

이 실행은 회귀형 보안 시스템에 의해 수행될 수 있는 복호 동작의 일 실시예를 도시하는 도 13을 참조하여 더 잘 설명될 수 있다. 도시된 바와 같이, 엔드포인트 장치는 메시지(1310)를 수신할 수 있고, 이 메시지(1310)는 다른 무엇보다도 콘텐트 지정 합성키(1316)(도 8과 관련하여 설명함)와 함께 암호화 콘텐트(1312), 복호 엔진 데이터 구조(1320)에 대한 포인터(1313) 또는 복호 엔진 자체를 내포할 수 있으며, 최초 메시지(1310) 및 키 리스트 포인터(1314)에 매립되어 있으면 키 또는 키 리스트 데이터 구조(1318)를 지적할 수 있다. 위에서 설명한 바와 같이, 이 데이터 구조는 키 또는 키 리스트(1316) 또는 디지털 서명(1317)을 포함할 수 있다. 복호 엔진 데이터 구조(1320)는 암호화 코드 블록(1321), 암호화(또는 대안적으로 퇴화하여 교체의 필요성이 있는) 복호 코드 블록(1321)과 관련된 후속 복호 포인터(1322) 및 관련 복호 키 리스트 포인터(1323)를 내포할 수 있다. 후속 복호 포인터(1322)는 최종 복호 코드 블록 데이터 구조(1330)를 지적할 수 있고, 상기 최종 복호 코드 블록 데이터 구조는 데이터 구조(1330)의 경우에 복호 코드 블록(1331)이 암호화 형태로 있지 않은 것을 제외하면 복호 코드 블록 데이터 구조(1320)의 구조와 실질적으로 유사한 구조를 갖는다.This implementation may be better described with reference to FIG. 13, which illustrates one embodiment of a decryption operation that may be performed by a regressive security system. As shown, the endpoint device can receive the message 1310, which is encrypted content 1312 along with the content specific synthesis key 1316 (described in conjunction with FIG. 8) among other things. May contain a pointer 1313 to the decryption engine data structure 1320 or the decryption engine itself, and if embedded in the initial message 1310 and the key list pointer 1314, the key or key list data structure 1318. Can be pointed out. As described above, this data structure may include a key or key list 1316 or digital signature 1317. Decryption engine data structure 1320 may include encryption code block 1321, subsequent decryption pointers 1322 associated with encryption (or alternatively degenerate to require replacement), and associated decryption key list pointers ( 1323). Subsequent decode pointer 1322 can point to the final decode code block data structure 1330, which in the case of data structure 1330 is that the decode code block 1331 is not in encrypted form. Except that, the structure of the decoding code block data structure 1320 is substantially similar.

도 13에 도시한 실시예의 동작은 다음과 같이 설명할 수 있다. 암호화 콘텐트 데이터 구조(1310)는 내포된 암호화 콘텐트(1312)의 복호를 예상하여 엔드포인트 프로세서의 메모리 스페이스에 로드된다. 데이터 구조(1310)는 복호 포인터(1313)를 내포하기 때문에, 관련 복호 엔진 코드 블록 데이터 구조(1320)는 메모리에 위치정해지고 읽어 들여진다. 이 후속 데이터 구조(1320)가 또한 복호 포인터(1322)를 내포하기 때문에, 포인터(1322)와 관련된 복호 엔진 코드 블록 데이터 구조(1330)는 메모리에 위치정해지고 로드된다. 데이터 구조(1330)에 있어서, 이 예에서 매립 복호 포인터(1332)는 무효 포인터로 결정되고, 그래서 목표 엔드포인트 장치의 보안 시스템이 현재 복호 회귀 사슬이 종료되었다고 결정할 수 있고(예를 들면 도 10에서 설명한 것처럼), 따라서 데이터 구조(1330)의 일부로서 메모리에 막 읽어 들여진 복호 엔진(1331)은 비암호화(및 따라서 잠재적으로 실행가능한) 코드 블록을 내포할 수 있다.The operation of the embodiment shown in FIG. 13 can be described as follows. The encrypted content data structure 1310 is loaded into the memory space of the endpoint processor in anticipation of decryption of the embedded encrypted content 1312. Since the data structure 1310 contains a decoding pointer 1313, the associated decoding engine code block data structure 1320 is positioned and read into memory. Because this subsequent data structure 1320 also contains a decoding pointer 1322, the decoding engine code block data structure 1330 associated with the pointer 1322 is located and loaded into memory. In the data structure 1330, in this example the embedded decryption pointer 1332 is determined to be an invalid pointer, so that the security system of the target endpoint device may determine that the current decryption regression chain has ended (e.g. in FIG. 10). As described, the decryption engine 1331, thus just read into memory as part of the data structure 1330, may contain unencrypted (and thus potentially executable) code blocks.

디지털 콘텐트(1331)가 코드 블록이고 데이터가 아니라고 결정될 수 있기 때문에(디지털 콘텐트가 호출된 방법으로), 복호 키 리스트 포인터(1333)(데이터 구조(1330)의 일부로서 메모리에 읽어 들여진 것)에 의해 지적된 키 리스트 데이터 구조(1338)가 디지털 서명(1337)(합성키(1336)에 추가해서)을 내포하고 있다고 또한 결정될 수 있다. 이 예에서의 키 리스트 데이터 구조(1318, 1328, 1338)는 도 7b와 관련하여 위에서 설명한 범용 암호 데이터구조를 이용하여 구현될 수 있다는 점에 또한 주목하여야 한다. 따라서, 이들 키 리스트 데이터 구조(1318, 1328, 1338)에서의 아규멘트의 순서는 반드시 고정될 필요는 없고, 따라서 이들은 런타임에서 데이터 구조 자체가 관통된 것으로 해석될 수 있다. 사실, 이들 키 리스트 데이터 구조(1318, 1328, 1338)는 키 리스트 데이터 구조(1318, 1328, 1338)의 일부 또는 전부에 보충적 복호 포인터 및 키 리스트 포인터를 통합함으로써 추가의 복호 또는 후속되는 해석을 위한 참조(reference)를 포함할 수 있지만, 이러한 특수한 옵션은 간단성을 위해 도 13의 실시예에서 도시하지 않았다.Because the digital content 1331 can be determined to be a code block and not data (in the manner in which the digital content was called), by the decryption key list pointer 1333 (read into memory as part of the data structure 1330). It can also be determined that the indicated key list data structure 1338 contains a digital signature 1335 (in addition to the composite key 1336). It should also be noted that the key list data structures 1318, 1328, 1338 in this example can be implemented using the general cryptographic data structures described above with respect to FIG. 7B. Thus, the order of the arguments in these key list data structures 1318, 1328, 1338 need not necessarily be fixed, so they can be interpreted at run time as the data structure itself is penetrated. In fact, these key list data structures 1318, 1328, 1338 may be incorporated into some or all of the key list data structures 1318, 1328, 1338 for further decoding or subsequent interpretation by incorporating key decode pointers and key list pointers. Although reference may be included, this particular option is not shown in the embodiment of FIG. 13 for simplicity.

키 리스트 데이터 구조(1338) 내의 적어도 하나의 키 포인터(1336)는 엔드포인트의 하드웨어 비밀키(1392)에 대한 참조에 대응한다고 또한 결정될 수 있다. 엔드포인트의 하드웨어 비밀키(1392)에 대한 이러한 참조는 적절히 보존된 메모리 위치(프로세서에 의해 직접 판독될 수 없고 따라서 구조적으로 직접 보여지지 않더라도 프로세서 아키텍쳐에 특정될 수 있는 위치)를 지적함으로써 명시적으로, 또는 포인터에 대해 어떤 특별하게 보존된 값을 이용함으로써 암시적으로 달성될 수 있다. 어느 경우이든, 이 참조는 다양한 수단을 이용하여 구현될 수 있지만, 그러한 실시예 중의 한가지 예는 키 리스트 데이터 구조의 "0"의 값("무효"의 값과는 다른 것임)을 엔드포인트의 하드웨어 비밀키(1392)에 대한 참조와 같게 하는 것이다. 키 리스트 데이터 구조의 적어도 일부분이 엔드포인트의 하드웨어 비밀키(1392)를 인용한다는 사실은 복호 엔진 코드 블록(1331)이 목표 엔드포인트 장치의 프로세서에서 보안 실행 모드로 동작하려고 의도한다는 것을 또한 표시할 수 있다. 따라서, 하드웨어 기반 디지털 서명 발생기 블록(1390)의 출력은 데이터 구조(1337)에 저장된 값과 비교된다. 2개의 값이 실질적으로 일치하는 경우에, 프로세서는 보안 실행 모드로의 진입이 허용된다.It may also be determined that at least one key pointer 1336 in the key list data structure 1338 corresponds to a reference to the hardware secret key 1332 of the endpoint. This reference to the endpoint's hardware secret key 1392 is explicitly stated by pointing to an appropriately reserved memory location (a location that can not be read directly by the processor and therefore can be specific to the processor architecture even though it is not directly visible structurally). This can be implicitly achieved by using some specially preserved values for, or pointers. In either case, this reference can be implemented using a variety of means, but one example of such an embodiment is to compare the value of "0" (which is different from the value of "invalid") of the key list data structure to the endpoint hardware. This is equivalent to a reference to the private key 1372. The fact that at least a portion of the key list data structure references the endpoint's hardware secret key 1332 may also indicate that the decryption engine code block 1331 is intended to operate in secure execution mode on the target endpoint device's processor. have. Thus, the output of the hardware-based digital signature generator block 1390 is compared with the value stored in the data structure 1335. If the two values substantially match, the processor is allowed to enter the secure execution mode.

여기에서 주목해야 할 것은 하드웨어 기반 디지털 서명 발생기 블록(1390)(이것에 대한 일 실시예의 상세한 사항은 도 15를 참조하여 더 포괄적으로 제시될 것이다)은, 일 실시예에 있어서, 하나 이상의 소프트웨어 기반 요소를 포함할 수 있지만, 위에서 설명한 것처럼 적어도 하나의 하드웨어 기반 보안 컴포넌트를 직접적으로 또는 간접적으로 또한 포함할 수 있다. 이 하드웨어 컴포넌트는 위에서의 많은 설명에서 인용된 하드웨어 기반 해싱 함수이고, 이것은 전체 목표 엔드포인트 유닛 보안 시스템의 신뢰의 근간을 포함한다.It should be noted here that the hardware-based digital signature generator block 1390 (the details of one embodiment of this will be presented more comprehensively with reference to FIG. 15), in one embodiment, includes one or more software-based elements. But may also include, directly or indirectly, at least one hardware-based security component as described above. This hardware component is a hardware-based hashing function cited in many of the descriptions above, which includes the basis of the trust of the entire target endpoint unit security system.

이 점에서, 복호 엔진 코드 블록(1331)은 보안 실행 모드에서 동작하는 것이 허용되고, 이것은 엔드포인트 프로세서가 엔드포인트의 하드웨어 장치 지정 비밀키(1392)를 보안 관련 계산(위에서 설명됨)의 일부로서 잠재적으로 사용하는 것을 허용한다. 프로세서가 보안 실행 모드에서 동작하지 않는 경우에, 비밀키(1392)의 값은 그러한 보안 관련 계산에서 사용될 수 없다. 이 개념은 하드웨어 액세스 제어 블록(1343)으로서 도 13과 관련하여 설명되고, 이것은 프로세서가 보안 실행 모드에서 동작하는 경우 비밀키(1392)의 값만이 (예를 들면 복호 엔진 코드 블록(1331)에서) 후속 사용을 위해 통과하도록 허용할 것이다.In this regard, the decryption engine code block 1331 is allowed to operate in secure execution mode, which means that the endpoint processor may use the endpoint's hardware device specific secret key 1392 as part of the security-related calculations (described above). Allows for potential use. If the processor is not operating in secure execution mode, the value of the private key 1392 cannot be used in such security related calculations. This concept is described in connection with FIG. 13 as a hardware access control block 1343, which is the only value of the secret key 1332 (e.g., in the decryption engine code block 1331) when the processor is operating in secure execution mode. It will allow to pass for subsequent use.

또한, 하드웨어 액세스 제어 블록(1343)에 대한 입력 파라미터 중의 하나는 액세스 제어 블록(1341)의 출력임을 알 수 있다. 이 방법으로, 하드웨어 액세스 제어 블록(1343)의 상태(이것은 실제상으로는 복호 코드 블록(1321)의 "보안 실행 모드 인에이블" 표시자이다)는 복호 코드 블록(1331)이 보안 실행 모드에서 또한 동작했다는 사실에 의존한다. 이것은 복호 코드 블록(1331)의 "보안 실행 모드 인에이블" 표시자의 상태(예를 들면, 하드웨어 액세스 제어 블록(1341)의 출력)에 의해 표시될 수 있다. 이 의존성은 복호 코드 블록(1331)이 보안 실행 모드에서 동작한 경우에만 보안 실행 모드에서 동작할 수 있는 복호 엔진 코드 블록(1321)의 능력을 억제한다. 본질적으로 동일한 방법으로, 하드웨어 액세스 제어 블록(1343)의 출력은 하드웨어 액세스 제어 블록(1345)에 대한 입력들 중 하나로서 사용되고, 이것은 복호 코드 블록(1311)의 "보안 실행 모드 인에이블" 표시자이다. 따라서, "보안 실행 모드 인에이블" 비트가 전파되게 하는 메카니즘은 선행하는 부모 코드 블록이 적절히 인증된 경우(도 14를 참조하여 더 자세히 설명함) 및 선행하는 부모 코드 블록이 회귀형 호출 사슬의 하부로부터 보안 사슬의 적절히 권한이 부여된 부분으로부터의 인증 복호 결과와 함께 공급된 경우에만 선행하는 부모 코드 블록이 보안 실행 모드에서 동작하도록 권한을 부여할 할 목적으로 호출 사슬을 역방향으로 백업한다. 위에서 설명한 것처럼, 몇 가지 조건들 중 임의의 조건은 임의의 "보안 실행 모드 인에이블" 비트가 "안전하지 않은" 디폴트 상태로 리세트시킬 수 있다는 점에 주목한다(따라서, 전체 보안 사슬이 재시작될 것을 잠재적으로 요구한다). 그러한 조건은 프로세서 인터럽트 또는 후속하는 디지털 서명 비교 불일치를 포함할 수 있다. 비록 이들 하드웨어 액세스 제어 블록(1341, 1343, 1345)이 도 13에서 명확성을 위해 별도의 엔티티로 도시되어 있지만, 이들은 사실상 출력이 그 자신의 입력 텀 중의 하나로서 피드백되는 단일 하드웨어 유닛으로 (도 15와 관련하여 설명하는 바와 같이) 구체화될 수 있다는 것을 알 수 있다. 궁극적으로, 전체 사슬에서 최고 레벨 또는 최종 "보안 실행 모드 인에이블" 비트의 출력은 목표 장치의 일부 외부적으로 보여지는 출력을 (예를 들면, 오디오 또는 비디오 출력 인에이블과 같이) 인에이블 또는 디스에이블하기 위한 제어 메카즘의 일부로서 사용될 수 있다.It can also be seen that one of the input parameters for the hardware access control block 1343 is the output of the access control block 1341. In this way, the state of the hardware access control block 1343, which is actually the "secure execution mode enable" indicator of the decryption code block 1321, indicates that the decryption code block 1331 has also operated in the secure execution mode. Depends on the facts This may be indicated by the state of the “secure execution mode enable” indicator of the decryption code block 1331 (eg, the output of the hardware access control block 1341). This dependency suppresses the ability of the decryption engine code block 1321 to operate in the secure execution mode only when the decryption code block 1331 operates in the secure execution mode. In essentially the same way, the output of the hardware access control block 1343 is used as one of the inputs to the hardware access control block 1345, which is the "secure execution mode enable" indicator of the decryption code block 1311. . Therefore, the mechanism for causing the "secure execution mode enable" bit to be propagated requires that the preceding parent code block is properly authenticated (described in more detail with reference to Figure 14) and that the preceding parent code block is at the bottom of the recursive call chain. The call chain is backed up in the reverse direction for the purpose of authorizing the preceding parent code block to operate in secure execution mode only if supplied with the result of authentication decryption from the appropriately authorized portion of the security chain. As described above, note that any of several conditions may reset any "secure execution mode enable" bit to the "unsafe" default state (thus, the entire security chain may be restarted). Potentially requires). Such conditions may include processor interrupts or subsequent digital signature comparison mismatches. Although these hardware access control blocks 1341, 1343, 1345 are shown as separate entities in FIG. 13 for clarity, they are in fact a single hardware unit whose output is fed back as one of its own input terms (see FIG. 15 and It can be seen that it can be embodied). Ultimately, the output of the highest level or final "secure execution mode enable" bit in the entire chain enables or disables some externally visible output of the target device (e.g., enabling audio or video output). It can be used as part of a control mechanism to enable.

단계 1370에서 복호 엔진 코드 블록(1331)의 동작은 데이터 구조(1320)의 복호 엔진 코드 블록부(1321)에 저장된 데이터 집합을 최초 데이터의 갱신된 및/또는 적절히 실행가능한 버전으로 교체 또는 다른 방식으로 보충하는 것이다. 이 동작은 복호 코드 블록(1321)에 저장된 최초 데이터를 이용하고 키 리스트 데이터 구조(1328)에 의해 저장되거나 지적된 하나 이상의 복호 키로 최초 데이터를 복호함으로써 달성될 수 있다. 대안적으로, 위에서 설명한 바와 같이, 복호 엔진 코드 블록(1331)의 동작(1370)은 복호 코드 블록(1321)을 갱신 버전으로 교체하거나 복호 엔진 코드 블록(1321) 대신에 직접 실행하게 할 수 있다. 어느 경우이든, 복호 엔진 코드 블록(1331)은 (이 실시예에서) 목표 엔드포인트 장치의 타임스탬프 레지스터(1394)에 내포된 값, 목표 엔드포인트 장치의 하드웨어 지정 비밀키(1392)(하드웨어 액세스 제어(1342)를 통과함으로써 수정됨) 및 엔드포인트 및 타임스탬프 지정 합성 디지털 키(1326)를 포함하는 각종 입력 데이터를 이용하여 최초로 동작할 수 있다. 복호 엔진 코드 블록(1331)이 복호 엔진 코드 블록(1321)의 직접 교체로서 후속적으로 동작하는 경우에, 복호 엔진 코드 블록(1331)은 예를 들면, 이 실시예에서 목표 엔드포인트 장치의 타임스탬프 레지스터(1394)에 내포된 값, 목표 엔드포인트 장치의 하드웨어 지정 비밀키(1392)(하드웨어 액세스 제어(1344)를 통과함으로써 수정됨) 및 엔드포인트 및 타임스탬프 지정 합성 디지털 키(1316)를 포함하는 입력 데이터의 제2 집합을 활용할 수 있다.Operation of the decoding engine code block 1331 at step 1370 replaces or otherwise replaces the data set stored in the decoding engine code block 1321 of the data structure 1320 with an updated and / or appropriately executable version of the original data. To supplement. This operation may be accomplished by using the original data stored in decryption code block 1321 and decrypting the original data with one or more decryption keys stored or indicated by key list data structure 1328. Alternatively, as described above, operation 1370 of decoding engine code block 1331 may replace decoding code block 1321 with an updated version or may execute directly on behalf of decoding engine code block 1321. In either case, the decryption engine code block 1331 may (in this embodiment) contain the value contained in the timestamp register 1394 of the target endpoint device, the hardware-specified secret key 1392 of the target endpoint device (hardware access control). Modified by passing 1342) and various input data, including endpoint and timestamp specified composite digital keys 1326, for the first time. When the decoding engine code block 1331 subsequently operates as a direct replacement of the decoding engine code block 1321, the decoding engine code block 1331 is, for example, the timestamp of the target endpoint device in this embodiment. A value contained in register 1394, a hardware-specific secret key 1372 of the target endpoint device (modified by passing through hardware access control 1344), and an endpoint and time stamp-specified composite digital key 1316. A second set of input data can be utilized.

단계 1371에서 갱신 복호 엔진 코드 블록(1321)의 추가의 동작은 소망의 출력 데이터(1380)를 생성하기 위해 최초의 암호화 콘텐트 데이터(1312)를 교체 또는 다른 방식으로 해석하는 것이다. 이 동작은 복호 코드 블록(1321)에 저장된 최초 데이터를 이용하고 키 리스트 데이터 구조(1318)에 의해 저장되거나 지적된 하나 이상의 복호 키로 최초 데이터를 복호함으로써 달성될 수 있다. 양측의 복호 엔진 코드 블록(1321, 1331)의 동작이 사실상 유사하기 때문에, 복호 엔진 코드 블록(1331)의 동작과 관련하여 위해서 구체적으로 설명한 임의의 옵션이 복호 엔진 코드 블록(1321)의 갱신 버전의 동작에도 동일하게 적용할 수 있음을 명백히 하여야 한다. 또한, 복호 엔진 코드 블록(1321)의 동작의 경우에, 일부 실시예에서, 관련 하드웨어 액세스 제어 블록(1344)은 하드웨어 액세스 제어 블록(1342)과 구별된다는 점에 주목하여야 한다. 그러나, 상기 2개의 하드웨어 액세스 제어 블록(1342, 1344)의 동작은 그들의 목적이 그들의 관련 복호 엔진(1331 또는 1321)에 의한 목표 엔드포인트 장치의 하드웨어 지정 비밀키(1392)의 사용을 가능 또는 불가능하게 하는 것이라는 점에서 사실상 유사하고, 따라서 다른 실시예에서는 구별되지 않는다.An additional operation of update decryption engine code block 1321 at step 1371 is to alternately or otherwise interpret the original encrypted content data 1312 to produce the desired output data 1380. This operation may be accomplished by using the original data stored in decryption code block 1321 and decrypting the original data with one or more decryption keys stored or indicated by key list data structure 1318. Since the operations of the decoding engine code blocks 1321 and 1331 on both sides are substantially similar, any of the options specifically described in connection with the operation of the decoding engine code blocks 1331 are related to the updated version of the decoding engine code block 1321. It should be clear that the same applies to the operation. It should also be noted that in the case of operation of decoding engine code block 1321, in some embodiments, the associated hardware access control block 1344 is distinct from hardware access control block 1342. However, the operation of the two hardware access control blocks 1342 and 1344 is intended to enable or disable the use of the hardware-specific secret key 1392 of the target endpoint device by their associated decryption engine 1331 or 1321. Are virtually similar in that respect, and thus are not distinguished in other embodiments.

마지막으로, 위에서 설명한 도 13의 실시예로 묘사한 모든 동작에 있어서, 목표 엔드포인트 장치의 타임스탬프 레지스터(1394)의 사용은 다른 실시예로 위에서 설명한 예들과 본질적으로 유사하다. 따라서, 레지스터(1394)에 저장된 값은 도 13에 도시한 특수 실시예에서 설명한 다른 인증 및 복호 동작에서 사용한 각종 합성키 및/또는 디지털 서명의 생성시에 추가적인 요소로서 사용될 수 있다.Finally, for all operations depicted in the embodiment of FIG. 13 described above, the use of the time stamp register 1394 of the target endpoint device is essentially similar to the examples described above in another embodiment. Thus, the value stored in the register 1394 can be used as an additional element in the generation of various composite keys and / or digital signatures used in the other authentication and decryption operations described in the special embodiment shown in FIG.

도 14는 회귀형 호출 사슬이 어떻게 관통 및 종료되는지 및 프로세서가 하나 이상의 매립 코드 블록의 메시지 다이제스트 기반 인증을 이용하여 어떻게 보안 실행 모드로의 진입이 허용되는지에 대한 일 실시예를 도시한 것이다. 이 실시예에서는 도 7b와 관련하여 위에서 설명한 것처럼 범용 암호 데이터 구조(1411, 1421)에 각각 내포될 수 있는 2개의 후보 코드 블록(1412, 1422)의 동작이 설명된다.14 illustrates one embodiment of how a recursive call chain penetrates and terminates and how the processor is allowed to enter secure execution mode using message digest based authentication of one or more embedded code blocks. In this embodiment, the operation of two candidate code blocks 1412, 1422, which may be implied in general cryptographic data structures 1411, 1421, respectively, as described above with respect to FIG. 7B, is described.

코드 블록 데이터 구조(1421)는 도 14에서 2회 표시된다는 점에 주목한다. 이 중복은 명확히 할 목적으로 별도의 반복을 표시하기 위해 도시한 것이지만, 이것은 두 가지 예에서 정확히 동일한 데이터 구조임을 알아야 한다. 그러나 인지될 수 있는 한가지 차이점은 키 리스트 포인터(1421)의 사례에 의해 지적되는 키 리스트 데이터 구조(1428, 1438)에 있다. 비록 키 리스트 포인터(1421)의 값이 이 도면에 도시한 2개의 사례 사이에서 변하지 않지만, 키 리스트 데이터 구조(1428)에 내포된(또는 키 리스트 데이터 구조(1428)에 의해 지적된) 값은 2개의 반복 사이에서 변할 수 있고, 따라서 이것의 세부는 데이터 구조(및 그 각종 컴포넌트)의 참조 번호를 1426, 1427 및 1428로부터 1436, 1437 및 1438로 각각 다시 번호 붙임으로써 표시된다. 이 구조가 다시 번호 붙임되었다는 사실은 데이터 구조의 실제 위치가 이동되었다는 것 및 그 콘텐트가 변경되었다는 것을 표시하는 것이 아니다. 마찬가지로, 명확성을 높이기 위해, 하드웨어 해싱 함수(1480)가 이 도면에서 또한 복수 회 도시되었다. 마지막으로, 2개의 후보 코드 블록(1421, 1422)의 어느 것도 암호화되지 않고, 따라서 그 관련 복호 포인터(1416, 1426, 1436)는 모두 무효(null) 포인터일 수 있다.Note that code block data structure 1421 is displayed twice in FIG. 14. This redundancy is shown to indicate separate iterations for clarity purposes, but it should be understood that this is exactly the same data structure in both examples. However, one difference that can be noticed is in the key list data structures 1428, 1438, pointed out by the example of the key list pointer 1421. Although the value of the key list pointer 1421 does not change between the two cases shown in this figure, the value contained in the key list data structure 1428 (or pointed out by the key list data structure 1428) is 2 Can be varied between the repetitions of the two, so details thereof are indicated by renumbering the reference numbers of the data structure (and its various components) from 1426, 1427 and 1428 to 1436, 1437 and 1438, respectively. The fact that this structure has been renumbered does not indicate that the actual position of the data structure has been moved and its content has changed. Likewise, for clarity, the hardware hashing function 1480 is also shown multiple times in this figure. Finally, none of the two candidate code blocks 1421, 1422 are encrypted, so that their associated decryption pointers 1416, 1426, 1436 may all be null pointers.

이 실시예에 있어서, 후보 코드 블록(1412)에 대한 호출이 개시될 수 있다. 위에서 설명한 것과 동일한 방식으로, 코드 블록 데이터 구조(1411)는 메모리에 읽어 들일 수 있고, 그 메시지 다이제스트(1441)는 해싱 함수(1480)(이것은 위에서 설명한 것처럼 전체적으로 또는 부분적으로 하드웨어로 실현될 수 있다)에 의해 계산될 수 있다. 그러나, 이 실시예에서, 해싱 함수는 초기 종자값(1440)(모두 0으로 세트될 수도 있고 아닐 수도 있다)이 주어진다. 위에서 설명한 것처럼, 이 해싱 함수 종자값 특징은 다수의 방법들 중 하나를 이용하여 구현될 수 있지만, 이 실시예에서는 종자값(1440)이 공지되어 있고, 종자값이 해싱 함수 블록(1480)의 메시지 다이제스트 출력(1441)에 영향을 주는 방법은 반복적이며 결정론적이다.In this embodiment, a call to candidate code block 1412 may be initiated. In the same manner as described above, the code block data structure 1411 can be read into memory, and the message digest 1441 is a hashing function 1480 (which can be implemented in hardware, in whole or in part, as described above). Can be calculated by However, in this embodiment, the hashing function is given an initial seed value 1440 (which may or may not be set to all zeros). As described above, this hashing function seed value feature may be implemented using one of a number of methods, but in this embodiment the seed value 1440 is known and the seed value is a message of the hashing function block 1480. The way to affect the digest output 1442 is iterative and deterministic.

해싱 함수의 결과(1441)가 생성되면, 프로세서는 코드 블록(1412)에 내포된 코드의 실행을 시작할 수 있다. 도 14에 도시한 실시예에 있어서, 키 리스트 포인터(1414)에 의해 지적된 2개의 위치(1416, 1417)(이것은 키 리스트 데이터 구조(1418) 내측에 포함되어 있다)의 값 및 복호 포인터(1413)는 모두 무효(null)이고, 코드 블록(1412)은 보안 실행 모드에서 동작하도록 설계되지 않을 수 있으며, 따라서 임의의 목표 엔드포인트 장치 보안 하드웨어 특징의 사용을 요구하지 않는다. 따라서, 프로세서는 코드 블록(1422)을 지적하는 매립 서브루틴 호출에 도달할 때까지 코드 블록(1412)에 내포된 명령어들의 실행을 시작한다.Once the result 1441 of the hashing function is generated, the processor can begin executing the code contained in the code block 1412. In the embodiment shown in Fig. 14, the values of the two positions 1416, 1417, which are pointed to by the key list pointer 1414, which are contained inside the key list data structure 1418, and the decoding pointer 1413 Are all null, and code block 1412 may not be designed to operate in a secure execution mode, and thus does not require the use of any target endpoint device security hardware features. Thus, the processor starts executing the instructions contained in code block 1412 until it reaches a buried subroutine call that points to code block 1422.

이 점에서, 코드 블록 데이터 구조(1421)는 메모리에 로드되고, 다음 메시지 다이제스트(1442)를 생성하는 처리가 해싱 함수 블록(1480)에 의해 반복된다. 그러나, 이 특수한 사례에 있어서, 해싱 함수 종자값은 더 이상 초기 종자값(1440)이 아니고 오히려 미리 생성된 결과(1441)이다. 따라서, 메시지 다이제스트(1442)의 값은 양쪽 코드 블록(1411, 1421)의 메시지 다이제스트에 결정론적으로 의존한다는 것을 알 수 있다. 그러나, 이전 경우에서처럼, 복호 포인터(1423)의 값 및 키 리스트 포인터(1424)에 의해 지적된 키 리스트 데이터 구조(1428)에 내포된 값들은 여전히 무효(null)이고, 따라서 프로세서는 앞에서처럼 비보안 실행 모드에서의 동작을 계속한다.At this point, the code block data structure 1421 is loaded into memory, and the process of generating the next message digest 1442 is repeated by the hashing function block 1480. However, in this particular case, the hashing function seed value is no longer the initial seed value 1440, but rather the pre-generated result 1441. Thus, it can be seen that the value of message digest 1442 is deterministically dependent on the message digest of both code blocks 1411 and 1421. However, as in the previous case, the value of the decrypt pointer 1423 and the values implied in the key list data structure 1428 pointed to by the key list pointer 1424 are still null, so the processor executes insecure as before. Continue operation in mode.

어떤 나중의 지점에서, 프로세서는 다른 서브루틴 호출을 만나지만, 이 예에서 코드 블록(1422)은 회귀형 호출(예를 들면, 자신에 대한 서브루틴 호출)을 내포한다. 특정 실시예에 있어서, 그러한 회귀형 호출 구조는 단지 예시적인 것이고, 목표 엔드포인트 장치 보안 시스템의 정확한 동작은 예를 들면 보안 시스템에 대한 임의의 호출이 단일 코드 층에 내포된 것을 보증하는 다른 수단에 의해 달성될 수 있다. 그러나, 보안 시스템의 복수의 레벨이 관통되자마자 회귀형 호출 형태가 위에서 상세히 설명한 것처럼 상대적으로 더 안전하게 되고, 도시된 실시예와 함께 보안 시스템을 구현하기 위해 효과적으로 활용될 수 있다.At some later point, the processor encounters another subroutine call, but in this example code block 1422 implies a recursive call (eg, a subroutine call to itself). In certain embodiments, such a recursive call structure is merely exemplary, and the correct operation of the target endpoint device security system may be implemented in other means to ensure, for example, that any call to the security system is contained in a single code layer. Can be achieved by However, as soon as multiple levels of security system are penetrated, the recursive call type becomes relatively safer as detailed above, and can be effectively utilized to implement the security system with the illustrated embodiment.

임의의 경우에, 프로세서가 코드 블록(1422)(자신을 참조함) 내에 매립된 서브루틴 호출과 만나면, 코드 블록 데이터 구조(1421)는 메모리에 다시 한번 로드되고(예를 들면, 대부분의 현대 시스템에서 데이터 구조(1421)는 두번째 인출된 때 물리적으로 다른 위치에 로드된다), 해싱 함수(1480)는 새로운 메시지 다이제스트(1443)를 계산한다. 이 새로운 메시지 다이제스트(1443)는 초기 메시지 다이제스트 종자값(1440), (코드 블록(1421)의) 메시지 다이제스트(1441) 및 코드 블록(1422)의 2개의 별도의 반복의 메시지 다이제스트에 의존한다는 점에 주목한다.In any case, when the processor encounters a subroutine call embedded within code block 1422 (see itself), code block data structure 1421 is once again loaded into memory (eg, in most modern systems). In the data structure 1421 is loaded at a different physical location when it is second fetched), the hashing function 1480 calculates a new message digest 1443. This new message digest 1443 depends on two separate iterations of the message digest: initial message digest seed value 1440, message digest 1441 (of code block 1421) and code block 1422. Pay attention.

이 두번째 시간에 키 리스트 포인터는 무효가 아닌(non-null) 디지털 서명값(1437)을 내포하는 새로운 데이터 구조(1438)를 지적한다. 이 무효가 아닌 값은 코드 블록(1422)의 반복이 목표 엔드포인트 하드웨어 지정 보안 시스템에 대한 참조를 내포한다는 것을 보안 시스템에 표시하는 표시자이다. 따라서, 이 실시예에서, 이러한 참조가 적절히 동작하기 위하여, 프로세서는 어떤 지점에서 보안 실행 모드로 진입하여야 한다. 따라서, 코드 블록 데이터 구조(1421)가 가장 최근에 메모리에 로드된 때 생성된 디지털 서명(1443)은 키 리스트 데이터 구조(1438)에 내포된 디지털 서명(1437)과 비교된다. 단계 1491에서 상기 2개의 값이 실질적으로 유사한 것으로 판정된 경우에, 목표 엔드포인트 프로세서는 보안 실행 모드로의 진입이 허용된다. 그러나, 만일 2개의 디지털 서명 값(1437, 1443)이 일치하지 않으면(및 디지털 서명(1437)이 이 지점에서 무효가 아닌 것으로 알려지면), 단계 1492의 결과가 프로세서에 제공되어 보안 시스템의 적당한 예외 에러 핸들러 부분(1470)을 실행시킨다.At this second time, the key list pointer points to a new data structure 1438 that contains a non-null digital signature value 1435. This non-valid value is an indicator that indicates to the security system that the repetition of code block 1422 implies a reference to the target endpoint hardware specific security system. Thus, in this embodiment, for this reference to work properly, the processor must enter the secure execution mode at some point. Thus, the digital signature 1443 generated when the code block data structure 1421 is most recently loaded into memory is compared with the digital signature 1437 contained in the key list data structure 1438. If it is determined in step 1491 that the two values are substantially similar, the target endpoint processor is allowed to enter the secure execution mode. However, if the two digital signature values 1437 and 1443 do not match (and the digital signature 1437 is known to be invalid at this point), then the result of step 1492 is provided to the processor to provide a suitable exception for the security system. The error handler portion 1470 is executed.

도 15는 위에서 설명한 특징들을 지원하기 위해 디지털 서명 발생기 블록(1560)이 어떻게 하드웨어에서 구현될 수 있는지에 관한 일 실시예를 보인 도이다. 도 15에 도시한 실시예는 도 10에 도시한 디지털 서명 발생기 블록의 기능과 유사한 기능의 하드웨어 구현을 보여주고 있고, 이것은 예를 들면 도 11, 12, 13 및 14와 관련하여 동작상의 세부로 설명한 기능적 특징들을 지원할 것이다.15 illustrates one embodiment of how the digital signature generator block 1560 can be implemented in hardware to support the features described above. The embodiment shown in FIG. 15 shows a hardware implementation of functionality similar to that of the digital signature generator block shown in FIG. 10, which is described in detail in operation with respect to FIGS. 11, 12, 13 and 14, for example. It will support functional features.

해싱 함수 종자 레지스터(1510)는 도 14에 블록(1440)으로 표시된 기능과 유사한 기능을 포함할 수 있고, 해싱 함수 블록(1561)에 공급된 초기값을 유지하도록 동작할 수 있다. 해싱 함수 블록(1561)의 출력은 합성 암호화 엔진의 제1 단계(1562)에 대한 입력들 중 하나로서 공급된다. 암호화 엔진(1562)의 다른 입력은 목표 엔드포인트 장치 타임스탬프 레지스터(1541)의 출력이다. 제1 단계 암호화 엔진(1562)의 결과적인 출력은 다음에 제2 단계 암호화 엔진(1563)의 입력들 중 하나로서 공급된다. 제2단계 암호화 엔진(1563)의 다른 입력은 보안 실행 모드 액세스 포인트(1566)의 출력이다.The hashing function seed register 1510 may include functionality similar to that indicated by block 1440 in FIG. 14 and may operate to maintain an initial value supplied to the hashing function block 1561. The output of the hashing function block 1561 is supplied as one of the inputs to the first stage 1562 of the synthesis cryptographic engine. Another input of cryptographic engine 1562 is the output of target endpoint device timestamp register 1541. The resulting output of the first stage encryption engine 1562 is then supplied as one of the inputs of the second stage encryption engine 1563. Another input of the second stage encryption engine 1563 is the output of the secure execution mode access point 1566.

액세스 포인트(1566)는 도 14를 참조하여 위에서 설명한 것처럼, 목표 엔드포인트 장치가 보안 실행 모드에서 동작할 때 또는 "회귀 종료" 조건이 검출된 때에만 목표 엔드포인트의 하드웨어 지정 비밀키(1540)의 값을 통과하도록 동작한다. 제2 단계 암호화 엔진(1563)으로부터의 결과적인 출력 값은 디지털 서명 레지스터(1564)에 저장되고, 상기 발생된 디지털 서명을 후보 코드 블록에 공급된 디지털 서명과 비교할 때 사용된다(예를 들면, 도 9, 도 10, 도 11, 도 12, 도 13 및 도 14의 설명에서 인용됨).As described above with reference to FIG. 14, the access point 1566 may determine the hardware-specific secret key 1540 of the target endpoint only when the target endpoint device is operating in secure execution mode or when a "return to end" condition is detected. Operate to pass a value. The resulting output value from the second stage encryption engine 1563 is stored in the digital signature register 1564 and used when comparing the generated digital signature with the digital signature supplied to the candidate code block (eg, FIG. 9, 10, 11, 12, 13 and 14 cited in the description).

디지털 서명 레지스터(1564)의 출력은 액세스 포인트(1565)에 의해 제어되고, 그 동작은 목표 엔드포인트 장치가 보안 실행 모드에서 동작하지 않을 때 디지털 서명 레지스터(1564)의 값을 통과하는 것이다. 그 다음에, 액세스 포인트(1565)의 출력은 해싱 함수 종자 레지스터(1510)의 입력으로 피드백되어 도 14와 관련한 설명에서 구체적으로 설명한 직렬 메시지 다이제스트 특징을 생성한다. 목표 엔드포인트 장치가 보안 실행 모드에서 동작하면, 해싱 함수 종자 레지스터(1510)의 입력은 디지털 서명 레지스터(1564)의 값에 의존하지 않고, 따라서 임의의 초기값으로 설정될 수 있고(도 14와 관련한 설명에서 설명됨) 또는 어떤 다른 수단에 의해 설정될 수 있다(예를 들면, 프로세서가 특정 메모리 위치에 기록한다).The output of the digital signature register 1564 is controlled by the access point 1565, the operation of which is to pass through the value of the digital signature register 1564 when the target endpoint device is not operating in secure execution mode. The output of the access point 1565 is then fed back to an input of a hashing function seed register 1510 to generate the serial message digest feature described in detail in connection with FIG. 14. If the target endpoint device is operating in secure execution mode, the input of the hashing function seed register 1510 does not depend on the value of the digital signature register 1564 and thus can be set to any initial value (in conjunction with FIG. 14). Or set by some other means (eg, the processor writes to a specific memory location).

지금까지 특정 실시예를 참조하여 본 발명을 설명하였다. 그러나, 이 기술에 통상의 지식을 가진 자라면 청구범위에서 규정하는 본 발명의 범위로부터 벗어나지 않고 여러 가지로 수정 및 변경이 가능하다는 것을 알 것이다. 따라서, 명세서, 부록 및 도면은 제한하는 의도라기보다는 예시적인 것으로 간주되어야 하고, 그러한 수정들은 모두 임의의 제한적인 용어의 사용에도 불구하고 본 발명의 범위에 포함된 것으로 의도된다.The present invention has been described above with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification, appendices, and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present invention despite the use of any restrictive terminology.

잇점, 다른 장점 및 문제점에 대한 해법을 특정 실시예와 관련하여 위에서 설명하였다. 그러나, 잇점, 장점, 문제점에 대한 해법, 및 임의의 잇점, 장점 또는 해법을 발생시키거나 더 명백하게 하는 임의의 컴포넌트는 임의의 또는 모든 청구항의 중요한, 요구된, 또는 본질적인 특징 또는 컴포넌트로서 해석되어서는 안된다.Benefits, other advantages, and solutions to problems have been described above in connection with specific embodiments. However, advantages, advantages, solutions to problems, and any components that generate or make any benefit, advantage, or solution more obvious, should be construed as important, required, or essential features or components of any or all claims. Can not be done.

부 록 AAppendix A

본 발명 및 그 각종 특징과 유리한 세부는 첨부 도면에 도시되고 이하의 설명에서 상세화되는 비제한적인 실시예를 참조하여 더욱 완전하게 설명된다. 잘 알려져 있는 시작 물질, 처리 기술, 컴포넌트 및 설비에 관한 설명은 본 발명의 세부를 불필요하게 불명료하게 하는 것을 방지하기 위해 생략한다. 그러나, 본 발명의 양호한 실시예를 표시하는 것이지만, 그 실시예에 대한 상세한 설명 및 특수한 예는 제한하는 의도가 없이 단지 예시하는 용도로만 주어진다는 것을 이해하여야 한다. 근원적인 발명 개념의 정신 및/또는 범위 내에서의 각종 치환, 수정, 추가 및/또는 재구성이 이 기술에 숙련된 사람에게는 이 명세서의 설명으로부터 명백할 것이다. The invention and its various features and advantageous details are explained more fully with reference to the non-limiting embodiments shown in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components and equipment are omitted to avoid unnecessarily obscuring the details of the present invention. However, while indicating a preferred embodiment of the present invention, it is to be understood that the detailed description and specific examples thereof are given for purposes of illustration only and are not intended to be limiting. Various substitutions, modifications, additions, and / or reconfigurations within the spirit and / or scope of the underlying inventive concept will be apparent to those skilled in the art from the description herein.

이제, 디지털 콘텐트를 보호하기 위한 보안 프로토콜의 시스템 및 방법에 대하여 살펴본다. 이 보안 프로토콜은 임의의 디지털 콘텐트에 대해 사용가능하고, 실제 디지털 콘텐트의 변경을 요구하지 않고 일반적으로 전통적인 워터마킹 방식과 관련된 아이덴티티 트레이싱의 개념을 또한 지원할 수 있다. 이 프로토콜은 모든 디지털 비트 스트림이 동일하다는 전제에 기초를 두기 때문에, 프로토콜 자체의 갱신을 위한 액세스를 제어하기 위해 회귀 형식으로 사용될 수 있다. 다시 말해서, 프로토콜은 데이터가 보호대상의 미디어 스트림이든지, 그러한 스트림을 재생하기 위해 필요한 실행가능 코드이든지, 그러한 스트림을 재생하기 위해 필요한 암호화 실행가능 코드이든지, 그러한 스트림을 재생하기 위해 필요한 암호화 코드를 복호하기 위해 필요한 실행가능 코드이든지, 복호 코드와 함께 사용되는 키이든지, 등등과 상관없이 디지털 데이터의 종류들 간에 구별을 만들지 않는다. 이러한 데이터의 디지털 속성은 모두 프로토콜에 중요하다. 따라서, 디지털 데이터의 속성 및/또는 용도가 보안 프로토콜에 관심이 없기 때문에, 프로토콜은 그 자체를 보호할 수 있다.Now, a system and method of a security protocol for protecting digital content will be described. This security protocol can be used for any digital content and can also support the concept of identity tracing generally associated with traditional watermarking schemes without requiring changes in the actual digital content. Since this protocol is based on the premise that all digital bit streams are the same, it can be used in a regression format to control access for updating the protocol itself. In other words, the protocol decodes the encryption code needed to play such a stream, whether the data is a protected media stream, the executable code required to play such a stream, or the cryptographic executable code required to play such a stream. It does not make any distinction between types of digital data, whether it's executable code needed to do it, keys used with decryption code, or the like. The digital properties of these data are all important to the protocol. Thus, because the nature and / or use of digital data is not concerned with security protocols, the protocol can protect itself.

이 능력은 보안 프로토콜이, 실행중이라 하더라도, 프로토콜이 동작하는 하드웨어의 어떠한 변경을 요구하지 않고 (예를 들면, 최근에 발견된 보안 취약점(security hole)을 수리하기 위해) 갱신될 수 있음을 의미한다. "오래된" 보안 시스템은 새로운 보안 시스템이 일부로서 포함된다(즉, 새롭고 잠재적으로 더 안전한 보안 레벨을 전체 시스템에 추가하기 위해 오래된 보호 "래퍼(wrapper)"를 벗겨낼 필요가 없다). 따라서, 전체 시스템이 최근의 가장 안전한 암호화 및/또는 액세스 제어 시스템으로 보호된다. 새로운 키가 추가될 뿐만 아니라, 완전히 새로운 보안 및/또는 암호화 알고리즘이 현재의 시스템에 또한 추가될 수 있다.This capability means that even if a security protocol is running, the protocol can be updated without requiring any change in the hardware on which it works (eg, to repair recently discovered security holes). do. An "old" security system is included as part of the new security system (ie, there is no need to strip off the old protection "wrapper" to add a new and potentially more secure level of security to the entire system). Thus, the entire system is protected with the latest and most secure encryption and / or access control systems. Not only are new keys added, entirely new security and / or encryption algorithms can also be added to the current system.

이 융통성은 시간 제한이 있는 대여, 페이 퍼 뷰, 다중 버전화(multiple versioning), 머신 의존형 허가 취소 및 하나의 사용자로부터 다른 사용자로 소유권의 영구 양도를 포함한 다수의 사업 모델을 프로토콜이 지원할 수 있게 한다.This flexibility allows the protocol to support multiple business models, including time-limited lending, paper views, multiple versioning, machine-dependent authorization revocation, and the permanent transfer of ownership from one user to another. .

저작권이 있는 소프트웨어 애플리케이션이 예시적인 실시예에서 활용되지만, 이 기술에 숙련된 사람이라면 동일한 방법 및 시스템을 사용하여 텍스트, 비디오 및 오디오 데이터, 소스 및 목적 코드 등을 포함한 모든 비트스트림에 대해 보안을 제공할 수 있다는 것을 이해할 것이다.While copyrighted software applications are utilized in the example embodiments, those skilled in the art use the same methods and systems to provide security for all bitstreams, including text, video and audio data, source and destination codes, and the like. I will understand.

보안 프로토콜을 구체화하는 기본 기능은 하기의 것을 제공하도록(그러나 제한하는 것은 아님) 설계된다.The basic function of specifying a security protocol is designed to provide (but not limit) the following.

공정한 사용("시간 이동", "공간 이동" 및 보관소 백업)Fair Use ("Move Time", "Move Space", and Archive Backup)

증진적 업그레이드Promotional upgrade

소유권의 임시 양도Temporary transfer of ownership

소유권의 영구 양도Permanent transfer of ownership

시간 제한 액세스Timed access

사용량 제한 액세스(사용 횟수)Usage Limit Access (Number of Usage)

장치 지정 허가 취소Revoke permission to assign device

데이터 또는 스트림 지정 허가 취소Revoke permission to specify data or stream

많은 보안 시스템에 있어서, 저작권이 있는 작품에 포함된 지적 재산의 보호를 위한 기본 메카니즘 중의 하나는 단순한 액세스 제어이다. 그러나, 이러한 메카니즘이 우회되면, 가장 복잡한 액세스 제어 메카니즘에 의해 제공된 보호는 매우 작은 가치를 갖는다. 이것은 액세스 제어가 무용 메카니즘이고 본질적으로 및 자연히 전체 보안 시스템이 아니라고 말할 수 있다. 다수의 저작권있는 미디어 스트림이 인터넷에서 공개 소비에 자유롭게 이용가능하다는 사실은 그러한 보안 시스템이 거의 항상 우회될 수 있다는 사실의 증거이다. 이러한 종류의 액세스 제어는 합법적으로 구매한 저작권 작품의 카피를 백업하도록 메카니즘을 구성하는 것이 더욱 어렵게 하고, 이것은 원본이 파괴될 위험에 처해있는 경우 필요하다. 따라서, 여기에서 설명하는 보안 프로토콜은 보안 프로토콜을 유용하게 하기 위해 어떠한 종류의 액세스 제어 시스템도 요구하지 않는다.In many security systems, one of the basic mechanisms for the protection of intellectual property contained in copyrighted works is simple access control. However, if this mechanism is bypassed, the protection provided by the most complex access control mechanisms has very little value. This can be said that access control is a dance mechanism and not inherently and naturally the entire security system. The fact that many copyrighted media streams are freely available for public consumption on the Internet is evidence of the fact that such security systems can almost always be bypassed. This kind of access control makes it more difficult to configure the mechanism to back up a copy of a legally purchased copyrighted work, which is necessary if the original is in danger of being destroyed. Thus, the security protocol described herein does not require any kind of access control system to make the security protocol useful.

여기에서 설명하는 보안 프로토콜은 저작권 작품의 표현을 제어하는 것에 집중되고, 작품 자체를 구성하는 디지털 데이터에 집중되는 것이 아니다. 그래서, 프로토콜은 저작권 작품을 보호하기 위해 사용하는 디지털 데이터 또는 그 작품이 어떻게 해석되어야 하는지를 설명하기 위해 사용하는 다른 디지털 데이터들 사이에 구별을 만들지 않는다. 그 결과, 프로토콜은 다른 보안 프로토콜을 보호하기 위해 사용될 수 있다.The security protocol described here is focused on controlling the representation of the copyrighted work, not on the digital data that constitutes the work itself. Thus, the protocol does not make a distinction between the digital data used to protect a copyrighted work or other digital data used to describe how the work should be interpreted. As a result, the protocol can be used to protect other security protocols.

기본 동작 설명:Description of basic behavior:

보안 프로토콜의 실시예는 소프트웨어 부분의 창조자가 그들의 코드가 그 알고리즘을 복사 또는 다른 방식으로 악용하고자 하는 사람에 의해 분해되는 것으로부터 보호되는 높은 신용 정도를 가질 수 있도록 설계된다. 실시예는 또한 코드의 기능을 변경하려고 하는 사람에 의해 코드가 수정되는 것으로부터 보호하도록 설계된다. 이러한 기본 특징이 다른 범용 컴퓨팅 시스템에서 구현될 수 있게 하는 방법들 중의 하나는 다음 섹션에서 설명된다. 이러한 2가지 기본 기능의 부산물로서 발생하는 추가의 특성은 소프트웨어가 동작할 수 있는 조건(즉, 언제 어떻게 어느 머신에서 코드의 실행이 허용되는지)을 제어하는 능력이다. 이 기능들 중 첫번째의 것은 변경 방지(tamper-resistant) 타이머 요소를 시스템에 추가함으로써 달성될 수 있다. 다른 기능은 당해 코드 블록을 실행하기 위해 부합되어야 하는 소정의 조건들을 표시하기 위해 사용되는 보안 데이터 구조를 구현함으로써 달성된다. 이 데이터 구조는 하드웨어 지정이 아니기 때문에, 다양한 방법으로 사용될 수 있고, 그것을 해석하기 위해 사용한 소프트웨어를 갱신함으로써 수정될 수 있다. 프로토콜을 더 효율적으로 구현하기 위해 활용되는 하드웨어 지정 특징들이 설명되고, 프로토콜을 지원하기 위해 상기 특징들을 어떻게 사용할 수 있는지에 관한 예들이 주어진다. 마지막으로, 저작권 작품을 보호하기 위해 프로토콜을 어떻게 사용할 수 있는지를 설명한다.Embodiments of security protocols are designed such that the creator of the software portion can have a high degree of credit that is protected from being broken down by someone who wants their code to copy or otherwise exploit the algorithm. Embodiments are also designed to protect the code from being modified by a person trying to change the functionality of the code. One of the ways in which this basic feature can be implemented in other general purpose computing systems is described in the following section. An additional feature that arises as a by-product of these two basic functions is the ability to control the conditions under which the software can run (i.e. when and how on which machines the code is allowed to run). The first of these functions can be accomplished by adding a tamper-resistant timer element to the system. Another function is achieved by implementing a secure data structure that is used to indicate certain conditions that must be met to execute the code block in question. Since this data structure is not hardware specific, it can be used in a variety of ways and can be modified by updating the software used to interpret it. Hardware specific features utilized to implement the protocol more efficiently are described, and examples are provided of how the features can be used to support the protocol. Finally, it explains how the protocol can be used to protect copyrighted works.

보안 프로토콜의 실시예는 디지털 비트스트림을 그 의도된 수령자에 의해서만 복호할 수 있게 하는 방법으로 디지털 비트스트림을 암호화하는 능력에 의존한다. 이것은 잘 이해되는 문제이고, 수많은 산업 표준 암호화 알고리즘의 기초가 된다. 그러나, 보안 프로토콜의 실시예와 함께 사용하도록 고려해야 하는 2가지의 추가적인 요소가 있다. 즉, 프로토콜의 핵심(core)이 전형적인 온칩 명령어 캐시(I-캐시)의 (비교적) 작은 한계에 맞추어질 수 있다면 도움이 된다는 사실과 반독립 방식으로 동작이 가능하다는 사실이다. 다시 말해서, 프로토콜이 작고 평소의 매일같은 동작(day-to-day operation)을 위해 중앙의 보안 서버의 사용을 요구하지 않는다면 유용하다.Embodiments of the security protocol rely on the ability to encrypt the digital bitstream in a way that allows it to be decrypted only by its intended recipient. This is a well understood problem and is the basis of many industry standard encryption algorithms. However, there are two additional elements that should be considered for use with embodiments of security protocols. That is, it is helpful if the core of the protocol can be fitted to the (comparatively) small limits of a typical on-chip instruction cache (I-cache) and that it can work in a semi-independent manner. In other words, it is useful if the protocol is small and does not require the use of a central security server for normal day-to-day operations.

하드웨어:hardware:

이제 도 161로 돌아가서, 이 보안 프로토콜을 실행할 수 있는 장치의 예시적인 전체 블록도가 도시되어 있다. 보안 프로토콜 시스템의 예는 프로토콜을 프로토콜 엔진(100)("목표 유닛"이라고도 부름)에서 안전한 방식으로 구현하는 하드웨어 블록의 집합을 포함한다. 이 블록들은 프로토콜이 정확하게 동작하게 하기 위해 하드웨어에서 캐스트될 필요가 없지만, 뒤에서 설명하는 하드웨어 요소를 모두 포함하는 장치는 최소의 경상비(overhead)로 프로토콜을 구현할 수 있을 것이다.Turning now to FIG. 161, an exemplary overall block diagram of a device capable of implementing this security protocol is shown. An example of a secure protocol system includes a set of hardware blocks that implement a protocol in a secure manner in the protocol engine 100 (also called a "target unit"). These blocks do not need to be cast in hardware to make the protocol work correctly, but devices that include all of the hardware elements described below will be able to implement the protocol with minimal overhead.

이러한 하드웨어 블록의 첫번째는 실시간 클럭(102)이다. 이것은 중앙 서버와의 안전한 상호 작용에 의해 세트 또는 리세트될 수 있는 자유 가동(free-running) 타이머이다. 비록 이것이 완전히 본질적인 블록은 아니지만, 안전 시간 표준의 질의를 행함으로써 시간이 확립될 수 있기 때문에 이 기능을 온칩으로 하는 것이 더 편리하다. 이것은 시간 의존성 소프트웨어 라이센스와 함께 행하여져야 하고, 그 예는 이 문서의 뒤의 섹션에서 주어질 것이다.The first of these hardware blocks is the real time clock 102. This is a free-running timer that can be set or reset by secure interaction with the central server. Although this is not a completely essential block, it is more convenient to turn this function on chip because time can be established by querying the safety time standard. This must be done with a time-dependent software license, an example of which will be given later in this document.

다른 하나의 하드웨어 요소는 실행될 코드를 온칩으로 저장할 수 있는 메모리(110)의 블록이다. 이것은 전형적으로 명령어 캐시(I-캐시)라고 알려져 있고, 일부 실시예에 있어서, 상기 I-캐시(110)의 부분들의 중요한 특성은 특정 블록에 내포된 데이터가 CPU 실행 유닛(120)에 의해서만 판독될 수 있다는 것이다. 다시 말해서, I-캐시 메모리(130)의 상기 특수 블록은 실행만 가능하고 임의의 소프트웨어에 의해 판독 또는 기록될 수 없다. 이 I-캐시의 특수 섹션을 우리는 "보안 코드 블록"(130)이라고도 부른다. 실행 대상 코드가 이 보안 I-캐시 블록(130)에 실제로 저장되는 방법은 다른 하드웨어 요소에 의해서 수행될 수 있다.Another hardware element is a block of memory 110 that can store code to be executed on-chip. This is typically known as an instruction cache (I-cache), and in some embodiments, an important characteristic of portions of the I- cache 110 is that data contained in a particular block can only be read by the CPU execution unit 120. Can be. In other words, the special block of I- cache memory 130 is executable only and cannot be read or written by any software. The special section of this I-cache is also referred to as "secure code block" 130. The manner in which the executable code is actually stored in this secure I- cache block 130 may be performed by other hardware elements.

게다가, 보안 코드 블록의 동작을 가속화하기 위해 사용할 수 있는 가능한 "증대(enhancement)"의 다른 카테고리가 있다. 이 카테고리 중의 하나는 CPU(120)가 보안 코드를 실행하는 동안 액세스만 가능한 CPU 레지스터(140)의 (부분)집합을 지정하는 능력이고 및/또는 이것은 보안 코드 블록의 실행 종료시 또는 어떤 이유로 실행 유닛이 비보안 즉 "정상" I-캐시에 위치된 임의의 코드 섹션으로 점프하면 클리어된다. CPU(120)가 "보안" 코드와 "비보안" 코드의 혼합물을 실행할 가능성은 없어 보이지만, 인터럽트 루틴으로 점프할 때 콘텍스트를 스위칭하는 과정에서 무슨 일이 발생할 수 있는지 및 CPU(120) 콘텍스트가 어디에 저장되는지는 항상 염두에 두어야 한다(대부분의 CPU는 콘텍스트를 메인 메모리에 저장하는데, 이 메모리는 나중에 비보안 코드 블록에 의해 발견될 가능성이 있다).In addition, there are other categories of possible "enhancement" that can be used to speed up the operation of secure code blocks. One of these categories is the ability to specify a (partial) set of CPU registers 140 that can only be accessed while the CPU 120 executes the security code and / or it is executed by the execution unit at the end of execution of the security code block or for some reason. Clearing if you jump to any code section that is insecure, i.e., a "normal" I-cache. While it seems unlikely that the CPU 120 will run a mixture of "secure" code and "non-secure" code, what can happen in the process of switching context when jumping to an interrupt routine and where the CPU 120 context is stored It should always be kept in mind (most CPUs store the context in main memory, which is likely to be discovered later by insecure code blocks).

다른 가능성(어떤 레지스터(140)가 클리어되어야 하는지를 보안 코드 블록의 창조자가 명백히 식별하는 것을 요구하는 것이 아닌 것)은 그것이 자동으로 행하여져야 한다는 것이다. 이것은 보안 코드 블록 내에서 실행하는 동안 어떤 레지스터(140)가 판독 또는 기록되는지를 CPU 실행 유닛(120)이 계속하여 추적하고, 그 다음에 "보안" 모드를 빠져나갈 때 상기 레지스터를 자동으로 클리어하는 것일 수 있다. 이것은 보안 코드가 그 자체 후에 신속히 "청소(clean-up)"되어 2종류의 코들 블록들 간에 공유되도록 허용된 데이터만이 본래대로 유지되게 한다. "자동" 처리는 "명시적" 절차보다 잠재적으로 더 안전할 수 있지만, 코드 창조자가 보안 코드 블록과 비보안 코드 블록 사이에서 정보를 공유하고자 하는 경우에 더욱 복잡하게 될 수 있다.Another possibility (not requiring the creator of the secure code block to explicitly identify which register 140 should be cleared) is that it should be done automatically. This keeps track of which registers 140 are read or written while executing within a secure code block, and then automatically clears those registers when exiting the "secure" mode. It may be. This ensures that only the data that is allowed to be "clean-up" quickly after the security code itself is shared between the two types of coded blocks is kept intact. "Automatic" processing can potentially be safer than "explicit" procedures, but can be more complicated when code creators want to share information between secure and non-secure code blocks.

보안 코드 세그멘트와 비보안 코드 세그멘트 사이에서 레지스터 저장 데이터의 "누설"을 취급하는 다른 잠재적인 방법은 CPU(120)가 보안 코드를 실행할 때만 사용되는 레지스터의 유일한 집합을 식별하는 것이다. 대형 범용 레지스터 집합(140)을 가진 일부 CPU 아키텍쳐에 있어서, 이것은 최초로 금지적으로 비싼 것으로 보인다. 그러나, 많은 현대의 CPU 설계에서 실시되는 레지스터 리네이밍 및 스코어보딩 메카니즘의 수정 버전을 이용함으로써 과도한 경상비를 요구하지 않고(즉, "보안" 레지스터의 물리적으로 다른 집합을 구현할 때 수반되는 실리콘 오버헤드없이) 동일한 효과가 달성될 수 있다. 만일 보안 코드 블록의 실행을 원자 동작(atomic action)으로 취급하면(즉, 중단할 수 없으면), 이러한 이슈는 다루기가 더 쉽지만, 이 편리성은 성능 및 잠재적인 전체 코드 복잡성을 가져올 수 있다. I-캐시의 "보안" 부분(130)은 CPU에 대하여 I-캐시의 "정상" 부분(150)과는 다른 데이터 경로를 반드시 요구하지 않는다는 점에 주목한다. 사실, 상기 둘은 완전히 동의어일 수 있다.Another potential way to handle "leakage" of register storage data between secure code segments and non-secure code segments is to identify a unique set of registers that are only used when the CPU 120 executes the secure code. For some CPU architectures with a large general register set 140, this first appears to be prohibited and expensive. However, by utilizing a modified version of the register renaming and scoreboarding mechanism implemented in many modern CPU designs, it does not require excessive overhead costs (i.e. without the silicon overhead involved in implementing a physically different set of "secure" registers). The same effect can be achieved. If the execution of a secured code block is treated as an atomic action (ie, it cannot be interrupted), this issue is easier to deal with, but this convenience can result in performance and potential overall code complexity. Note that the "secure" portion 130 of the I-cache does not necessarily require a different data path to the CPU than the "normal" portion 150 of the I-cache. In fact, the two can be completely synonymous.

일방향 해시 함수 블록(160)이 또한 도시되어 있다. 이 기능을 하드웨어로 구현할 필요없이 보안 프로토콜의 실시예를 실행할 수 있는 엔진을 구성하는 것이 가능하다. 그러나, 해싱 알고리즘의 특정 부분에 대한 하드웨어 가속기는 확실히 바람직한 특징이다. 이 기능 블록의 하드웨어와 소프트웨어 구현 간의 교환조건(tradeoff)은 뒤에서 설명한다.One-way hash function block 160 is also shown. It is possible to construct an engine that can execute embodiments of the security protocol without having to implement this functionality in hardware. However, hardware accelerators for certain parts of the hashing algorithm are certainly desirable features. The tradeoff between the hardware and software implementation of this functional block is described later.

목표 유닛(100)의 다른 부분은 하드웨어 조력 복호 시스템(170)이고, 이것은 암호화 메시지에서 동작하는 목표 유닛(100)의 비밀키 및 공개/개인키(뒤에서 설명함)를 사용하여 이들을 실행가능 코드 블록으로 변환한다. 이 복호 시스템(170)은 여러 가지 방법으로 구현될 수 있다. 전체 프로토콜의 속도 및 보안성은 이 블록의 구성에 의존하고, 따라서 보안 시스템 갱신을 수용하도록 충분히 융통성이 있을 뿐만 아니라 시스템이 시간 임계 메시지의 실시간 복호를 수행하도록 충분히 고속이어야 한다.Another part of the target unit 100 is the hardware assisted decryption system 170, which executes the executable code block using the secret key and public / private key (described below) of the target unit 100 operating on the encrypted message. Convert to This decoding system 170 can be implemented in a number of ways. The speed and security of the overall protocol depends on the configuration of this block and therefore must be flexible enough to accommodate secure system updates as well as fast enough for the system to perform real time decryption of time critical messages.

이 두 가지 제약을 염두에 두고 있으면 프로토콜에 있어서 정확히 어떤 암호화 알고리즘이 이 하드웨어 블록(170)에 대하여 사용되는지는 중요하지 않다. 최대의 융통성을 촉진하기 위하여, 실제 하드웨어는 비알고리즘적으로 특수한 방법으로 사용되도록 충분히 범용이라고 추정되지만, 이 메카니즘을 구현할 수 있는 많은 다른 수단이 있다.With these two constraints in mind, it is not important what exactly encryption algorithm is used for this hardware block 170 in the protocol. To facilitate maximum flexibility, the actual hardware is assumed to be general enough to be used in a non-algorithmically specific way, but there are many other means of implementing this mechanism.

온칩 난수 발생기(180)가 또한 블록도에 점선으로 표시되어 있다. 이 블록은 선택적이다. 또한, 이 난수 발생기는 소프트웨어 기반 의사 난수 발생 시스템에 종자 값을 공급할 수 있는 충분히 무작위인 수의 열을 생성하는 적당한 오프칩 방법으로 교체될 수 있다. 이 의사 난수 발생기는 잠재적으로 하드웨어로 또는 "보안" 소프트웨어로 또한 구현될 수 있다. 물론, 소프트웨어 기반 시스템의 융통성과 하드웨어 구현 간의 동일 원리의 교환조건이 이 경우에 또한 적용될 수 있다. 그러나, 목표 장치(100)가 난수를 발생해야 하는 경우는 이 프로토콜에서 빈번하게 발생하지 않기 때문에, 이 특수한 기능이 하드웨어 가속화가 아닐지라도 전체 성능에 영향을 주지는 않을 것이다.On-chip random number generator 180 is also indicated by dashed lines in the block diagram. This block is optional. The random number generator can also be replaced with a suitable off-chip method that generates a sufficiently random number of rows capable of supplying seed values to a software based pseudo random number generation system. This pseudo random number generator can potentially also be implemented in hardware or in "secure" software. Of course, the same principle of exchange between the flexibility of the software-based system and the hardware implementation can also be applied in this case. However, the case where the target device 100 has to generate random numbers does not occur frequently in this protocol, so even if this special function is not hardware acceleration, it will not affect the overall performance.

비밀키:Secret key:

각 프로토콜 엔진(100)은 온칩으로 저장된 2세트의 비밀키 상수(104)를 가질 수 있고, 그들의 값은 소프트웨어에 의해 판독될 수 없다. 이들 키의 첫번째(1차 비밀키)는 비밀키의 집합으로서 구성될 수 있고, 그들 중에서 하나만이 임의의 특정 시간에 판독될 수 있다. 만일 유닛의 "소유권"이 바뀌면(예를 들면, 프로토콜 엔진을 내포한 설비가 판매되거나 그 소유권이 다른 방식으로 이전되면), 현재 활성인 1차 비밀키는 "클리어"되거나 다른 값으로 덮어쓰기 될 수 있다. 이 값은 안전한 방법으로 유닛에 전달될 수도 있고, 또는 상기 제1 키가 클리어된 때에만 사용되는 방식으로 유닛에 이미 저장되어 있을 수도 있다. 사실, 이것은 유닛의 소유권이 변경되었을 때 또는 그러한 변경에 관한 어떤 다른 이유가 있는 경우(절충키(compromised key)와 같이) 새로운 1차 비밀키를 상기 특수 유닛에 발행하는 것과 등가이다. 이 1차 비밀키 값(또는 값들의 집합)이 저장되는 유일한 다른 장소는 허가 기관에 있는 중앙 서버이다.Each protocol engine 100 may have two sets of secret key constants 104 stored on-chip, and their values cannot be read by software. The first of these keys (the primary secret key) can be configured as a set of secret keys, and only one of them can be read at any particular time. If the unit's "ownership" is changed (for example, a facility containing a protocol engine is sold or its ownership is transferred in another way), the currently active primary secret key will be "cleared" or overwritten with another value. Can be. This value may be delivered to the unit in a secure manner, or may already be stored in the unit in such a way that it is used only when the first key is cleared. In fact, this is equivalent to issuing a new primary secret key to the special unit when the ownership of the unit changes or if there is any other reason for such a change (such as a compromised key). The only other place where this primary secret key value (or set of values) is stored is the central server at the authority.

1차 비밀키는 중앙 서버 데이터베이스에 있는 특수한 목표 유닛(100)의 일련번호(106)와 관련될 수 있다. 일련 번호(106)는 목표 유닛(100)의 어디에든 저장될 수 있고, 소프트웨어 액세스가능이며 1차 비밀키에 대한 다른 관계를 갖지 않는다. 유닛의 동작 태양에 대한 임의의 갱신(보안 시스템의 갱신 등)은 1차 비밀키를 이용하여 달성될 수 있다. 만일 이 키의 값이 목표 유닛(100) 및 허가 기관 이외의 다른 당사자에게 알려져 있지 않으면, 안전한 중앙 서버를 통한 링크를 수반하지 않은 임의의 보안 트랜잭션을 위하여 사용될 수 없다. 그러나, 이 1차 키의 보안성은 최고의 중요성을 갖기 때문에, 절대적으로 필요할 때만 사용되어야 한다. 따라서, 예를 들면, 허가 기관의 중앙 서버와 목표 유닛 간의 안전한 트랜잭션을 위한 통신 링크를 암호화하기 위해 사용되어서는 안된다. 이 링크는 현재 허용되는 표준 실시에 따라서 급히 발생되는 임의 키를 이용하는 표준 키 교환 프로토콜을 이용하여 안전하게 될 수 있다.The primary secret key may be associated with the serial number 106 of the particular target unit 100 in the central server database. The serial number 106 can be stored anywhere in the target unit 100, is software accessible and has no other relationship to the primary secret key. Any update to the operational aspect of the unit (such as an update of the security system) can be accomplished using the primary secret key. If the value of this key is unknown to parties other than the target unit 100 and the authority, it cannot be used for any secure transaction that does not involve a link through a secure central server. However, the security of this primary key is of utmost importance and should only be used when absolutely necessary. Thus, for example, it should not be used to encrypt a communication link for secure transactions between a central server of a licensing authority and a target unit. This link can be secured using a standard key exchange protocol that uses any key that is rapidly generated according to currently accepted standard implementations.

2차 비밀키는 목표 유닛(100) 자체에만 알려질 수 있다(따라서 허가 기관에도 알려지지 않는다). 목표 유닛(100)의 CPU(120)는 1차 또는 2차 비밀키의 값에 액세스할 수 없으므로, 어떤 면에서 목표 유닛(100)은 그 자신의 비밀키(104)까지도 알지 못한다. 이 키들은 목표 유닛 CPU(120)의 보안 블록 내에 저장되어 사용될 뿐이다. 이들 두 가지 비밀키의 조합은 목표 유닛의 전체 보안성을 증대시킨다. 이들이 어떻게 사용되는 지는 뒤에서 설명한다.The secondary secret key may only be known to the target unit 100 itself (and therefore not to the licensing authority). Since the CPU 120 of the target unit 100 cannot access the value of the primary or secondary secret key, the target unit 100 does not know even its own secret key 104 in some respects. These keys are only stored and used in the security block of the target unit CPU 120. The combination of these two secret keys increases the overall security of the target unit. How they are used is explained later.

다른 키 집합은 임시 공개/개인키 시스템(비대칭 키 시스템 또는 PKI 시스템이라고도 알려져 있다)의 일부로서 동작할 수 있다. 이 쌍의 키들은 급하게 생성되고, 중앙 서버의 개입없이 유사한 유닛들 간의 보안 통신 링크를 확립하기 위해 사용될 수 있다. 이러한 시스템의 보안성이 등가 키 길이 대칭 키 암호화 시스템의 보안성보다 전형적으로 더 낮기 때문에, 이 키들은 전술한 비밀키 집합보다 사이즈가 더 커야 한다. 이 키들은 다른 무엇보다도 "재전송 공격"에 대하여 보호하기 위해 온칩 타이머 블록에서 제시되는 값과 함께 사용될 수 있다. 이 키들은 급하게 생성되기 때문에, 키들이 생성되는 방법은 일부 종류의 난수 발생 시스템(180)에 의존한다. 마지막으로, 상기 생성된 키들은 소위 "취약(weak)" 키의 부류에 포함되지 않도록 주의를 기울여야 한다. "취약"이라고 생각되는 특정 키 집합은 사용되는 특정 암호화 알고리즘에 의존한다.The other key set may operate as part of a temporary public / private key system (also known as asymmetric key system or PKI system). These pairs of keys are generated in a hurry and can be used to establish a secure communication link between similar units without the intervention of a central server. Since the security of such a system is typically lower than that of an equivalent key length symmetric key encryption system, these keys must be larger in size than the secret key set described above. These keys can be used in conjunction with the values presented in the on-chip timer block to, among other things, protect against "retransmission attacks." Since these keys are generated in a hurry, the way the keys are generated depends on some kind of random number generation system 180. Finally, care must be taken that the generated keys are not included in the class of so-called "weak" keys. The particular set of keys that are considered "vulnerable" depends on the specific encryption algorithm used.

동작 세부:Operation details:

보안 프로토콜의 실시예가 동작하는 방식은 몇 개의 별도의 처리, 즉 시스템 초기화, 보안 코드 발생 및 대량 분배, 보안 코드 로딩 및 실행, 키 리스트 데이터 구조 구성, 임시 라이센스 이전, 영구 라이센스 이전, 시스템 소유권 양도, 허가 취소 및 보안 시스템 갱신으로 나누어 질 수 있다. 상기 각 처리는 차례로 설명한다. 그러나, 이하에서 설명하는 예들은 설명의 간편성을 위하여 선택된 것이고, 이 프로토콜이 구현될 수 있는 가장 효과적인(유일한 것이 아님) 방법이라고 할 수는 없다.The manner in which an embodiment of a security protocol operates may include several separate processes: system initialization, security code generation and mass distribution, security code loading and execution, key list data structure construction, temporary license transfer, permanent license transfer, system ownership transfer, It can be divided into revoke permission and update security system. Each process described above is explained in turn. However, the examples described below are chosen for simplicity of explanation and are not to be the most effective (but not the only) way in which this protocol can be implemented.

시스템 초기화System initialization

이것은 목표 유닛의 비밀키(104)가 소정의 초기값으로 설정되는 단계이다. 이 절차는 2개의 비밀키 중의 어느 하나에 대하여 몇 개의 위치 중의 하나에서 달성될 수 있지만, 논리적인 이유 때문에, 일련 번호 또는 비밀키가 변경될 가능성이 있는 조립 과정의 최종 단계이어야 한다. 유닛(100)의 일련 번호가 오프칩으로 저장되는 경우에, 이 절차는 최종 조립 시점에서 수행될 가능성이 가장 높다. 유닛의 일련 번호(106)가 온칩으로 저장되면, 칩 제조 공정의 최종 지점(즉, 칩이 패키지된 후)에서 이 절차를 실행하는 것이 일반적이고, 따라서 임의의 후반작업(postproduction) 또는 번인 폴아웃(burn-in fall out)은 비기능성 부분을 골라내는 기회를 갖는다. 이 방법으로 안전하게 유지해야 할 데이터 양을 최호화한다. 전체 프로토콜의 보안은 유닛의 비밀키(104)의 보안에 기초하므로, 초기화 절차는 물리적인 보안이 가능한 시점에서 수행되어야 한다.This is a step in which the secret key 104 of the target unit is set to a predetermined initial value. This procedure can be accomplished in one of several locations for either of the two secret keys, but for logical reasons it should be the final step in the assembly process where the serial number or the secret key may be changed. If the serial number of the unit 100 is stored off chip, this procedure is most likely to be performed at the time of final assembly. Once the unit's serial number 106 is stored on-chip, it is common to execute this procedure at the final point in the chip manufacturing process (ie, after the chip is packaged), and therefore any postproduction or burn-in fallout. (burn-in fall out) has the opportunity to pick out non-functional parts. In this way, you minimize the amount of data you need to keep secure. Since the security of the entire protocol is based on the security of the unit's secret key 104, the initialization procedure should be performed at the point where physical security is possible.

1차 비밀키는 2차 비밀키를 공급하기 위해 사용되는 절차와 다른 절차에서 초기화(또는 장치에 "번(burn)"됨) 되어야 한다. 비록, 실제상으로, 이 2차 키는 소정 시점에서 공지되겠지만(2차 키가 제조 공정 중의 소정 시점에서 유닛에 프로그램되기 때문에) 관련된 유닛은 2차 키가 목표 장치(100)에 저장되었으면 어디에도 기록되어서는 안된다. 회계 감사의 목적으로, 2차 비밀키 값의 전체 집합에 대하여 어느 부분이 어떤 키를 보유하고 있는지를 아는 것과 무관하게 시험되는 것이 바람직하다(분배의 무작위성을 테스트하기 위해 또는 어떤 다른 이유로). 그러나, 시스템의 보안성을 유지하기 위해, 상기 2차 비밀키를 유닛에 프로그램하는 장치는 2차 비밀키를 제1 비밀키에 또는 목표 장치 일련 번호(106)에 관련시키는 어떠한 수단도 갖지 않는 것이 바람직하다. 또한, 상기 두 가지 비밀키는 뒤에서 설명하는 이유 때문에 변경 방지(tamper-proof) 방식으로 구현되어야 한다. 상기 2개의 비밀키가 어떤 순서로 초기화되는지는 문제가 되지 않는다. 예시적인 실시예에서 설명한 초기화 절차를 따르면, 목표 장치의 일련 번호(106) 및 그 관련 1차 비밀키가 공동으로 위치되는 (실제 칩이 아닌) 유일한 위치는 허가 기관의 보안 서버이어야 한다.The primary secret key must be initialized (or "burned" to the device) in a procedure different from the procedure used to supply the secondary secret key. Although in practice, this secondary key will be known at some point in time (because the secondary key is programmed into the unit at some point in the manufacturing process), the associated unit can be written anywhere if the secondary key has been stored in the target device 100. It should not be. For the purposes of auditing, it is desirable to test against the entire set of secondary secret key values irrespective of which part holds which key (to test randomness of distribution or for some other reason). However, in order to maintain the security of the system, the device programming the secondary secret key into the unit does not have any means of associating the secondary secret key with the first secret key or with the target device serial number 106. desirable. In addition, the two secret keys should be implemented in a tamper-proof manner for the reasons described later. It does not matter in what order the two secret keys are initialized. Following the initialization procedure described in the exemplary embodiment, the only location (not the actual chip) where the serial number 106 of the target device and its associated primary secret key are jointly located should be the security server of the authorization authority.

보안 코드 발생 및 대량 분배Security code generation and mass distribution

도 165를 참조하면, 예시적인 실시예에 있어서, 개발자(520)가 이 프로토콜 하에서 동작하는 애플리케이션을 생성하고자 한다고 가정하자. 상기 애플리케이션은 분해(disassembly)로부터 합리적으로 면역성을 갖는 것이고 특수한 장치에서만 실행될 수 있는 것이다. 각 등록된 개발자(520)는 허가 기관의 서버와 통신하기 위해, 및 임의의 공개된 코드 블록 또는 다른 비트스트림을 인증하기 위해 사용될 수 있는 부호화 메시지 인증 코드(MAC)(전형적으로 디지털 서명이라고 함)를 생성하기 위해 개발자가 사용하는 임의의 메시지를 인증하기 위해 사용되는 공개키/개인키 쌍을 갖고 있을 것이다.Referring to FIG. 165, assume that in an example embodiment, the developer 520 wants to create an application that operates under this protocol. The application is reasonably immune from disassembly and can only be run on special devices. Each registered developer 520 is an Encrypted Message Authentication Code (MAC) (typically referred to as a digital signature) that can be used to communicate with a server of a licensing authority and to authenticate any published code blocks or other bitstreams. It will have a public / private key pair that will be used to authenticate any message that the developer uses to generate a.

애플리케이션이 디버그(debug)된 후에, 애플리케이션은 최초 개발자에게만 알려져 있는 애플리케이션 지정 암호화 알고리즘 및 키를 이용하여 인코드된다. 상기 애플리케이션 지정 알고리즘 및 키는 대칭(비밀) 키 시스템 또는 비대칭(PKI) 키 기반 시스템일 수 있다. 암호화 코드 블록의 끝에는 MAC가 첨부되고, 이것은 개발자(520)에 의해 그들의 공개된 공개키/개인키 쌍의 개인키를 이용하여 부호화된다(따라서 암호화 코드 블록에 대하여 불명료하지 않은 디지털 서명을 형성한다). 디지털 서명 또는 최초 MAC와 대응하는 코드 지정 ID 번호는 허가 기관에 제공될 수 있다. 애플리케이션 개발자(520)는 또한 적당한 디코딩 키를 제공하도록 선택할 수 있다(이 결정의 교환조건에 대해서는 이 문서의 뒷부분에서 설명한다).After the application is debugged, the application is encoded using application specific cryptographic algorithms and keys known only to the original developer. The application specific algorithm and key may be a symmetric (secret) key system or an asymmetric (PKI) key based system. The end of the encryption code block is appended with a MAC, which is encoded by the developer 520 using the private key of their public / private key pair (thus forming an unambiguous digital signature for the encryption code block). . A digitally signed or coded ID number corresponding to the original MAC may be provided to the licensing authority. The application developer 520 may also choose to provide the appropriate decoding key (exchange conditions for this decision are discussed later in this document).

만일 애플리케이션 지정 알고리즘이 비대칭 암호화 시스템이면, 부호화 메시지 인증 코드(디지털 서명)를 생성하기 위해 사용한 동일한 공개 PKI 키 쌍을 사용하여 암호화할 필요가 없다. 그러나, 코드 블록의 끝에 저장된 MAC는 공지된 해싱 알고리즘을 이용하여 생성되어야 하고 또한 개발자의 공개된 공개키 중의 하나를 이용하여 부호화되어야 한다(따라서 디지털 서명을 형성한다). 이것은 목표가 공지의 해싱 함수 및 공지의 공개키를 이용하여 MAC의 인증을 검증할 수 있게 한다.If the application specific algorithm is an asymmetric encryption system, there is no need to encrypt using the same public PKI key pair used to generate the encoded message authentication code (digital signature). However, the MAC stored at the end of the code block must be generated using a known hashing algorithm and also encoded using one of the developer's public public keys (thus forming a digital signature). This allows the target to verify the authenticity of the MAC using known hashing functions and known public keys.

다시 도 162로 되돌아가서, 모든 애플리케이션 지정 암호화 키 데이터 구조(210)는 다수의 여분의 필드(복호키 자체(220)에 추가해서)를 포함할 수 있다. 이 필드 중의 하나는 타임스탬프(230) 및 관련 마스크 값(240)을 포함할 수 있다. 다른 필드는 "카운트다운 값"(250)을 포함할 수 있다. 마스크 값(240)은 다른 2개의 필드(230, 250)와 함께 사용되어 키가 유효로 된 때를 결정한다. 정확히 얼마나 많은 비트가 각 필드에 할당되었는지는 프로토콜과 관계가 없다는 점에 또한 주목하여야 한다.Returning to FIG. 162 again, every application specific encryption key data structure 210 may include a number of extra fields (in addition to the decryption key itself 220). One of these fields may include a timestamp 230 and an associated mask value 240. Another field may include a "countdown value" 250. The mask value 240 is used in conjunction with the other two fields 230 and 250 to determine when the key is valid. It should also be noted that the exact number of bits allocated to each field is independent of the protocol.

타임스탬프 값(230)은 타임스탬프 마스크(240) 필드에 저장된 비트 패턴에 따라서 몇 가지 방법으로 사용될 수 있다는 점에 주목한다. 타임스탬프 마스크(240) 값은 목표 유닛(100)의 현재 시간과 비교를 수행할 때 무시된 타임스탬프 도형(figure)의 일부 부분집합을 개발자(520)가 선택할 수 있게 한다. 그러나, 예로서, 타임스탬프 필드(230)에 의해 지원된 최소 해상도(resolution)가 1초라고 가정하면, 타임스탬프 데이터(230)의 하위 5비트를 제거함으로써 타임스탬프 필드(230)에 저장된 때로부터 시작하여 약 32초의 과정에서 사용될 때만 유효로 되는 특수한 키 데이터 구조(210)가 발생될 수 있다. 보안 프로토콜의 전체 기능은 타임스탬프 필드(230)의 최하위 순서 비트의 실제 해상도에 의존하지 않는다.Note that the timestamp value 230 can be used in several ways depending on the bit pattern stored in the timestamp mask 240 field. The time stamp mask 240 value allows the developer 520 to select some subset of the time stamp figures that were ignored when performing a comparison with the current time of the target unit 100. However, as an example, assuming that the minimum resolution supported by the timestamp field 230 is one second, from when stored in the timestamp field 230 by removing the lower five bits of the timestamp data 230. A special key data structure 210 can be generated that starts and becomes valid only when used in about 32 seconds. The overall functionality of the security protocol does not depend on the actual resolution of the least significant order bits of the timestamp field 230.

마스크 필드(240)와 관련된 다른 비트들이 있을 수 있고, 그 중 일부는 값이 타임스탬프(230)에서 지정되기 전에 키가 유효화되었는지 후에 유효화되었는지를 표시하기 위해 사용될 수 있다. 또다른 마스크 필드(240) 비트는 타임스탬프(230)와 "카운트다운" 값(250)이 어떻게 관련되는지를 표시하기 위해 사용될 수 있다. 예를 들면, 이것은 애플리케이션 개발자(520)의 의도가 특정 데이터 및 시간창(time window)에 단순히 결합하기 보다는, 특정 날짜 이전에 또는 후에 특정의 반복 횟수로 소프트웨어의 사용을 제한하는 것인 경우에 유용할 것이다. 물론, 이들 조건의 임의 조합이 구성될 수 있고, 따라서 프로토콜은 이 점에서 매우 융통성있는 것이다. 또한, 얼마나 많은 합법적 키 복사본이 최초 목표 유닛(100)으로부터 다른 유닛으로 동시에 분배될 수 있는지와 같은 다른 특성들을 표시하기 위한 추가의 플래그가 이 데이터 구조에 포함될 수 있다. 이것은 예를 들면 디지털 도서관에서 볼 수 있는 것처럼 다중 복사 허가가 필요한 경우에 유용할 것이다.There may be other bits associated with the mask field 240, some of which may be used to indicate whether a key has been validated or validated before the value is specified in the timestamp 230. Another mask field 240 bit may be used to indicate how time stamp 230 is associated with a "countdown" value 250. For example, this is useful when the intention of the application developer 520 is to limit the use of the software to a specific number of iterations before or after a particular date, rather than simply combining to specific data and time windows. something to do. Of course, any combination of these conditions can be constructed, so the protocol is very flexible in this respect. In addition, additional flags may be included in this data structure to indicate other characteristics, such as how many legal key copies can be distributed from the original target unit 100 to other units simultaneously. This may be useful if multiple copy permissions are required, for example as seen in digital libraries.

암호화 처리의 일 실시예를 나타내는 흐름도가 도 163에 도시되어 있다. 디지털 미디어 스트림 또는 소프트웨어 애플리케이션(미디어 스트림을 해석하기 위해 사용된 복호 명령어 등)을 분배하기 위해 사용된 처리들 간에 실질적인 차이는 없다는 점에 주목한다. 어느 경우이든, 온라인 서버를 통하여 또는 직렬화 디스크(표준 DVD 등)를 이용하여 암호화 코드 블록(310, 320)을 분배하기 위한 몇 가지 다른 옵션들이 있다. 후자의 경우에, 개발자(520)는 대량 생산된 디스크의 개별 일련 번호를 허가 기관(510)에 미리 등록하도록(또는 등록하지 않도록) 선택할 수 있다. 만일 등록하면, 일련 번호는 버스트 커팅 영역에 버닝(burning)함으로써(DVD의 경우) 또는 잉크젯 인쇄함으로써(표준 CD의 경우) 디스크에 영구적으로 첨부될 수 있다. 동일한 일련 번호가 대량 생산된 모든 디스크에 복제될 것이기 때문에, 개발자(520)는 일련 번호를 CD 또는 DVD의 데이터 영역에 매립(embed)할 수 없다는 점에 주목한다. 디스크의 일부가 대량 생산되고 다른 부분에 1회 기록되는 소정의 하이브리드 포맷이 사용되는 경우, 이것은 개별 일련 번호와 함께 디스크를 분배하는 다른 잠재적 방법이다. 어느 경우이든, 등록 과정에서 에러가 발생할 가능성이 적기 때문에 기계 판독가능 일련 번호가 확실히 바람직하다.A flowchart illustrating one embodiment of the encryption process is shown in FIG. Note that there is no substantial difference between the processes used to distribute the digital media stream or software application (such as the decoding instructions used to interpret the media stream). In either case, there are several other options for distributing encryption code blocks 310, 320 via an online server or using a serialized disc (such as a standard DVD). In the latter case, the developer 520 may choose to pre-register (or not register) the individual serial number of the mass-produced disk with the licensing authority 510. If registered, the serial number can be permanently attached to the disc by burning in the burst cutting area (for DVD) or by inkjet printing (for standard CD). Note that the developer 520 cannot embed the serial number in the data area of the CD or DVD because the same serial number will be duplicated on all the mass produced disks. If some hybrid format is used in which part of the disc is mass produced and written once in another part, this is another potential way of distributing the disc along with the individual serial number. In either case, machine-readable serial numbers are certainly desirable because there is less chance of errors occurring during the registration process.

만일 개발자(520)가 미디어 일련 번호를 허가 기관에 등록하지 않는 것을 선택하면, 적당한 암호화 키를 애플리케이션 또는 미디어 스트림 필드에 관련시킬 수 있는 소정의 다른 방법이 있다. 따라서, 애플리케이션 개발자(520)는 코드 지정 ID 또는 관련 미디어 일련 번호를 등록할 수 있다. 전자의 경우에, 애플리케이션은 자유롭게 분배될 수 있다(즉, 특수한 해제 포맷 및 미디어에 결합되지 않는다).If the developer 520 chooses not to register the media serial number with the licensing authority, there are some other ways in which the appropriate encryption key can be associated with the application or media stream field. Accordingly, application developer 520 may register a code designation ID or an associated media serial number. In the former case, the application can be freely distributed (ie not bound to a special release format and media).

개별 일련 번호 메카니즘의 경우에는 허가 기관(510)이 어떤 애플리케이션(또는 미디어 스트림)이 어떤 일련 번호와 관련되는지 알 필요가 없기 때문에(잠재적으로 표시가 없음), 최종 사용자의 프라이버시가 유지된다. 개발자(520)가 애플리케이션 ID(또는 미디어 스트림 ID)를 그 관련 키와 함께 등록하는 경우에, 허가 기관(510)은 어떤 애플리케이션 또는 미디어 스트림이 특수한 최종 사용자에 의해 "소유"되었다는 것을 알 수 있다. 반면에, 이 잠재적 프라이버시 결핍은 개발자(520)가 물리적 매체를 제조하여 분배할 것을 요구하지 않는 추가적인 편리성 및 비용 절감으로 상쇄된다. 용어 "물리적 매체"는 반드시 디스크를 의미하는 것이 아님에 주목한다. 이 기능은 매체에 첨부되는 개별 일련 번호 스티커와 함께 인쇄된 매뉴얼(또는 단순한 등록 양식)을 이용함으로써 달성될 수 있다. 필요한 것은 개발자(520)가 최종 사용자에게 공급되는 유일한 일련 번호를 가진 어떤 물체(object)를 생성해야 하는 것뿐이다. 이 일련 번호의 목적은 비트스트림 등록 번호로 사용하기 위한 것이다. 이 일련 번호가 프로토콜에서 어떻게 사용되는지는 다음 섹션에서 설명한다.In the case of an individual serial number mechanism, the end user's privacy is maintained because the permitting authority 510 does not need to know which application (or media stream) is associated with which serial number (potentially no indication). In the event that developer 520 registers an application ID (or media stream ID) with its associated key, authorization authority 510 may know that an application or media stream has been "owned" by a particular end user. On the other hand, this potential privacy deficiency is offset by additional convenience and cost savings that do not require the developer 520 to manufacture and distribute the physical medium. Note that the term "physical medium" does not necessarily mean a disc. This function can be accomplished by using a printed manual (or simple registration form) with individual serial number stickers attached to the medium. All that is needed is for the developer 520 to create an object with a unique serial number that is supplied to the end user. The purpose of this serial number is to use it as a bitstream registration number. How this serial number is used in the protocol is described in the next section.

도 163에 도시한 예에서, 암호화 소프트웨어 애플리케이션(또는 미디어 스트림)(310)과 머신 의존 복호 소프트웨어(330)는 둘 다 동일한 메카니즘을 이용하여 분배된다. 이것이 그 경우이고 암호화 코드 블록(310, 330)의 어느 하나 또는 둘 다가 온라인으로 또는 디스크를 인쇄함으로써 분배될 수 있다는 것은 프로토콜의 필요조건이 아니다. 그러나, 디지털 미디어 스트림의 경우에, 미디어 스트림 자체는 몇 개의 크기 등급만큼 2개의 블록(310, 330) 중에서 더 큰 것일 가능성이 높다는 것에 주목하여여 한다. 따라서, 그 경우에, 적어도 이 블록의 분배를 대량 생산 디스크 포맷으로 시행하는 것이 가장 사리에 맞는 일이다. 많은 경우에, 동반자 암호화 코드 블록(제1 블록을 디코드하는 방법에 대한 명령어를 포함하고 있는 것)뿐만 아니라 1차 암호화 코드 블록을 맞추기 위한 룸이 디스크에 충분히 있을 수 있다. 2개의 데이터 집합의 어느 것도 공개 후에 변경될 가능성은 없고, 따라서 그들이 온라인으로 분배되어야 한다는 기본적인 필요조건도 없다는 점에 또한 주목하여야 한다. 그래서 이들은 대량 생산 디스크 기반 분배 메카니즘에 적합하다. 2개의 코드 블록을 동일한 디스크에 배치하면 명백한 방식으로 하나를 다른 하나에 관련시키는 것이 더 쉬워진다.In the example shown in FIG. 163, both the encryption software application (or media stream) 310 and the machine dependent decryption software 330 are distributed using the same mechanism. It is not a requirement of the protocol that this is the case and that either or both of the encryption code blocks 310, 330 can be distributed online or by printing a disk. However, it should be noted that in the case of digital media streams, the media stream itself is likely to be the larger of the two blocks 310, 330 by several magnitude classes. In that case, therefore, it makes the most sense to enforce at least the distribution of this block in the mass production disk format. In many cases, there may be enough room on the disk to fit the primary encryption code block as well as the companion encryption code block (including instructions on how to decode the first block). It should also be noted that neither of the two data sets are likely to change after publication, and therefore there is no basic requirement that they be distributed online. Thus they are suitable for mass production disk based distribution mechanisms. Placing two blocks of code on the same disk makes it easier to relate one to the other in obvious ways.

보안 코드 로딩 및 실행Secure Code Loading and Execution

분배 메카니즘이 실제 디스크를 통해 달성되는 경우에, 소비자는 전통적인 소프트웨어 구매와 정확히 동일한 방식으로 애플리케이션을 내포한 디스크를 구매할 수 있다. 물론, 최종 사용자는 "목표" 유닛의 프로세서에서 수정되지 않은 암호화 코드 블록을 동작시키지 못할 수 있다. 사용자가 애플리케이션을 그들의 머신에서 동작시키려고 시도할 때, CPU(120)는 암호화 소프트웨어 블록을 로드하고, 소프트웨어 개발자의 공개키와 함께 코드 블록의 끝에 저장된 디지털 서명("부호화" MAC)을 이용하여 당해 코드 블록이 진정한 것인지 검증한다. 이것은 다른 범용 CPU(120)에 대한 제1 하드웨어 수정이 동작(play)으로 되는 경우이다. 상기 보안 코드의 블록을 로드하고 복호하는 처리는 도 164에 도시하였다.If the distribution mechanism is achieved via a physical disk, the consumer can purchase the disk containing the application in exactly the same way as a traditional software purchase. Of course, the end user may not be able to operate unmodified cryptographic code blocks in the processor of the "target" unit. When a user attempts to run an application on their machine, CPU 120 loads the cryptographic software block and uses the digital signature ("encoding" MAC) stored at the end of the code block along with the software developer's public key to code that code. Verify that the block is true This is the case when a first hardware modification to another general purpose CPU 120 is made play. The process of loading and decoding the block of security code is shown in FIG.

해싱 함수가 정확하게 계산되는 것(및 더 나아가 일반화 메시지 다이제스트와 "실제" 메시지 다이제스트의 비교가 유효인 것)을 보증하기 위해, CPU(120)는 이 해싱 함수를 보안 방식으로 수행하여야 한다. 따라서, 해싱 함수는 디코더 유닛의 하드웨어에 의해 직접 발생되거나 해싱 함수 자체가 "보안" 코드 블록을 이용하여 계산되어야 하고, 그 동작은 다른 "비보안" 프로그램에 의해 부정하게 변경될 수 없다.In order to ensure that the hashing function is correctly calculated (and further that the comparison of the generalized message digest with the "real" message digest is valid), the CPU 120 must perform this hashing function in a secure manner. Thus, the hashing function must be generated directly by the hardware of the decoder unit or the hashing function itself must be calculated using a "secure" code block, and its operation cannot be tampered with by other "non-secure" programs.

소프트웨어 기반 해시의 경우에, 이 보안 코드 블록은 유닛(100)의 보안 시스템의 일부로서 고려되어야 하고, 그래서 유닛(100)과 허가 기관(510) 간의 안전한 트랜잭션을 통해 플레이어에 다운로드될 수 있다. 충분히 흥미롭게, "보안" 해싱 함수의 확립은 여기에서 설명한 동일한 보안 프로토콜을 통해 달성될 수 있다. 보안 시스템의 모든 태양에 대한 이러한 회귀적 행동은 이 프로토콜의 소프트웨어 기반 버전이 그 암호화/복호 아키텍쳐에서 극히 유연하게(따라서 갱신가능하게) 할 수 있다.In the case of a software-based hash, this security code block must be considered as part of the security system of the unit 100 and so can be downloaded to the player via a secure transaction between the unit 100 and the authority authority 510. Interestingly enough, the establishment of a "secure" hashing function can be achieved through the same security protocol described herein. This recursive behavior for all aspects of security systems allows the software-based version of this protocol to be extremely flexible (and therefore updateable) in its encryption / decryption architecture.

메시지 다이제스트 계산이 하드웨어로 고정되면, 우리는 잠재적으로 어느 정도의 보안성을 얻을 수 있지만, 이것은 융통성의 희생을 요구한다. 전용 하드웨어 블록을 이용하여 해시 값을 생성하고, 그 다음에 칩이 제조된 후의 소정 시점에서 해싱 알고리즘의 어떤 약점이 발견되면(또는 그 구현시에 어떤 버그가 있으면), 그 사실을 안 후에 문제를 처리할 기회가 없다. 이것은 처리를 가속화하기 위해 소프트웨어 기반 해싱 함수(프로그램가능 S-박스 구조 등)에 대한 어떤 종류의 하드웨어 가속화를 사용할 수 없다는 것을 말하는 것이 아니다. 그러나, 그 경우에, 하드웨어는 이상적으로 매우 다양한 일방향 해싱 함수를 지원하기 위해 충분히 범용이어야 한다.If the message digest computation is fixed in hardware, we can potentially gain some security, but this requires a sacrifice of flexibility. If a dedicated hardware block is used to generate a hash value and then any weaknesses in the hashing algorithm are found at some point after the chip is manufactured (or if there are any bugs in its implementation), then the problem is known. There is no opportunity to deal with it. This is not to say that some kind of hardware acceleration for software-based hashing functions (such as programmable S-box structures) cannot be used to speed up processing. In that case, however, the hardware should ideally be general enough to support a wide variety of one-way hashing functions.

그러나, 이 프로토콜의 보안은 궁극적으로 이 보안 코드 로딩 절차의 일부로서 제공된 최저 수준 기능에 의존한다는 것에 주목하여야 한다. 저수준 특징(해싱 함수에서 사용된 비밀키 또는 원시 연산 등)은 다른 방법으로 함께 결합되어 부호화 메시지 다이제스트와 같은 고수준 기능을 생성한다. 다음에, 상기 고수준 기능 블록을 사용하여 아이덴티티 검증과 같은 고수준 유틸리티를 제공한다. 보다 원시층의 위에 고수준 기능을 구축하는 이러한 처리는 "신뢰 사슬(Chain of Trust)" 구축이라고 알려져 있다. 시스템의 융통성은 보안 관련 기능이 이 계층구조 내에서 가능한 한 낮게 수정될 수 있는 지점의 배치에 있다. 그러나, 소정 지점에서, 상기 사슬이 기초하는 기본적인 원시 연산은 본질적으로 원자이어야 한다(즉, 이것은 하드웨어에서 구현되어야 하는 기능의 최저 수준이다). 이 하드웨어 입상 지점의 정확한 선택은 대부분 구현예의 세부이고, 이 프로토콜의 전체 동작은 위에서 주어진 조건의 이러한 태양에 의존하지 않는다.However, it should be noted that the security of this protocol ultimately depends on the lowest level functionality provided as part of this secure code loading procedure. Low-level features (such as secret keys or primitives used in hashing functions) are combined together in other ways to create high-level features such as encoded message digests. The high level functional block is then used to provide a high level utility such as identity verification. This process of building high-level functions on top of the primitive layer is known as building a "Chain of Trust." The flexibility of the system lies in the placement of points where security-related functions can be modified as low as possible within this hierarchy. However, at some point, the basic primitive operations on which the chain is based should be essentially atomic (ie, this is the lowest level of functionality that must be implemented in hardware). The exact choice of this hardware winning point is mostly an implementation detail, and the overall operation of this protocol does not depend on this aspect of the conditions given above.

암호화 코드 블록(310)이 목표의 메모리 스페이스(110)에 로드되고 메시지 다이제스트가 계산되면, 그 결과는 개발자의 공개키를 가진 암호화 코드(310)와 함께 저장된 디지털 서명(340)을 복호함으로써 계산된 메시지 다이제스트와 비교된다. 2개가 일치하면 목표 유닛(100)은 암호화 코드 블록(310)이 진정한 것(또는 적어도 코드가 디지털 서명을 복호하기 위해 자신의 공개키를 사용한 개발자(520)에 의해 분배된 것)임을 확신할 수 있다.Once the encryption code block 310 is loaded into the target memory space 110 and the message digest is calculated, the result is calculated by decrypting the digital signature 340 stored with the encryption code 310 with the developer's public key. Compared to the message digest. If the two match, the target unit 100 can be sure that the cryptographic code block 310 is true (or at least the code has been distributed by the developer 520 using its public key to decrypt the digital signature). have.

이 시점에서, 목표(100)는 복호키의 복사본을 요구하는 허가 기관(510)에 보안 메시지를 전송하고, 보안 메시지는 최근에 검증한 암호화 코드 블록과 제휴하여 사용될 것이다. 허가 기관과의 보안 접속을 설정하는 일환으로서, 목표 유닛(100)은 임시 공개키/개인키 쌍을 발생한다(그 중 공개 부분은 허가 기관(510) 서버에 제공된다). 키 교환 절차의 세부는 잘 알려져 있으므로 이것을 달성하는 정확한 메카니즘까지 여기에서 설명할 필요는 없을 것이다. 어느 경우이든 목표 유닛(100)과 허가 기관(510)의 중앙 서버 간의 전체 네트워크 트래픽은 상당히 작은 데이터 집합으로 제한되는데, 그 이유는 데이터 집합이 함께 저장된 몇 개의 키 전송, 코드 지정 ID 및 MAC로 구성되기 때문이다.At this point, the target 100 sends a secure message to the authorization authority 510 requesting a copy of the decryption key, which will be used in conjunction with a recently validated cryptographic code block. As part of establishing a secure connection with the authorization authority, the target unit 100 generates a temporary public key / private key pair, the public portion of which is provided to the authorization authority 510 server. The details of the key exchange procedure are well known and need not be described here until the exact mechanism that achieves it. In either case, the total network traffic between the target unit 100 and the central server of the authority authority 510 is limited to a fairly small data set, which consists of several key transmissions, coded IDs, and MACs with the data set stored together. Because it becomes.

코드 지정 ID(260)가 허가 기관(510)에서 인식하고 있는 것이라고 가정하면, 애플리케이션 창조자가 피요청 복호키의 "명문(clear)" 복사본을 이미 허가 기관(510)에 제공하였는지 여부에 따라서 2가지의 가능한 동작 과정이 있을 수 있다. 개발자(520)가 허가 기관(510)에 그러한 정보를 제공하지 않은 경우에는 중앙 서버가 목표 장치의 임시 공개키의 복사본(및 당해 코드 지정 ID(260))을 애플리케이션 개발자의 서버에 전송한다. 그 시점에서, 개발자의 서버는 피요청 복호키(목표 장치의 임시 공개키로 암호화한 것)를 내포한 메시지 및 적절히 복호된 코드로부터 생성한 메시지 다이제스트로 허가 기관(510)에 응답한다. 이러한 방법으로, 목표 장치(100)는 메시지를 복호하여 애플리케이션 지정 복호키를 얻을 수 있고, 허가 기관(510)은 명문 형식의 복호키에 액세스하지 않을 것이다.Assuming that code designation ID 260 is recognized by permitting authority 510, there are two ways depending on whether the creator of the application has already provided a permitting authority 510 with a "clear" copy of the requested decryption key. There may be a possible operating process. If the developer 520 did not provide such information to the authorization authority 510, the central server sends a copy of the temporary public key of the target device (and the corresponding code designation ID 260) to the application developer's server. At that point, the developer's server responds to the authorization authority 510 with a message containing the requested decryption key (encrypted with the temporary public key of the target device) and a message digest generated from the appropriately decrypted code. In this way, the target device 100 can decrypt the message to obtain an application specific decryption key, and the authorization authority 510 will not have access to the decryption key in the prestigious format.

비록 메시지 다이제스트가 미리 계산되어 허가 기관 서버에 저장되지만, 메시지 다이제스트가 트랜잭션 중에 개발자(520)에 의해 제공될 수 있다는 사실은 해싱 함수(메시지 다이제스트를 생성하기 위해 사용한 것)가 변경되어야 하는 경우에 잠재적으로 사용된다. 이러한 일이 발생하면, 개발자(520)는 복호된 코드 메시지 다이제스트의 갱신된 버전을 목표 장치(100)와의 실제 트랜잭션 전에 또는 트랜잭션 중에 허가 기관(510)에 제공할 필요가 있다. 허가 기관(510)이 최초의 (복호된) 코드에 액세스하지 않기 때문에 개발자(520)는 이 정보를 제공해야 한다. 앞에서처럼, 허가 기관 서버와 개발자 서버 간의 네트워크 트래픽 양은 여전히 매우 작다. 개발자(520)로부터 수신한 암호화 키는 허가 기관(510)으로부터 목표 장치로 전송되기 전에 목표 장치의 1차 비밀키를 이용하여 다시 암호화된다. 이 제2 암호화는 다른 트랜잭션의 일부로서 개발자측에서 실제로 실행될 수 있지만, 그 경우 개발자는 잠재적으로 목표 장치의 1차 키에 액세스하는데(양측의 키가 어떤식으로든 결합되어 있지 않는 한), 이것은 최종 사용자에 대하여 프라이버시 문제의 잠재적 손실을 가져온다.Although the message digest is precomputed and stored on the authority authority server, the fact that the message digest can be provided by the developer 520 during the transaction is a potential case where the hashing function (which was used to generate the message digest) must be changed. Used as If this happens, the developer 520 needs to provide the authorized authority 510 with an updated version of the decoded code message digest before or during the actual transaction with the target device 100. The developer 520 must provide this information because the authorization authority 510 does not have access to the original (decoded) code. As before, the amount of network traffic between the license authority server and the developer server is still very small. The encryption key received from the developer 520 is encrypted again using the primary secret key of the target device before being sent from the authorization authority 510 to the target device. This second encryption can actually be executed on the developer side as part of another transaction, but in that case the developer potentially accesses the primary key of the target device (unless the keys on both sides are combined in some way), which is the final It results in potential loss of privacy issues for the user.

애플리케이션 개발자(520)가 허가 기관(510)과 목표 장치(100) 간의 트랜잭션을 위하여 "루프외(out of the loop)"에 머무르기를 원하는 경우, 명문(암호화되지 않은) 형식의 관련 복호키의 복사본 및 복호된 코드 블록의 관련 MAC(그 값은 해싱 알고리즘이 변경된 때마다 갱신되어야 한다)를 허가 기관(510)에 간단히 제공할 수 있다. 따라서, 허가 기관(510)의 중앙 서버는 독립적으로 동작할 수 있고 목표 장치(100)로부터의 키 요청을 충족시키기 위하여 개발자 서버에 대한 통신 링크를 확립할 필요가 없다. 그러나, 이것은 상기 "명문 키" 정보가 허가 기관에 의해 의도적으로 또는 비의도적으로 절충되는 경우 개발자에게 잠재적인 보안 위험을 야기한다.If the application developer 520 wishes to stay "out of the loop" for a transaction between the authorization authority 510 and the target device 100, a copy of the associated decryption key in the noble (unencrypted) format. And the associated MAC of the decoded code block, the value of which must be updated each time the hashing algorithm changes. Thus, the central server of the authority authority 510 can operate independently and does not need to establish a communication link to the developer server in order to satisfy the key request from the target device 100. However, this poses a potential security risk to the developer if the "prestige key" information is intentionally or unintentionally compromised by the licensing authority.

전체적인 키 암호화/복호 처리의 흐름도는 도 165에 도시되어 있다. 이 경우에, 명문 키는 (위에서처럼) 전송 전에 목표 장치의 임시 공개키 및 다시 목표 장치의 1차 비밀키를 이용하여 암호화된다. 이 시점에서, 목표 장치(100)는 두번 암호화된 포맷으로 적당한 복호키를 갖는다. 허가 기관(510)이 명문의 애플리케이션 지정 키(550) 정보에 액세스하지 않는 경우에, 의도된 목표 장치(100)가 아닌 누군가가 이 키 데이터를 명문 형식으로 재생산하는 것은 불가능하다. 왜냐하면, 각 유닛(100)의 비밀키는 허가 기관(510)에만 알려져 있고, 전송을 위한 개인키는 목표 장치(100)에 의해서만 공지되기 때문이다.A flowchart of the overall key encryption / decryption process is shown in FIG. In this case, the prestigious key is encrypted using the temporary public key of the target device and again the primary secret key of the target device (as above) before transmission. At this point, the target device 100 has the appropriate decryption key in twice encrypted format. If the authority 510 does not have access to the prestigious application specific key 550 information, it is impossible for anyone other than the intended target device 100 to reproduce this key data in the prestigious format. This is because the secret key of each unit 100 is known only to the authority 510 and the private key for transmission is known only by the target device 100.

그러나, 이 시점에서, 목표 장치(100)가 애플리케이션 개발자(520)로부터 수신한 인코드된 복호키는 목표 장치(100)의 개방시에 안전하게 저장될 수 없다(예를 들면, 플래시 ROM에 또는 하드드라이브에 백업됨). 목표 장치(100)는 허가 기관(510)으로부터 전송된 인코드된 복호키와 함께 임시 비밀키의 복사본을 또한 저장해야 한다는 점에 문제점이 있다. 만일 허가 기관(510)의 누군가가 어떤 수단에 의해 상기 2편의 데이터에 액세스하였으면, 그들은 잠재적으로 복호 애플리케이션 지정 키(550)를 재구성할 수 있다(그들은 목표 장치(100)의 1차 비밀키에도 또한 액세스할 것이다).However, at this point, the encoded decryption key received by the target device 100 from the application developer 520 may not be stored securely upon opening of the target device 100 (eg, in a flash ROM or hard drive). Backed up to a drive). The target device 100 has a problem in that it must also store a copy of the temporary secret key along with the encoded decryption key sent from the authorization authority 510. If someone at the authority 510 has accessed the two pieces of data by some means, they can potentially reconstruct the decryption application designation key 550 (they will also be in the primary secret key of the target device 100). Will access).

이것은 목표 장치의 2차 비밀키가 사용으로 되는 지점이다. 이 2차 비밀키는 목표 장치의 복호 유닛 외의 누구에게도 알려져 있지 않다는 것을 상기하자. 따라서, 키를 복호하기 위해 허가 기관으로부터 목표 장치(100)에 공급된 임시 개인키를 사용하였으면, 2차 비밀키가 애플리케이션 지정 키를 그 사용(및/또는 보관) 전에 재암호화하기 위해 사용된다.This is the point where the secondary secret key of the target device is used. Recall that this secondary secret key is unknown to anyone other than the decryption unit of the target device. Thus, if the temporary private key supplied to the target device 100 from the authorization authority was used to decrypt the key, the secondary secret key is used to re-encrypt the application-specific key before its use (and / or storage).

그 다음에, 목표 장치는 애플리케이션 지정 (명문) 키(550)를 이용하여 코드 블록(또는 미디어 스트림)을 복호한다. 따라서, 애플리케이션 코드가 명문 형태로 존재하는 단지 2개의 장소가 최초 개발자(520) 자체에 및 목표 장치의 I-캐시(110)의 "보안" 부분 내측에 있다(이곳에서 애플리케이션 코드가 실행될 수 있고 메모리에 명문 형태로 다시 기록되지 않는다). 이것은 사용자와 허가 기관(510) 간의 프라이버시를 허용한다. 다시 말해서, 허가 기관(510)은 사용자가 허가받은 것이 무엇인지 알지 못하지만(거대한 프라이버시 장점), 목표 장치(100)가 손상되거나 분실되거나 또는 다른 방법으로 동작불능으로 된 경우에 사용자 키 리스트에 대한 보관소(또는 백업)으로서 여전히 동작할 수 있다.The target device then uses the application specific (preface) key 550 to decrypt the code block (or media stream). Thus, there are only two places where the application code exists in prestigious form, within the initial developer 520 itself and inside the "secure" portion of the I- cache 110 of the target device (where the application code can run and memory Are not rewritten in noble form). This allows privacy between the user and the authority 510. In other words, the permitting authority 510 does not know what the user is authorized (a huge privacy advantage), but the archive for the user key list if the target device 100 is damaged, lost or otherwise inoperable. It can still work as (or back up).

복호 처리가 정확하게 수행되었는지 검증하기 위한 체크로서, 적절히 복호된 코드의 메시지 다이제스트는 그 다음에, 최초 개발자(520)로부터 허가 기관(510)을 통하여 목표 장치(100)에 전송된, 디지털 서명을 복호함으로써 생성된 메시지 다이제스트와 비교된다. 위에서 언급한 바와 같이, 이 디지털 서명은 애플리케이션 개발자의 개인키로 비암호화 코드 블록의 메시지 다이제스트를 암호화함으로써 생성된다. 대안적으로, 이 디지털 서명은 접속이 확립되었을 때 허가 기관(510)에 공급하였던 다른 임시 공개키(530)를 이용하여 개발자(520)에 의해 다시 암호화될 수 있다. 어쨌든, 올바른 메시지 다이제스트는 그 다음에 개발자의 공개키로 디지털 서명을 복호함으로써 목표 장치(100)에 의해 디코드될 수 있다. 만일 이 메시지 다이제스트가 복호 코드 블록의 MAC와 일치하면, 코드는 진정한 것으로 고려되고 목표 장치(100)에서의 동작이 허용된다. 이 메시지 다이제스트는 재암호화된 애플리케이션 지정키(550)와 함께 보관하기 위하여 목표 장치의 2차 키(540)로 재암호화될 수 있다.As a check to verify that the decryption process was performed correctly, the message digest of the appropriately decoded code is then decoded the digital signature, sent from the original developer 520 to the target device 100 via the authorization authority 510. Is compared with the generated message digest. As mentioned above, this digital signature is generated by encrypting the message digest of an unencrypted code block with the application developer's private key. Alternatively, this digital signature can be encrypted again by the developer 520 using another temporary public key 530 that was supplied to the authorization authority 510 when the connection was established. In any case, the correct message digest can then be decoded by the target device 100 by decrypting the digital signature with the developer's public key. If this message digest matches the MAC of the decode code block, the code is considered true and operation at the target device 100 is allowed. This message digest may be re-encrypted with the secondary key 540 of the target device for storage with the re-encrypted application designation key 550.

이 절차에서의 마지막 단계는 애플리케이션 지정키(560)의 (목표 장치의 2차 키(540)로) 새로 암호화된 버전이 보관 목적으로 허가 기관(510) 서버에 다시 재전송된다. 이 전송 서버는 몇 가지 목적으로 사용된다. 첫째, 목표 장치(100)가 코드 블록을 적절히 복호할 수 있었음을 통지하는 것이다. 둘째, 최종 사용자가 어떤 종류의 파국적인 데이터 장애를 받고 그들 자신의 액세스 키에 대한 백업 카피를 만드는 것을 게을리한 경우를 취급하기 위해 허가 기관(510)이 상기 암호화 키(560)의 복사본을 가질 필요가 있다. 그 다음에, 허가 기관(510)은 임의의 특정 사용자에 대해 백업 스토리지 설비로서 동작할 수 있다. 상기 절차의 또다른 이유는 특수한 목표 장치(100)가 하나의 사용자로부터 다른 사용자로 그 소유권을 변경한 경우 또는 사용자가 자신의 목표 장치(100)를 업그레이드하고자 하는 경우를 취급하기 위해서이다. 이러한 종류의 소유권 영구 양도는 그 유닛(100)에 대한 모든 허가된 애플리케이션 키의 양도를 수반할 수 있다(이 경우에, 그 유닛을 새로운 소유자 이름으로 재등록하는 것 외에 할 것은 아무것도 없다). 그러나, 사용자가 자신의 키 데이터의 영구적인 소유권을 제1 장치로부터 제2 장치로 이전하기 원하면, 이것은 허가 기관(510)과 2개의 목표 장치 간의 보안 트랜잭션에 의해 달성될 수 있다.The final step in this procedure is that the newly encrypted version of the application designation key 560 (with the secondary device 540 of the target device) is retransmitted back to the authorization authority 510 server for archiving purposes. This transport server is used for several purposes. First, the target device 100 notifies that the code block could be properly decoded. Second, the authorization authority 510 needs to have a copy of the encryption key 560 to handle cases where end users are suffering some sort of catastrophic data failure and neglect to make backup copies of their own access keys. There is. The authority authority 510 may then act as a backup storage facility for any particular user. Another reason for the above procedure is to handle the case where the special target device 100 changes its ownership from one user to another user, or when the user wants to upgrade his or her target device 100. This kind of permanent ownership transfer can involve the transfer of all authorized application keys for that unit 100 (in this case, there is nothing else to do except to re-register that unit with a new owner name). However, if the user wishes to transfer permanent ownership of his key data from the first device to the second device, this can be achieved by a secure transaction between the authorization authority 510 and the two target devices.

목표 장치(100)가 허가 기관(510) 서버에 다시 전송하는 다른 정보는 목표 장치의 새로 갱신된 키 리스트 데이터 구조(610)(도 166에 도시됨)의 메시지 다이제스트이다. 이것은 새로 갱신된 키 리스트 데이터 구조(610)의 승인(acknowledgement)이고, 허가 기관(510) 서버 및 목표 장치(100)에서 상기 특수한 목표 장치(100)와 관련된 키 리스트 데이터 구조(610)의 동일성을 검증하기 위해 또한 사용된다. 이 데이터 구조의 정확한 구성은 다음 섹션에서 설명한다. 우리는 또한 특수 키 또는 키 집합의 소유권의 영구 양도를 달성하는 방법에 대하여 뒤의 섹션에서 설명할 것이다.Another information that the target device 100 sends back to the authorization authority 510 server is the message digest of the target device's newly updated key list data structure 610 (shown in FIG. 166). This is an acknowledgment of the newly updated key list data structure 610 and the identity of the key list data structure 610 associated with the special target device 100 at the authorization authority 510 server and the target device 100. It is also used to verify. The exact organization of this data structure is described in the next section. We will also explain in a later section how to achieve a permanent transfer of ownership of a special key or set of keys.

이 시점에서, 위에서 설명한 프로세스는 애플리케이션 지정키(550)를 개발자(520)로부터 목표 장치(100)로 이전하기 위해 프로토콜을 사용하는 유일한 방법이 아니라는 점에 주목하여야 한다. 예를 들면, 실제 키 전송 트랜잭션은 목표 장치(100)와 애플리케이션 개발자(520) 사이에서만의 직접 접속을 수반할 수 있다. 그러나, 이 경우에 장치 지정 암호화 정보를 트랜잭션에 제공하기 위해 개발자 서버와 허가 기관 서버 간에 접속이 확립되어야 한다. 보안 방식으로 작업하기 위해 이 프로토콜이 만들어질 수 있는 다수의 메카니즘이 있고, 위에서 설명한 예는 이 메카니즘들 중의 하나일 뿐이다. 그러나, 공통의 스레드(thread)는 목표 장치(100)에 전송된 키 데이터가 그 목표 장치(100)에 대해서만 사용할 수 있다는 것을 보증하기 위해 3개의 당사자 모두가 함께 작용해야 한다는 것이다.At this point, it should be noted that the process described above is not the only way to use the protocol to transfer application specific key 550 from developer 520 to target device 100. For example, the actual key transfer transaction may involve a direct connection only between the target device 100 and the application developer 520. In this case, however, a connection must be established between the developer server and the authorization authority server in order to provide device-specific encryption information to the transaction. There are a number of mechanisms by which this protocol can be created to work in a secure manner, and the example described above is just one of these mechanisms. However, a common thread is that all three parties must work together to ensure that key data sent to the target device 100 is available only for that target device 100.

키의 구조는 2개의 부분, 즉 하드웨어 지정 부분과 애플리케이션 지정 부분을 갖도록 설정될 수 있다는 것에 주목한다. 상기 2개의 부분이 완전히 불가분성인 것은 필요조건이 아니다. 만일 이들이 불가분성이면, 우리는 위에서 설명한 특성들을 정확히 취하게 된다. 그러나, 키 부분들이 독립적으로 동작하게 하는 방법이 있으면, 우리는 총체적인 복사본 집합을 얻을 수 있고, 실제 코드 또는 실제 목표 장치(100)와 무관한 제약들을 사용할 수 있다. 다시 말해서, 임의의 개발자(520)는 분배에 제약이 없지만 판독할 수 없고 실행만 가능한 애플리케이션 또는 미디어 스트림을 공개할 수 있다. 이것은 허가 기관(510)이 제조자에 관계없이 모든 장치에서 동작하는 보안 시스템 갱신을 송출하기 원하는 경우에 유용할 수 있다. 이것의 다른 예는 스트림의 저작권에 대한 제어를 여전히 유지하면서 공개적으로 이용가능한 미디어 스트림의 방송일 것이다. 유사하게, 공개자는 누군가가 판독 및/또는 복사할 수 있지만 하나의 특수한 목표 장치(100) 또는 장치들의 집합에서 실행만 가능한 애플리케이션을 분배할 수 있다. 이것은 예를 들면 "이 특수 종류의 장치 갱신" 메시지를 송출할 때 유용하다. 다른 가능한 응용은 어디에서든 동작할 수 있고 분배에 제약이 없는 애플리케이션을 송출하는 것이다. 이것은 특수한 응용(즉, 개방 소스 분배)을 위해 소스 코드를 공개하는 것과 본질적으로 유사하다. 분리가능한 H/W 지정 및 S/W 지정 키 구조에 의해 가능하게 되는 다른 종류의 보안은 표 1에 도시하였다.Note that the structure of the key can be set to have two parts, a hardware specific part and an application specific part. It is not a requirement that the two parts are completely inseparable. If they are inseparable, we take exactly the characteristics described above. However, if there is a way to make the key parts operate independently, we can get a complete copy set and use constraints independent of the actual code or the actual target device 100. In other words, any developer 520 can publish an application or media stream that is unrestricted but unreadable and executable only. This may be useful if the licensing authority 510 wants to issue a security system update that operates on all devices regardless of the manufacturer. Another example of this would be the broadcast of a publicly available media stream while still maintaining control over the copyright of the stream. Similarly, a publisher can distribute an application that anyone can read and / or copy but can only run on one particular target device 100 or set of devices. This is useful, for example, when sending a "Update this special kind of device" message. Another possible application is to send an application that can operate anywhere and is not restricted by distribution. This is essentially similar to publishing the source code for special applications (ie open source distribution). Other types of security enabled by separable H / W designation and S / W designation key structures are shown in Table 1.

[표 1]TABLE 1

<분리 가능한 하드웨어 지정 및 애플리케이션 지정 키 구조><Separable hardware-specific and application-specific key structure>

키 리스트 데이터 구조 구성The key list data structure

이제 도 166을 살펴보면, 특수 목표 장치(100)에 허가된 애플리케이션 또는 미디어 지정 키를 내포한 데이터 구조(610)는 가치있는 상품(commodity)이고, 그래서 소유자에 의해 백업될 수 있어야 한다. 개별 키들은 목표 장치의 2차 비밀키로 (위에서 설명한 것처럼) 암호화되기 때문에, 그 리스트는 키들이 허가된 유닛에만 유용하다. 그러나, 우리는 이 데이터 구조(610)가 부정한 변경, 훼손 및/또는 완전한 손실로부터 안전하다는 것을 확실하게 할 필요가 있다. 손실된 키 리스트 데이터 구조의 경우에, 전체 데이터 구조(610)는 그 특수 목표 장치(100)에 대한 키 리스트의 새로운 복사본을 위에서 설명한 것처럼 허가 기관(510)으로부터 요청함으로써 복구될 수 있다. 키 리스트 데이터 구조에 대하여 임의 변경이 이루어진 경우에(그러한 시나리오의 이유에 대해서는 이 섹션에 이어지는 섹션에서 설명할 것이다), 프로토콜은 그러한 변경을 임시인 것으로 식별하는 수단을 수용할 수 있다. 마지막으로, 우리는 키 리스트 데이터 구조(610)의 진정성, 적시성 및 유효성을 유효화하기 위한 소정의 위조 방지 메카니즘을 포함한다.Referring now to FIG. 166, data structure 610 containing an application or media specific key authorized to special target device 100 is a valuable commodity, and so should be able to be backed up by the owner. Since the individual keys are encrypted (as described above) with the secondary secret key of the target device, the list is only useful for the unit for which the keys are authorized. However, we need to ensure that this data structure 610 is safe from fraudulent alteration, corruption and / or complete loss. In the case of a lost key list data structure, the entire data structure 610 may be recovered by requesting a new copy of the key list for that special target device 100 from the authorization authority 510 as described above. If any changes have been made to the key list data structure (the reasons for such a scenario will be described in the sections following this section), the protocol may accept a means of identifying such changes as temporary. Finally, we include some anti-counterfeiting mechanisms to validate the authenticity, timeliness, and validity of the key list data structure 610.

이러한 필요조건을 염두에 두고서, 도 166에 도시한 것과 유사한 방법으로 상기의 모든 품질을 나타내는 안전한 키 리스트 데이터 구조(610)를 구성할 수 있다. 평소와 같이, 도시된 예는 모든 소망하는 특성들을 그러한 데이터 구조에 포함시킬 수 있는 유일한 방법이 아니다. 그럼에도 불구하고, 도 166에 도시한 특수한 데이터 구조는 사실상 프로토콜의 모든 기본적인 필요조건을 충족시킨다.With this requirement in mind, a secure key list data structure 610 representing all of the above qualities can be constructed in a manner similar to that shown in FIG. As usual, the illustrated example is not the only way to include all desired properties in such a data structure. Nevertheless, the special data structure shown in FIG. 166 satisfies virtually all basic requirements of the protocol.

위의 도표에서 주목해야 할 몇 가지 법칙이 있다. 첫번째는 키 리스트 데이터 구조(610)의 최상위 암호화는 목표 장치의 1차 비밀키로 수행되어야 한다는 것이다. 이러한 특수한 키를 이용하는 데는 몇 가지 이유가 있지만, 그 중 중요한 것은 데이터 구조의 국부적 복사본(local copy)이 복원되어야 하는 경우에 허가 기관(510)이 이 데이터 구조의 암호화 형태를 목표 장치(100)와 무관하게 재생성할 수 있어야 한다는 것이다. 이 데이터 구조를 암호화하기 위해 임의의 다른 키(예를 들면, 목표 장치의 2차 비밀키)가 사용되면, 목표 장치가 데이터 구조를 변경할 필요가 있을 때(키가 리스트에 추가되는 경우처럼) 전체 리스트가 백업 목적으로 허가 기관(510)에 전송되어야 한다. 이것은 허가 기관(510)에 다시 전송해야 할 네트워크 트래픽 양을 잠재적으로 크게 증가시킬 수 있으며, 이것은 반드시 채널 대역폭의 가장 효율적인 사용이라고 볼 수 없다.There are several laws to note in the chart above. The first is that the highest level encryption of the key list data structure 610 should be performed with the primary secret key of the target device. There are several reasons for using this special key, but the most important of these is that if a local copy of the data structure is to be restored, the authorization authority 510 will convert the encryption form of this data structure to the target device 100. It must be able to regenerate regardless. If any other key (for example, the secondary secret key of the target device) is used to encrypt this data structure, the entire time when the target device needs to change the data structure (such as when a key is added to the list) The list should be sent to the authority 510 for backup purposes. This can potentially significantly increase the amount of network traffic that must be sent back to the authority 510, which is not necessarily the most efficient use of channel bandwidth.

또한, 이 키 리스트 데이터 구조(610)는 표준 애플리케이션 또는 미디어 스트림 지정 허가 키의 저장용으로 사용되는 것 외에 보안 시스템 관련 키의 저장용으로 사용되는 것이 바람직하다. 이 데이터 구조는 허가 기관(510)에 의해 재생성될 수 있기 때문에, 목표 장치에서 동작하는 보안 소프트웨어를 갱신하는 것이 바람직한 경우에, 이것은 동일한 키 리스트 데이터 구조(610)가 2가지 기능으로 사용될 수 있는 경우 (목표 장치(100)의 코드 저장 필요조건의 입장에서) 더 안전하고 더 효율적일 것이다.The key list data structure 610 is also preferably used for storage of security system related keys in addition to being used for storage of standard applications or media stream specific permission keys. Since this data structure can be regenerated by the authority 510, in the case where it is desirable to update the security software running on the target device, this is the case when the same key list data structure 610 can be used with two functions. It will be safer and more efficient (in terms of code storage requirements of target device 100).

두번째 이슈는 키 리스트 데이터 구조(610)의 암호화 버전이 최초 키 리스트 데이터 구조(610)의 메시지 다이제스트를 포함한다는 것이다. 비록 각각의 개별적인 키들이 암호화되지만, 리스트 자체의 다른 부분은 메시지 다이제스트가 계산되는 시점에서 별도로 암호화되지 않는다는 점에 주목하여야 한다. 메시지 다이제스트 계산에 이어서, 전체 키 리스트 데이터 구조(610)(메시지 다이제스트를 포함함)는 최상위(또는 마스터) 키에 의해 식별된 키 값 및 알고리즘으로 암호화된다. 이것은 악의있는 제3자가 리스트를 부정하게 변경하고 새로운 메시지 다이제스트를 계산하며 진정한 리스트를 수정된 리스트로 대체하는 것을 금지하기 위해 수행된다. 키 리스트 데이터 구조(610)가 목표 장치(100)의 메모리 스페이스에 읽어 들여질 때, 이 (복호된) 메시지 다이제스트는 MAC가 임의의 다른 보안 암호화 코드 블록에 대하여 사용된 방법과 동일한 방법으로 키 리스트 자체의 진정성 및 유효성을 검증하기 위해 사용된다. 개별 키 외의 모든 요소들이 마스터 키로만 암호화된다는 사실은 리스트가 최상위 키 외의 임의의 키에 액세스할 필요가 없이 관통될 수 있음(및 리스트가 유지됨)을 의미한다. 또한, 키 리스트 목록(inventory)은 복호 블록의 단일 통과만으로 편집될 수 있다.The second issue is that the encrypted version of the key list data structure 610 includes the message digest of the original key list data structure 610. Note that although each individual key is encrypted, other parts of the list itself are not encrypted separately at the time the message digest is calculated. Following the message digest calculation, the entire key list data structure 610 (including the message digest) is encrypted with the key value and algorithm identified by the top (or master) key. This is done to prevent malicious third parties from tampering with lists, calculating new message digests, and replacing true lists with modified lists. When the key list data structure 610 is read into the memory space of the target device 100, this (decoded) message digest is the same as the method used by the MAC for any other secure encryption code block. It is used to verify the authenticity and validity of the The fact that all elements other than the individual key are encrypted only with the master key means that the list can be traversed (and the list is maintained) without the need to access any key other than the top key. In addition, the key list inventory can be edited with only a single pass of the decryption block.

중요한 제3 원칙은 개별 애플리케이션 코드 또는 미디어 스트림 지정 키가 각 목표 장치(100)의 개별화 키를 수용하도록 충분히 크게 될 수 있다는 것이다. 코드 또는 미디어 스트림이 대량 생산 디스크에 의해 분배된 경우에, 이것은 애플리케이션 개발자(520)가 개별 복호키와 함께 새로운 코드 지정 ID를 발행할 필요가 있음을 의미한다. 비록 이것이 허가 처리에 수반된 모든 당사자들 간에 전송되어야 하는 데이터 양을 최소화한다는 관점에서 덜 효과적일 수 있지만, 이것은 절충된 복호키를 추적하는 능력을 포함한(제한되는 것은 아님) 기능을 프로토콜에 추가한다. 우리는 이것을 키 취소를 취급하는 뒤의 섹션에서 설명할 것이다.An important third principle is that the individual application code or media stream designation key can be made large enough to accommodate the individualization key of each target device 100. If the code or media stream is distributed by the mass production disk, this means that the application developer 520 needs to issue a new code assignment ID with a separate decryption key. Although this may be less effective in terms of minimizing the amount of data that must be transferred between all parties involved in the authorization process, this adds functionality to the protocol, including but not limited to the ability to track compromised decryption keys. . We will explain this in a later section that deals with key cancellation.

주목해야 할 다음 이슈는 키 리스트 데이터 구조(610) 헤더가 리스트의 나머지를 구성하는 애플리케이션 지정 키와 동일한 특성들의 집합을 공유한다는 것이다. 사실, 헤더는 키 리스트 데이터 구조(610) 자체의 나머지에 대한 마스터 키(620)로서 생각할 수 있다. 따라서, 나머지 리스트의 관리를 결정하기 위해 이 키를 사용할 수 있는 한 동일한 동작 원칙이 적용될 수 있다. 이것은 목표 장치(100)의 보안 시스템의 시간 의존 관리를 포함한다. 따라서, 목표 장치(100)는 미리 정해진 간격으로 그 보안 시스템을 갱신하도록 강요될 수 있으며, 이것은 그 자체로 극히 강력한 개념이다.The next issue to note is that the key list data structure 610 header shares the same set of properties as the application specific key that makes up the rest of the list. In fact, the header can be thought of as the master key 620 for the rest of the key list data structure 610 itself. Thus, the same principle of operation can be applied as long as this key can be used to determine management of the rest of the list. This includes time dependent management of the security system of the target device 100. Thus, the target device 100 may be forced to update its security system at predetermined intervals, which is an extremely powerful concept in itself.

키 리스트가 자신의 마스터 키(620)(리스트 헤더) 및 자신의 독립적 암호화 메카니즘을 각각 갖는 다수의 섹션을 포함할 가능성이 또한 존재한다. 임의의 다른 키와 같이, 리스트 헤더는 키 리스트 데이터 구조(610)를 해석하기 위해 사용되는 암호화 코드 블록을 지적할 수 있는 코드 지정 ID 필드(620)를 포함한다. 전체 리스트는 그 다음에 자신의 마스터 키(이것은 또다른 리스트 헤더이다)를 포함하는 또다른 마스터 리스트 내에 포함될 수 있다. 따라서, 전체 키 리스트 데이터 구조(610)는 회귀적으로 정의될 수 있다. 앞에서처럼, 이 회귀적 특성은 동일한 데이터 구조의 이전 버전의 단점을 취급하기 위해 새로운 키 리스트 데이터 구조를 생성함으로써 보안 시스템을 갱신하기 위해 사용될 수 있다. 전체 리스트의 보안성은 "최외측"(또는 최근) 보안층에 내포되기 때문에, 전체 키 리스트 데이터 구조(610)의 보안성은 항상 보안 소프트웨어의 최종 반복에 기초를 둔다.There is also the possibility that the key list includes multiple sections, each with its own master key 620 (list header) and its own independent encryption mechanism. Like any other key, the list header includes a code designation ID field 620 that can point to the encryption code block used to interpret the key list data structure 610. The entire list can then be included in another master list containing its master key (this is another list header). Thus, the entire key list data structure 610 may be defined recursively. As before, this regression feature can be used to update the security system by creating a new key list data structure to handle the shortcomings of previous versions of the same data structure. Since the security of the entire list is implied in the "outermost" (or most recent) security layer, the security of the entire key list data structure 610 is always based on the final iteration of the security software.

따라서, 키 리스트 데이터 구조(610)의 회귀적 특성은 강력한 특징이다. 앞의 섹션에서 설명한 데이터 구조의 정확한 구현이 큰 중요도가 없는 것도 또한 이유이다. 위에서 제공한 설명은 프로토콜 작업의 회귀적 성질을 만드는데 필요한 기능의 최소 부분집합인 특징들을 포함한 단순한 예이었다.Thus, the recursive nature of the key list data structure 610 is a powerful feature. Another reason is that the exact implementation of the data structures described in the previous section is not of great importance. The explanation provided above is a simple example that includes features that are a minimal subset of the functionality needed to create the recursive nature of protocol operations.

키 리스트(160)는, 어떻게 구성되는가에 관계없이, 몇 가지 공통 환경 하에서 유지 및/또는 갱신될 수 있다. 이 환경은 리스트에 내포된 하나 이상의 키의 상태가 수정되는 경우를 포함한다(제한되는 것은 아님). 특수 키(210)의 소유권이 하나의 유닛으로부터 다른 유닛으로 이전될 수 있는 몇 가지 기본 메카니즘이 있고, 우리는 이것을 뒤의 섹션에서 설명할 것이다. 그러나, 어느 경우이든, 개정된 키 리스트가 유지되는 메카니즘은 2가지 분류, 즉 허가 기관(510)의 개입을 요구하는 것과 독립적으로 실행될 수 있는 것으로 나누어질 수 있다. Key list 160 may be maintained and / or updated under some common environment, regardless of how it is configured. This environment includes (but is not limited to) modifying the state of one or more keys in a list. There are some basic mechanisms by which ownership of the special key 210 can be transferred from one unit to another, which we will describe in later sections. In either case, however, the mechanism by which the revised key list is maintained can be divided into two classes, one that can be implemented independently of requiring intervention of the authority 510.

이 프로토콜이 기초하고 있는 주요 동작 개념 중의 하나는 허가 기관(510)의 중앙 서버와 개별 목표 유닛 간의 필요한 네트워크 트래픽의 양을 최소로 감소시키는 것이다. 따라서, 키 리스트 데이터 구조(610)에 대한 임의의 임시 변경(그 이유는 뒤에서 설명함)은 목표 유닛(100)에 의해 독립적으로 유지될 수 있어야 한다. 이것의 주요 이유는 이러한 변경이 장치 보안 시스템에 대한 영구적인 변경보다 더 빈번하게 명시적으로 발생한다는 것이다(이것은 항상 목표 장치(100)와 허가 기관(510) 간의 상호작용에 의해서만 달성된다).One of the main operational concepts on which this protocol is based is to minimize the amount of network traffic needed between the central server of the licensing authority 510 and the individual target units. Thus, any temporary change to the key list data structure 610 (the reason for which will be described later) should be able to be maintained independently by the target unit 100. The main reason for this is that such changes occur explicitly more frequently than permanent changes to the device security system (this is always achieved only by the interaction between the target device 100 and the authorization authority 510).

어쨋든, 목표 장치(100)가 명료한 방법으로 마스터 키 리스트 데이터 구조의 현재 상태를 계속하여 추적할 수 있는 소정의 메카니즘이 있어야 한다. 이것은 2개의 "마스터" 리스트를 가짐으로써 달성될 수 있다. 이들 2개의 리스트 중 첫번째(우리는 이것을 영구 키 리스트라고 부른다)는 허가 기관(510)에 의해 유지된다. 이 리스트는 당해 목표 유닛(100)과 관련된 애플리케이션 지정 키의 "영구" 소유권과 관계된다. 두번째 리스트는 동일한 중요도를 갖지만, 이것은 "영구" 키 리스트 데이터 구조의 임시 수정과 관계된다. 이러한 수정은 리스트에의 추가이거나 리스트로부터 삭제하는 것일 수 있다. 2개의 리스트 자체의 데이터 구조의 구현에 있어서의 필요한 차이는 없고, 중요한 차이는 그들이 어떻게 유지되는가에서 발생한다. 목표 유닛(100)에 대하여 상기 리스트 중의 하나 또는 다른 것으로부터 데이터가 손실되는 경우로부터 복구하는 어떤 방법이 있다는 것은 바람직하다. 이러한 손실은 어떤 파국적 장애에 기인하거나 또는 리스트 중의 하나에 내포된 정보가 어떤 이유로(단순하게 또는 악의적으로) 훼손된 경우에 기인할 수 있다. 우리는 이러한 "키 리스트 훼손"의 경우의 영향에 대하여 뒤의 섹션에서 설명한다. 비록 영구 리스트가 허가 기관과의 접속에 의해 복구되는 것이 필요하지만, 허가 기관(510)이 특수 목표 장치의 임시 키 리스트를 복구할 수 있는 것은 필요하지 않다(또는 바람직하지 않다). 이러한 입장에 대한 많은 이유가 있지만, 주요 이유는 임시 키 리스트가 영구 키 리스트보다 훨씬 더 빈번하게 갱신될 가능성이 있고 중앙의 허가 기관(510)과 목표 유닛 간의 필요한 네트워크 트래픽의 양을 절대 최소치로 유지하고 싶기 때문이다. 그럼에도 불구하고, 허가 기관(510)이 몇 가지 이유(이들 중 일부에 대해서는 뒤에서 설명한다)로 특수 목표 장치의 임시 키 리스트에 대한 수정을 행할 수 있는 것이 잠재적으로 바람직하다. 이 경우에, 이 리스트는 목표 장치의 1차 비밀키(이것은 허가 기관(510)에 알려져 있음)를 이용하여 암호화되는 것이 바람직할 것이다.In any case, there must be some mechanism by which the target device 100 can keep track of the current state of the master key list data structure in a clear manner. This can be accomplished by having two "master" lists. The first of these two lists (we call this permanent key list) is maintained by the authority authority 510. This list relates to the "permanent" ownership of the application specified key associated with the target unit 100 in question. The second list has the same importance, but this involves temporary modification of the "permanent" key list data structure. Such modification may be addition to or delete from the list. There is no necessary difference in the implementation of the data structures of the two lists themselves, and an important difference arises in how they are maintained. It is desirable for the target unit 100 to have some way of recovering from the case where data is lost from one or the other of the above lists. This loss may be due to some catastrophic failure or if the information contained in one of the lists is damaged for some reason (simply or maliciously). We will discuss the impact of this "key list corruption" case in later sections. Although it is necessary for the permanent list to be recovered by connection with the authorization authority, it is not necessary (or not desirable) for the authorization authority 510 to be able to recover the temporary key list of the special target device. There are many reasons for this stance, but the main reason is that the temporary key list is likely to be updated much more frequently than the permanent key list and keep the amount of network traffic required between the central authority and the target unit at an absolute minimum. Because I want to. Nevertheless, it is potentially desirable that the permitting authority 510 be able to make modifications to the temporary key list of the special target device for several reasons (some of which are described later). In this case, this list would preferably be encrypted using the primary secret key of the target device (which is known to the authority 510).

위에서 언급한 바와 같이, 양측 키 리스트 데이터 구조의 완전성은 리스트 자체와 함께 저장된 부호화 메시지 다이제스트(디지털 서명)를 이용하여 검증될 수 있다. 이 메시지 다이제스트를 생성하기 위해 사용되는 보안 코드 메카니즘의 구현은 위의 섹션에서 설명하였고, 그 절차를 다시 설명할 필요는 없을 것이다. 우리는 또한 손실 및/또는 훼손이 있는 경우에 영구 키 리스트 데이터 구조(610)를 복구하는 절차에 대하여 이미 설명하였다. 취급되어야 할 유일한 나머지 이슈는 임시 키 리스트 데이터 구조의 시간 의존 부분을 어떻게 해석하고 임시 키 리스트가 사용불능으로 된 경우를 어떻게 다룰 것인가이다.As mentioned above, the integrity of both key list data structures can be verified using an encoded message digest (digital signature) stored with the list itself. The implementation of the security code mechanism used to generate this message digest is described in the section above, and the procedure will not need to be described again. We have also already described the procedure for recovering the permanent key list data structure 610 in case of loss and / or corruption. The only remaining issue to be dealt with is how to interpret the time-dependent part of the temporary key list data structure and how to deal with the case where the temporary key list is disabled.

임시 temporary 라이센스license 이전 Previous

이것은 타임스탬프 필드(230)의 사용이 가장 중요한 보안 프로토콜의 섹션들 중 하나이다. 위에서 설명한 것처럼, 임시 키 리스트 데이터 구조는 목표 장치의 영구 키 리스트와 정확히 동일한 방법으로 구성된다. 그러나, 양자간에는 몇 가지 차이가 있다. 첫번째 차이는 임시 키 리스트가 목표 장치의 비밀키(104) 중의 하나를 이용하여 잠재적으로 암호화될 수 있다는 것이다. 허가 기관(510)이 정상 환경 하에서 이 데이터 구조를 재구성할 필요가 없기 때문에, 목표 장치의 어떤 키를 이용하여 데이터 구조를 암호화할지는 명시적으로 관계가 없다. 그러나, 이 리스트가 목표 장치의 1차 비밀키를 이용하여 또한 암호화되었다면 허가 기관(510)에 대하여 잠재적으로 사용될 것이다. 이것의 이유는 허가 취소와 함께 이루어져야 하고, 그 상황은 뒤의 섹션에서 설명할 것이다.This is one of the sections of the security protocol where the use of the timestamp field 230 is of utmost importance. As described above, the temporary key list data structure is constructed in exactly the same way as the permanent key list of the target device. However, there are some differences between the two. The first difference is that the temporary key list can potentially be encrypted using one of the target device's secret keys 104. Since the authorization authority 510 does not need to reconstruct this data structure under normal circumstances, it does not explicitly matter which key of the target device is used to encrypt the data structure. However, this list would potentially be used for the authorization authority 510 if it was also encrypted using the primary secret key of the target device. The reason for this has to be done with revoke of permission, the situation will be explained in later section.

임시 키 리스트와 영구 키 리스트 간의 두번째(및 더 중요한) 차이는 가장 최근의 임시 키 리스트 데이터 구조와 관련된 타임스탬프 값(230)의 복사본이 또한 목표 장치(100) 내에 저장(즉 온칩)된다는 것이다. 이 레지스터는 소프트웨어 판독가능이 아니고, 보안 블록의 일부이기 때문에 보안 코드에 의한 덮어쓰기만 가능하다. 이 레지스터의 값은 임시 키 리스트 데이터 구조가 어떻게든 손실되고 및/또는 훼손된 경우에 무엇을 할 것인지를 결정하기 위해 사용된다. 우리는 그 절차를 이 섹션의 뒷부분에서 설명할 것이다.The second (and more important) difference between the temporary key list and the permanent key list is that a copy of the time stamp value 230 associated with the most recent temporary key list data structure is also stored (ie on chip) in the target device 100. This register is not software readable and is part of the security block so it can only be overwritten by a security code. The value of this register is used to determine what to do if the temporary key list data structure is somehow lost and / or corrupted. We will explain the procedure later in this section.

임시 키 리스트와 영구 키 리스트 간의 또다른 차이는 목표 유닛(100)이 특수 키의 소유권을 그 영구 리스트로부터 다른 유닛(100)의 임시 리스트로 (임시로) 이전할 수 있지만, (올바르게 동작하는) 장치는 특수 키의 소유권을 그 임시 키 리스트로부터 임의의 다른 키 리스트로 이전할 수 없다는 것이다. 이것은 물론 다른 유닛의 임시 키 리스트뿐만 아니라 목표 장치(100) 자신의 영구 키 리스트도 또한 포함한다. 이것은 영구 소유자만이 어떤 장치가 언제 임의의 특수 키를 "차용"하도록 허용되는지 결정할 수 있다는 의미이다. 그러나, 이 "대여" 기간은 막연하게 될 수 있다는 점에 주목한다(이 트랜잭션은 허가 기관에 접촉할 필요없이 실행될 수 있다). 이 "영구 대여" 특징은 현대의 디지털 저작권 제어 정보(Copyright Control Information; CCI) 시스템의 일부인 표준 "1회 복사(Copy Once)" 기능 필요조건과 등가이다.Another difference between the temporary key list and the permanent key list is that the target unit 100 can transfer (temporarily) ownership of a special key from its permanent list to a temporary list of another unit 100, but (works correctly). The device cannot transfer ownership of a special key from its temporary key list to any other key list. This of course also includes the temporary key list of the other unit as well as the permanent key list of the target device 100 itself. This means that only the permanent owner can determine which device is allowed to "borrow" any special key. However, note that this "loan" period may become vague (this transaction may be executed without the need to contact the licensing authority). This "permanent rental" feature is equivalent to the standard "Copy Once" functionality requirement that is part of the modern Digital Copyright Control Information (CCI) system.

이제 도 167을 참조하면, 임시 "키 체크아웃" 절차를 나타내는 상세한 흐름도가 도시되어 있다. "키 소유권" 이전 절차는 도서관으로부터 서적 복사본을 체크아웃하는 절차와 어느 정도 유사하다. "차용자"(720)가 영구 소유자("대여자"(710))로부터 특수한 애플리케이션 지정 키(550)의 임시 사용을 요청하면, 대여자(710)는 먼저 상기 특수 키의 사용을 키 체크아웃 협상 처리 동안에 금지하는 갱신된 임시 키 리스트를 단독으로 발생한다. 이 동작은 하나 이상의 차용자(720) 유닛이 동일한 키를 요청하는 것을 금지한다. 대여자 유닛(710)의 임시 키 리스트에 존재하는 "체크아웃 키"는 임의의 특수 키에 대한 액세스를 제어하는 신호기(semaphore)로서 유효하게 사용된다. 그러나, 키가 "구속 상태"로 있는 초기 시간량은 비교적 짧은 기간으로 제한되어야 한다. 이것은 차용자(720) 장치가 특수 키에 대한 액세스를 장기간 동안 요청하고 그래서 특수 키의 사용을 불공정하게 독점하는 것으로부터 어떤 이유로 트랜잭션을 완성할 수 없는 경우를 방지하기 위한 것이다. 상기 비교적 짧은 체크아웃 협상 단계 타임아웃은 대여자 유닛(710)에 대항하여 "서비스 거부" 공격의 등가물을 설치하려고 하는 악의적 장치에 대한 싸움에서 또한 도움이 된다. 사실, 대여자 유닛(710)은 자신의 "승인된 차용자" 리스트에 없는 장치로부터의 요청이 있는 경우 또는 그러한 유닛들의 임의의 하나가 소정 시간 내에 너무 많은 요청을 하려고 시도하는 경우 그 요청을 선택적으로 무시할 수 있다. 이 임시 블록이 키에 존재하는 정확한 시간 길이는 중요하지 않지만, 임의의 주어진 체크아웃 절차가 완성될 수 있도록 충분히 길어야 한다. 네트워크 트래픽 또는 대기시간이 높은 시간대에서는 이 기간을 연장할 수 있다.Referring now to FIG. 167, a detailed flow diagram illustrating a temporary "key check out" procedure is shown. The "key ownership" transfer process is somewhat similar to the process of checking out a copy of a book from a library. When the "borrower" 720 requests the temporary use of a special application- specific key 550 from the permanent owner ("rent" 710), the lender 710 first checks the use of the special key during the key checkout negotiation process. Generates a list of updated temporary keys that are forbidden. This operation prohibits one or more borrower 720 units from requesting the same key. The "checkout key" present in the temporary key list of the lender unit 710 is effectively used as a semaphore to control access to any special key. However, the initial amount of time that the key is in the "bound state" should be limited to a relatively short period of time. This is to prevent the borrower 720 device from requesting access to a special key for a long time and thus unable to complete a transaction for some reason from unfairly monopolizing the use of the special key. The relatively short checkout negotiation phase timeout is also helpful in the fight against malicious devices attempting to install the equivalent of a "denial of service" attack against the lender unit 710. In fact, the lender unit 710 may selectively ignore the request if there is a request from a device that is not on its "approved borrower" list, or if any one of those units attempts to make too many requests within a certain amount of time. Can be. The exact length of time that this temporary block is in the key is not important, but it must be long enough for any given checkout procedure to be completed. This period can be extended in times of high network traffic or latency.

주어진 키의 하나 이상의 복사본이 동시에 체크아웃될 수 있는 경우에, 대여자 장치(710)의 임시 키 리스트 내의 적당한 필드를 사용하여 얼마나 많은 키 복사본이 임의의 한 시점에서 체크아웃되는지를 표시할 수 있다는 점에 주목한다. 차용자(720)와 대여자(710)가 주어진 키에 대한 특정 체크아웃 기간을 협상하였으면, 대여자(710)는 키의 암호화한 복사본(740)을 차용자(720)에게 보낸다. 이 암호화는 대여자 장치(710)에게만 알려져 있는 임시 비밀키(730)를 이용하여 실행된다. 차용자(720)가 암호화 키의 정확한 수령을 (암호화 메시지로부터 계산된 메시지 다이제스트에 의해) 승인한 경우, 대여자(710)는 체크아웃 키의 "대여 기간"을 연장하고 임시 비밀키(730)를 차용자 장치(720)에 보낸다. 이 대여 처리의 최대 기간은 프로토콜의 동작에 중요하지 않고 이 값의 선택에 있어서 행하여져야 할 몇 가지 교환조건이 있다. 우리는 그러한 특수한 이슈를 이 섹션의 뒷부분에서 설명할 것이다. 위에서 설명한 예에서, 우리는 "차용자(720)"와 "대여자(710)" 장치가 키마다 체크아웃 기간의 실제 길이를 협상할 수 있는 것으로 가정하지만, 이것은 프로토콜의 필요조건이 아니다.If one or more copies of a given key can be checked out at the same time, the appropriate field in the temporary key list of the lender device 710 can be used to indicate how many copies of the key are checked out at any one point in time. Pay attention to If borrower 720 and lender 710 negotiate a particular checkout period for a given key, lender 710 sends an encrypted copy 740 of the key to borrower 720. This encryption is performed using a temporary secret key 730 known only to the lender device 710. If borrower 720 authorizes the correct receipt of the encryption key (by message digest calculated from the encryption message), lender 710 extends the “rental period” of the checkout key and borrows temporary temporary key 730. To device 720. The maximum duration of this loan process is not critical to the operation of the protocol and there are some exchange conditions that must be made in choosing this value. We will discuss those special issues later in this section. In the example described above, we assume that the " borrower 720" and " loan 710" devices can negotiate the actual length of the checkout period per key, but this is not a requirement of the protocol.

차용자(720) 또는 대여자(710)의 임시 키 리스트가 갱신되는 바로 앞의 시점에서, 이 새로운 임시 리스트와 관련된 타임스탬프 값(230)의 복사본이 목표 장치(100)에 비휘발성 형태로 저장된다. 그 시점에서, 임시 키 리스트 데이터 구조의 암호화 버전이 온보드 NVRAM, 플래시 ROM 또는 일부 하드 디스크(750)의 백업 파일 외부와 같은 메모리에 안전하게 기록될 수 있다(또는 소정의 다른 더 영구적인 위치에 저장될 수 있다). 임시 키 리스트는 잠재적으로 판독가능하고 영구 키 리스트보다 훨씬 더 빈번하게 갱신되기 때문에, 이 리스트는 목표 유닛에 신속히 액세스되는 것이 바람직하고, 그래서 이 리스트는 액세스 대기시간이 비교적 짧은 적어도 하나의 위치에 저장되는 것이 권장된다(그러나 이것은 프로토콜의 실제 필요조건이 아니다). 반면에, 전력 고장에 의해 중간 시간량 동안 목표 장치(100)의 기능 상실을 잠재적으로 야기할 수 있기 때문에, 상기 리스트를 저장하는 장소는 어떤 휘발성 기억 매체가 아닌 것(DRAM 등)이 권장된다. 우리는 이 이슈에 대한 세부를 이 섹션의 뒤에서 설명할 것이다.At the point immediately before the borrower 720 or lender 710's temporary key list is updated, a copy of the timestamp value 230 associated with this new temporary list is stored in the target device 100 in a non-volatile form. At that point, an encrypted version of the temporary key list data structure can be securely written to memory, such as onboard NVRAM, flash ROM, or outside a backup file of some hard disk 750 (or to be stored in some other more permanent location). Can be). Since the temporary key list is potentially readable and updated much more frequently than the permanent key list, it is desirable that this list be accessed quickly in the target unit, so that the list is stored in at least one location with relatively low access latency. It is recommended (but this is not a real requirement of the protocol). On the other hand, it is recommended that the location for storing the list is not any volatile storage medium (DRAM, etc.), as it could potentially cause a malfunction of the target device 100 for an intermediate amount of time due to a power failure. We will discuss the details of this issue later in this section.

특수 키에 대한 체크아웃 기간이 만료되면, 차용자(720) 및 대여자(710) 장치는 그들 각각의 임시 키 리스트 데이터베이스를 독립적으로 갱신할 수 있다. 따라서, 차용자(720)가 계산 대상 특수 키를 돌려주기 위해 대여자(710) 장치와 접촉할 필요는 없다. 이것은 차용자(720)와 대여자(710) 장치가 멀리 떨어져 있는 경우에 중요한 편리 요소이다. 물론, 이 동작의 보안성은 키 타임스탬프 기록을 생성 및 제어하기 위해 사용하는 온칩 클럭들 간의 매우 단단한 상관성에 의존할 수 있다. 따라서, 시간/날짜 클럭이 보안 시스템의 통합 부분으로 되어야 하고, 그래서 중앙 서버와의 트랜잭션에 의해 덮어쓰기 될 수 있어야 한다. 또한, 클럭들은 악의있는 사용자가 내부 타임스탬프 값(230)을 수정하려고 하는 경우에 부정한 변경에 저항하도록 및 평소에 시스템 전력 장애가 발생한 경우에 살아남을 수 있도록 충분히 강하게 설계되어야 한다. 이 클럭이 배터리에 의해 전력이 공급되는 경우 배터리가 제거되거나 시간 경과에 따라 배터리 전력이 없어지는 것을 상상할 수 있기 때문에, 시스템은 허가 기관과의 안전한 상호작용에 의해 클럭이 잠재적으로 재시작되거나 리세트될 수 있도록 하는 방법으로 설계되어야 한다.Once the checkout period for the special keys expires, the borrower 720 and lender 710 devices can update their respective temporary key list databases independently. Thus, the borrower 720 does not need to contact the lender 710 device to return the special key to be calculated. This is an important convenience factor when the borrower 720 and lender 710 devices are far apart. Of course, the security of this operation may rely on very tight correlations between on-chip clocks used to generate and control key timestamp records. Thus, the time / date clock must be an integral part of the security system, so that it can be overwritten by a transaction with the central server. In addition, the clocks must be designed strong enough to resist a fraudulent change in case a malicious user attempts to modify the internal timestamp value 230 and to survive in the event of a system power failure normally. Because it can be imagined that the battery is removed or loses battery power over time when this clock is powered by the battery, the system could potentially restart or reset the clock by a safe interaction with the licensing authority. It must be designed in such a way as to enable it.

따라서, 우리는 특수 애플리케이션 지정키(550)의 소유권이 하나의 유닛으로부터 다른 유닛으로 임시로 이전될 수 있는 상황을 설명하였다. "대여 기간"의 끝에서, 차용자(720) 유닛과 대여자(710) 유닛은 최초 소유자로의 키의 "복귀"를 반영하도록 그들의 임시 키 리스트 데이터 구조를 갱신할 수 있다. 이 절차는 양측 유닛에서 독립적으로 수행될 수 있고, 따라서 두 장치 간에 어떤 상호작용을 필요로 하지 않는다는 점에 주목한다.Thus, we have described a situation in which ownership of the special application designation key 550 may be temporarily transferred from one unit to another. At the end of the "rental period", the borrower 720 unit and the lender 710 unit may update their temporary key list data structure to reflect the "return" of the key to the original owner. Note that this procedure can be performed independently in both units and therefore does not require any interaction between the two devices.

이제, 하나 이상의 키가 "체크아웃" 하는 동안 또는 "대여중"인 동안 하나 또는 다른 임시 키 리스트 데이터 구조가 훼손 및/또는 상실된 경우를 설명한다. "대여자(710)" 유닛 측에서, 임의의 키가 체크아웃될 때, 해야 할 첫번째 일은 "대여" 기간의 끝을 결정하는 것이다. 이 값은 대여 기간의 지속기간을 현재 시간/날짜 필드의 값에 가산함으로써 명백하게 구성된다. 이 시간/날짜 값은 그 다음에 장치의 임시 키 리스트가 마지막으로 갱신된 결과로서 저장된 값과 비교된다. 새로운 값이 오래된 값보다 더 크면(더 뒤에 있으면) 새로운 값이 오래된 값 대신으로 덮어쓰기 된다. "차용자(720)" 측에서, 상기와 동일한 처리가 사용되고, 그래서 그 결과는 임의의 주어진 목표 유닛에 있어서, 임시 키 리스트 타임스탬프가 항상 특수 유닛(100)의 임시 키 리스트의 일부로서 저장된 임의의 타임스탬프 중 최신의 것으로 된다.The case where one or the other temporary key list data structure is corrupted and / or lost while one or more keys are "checked out" or "rental" is described. On the " loan 710" unit side, when any key is checked out, the first thing to do is to determine the end of the "loan" period. This value is explicitly constructed by adding the duration of the rental period to the value of the current time / date field. This time / date value is then compared with the value stored as the result of the last update of the device's temporary key list. If the new value is greater than the old one (more later), the new value is overwritten instead of the old one. On the " borrower 720 &quot; side, the same processing as above is used, so the result is that for any given target unit, any temporary key list timestamp is always stored as part of the temporary key list of the special unit 100. The newest of the timestamps is taken.

만일 유닛(100)의 임시 키 리스트가 상실되거나 또는 다른 방식으로 부적절하게 수정되면, 임시 키 리스트와 영구 리스트 양자는 상기 "최신 타임스탬프" 값이 만료되는 시점(실제로는 "타임아웃" 기간)까지 디스에이블된다. 그 시점에서, 유닛은 영구 키 리스트를 사용하는 것으로 되돌아갈 수 있고 새로운 임시 키 리스트를 재구성하는 처리를 시작할 수 있다.If the temporary key list of the unit 100 is lost or otherwise modified inappropriately, both the temporary key list and the permanent list are up to the point at which the "latest timestamp" value expires (actually a "timeout" period). Is disabled. At that point, the unit can go back to using the permanent key list and begin the process of reconstructing the new temporary key list.

따라서, 만일 장치의 임시 리스트가 부정하게 변경되거나 삭제되면, 유닛은 타임아웃 기간이 만료될 때까지 효과적으로 비동작 상태로 된다. 이 타임아웃 절차는 불필요하게 구속하는 것으로 보이지만, 이것은 어떤 악의적인 동작의 결과로서 또는 키를 하나의 유닛으로부터 다른 유닛으로 이전하는 동안에 발생할 수 있는 어떤 돌연한 고장(glitch)(전력이 나가거나 네트워크 접속이 다운되는 것 등) 때문에 있을 수 있는 임의의 특수 애플리케이션 지정 키의 다수의 복사본에서의 잠재적인 문제점을 피할 수 있게 한다. 또한, 임시 키 리스트 데이터 구조를 부정하게 변경한 결과로서 심각한 영향을 받을 잠재성은 모든 더 정교한 공격자에 의한 실행을 저지하는데 도움이 되어야 한다.Thus, if the temporary list of devices is tampered with or deleted, the unit is effectively inactive until the timeout period expires. This timeout procedure appears to be unnecessarily constrained, but this may result in some sudden glitches (power outages or network connections) that may occur as a result of some malicious operation or during the transfer of keys from one unit to another. This can avoid potential problems with multiple copies of any special application-specified keys that might be due to such a crash. In addition, the potential to be severely affected as a result of fraudulently altering the temporary key list data structure should help prevent execution by any more sophisticated attacker.

이 점에서 프로토콜의 동작을 강화하기 위해 사용될 수 있는 다수의 선택적인 추가의 특징들이 있다. 그러한 가능한 옵션 중의 하나는 암호화 키 리스트 데이터 구조 중의 어느 하나(또는 양자)로부터 발생된 부호화 메시지 다이제스트(디지털 서명)를 목표 장치의 온칩 보안 섹션에 저장된 값들에 추가하는 것이다. 디지털 서명의 복호로부터 발생하는 MAC 값은 전체 복호 처리를 통과할 필요없이 임의의 특수 키 리스트의 유효성을 신속히 검증하기 위해 사용될 수 있다. 그러나, 네스티드 키 리스트를 증가시키는 문제는 이 복호 처리가 비암호화 키를 최종적으로 생성하기 위해 소정 시점에서 복수 회 수행되어야 한다는 것을 의미하고, 따라서 디지털 서명이 온칩으로 저장되는 것은 프로토콜의 동작에 중요한 것이 아니다.In this respect there are a number of optional additional features that can be used to enhance the operation of the protocol. One such possible option is to add the encoded message digest (digital signature) generated from either (or both) of the encryption key list data structure to the values stored in the on-chip security section of the target device. The MAC value resulting from the decryption of the digital signature can be used to quickly validate the validity of any special key list without having to go through the entire decryption process. However, the problem of increasing the nested key list means that this decryption process must be performed a plurality of times at a given point in time to finally generate an unencrypted key, so that the digital signature is stored on-chip, which is important for the operation of the protocol. It is not.

증대(enhancement)를 위한 다른 하나의 가능성은 온칩 타임스탬프 값을 하나씩 저장하기보다는 쌍으로 저장하는 것이다. 추가적인 타임스탬프는 임시 키 리스트가 갱신되어야 할 때 가장 이른 (다음) 시간을 표시하기 위해 사용할 수 있다. 이것은 목표 장치(100)가 리스트를 지속적으로 체크할 수 없기 때문에(이것은 복호 처리의 수행을 수반한다) 그 임시 키 리스트를 개정할 필요가 있을 때를 더 쉽게 결정할 수 있게 한다. 비록 이 특징이 매우 유용하지만, 유닛이 이 프로토콜을 실행할 수 있게 하는 기본적인 필요조건은 아니다. 만일 상기 제2 타임스탬프를 내포한 시스템이 구현되면, 2개의 타임스탬프가 어떤 이유로 "동기 파괴(out of sync)"로 되는 경우에 혼란을 일으킬 가능성이 있다. 그러한 예 중의 하나는 하나의 타임스탬프가 기록된 직후이고 두번째 타임스탬프가 갱신되기 전의 시점에서 돌연한 전력 고장이 발생한 경우이다.Another possibility for enhancement is to store on-chip timestamp values in pairs rather than one by one. An additional timestamp can be used to indicate the earliest (next) time when the temporary key list should be updated. This makes it easier to determine when the target device 100 needs to revise its temporary key list since it cannot continuously check the list (this entails performing a decryption process). Although this feature is very useful, it is not a basic requirement for the unit to implement this protocol. If a system incorporating the second timestamp is implemented, there is a possibility of confusion if the two timestamps become " out of sync " for some reason. One such example is when a sudden power failure occurs shortly after one timestamp is written and before the second timestamp is updated.

다루어야 할 최종 이슈는 상기 임시 키 리스트 타임스탬프의 값에 대한 최소 및 최대 한계가 무엇이냐 하는 문제이다. 한편으로, 최대 "임시 대여 기간"의 더 큰 한계는 특수 데이터 애플리케이션(또는 미디어 스트림)의 사용권이 상당히 긴 기간동안 하나의 유닛으로부터 다른 유닛으로 이전할 수 있게 한다. 이것은 사용자가 미디어 스트림의 소유권을 자신의 "홈 유닛"으로부터 휴대용 장치로 이전하고자 하는 경우에 잠재적으로 사용할 수 있다. 긴 "체크아웃 기간"을 가지면, 사용자가 최초의 "대여자" 유닛(710)과 접촉할 필요없이 상기 체크아웃 기간(그 관련 임시 키와 함께)을 가진 휴대용 장치를 가지고 긴 여행을 할 수 있다. 긴 "체크아웃 기간"의 불리한 점은 최초 유닛에서 임시 키 리스트 데이터 구조에 어떤 일이 발생하면 그 유닛이 장시간 동안 잠재적으로 디스에이블된다는 것이다.The final issue to be addressed is what is the minimum and maximum limit on the value of the temporary key list timestamp. On the one hand, a larger limit of the maximum "temporary rental period" allows the use of special data applications (or media streams) to transfer from one unit to another for a fairly long period of time. This can potentially be used if the user wishes to transfer ownership of the media stream from his “home unit” to the portable device. Having a long " checkout period " allows a user to travel long with a portable device with the checkout period (along with its associated temporary key) without having to contact the original " lender " unit 710. The disadvantage of the long "checkout period" is that if something happens to the temporary key list data structure at the first unit, that unit is potentially disabled for a long time.

상기 최종 이슈는 일부 악성 코드가 온칩 타임스탬프 레지스터의 값을 어떤 불확실한 값으로 설정할 수 있는 경우에 목표 유닛(100)에서 잠재적인 위험성을 또한 나타낸다. 이것은 공격의 목표를 디스에이블시키는 것과 잠재적으로 동등한 것이고, 따라서 이 타임스탬프 레지스터의 값은 "보안" 코드 블록에 의해서만 기록될 수 있어야 한다. 또한, 각 유닛이 별개의 비밀키 집합을 갖기 때문에, 하나의 특수 유닛의 비밀키(104) 데이터의 발견은 부당한 장치가 합법적 장치로 효과적으로 가장할 수 있는 경우를 제외하고 임의의 다른 장치의 관심을 일으키지 않을 것이다. 이 공격 모드는 뒤에서 신원 검증과 관련된 이슈를 다루면서 설명한다.The final issue also indicates a potential risk in the target unit 100 if some malicious code can set the value of the on-chip timestamp register to some uncertain value. This is potentially equivalent to disabling the target of the attack, so the value of this timestamp register should only be able to be written by a "secure" code block. In addition, since each unit has a separate set of secret keys, the discovery of the secret key 104 data of one special unit is of interest to any other device, except where an unjust device can effectively impersonate a legitimate device. Will not produce. This mode of attack is discussed in the following section, which addresses issues related to identity verification.

영구적 Permanent 라이센스license 이전 Previous

이 절차와 관련한 많은 요소들은 이 문서의 앞의 섹션에서 설명하였다. 특정 키를 하나의 유닛으로부터 다른 유닛으로 영구적으로 이전하는 기본 처리는 앞에서 도 5와 관련하여 설명하였다. 많은 점에서 이 절차는 바로 앞의 섹션에서 설명한 것처럼 키 소유권을 임시 이전하는 절차와 본질적으로 유사하다.Many elements of this procedure are described in the earlier sections of this document. The basic process of permanently transferring a particular key from one unit to another has been described with reference to FIG. 5 above. In many respects, this procedure is essentially similar to the procedure for temporarily transferring key ownership, as described in the previous section.

2개의 절차 간의 중요한 차이점은 영구 이전이 임시 이전보다 처리가 더 간단하고 영구 키 소유권 이전 절차는 허가 기관(510)과 목표 유닛(100)의 상호작용을 활용해야 한다는 것이다. 영구 이전 처리가 더 간단한 이유는 임시 키 체크아웃 절차에서의 선행조건인 체크아웃 시간 기간 협상을 영구 이전 처리에서 요구하지 않는다는 사실에 있다. 영구 이전 기능이 허가 기관(510)과 목표 유닛(100) 간의 상호작용을 활용하는 이유는 갱신된 키 리스트 데이터 구조가 트랜잭션의 양 끝에서 재구성될 수 있어야 한다는 사실에 기인한다.An important difference between the two procedures is that permanent transfer is simpler to handle than temporary transfer and the permanent key ownership transfer procedure must utilize the interaction of the authorization authority 510 and the target unit 100. The reason that the permanent migration process is simpler is that the checkout time period negotiation, which is a prerequisite in the temporary key checkout procedure, does not require the permanent migration process. The reason that the permanent transfer function utilizes the interaction between the authorization authority 510 and the target unit 100 is due to the fact that the updated key list data structure must be reconstructable at both ends of the transaction.

영구적 라이센스 이전이 일반적으로 허가 기관(510)과의 상호작용에 의해 발생하기 때문에, 어떤 애플리케이션 또는 미디어 스트림 지정 키가 어떤 목표 유닛에 속하는지에 관한 기록이 있다. 앞에서 설명한 바와 같이, 이것은 목표 유닛(100)의 키 리스트가 어떤 파국적 데이터 상실 상황 후에 복원되어야 하는 경우에, 또는 특수 목표 유닛(100)의 소유권이 다른 엔티티로 이전된 경우에 필요하다. 허가 기관(510) 부분에서의 이러한 개입은 특수 키의 영구 소유권이 하나의 목표 유닛(100)으로부터 다른 목표 유닛으로 이전된 경우에 또한 필요하다. 소유자가 다른 엔티티로부터 최초로 구매한 자산을 되파는 이러한 능력은 "최초 판매 권한(right of first sale)"이라고 알려져 있고, 여기에서 설명한 프로토콜이 상기 특수 기능을 지원하는 능력은 중요한 것이다.Since permanent license transfer generally occurs by interaction with the licensing authority 510, there is a record of which application or media stream designation key belongs to which target unit. As described above, this is necessary if the key list of the target unit 100 is to be restored after some catastrophic data loss situation, or if ownership of the special target unit 100 has been transferred to another entity. This intervention in the authority authority 510 part is also necessary if the permanent ownership of the special key has been transferred from one target unit 100 to another. This ability for owners to repurchase assets purchased for the first time from another entity is known as the "right of first sale" and the ability of the protocol described herein to support these special functions is important.

목표 유닛(100)의 영구 키 리스트가 허가 기관(510)에 의해 유지되는 사실의 다른 중요한 태양은 목표 유닛(100)이 어떻게든지 절충되었음이 입증된 경우에 또는 키들 중의 하나가 절충된 것으로 확인된 경우에, 이 보디(body)가 개별적인 목표 유닛(100)의 라이센스 키의 일부 또는 전부를 취소할 능력이 있다는 점이다. 각각의 목표 유닛(100)에 (위에서 설명한 것처럼) 유일한 키 리스트를 제공할 가능성이 있기 때문에, 허가 기관(510)이 임의의 절충된 키의 소스를 추적할 기회가 또한 제공될 수 있다. 그러한 상황에서, 이 프로토콜은 전통적인 워터마크 처리의 단점(워터마크가 미디어 스트림의 품질에 악영향을 줄 가능성 등) 없이 일반적으로 "워터마크" 특징의 기능과 관련된 기능을 충족시킬 수 있다.Another important aspect of the fact that the permanent key list of the target unit 100 is maintained by the licensing authority 510 is that if the target unit 100 proved to be somehow compromised or one of the keys was found to have been compromised In this case, this body is capable of revoking some or all of the license keys of the individual target units 100. Since there is a possibility to provide a unique list of keys (as described above) to each target unit 100, the opportunity may also be provided for the licensing authority 510 to track the source of any compromised keys. In such a situation, this protocol can meet the functionality generally associated with the functionality of the "watermark" feature without the disadvantages of traditional watermark processing (such as the possibility that the watermark will adversely affect the quality of the media stream).

그러한 경우로 보이지는 않지만, 디지털 콘텐트 소유자의 프라이버시는, 애플리케이션 코드 또는 미디어 스트림 지정 ID 정보가 애플리케이션 개발자(520)에게서 발원하고 허가 기관(510)이 임의의 특수한 애플리케이션 또는 미디어 스트림과 그 허가된 소유자 간에 연합(association)을 만들 수 있는 충분한 정보를 가질 필요가 없기 때문에, 이 처리에 의해 여전히 유지된다. 소유자의 프라이버시를 보호하기 위한 이러한 능력은 역시 이 프로토콜의 중요한 태양이다.Although not seen as such, the privacy of the digital content owner is that the application code or media stream specific ID information originates from the application developer 520 and the licensing authority 510 is responsible for any special application or media stream and its authorized owner. This process is still maintained because it is not necessary to have enough information to make an association. This ability to protect the privacy of the owner is also an important aspect of the protocol.

영구 키 이전 처리와 관련하여 주목해야 할 마지막 이슈는 사실상 영구적 키 이전이 수행하는 모든 동일한 기능이 임시 키 라이센스 이전과 함께 달성될 수 있다는 점이다. 그러나, 목표 유닛의 보안 시스템의 유지는 이상적으로 중앙 보안 서버에 의해 제어되어야 하는 기능이고, 따라서 사슬의 어딘가의 적소에 그러한 메카니즘을 가질 필요가 있다. 또한, 사용자가 자신의 프라이버시를 유지하는 것에 관심이 있는 경우에, 중앙 서버가 저작권 보유자와 목표 유닛(100) 간의 완충기(buffer)로서 작용할 수 있다는 사실은 크게 유익한 것이다. 마지막으로, 허가 기관(510)이 상기 기능을 임시 키 이전 메카니즘을 제외하고 설정하는 특수 목표 유닛(100)의 영구 키 리스트에 대한 중앙 백업 스토리지 메카니즘으로서 작용할 수 있는 점도 또한 흥미로운 점이다.The last issue to note with regard to permanent key migration processing is that virtually all the same functions that permanent key migration performs can be achieved with temporary key license transfer. However, the maintenance of the security system of the target unit is a function that should ideally be controlled by a central security server, and therefore it is necessary to have such a mechanism somewhere in the chain. Also, if the user is interested in maintaining his or her privacy, the fact that the central server can act as a buffer between the copyright holder and the target unit 100 is of great benefit. Finally, it is also interesting that the authority authority 510 can act as a central backup storage mechanism for the permanent key list of the special target unit 100 which sets this function apart from the temporary key transfer mechanism.

시스템 소유권 양도, 허가 취소 및 보안 시스템 갱신Transfer system ownership, revoke authorization and renew security system

하나 이상의 목표 장치(100)의 라이센스(또는 키)를 취소하는 몇 가지 상이한 수단들이 있다. 가장 간단한 방법은 목표 장치(100)의 1차 비밀키를 단순히 갱신하는 것이다. 이 시점에서, 목표 장치(100)는 자신의 영구 키 리스트에 액세스할 수 없고, 따라서 새로운 키 리스트를 생성하는 처리를 시작하여야 한다. 1차 비밀키가 임시 키 리스트 데이터 구조의 암호화 처리에 사용될 수 없는 경우에 상기 임시 키 리스트는 영구 키 리스트가 다른 방식으로 액세스불능으로 된다 하더라도 잠재적으로 여전히 액세스될 수 있다는 점에 주목한다.There are several different means of revoking a license (or key) of one or more target devices 100. The simplest way is to simply update the primary secret key of the target device 100. At this point, the target device 100 cannot access its permanent key list, and therefore must start the process of generating a new key list. Note that if the primary secret key cannot be used for the encryption process of the temporary key list data structure, the temporary key list can still be accessed even if the permanent key list is otherwise inaccessible.

이 점에 대해서는 임시 키 리스트의 암호화 처리를 설명하면서 앞에서 설명하였다. 이 때문에, 영구 및 임시 키 리스트 데이터 구조 양자에 대한 암호화 키로서 목표 장치(100)의 1차 비밀키를 사용하는 것이 아마도 최상의 아이디어일 것이다.This point has been described above while explaining the encryption process of the temporary key list. Because of this, it is probably the best idea to use the primary secret key of the target device 100 as the encryption key for both the permanent and temporary key list data structures.

목표 장치(100)의 소유권이 일 개인으로부터 다른 개인으로 변경되는 경우에, 이 소유권 변경을 시행하는 가장 간단한 방법은 목표 장치(100)의 1차 비밀키를 어떤 새로운 값으로 설정하는 것이다. 그러나, 이러한 변경이 최초 소유자가 자신의 모든 영구 키를 목표로부터 복구하는 기회를 갖기 전에 발생하면, 그들은 자신의 라이센스를 잃을 것이다. 최초 소유자가 관련 영구 키 리스트의 소유권을 목표 장치와 함께 이전하기를 원하는 경우, 그 특수 장치와 관련된 소유권 정보(허가 기관(510)에 저장되어 있음)를 변경하는 것 외에 목표 장치(100)가 해야 할 것은 아무것도 없다.In the case where ownership of the target device 100 changes from one individual to another, the simplest way to effect this ownership change is to set the primary secret key of the target device 100 to some new value. However, if these changes occur before the original owner has a chance to recover all their permanent keys from the goal, they will lose their license. If the original owner wants to transfer ownership of the associated permanent key list with the target device, the target device 100 must do that in addition to changing the ownership information associated with that special device (stored in the authorization authority 510). There is nothing to do.

라이센스 취소가 발생할 수 있는 다른 경우는 특수 목표 장치(100)의 영구 키 리스트의 마스터 키가 "만료"되는 경우이다. 목표 장치(100) 보안 시스템의 갱신이 영구 키 리스트의 일부로서 저장되기 때문에, 이 상황은 잠재적으로 비참한 반향을 가질 수 있다.Another case where license revocation may occur is when the master key of the permanent key list of the special target device 100 is "expired". Since the update of the target device 100 security system is stored as part of the permanent key list, this situation can potentially have a disastrous echo.

잠재적으로 이러한 곤경으로부터 회복될 수는 있지만, 목표 장치(100)는 처음부터 구축되는 완전히 새로운 "신뢰 사슬(chain of trust)"을 가질 필요가 있다. 이 상황에서, 새로 개시되는 보안 시스템의 핵심은 목표 장치(100)의 일부에서 원자식으로 동작하는 것처럼 검증될 수 있는 그러한 계산에만 기초를 두어야 한다. 따라서, 다른 방식의 범용 코드(이것은 잠재적으로 의심을 받을 수 있다)의 최소량만을 요구하는 임의의 해싱 함수의 사용을 배제한다. 다행히도, 이 상황은 만료가 되지 않은 영구 키 리스트 데이터 구조의 일부로서 검증가능하게 안전한 코드 파편(fragment)의 영구적인 핵심을 항상 유지하는 간단한 방법으로 피할 수 있다. 그러나, 이것은 위에서 설명한 이유 때문에 보안상 위험이 있고, 따라서 이 영구 코드 핵심의 콘텐트는 가능한 한 많이 제한되어야 한다.While potentially recovering from this predicament, the target device 100 needs to have an entirely new "chain of trust" built from scratch. In this situation, the core of the newly disclosed security system should be based only on those calculations that can be verified as operating atomically on a portion of the target device 100. Thus, it excludes the use of any hashing function that requires only a minimal amount of other ways of general-purpose code (which can potentially be suspected). Fortunately, this situation can be avoided in a simple way that always maintains the permanent core of verifiably secure code fragments as part of the permanent key list data structure that has not expired. However, this is a security risk for the reasons described above, so the content of this permanent code core should be limited as much as possible.

라이센스 취소가 발생할 수 있는 또다른 경우는 허가 기관(510)이 목표 장치(100)의 영구 또는 임시 키 리스트의 특수 키 엔트리를 무효화(override) 하기로 선택한 경우이다. 이것은 보안 시스템 업그레이드가 필요한 경우 또는 특수 목표 장치(100)가 특수 애플리케이션 또는 미디어 스트림의 허가되지 않은 복사본을 갖고 있는 것으로 확인된 경우에 사용될 수 있다. 목표 장치(100)는 평소에 자신의 키 리스트 데이터 구조를 유지하고 있기 때문에, 이 절차는 허가 기관(510)과 목표 장치 간의 정상적인 네트워크 트래픽 양보다 더 큰 트래픽을 수반할 것이다. 따라서, 이 동작 과정은 극한의 경우를 위하여 보존되어야 한다.Another case where license revocation can occur is when the licensing authority 510 chooses to override a special key entry in the permanent or temporary key list of the target device 100. This may be used when a security system upgrade is needed or when the special target device 100 is found to have an unauthorized copy of the special application or media stream. Since the target device 100 normally maintains its key list data structure, this procedure will involve traffic that is greater than the normal amount of network traffic between the licensing authority 510 and the target device. Thus, this operating procedure must be preserved for extreme cases.

그럼에도 불구하고, 이러한 절차는 당해 목표 장치(100)가 경쟁 키(disputed key)를 조사하여 디스에이블시키도록 설계된 목표 지정 커스텀 버전으로 자신의 보안 시스템 소프트웨어를 개정하게 하고 및/또는 오래된 소프트웨어를 갱신 버전으로 교체하게 함으로써 달성될 수 있다. 물론, 이 절차는 목표 장치(100)가 허가 기관 중앙 서버와의 접속을 개시한 때의 시점에서의 동작으로만 설정할 수 있다. 정상적인 상황에서는 임의의 특수 목표 장치(100)가 임의의 특수한 계획으로 허가 기관(510)과 접촉을 개시하는 것을 보장할 수 없다. 다행히도, 당해 목표 장치(100)는 자신의 영구 키 리스트에 대한 임의의 새로운 추가를 인증하기 위해 허가 기관(510)에 (직접적으로 또는 간접적으로) 접속하여야 하고, 그래서 임의의 키 취소 동작이 새로운 키 허가 절차의 일부로서 달성될 수 있다. 위에서 설명한 "보안 시스템 타임아웃" 메카니즘을 사용하여 이 "리스트 폴리싱(list policing)" 동작을 지원하는 것도 또한 가능하다. 그러나, 이것이 그 경우인 것 및 그러한 시스템이 사용자 프라이버시 권리의 훼손을 초래할 가능성이 있다는 것은 이 프로토콜에 대한 필요조건이 아니다.Nevertheless, this procedure causes the target device 100 to revise its security system software with a targeted custom version designed to investigate and disable the disputed key and / or update the outdated software. It can be achieved by making a replacement. Of course, this procedure can be set only for the operation at the time when the target apparatus 100 initiates the connection with the authority authority central server. Under normal circumstances, no special target device 100 can be guaranteed to initiate contact with the licensing authority 510 with any special plan. Fortunately, the target device 100 must connect (directly or indirectly) to the authority authority 510 to authenticate any new additions to its permanent key list, so that any key revocation operation is a new key. It can be accomplished as part of the licensing process. It is also possible to support this "list policing" operation using the "Security System Timeout" mechanism described above. However, it is not a requirement for this protocol that this is the case and that such a system is likely to result in a compromise of user privacy rights.

기타 관심사:Other interests:

반드시 프로토콜 자체의 일부는 아니지만 그럼에도 불구하고 여기에서 설명하는 프로토콜을 적절히 실행할 수 있는 실제적인 시스템을 생성하는 처리에서 다루어야 할 다수의 이슈가 있다. 이러한 이슈들 중의 일부는 실제 프로세서 장치의 구현에 의존하고, 다른 것들은 대부분 애플리케이션에 특수한 것이다. 이 정보는 적합한 목표 장치(100)의 적절한 구성에 밀접한 관계가 있기 때문에, 우리는 이 이슈의 일부에 대하여 다음 섹션에서 설명할 것이다.Although not necessarily part of the protocol itself, there are nevertheless a number of issues that must be addressed in the process of creating a practical system that can properly implement the protocol described herein. Some of these issues depend on the implementation of the actual processor device, while others are mostly application specific. Since this information is closely related to the proper configuration of a suitable target device 100, we will discuss some of these issues in the next section.

상호 동작이 가능한 장치 수 제한Limit the Number of Devices That Can Interoperate

1차 목표 장치가 소유권을 임시로 이전할 수 있는 장치의 총 수를 저작권 보유자가 제한하고자 하는 경우에, 이것은 임의의 하나의 시간에 동작할 수 있는 제한된 수의 공개/개인키 쌍을 확립하는 수단에 의해 달성될 수 있다. 이것은 동일한 애플리케이션 지정 키의 복수의 복사본이 위의 섹션에서 설명한 동시 "대여중"인 경우와 다르다는 점에 주목한다. 특수 목표 장치(100)로부터 임의의 애플리케이션 지정 키를 "체크아웃"할 수 있는 장치들의 리스트가 특정 일련 번호 집합으로 제한될 수 있는 다른 시나리오가 가능하다. 허가 기관(510)은 목표 장치(100)의 보안 시스템이 관리되는 것과 정확히 동일한 방법으로 상기 "승인된 차용자" 리스트를 관리할 수 있다. 따라서, 허가 기관(510)은, 예를 들면, "승인된 차용자" 리스트의 일련 번호 집합을 최초 목표 장치(100)와 동일한 소유권 정보를 갖는 것으로 제한할 수 있다. 이 문제에 대한 다른 가능한 해법은 임의의 "차용자" 장치(720)가 중앙 허가 기관(510)의 공개키로 증명서(certificate)를 복호함으로써만 검증될 수 있는 신임장(credential)(서명된 증명서 등)을 대여자에게 제공함으로써 "인증"된 차용자로서 유효화될 것을 요구하는 것이다. 이 시나리오는 물론 특수 유닛이 절충된 것으로 결정된 경우에 허가 기관(510)이 상기 증명서를 취소하는 능력을 수반한다. 이 증명서 취소 처리가 달성될 수 있는 한가지 잘 알려져 있는 방법은 정기적으로 발행되는 "취소 리스트"를 이용하는 것이다.If the copyright holder wishes to limit the total number of devices to which the primary target device can temporarily transfer ownership, this means that a limited number of public / private key pairs can be operated at any one time. Can be achieved by Note that this is different from the case where multiple copies of the same application specific key are concurrent "rental" described in the section above. Another scenario is possible where the list of devices capable of "checking out" any application specific key from the special target device 100 may be limited to a particular set of serial numbers. The authorization authority 510 may manage the "approved borrower" list in exactly the same way that the security system of the target device 100 is managed. Thus, the permitting authority 510 may restrict, for example, the set of serial numbers in the "Approved Borrower" list to having the same ownership information as the original target device 100. Another possible solution to this problem is to provide a credential (signed certificate, etc.) that can only be verified by any "borrower" device 720 decrypting the certificate with the public key of the central licensing authority 510. By providing to the lender, it is required to be validated as a "certified" borrower. This scenario, of course, involves the ability of the licensing authority 510 to revoke the certificate if it is determined that the special unit is compromised. One well-known method by which this certificate revocation process can be achieved is by using a regularly published "cancellation list".

비밀키 발견 및 신원 검증 문제Secret Key Discovery and Identity Verification Issues

특수 플레이어에 대한 1차 비밀키가 물리적인 분해 및 칩 다이 시험에 의해 발견되면, 각 장치가 별도의 비밀키(104) 집합을 가질 것이기 때문에 임의의 다른 장치의 보안성을 희생시켜서는 안된다. 그러나, 특수 플레이어의 1차 키가 어떻게든 희생되면 인증되지 않은 장치가 합법적 목표 장치로서 가장할 잠재적인 가능성이 있다. 이 문제가 검지되지 않은 경우에, 이 지식으로 무장한 허가받지 않은 장치가 그 특수 목표 장치에 발행된 임의의 애플리케이션 지정 복호키를 손상시킬 가능성이 있다. 목표 장치(100)의 일련 번호(106)는 허가 기관(510)이 제1 장소에 있는 장치에 복호키를 발행하기 위해 등록되어야 하기 때문에, 이점에 대한 문제점은 허가되지 않은 장치에 의한 다른 방식의 합법적인 목표 장치(100)의 제한으로 명시적으로 제한된다.If the primary secret key for a special player is found by physical disassembly and chip die testing, it should not be sacrificed for the security of any other device since each device will have a separate set of secret keys 104. However, if the primary player's primary key is somehow sacrificed, there is a potential for unauthorized devices to impersonate legitimate target devices. If this problem is not detected, there is a possibility that an unauthorized device armed with this knowledge would compromise any application specified decryption key issued to that special target device. Since the serial number 106 of the target device 100 must be registered in order for the authority authority 510 to issue a decryption key to the device at the first location, the problem with this advantage is that of another method by the unauthorized device. It is expressly limited by the limitation of the legal target device 100.

그러나, 목표 장치(100)의 비밀키가 이러한 처리에 의해 발견되면, 암호화 키 리스트 다이제스트의 복사본을 이전에 백업한 시험에 기초하여 그 유닛에 허가를 준 모든 애플리케이션 지정키를 손상시킬 가능성이 있다. 이 때문에, 1차 비밀키와 2차 비밀키는 이 키들의 값을 찾아내고자 하는 임의의 시도가 키 데이터의 상실을 야기하는 "변경 방지" 방식으로 목표 칩에서 구현되어야 한다.However, if the secret key of the target device 100 is found by such a process, there is a possibility of damaging all the application-specified keys that granted the unit based on a test that previously backed up a copy of the encryption key list digest. Because of this, the primary secret key and the secondary secret key must be implemented on the target chip in a "change prevention" manner in which any attempt to find the value of these keys would result in loss of the key data.

목표 장치(100)에서 변경 방지 특징을 구현하는 다수의 수단이 있지만, 그 정확한 구현은 이 문서에서 설명한 프로토콜에 중요한 것이 아니다. 만일 "비밀키 상실" 상황이 사용자 부분에서 부주의(또는 남용)에 따른 어떤 악의없는 행동에 의해 발생하였으면, 합법적인 사용자는 손상된 유닛의 애플리케이션 지정키를 새로운 장치에 이전시키도록 배열할 수 있는 허가 기관(510)에 자신의 손상된 유닛을 되돌려보낼 수 있어야 한다. 그러나, 최초의 목표 장치(100)가 기능할 수 없는 경우에, 새로운 목표 장치(100)로의 키 이전은 (적어도 제1 장소에서 명문으로 허가 기관(510)에 공급되지 않은 키에 대해서) 애플리케이션 개발자(520)와의 트랜잭션을 수반하여야 한다.While there are a number of means for implementing the tamper resistant feature in the target device 100, the exact implementation is not critical to the protocol described in this document. If the "lost key" situation was caused by some malicious act of negligence (or abuse) at the user's part, the legitimate user could arrange to transfer the application-specific key of the compromised unit to a new device. It should be possible to return its damaged unit to (510). However, if the original target device 100 is unable to function, the transfer of keys to the new target device 100 (at least for keys that are not supplied predominantly to the authorization authority 510 at the first location) is an application developer. Must be accompanied by a transaction with 520.

그러나, 다른 진정한 목표 장치(100)를 흉내낼 수 있었던 장치는 표면상으로, 신용하는 합법적으로 허가된 장치를 하나 이상의 애플리케이션 지정 키의 임시 포기하는 소유권으로 또는 일시 정지한 동작으로 속일 수 있다는 점에 주목하여야 한다(위에서 설명하였음). 후자의 경우가 발생하면, 키를 차용하려고 시도한 모든 장치들을 디스에이블시키는 "부정 장치(rogue unit)"를 가질 가능성이 존재한다. 전자의 경우가 발생하면, 임의 갯수의 애플리케이션 또는 미디어 지정 키들이 잠재적으로 절충될 수 있다.However, it is noted that a device that has been able to mimic another true target device 100 may, on the surface, fool a trusted legally authorized device with temporary relinquish ownership of one or more application-specified keys or with suspended operation. (As described above). If the latter case occurs, there is a possibility of having a "rogue unit" that disables all devices attempting to borrow a key. If the former case occurs, any number of application or media specific keys can potentially be compromised.

따라서, 특수 목표 장치(100)에 대해 잠재적인 "허가된 차용자"의 수를 허가 기관(510) 서버로부터의 안전한 갱신에 의해 합법적인 장치에 공급될 수 있는 리스트로 제한하는 것에 관한 위에서 설명한 개념은 세심한 것이다. 전자의 경우에, 이것은 유닛이 제1 장소에서 그들에게 실제로 속하지 않는 한 다른 신용하는 장치의 소유자가 그 비밀키에 액세스하기 위해 기능 유닛을 분해하는 해커에 의해 디스에이블된 합법적 장치를 갖는 것을 방지할 것이다. 후자의 경우에, 이것은 하나의 지점에서 허가 기관에 적절히 등록된 허가된 장치이었던 그러한 장치들에게 애플리케이션 또는 미디어 지정 키가 이전하는 것을 제한할 것이다. 그럼에도 불구하고, 단호한 해커는 여전히 합법적 장치를 구매하고, 그것을 분해하여 어떻게든 그 비밀키 데이터에 액세스하며, 그 다음에 합법적 장치로 가장하기 위해 이 정보를 이용할 수 있다.Thus, the concept described above regarding limiting the number of potential "authorized borrowers" for the special target device 100 to a list that can be supplied to legitimate devices by a secure update from the license authority 510 server is It is meticulous. In the former case, this would prevent the owner of another crediting device from having a legitimate device disabled by a hacker who disassembles the functional unit to access its private key unless the unit actually belongs to them in the first place. will be. In the latter case, this would limit the transfer of the application or media assignment key to those devices that were authorized devices properly registered with the authority at one point. Nevertheless, a determined hacker can still use this information to purchase a legitimate device, disassemble it and somehow access its private key data, and then impersonate the legitimate device.

그래서, 이러한 종류의 흉내 사건(impersonation event)을 탐지하기 위하여 어떻게 할 것인지에 대한 이슈가 남아있다. 이러한 성질에 극히 잘 대처하는 반대자(opponent)를 좌절시키기 위한 유일한 성공적인 전략은 적어도 비용 교환조건 관점에서 잠재적 이득이 요구되는 노력을 무가치하게 하도록 시스템을 설계하는 것이다.Thus, there remains an issue of what to do to detect this kind of impersonation event. The only successful strategy to frustrate opponents who cope very well with these properties is to design the system to make the effort worth the potential benefits at least in terms of cost exchange conditions.

통신을 행하는 다른 알 수 없는 장치의 진정성을 증명하기 위한 몇 가지 수단이 있다. 그러나, 장치가 사실상 청구하는 것임을 입증하는 가장 성공적인 방법은 이 장치를 다른 장치와 구별되게 하는 특성에 촛점을 맞추는 것이다. 이 문서에서 설명하는 디지털 복호 메카니즘과 같은 특수 용도 장치의 경우에는 장치가 보안 프로토콜을 적절히 실행하고 주어진 입력 변수 집합에 기초하여 정확한 결과를 계산하는 능력이다. 그러나, 여기에서 설명하는 보안 프로토콜은 공개적으로 알려진 알고리즘에 기초를 두기 때문에, 이것은 표면상 계산 완료까지 충분한 시간을 갖는 임의의 범용 컴퓨팅 장치에 의해 달성될 수 있다. 사실, 이 이슈는 장치를 유일하게 하는 비밀키 정보가 어떻게든 절충되면 공개적으로 이용가능한 기술에 기초한 임의의 장치에 대하여 잠재적인 문제가 될 것이다. 따라서, 분해 및 칩 다이 검사에도 불구하고 모든 합법적 목표 장치를 위하여 온칩으로 저장된 비밀키 정보가 비밀로 유지되어야 하는 교훈에 궁극적으로 의존해야 한다.There are several means to prove the authenticity of other unknown devices that communicate. However, the most successful way to prove that a device is in fact a claim is to focus on the characteristics that make this device different from other devices. For special purpose devices, such as the digital decryption mechanism described in this document, it is the ability of the device to properly implement security protocols and to calculate accurate results based on a given set of input variables. However, since the security protocol described herein is based on publicly known algorithms, this can be achieved by any general purpose computing device having sufficient time to complete the on-the-fly calculation. In fact, this issue will be a potential problem for any device based on publicly available technology if the private key information that makes the device unique is somehow compromised. Thus, despite disassembly and chip die inspection, it must ultimately rely on the lesson that secret key information stored on-chip must be kept secret for all legitimate target devices.

우리는 소정량의 시간 내에서 검증가능한 MAC 값을 정확하게 찾아내는 능력과 같은 목표 식별 및 검증 처리에 대한 필요조건을 확실하게 추가할 수 있다. 우리는 최종 MAC 값이 복수회 암호화되는 것을 요구함으로써 절차를 더 어렵게 할 수 있다. 따라서, 우리는 라이센스 자체의 합법적 복사본을 단순히 구매하는 비용보다 일반적으로 훨씬 더 비싼 (더 일반적인) 연산 리소스에 액세스할 것이 요구된다는 점에서 합법적 장치를 위조하는 공격자의 능력을 잠재적으로 제한할 수 있다. 미디어 스트림 플레이어의 경우, 플레이어가 표면상 수용하도록 설계되는 하나 이상의 미디어 스트림의 일부를 정확히 디코드하는 능력을 또한 포함할 수 있다.We can certainly add requirements for target identification and verification processing, such as the ability to accurately find verifiable MAC values within a certain amount of time. We can make the procedure more difficult by requiring the final MAC value to be encrypted multiple times. Thus, we could potentially limit the attacker's ability to forge a legitimate device in that it would be required to access computational resources that are generally much more expensive than simply buying a legal copy of the license itself. In the case of a media stream player, it may also include the ability to accurately decode a portion of one or more media streams that the player is designed to receive on the surface.

그러나, 어쨌든, 디지털 저작권 보호의 전체 과정은 튜링 문제(Turing problem)이다. 따라서, 충분한 시간 및 리소스가 주어지면, 임의의 디지털 저작권 보호 방식이 단호한 반대자에 의해 좌절될 수 있다. 이것은 물론 비밀키 정보에 대한 액세스가 명확하게 예비 공격자에 대해 큰 장점으로 된다는 사실과 무관하다. 그러므로, 유닛의 비밀키가 절충되지 않도록 지키는 능력은 이 보안 프로토콜의 중요한 부분이다.However, anyway, the whole process of digital copyright protection is a Turing problem. Thus, given enough time and resources, any digital copyright protection scheme can be frustrated by determined opponents. This is of course irrelevant to the fact that access to private key information is clearly a huge advantage for prospective attackers. Therefore, the ability to keep the unit's private key from being compromised is an important part of this security protocol.

ê²°ë¡ :conclusion:

위에서 설명한 저작권 보호 프로토콜은 몇 가지 방법에서 유일한 것이다. 첫번째는 사용자가 합법적으로 구매한 애플리케이션 또는 미디어 지정 키 데이터의 백업 복사본을 만들 능력을 갖지 못하도록 시도하지 않는다는 사실이다. 둘째로, 이 프로토콜은 임의 종류의 디지털 데이터 간에 차이를 만들지 않으며, 따라서 보안 프로토콜이 보호하도록 설계된 데이터 스트림처럼 쉽게 갱신되게 한다. 셋째로, 이 프로토콜은 사용자가 자신의 애플리케이션 또는 미디어 지정 키의 소유권을 프로토콜을 실행할 수 있는 다른 유닛에 임시로 이전할 수 있게 한다. 또한, 이 프로토콜은 허가받은 자가 소유권을 하나의 목표 장치(100)로부터 다른 목표 장치로 영구 이전하는 능력을 제공한다. 상기 마지막 특성은 이 프로토콜 하에서 소비자의 법적 "최초 판매 권한"의 구현을 가능하게 한다.The copyright protection protocol described above is unique in several ways. The first is that it does not attempt to prevent the user from having the ability to make backup copies of legally purchased application or media specific key data. Secondly, this protocol does not make a difference between any kind of digital data and thus allows the security protocol to be updated as easily as the data stream designed to protect. Third, the protocol allows users to temporarily transfer ownership of their application or media specific key to another unit capable of executing the protocol. The protocol also provides the ability for an authorized person to permanently transfer ownership from one target device 100 to another. This last feature enables the consumer to implement a legal "first selling right" under this protocol.

사실, 이 문서에서 설명한 프로토콜과 다른 복사 보호 방식 간의 기본적인 차이 중의 하나는 이 시스템의 보안이 특수 데이터 집합에 액세스하는 능력을 제어하는 것에 의존하는 것이 아니라 오히려 데이터 집합 내에 포함된 아이디어를 표시하는 동작을 제어하는 능력에 의존한다는 것이다.In fact, one of the fundamental differences between the protocols described in this document and other copy protection schemes is that the security of this system does not rely on controlling the ability to access special data sets, but rather to display ideas contained within the data sets. It depends on your ability to control.

앞의 명세서에서, 본 발명은 특정 실시예를 참조하여 설명하였다. 그러나, 이 기술에 통상의 지식을 가진 자라면 아래의 청구범위에서 규정하는 본 발명의 범위로부터 벗어나지 않고 여러 가지로 수정 및 변경이 가능하다는 것을 알 것이다. 따라서, 명세서 및 도면은 제한하는 의도라기보다는 예시적인 것으로 간주되어야 하고, 그러한 수정들은 모두 본 발명의 범위에 포함된 것으로 의도된다.In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention.

잇점, 다른 장점 및 문제점에 대한 해법을 특정 실시예와 관련하여 위에서 설명하였다. 그러나, 잇점, 장점, 문제점에 대한 해법, 및 임의의 잇점, 장점 또는 해법을 발생시키거나 더 명백하게 하는 임의의 컴포넌트는 임의의 또는 모든 청구항의 중요한, 요구된, 또는 본질적인 특징 또는 컴포넌트로 해석되어서는 안된다.Benefits, other advantages, and solutions to problems have been described above in connection with specific embodiments. However, any benefit, advantage, solution to a problem, and any component that produces or makes any benefit, advantage, or solution more obvious, should be construed as an important, required, or essential feature or component of any or all claims. Can not be done.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4