KR20150011802A - 프로세스 작업 세트 격리를 위한 방법 및 시스템 - Google Patents

프로세스 작업 세트 격리를 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20150011802A
KR20150011802A KR1020147029364A KR20147029364A KR20150011802A KR 20150011802 A KR20150011802 A KR 20150011802A KR 1020147029364 A KR1020147029364 A KR 1020147029364A KR 20147029364 A KR20147029364 A KR 20147029364A KR 20150011802 A KR20150011802 A KR 20150011802A
Authority
KR
South Korea
Prior art keywords
security
key
cache
data
code
Prior art date
Application number
KR1020147029364A
Other languages
English (en)
Inventor
윌리엄 브이 옥스포드
Original Assignee
크림메니 테크놀로지스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 크림메니 테크놀로지스, 인크. filed Critical 크림메니 테크놀로지스, 인크.
Publication of KR20150011802A publication Critical patent/KR20150011802A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0837—Cache consistency protocols with software control, e.g. non-cacheable data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466—Key-lock mechanism
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

본 명세서에 개시되어 있는 시스템들 및 방법들의 실시예들은, 원래의 프로세스가 종료된 후에도, 작업 세트의 데이터가 다른 프로세스들에 의해 액세스가능하지 않도록, 프로세스의 작업 세트를 격리시킬 수 있다. 보다 구체적으로는, 특정의 실시예에서, 실행 중인 프로세스의 작업 세트가 캐시에 저장될 수 있고, 보안 모드에 있는 동안 기입되는 그 캐시 라인들 중 임의의 것에 대해, 그 캐시 라인들이 현재 실행 중인 프로세스에 대한 보안 서술자와 연관될 수 있다. 보안 서술자는, 그 캐시 라인들에 대한 액세스가 그 프로세스로만 제한될 수 있도록, 그 캐시 라인들을 실행 중인 보안 프로세스에 속하는 것으로 일의적으로 명시할 수 있다.

Description

프로세스 작업 세트 격리를 위한 방법 및 시스템{METHOD AND SYSTEM FOR PROCESS WORKING SET ISOLATION}
관련 출원
본 출원은 미국 특허법 제119조 하에서 2012년 3월 20일자로 출원된, 발명의 명칭이 "프로세스 작업 세트 격리를 위한 방법 및 시스템(Method and System for Process Working Set Isolation)"인 William V. Oxford의 미국 가특허 출원 제61/613,290호(참조 문헌으로서 그 전체가 본 명세서에 완전히 포함됨)에 기초하여 우선권을 주장한다.
본 개시 내용은 일반적으로 컴퓨터 시스템에서의 보안에 관한 것이다. 보다 구체적으로는, 본 개시 내용은 컴퓨팅 시스템의 프로세스들과 연관되어 있는 데이터(명령어들을 포함함)를 보호하는 것에 관한 것이다. 보다 상세하게는, 본 개시 내용은 재귀적 보안 프로토콜(recursive security protocol)의 구현과 관련하여 실행 중인 컴퓨팅 시스템의 프로세스들과 연관되어 있는 데이터를 보호하는 것에 관한 것이다.
컴퓨터 바이러스들 및 다른 악의적 소프트웨어는 정보 기술 산업에 대해 엄청난 문제를 야기한다. 범용 컴퓨터가, 정의에 의해, 임의의 코드를 실행할 수 있기 때문에, 정확히 어느 소프트웨어가 주어진 범용 컴퓨터 플랫폼 상에서, 부분적으로 또는 전체적으로, 실행될 수 있는지에 대한 제어를 유지하는 것이 아주 어려울 수 있다. 이 때문에, 멀웨어(malware) 또는 다른 유형들의 바람직하지 않은 소프트웨어의 실행을 방지하는 것이 어려울 수 있다. 이 통제 레벨이 현재 시도되는 다수의 방법들이 있지만, 프로세서를 공격으로부터 격리시키는 대부분의 노력들은 2가지 기본적인 문제들, 즉 프로세서 플랫폼에서의 일반성의 상실 또는 성능의 손실을 겪는다. 이러한 상실 또는 손실은 안전하게 보존되어야만 하는 데이터를 자유롭게 공개될 수 있는 데이터로부터 어떻게 격리시킬지 및 허가된 사용 모드와 허가되지 않은 사용 모드를 어떻게 신속하고 명백하게 구분할지의 기본적인 문제에 기인한다.
부차적인 관련 문제는 저작권 관리(copyright control)의 문제이다. 현재 제작되는 대부분의 필기, 오디오 및 시각적 예술 작품들은 디지털 형식으로 시작되거나 끝난다. 디지털 데이터의 특성들 중 하나는 용이하게 거의 똑같이 복제될 수 있다는 것이다. 이 특성은 각종의 저렴한 배포 메커니즘들을 용이하게 하고, 그들 대부분이 쉽게 통제되지 않는다. 디지털 콘텐츠의 배포를 본질적으로 제한할 수 없다는 것이 지난 20년에 걸쳐 저작권법의 영역에 지대한 영향을 미쳤다. 이러한 복제된 데이터의 복사 및 배포를 통제하는 특정의 시스템들 및 방법들이 개발되었지만, 이 시스템들 및 방법들에서의 하나의 문제는 이들이 이 시스템들 및 방법들과 관련한 특정의 유형의 소프트웨어, 예를 들어, 허가되지 않은 또는 의도되지 않은 방식으로 이 시스템들 및 방법들을 수정하거나 이러한 시스템들 및 방법들에 의해 이용되는 데이터를 획득하는 코드의 실행을 통해 회피될 수 있다는 것이다.
상세하게는, 컴퓨터 상에서 실행 중인 이러한 보안 시스템들에 의해 액세스되는(예컨대, 판독되거나 기입되는) 데이터를 획득하기 위해 특정의 기법들이 이용될 수 있다. 이 데이터는 이어서 이러한 보안 시스템들을 회피하고 따라서 디지털 데이터의 복사 및 배포에 대한 통제를 회피하려는 시도들에서 이용될 수 있다.
그에 따라, 이러한 보안 시스템들의 데이터도 마찬가지로 보호되는 시스템들 및 방법들을 찾을 필요가 있고, 여기서 이러한 데이터를 보호하는 것에 의해, 이러한 보안 시스템의 유효성이 향상될 수 있다.
보안 모드(secure mode)에서 실행 중인 프로세스의 작업 세트를 격리시키는 시스템들 및 방법들의 실시예들이 개시되어 있다. 이 시스템들 및 방법들의 실시예들이 이용될 때, 일반성이 방해받지 않는 것은 물론 많은 다른 보안 시스템들을 능가하는 공격에 대한 보호 레벨이 획득될 수 있다.
상세하게는, 하나의 실시예에서, 특정의 계산에서 사용되는 데이터에 대한 직접적인 액세스를 방지하는 시스템들 및 방법들은 그럼에도 불구하고 여전히 그 데이터의 사용을 가능하게 한다. 다른 실시예에서, 하나의 소프트웨어 프로세스에 의해 사용되는 데이터에 대한 액세스가 임의의 다른 소프트웨어 프로세스에는 거부될 수 있다. 데이터 액세스 통제를 위한 이 시스템들 및 방법들의 실시예들이 디지털 보안, 저작권 관리, 조건부 액세스, 바람직하지 않은 컴퓨터 바이러스들에 대한 보호(이들로 제한되지 않음) 등을 포함할 수 있는 보안 영역들을 비롯한 많은 수의 잠재적인 응용 영역들에서 사용될 수 있다. 구체적으로는, 실시예들이 재귀적 보안 프로토콜과 관련하여 이러한 보안 프로토콜을 보강하기 위해 이용될 수 있다.
그에 부가하여, 이 유형의 방법들을 컴퓨터 시스템들, 하드웨어, 및 소프트웨어로 구현하는 시스템들의 실시예들이 제시된다. 유의할 점은, 똑같은 하드웨어 구현이, 소프트웨어의 요구사항들에 따라, 전 범위의 해결책들 중 임의의 하나 또는 조합을 구현하는 데 어쩌면 사용될 수 있다는 것이다.
더욱이, 실시예들이 독자적인 협력 프레임워크에서 함께 동작하는 3개의 교차하는 기술 구성요소들로 이루어져 있는 간단하고 쉽게 이해되는 보안 프로토콜을 제공한다. 개별적인 구성요소들의 단순성, 완전한 아키텍처 독립성, 및 그들의 낮은 구현 오버헤드는 이 시스템을 아주 다양한 아키텍처들 및 배포 시나리오들에 적합하게 만든다. 실시예들이, 임의의 기존의 소프트웨어에 대한 최소한의 변경으로, 간단한 저성능 시스템들은 물론 정교하고 복잡한 고처리율 설계들에도 배포될 수 있다.
실시예들에 기술된 바와 같이 구현되는 경우, 이러한 접근 방법의 실시예들은 "영 지식(Zero-Knowledge)" 측면들을 갖는 것으로 입증될 수 있고, 따라서 적응적 선택 암호문 공격(Adaptive Chosen-Ciphertext attack)과 같은 공지된 공격 전략들에 직면하여 안전한 것으로 증명가능할 수 있다. 시스템의 비밀 키들(Secret Keys)을 (직접적으로는 물론 간접적으로도) 구조적으로 보이지 않게(architecturally invisible) 만드는 것에 의해 그리고 임의의 보안 프로세스의 작업 세트를 임의의 다른 프로세스로부터 격리시킬 수 있는 것에 의해, 정확히 구현된 재귀적 보안 시스템(Recursive Security system)은 재생 공격(Replay Attack)에 영향을 받지 않고 경쟁하는 솔루션들에서는 대처하지 못하는 ROP 익스플로이트(Return-Oriented Programming exploit)에 대한 내성을 제공하는 것으로 입증될 수 있다.
재귀적 보안 프로토콜의 실시예들은 또한 모든 종류의 멀웨어와의 싸움에서 유용할 수 있다. 보다 전통적인 "실행 권한 거부(Permission to Execute Denied)" 방법과 달리 그의 "실행을 위해 권한이 필요함(Permission Required to Execute)" 접근 방법으로 인해(흔히 "허용 목록(White-Listing)" 대 "차단 목록(Black Listing)" 방식이라고 함), 허가되지 않은 및/또는 수정된 소프트웨어 실행파일들이 임의의 아키텍처의 시스템에서 실행되지 못하게 하기 위해 재귀적 보안 프로토콜이 사용될 수 있다.
하나의 실시예에서, 프로세스가 프로세서 상에서 보안 모드로 실행 중일 수 있고 데이터가 캐시의 라인에 저장되어 있을 수 있으며, 여기서 데이터는 프로세서 상에서 보안 모드로 실행되는 프로세스에 의해 저장되었다. 이러한 캐시의 라인들에 대한 액세스가, 프로세스와 연관되어 있는 보안 서술자(secure descriptor)를 사용하여, 그 프로세스만이 캐시의 라인에 액세스할 수 있도록 통제될 수 있고, 여기서 보안 서술자는 프로세서 및 캐시를 포함하는 시스템의 하드웨어에 저장되어 있는 비밀 키에 기초하고 있다. 어떤 실시예들에 따르면, 심지어 프로세스가 종료된 후에도 액세스가 통제될 수 있다.
어떤 실시예들에서, 보안 서술자에 기초하여 보안 모드에 진입되었으며, 프로세스의 전체 작업 세트가 캐시에 저장되고, 보안 모드로 디스에이블되어 있는 캐시 이외의 메모리 장소에 기입된다. 게다가, 캐시의 라인은 프로세스와 연관된 보안 서술자와 연관되어 있을 수 있거나, 프로세스가 데이터를 기입할 때 캐시의 라인과 연관된 보안 플래그가 세트되어 있을 수 있다.
다른 실시예에서, 캐시의 라인에 대한 액세스를 제어하는 것은 캐시의 라인이 현재 실행 중인 프로세스에 의해 액세스되고 있는 것으로 판정하는 것, 현재 실행 중인 프로세스가 보안 모드로 실행 중인지를 판정하는 것, 현재 실행 중인 프로세스와 연관된 보안 서술자를 결정하는 것, 보안 서술자를 라인과 연관된 보안 서술자와 비교하는 것 및 현재 실행 중인 프로세스가 보안 모드로 실행 중이고 보안 서술자들이 일치하는 경우에만 액세스를 허용하는 것을 포함할 수 있다.
이하의 설명 및 첨부 도면들과 관련하여 고려될 때 본 개시 내용의 이들 및 기타 측면들이 더 잘 이해될 것이다. 그렇지만, 이하의 설명이, 본 발명의 다양한 실시예들 및 그의 많은 구체적인 상세들을 나타내고 있지만, 제한이 아닌 예시로서 주어져 있다는 것을 잘 알 것이다. 본 발명의 사상을 벗어나지 않고 본 발명의 범위 내에서 많은 치환들, 수정들, 부가들 및/또는 재구성들이 행해질 수 있고, 본 발명은 모든 이러한 치환들, 수정들, 부가들 및/또는 재구성들을 포함한다.
본 발명의 특정의 측면들을 나타내기 위해 본 명세서에 첨부되어 그의 일부를 형성하는 도면들이 포함되어 있다. 본 발명 및 본 발명에서 제공된 시스템들의 동작 및 구성요소들에 대한 더 명확한 이해가, 동일한 참조 번호들이 동일한 구성요소들을 가리키고 있는 도면들에 예시되어 있는 예시적인, 따라서 비제한적인 실시예들을 참조함으로써, 더 즉각적으로 명백하게 될 것이다. 본 명세서에 제공된 설명과 함께 이 도면들 중 하나 이상을 참조함으로써 본 발명이 더 잘 이해될 수 있다. 주목할 점은, 도면들에 예시된 특징부들이 반드시 축척대로 그려져 있는 것은 아니라는 것이다.
도 1은 콘텐츠 배포를 위한 아키텍처의 하나의 실시예를 나타낸 도면.
도 2는 대상 디바이스의 하나의 실시예를 나타낸 도면.
도 3은 보안 실행 제어기(secure execution controller)의 하나의 실시예를 나타낸 도면.
도 4a 및 도 4b는 프로세스 작업 세트 격리(process working set isolation)를 위해 사용되는 캐시의 일 실시예를 나타낸 도면.
도 5는 보안 코드 블록 실행(secured code block execution)의 일 실시예를 나타낸 도면.
도 6은 보안 코드 블록 실행의 일 실시예를 나타낸 도면.
도 7은 보안 코드 블록 실행의 일 실시예를 나타낸 도면.
도 8 내지 도 14는 프로세스 작업 세트 격리의 일 실시예를 나타낸 도면.
도 15는 복합 키(compound key) 발생의 일 실시예를 나타낸 도면.
도 16은 복합 키 발생의 일 실시예를 나타낸 도면.
도 17은 복합 키 발생의 일 실시예를 나타낸 도면.
도 18은 복호화 키 데이터 구조(decryption key data structure)의 일 실시예를 나타낸 도면.
도 19는 보안 프로토콜의 암호화된 및 배포 프로세스의 일 실시예를 나타낸 도면.
도 20은 보안 프로토콜의 일 실시예에 대한 복호화 및 로딩 프로세스를 나타낸 도면.
도 21은 보안 프로토콜의 암호화/복호화 프로세스의 하나의 실시예를 나타낸 도면.
도 22는 키 목록 데이터 구조(key list data structure)의 일 실시예를 나타낸 도면.
도 23은 일시적 키 소유권 이전 절차(temporary key ownership transfer procedure)의 일 실시예를 나타낸 도면.
도 24는 복합 키의 생성의 하나의 실시예를 나타낸 도면.
도 25a 및 도 25b는 디지털 서명 또는 그의 등가물의 생성의 실시예들을 나타낸 도면.
도 26a 및 도 26b는 보안 코드 블록을 갖는 복합 키 구조(compound key structure)의 사용의 실시예들을 나타낸 도면.
도 27은 복합 메시지 다이제스트(compound message digest)의 사용의 하나의 실시예를 나타낸 도면.
도 28a, 도 28b 및 도 28c는 보안 코드 블록 메시지(secured code block message)의 실시예들을 나타낸 도면.
도 29는 복호화 동작의 일 실시예를 나타낸 도면.
도 30은 복합 키의 사용의 하나의 실시예를 나타낸 도면.
도 31은 후보 코드 블록의 허가(authorization)에서의 복합 키의 사용의 하나의 실시예를 나타낸 도면.
도 32는 복호화 동작의 하나의 실시예를 나타낸 도면.
도 33은 코드 블록의 검증(validation)의 하나의 실시예를 나타낸 도면.
도 34는 재귀적 보안 프로토콜을 사용하여 수행되는 복호화 동작의 하나의 실시예를 나타낸 도면.
도 35는 코드 검증(code validation)의 동작의 하나의 실시예를 나타낸 도면.
도 36은 디지털 서명 함수 블록의 하나의 실시예를 나타낸 도면.
본 발명 및 그의 다양한 특징들 및 유리한 상세들이 첨부 도면들에 예시되고 이하의 설명에서 상세히 기술된 비제한적인 실시예들을 참조하여 더 상세히 설명된다. 상세히 기술하여 본 발명을 불필요하게 모호하게 하지 않기 위해, 공지된 시작 물질들, 처리 기법들, 구성요소들 및 장비에 대한 설명이 생략되어 있다. 그렇지만, 상세한 설명 및 구체적인 예들이, 본 발명의 바람직한 실시예들을 나타내고 있지만, 제한이 아니라 단지 예시로서 주어져 있다는 것을 잘 알 것이다. 기초를 이루는 발명 개념의 사상 및/또는 범위 내에서의 다양한 치환, 수정, 부가 및/또는 재배치가 본 개시 내용으로부터 기술 분야의 당업자에게 명백하게 될 것이다. 본 명세서에서 논의되는 실시예들은 컴퓨터 판독가능 매체(예컨대, 하드 디스크(HD)), 하드웨어 회로 등, 또는 임의의 조합에 존재할 수 있는 적당한 컴퓨터 실행가능 명령어들로 구현될 수 있다.
본 명세서에서 사용되는 바와 같이, "구비한다", "구비하는", "포함한다", "포함하는", "갖는다", "갖는" 또는 그의 임의의 다른 변형과 같은 용어들은 비배타적 포함(non-exclusive inclusion)을 포괄하기 위한 것이다. 예를 들어, 일련의 요소들을 포함하는 프로세스, 물품, 또는 장치가 꼭 그 요소들만으로 제한되지 않고 명확히 열거되어 있지 않은 또는 이러한 프로세스, 물품 또는 장치에 본질적인 다른 요소들을 포함할 수 있다. 게다가, 달리 명확히 언급하지 않는 한, "또는"은 배타적 논리합(exclusive or)이 아니라 포함적 논리합(inclusive or)을 말한다. 예를 들어, 조건 A 또는 B는 다음과 같은 것들 중 임의의 것에 의해 충족된다: A가 참(또는 존재함)이고 B가 거짓(또는 존재하지 않음)인 것, A가 거짓(또는 존재하지 않음)이고 B가 참(또는 존재함)인 것, 그리고 A 및 B 둘 다가 참(또는 존재함)인 것.
그에 부가하여, 본 명세서에 주어진 임의의 예들 또는 예시들은 결코 이들에 대해 이용되는 임의의 용어 또는 용어들에 대한 한정들, 제한들 또는 명확한 정의들로서 보아서는 안된다. 그 대신에, 이 예들 또는 예시들은 하나의 특정의 실시예와 관련하여 그리고 단지 예시적인 것으로서 기술되는 것으로 보아야 한다. 예를 들어, 본 명세서에 기술된 실시예들이 재귀적 보안 시스템과 관련한 그의 구현에 대해 기술되어 있지만, 주목할 점은, 다른 실시예들이 프로세스 작업 세트들을 보호하기 위해 다른 상황들에서 유용하게 적용될 수 있다는 것이다.
당업자라면 이 예들 또는 예시들에 대해 이용되는 임의의 용어 또는 용어들이 그와 함께 또는 본 명세서의 다른 곳에서 주어져 있을 수 있거나 그렇지 않을 수 있는 다른 실시예들을 포괄할 것이고 모든 이러한 실시예들이 그 용어 또는 용어들의 범위 내에 포함되는 것으로 보아야 하는 것임을 잘 알 것이다. 이러한 비제한적 예들 및 예시들을 가리키는 표현으로는 "예를 들어", "예를 들면", "예컨대", "하나의 실시예에서"가 있지만, 이들로 제한되지 않는다.
본 발명의 실시예들은 네트워크(예를 들어, 인터넷(Internet), 인트라넷, 인터넷(internet), WLAN, LAN, SAN 등), 다른 컴퓨터에 통신 연결되어 있는 컴퓨터에서, 또는 독립형 컴퓨터에서 구현될 수 있다. 당업자에게 공지되어 있는 바와 같이, 컴퓨터는 중앙 처리 장치("CPU") 또는 프로세서, 적어도 하나의 판독 전용 메모리("ROM"), 적어도 하나의 랜덤 액세스 메모리("RAM"), 적어도 하나의 하드 드라이브("HD"), 및 하나 이상의 입출력("I/O") 디바이스(들)를 포함할 수 있다. I/O 디바이스들은 키보드, 모니터, 프린터, 전자 포인팅 디바이스(예를 들어, 마우스, 트랙볼, 스타일리스트 등), 또는 기타를 포함할 수 있다. 실시예들에서, 컴퓨터는 네트워크를 통해 적어도 하나의 데이터베이스에 액세스한다.
ROM, RAM 및 HD는 CPU에 의해 실행가능한 또는 CPU에 의해 실행가능하도록 컴파일 또는 인터프리트될 수 있는 컴퓨터 실행가능 명령어들을 저장하기 위한 컴퓨터 메모리이다. 본 개시 내용에서, "컴퓨터 판독가능 매체"라는 용어는 ROM, RAM 및 HD로 제한되지 않고, 프로세서에 의해 판독될 수 있는 임의의 유형의 데이터 저장 매체를 포함할 수 있다. 예를 들어, 컴퓨터 판독가능 매체는 데이터 카트리지, 데이터 백업 자기 테이프, 플로피 디스켓, 플래시 메모리 드라이브, 광 데이터 저장 드라이브, CD-ROM, ROM, RAM, HD 등을 말하는 것일 수 있다. 본 명세서에 기술되어 있는 프로세스들은 컴퓨터 판독가능 매체(예를 들어, 디스크, CD-ROM, 메모리 등) 상에 존재할 수 있는 적당한 컴퓨터 실행가능 명령어들로 구현될 수 있다. 다른 대안으로서, 컴퓨터 실행가능 명령어들은 DASD 어레이, 자기 테이프, 플로피 디스켓, 광 저장 디바이스, 또는 다른 적절한 컴퓨터 판독가능 매체 또는 저장 디바이스에 소프트웨어 코드 컴포넌트들로서 저장될 수 있다.
본 발명의 하나의 예시적인 실시예에서, 컴퓨터 실행가능 명령어들은 C++, Java, JavaScript, 또는 임의의 다른 프로그래밍 또는 스크립팅 코드의 라인들일 수 있다. 일 실시예에서, HTML은 코딩을 통한 자동화 및 계산의 수단을 제공하기 위해 JavaScript를 이용할 수 있다. 다른 소프트웨어/하드웨어/네트워크 아키텍처들이 사용될 수 있다. 예를 들어, 본 발명의 기능들은 하나의 컴퓨터 상에서 구현되거나 2개 이상의 컴퓨터들 간에 공유될 수 있다. 하나의 실시예에서, 본 발명의 기능들이 네트워크에 분산되어 있을 수 있다. 본 발명의 실시예들을 구현하는 컴퓨터들 간의 통신은 임의의 전자 신호, 광 신호, 무선 주파수 신호, 또는 공지된 네트워크 프로토콜들에 따른 다른 적당한 통신 방법들 및 도구들을 사용하여 달성될 수 있다. 다른 실시예에서, 시스템들 간의 이 통신이 인쇄된 매체를 사용하여 실시될 수 있고, 여기서 사용자는 전달되는 데이터를, 그를 수동으로 입력하는 것에 의해, 대상 "종단점" 시스템에 제공할 수 있다.
그에 부가하여, 개시된 실시예들의 기능들은 하나의 컴퓨터 상에서 구현되거나 네트워크에 있는 또는 네트워크에 걸쳐 있는 2개 이상의 컴퓨터들 간에 공유/분산될 수 있다. 실시예들을 구현하는 컴퓨터들 간의 통신은 임의의 전자 신호, 광 신호, 무선 주파수 신호, 또는 공지된 네트워크 프로토콜들에 따른 다른 적당한 통신 방법들 및 도구들을 사용하여 달성될 수 있다. 본 개시 내용의 목적상, 모듈이 하나 이상의 기능들을 수행하도록 구성되어 있는, 하나 이상의 컴퓨터 프로세스들, 컴퓨팅 디바이스들 또는 둘 다라는 것을 잘 알 것이다. 모듈은 이 기능들에 액세스하기 위해 이용될 수 있는 하나 이상의 인터페이스들을 제공할 수 있다. 이러한 인터페이스들은 API, 웹 서비스를 위해 제공되는 웹 서비스 인터페이스, 원격 프로시저 호출(remote procedure call), 원격 메소드 호출(remote method invocation) 등을 포함한다.
앞서 논의한 바와 같이, 디지털 배포는 미디어 사업을 완전히 그리고 돌이킬 수 없게 바꾸어 놓았고, 엇갈린 결과들을 가져왔다. 임의의 기술적 진보와 같이, 디지털 형식으로의 전환은 창조 예술에 대한 풍부한 새로운 기회들을 가능하게 하였다. 그렇지만, 프로세스에서, 이러한 변화는 예술적 자산을 얼마나 최상으로 배포하고 상품화할지의 오래된 관념에 도전하였다.
하나의 특정의 문제는 디지털 데이터를 복사하는 것의 용이성과 관련이 있다. 위조는 원본 작품이 존재하는 한 문제가 되었지만, 확실한 사본을 제작하는 것은 역사적으로 재능있는 예술가(즉, 전문가 위조범)를 필요로 하였다. 디지털 혁명은 2가지 주목할 만한 측면들에서 규칙들을 변화시켰다. 첫째, 디지털 저작물의 사본이 "원본"과 구분할 수 없는 정확한 복제물일 수 있다. 이와 같이, 디지털 저작물의 "정품" 사본과 "불법" 사본을 구분하는 현실적인 방법이 없을 수 있다. 두번째 변화는 정확한 복제물 사본이 누구에 의해서라도 사실상 마음대로, 아주 저가로 제작될 수 있다는 것이다.
이 2가지 측면들이 디지털 저작물의 정품은 물론 불법 사본을 배포할 전례없는 기회를 생성한다. 과거에는, 저작물의 가치가 실제 대상물에, 불가분적은 아니더라도, 밀접하게 연계되어 있었다. 그렇지만, 디지털 세계에서는, 저작물을 사본당 무시할 정도의 비용으로 전세계적으로 배달할 수 있는 것은, 저작권 소유자 및 저작물의 불법 배포로 이득을 보게 될 자 모두에 대해, 역학 관계를 변화시켰다.
디지털 저작권 관리(DRM)에 들어가기. 성공적인 DRM 시스템의 하나의 목표는 디지털 저작물의 사본을 "무허가" 방식로 배포하는 것을 막는 것이다. 이 전략은 실제 대상물과 저작물 사이의 과거의 관련성과 일치한다. 디지털 시대에는, 이 전략이 많은 이유들로 결함이 있지만, 이 "복사 통제" 접근 방법은 여전히 대부분의 DRM 시스템들이 구축되는 전제이다.
디지털 데이터 배포의 경우에, "통제된" 데이터를 복사하는 것은 그가 배포될 때 일어난다. 배포 지점에서 발신되는 데이터는 그의 의도된 재생 디바이스(들)에 이르기 전에 상당수의 중재자를 통과할 수 있다. 각각의 중간 디바이스는 전체 데이터 스트림이 통과할 때 어쩌면 그의 정확한 복제물 사본을 만들 수 있다. 이와 같이, 전세계적으로 배포되는 디지털 데이터를 "복사"하는 것을 제한하려는 시도들은 본질적으로 무의미할 수 있다. 많은 경우들에서, 배포된 디지털 데이터가 언제라도 복사될 수 있다.
그렇지만, 디지털 데이터의 암호화된 버전은 전형적으로 원본과 유사한 데가 거의 없다. 데이터를 복호화할 수 있는 것은, 실시예들에 따르면, 비밀로 유지되는 단일의 키(보통 전역 키(global key))에 의해 중재될 수 있다.
사실상, 전역 키를 가지는 것은 저작권으로 보호받는 저작물을 소유하는 것과 동등하다. 이와 같이, 암호화 프로세스가 정확하게 수행된다면, 이론적으로는 아무것도 임의의 주어진 저작권 보호를 받는 저작물의 암호화된 버전의 임의의 수의 사본의 자유로운 배포를 막지 못할 것이다. 실제로, 관련 문제는 복사 방지보다는 복호화 프로세스 자체의(그리고 전역 암호화 키의) 통제로 된다.
이러한 방식으로, 디지털 배포의 문제가 (통상적으로 훨씬 더 큰) 암호화된 데이터 세트에 대한 통제보다는 비밀 키에 대한 통제의 문제로 될 수 있다. 유의할 점은, 주어진 데이터 세트가 크기가 증가함에 따라, 그를 숨기는 것이 또는 적어도 그에 대한 통제를 유지하는 것이 더 어렵다. 물론, 비밀 키의 크기가 감소됨에 따라, 그 키의 값을 추축하는 것이 더 쉽다. 이와 같이, 성공적인 보안 시스템에 대한 정확한 절충안은 비밀 키의 크기를 가능한 한 작지만 쉽게 추측될 정도로 그렇게 작지는 않도록 최적화하는 것이다.
다른 관심사는 배포된 데이터 세트를 전역적으로 암호화할지 또는 이 동일한 데이터 세트의 다수의 개별적인 암호화된 사본들을 배포할지 여부이고, 여기서 지정된 허가된 수신자들 각각은 개별적으로 암호화된 사본을 제공받는다. 이러한 방식의 명백한 비효율과 달리, 이는, 대부분의 경우들에서, 실제로 (연관된 "전역적" 암호화 키로) 한번의 "전역적" 암호화를 수행하고 한번(그리고 전역적으로) 암호화된 데이터 세트를 단지 배포하는 것보다 덜 안전한 전략이다. 이것은 암호화된 데이터 세트들 모두가 암호화 프로세스에서 사용되는 비밀 키들의 값에 관한 풍부한 부가 정보를 제공하기 위해 분석될 수 있는 통상의 통계들과 함께 공통의 평문 소스를 가진다는 사실로 인한 것이다. 따라서, 올바른 전략은, 대부분의 경우들에서, (단일의 전역 비밀 키로) 단일의 암호화를 수행하고 전역적으로 암호화된 데이터 세트만을 배포하는 것이다.
당분간, 전역 비밀 키의 "허가된" 사본을 적법한 고객에게 성공적으로 그리고 안전하게 전송하기 위해 그것이 관리되었던 것으로 가정한다. 그러면, 문제는 그 고객이 이 동일한 전역 키를 어쩌면 허가되지 않은 다른 엔터티들과 어떻게 공유하지 못하게 할지의 문제로 된다. 이와 같이, 허가된 전역 암호화 키들이 이들 키의 적법한 소유자의 소유로 된 후에도 이들 키를 관리하는 어떤 방식을 정의하는 것이 요망될 수 있다. 게다가, 전역 키가 암호화된 데이터 세트의 적법한 사본을 복호화하는 데 사용된다면, 복호화된 데이터 세트의 허가된 소유자가 그 복호화된 데이터 세트를 허가되지 않은 방식으로 다른 사람들에게 어떻게 재배포하지 못하게 할지의 문제도 또한 고려할 수 있다.
이와 같이, 보안 "범위"(security envelope)가 단지 복호화 프로세스를 넘어서 통제 메커니즘의 경계를 확장시켜야만 하는 것이 요망된다. 심지어 하나의 정확하게 복호화되지만 다른 방식으로 "통제되지 않는" 디지털 사본이 생성되면, 그 통제되지 않는 사본은 제한없이 디지털적으로 복제될 수 있다. "디지털 요정"이 해방되면, 이는 결코 병 속에 다시 넣어질 수 없다. 이와 같이, (저작권 보호를 받거나 그렇지 않은) 데이터를 정말로 통제하기 위해, 암호화된 데이터를 올바르게 복호화하는 엔터티들이 복호화된 버전들을 재배포하지 못해야만 한다. 따라서, 디지털 데이터(예컨대, 저작권 보호를 받는 데이터)의 효과적인 통제의 목표를 달성하기 위해 복호화는 물론 임의의 잠재적인 재배포 둘 다를 통제하는 것이 바람직하다. 주목할 만한 점은, 데이터 세트의 복호화 및 그 동일한 데이터 세트의 디스플레이가 동일한 디바이스에서 일어나지 않는 경우에, 복호화 디바이스들과 디스플레이 디바이스 사이의 전송 링크를 보호할 필요가 있을 수 있다는 것인데, 그 이유는 이 전송이 실질적으로 재배포 프로세스에 해당하기 때문이다. 이 경우에, 전송 링크는 외부 관찰자들 및 간섭에 대해 주 배포 수단과 동일한 강건성을 나타내야만 한다. 그렇지 않은 경우, 장래의 공격자들은 단순히 더 약한 링크를 목표로 할 수 있다.
2007년 4월 10일자로 특허된, 발명의 명칭이 "디지털 저작권 관리를 위한 재귀적 보안 프로토콜 시스템 및 방법(Recursive Security Protocol System and Method for Digital Copyright Control)"인 미국 특허 제7,203,844호, 2008년 11월 25일자로 특허된, 발명의 명칭이 "디지털 저작권 관리를 위한 재귀적 보안 프로토콜 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"인 미국 특허 제7,457,968호, 2010년 6월 29일자로 특허된, 발명의 명칭이 "디지털 저작권 관리를 위한 재귀적 보안 프로토콜 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"인 미국 특허 제7,747,87호, 2009년 11월 10일자로 출원된, 발명의 명칭이 "범용 컴퓨팅 디바이스 상에서의 코드 실행의 제어 및 재귀적 보안 프로토콜에서의 코드 실행의 제어 방법 및 시스템(Method and System for Control of Code execution on a General Purpose Computing Device and Control of Code Execution in an Recursive Security Protocol)"인 미국 특허 출원 제12/615,843호, 2010년 5월 27일자로 출원된, 발명의 명칭이 "디지털 저작권 관리를 위한 재귀적 보안 프로토콜 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"인 미국 특허 출원 제12/788,516호, 2013년 1월 18일자로 출원된, 발명의 명칭이 "디지털 저작권 관리를 위한 재귀적 보안 프로토콜 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"인 미국 특허 출원 제13/745,236호를 비롯하여, 데이터의 통제를 효과적으로 유지하기 위한 특정의 아주 효과적인 기법들이 개발되었으며, 이들의 발명 요지는 본 출원의 도 18 내지 도 36과 관련하여 기술되어 있다. 이 기법들은, 예를 들어, DRM, 저작권 보호 또는 다른 유형들의 통제와 관련하여 거의 모든 유형의 데이터에 대한 통제를 유지하기 위해 효과적으로 사용될 수 있다.
상기 출원들 및 특허들의 검토로부터, 이러한 기법들의 실시예들이 디지털 데이터를 인코딩하기 위해 복합 암호화(compound encryption)를 이용할 수 있다는 것이 실현될 수 있다. 복합 암호화의 하나의 실시예에서, 단일의 키(예컨대, 전역 키)가, 그 자체로, 인코딩된 데이터 세트를 정확하게 디코딩할 수 있다. 각각의 키는 복합 키를 구성하기 위해 적어도 하나의 다른 키와 결합되어야만 한다. 편의상, 복합 키를 구성하고 있는 원래의 개별적인 키들은 프리커서 키(precursor key)라고 한다. 임의의 복합 키가 적어도 2개의 프리커서 키들을 결합하는 것에 의해 구성될 수 있지만, 최소 이분 복합 키(minimally bipartite compound key)가 주어진 경우, 단일의 복합 키가 실제로는 임의의 수의 프리커서 키들에 기초할 수 있다는 것을 알 수 있다. 이것이 어떻게 달성되는지에 대해 이하에서 논의할 것이다.
유의할 점은, 하나의 실시예에서, 이 전체 체인에서의 프리커서 키들 중 적어도 하나가 "비밀"인 것으로 간주되는 경우, 다른 프리커서 키들 중 임의의 것은 어쩌면 공개 데이터일 수 있고, 따라서 전체 보안 시스템의 요구 및 아키텍처에 따라, 공개되거나 그렇지 않을 수 있다. 주어진 복합 키의 구성 체인(chain of construction)에서 적어도 하나의 비밀 프리커서 키가 있는 한, 복합 키 기반 시스템의 전체 보안이 본질적으로 그 단일의 비밀 프리커서 키의 보안을 조건으로 할 수 있다.
복합 키를 생성하는 다수의 방법들이 있지만, 2개의 이러한 메커니즘들, 즉 단방향(one-way) 메커니즘 및 가역적(reversible) 메커니즘이 예로서 주어져 있다. 제1 방법의 예들이 도 15에 도시되어 있다. 단방향 방법에서, 복합 키가 단방향 보안 해시 함수(secure one-way hash function)에 의해 발생될 수 있다. 이 예에서, 적어도 2개의 프리커서 키들을 연접시키고 얻어진 연접된 데이터 세트를 단방향 해시 함수를 통과시키는 것에 의해 복합 키가 발생될 수 있다. 해시 함수의 단방향 특성은 이러한 종류의 변환을 비가역적(irreversible)으로 만든다. 이는 얻어진 복합 키로부터 프리커서 키들 중 임의의 것의 값을 재생성하는 현실적인 방법이 없다는 것을 의미한다. 단방향 해시 함수의 제2 속성은 내장된 데이터 압축 기능을 포함할 수 있다는 것이다. 이와 같이, 입력 데이터 세트가 얼마나 긴지에 관계없이(예컨대, 프리커서 키들이 임의의 길이를 가질 수 있음), 얻어진 출력(복합 키)은 고정된 길이를 가질 것이다.
복합 키가 3개 이상의 프리커서들을 가질 수 있다는 이상에서의 논의를 상기하면, 이와 같이 임의의 크기의 프리커서 키 입력 데이터 세트로 단일의 복합 키가 발생될 수 있다는 것을 알 수 있다. 이것은 "케스케이딩(cascading)" 또는 "체이닝(chaining)" 프로세스에 의해 달성될 수 있고, 여기서 제1 복합 키가 구성되고, 이어서 이 제1 복합 키가 제2 복합 키에 대한 프리커서 키들 중 하나로서 사용된다.
이러한 단방향 복합 키 발생 프로세스의 출력이 고정된 길이를 가질 수 있기 때문에, 이 특성은 다수의 방식으로 이용될 수 있다. 첫째, 프리커서 키 입력들 중 어느 것도 고정된 길이를 가져서는 안되도록 단방향 복합 키 절차가 일반화될 수 있다. 그렇지만, 프리커서 키들 중 하나(예를 들어, 비밀 프리커서 키)가 고정된 길이를 갖는 것으로 가정되는 경우에, 비밀 키 값(시스템의 전체 보안이 이것에 의존함)을 전달하도록 그 고정된 길이의 프리커서 키를 추가로 할당할 수 있다.
이와 같이, 실시예들에 따르면, 예를 들어, 간단한 1회 프로그램가능 레지스터 구조(one time-programmable register structure)에 의해 구현될 수 있는 단일의 비교적 작은, 고정 길이의 레지스터를 사용하여 간단히 그리고 효율적으로 임의의 크기의 입력 데이터(예컨대, 프리커서들) 세트로 이루어져 있는 시스템의 전체 보안을 보장할 수 있다. 앞서 언급된 바와 같이, 이것이 사실상 성공적인 보안 시스템의 목표이고; 필수적인 비밀 지식이 쉽게 추측되지 못하게 할 정도로 최소 크기가 충분히 크기만 하다면 필수적인 비밀 지식을 그 최소 크기로 압축시킨다.
유의할 점은, 심지어 비밀 프리커서 키가, 예를 들어, 비교적 작은 (그리고 쉽게 구현되는) 128 비트, 256 비트, 512 비트 등의 값으로 고정되는 경우에, 이러한 비밀 키를 정확하게 추측하는 데, 평균적으로, 걸리는 시간이 그럼에도 불구하고 여전히 길 것이다.
그렇지만, 어떤 경우들에서, 프리커서 키 값을 재발생시키기 위해 복합 키를 "리버싱(reverse)"하는 것이 바람직하다. 그 상황에서, "가역적 복합 키(reversible compound key)"를 생성하기 위해 약간 다른 메커니즘을 사용할 수 있다. 이러한 가역적 복합 키를 어떻게 구성할 수 있을지의 하나의 예가 도 16에 도시되어 있다. 물론, 이것이 달성될 수 있는 다수의 방법들이 있고, 도 16에 도시되어 있는 예가 하나의 이러한 예에 불과하다는 것을 잘 알 것이다. 그렇지만, 이러한 구조의 통상적인 특징은 적어도 2개의 "프리커서" 입력들이 있다는 것일 수 있다. 여기서, 이들은 앞서 논의한 단방향 복합 키 구조의 2개의 프리커서들(예컨대, 비밀 키 프리커서 및 공개 키 프리커서)에 대응하는 평문(1610) 및 키(1620)로 도시되어 있다. 이와 같이, 단방향 복합 키에서와 같이, 적어도 2개의 프리커서들을 사용하여 가역적 복합 키가 생성될 수 있다. 또한, 논의된 바와 같이, 이 구성이 "케스케이딩된" 또는 "체이닝된" 복합 키 구조로 일반화될 수 있고, 여기서 최종적인 복합 구조는 임의의 수의 프리커서 입력들에 의존한다. 이러한 "케스케이딩된" 가역적 복합 키를 어떻게 생성할지의 하나의 예가 또한 도 16에 도시되어 있다.
또한, 이전과 같이, 키 프리커서가 비밀로 유지되는 경우, 얻어진 출력으로부터 프리커서들의 원래의 값들 중 어느 하나를 추측하는 현실적인 방법이 없고, 비밀이 아닌 프리커서(도 16에 도시된 예에서, 평문(1610)) 입력이 알려져 있더라도, 암호화된 출력의 값을 정확하게 예측하는 현실적인 수단도 없다. 이와 같이, 다시 말하자면, 전체 보안이 시스템이 비밀 키 값만을 제어 하에 두고 있을 수 있는 것을 조건으로 한다.
복합 키를 생성하기 위해 가역적 방법을 사용하여, 제1 프리커서의 원래의 값이 대칭 암호화 함수를 다시 통과시키는 것에 의해 재구성될 수 있다. 유의할 점은, 암호화 함수가 제2 복합 키를 먼저 생성하기 위해 사용되는 동일한 프리커서에 액세스할 수 있는 경우에만 이 리버싱 프로세스(reversal process)가 가능하다는 것이다.
복합 암호화의 흥미로운 측면은 임의의 수치값이 프리커서일 수 있다는 것이다. 이 유연성은 재귀적 보안 시스템이 간단하고 대단히 효율적인 방식으로 아주 복잡한 논리 구조들에 대응하는(그리고 따라서 임의의 많은 수의 다양한 컴포넌트들에 의존하는) 단일 복합 키 값들을 생성할 수 있게 한다. 그렇지만, 모든 경우들에서, 주어진 암호 구조에서의 임의의 키의 값이 얻어진 복합 키만으로부터 발견되는 것(기본 암호 함수의 처리 곤란성(intractability)을 가정함)에 대해 안전하는 것은 입증가능하다.
논의된 대칭 암호화에 부가하여, 비대칭 암호화 메커니즘을 사용하여 가역적 복합 키를 또한 구성할 수 있다. 그 경우에, 가역적 복합 키가 이어서 공개-개인 키 세트(public-private key set) 중 하나와 비밀 프리커서 키를 사용한 해시 함수의 "씨딩(seeding)"으로부터 얻어지는 디지털 서명으로서 사용될 수 있다. 이러한 구성은 이어서 주어진 플랫폼에서 보안 방식으로 디지털 문서들에 서명하는 데 사용될 수 있을 것이다. 환언하면, 특정의 컴퓨터 플랫폼을 사용하는 동안 또는 특정의 지리적 위치에 있는 동안 ― 또는 디지털 형태로 표현될 수 있는 임의의 입력 파라미터의 어떤 조합 -, 정확하게 검증가능한 디지털 서명만을 발생시킬 수 있을 것이다.
그에 따라, 재귀적 보안을 구현하는 하드웨어 디바이스들(예컨대, 대상 디바이스들)의 실시예들에서, 그 시스템 상에서 실행되는 임의의 복합 키 연산(compound key operation)에 대한 프리커서들 중 적어도 하나가 실제의 디바이스 상에 안전하게 저장되어야만 한다. 이와 같이, 어떤 실시예들에 따르면, 복합 키 동작을 위한 하나의 프리커서가 대상 디바이스의 하드웨어에 저장된 비밀 키일 수 있다. 이러한 하드웨어 비밀 키는, 많은 경우들에서, 이러한 재귀적 보안 시스템의 "신뢰 체인(Chain of Trust)"의 근간(root)의 일부로서 역할할 수 있다. 다른 실시예들에서, 시스템의 다른 측면들은 또한 이 하드웨어 "신뢰 체인"에서의 일부일 수 있을 것이다. 이러한 측면들은 단방향 보안 해시 함수, (구조적으로 보이는(architecturally visible) 것일 수 있는) 1회 프로그램가능 일련 번호 레지스터, 또는 심지어 문턱 전압 대 온도 곡선과 같은 실리콘 다이 자체의 어떤 파라미터적 특성(parametric property) 또는, 예를 들어, 문제의 칩이 스캔/테스트 모드에 있을 때에만 관찰가능한 어떤 값을 포함할 수 있을 것이다. 이 메커니즘을 사용하여, 특정의 칩이 다른 방식으로 기능적으로 동일한 디바이스와 명백하게 그리고 개별적으로 구분될 수 있을 것이다.
앞서 언급한 특허들 및 출원들에 기술된 바와 같이, 그리고 또한 본 명세서에 기술될 것인 바와 같이, 이러한 비밀 키는 대상 디바이스의 프로세서가 보안 실행 모드(보안 모드라고도 함)에서 동작하고 있을 때에만 액세스가능할 수 있다. 이와 같이, 이러한 대상 디바이스 상에서 보안 모드로 실행 중인 프로세스는 비밀 키에 액세스할 수 있고, 이 비밀 키에 기초하여 데이터를 발생시킬 수 있다.
이러한 시스템에서, 특정의 실시예들에서, 비록 그의 값이 명시되지 않은 계산에서 사용될 수 있더라도, 그의 값이 심지어 무심결에도 노출되지 않을 수 있는 방식으로 비밀 키를 추가로 격리시키는 것이 어쩌면 바람직할 수 있다. 이 목표를 달성하는 하나의 이러한 수단은, 앞서 언급한 명시되지 않은 계산에서 직접 비밀 키 값을 사용하는 대신에, 비밀 키 및 어떤 다른 데이터에 대해 단방향 보안 해시 함수의 출력을 사용하는 것이다. 단방향 함수가 정확하게 선택되면, 명시되지 않은 계산의 출력이 완전히 결정론적이지만, 그럼에도 불구하고 비밀 키의 값의 사전 지식 없이는 실제로 예측가능하지 않다. 이와 같이, 비밀 키를 사용하지만 그럼에도 불구하고 계산과 관련하여 그의 값을 노출시키지 않을 수 있는 시스템이 구성될 수 있을 것이다.
그렇지만, 어떤 계산들에서, 계산의 연산이 완료 이전에 중지되는 경우 또는 이러한 계산의 어떤 중간 결과가 외부 관찰자에게 노출되는 경우, 어떤 다른 비밀을 어쩌면 노출시킬 수 있는 계산에서 비밀 키(또는 그의 어떤 파생물)를 사용하는 것이 바람직할 수 있다. 그에 따라, 보안을 유지하기 위해 이러한 대상 디바이스 상에서의 코드의 실행을 제어하는 것에 부가하여, 대상 디바이스 상에서 보안 모드로 실행 중인 임의의 프로세스들의 작업 세트(예컨대, 캐시, 메인 메모리, 레지스터들 등과 같은 메모리로부터 판독되거나 기입되는 데이터)를 격리시키는 것이 또한 바람직할 수 있다. 보다 구체적으로는, 예를 들어, 이러한 보안 시스템이 대상 디바이스 자체로부터 분리가능하고 중간 결과들이 복호화 프로세스 동안 관찰가능한 경우, 이러한 보안 시스템은 중간자 공격들 및 차분 암호 해독(differential cryptanalysis)에 취약할 수 있다. 이것은 그렇지 않았으면 유효하지 않은 동작의 부분 결과가 그렇지 않았으면 불투명한 "블랙박스" 기반 시스템인 것으로의 창을 제공할 수 있다는 사실로 인한 것이다. 환언하면, 프로세스의 작업 세트로부터 역으로 작업을 하여, 보안 프로세스에 의해 사용되고 있는 비밀 키의 파생 값(derivative value)을 발견하는 것이 가능할 수 있고, 따라서 보안 시스템의 신뢰 체인을 손상시킨다.
이와 같이, 대상 디바이스 상에서의 프로세스의 작업 세트에 대한 액세스를 제어할 수 있는 방법들 및 시스템들이 필요하고, 상세하게는 보안 모드로 실행 중인 프로세스의 동작 동안 판독되거나 기입된 그 데이터는, 코드 세그먼트가 실행 중인 동안에 또는 심지어 원래의 코드 세그먼트가 종료된 후에도, 임의의 다른 코드 세그먼트에 의해 판독가능하지 않은 채로 있다. 상세하게는, 프로세스의 하나의 인스턴스에 속하는 데이터를 임의의 다른 프로세스로부터 명확하게 격리시키는 것이 요망될 수 있다.
그를 위해, 이제부터 프로세스 작업 세트 격리를 위한 시스템들 및 방법들의 실시예들에 중점을 둔다. 일반적으로, 이러한 시스템들 및 방법들의 실시예들은, 심지어 원래의 프로세스가 종료된 후에도 데이터가 임의의 다른 프로세스에 의해 액세스가능하지 않도록, 보안 모드로 실행 중인 프로세스의 작업 세트를 격리시킬 수 있다. 보다 구체적으로는, 하나의 실시예에서, 현재 실행 중인 프로세스의 전체 작업 세트가 캐시(예컨대, 온칩 캐시)에 저장될 수 있고, 보안 모드로 실행 중일 때 그 캐시의 오프칩 기입(off-chip writes) 및 동시 기입(write-through)이 허용되지 않을 수 있다. 그에 부가하여, 보안 모드에 있는 동안 기입되는 그 캐시 라인들(예컨대, "더티(dirty)" 캐시 라인) 중 임의의 것에 대해, 그 캐시 라인들은 현재 실행 중인 프로세스에 대한 보안 서술자와 연관되어 있을 수 있다. 보안 서술자는, 그 캐시 라인들에 대한 액세스가 그 프로세스로만 제한될 수 있도록, 그 연관된 "더티" 캐시 라인들을 실행 중인 보안 프로세스에 속하는 것으로 일의적으로 명시할 수 있다.
하나의 실시예에서, 보안 서술자가 (상이한 때에 호출되는 동일한 코드 세그먼트의 상이한 인스턴스화들을 포함하는) 상이한 프로세스들을 구별하도록 충분히 독자적이도록 하기 위해, 보안 서술자는 복합 키일 수 있다. 복합 키가 보안 프로세스 서술자로서 사용하기 위해 대상 디바이스의 비밀 키를 사용하여 생성될 수 있다. 앞서 논의한 바와 같이, 대상 디바이스의 비밀 키를 포함시키는 일 없이 복합 키가 생성될 수 있다. 특정의 실시예들에서, 전용 해시 기능 블록이 대상 디바이스에 제공될 때, 대상 디바이스의 비밀 키를 사용하여 이 보안 프로세스 서술자들을 생성하기 위해, 이러한 해시 블록(또는 해시 블록을 포함하는 보안 실행 제어기)의 출력이 사용될 수 있다.
게다가, 특정의 실시예들에서, 발생된 보안 프로세스 서술자의 실제 값을 외부 공격자에게 노출시키는 일 없이 (자동으로 발생될 수 있는) 이러한 발생된 보안 프로세스 서술자들과 구조적으로 보이는 보안 프로세스 서술자를 비교하여 값들 간에 일치가 있는지 여부를 판정하기 위해, 이 해시 함수의 출력이 사용될 수 있다.
또한, 이 보안 서술자를 생성하기 위해 단방향 해시 함수의 평가에서 대상 디바이스의 비밀 키와 함께 부가의 값들이 또한 사용될 수 있다. 비밀 키의 값을 손상시키는 일 없이, 이러한 부가의 값들이 프로세서에 보일 수 있거나 그렇지 않을 수 있다. 이 부가의 값들의 어떤 예들은 타임스탬프, 프로세스 ID, 해시 함수의 이전에 계산된 결과 또는 디지털 형태로 표현될 수 있는 임의의 다른 속성을 포함할 수 있다.
그에 부가하여, 특정의 실시예들에서, 이 부가의 값들의 크기가 완전히 임의적일 수 있다. 단방향 해시 함수가 내장된 압축 속성(built-in compression attribute)을 가지는 시스템에서, 해시 함수의 결과 출력은 고정 길이를 가질 것이고, 따라서 몇번의 해시 함수 반복이 이용되든 간에 해시 함수를 통한 임의의 많은 수의 반복들의 결과가 크기가 고정된 채로 있을 수 있게 한다. 이러한 방식으로, 보안 프로세스 서술자는 보안 프로세스의 실행 시간에 관한 정보는 물론 문제의 보안 프로세스의 전체 호출 체인을 포함할 수 있다. 이와 같이, 임의의 하나의 보안 프로세스는 임의의 다른 보안 프로세스로부터 효율적으로 그리고 효과적으로 격리될 수 있으며, 예를 들어, 이 2개의 프로세스들이 정확히 동일하지만 단순히 상이한 때에 또는 상이한 "부모" 프로세스들에 의해 호출되더라도 그러하다.
특정의 실시예들에서, 보안 프로세스의 작업 세트가 온칩 캐시를 오버플로우하고 보안 프로세스 서술자와 연관되어 있는 그 더티 라인들을 포함하는 그 캐시의 일부분들이 메인 메모리에 기입될 필요가 있는 경우에(예컨대, 페이지 스왑(page swap) 또는 페이징 아웃(page out) 동작), 프로세서와 버스(예컨대, 외부 메모리 버스) 사이의 외부 데이터 트랜잭션들이 암호화될 수 있다. 이러한 암호화에 대한 키는 보안 서술자 자체 또는 그의 어떤 파생 값, 예를 들어, 보안 프로세스 서술자와 비밀 키에 의한 해시 함수의 출력일 수 있다.
이러한 암호화 키에 대한 다른 가능한 경우는 보안 프로세스 서술자의 암호화된 버전일 수 있다. 이 후자의 경우에 사용되는 암호화 키는 현재의 보안 프로세스 서술자와 연접되어 있는 비밀 키와 어떤 다른 값의 해시 함수의 출력일 수 있다. 이 후자의 값은 이어서 공개될 수 있을 것이다(예컨대, 메모리에 평문으로 기입됨). 그 경우에, 암호화된 다음에 이어서 메모리에 먼저 기입된 데이터를 실제로 발생시켰던 보안 프로세스만이 정확한 복호화 키를 재발생시키고 따라서 메모리로부터 데이터 캐시로 다시 판독될 때 원래의 데이터를 복원할 수 있을 것이다. 이것은 보안 프로세스가 인터럽트되고(그리고 그의 작업 세트가 데이터 캐시로부터 스왑됨) 이어서 나중에 보안 방식으로 재개될 수 있는 하나의 수단이다.
하나의 보안 프로세스로부터 다른 프로세스로 데이터를 안전하게 전달하기 위해 이 동일한 방식의 파생물이 사용될 수 있으며, 이 2개의 프로세스들이 상이한 보안 프로세스 서술자들을 가지고 있더라도 그러하다. 그 경우에, 적어도 2개의 옵션들, 즉 공유된 데이터에 대한 수신자 보안 프로세스의 판독 전용 액세스 또는 공유된 데이터에 대한 판독-기입 액세스가 있다. 어느 경우든지, 이 2개의 프로세스들은 서로 간에 공유된 비밀 복호화 키를 전달해야만 한다. 공유된 비밀 복호화 키가 가역적 복합 키 프로세스에 의해 발생되는 경우에, 공유된 데이터는 공유된 데이터의 수신자인 보안 프로세스에 의해 기입가능할 수 있다. 공유된 키가 단방향 복합 키 메커니즘에 기초하는 경우에, 공유된 데이터는 수신자의 판독 전용 액세스로 제한될 수 있다.
성능을 향상시키기 위해, 보안 프로세스가 큰 작업 세트를 가지거나 빈번히 인터럽트되는 특정의 경우들에서(예컨대, 많은 페이지 스왑들을 수반함), "안전한" 것으로 간주되는 프로세스 작업 세트의 서브셋이 생성될 수 있고(예컨대, 프로세스에 대한 더티 캐시 라인들의 서브셋만이 보안 서술자와 연관되어 있을 수 있음), 외부 메모리에 기입될 때, 그 캐시 라인들 또는 그 라인들을 포함하는 캐시의 일부분만을 암호화할 수 있다.
그에 부가하여, 성능을 향상시키기 위해, 오프칩 저장 메커니즘(예컨대, 페이지 스와핑 모듈)은 (예컨대, 통합된 AES 암호화 하드웨어 가속을 갖는 DMA 유닛을 사용하여) 인터럽트하는 프로세스와 병렬로 비동기적으로 실행될 수 있고, 따라서 프로세서 성능에 최소한의 영향을 미치도록 설계될 수 있을 것이다. 다른 실시예에서, 작업 세트 데이터가 메모리에 기입될 수 있게 하기 전에 암호화를 수행하기 위해 별도의 보안 "작업 세트 캡슐화(working set encapsulation)" 모듈이 사용될 수 있다.
본 명세서에서 제시된 실시예들을 사용하여, 시스템의 비밀 키들을 (직접적으로는 물론 간접적으로도) 구조적으로 보이지 않게 만드는 것에 의해 그리고 보안 프로세스의 작업 세트를 임의의 다른 프로세스로부터 효율적으로 그리고 명확하게 격리시킬 수 있는 것에 의해, 재귀적 보안 디바이스들은 재생 공격에 실질적으로 영향을 받지 않고 경쟁하는 솔루션들에서는 대처하지 못하는 ROP 익스플로이트(return-oriented programming exploit) 또는 다른 프로그래밍 익스플로이트잇에 대한 내성을 제공할 수 있다. 그에 따라, 이 재귀적 보안 시스템들은 난독화(obfuscation)만을 사용하는 보안의 구현에 대해 다수의 장점들을 제공할 수 있다.
실시예들을 더 상세히 논의하기 전에, 본 발명의 실시예들이 효과적으로 이용될 수 있는 아키텍처의 전반적인 개요를 제공하는 것이 도움이 될 수 있다. 도 1은 이러한 토폴로지의 하나의 실시예를 나타낸 것이다. 여기서, 콘텐츠 배포 시스템(101)은 (예를 들어, 오디오 또는 비디오 데이터, 소프트웨어 응용 프로그램 등을 포함하는 비트스트림) 디지털 콘텐츠를 프로토콜 엔진들을 포함하는 하나 이상의 대상 유닛들(100)(본 명세서에서 대상 또는 종단점 디바이스들이라고도 함)로 배포하는 동작을 할 수 있다. 이 대상 유닛들은, 예를 들어, 유선 또는 무선 네트워크 상의 컴퓨팅 디바이스들 또는 네트워크로 연결되어 있지 않은 컴퓨팅 디바이스의 일부일 수 있고, 이러한 컴퓨팅 디바이스들은, 예를 들어, 개인용 컴퓨터, 휴대폰, PDA(personal data assistant), 네트워크를 통해 비트스트림으로서 전달된 또는, 예를 들어, 우편을 통해 배달될 수 있는 컴퓨터 판독가능 저장 매체 상의 콘텐츠를 재생할 수 있는 미디어 플레이어 등을 포함한다. 이 디지털 콘텐츠는 디지털 콘텐츠의 실행에 대한 통제가 제어될 수 있고 디지털 콘텐츠에 대해 보안이 구현될 수 있는 방식으로 제작 또는 배포될 수 있다.
특정의 실시예들에서, 디지털 콘텐츠에 대한 통제는 라이센싱 기관(licensing authority)(103)과 관련하여 실시될 수 있다. 이 라이센싱 기관(103)(중앙 라이센싱 기관(central licensing authority)이라고 할 수 있지만, 이러한 라이센싱 기관이 중앙 집중식으로 될 필요는 없고, 그 기능이 분산되어 있을 수 있거나, 그 기능이 콘텐츠 배포 시스템(101), 메모리 스틱과 같은 하드웨어 디바이스를 통한 데이터의 수동 배포 등에 의해 달성될 수 있다는 것을 잘 알 것임)이 키 또는 허가 코드(authorization code)를 제공할 수 있다. 이 키는 대상 디바이스로 배포되는 디지털 콘텐츠에 암호적으로 의존(cryptographically dependent)하기도 하고 각각의 대상 디바이스(TDn)에 바인딩(bound)되어 있기도 하는 복합 키(DS)일 수 있다. 하나의 예에서, 대상 디바이스는 보안 모드로 응용 프로그램을 실행하려고 시도하고 있을 수 있다. 이 보안 응용 프로그램(후보 코드 또는 후보 코드 블록(예컨대, CC)이라고 할 수 있음)은 특정의 디지털 콘텐츠에 액세스하기 위해 사용될 수 있다.
그에 따라, 후보 코드 블록이 후보 코드 블록이 배포되는 특정의 대상 디바이스(100)의 프로세서 상에서 보안 모드로 실행될 수 있게 하기 위해, 라이센싱 기관(103)은 복합 키의 정확한 값(그의 한 예를 허가 코드라고 할 수 있음)을 후보 코드 블록이 보안 모드로 실행하려고 시도하고 있는 대상 디바이스에 제공해야만 한다(예컨대, DS1을 TD1에 제공함). 어떤 다른 대상 디바이스(예컨대, TDn, 여기서 TDn≠TD1임)도 복합 키(예컨대, DS1)를 사용하여 후보 코드 블록을 정확하게 실행할 수 없고, 어떤 다른 복합 키(DSn, DSn≠DS1이라고 가정함)도 그 대상 디바이스(100)(예컨대, TD1) 상의 그 후보 코드 블록에 대해 올바르게 동작하지 않을 것이다.
본 명세서에서 나중에 더 상세히 기술될 것인 바와 같이, 대상 디바이스(100)(예컨대, TD1)가 후보 코드 블록(예컨대, CC1)을 그의 명령어 캐시에 로드할 때(그리고, 예를 들어, CC1이 보안 모드로 실행되도록 의도되어 있는 코드로서 식별되는 경우), 대상 디바이스(100)(예컨대, TD1)는 그 후보 코드 블록(예컨대, CC1)의 메시지 다이제스트(예컨대, MD1)를 생성하는 (하드웨어 기반일 수 있는) 해시 함수를 관여시킨다. 이 해시 함수의 씨드 값은 대상 디바이스(100)에 대한 비밀 키(예컨대, TD1의 비밀 키(예컨대, SK1))이다.
실제로, 이러한 메시지 다이제스트(예컨대, MD1)는 메시지 인증 코드(Message Authentication Code)(MAC)는 물론 복합 키일 수 있는데, 그 이유는 해시 함수 결과가 해시의 씨드 값인 대상 디바이스(100)의 비밀 키(예컨대, SK1)에 의존하기 때문이다. 이와 같이, 메시지 다이제스트(예컨대, MD1)의 결과 값은 대상 디바이스(100)의 비밀 키 및 후보 코드 블록 둘 다에 암호적으로 바인딩되어 있다. 라이센싱 기관 배포 복합 키(예컨대, DS1)가 메시지 다이제스트(예컨대, MD1)의 값과 일치하는 경우, 후보 코드 블록(예컨대, CC1)이 변경되지도 않고 대상 디바이스(100)(예컨대, TD1) 상에서 보안 모드로 실행되게 허가되어 있도록 보장될 수 있다. 대상 디바이스(100)는 이어서 후보 코드 블록을 보안 모드로 실행할 수 있다.
그러면 알 수 있는 바와 같이, 하나의 실시예에서, 대상 디바이스(100)에 대한 보안 모드 실행이 수행될 때, 대상 디바이스(100)는 그의 원래의 형태로부터 변경되지 않은 것으로 검증되기도 하고 그가 실행되고 있는 대상 디바이스(100)에 암호적으로 "바인딩"되어 있기도 하는 코드를 실행하고 있을 수 있다. 대상 디바이스의 보안 모드 실행을 보장하는 이 방법은 프로세서가 하드웨어 리셋 시에 보안 모드에 진입하고 이어서 신뢰 근간(root-of-trust)을 확립하기 위해 하이퍼바이저 모드 등으로 실행될 수 있는 다른 시스템들과 대조될 수 있다.
그에 따라, 개시된 실시예들을 사용하여, 대상 디바이스(100)에 대한 비밀 키(예컨대, SK1)가 노출되지 않는 한, 라이센싱 기관으로부터의 복합 키, 메시지 다이제스트, 후보 코드 블록(예컨대, DS1, MD1, CC1) 등과 같은 이들 데이터의 일부 또는 전부가 완전히 공개될 수 있다. 이와 같이, 대상 디바이스의 비밀 키의 값이 직접 또는 간접적으로 결코 노출되지 않는 것이 요망된다. 그에 따라, 앞서 논의된 바와 같이, 본 명세서에서 제시되는 시스템들 및 방법들의 실시예들은, 비밀 키를 직접적인 노출로부터 보호하는 것에 부가하여, 대상 디바이스들(100) 상에서 보안 모드로 실행 중인 프로세스들의 작업 세트들을 보호함으로써 대상 디바이스(100) 상의 비밀 키의 간접적인 노출로부터도 보호할 수 있다.
이제 도 2로 가면, 대상 디바이스의 하나의 실시예의 아키텍처는 디지털 콘텐츠의 실행을 제어하거나 수신된 디지털 콘텐츠와 관련하여 보안 프로토콜들을 구현할 수 있다. 대상 유닛의 요소들은, 프로세스가 보안 모드로 실행 중일 때, 프로세스의 작업 세트가 격리될 수 있도록, 프로세스가 대상 디바이스 상에서 보안 모드로 실행할 수 있게 하는 한 세트의 블록들을 포함할 수 있다. 유의할 점은, 이 실시예에서, 이 블록들이 하드웨어로서 기술되어 있지만, 유사한 기능을 똑같은 효능으로 달성하기 위해 소프트웨어가 이용될 수 있다는 것이다. 또한 유의할 점은, 특정의 실시예들이 본 명세서에 기술되어 있는 모든 블록들을 포함할 수 있지만, 다른 실시예들은 더 적은 또는 부가의 블록들을 이용할 수 있다.
대상 디바이스(100)는 실행 유닛 및 명령어 파이프라인을 갖는 프로세서 코어일 수 있는 CPU 실행 유닛(120)을 포함할 수 있다. 클럭 또는 날짜/시간 레지스터(102)는 중앙 서버와의 보안 상호작용에 의해 세트되거나 리셋될 수 있는 자율 동작 타이머(free-running timer)일 수 있다. 시간이 보안 시간 표준(secure time standard)의 질의를 수행하는 것에 의해 설정될 수 있기 때문에, 이 기능을 온칩으로 되게 하는 것이 편리할 수 있다. 이러한 날짜/시간 레지스터의 다른 예는 그의 값이 단조적으로 증가될 필요는 없고 그의 값이 빈번히 반복되지 않는 레지스터일 수 있다. 특정의 이유로 고유의 타임스탬프 값이 필요할 수 있지만 그 타임스탬프 값이 꼭 사전에 예측될 필요가 없을 수 있는 경우에 이러한 레지스터가 유용할 수 있을 것이다. 이와 같이, 의사 난수 발생기가 이러한 레지스터를 구현하는 적당한 메커니즘일 수 있다. 이러한 기능을 구현하는 다른 옵션은 이 레지스터의 현재 값을 생성하기 위해 하드웨어 해시 함수(160)의 출력을 사용하는 것이다. 이러한 해시 함수의 출력이 해시 함수의 입력에 대한 씨드(seed) 또는 솔트(salt) 값으로서 사용되는 경우에, 얻어진 출력 계열(output series)은 통계적으로 난수 시퀀스(random number sequence)와 비슷할 수 있지만, 값들이 그럼에도 불구하고 결정론적일 수 있고 따라서 어쩌면 예측가능할 수 있다. 대상 유닛(100)은 또한 충분히 랜덤한 수들의 시퀀스를 생성하도록 구성되어 있을 수 있는 또는 의사 난수 발생 시스템(pseudo-random number generation system)에 대한 씨드 값들을 제공하는 데 사용될 수 있는 참 난수 발생기(true random number generator)(182)를 포함할 수 있다 이 의사 난수 발생 시스템는 또한 어쩌면 하드웨어, 소프트웨어로 또는 "보안" 소프트웨어로 구현될 수 있다.
단방향 해시 함수 블록(160)은 해싱 함수를 실질적으로 하드웨어로 구현하는 동작을 할 수 있다. 단방향 해시 함수 블록(160)은 대상 디바이스(100)를 보안 모드에 두는 것을 제어하는 데 사용될 수 있는 또는 (예컨대, 대상 디바이스(100)가 보안 모드로 실행 중일 때) 메모리 액세스를 제어하는 데 사용될 수 있는 보안 실행 제어기(162)의 일부일 수 있고, 이에 대해서는 본 명세서에서 나중에 더 상세히 기술될 것이다.
하나의 실시예에서, 단방향 해시 함수 블록(160)은 주어진 프로세스가 보안인지 여부를 평가하는 데 사용되는 바로 그 CPU 상에서 실행 중인 보안 프로세스에 의해 가상적으로 구현될 수 있다. 특정의 실시예들에서, 이러한 시스템이 올바르게 해결할 수 있도록 하기 위해 2개의 조건들이 준수될 수 있다. 첫째, 보안 모드 "평가" 동작(예컨대, 해시 함수)이 그가 평가하는 보안 프로세스의 실행에 독립적으로 진행된다. 둘째, 내포된 평가들의 체인이 명확한 종료 지점("신뢰 체인"의 루트 또는 간단히 "신뢰 근간"이라고 할 수 있음)을 가질 수 있다. 이러한 실시예들에서, 이 "신뢰 근간"은 어떤 비변경가능 방식으로(예컨대, 하드웨어로) 구현되어야만 하는 시스템의 최소 부분일 수 있다. 이 최소 특징부는 "하드웨어 신뢰 근간(hardware root of trust)"이라고 할 수 있다. 예를 들어, 이러한 실시예들에서, 하나의 이러한 하드웨어 신뢰 근간은 펌웨어로(예컨대, 비변경가능 소프트웨어로) 실현되는 단방향 해시 함수일 수 있다.
대상 유닛(100)의 다른 부분은, 앞서 기술된 바와 같이, 대상 디바이스(100)의 비밀 키(들) 또는 공개/개인 키들(public/private keys)(나중에 기술됨) 또는 그의 파생물을 사용할 수 있는 하드웨어 지원 암호화/복호화 블록(170)(암호화 시스템 또는 블록, 복호화 시스템 또는 블록, 또는 암호화/복호화 블록이라고 서로 바꾸어 지칭될 수 있음)일 수 있다. 이 암호화/복호화 블록(170)은 다수의 방식들로 구현될 수 있다. 또한 유의할 점은, 단방향 해시 함수와 후속하는 암호화/복호화 시스템의 이러한 조합은, 임의의 디지털 데이터가 암호화된 형태로 배포되든 평문 형태로 배포되든 간에, 그 데이터의 검증을 위해 사용될 수 있는 디지털 서명 발생기를 포함할 수 있다. 전체 프로토콜의 속도 및 보안은 이 블록의 구성에 따라 변할 수 있고, 따라서 보안 시스템 업데이트들을 수용하기에 충분히 유연성이 있음은 물론 시스템이 시간 제약이 있는(time-critical) 메시지들의 실시간 복호화를 수행할 수 있게 하기에 충분히 빠르도록 구성되어 있을 수 있다.
이 하드웨어 블록(170)에 대해 정확히 어느 암호화 알고리즘이 사용되는지가 실시예들에 중요하지 않다. 최대 유연성을 증진시키기 위해, 실제의 하드웨어가 비알고리즘적 관련 방식으로 사용되기에 충분히 범용이지만, 이 메커니즘이 구현될 수 있는 많은 다른 수단들이 있는 것으로 가정된다. 이 시점에서 유의할 점은, 암호화/복호화를 수행하는 엔진들(알고리즘들, 하드웨어, 소프트웨어 등)을 언급할 때 암호화 및 복호화라는 용어들이 서로 바꾸어 사용될 수 있다는 것이다. 잘 알게 될 것인 바와 같이, 특정의 실시예들에서, 대칭 암호화가 사용되는 경우, 동일한 또는 유사한 암호화 또는 복호화 엔진이 암호화 및 복호화 둘 다를 위해 이용될 수 있다. 비대칭 메커니즘의 경우에, 비록 키들이 상이할 수 있지만, 암호화 및 복호화 기능들이 실질적으로 유사할 수 있거나 그렇지 않을 수 있다.
대상 디바이스(100)는 또한 데이터 캐시(180), 실행되어야 하는 코드가 저장되어 있을 수 있는 명령어 캐시(110), 및 메인 메모리(190)를 포함할 수 있다. 데이터 캐시(180)는 L1 또는 L2 캐시와 같은 원하는 거의 모든 유형의 캐시일 수 있다. 하나의 실시예에서, 데이터 캐시(180)는 보안 프로세스 서술자를 캐시의 하나 이상의 페이지들과 연관시키도록 구성되어 있을 수 있고, 데이터 캐시(180)의 라인들(그의 모든 또는 일부 서브셋)과 연관되어 있는 하나 이상의 보안 플래그들을 가질 수 있다. 예를 들어, 보안 프로세스 서술자는 데이터 캐시(180)의 페이지와 연관되어 있을 수 있다.
일반적으로, 대상 디바이스(100)의 실시예들은, 심지어 원래의 프로세스가 종료된 후에도 데이터가 임의의 다른 프로세스에 의해 액세스가능하지 않도록, 데이터 캐시(180)에 저장되어 있는 보안 모드로 실행 중인 프로세스의 작업 세트를 격리시킬 수 있다. 보다 구체적으로는, 하나의 실시예에서, 현재 실행 중인 프로세스의 전체 작업 세트가 데이터 캐시(180)에 저장될 수 있고, 보안 모드에서 실행 중일 때 메인 메모리(190)에의 기입 및 (예컨대, 메인 메모리(190)에의) 그 캐시의 동시 기입이 (예컨대, 보안 실행 제어기(162)에 의해) 허용되지 않을 수 있다.
그에 부가하여, 보안 모드로 실행 중인 동안 기입되는 데이터 캐시(180)의 그 라인들 중 임의의 것에 대해, 그 캐시 라인들(또는 그 캐시 라인들을 포함하는 페이지)은 현재 실행 중인 프로세스에 대한 보안 프로세스 서술자와 연관되어 있을 수 있다. 보안 프로세스 서술자는, 그 캐시 라인들에 대한 액세스가 (예컨대, 보안 실행 제어기(162)에 의해) 그 프로세스로만 제한될 수 있도록, 그 연관된 "더티" 캐시 라인들을 실행 중인 보안 프로세스에 속하는 것으로 일의적으로 명시할 수 있다.
특정의 실시예들에서, 보안 프로세스의 작업 세트가 데이터 캐시(180)를 오버플로우하고 현재 실행 중인 프로세스의 보안 서술자와 연관되어 있는 그 더티 라인들을 포함하는 데이터 캐시(180)의 일부분들이 메인 메모리에 기입될 필요가 있는 경우에(예컨대, 페이지 스왑 또는 페이징 아웃 동작), 프로세서와 버스(예컨대, 외부 메모리 버스) 사이의 외부 데이터 트랜잭션들이 (예컨대, 암호화 블록(170) 또는 보안 모드로 실행 중인 암호화 소프트웨어를 사용하여) 암호화될 수 있다. 메인 메모리에 기입되는 데이터의 암호화(및 복호화)가 보안 실행 제어기(162)에 의해 제어될 수 있다.
이러한 암호화에 대한 키가 보안 프로세스 서술자 자체 또는 그의 어떤 파생물일 수 있고, 그 보안 서술자 자체가 암호화되고 메인 메모리에 기입되는 데이터의 일부로서 메인 메모리(190)에 암호화된 형태로 저장될 수 있다.
명령어 캐시(110)는 전형적으로 I-캐시(I-Cache)라고 한다. 어떤 실시예들에서, 이 I-캐시(110)의 부분들의 특성은 특정의 블록들 내에 포함된 데이터가 CPU 실행 유닛(120)에 의해서만 판독가능하다는 것이다. 환언하면, I-캐시(130)의 이 특정의 블록은 실행 전용(execute-only)이고, 임의의 실행 중인 소프트웨어에 의해 판독되지도 기입되지도 않을 수 있다. I-캐시(130)의 이 블록은 또한 본 명세서에서 "보안 I-캐시(secured I-Cache)"(130)라고 지칭될 것이다. 실행될 코드가 이 보안 I-캐시 블록(130)에 저장되는 방식은 도시되어 있을 수 있거나 그렇지 않을 수 있는 다른 블록을 통할 수 있다. 기술 분야에 공지되어 있는 바와 같이 정상적으로 실행되어야 하는 코드를 저장하기 위해 정상 I-캐시(normal I-Cache)(150)가 이용될 수 있다.
그에 부가하여, 일부 실시예에서, 보안 코드 블록의 동작을 가속화시키기 위해 특정의 블록들이 사용될 수 있다. 그에 따라, 한 세트의 CPU 레지스터들(140)은 CPU(120)가 보안 코드를 실행하고 있는 동안에만 액세스가능하도록 지정될 수 있거나, 보안 코드 블록(보안 모드로 실행 중인 보안 I-캐시 블록(130) 내의 명령어들)의 실행의 완료 시에 또는 어떤 이유로 비보안 또는 "정상" I-캐시(150) 또는 다른 영역들에 위치해 있는 코드의 임의의 섹션으로의 점프가 보안 I-캐시(130)에 저장된 코드의 실행 동안 일어나는 경우 소거된다.
하나의 실시예에서, CPU 실행 유닛(120)은 보안 I-캐시 블록(130)에 저장된 코드를 실행하는 동안 어느 레지스터들(140)이 판독되거나 기입되는지를 추적하고 이어서 "보안 실행" 모드를 빠져나갈 시에 이 레지스터들을 자동으로 소거되거나 그에 대한 액세스를 디스에이블시키도록 구성되어 있을 수 있다. 이것은, 2가지 종류의 코드 블록들 간에 공유되도록 허용되어 있는 데이터만이 그대로 유지되도록, 보안 코드가 그 자체 후에 신속하게 "소거"될 수 있게 한다. 다른 가능한 경우는 보안 코드 블록(130)에서 실행될 코드의 저작자가 어느 레지스터들(140)이 소거되거나 디스에이블되어야 하는지를 명확하게 식별할 수 있다는 것이다. 보안 코드 블록이 인터럽트되고 이어서 재개되는 경우에, 재개되고 있는 보안 코드가 보류 중이었던 시간 동안 변조(tamper)되지 않은 것으로 판정될 수 있는 경우, 이 디스에이블된 레지스터들이 어쩌면 재인에이블될 수 있다.
하나의 실시예에서, 보안 코드 세그먼트와 비보안 코드 세그먼트 사이에서 레지스터들(140)에 저장된 데이터의 "누설"을 처리하기 위해, CPU(120)가 보안 코드를 실행하고 있을 때에만 사용되어야 하는 한 세트의 레지스터들(140)이 식별될 수 있다. 일 실시예에서, 이것은 많은 최근의 CPU 설계들에서 실시되는 레지스터 재명명(renaming) 및 스코어보딩(scoreboarding) 메커니즘의 한 버전을 이용하여 달성될 수 있다. 어떤 실시예들에서, 보안 모드에서의 코드 블록의 실행은 이러한 재명명 및 스코어보딩을 구현하기 더 쉽게 만들 수 있는 원자적 동작(atomic action)(예컨대, 비인터럽트가능(non-interruptible)임)으로서 취급된다.
CPU(120)가 "보안" 코드 블록(보안 I-캐시(130)로부터의 코드) 및 "비보안 코드"(정상 I-캐시(150) 또는 메모리 내의 다른 위치와 같은 다른 위치에 있는 코드)의 혼합을 실행할 가능성이 거의 없는 것처럼 보일 수 있지만, 인터럽트 루틴들로 점프할 때와 같은 스위칭 컨텍스트 도중에 또는 CPU(120) 컨텍스트가 어디에 저장되어 있는지(대부분의 CPU는 컨텍스트를 메인 메모리에 저장하고, 여기서 이는 어쩌면 발견 및 비보안 코드 블록에 의한 조작의 대상으로 됨)에 따라, 이러한 상황이 일어날 수 있다.
이러한 만일의 사태로부터 보호하는 데 도움을 주기 위해, 하나의 실시예에서, 실행 중간에 인터럽트되는 보안 코드 블록의 실행 동안 획득되는 결과가 시스템 내의 다른 실행 스레드들에 노출되는 것으로부터 보호하기 위해 이용될 수 있는 다른 방법은 대상 디바이스(100)가 보안 실행 모드로 동작하고 있는 동안 스택 푸시(stack push)를 디스에이블시키는 것이다. 스택 푸시를 이와 같이 디스에이블시키는 것은 따라서, 보안 코드 블록이 그의 정상적인 완료 이전에 인터럽트되는 경우, 그 블록이 재개될 수 없고 따라서 처음부터 재시작되어야만 한다는 의미에서, 인터럽트가능하지 않다는 것을 의미할 것이다. 유의할 점은, 특정의 실시예들에서, "보안 실행" 모드가 프로세서 인터럽트 동안 디스에이블되는 경우, 보안 코드 블록은 또한, 전체 호출 체인이 재시작되지 않는 한, 어쩌면 재시작될 수 없을지도 모른다.
각각의 대상 유닛(100)은 또한 하나 이상의 보안 키 상수들(104)을 가질 수 있고, 이들의 값들 중 어느 것도 소프트웨어 판독가능하지 않다. 하나의 실시예에서, 이 키들 중 제1 키(주 비밀 키(primary secret key))는 한 세트의 비밀 키들로서 구성되어 있을 수 있고, 그들 중 단지 하나만이 임의의 특정의 때에 판독가능하다. 유닛의 "소유권"이 변경되는 경우(예를 들어, 프로토콜 엔진을 포함하는 장비가 판매되거나 그의 소유권이 다른 방식으로 이전되는 경우), 현재 활성인 주 비밀 키가 "소거"되거나 다른 값으로 덮어쓰기될 수 있다. 이 값이 보안 방식으로 유닛으로 전송될 수 있거나, 이 제1 키가 소거될 때에만 사용되도록 하는 방식으로 유닛에 이미 저장되어 있을 수 있다. 사실상, 이것은 그의 소유권이 변경될 때 또는 (손상된 키와 같은) 이러한 변경에 대한 어떤 다른 이유가 있는 경우 그 특정의 유닛에 새로운 주 비밀 키를 발행하는 것과 동등하다. 대상 유닛(100) 자체에 대해 보조 비밀 키(secondary secret key)가 이용될 수 있다. 대상 유닛(100)의 CPU(120)가 주 비밀 키 또는 보조 비밀 키 중 어느 하나의 값에 결코 액세스할 수 없기 때문에, 어떤 의미에서, 대상 유닛(100)은 심지어 그 자신의 비밀 키들(104)도 "알지" 못한다. 이 키들은, 기술될 것인 바와 같이, 단지 대상 유닛(100)의 보안 실행 제어기(162) 내에 저장되어 사용된다.
다른 실시예에서, 2개의 키들이 "쌍으로 된" 키들의 목록으로서 구성될 수 있고, 여기서 하나의 이러한 키는 1회 프로그램가능 레지스터로서 구현되고, 쌍에서의 다른 키는 재기입가능 레지스터(re-writeable register)를 사용하여 구현된다. 이 실시예에서, 재기입가능 레지스터는 기지의 값(예컨대, 0)으로 초기화될 수 있고, 시스템이 그 상태에서 보안 모드로 실행하기 위해 이용가능할 수 있는 유일한 옵션은 레지스터의 재기입가능 부분에 값을 기입하는 것일 수 있다. 이 재기입가능 레지스터 내의 값이 어떤 값(예컨대, 예를 들어, 라이센싱 기관만이 알고 있을 수 있는 것)으로 초기화되면, 시스템은 단지 보안 모드에 있는 동안 더 범용인 코드를 실행할 수 있다. 이 재기입가능 값이 어떤 이유로 재초기화되어야만 하는 경우, 이 레지스터가 기입될 때마다 새로운 값을 사용하는 것은 잠재적인 재생 공격에 대해 증가된 보안을 제공할 수 있다.
또 다른 키 세트들이 임시 공개/개인 키 시스템(비대칭 키 시스템 또는 PKI 시스템이라고도 함)의 일부로서 동작할 수 있다. 이 쌍에서의 키들은 동작 중에 발생될 수 있고, 중앙 서버의 개입 없이 유사한 유닛들 간의 보안 통신 링크를 설정하기 위해 사용될 수 있다. 이러한 시스템의 보안이 전형적으로 동등한 키 길이의 대칭 키 암호화 시스템의 보안보다 더 낮기 때문에, 이 키들은 크기가 앞서 언급한 비밀 키들의 세트보다 더 클 수 있다. 이 키들은, 그 중에서도 특히, "재생 공격"으로부터 보호하기 위해 온칩 타이머 블록에 존재하는 값과 함께 사용될 수 있다. 이 키들이 동작 중에 발생될 수 있기 때문에, 이들이 발생되는 방식은 전체 시스템 보안을 증가시키기 위해 난수 발생 시스템(180)에 의존할 수 있다.
하나의 실시예에서, 특정의 대상 유닛의 "소유권"의 변경에 영향을 주는 데 사용될 수 있는 하나의 방법은 주 비밀 키를 다른 키(107)(타임스탬프 또는 타임스탬프 값이라고 할 것임)와 관련하여 복합 키로서 항상 사용하는 것인데, 그 이유는 이 키의 값이 변경될 수 있고(환언하면, 상이한 때에 상이한 값을 가질 수 있음), 현재 시간을 꼭 반영할 필요가 없을 수 있기 때문이다. 이 타임스탬프 값 자체가 구조적으로 보일 수 있거나 그렇지 않을 수 있지만(꼭 비밀 키일 필요는 없을 수 있음), 그럼에도 불구하고, 대상 유닛(100)이 보안 실행 모드에서 동작하고 있지 않는 한, 이는 수정될 수 없을 것이다. 이러한 경우에, 주 비밀(primary secret)이 사용될 때마다 타임스탬프 값을 복합 키의 성분으로서 일관성있게 사용하는 것은, 주 비밀 키가 별도의 값으로 전환된 것처럼, 본질적으로 동일한 효과를 생성할 수 있고, 따라서 주 비밀 키 자체를 수정할 필요 없이 특정의 대상 종단점 유닛의 "소유권의 변화"를 사실상 가능하게 한다.
잘 알 수 있는 바와 같이, 대상 디바이스는, 심지어 원래의 프로세스가 종료된 후에도 데이터가 임의의 다른 프로세스에 의해 액세스가능하지 않도록, 보안 모드로 실행 중인 프로세스들의 작업 세트들을 격리시키기 위해 보안 실행 제어기(162) 및 데이터 캐시(180)를 사용할 수 있다. 이 작업 세트 격리는, 특정의 실시예들에서, 보안 모드로 실행 중일 때 오프칩 기입 및 데이터 캐시의 동시 기입을 디스에이블시키는 것, 실행 중인 프로세스에 의해 기입되는 데이터 캐시의 라인들을 (실행 중인 프로세스와 일의적으로 연관되어 있을 수 있는) 보안 서술자와 연관시키는 것, 및 그 캐시 라인들에 대한 액세스를 보안 프로세스 서술자를 사용하여 그 프로세스로만 제한하는 것에 의해 달성될 수 있다. 이러한 보안 프로세스 서술자는 허가 코드 또는 그의 어떤 파생 값과 같은 복합 키일 수 있다.
프로세스가 데이터 캐시 내의 데이터에 액세스하고자 할 때, 현재 실행 중인 프로세스와 연관되어 있는 보안 서술자가 데이터 캐시의 요청된 라인과 연관되어 있는 보안 서술자와 비교될 수 있다. 보안 서술자들이 일치하는 경우, 그 캐시 라인의 데이터가 실행 중인 프로세스에 제공될 수 있는 반면, 보안 서술자들이 매칭되지 않는 경우, 데이터가 제공되지 않을 수 있고, 다른 동작이 취해질 수 있다.
더욱이, 특정의 실시예들에서, 보안 프로세스의 작업 세트가 온칩 캐시를 오버플로우하고 보안 프로세스 서술자와 연관되어 있는 그 더티 라인들을 포함하는 캐시의 일부분들이 메인 메모리에 기입될 필요가 있는 경우에(예컨대, 페이지 스왑 또는 페이징 아웃 동작), 프로세서와 버스(예컨대, 외부 메모리 버스) 사이의 외부 데이터 트랜잭션들이 암호화될 수 있다. 이러한 암호화를 위한 키는 보안 프로세스 서술자 자체 또는 그의 어떤 파생물일 수 있고, 그 보안 프로세스 서술자는 메인 메모리에 기입되기 전에 (예컨대, 대상 디바이스의 비밀 키 또는 그의 어떤 파생물을 사용하여) 암호화될 수 있다. 다시 말하지만, 이 암호화 프로세스들이 실질적으로 대상 디바이스의 해싱 블록을 사용하여 또는 프로세서 자체 또는 어떤 다른 온칩 처리 자원 상에서 보안 모드로 실행 중인 소프트웨어 암호화 프로세스의 사용에 의해, 또는 하드웨어로 구현되는 암호화 함수의 사용에 의해 달성될 수 있다.
성능을 향상시키기 위해, 보안 프로세스가 큰 작업 세트를 가지거나 빈번히 인터럽트되는 특정의 경우들에서(예컨대, 많은 페이지 스왑들을 수반함), "안전한" 것으로 간주되는 프로세스 작업 세트의 서브셋이 생성될 수 있고(예컨대, 프로세스에 대한 더티 캐시 라인들의 서브셋만이 보안 서술자와 연관되어 있을 수 있음), 외부 메모리에 기입될 때, 그 캐시 라인들 또는 그 라인들을 포함하는 캐시의 일부분만을 암호화할 수 있다.
그에 부가하여, 성능을 향상시키기 위해, 오프칩 저장 메커니즘(예컨대, 페이지 스와핑 모듈)은 (예컨대, 통합된 AES 암호화 하드웨어 가속을 갖는 DMA 유닛을 사용하여) 인터럽트하는 프로세스와 병렬로 비동기적으로 실행될 수 있고, 따라서 메인 프로세서 성능에 최소한의 영향을 미치도록 설계될 수 있을 것이다. 다른 실시예에서, 작업 세트 데이터가 메모리에 기입될 수 있게 하기 전에 암호화를 수행하기 위해 별도의 보안 "작업 세트 캡슐화" 소프트웨어 모듈이 사용될 수 있다.
본 논의에서의 이 시점에서, 보다 구체적인 예를 논의하기 전에, 단방향 복합 키가 어떻게 구성될 수 있는지의 한 예를 전반적으로 보여주는 것이 도움을 줄 수 있다. 이제 도 15를 참조하면, 일반적인 구조는 제1 단방향 해시 함수(1510), 그의 연관된 입력 데이터 세트(1520) 및 그의 결과 출력(1523)으로 이루어져 있다. 이 예에서, 입력 데이터 세트(1520)는 3개의 성분들, 즉 비밀 키(1521), 프리커서 키(1522) 및 페이로드 데이터 1(1523)로 추가로 분해될 수 있다.
유의할 점은, 이 입력 데이터 요소들(1521, 1522 및 1523)의 이름들 및 형식들은 물론 결과 출력(1532)(복합 키 1이라고 지칭함)의 이름 및 형식이 이 예에서 단지 참조의 편의상 명시되어 있다는 것이다. 실제로, 이 입력 데이터 세트 요소들 중 임의의 것에 대한 형식이 고정되어 있지 않을 수 있다. 단방향 해시 함수(1510)는 그의 입력 데이터 세트(1520)의 구조를 모르고 있을 수 있고, 입력 데이터 세트(1520)가 얼마나 큰지는 중요하지 않다.
대부분의 경우들에서, 제1 단방향 해시 함수(1510)의 결과 출력(1532)의 크기는, 입력 데이터 세트(1520)가 얼마나 클 수 있는지에 관계없이, 전형적으로 크기가 일정하다. 이 특징은 전형적으로 임의의 단방향 해시 함수의 내장된 "데이터 압축" 기능이라고 한다. 내장된 데이터 압축 특성이 이하의 예들에서 이용될 수 있지만, 본 명세서에 나타낸 시스템들의 실시예들의 전체 구조가 이 데이터 압축 기능에 의존하지 않는다.
여전히 도 15를 보면, 단방향 해시 함수(1510)의 첫번째 적용의 결과 출력(1532)은 또한 이어서, 단방향 해시 함수(1540)의 두번째 적용을 위한 입력 데이터 세트(1530)를 형성하기 위해, 앞서 사용된 비밀 키(1521) 및 대응하는 페이로드 데이터 2(1533)와 함께 사용될 수 있다. 유의할 점은, 구현의 편의상, 제1 단방향 해시 함수(1510) 및 제2 단방향 해시 함수(1540)이 실제로 동작이 동일할 수 있지만 또한 상이할 수 있다는 것이다. 또한, 이 예에서, 동일한 비밀 키(1521)가 제1 단방향 해시 함수(1510) 및 제2 단방향 해시 함수(1540) 둘 다에 대해 입력 데이터 세트의 일부로서 사용되지만, 이 키들이 또한 상이할 수 있다. 제2 단방향 해시 함수(1540)의 결과 출력(1550)은 이어서 복합 키 2라고 지칭된다.
제2 단방향 해시 함수(1540)의 출력(1550)의 값을 취하고 이를 제1 단방향 해시 함수(1510)의 입력 데이터 구조(1520)의 프리커서 키 위치(1522)에 삽입하는 것에 의해 이 구조가 쉽게 무한정 확장될 수 있다는 것을 알 수 있다. 이와 유사하게, 제1 단방향 해시 함수(1510)의 입력 데이터 세트(1520)의 페이로드 데이터 1 부분(1523)이 또한 상이한 페이로드 데이터 세트로 대체될 수 있다. 그에 따라, 이 연접된 구조는 "키 체이닝(key-chaining)" 메커니즘을 생성하고, 그로써 궁극적인 결과는 임의의 큰 세트의 의존 관계들을 갖는 단일의 고정 길이 복합 키일 수 있다. 환언하면, 간단한 집계를 사용하여 임의의 수의 임의의 크기의 프리커서들에 암호적으로 의존적인 단일의 복합 키 값의 생성을 가능하게 하기 위해 복합 암호화 메커니즘이 체이닝될 수 있다.
게다가 유의할 점은, 해시 함수의 단방향 속성으로 인해, 해시 함수를 리버싱하는 것, 즉 결과 출력(1532)이 주어진 경우 입력 데이터 세트(1520)의 값을 계산하는 것이 계산적으로 불가능하다. 단방향 해시 함수의 제2의 유용한 특성은, 다른 입력 데이터 요소들의 값들 및 결과 출력 값(1532) 모두가 알려져 있더라도 개별적인 입력 데이터 요소들(예를 들어, 1521, 1522 또는 1523) 중 임의의 것의 값을 계산하는 것이 또한 계산적으로 불가능하다는 것이다.
원칙적으로 앞서 기술한 "체이닝된" 또는 "케스케이딩된" 단방향 복합 키 구조와 유사하게, 논리적으로 동등한 구조가 단방향 해시 함수 대신에 암호화 함수를 사용하여 구성될 수 있다는 것을 알 수 있다. 이 암호화 함수는 동작 원리에 영향을 주는 일 없이 대칭 암호화 함수 또는 비대칭 암호화 함수일 수 있다. 이 예의 목적상, 대칭 암호화 메커니즘에 기초하고 있는 구조를 보여줄 것이다.
앞서 기술한 단방향 복합 키 예와 달리, 암호화 체인이 특정의 중간 키 값을 재생성하기 위해 전방향 또는 역방향 입력/출력 순서로 실행될 수 있다. 이 때문에, 도 16에 도시되어 있는 구조는 "가역적" 복합 키 구성이라고 한다. 단방향 복합 키 메커니즘에서와 같이, 전방향 또는 역방향 프로세스에서의 스테이지들 중 임의의 것에서 수행되는 특정의 암호화 함수들이 동일할 수 있거나 그렇지 않을 수 있다. 이와 유사하게, "체이닝된" 가역적 복합 키 메커니즘의 전체적인 기능에 영향을 주는 일 없이 다양한 암호화 스테이지들을 통한 반복 횟수가 무한히 누적될 수 있다. 유의할 점은, 가역적 복합 키 메커니즘에서의 스테이지들 각각이 소프트웨어로 구현되는 경우, "체이닝된" 복합 키 구조의 전체적인 보안은 시스템이 중간 키들을 "체인"의 일부가 아닌 다른 프로세스들에 대해 비밀로(예컨대, 격리되게) 유지할 수 있는 것에 의존할 수 있다. 사실, 이 중간 값들 중 적어도 일부가 임의의 다른 프로세스(이 프로세스가 "체인"의 일부이든 그렇지 않든 관계없음)로부터 격리되게 유지하는 것이 바람직할 수 있다. 이러한 격리 메커니즘을 가능하게 하는 실시예들이 이하에서 논의된다.
또한 유의할 점은, 단방향 복합 키 요소 및 가역적 복합 키 요소 둘 다를 포함하는 "하이브리드" 복합 키 메커니즘이 구성될 수 있다. 이러한 구조의 한 예가 도 17에 도시되어 있다. 보안 프로세스들의 체인은 물론 그 보안 프로세스들에 제공되는 입력 데이터의 보안을 보장하기 위해 이러한 종류의 메커니즘이 유용할 수 있다.
이제부터 도 15에 도시된 복합 키 발생의 실시예들이 보안 실행 제어기 및 데이터 캐시의 실시예들의 아키텍처에서 어떻게 이용될 수 있는지의 특정의 예를 논의하는 것이 이제 도움이 될 수 있다. 도 3을 참조하면, 보안 실행 제어기의 아키텍처의 하나의 실시예가 도시되어 있다. 이 실시예에서, 보안 실행 제어기(362)는 CPU가 포함되어 있고 메인 CPU 상에서 보안 모드로 후보 코드 블록을 실행하는 것을 지원하도록 되어 있는 시스템의 CPU와 연관되어 있다. 그에 따라, 보안 실행 제어기(362)는 CPU에 보이지 않을 수 있는 비밀 하드웨어 키(310), 보안 모드 제어 레지스터(350), 허가 코드 레지스터(360), 보안 모드 상태 레지스터(352), 해시 씨드 레지스터(312), 및 하드웨어 발생 복합 키 레지스터(314)를 비롯한 레지스터들 중 하나 이상을 포함할 수 있다. 이 레지스터들 중에서, 비밀 하드웨어 키(310)를 제외한 모두가 시스템의 전체 보안에 영향을 주는 일 없이 CPU에 의해 판독가능할 수 있지만, 이 다른 레지스터들 중 임의의 것이 보일 수 있거나 그렇지 않을 수 있다.
보안 모드 제어 레지스터(350)는 대상 디바이스를 보안 모드에 두려고 시도하기 위해 기입될 수 있는 레지스터일 수 있다. 보안 모드 제어 레지스터(350)는 후보 코드 블록(예컨대, 보안 모드로 실행될 코드 블록)의 시작 주소에 대응하는 (예컨대, I-캐시 또는 메인 메모리 내의) 메모리 장소가 기입될 수 있는 레지스터 및 이러한 후보 코드 블록의 길이가 기입될 수 있는 별도의 레지스터를 가질 수 있다. 허가 코드 레지스터(360)는 허가 코드 또는 다른 유형의 키 또는 데이터가 기입될 수 있는 장소일 수 있다. 보안 모드 상태 레지스터(352)는 하드웨어 비교 블록(340)에 의해서만 세트될 수 있고 대상 디바이스(100)가 보안 모드로 동작하고 있는지 여부를 나타낼 수 있는 하나 이상의 비트들을 포함하는 메모리 매핑된 장소일 수 있다.
하드웨어 해시 함수 블록(320)은 복합 키(314)를 발생시키기 위해 해시 함수를 실질적으로 하드웨어로 구현하는 동작을 할 수 있다. 하드웨어 해시 함수 블록(320)은, 예를 들어, SHA(256) 또는 어떤 유사한 단방향 해시 함수를 구현할 수 있다. 그렇지만, 이 해시 함수는 또한 시스템의 CPU와 별도의 프로세서에서 실행 중인 소프트웨어로 또는 펌웨어로 구현될 수 있거나, 심지어 앞서 기술된 바와 같은 가상 하드웨어 해시 함수 방법을 사용하여 CPU 상에서 보안 모드로 실행되는 프로세스일 수 있다.
하드웨어 해시 함수 블록(320)은 해시 씨드 레지스터(312)에 저장된 값들, 비밀 하드웨어 키(310) 또는 다른 장소로부터의 데이터 중 하나 이상을 입력으로서 취하고, 이 입력들을 연접시키며(하나의 입력을 다른 입력에 전치 첨부(prepend) 또는 후치 첨부(append)함), 결과 데이터 세트를 해싱하여 메시지 인증 코드(앞서 단방향 복합 키라고 지칭하였음)를 발생시킬 수 있다.
특정의 실시예들에서, 거의 모든 수치값이 하드웨어 해시 함수 블록(320)에 대한 입력(프리커서)으로서 제공될 수 있다. 도 6을 간략히 참조하면, 예를 들어, 하드웨어 해시 함수(510)에 대한 입력 데이터는 비밀 하드웨어 키(514), 해시 씨드 프리커서 키(516) 및 보안 코드 블록 후보(532)의 연접에 의해 구성될 수 있다. 입력 데이터(514, 516 및 532)가 무엇을 나타내는지 또는 이 데이터 세트들 중 임의의 것이 얼마나 클 수 있는지에 거의 관계없이, 해시 함수(510)의 동작에 기본적인 차이가 없을 수 있다. 또한 여기서 유의할 점은, 보안 모드 제어기 상태 기계(580)로부터 오는, 도시되어 있는 하드웨어 해시 함수(510)에의 다른 입력들은 해시 함수에의 입력 데이터와 달리 제어 입력들을 나타낸다.
이제 도 7을 간략히 참조하면, 도 6에 나타낸 것과 동일한 구조가 도시되어 있지만, 이 경우에, 해시 함수(524)의 결과 출력이 이제는 도시되어 있다. 이 값(524)은 최근의 암호 문헌에서 통상적으로 메시지 인증 코드(Message Authentication Code)(또는 MAC)라고 하고, 이 결과(524)는 또한 본 명세서에서 복합 키(예컨대, 하드웨어 발생 복합 키)라고 지칭되었다. (거의 모든) 보안 단방향 해시 메커니즘들의 본질적인 압축 기능으로 인해, 사용된 입력 데이터 세트들이 얼마나 큰지 또는 심지어 데이터가 해시 함수(510)를 통해 몇번 반복되었는지에 거의 관계없이, 얻어진 복합 키(524)는 일정한 크기일 것이다.
이제 다시 도 3을 참조하면, 하드웨어 발생 복합 키 레지스터(314)는 하드웨어 해시 함수 블록(320)의 출력을 저장하도록 구성되어 있다. 하드웨어 비교 블록(340)은 하드웨어 발생 복합 키 레지스터(314) 내의 데이터를 허가 코드 레지스터(360) 내의 데이터와 비교하도록 구성되어 있을 수 있다. 2개의 값들이 동일한 경우, 하드웨어 비교 블록(340)은 대상 디바이스를 보안 모드에 두는 보안 모드 상태 레지스터(352) 내의 하나 이상의 비트들을 세트시키도록 구성되어 있다.
보안 모드 제어기 상태 기계(370)는 보안 모드 제어 레지스터(350) 또는 보안 모드 상태 레지스터(352)의 비트들의 상태에 기초하여 동작할 수 있는 논리(예컨대, 하드웨어, 소프트웨어 또는 어떤 조합)일 수 있다. 프리커서들이 하드웨어 해시 함수 블록(320)의 원하는 출력(314)을 발생시키기 위해 정확한 방식으로 이용될 수 있도록, 보안 모드 제어기 상태 기계(370)는 하드웨어 해시 함수 블록(320)에의 입력들을 제어하도록 구성되어 있다. 예를 들어, 보안 모드 제어기 상태 기계(370)는 얻어진 출력이 적당한 때에 하드웨어 발생 복합 키 레지스터(314)에 로드되게 하도록 구성되어 있을 수 있다. 그에 부가하여, 보안 모드 제어기 상태 기계(370)는 정확한 데이터가 보안 모드 상태 레지스터(352)에 기입되게 하도록 구성되어 있을 수 있다.
보안 모드 제어기 상태 기계(370)는 또한 대상 디바이스가 보안 모드로 실행 중일 때 메모리 액세스를 제어하도록 구성되어 있을 수 있다. 하나의 실시예에서, 보안 모드 상태 레지스터(352) 내의 비트들이 대상 디바이스가 현재 보안 모드로 동작하고 있다는 것을 나타낼 때, 보안 모드 제어기 상태 기계(370)는 데이터 캐시의 페이지들 중 어느 것이 그 프로세스에 할당되었는지를 판정하고 데이터 캐시의 페이지들 중 하나 이상과 관련하여 그 프로세스에 대한 보안 서술자를 데이터 캐시에 저장하도록 구성되어 있을 수 있다. 이 보안 프로세스 서술자들은 이와 같이 데이터 캐시에 저장되어 있는 특정의 데이터 세트를 보안 모드로 실행 중인 특정의 프로세스와 연관시키기 위해 사용될 수 있다. 이러한 보안 프로세스 서술자는, 예를 들어, 허가 코드 레지스터(360) 또는 하드웨어 발생 복합 키 레지스터(314)에 위치해 있는 데이터에 기초하는 값일 수 있다.
그에 부가하여, 대상 디바이스를 보안 모드에 두는 보안 모드 상태 레지스터(352) 내의 비트들이 세트되어 있을 때, 보안 모드 제어기 상태 기계(370)는 보안 모드로 실행 중인 프로세스에 의한 메모리 액세스들을 수신하고 메모리 액세스가 판독 또는 기입 액세스인지를 판정할 수 있다.
데이터 액세스가 기입 동작으로 이루어져 있는 경우, 보안 모드 제어기 상태 기계(370)는 데이터가 기입되어야 하는 주소에 대응하는 데이터 캐시의 캐시 라인을 결정하고 이어서 그 캐시 라인과 연관되어 있는 보안 플래그를 그 캐시 라인에 포함된 데이터가 안전하다는 것을 나타내게 세트시키도록 구성되어 있을 수 있다. 특정의 실시예들에서, 보안 모드 제어기 상태 기계(370)는 또한, 예를 들어, 대상 디바이스의 데이터 캐시 또는 메모리 제어기의 동시 기입, 라이트 백(write-back) 또는 다른 동작들을 디스에이블시킴으로써, 데이터 캐시에 있지 않은 임의의 메모리 장소에의 임의의 기입들을 방지하도록 구성되어 있다.
액세스가 판독 액세스인 경우, 보안 모드 제어기 상태 기계(370)는 캐시 미스(cache miss)가 일어났는지 판정하도록 구성되어 있을 수 있고, 요청된 주소가 이전에 데이터 캐시에 저장되지 않은 경우, 보안 모드 제어기 상태 기계(370)는 요청된 데이터가 메인 메모리로부터 판독되어 데이터 캐시에서 프로세스와 연관되어 있는 페이지에 넣어질 수 있도록 구성되어 있을 수 있다. 캐시 히트(cache hit)가 일어나는 경우, 보안 모드 제어기 상태 기계(370)는 메모리 액세스의 주소에 대응하는 캐시 라인을 결정하도록 그리고 그 캐시 라인과 연관되어 있는 보안 플래그가 세트되어 있는지를 판정하기 위해 그 보안 플래그를 검사하도록 구성되어 있을 수 있다. 보안 플래그가 세트되어 있지 않은 경우, 메모리 액세스가 계속될 수 있다(예컨대, 데이터가 캐시 라인으로부터 판독될 수 있음).
다른 대안으로서, 데이터가 판독되어야 하는 주소에 대응하는 데이터 캐시 내의 캐시 라인과 연관되어 있는 보안 플래그가 세트되어 있는 경우, 보안 모드 제어기 상태 기계(370)는 그 캐시 라인을 포함하는 데이터 캐시 내의 페이지와 연관되어 있는 보안 프로세스 서술자를 획득하고 이를 현재 실행 중인 프로세스와 연관되어 있는 보안 프로세스 서술자와 비교하도록 구성되어 있을 수 있다. 보안 프로세스 서술자들이 일치하는 경우, 메모리 액세스가 계속될 수 있다. 보안 서술자들이 일치하지 않는 경우, 메모리 액세스에 응답하여 가비지(garbage) 또는 사전 설정된 값을 반환하는 것 또는 그 주소에 "유효한 데이터 없음" 메시지를 CPU로 반환하는 것과 같은 다른 동작이 취해질 수 있고, 그러면 CPU 메모리 관리 유닛은 시스템 메모리로부터 판독할 대체 캐시 라인을 요청할 수 있다.
하나의 실시예에서, 보안 모드로 실행 중인 프로세스의 전체 작업 세트를 저장하기 위해 데이터 캐시만이 사용되고, 프로세스에 의한 데이터 캐시 이외의 메모리에의 임의의 기입들이 디스에이블될 수 있다. 그에 부가하여, 보안 모드에 있는 동안 기입되는 데이터 캐시의 임의의 라인들(예컨대, 소위 "더티" 캐시 라인들)이 "더티" 캐시 라인이 어느 프로세스에 속하는지를 일의적으로 그리고 정확하게 명시할 수 있는 보안 프로세스 서술자와 연관되어 있다. 원래의 프로세스가 종료된 후에도, 보안 프로세스의 동작 동안 수정된 임의의 캐시 라인이 임의의 다른 프로세스에 의해 판독가능하지 않도록, 이 캐시 라인들에 대한 액세스가 특정의 "더티" 캐시 라인의 소유자에게만 허용될 수 있다. 이와 같이, 프로세스의 하나의 인스턴스에 속하는 데이터가 임의의 다른 프로세스로부터 명확하게 격리된다.
이제 도 4a 및 도 4b로 가면, 특정의 실시예들에 따른 프로세스들의 작업 세트들의 격리를 달성하기 위해 이용될 수 있는 데이터 캐시의 아키텍처의 하나의 실시예가 도시되어 있다. 먼저 도 4a를 참조하면, 데이터 캐시(400)는 원하는 거의 모든 관리 또는 기입 정책들과 관련하여 구현될 수 있는 L1 캐시, L2 캐시, 직접 매핑(direct mapped) 캐시, 2-웨이 집합 연관(2-way set associative) 캐시, 4-웨이 집합 연관(4-way set associative), 2-웨이 스큐 연관(2-way skewed associative) 캐시 등을 비롯한 거의 모든 유형의 캐시일 수 있다. 캐시(400)는 한 세트의 페이지들(410)을 포함할 수 있다. 본 명세서에서 캐시를 언급하는 경우에 사용될 때, 페이지는 캐시 블록(cache block) 또는 캐시 세트(cache set)를 의미하는 것으로 이해될 수 있다. 데이터 캐시(400)는 캐시의 하나 이상의 페이지들(410)과 연관되어 있는 보안 서술자를 저장하도록 구성되어 있다.
도 4b는 캐시(400)의 페이지(410a)의 하나의 실시예의 도면을 나타낸 것이다. 여기서, 캐시는 페이지(410a)와 관련하여 보안 프로세스 서술자를 저장하도록 그리고 페이지(410a)의 보안 프로세스 서술자에 대한 요청에 응답하여 또는 페이지(410a)의 캐시 라인(402)에 대한 판독과 관련하여 보안 프로세스 서술자를 제공하도록 설계되어 있는 논리(412)를 포함한다. 페이지(410a)의 각각의 캐시 라인(402)은 데이터, 주소 태그들 및 플래그들(420)에 대한 비트들을 포함하고 있다. 플래그들(420)은 유효 비트(valid bit) 또는 더티 비트(dirty bit)와 같은 비트들을 포함할 수 있다. 그에 부가하여, 플래그들(420)은 보안 비트(422)를 포함할 수 있다. 캐시(400)는 (예컨대, 보안 모드로 실행 중인 프로세스가 그 캐시 라인(402)에 기입할 때) 캐시 라인(402)에 대한 보안 비트(422)가 세트될 수 있도록 구성될 수 있다.
이러한 대상 디바이스의 실시예들이 어떻게 보안 모드에 놓여질 수 있는지를 설명하는 것이 이제 유용할 것이다. 다시 말하지만, 2009년 11월 10일자로 출원된, 발명의 명칭이 "범용 컴퓨팅 디바이스 상에서의 코드 실행의 제어 및 재귀적 보안 프로토콜에서의 코드 실행의 제어 방법 및 시스템(Method and System for Control of Code execution on a General Purpose Computing Device and Control of Code Execution in an Recursive Security Protocol)"인 미국 특허 출원 제12/615,843호의 검토로부터 특정의 실시예들의 더 나은 이해가 얻어질 수 있고, 이 미국 출원의 발명 요지는 본 출원의 도 18 내지 도 36과 관련하여 기술되어 있다.
유의할 점은, 하나의 실시예에서, 임의의 일반(또는 다른) 코드 블록이 본 명세서에 기술되는 것과 같은 시스템의 실시예들 상에서 보안 모드로 실행될 수 있는 절차("보안 작업 함수(secure work function)"라고 지칭될 것임)는, 보안 작업 함수의 양측에서(예컨대, 이전에 또는 이후에) 하나씩, 한 쌍의 추가 함수들을 실행하는 것이다. 보안 작업 함수 직전에 실행되는 함수(또는 함수들의 세트)는 "프롤로그(prologue)"라고 지칭될 것이고, 보안 작업 함수 직후에 실행되는 함수(또는 함수들의 세트)는 "에필로그(epilogue)"라고 지칭될 것이다.
이와 같이, 하나의 실시예에서, CPU 상에서 보안 작업 함수를 실행하기 위해, 그 보안 작업 함수 이전에 프롤로그가 선행되어야 하고 그 이후에 에필로그가 따라와야 한다. 특정의 실시예들에서, 프롤로그의 목적은 적어도 3가지이다. 첫째, 프롤로그는 보안 작업 함수에 의한 사용을 위해 보안 작업 함수로 전달되는 입력 인수들(input arguments)을 준비해야만 한다. 이 준비는, 예를 들어, 보안 작업 함수에 평문으로 전달되지 않을 수 있는 그 입력 인수들에 대해 필요할 수 있는 복호화 프로세스를 포함할 수 있다. 프롤로그의 제2 함수는 다수의 데이터 요소들에 의존하는 값을 갖는 복합 키를 구성하는 것일 수 있다. 이러한 데이터 요소들은 대상 디바이스의 하드웨어 비밀 키, 부모(예컨대, 호출) 함수의 허가 코드, (암호화된 또는 비암호화된 형태로 되어 있는) 보안 작업 함수에 대한 하나 이상의 입력 인수들의 목록, 보안 작업 함수 자체의 실행가능 이미지, 또는 보안 작업 함수가 대상 디바이스 상에서 보안 모드로 실행하도록 허용되어야만 하는지를 판정하는 데 사용될 수 있는 어떤 다른 정보를 포함할 수 있다. 프롤로그의 제3 함수는 CPU가 보안 작업 함수를 보안 모드로 실행하기 시작하라는 요청을 개시하는 것일 수 있다.
에필로그의 목적은 보안 작업 함수의 실행이 완료된 후에 "소거(clean up)"하는 것일 수 있다. 에필로그의 하나의 기능은 (예컨대, 보안 작업 함수 이후에 실행될) 후속하는 코드 블록들(보안이거나 그렇지 않음)에 의한 사용을 위한 임의의 지정된 출력 파라미터들을 준비하는 것일 수 있다. 예를 들어, 이 준비는 이러한 출력 인수들의 의도된 수신자 이외의 임의의 관찰 프로세스들(하드웨어 또는 소프트웨어 기반 관찰자들을 포함함)이 그 데이터를 사실상 가로채지 못하게 배제될 수 있도록 보안 작업 함수로부터의 지정된 출력(또는 반환된 데이터)의 암호화를 포함할 수 있다. 이러한 경우에, 사용될 수 있는 암호화 키는 그의 호출 인수들(calling arguments) 중 하나로서 보안 루틴(secure routine)으로 전달되는 가역적 복합 키일 수 있다.
에필로그의 제2 기능은 보안 작업 함수가 실행 중인 동안 (예컨대, 보안 작업 함수에 의해) 기입된 데이터 캐시의 그 부분들을 프로그램적으로 또는 자동으로 무효화하는 것일 수 있다. 이와 같이, 보안 작업 함수가 그의 동작을 일시 정지시키고 이어서 재개시킬 수 있는 경우에, 프로세스가 일시 정지되기 전에 데이터 캐시의 보안 부분에 기입된 데이터 값들이 따라서, 이 보안 데이터 장소들을 메모리로 페이징 아웃할 필요 없이(이는 중간 암호화 프로세스를 수반할 수 있음), 재개된 보안 프로세스에 의해 이용가능할 수 있다. 이어서, 보안 함수가 재개되면, 이 동일한 데이터 캐시 장소들이 보안 함수에 의해 이용가능하게 될 수 있는데, 그 이유는 보안 프로세스 서술자가 현재 실행 중인 허가 코드 또는 그의 어떤 파생물(또는 보안 프로세스 서술자로서 사용되고 있는 다른 값)과 일치할 수 있기 때문이다.
그렇지만, 보안 프로세스가 (예를 들어, 에필로그 함수를 사용하여) 종료되면, 이 동일한 보안 데이터 캐시 장소들이 에필로그 함수 동안 유효하지 않은 것으로 표시될 수 있다. 이 무효화 프로세스는 데이터 캐시의 보안 부분에 여전히 존재할 수 있는 데이터의 임의의 의도하지 않은 잠재적 "누설"이 보안 작업 함수가 적절히 종료된 후에 액세스되지 않도록 할 것이다.
이러한 방식으로, 심지어 보안 작업 함수가 반복되는 경우 그리고 보안 작업 함수가 두번 연속 동일한 보안 프로세스 서술자를 제공받는 경우, 이들이 이들 반복 둘 다에 대해 동일한 보안 프로세스 서술자를 가질 수 있다는 사실에도 불구하고, 이 보안 작업 함수의 두번째 반복은 그럼에도 불구하고 그 동일한 보안 작업 함수의 첫번째 반복으로부터의 작업 세트 데이터에 액세스할 수 없을 것이다. 유의할 점은, 프롤로그 및 에필로그에 대한 설명은 예로서 제공되어 있고, 더 많은 또는 더 적은 함수들이 에필로그의 프롤로그에 의해 달성될 수 있고, 그에 부가하여, 기술된 바와 같이 실시예들의 범위를 벗어남이 없이 이 함수(또는 부가의 또는 더 적은 함수)가 다른 방식으로 달성될 수 있다.
도 5 내지 도 7은 대상 디바이스를 보안 모드에 두는 흐름의 하나의 실시예의 블록도를 나타낸 것이다. 먼저 도 5를 참조하면, 처음에, 코드 블록(531)이 보안 모드로 실행되도록 구성되어 있을 수 있다. 이러한 코드 블록이, 예를 들어, 콘텐츠 배포 시스템으로부터 수신되거나 컴퓨터 판독가능 매체 등으로부터 로드될 수 있다. 그에 부가하여, 허가 코드가, 예를 들어, 라이센싱 기관으로부터 수신되거나, 컴퓨터 판독가능 매체로부터 판독되거나, 사용자에 의해 입력되거나, 기타일 수 있다. 코드 블록(보안 모드에서 실행할 "후보"이기 때문에, 명세서에서 어떤 장소들에 있는 후보 코드 블록이라고 함) 및 허가 코드(520) 둘 다가 대상 디바이스의 메인 메모리(530)에 저장될 수 있다.
유의할 점은, 이 실시예에서, 후보 코드 블록이 프롤로그 함수, 보안 작업 함수 및 에필로그 함수를 그 순서로 포함하고 있다. 이러한 실시예에서, 보안 작업 함수과 연관되어 있을 허가 코드는 후보 코드 블록의 모든 3개의 기능 섹션들에 대한 의존 관계들을 포함할 수 있다. 그렇지만, 어떤 실시예들에서, 프롤로그 및 에필로그 함수들은 실질적으로 고정된 방식으로(환언하면, 하드웨어 또는 펌웨어로) 구현될 수 있다. 그 경우에, 후보 코드 블록에 대한 허가 코드가 프롤로그 및 에필로그 함수들에 대한 더 제한된 의존 관계들을 가질 수 있는 것이 가능하다.
그에 따라, 후보 코드 블록(510)이 I-캐시(540)에 로드되고 CPU 실행 유닛(550)에 의해 실행되기 시작할 때, CPU 실행 유닛(550)은 보안 실행 제어기(570)의 보안 모드 제어 레지스터(560)에 액세스하고, 대상 디바이스를 보안 모드에 두는 것을 개시하기 위해 보안 모드 제어 레지스터(560)의 비트들을 세트시킬 수 있다. 그에 부가하여, 후보 코드 블록(531)의 길이와 함께 후보 코드 블록(531)의 메모리 장소(예컨대, 코드 블록(531)이 전송되고 있는 I-캐시 내의 장소 또는 메인 메모리(530) 내의 장소)가 보안 모드 제어 레지스터(560)에 기입될 수 있다. 보안 모드 제어 레지스터(560) 내의 비트들을 세트시킨 것에 기초하여, 보안 모드 제어기 상태 기계(580)가 하나 이상의 기능들을 수행할 수 있다.
계속하여 도 6으로 가면, 보안 모드 제어기 상태 기계(580)는 후보 코드 블록(531)이 보안 실행 제어기(570)의 하드웨어 해시 블록(510)에 제공되도록 대상 디바이스를 구성할 수 있다. 이 구성은, 예를 들어, 보안 모드 제어 레지스터(560)에 기입되는 후보 코드 블록의 메모리에서의 장소에 기초하여 행해질 수 있다.
하나의 실시예에서, 보안 모드 제어기 상태 기계(580)는 메인 메모리(530)로 가서, 후보 코드 블록을 I-캐시(540)에 명시적으로 로드하기 위해 후보 코드 블록(531)을 페치(fetch)할 수 있다. 다른 실시예에서, 대상 디바이스의 어떤 다른 부분이 후보 코드 블록(531)을 메인 메모리(530)로부터 I-캐시(540)에 로드할 때, 보안 모드 제어기 상태 기계(580)는 데이터 버스 트랜잭션들을 관찰하여, 후보 코드 블록(510)이 그 전체가 I-캐시(540)에 로드되었다는 것을 확인할 수 있다.
다른 실시예에서, 보안 모드 제어기 상태 기계(580)는 대상 디바이스의 다른 부분으로 하여금 메인 메모리(530)로부터 I-캐시(540)로의 이러한 전송을 수행하게 할 수 있다. 또 다른 실시예에서, 보안 모드 제어기 상태 기계(580)는 메인 메모리(530)로부터 전송된 데이터를 관찰하고 데이터가 I-캐시(540)로 전송될 때 데이터를 추적할 수 있다.
하나의 실시예에서, 후보 코드 블록(531)을 포함하는 비트들이 하드웨어 해시 함수 블록(510)에 제공될 수 있는데, 그 이유는 이들이 버스를 통해 메인 메모리(530)로부터 I-캐시(540)로 전송되기 때문이다. 수신된 후보 코드 블록(531)을 사용하여, 하드웨어 해시 블록(512)은 후보 코드 블록(531), 비밀 하드웨어 키(514) 및 선택적으로 해시 씨드 레지스터(516)에 저장된 하나 이상의 다른 프리커서 값들로부터 복합 키를 생성할 수 있다.
도 7을 참조하면, 어떤 시점에서, 후보 코드 블록의 보안 실행을 시작하기 위해, CPU 실행 유닛은 후보 코드 블록(531)과 연관되어 있는 허가 코드(520)를 보안 실행 제어기(570)의 허가 코드 레지스터(522)에 기입할 수 있다. 하드웨어 해시 블록(512)에 의해 복합 키가 발생될 때, 이는 하드웨어 발생 복합 키 레지스터(524)에 기입된다. 보안 모드 제어기 상태 기계(580)는 이어서 하드웨어 발생 복합 키 레지스터(524) 내의 값과 허가 코드 레지스터(522) 내의 값 간의 비교를 개시하도록 구성되어 있다. 이 값들이 일치하면, 하드웨어 비교 블록(532)은 대상 디바이스를 보안 모드에 두는 보안 모드 상태 레지스터(534) 내의 비트들을 기입할 수 있다. 코드 블록(510)은 이어서 CPU 실행 유닛(550)에 의해 보안 모드로 실행될 수 있다. 이 값들이 일치하지 않는 경우, 대상 디바이스가 보안 모드에 있지 않을 것이지만, 코드 블록(510)은 (비록 보안 모드에 있지 않지만) 여전히 실행하도록 허용될 수 있다(또는 그렇지 않을 수 있다).
그러면 알 수 있는 바와 같이, 보안 모드에서의 코드의 실행이 제공된 허가 코드의 사용을 통해 제어될 수 있다. 이 허가 코드는 대상 디바이스로 배포되는 후보 코드 블록에 암호적으로 의존하기도 하고 (예컨대, 그 대상 디바이스의 비밀 키를 사용하여) 각각의 대상 디바이스에 바인딩되어 있기도 하는 복합 키(DS)일 수 있다.
그에 따라, 후보 코드 블록이 특정의 대상 디바이스 상에서 보안 모드로 실행할 수 있게 하기 위해, (예컨대, 후보 코드 블록 및 대상 디바이스의 비밀 키 둘 다를 사용하여 구성되는) 정확한 허가 코드가 제공되어야만 한다. 어떤 다른 대상 디바이스도 그 허가 코드로 후보 코드 블록을 정확하게 실행할 수 없고, 어떤 다른 복합 키도 그 대상 디바이스 상에서 그 후보 코드 블록에 대해 동작하지 않는다.
그 결과, 대상 디바이스가 보안 모드로 실행 중일 때에만(또는, 예를 들어, 대상 디바이스가 보안 모드에 있어야만 하는 것으로 판정할 때와 같이 특정의 다른 경우들에서) 대상 디바이스의 비밀 키가 액세스될 수 있기 때문에, 순환 의존 관계(circular dependency)와 유사한 의존 관계가 생성되었다. 특정의 코드 블록이 그 대상 디바이스 상에서 보안 모드로 실행할 수 있게 하기 위해, 제일 먼저 디바이스의 비밀 키를 가지고 있는 어떤 엔터티만이 복합 키를 발생시킬 수 있다. 이와 같이, 엔터티는, 코드가 그 키에 액세스하도록 허가할 수 있기 전에, 디바이스의 비밀 키의 사전 지식을 필요로 할 수 있다. 엔터티가 비밀 키의 정확한 값에 액세스하지 않은 경우, 엔터티는 그 코드가 보안 모드에서 실행하도록 허가하기 위해 유효한 복합 키를 발생시킬 수 없다.
게다가, 라이센싱 기관에 의해 제공된 복합 키가 원래의 코드 블록 및 비밀 키를 사용하여 생성되었기 때문에, 후보 코드 블록이 임의의 방식으로 수정되었고, 대상 디바이스에서 발생된 복합 키가 (예컨대, 라이센싱 기관으로부터) 수신된 복합 키와 일치하지 않으며, 따라서 대상 디바이스가 보안 모드에 있지 않게 되는 것처럼, 대상 디바이스 상의 후보 코드 블록이 디바이스를 보안 모드에 두기 전에 수정되거나 변조되지 않도록 보장될 수 있다.
이러한 방식으로, 대상 디바이스 상에서의 해시 함수의 사용은 후보 코드 블록이 변조되지 않았다는 것을 검증하고, (예컨대, 앞서 기술된 복합 키 "체이닝" 방법의 사용에 의해) 프로세스들의 실행 순서를 보장하는 것은 물론 후보 코드 블록이 대상 디바이스 상에서 보안 모드로 실행하도록 허가되어 있다는 것을 확인한다. 시스템의 전체적인 동작 보안을 유지하기 위해, 하나의 실시예에서, 코드 블록을 프로세스로서 보안 모드로 실행할 때, 호출 인수들이 (악의적으로 또는 다른 방식으로) 수정되지 않았도록; 프로세스가 (예컨대, 중단이 있거나 중단 없이) 끝까지 실행되도록 그리고 프로세스의 작업 세트가 외부 관찰로부터 격리된 채로 있도록 보장하는 것이 또한 요망된다.
하나의 실시예에서, 이 3가지 요망 사항들 중 첫번째(호출 인수들이 수정되지 않도록 보장하는 것)는 호출 인수들(또는 그의 적절한 서브셋)이 해시 함수에 의해 보호될 후보 코드 블록의 나머지에 포함되는 경우 달성가능하다. 이 개념은 후보 코드 블록의 내용의 실시예들과 관련하여 앞서 논의되었다.
후자의 두가지 요망 사항들(각각 끝까지 실행 및 작업 세트 격리라고 함)은 또한, 특정의 실시예들에서, 본 명세서에 기술되어 있는 복합 키 또는 재귀적 실행 컴포넌트들을 사용하여 해결될 수 있다. 앞서 언급한 바와 같이, 끝까지 실행을 보장하는 실시예들은 2009년 11월 10일자로 출원된, 발명의 명칭이 "범용 컴퓨팅 디바이스 상에서의 코드 실행의 제어 및 재귀적 보안 프로토콜에서의 코드 실행의 제어 방법 및 시스템(Method and System for Control of Code execution on a General Purpose Computing Device and Control of Code Execution in an Recursive Security Protocol)"인 미국 특허 출원 제12/615,843호에 개시되고 논의되어 있으며, 이 미국 출원의 발명 요지는 본 출원의 도 18 내지 도 36과 관련하여 기술되어 있다.
이어서 작업 세트 격리를 살펴보면, (어쩌면 반환된 인수들 이외의) 보안 모드에서 프로세스의 실행 동안 수정되거나 발생되는 임의의 데이터가, 원래의 프로세스가 종료된 후에도, 임의의 다른 프로세스에 의해 판독가능하지 않은 채로 있는 것이 요망될 수 있다. 작업 세트 격리는 프로세스를 보안 모드로 실행 중일 때 사용되는 시스템 메모리(예컨대, 데이터 캐시 또는 메인 메모리) 중 임의의 것이 외부 관찰로부터 격리되도록 단순히 보장하는 것보다 더 복잡할 수 있는데, 그 이유는 그렇지 않았으면 폐쇄된 보안 시스템을 공격하는 다수의 공지된 부채널 또는 간접적인 방법들이 있기 때문이며, 그 중 타이밍 공격 및 DPA(Differential Power Analysis, 차분 전력 분석)는 이러한 널리 실시되는 방식들 중 2가지 더 강력한 것이다.
작업 세트 격리를 보장하기 위해, 특정의 실시예들에서, 대상 디바이스가 보안 모드로 실행 중일 때(예컨대, 대상 디바이스를 보안 모드에 두기 위해 사용되는 보안 모드 상태 레지스터의 비트가 세트되어 있을 때), 프로세서의 데이터 캐시는 현재 실행 중인 보안 코드 세그먼트의 전체 작업 세트를 저장하는 데 사용될 수 있고, 프로세스에 의한 메모리의 임의의 다른 부분에의 기입들이 허용되지 않을 수 있으며, 데이터 캐시의 라인들의 동시 기입 또는 라이트 백(또는 데이터 캐시와 메인 메모리 사이의 임의의 다른 유형의 메모리 동기화)이 또한 허용되지 않을 수 있다. 그에 부가하여, 보안 모드에 있는 동안 보안 프로세스에 의해 기입되는 데이터 캐시의 임의의 라인들이 데이터 캐시 라인이 속하는 프로세스를 일의적으로 그리고 정확하게 명시하는 고유의 보안 프로세스 서술자로 태깅될 수 있다. 그러면 그 데이터 캐시 라인들(또는 페이지들)에의 액세스는 그 보안 서술자와 연관되어 있는 프로세스로만 제한될 수 있다.
그에 따라, 특정의 실시예들에서, 보안 프로세스 서술자는 상이한 프로세스들을 상이한 코드 블록들과 구별할 뿐만 아니라 상이한 때에 동일한 코드 블록을 실행하는 것으로부터 얻어진 상이한 프로세스들 간을 구별할 수 있도록 충분히 일의적이다. 그에 따라, 보안 서술자는 복합 키일 수 있다. 본 명세서에서 논의되는 이전의 예들에서와 같이, 대상 디바이스의 비밀 키를 손상시키는 일 없이 이 보안 서술자를 생성하기 위해 복합 키 메커니즘이 이용될 수 있다. 이러한 경우에, 부가된 장점은 앞서 기술한 기존의 하드웨어 기반 해시 블록 및 하드웨어 비교 블록이, 임의의 중간 데이터를 외부 공격자에 노출시키는 일 없이, 이 보안 프로세스 서술자들을 생성하거나 비교하는 데 사용될 수 있다는 것이다.
사실, 하나의 실시예에서, 이용될 수 있는 간단하고 효과적인 보안 프로세스 서술자는 보안 모드로 실행 중인 코드 블록과 연관되어 있고 그를 검증하는 데 사용되는 허가 코드이다. 보안 프로세스 서술자들의 다른 예들을 생성하는 데 이용될 수 있는 예시적인 프리커서들은, 예를 들어, 대상 디바이스의 비밀 키, 보안 모드로 실행 중인 코드 블록의 메시지 다이제스트(예컨대, 허가 코드), 부모 프로세스의 보안 프로세스 서술자(예컨대, 현재 실행 중인 프로세스의 호출 함수(calling function)) 또는 현재 실행 중인 프로세스의 호출 인수들이다.
물론, 많은 다른 가능한 조합들이, 지리적 위치 또는 하루 중 시간과 같은 변수들을 비롯하여, 이 복합 키 기반 보안 프로세스 서술자에 대한 프리커서 값들로서 사용될 수 있을 것이다. 이러한 한 세트의 변수들에 기초하여 보안 프로세스의 심지어 그 자신의 작업 세트에 대한 접근가능성을 동적으로 제한할 수 있는 것은 전체 시스템의 전체적인 동작에 대한 커다란 영향을 미칠 수 있다. 이러한 종류의 외부 데이터 의존 관계를 갖는 보안 코드 블록에 대한 기능적 영향들이 엄청나고, 이 기능이 간단하고 아주 효율적인 메커니즘에서 보안 모드로 실행 중인 임의의 코드 블록에 부가될 수 있다. 단지 한 예로서, 보안 코드 블록이 실행되고 있는 대상 디바이스가 2014년 3월 19일 동부 시간으로 오후 2시와 오후 2시 25분 사이에 맨해튼 중간 지대에 있는 특정의 3 블록 영역 내에 위치해 있을 때에만 정확한 결과를 생성하게 될 보안 코드 블록이 생성될 수 있을 것이다.
또한, 유의할 점은, 특정의 실시예들에서, 보안 코드 블록이 완료 이전에 인터럽트되는 경우, 그의 작업 세트가 임의의 다른 보안 코드 블록에 의해 액세스될 수 없다(어쩌면 그가 그 자신을 호출하는 경우에도 그렇지 않음). 보안 코드 세그먼트의 결과를(그리고 그 결과만을) 다시 그의 부모로 반환할 수 있는 것과 관련하여, 보안 코드 블록으로부터의 반환된 값(들)은, 앞서 기술된 바와 같이, 유사하게 제한된 액세스 권한을 가질 수 있다. 이 경우에, 자식 루틴의 반환 인수들에 대한 보안 프로세스 서술자 캐시 태그들은 부모 루틴의 보안 프로세스 서술자(그 자체가 유사하게 "보안" 방식으로 "자식" 루틴으로 전달되는 인수일 수 있음)에 기초할 것이다. 단방향 복합키 구조 또는 가역적 복합 키 구조를 사용함으로써, 부모 프로세스와 자식 프로세스 사이에서 전달되는 특정의 인수가 "판독 전용" 또는 "판독/기입" 데이터 유형으로서 정의되는지의 선택이 행해질 수 있다. 자식 프로세스 보안 작업 함수가 종료하면, "더티" 캐시 라인들(예컨대, 자식 프로세스의 보안 작업 함수에 의해 그에 기입되었던 데이터를 포함하는 것)이 에필로그 함수에 의해 무효화될 수 있고, 따라서 임의의 프로세스(보안 프로세스 또는 기타 프로세스)에 의해 액세스될 수 없을 수 있다. 사실상, 보안 자식 프로세스가 적절히 구성된 에필로그 함수에 의해 정상적으로 종료되면, 이들 데이터는 논리적으로 "증발(evaporate)"하는데, 그 이유는 어떤 프로세스에 의해서도, 심지어 그에 처음으로 기입한 동일한 프로세스에 의해서도 더 이상 판독될 수 없기 때문이다. 유의할 점은, 영향을 받는 캐시 라인들이 명시적으로 소거될 필요가 없고, 단지 더 이상 액세스가능하지 않을 것이며, 이 데이터에 대한 액세스를 거부하는 아주 효과적이고 효율적인 수단이라는 것이다.
또한, 보안 프로세스가 종료하면, 그의 최종적인 동작은 특정의 반환된 결과를, 어쩌면 암호화된 형태로, 다시 부모 루틴으로 전달하는 것이다. 이 경우에, 사용되는 암호화 키는 호출(부모) 루틴의 보안 프로세스 서술자에 기초할 것이다. 보안 자식 프로세스가 이 최종적인 동작 이전에 종료되면, 반환된 값들이 부모 루틴에 의해 액세스될 수 없을 것이다. 이 특정의 메커니즘은 부분 결과가 임의의 다른 프로세스(보안 프로세스 또는 기타 프로세스)에 의해 결코 액세스되지 못하게 한다. 이 작업 세트 격리 메커니즘이, 예를 들어, "안전한" 및 "안전하지 않은" 메모리 뱅크들로의 간단한 주소 공간 양분보다 훨씬 더 안전하고 훨씬 더 세분되어 있다는 것을 쉽게 알 수 있다. 또한, 이 기능이 최소한의 오버헤드로 구현될 수 있다.
이와 같이, 보안 코드 세그먼트의 작업 세트로부터의 "누설"을 방지하는 방법 뿐만 아니라, 복합 암호화 및 속성 인증(Attributive Authentication) 메커니즘들에 기초하여 부모 코드 세그먼트와 그의 "자식들" 사이에서 결과를 효율적으로 그리고 안전하게 전달하는 방법도 기술하였다. 물론, 이 메커니즘은 각종의 방법들로 구현될 수 있지만, 이 특정의 구현은 최소한의 실리콘 면적 영향으로, 구조적 의존 관계가 전혀 없이, 그리고 전체 성능의 손실이 거의 없이, 임의의 기존의 CPU 아키텍처에 아주 용이하게 통합된다.
보안 모드로 실행 중인 프로세스의 작업 세트를 보호하는 하나의 실시예의 흐름을 나타내는 것이 이제 유용할 것이다. 이 실시예를 설명하기 위해, 도 8 내지 도 14를 살펴보기로 한다. 먼저 도 8을 참조하면, 이상의 논의로부터 상기할 점은, 코드 블록이 검증될 때, 코드 블록에 대한 허가 코드가 보안 실행 제어기(820)의 허가 코드 레지스터(812)에 들어 있고, 코드 블록이 검증될 때, 대상 디바이스를 보안 모드에 두는 보안 모드 상태 레지스터(810) 내의 비트들이 세트되고, 코드 블록(852)이 CPU 실행 유닛(850) 상에서 보안 모드로 실행된다. 이 코드 블록(852)의 실행 동안, 주소에 대한 메모리 액세스가 행해질 수 있다. 이러한 메모리 액세스가 보안 모드 제어기 상태 기계(880)에 의해 수신될 수 있다. 유의할 점은, 메모리 액세스가 다수의 방식들로, 예를 들어, 대상 디바이스의 메모리 제어기로부터, 시스템 버스의 "스누핑(snoop)"으로부터, TLB(translation lookaside buffer) 또는 다른 캐시 관리 디바이스로부터, 또는 아주 다양한 다른 방식들로 수신될 수 있다.
보안 모드 제어기 상태 기계(880)는, 이러한 메모리 액세스를 수신할 때, 메모리 액세스가 판독 액세스인지 기입 액세스인지를 판정할 수 있고(단계(803)), 메모리 액세스가 판독 액세스인 것으로 판정되는 경우, 이어서 메모리 액세스에 대응하는 주소가 3개의 데이터 캐시(840)에 이전에 저장되었는지가 판정될 수 있다(단계(805)). 이 판정은, 예를 들어, 캐시 히트가 일어나는지 캐시 미스가 일어나는지에 기초하여 행해질 수 있다. 다시 말하지만, 이 데이터가 메모리 제어기, TLB(translation lookaside buffer, 변환 참조 버퍼) 또는 다른 주소 결정 메커니즘 등으로부터와 같이 다수의 방식들로 획득될 수 있다.
도 9로 가면, 메모리 액세스가 데이터 캐시(840)에 이전에 있지 않았던 주소에 대한 것인 경우(예컨대, 캐시 미스), 판독이 허용될 수 있다(단계(807)). 원하는 주소에 있는 데이터가 메인 메모리(890)로부터 판독되고 현재 실행 중인 프로세스에 의해 사용되는 페이지(842)의 데이터 캐시(840) 내의 라인(846)에 놓여질 수 있다. 도시된 예에 나타낸 바와 같이, 요청된 주소와 연관되어 있는 데이터가 메인 메모리(890)로부터 판독되고, 페이지(842a)의 캐시 라인(846a)에 놓여 있다.
도 10을 참조하면, 메모리 액세스가 기입인 경우(단계(803)), 기입이 데이터 캐시(840) 내에 위치해 있는 주소에 대한 것인지가 판정될 수 있다(단계(813)). 주소가 데이터 캐시(840) 내에 있지 않는 경우, 데이터 캐시에 대해서만 기입이 허용되지 않을 수 있거나(단계(815)) 기입이 허용될 수 있다(예컨대, 임의의 데이터 캐시 동시 기입 옵션들이 디스에이블될 수 있다). 이제 도 11을 보면, 기입이 데이터 캐시(840) 내에 위치해 있는 주소에 대한 것인 경우(단계(813)), 그 캐시 라인(846)을 포함하는 페이지(842) 내의 적절한 캐시 라인(846)에의 기입이 허용될 수 있다. 이 예의 목적상, 메모리 액세스가 페이지(842a)의 캐시 라인(846a) 내의 데이터에의 기입인 것으로 가정한다. (페이지(842a)의 캐시 라인(846a)의 보안 비트(848a)가 세트되어 있는 예시된 예에서) 보안 모드 제어기 상태 기계(880)는 또한 기입된 캐시 라인(846)의 보안 비트를 세트시킬 수 있다(단계(817)).
이제 도 12로 가면, 기입이 데이터 캐시(840) 내에 위치해 있는 주소에 대한 것인 경우(단계(813)). 실행 중인 프로세스와 연관되어 있는 보안 프로세스 서술자가 발생될 수 있는지가 판정될 수 있고(단계(819)), 기입이 행해진 캐시 라인(846)을 포함하는 페이지(842)와 관련하여 데이터 캐시(840)에 저장될 수 있다(단계(821)). 유의할 점은, 이러한 보안 프로세스 서술자가 이전에 페이지와 연관되어 있지 않은 경우에만(단계(823)) 이 단계들이 행해질 수 있다는 것이다.
하나의 실시예에서, 실행 중인 프로세스에 대한 보안 서술자는 현재 프로세스에 의해 실행되고 있는 코드 블록을 검증하는 데 사용되는 허가 코드일 수 있다. 이 허가 코드는 보안 실행 제어기(820)의 허가 코드 레지스터(812)에 존재할 수 있다. 이와 같이, 허가 코드 레지스터(812) 내의 허가 코드는 기입이 행해진 캐시 라인(846)을 포함하는 페이지(842)와 연관되어 있는 데이터 캐시(840)의 보안 서술자 영역(844)에 저장될 수 있다. 예시되어 있는 예에서, 허가 코드 레지스터(812) 내의 허가 코드는 캐시 라인(846a)을 포함하는 페이지(842a)와 연관되어 있는 보안 서술자 영역(844a)에 저장된다.
도 13을 보면, 보안 모드 제어기 상태 기계에 의해 수신된 메모리 액세스가 데이터 캐시(840)에 이전에 저장되었던(단계(805)) 데이터의 판독인 경우(단계(803))(예컨대, 캐시 히트), 액세스되고 있는 캐시 라인(846)과 연관되어 있는 보안 비트(848)가 세트되어 있는지가 판정될 수 있다(단계(823)). 보안 비트가 세트되어 있지 않은 경우(단계(823)), 데이터 캐시(840)로부터의 판독이 허용될 수 있다(단계(825)).
계속하여 도 14로 가면, 액세스되고 있는 캐시 라인(846)과 연관되어 있는 보안 비트(848)가 세트되어 있는 경우(단계(823)), 액세스되고 있는 캐시 라인(846)의 페이지(842)와 연관되어 있는 보안 프로세스 서술자가 액세스된 캐시 라인(846)을 포함하는 페이지(842)와 연관되어 있는 보안 프로세스 서술자 영역(844)으로부터 획득될 수 있다(단계(825)). 프로세스와 연관되어 있는 보안 프로세스 서술자가 이어서 획득될 수 있고(단계(827)), 이어서 이 보안 서술자들이 동일한지가 판정될 수 있다(단계(829)).
논의된 바와 같이, 실행 중인 프로세스에 대한 보안 프로세스 서술자는 보안 실행 제어기(820)의 허가 코드 레지스터(812)에 존재하는 허가 코드이거나 그의 어떤 파생 값일 수 있다. 이와 같이, 액세스된 캐시 라인(846)을 포함하는 페이지(842)와 연관되어 있는 보안 프로세스 서술자 영역(844)으로부터 획득된 보안 프로세스 서술자가 보안 실행 제어기(820)의 하드웨어 비교 블록(814)에 제공될 수 있고, 여기에서 허가 코드 레지스터(812)에 존재하는 허가 코드 또는 그의 어떤 파생 값과 비교된다. 예시된 예에서, 캐시 라인(846a)을 포함하는 페이지(842a)와 연관되어 있는 보안 프로세스 서술자 영역(844a) 내의 보안 프로세스 서술자가 하드웨어 비교 블록(814)에 제공되었고, 여기에서 허가 코드 레지스터(812)에 존재하는 허가 코드 또는 그의 어떤 파생 값과 비교된다. 보안 프로세스 서술자들이 매칭되는 경우, 판독이 허용될 수 있고(단계(831)), 그렇지 않은 경우, 판독이 허용되지 않을 수 있으며(단계(833)) 다른 동작이 취해질 수 있다. 이러한 다른 동작들의 예들은 가비지 또는 고정된 값을 제공하는 것, 캐시 미스를 나타내는 것 등일 수 있다.
실시예들이, 앞서 논의된 바와 같이, 허가 코드를 보안 모드로 실행 중인 프로세스에 대한 보안 프로세스 서술자로서 사용하는 것과 관련하여 예시되어 있지만, (예컨대, 대상의 비밀 키를 사용하여) 거의 모든 원하는 프리커서들로부터 발생된 거의 모든 유형의 복합 키가 사용될 수 있다. 이러한 경우들에서, 예를 들어, 보안 실행 제어기(820)의 하드웨어 해시 블록을 비롯한 보안 실행 제어기의 다른 블록들은 이러한 보안 프로세스 서술자의 발생 또는 비교에 관여되어 있을 수 있다.
특정의 경우들에서, 데이터 캐시 외부에의 기입들이 허용되지 않을 수 있는 동안, 보안 프로세스의 작업 세트가 데이터 캐시를 오버플로우할 수 있다. 하나의 실시예에서, 보안 프로세스(예를 들어, 페이징 아웃 동작 등을 포함함)의 실행 동안 CPU 실행 유닛과 외부 메모리 버스 사이의 임의의 외부 데이터 트랜잭션들이 암호화될 수 있다. 이러한 암호화 프로세스에 대해, 보안 프로세스 서술자 자체 또는 그의 어떤 파생 값이 키로서 사용될 수 있고, 그 보안 프로세스 서술자 또는 파생 값 자체가 (예컨대, 대상 디바이스의 비밀 키의 파생 값을 사용하여) 암호화되고 데이터 세트의 일부로서 메인 메모리에 저장될 수 있다. 한 장점으로서, 이 메커니즘을 구현하는 데 필요한 구조적 변경이 실질적으로 그다지 없을 수 있다. 보안 프로세스가 큰 작업 세트를 가지며 빈번히 인터럽트되는 경우에 가장 중요한 영향은 성능에 관한 것이다. 이러한 실시예들에서, "안전한" 것으로 간주되는 프로세스의 작업 세트의 서브셋이 생성될 수 있고, 그 "안전한" 작업 세트에 대응하는 캐시의 그 부분만이 메인 메모리에 기입될 때 암호화될 수 있다.
그렇지만, 보안이 가장 중요한 관심사이고 보안 코드 블록들의 작업 세트들이 클 수 있는 시스템에서, 메모리 버스에 놓이는 시점 이전에, 작업 세트 전체가 암호화될 수 있다. 이러한 경우에, 메인 메모리에의 저장은 다른 프로세스(예컨대, 통합된 하드웨어 가속 암호화를 갖는 DMA 유닛)와 병렬로 비동기적으로 실행될 수 있고, 따라서 성능에 최소한의 영향을 미치도록 설계될 수 있을 것이다. 어떤 실시예들에서, 작업 세트 데이터가 메인 메모리에 기입될 수 있게 하기 전에 암호화를 수행하기 위해, 별도의 "작업 세트 캡슐화" 루틴(그 자체가 보안 모드로 실행하도록 설계된 보안 코드 블록일 수 있음)이 사용될 수 있다. 다시 말하지만, 이 메커니즘을 거의 모든 기존의 CPU에 통합시키기 위해, 있더라도 최소한의 변경들이 필요할 수 있다.
어떤 실시예들에서, 메인 메모리에 저장되는 페이지(들) 또는 캐시 라인들의 암호화를 수행하는 데 사용되는 키는 허가 코드의 파생물일 수 있다. 구체적으로는, 하나의 실시예에서, 메인 메모리에 저장되고 있는 페이지들을 갖는 보안 모드로 실행 중인 프로세스에 대한 허가 코드가 디바이스의 비밀 키 및 다른 프리커서를 사용하는 하드웨어 해시 블록을 사용하여 복합 키(예컨대, 메시지 허가 코드)를 발생시키는 데 사용될 수 있다. 얻어진 복합 키 자체는 단기 키(ephemeral key)를 발생시키기 위해 허가 코드를 암호화하는 데 사용될 수 있다. 이 단기 키는 메인 메모리에 저장될 데이터 캐시의 페이지를 암호화하는 데 사용될 수 있고, 이는 이어서 복합 키를 발생시키는 데 사용되는 허가 코드 및 프리커서와 함께 메인 메모리에 저장된다.
거의 모든 대칭 암호화 메커니즘이 메인 메모리에 저장되는 페이지들을 암호화하는 데 이용될 수 있다. 예를 들어, 하드웨어 암호화 블록(예컨대, AES 하드웨어 블록)이 이용될 수 있다. 그에 부가하여, 이 암호화가 보안 모드로 실행 중인 암호화 코드에 의해 달성될 수 있다. 이러한 경우들에서, 이 암호화 코드는 보안 모드로 실행되었던 다른 프로세스와 연관되어 있는 데이터 캐시의 캐시 라인들 또는 페이지들(예컨대, 암호화되어야 하는 캐시 내의 데이터)에 액세스할 필요가 있을 수 있다. 그 캐시 라인들의 암호화를 달성하도록 이러한 암호화 프로세스에 의한 이러한 액세스를 허용하기 위해 하나의 실시예에서, 암호화 프로세스는 호출 인수의 파생물을 그의 암호화 키로서 사용할 수 있다. 이러한 파생물은, 예를 들어, 비밀 키 및 어떤 다른 데이터(앞서 기술한 바와 같이, 부모 또는 자식 루틴의 보안 프로세스 서술자 등)와 함께 호출 인수를 사용하여 발생되었을 수 있는 하드웨어 해시의 출력(예컨대, 메시지 인증 코드)일 수 있다. 이와 같이, 암호화 프로세스에 의해 데이터를 암호화 또는 복호화하는 데 사용되는 실제의 키는 전달된 키의 파생물일 수 있지만, 단일의 보안 프로세스에 의해서만 정확히 발생될 수 있는 것일 수 있다. 입력/출력 인수 트랜잭션에 직접 관여된 것들을 제외한 보안 프로세스의 입력 또는 출력 인수들 중 어느 것도 임의의 다른 프로세스들(보안 프로세스 또는 기타 프로세스)에 노출시키는 일 없이, 암호화된 페이지들이 이어서 메인 메모리에 저장될 수 있다.
디지털 보안의 특정의 측면들을 논의하는 것이 이제 도움이 될 수 있다. 디지털 보안 알고리즘들에서의 최신의 공지 기술들은 온라인 정보의 조사를 통해 또는 이 주제를 다루고 있는 다양한 간행물들 및 특허들을 통해 즉각 입수될 수 있고, 그의 보다 최근의 것들 중 일부는 미국 특허 제6,327,652호; 미국 특허 제6,1930,670호; 미국 특허 제6,412,070호; 미국 특허 공개 제20020013772호; 미국 특허 제6,226,742호; 미국 특허 제6,101,605호; 그리고 David Lie 등의 "Architectural Support for Copy and Tamper-Resistant Software" (Proceedings of the 9th Annual Conference on Architectural Support for Programming Languages and Operating Systems aka ASPLOS-IX, Cambridge, MA. 2000)를 포함하고, 이들 모두는 참조 문헌으로서 본 명세서에 완전히 포함된다.
종래 기술의 시스템들은 디지털 데이터 암호화 및 복호화 기술들의 몇가지 기본 동작 카테고리들을 이용한다. 이 카테고리들은 보안 알고리즘들 자체의 사용에 기초하고 있으며, 실제의 데이터를 암호화 또는 복호화하는 실제의 메커니즘에 독립적이다. 이 공지된 기술들 및 광범위하게 기술된 분류들 및 기술들은 다음과 같다:
단방향 해싱 메커니즘들 및/또는 메시지 다이제스트들.
메시지 인증 시스템들
디지털 서명들
비밀 키 암호화 시스템들
공개 키 암호화 시스템들
주어진 보안 시스템에서 이 기술들이 사용되는 수단은 보안 프로토콜이라고 한다. 유의할 점은, 보안 프로토콜이 다양한 기능들이 어떻게 구현되는지의 실제의 기본 역학 관계에 독립적이라는 것이다. 그에 따라, 심지어 완벽하게 안전한 암호화 알고리즘이 어쩌면 암호화 기술 자체의 보안 측면을 무력화시키는 방식으로 전체적인 보안을 손상시키는 보안 프로토콜 내에서 사용될 수 있다. 그 결과, 임의의 주어진 보안 시스템의 전체적인 보안이 기본 보안 기술들의 상대적 강점은 물론 이 보안 기술들이 사용되는 방식에도 의존하고 있다. 보안 시스템을 구현하려는 종래의 시도들은 보호될 다양한 유형의 비트스트림들을 (인위적으로) 구분하였다. 기본 레벨에서, 모든 이진 디지털 데이터가 그 비트스트림의 의도된 목적 또는 해석에 완전히 독립적인 방식으로 저장 및 검색될 수 있는 1과 0의 스트림(비트스트림)으로 될 수 있다. 임의의 특정의 비트스트림에 포함되어 있는 데이터가 텍스트 또는 사진 또는 심지어 실행가능 오브젝트 코드를 전달하는 데 사용된다는 사실이 비트스트림이 저장되는 방식 또는 비트스트림이 저장되어 있는 디바이스에 관련이 없다.
이와 같이, 디지털 데이터 유형들 간의 임의적인 구분에 의존하지 않는 보안 프로토콜들이 필요하다. 디지털 콘텐츠를 더 잘 그리고 더 효율적으로 보호하기 위해 산업 표준 보안 기술들 및 다른 유형들의 보안 표준들을 이용할 수 있는 이 프로토콜들은 그 자체가 디지털 비트스트림으로 표현될 수 있다. 이와 같이, 이러한 프로토콜은 그 자신을 똑같이 보호할 수 있을 것이다. 이러한 자기 참조 거동은 "재귀(recursion)"라는 특성으로 알려져 있고, 이러한 보안 프로토콜은 "재귀적 보안 프로토콜"이라고 할 수 있다.
이제 디지털 콘텐츠를 보호하도록 되어 있는 보안 프로토콜들에 대한 시스템들 및 방법들을 살펴본다. 이 보안 프로토콜들은 임의의 디지털 콘텐츠에 대해 사용가능하고, 또한 실제의 디지털 콘텐츠가 변경될 필요 없이 종래의 워터마킹 방식과 통상적으로 연관되어 있는 ID 추적(identity tracing)의 개념을 지원할 수 있다. 이 프로토콜들이 모든 디지털 비트스트림들이 똑같다는 전제에 기초하기 때문에, 이는 심지어 프로토콜 자체에 대한 업데이트들에의 액세스를 제어하기 위해 재귀적 방식으로 사용될 수 있다. 환언하면, 프로토콜은, 데이터가 보호될 미디어 스트림들이든, 그 스트림들을 재생하는 데 필요한 실행가능 코드이든, 그 스트림들을 재생하는 데 필요한 암호화된 실행가능 코드이든, 그 스트림들을 재생하는 데 필요한 암호화된 코드를 복호화하는 데 필요한 실행가능 코드이든, 복호화 코드와 함께 사용될 키들 등이든 간에, 디지털 데이터의 유형들을 구분하지 않는다. 이들 데이터의 디지털 속성이 프로토콜에 중요한 모든 것이다. 이와 같이, 디지털 데이터의 속성 및/또는 사용이 보안 프로토콜에게 중요한 것이 아니기 때문에, 프로토콜은 그 자신을 보호할 수 있다.
이 능력은 심지어 실행 동안에도 보안 프로토콜이 실행되고 있는 하드웨어에 대한 어떤 변경도 필요로 함이 없이 (예를 들어, 최근에 발견된 보안 구멍들을 수정하기 위해) 보안 프로토콜이 업데이트될 수 있다는 것을 의미한다. "이전의" 보안 시스템이 새로운 보안 시스템의 일부로서 "포함"되어 있다(즉, 새로운, 어쩌면 더 안전한 레벨의 보호를 전체 시스템에 추가하기 위해 이전의 보호 "래퍼(wrapper)"를 제거할 필요가 결코 없음). 이와 같이, 전체 시스템이 가장 최근의 가장 안전한 암호화 및/또는 액세스 제어 시스템에 캡슐화되어 있다. 새로운 키들이 추가될 수 있을 뿐만 아니라, 완전히 새로운 보안 및/또는 암호화 알고리즘들이 또한 기존의 시스템들의 상단에 추가될 수 있다.
이 유연성은 프로토콜이 시간 제한된 임대(Time-limited Rental), 유료 방송(Pay-per-View), 다중 버저닝(Multiple Versioning), 기계 의존적 라이센스 취소(Machine-dependent License Revocation), 및 하나의 사용자로부터 다른 사용자로의 소유권 영구 이전을 비롯한 다수의 사업 모델들을 지원할 수 있게 한다.
한 예시적인 실시예에서, 저작권 보호를 받는 소프트웨어 응용 프로그램이 이용되지만, 당업자라면 동일한 방법들 및 시스템들이 텍스트, 비디오 및 오디오 데이터, 소스 및 오브젝트 코드 등을 비롯한 임의의 비트스트림에 보안을 제공하는 데 사용될 수 있다는 것을 잘 알 것이다.
보안 프로토콜의 실시예들이 제공하도록 설계되어 있는 기본 기능들은 다음과 같은 것들(이들로 제한되지 않음)을 포함한다:
공정한 사용("시간 천이", "공간 천이" 및 보관 백업)
증분적 업그레이드(Incremental Upgrade)
소유권의 일시적 이전
소유권의 영구적 이전
시간 제한된 액세스
사용 제한된 액세스(사용된 횟수)
디바이스 관련 라이센스 취소
데이터 또는 스트림 관련 라이센스 취소
많은 보안 시스템들에 대해, 저작권 보호를 받는 저작물에 포함된 지적 재산권의 보호를 위한 주된 메커니즘들 중 하나는 간단한 액세스 제어이다. 그렇지만, 이러한 메커니즘이 우회되는 경우, 심지어 가장 세련된 액세스 제어 메커니즘에 의해 제공되는 보호가 거의 가치가 없다. 이것은 액세스 제어가 쓸모없는 메커니즘이라는 것을 말하는 것이 아니라, 단순히 그것 자체로 완전한 보안 시스템이 아니라는 것을 말하는 것이다. 다수의 저작권 보호를 받는 미디어 스트림들이 인터넷을 통한 공개적인 소비에 자유롭게 이용가능하다는 사실은 이러한 보안 시스템들이 거의 항상 우회될 수 있다는 사실에 대한 증거이다. 이러한 종류의 액세스 제어는 또한, 원본이 파괴될 위험이 있는 경우에 필요한 것인, 합법적으로 구매한 저작권 보호를 받는 저작물의 백업 사본들을 만드는 메커니즘을 확립하는 것을 더 어렵게 만든다. 이와 같이, 본 명세서에 기술되어 있는 보안 프로토콜은 그를 유용하게 만들기 위해 어떤 종류의 액세스 제어 시스템도 필요로 하지 않는다.
기술된 보안 프로토콜들은, 저작물 자체를 이루고 있는 디지털 데이터가 아니라, 저작권 보호를 받는 저작물을 표현하는 것을 통제하는 것에 중점을 두고 있다. 그에 따라, 프로토콜은 저작권 보호를 받는 저작물을 캡슐화하는 데 사용되는 디지털 데이터 또는 그 저작물이 어떻게 해석되어야 하는지를 나타내는 데 사용되는 다른 디지털 데이터를 구별하지 않는다. 그 결과로서, 프로토콜은 심지어 다른 보안 프로토콜들을 캡슐화하는 데 사용될 수 있다.
기본 동작 설명:
보안 프로토콜의 실시예들은 소프트웨어의 저작자가 그의 코드가 그의 알고리즘을 복사하거나 다른 방식으로 유용하려고 하는 자에 의한 분해(disassembly)로부터 보호된다는 높은 정도의 확신을 가질 수 있게 하도록 설계되어 있다. 이들은 또한 이 코드를 그의 기능을 변경하려고 시도하는 자에 의한 수정으로부터 보호하도록 설계되어 있다. 이 주된 특성들이 기타 범용 컴퓨팅 시스템에서 구현될 수 있는 방법들 중 하나가 이하의 섹션에서 논의된다. 이 2개의 주된 기능들의 부산물로서 일어나는 부가의 특성은 소프트웨어가 실행될 수 있는 조건들(즉, 코드가 언제, 어떻게 그리고 어느 기계 또는 기계들에서 실행될 수 있는지)을 제어할 수 있다는 것이다. 이들 기능 중 제1 기능은 변조 방지 타이머 요소를 시스템에 부가하는 것에 의해 달성될 수 있다. 다른 것들은 문제의 코드 블록을 실행하기 위해 충족되어야만 하는 원하는 조건들을 나타내는 데 사용되는 보안 데이터 구조를 구현하는 것에 의해 달성된다. 이 데이터 구조가 하드웨어에 특유한 것이 아니기 때문에, 이 데이터 구조는 각종의 방식들로 사용될 수 있고, 그를 해석하는 데 사용되는 소프트웨어를 업데이트하는 것에 의해 수정될 수 있다. 프로토콜을 보다 효율적으로 구현하는 데 이용되는 하드웨어 관련 특징들이 논의되고, 프로토콜을 지원하기 위해 이 특징들이 어떻게 사용될 수 있는지의 예들이 주어져 있다. 마지막으로, 저작권 보호를 받는 저작물을 보호하기 위해 프로토콜이 어떻게 사용될 수 있는지를 보여줄 것이다.
보안 프로토콜의 실시예들은 그의 의도된 수신자에 의해서만 복호화될 수 있게 하는 방식으로 디지털 비트스트림을 암호화할 수 있는 것에 의존하고 있다. 이것은 잘 알려진 문제이고, 많은 수의 산업 표준 암호화 알고리즘들의 기초이다. 그렇지만, 보안 프로토콜의 실시예들에서 사용하기 위해 고려되어야만 하는 다음과 같은 2가지 부가의 인자들이 있다: 프로토콜의 핵심이 전형적인 온칩 명령어 캐시(I-캐시)의 (비교적) 작은 범위에서 적합할 수 있는 경우에 그것이 도움이 된다는 사실 및 그것이 반자율적 방식으로 실행될 수 있다는 사실. 환언하면, 프로토콜이 작고 보통의 매일의 동작을 위해 중앙 보안 서버를 필요로 하지 않는다면 유용하다.
하드웨어:
이 보안 프로토콜을 실행할 수 있는 디바이스의 한 예시적인 전체 블록도가 상기 2에 도시되어 있다.
동작 상세:
보안 프로토콜의 실시예들이 동작하는 방식은 다음과 같은 몇개의 개별적인 프로세스들로 분해될 수 있다: 시스템 초기화, 보안 코드 발생 및 대량 배포, 보안 코드 로딩 및 실행, 키 목록 데이터 구조 구성, 일시적 라이센스 이전, 영구적 라이센스 이전, 시스템 소유권 이전, 라이센스 취소 및 보안 시스템 업데이트. 이들 각각이 차례로 논의된다. 그렇지만, 유의할 점은, 이하에서 기술되는 예들은 논의의 간략함을 위해 선택되고, 이 프로토콜이 구현될 수 있는 꼭 가장 효율적인 방식일 필요는 없다(유일한 방식은 아님).
시스템 초기화
이것은 대상 유닛의 비밀 키들(104)이 어떤 초기 값으로 설정되는 단계이다. 이 절차는 (2개의 비밀 키들 중 어느 하나에 대해) 몇개의 장소들 중 하나에서 달성될 수 있지만, 논리적 이유들로 인해, 이는 일련 번호 또는 비밀 키가 어쩌면 변경될 수 있는 조립 공정에서의 최종 단계이어야만 한다. 유닛(100)의 일련 번호가 오프칩 저장되는 경우에, 이 절차는 최종 조립의 시점에서 수행될 가능성이 아주 많다 유닛에 대한 일련 번호(106)가 온칩 저장되는 경우, 임의의 제조후(post-production) 또는 번인(burn-in) 불량이 동작하지 않는 부품들을 가려낼 기회를 갖도록, 칩 제조 공정에서의 마지막 시점에서(즉, 칩이 패키징된 후에) 이 절차를 수행하는 것이 가장 현실적일 것이다. 이러한 방식으로, 안전하게 유지되어야만 하는 데이터의 양이 최소화된다. 전체 프로토콜의 보안이 유닛의 비밀 키들(104)의 보안에 기초할 수 있기 때문에, 물리적 보안이 가능한 시점에서 초기화 절차가 취해져야만 한다.
주 비밀 키가 보조 비밀 키를 제공하는 데 사용되는 것과 상이한 절차에서 초기화(또는 디바이스에 "버닝")되어야만 한다. 비록, 실제로는, 이 보조 키가 (제조 공정 동안 어떤 시점에서 유닛에 프로그램되기 때문에) 어떤 시점에서 알려질 것이지만, 그것이 대상 디바이스(100) 상에 저장되면 그와 연관되어 있는 유닛이 어디에도 기록되어서는 안된다. 감사(auditing)를 위해, (배포의 랜덤성에 대해 테스트하기 위해 또는 어떤 다른 이유로) 어느 부분들이 어느 키들을 보유하는지를 아는 것에 관계없이, 보조 비밀 키 값들의 전체 세트가 검사되는 것이 어쩌면 바람직할 수 있다. 그렇지만, 시스템의 보안 속성을 유지하기 위해, 이 제2 비밀 키를 유닛에 프로그램하는 디바이스가 보조 비밀 키를 제1 비밀 키 또는 대상 디바이스 일련 번호(106)와 연관시키는 어떤 수단도 결코 갖지 않는 것이 바람직하다. 또한, 이 비밀 키들 둘 다는 이후에 기술되는 이유들로 인해 변조 방지 방식으로 구현되어야만 한다. 이들 2개의 비밀 키들이 어느 순서로 초기화되는지는 중요하지 않다. 예시적인 실시예에서 기술되는 초기화 절차 이후에, 대상 디바이스의 일련 번호(106) 및 그의 연관된 주 비밀 키들이 동일 위치에 있는 유일한 장소는 라이센싱 기관에 있는 보안 서버이어야만 한다.
보안 코드 발생 및 대량 배포
도 21을 간략히 참조하면, 예시적인 시나리오에서, 개발자(2120)가 분해의 영향을 받지 않을 것이고 특정의 디바이스 상에서만 실행될 수 있는 이 프로토콜 하에서 실행될 응용 프로그램을 제작하고자 하는 것으로 가정하자. 각각의 등록된 개발자(2120)는 라이센싱 기관과 통신하는 데는 물론, 임의의 공개된 코드 블록 또는 다른 비트스트림을 인증하는 데 사용될 수 있는 서명된 메시지 인증 코드(Message Authentication Code) 또는 MAC(통상적으로 디지털 서명이라고 함)을 생성하는 데 사용하는 임의의 메시지들을 인증하는 데 사용되는 공개 키/개인 키 쌍을 가진다.
응용 프로그램은, 디버깅된 후에, 원래의 개발자에게만 알려져 있는 응용 프로그램 관련 암호화 알고리즘 및 키(들)를 사용하여 인코딩된다. 이 응용 프로그램 관련 알고리즘 및 키(들)가 대칭(비밀) 키 시스템 또는 비대칭(PKI) 키 기반 시스템 중 어느 하나일 수 있다. 개발자(2120)에 의해 그의 공개된 공개 키/개인 키 쌍의 개인 키를 사용하여 서명되는 MAC은 암호화된 코드 블록의 끝에 첨부된다(이와 같이 암호화된 코드 블록에 대한 명확한 디지털 서명을 형성함). 디지털 서명 또는 원래의 MAC 중 어느 하나 및 대응하는 코드 관련 ID 번호가 라이센싱 기관에 제공될 수 있다. 응용 프로그램 개발자(2120)는 또한 적절한 디코딩 키(들)를 또한 제공하기로 할 수 있다(이 결정의 트레이드오프에 대해서는 본 문서의 나중의 섹션에서 논의할 것임).
유의할 점은, 응용 프로그램 관련 알고리즘이 비대칭 암호화 시스템인 경우, 이는 서명된 메시지 인증 코드(디지털 서명)를 발생시키는 데 사용되는 동일한 공개된 PKI 키 쌍을 사용하여 암호화될 필요가 없다. 그렇지만, 코드 블록의 끝에 저장되는 MAC은 공지된 해싱 알고리즘을 사용하여 발생되어야만 하고, 또한 개발자의 공개된 공개 키들 중 하나를 사용하여 서명되어야만 한다(따라서 디지털 서명을 형성함). 이것은 대상이 기지의 해싱 함수 및 기지의 공개 키를 사용하여 MAC의 진위를 검증할 수 있게 한다.
이제 도 18로 가면, 모든 응용 프로그램 관련 암호화 키 데이터 구조(1810)는 (복호화 키 자체(1820)에 부가하여) 다수의 부가 필드들을 포함할 수 있다. 이 필드들 중 하나는 타임스탬프(1830) 및 연관된 마스크 값(1840)을 포함할 수 있다. 제2 필드는 "카운트다운 값"(1850)을 포함할 수 있다. 마스크 값(1840)은 키가 유효할 때를 판정하기 위해 다른 2개의 필드들(1830, 1850)과 관련하여 사용된다. 또한 유의할 점은, 정확히 몇개의 비트들이 필드들 각각에 할당되는지가 프로토콜과 관련이 없다는 것이다.
유의할 점은, 타임스탬프 값(1830)이 타임스탬프 마스크(1840) 필드에 저장되어 있는 비트 패턴에 따라 몇가지 방식들로 사용될 수 있다는 것이다. 타임스탬프 마스크(1840) 값은 개발자(2120)가 대상 유닛(100)의 현재 시간과의 비교를 수행할 때 무시되는 타임스탬프 숫자의 어떤 서브셋을 선택할 수 있게 한다. 그렇지만, 한 예로서, 타임스탬프 필드(1830)에 의해 지원되는 가장 작은 분해능이 1초인 것으로 가정하면, 타임스탬프 데이터(1830)의 하위 5 비트를 마스킹 제거함으로써, 타임스탬프 필드(1830)에 저장되어 있는 시간에 시작하여 약 32초 동안 사용될 때에만 유효한 특정의 키 데이터 구조(1810)가 발생될 수 있다. 보안 프로토콜의 전체 기능이 타임스탬프 필드(1830)의 최하위 비트의 실제 분해능에 의존하지 않는다.
마스크 필드(1840)와 연관되어 있는 다른 비트들이 있을 수 있고, 그 중 일부는 타임스탬프(1830)에 명시된 값 이전에 또는 그 이후에 키가 유효한지를 나타내는 데 사용될 수 있다 또 다른 마스크 필드(1840) 비트는 타임스탬프(1830)와 "카운트다운" 값들(1850)이 어떻게 연관되어 있는지를 나타내는 데 사용될 수 있다. 예를 들어, 응용 프로그램 개발자(2120)의 의도가 소프트웨어의 사용을, 특정의 날짜 및 시간 윈도우에 단순히 연계되는 것보다는, 특정의 날짜 이전 또는 그 이후 특정의 반복 횟수로 제한하는 것인 경우에 이것이 유용할 것이다. 물론, 이 조건들의 임의의 조합이 구성될 수 있고, 따라서 프로토콜이 이 점에서 아주 유연하다. 그에 부가하여, 키들의 몇개의 합법적 사본들이 원래의 대상 유닛(100)으로부터 다른 것들로 동시에 배포될 수 있는지와 같은 다른 특성들을 나타내기 위해 추가적인 플래그들이 이 데이터 구조에 포함될 수 있다. 예를 들어, 디지털 라이브러리에서 보는 바와 같이, 다중 사본 라이센스(multiple-copy license)가 요망되는 경우에 이것이 유용할 것이다.
암호화 프로세스의 하나의 실시예를 나타낸 흐름도는 도 19에서 볼 수 있다. 유의할 점은, (그 미디어 스트림을 해석하는 데 사용되는 복호화 명령어들과 같은) 디지털 미디어 스트림를 배포하는 데 사용되는 프로세스와 소프트웨어 응용 프로그램을 배포하는 데 사용되는 프로세스 간에 그다지 차이가 없다는 것이다. 어느 경우든지, 암호화된 코드 블록(들)(1910, 1920)을 배포하는 2가지 상이한 옵션들, 즉 온라인 서버를 통하는 것 또는 일련 번호가 부여되어 있는 디스크들(serialized discs)(표준 DVD 등)을 통하는 것이 있다. 후자의 경우에, 개발자(2120)는 이어서 대량 생산된 디스크들의 개개의 일련 번호들을 라이센싱 기관(2110)에 사전 등록하기로 할 수 있다(또는 그렇지 않을 수 있음). 그러한 경우, 일련 번호들이 이들을 버스트 커팅 영역(Burst Cutting Area)(DVD의 경우)에 버닝(burning)하는 것에 의해 또는 표준의 CD의 경우에 잉크젯 각인(ink-jet imprinting)에 의해 영구적으로 디스크들에 부착되어 있을 수 있을 것이다. 유의할 점은, 동일한 일련 번호가 대량 생산된 디스크들 모두에 복제될 것이기 때문에, 개발자(2120)가 이 일련 번호들을 CD 또는 DVD의 데이터 영역에 삽입할 수 없다는 것이다. 디스크의 일부가 대량 생산될 수 있고 다른 부분이 한번 기입되는 어떤 종류의 혼성 형식이 사용되는 경우, 이것은 개개의 일련 번호들을 갖는 디스크들을 배포하는 다른 잠재적인 방법일 것이다. 어쨋든, 기계 판독가능 일련 번호가 분명히 바람직한데, 그 이유는 등록 프로세스 동안 오류가 일어날 가능성이 더 적기 때문이다.
개발자(2120)가 미디어 일련 번호를 라이센싱 기관에 등록하지 않기로 하는 경우, 적절한 암호화 키(들)가 응용 프로그램 또는 미디어 스트림 파일들과 연관될 수 있는 어떤 다른 방식이 있을 수 있다. 이와 같이, 응용 프로그램 개발자(2120)는 코드 관련 ID 또는 연관된 미디어 일련 번호를 등록할 수 있다. 전자의 경우에, 응용 프로그램이 자유롭게 배포될 수 있다(즉, 특정의 릴리스 형식 및 미디어에 연계되어 있지 않음).
개별적인 일련 번호 메커니즘의 경우에, 최종 사용자의 프라이버시가 유지되는데, 그 이유는 라이센싱 기관(2110)이 어느 응용 프로그램(또는 미디어 스트림)이 어느 일련 번호(들)와 연관되어 있는지(그리고 어쩌면 그의 표시)를 알 필요가 없기 때문이다. 개발자(2120)가 응용 프로그램 ID(또는 미디어 스트림 ID)를 그의 연관된 키(들)와 함께 등록하는 경우에, 라이센싱 기관(2110)이 어느 응용 프로그램(들) 또는 미디어 스트림들이 특정의 최종 사용자의 "소유"인지를 아는 것이 가능하다. 다른 한편으로는, 이러한 프라이버시의 상실 가능성은 개발자(2120)가 물리 매체를 제조 및 배포할 필요가 없다는 부가된 편의성 및 비용 절감으로 상쇄된다. 유의할 점은 "물리 매체"라는 용어가 꼭 디스크를 의미하지는 않는다는 것이다. 이 기능이 또한 개별적인 일련 번호 스티커가 부착되어 있는 인쇄된 매뉴얼(또는 심지어 간단한 등록 양식)을 사용하는 것에 의해 달성될 수 있을 것이다. 필요한 모든 것은 개발자(2120)가 최종 사용자에게 제공되는 고유의 일련 번호를 갖는 어떤 대상물을 생성해야만 한다는 것이다. 이 일련 번호의 목적은 비트스트림 등록 번호로서 역할하는 것이다. 이하의 섹션에서는 프로토콜에서 이 일련 번호가 어떻게 사용되는지에 대해 논의할 것이다.
도 19에 도시된 예에서, 암호화된 소프트웨어 응용 프로그램(또는 미디어 스트림)(1910) 및 기계 의존적 복호화 소프트웨어(1930) 둘 다는 동일한 메커니즘을 사용하여 배포된다. 이렇게 해야만 하는 것 및 암호화된 코드 블록들(1910, 1930) 중 어느 하나 또는 둘 다가 온라인으로 또는 디스크를 찍어 내는 것에 의해 배포될 수 있는 것이 프로토콜의 요구사항은 아니다. 그렇지만, 유의할 점은, 디지털 미디어 스트림의 경우에, 미디어 스트림 자체는 몇 자리수만큼 2개의 블록들(1910, 1930) 중 큰 쪽일 가능성이 아주 많다. 이와 같이, 그 경우에, 적어도 이 블록을 대량 생산된 디스크 형식으로 배포하는 것이 가장 타당하다. 많은 경우들에서, 암호화된 동반 코드 블록(제1 블록을 어떻게 디코딩할지의 명령어들을 포함하는 것)은 물론 암호화된 주 코드 블록을 집어 넣을 충분한 공간이 이러한 디스크 상에 있을 수 있다. 또한 유의할 점은, 2개의 데이터 세트들 중 어느 것도 공개 후에 어떤 변경도 거치지 않을 가능성이 있고, 따라서 이들이 온라인으로 배포되어야만 한다는 기본 요구사항이 없다. 그에 따라, 이들 둘 다는 대량 생산된 디스크 기반 배포 메커니즘에 아주 적합하다. 이들 둘 다를 동일한 디스크 상에 가지는 것은 또한 하나를 다른 것과 명확한 방식으로 연관시키는 것을 더 쉽게 만든다.
보안 코드 로딩 및 실행
배포 메커니즘이 실제의 디스크를 통해 달성되는 경우에, 소비자는 종래의 소프트웨어 구입과 완전히 동일한 방식으로 응용 프로그램을 포함하는 디스크를 구입할 수 있다. 물론, 최종 사용자는 "대상" 유닛의 프로세서 상에서 수정되지 않은 채로 암호화된 코드 블록을 실행할 수 없을 것이다. 사용자가 그의 기계 상에서 응용 프로그램을 실행하려고 시도할 때, CPU(120)는 암호화된 소프트웨어 블록을 로드하고, 문제의 코드 블록이 정품인지를 검증하기 위해 소프트웨어 개발자의 공개 키와 함께 코드 블록의 끝에 저장된 디지털 서명("서명된" MAC)을 사용한다. 이것은 다른 범용 CPU(120)에 대한 제1 하드웨어 수정이 작동하기 시작할 수 있는 경우이다. 보안 코드의 이러한 블록을 로드하고 복호화하는 프로세스가 도 20에 도시되어 있다.
해싱 함수가 정확하게 계산되도록 하기 위해(그리고 발생된 메시지 다이제스트와 "실제" 메시지 다이제스트 간의 비교가 유효하도록 하기 위해), CPU(120)는 이 해싱 함수를 보안 방식으로 수행해야만 한다. 이와 같이, 해싱 함수가 디코더 유닛의 하드웨어에 의해 직접 발생되어야만 하거니 해싱 함수 자체가 "보안" 코드의 블록을 사용하여 계산되어야만 하며, 따라서 그의 동작이 다른 "비보안" 프로그램에 의해 변조될 수 없다.
유의할 점은, 소프트웨어 기반 해시 경우에, 보안 코드의 이 블록은 유닛(100)의 보안 시스템의 일부로서 간주되어야만 하고, 그에 따라, 유닛(100)과 라이센싱 기관(2110) 간의 보안 트랜잭션을 통해 플레이어로만 다운로드될 수 있다. 충분히 흥미로운 점은, "보안" 해싱 함수의 설정이 본 명세서에 기술되어 있는 동일한 보안 프로토콜들을 통해 달성될 수 있다는 것이다. 보안 시스템의 모든 측면들에 대한 이 재귀적 거동은 이 프로토콜의 소프트웨어 기반 버전이 그의 암호화/복호화 아키텍처에서 아주 유연하게(그리고 따라서 업데이트가능하게) 될 수 있다는 것이다.
메시지 다이제스트 계산이 하드웨어로 수정되는 경우, 어쩌면 어느 정도의 보안을 획득할 수 있고, 이것은 유연성을 대가로 하여 얻어진다. 해시 값을 발생시키기 위해 전용 하드웨어 블록이 사용되고, 이어서 칩이 제조된 후에 어떤 시점에서(또는 그의 구현에서 어떤 버그가 있는 경우) 해싱 알고리즘 내의 어떤 취약점이 발견되는 경우, 문제를 사후에 해결할 기회가 없다. 이는 프로세스를 가속시키기 위해 (프로그램가능 S-박스(S-Box) 구조와 같은) 소프트웨어 기반 해싱 함수의 어떤 종류의 하드웨어 가속을 사용할 수 없다는 것을 말하는 것이 아니다. 그렇지만, 그 경우에, 하드웨어는 아주 다양한 단방향 해싱 함수들을 지원하기 위해 이상적으로는 충분히 범용이어야만 한다.
그렇지만, 유의할 점은, 이 프로토콜의 보안은 궁극적으로 이 보안 코드 로딩 절차의 일부로서 제공되는 최하위 레벨 기능에 의존한다. 서명된 메시지 다이제스트와 같은 상위 레벨 기능을 생성하기 위해 (해싱 함수에서 사용되는 비밀 키 또는 원시 동작(primitive operation)과 같은) 하위 레벨 특징들이 상이한 방식들로 서로 결합될 수 있다. 차례로, 이 상위 레벨 기능 블록들은 ID 검증(identity verification)과 같은 훨씬 더 높은 레벨의 유틸리티들을 제공하는 데 사용된다. 보다 원시적인 계층들 상에 상위 레벨 기능들을 구축하는 이 프로세스는 "신뢰 체인"을 구축하는 것이라고 한다. 시스템의 유연성은 보안 관련 기능들이 수정될 수 있는 시점을 이 계층구조 내에서 가능한 한 낮게 두는 데 있다. 그렇지만, 어떤 시점에서, 이 체인이 기초하는 기본 원시 동작(들)은 속성이 원자적이어야만 한다(즉, 이것은 하드웨어로 구현되어야만 하는 최소 레벨의 기능이다). 하드웨어 입도(hardware granularity)의 이 시점의 정확한 선택은, 대부분의 경우, 구현 상세이고, 상기 조건들이 주어진 경우, 이 프로토콜의 전체적인 동작은 이 측면에 의존하지 않는다.
암호화된 코드 블록(1910)이 대상의 메모리 공간(110)에 로드되고, 메시지 다이제스트가 계산되면, 결과가 개발자의 공개 키를 갖는 암호화된 코드(1910)와 함께 저장되었던 디지털 서명(1940)을 복호화하는 것에 의해 계산되는 메시지 다이제스트와 비교된다. 이 둘이 일치하는 경우, 대상 유닛(100)은 암호화된 코드 블록(1910)이 정품이라는 것(또는 적어도 코드가 디지털 서명을 복호화하는 데 그의 공개 키가 사용된 개발자(2120)에 의해 배포되었다는 것)을 확신할 수 있다.
이 시점에서, 대상(100)은 이어서 최근에 검증된 암호화된 코드 블록과 함께 사용될, 복호화 키(들)의 사본을 요청하는 보안 메시지를 라이센싱 기관(2110)으로 송신한다. 라이센싱 기관과 보안 연결을 설정하는 것의 일부로서, 대상 유닛(100)은 임시 공개/개인 키 쌍(그의 공개 부분이 라이센싱 기관(2110) 서버에 제공됨)을 발생시킨다. 키 교환 절차의 상세는 공지되어 있으며, 이 논의에서 이것이 달성되는 정확한 메커니즘을 언급할 필요가 없다. 어쨋든, 유의할 점은, 대상 유닛(100)과 라이센싱 기관(2110)에 있는 중앙 서버 간의 전체 네트워크 트래픽이 적당히 작은 데이터 세트로 제한되는데, 그 이유는 그것이 2개의 키 전송들, 즉 코드 관련 ID 및 그와 함께 저장된 MAC으로 이루어져 있기 때문이다.
코드 관련 ID(260)가 라이센싱 기관(2110)이 인식하는 것인 것으로 가정하면, 응용 프로그램 저작자가 요청된 복호화 키(들)의 "평문" 사본을 라이센싱 기관(2110)에 이미 제공했는지에 따라 2가지 가능한 행동 방침이 있을 수 있다. 개발자(2120)가 라이센싱 기관(2110)에 이러한 정보를 제공하지 않은 경우에, 중앙 서버가 대상 디바이스의 임시 공개 키의 사본(은 물론 문제의 코드 관련 ID(260))을 응용 프로그램 개발자의 서버로 전송한다. 그 시점에서, 개발자의 서버는 요청된 복호화 키(들)(대상의 임시 공개 키로 암호화되어 있음) 및 적절히 복호화된 코드로부터 발생된 메시지 다이제스트를 포함하는 메시지로 라이센싱 기관(2110) 서버에 응답한다. 이러한 방식으로, 대상 디바이스(100)만이 응용 프로그램 관련 복호화 키(들)를 획득하기 위해 메시지를 복호화할 수 있고, 라이센싱 기관(2110)은 평문 형태의 복호화 키(들)에 액세스하지 않을 것이다.
메시지 다이제스트가 사전 계산되고 라이센싱 기관의 서버에 저장될 수 있지만, 그것이 트랜잭션 동안 개발자(2120)에 의해 제공될 수 있다는 사실이 해싱 함수가 변해야만 하는 경우 사용될 수 있다. 이것이 일어나는 경우, 개발자(2120)는, 대상 디바이스(100)와의 실제 트랜잭션 이전에 또는 그 동안에, 복호화된 코드 메시지 다이제스트의 업데이트된 버전을 라이센싱 기관(2110)에 제공할 필요가 있다. 라이센싱 기관(2110)이 원래의 (복호화된) 코드에 결코 액세스해서는 안되기 때문에, 개발자(2120)가 이 정보를 제공해야만 한다. 이전과 같이, 라이센싱 기관의 서버와 개발자의 서버 간의 네트워크 트래픽의 양이 여전히 아주 작다. 개발자(2120)로부터 수신된 암호화된 키는 이어서 라이센싱 기관(2110)으로부터 대상으로의 전송 이전에 또다시 대상 디바이스의 주 비밀 키로 암호화된다. 이 두번째 암호화는 실제로는 개발자측에서 다른 트랜잭션의 일부로서 수행될 수 있을 것이지만, 그 경우에, 개발자는 (이들 키 둘 다가 어떻게든 결합되어 있지 않는 한) 어쩌면 대상 유닛의 주 키에 액세스할 것이며, 이는 최종 사용자에 대한 잠재적인 프라이버시 상실 문제를 야기할 것이다.
유의할 점은, 응용 프로그램 개발자(2120)가 라이센싱 기관(2110)과 대상 디바이스(100) 사이의 트랜잭션들에 대해 "소외된(out of the loop)" 채로 있기를 원하는 경우에, 그들은 단순히 평문(암호화되지 않은) 형태로 되어 있는 관련 복호화 키(들)의 사본 및 복호화된 코드 블록에 대한 연관된 MAC(해싱 알고리즘이 변경될 때마다 그의 값이 업데이트되어야만 함)을 라이센싱 기관(2110)에 제공할 수 있다. 이와 같이, 라이센싱 기관(2110)에 있는 중앙 서버는 자율적으로 동작할 수 있고, 대상 유닛(100)으로부터의 키 요청을 이행하기 위해 개발자의 서버로의 통신 링크를 설정할 필요가 없을 것이다. 그렇지만, 이 "평문 키" 정보가 라이센싱 기관에 의해 의도적으로 또는 비의도적으로 손상되는 경우, 이것은 개발자에게 잠재적인 보안 위험을 야기한다.
키 암호화/복호화 프로세스 전체에 대한 흐름도가 도 21에 개략적으로 나타내어져 있다. 이 경우에, 평문 키는 여전히 (상기와 같이) 전송 이전에 대상 디바이스의 임시 공개 키로 그리고 이어서 대상의 주 비밀 키로 재차 암호화될 것이다. 이 시점에서, 대상 디바이스(100)는 이중 암호화된 형식으로 된 적절한 복호화 키를 가진다. 라이센싱 기관(2110)이 평문으로 되어 있는 응용 프로그램 관련 키(2150) 정보에 액세스하지 않는 경우, 의도된 대상 디바이스(100) 이외의 임의의 자가 이 키 데이터를 평문 형태로 재생할 수 없을 것인데, 그 이유는 각각의 유닛(100)에 대한 비밀 키는 라이센싱 기관(2110)만이 알고 있어야만 하고 전송을 위한 개인 키는 대상(100)만이 알고 있기 때문이다.
그렇지만, 이 시점에서, 대상(100)이 응용 프로그램 개발자(2120)로부터 수신하는 인코딩된 복호화 키(들)는 아직 공개되어 대상(100)에(예컨대, 플래시 ROM에 또는 하드 드라이브에 백업됨) 안전하게 저장될 수 없다. 문제는 대상 디바이스(100)가 또한 라이센싱 기관(2110)으로부터 전송되었던 인코딩된 복호화 키(들)와 함께 임시 개인 키의 사본을 저장해야만 한다는 것이다. 라이센싱 기관(2110)에 있는 누군가가 어떤 수단에 의해 이들 2개의 데이터에 액세스할 수 있는 경우, (이들이 대상 디바이스(100)의 주 비밀 키에도 액세스할 수 있기만 하다면) 이들은 복호화된 응용 프로그램 관련 키(2150)를 어쩌면 재구성할 수 있을 것이다.
이것이 대상 디바이스의 보조 비밀 키가 사용되는 시점이다. 이 보조 비밀 키가 대상 유닛의 복호화 유닛 이외의 누구에게도 알려져 있지 않다는 것을 상기한다. 이와 같이, 임시 개인 키가 라이센싱 기관으로부터 대상(100)에 제공된 그 키를 복호화하기 위해 사용되면, 그의 사용(및/또는 보관) 이전에 응용 프로그램 관련 키를 재암호화하기 위해 보조 비밀 키가 사용된다.
대상은 이어서 코드 블록(또는 미디어 스트림)을 복호화하기 위해 응용 프로그램 관련 (평문) 키(2150)를 사용할 수 있다. 이와 같이, 응용 프로그램 코드가 평문 형태로 존재하는 유일한 2개의 장소는 원래의 개발자(2120) 자체 및 대상 디바이스의 I-캐시(110)의 "보안" 부분 내부이다(여기에서 단지 실행될 수 있고 메모리에 평문 형태로 결코 라이트백될 수 없음). 이것은 사용자와 라이센싱 기관(2110) 사이의 프라이버시를 가능하게 한다. 환언하면, 라이센싱 기관(2110)은 사용자가 무엇에 대해 라이센스를 가지고 있는지를 알 필요가 없지만(엄청난 프라이버시 문제), 사용자의 유닛(100)이 손상 또는 도난되거나 다른 방식으로 동작하지 않게 되는 경우에, 여전히 사용자의 키 목록에 대한 보관소(또는 백업)로서 역할할 수 있다.
복호화 프로세스가 올바르게 수행되었는지를 검증하는 검사로서, 적절히 복호화된 코드의 메시지 다이제스트가 이어서 원래의 개발자(2120)로부터 라이센싱 기관(2110)을 통해 대상 유닛(100)으로 포워딩되었던 디지털 서명을 복호화하는 것에 의해 발생된 메시지 다이제스트와 비교된다. 앞서 언급한 바와 같이, 이 디지털 서명은 암호화되지 않은 코드 블록의 메시지 다이제스트를 응용 프로그램 개발자의 개인 키로 암호화하는 것에 의해 생성된다. 다른 대안으로서, 이 디지털 서명은 또한 연결이 설정되었을 때 라이센싱 기관(2110)에 제공되었던 다른 임시 공개 키(2130)를 사용하여 개발자(2120)에 의해 재차 암호화될 수 있다. 어쨋든, 정확한 메시지 다이제스트가 이어서 디지털 서명을 개발자의 공개 키로 복호화함으로써 대상 디바이스(100)에 의해 디코딩될 수 있다. 이 메시지 다이제스트가 복호화된 코드 블록의 MAC와 일치하는 경우, 이 코드는 정품인 것으로 간주되고, 대상(100)에서 실행되도록 허용된다. 이 메시지 다이제스트는 이어서 재암호화된 응용 프로그램 관련 키(2150)와 함께 보관을 위해 대상 유닛의 보조 키(2140)로 재암호화될 수 있다.
이 절차에서의 마지막 단계는 응용 프로그램 관련 키(2160)의 (대상 디바이스의 보조 키(2140)로) 새로 암호화된 버전이 보관을 위해 다시 라이센싱 기관(2110) 서버로 재전송되는 것이다. 이 전송은 몇가지 목적을 이룬다. 첫째, 이는 대상 디바이스(100)가 코드 블록을 적절히 복호화할 수 있었다는 확인 응답이다. 둘째, 최종 사용자가 어떤 종류의 파국적 데이터 장애를 겪고 그의 액세스 키의 그 자신의 백업 사본을 만들지 못한 경우를 취급하기 위해 라이센싱 기관(2110)이 이 암호화된 키(2160)의 사본을 가질 필요가 있다. 라이센싱 기관(2110)은 이어서 임의의 특정의 사용자에 대한 백업 저장 설비로서 역할할 수 있다. 이 절차에 대한 또 다른 이유는 특정의 대상 디바이스(100)가 하나의 사용자로부터 다른 사용자로 소유권을 변경하는 경우 또는 사용자가 그의 대상 디바이스(100)를 업그레이드하고자 하는 경우를 취급하기 위한 것이다. 이러한 종류의 소유권 영구 이전은 그 유닛(100)에 대한 라이센싱된 응용 프로그램 키들 모두의 이전을 수반할 수 있다(이 경우에, 유닛을 새로운 소유자의 이름으로 재등록하는 것 이외에 아무것도 할 필요가 없다). 그렇지만, 사용자가 그의 키 데이터의 영구적 소유권을 제1 디바이스로부터 제2 디바이스로 이전하고자 하는 경우, 이것은 라이센싱 기관(2110)과 대상 디바이스 둘 다 사이의 보안 트랜잭션에 의해 달성될 수 있다.
대상 디바이스(100)가 다시 라이센싱 기관(2110) 서버로 전송하는 다른 정보는 대상 디바이스의 새로 업데이트된 키 목록 데이터 구조(2210)의 메시지 다이제스트이다(도 22에 도시되어 있음). 이것은 새로 업데이트된 키 목록 데이터 구조(2210)의 확인 응답이기도 하고 또한 라이센싱 기관(2110) 서버 상의 그리고 대상 디바이스(100) 상의 그 특정의 대상 디바이스(100)와 연관되어 있는 키 목록 데이터 구조(2210)의 동등성을 검증하는 데 사용되기도 한다. 이 데이터 구조의 정확한 구성은 이하의 섹션에서 기술될 것이다. 특정의 키 또는 키들의 세트의 소유권 영구 이전이 달성되는 방법들에 대해서도 나중의 섹션에서 논의할 것이다.
이 시점에서 유의할 점은, 앞서 개략적으로 기술된 프로세스는 응용 프로그램 관련 키(2150)를 개발자(2120)로부터 대상 디바이스(100)로 전송하기 위해 프로세스가 사용될 수 있는 유일한 방식이 아니다. 예를 들어, 실제 키 전송 트랜잭션은 대상(100)과 응용 프로그램 개발자(2120) 사이의 직접 연결만을 수반할 수 있다. 그렇지만, 그 경우에, 디바이스 관련 암호화 정보를 트랜잭션에 제공하기 위해 개발자의 서버와 라이센싱 기관의 서버 사이에 연결이 설정되어야만 한다. 이 프로토콜이 보안 방식으로 동작할 수 있게 되는 다수의 메커니즘들이 있고, 앞서 논의된 예는 이들 중 하나에 불과하다. 그렇지만, 공통된 맥락은 대상(100)으로 전송되는 키 데이터가 그 대상 디바이스(100)에 대해서만 사용가능하도록 하기 위해 3명의 당사자 모두가 함께 동작해야만 한다는 것이다.
유의할 점은, 키의 구조가 2개의 단편들, 즉 하드웨어 관련 부분 및 응용 프로그램 관련 부분을 갖도록 설정될 수 있다는 것이다. 이 2개의 단편들이 완전히 불가분일 필요는 없다. 이들이 불가분인 경우, 앞서 논의된 바와 같은 특성들이 얻어진다. 그렇지만, 키 단편들을 독립적으로 동작가능하게 하는 방식이 있는 경우, 실제의 대상 디바이스(100)의 실제 코드에 독립적일 수 있는 전역적 사본 세트 및 사용 제한이 가능하게 될 수 있다. 환언하면, 임의의 개발자(2120)는 배포에 대한 어떤 제한도 갖지 않지만 판독될 수 없고 단지 실행될 수만 있었던 응용 프로그램 또는 미디어 스트림을 공개할 수 있다. 라이센싱 기관(2110)이 제조업체에 관계없이 모든 디바이스들 상에서 실행될 보안 시스템 업데이트를 송출하고자 하는 경우에 이것이 유용할 수 있을 것이다. 이것의 다른 예는 공개적으로 이용가능한 미디어 스트림의 저작권에 대한 통제를 유지하면서 그 스트림을 브로드캐스트하는 것이다. 이와 유사하게, 게시자는 누구라도 판독 및/또는 복사할 수 있지만 하나의 특정의 대상 디바이스(100) 또는 디바이스들의 세트에서만 실행되는 응용 프로그램을 배포할 수 있다. 이것은, 예를 들어, "이 특정의 부류의 디바이스를 업데이트하세요"라는 메시지를 송출하는 데 유용할 수 있을 것이다. 다른 가능한 응용은 모든 곳에서 실행되고 배포에 어떤 제한도 없는 응용 프로그램을 송출하는 것이다. 이것은 사실상 특정의 응용 프로그램에 대한 소스 코드를 공개하는 것(즉, 오픈 소스 배포)과 유사하다. 분리가능한 H/W 관련 및 S/W 관련 키 구조에 의해 가능하게 되는 다른 부류들의 보안이 표 1에 예시되어 있다.
분리가능한 하드웨어 관련 및 응용 프로그램 관련 키 구조
소프트웨어 또는 응용 프로그램 관련 키 세그먼트
"잠금됨"* "잠금 해제됨"**
하드웨어 관련 키 세그먼트 "잠금됨"* 제한된 동작은 물론 제한된 배포 비제한된 배포 그렇지만 지정된 유닛에서만 실행가능함(예컨대, 특정의 유닛을 대상으로 한 코드)
"잠금 해제됨"** 비제한된 배포 그렇지만 실행만 됨, 즉 코드가 "판독가능"하지 않음 동작 또는 배포에 관해 제한 없음(즉 공개적이고 개방적임)
*즉, 특정의 일련 번호로(또는 일정 범위의 숫자들로) 잠금됨
** 즉, 어느 곳에서나 동작함
키 목록 데이터 구조 구성
이제 도 22를 보면, 특정의 대상 디바이스(100)에 사용 허가되어 있는 응용 프로그램 또는 미디어 관련 키들의 목록을 포함하는 데이터 구조(2210)는 귀중한 것이고, 그에 따라, 소유자에 의해 백업될 수 있어야만 한다. 개별적인 키들이 (앞서 기술한 바와 같이) 대상의 보조 비밀 키로 암호화되기 때문에, 목록은 키들이 사용 허가되어 있는 유닛에게만 유용하다. 그렇지만, 이 데이터 구조(2210)가 변조, 오염 및/또는 완전한 손실로부터 안전하도록 할 수 있어야 한다. 상실된 키 목록 데이터 구조의 경우에, 앞서 기술한 바와 같이, 그 특정의 대상 디바이스(100)에 대한 키 목록의 새로운 사본을 라이센싱 기관(2110)에 요청함으로써 데이터 구조(2210) 전체가 복구될 수 있다. 키 목록 데이터 구조에 대한 일시적인 변경이 행해진 경우에(이러한 시나리오에 대한 이유는 이 섹션 이후의 섹션에서 논의할 것임), 프로토콜은 이러한 변화를 일시적인 것으로 식별하는 수단을 수용할 수 있다. 마지막으로, 키 목록 데이터 구조(2210)의 정품 여부, 적시성(timeliness) 및 유효성을 검증하기 위한 어떤 변조 방지 메커니즘을 포함한다.
이 요구사항들을 염두에 두고서, 도 22에 도시되는 것과 유사한 방식으로 이 특성들 모두를 나타내는 안전한 키 목록 데이터 구조(2210)를 구성할 수 있다. 언제나처럼, 도시된 예가 원하는 특성들 모두가 이러한 데이터 구조에 포함될 수 있는 유일한 방법은 아니다. 그럼에도 불구하고, 도 22에 예시되어 있는 특정의 데이터 구조는, 사실, 프로토콜의 기본 요구사항들 모두를 충족시킨다.
상기 도면에서 유의해야만 하는 몇가지 기본 지침들이 있다. 첫째는 키 목록 데이터 구조(2210)의 최상위 레벨 암호화가 대상 디바이스의 주 비밀 키로 수행되어야만 한다는 것이다. 이 특정의 키를 사용하는 몇가지 이유들이 있지만, 주된 문제는 이 데이터 구조의 로컬 사본이 복원되어야만 하는 경우에 라이센싱 기관(2110)이 대상 디바이스(100)에 독립하여 이 데이터 구조의 암호화된 형태를 재발생시킬 수 있어야만 한다는 것이다. 이 데이터 구조를 암호화하기 위해 (예를 들어, 대상의 보조 비밀 키와 같은) 임의의 다른 키가 사용되는 경우, (키가 목록에 부가되는 경우와 같이) 대상이 데이터 구조를 변경할 필요가 있을 때, 전체 목록이 백업을 위해 라이센싱 기관(2110)으로 전송되어야만 한다. 이것은 어쩌면 라이센싱 기관(2110)으로 다시 전송되어야만 하는 네트워크 트래픽의 양을 크게 증가시킬 수 있고, 꼭 채널 대역폭의 가장 효율적인 사용일 필요는 없다.
또한, 표준의 응용 프로그램 또는 미디어 스트림 관련 라이센스 키들의 저장을 위해 사용되는 것에 부가하여, 보안 시스템 관련 키들의 저장을 위해 이 키 목록 데이터 구조(2210)가 사용되는 것이 바람직하다. 이 데이터 구조가 라이센싱 기관(2110)에 의해 재발생될 수 있기 때문에, 대상 디바이스(100) 상에서 실행되는 보안 소프트웨어를 업데이트하는 것이 바람직한 경우에, 동일한 키 목록 데이터 구조(2210)가 이들 기능 둘 다에 대해 사용될 수 있는 경우, (대상 디바이스(100)에 대한 코드 저장 요구사항들의 관점에서 볼 때) 더 안전하기도 하고 더 효율적이기도 할 것이다.
두번째 문제는 키 목록 데이터 구조(2210)의 암호화된 버전이 원래의 키 목록 데이터 구조(2210)의 메시지 다이제스트를 포함한다는 것이다. 유의할 점은, 개개의 키들 각각이 암호화되지만, 메시지 다이제스트가 계산되는 시점에서 목록 자체의 다른 단편들이 개별적으로 암호화되지 않는다는 것이다. 메시지 다이제스트 계산 후에, (메시지 다이제스트를 포함하는) 키 목록 데이터 구조(2210) 전체가 이어서 최상위 레벨(또는 마스터) 키에 의해 식별되는 키 값 및 알고리즘으로 암호화된다. 악의적 제3자가 목록을 변조하는 것, 새로운 메시지 다이제스트를 계산하는 것 그리고 이어서 정품 목록을 수정된 목록으로 대체하지 못하게 하기 위해 이것이 행해진다. 키 목록 데이터 구조(2210)가 대상 유닛(100)의 메모리 공간 내로 판독될 때, 임의의 다른 안전한 암호화된 코드 블록에 대해 MAC이 사용되는 방식과 동일한 방식으로 키 목록 자체의 정품 여부 및 유효성을 검증하기 위해 이 (복호화된) 메시지 다이제스트가 사용된다. 개개의 키들 이외의 요소들 전부가 마스터 키로만 암호화된다는 사실은, 최상위 레벨 키 이외의 임의의 키들에 액세스할 필요 없이, 목록이 순회될 수 있다는 것(그리고 목록이 유지될 수 있다는 것)을 의미한다. 또한, 복호화 블록에 걸쳐 단지 한번의 패스로 키 목록 인벤토리가 편집될 수 있다.
관심을 끄는 제3 원리는 개개의 응용 프로그램 코드 또는 미디어 스트림 관련 키들이 각각의 대상 디바이스(100)에 대한 개별화된 키들을 수용할 정도로 충분히 크게 만들어질 수 있다는 것이다. 코드 또는 미디어 스트림이 대량 생산된 디스크를 통해 배포되는 경우에, 이것은 응용 프로그램 개발자(2120)가 개개의 복호화 키(들)와 함께 새로운 코드 관련 ID를 발행할 필요가 있다는 것을 의미한다. 이것이 라이센싱 프로세스에 관여된 모든 당사자들 간에 전송되어야만 하는 데이터의 양을 최소화하려고 시도하는 관점에서 볼 때 덜 효율적일 수 있지만, 이는 손상된 복호화 키들을 추적할 수 있는 것(이들로 제한되지 않음)을 비롯한 기능을 프로토콜에 부가한다. 또한 키 취소를 다루고 있는 나중의 섹션에서 이것을 논의할 것이다.
유의할 그 다음 문제는 키 목록 데이터 구조(2210) 헤더가 목록의 나머지를 이루고 있는 응용 프로그램 관련 키들과 동일한 일련의 특성들을 공유한다는 것이다. 사실, 헤더는 키 목록 데이터 구조(2210) 자체의 나머지에 대한 마스터 키(2220)로서 생각될 수 있다. 이와 같이, 목록의 나머지의 관리를 결정하기 위해 이 키가 사용될 수 있는 한, 동일한 동작 원리들이 적용될 수 있다. 이것은 대상 디바이스(100)의 보안 시스템의 시간 의존적 관리를 포함한다. 이와 같이, 대상 유닛(100)은 사전 결정된 간격으로 그의 보안 시스템을 강제로 업데이트할 수 있고, 이는 그 자체로 극히 강력한 개념이다.
또한, 키 목록이 각각이 그 자신의 마스터 키(2220)(목록 헤더)를 갖는 그리고 따라서 그 자신의 독립적인 암호화 메커니즘을 갖는 다수의 섹션들을 포함할 수 있을 가능성이 존재한다. 임의의 다른 키에서와 같이, 목록 헤더는 키 목록 데이터 구조(2210)를 해석하는 데 사용되는 암호화된 코드 블록을 가리킬 수 있는 코드 관련 ID 필드(260)를 포함한다. 전체 목록이 이어서 (또 다른 목록 헤더인) 그 자신의 마스터 키를 포함하는 또 다른 마스터 목록 내에 포함될 수 있다. 이와 같이, 키 목록 데이터 구조(2210) 전체가 재귀적으로 정의될 수 있다. 이전과 같이, 동일한 데이터 구조의 이전 버전들의 단점들을 해결하기 위해 새로운 키 목록 데이터 구조를 생성함으로써 보안 시스템을 업데이트하기 위해 이 재귀적 특성이 사용될 수 있다. 전체 목록의 보안이 "가장 바깥쪽"(또는 가장 최근의) 보안 계층 내에 포함되기 때문에, 키 목록 데이터 구조(2210) 전체의 보안이 항상 보안 소프트웨어의 마지막 반복에 기초한다.
이와 같이, 키 목록 데이터 구조(2210)의 재귀적 특성은 강력한 특징이다. 이는 또한 이전의 섹션에서 논의된 데이터 구조의 정확한 구현이 그다지 중요하지 않은 이유이기도 하다. 앞서 제공된 설명은 프로토콜 동작의 재귀적 성질을 만들 필요가 있는 기능의 최소 서브셋인 특징들을 포함하는 한 예에 불과하다.
그것이 어떻게 구성되는지에 관계없이, 몇가지 통상적인 상황들 하에서 키 목록(2210)이 유지되고 그리고/또는 업데이트될 수 있다. 이 상황들은 목록에 포함된 키들 중 하나 이상의 키들의 상태가 수정되는 경우(이들로 제한되지 않음)를 포함한다. 특정의 키(1810)의 소유권이 하나의 유닛으로부터 다른 유닛으로 이전될 수 있는 몇개의 기본 메커니즘들이 있고, 이들에 대해서는 나중의 섹션들에서 논의할 것이다. 그렇지만, 어쨋든, 개정된 키 목록이 유지되는 메커니즘이 2개의 부류들, 즉 라이센싱 기관(2110)의 개입을 필요로 하는 것과 독립적으로 수행될 수 있는 것으로 분할될 수 있다.
이 프로토콜이 기초하고 있는 주된 동작 개념들 중 하나는 라이센싱 기관(2110)의 중앙 서버와 개개의 대상 유닛들 간의 필요한 네트워크 트래픽의 양을 최소한으로 감소시키는 것이다. 이와 같이, 키 목록 데이터 구조(2210)에 대한 임의의 일시적인 변경들(그에 대한 이유들은 이하에서 기술될 것임)이 대상 유닛(100)에 의해 독립적으로 유지될 수 있어야만 한다. 이것에 대한 주된 이유는 이 변경들이 표면상 디바이스의 보안 시스템에 대한 영구적인 변경들(이는 항상 대상 디바이스(100)와 라이센싱 기관 사이의 상호작용에 의해서만 달성되어야 함)보다 더 빈번히 일어난다는 것이다.
어쨋든, 대상 디바이스(100)가 명확한 방식으로 마스터 키 목록 데이터 구조의 현재 상태를 추적할 수 있는 어떤 메커니즘이 있어야만 한다. 이것은 2개의 "마스터" 목록들을 가지는 것에 의해 달성될 수 있다. 이 2개의 목록들 중 제1 목록(영구적 키 목록이라고 지칭할 것임)은 라이센싱 기관(2110)에 의해 유지된다. 이 목록은 문제의 대상 유닛(100)과 연관되어 있는 응용 프로그램 관련 키들의 "영구적" 소유권에 관한 것이다. 제2 목록은 똑같이 중요하지만, 이는 "영구적" 키 목록 데이터 구조에 대한 일시적인 수정들에 관한 것이다. 유의할 점은, 이 수정들이 목록에 대한 부가일 수 있거나 목록으로부터의 삭제일 수 있다는 것이다. 2개의 목록들 자체의 데이터 구조들의 구현에 필요한 차이점이 없고, 주된 차이점은 이들이 어떻게 유지되느냐이다. 대상 유닛(100)이 이 목록들 중 하나 또는 다른 하나로부터의 데이터가 상실되는 경우로부터 복원되는 어떤 방식이 있는 것이 바람직하다. 이 상실은 어떤 파국적 고장로 인한 것이거나 목록들 중 하나에 포함된 정보가 어떤 식으로든(무심결에 또는 악의적으로) 오염되는 경우로 인한 것일 수 있다. 이러한 "키 목록 오염" 이벤트들의 영향들에 대해서는 나중의 섹션에서 논의할 것이다. 영구적 목록이 라이센싱 기관과의 연결에 의해 복원될 수 있는 것이 필요하지만, 라이센싱 기관(2110)이 특정의 대상 디바이스의 일시적 키 목록을 복원할 수 있는 것이 필요하지 않다(심지어 바람직하지도 않다). 이 상황에 대한 많은 이유들이 있지만, 주된 이유는 일시적 키 목록이 영구적 키 목록보다 훨씬 더 빈번하게 업데이트될 가능성이 아주 많고, 중앙 라이센싱 기관(2110)과 대상 유닛들 간의 요구된 네트워크 트래픽의 양을 절대 최소로 유지하고자 한다는 것이다. 그럼에도 불구하고, 몇가지 이유들(그 중 일부는 나중에 논의될 것임)로 라이센싱 기관(2110)이 특정의 대상의 일시적 키 목록을 수정할 수 있는 것이 어쩌면 바람직할 수 있다. 이 경우에, 이 목록을 (라이센싱 기관(2110)이 알고 있는) 대상 디바이스의 주 비밀 키를 사용하여 암호화하는 것이 바람직할 것이다.
앞서 언급한 바와 같이, 키 목록 데이터 구조들 둘 다의 무결성이 목록 자체와 함께 저장되어 있는 서명된 메시지 다이제스트(디지털 서명)를 사용하여 검증될 수 있다. 이 메시지 다이제스트를 발생시키는 데 사용되는 보안 코드 메커니즘의 구현은 이전의 섹션에서 기술되었으며, 그 절차를 다시 살펴볼 필요는 없다. 또한 상실 및/또는 오염의 경우에 영구적 키 목록 데이터 구조(2210)를 복원하는 절차에 대해서도 이미 기술하였다. 해결되어야만 하는 남아 있는 유일한 문제들은 일시적 키 목록 데이터 구조의 시간 의존적 부분을 어떻게 해석할지 및 일시적 키 목록이 어떻게든 사용가능하지 않게 되는 경우에 어떻게 처리할지이다.
일시적 라이센스 이전
이것은 타임스탬프 필드(1830)의 사용이 제일 중요한 보안 프로토콜의 섹션들 중 하나이다. 앞서 논의한 바와 같이, 일시적 키 목록 데이터 구조가 대상 디바이스의 영구적 키 목록과 완전히 동일한 방식으로 구성된다. 그렇지만, 이 둘 사이에 2가지 차이점이 있다. 제1 차이점은 일시적 키 목록이 어쩌면 대상 유닛의 비밀 키들(104) 중 어느 하나로 암호화될 수 있다는 것이다. 라이센싱 기관(2110)이 보통의 상황들 하에서 이 데이터 구조를 재구성할 수 있을 필요가 없기 때문에, 대상 유닛의 키들 중 어느 것이 그를 암호화하는 데 사용되는지는 표면상 관련이 없다. 그렇지만, 이 목록이 또한 대상 유닛의 주 비밀 키를 사용하여 암호화되면 라이센싱 기관(2110)에 어쩌면 유용할 것이다. 이것에 대한 이유는 라이센스 취소와 관련이 있고, 그 상황에 대해서는 나중의 섹션에서 논의할 것이다.
일시적 키 목록과 영구적 키 목록 사이의 제2 (더 중요한) 차이점은 가장 최근의 일시적 키 목록 데이터 구조와 연관되어 있는 타임스탬프 값(1830)의 사본이 또한 대상 디바이스(100) 내에(즉, 온칩) 저장된다는 것이다. 이 레지스터는, 보안 블록의 일부이기 때문에, 소프트웨어 판독가능하지 않고 보안 코드에 의해서만 덮어쓰기될 수 있다. 이 레지스터 내의 값은 일시적 키 목록 데이터 구조가 어떤 식으로든 상실 및/또는 오염되는 경우에 무엇을 할지를 결정하는 데 사용된다. 그 절차에 대해서는 이 섹션에서 나중에 논의할 것이다.
일시적 키 목록과 영구적 키 목록 사이의 또 다른 차이점은 대상 유닛(100)이 그의 영구적 목록으로부터 다른 유닛(100)의 일시적 목록으로 특정의 키의 소유권을 (일시적으로) 이전할 수 있지만, 어떤 (올바르게 동작하는) 디바이스도 특정의 키의 소유권을 그의 일시적 키 목록으로부터 임의의 다른 키 목록으로 이전할 수 없다는 것이다. 이것은, 물론, 다른 유닛들의 일시적 키 목록들 뿐만 아니라 대상(100) 자신의 영구적 키 목록도 포함한다. 이것은 영구적 소유자만이 어느 디바이스들이 임의의 특정의 키를 "차용(borrow)"하도록 허용되는지(그리고 언제 허용되는지)를 결정할 수 있다는 것을 의미한다. 그렇지만, 유의할 점은, 이 "대여(loan)" 기간이 무기한일 수 있다는 것(그리고 이 트랜잭션이 라이센싱 기관에 접촉할 필요 없이 수행될 수 있다는 것)이다. 이 "영구적 대여" 특징은 가장 최근의 디지털 CCI(Copyright Control Information) 시스템들의 일부인 표준의 "1회 복사(Copy Once)" 기능 요구사항과 동등하다.
이제 도 23을 참조하면, 일시적 "키 체크아웃(key checkout)" 절차를 나타낸 상세 흐름도가 도시되어 있다. "키 소유권" 이전 절차는 도서관으로부터 책의 사본을 대출하는 절차와 얼마간 유사하다. "차용자(2320)"가 특정의 응용 프로그램 관련 키(2150)의 일시적 사용을 영구적 소유자("대여자(2310)")에 요청할 때, 대여자(2310)는 먼저 키 체크아웃 협상 프로세스의 지속기간 동안 그 특정의 키의 사용을 금지시키는 그 자신에 대한 업데이트된 일시적 키 목록을 발생시킨다. 이 동작은 2개 이상의 차용자(2320) 유닛이 동일한 키를 요청하는 것을 금지시킨다. 대여자 유닛(2310)의 일시적 키 목록 상에 "체크아웃된 키"가 존재하는 것은 사실상 임의의 특정의 키에 대한 액세스를 제어하는 세마포어(semaphore)로서 사용된다. 그렇지만, 키가 "제한을 받는(on restriction)" 초기 시간량은 비교적 짧은 기간으로 제한되어야 한다. 이것은 차용자(2320) 디바이스가 오랜 기간 동안 특정의 키에 대한 액세스를 요청하고 이어서 특정의 키의 사용을 부당하게 독점하는 것으로부터 어떤 이유로 트랜잭션을 완료할 수 없는 경우를 방지하기 위한 것이다. 이 비교적 짧은 체크아웃 협상 단계 타임아웃은 또한 대여자 유닛(2310)에 대한 "서비스 거부" 공격과 동등한 것을 착수하려고 시도하고 있을 수 있는 악의적 디바이스와의 싸움에서 도움을 준다. 사실, 대여자 유닛(2310)은 선택적으로 그의 "승인된 차용자" 목록 상에 있지 않은 디바이스들로부터의 요청들을 무시할 수 있거나, 그 유닛들 중 임의의 것이 특정의 기간 내에 너무 많은 요청들을 하려고 시도하는 경우 그러할 수 있다. 이 일시적 블록이 키에 놓여 있는 정확한 시간 길이는 중요하지 않으며, 임의의 주어진 체크아웃 절차가 완료될 수 있게 충분히 길어야만 한다. 네트워크 트래픽 또는 대기 시간이 높을 때, 이 기간이 연장될 수 있을 것이다.
유의할 점은, 주어진 키의 2개 이상의 사본이 동시에 체크아웃될 수 있는 경우에, 대여자 디바이스(2310)의 일시적 키 목록 내의 적절한 필드들은 임의의 주어진 시점에서 주어진 키의 몇개의 사본들이 체크아웃되는지를 나타내기 위해 사용될 수 있다. 차용자(2320) 및 대여자(2310)가 주어진 키에 대한 특정의 체크아웃 기간을 협상했으면, 대여자(2310)는 키(2340)의 암호화된 사본을 차용자(2320)로 송신한다. 이 암호화는 대여자 디바이스(2310)만이 알고 있는 임시 비밀 키(2330)를 사용하여 수행된다. 차용자(2320)가 (암호화된 메시지로부터 계산되는 메시지 다이제스트에 의해) 암호화된 키의 정확한 수신을 확인 응답할 때, 대여자(2310)는 체크아웃된 키의 "대여 기간"을 연장시키고 이어서 임시 비밀 키(2330)를 차용자 디바이스(2320)로 송신한다. 이 대여 프로세스의 최대 지속기간이 프로세스의 동작에 중요하지 않으며, 이 값의 선택에서 행해져야만 하는 어떤 절충이 있다. 이 특정의 문제들에 대해서는 이 섹션에서 나중에 살펴볼 것이다. 앞서 논의된 예에서, "차용자(2320)" 및 "대여자(2310)" 디바이스들이 키별로 체크아웃 기간의 실제 길이를 협상할 수 있는 것으로 가정하지만, 이것이 확실히 프로토콜의 요구사항은 아니다.
차용자(2320) 또는 대여자(2310) 중 어느 하나의 일시적 키 목록이 업데이트되는 시점 바로 전에, 이 새로운 일시적 목록과 연관되어 있는 타임스탬프 값(1830)의 사본이 대상 디바이스(100) 상에 비휘발적으로 저장된다. 그 시점에서, 일시적 키 목록 데이터 구조의 암호화된 버전이 메모리에 안전하게 기입될 수 있다(또는 온보드 NVRAM, 플래시 ROM과 같은 어떤 다른 더 영구적인 장소에 또는 심지어 어떤 하드 디스크(2350) 상의 백업 파일에 저장될 수 있음). 일시적 키 목록이 어쩌면 영구적 키 목록으로부터 판독되고 그보다 훨씬 더 빈번히 업데이트되기 때문에, 이 목록이 대상 유닛에 의해 신속하게 액세스될 수 있는 것이 바람직하며, 따라서 (비록 프로토콜의 실제 요구사항은 아니지만) 이 목록이 액세스 대기시간이 비교적 짧은 적어도 하나의 장소에 저장되는 것이 추천된다. 다른 한편으로는, 이 목록이 저장되는 유일한 장소가 어떤 휘발성 저장 매체(DRAM 등)인 것이 추천되는데, 그 이유는 전력 장애가 불확정 시간 동안 어쩌면 유닛(100)의 기능의 상실을 야기할 수 있기 때문이다. 이 문제에 관한 상세에 대해서는 이 섹션에서 나중에 살펴볼 것이다.
특정의 키에 대한 체크아웃 기간이 만료될 때, 차용자(2320) 및 대여자(2310) 둘 다는 그 각자의 일시적 키 목록 데이터베이스들을 독립적으로 업데이트할 수 있다. 따라서, "특정의 키를 반환하여 순환시키기 위해" 차용자(2320)가 대여자(2310) 유닛과 접촉할 필요가 없다. 차용자(2320) 및 대여자(2310) 디바이스들이 멀리 떨어져 있는 경우에 이것은 주된 편의성 인자이다. 물론, 이 동작의 보안은 키 타임스탬프 레코드들을 발생시키고 제어하는 데 사용되는 온칩 클럭들 간의 아주 엄격한 상관 관계에 의존할 수 있다. 이와 같이, 시간/날짜 클럭은 보안 시스템의 일체형 부분이어야만 하고, 그에 따라, 중앙 서버와의 트랜잭션에 의해 덮어쓰기될 수 있어야만 한다. 또한, 클럭들은 악의적 사용자가 내부 타임스탬프 값(1830)을 수정하려고 시도하는 경우에 변조를 방지하기에 충분히 강건하도록 그리고 또한 통상적으로 일어나는 시스템 전력 장애를 극복할 수 있도록 설계되어야만 한다. 이 클럭이 배터리-전원으로 동작되는 것 그리고 배터리가 제거될 수 있거나 시간의 경과에 따라 닳아 없어질 수 있다는 것을 생각할 수 있기 때문에, 시스템은 클럭이 어쩌면 라이센싱 기관과의 상호작용에 의해 재기동되고 리셋될 수 있는 방식으로 설계되어야만 한다.
이와 같이, 특정의 응용 프로그램 관련 키(2150)의 소유권이 한 유닛으로부터 다른 유닛으로 일시적으로 이전될 수 있는 상황을 기술하였다. "대여 기간"의 끝에서, "차용자(2320)" 및 "대여자(2310)" 유닛들 둘 다는 키의 그의 원래의 소유자로의 "반환"을 반영하기 위해 그의 일시적 키 목록 데이터 구조들을 업데이트할 수 있다. 유의할 점은, 이 절차가 이들 유닛 둘 다에서 독립적으로 수행될 수 있고 따라서 이 2개의 디바이스들 간의 어떤 상호작용도 필요로 하지 않는다는 것이다.
하나 이상의 키들이 "체크아웃"되거나 "대여중"인 동안 일시적 키 목록 데이터 구조들 중 하나 또는 다른 하나가 오염 및/또는 상실되는 경우를 이제 다루어야만 한다. "대여자(2310)" 유닛의 측에서, 임의의 키들이 체크아웃될 때, 그가 맨먼저 하는 것은 "대여" 기간의 끝을 결정하는 것이다. 대여 기간의 지속기간을 현재 시간/날짜 필드의 값에 가산함으로써 이 값이 명백히 구성된다. 이 시간/날짜 값은 이어서 디바이스의 일시적 키 목록이 마지막으로 업데이트된 결과로서 칩에 저장되어 있는 값과 비교된다. 새로운 값이 이전의 값보다 더 큰(더 늦은) 경우, 이전의 값 대신에 새로운 값이 덮어쓰기된다. "차용자(2320)" 측에서, 이 동일한 프로세스가 사용되고, 따라서 그 결과 임의의 주어진 대상 유닛에서, 일시적 키 목록 타임스탬프가 항상 그 특정의 유닛(100)의 일시적 키 목록의 일부로서 저장되어 있는 타임스탬프들 중 임의의 것 중 최신의 것이다.
유닛(100)의 일시적 키 목록이 상실되거나 달리 부적절하게 수정되는 경우, 이 "마지막 타임스탬프" 값이 만료되는 시점까지(사실상, "타임아웃" 기간) 일시적 키 목록 및 영구적 목록 둘 다가 디스에이블된다. 그 시점에서, 유닛은 다시 영구적 키 목록을 사용하는 것으로 갈 수 있고, 새로운 일시적 키 목록을 재구성하는 프로세스를 시작할 수 있다.
이와 같이, 디바이스의 일시적 목록이 변조되거나 삭제되면, 이 유닛은 타임아웃 기간이 만료할 때까지 사실상 동작하지 않게 된다. 이 타임아웃 절차가 불필요하게 제한적인 것처럼 보일 수 있지만, 이는 어떤 악의적 행위의 결과로서 또는 하나의 유닛으로부터 다른 유닛으로의 키의 전송 동안 일어날 수 있는 (정전 또는 네트워크 연결이 중단되는 것과 같은) 어떤 고장으로 인해 임의의 특정의 응용 프로그램 관련 키들의 다수의 사본들이 계속 존재하는 잠재적인 문제를 피한다. 또한, 일시적 키 목록 데이터 구조를 변조한 결과로서의 이러한 심각한 영향의 가능성은 더 정교한 공격자들 이외의 모두에 의한 실행을 좌절시키는 데 도움을 주어야만 한다.
이와 관련하여 프로토콜의 동작을 향상시키기 위해 사용될 수 있는 다수의 선택적인 부가 특징들이 있다. 하나의 이러한 가능한 옵션은 암호화된 키 목록 데이터 구조들 중 어느 하나(또는 둘 다)로부터 발생되는 서명된 메시지 다이제스트(디지털 서명)를 대상 유닛의 온칩 보안 섹션에 저장되어 있는 값들에 부가하는 것이다. 디지털 서명의 복호화로부터 얻어지는 MAC 값은, 복호화 프로세스 전체를 거칠 필요 없이, 임의의 특정의 키 목록의 유효성을 신속하게 검증하는 데 사용될 수 있다. 그렇지만, 다중 내포된 키 목록들의 문제는, 암호화되지 않은 키를 최종적으로 생성하기 위해, 이 복호화 절차가 어떤 시점에서 여러번 수행되어야만 할 가능성이 전적으로 있다는 것을 의미하고, 따라서 이 디지털 서명들이 온칩 저장되는 것이 프로토콜의 동작에 중요하지 않다.
향상을 위한 다른 가능한 방법은 단지 하나만이 아니라 한 쌍의 온칩 타임스탬프 값들을 저장하는 것이다. 일시적 키 목록이 업데이트되어야만 하는 가장 이른 (그 다음) 때를 나타내기 위해 부가의 타임스탬프가 사용될 수 있을 것이다. 이것은 대상 디바이스(100)가 그의 일시적 키 목록을 수정할 필요가 있을 때를 결정하는 것을 더 쉽게 만들어주는데, 그 이유는 그가 목록을 항상 검사(이는 복호화 프로세스를 거치는 것을 수반함)할 필요가 없기 때문이다. 이 특징이 아주 유용하지만, 다시 말하자면, 이는 유닛이 이 프로토콜을 실행할 수 있기 위한 기본 요건은 아니다. 그렇지만, 이 제2 타임스탬프를 포함하는 시스템이 구현되면, 이는 2개의 타임스탬프들이 어떤 이유로 "동기를 벗어나게" 되는 경우에 혼동 가능성을 야기한다. 머리에 떠오르는 하나의 이러한 예는 하나의 이러한 타임스탬프가 기입된 직후 그러나 제2 타임스탬프가 업데이트되기 이전의 시점에서 일어나는 전력 장애이 있는 경우이다.
해결되어야만 하는 마지막 문제는 이 일시적 키 목록 타임스탬프들의 값들에 대한 최소 및 최대 한계들이 무엇인지의 문제이다. 한편, 최대 "일시적 대여 기간"에 대한 더 큰 한계는 사용자가 특정의 데이터 응용 프로그램(또는 미디어 스트림)의 사용을 꽤 오랜 기간 동안 하나의 유닛으로부터 다른 유닛으로 이전할 수 있게 한다. 사용자가 미디어 스트림의 소유권을 그의 "홈 유닛"으로부터 휴대용 유닛으로 이전하고자 하는 경우에 이것이 어쩌면 유용할 것이다. 긴 "체크아웃 기간"을 가지는 것은, 사용자가 원래의 "대여자" 유닛(2310)과 접촉하고 있을 필요 없이, 사용자가 휴대용 유닛을 (그의 연관된 임시 키들과 함께) 가지고 다닐 수 있게 한다. 긴 "체크아웃" 기간의 불리한 면은, 원래의 유닛 상의 일시적인 키 목록 데이터 구조에 무언가가 일어나는 경우, 그 유닛이 어쩌면 오랜 시간 동안 디스에이블된다는 것이다.
이 마지막 문제는 또한 악의적 코드가 온칩 타임스탬프 레지스터의 값을 어떤 불확정 값으로 설정할 수 있는 경우에 대상 유닛(100)에 대한 잠재적임 위험을 가리킨다. 이것은 어쩌면 공격의 목표를 디스에이블시키는 것이나 다름 없고, 따라서 이 타임스탬프 레지스터의 값은 "보안" 코드 블록에 의해서만 기입될 수 있다. 다시 말하지만, 각각의 유닛이 구별되는 비밀 키들의 세트를 가질 것이기 때문에, 하나의 특정의 유닛(100)의 비밀 키(104) 데이터의 발견이, 악의적 디바이스가 적법한 유닛으로 효과적으로 가장할 수 있는 경우를 제외하고는, 임의의 다른 유닛에 대한 걱정의 원인이 되어서는 안된다. 이 공격 모드는 ID 검증(Identity Verification)에 관계된 문제들을 다루는 나중의 섹션에서 논의된다.
영구적 라이센스 이전
이 절차의 요소들 중 다수는 본 문서의 이전의 섹션들에서 논의되었다. 특정의 키가 하나의 유닛으로부터 다른 유닛으로 영구적으로 이전되는 기본적인 프로세스는 앞서 도 21에 나타내어져 있다. 여러 면에서, 이 섹션 바로 이전의 섹션에서 기술된 바와 같이, 이 절차는 본질적으로 키 소유권의 일시적 이전의 절차와 유사하다.
2개의 절차들 간의 주된 차이점들은 영구적 이전이 일시적 이전보다 더 간단한 프로세스라는 것 및 영구적 키 소유권 이전 절차가 라이센싱 기관(2110)과 대상 유닛(100) 사이의 상호작용을 이용해야만 한다는 것이다. 영구적 이전 프로세스가 더 간단한 이유는 일시적 키 체크아웃 절차에서의 전제 조건인 체크아웃 기간 협상을 필요로 하지 않는다는 사실에 있다. 영구적 이전 기능이 라이센싱 기관(2110)과 대상 유닛(100) 사이의 상호작용을 이용하는 이유는 업데이트된 키 목록 데이터 구조가 트랜잭션의 양단에서 재구성될 수 있어야만 한다는 사실로 인한 것이다.
영구적 라이센스 이전이 보통 라이센싱 기관(2110)과의 상호작용에 의해 일어나기 때문에, 어느 응용 프로그램 또는 미디어 스트림 관련 키들이 어느 대상 유닛들에 속하는지의 기록이 있다. 앞서 기술된 바와 같이, 어떤 파국적인 데이터 상실 상황 후에 대상 유닛(100)의 키 목록이 복원되어야만 하는 경우에 또는 특정의 대상 유닛(100)의 소유권이 다른 엔터티로 이전되는 경우에 이것이 필요하다. 특정의 키의 영구적 소유권이 하나의 대상 유닛(100)으로부터 다른 대상 유닛으로 이전되는 경우에 라이센싱 기관(2110)측에서의 이러한 개입이 또한 필요하다. 원래 다른 엔터티로부터 구입되었던 자산을 소유자가 이와 같이 재판매할 수 있는 것은 "우선매도권(right of first sale)"이라고 하며, 본 명세서에 기술되어 있는 프로토콜이 이 특정의 기능을 지원할 수 있는 것이 중요하다.
대상 유닛(100)의 영구적 키 목록이 라이센싱 기관(2110)에 의해 유지되는 사실의 다른 중요한 측면은, 유닛(100)이 어떻게든 손상되었다는 것이 입증되는 경우 또는 키들 중 하나가 손상된 것으로 식별된 경우, 이 조직이 개개의 대상 유닛(100)의 라이센스 키들 중 일부 또는 전부를 취소할 수 있다는 것이다. (앞서 기술된 바와 같이) 모든 대상 유닛(100)에 고유의 키 목록을 제공할 가능성이 존재하기 때문에, 또한 라이센싱 기관(2110)이 임의의 손상된 키들의 소스를 추적할 기회를 제공할 수 있다. 이러한 상황에서, 이 프로토콜은, (워터마크가 미디어 스트림의 품질에 악영향을 미칠 수 있는 가능성과 같은) 전통적인 워터마크 프로세스의 단점들 없이, 통상적으로 "워터마크" 특징의 기능과 연관되어 있는 기능을 수행할 수 있다.
비록 이러하지 않은 것처럼 보일지라도, 디지털 콘텐츠 소유자의 프라이버시가 이 프로세스에 의해 여전히 유지되는데, 그 이유는 응용 프로그램 코드 또는 미디어 스트림 관련 ID 정보가 응용 프로그램 개발자(2120)로부터 오고 라이센싱 기관(2110)이 임의의 특정의 응용 프로그램 또는 미디어 스트림과 그의 라이센스 있는 소유자를 연관시킬 수 있기에 충분한 정보를 가질 필요가 없기 때문이다. 사용자의 프라이버시를 이와 같이 보호할 수 있는 것이 또한 이 프로토콜의 중요한 측면이다.
영구적 키 이전 프로세스에 관해 주목해야만 하는 최종적인 문제는, 사실, 영구적 키 이전이 수행하는 동일한 기능들 모두를 일시적 키 라이센스 이전으로 달성하는 것이 가능하다는 것이다. 그렇지만, 대상 유닛의 보안 시스템의 유지 관리는 이상적으로는 중앙 보안 서버에 의헤 제어되어야만 하는 기능이고, 따라서 체인에서의 어딘가에 이러한 메커니즘을 가질 필요가 있다. 또한, 사용자가 그의 프라이버시를 유지하는 것을 걱정하는 경우에, 중앙 서버가 저작권 소유자와 대상 유닛(100) 사이의 버퍼로서 기능할 수 있다는 사실이 아주 유용하다. 마지막으로, 또한 라이센싱 기관(2110)이 일시적 키 이전 메커니즘으로부터 이 기능을 떼어 놓은 특정의 대상 유닛(100)의 영구적 키 목록에 대한 중앙 백업 저장 메커니즘으로서 기능할 수 있다는 매력이 있다.
시스템 소유권 이전, 라이센스 취소 및 보안 시스템 업데이트
대상 유닛(100)의 라이센스들(또는 키들) 중 하나 이상이 취소될 수 있는 몇가지 다른 수단들이 있다. 가장 간단한 방법은 대상(100)의 주 비밀 키를 단순히 업데이트하는 것이다. 이 시점에서, 대상(100)은 그러면 그의 영구적 키 목록에 액세스할 수 없고, 따라서 새로운 것을 생성하는 프로세스를 시작해야만 할 것이다. 유의할 점은, 주 비밀 키가 일시적 키 목록 데이터 구조에 대한 암호화 프로세스에서 사용되지 않은 경우에, 비록 영구적 키 목록이 다른 방식으로 액세스가능하지 않을지라도 이 일시적 키 목록이 어쩌면 여전히 액세스될 수 있다는 것이다. 이 점에 대해서는 일시적 키 목록에 대한 암호화 프로세스의 설명에서 앞서 언급하였다. 이 때문에, 영구적 및 일시적 키 목록 데이터 구조들 둘 다에 대해 대상 유닛(100)의 주 비밀 키를 암호화 키로서 사용하는 것이 아마도 최상의 생각이다.
대상 유닛(100)의 소유권이 한 사람으로부터 다른 사람으로 변경되는 경우에, 이 소유권 변경을 달성하는 가장 간단한 방식은 유닛(100)의 주 비밀 키를 어떤 새로운 값으로 설정하는 것이다. 그렇지만, 원래의 소유자가 대상으로부터 그의 영구 키들 모두를 복구할 기회를 가지기 전에 이것이 일어나는 경우, 원래의 소유자는 그의 라이센스들을 상실할 것이다. 원래의 소유자가 연관된 영구적 키 목록의 소유권을 대상 유닛과 함께 이전하고자 하는 경우에, (라이센싱 기관(2110)에 저장되어 있는) 그 특정의 디바이스와 연관되어 있는 소유권 정보를 변경하는 것을 제외하고는 대상 유닛(100)에 대해 아무것도 행해질 필요가 없다.
라이센스 취소가 일어날 수 있는 다른 방식은 특정의 대상 유닛(100)의 영구적 키 목록에 대한 마스터 키가 "만료"되는 경우이다. 유닛(100)의 보안 시스템에 대한 업데이트들이 영구적 키 목록의 일부로서 저장되기 때문에, 이 상황은 어쩌면 재난적인 영향을 미칠 수 있다.
비록 이 곤경으로부터 복구하는 것이 어쩌면 가능할 것이지만, 대상(100)이 처음부터 다시 구축된 완전히 새로운 "신뢰 체인"을 가질 필요가 있는 것이 요구된다. 이 상황에서, 새로 초기화된 보안 시스템의 핵심은 대상(100)의 어떤 부분에서 원자적으로 실행될 수 있는 것으로 검증될 수 있는 그 계산들에만 기초해야 할 것이다. 이와 같이, 이것은 심지어 가장 적은 양의 다른 범용 코드를 필요로 하는 임의의 해싱 함수의 사용(이는 어쩌면 의심스러울 수 있음)을 배제할 것이다. 다행스럽게도, 이 상황이 안전한 것으로 검증가능한 코드 단편들의 영구적 코어를 만료되지 않는 영구적 키 목록 데이터 구조의 일부로서 항상 유지하는 간단한 일로 회피될 수 있다. 그렇지만, 앞서 논의한 이유들로 이 자체가 보안 위협이고, 따라서 이 영구적 코드 코어의 내용이 가능한 한 많이 제한되어야만 한다.
라이센싱 기관(2110)이 대상 유닛(100)의 영구적 또는 일시적 키 목록들에 있는 특정의 키 엔트리를 무시하기로 하는 경우 라이센스 취소의 또 다른 방식이 있을 수 있다. 보안 시스템 업그레이드가 필요한 경우에 또는 특정의 대상 유닛(100)이 특정의 응용 프로그램 또는 미디어 스트림의 라이센스 없는 사본을 가지는 것으로 식별된 경우 이것이 사용될 수 있을 것이다. 대상 유닛(100)이 통상적으로 그 자신의 키 목록 데이터 구조를 유지하기 때문에, 이 절차는 라이센싱 기관(2110)과 대상 유닛 사이에 보통보다 더 많은 양의 네트워크 트래픽을 수반할 것이다. 이와 같이, 극단적인 경우들에 대해 이 행동 방침이 예비되어 있어야만 한다.
그럼에도 불구하고, 문제의 대상 디바이스(100)로 하여금 논란의 대상이 된 키를 검색하고 디스에이블시키도록 그리고/또는 이어서 이전의 소프트웨어를 업데이트된 버전으로 대체하도록 설계되어 있는 대상 관련 커스텀 버전으로 그의 보안 시스템 소프트웨어를 수정하게 함으로써 이러한 절차가 달성될 수 있다. 물론, 이 절차는 대상 디바이스(100)가 라이센싱 기관의 중앙 서버와의 연결을 개시하는 시점에서만 시행될 수 있다. 보통의 상황들 하에서, 임의의 특정의 대상 유닛(100)이 임의의 특정의 스케줄로 라이센싱 기관(2110)과의 접촉을 개시하는 것이 보장되지 않을 수 있다. 다행스럽게도, 문제의 대상 디바이스(100)는 그의 영구적 키 목록에의 임의의 새로운 부가를 허가하기 위해 라이센싱 기관(2110)과 (직접 또는 간접적으로) 접촉해야만 하고, 따라서 임의의 키 취소 동작들이 새로운 키 라이센싱 절차의 일부로서 달성될 수 있다. 앞서 언급된 "보안 시스템 타임아웃" 메커니즘이 이 "목록 폴리싱(list policing)" 동작을 지원하는 데 사용될 수 있는 것이 또한 가능하다. 그렇지만, 이 프로토콜에 대해서는 이러할 필요가 없고, 이러한 시스템으로 인해 사용자의 프라이버시 권리들이 침해될 가능성이 있다.
다른 관심 사항들:
프로토콜 자체의 일부일 필요는 없지만 그럼에도 불구하고 본 명세서에 기술되어 있는 프로토콜을 적절히 실행할 수 있는 실용적인 시스템을 생성하는 프로세스에서 해결되어야만 하는 다수의 문제들이 있다. 이 문제들 중 일부는 실제의 프로세서 디바이스의 구현에 의존하고, 다른 것들은 대체로 응용 프로그램에 관련되어 있다. 이 정보가 적합한 대상 디바이스(100)의 적절한 구성에 밀접한 관계가 있기 때문에, 이하의 섹션에서 이 문제들 중 일부를 논의할 것이다.
연동할 수 있는 유닛들의 수에 대한 제한
저작권 소유자가 주 대상(primary target)이 소유권을 일시적으로 이전할 수 있는 디바이스들의 총수를 제한하고자 하는 경우에, 어느 때든 활성일 수 있는 제한된 수의 공개/개인 키 쌍들을 설정하는 것에 의해 이것이 달성될 수 있다. 유의할 점은, 이것이 이전의 섹션에서 기술된 동일한 응용 프로그램 관련 키(들)의 다수의 사본들이 동시에 "대여중"인 경우와 상이하다는 것이다. 특정의 대상 디바이스(100)로부터 응용 프로그램 관련 키들 중 임의의 것을 "체크아웃"할 수 있는 디바이스들의 목록이 특정의 일련 번호들의 세트로 제한될 수 있는 다른 시나리오들이 가능하다. 라이센싱 기관(2110)은 대상 유닛(100)의 보안 시스템이 관리되는 것과 완전히 동일한 방식으로 이러한 "승인된 차용자" 목록을 관리할 수 있다. 이와 같이, 라이센싱 기관(2110)은, 예를 들어, "승인된 차용자들" 목록 상의 일련 번호들의 세트를 원래의 대상 디바이스(100)와 동일한 소유권 정보를 가지는 것들로 제한할 수 있다. 이 문제에 대한 다른 가능한 해결책은 임의의 "차용자" 디바이스(2320)가 (서명된 인증서와 같은) 자격 증명들을 중앙 라이센싱 기관(2110)의 공개 키로 인증서를 복호화하는 것에 의해서만 검증될 수 있는 대여자에게 제시하는 것에 의해 "허가된" 차용자로서 검증될 필요가 있다는 것이다. 이 시나리오는 또한, 물론, 특정의 유닛이 손상된 것으로 판정된 경우에 라이센싱 기관(2110)이 이러한 인증서를 취소할 수 있는 것을 포함한다. 이 인증서 취소 프로세스가 달성될 수 있는 하나의 공지된 방법은 규칙적으로 공개되는 "취소 목록"을 통하는 것이다.
비밀 키 발견 및 ID 검증 문제
특정의 플레이어에 대한 주 비밀 키가 물리적 분해 및 칩 다이 검사에 의해 발견되는 경우, 이것은 임의의 다른 디바이스의 보안을 손상시켜서는 안되는데, 그 이유는 각각의 디바이스가 구별되는 비밀 키들(104)의 세트를 가질 것이기 때문이다. 그렇지만, 특정의 플레이어에 대한 주 키가 어떻게든 손상된 경우, 라이센스 없는 디바이스가 적법한 대상 유닛으로 가장하는 것이 어쩌면 가능하다. 이 문제가 검출되지 않은 경우에, 이 정보를 가지고 있는 라이센스 없는 디바이스가 그 특정의 대상 유닛에게 발행된 응용 프로그램 관련 복호화 키들 중 임의의 것을 손상시킬 가능성이 존재한다. 라이센싱 기관(2110)이 제일 먼저 복호화 키들을 그 디바이스에게 발행하기 위해 대상 유닛(100)의 일련 번호(106)가 등록될 필요가 있기 때문에, 이와 관련한 문제는 표면상 라이센스 없는 디바이스에 의한 다른 적법한 대상 유닛(100)의 제한으로 제한된다.
그렇지만, 유닛(100)의 비밀 키들 둘 다가 이러한 프로세스에 의해 발견되면, 암호화된 키 목록 다이제스트들의 이전에 백업된 사본들의 검사에 기초하여, 그 유닛에 사용 허가된 응용 프로그램 관련 키들 모두의 보안을 손상시킬 수 있는 일이 일어날 수 있다. 이 때문에, 이들 키의 값을 발견하려는 임의의 시도로 인해 키 데이터가 상실되도록, 주 비밀 키 및 보조 비밀 키 둘 다가 대상 칩 상에 "변조 방지(tamper-proof)" 방식으로 구현되어야만 한다.
이 변조 방지 특징이 대상 디바이스(100)에서 구현될 수 있는 다수의 수단이 있지만, 이러한 것의 정확한 구현이 본 문서에 기술된 프로토콜에 중요하지 않다. "비밀 키 상실" 상황이 사용자측에서 무심결에 행해지는 어떤 무시(또는 남용)를 통해 일어나는 경우, 적법한 사용자는 손상된 유닛의 응용 프로그램 관련 키들을 새로운 디바이스로 이전시키도록 처리할 수 있는 라이센싱 기관(2110)으로 그의 손상된 유닛을 반환할 수 있어야만 한다. 그렇지만, 유의할 점은, 원래의 대상 디바이스(100)가 기능하지 않는 경우에, 새로운 대상 디바이스(100)으로의 키들의 이전은 (적어도 라이센싱 기관(2110)에 제일 먼저 평문으로 제공되지 않은 그 키들에 대해) 응용 프로그램 개발자(2120)과의 트랜잭션을 수반해야만 한다.
그렇지만, 유의할 점은, 다른 정품 대상 유닛(100)을 가장할 수 있는 디바이스가 표면상 의심하지 않는 적법한 라이센스 있는 디바이스를 속여 그의 응용 프로그램 관련 키들 중 하나 이상의 키들의 소유권을 일시적으로 양도하게 하거나 동작을 일시 중지시키게 할 수 있다(이에 대해서는 앞에서 논의하였음). 후자가 일어나는 경우, 그로부터 키를 차용하려고 시도했던 유닛들 모두를 디스에이블시킬 수 있는 "악의적 유닛(rogue unit)"을 가질 가능성이 존재한다. 전자가 일어나는 경우, 임의의 수의 응용 프로그램 또는 미디어 관련 키들이 어쩌면 손상될 수 있을 것이다.
이와 같이, 특정의 대상 유닛(100)에 대한 잠재적인 "라이센스 있는 차용자들"의 수를 라이센싱 기관(2110)으로부터의 보안 업데이트에 의해 적법한 유닛에만 제공될 수 있었던 목록으로 제한하는 이전에 논의된 개념은 신중한 것이다. 전자의 경우에, 이것은 다른 의심하지 않는 유닛들의 소유자들이, 그 유닛이 실제로 제일 먼저 해커에 속하지 않은 한, 그의 비밀 키들에 액세스하기 위해 기능 유닛을 분해하는 해커에 의해 디스에이블된 그의 적법한 디바이스들을 갖지 못하게 한다. 후자의 경우에, 이것은 응용 프로그램 또는 미디어 관련 키들의 이전을 한 시점에서 라이센싱 기관에 적절히 등록된 라이센스 있는 디바이스들이었던 그 디바이스들로만 제한할 것이다. 그럼에도 불구하고, 단호한 해커는 적법한 유닛을 여전히 구입하고, 그를 부수고 어떻게든 그의 비밀 키 데이터에 액세스하고 이어서 적법한 디바이스로 가장하기 위해 이 정보를 사용할 수 있다.
따라서, 이러한 종류의 가장 이벤트(impersonation event)를 검출하려고 어떻게 시도할지의 문제가 남아 있다. 이러한 속성의 재정이 아주 탄탄한 적대자를 무찌르는 유일한 성공적인 전략은 잠재적인 이득이, 적어도 비용 트레이드오프 관점에서, 요구된 노력만큼의 가치가 없도록 시스템을 설계하는 것이다.
통신하고 있는 다른 미지의 디바이스의 정품 여부를 증명하려고 시도하는 몇가지 수단이 있다. 그렇지만, 디바이스가, 사실, 자신이 바로 그것임을 증명하는 가장 성공적인 방법은 이 디바이스를 다른 디바이스들로부터 독자적인 것으로 만드는 특성들에 집중하는 것이다. 본 문서에 기술된 것과 같은 디지털 복호화 메커니즘과 같은 특수 목적 장치의 경우에, 디바이스가 보안 프로토콜을 적절히 실행하고 주어진 입력 변수들의 세트에 기초하여 정확한 결과를 계산할 수 있을 것이다. 그렇지만, 본 명세서에 기술되어 있는 보안 프로토콜이 공개적으로 알려져 있는 알고리즘들에 기초하기 때문에, 이것은, 계산을 완료하는 데 충분한 시간을 갖는 경우, 표면상 임의의 범용 컴퓨팅 디바이스에 의해 달성될 수 있을 것이다. 사실, 이 문제는, 디바이스를 독자적인 것으로 만드는 비밀 키 정보가 어떻게든 손상되는 경우에, 공개적으로 이용가능한 기술에 기초하는 임의의 디바이스에 대한 잠재적인 문제점일 것이다. 이와 같이, 적법한 대상 디바이스들 모두에 대해 온칩 저장되어 있는 비밀 키 정보가, 심지어 분해 및 칩 다이 검사에도 불구하고, 비밀로 유지되어야만 한다는 지침에 궁극적으로 의존해야만 한다.
특정의 양의 시간 내에 검증가능한 MAC 값을 정확하게 산출할 수 있는 것과 같은 대상 식별 및 검증 프로세스에 요구사항들을 확실히 추가할 수 있다. 최종적인 MAC 값이 여러번 암호화되어야 하는 것에 의해 이 절차를 더 어렵게 만들 수 있다. 따라서, 라이센스들 자체의 적법한 사본들을 단순히 구입하는 비용보다 통상적으로 훨씬 더 비싼 (더 일반적인) 계산 자원들에 액세스할 필요가 있다는 점에서, 어쩌면 공격자가 적법한 디바이스를 가장할 수 있는 능력을 제한할 수 있다. 미디어 스트림 플레이어의 경우에, 또한 플레이어가 표면상 수용하도록 설계되어 있는 미디어 스트림들 중 하나 이상의 미디어 스트림들의 일부분을 정확하게 디코딩할 수 있다.
그렇지만, 어쨋든, 디지털 저작권 보호의 전체 프로세스는 튜링(Turing) 문제이다. 이와 같이, 충분한 시간 및 자원들이 주어진 경우, 임의의 디지털 저작권 보호 방식이 단호한 적대자에 의해 어쩌면 좌절될 수 있다. 이것은 심지어, 물론, 비밀 키 정보에 대한 액세스가 잠재적 공격자에 커다란 이점이 된다는 사실과는 무관하다. 유닛의 비밀 키들을 손상되지 않도록 할 수 있는 것은 따라서 이 보안 프로토콜의 중요한 부분이다.
결론:
앞서 기술한 저작권 보호 프로토콜은 몇가지 측면들에서 독자적이다. 첫째는 사용자가 그가 합법적으로 구입한 응용 프로그램 또는 미디어 관련 키 데이터의 백업 사본들을 만들 수 없도록 시도하지 않는다는 사실이다. 둘째, 이 프로토콜은 임의의 종류의 디지털 데이터를 구분하지 않으며, 따라서 보안 프로토콜이 보호하도록 설계되어 있는 데이터 스트림만큼 보안 프로토콜이 쉽게 업데이트될 수 있게 한다. 셋째, 이 프로토콜은 사용자가 그의 응용 프로그램 또는 미디어 관련 키(들)의 소유권을 그 프로토콜을 실행할 수 있는 다른 유닛에 일시적으로 이전할 수 있게 한다. 또한, 이 프로토콜은 또한 라이센스 소유자가 하나의 대상 유닛(100)으로부터 다른 대상 유닛으로의 소유권 영구 이전을 달성할 수 있는 것을 제공한다. 이 마지막 특성은 이 프로토콜 하에서 소비자의 합법적 "우선매도권"의 구현을 가능하게 한다.
사실, 본 문서에 기술된 프로토콜과 다른 복사 방지 방식들 간의 기본적인 차이점들 중 하나는 이 시스템의 보안이 특정의 데이터 세트에 액세스할 수 있는 것을 통제하는 것이 아니라 오히려 그 데이터 세트 내에 포함되어 있는 아이디어들을 표현하는 행위를 통제할 수 있는 것에 의존한다.
앞서 논의한 바와 같이, 프로세서가 임의적인 코드 세그먼트를 소정의 방식으로 실행할 수 있는 것이 요망된다. 그 중에서도 특히, 이 요망을 해결하는 해결책이 이제부터 논의될 것이다. 심지어 적법한 소프트웨어가 의도하지 않은 또는 심지어 악의적인 결과들을 생성하기 위해 조작될 수 있는 많은 다양한 방법들에 의해 제어의 문제가 복잡하게 된다. 이 공격 방법들은 입력 데이터 코너 사례들 또는 심지어 다른 알고리즘적 결함들을 이용하기 위해 가짜 인수들(bogus arguments)을 입력으로서 루틴에 피드하는 것에 의해 엉성하게 작성되었지만 다른 방식으로 유효한 코드를 이용하는 것을 포함할 수 있다. 다른 가능한 공격 방안들은 부적절한 또는 의도적으로 오류있는 결과들을 야기하는 방식으로 다른 적법한 코드에 의해 참조되는 (스택 포인터와 같은) 다양한 프로세서 레지스터들 또는 외부 메모리 장소들에 저장되어 있는 데이터를 독립적으로 수정하는 것을 포함한다.
이러한 종류의 제어가 영향을 받을 수 있는 다수의 메커니즘들이 있다. 이 시스템들은 프로세서를 이러한 종류의 의도하지 않은 사용으로부터 보호하려고 시도하는 간단한 방식들은 물론 복잡한 방식들도 포함한다. 하나의 상당히 안전하지만 복잡한 메커니즘은 코드 세그먼트의 실행 이전에 코드 세그먼트의 사전 암호화를 포함한다. 코드 세그먼트가 메모리로부터 프로세서로 로드되면, 이는 주의깊게 제어되는 상황 하에서 복호화되고 이어서 보안 방식으로 실행되어야만 한다(환언하면, 이는 복호화 동작과 이후의 실행 사이에서 수정되거나 변조되어서는 안된다). 이 메커니즘은 문제의 코드 세그먼트가 실행을 시작할 수 있기 전에 복호화될 때까지 프로세서가 기다려야만 하기 때문에 야기될 수 있는 성능 비효율을 겪는다. 실행될 특정의 코드 세그먼트의 선택과 실제의 사후 복호화 실행 사이의 이 지연 시간은 프로세서 파이프라인 스톨(processor pipeline stall) 및 데이터 경로 비효율은 물론 (복호화 동작과 실행 동작 사이에 코드를 장악하는 것에 의한) 잠재적인 공격들에 대한 다른 방안을 제공하는 것(이들로 제한되지 않음)을 비롯한 많은 문제들을 야기할 수 있다.
이 암호화된 코드 메커니즘은 또한 해커가 표면상 보호되는 암호화된 코드 세그먼트를 어떻게든 적절히 복호화하는(또는 그의 복호화된 사본을 획득하는) 것으로부터 프로세서를 보호하기 위해 아무것도 하지 않는다. 그 경우에, 해커는 그 보호되지 않은 코드를, 대상 프로세서 상에서 또는 어떤 다른 비허가된 프로세서 상에서 비제어된 방식으로 실행할 수 있을 것이다. 이와 같이, 코드가 평문으로(즉, 평문 형태로) 배포되는지 암호화된 형태로 배포되는지에 관계없이, 정확히 어느 코드 세그먼트들이 특정의 프로세서 또는 프로세서들 상에서 실행될 수 있는지에 대한 제어를 실시하는 방법을 찾아내는 것이 바람직하다. 다른 한편으로는, 특정의 프로세서 상에서 실행될 수 있는 코드가 어떤 사전 선택된 서브셋으로 제한되는 경우, 프로세서 자체의 범용 속성이 위반될 수 있다. 이것은 아마도 프로세서가 범용성이 떨어지도록 그리고 따라서 그의 잠재적 응용 프로그램 공간에서 훨씬 덜 유연하도록 아키텍처를 제약하는 효과를 가질 수 있다. 최대로 유연한 범용 프로세서 아키텍처에 대한 강한 욕구가 항상 있을 것이지만, 바로 그 프로세서들이 멀웨어 공격에 가장 취약하다.
이와 같이, 어떤 특정의 프로세서 아키텍처에 의존하지 않도록 충분히 범용적인 코드 실행 제어 방법이 필요하다. 이러한 방법이 또한 오브젝트 코드 밀도(object code density)에도 대상 프로세서의 실행 파이프라인에도 악영향을 미치지 않는 것이 유용할 것이다. 이와 동시에, 이러한 시스템들 및 방법들이 원래의 대상 프로세서 또는 어떤 다른 의도되지 않은 대상 프로세서 상에서의 다른 적법한 코드 세그먼트들의 라이센스 없는 사용에 대한 보호를 제공하는 것이 바람직하다. 이러한 방법은 소프트웨어 바이러스 및 멀웨어에 대한 제어를 위한 싸움에서의 귀중한 도구는 물론 디지털 콘텐츠의 세계에서의 저작권을 보호하는 독자적으로 강력한 메커니즘일 것이다.
그를 위해, 이제부터 범용 코드 블록의 실행에 대한 아주 구체적인 제어를 제공하고, 차례로 프로그래머가 주어진 코드 블록이 실행될 수 있는 정확한 상황을 결정할 수 있게 하는 시스템들 및 방법들의 실시예들을 살펴본다. 이 조건들은 코드 블록이 실행하려고 시도하는 개개의 디바이스, 코드 블록 호출되는 환경, 실행 시간, 실행 순서는 물론 특정의 실행 스레드에서 코드 블록이 호출된 횟수와 같은 제약조건들(이들로 제한되지 않음)을 포함할 수 있다.
이러한 제어 메커니즘은, 예를 들어, 재귀적 실행을 통해 하나의 실시예에서 구현된 한 세트의 피호출 코드 세그먼트들의 명시적으로 정렬된 실행(explicitly ordered execution)에 기초한 데이터 은폐(data hiding) 시스템 및 방법의 실시예들과 결합될 수 있다. 이 시스템들 및 방법들의 실시예들이 함께 이용될 때, 일반성이 방해받지 않는 것은 물론 많은 다른 보안 시스템들을 능가하는 공격에 대한 보호 레벨이 획득될 수 있다.
도 1은 기술된 실시예들이 효과적으로 이용될 수 있는 아키텍처의 전반적인 개요를 제공하는 반면, 도 2는 디지털 콘텐츠의 실행을 제어하거나 수신된 디지털 콘텐츠와 관련하여 보안 프로토콜들을 구현할 수 있는 대상 유닛의 하나의 실시예의 아키텍처를 도시한 것이다.
대상 유닛의 단방향 해시 함수 하드웨어에 관해 더 상세히 살펴보는 것이 이제 유용할 수 있다. 이제 도 36을 참조하면, 재귀적 보안 프로토콜의 하나의 반복에서 발생된 디지털 서명 동작의 결과를 차후의 반복에서의 단방향 해시 함수에 대한 씨드 값으로서 사용할 수 있는 단방향 해시 함수 블록의 하나의 실시예가 도시되어 있다. 하나의 실시예에서, 대상 유닛의 상태가 대상 유닛이 보안 실행 모드에서 동작하고 있는지 여부에 관한 것인 한, 그 상태가 본 명세서에서 "보안 모드 인에이블됨(Secured Mode Enabled)" 비트라고 지칭되고 있는 하드웨어 비트(3670)의 값에 의해 반영될 수 있다.
여기서, 이 하드웨어 비트의 기본 상태가 클리어될 수 있다(즉, 대상 프로세서의 기본 상태는 보안 실행 모드에서 동작하고 있는 것이 아니다). 특정의 실시예들에서 이 비트와 단방향 해시 함수 하드웨어 블록(3661) 간의 상호작용이 2개의 부분으로 기술될 수 있다. 제1 (비보안) 경우에, 비밀 하드웨어 키(3640)에 대한 모든 액세스들이 차단되는데, 그 이유는 "보안 모드 인에이블됨" 비트가 이 하드웨어 비트가 (예를 들어, "1"로) 세트되어 있을 때에만(그렇지만, 또한 유의할 점은 특정의 아키텍처들에서 비트가 "0"의 값을 가질 때 "세트"되는 것으로 간주될 수 있음) 비밀 하드웨어 키의 사용을 가능하게 위해 게이트키퍼(gatekeeper)로서 기능하기 때문이다. 또한 이 경우에, 단방향 해시 함수(3661)의 입력 "씨드"(3610)를 형성하기 위해 디지털 서명 레지스터(3664)의 출력이 피드백된다. 이와 같이, 프로세서가 이 "비보안 실행" 모드에서 동작하고 있을 때, 임의의 차후의 단방향 해시 함수 동작들에 대한 씨드를 형성하기 위해 단방향 해시 함수 동작들 중 임의의 것의 중간 결과들이 피드백된다. 이것은 한 세트의 내포된 또는 연접된 함수들의 호출 체인 전체의 연속 체크섬(running checksum) 등가물이 유지될 수 있게 한다. 실행되도록 시도되는 각각의 코드 블록이 이 단방향 해시 함수를 실행하도록 허용되기 전에 그 코드 블록이 그 해시 함수로 처음으로 평가되는 경우에, 임의의 주어진 코드 블록의 호출 체인 전체가 이 단일의 메커니즘으로 실질적으로 명확하게 결정될 수 있다.
마찬가지로, "보안 모드 인에이블됨" 비트가 세트되어 있는 경우(즉, 프로세서가 "보안 실행 모드"로 동작하고 있는 경우), 비밀 하드웨어 키가 액세스가능하다(환언하면, 직접 액세스가능하거나, 그의 값이 프로세서 자체에 의해 직접 액세스가능하지 않더라도 적어도 그의 값이 계산 동작에서 사용될 수 있음). 그에 부가하여, 보안 실행 모드에서 동작하고 있을 때, 단방향 해시 함수의 차후의 평가들을 위한 씨드 값을 형성하기 위해 디지털 서명 레지스터의 출력이 피드백되지 않는다. 이 디지털 서명 발생기 블록의 정확한 구현이 나중에 더 상세히 논의될 것이다. 그러면 알 수 있는 바와 같이, 특정의 실시예들에서, 특정의 코드 블록의 호출 체인 전체가 시스템 전반적인 소프트웨어 또는 하드웨어 검증(또는 증명(attestation)) 동작들과 같은 대책들을 이용할 필요 없이 그의 보안 실행 이전에 검증될 수 있다. 유의할 점은, 타임스탬프 레지스터에 대해 앞서 기술된 경우에서와 같이, 특정의 실시예들에서, 이 "보안 모드 인에이블됨" 비트는 구조적으로 프로세서에 보일 수 있거나 그렇지 않을 수 있지만, 그의 상태가 프로세서에 의해 명시적으로 설정되지 않을 수 있다. 이 하드웨어 비트가 비보안 코드 세그먼트를 호출하는 것에 의해 기본값으로 리셋될 수 있지만, 하나의 실시예에서, 이 비트가 세트될 수 있는 유일한 방식은 하드웨어 측에서의 직접적인 동작을 통하는 것이다. 비트가 구조적으로 보이는 경우에, 프로세서가 보안 실행 모드로 동작하고 있는지 여부가 명시적으로 판정될 수 있다. 비트가 구조적으로 보이지 않는 경우에, 그럼에도 불구하고, 판정이 하드웨어 비밀 키에 어떻게든 의존하는 값을 갖는 어떤 표현을 평가하는 것에 의해 암시적으로 행해질 수 있다.
코드 실행의 제어 및 보안 프로토콜들의 구현과 밀접한 관련이 있을 수 있는 주제들의 바탕을 이루는 기본적인 문제들을 더 상세히 기술하는 것이 이제 유용할 수 있다. 이어서, 앞서 기술한 하드웨어의 실시예들을 사용하여 임의적인 범용 프로세서 상에서의 임의적인 코드의 실행에 대한 제어를 어떻게 구현할지 및 이 시스템들 및 방법들의 실시예들이 효과적인 전체 보안 시스템을 구성하기 위해 보안 프로토콜들 및 시스템들에서 어떻게 효과적으로 이용될 수 있는지가 보여질 수 있다.
비밀 키 은폐
대부분의 상용 디지털 콘텐츠 배달 시스템들은 디지털 미디어 데이터를 복제되고 자유롭게 배포되는 것으로부터 보호하려고 시도하기 위해 어떤 형태의 암호화 또는 데이터 은폐를 포함한다. 대부분의 경우들에서, 데이터 은폐 전략은 궁극적으로 전혀 효과적이지 않은 콘텐츠 보호 수단인 것으로 입증되었다. 이 은폐가 성공적이지 못한 것으로 입증된 주된 이유들 중 하나는 노출로부터 보호되어야 하는 바로 그 데이터가 그럼에도 불구하고 임의의 허가된 당사자에 의해 자유롭게 사용될 수 있어야만 한다는 것이다. 이와 같이, 디지털 콘텐츠의 배포에 대한 한 세트의 겉보기에 상반된 요구사항들이 존재한다.
원본 디지털 콘텐츠가 모든 의도된 수신자들에 대해 개별적으로 암호화될 수 있고 의도된 수신자만이 배포된 디지털 콘텐츠를 실제로 사용할 수 있는 경우에, 시스템의 보안이 어쩌면 꽤 양호할 수 있다. 그렇지만, 다수의 특정의 조건들이 충족되지 않는 한, 이러한 종류의 시스템의 보안이 몇가지 측면들에서 결함이 있는 것으로 보여질 수 있다. 첫째, 이러한 시스템은 배포된 데이터 세트 전체가 각각의 의도된 수신자에 대해 개별적으로 재암호화되어야만 하는 것을 필요로 한다는 점에서 덜 효율적이다. 둘째, 배포자는 범용 프로세서 상에서 어떤 허가되지 않은 복호화도 가능하지 않도록 보장할 필요가 있을 수 있다. 셋째, 각각의 개별 수신 디바이스는 어떤 다른 종단점 디바이스 상에서 쉽제 복제될 수 없는 어떤 속성을 가져야만 한다는 점에서 독자적이어야만 한다. 이들 마지막 2개의 조건 중 어느 하나가 위반되는 경우, 이 시스템은 단순히 개별적으로 암호화된 데이터는 물론 그 데이터와 연관되어 있는 디바이스 관련 키 둘 다를 가로채기하는 것에 의한 공격에 취약하다.
사실, 이러한 시스템이 보안이 수신 디바이스들 각각의 독자적인 속성의 보안에 기초할 수 있다는 것이 보여질 수 있다. 이 독자적인 속성은 전형적으로 배포자 및 허가된 수신자만이 알고 있는 비밀 키를 사용하여 구현된다. 원칙적으로, 이러한 종류의 설정이 효과적인 보안 시스템일 수 있지만, 원본 디지털 콘텐츠가 각각의 수신자에 대해 개별적으로 암호화되어야 한다는 요구사항은 실제의 구현을 대부분의 목적들에 대해 실용적이지 않게 만든다. 원본 디지털 콘텐츠가 한번 암호화되고 모든 어쩌면 허가된 당사자들에 똑같이 배포되는 것이 요망되는 경우, 문제는 다시 데이터 은폐의 문제로 되돌아간다. 이 유형들의 문제들은 브로드캐스트 암호화(Broadcast Encryption)의 분야라고 한다.
거의 모든 종류의 배포된 비밀 데이터 시스템에서의 기본적인 문제들 중 하나는, 대부분의 경우들에서, 보안 시스템의 개별적인 엔터티들 사이에서 오고가는 메시지들 및 데이터 모두가 보통 공개되어 전송되고 따라서 도청자들에 의해 관찰가능하다는 것이다. 이와 같이, 이러한 시스템의 개개의 구성요소들 사이에서 전송되는 임의의 메시지들 또는 데이터는 허가되지 않은 당사자들에 의한 가로채기로부터 보호하기 위해 암호화되어야만 한다. 이러한 시스템에서 해결되어야만 하는 다른 문제는 임의의 이러한 비밀 데이터 전송에서의 송신기는 물론 수신기의 ID(identity)의 검증이다. 2개의 당사자들이 서로를 모르는 경우에, 상호 신뢰 중재자(mutually trusted intermediary) 전략이 통상적으로 이용된다.
그렇지만, 그에 부가하여, 비밀 데이터가 그의 목적지에 도착하면, 해결되어야만 하는 똑같이 어려운 문제는 그 비밀 데이터를 손상되지 않는 방식으로 어떻게 안전하게 사용할지이다. 이러한 사전 예방이 보통 필요한데, 그 이유는 적법한 종단점이라도 잘못된 정보를 제공하는 것에 의해 그의 보안을 손상시킬 수 있는 것도 가능하기 때문이다. 따라서, 배포 동안 허가되지 않은 발견으로부터 보호하는 것에 부가하여, 비밀 데이터의 다른 허가된 사용자에 의한 발견으로부터 그 비밀 데이터를 보호하는 것이 때때로 요망된다.
하나의 실시예에서, 실행 이전에 실시간으로 복호화되어야만 하는 구조적으로 은폐된 비밀 키 또는 암호화된 오브젝트 코드 블록의 간단한 시간 의존적 사용을 사용하여, 이러한 요망된 제어가 제어될 수 있다. 첫번째 경우에, 코드 블록 실행은 제어 메커니즘에 완전히 투명할 수 있고, 이는 실행 속도가 최소한으로 영향을 받아야만 한다는 것을 의미한다. 후자의 경우에, 실행될 코드 블록이 실행 이전에 복호화될 수 있고, 따라서 복호화 프로세스의 지연 시간으로 인해 동시적인 성능 손실이 있을 가능성이 아주 많다. 그렇지만, 이 후자의 경우에, 오브젝트 코드는 분해로부터 비교적 안전할 수 있고, 따라서 어쩌면 잠재적 공격자들이 와해시키기 더 어렵다. 본 명세서에서 나중에 논의되는 실시예들은 아주 안전한 암호화된 오브젝트 코드 방법으로부터 비교적 더 높은 성능이지만 그럼에도 불구하고 여전히 아주 안전한 선택적 이용가능 비밀 키 방법에 이르는 많은 가능한 해결책들에서 구현될 수 있는 시스템들 및 방법들을 개시하고 있다.
하나의 실시예에서, 비밀 키를 이러한 비밀 키의 사용자에게 은폐시키는 것은 하버드 아키텍처(Harvard Architecture) 메모리 공간 양분과 유사한 방법에서 달성될 수 있다. 그렇지만, 이 실시예에서, 비밀 키가 암호화/복호화 계산에서 사용될 수 있지만 실제로는 프로세서에 의해 결코 직접 판독될 수 없다는 구별이 행해질 수 있다. 이 구별은 암호화/복호화 동작들을 하드웨어로 구현되거나 하드웨어의 설계 시에 정해지는 사전 결정된 소프트웨어 매크로들(마이크로 코드라고도 함)인 것들로 제한하는 것에 의해 실시될 수 있다. 예를 들어, 하드웨어 비밀 키가 어떤 임의적인 코드에 의해 사용될 수 있는 경우에, 비록 그것이 프로세서에 의해 직접 판독될 수 없지만, 그럼에도 불구하고, 그는 간단한 계산들에 의해 용이하게 결정될 수 있다. 이와 같이, 이러한 코드 세그먼트들을 더 범용적이지만 덜 안전한 코드 블록들과 구분하기 위해 보안 관련 계산들만이 하드웨어 비밀 키에 액세스할 수 있도록 명시하는 것이 요망될 수 있다.
특정의 실시예들에서, 이 구분은 본 명세서에 기술되는 것들과 실질적으로 유사한 검증 방법들을 이용하여 달성될 수 있다. 앞서 기술된 적응적 디지털 서명 방법들의 실시예들이 하드웨어 비밀 키가 액세스될 수 있는지를 판정하는 데 이용되는 경우, 대상 프로세서가 보안 관련 계산들(즉, 대상 프로세서가 "보안 실행" 모드로 동작하고 있을 때 수행되는 계산들) 및 보호되지 않는 것들을 실행하고 있는지가 용이하게 그리고 신뢰성있게 판정될 수 있다. 그에 부가하여, 최종적인 계산들이 완료되고 완전히 디코딩된 결과가 보고될 때까지 임의의 중간 키 결과들을 발견되지 못하게 은폐된 채로 유지하기 위해, 앞서 개략적으로 기술한 것들과 실질적으로 유사한 재귀적 방법들이 이용될 수 있다. 이와 같이, 본 명세서에 기술된 실시예들은 동일한 비트스트림을 발생시키는 데 사용되는 비밀 전역 키를 노출시키는 일 없이 암호화된 디지털 비트스트림을 디코딩할 수 있다.
코드 실행 제어
특정의 코드 세그먼트가 주어진 프로세서 상에서 안전하게 실행되도록 보장하는 방법들이 수년 동안 널리 연구되어 왔다. 보안 코드 실행 보호물을 생성하려는 이전의 시도들 중 일부는 한 세트의 "특권" 명령어들(privileged instructions)을 설정하기 위해 프로세서 아키텍처를 수정하는 것을 포함한다. 프로세서가 "수퍼바이저" 또는 "커널" 모드라고 하는 특정의 모드로 실행 중일 때만 이 특권 명령어들이 실행될 수 있도록 아키텍처를 설계하는 것에 의해 이 특권 명령어들이 보호되었다. 프로세서 아키텍처의 이러한 종류의 양분은 프로세서 잠재적인 일반성의 상실은 물론 잠재적인 성능의 열화 둘 다를 비롯한 다수의 단점들을 가진다. 이 단점들에 부가하여, 이러한 보호 대책들은 종종 표준 시스템 루틴들에 대한 특별히 설계된 소프트웨어 호출들을, 프로세서가 수퍼바이저 모드로 실행 중인 동안 예상되지 않은 실행 경로들을 이용하는 방식으로, 사용함으로써 우회될 수 있다. 이러한 특별히 설계된 멀웨어 공격들의 예들은 소위 "스택 오버플로우(stack overflow)", "스택 오버런(stack overrun)" 및 "코드 삽입(code injection)" 공격들을 포함한다.
대체로 다양한 체크섬 검증(checksum verification) 또는 인수 범위 검사(argument bounds checking) 수단들에 기초하여, 이러한 종류의 익스플로이트들로부터 보호하는 것을 돕기 위해 다수의 전략들이 고안되었다. 이러한 종류의 보호 대책들에도 불구하고, 다형적 바이러스들(polymorphic viruses)(즉, 자체 수정 코드(self-modifying code))을 비롯한 각종의 대항책들이 진화하였다. 범위 검사에 불구하고 프로세서 약점들을 이용하는 다른 전략들은 범위 검사 "수퍼바이저" 루틴 자체를 단순히 우회하는 것을 포함한다. 다양한 복사 방지 시스템들을 회피하는 데 이러한 종류의 익스플로이트가 또한 아주 종종 사용된다. 밝혀진 바와 같이, 수퍼바이저 루틴을 장악하는 전략은 컴퓨터 보안의 세계에 독자적인 것은 아니며, 전혀 새로운 개념이 아니다. 사실, 바로 이 문제는 각종의 응용들에서 유사점들을 가지며, 플라톤의 저서 "국가론"까지 거슬러 올라가 참조되고 있다. 기본적인 문제는, 임의의 주어진 시스템에서, 구조의 궁극적인 보안 또는 안정성을 위임받고 있는 어떤 종류의 전역 수퍼바이저를 항상 식별할 수 있다는 것이다. 모든 차후의 보안 기능에 대한 전역적 기초인 이러한 개념이 보안 시스템들의 최근의 연구에서 "신뢰 근간"이라고 한다.
보다 최근에, 프로세서가 명령어들을 페치하고 있는 메모리 세그먼트들을 속성이 판독 전용인 것으로 제한함으로써(이것은 소위 W^X 또는 "기입-XOR-실행(write-XOR-execute)" 방식을 포함함) 수퍼바이저 루틴 공격들로부터 프로세서를 보호하려는 어떤 시도들이 있었다. 다른 범용 컴퓨터의 메모리 공간을 데이터 기반 및 코드 기반 파티션들로 분할하는 개념은 소위 "하버드 아키텍처"의 변형으로 볼 수 있다. 이 방법은 보호 메커니즘과 연관되어 있는 특정의 성능 저하(performance penalty)는 물론 메모리 이용률의 동시적인 증가를 가진다. 마지막으로, 심지어 이러한 종류의 방어들이 소위 "반환 기반(return-based)" 프로그래밍 익스플로이트들의 사용에 의해 또는 심지어 간단한 메모리-앨리어싱 익스플로이트들(memory-aliasing exploits)에 의해 우회될 수 있다는 것이 또한 최근에 밝혀졌으며, 여기서 2개의 개별적인 실행 스레드들은 상이한 모드들에서(하나는 "데이터 모드"에 있고 다른 것은 "실행 모드"에 있음) 동일한 메모리 블록을 참조할 수 있다.
프로세서의 실행 스레드를 장악되는 것으로부터 보호하는 다른 제안된 수단은 암호화된 코드 블록들의 사용을 포함한다. 이 방법에서, 실행될 코드 세그먼트들은 사전 암호화되고, 따라서 그의 프로세서에의 로딩 이전에, 비판독가능하다(아마도 훨씬 더 중요한 것은 비변경가능하다는 것임). 이 방법은 또한 몇가지 약점들을 가진다. 첫째, 코드 세그먼트 자체는 보호될 수 있지만, 인수들이 꼭 동일한 수준의 보안을 제공받지는 않는다. 이와 같이, 완전히 적법하고 안전한 코드 세그먼트가 그럼에도 불구하고 그로 하여금 예측되지 않은 방식으로 거동하게 할 수 있는 가짜 인수들을 그의 호출 루틴으로부터 제공받을 수 있다. 둘째, 어떤 경우들에서, 실행 스레드는 앞서 기술한 반환 기반 프로그래밍 공격들로부터 꼭 보호되지는 않는다. 또한, 프로세서 버스가 공격자에 의해 용이하게 관찰될 수 있는 경우, (비록 암호화되어 있지만) 올바르게 실행되는 코드 세그먼트들은 물론 실행가능 스트림에 삽입된 부적절하게 암호화된 코드 세그먼트들에 의해 야기되는 예외 장애들의 관찰 둘 다의 장기 관찰은 수정된 사전 공격(dictionary attack) 방법을 사용하여 암호화 키를 노출시키는 데 도움을 줄 수 있다. 마지막으로, 이러한 시스템에서의 프로세서 성능이 필연적으로 유사하지만 비암호화된 코드 시스템들보다 심각하게 열화된다. 이이 성능 저하는 다수의 문제들에 의해 야기될 수 있고, 그 문제들 중 가장 중요한 것은 코드 블록이 메모리로부터 페치될 때와 실행될 수 있을 때 사이에 코드 블록의 요구된 복호화에 의해 야기되는 지연 시간이다. 대부분의 최근의 프로세서들이 (다양한 수단들에 의해) 병렬로 실행될 수 있는 명령어들의 수를 증가시키려고 시도하기 위해 파이프라이닝 메커니즘을 사용하지만, 암호화된 코드 블록은 먼저 복호화되고 나서 이러한 파이프라인 내로 판독될 수 있다. 코드가 빈번히 분기하는 경우에, 복호화 프로세스는, 하드웨어 보조 복호화에서도, 어쩌면 코드 실행 자체보다 더 오래 걸릴 수 있다.
본 발명에 기술된 시스템들 및 방법들의 실시예들은 암호화되지 않은 코드 블록들의 이용을 가능하게 할 수 있고, 따라서 암호화된 실행 파일들과 연관되어 있는 성능 저하가 따라서 별로 문제가 되지 않는다. 그렇지만, 실행 효율이 중요한 관심사가 아닌 경우에, 암호화된 코드 블록들이 여전히 이용될 수 있다. 이와 같이, 본 명세서에 개시된 실시예들은 동일하거나 유사한 방법들 및 시스템들을 이용하여 평문 실행 파일들의 효율은 물론 암호화된 코드 세그먼트들의 부가된 보안 둘 다를 가질 수 있다. 그에 부가하여, 본 명세서에 기술되어 있는 보안 시스템들 및 방법들의 실시예들은 새로 발견된 보안 관심사들을 해결하기 위해서는 물론 일 실시예가 이미 배포된 후에 새로운 기능을 추가하기 위해서도 현장에서 업데이트될 수 있다.
본 발명의 실시예들은, 그 중에서도 특히, "보안 코드 세그먼트"가 암호 해싱 함수에 의해 실행 이전에 검증되도록 보장하는 것에 의해 이 장점들을 달성할 수 있다. 이 검증은, 예를 들어, 이러한 보안 코드 세그먼트에 대해 생성된 메시지 다이제스트 또는 디지털 서명을 인증함으로써 달성될 수 있다. 디지털 서명을 형성하기 위해 앞서 기술된 바와 같이 얻어진 메시지 다이제스트의 암호화와 관련하여 복합 키 구조를 사용하여 이 암호 해싱 함수의 평가가 행해지는 경우에, 특정의 코드 블록이 특정의 대상 유닛 또는 프로세서와 일의적으로 연관되어 있을 수 있다. 이 프로세스는, 특정의 실시예들에서, 이 보안 코드 블록이 복합 키 기반 디지털 서명을 사용하여 특정의 대상 유닛에 암호적으로 바인딩될 수 있다는 사실에 기초하여, 본 명세서에서 "보안 코드 바인딩(secured code binding)"이라고 지칭될 것이다.
이러한 해싱 함수를 실행하는 것이 자원을 필요로 하지 않는 것(resource free)은 아닐 수 있지만, 이 방식의 장점은 그의 암호 검증을 완료하기 전에 보안 코드 세그먼트가 실행 파이프라인에 도입될 수 있다는 것이다. 이와 같이, 해싱 함수가 어쩌면 (투기적 분기 실행과 유사한 방식으로) 보안 코드 세그먼트 자체의 실행과 병렬로 평가될 수 있다. 이 실시예에서, 얻어진 메시지 다이제스트가 정품인 것으로 판정되는 경우에만 보안 코드 세그먼트의 결과들이 이용될 수 있다. 그렇지만, 다른 실시예에서, 보안 코드 세그먼트의 결과들이 차후의 동작들에서 이용될 수 있지만, 결과들 자체가 프로세서가 보안 실행 모드로 동작하고 있는지 여부에 따라 상이할 수 있다. 이 실시예는 디지털 서명에서 사용하기 위한 복합 키의 평가에 대해 앞서 기술된 프로세스와 실질적으로 유사하고, 도 36에 도시된 것과 같은 하드웨어의 사용에 의해 발생될 수 있다.
그렇지만, 암호 검증의 사용은 암호화된 코드 세그먼트들의 사용을 배제하지 않는다. 사실, 정확하게 복호화된 코드(임의의 유형의 암호화를 적용하기 전의 그의 원래의 상태에 있는 보안 코드 세그먼트)의 메시지 다이제스트 또는 디지털 서명의 사용은 부가의 보호 레벨을 제공할 수 있다. 이것은 장래의 공격자가 위조 메시지 다이제스트를 생성하기 위해 정확히 복호화된 코드 블록에 대한 사전 지식을 가질 필요가 있다는 사실로 인한 것이다. 이와 같이, 코드 세그먼트 검증은 물론 암호화된 코드 방법들 둘 다가 동시에 사용될 수 있는 경우, 공격에 대한 더 높은 강건성이 실현될 수 있다.
그렇지만, 역시 실현될 수 있기 때문에, 이러한 해싱 검증이 우회될 수 있는 몇가지 방법들이 있고, 그 중 가장 간단한 것은 해싱 함수 자체를 와해시키는 것이다. (예를 들어, 하드웨어 해싱 함수를 이용하는 것에 의한) 특정의 실시예들에서 이 전략이 가능하지 않은 것으로 가정되더라도, 적절히 검증된 메시지 다이제스트와 함께 위장자 코드 세그먼트(impostor code segment)를 제공하는 것에 의해 이러한 실시예의 보안을 공격하는 것이 여전히 가능할 수 있다. 디지털 서명을 형성하기 위해 많은 메시지 다이제스트들이 실제로 암호화되기 때문에, 표면상, 이 공격 전략은 겉보기에 어려운 것으로 판명될 것이다. 그렇지만, 심지어 디지털 서명 메커니즘이 어쩌면 디지털 서명의 공개 키 탐색 부분을 스푸핑하고 따라서 위장자 디지털 서명의 인위적 검증을 제공하는 것에 의해 또는, 다른 대안으로서, 서명 검증 루틴 자체의 악의적 와해에 의해 공격받을 수 있다.
이 제한들은 본 명세서에 개시된 시스템들 및 방법들의 실시예들에서 보안 코드 세그먼트와 연관되어 있는 메시지 다이제스트를 두번 암호화하는 것에 의해 ― (전역) "저작자" 비밀 키로 한번 그리고 이어서 (실제로 원래의 칩 제조업체는 아니라 보조 레벨 배포자, 시스템 통합자, 서비스 제공자 등일 수 있는) 종단점 "제조업체" 및 문제의 코드 세그먼트가 실행될 특정의 종단점 디바이스만이 알고 있는 비밀 키로 또다시 한번 ― 극복된다. 이 실시예의 장점은, 상기한 디지털 서명이 유사한 종단점 디바이스들 사이에서 공유되더라도, 상이한 대상 유닛들의 비밀 키들이 상이할 것이기 때문에, 그 디지털 서명이 그의 의도된 대상 유닛 상에서만 정확하게 기능한다는 것이다. 이와 같이, 임의의 이러한 디지털 서명이 평문으로 전송되고 저장될 수 있다.
(소위 "계층화된 키" 시스템들에서는 물론 재귀적 보안 시스템에서도 사용될 수 있는) 비밀을 두번 암호화하는 기법들의 실시예들은, 부정확하게 사용되는 경우, 특정의 문제들을 가질 수 있다. 첫째, 이러한 계층화된 암호화 프로세스의 중간 결과가 가로채기되는 경우, 이 중간 키는 모든 이러한 시스템들에서 상위 레벨 보안을 우회하는 데 사용될 수 있다. 또한 유의할 점은, 이러한 계층화된 시스템의 "최하위 계층"에서, 이 중간 결과는 실제로, 발견되는 경우, 모든 실질적으로 유사한 종단점 디바이스들에 대한 전체 보안 시스템을 우회하는 데 사용될 수 있는 "전역" 복호화 키이다. 이러한 종류의 "가로채기" 공격은 복호화 프로세스 동안 임의의 메모리 트랜잭션들을 단순히 기다리는 것 및 이어서 잠재적 전역 암호화 키가 있는지 모든 이러한 메모리 장소들을 검사하는 것에 의해 2번 이상 행해져 왔다. 복호화 프로세스 동안 모든 메모리 액세스들을 기다리는 프로세스는 처음에는 번거로운 것처럼 보일 수 있지만, 거의 확실히 이러한 비밀 키의 값의 무작위 추측(brute-force guessing)보다 더 효율적인 공격 전략이다. 계층화된 키 시스템에서의 제2 잠재적 약점이 재생 공격의 변형에 의해 이용될 수 있다. 계층화된 키 시스템의 보안이 손상되고 그의 키들이 업데이트되어야만 하는 경우에, 원래의 시스템이 그의 이전의 상태로 다시 리셋되면 또는 그의 이전의 상태가 위장자 유닛에 의해 복제되면 이전의 (손상된) 키들이 여전히 사용될 수 있다.
이 약점들이 "계층화된 키" 구조와 달리 "복합 키"라고 하는 것을 사용하여 본 명세서에서 논의된 실시예들에서 해결될 수 있다. 복합 키와 계층화된 키 사이의 주된 차이점들 중 하나는 전자의 모든 세그먼트들이 단일의 모놀리딕 패스에서 평가될 수 있다는 것이다. 이와 달리, 계층화된 키 시스템에서, "가장 바깥쪽" 계층 키가 먼저 평가되고, 그 다음의 가장 안쪽 키(이는 이어서 그 다음 계층의 키를 생성하기 위해 인수로서 사용되고, 전체 키 스택이 순회될 때까지 계속됨)를 반환할 수 있다. 이 시스템에서의 문제점은 하위 레벨 키들이 가로채기되고 나중에 사용되어, 사실상 가장 바깥쪽 보안 계층들을 우회할 수 있다는 것이다. 따라서, 이러한 계층화된 키 실시예들에서, 가장 중요한 (이 경우에, 전역) 키들은 체인에서 마지막으로 생성되고 사용되는 것들이고, 여기서 임의의 부가적인 (또는 더 최근의) 보안 계층들이 전혀 존재하지 않는다.
이 때문에, 이러한 보안 스택이 "내부에서 외부로(inside out)" 순회되도록 이 스택을 순회하는 더 강건한 방식이 이용될 수 있다. 이것은 보안 체인에 대한 가장 최근의 부가들이 시퀀스에서 처음으로 실행되지만 사실은 보안 시스템의 가장 안쪽 계층에 위치해 있는 것들이라는 것을 의미한다. 그에 따라, 이러한 "인사이드 아웃(inside out)" 실행 순서를 실시하기 위해 실시예들이 사용될 수 있다. 코드 스택 순회의 이 특정의 순서는 간단한 반복 방식을 사용하여 달성될 수 있고, 여기서 코드 루프는 먼저 현재의 보안 레벨을 평가하고 이어서 그에 따라 분기한다. 그렇지만, 반복적 방법에서, 보안 시스템 순회의 중간 결과들이 어쩌면 우회될 수 있는데, 그 이유는, 앞서 살펴본 바와 같이, 공격자가 시스템의 위조된 "이전의" 버전을 복제하기 위해 그 다음 하위 레벨 키가 적법한 보안 시스템 순회에서 노출되기를 단순히 기다리고 이어서 그 가로채기된 키를 사용할 수 있기 때문이다. 이와 같이, 이 "인사이드 아웃" 실행 순서를 실시할 수 있을 뿐만 아니라 중간 결과들을 악의적 코드 또는 다른 공지된 보안 시스템 익스플로이트들에 의해 가로채기되는 것으로부터 보호할 수 있는 시스템들 및 방법들의 실시예들이 기술되어 있다.
이러한 "인사이드 아웃" 보안 방식을 사용할 때의 다른 주된 장점은 호출 인수들의 전체 시퀀스가 보안 시스템의 가장 안쪽 계층(그리고 따라서 가장 최근의 버전)에 보일 수 있다는 것이다. 이 "인사이드 아웃" 실행 시퀀스가 적절히 구현되는 경우, 이러한 시스템에서 이용되는 정확히 구성된 범위 검사 메커니즘들이 호출 체인 전체에 대한 가시성을 가질 수 있다는 것을 알 수 있다. 이와 같이, 실시예들은 상당한 양의 시스템 증명 기능과 보통 연관되어 있는 어떤 부가의 성능 저하를 야기하는 일 없이 이러한 기능을 수행하기 위한 내장된 메커니즘을 가질 수 있다.
그에 따라, 특정의 실시예들은 중간 키들이 상위 레벨(그리고 따라서 덜 안전한) 보안 시스템 루틴들에 노출되지 않게 하는 것은 물론 적절한 보안 스택 순회 방법을 보장하는 수단을 이용할 수 있다. 이것을 달성하기 위한 하나의 이러한 방법은 재귀적 보안 구조를 사용하는 것이며, 그의 하나의 실시예는 2003년 6월 19일자로 출원된, 발명의 명칭이 "디지털 저작권 관리의 재귀적 보안 프로토콜에 대한 방법 및 시스템(Method and System for a Recursive Security Protocol for Digital Copyright Control)"인 William V. Oxford의 미국 특허 출원 제10/465,274호(그 후에 2007년 4월 10일자로 미국 특허 제7,203,844호로서 특허되었음)(모든 목적들을 위해 참조 문헌으로서 본 명세서에 포함됨)에 나타내어져 있다.
이러한 재귀적 보안 프로토콜들의 실시예들이 이용되는 경우, 특정의 장점들이 실현될 수 있다. 첫째, 스택 순서 순회(stack order traversal)가 "내부에서 외부로" 평가되어야만 하도록 설계될 수 있다. 이것은 가장 최근의 보안 시스템 부가들이 먼저 실행되고 이 시스템이 (예를 들어, "반환 기반" 프로그래밍 익스플로이트들에서 사용되는 바와 같이) "중간에서 시작"될 수 없다는 것을 의미한다. 재귀적 시스템의 제2 장점은 보안 시스템에 대한 임의의 업데이트들의 부가가 보안 시스템 자체에서의 원래의 호출 인수들을 변경하지 않을 수 있다는 것이다. 그에 따라, 전통적인 재생 기반 공격 메커니즘을 사용하여 보안 시스템을 스푸핑하는 것이 더 어려울 수 있다. 본 명세서에 개시된 실시예들이 반복적 방식에서 역순서로 인라인 실행 스택(inline execution stack)을 이용하는 것이 확실히 가능하지만, 반복적 메커니즘은 중단을 겪을 수 있고, 따라서 또한 보안 스택의 부분 평가가 수행되는 상황을 야기하는 것이 가능할 수 있다. 이것은 어쩌면 하나 이상의 중간 결과들이 외부 관찰자들에 의해 가로채기될 수 있게 한다. 본 명세서에서의 실시예들에 의해 이용될 수 있는 바와 같이 재귀를 통해 구현되는 인사이드 아웃 보안 시스템에서, 중간 결과들이 임의의 시점에서 인수로서 그 다음 레벨 루틴으로 전달될 수 없고, 현재 실행 중인 보안 시스템 계층의 최종 결과들만이 보안 시스템 스택에서의 그 다음 위쪽 레벨에 의해 이용가능하다.
특정의 실시예들에서, 복합 키 구조는 또한 대상 유닛의 비밀 키에의 액세스를 엄격하게 제어하는 것에 의해 부분 평가로부터 보호될 수 있다. 예를 들어, 비밀 키가 구조적으로 보이지 않는 액세스가능하지 않은 메모리 장소에 저장되는 경우, 이는 단지 특정의 보안 관련 명령어 또는 함수의 일부로서 액세스될 수 있다. 특정의 실시예들에서, 이 함수 또는 명령어는, 비단순(non-trivial) 단방향 변환과 같은, 쉽게 반전되지 않을 수 있는 것이다. 그와 같이, 심지어 위조 보안 시스템도 비밀 키의 값을 노출시킬 수 없어야 한다. 그 결과, 단지 비밀 키가 단방향 함수의 일부로서 간접적으로 참조되게 하는 것에 의해, 비밀 키가 그 자체로 수학적 연산의 일부로서 결코 사용될 수 없고 단독으로 또는 어떤 다른 데이터와 함께 단지 해싱 연산의 일부로서만 사용될 수 있기 때문에, 비밀 키가 보호될 수 있고, 여기서 해싱 함수의 결과만이 관찰가능할 수 있다.
특정의 실시예들에서, 비밀 키를 보호하는 부가의 메커니즘들이 또한 유용한 것으로 판명될 수 있다. 하나의 이러한 잠재적인 메커니즘은 복합 키의 사용이고, 여기서 대상 유닛의 비밀 키는 어떤 다른 제약조건 또는 한 세트의 부가의 피연산자들에 밀접하게 결합되어 있다. 이러한 보조 피연산자의 예들은 별도의 비밀 키, (타임스탬프 또는 시스템 버전 번호와 같은) 전역적으로 보이는 레지스터(globally visible register), 비밀 키에 액세스하고 있는 코드의 메시지 다이제스트 등을 포함할 수 있다. 이러한 시스템의 실시예들에서, 이 마지막 예는 비밀 키가 바로 그 키를 사용하도록 허가되어 있는 코드 세그먼트에 의해서만 액세스될 수 있도록 보장할 수 있다. 게다가, 디지털 서명을 형성하기 위해 메시지 다이제스트가 암호화되는 경우 그리고 그 메시지 다이제스트를 암호화하는 데 사용되는 키가 비밀 키 자체인 경우, 비밀 키에 액세스하는 유일한 방법이 그 비밀 키가 무엇인지를 이미 알고 있는 누군가에 의해 저장된 코드 세그먼트를 사용하는 것임을 보장할 수 있는 의존 관계들의 원이 생성될 수 있다.
이 경우에, 복합 키 구조의 사용은 대상 유닛이 그 키를 사용하도록 허용되기 전에 대상 유닛의 비밀 키의 사용을 요청하는 코드 단편의 "권한(authority)"을 검증할 수 있게 한다. "계층화된 키" 구조와 "복합 키" 구조 사이의 차이점이, 특정의 실시예들에서, 후자가 원자적 방식(이 자체가 재귀적 수단에 의해 달성될 수 있음)으로 평가될 수 있다는 것임을 상기하자. 재귀적 구조와 달리, 반복적 방식을 사용하여 유사한 구조를 조립하는 것이 시도되는 경우, 키 평가 프로세스의 중간 결과들을 노출시킬(그리고 따라서 어쩌면 비밀 키를 노출시킬) 위험이 있을 수 있다. 비밀 키들(또는 그의 조상들)이 인터럽트가 일어날 때 메인 메모리로 푸시아웃되는 범용 레지스터들과 같은 공개적으로 이용가능한 장소들에(또는 심지어 메모리 자체에 직접) 저장될 때 "노출"이 일어날 수 있다.
특정의 실시예들에서 해결될 수 있는 잠재적인 보안 붕괴는 보안 스택 동작이 평가 중에 인터럽트될 때의 부분 결과들의 보호이고 대상 유닛의 프로세서의 상태가 이어서 메인 메모리에 기입되며, 여기서 이는 외부 관찰자들에 의한 검사에 노출되어 있다. 하나의 실시예에서, 이 메모리 "노출"을 방지하기 위해, 프로세서가 보안 실행 모드에 있는 동안 힙 푸시(heap push)가 허용되지 않는다. 그 조건이 시행되는 경우, 재귀적 보안 프로토콜은 (중간 인수들이 없기 때문에) 그의 현재 상태를 상실함이 없이 인터럽트될 수 없다. 유의할 점은, 재귀적 보안 프로토콜의 실시예들에서, 재귀가 종료될 때 보안 프로토콜 전체가 순회되었고, 프로세서는 보안 실행 모드에서 실행되고 있으며, 따라서 인터럽트 이외의 임의의 경우에 임의의 인수들의 힙으로의 푸시가 더 이상 없을 수 있다. 이와 같이, 복합 키 평가가 임의의 시점에서 인터럽트되는 경우 그리고 보안 실행 모드에서 힙 푸시가 허용되지 않는 경우, 보안 시스템 스택 순회가 실행 중에 재시작되지 않을 수 있다(즉, 계산이 처음부터 재시작되어야 함). 이와 같이, 임의의 중간 결과들이 시스템 힙에 저장되는 것(그리고 따라서 허가되지 않은 관찰자들에 어쩌면 노출되는 것)을 방지하기 위해 재귀적 보안 프로토콜이 이 방식으로 사용될 수 있다. 물론, 특정의 실시예들에서, 재귀적 보안 시스템 평가 동안 힙 동작들을 디스에이블시키는 것이 가능하고, 따라서 이러한 인터럽트된 보안 시스템 동작이 처음부터 재시작되어야만 하는 것을 사실상 필요로 한다. 그렇지만, 이러한 반복적 방식은 "인사이드 아웃" 실행 순서, "반환 기반" 프로그래밍 익스플로이트들에 대한 보호, 원래의 함수에 대한 호출 인수들을 변경하지 않는 방식으로 후속 보안 계층들을 부가할 수 있는 것은 물론, 중간 결과들 및 최종적인 함수 출력 결과들의 격리와 같은, 재귀적 구조가 제공하는 조건들 전부를 시행하지는 않을 수 있다. 보안 시스템 재귀가 종료되고 프로세서가 보안 실행 모드에 진입하도록 허용되는 메커니즘에 대해 더 상세히 기술할 것이다.
재귀의 종료
하나의 실시예에서, 주어진 코드 세그먼트의 메시지 다이제스트가 코드 세그먼트 자체와 함께 제공된 것과 일치할 때 종료하도록 재귀가 신호될 수 있다. 메시지 다이제스트가 하드웨어 해싱 함수에 의해 계산되는 경우, 이 방법이 공격에 대해 더 강건하게 될 수 있다. 특정의 실시예들에서, 디지털 서명이 또한 이용될 수 있다. 디지털 서명 메커니즘은 적어도 2개의 주된 속성들을 제공할 가능성이 있다: 1) 코드 세그먼트가 변조되지 않았다는 확신 및 2) 코드 세그먼트 저작자의 즉각적인 식별. 그렇지만, 이러한 디지털 서명이 공개적으로 보이거나 수정가능한 장소들에 캐싱되는 실시예들의 경우에, 디지털 서명 자체가 언제라도 수정될 수 있고 따라서 꼭 정품인 것은 아닐 수 있기 때문에, 부가의 보안이 요망될 수 있다. 따라서, 이 유형의 실시예들에서, 디지털 서명을 검증하기 위해 공개 키 시스템이 사용될 수 있거나, 문제의 코드 세그먼트와 함께 제공된 디지털 서명이 대상 유닛의 비밀 키를 소유하고 있는 어떤 당사자에 의해 생성되었다는 것을 보장하기 위해 (앞서 기술한 바와 같은) 복합 키 구조가 사용될 수 있다. 후자의 경우에, 그 복합 키의 사용이 또한 단일의 종단점 또는 어떤 종단점들의 세트로 제한될 수 있다. 그에 부가하여, 공개 키 방식은 물론 복합 키 방식 둘 다가 함께 이용될 수 있다. 그러한 방식으로, 코드 세그먼트가 정품이라는 것은 물론 코드 세그먼트가 복합 디지털 서명의 수신자로 보내지게 되어 있다는 것도 보장될 수 있다.
특정의 실시예들에서, 대상 유닛 상의 보안 메커니즘들을 검증하는 것이 또한 요망될 수 있다. 대상 디바이스 상의 보안 시스템의 임의의 하나의 세그먼트에 대한 하드웨어 발생 디지털 서명이 이용될 수 있는 반면, 보안 시스템이 재귀적인 경우에, 보안 시스템 자체가 순회될 때 구별되는 디지털 서명이 실질적으로 자동으로 발생될 수 있다. 앞서 언급한 바와 같이, 재귀적 보안 프로토콜의 실행이 종료되면, 호출 체인 전체가 노출된다. 이와 같이, 보안 프로토콜의 가장 안쪽(그리고 따라서 가장 최근의) 부분은, 어쩌면 스택 상에 저장된 호출 인수들은 물론 시스템 힙(system heap)에(또는 심지어 메모리에서의 다른 곳에) 저장되어 있는 다른 환경 변수들을 포함하는, 그것이 호출된 전체 환경에 액세스한다. 이 내장된 시스템 증명 메커니즘은 특히 효율적인 것은 물론 공격에 대해 강건한데, 그 이유는 그것이 보안 프로토콜 자체의 순회와 동시에 평가되기 때문이다.
하나의 실시예에서, 이어서, 보안 시스템 스택 순회의 "실행 단계" 이전에 준비되어 있어야만 하는 한 세트의 조건들이 명시될 수 있다. 하나의 실시예에서, 이 조건들은 개별적으로 요구된 보안 조건들 모두의 "교집합"으로서 표현될 수 있다. 그러한 방식으로, 새로운 보안 위험들이 발견될 때, 그 위험들을 고려하는 부가의 조건들이 쉽게 준비될 수 있다. 이 조건들은 새로운 조건들 및 이전의 조건들 모두가 충족될 때까지 보안 시스템의 어느 부분도 실행되도록 허용되지 않도록 보장할 수 있다. 다양한 보안 시스템 조건들의 이 "교집합"은 앞서 논의된 바와 같은 복합 키 구조 메커니즘의 사용을 통해 달성될 수 있다. 예를 들어, 이러한 복합 키 구조의 구성요소들 중 하나가 대상 유닛의 비밀 키에 부분적으로 기초하는 경우, 이 비밀 키는 전체 보안 시스템의 "신뢰 근간"의 하나로서 간주될 수 있다. 게다가, 하드웨어 기반 타임스탬프 메커니즘이 복합 키의 다른 구성요소들 중 하나로서 이용되는 경우, 시스템이 재생 공격들로부터 더 잘 보호될 수 있다. 특정의 실시예들에서, 다른 조건들을 시행하기 위해 이용될 수 있는 상기한 것들 이외의 다수의 구성요소들이 있다. 이러한 구성요소들은, 코드가 변조된 경우 키가 적절히 평가되지 못하게 하기 위해, 코드 블록의 메시지 다이제스트의 하드웨어 기반 해시 계산을 복합 키의 일부로서 사용하는 것을 포함한다. 하나의 실시예에서, 다른 이러한 구성요소는 실행될 코드 블록의 호출 인수들의 어떤 선택된 서브셋의 디지털 서명일 수 있고, 이는 스택 오버플로우 스타일 공격들로부터 보호할 수 있다.
코드 세그먼트가 타임스탬프 또는 사용 관련 제한들과 같은 그의 실행에 관한 다른 제약조건들을 가지는 경우에, 특정의 실시예들에서, 그 제약조건들이 또한 적절히 시행되도록 보장하기 위해 추가적인 조건들이 복합 디지털 서명에 추가될 수 있다. 유의할 점은, 중간 보안 토큰들의 정확한 평가에 기초하여, 시스템의 각각의 계층 내에서 적절한 코드 분기를 시행함으로써 다양한 보안 스택 계층들을 통해 특정의 다수의 반복을 강요하기 위해 이 동일한 메커니즘이 또한 사용될 수 있다.
앞서 기술한 바와 같이, 보안 토큰을 평가하기 시작하기 전에 조건들 모두가 준비되도록 보장하는 것이 요망되는 특정의 실시예들에서, 재귀적 보안 시스템의 실시예들이 유익하다. 인사이드 아웃 보안 스택 순회를 시행할 수 있고 중간 결과들의 가시성에 대한 제한을 갖는 재귀적 시스템은 따라서 외부 공격에 대한 향상된 강건성은 물론 최소한으로 방해된 방식으로 보안 시스템 평가에 관한 더 많은 제약조건들을 추가하는 것이 요망될 때의 유연성을 제공할 수 있다.
여기서 유의할 점은, 보안 시스템 스택의 재귀적 순회는 전체적인 알고리즘적 흐름에 대한 재귀적 형태와 꼭 같지는 않다는 것이다. 이와 같이, 보안 시스템의 논리적 흐름 및 시스템의 보안 시스템을 사용하고 있는 코드 스레드들의 논리적 흐름이 완전히 구별될 수 있다.
그에 부가하여, 특정의 실시예들에서, 특정의 코드 세그먼트가 파싱될 때 디지털 서명이 어떻게 수정되는지를 명시하는 한 세트의 기능들을 포함시키는 것에 의해, 디지털 서명이 어떻게 사용될 수 있는지의 유연성이 증가될 수 있다. 예를 들어, 첫번째 반복 후에 코드 세그먼트가 디지털 서명을 파싱 프로세스를 통해 그대로 통과시킬 수 있는 경우, 보안 시스템이 그 특정의 코드 블록을 통해 몇번 순환하는지를 사전에 명시할 필요 없이 그 코드 세그먼트가 검증될 수 있다. 이와 유사하게, 특정의 코드 세그먼트를 만날 때 디지털 서명이 기지의 "씨드" 상태로 리셋되도록 명시될 수 있다. 이와 같이, 단순히 (평문으로 저장될 수 있는) 단일의 고유 번호를 제공하는 것에 의해, 보안 시스템의 다양한 부분들이 몇번 그리고 어떤 순서로 순회되는지의 고유의 변동이 명시될 수 있다. 사실, 각종의 유용한 기능들을 구현하기 위해 이러한 코드 검증 프로세스가 사용될 수 있고, 따라서 이 기법이 보안 시스템 자체의 배타적 사용으로 꼭 제한될 필요는 없다.
적절한 디지털 서명이 일반 코드(보안의 구현에 관련되어 있을 수 있거나 그렇지 않을 수 있는 코드)를 제공받는 경우에, 그 특정의 코드 블록이 특정의 대상 유닛에서 실행되는 방식이 꽤 구체적으로 제어될 수 있다. 이것은 일반 코드를 한 세트의 대상 디바이스들로 안전하게 배포하기 위해 사용될 수 있는 아주 강력한 메커니즘이다. 이 배포 방법은, 예를 들어, 응용 프로그램들에 대한 무료 또는 유료 업그레이드들에 또는 소프트웨어 바이러스 및 다른 바람직하지 않은 멀웨어의 확산을 관리하는 데 효과적으로 적용될 수 있다. 이 후자의 실시예에서, 대상 디바이스에서 사용하기 위한 후보인 모든 코드 블록을 각각 검증하기 위해 재귀적 보안 시스템이 사용될 수 있다. 이와 같이, 이전에 인증된 코드 세그먼트들에 대한 멀웨어 응용 프로그램 또는 심지어 다형적 바이러스 공격이 실행되지 못하게 될 수 있다.
하드웨어 의존 관계들을 보안 시스템 평가에 포함시키는 기능을 제공하기 위해, 특정의 실시예들에서, 하드웨어 구현 버전 번호가 디지털 서명 평가의 복합 구성요소들 중 하나로서 이용될 수 있다. 보안 시스템이 수정될 때마다 하드웨어 버전 번호가 업데이트되는 경우(그리고 그 업데이트가 안전한 경우), 보안 시스템이 그가 실행 중인 대상 유닛에 정합되도록 보장될 수 있다. 유의할 점은, 이것이 앞서 기술된 타임스탬핑 메커니즘과 구별되지만, 재생 공격 시나리오들 또는 다른 위반들로부터 보호하기 위해 이 둘이 복합 키 평가에서 함께 사용될 수 있다는 것이다.
예를 들어, JTAG 서명과 같은 하드웨어 도출된 체크섬을 여기서의 복합 키 구조의 일부로서 사용하는 경우, 하드웨어 구현 자체가 인증될 수 있다. 이러한 종류의 메커니즘은 소프트웨어와 하드웨어가 정합된 쌍이라는 것 및 하드웨어 자체가 정품이라는 것(또는 변조되지 않았다는 것)을 보장할 수 있다. 게다가, 복합 키 평가의 일부로서 사용되는 JTAG 서명이 직접 관찰가능하지 않은 경우(예를 들어, 그의 상태가 외부에서 보이지도 않고 구조적으로도 보이지 않는 스캔 체인(scan chain)에서의 지점으로부터 취해지는 경우), 하드웨어를 복제하는 것에 기초한 잠재적인 공격을 착수하는 것의 어려움이 몇배 증가될 수 있다. 예를 들어, 디바이스의 개개의 일련 번호가 이 스캔 체인에 포함되는 경우, 이 전략이 효과적일 수 있다.
여기서 유의할 점은, 프로세서의 관점으로부터 볼 때, 본질적으로, (직접 실행가능하지 않은) 암호화된 코드 블록과 어쩌면 정확한 디지털 서명 정합이 주어진 경우 한번 실행가능할 수 있지만 그의 디지털 서명이 더 이상 유효하지 않기 때문에 더 이상 실행가능하지 않은 "오래된" 코드 블록 사이의 논리적 차이가 없을 수 있다는 것이다. 예를 들어, 대상 디바이스의 타임스탬프 레지스터가 변경되었기 때문에 또는, 다른 대안으로서, 대상 디바이스의 하드웨어가 어떤 허가되지 않은 방식으로 수정되는 경우, 이 시나리오가 일어날 수 있다.
이와 같이, 특정의 코드 블록이 업데이트된 버전으로 대체되는 경우에(이 둘이 어쩌면 실행가능함), 하나의 실시예에서, 이것을 달성하는 간단하지만 효과적인 방법은 먼저 문제의 코드 블록에 대한 복호화 키 포인터를 코드 블록의 이전 버전을 업데이트된 버전으로 대체하기 위한 수단을 가져오는 새로운 포인터로 대체하고 이어서 대상 종단점 디바이스의 타임스탬프 레지스터를 업데이트하는 것일 수 있다. 여기서, 업데이트된 타임스탬프 레지스터 값은 이전의 값을 사용하여 발생된 이전의 디지털 서명들 모두를 무효화시킬 수 있고, 따라서 전체 보안 시스템이 최신의 것으로 만들기 위해 그리고 이전의 디지털 서명들(또는 키들)을 새로운 키/디지털 서명 값들 및 업데이트된 기능으로 대체하기 위해 (이상적으로는 보안 방식으로) 개조되는 것을 수반할 수 있다. 이것은 종단점 디바이스의 타임스탬프 레지스터에 저장된 값에 대한 단일의 변경으로 쉽게 영향을 받을 수 있는 아주 강력한(그리고 어쩌면 지대한 영향을 미치는) 메커니즘이다. 이 경우에, 종단점 타임스탬프 레지스터 값이 안전하지 않거나 무모한 방식으로 변경되지 않도록 주의를 해야만 한다. 이러한 강제 업데이트 시나리오의 하나의 실시예는 (단지 단일의 디지털 서명 불일치를 강요하는 것에 의해) 다른 직접 실행가능 코드 블록에 암호화 계층을 추가하는 것과 논리적으로 등가라고 할 수 있다.
보안 모드 및 보안 코드 바인딩
앞서 기술한 바와 같이, 시스템이 구조적으로 보이지 않는 비밀 키들 중 하나를 이용하는 실시예에서, 이러한 키를 사용하는 코드는 이 비밀 키들이 손상되지 않도록 하는 방식으로 설계되어야만 한다. 앞서 언급한 바와 같이, 허가되지 않은 방식으로 사용될 때 특정의 종단점 디바이스 상에서의 다른 적법한 코드 블록의 정확한 실행을 방지하기 위해 보안 코드 바인딩 메커니즘을 사용할 수 있다.
하나의 실시예에서, 이 보안 코드 바인딩은 특정의 종류의 해싱 함수를 후보 코드 세그먼트에 적용하는 것의 결과가 그 코드 세그먼트가 실행되도록 허용되기 전에 그 코드 세그먼트와 함께 제공되는 특별히 사전 결정된 메시지 다이제스트와 일치해야만 한다는 요구사항에 기초하고 있다. 후보 코드 세그먼트가 호출된 후에 그렇지만 그것이 실행되도록 허용되기 전에, 이 해싱 함수가 적용될 수 있다. 이 해싱 함수가 개시되면, 후보 코드 세그먼트를 포함하는 그 특정의 메모리 공간에의 임의의 기입들이 디스에이블되거나 무시될 수 있다. 후보 코드 세그먼트가 CPU의 명령어 캐시와 같은 CPU 실행 유닛과 동일한 칩 상에 위치해 있는 경우, 이것은 용이하게 구현될 수 있다. 그렇지만, 멀티프로세서 시스템에서, I-캐시가, 예를 들어, 동일한 칩 상에 존재하는 2개 이상의 프로세서들 간에 공유될 수 있는 경우, 이것은 표면상으로 보이는 것만큼 구현하기가 간단하지 않을 수 있다. 메시지 다이제스트가 계산된 후에 코드가 수정되는 것을 방지하는 다른 잠재적인 방법은 해싱 함수가 개시된 후에 일어나는 그 메모리 공간에의 임의의 시도된 기입들이 프로세서 인터럽트를 야기하도록 시스템을 구성하는 것이다. 앞서 기술된 바와 같이, 이것은 프로세서의 보안 실행 모드를 그의 기본 초기 "비보안" 모드로 리셋할 수 있다. 이러한 침입에 대한 다른 반응은, 예를 들어, 메모리 세그먼트화 장애를 개시하는 것에 의해 오류로 보안 실행 스레드를 종료시키는 것일 수 있다.
후보 코드 세그먼트의 계산된 메시지 다이제스트가 후보 코드 세그먼트와 함께 수신된 사전 결정된 메시지 다이제스트와 일치하는 경우, 후보 코드 세그먼트는 소위 "보안 모드" 또는 "보안 실행 모드"로 실행하도록 허용된다. 앞서 기술된 바와 같이, 보안 모드로 동작 중인 코드만이 구조적으로 보이지 않는 비밀 키를 이용할 수 있다. 특정의 코드 세그먼트가 보안 모드로 동작하고 있지 않은 경우, 비밀 키(들)가 디스에이블되고, 그들 중 하나에 대한 임의의 참조가 (0과 같은) 어떤 다른 값을 반환할 것이다.
특정의 실시예들에서, 후보 코드 세그먼트에 대한 메시지 다이제스트를 계산하는 데 이용되는 해싱 함수는 특정의 특성들을 가질 수 있다. 제1 특성은 해싱 함수가 대상 유닛의 하드웨어로 구현될 수 있다는 것이다. 이것은 이 함수가 이 원래의 하드웨어 해싱 함수의 어떤 다른 (아마도 와해된) 버전으로 완전히 대체될 수 없다는 것을 의미한다. 유의할 점은, 이 해싱 함수는 원하는 경우 원래의 함수의 세련된 버전(또는 심지어 조건부 전면 대체(conditioned outright replacement))으로 보완될 수 있다. 하나의 실시예에서, 하드웨어 해싱 함수를 세련된 버전으로 대체하는 방법은 보안 시스템의 구조의 재귀적 정의를 통해 보안 시스템에 새로운 계층들을 삽입하기 위해 사용되는 앞서 기술한 절차와 실질적으로 유사하다. 그렇지만, 유의할 점은, 이 경우에, 비록 모든 차후의 보안 시스템 동작들에 대해 새로운 해싱 함수가 원래의 함수를 대체할 수 있지만, 이 새로운 해싱 함수 자체는 여전히 그의 신뢰 근간의 토대인 원래의 하드웨어 해싱 함수에 의존할 수 있다. 따라서, "조건부 전면 대체"라는 용어를 사용한다. 하나의 실시예에서, 원래의 하드웨어 기반 신뢰 근간이 그대로 유지될 수 있다. 이것은 이러한 하드웨어 기반 보안 시스템을 훼손시키기 아주 어려울 수 있다는 점에서 바람직할 수 있다. 그렇지만, 대상 디바이스가 현장에 배치된 후에 원래의 하드웨어 해싱 함수에서의 단점이 발견되는 경우, 단일의 응용 프로그램에서 원래의 해싱 함수를 사용하는 것에 의해 이러한 단점이 어쩌면 포함될 수 있고, 여기서 호출 인수들이 효과적으로 제한될 수 있다.
하드웨어 해싱 함수의 제2 특성은 하드웨어 해싱 함수가 구조적으로 보이지 않는 비밀 키를 그의 씨드 값으로서 사용할 수 있다는 것이다. 이와 같이, 동일한 입력 인수들이 주어진 경우에도, 이러한 하드웨어 해싱 함수의 메시지 다이제스트 결과가 유닛마다 다를 수 있다. 모든 대상 유닛마다 독자적인 메시지 다이제스트가 얻어질 수 있다는 점에서 이 차이가 이용될 수 있다. 이 특성은 디지털 서명의 특성과 개념이 유사하지만, 하드웨어 해싱 함수에의 개별적인 암호화/복호화 블록의 부가를 꼭 필요로 하지는 않는다. 하드웨어 생성 메시지 다이제스트가 후보 코드 세그먼트와 함께 배포되는 것과 일치하는 유닛들에서만 후보 코드 세그먼트가 (적어도 보안 모드로) 실행되는 것으로 제약되기 때문에, 순환 의존 관계가 생성된다. 이 순환 의존 관계는 정확한 대상 유닛의 비밀 키로 생성된 메시지 다이제스트를 갖는 코드만이 이 동일한 비밀 키를 실제로 사용할 수 있다는 것을 의미한다. 이 특성은 잠재적 공격자가 대상 디바이스에서 보안 모드로 실행되도록 허용되는 코드 세그먼트를 생성할 수 있는 능력을 실질적으로 손상시킨다.
앞서 기술한 메커니즘은 "보안 코드 바인딩"이라고 하는데, 그 이유는 코드 세그먼트가 특정의 대상 디바이스에(또는 심지어 종단점 디바이스들의 특정의 세트에) "바인딩"될 수 있기 때문이다. 앞서 언급한 바와 같이, 실행 중인 보안 코드 블록이 인터럽트되는 경우에, 컨텍스트가 저장되지 않고, 따라서 이 코드 세그먼트의 실행이 포기되거나 처음부터 재시작되어야만 한다. 또한, 보안 모드에서의 코드 세그먼트의 실행이 인터럽트되면, 프로세서는 더 이상 보안 모드로 동작하지 않을 수 있고, 프로세서가 보안 모드로 복귀할 때까지 구조적으로 보이지 않는 비밀 키(들)에 대한 임의의 액세스가 차단될 수 있다. 특정의 실시예들에서, 프로세서가 보안 모드로 동작하고 있는 동안 오프칩 저장 동작들이 또한 제어되거나 금지될 수 있다.
논의한 바와 같이, 특정의 실시예들에서, 각각의 대상 유닛은 구조적으로 보이지 않는 비밀 키들의 독자적인 세트를 가질 수 있다. 그렇지만, 다른 실시예들에서, 이 키들의 어떤 서브셋은 다수의 동일한 디바이스들에 공통일 수 있다. 이와 같이, 특정의 코드 세그먼트는 키들의 공통 서브셋을 갖는 특정의 부류의 종단점 디바이스들에 바인딩될 수 있으면서, 여전히 이러한 디바이스들 간에 공통으로 보유되는 구조적으로 보이지 않는 비밀 키들의 이 세트를 보호한다. 하드웨어 해싱 함수와 하나 이상의 구조적으로 보이지 않는 비밀 키들의 조합은 따라서 아주 효과적이고 강건한 재귀적 보안 프로토콜의 신뢰 체인에 대한 기초를 제공할 수 있다.
이제부터 다양한 실시예들의 구현 상세들이 첨부된 도면들을 사용하여 추가로 기술될 것이다. 유의할 점은, 이 예들 모두에서, "디지털 비트스트림"이라는 용어는 일반적인 디지털 데이터의 집합체를 말하며, 따라서 이 용어는 디지털 콘텐츠, 코드 블록 또는 디지털 데이터 세트와 같은 단어들과 서로 바꾸어 사용될 수 있다. 용어 코드 블록의 경우에, 참조된 데이터는 또한 실행가능 파일, 실행가능 스크립트 또는 심지어 알고리즘적 설명 또는 의사 코드 블록을 나타내는 것으로 가정될 수 있다.
도 24는 디지털 콘텐츠에 대한 복합 키의 생성의 하나의 실시예를 나타낸 것이다. 특정의 종단점 디바이스(대상 유닛)와 연관되어 있는 (앞서 논의된 바와 같은) 구조적으로 보이지 않는 비밀 키일 수 있는 종단점 관련 하드웨어 키(2440)를 이용하여 (디지털 콘텐츠의 소유자 또는 저작자에 의해 제공되거나 결정될 수 있는) 전역 콘텐츠 키(2430)에 암호화 엔진(2420)을 적용하는 것에 의해 이 복합 키(2410)가 생성될 수 있다. 특정의 종단점 및 디지털 콘텐츠 둘 다에 관련되어 있는 얻어진 복합 키는 복합 키가 제공되는 종단점 디바이스로 전송되어 그에 저장되고, 그 평문으로 저장된다.
도 25a는 보안 디지털 데이터 블록 구조의 생성의 하나의 실시예를 나타낸 것이다. 이 실시예에서, 디지털 데이터 블록(2510)은 암호화되지 않을 수 있지만, 디지털 서명(2520)은 하나 이상의 토큰들(2540 또는 2550)로 디지털 데이터 블록으로부터 해싱 함수(2530)에 의해 계산된 메시지 다이제스트를 암호화하는 것에 의해 형성된다. 이 토큰들은 비밀 키들 또는 타임스탬프와 같은 공개적으로 이용가능한 데이터일 수 있다. 유의할 점은, 암호화 엔진(들)(2560 및 2561)을 통과하는 데이터를 암호화하는 데 이용되는 방법들이 동일할 수 있거나 그렇지 않을 수 있다는 것이다. 비밀 키가 암호화 키들 중 하나로서 사용되는 경우에, 그 비밀 키 값을 모른 채로 디지털 서명을 위조하는 것이 더 어려울 수 있다. 암호화 동작들(2560 및 2561)의 순서가 결과의 전체적인 보안에 관련이 없지만, 동작들의 순서가 변경되는 경우 얻어진 디지털 서명(2520)이 상이할 것임에 유의하는 것이 또한 유익하다.
도 25b는 보안 코드 블록 데이터 구조의 생성의 대안의 실시예를 나타낸 것이다. 이 경우에, 전체 메시지(2580)를 형성하기 위해 비밀 키(2570)가 디지털 데이터 블록(2571)에 후치 첨부된다. 이전과 같이, 이 후치 첨부 동작이 비밀 키(2570)를 원래의 디지털 데이터 세트(2571)의 이전에 또는 그 이후에 위치시키는지가 얻어진 보안의 강건성에 꼭 관련되는 것은 아니지만, 순서가 변경되는 경우 최종 결과가 달라질 것이다. 또한 유의할 점은, 보안을 보장하기 위해, 비밀 키(2570)가 원래의 디지털 데이터 세트(2571)와 함께 공개되어서는 안된다. 따라서, 공개된 데이터 세트가 전체 데이터 구조(2580)보다는 디지털 데이터 세트(2571)로만 제한된다. 도 25a와 관련하여 앞서 도시된 것과 본질적으로 동일한 방식으로, 이 전체 데이터 구조(2580)가 이어서 해싱 함수(2530)를 통해 지나간다. 그렇지만, 이 실시예에서, 최종 출력(490)은 도 25a에 도시된 디지털 서명(2520)의 특성들 중 다수를 가지지만, 암호화 엔진(들)(2560 또는 2561)의 사용을 필요로 하지 않을 수 있다. 따라서, 이 동작의 결과(2590)를 디지털 서명 등가물이라고 지칭할 것이다. 유의할 점은, 이 디지털 서명 등가물(2590)이 각각의 독자적인 전체 데이터 구조(2580)에 대해 고유하다(해싱 함수(2530)가 적절히 구성되는 것으로 가정함)는 것이다. 따라서, 비밀 키(2570)가 디지털 데이터 세트(2571)의 저작자와 그 디지털 데이터 세트의 소비자(종단점 디바이스 또는 대상 디바이스)에 의해서만 공유되는 경우, 이 2개의 당사자들만이 동일한 정확한 디지털 서명 등가물(2590)을 재생성할 수 있어야만 한다. 이 경우에, 디지털 데이터 블록(2571)은 그 비밀 키(2570)에(그리고 따라서 대상 디바이스에) "바인딩"되는 것으로 간주될 수 있다.
도 26a는 해싱 함수(2640) 및 암호화 엔진(2661)에 의해 계산되는 디지털 서명(2624)을 사용하여 암호화된 데이터 블록(2610)을 특정의 복호화 엔진 코드 블록(2662)에 암호적으로 바인딩하기 위해 그리고 이어서 그 조합(2630)을 특정의 종단점의 하드웨어 비밀 키(2623)에 바인딩하기 위해 본 명세서에 기술되는 것과 같은 보안 시스템이 어떻게 사용될 수 있는지의 하나의 실시예를 나타낸 것이다. 유의할 점은, 이 예에서, (전역 콘텐츠 비밀 키(2620)로 복호화 엔진 코드 블록(2662)의 메시지 다이제스트(2621)를 암호화하는 것에 의해 구성되는) 공개 키(2622)가 원래의 암호화된 데이터 블록(2610)과 함께 단일의 연접된 데이터 세트(2630)로서 공개적으로 배포된다. (공개 키(2622)와 결합된 원래의 암호화된 데이터 블록(2610)을 포함하는) 결합된 메시지(2630)의 메시지 다이제스트로부터 디지털 서명(2624)을 생성하는 동작은 적절히 허가된 종단점 디바이스들만이 원래의 암호화된 데이터 블록(2610)을 복호화할 수 있도록 보장하고, 그것뿐만 아니라, 이 복호화 프로세스가 복호화 엔진(2662)의 소정의 방법을 사용해서만 달성될 수 있도록 보장한다. 유의할 점은, 추가의 구성요소들을 (예를 들어, 다중항 복합 암호화(multi-term compound encryption)와 같은) 암호화 엔진 체인(2660)에 부가하는 것에 의해 복호화 허가 절차에 추가의 제약조건들이 쉽게 추가될 수 있다는 것이다.
도 26b는 도 26a에 도시되어 있는 실시예의 한 변형례를 나타낸 것이다. 이 실시예에서, 특정의 암호화된 메시지(2611)의 저작자가 특정의 종단점 디바이스 상에서만 명확하게 인증될 수 있다. 여기서, 원래의 암호화된 데이터 블록(2611)은, 앞서 기술된 바와 같이, 특정의 복호화 루틴(2662)에 암호적으로 바인딩된다. 이 시점에서, 복호화 루틴(2662)이 비대칭 암호화 엔진이라는 것이 추가로 명시될 수 있고, 여기서 입력은 저작자의 비밀 개인 키(2625)일 수 있고, 출력은 저작자의 공개 키를 사용해서만 정확하게 복호화된다. 전체 데이터 구조(2631)를 형성하기 위해, 비대칭 암호화 루틴(2662)의 메시지 다이제스트(2627)가 디지털 서명(2626)과 함께 원래의 암호화된 디지털 데이터(2611)에 후치 첨부된다. 디지털 서명(2628)을 형성하기 위해, 데이터 구조(2631)가 이어서 특정의 종단점 디바이스의 비밀 키(2623), 해싱 함수(2644) 및 암호화 엔진(2661)을 사용하여 그 종단점 디바이스에 암호적으로 바인딩될 수 있다. 이 실시예에서, 암호화된 메시지(2611)가 정품이고 그의 저작자가 알려져 있음은 물론 저작자가 하드웨어 비밀 키(2623)를 소유하고 있다는 것이 보장될 수 있다. 여기서 유의할 점은, 저작자라는 용어가, 본 명세서에서 사용되는 바와 같이, 꼭 데이터의 창작자를 의미하는 것은 아니며, 라이센서(licensor), 배포자, 또는 이러한 데이터를 배포하거나 다른 방식으로 전달하고자 하는 다른 유형의 엔터티라고도 할 수 있다. 이 특정의 신뢰 체인이 상당히 유용한 하나의 예는 종단점 디바이스의 보안 시스템이 (원래의 데이터 블록(2611)에 암호화된 형태로 포함되어 있는) 보안 코드 블록을 사용하여 업데이트되어야 하는 경우이다.
도 27은 보안 코드 블록(2720)의 실행을 제어하기 위해 케스케이딩된 해싱 방법을 이용하는 하나의 실시예를 나타낸 것이다. 이 경우에, 2개의 독립적인 코드 블록들(2710, 2720)이 있다. 이 예에서, 제1 코드 블록(보안 코드 블록(2710))은 제2 서브루틴(보안 코드 블록(2720))에 대한 내장된 서브루틴 호출을 포함한다. 이와 같이, 보안 코드 블록(2710)에 대한 해싱 함수(2740)에 의해 계산된 메시지 다이제스트(2730)는 보안 코드 블록(2710) 내부에 포함되어 있는 보안 코드 블록(2720)에 대한 참조에 의존한다. 보안 코드 블록(2710)의 관점에서 볼 때, 이 메시지 다이제스트(2730)는 이어서 2개의 보안 코드 블록들을 서로 링크시킨다. 그 다음에, 해싱 함수(2770)를 사용하여 코드 블록(2720)에 대한 메시지 다이제스트(2750)가 구성될 수 있다. 그렇지만, 메시지 다이제스트(2750)를 보안 코드 블록(2720)은 물론 그의 호출 부모 루틴(이 경우에, 보안 코드 블록(2710)) 둘 다에 연계시키기 위해, 원래의 메시지 다이제스트(2730)가 해싱 함수(2770)에 의해 계산되는 메시지 다이제스트(2750)에 대한 씨드로서 사용될 수 있다. 이러한 씨드 값이 많은 방식들로 구현될 수 있지만, 하나의 이러한 방법이 전체 메시지(2760)를 형성하기 위해 원래의 메시지 다이제스트(2730)를 제2 디지털 데이터 세트(예를 들어, 이 경우에, 보안 코드 블록(2720))에 단순히 연접시키는 것임을 상기한다. 보안 코드 블록(2720)은 물론 원래의 메시지 다이제스트(2730)(그 자체는 보안 코드 블록들 둘 다(2710 및 2720)에 의존함) 둘 다에 의존하는 제2 메시지 다이제스트(2750)를 형성하기 위해 전체 메시지(2760)가 이어서 해싱 함수(2770)(해싱 함수(2740)와 동일할 수 있거나 어떤 다른 독립적인 해싱 함수일 수 있음)를 통해 지나간다. 도 25b의 논의에서 살펴본 바와 같이, 이 연접된 요소들(2720 및 2730)의 순서가 얻어진 메시지 다이제스트(2750)에 중요할 수 있지만, 해싱 함수(2770)의 경우에, 전체 메시지(2760)를 구성하는 요소들의 순서가 해싱 함수(2770)의 보안에 그다지 영향을 미치지 않을 수 있다.
보안 코드 블록(2720)이 코드 블록(2710)으로부터 호출되는 경우에만 정확하게 실행될 수 있도록 하기 위해, 이 제2 메시지 다이제스트(2750)가 이어서 앞서 기술된 것과 실질적으로 유사한 방식으로 사용될 수 있다. 유의할 점은, 코드 블록(2720)이 실제로 코드 블록(2710)의 정확한 복제물(또는 동등한 참조)일 수 있고, 이것이 재귀적 시스템의 일 실시예가 된다는 것이다. 동일한 코드 블록의 2개의 인스턴스화들 사이의 유일한 차이는 보안 코드 블록 메시지 다이제스트를 형성하기 위해 코드 블록에 후치 첨부되는 특정의 메시지 다이제스트일 수 있다.
이 특정의 실시예에서, 유의할 점은, 어떤 비밀 키들도 사용하지 않았고, 따라서 본 명세서에 기술되는 것과 동일한 전체 보안 시스템을 사용하고 있는 임의의 종단점 디바이스에서 적절한 실행 순서를 시행하기 위해 이 유형의 구조가 특이성 없이 사용될 수 있다는 것이다. 또한, 이전과 같이, 보안 코드 블록들(2710 또는 2720) 중 어느 하나의 실행이 그에 부가하여, 각각, 메시지 다이제스트들(2730 또는 2750) 대신에 복합 키 기반 디지털 서명 구조 또는 그의 등가물을 이용하여 어떤 특정의 종단점 디바이스 또는 디바이스들의 세트로 제약되는 한 유사한 예가 구성될 수 있다.
도 28a는 보안 코드 블록 메시지의 구성의 실시예들을 나타낸 것이다. 하나의 실시예에서, 암호화된 디지털 데이터 세트(2811)는 포인터(2820)에 의해 식별되는 암호화 알고리즘을 사용하여 암호화된다. 데이터 구조(2830)는 디지털 데이터 세트(2811) 및 포인터(2820)의 연접에 의해 형성된다. 데이터 구조(2830)의 메시지 다이제스트(2850)가 해싱 함수(2840)에 의해 발생된다. 이 구성은 암호화된 데이터 세트와 그의 연관된 복호화 루틴을 암호적으로 바인딩하는 것을 가능하게 한다.
제2 실시예에서, 부가의 항이 연접된 데이터 구조(2831)에 부가된다, 즉 포인터(2821)가 복호화 키(2860)에 부가된다. 유의할 점은, 이 특정의 실시예에 나타낸 바와 같이, 이 키(2860)가 꼭 하드웨어 기반 비밀 키는 아니라는 것이다. 사실, 포인터(2821)가 가리키고 있는 키(2860)는 심지어 그 자체가 데이터 구조일 수 있고, 이에 대해서는 이하의 도 28c의 설명에서 논의될 것이다. 그렇지 않은 경우, 이 실시예는 앞서 기술된 실시예들과 실질적으로 유사하다. 원래의 암호화되지 않은 데이터 세트(2810)에 대해 동작하는 암호화 엔진(2870) 및 하나 이상의 키들(2860)을 사용한 결과로서 암호화된 디지털 데이터 세트(2811)가 생성된다. 연접된 데이터 구조(2831)에 대해 해싱 함수(2841)를 사용하여 메시지 다이제스트(2851)가 발생된다. 이 경우에, 이제 암호화되지 않은 데이터 세트(2810)를 암호화 엔진(2870)은 물론 암호화된 데이터 세트(2811)로부터 암호화되지 않은 데이터 세트(2810)를 재생성하기 위해 사용될 수 있는 고유 키(2860) 둘 다와 암호적으로 연관시키는 메커니즘이 있다. 이전의 실시예들에서와 같이, 전체적인 구조를 주어진 종단점 디바이스 상에서 만족되어야 하는 특정의 조건들의 세트 및 그의 고유 비밀 하드웨어 키(2860)에 암호적으로 바인딩하기 위해 부가의 항들이 암호화 체인에 부가될 수 있다. 유의할 만한 가치가 있는 점은, 디지털 데이터 세트들(2810 및 2811)의 형식 및 암호화 상태가 이 프로세스에 관련되어 있지 않을 수 있는데, 그 이유는 이 상세들이 포인터들(2820, 2821)로부터 추론될 수 있기 때문이다.
이것을 염두에 두고서, 도 28b는 재귀적 보안 시스템에서 이와 같이 사용될 수 있는 범용 암호 데이터 구조(Universal Cryptographic Data Structure)의 기본적인 일반화된 형식에 대한 하나의 가능한 실시예를 나타낸 것이다. 이 구조의 실시예들은 간단하고 강력할 수 있으며, 3개의 기본 요소들, 즉 일반 데이터 블록(2812), 복호화 포인터(2820) 및 복호화 키 포인터(2821)의 간단한 연결 리스트(linked list)로서 구현될 수 있다. 전체적인 연결 리스트가 데이터 구조(2832)에 함께 번들링된다. 연결 리스트를 사용하는 것에 의해, 연접된 데이터 구조(2832)에서의 요소들의 순서가 그의 기능에 관련되어 있지 않을 수 있다는 것을 쉽게 알 수 있지만, 이는 데이터 구조의 동작 또는 평가에 영향을 미칠 수 있다. 일반(예를 들어, 사전 정의되지 않은) 데이터 블록 구조 및 연결 리스트 형식을 사용하는 것의 다른 흥미로운 측면은 3개의 요소들(2812, 2820 및 2821)이 또한 꼭 선형적으로 또는 심지어 연속적으로 정렬될 필요가 없다는 것이다. 이와 같이, 하나의 실시예는 전체 데이터 구조(2832)와 함께 저장되는 어떤 다른 독립적이지만 아마도 관련된 데이터를 포함하는 보조 데이터 구조(2813)를 포함할 수 있다. 이 개념의 하나의 실시예는 도 28의 보조 데이터 구조(2813) 내의 포인터(2820)가 가리키는 것과 같은 실제의 복호화 엔진 코드 블록(2871)을 위치시키는 것일 수 있다. 다른 이러한 예는 이 보조 데이터 블록 내의 포인터(2821)에 의해 명시되는 실제 키 값을 저장하는 것일 수 있다.
이 경우들 둘 다에서, 이러한 보조 데이터 블록들에 포함된 실제 데이터는 도 25a, 도 25b, 도 26a, 도 26b, 도 27 및 도 28a에 제시된 예시적인 실시예들에 다양하게 도시되어 있는 메시지 다이제스트 또는 디지털 서명을 발생시키는 프로세스에서 사용될 수 있다. 본 개시 내용에서 살펴본 바와 같이, 연접된 데이터 세트에 저장되는 다양한 데이터 필드들의 순서는, 해싱 함수가 적절히 설계되는 경우, 얻어진 메시지 다이제스트(또는 디지털 서명)에 영향을 미칠 수 있다.
그러면, 특정의 실시예들에서 이용되는 키들을 보호하기 위해 유사한 블록 구조가 또한 사용될 수 있다는 것이 명백하게 될 것이다. 도 28c는 키들만을 포함하는 이러한 보안 데이터 블록(2833)의 하나의 실시예를 나타낸 것이다. 여기서, 데이터 블록은 디바이스 관련 키들(2814, 2815, 2816)(또는, 원하는 경우, 다른 것들)의 목록을 포함할 수 있다. 이 예에서, 이 키들 중 임의의 것이 (예를 들어) 암호화 엔진들(2871 및 2872)을 사용하여, 각각, 암호화된 종단점 디바이스의 비밀 키(2860) 및 종단점 디바이스 타임스탬프 레지스터(2890)를 사용하여 생성되었을 수 있다. 보안 시스템의 강건성의 측면에서 이러한 동작들에 대한 이전의 설명들에서의 경우와 같이, 암호화 엔진들(2871 및 2872)이 구별되거나 심지어 상이해야만 한다는 요구사항이 없고, 암호화 체인에 있는 이 암호화 동작들의 특정의 수에 대한 기본적인 제한이 없을 수 있으며, 이 동작들의 순서가 얻어지는 복합 키들에 중요할 수 있는 반면, 암호화 동작들의 특정의 순서에 대해 어떤 요구사항도 없다. 이 경우에 유의할 하나의 다른 특징은 연접된 키 목록 데이터 구조(2833)의 키 목록 포인터 요소(2821)가 또 다른 연접된 키 목록 데이터 구조(2834)를 가리킬 수 있다는 것이다. 이 데이터 구조들 둘 다가, 도 28b에 도시되어 있는 바와 같이, 동일한 범용 암호 형식을 갖기 때문에, 키 목록 데이터 구조가 재귀적 방식으로 형성될 수 있다. 그에 따라, 이러한 재귀적 보안 시스템의 실시예들에서 사용하기 위한 키들(2833)이 동일한 방식으로 그리고 이러한 보안 프로토콜의 실시예들이 적용될 수 있는 임의의 다른 데이터와 동일한 구조들을 사용하여 보호될 수 있고, 이와 유사하게, 이 보호된 키들이 또한 본 명세서에 개시되어 있는 시스템들 및 방법들의 실시예들에 의해 보호되는 다른 데이터와 동일한 방식으로 종단점 디바이스 상에서 복호화되고 인증될 수 있다.
이제 도 29를 참조하면, 암호화된 콘텐츠를 복호화하기 위해 복합 키가 어떻게 이용될 수 있는지의 하나의 실시예가 도시되어 있다. 이 복호화 동작은, 앞서 기술한 바와 같이, "보안 모드"로 행해질 수 있다. 여기서, 콘텐츠(2910)가 복합 키(2930)와 함께 종단점 디바이스에 제공될 수 있고, 여기서 콘텐츠는 초기에 전역 콘텐츠 키를 사용하여 암호화된다. 복합 키(2930)는 도 24에서 앞서 기술한 바와 같이 생성될 수 있다. 그에 따라, 암호화된 콘텐츠(2910)가 종단점 디바이스에 수신될 때, 이는 연관된 복합 키(2930)와 함께 수신될 수 있다. 보안 모드로 실행할 때, 디바이스에 있는 비밀 키(2940)가 액세스될 수 있도록, 전역 콘텐츠 키를 산출하기 위해 복합 키(2930)가 보안 코드 블록(2960) 내부에서 복호화될 수 있다. 복호화된 콘텐츠(2980)를 산출하기 위해 원래의 암호화된 콘텐츠(2910)를 복호화하기 위해 전역 콘텐츠 키가 보안 코드 블록(2960) 내부에서 차례로 사용될 수 있다.
도 30은 실행 이전에 코드 블록이 특정의 종단점 디바이스에서 실행하도록 허가되어 있는지를 확인하기 위해 비밀 키가 어떻게 이용될 수 있는지의 하나의 실시예를 도시한 것이다. 실행을 위한 후보 코드 블록(3010)이 종단점 디바이스에 제공될 수 있거나, (예를 들어, 도 29에서 앞서 도시된 바와 같이) 수신된 암호화된 디지털 콘텐츠를 복호화함으로써 획득될 수 있다. 그에 부가하여, 종단점 디바이스는 후보 코드 블록(3010)에 대응하는 디지털 서명(3020)을 수신할 수 있다. 이 디지털 서명(3020)은 종단점 디바이스 하드웨어 관련 비밀 키(3030)를 사용하여 암호화된 (예를 들어, 그 코드 블록을 해싱하는 것에 의해) 코드 블록으로부터 생성된 메시지 다이제스트를 포함할 수 있다. 이와 같이, 후보 코드 블록(3010)이 실행될 수 있는지를 확인하기 위해, 인증 동작이 보안 모드로 구현될 수 있고, 그로써 후보 코드 블록(3010)이 메시지 다이제스트를 생성(3012)하기 위해 해싱된다. 이 메시지 다이제스트(3012)는 이어서 단계(3014)에서 원래 제공된 디지털 서명(3020)과 비교되는 디지털 서명을 생성하기 위해 (확인이 보안 모드로 행해지고 있기 때문에 액세스가능할 수 있는) 종단점 디바이스의 종단점 디바이스 하드웨어 관련 키(3030)를 사용하여 암호화될 수 있다. 이 디지털 하드웨어 발생 디지털 서명이 후보 코드 블록(3010)에 대응하는 수신된 디지털 서명(3020)과 일치하는 경우, 후보 코드 블록(3010)이 확인된 것으로 간주될 수 있고 실행가능한 것으로 생각될 수 있으며, 그렇지 않은 경우, 예외 오류가 발생할 수 있다(단계(3016)).
도 31은 코드 블록이 어떻게 특정의 종단점 프로세서 상에서 (소정의 상황들 하에서) "보안 실행" 모드로 실행되도록 허용될 수 있는지의 하나의 실시예의 블록도이다. 이 특정의 경우에, 코드 블록(3111)의 사전 계산된 디지털 서명(3130)(종단점 관련 복호화 키라고도 할 수 있음)이 코드 블록의 메시지 다이제스트를 사용하여 그리고 이를 허가된 대상 종단점 디바이스의 비밀 키(3140), 허가된 대상 종단점 디바이스의 가장 최근의 타임스탬프 값(3141), 또는 (이 특정의 실시예에서 나타내지 않은) 앞서 기술된 것과 같은 임의의 수의 제약 조건들 중 하나 이상 중 하나 이상으로 암호화하여 구성된다.
또한 유의할 점은, 이 항들 중 임의의 것이 또한 항 자체의 서브셋에 마스킹 함수를 적용함으로써 사전 조건 부여(pre-conditioned)될 수 있다. 예를 들어, 타임스탬프 필드의 다수의 최하위 비트들이 마스크 오프(mask off)되는 (그리고 따라서 디지털 서명의 계산에서 고려되지 않을 수 있는) 경우, 그 타임스탬프 값의 유효 입도(effective granularity)가 하드웨어의 어떤 변경도 없이 코드 세그먼트마다 쉽게 제어될 수 있다. 이 동일한 원리가, 특정의 실시예들에서, 디지털 서명의 계산에서 사용되는 임의의 수의 항들에 적용될 수 있다.
도 28에 도시된 키 목록 데이터 구조에서와 같이, 코드 블록(3111)을 포함하는 연접된 디지털 데이터 세트(3110)는 또한 적어도 하나의 복호화 포인터(3112) 및 적어도 하나의 복호화 키 또는 키 목록 포인터(3113)를 포함한다. 또한 앞서 기술된 바와 같이, 이들 중 어느 하나는 (종단점 관련 디지털 키 또는 디지털 서명(3130)과 같은) 외부 데이터 구조(external data structure) 또는 연접된 데이터 세트(3110) 내에 완전히 포함되어 있는 내장된 데이터 구조(embedded data structure)라고 할 수 있다.
도 31에 도시되어 있는 실시예를 설명하기 위해, 코드 블록(3111)이 암호화되지 않은 것으로(그리고 따라서 어쩌면 종단점 디바이스 대상 프로세서 상에서 실행가능한 것으로) 가정될 것이다 이 경우에, 복호화 포인터가 널(null)일 수 있는데, 그 이유는 코드 블록(3111)의 사용 이전에 이에 대한 추가적인 암호화가 필요 없기 때문이다. 코드 블록이 암호화되어 있지 않을 때, 이 경우에서와 같이, 그의 대응하는 복호화 키(포인터)(3113)가 연관된 종단점 또는 하드웨어 관련 디지털 서명(3130)을 가리킬 수 있다. 이와 같이, 도 25a, 도 25b, 도 26a 및 도 26b에서 앞서 나타낸 것들과 같은 데이터 구조들 및 방법들의 실시예들은 블록(3111)에 나타낸 것과 같은 암호화되지 않은 데이터 세트의 사용에 관한 아주 다양한 인증, 암호적 바인딩 또는 다른 제약조건들을 시행하는 데 사용될 수 있다.
종단점 관련 디지털 서명(또는 복호화 키)(3130)가 하드웨어 비밀 키(3140)만 또는, 다른 대안으로서, 하드웨어 비밀 키(3140) 및 종단점 디바이스 타임스탬프 레지스터(3141)만을 가리키는 경우에, 보안 시스템 관련 호출들이 호출 체인의 "하부"에 도달했고 이 특정의 호출 체인에서 보안 시스템의 부가의 계층들에 대한 추가적인 호출들이 없을 것으로 결정할 수 있다. 이와 같이, 보안 시스템 재귀가 이 시점에서 "종료"된다. 이 재귀 종료 조건은 종단점 관련 하드웨어 비밀 키(3140)의 값에 대한 액세스를 선택적으로 허용하거나 거부하기 위해 "게이트키퍼"로서 그리고 하드웨어 해싱 함수 블록(3161)의 출력을 사용하는 암호 함수에 대한 입력 구성요소로서만 기능하는 하드웨어 블록(3150)에 의해 검출된다. 도 31에 도시된 예에서, 하드웨어 관련 비밀 키(3140) 및 하드웨어 해싱 함수 블록(3161)의 (메시지 다이제스트) 출력이 암호화 엔진들(3162 및 3163)에의 입력 인수들로서 사용된다.
마지막으로, (원래의 연접된 데이터 구조(3110)의 디지털 서명인) 암호화 엔진(3163)의 출력이 제공된 디지털 서명(3130)의 값과 일치하는 경우, "보안 모드 인에이블됨" 하드웨어 비트(3170)가 세트된다. 이 조건은 종단점 하드웨어 I-캐시(3120)에 로드된 후보 코드 블록(3111)이 이제 "보안" 모드로 실행하도록 허가되어 있다는 것을 나타낸다. 유의할 점은, I-캐시(3120)에 존재하는 후보 코드 블록(3111)에 대한 어떤 물리적 변경도 없고 I-캐시(3120) 자체에 대한 어떤 변경도 없다는 것이다. 이 시점에서 변경된 유일한 것은 "보안 모드 인에이블됨" 하드웨어 비트(3170)의 값이다.
도 32는 재귀적 보안 시스템에 의해 수행될 수 있는 복호화 동작의 하나의 실시예를 나타낸 것이다. 이 복호화 동작은 배포된 콘텐츠를 복호화하거나 다른 방식으로 조작하고 사용하는 프로세스에서 사용되어야 하는 보안 코드 블록을 검증하기 위해 복합 키를 사용할 수 있다. 앞서 기술된 바와 같이, 종단점 디바이스는 (도 30과 관련하여 앞서 논의된 바와 같이) 암호화된 콘텐츠(3211), 복호화 엔진(3220)에 대한 포인터(3212)(또는 복호화 엔진 자체) 및 종단점 관련 복합 키(3230)에 대한 포인터(3213)를 포함하는 데이터 구조(3210)를 수신할 수 있다. 보안 모드로 실행하도록 허용되기 전에, 지시되는 또는 수신되는 복합 복호화 엔진(3240)이 인증될 것이다. 이 인증은 종단점 디바이스에 존재하는 해싱 함수(3221)를 사용하여 복합 복호화 엔진(3240) 코드 블록의 메시지 다이제스트(3222)를 계산하는 것에 의해 달성될 수 있다. 유의할 점은, 이 예에서, 해싱 함수(3221)가 하드웨어 블록인 것으로 도시되어 있지만, 앞서 논의된 바와 같이, 이 해싱 함수(3221)가, 예를 들어, 종단점 디바이스의 내장된 하드웨어 해싱 함수 대신에 사용될 수 있는 보안 소프트웨어 코드 블록일 수 있다는 것이다. 그렇지만, 이 경우에, 해싱 함수의 소프트웨어 버전은 여전히 궁극적으로 인증 또는 허가를 위해 내장된 하드웨어 해싱 함수에 의존할 수 있고, 따라서 이 경우에 궁극적인 신뢰 근간은 여전히 종단점의 내장된 하드웨어 해싱 함수 블록(3221)에 존재한다.
이 해싱 블록(3221)에 의해 발생된 메시지 다이제스트(3222)가 이어서 단계(3223)에서 복호화 엔진(3240)에 대응하는 사전 계산된 메시지 다이제스트(3250)와 비교될 수 있다. 이 사전 계산된 메시지 다이제스트(3250)는, 예를 들어, 종단점 디바이스에 보안 방식으로 제공되거나, 종단점 디바이스 자체에서 사전 계산되어 그에 저장될 수 있다. 메시지 다이제스트들이 일치하는 경우, 복합 복호화 엔진(3240)은 종단점 디바이스 상에서 실행되도록 허용될 수 있다(단계(3225)). 메시지 다이제스트들이 실질적으로 동일하지 않은 경우, 유효하지 않은 코드 예외가 일어날 수 있다(단계(3226)).
그렇지만, 메시지 다이제스트들이 실질적으로 동일한 경우, 종단점 디바이스의 프로세서는 복합 복호화 엔진(3240)에 포함된 코드를 실행하기 위해 보안 실행 모드에 진입할 수 있다. 이 복합 복호화 엔진(3241)의 제1 부분은 복합 키로부터 전역 콘텐츠 관련 키를 발생시키기 위해 종단점 디바이스의 하드웨어 관련 비밀 키(1131)를 이용하여 달성될 수 있다(단계(3232)). 제2 복호화 동작(3242)은 이어서, 획득된 전역 콘텐츠 관련 키를 사용하여, 암호화된 콘텐츠(3210)로부터 복호화된 콘텐츠(3252)를 발생시키기 위해 복호화 동작(3241)에 의해 발생되는 중간 결과를 사용할 수 있다. 여기서 유의할 점은, 복호화 엔진(3240)이 한 쌍의 복호화 알고리즘들(3241 및 3242)로서 도시되어 있지만, 이는, 원래의 암호화된 데이터 세트(3210)에 적용되는 보안 코드 블록(3240)의 다양한 개별적인 구성요소들(3241, 3242 등)의 동작의 최종 결과가 원하는 복호화된 콘텐츠 결과(3252)를 생성하도록, 임의의 더 적은 또는 더 많은 수의 케스케이딩된 복호화 스테이지들을 포함할 수 있다는 것이다. 또한 유의할 점은, 이 다양한 개별적인 복호화 구성요소들 중 임의의 2개가 동일하거나 상이한 알고리즘들일 수 있다.
특정의 실시예들에서, 그에 부가하여, 보안을 추가적으로 계층화하는 것이 요망될 수 있고, 따라서, 어떤 실시예들에서, 도 25a, 도 28c 및 도 31과 관련하여 앞서 도시된 것과 실질적으로 동일한 방식으로, 복합 키가 종단점 디바이스 관련 하드웨어 키 및 종단점 관련 타임스탬프 값을 사용하여 사전 계산된 메시지 다이제스트로부터 형성될 수 있다.
도 33은 종단점 디바이스에서 재귀적 보안 프로토콜을 구현하는 하나의 실시예를 나타낸 것이다. 구체적으로는, 보안 코드 블록의 검증을 위해서는 물론 배포된 디지털 비트스트림의 실제의 복호화 또는 다른 사용을 위해 한 세트의 복합 키들을 사용하는 하나의 실시예가 도시되어 있다. 이 실시예는 많은 측면들에서 도 32에 도시된 실시예와 유사하고, 따라서 실시예의 상이한 그 측면들만이 도 33과 관련하여 중점적으로 다루어질 것이다. 복호화 엔진(3340)에 대한 포인터(3312)(또는 복호화 엔진 자체), (도 29와 관련하여 논의된) 콘텐츠 관련 복합 키(3331) 그리고 종단점 및 타임스탬프 관련 복합 키(3332)를 포함하는 암호화된 콘텐츠(3311)를 포함하는 메시지(3310)가 수신될 수 있다. 암호화된 콘텐츠(3311)는 종단점 디바이스에 있는 메모리에 로드될 수 있고, 복호화 엔진(3340)에 대한 포인터(3312)가 또한 메모리(예를 들어, 종단점 디바이스에 있는 명령어 캐시 또는 명령어 캐시의 보안 부분)에 로드될 수 있다. 지시되는 복호화 엔진(3340)이 이어서 인증될 것이다. 이 인증은, 도 32와 관련하여 기술된 것과 실질적으로 유사한 방식으로, 종단점 디바이스에 존재하는 해싱 함수(3321)를 사용하여 암호화 엔진(3340)의 메시지 다이제스트를 계산하는 것에 의해 달성될 수 있다.
이 예에서, 하드웨어 발생 메시지 다이제스트가 이어서 암호화 엔진을 사용하여 암호화될 수 있고, 이 암호화 엔진은 종단점 디바이스 상에서 하드웨어로 또는 소프트웨어로 구현될 수 있고, 계산된 메시지 다이제스트 및 하드웨어 관련 키들 또는 레지스터들 중 하나 이상(종단점 디바이스 하드웨어 관련 비밀 키(3370) 또는 종단점 디바이스 타임스탬프 레지스터(3360) 등)에 대해 동작하는 하나 이상의 케스케이딩된 복합 암호화 엔진 스테이지들(3324, 3325 등)을 포함한다. 발생되는 얻어진 복합 디지털 서명(3326)은 복호화 엔진 코드 블록(3340)에 정확하게 대응할 수 있고, 또한 (하나 이상의 암호화 스테이지들(3324, 3325) 그리고 3360 및 3370과 같은 다양한 비밀 또는 공개 변수들 또는 상수들) 특정의 종단점 디바이스에 암호적으로 바인딩되어 있을 수 있다. 앞서 논의된 바와 같이, 이 발생된 디지털 서명은 이 복합 디지털 서명의 적용가능성을 추가로 제한하기 위해 다른 제약 변수들 또는 상수들로 (동일하거나 상이한 암호화 엔진들을 사용하여) 선택적으로 추가로 암호화될 수 있다. 또한, 이 디지털 서명(3332)과 연관되어 있는 코드 블록(3340)의 적용을, 예를 들어, 단일의 고유의 종단점 유닛을 넘어 확장시키는 것이 요망되는 경우에, 잠재적인 발생된 복합 디지털 서명 일치들의 필드를 넓히기 위해 암호화 스테이지들 중 하나 이상이 선택적으로 제한될 수 있다.
발생된 복합 디지털 서명(3326)은 이어서 단계(3323)에서 (예를 들어, 이전의 시점에서 종단점 코드 라이센싱 프로세스의 일부로서 라이센싱 기관에 의해) 원래 종단점 디바이스에 제공되었을 수 있는 그 암호화 엔진(3340)에 대응하는 종단점 및 타임스탬프 관련 복합 디지털 서명(3332)과 비교될 수 있다. 유의할 점은, 이 토큰(3332)이 디지털 서명이든 키이든 간에, 데이터 구조가 동일할 수 있고, 따라서 "키" 및 "디지털 서명"이라는 용어들이 그 경우들에서 어쩌면 서로 바꾸어 사용될 수 있다는 것이다.
복합 디지털 서명들(3326 및 3332)이 실질적으로 동일한 경우, 종단점 디바이스의 프로세서는 복호화 엔진 코드 블록(3340)에 포함된 코드를 보안 실행 모드로 실행하도록 허용될 수 있다. 보안 실행 모드에서 실행 중일 때, 복호화 엔진(3340)은 복호화 엔진들(3341 또는 3342)을 사용하여 디바이스 관련 복합 키(3331)로부터 전역 콘텐츠 관련 키를 발생시키기 위해 종단점 디바이스의 하드웨어 키(3370)를 사용할 수 있다. 전역 콘텐츠 관련 키는 이와 같이 중간 결과일 수 있고, 그에 따라, 결코 캐싱되거나 복합 복호화 엔진 코드 블록(3340) 이외의 임의의 소프트웨어 또는 하드웨어 엔터티들에 다른 방식으로 보이게 되지 않을 수 있다. 이 전역 콘텐츠 관련 키는 이어서, 복호화 엔진(3343)을 통해 원래의 암호화된 콘텐츠(3311)로부터 최종적인 복호화된 콘텐츠(3350)를 발생시키는 데 사용된다.
그렇지만, 발생된 디지털 서명(3326)이 제공된 디지털 서명(3332)과 실질적으로 일치하지 않는 경우, 복호화 엔진 코드 블록(3340)을 사용하려는 시도들이 허가되지 않은 당사자들에 의해 행해지는 경우를 비롯한, 불일치가 일어날 수 있는 몇가지 가능한 이유들이 있을 수 있다. 그렇지만, 불일치에 대한 다른 가능한 이유는 복호화 엔진에 대한 소프트웨어가 업데이트된(그리고 종단점의 타임스탬프 레지스터가 마찬가지로 증가되거나 다른 방식으로 변경된) 경우일 수 있다. 이 경우에, 2개의 디지털 서명들이 일치하지 않을 수 있고, 단계(3381)에서 암호화 엔진 코드(3340) 자체가 (예를 들어) 암호화되는지 다른 방식으로 대체될 필요가 있는지가 검사될 수 있다. 본 명세서에서 논의되는 실시예들이 재귀적 보안 프로토콜에 대해 효과적으로 이용될 수 있고, 따라서, 많은 경우들에서, (지시되거나 암호화된 콘텐츠에 포함되어 있을 수 있는) 암호화 알고리즘들 자체가 암호화될 수 있고, 이 암호화된 암호화 알고리즘들 자체가 암호화될 수 있다는 것을 상기한다. 그에 따라, 암호화 알고리즘에 대한 발생된 종단점 및 타임스탬프 관련 복합 키(3326)와 수신된 종단점 및 타임스탬프 관련 복합 키(3332)가 일치하지 않으면, 적어도 하나의 우회(indirection) 또는 암호화 계층이 이용되는 경우가 있을 수 있다.
앞서 언급한 바와 같이, 암호화 계층을 특정의 실행가능 코드 블록에 부가하는 개념은 특정의 코드 블록의 오래된 버전을 그 코드 블록의 새로운 버전으로 대체하는 동작과 논리적으로 등가일 수 있다. 그에 따라, 그 코드 블록과 연관되어 있는 다음과 같은 토큰들, 즉 종단점 및 타임스탬프 관련 복합 디지털 서명(3332), 코드 블록의 복호화 포인터(도시 생략) 또는 코드 블록의 복호화 키 포인터(역시 도시 생략) 중 하나 이상을 검사하는 것으로 나타낸 바와 같이, (단계(1282)에 나타낸 것처럼) 복호화 엔진(3340) 자체가 암호화되어 있는지 다른 방식으로 대체를 필요로 하는지가 판정될 수 있다. 하나의 예에서, 코드 블록(3340)의 연관된 복호화 포인터가 널 값을 가리키는 경우, 이는 암호화 엔진(3340)이 암호화되지 않거나 다른 방식으로 오래되었다는 것을 나타내고, 따라서, 예외 오류가 일어날 수 있는데(단계(3383)), 그 이유는 발생된 디지털 서명(3326) 및 제공된 디지털 서명(3332)이 실질적으로 동일하지 않지만, 코드 블록을 아마도 정확한 디지털 서명을 생성할 수 있는 다른 버전으로 대체하기 위한 다른 의지할 것이 없을 수 있기 때문이다. 그렇지만, 복호화 엔진 코드 블록(3340)의 복호화 포인터가 다른 코드 블록, 즉 다른 (아마도 업데이트된) 암호화 엔진(도시 생략) 또는 어떤 다른 코드 블록을 가리키는 경우, 이 새로운 코드 블록이 로드될 수 있고, 상기한 인증 단계들이 이 다음의 암호화 엔진에 적용될 수 있다(환언하면, 다른 재귀 계층이 도입될 수 있다). 이 재귀적 실행 메커니즘은 발생된 종단점 및 타임스탬프 관련 복합 디지털 서명(3326)과 제공된 종단점 및 타임스탬프 관련 복합 디지털 서명(3332) 사이의 일치가 있는 것으로 판정될 때까지(단계(3327)) 또는 일치가 없고 복호화 엔진(3340) 자체가 암호화되어 있지 않은 것으로 판정될 때까지(이 시점에 예외 오류가 발생할 수 있음)(단계(3383)) 계속될 수 있다.
발생된 종단점 및 타임스탬프 관련 복합 디지털 서명(3326)과 제공된 종단점 및 타임스탬프 복합 디지털 서명(3332)이 일치하는 것으로 판정되는 경우, 재귀가 종료되고 풀릴(unwind) 수 있다. 이것은 전체적인 재귀적 호출 체인을 통한 초기 전방향 패스(forward pass) 동안 만나게 되어 스택에 저장된 코드 블록들 각각의 인증 및 실행을 수반할 수 있다. 유의할 점은, 이 코드 블록들 중 일부 또는 어쩌면 심지어 전부가 꼭 암호화 또는 복호화 엔진일 필요는 없을 수 있다. 어쨋든, 대상 종단점 디바이스의 프로세서가 보안 실행 모드로 동작하고 있는 동안 이 코드 블록들 각각이 인증될 수 있다.
이 실행은 재귀적 보안 시스템에 의해 수행될 수 있는 복호화 동작의 하나의 실시예를 나타낸 도 34를 참조하여 더 잘 설명될 수 있다. 기술된 바와 같이, 종단점 디바이스는, 그 중에서도 특히, (도 29와 관련하여 논의된 바와 같이) 콘텐츠 관련 복합 키(3416)와 함께 암호화된 콘텐츠(3412), 복호화 엔진 데이터 구조(3420)에 대한 포인터(3413) 또는 복호화 엔진 자체(원래의 메시지(3410)에 내장되어 있는 경우), 그리고 키 또는 키 목록 데이터 구조(3418)를 가리킬 수 있는 키 목록 포인터(3414)를 포함할 수 있는 메시지(3410)를 수신할 수 있다. 앞서 논의한 바와 같이, 이 데이터 구조는 키 또는 키 목록(3416) 또는 디지털 서명(3417)을 포함할 수 있다. 복호화 엔진 데이터 구조(3420)는, 차례로, 암호화된 코드 블록(3421), 암호화된(또는, 다른 대안으로서, 쓸모없어 대체할 필요가 있는) 복호화 코드 블록(3421)과 연관되어 있는 차후의 복호화 포인터(3422), 및 연관된 복호화 키 목록 포인터(3423)를 포함할 수 있다. 차후의 복호화 포인터(3422)는, 데이터 구조(3430)의 경우에, 복호화 코드 블록(3431) 자체가 암호화된 형태로 되어 있지 않은 것을 제외하고는, 복호화 코드 블록 데이터 구조(3420)의 구조와 실질적으로 유사한 구조를 가지는 최종 복호화 코드 블록 데이터 구조(3430)를 가리킬 수 있다.
도 34에 도시된 실시예의 동작은 다음과 같이 설명될 수 있다. 암호화된 콘텐츠 데이터 구조(3410)가 그 안에 포함된 암호화된 콘텐츠(3412)를 복호화할 것을 예상하여 종단점 프로세서의 메모리 공간에 로드된다. 데이터 구조(3410)가 복호화 포인터(3413)를 포함하기 때문에, 연관된 복호화 엔진 코드 블록 데이터 구조(3420)가 찾아내어져 메모리 내로 판독된다. 이 차후의 데이터 구조(3420)가 또한 복호화 포인터(3422)를 포함하기 때문에,포인터(3422)와 연관되어 있는 복호화 엔진 코드 블록 데이터 구조(3430)가 이어서 찾아내어져 메모리 내로 로드된다. 데이터 구조(3430)에 대해, 이 예에서 내장된 복호화 포인터(3432)는 널 포인터인 것으로 결정되고, 따라서 (예를 들어, 도 31에 논의된 바와 같이) 대상 종단점 디바이스의 보안 시스템이 이와 같이 현재의 복호화 재귀 체인이 종료된 것으로 판정할 수 있고, 이와 같이, 데이터 구조(3430)의 일부로서 메모리 내로 방금 판독된 복호화 엔진(3431)은 암호화되지 않은(그리고 따라서 어쩌면 실행가능한) 코드 블록을 포함할 수 있다.
디지털 콘텐츠(3431)가 (그것이 호출된 방식에 의해) 데이터가 아니라 코드 블록인 것으로 판정될 수 있기 때문에, 또한 (데이터 구조(3430)의 일부로서 메모리 내로 판독된) 복호화 키 목록 포인터(3433)가 가리키는 키 목록 데이터 구조(3438)가 (복합 키(3436)에 부가하여) 디지털 서명(3437)을 포함할 수 있는 것으로 판정될 수 있다. 또한 유의할 점은, 이 예에서 키 목록 데이터 구조들(3418, 3428 및 3438)이 도 28b와 관련하여 앞서 도시된 바와 같이 범용 암호 데이터 구조를 사용하여 구현될 수 있다는 것이다. 이와 같이, 이 키 목록 데이터 구조들(3418, 3428 및 3438)에서의 인수들의 순서가 꼭 고정되어 있지는 않고, 따라서 데이터 구조들 자체가 순회될 때 런타임 시에 해석될 수 있다. 사실, 유의할 점은, 이 키 목록 데이터 구조들(3418, 3428 및 3438) 자체는 보조 복호화 포인터들 및 키 목록 포인터들을 이 키 목록 데이터 구조들(3418, 3428 및 3438) 자체 중 일부 또는 전부 내에 포함시키는 것에 의해 추가적인 복호화 또는 차후의 해석에 대한 참조들을 포함할 수 있지만, 이 특정의 옵션이 간단함을 위해 도 34의 실시예에 도시되어 있지 않다.
또한 키 목록 데이터 구조(3438) 내의 키 포인터들(3436) 중 적어도 하나가 종단점의 하드웨어 비밀 키(3492)에 대한 참조에 대응하는 것으로 판정될 수 있다. 종단점의 하드웨어 비밀 키(3492)에 대한 이 참조는 적절히 예비된 메모리 장소(비록 프로세서에 의해 결코 직접 판독될 수 없고 따라서 직접 구조적으로 보이지 않지만, 프로세서의 아키텍처에서 명시될 수 있는 장소)를 가리키는 것에 의해 명시적으로 또는 포인터에 대한 어떤 특별히 예비된 값을 사용하는 것에 의해 암시적으로 달성될 수 있다. 어느 경우든지, 이 참조는 다양한 수단을 사용하여 구현될 수 있지만, 한 예에서, 하나의 이러한 실시예는 키 목록 데이터 구조에서의 "0"의 값("널"의 값과 구분됨)을 종단점의 하드웨어 비밀 키(3492)에 대한 참조와 동일시하는 것일 수 있다. 키 목록 데이터 구조의 적어도 하나의 부분이 종단점의 하드웨어 비밀 키(3492)를 참조한다는 사실은 또한 복호화 엔진 코드 블록(3431)이 대상 종단점 디바이스의 프로세서 상에서 보안 실행 모드로 실행되도록 의도되어 있다는 것을 나타낼 수 있다. 이와 같이, 하드웨어 기반 디지털 서명 발생기 블록(3490)의 출력이 데이터 구조(3437)에 저장된 값과 비교된다. 2개의 값들이 실질적으로 일치하는 경우에, 프로세서는 보안 실행 모드에 진입하도록 허용된다.
여기서 유의할 점은, 하드웨어 기반 디지털 서명 발생기 블록(3490)(그의 하나의 실시예의 상세는 도 36과 관련하여 더 포괄적으로 제시될 것임)은, 하나의 실시예에서, 하나 이상의 소프트웨어 기반 요소들을 포함할 수 있지만, 또한, 앞서 논의된 바와 같이, 적어도 하나의 하드웨어 기반 보안 구성요소를 직접 또는 간접적으로 포함할 수 있다. 그 하드웨어 구성요소는 본 명세서에 포함된 이전의 설명들 중 다수에서 언급되었던 그리고 전체적인 대상 종단점 유닛의 보안 시스템 신뢰 근간을 포함하는 하드웨어 기반 해싱 함수이다.
이 시점에서, 복호화 엔진 코드 블록(3431)은 종단점 프로세서가 어쩌면 종단점의 하드웨어 디바이스 관련 비밀 키(3492)를 보안 관련 계산(본 명세서에서 앞서 기술되었음)의 일부로서 사용할 수 있게 하는 보안 실행 모드로 실행되도록 허용된다. 프로세서가 보안 실행 모드로 동작하지 않은 경우에, 비밀 키(3492)의 값이 이러한 보안 관련 계산에서 사용하는 데 이용가능하지 않을 것이다. 이 개념은, 도 34와 관련하여, 프로세서가 보안 실행 모드로 실행 중인 경우 비밀 키(3492)의 값만이 (예를 들어, 복호화 엔진 코드 블록(3431)에서의) 차후의 사용으로 통과할 수 있게 하는 하드웨어 액세스 제어 블록(3443)으로서 도시되어 있다.
그에 부가하여, 하드웨어 액세스 제어 블록(3443)에 대한 입력 파라미터들 중 하나가 액세스 제어 블록(3441)의 출력인 것을 알 수 있다. 이러한 방식으로, (사실상 복호화 코드 블록(3421)에 대한 "보안 실행 모드 인에이블됨" 표시자인) 하드웨어 액세스 제어 블록(3443)의 상태는 복호화 코드 블록(3431)이 또한 보안 실행 모드로 실행 중이었다는 사실에 의존한다. 이것은 복호화 코드 블록(3431)에 대한 "보안 실행 모드 인에이블됨" 표시자의 상태(예를 들어, 하드웨어 액세스 제어 블록(3441)의 출력)로 나타내어질 수 있다. 이 의존 관계는 복호화 코드 블록(3431)이 또한 보안 실행 모드로 실행 중인 경우에만 보안 실행 모드로 실행될 수 있도록 복호화 엔진 코드 블록(3421)의 능력을 제약한다. 본질적으로 동일한 방식으로, 하드웨어 액세스 제어 블록(3443)의 출력은 복호화 코드 블록(3411)에 대한 "보안 실행 모드 인에이블됨" 표시자인 하드웨어 액세스 제어 블록(3445)에 대한 입력들 중 하나로서 사용된다. 이와 같이, 이 메커니즘은 선행하는 부모 코드 블록들이 적절히 인증된 경우에(도 35와 관련하여 더 상세히 설명될 것임) 그리고 동시에 재귀적 호출 체인에서 아래에 있는 하부로부터의 보안 체인의 적절히 허가된 부분들로부터 정품 복호화 결과들을 제공받는 경우에만 보안 실행 모드로 실행되도록 허가하기 위해, "보안 실행 모드 인에이블됨" 비트가 반대 방향으로 호출 체인을 따라 다시 위쪽으로 전파될 수 있게 한다. 유의할 점은, 앞서 기술된 바와 같이, 몇가지 조건들 중 임의의 것은 "보안 실행 모드 인에이블됨" 비트들 중 임의의 것을 "비보안" 기본 상태로 리셋시킬 수 있다(따라서 어쩌면 보안 체인 전체가 재시작되는 것을 필요로 함). 이러한 조건들은 프로세서 인터럽트 또는 차후의 디지털 서명 비교 불일치를 포함할 수 있다. 이 하드웨어 액세스 제어 블록들(3441, 3443 및 3445)이 도 34에서 명확함을 위해 개별적인 엔터티들로서 도시되어 있지만, 이들이, 사실, (도 36과 관련하여 기술된 것과 같은) 단일의 하드웨어 유닛(이의 출력은 따라서 그 자신의 입력 항들 중 하나로서 피드백됨)으로 구현될 수 있다는 것을 알 수 있다. 궁극적으로, 전체 체인에서의 최상위 레벨 또는 최종 "보안 실행 모드 인에이블됨" 비트의 출력(이 실시예에서, 하드웨어 액세스 제어 블록(3445)의 출력)은 (예를 들어, 오디오 또는 비디오 출력 인에이블과 같은) 대상 디바이스에 대한 어떤 외부에서 보이는 출력을 인에이블 또는 디스에이블시키기 위해 제어 메커니즘의 일부로서 사용될 수 있다.
단계(3470)에서의 복호화 엔진 코드 블록(3431)의 동작은 데이터 구조(3420)의 복호화 엔진 코드 블록 부분(3421)에 저장되어 있는 데이터 세트를 원래의 데이터의 업데이트된 및/또는 적절히 실행가능한 버전으로 대체하거나 다른 방식으로 보완하는 것이다. 이 동작은 3421에서 저장된 원래의 데이터를 이용하여 그리고 키 목록 데이터 구조(3428)에 저장되어 있거나 그에 의해 지시되는 하나 이상의 복호화 키들로 그를 복호화하여 달성될 수 있다. 다른 대안으로서, 앞서 논의된 바와 같이, 복호화 엔진 코드 블록(3431)의 동작(3470)은 복호화 코드 블록(3421)을 업데이트된 버전으로 대체하는 것 또는 심지어 복호화 엔진 코드 블록(3421) 대신에 직접 실행되는 것일 수 있다. 어쨋든, 복호화 엔진 코드 블록(3431)은 먼저 (이 실시예에서) 대상 종단점 디바이스의 타임스탬프 레지스터(3494)에 들어 있는 값, (하드웨어 액세스 제어(3442)를 통과하는 것에 의해 수정된) 대상 종단점 디바이스의 하드웨어 관련 비밀 키(3492) 그리고 종단점 및 타임스탬프 관련 복합 디지털 키(3426)를 비롯한 다양한 입력 데이터를 사용하여 동작할 수 있다. 복호화 엔진 코드 블록(3431)이 이어서 복호화 엔진 코드 블록(3421)의 직접적인 대체물로서 동작하는 경우에, 이는 입력 데이터의 제2 세트(예를 들어, 이 실시예에서, 대상 종단점 디바이스의 타임스탬프 레지스터(3494)에 들어 있는 값, (하드웨어 액세스 제어(3444)를 통과하는 것에 의해 수정된) 대상 종단점 디바이스의 하드웨어 관련 비밀 키(3492) 그리고 종단점 및 타임스탬프 관련 복합 디지털 키(3416))를 이용할 수 있다.
단계(3471)에서의 업데이트된 복호화 엔진 코드 블록(3421)의 추가적인 동작은, 원하는 출력 데이터(3480)를 생성하기 위해 원래의 암호화된 콘텐츠 데이터(3412)를 대체하거나 다른 방식으로 해석하는 것이다. 이 동작은 3412에서 저장된 원래의 데이터를 이용하여 그리고 키 목록 데이터 구조(3418)에 저장되어 있거나 그에 의해 지시되는 하나 이상의 복호화 키들로 그를 복호화하여 달성될 수 있다. 복호화 엔진 코드 블록들(3421 및 3431) 둘 다의 동작들이 사실상 유사하기 때문에, 복호화 엔진 코드 블록(3431)의 동작의 설명에서 앞서 상세히 기술한 옵션들 중 임의의 것이 복호화 엔진 코드 블록(3421)의 업데이트된 버전의 동작에 똑같이 적용가능하다는 것이 명백하다. 또한, 복호화 엔진 코드 블록(3421)의 동작의 경우에, 유의할 점은, 어떤 실시예들에서, 연관된 하드웨어 액세스 제어 블록(3444)이 하드웨어 액세스 제어 블록(3442)와 구분된다는 것이다. 그렇지만, 이 2개의 하드웨어 액세스 제어 블록들(3442 및 3444)의 동작들은 그들의 목적이 그들의 연관된 복호화 엔진들(3431 또는 3421)에 의해, 각각, 대상 종단점 디바이스의 하드웨어 관련 비밀 키(3492)의 사용을 인에이블 또는 디스에이블시키는 것이라는 점에서 사실상 유사하고, 따라서 다른 실시예들에서, 구별되지 않을 수 있다.
마지막으로, 앞서 기술된 도 34의 실시예에 나타낸 동작들 모두에서, 대상 종단점 디바이스의 타임스탬프 레지스터(3494)의 사용은 다른 실시예들에 대해 본 명세서에서 앞서 기술된 그 예들과 본질적으로 유사하다. 이와 같이, 레지스터(3494)에 저장된 값이 도 34에 도시된 특정의 실시예에 기술되어 있는 상이한 허가 및 복호화 동작들에서 이용되는 다양한 복합 키들 및/또는 디지털 서명들을 발생하는 데 부가의 요소로서 사용될 수 있다는 것은 당연하다.
도 35는 재귀적 호출 체인이 어떻게 순회되고 종료될 수 있는지 및 프로세서가 어떻게 하나 이상의 내장된 코드 블록들의 메시지 다이제스트 기반 인증을 사용하여 보안 실행 모드에 진입하도록 허용될 수 있는지의 하나의 실시예를 나타낸 것이다. 이 실시예에서, 2개의 후보 코드 블록들(3512 및 3522)의 동작이 설명될 수 있고, 도 28b와 관련하여 앞서 논의된 바와 같이, 그 둘 다는 범용 암호 데이터 구조들(각각, 3511 및 3521) 내에 포함되어 있을 수 있다.
주목할 점은, 코드 블록 데이터 구조(3521)가 도 35에 두번 나타내어져 있다는 것이다. 이 복제는 명확함을 위해 개별적인 반복들을 나타내기 위해 예시되어 있지만, 유의할 점은, 이것이 이들 경우 둘 다에서 완전히 동일한 데이터 구조라는 것이다. 그렇지만, 주목될 수 있는 하나의 차이는 키 목록 포인터(3521)의 경우들이 가리키는 키 목록 데이터 구조들(3528 및 3538)에 있다. 키 목록 포인터(3521)의 값이 이 도면에 도시되어 있는 2가지 경우들 간에 달라지지 않지만, 키 목록 데이터 구조(3528) 내에 포함되어 있는(또는 그가 가리키는) 값들이 2개의 반복들 간에 변할 수 있고, 따라서 이 상세는 데이터 구조(및 그의 다양한 구성요소들)를, 각각, 3526, 3527 및 3528로부터 3536, 3537 및 3538로 리넘버링하는 것에 의해 표시되어 있다. 이 구조가 리넘버링된다는 사실이 꼭 데이터 구조의 실제 위치가 이동되었다는 것을 나타내지 않고, 단지 그의 내용이 변경되었을 수 있다는 것을 나타낸다. 마찬가지로, 하드웨어 해싱 함수(3580)가 또한 명확함의 향상이라는 동일한 이유로 이 도면에 여러번 도시되어 있다. 마지막으로, 유의할 점은, 2개의 후보 코드 블록들(3512 또는 3522) 중 어느 것도 암호화되지 않고, 따라서 그들의 연관된 복호화 포인터들(3516, 3526 및 3536) 모두가 널 포인터들일 수 있다는 것이다.
이 실시예에서, 후보 코드 블록(3512)에 대한 호출이 개시될 수 있다. 앞서 기술된 것과 동일한 방식으로, 코드 블록 데이터 구조(3511)가 메모리 내로 판독될 수 있고, 그의 메시지 다이제스트(3541)가 (앞서 기술한 바와 같이, 전체적으로 또는 부분적으로 하드웨어로 실현될 수 있는) 해싱 함수(3580)에 의해 계산될 수 있다. 그렇지만, 이 실시예에서, 해싱 함수는 (모두 영으로 설정되어 있을 수 있거나 그렇지 않을 수 있는) 초기 씨드 값(3540)을 제공받을 수 있다. 앞서 논의된 바와 같이, 이 해싱 함수 씨드 값 특징은 다수의 방법들 중 하나를 사용하여 구현될 수 있지만, 이 실시예에서, 씨드 값(3540)이 알려져 있고, 그 값이 해싱 함수 블록(3580)의 메시지 다이제스트 출력(3541)에 영향을 미치는 방법이 반복가능하기도 하고 결정론적이기도 하다.
해싱 함수의 결과(3541)가 발생되면, 프로세서는 코드 블록(3512)에 포함된 코드를 실행하기 시작할 수 있다. 도 35에 도시된 실시예에서, 키 목록 포인터(3514)가 가리키는 (키 목록 데이터 구조(3518) 내에 포함되어 있는) 장소들(3516 및 3517) 둘 다의 값들 및 복호화 포인터(3513) 둘 다가 모두 널인 경우, 코드 블록(3512)은 보안 실행 모드로 실행되도록 설계되지 않을 수 있고, 따라서 대상 종단점 유닛의 보안 하드웨어 특징들 중 임의의 것의 사용을 필요로 하지 않는다. 따라서, 프로세서는 코드 블록(3522)을 가리키는 내장된 서브루틴 호출에 도달할 때까지 코드 블록(3512) 내에 포함된 명령어들을 실행하기 시작한다.
그 시점에서, 코드 블록 데이터 구조(3521)는 메모리 내로 로드되고, 그 다음 메시지 다이제스트(3542)를 발생시키는 프로세스가 해싱 함수 블록(3580)에 의해 반복된다. 그렇지만, 이 특정의 경우에, 해싱 함수 씨드 값이 더 이상 초기 씨드 값(3540)이 아니고 오히려 이전에 발생된 결과(3541)일 수 있다. 이와 같이, 메시지 다이제스트(3542)의 값이 코드 블록들(3511 및 3521) 둘 다의 메시지 다이제스트에 결정론적으로 의존하는 것으로 보일 수 있다. 그렇지만, 이전의 경우에서와 같이, 복호화 포인터(3523)의 값들 및 키 목록 포인터(3524)가 가리키는 키 목록 데이터 구조(3528)에 포함된 값들이 여전히 널일 수 있고, 따라서 프로세서가 이전과 같이 비보안 실행 모드로 계속된다.
어떤 나중의 시점에서, 프로세서는 다른 서브루틴 호출을 만나지만, 이 예에서, 코드 블록(3522)은 재귀적 호출(예를 들어, 그 자신에 대한 서브루틴 호출)을 포함한다. 유의할 점은, 특정의 실시예들에서, 이러한 재귀적 호출 구조는 단지 예시적인 것이고, 대상 종단점 디바이스의 보안 시스템의 정확한 동작이 다른 수단에 의해 달성될 수 있고, 예를 들어, 보안 시스템에 대한 임의의 호출들이 단일의 코드 계층 내에 포함되도록 보장한다. 그렇지만, 보안 시스템의 다수의 레벨들이 순회되자마자, 재귀적 호출 형태가, 앞서 상세히 기술한 바와 같이, 비교적 더 안전할 수 있고, 도시된 실시예와 관련하여 보안 시스템을 구현하기 위해 효과적으로 이용될 수 있다.
어쨋든, 프로세서가 (그 자신을 참조하는) 코드 블록(3522) 내에 내장된 서브루틴 호출을 만날 때, 코드 블록 데이터 구조(3521)가 또 다시 메모리 내에 로드되고(예를 들어, 대부분의 최근의 시스템들에서, 데이터 구조(3521)는 두번째로 페치될 때 상이한 물리적 장소로 로드될 수 있음), 해싱 함수(3580)는 새로운 메시지 다이제스트(3543)를 계산한다. 주목할 점은, 이 새로운 메시지 다이제스트(3543)가 초기 메시지 다이제스트 씨드 값(3540), (코드 블록(3512)의) 메시지 다이제스트(3541)는 물론 코드 블록(3522)의 2개의 개별적인 반복들의 메시지 다이제스트에 의존한다는 것이다.
또한 유의할 점은, 이 두번째에서, 키 목록 포인터가 널이 아닌(non-null) 디지털 서명 값(3537)을 포함하는 새로운 데이터 구조(3538)를 가리킨다는 것이다. 이 널이 아닌 값은 코드 블록(3522)의 이 반복이 대상 종단점 하드웨어 관련 보안 시스템에 대한 참조를 포함한다는 보안 시스템에 대한 표시자이다. 이와 같이, 이 실시예에서, 이러한 참조가 제대로 동작하기 위해, 프로세서는 어떤 시점에서 보안 실행 모드에 진입해야만 한다. 이와 같이, 코드 블록 데이터 구조(3521)가 가장 최근에 메모리 내에 로드되었을 때 발생된 디지털 서명(3543)이 이어서 키 목록 데이터 구조(3538) 내에 포함된 디지털 서명(3537)과 비교될 수 있다. 2개의 값들이 단계(3591)에서 실질적으로 유사한 것으로 발견되는 경우, 대상 종단점 프로세서는 보안 실행 모드에 진입하도록 허용된다. 그렇지만, 2개의 디지털 서명 값들(3537 및 3543)이 일치하지 않는 경우(그리고 디지털 서명(3537)이 이 시점에서 널이 아닌 것으로 알려져 있는 경우), 단계(3592)의 결과는 보안 시스템의 적절한 예외 오류 핸들러 부분(3570)을 실행하라고 프로세서에 지시하는 것이다.
도 36은 앞서 상세히 기술된 특징들을 지원하기 위해 디지털 서명 발생기 블록(3660)이 어떻게 하드웨어로 구현될 수 있는지의 하나의 실시예를 나타낸 것이다. 도 36에 도시되어 있는 실시예는 도 31에 도시된 디지털 서명 발생기 블록의 기능과 유사한 기능의 하드웨어 구현을 나타낸 것이고, 이는, 예를 들어, 도 32, 도 33, 도 34 및 도 35와 관련하여, 동작 상세에 기술된 기능 특징들을 지원할 것이다.
해싱 함수 씨드 레지스터(3510)는 도 35의 블록(3540)으로 표시된 것과 유사한 기능을 포함할 수 있고, 해싱 함수 블록(3661)에 피드되는 초기 값을 보유하는 기능을 할 수 있다. 해싱 함수 블록(3661)의 출력은 복합 암호화 엔진의 제1 스테이지(3662)에의 입력들 중 하나로서 피드된다. 암호화 엔진(3662)에의 다른 입력은 대상 종단점 디바이스의 타임스탬프 레지스터(3641)의 출력이다. 제1 스테이지 암호화 엔진(3662)의 얻어진 출력은 이어서 제2 스테이지 암호화 엔진(3663)에의 입력들 중 하나로서 제공된다. 제2 스테이지 암호화 엔진(3663)에의 다른 입력은 보안 실행 모드 액세스 포인트(3666)의 출력이다.
액세스 포인트(3666)는, 도 35와 관련하여 앞서 상세히 기술한 바와 같이, 대상 종단점 디바이스가 보안 실행 모드로 실행 중일 때 또는 "재귀 종료" 조건이 검출될 때에만 대상 종단점의 하드웨어 관련 비밀 키(3640)의 값을 통과시키는 동작을 한다. 제2 스테이지 암호화 엔진(3663)으로부터 얻어진 출력 값이 이어서 이 발생된 디지털 서명을 (예를 들어, 도 30, 도 31, 도 32, 도 33, 도 34 및 도 35의 설명들에서 언급된 바와 같이) 후보 코드 블록들과 함께 제공되는 디지털 서명들과 비교하는 데 사용하기 위해 디지털 서명 레지스터(3664)에 저장된다.
디지털 서명 레지스터(3664)의 출력은 액세스 포인트(3665)에 의해 게이팅되고, 액세스 포인트(3665)의 동작은 대상 종단점 디바이스가 보안 실행 모드로 실행하고 있지 않을 때 디지털 서명 레지스터(3664)의 값을 통과시키는 것이다. 액세스 포인트(3665)의 출력은 이어서 도 35와 관련한 설명에서 상세히 기술한 케스케이딩된 메시지 다이제스트 특징을 생성하기 위해 해싱 함수 씨드 레지스터(3610)의 입력에 피드백된다. 대상 종단점 디바이스가 보안 실행 모드에서 실행 중일 때, 해싱 함수 씨드 레지스터(3610)에의 입력은 디지털 서명 레지스터(3664)의 값에 의존하지 않고, 따라서 어떤 초기 값으로(도 35와 관련한 설명에서 상세히 기술됨) 또는 어떤 다른 수단에 의해(예를 들어, 특정의 메모리 장소에의 프로세서 기입 등) 설정될 수 있다.
본 명세서에 기술된 실시예들은 소프트웨어 또는 하드웨어 또는 이 둘의 조합으로 제어 논리의 형태로 구현될 수 있다. 제어 논리는 다양한 실시예들에 개시된 한 세트의 단계들을 수행하라고 정보 처리 디바이스에 지시하도록 구성되어 있는 복수의 명령어들로서 컴퓨터 판독가능 매체와 같은 정보 저장 매체에 저장될 수 있다. 본 명세서에 제공된 개시 내용에 기초하여, 당업자라면 본 발명을 구현하는 다른 방식들 및/또는 방법들을 잘 알 것이다.
또한 본 명세서에 기술되어 있는 단계들, 동작들, 방법들, 루틴들 또는 그의 일부분들을 소프트웨어 프로그래밍으로 구현하는 것이 본 발명의 사상 및 범위 내에 속하고, 여기서 이러한 소프트웨어 프로그래밍 또는 코드는 컴퓨터 판독가능 매체에 저장될 수 있고, 컴퓨터가 본 명세서에 기술되어 있는 단계들, 동작들, 방법들, 루틴들 또는 그의 일부분들 중 임의의 것을 수행할 수 있게 하기 위해 프로세서에 의해 처리될 수 있다. 본 발명은 하나 이상의 범용 디지털 컴퓨터들에서 소프트웨어 프로그래밍 또는 코드를 사용하여, ASIC(application specific integrated circuit), PLD(programmable logic device), FPGA(field programmable gate array)을 사용하여 구현될 수 있고, 광학, 화학, 생물학, 양자 또는 나노엔지니어링된 시스템들, 구성요소들 및 메커니즘들이 사용될 수 있다. 일반적으로, 본 발명의 기능들은 기술 분야에 공지되어 있는 임의의 수단에 의해 달성될 수 있다. 예를 들어, 분산된 또는 네트워크로 연결된 시스템들, 구성요소들 및 회로들이 사용될 수 있다. 다른 예에서, 데이터의 전달 또는 전송이 유선, 무선, 또는 임의의 다른 수단에 의할 수 있다.
"컴퓨터 판독가능 매체"는 명령어 실행 시스템, 장치, 시스템 또는 디바이스에서 또는 그와 관련하여 사용하기 위한 프로그램을 포함하거나, 저장하거나, 전달하거나, 전파하거나, 전송할 수 있는 임의의 매체일 수 있다. 컴퓨터 판독가능 매체는, 제한이 아니라 단지 예로서, 전자, 자기, 광학, 전자기, 적외선, 또는 반도체 시스템, 장치, 시스템, 디바이스, 전파 매체, 또는 컴퓨터 메모리일 수 있다. 이러한 컴퓨터 판독가능 매체는 일반적으로 기계 판독가능이고, 사람 판독가능(예컨대, 소스 코드)하거나 기계 판독가능(예컨대, 오브젝트 코드)할 수 있는 소프트웨어 프로그래밍 또는 코드를 포함한다.
"프로세서"는 데이터, 신호 또는 다른 정보를 처리하는 임의의 하드웨어 시스템, 메커니즘 또는 구성요소를 포함한다. 프로세서는 기능을 달성하기 위한 범용 중앙 처리 유닛, 다수의 처리 유닛들, 전용 회로, 또는 다른 시스템들을 갖는 시스템을 포함할 수 있다. 처리는 지리적 위치로 제한될 필요가 없거나 시간적 제한을 가질 필요가 없다. 예를 들어, 프로세서는 "실시간으로", "오프라인으로", "배치 모드로", 기타로 그의 기능들을 수행할 수 있다. 처리의 일부분들이 상이한 때에 그리고 상이한 장소들에서, 상이한(또는 동일한) 처리 시스템들에 의해 수행될 수 있다.
또한, 도면들에 도시된 요소들 중 하나 이상이 또한, 특정의 응용에 따라 유용한 바와 같이, 더 분리된 또는 통합된 방식으로 구현될 수 있거나, 특정의 경우들에서 제거되거나 동작하지 않는 것으로 될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 도면들에서의 임의의 신호 화살표는, 달리 특별히 언급하지 않는 한, 제한하는 것이 아니라 단지 예시적인 것으로 간주되어야 한다.
게다가, "또는"이라는 용어는, 본 명세서에서 사용되는 바와 같이, 달리 언급하지 않는 한, 일반적으로 "및/또는"을 의미하는 것으로 보아야 한다. 본 명세서에서 사용되는 바와 같이, 단수 관형사(단수 관형사가 앞서 나온 경우, 지시사) 다음에 나오는 용어는 단일의 및 복수의 이러한 용어를 포함한다(즉, 단수 관형사는 명백히 단수만 또는 복수만을 나타냄). 또한, 본 명세서에서의 설명에서 사용되는 바와 같이, "~에"의 의미는, 문맥이 명확히 달리 말하지 않는 한, "~에" 및 "~ 상에"를 포함한다.
이점들, 다른 장점들, 및 문제들에 대한 해결책들이 특정의 실시예들과 관련하여 앞서 기술되었다. 그렇지만, 임의의 이점, 장점, 또는 해결책을 가져올 수 있거나 더 두드러지게 할 수 있는 이점들, 장점들, 문제들에 대한 해결책들, 및 임의의 구성요소(들)이 아주 중요한, 요구된 또는 필수적인 특징 또는 구성요소로서 해석되지 않는다.

Claims (21)

  1. 시스템에 있어서,
    프로세서;
    메모리;
    하드웨어에 저장된 비밀 키;
    상기 프로세서 상에서 보안 모드로 실행되는 프로세스의 데이터를 포함하는 라인을 갖는 캐시; 및
    상기 프로세스만이 상기 캐시의 상기 라인에 액세스할 수 있도록, 상기 프로세스와 연관되어 있는 그리고 상기 비밀 키에 기초한 제1 보안 서술자(secure descriptor)를 사용하여 상기 캐시의 상기 라인에 대한 액세스를 제어하도록 구성되어 있는 보안 실행 제어기(secure execution controller)
    를 포함하는, 시스템.
  2. 제1항에 있어서,
    상기 시스템은 상기 제1 보안 서술자에 기초하여 보안 모드에 있었던 것인, 시스템.
  3. 제1항에 있어서,
    상기 보안 실행 제어기는 상기 프로세스의 전체 작업 세트가 상기 캐시에 저장되게 하도록 그리고 상기 보안 모드에 있는 상기 캐시 이외의 메모리 장소에의 기입들이 디스에이블되게 하도록 구성되는 것인, 시스템.
  4. 제1항에 있어서,
    상기 프로세스는 종료된 것인, 시스템.
  5. 제3항에 있어서,
    상기 보안 실행 제어기는 상기 캐시의 상기 라인을 상기 프로세스와 연관되어 있는 상기 제1 보안 서술자와 연관시키도록 구성되는 것인, 시스템.
  6. 제5항에 있어서,
    상기 보안 실행 제어기는, 상기 프로세스가 상기 데이터를 기입할 때, 상기 캐시의 상기 라인과 연관되어 있는 보안 플래그를 세트시키도록 구성되는 것인, 시스템.
  7. 제6항에 있어서, 상기 보안 실행 제어기는,
    상기 캐시의 라인이 현재 실행 중인 프로세스에 의해 액세스되고 있는 것으로 판정하는 단계,
    현재 실행 중인 프로세스가 보안 모드로 실행 중인지를 판정하는 단계,
    상기 현재 실행 중인 프로세스와 연관되어 있는 제2 보안 서술자를 결정하는 단계,
    상기 제1 보안 서술자와 상기 제2 보안 서술자를 비교하는 단계, 및
    상기 현재 실행 중인 프로세스가 보안 모드로 실행 중이고 상기 제1 보안 서술자가 상기 제2 보안 서술자와 일치하는 경우에만 액세스를 허용하는 단계
    가 수행되게 함으로써 액세스를 제어하도록 구성되는 것인, 시스템.
  8. 프로세서 상에서 보안 모드로 프로세스를 실행하는 단계;
    캐시의 라인에 데이터를 저장하는 단계 ― 상기 데이터는 상기 프로세서 상에서 상기 보안 모드로 실행되는 상기 프로세스에 의해 저장되었음 ― ; 및
    상기 프로세스만이 상기 캐시의 상기 라인에 액세스할 수 있도록, 상기 프로세스와 연관되어 있는 제1 보안 서술자를 사용하여 상기 캐시의 상기 라인에 대한 액세스를 제어하는 단계 ― 상기 제1 보안 서술자는 상기 프로세서 및 상기 캐시를 포함하는 시스템의 하드웨어에 저장되어 있는 비밀 키에 기초함 ―
    를 포함하는, 방법.
  9. 제8항에 있어서,
    상기 보안 모드는 상기 제1 보안 서술자에 기초하여 진입된 것인, 방법.
  10. 제8항에 있어서,
    상기 프로세스의 전체 작업 세트를 상기 캐시에 저장하는 단계, 및 상기 보안 모드에서 상기 캐시 이외의 메모리 장소에의 기입들을 디스에이블시키는 단계를 더 포함하는, 방법.
  11. 제8항에 있어서,
    상기 프로세스는 종료된 것인, 방법.
  12. 제10항에 있어서,
    상기 캐시의 상기 라인을 상기 프로세스와 연관되어 있는 상기 제1 보안 서술자와 연관시키는 단계를 더 포함하는, 방법.
  13. 제12항에 있어서,
    상기 프로세스가 상기 데이터를 기입할 때 상기 캐시의 상기 라인과 연관되어 있는 보안 플래그를 세트시키는 단계를 더 포함하는, 방법.
  14. 제13항에 있어서, 상기 액세스를 제어하는 단계는,
    상기 캐시의 상기 라인이 현재 실행 중인 프로세스에 의해 액세스되고 있는 것으로 판정하는 단계,
    현재 실행 중인 프로세스가 보안 모드로 실행 중인지를 판정하는 단계,
    상기 현재 실행 중인 프로세스와 연관되어 있는 제2 보안 서술자를 결정하는 단계,
    상기 제1 보안 서술자와 상기 제2 보안 서술자를 비교하는 단계, 및
    상기 현재 실행 중인 프로세스가 보안 모드로 실행 중이고 상기 제1 보안 서술자가 상기 제2 보안 서술자와 일치하는 경우에만 액세스를 허용하는 단계
    를 포함하는 것인, 방법.
  15. 비일시적 컴퓨터 판독가능 매체에 있어서,
    프로세서 상에서 보안 모드로 프로세스를 실행하기 위한 명령어들;
    캐시의 라인에 데이터를 저장하기 위한 명령어들 ― 상기 데이터는 상기 프로세서 상에서 상기 보안 모드로 실행되는 상기 프로세스에 의해 저장되었음 ― ; 및
    상기 프로세스만이 상기 캐시의 상기 라인에 액세스할 수 있도록, 상기 프로세스와 연관되어 있는 제1 보안 서술자를 사용하여 상기 캐시의 상기 라인에 대한 액세스를 제어하기 위한 명령어들 ― 상기 제1 보안 서술자는 상기 프로세서 및 상기 캐시를 포함하는 시스템의 하드웨어에 저장되어 있는 비밀 키에 기초함 ―
    을 포함하는, 컴퓨터 판독가능 매체.
  16. 제15항에 있어서,
    상기 보안 모드는 상기 제1 보안 서술자에 기초하여 진입된 것인, 컴퓨터 판독가능 매체.
  17. 제15항에 있어서,
    상기 프로세스의 전체 작업 세트를 상기 캐시에 저장하고 상기 보안 모드에서 상기 캐시 이외의 메모리 장소에의 기입들을 디스에이블시키기 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 매체.
  18. 제15항에 있어서,
    상기 프로세스는 종료된 것인, 컴퓨터 판독가능 매체.
  19. 제17항에 있어서,
    상기 캐시의 상기 라인을 상기 프로세스와 연관되어 있는 상기 제1 보안 서술자와 연관시키기 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 매체.
  20. 제19항에 있어서,
    상기 프로세스가 상기 데이터를 기입할 때 상기 캐시의 상기 라인과 연관되어 있는 보안 플래그를 세트시키기 위한 명령어들을 더 포함하는, 컴퓨터 판독가능 매체.
  21. 제20항에 있어서, 상기 액세스를 제어하는 것은,
    상기 캐시의 상기 라인이 현재 실행 중인 프로세스에 의해 액세스되고 있는 것으로 판정하는 것,
    현재 실행 중인 프로세스가 보안 모드로 실행 중인지를 판정하는 것,
    상기 현재 실행 중인 프로세스와 연관되어 있는 제2 보안 서술자를 결정하는 것,
    상기 제1 보안 서술자와 상기 제2 보안 서술자를 비교하는 것, 및
    상기 현재 실행 중인 프로세스가 보안 모드로 실행 중이고 상기 제1 보안 서술자가 상기 제2 보안 서술자와 일치하는 경우에만 액세스를 허용하는 것
    을 포함하는 것인, 컴퓨터 판독가능 매체.
KR1020147029364A 2012-03-20 2013-03-19 프로세스 작업 세트 격리를 위한 방법 및 시스템 KR20150011802A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261613290P 2012-03-20 2012-03-20
US61/613,290 2012-03-20
PCT/US2013/033009 WO2013142517A1 (en) 2012-03-20 2013-03-19 Method and system for process working set isolation

Publications (1)

Publication Number Publication Date
KR20150011802A true KR20150011802A (ko) 2015-02-02

Family

ID=49213445

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147029364A KR20150011802A (ko) 2012-03-20 2013-03-19 프로세스 작업 세트 격리를 위한 방법 및 시스템

Country Status (5)

Country Link
US (2) US9575906B2 (ko)
EP (1) EP2828759A4 (ko)
JP (1) JP2015511050A (ko)
KR (1) KR20150011802A (ko)
WO (1) WO2013142517A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190092948A (ko) * 2018-01-31 2019-08-08 에스케이하이닉스 주식회사 저장 장치 및 그 동작 방법

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8438392B2 (en) 2002-06-20 2013-05-07 Krimmeni Technologies, Inc. Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol
US7203844B1 (en) * 2002-06-20 2007-04-10 Oxford William V Method and system for a recursive security protocol for digital copyright control
US8904189B1 (en) 2010-07-15 2014-12-02 The Research Foundation For The State University Of New York System and method for validating program execution at run-time using control flow signatures
JP6402034B2 (ja) * 2011-09-13 2018-10-10 フェイスブック，インク． コンピュータ内の情報を安全に保つシステム及び方法
US9477603B2 (en) 2013-09-05 2016-10-25 Facebook, Inc. System and method for partitioning of memory units into non-conflicting sets
US9983894B2 (en) 2013-09-25 2018-05-29 Facebook, Inc. Method and system for providing secure system execution on hardware supporting secure application execution
US10049048B1 (en) 2013-10-01 2018-08-14 Facebook, Inc. Method and system for using processor enclaves and cache partitioning to assist a software cryptoprocessor
US9747450B2 (en) 2014-02-10 2017-08-29 Facebook, Inc. Attestation using a combined measurement and its constituent measurements
JP6488317B2 (ja) 2014-03-14 2019-03-20 アビニシオ テクノロジー エルエルシー キー指定される実体の属性のマッピング
US9734092B2 (en) 2014-03-19 2017-08-15 Facebook, Inc. Secure support for I/O in software cryptoprocessor
WO2015157693A2 (en) * 2014-04-11 2015-10-15 Rubicon Labs, Inc. System and method for an efficient authentication and key exchange protocol
US9639671B2 (en) * 2014-05-27 2017-05-02 Assured Information Security, Inc. Secure execution of encrypted program instructions
US9830162B2 (en) * 2014-12-15 2017-11-28 Intel Corporation Technologies for indirect branch target security
FR3030827B1 (fr) 2014-12-19 2017-01-27 Stmicroelectronics (Grenoble 2) Sas Procede et dispositif de traitement securise de donnees cryptees
US20160188874A1 (en) * 2014-12-29 2016-06-30 Rubicon Labs, Inc. System and method for secure code entry point control
US10440036B2 (en) * 2015-12-09 2019-10-08 Checkpoint Software Technologies Ltd Method and system for modeling all operations and executions of an attack and malicious process entry
US10291634B2 (en) 2015-12-09 2019-05-14 Checkpoint Software Technologies Ltd. System and method for determining summary events of an attack
US10880316B2 (en) * 2015-12-09 2020-12-29 Check Point Software Technologies Ltd. Method and system for determining initial execution of an attack
US9660978B1 (en) * 2016-08-08 2017-05-23 ISARA Corporation Using a digital certificate with multiple cryptosystems
US10102375B2 (en) 2016-08-11 2018-10-16 Qualcomm Incorporated Multi-modal memory hierarchical management for mitigating side-channel attacks in the cloud
KR102649209B1 (ko) * 2016-09-15 2024-03-20 너츠 홀딩스 엘엘씨 암호화된 사용자 데이터 송신 및 저장
CN108965220B (zh) * 2017-11-29 2021-04-23 视联动力信息技术股份有限公司 一种会议控制权同步的方法及系统
US10944557B2 (en) * 2018-04-25 2021-03-09 Nxp B.V. Secure activation of functionality in a data processing system
US10852988B2 (en) * 2018-04-30 2020-12-01 Intel Corporation On access memory zeroing
US11138132B2 (en) * 2018-06-20 2021-10-05 Intel Corporation Technologies for secure I/O with accelerator devices
US10425401B1 (en) 2018-10-31 2019-09-24 ISARA Corporation Extensions for using a digital certificate with multiple cryptosystems
US11190336B2 (en) * 2019-05-10 2021-11-30 Sap Se Privacy-preserving benchmarking with interval statistics reducing leakage
US20210004795A1 (en) * 2019-07-03 2021-01-07 Sap Se Anomaly and fraud detection using duplicate event detector
US11282078B2 (en) 2019-07-03 2022-03-22 Sap Se Transaction auditing using token extraction and model matching
US11645425B2 (en) 2019-07-03 2023-05-09 Beyond Semiconductor, d.o.o. Systems and methods for data-driven secure and safe computing
DE102019128528A1 (de) 2019-10-22 2021-04-22 Infineon Technologies Ag Datenkryptografievorrichtungen und speichersysteme
US11907132B2 (en) * 2022-03-23 2024-02-20 International Business Machines Corporation Final cache directory state indication
EP4261679A1 (en) * 2022-04-13 2023-10-18 Thales Dis France SAS Method for a secure execution of instructions

Family Cites Families (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4293910A (en) * 1979-07-02 1981-10-06 International Business Machines Corporation Reconfigurable key-in-storage means for protecting interleaved main storage
FR2514593B1 (fr) 1981-10-09 1986-12-26 Bull Sa Procede et dispositif pour authentifier la signature d'un message signe
US5319710A (en) 1986-08-22 1994-06-07 Tandem Computers Incorporated Method and means for combining and managing personal verification and message authentication encrytions for network transmission
US4893339A (en) 1986-09-03 1990-01-09 Motorola, Inc. Secure communication system
US5029207A (en) 1990-02-01 1991-07-02 Scientific-Atlanta, Inc. External security module for a television signal decoder
US5210748A (en) 1990-02-09 1993-05-11 Hitachi, Ltd. Address filter unit for carrying out address filter processing among plurality of networks and method thereof
US5210870A (en) 1990-03-27 1993-05-11 International Business Machines Database sort and merge apparatus with multiple memory arrays having alternating access
US5222136A (en) 1992-07-23 1993-06-22 Crest Industries, Inc. Encrypted communication system
US5285497A (en) 1993-04-01 1994-02-08 Scientific Atlanta Methods and apparatus for scrambling and unscrambling compressed data streams
US5343527A (en) 1993-10-27 1994-08-30 International Business Machines Corporation Hybrid encryption method and system for protecting reusable software components
GB2288476A (en) 1994-04-05 1995-10-18 Ibm Authentication of printed documents.
US5724425A (en) 1994-06-10 1998-03-03 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
CN101303717B (zh) 1995-02-13 2015-04-29 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
JPH0950465A (ja) 1995-08-04 1997-02-18 Hitachi Ltd 電子ショッピング方法、電子ショッピングシステムおよび文書認証方法
US5623545A (en) 1995-08-31 1997-04-22 National Semiconductor Corporation Automatic data generation for self-test of cryptographic hash algorithms in personal security devices
US5631961A (en) 1995-09-15 1997-05-20 The United States Of America As Represented By The Director Of The National Security Agency Device for and method of cryptography that allows third party access
US5764774A (en) 1995-09-25 1998-06-09 Intermec Corporation Source data compression and decompression in code symbol printing and decoding
US5999629A (en) 1995-10-31 1999-12-07 Lucent Technologies Inc. Data encryption security module
US6055314A (en) 1996-03-22 2000-04-25 Microsoft Corporation System and method for secure purchase and delivery of video content programs
US6009176A (en) 1997-02-13 1999-12-28 International Business Machines Corporation How to sign digital streams
US6101605A (en) 1997-05-15 2000-08-08 Vlsi Technology, Inc. Method and apparatus for performing a secure operation
US5890129A (en) 1997-05-30 1999-03-30 Spurgeon; Loren J. System for exchanging health care insurance information
US6378072B1 (en) 1998-02-03 2002-04-23 Compaq Computer Corporation Cryptographic system
US7809138B2 (en) 1999-03-16 2010-10-05 Intertrust Technologies Corporation Methods and apparatus for persistent control and protection of content
US6226742B1 (en) 1998-04-20 2001-05-01 Microsoft Corporation Cryptographic technique that provides fast encryption and decryption and assures integrity of a ciphertext message through use of a message authentication code formed through cipher block chaining of the plaintext message
JP2000010860A (ja) * 1998-06-16 2000-01-14 Hitachi Ltd キャッシュメモリ制御回路及びプロセッサ及びプロセッサシステム及び並列プロセッサシステム
US6278966B1 (en) 1998-06-18 2001-08-21 International Business Machines Corporation Method and system for emulating web site traffic to identify web site usage patterns
US6865675B1 (en) 1998-07-14 2005-03-08 Koninklijke Philips Electronics N.V. Method and apparatus for use of a watermark and a unique time dependent reference for the purpose of copy protection
US6438235B2 (en) 1998-08-05 2002-08-20 Hewlett-Packard Company Media content protection utilizing public key cryptography
US6389403B1 (en) 1998-08-13 2002-05-14 International Business Machines Corporation Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system
US6226618B1 (en) 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US7228437B2 (en) 1998-08-13 2007-06-05 International Business Machines Corporation Method and system for securing local database file of local content stored on end-user system
US6412070B1 (en) 1998-09-21 2002-06-25 Microsoft Corporation Extensible security system and method for controlling access to objects in a computing environment
US6330670B1 (en) 1998-10-26 2001-12-11 Microsoft Corporation Digital rights management operating system
US6327652B1 (en) 1998-10-26 2001-12-04 Microsoft Corporation Loading and identifying a digital rights management operating system
JP2000155735A (ja) 1998-11-20 2000-06-06 Mitsubishi Electric Corp ディジタルコンテンツ配布システム装置
FR2787900B1 (fr) 1998-12-28 2001-02-09 Bull Cp8 Circuit integre intelligent
US6654889B1 (en) 1999-02-19 2003-11-25 Xilinx, Inc. Method and apparatus for protecting proprietary configuration data for programmable logic devices
US6367019B1 (en) 1999-03-26 2002-04-02 Liquid Audio, Inc. Copy security for portable music players
US7073063B2 (en) 1999-03-27 2006-07-04 Microsoft Corporation Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like
US7225333B2 (en) 1999-03-27 2007-05-29 Microsoft Corporation Secure processor architecture for use with a digital rights management (DRM) system on a computing device
US6701432B1 (en) 1999-04-01 2004-03-02 Netscreen Technologies, Inc. Firewall including local bus
US6681214B1 (en) 1999-06-29 2004-01-20 Assure Systems, Inc. Secure system for printing authenticating digital signatures
KR100682290B1 (ko) 1999-09-07 2007-02-15 소니 가부시끼 가이샤 콘텐츠 관리 시스템, 장치, 방법 및 프로그램 격납 매체
US6683954B1 (en) 1999-10-23 2004-01-27 Lockstream Corporation Key encryption using a client-unique additional key for fraud prevention
KR100652098B1 (ko) 2000-01-21 2006-12-01 소니 가부시끼 가이샤 데이터 인증 처리 시스템
JP2001209583A (ja) 2000-01-26 2001-08-03 Sony Corp データ記録再生器およびセーブデータ処理方法、並びにプログラム提供媒体
EP1252738A2 (en) 2000-01-31 2002-10-30 VDG Inc. Block encryption method and schemes for data confidentiality and integrity protection
ES2220284T3 (es) 2000-03-30 2004-12-16 Siemens Aktiengesellschaft Sistema de navegacion para automovil con un medio de memoria protegido.
JP3734408B2 (ja) * 2000-07-03 2006-01-11 シャープ株式会社 半導体記憶装置
IL137296A (en) 2000-07-13 2009-09-01 Nds Ltd Configurable hardware system
TW513883B (en) 2000-08-03 2002-12-11 Telepaq Technology Inc A secure transaction mechanism system and method integrating wireless communication and wired communication
JP4552294B2 (ja) 2000-08-31 2010-09-29 ソニー株式会社 コンテンツ配信システム、コンテンツ配信方法、および情報処理装置、並びにプログラム提供媒体
US7272720B2 (en) 2000-09-27 2007-09-18 Fujitsu Limited Date-and-time management device and signature generation apparatus with date-and-time management function
US7088822B2 (en) 2001-02-13 2006-08-08 Sony Corporation Information playback device, information recording device, information playback method, information recording method, and information recording medium and program storage medium used therewith
US7047405B2 (en) 2001-04-05 2006-05-16 Qualcomm, Inc. Method and apparatus for providing secure processing and data storage for a wireless communication device
US20020138435A1 (en) 2001-03-26 2002-09-26 Williams L. Lloyd Method and system for content delivery control using a parallel network
US20030037237A1 (en) 2001-04-09 2003-02-20 Jean-Paul Abgrall Systems and methods for computer device authentication
DE10224473A1 (de) 2001-06-18 2003-12-24 Hans-Joachim Mueschenborn Symmetrische und asymmetrische Verschlüsselungsverfahren mit beliebig wählbaren Einmalschlüsseln
JP3846230B2 (ja) 2001-06-18 2006-11-15 日本ビクター株式会社 コンテンツ情報認証再生装置
US7203966B2 (en) 2001-06-27 2007-04-10 Microsoft Corporation Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices
HUP0401720A2 (hu) 2001-09-27 2005-07-28 Matsushita Electric Industrial Co., Ltd. Kódoló, dekódoló, és titkos kulcsot képző eszközé és eljárás, valamint eszközkészlet szerzői jog védelmére és távközlési eszköz titkosított összeköttetés létesítésére
JP4248208B2 (ja) 2001-09-27 2009-04-02 パナソニック株式会社 暗号化装置、復号化装置、秘密鍵生成装置、著作権保護システムおよび暗号通信装置
US20030084298A1 (en) 2001-10-25 2003-05-01 Messerges Thomas S. Method for efficient hashing of digital content
US7159240B2 (en) 2001-11-16 2007-01-02 Microsoft Corporation Operating system upgrades in a trusted operating system environment
US7328345B2 (en) 2002-01-29 2008-02-05 Widevine Technologies, Inc. Method and system for end to end securing of content for video on demand
US7003702B2 (en) 2002-03-18 2006-02-21 Emc Corporation End-to-end checksumming for read operations
US8438392B2 (en) 2002-06-20 2013-05-07 Krimmeni Technologies, Inc. Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol
US7203844B1 (en) 2002-06-20 2007-04-10 Oxford William V Method and system for a recursive security protocol for digital copyright control
US20040003248A1 (en) 2002-06-26 2004-01-01 Microsoft Corporation Protection of web pages using digital signatures
CN1708942B (zh) 2002-10-31 2010-11-03 艾利森电话股份有限公司 设备特定安全性数据的安全实现及利用
JP3880933B2 (ja) * 2003-01-21 2007-02-14 株式会社東芝 耐タンパマイクロプロセッサ及びキャッシュメモリ搭載プロセッサによるデータアクセス制御方法
US7380059B2 (en) 2003-05-16 2008-05-27 Pillar Data Systems, Inc. Methods and systems of cache memory management and snapshot operations
US7647507B1 (en) 2003-07-08 2010-01-12 Marvell International Ltd. Secure digital content distribution system and secure hard drive
US7366302B2 (en) 2003-08-25 2008-04-29 Sony Corporation Apparatus and method for an iterative cryptographic block
US20050172132A1 (en) 2004-01-30 2005-08-04 Chen Sherman (. Secure key authentication and ladder system
WO2005088893A1 (en) 2004-02-13 2005-09-22 Psycrypt, Inc. Method and apparatus for cryptographically processing data
US20060090073A1 (en) * 2004-04-27 2006-04-27 Shira Steinberg System and method of using human friendly representations of mathematical values and activity analysis to confirm authenticity
JP2005346182A (ja) 2004-05-31 2005-12-15 Fujitsu Ltd 情報処理装置、耐タンパ方法、耐タンパプログラム
EP1805638A4 (en) 2004-10-12 2010-04-07 Korea Advanced Inst Sci & Tech CONTENT PROCESSING SYSTEM, METHOD AND METHOD FOR CONTINUOUS CONFIRMATION THROUGH A NETWORK USING THE ENCRYPTION METHOD
US7480385B2 (en) 2004-11-05 2009-01-20 Cable Television Laboratories, Inc. Hierarchical encryption key system for securing digital media
JP2006222496A (ja) 2005-02-08 2006-08-24 Matsushita Electric Ind Co Ltd デジタル映像受信装置およびデジタル映像受信システム
US7639819B2 (en) 2005-06-16 2009-12-29 Oracle International Corporation Method and apparatus for using an external security device to secure data in a database
GB2453287B (en) * 2006-07-14 2010-05-19 Kinamik Data Integrity S L Method and system of generating immutable audit logs
JP2010520703A (ja) * 2007-03-06 2010-06-10 ウィリアム ブイ． オックスフォード， デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
JP5211716B2 (ja) 2008-01-29 2013-06-12 富士通株式会社 ファイルアクセス制御方法、ファイルアクセス制御プログラム、およびファイルアクセス制御装置
WO2010010430A2 (en) * 2008-07-25 2010-01-28 Lee Kok-Wah Methods and systems to create big memorizable secrets and their applications in information engineering
US8321385B2 (en) * 2010-03-12 2012-11-27 Lsi Corporation Hash processing in a network communications processor architecture
US8244988B2 (en) * 2009-04-30 2012-08-14 International Business Machines Corporation Predictive ownership control of shared memory computing system data
US9298894B2 (en) * 2009-06-26 2016-03-29 International Business Machines Corporation Cache structure for a computer system providing support for secure objects
US8972746B2 (en) * 2010-12-17 2015-03-03 Intel Corporation Technique for supporting multiple secure enclaves
US9448950B2 (en) * 2013-12-24 2016-09-20 Intel Corporation Using authenticated manifests to enable external certification of multi-processor platforms

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190092948A (ko) * 2018-01-31 2019-08-08 에스케이하이닉스 주식회사 저장 장치 및 그 동작 방법
US11580033B2 (en) 2018-01-31 2023-02-14 SK Hynix Inc. Storage device and method of operating the same

Also Published As

Publication number Publication date
WO2013142517A1 (en) 2013-09-26
US9575906B2 (en) 2017-02-21
JP2015511050A (ja) 2015-04-13
US20130254494A1 (en) 2013-09-26
US20170192909A1 (en) 2017-07-06
EP2828759A1 (en) 2015-01-28
EP2828759A4 (en) 2015-09-30

Similar Documents

Publication Publication Date Title
KR20150011802A (ko) 프로세스 작업 세트 격리를 위한 방법 및 시스템
US9710617B2 (en) Method and system for a recursive security protocol for digital copyright control
US9705677B2 (en) Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol
JP5636371B2 (ja) 汎用コンピューティングデバイスにおけるコード実行制御および再帰的セキュリティプロトコルでのコード実行制御のための方法およびシステム
Dwoskin et al. Hardware-rooted trust for secure key management and transient trust
JP4689945B2 (ja) リソースアクセス方法
JP4689946B2 (ja) 安全なデータを使用して情報処理を実行するシステム
US20040093505A1 (en) Open generic tamper resistant CPU and application system thereof
US20050060568A1 (en) Controlling access to data
US8769675B2 (en) Clock roll forward detection
US20170063544A1 (en) System and method for sharing data securely
EP2119092A2 (en) Method and system for a recursive security protocol for digital copyright control
Mohammad et al. Required policies and properties of the security engine of an SoC
JP2015135703A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
Payne A cryptographic access control architecture secure against privileged attackers
JP2013084294A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
JP2014017871A (ja) デジタル著作権制御用再帰的セキュリティプロトコルのための方法およびシステム
JP2006279179A (ja) データ２重化を活用した暗号処理方式
McGregor Jr Architectural techniques for enabling secure cryptographic processing
Fleming Data Tethers: Preventing Information Leakage by Enforcing Environmental Data Access Policies

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination