KR20240016243A - 온 다이 암호화 및 원격 증명을 통한 디지털 콘텐츠관리 - Google Patents

온 다이 암호화 및 원격 증명을 통한 디지털 콘텐츠관리 Download PDF

Info

Publication number
KR20240016243A
KR20240016243A KR1020237021856A KR20237021856A KR20240016243A KR 20240016243 A KR20240016243 A KR 20240016243A KR 1020237021856 A KR1020237021856 A KR 1020237021856A KR 20237021856 A KR20237021856 A KR 20237021856A KR 20240016243 A KR20240016243 A KR 20240016243A
Authority
KR
South Korea
Prior art keywords
platform
enclave
key
uefi
binary file
Prior art date
Application number
KR1020237021856A
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 KR20240016243A publication Critical patent/KR20240016243A/ko

Links

Images

Classifications

    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/321—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 involving a third party or a trusted authority
    • 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/3271—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 challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4627—Rights management associated to the content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

플랫폼 내의 프로세서 및 실행될 때 동작들을 수행하도록 프로세서를 구성하는 명령어들을 포함하는 메모리 디바이스를 포함하는 디지털 저작권 관리를 위한 시스템. 동작들은 운영 체제를 개시하기 전에 디지털 미디어가 플랫폼에 로컬로 설치되어 있는지 여부를 결정하는 동작, 및 디지털 미디어가 설치되어 있지 않다고 결정하는 것에 응답하여 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭하는 동작을 포함할 수 있다. 동작들은 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하는 동작 및 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 바이너리 파일의 봉인을 수행하고 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키를 생성하는 동작을 또한 포함할 수 있다. 동작들은 봉인된 바이너리 파일을 로컬 저장소에 설치하는 동작을 또한 포함할 수 있다.

Description

온 다이 암호화 및 원격 증명을 통한 디지털 콘텐츠 관리
본 개시내용은 일반적으로 온 다이 암호화(on-die cryptography) 및 원격 증명(remote attestation)을 통한 디지털 콘텐츠 관리를 위한 컴퓨터화된 시스템들 및 방법들에 관한 것이다. 본 개시내용의 실시예들은 UEFI(Unified Extensible Firmware Interface) 애플리케이션들 및 플랫폼의 하드웨어에 고유한 암호화 엔트로피(cryptographic entropy)를 사용하는 펌웨어 기반 디지털 저작권 관리를 위한 시스템들 및 방법들에 관한 것이다.
디지털 미디어는 쉽게 복제되고 배포될 수 있다. 예를 들어, 디지털 파일들은 열화 없이 무제한으로 복사될 수 있으며, 디지털 사본들은 온라인 파일 공유 도구들을 통해 광범위하고 쉽고 빠르게 배포될 수 있다. 빈번히 저작권 침해되며, 부적절하게 사용되고/되거나 소유자의 허가 없이 조작되는 디지털 자료 또는 콘텐츠의 배포(distribution) 및 재현(reproduction)에 대해 보호하는 것은 어렵다. 디지털 미디어의 본질적인 재현성(reproducibility)은 자신의 제품을 소비자들이 이용할 수 있게 하면서 자신의 제품을 주의 깊게 보호하는 것의 균형을 유지해야만 하는 디지털 콘텐츠 제작자들에게 어려운 상황을 만든다.
디지털 미디어의 배포 및 재현을 제어하기 위해 여러 검증 기술들이 개발되었다. 예를 들어, 콘텐츠 제작자들은 디지털 콘텐츠의 설치 동안 일련 번호 또는 코드를 입력할 것을 요구하는 제품 키로 자신의 제작물의 배포에 대해 보호해 왔다. 다른 검증 기술들은 동시에 실행 중인 사본들의 수를 제한(예를 들면, 제한된 설치 활성화들)하고/하거나 사용자들의 주기적인 인증(예를 들면, 지속적인 온라인 인증)을 요구하는 데 사용되는 인증 서버들에 기초한다. 그러나, 다른 검증 기술들은, 예를 들어, 변조 방지 방법들, 워터마크들, 및/또는 잠금 목록(lockout list)들을 사용하여, 디지털 콘텐츠의 암호화(encryption)를 이용하거나 디지털 콘텐츠를 제한한다.
그렇지만, 디지털 콘텐츠를 관리하고 보호하기 위한 이러한 기술들은 공격들에 취약하고/하거나 사용자들과 콘텐츠 제작자들 양쪽 모두에게 불편을 주게 된다. 예를 들어, 제품 키가 게시되고/되거나 유출될 때, 제품 키는 침해된다. 게다가, 인증 서버들은 제한들을 제거하고/하거나 (예를 들면, DDOS 공격들을 통해) 합법적인 사용자들을 잠금하기 위해 공격을 받는다. 암호화 또는 지역 잠금(regional lock-out)과 같은, 다른 기술들은 콘텐츠 제공자들과 사용자들에게 큰 부담을 주어, 사용성 또는 사용자 친화성을 저해한다. 예를 들어, 일부 디지털 미디어 제한들은 디지털 미디어를 단일 디바이스들에 잠금하여, 이식성 또는 플랫폼 독립성을 방지한다. 더욱이, 일부 콘텐츠 제공자들은 인증 또는 TPM(trusted platform module)들에 사용되는 서버들을 생성, 유지 관리, 보호, 및 보증하는 것이 너무 번거롭다고 생각한다. 추가적으로, 운영 체제가 해킹되거나 변조될 때 인증 서버가 속을 수 있다.
개시된 시스템들 및 방법들은 위에서 제시된 문제들 및/또는 해당 분야에서의 다른 알려진 문제들 중 하나 이상을 해결한다.
본 개시내용의 일 양상은 플랫폼 내의 적어도 하나의 프로세서 및 실행될 때 동작들을 수행하도록 상기 적어도 하나의 프로세서를 구성하는 명령어들을 포함하는 적어도 하나의 메모리 디바이스를 포함하는 디지털 저작권 관리를 위한 시스템에 관한 것이다. 상기 동작들은, 상기 적어도 하나의 프로세서의 운영 체제를 개시하기 전에, 디지털 미디어가 플랫폼에 로컬로 설치되어 있는지 여부를 결정하는 동작; 상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여, 증명 엔클레이브(attestation enclave)에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭(launch)하는 동작; 및 상기 서버로부터 상기 암호화된 매체를 통해, 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하는 동작을 포함할 수 있다. 상기 동작들은 상기 제1 UEFI 애플리케이션의 봉인 엔클레이브(sealing enclave)를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키(상기 제2 키는 상기 플랫폼에 고유함)를 생성하는 동작 및 상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하는 동작을 또한 포함할 수 있다.
본 개시내용의 다른 양상은 디지털 저작권 관리를 위한 방법에 관한 것이다. 상기 방법은 플랫폼에서 프로세서의 운영 체제를 개시하기 전에, 디지털 미디어가 상기 플랫폼에 로컬로 설치되어 있는지 여부를 결정하는 단계, 및 (상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여) 증명 엔클레이브에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭하는 단계를 포함할 수 있다. 상기 방법은 (상기 서버로부터 상기 암호화된 매체를 통해) 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하는 단계를 또한 포함할 수 있다. 상기 방법은 상기 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키(상기 제2 키는 상기 플랫폼에 고유함)를 생성하는 단계, 및 상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하는 단계를 또한 포함할 수 있다.
본 개시내용의 또 다른 양상은 하나 이상의 프로세서 및 명령어들을 저장하는 하나 이상의 메모리 디바이스를 포함하는 장치에 관한 것이며, 상기 명령어들은 상기 장치의 운영 체제를 개시하기 전에, 디지털 미디어가 상기 장치에 로컬로 설치되어 있는지 여부를 결정하고; 상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여, 증명 엔클레이브에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭하도록 상기 하나 이상의 프로세서를 구성한다. 상기 명령어들은 또한 (상기 서버로부터 상기 암호화된 매체를 통해) 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하도록 상기 장치를 구성할 수 있다. 게다가, 상기 명령어들은 또한 상기 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키(상기 제2 키는 상기 플랫폼에 고유함)를 생성하고 상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하도록 상기 프로세서들을 구성할 수 있다.
도 1은 개시된 실시예들에 따른, 예시적인 플랫폼의 블록 다이어그램이다.
도 2은 개시된 실시예들에 따른, 예시적인 프로세서의 블록 다이어그램이다.
도 3은 개시된 실시예들에 따른, 보호된 디지털 미디어(secured digital media)의 예시적인 UEFI 기반 론칭을 예시하는 블록 다이어그램이다.
도 4는 개시된 실시예들에 따른, 고객 오프라인 복구 및 업데이트 설치 프로세스를 예시하는 블록 다이어그램이다.
도 5는 개시된 실시예들에 따른, 보안 하이퍼바이저(secured hypervisor)를 통한 가상 머신들에서의 디지털 저작권 관리를 위한 예시적인 프로세스의 플로차트이다.
도 6은 개시된 실시예들에 따른, 엔클레이브들을 생성하는 UEFI 애플리케이션의 블록 다이어그램이다.
도 7은 개시된 실시예들에 따른, UEFI 보호된 디지털 콘텐츠(UEFI-secured digital content)를 론칭하기 위한 프로세스의 플로차트이다.
도 8은 개시된 실시예들에 따른, 원격 증명을 통한 디지털 콘텐츠의 UEFI 기반 프로비저닝을 위한 프로세스의 플로차트이다.
도 9는 개시된 실시예들에 따른, 프로세서와 증명 서버 사이의 통신을 위한 프로세스의 타이밍 다이어그램이다.
이하의 상세한 설명은 첨부 도면들을 참조한다. 가능한 한, 도면들 및 이하의 설명에서 동일하거나 유사한 부분들을 지칭하기 위해 동일한 참조 번호들이 사용된다. 여러 예시적인 실시예들이 본 명세서에서 설명되지만, 수정들, 적응들 및 다른 구현들이 가능하다. 예를 들어, 도면들에 예시된 컴포넌트들 및 단계들에 대해 대체들, 추가들 또는 수정들이 이루어질 수 있으며, 개시된 방법들에 대해 단계들을 대체, 재정렬, 제거 또는 추가하는 것에 의해 본 명세서에서 설명되는 예시적인 방법들이 수정될 수 있다. 이하의 상세한 설명은 개시된 실시예들 및 예들로 제한되지 않는다.
본 개시내용의 일부 실시예들은 UEFI 애플리케이션들이 디지털 미디어 설치 및 실행을 제어하는 데 사용될 수 있는 UEFI(Unified Extensible Firmware Interface)-시행 디지털 저작권 관리(DRM) 시스템에 관한 것일 수 있다. 그러한 실시예들에서, 개시된 시스템들 및 방법들은 (예를 들어, 원격 증명을 사용한) 인증을 위해 그리고 원격 증명 프로세스들을 통해 플랫폼 특정 암호화 키들을 생성하기 위해 플랫폼의 고유 암호화 엔트로피를 이용할 수 있다. 개시된 시스템들 및 방법들은 향상된 DRM 보안 및 제어를 위해 하드웨어와 소프트웨어 검증 둘 모두를 통합할 수 있다. 개시된 시스템들 및 방법들의 그러한 실시예들은 디지털 콘텐츠의 인가되지 않은 수정 또는 실행을 방지하는 것에 의해 컴퓨터 보안을 향상시킬 수 있다.
더욱이, 개시된 시스템들 및 방법들은, 예를 들어, 임의의 운영 체제가 개시되기 전과 같이, 조기에 보안 정책들을 시행하는 것에 의해 DRM 프로세스의 보안을 향상시킬 수 있다. 인증 동작들의 보안을 향상시키고 플랫폼 특정 서명들을 변조하기 위한 잠재적인 공격 벡터들을 최소화하기 위해, 개시된 시스템들 및 방법들은 부팅 펌웨어에서(예를 들어, BIOS 또는 IIEFI 내에서) 인증 및 암호화/복호화 작업들을 수행할 수 있다. 예를 들어, 개시된 시스템들 및 방법들의 일부 실시예들은 플랫폼의 운영 체제를 개시 또는 시작할 필요 없이 원격 증명, 인증 및 복호화 작업들을 수행하기 위해 UEFI 애플리케이션들을 이용할 수 있다. 그러한 실시예들에서, 개시된 시스템들 및 방법들은 프로비저닝 및/또는 로더 작업들을 수행하기 위해 일련의 UEFI 엔클레이브들 또는 애플리케이션들을 생성 및 사용할 수 있다. UEFI 엔클레이브들은 개시된 시스템들 및 방법들이 인증에 온 다이 암호화 고유 자료를 통합할 수 있게 할 수 있다. UEFI 엔클레이브들은 또한 온 다이 암호화 자료와 함께 UEFI(또는 BIOS) 내로부터 원격 웹 서버로의 보안 통신을 사용하여 원격 증명 작업들을 수행하기 위해 개시된 시스템들 및 방법들을 용이하게 할 수 있다. 그러한 실시예들에서, UEFI 애플리케이션들을 실행하는 플랫폼은 UEFI 동작들에 기초하여 프로비저닝되고 검증될 수 있다.
더욱이, 개시된 시스템들 및 방법들은 UEFI 파티션 내에 애플리케이션 바이너리들을 봉인 및 저장하는 프로세스들을 설명한다. 이 배열은 플랫폼 부팅 동안 페이로드 바이너리들의 검증을 용이하게 할 수 있다. 예를 들어, 부트 엔클레이브는 엔클레이브 내로부터 검색되는 플랫폼 고유 키들로 페이로드 바이너리들을 검증할 수 있다. 그러한 프로세스들은 플랫폼과 플랫폼에게 전송되는 바이너리들 양쪽 모두의 검증을 가능하게 하는 것에 의해 컴퓨터 보안 및 안전의 동작을 향상시킬 수 있다. 게다가, 개시된 시스템들 및 방법들은 신뢰할 수 있는 플랫폼들에서 디지털 콘텐츠를 안전하게 실행할 수 있다. 예를 들어, 일부 실시예들에서, 일단 페이로드가 검증되면, 페이로드는 플랫폼 상에서 안전한 런타임 환경(secure runtime environment, SRE)으로 완전히 부팅될 수 있다. 이 프로세스는 운영 체제 기반 공격들에 취약할 수 있는 초기 원격 증명(early remote attestation)을 위한 메커니즘을 배포하는 것에 의해 컴퓨터 보안 및 DRM 분야를 향상시킬 수 있다.
개시된 시스템들 및 방법들은 또한 가상 머신(VM)을 통과할 수 있는 고유 암호화 키들로 하이퍼바이저 커널들을 구축하는 것에 의해 가상 머신 환경에서 DRM 정책들을 시행할 수 있다. 예를 들어, 개시된 시스템들 및 방법들의 일부 실시예들은 가상 모드 특정 레지스터(mode specific register, MSR)에 저장되는 고유 키들을 생성하기 위해 UEFI 엔클레이브들 내의 온 다이 암호화 및/또는 고유 암호화 자료를 이용하는 동작들을 포함할 수 있다. 이러한 고유 키들은 DRM 정책들을 VM들로 확장하는 동시에 가상 MSR 키 저장소를 사용하여 각각의 VM에 대한 고유 키들을 생성하는 데 사용될 수 있다.
게다가, 개시된 시스템들 및 방법들은 플랫폼 서명들 및 원격 증명에 기초한 액세스 제어로 하이퍼바이저들의 안전한 배포를 용이하게 할 수 있다. 개시된 시스템들 및 방법들은, 암호화, 복호화, 키 유도 함수들(Key Derivation Functions, KDF), 엔트로피, 및 소프트웨어 가드 확장들(Software Guard Extensions, SGX)과 같은, 암호화 기술들의 조합을 사용할 수 있다. 다양한 암호화 기술들을 고유 하드웨어 암호화 자료와 결합하는 것에 의해, 개시된 시스템들 및 방법들은 특정 하드웨어에 바인딩된 소프트웨어 바이너리를 구축할 수 있다. 추가적으로, 개시된 시스템들 및 방법들은 특정 소프트웨어 설치들로 플랫폼들을 프로비저닝할 수 있다.
더욱이, 일부 실시예들에서, 개시된 시스템들 및 방법들은, 업데이트들(또는 다른 새로운 소프트웨어)을 원격 증명 후에 검증된 플랫폼들에게만 전송하는 것에 의해, 업데이트들 또는 일반적으로 새로운 소프트웨어의 배포를 보호할 수 있다. 예를 들어, 개시된 시스템들 및 방법들은 UEFI BIOS 및 온 다이 암호화 자료를 통해 업데이트들 또는 새로운 소프트웨어를 배포할 때 서버 및 로컬 암호화를 사용할 수 있다. 그러한 실시예들은 특정 검증된 플랫폼들에 소프트웨어를 프로비저닝하는 안전한 방법을 제공할 수 있다. 개시된 시스템들 및 방법들은 사이버 보안과 안전 둘 모두를 향상시키기 위해 플랫폼과 배포되는 소프트웨어 둘 모두를 검증할 수 있다. 개시된 시스템들 및 방법들은 원격 증명 및 온 다이 암호화를 사용하여 검증된 플랫폼들에만 검증된 콘텐츠를 배포하는 것을 용이하게 할 수 있다. 추가적으로, 암호화 방법들은 프로비저닝 웹 서버들과 로컬 플랫폼들 사이의 통신을 보호할 수 있으며, 시스템이 안전하고 콘텐츠가 변조되지 않도록 보장하기 위해 특정 복호화 키들을 이용할 수 있다. 개시된 시스템들 및 방법들은 다른 프로비저닝 방법들의 취약성들을 해결하고, 보안을 향상시키며, DRM 관리의 향상된 제어를 제공할 수 있다.
이제 개시된 실시예들이 언급될 것이며, 그 예들은 첨부 도면들에 예시되어 있다.
도 1은 개시된 실시예들에 따른, 예시적인 플랫폼(100)의 블록 다이어그램이다. 도 1에 도시된 바와 같이, 플랫폼(100)은 마더보드 및 주변기기들을 포함할 수 있다.
마더보드는 프로세서(102)를 포함할 수 있다. 일부 실시예들에서, 프로세서(102)는 임의의 적합한 프로세싱 디바이스 및/또는 상업적으로 이용 가능한 프로세서를 포함할 수 있다. 다른 실시예들에서, 프로세서(102)는 함께 결합되고 본 개시내용에 따른 기능들을 수행하도록 구성된 복수의 디바이스들일 수 있다. 예를 들어, 프로세서(102)는 복수의 코프로세서들 또는 그래픽 프로세싱 유닛들을 포함할 수 있으며, 각각은, 부동 소수점 산술, 그래픽, 신호 프로세싱, 문자열 프로세싱, 암호화, 및/또는 I/O 인터페이싱과 같은, 특정 동작들을 실행하도록 구성될 수 있다. 프로세서(102)는 도 2와 관련하여 추가로 설명된다.
마더보드는 코프로세서(104)를 또한 포함할 수 있다. 코프로세서(104)는 프로세서(102)의 기능들을 보완할 수 있다. 일부 실시예들에서, 코프로세서(104)는 부동 소수점 산술, 그래픽, 신호 프로세싱, 문자열 프로세싱, 암호화, 및/또는 주변 디바이스들과의 I/O 인터페이싱의 동작들을 수행할 수 있다. 코프로세서(104)는 프로세서(102)로부터 프로세서 집약적 작업들을 오프로딩할 수 있으며, 이는 플랫폼(100) 성능을 가속시킬 수 있다. 일부 실시예들에서, 코프로세서(104)는 맞춤형 동작들을 가질 수 있다. 예를 들어, 코프로세서(104)는 SRE를 초기화하고/하거나 격리된 도메인들 사이에 방화벽들을 시행하기 위해 맞춤형 동작들을 실행할 수 있다.
마더보드는 클록 생성기(106) 및 DRAM(dynamic random-access memory)(108)을 또한 포함할 수 있다. 일부 실시예들에서, 클록 생성기(106)는 타이밍 신호를 생성하도록 구성된 전자 발진기를 포함할 수 있다. 클록 생성기(106)는 대칭파 및/또는 더 복잡한 배열들을 생성할 수 있다. 클록 생성기(106)는 공진 회로 및 증폭기를 또한 포함할 수 있다. 일부 실시예들에서, 클록 생성기(106)는 하나 이상의 주파수 분주기, 클록 체배기 섹션 및 프로그래밍 가능 클록을 포함할 수 있다. 클록 생성기(106)는 UEFI 또는 BIOS 부팅 동안 선택된 값으로 구성될 수 있다.
DRAM(108)은 프로세서(102) 동작들에 사용되는 솔리드 스테이트 메모리를 포함할 수 있다. 본 기술 분야의 통상의 기술자는 DRAM(108)이 다수의 유형들의 메모리들을 포함할 수 있고, 랜덤 액세스 메모리로 제한되지 않을 수 있다는 것을 이해할 것이다. 일부 실시예들에서, 예를 들어, DRAM(108)은 판독 전용 메모리를 포함할 수 있다.
마더보드는 UEFI/BIOS(110)를 또한 포함될 수 있다. UEFI/BIOS(110)는 부팅 프로세스(파워 온 기동(power-on startup)) 동안 하드웨어 초기화를 수행하고 운영 체제들 및 프로그램들에 대한 런타임 서비스들을 제공하는 데 사용되는 비휘발성 펌웨어를 포함할 수 있다. 일부 실시예들에서, UEFI/BIOS(110)는, 도 7 내지 도 9와 관련하여 추가로 설명되는 바와 같이, 하나 이상의 엔클레이브를 생성하고 증명 서비스들과 통신하기 위한 명령어들을 포함할 수 있다. UEFI/BIOS(110)는 보호된 SRE를 론칭할 때 보안 핸드오프들을 위한 암호화 키잉(cryptographic keying)을 또한 포함할 수 있다.
일부 실시예들에서, UEFI/BIOS(110) 펌웨어는 OEM(original equipment manufacturer)에 의해 컴퓨터 상에 미리 설치될 수 있고, 컴퓨터가 전원이 켜질 때 실행되는 첫 번째 소프트웨어이도록 구성될 수 있다. 일부 실시예들에서, UEFI/BIOS(110)는 시스템 하드웨어 컴포넌트들을 초기화하고 테스트할 수 있다. UEFI/BIOS(110)는 또한 대용량 메모리 디바이스로부터 부트 로더를 로딩할 수 있으며, 이는 이어서 격리된 도메인들을 생성하는 가상화 계층으로 하이퍼바이저를 초기화할 수 있다. 게다가, UEFI/BIOS(110)는 SRE에서 호스팅되는 가상 머신들을 프로세서(102) 내의 격리된 하드웨어 자원들과 연결하기 위한 암호화 키들 또는 명령어들을 포함할 수 있다.
마더보드는 전원 리셋(power reset)(164)을 또한 포함할 수 있으며, 이는 마더보드의 컴포넌트들을 재초기화하고/하거나 플랫폼(100)에서 현재 동작들을 종료하도록 구성될 수 있다. 일부 실시예들에서, 전원 리셋(164)은 컴포넌트들을 초기화할 수 있고, UEFI/BIOS(110)는 플랫폼(100)을 재시작하고 도 3과 관련하여 논의된 DRM 정책들을 배포할 수 있다.
마더보드는 주변기기들과 통신하기 위한 하나 이상의 브리지 컴포넌트를 또한 포함할 수 있다. 일부 실시예들에서, 마더보드는 USB(Universal Serial Bus) 브리지(114), PCI(Peripheral Component Interconnect) 버스 브리지(112), SCSI(Small Computer System Interface) 버스 브리지(113), 및 EISA(Extended Industry Standard Architecture) 버스 브리지(122)를 포함할 수 있다.
마더보드는 비디오 RAM(126) 및 비디오 프로세서(124)를 포함할 수 있다. 비디오 RAM(126)은 프로세서(102)와 디스플레이 사이의 버퍼를 포함할 수 있다. 일부 실시예들에서, 비디오 RAM(126)은 프레임 버퍼로 구현될 수 있으며, 따라서 이미지들이 디스플레이로 송신되어야 할 때, 이미지들은 한 형태의 메인(비-비디오) RAM으로부터 데이터로서 프로세서(102)에 의해 먼저 판독되고 이어서 디스플레이할 준비를 위해 비디오 RAM(126)에 기입될 수 있다. 비디오 프로세서(124)는 디스플레이 디바이스에 대한 출력 이미지들의 피드를 생성할 수 있는 확장 카드로 구현될 수 있다. 일부 실시예들에서, 비디오 프로세서(124)는 전용 그래픽 카드들 및/또는 그래픽 프로세싱 유닛(GPU)을 포함할 수 있다.
추가적으로, 마더보드는 네트워크 버스(120)를 포함할 수 있다. 네트워크 버스(120)는 마더보드, 플랫폼(100), 및 마더보드와 통신하거나 결합될 수 있는 다른 컴포넌트들 사이의 통신을 제공하도록 구성된 임의의 유형의 네트워크에 대한 연결을 제공할 수 있다. 일부 실시예들에서, 네트워크 버스(120)는, 인터넷, TLS 통신, 로컬 영역 네트워크, NFC(near field communication), 광학 코드 스캐너, 또는 플랫폼(100)에서의 정보의 송수신을 용이하게 하는 다른 적합한 연결(들)과 같은, 통신을 제공하며, 정보를 교환하고/하거나, 정보 교환을 용이하게 할 수 있는 임의의 유형의 네트워크와의 연결을 위한 포트일 수 있다.
도 1에 도시된 바와 같이, 주변기기들은 모니터(150), 키보드(152), 및 마우스(153)를 포함할 수 있다. 주변기기들은 하드 드라이브(154), 외부 저장소(160), 모뎀(158), 및 PCI 슬롯들(162)을 또한 포함할 수 있다. 본 개시내용의 실시예들은 또한 플랫폼(100)이 임의의 다른 적합한 주변 디바이스들을 포함할 수 있음을 고려한다.
본 기술 분야의 통상의 기술자는 플랫폼(100)의 기능 빌딩 블록들의 구성 및 경계들이 본 명세서에서 설명의 편의를 위해 예시되었음을 이해할 것이다. 본 개시내용의 실시예들은, 그의 지정된 기능들 및 관계들이 적절하게 수행되는 한, 대안적인 경계들이 구현될 수 있음을 고려한다. 대안들(본 명세서에서 설명된 것들의 등가물들, 확장들, 변형들, 파생물들 등을 포함함)은 본 명세서에 포함된 교시내용에 기초하여 본 기술 분야의 통상의 기술자에게 명백할 것이다. 그러한 대안들은 개시된 실시예들의 범위 및 사상 내에 속한다.
도 2는 개시된 실시예들에 따른, 예시적인 프로세서(102)의 블록 다이어그램을 도시한다. 프로세서(102)는 하나 이상의 코어(202), 하나 이상의 icache(204), 하나 이상의 dcache(206) 및 하나 이상의 L2 캐시(208)를 포함할 수 있다. 게다가, 프로세서(102)는 하나 이상의 메모리 제어기(210) 및 플랫폼 캐시(212)를 포함할 수 있다.
코어들(202)은 프로세서(102)의 효율을 향상시키기 위해 병렬 작업들을 수행하도록 구성될 수 있다. 일부 실시예들에서, 코어들(202)은 물리적으로 별개의 코어들일 수 있다. 다른 실시예들에서, 코어들(202)은 프로세싱 유닛들을 가상 코어들로 분할할 수 있는 멀티스레딩 또는 하이퍼스레딩으로 가상적으로 정의될 수 있다.
도 2에 도시된 바와 같이, 제1 레벨의 캐시 메모리는 icache(204) 및 dcache(206)를 갖는 프로세서(102)에서 분할될 수 있다. icache(204)는 코어들(202)에 대한 개별 명령어들을 구분하기 위한 프리코드(pre-code)를 포함할 수 있는 명령어 캐시를 포함할 수 있다. 일부 실시예들에서, icache(204)는 디코드 속도를 향상시키기 위한 명령어들을 포함할 수 있고, dcache(206)는 데이터 캐시일 수 있다. icache(204)와 dcache(206) 사이의 이러한 분할에 따라, 2개의 작은 캐시가 존재할 수 있는데, 하나는 명령어 코드를 독점적으로 캐싱하고 다른 하나는 데이터를 독점적으로 캐싱한다. 소프트웨어는 코드를 데이터(전역 및 정적 변수들, 상수들 등)와 분리할 수 있다. 이러한 배열은 데이터 프로세싱을 용이하게 하기 위해 실제 명령어 코드, 하드 코딩된 데이터, 및 동적으로 할당된 데이터 사이의 공간적 분리를 생성할 수 있다.
L2 캐시(208)는 icache(204) 또는 dcache(206)보다 증가된 용량을 갖는 레벨 2 캐시를 포함할 수 있다. L2 캐시(208)는 프로세스 및 메모리 성능 격차에 대한 브리지로서 역할할 수 있고, 어떠한 중단이나 대기 상태도 없이 저장된 정보를 프로세서(102)에 제공할 수 있다. L2 캐시(208)는 또한 데이터의 액세스 시간을 감소시키도록 구성될 수 있다. 예를 들어, L2 캐시(208)는 데이터가 이전에 이미 액세스되었을 수 있고, 따라서 데이터가 또다시 로딩될 필요가 없을 수 있는 이벤트들에서 데이터의 액세스 시간을 감소시킬 수 있다. 일부 실시예들에서, L2 캐시(208)는 버퍼링 동작들을 수행할 수 있고, 메모리에 데이터를 요청할 수 있어, RAM에 비해 더 가까운 대기 영역으로서 역할할 수 있다.
메모리 제어기들(210)은 프로세서(102)의 메모리들로 그리고 프로세서(102)의 메모리들로부터, 코어들(202)과 같은, 프로세싱 유닛들로 가는 데이터의 흐름을 관리할 수 있는 디지털 회로들을 포함할 수 있다. 일부 실시예들에서, 프로세서(102)는 각각의 코어(202)와 연관된 고유한 캐시 또는 캐시 그룹을 갖도록 구성될 수 있다. 추가적으로 및/또는 대안적으로, 하드웨어 컴포넌트들은 상이한 코어들 사이에 공유될 수 있다. 유출 공격들을 방지하기 위해, 가상화 계층은 코어들(202) 중 하나 또는 선택된 그룹만을 위한 메모리 섹션들을 격리 및 분리하도록 메모리 제어기들(210)를 구성할 수 있다. 메모리 제어기들(210)은 통합 메모리 제어기(integrated memory controller, IMC) 및/또는 메모리 칩 제어기(memory chip controller, MCC)로서 구현될 수 있다.
일부 실시예들에서, 프로세서(102)는 상이한 코어들(202) 사이의 정보의 배포를 용이하게 할 수 있는 상위 레벨의 캐시를 제공하기 위해 플랫폼/L3 캐시(212)를 포함할 수 있다. 일부 실시예들에서, 플랫폼/L3 캐시(212)는 디스크립터(descriptor)들, 키들, 콘텍스트들, 및 네트워크 패킷 프로세싱에 필요한 다른 데이터를 저장할 수 있는 상위 레벨 캐시를 제공할 수 있다. 그러한 구성들에 의해, 프로세서(102)는 데이터 평면 트래픽을 외부 메모리들 또는 주변기기들 외부에 유지할 수 있다. UEFI/BIOS(110)로부터 구현되는 SRE의 가상화 계층은 특정 공격들에 대한 취약성을 완화시키기 위해 특정 격리된 도메인들에서 플랫폼/L3 캐시(212)의 레지스터들을 분할할 수 있다.
프로세서(102)는 프로세서(102)에서의 동작들을 관리 또는 제어할 수 있는 하나 이상의 모듈을 또한 포함할 수 있다. 일부 실시예들에서, 프로세서(102)는 검증된 UEFI 부트(214), 격리 관리자(216), 플래시 제어기(218) 및 전력 관리(220)를 포함할 수 있다.
검증된 UEFI 부트(214)는 OEM에 의해 신뢰되는 소프트웨어만을 사용하여 부트를 강제하는 모듈일 수 있다. PC가 시작될 때, 검증된 UEFI 부트(214) 펌웨어는, 예를 들어, BIOS 펌웨어 드라이버들(예를 들면, 옵션 ROM(Option ROM)들), EFI(Extensible Firmware Interface) 애플리케이션들, 및 운영 체제를 포함하여, 부트 소프트웨어의 각각의 부분의 서명을 확인할 수 있다. 서명이 유효한 경우, 프로세서(102)가 부팅될 수 있고, 펌웨어가 운영 체제에 대한 제어를 제공할 수 있다. 서명이 유효하지 않은 경우, 프로세서(102)는 경보를 생성할 수 있다. 격리 관리자(216)는 소프트웨어 애플리케이션, 테넌트들, 및/또는 엔클레이브들을 서로 격리된 특정 하드웨어 컴포넌트들와 바인딩하도록 구성될 수 있다. 일부 실시예들에서, 격리 관리자(216)는 프로세서(102) 자원들을 개별 소켓들 및 브리지 칩들에 바인딩할 수 있는 가상 신뢰 플랫폼 모듈(trusted platform module, TPM)을 생성하는 멀티 소켓 시스템을 구성할 수 있다. 격리 관리자(216)가 특정 애플리케이션들 또는 테넌트들을 위한 하드웨어 자원들을 피닝(pin)할 수 있기 때문에, 프로세서(102)를 작동시키도록 구성된 가상화 계층은 스케줄러 없이 하이퍼바이저를 구현할 수 있다.
플래시 제어기(218)는 플래시 카드를 인터페이싱하고 작동시키는 데 사용될 수 있다. 일부 실시예들에서, 플래시 제어기(218)는, 예를 들어, SD 카드들, CompactFlash 카드들, 또는 다른 유사한 매체들과 같은, 저 듀티 사이클 환경들에서 작동할 수 있다. 전력 관리(220)는 전력 관리 정책들을 시행하고/하거나 특정 요소들을 디스에이블시키기 위해 프로세서(102)의 하나 이상의 컴포넌트를 제어하도록 구성될 수 있다. 일부 실시예들에서, 전력 관리(220)는 전력 소비를 최소화하기 위해 요구 기반 스위칭(demand-based switching, DBS)을 수행하며, 성능을 향상시키기 위해 터보 모드들을 활성화시키고/시키거나, 전력 모드 관리 작업들을 실행할 수 있다. 더욱이, 그리고 도 6과 관련하여 추가로 논의되는 바와 같이, 전력 관리(220)는 잠재적인 보안 문제들의 보안 레벨들에 의해 제공되는 바와 같이 프로세서(102)의 특정 요소들을 디스에이블시킬 수 있다.
일부 실시예들에서, 프로세서(102)는, 외부 용량 모듈(222), UART(Universal Asynchronous Receiver Transmitter) 모듈(224), SPI(Serial Peripheral Interface) 모듈(226), 및 USB 모듈(228)과 같은, 추가적인 모듈들을 포함할 수 있다.
프로세서(102)는 하나 이상의 입력-출력 메모리 관리 유닛(input-output memory management units, IOMMU)을 포함한 캐시 일관성 모듈(cache coherency module, 230)을 또한 포함할 수 있다. 캐시 일관성 모듈(230)은 공유 자원들을 갖도록 프로세서(102) 내의 캐시 메모리들을 구성할 수 있다. 시스템 내의 클라이언트들이 공통 메모리 자원의 캐시들을 유지할 때, 특히 멀티프로세싱 시스템에서, 일관성 없는 데이터로 인해 문제들이 발생할 수 있다. 캐시 일관성 모듈(230)은 다수의 캐시들에서 데이터 값들의 일관된 보기를 유지하는 것에 의해 그러한 충돌들을 관리할 수 있다. 캐시 일관성 모듈(230) 내의 IOMMU는 직접 메모리 액세스 I/O 버스를 메인 메모리에 연결할 수 있다. IOMMU는 CPU에 보이는(CPU-visible) 가상 주소들을 물리적 주소들로 변환할 수 있고, 디바이스에 보이는(device-visible) 가상 주소들(이 맥락에서는 디바이스 주소들 또는 I/O 주소들이라고도 함)을 물리적 주소들에 매핑할 수 있다. 게다가, IOMMU는 결함 있거나 악의적인 디바이스들로부터 프로세서(102) 내의 캐시 메모리들을 보호할 수 있다. 일부 실시예들에서, UEFI/BIOS(110)(도 1)에 저장된 펌웨어는 IOMMU를 조작하여 자원들을 분리할 수 있고, 프로세서(102)로부터의 전용 하드웨어 컴포넌트들을 갖는 격리된 도메인들을 생성할 수 있다.
도 2에 도시된 바와 같이, 프로세서(102)는 모듈 PME(Power Management Event)(234)를 포함하는 관리 컴플렉스를 또한 포함할 수 있다. 일부 실시예들에서, PME(234)는 UEFI/BIOS 셋업 유틸리티를 용이하게 하고/하거나 시스템이 종료될 때 네트워크 카드에 대한 전력을 용이하게 하도록 구성될 수 있다. UEFI/BIOS(110)는 도 7 내지 도 9와 관련하여 추가로 논의되는 바와 같이 DRM 프로세스들을 위한 구성(configure) 및 실행(execute) 애플리케이션들을 실행하도록 구성될 수 있다. 게다가, UEFI/BIOS(110)는 격리된 도메인들로부터의 자원들을 피닝하기 위해 SRE 프로세스들을 수행할 수 있다. 더욱이, 관리 컴플렉스는 DCE(Distributed Codec Engine)(232), 보안 제어기(238), 버퍼 관리(240), 및 I/O 프로세서(242)를 포함할 수 있다.
프로세서(102)는 캐시 일관성 모듈(230)에서의 데이터를 제어하도록 구성된 버퍼(248), 예를 들어, L2 캐시(208)와 dcache(206) 사이의 교환들을 제어하도록 구성된 L2 스위치(250), 및 가속 모듈(252)을 또한 포함할 수 있다. 프로세서(102)는 직렬화기/역직렬화기(serializer/de-serializer)(256), 하나 이상의 PCI 카드(258), 및 하나 이상의 SATA(Serial Advanced Technology Attachment) 모듈(260)을 포함할 수 있다. 게다가, 프로세서(102)는 SR-IOV(Single Root I/O Virtualization)(262)를 위한 모듈을 포함할 수 있다.
도 3은 개시된 실시예들에 따른, 보호된 디지털 미디어의 예시적인 UEFI 기반 론칭을 설명하는 블록 다이어그램(300)을 예시한다. 블록 다이어그램(300)에 의해 설명되는 프로세스는 UEFI 애플리케이션들 및 원격 증명을 통해 DRM을 제공한다. 그러한 구성에서, 운영 체제를 시작하지 않고, 부팅 스테이지에서 원격 증명과 온 다이 암호화를 결합하는 것에 의해 디지털 미디어가 보호되고 시행될 수 있다. 블록 다이어그램(300)에서 설명되는 프로세스는, 프로세스가 디지털 저작권을 특정 머신들에 연계시키고 변조에 대한 기회들을 최소화하므로, 컴퓨터 동작의 보안을 향상시킨다.
블록 다이어그램(300)은 플랫폼 초기화(302)의 초기 스테이지를 나타낸다. 예를 들어, 일부 실시예들에서, 컴퓨터, 서버 또는 플랫폼(100)(도 1)과 같은, 플랫폼은 전원이 켜지거나 다른 방식으로 초기화된다. 플랫폼의 프로세서(예를 들면, 프로세서(102))는 프로세서가 대상 디지털 미디어가 설치되어 있는지 여부를 결정하는 발견 동작(304)을 수행할 수 있다. 예를 들어, UEFI 기반 DRM을 통해 시행되는 디지털 미디어는 안전한 런타임 환경(SRE)을 포함할 수 있다. 그러한 실시예들에서, 발견 동작(304)은 SRE가 설치되었는지 여부의 결정을 포함할 수 있다. 발견 동작(304)은 플랫폼 내의 메모리 위치들을 분석하고/하거나 레지스터들을 파싱하도록 구성된 UEFI 애플리케이션에 의해 수행될 수 있다. 대안적으로 및/또는 추가적으로, 발견 동작(304)은 플랫폼에 이미 설치된 디지털 미디어를 분석하는 BIOS 기반 프로그램들을 포함할 수 있다.
발견 동작(304)이 디지털 미디어가 설치되었다고 결정하는 경우, 프로세서는 UEFI 로더(306)를 실행, 초기화 또는 스탠드업(stand up)할 수 있다. 도 3에 도시된 바와 같이, UEFI 로더(306)는 부트 엔클레이브(310)를 포함할 수 있다. UEFI 로더(306)는 설치된 미디어를 부트 엔클레이브(310)를 통해 로딩하도록 구성될 수 있다. 일부 실시예들에서, UEFI 로더(306)는 디스크로부터 부팅하는 것 뿐만 아니라 특정 디스크 상의 특정 위치에 있는 특정 부트 로더로부터 부팅하는 것에 의해 디스크 파티션들로부터의 엔트리들로부터 판독할 수 있는 능력을 가진 확장 가능 펌웨어를 포함할 수 있다. 그러한 실시예들에서, UEFI 로더(306)는 초기화 시에 초기화될 실행 가능 포맷들을 정의하고 실행 가능 포맷들을 실행할 수 있다. 더욱이, UEFI 로더(306)는, 예를 들어, BIOS 펌웨어와 같이, 시스템을 부팅하고, 마스터 부트 레코드(master boot record, MBR)를 탐색하며, 거기로부터 부트 로더를 실행할 수 있도록, 역호환성을 가질 수 있다.
도 3에 도시된 바와 같이, 일부 실시예들에서, UEFI 로더(306)는 암호화 또는 복호화 동작들을 수행할 수 있다. 예를 들어, UEFI 로더(306)는 봉인된 키(312)를 사용하여 디지털 미디어를 복호화할 수 있다. 일부 실시예들에서, 봉인된 키(312)는 AES 키를 포함할 수 있다. AES 키는 플랫폼에 로컬로 저장될 수 있다. 그렇지만, 일부 실시예들에서, AES 키는 상이한 위치로부터 검색될 수 있다. 봉인된 키(312) 및 부트 엔클레이브(310)를 사용하여, UEFI 로더(306)는 (바이너리 파일들과 같은) 파일들을 복호화하기 위해 복호화 동작(314)을 수행할 수 있다. 복호화 동작(314)이 성공적일 때, 프로세서는 부트 미디어 동작(316)을 수행할 수 있으며, 여기서 대상 미디어(발견 동작(304)에서 발견됨)가 열리며, 실행되고/되거나 로딩된다.
발견 동작(304)이 부정적인 결과(예를 들면, 대상 디지털 미디어가 플랫폼에 설치되지 않음)를 반환할 때, 프로세서는 UEFI 프로비저닝 애플리케이션(320)을 초기화하거나 시작할 수 있다. 도 3에 도시된 바와 같이, UEFI 프로비저닝 애플리케이션(320)은 봉인 엔클레이브(322) 및 증명 엔클레이브(324)를 포함할 수 있다. 봉인 엔클레이브(322)는 안전한 데이터 저장을 위한 동작들을 수행하도록 구성될 수 있다. 예를 들어, 봉인 엔클레이브(322)는 메인 메모리의 일부인 엔클레이브에 있는 경우에만 데이터에 보호를 제공할 수 있다. 따라서, 봉인 엔클레이브(322)는 일시적이고 파괴될 수 있으며, 엔클레이브 내에서 보호되는 임의의 데이터는 봉인 동작 후에 상실될 것이다. 그렇지만, 일부 실시예들에서, 봉인 엔클레이브(322)는 데이터를 엔클레이브 외부에 저장하기 위해 특별한 배열들을 통해 데이터를 재사용하도록 구성될 수 있다.
증명 엔클레이브(324)는 원격 증명 서비스들을 수행하도록 구성될 수 있다. 예를 들어, 도 8과 관련하여 추가로 설명되는 바와 같이, 증명 엔클레이브(324)는 플랫폼의 아이덴티티를 검증하기 위해 원격 제공자(신뢰 당사자(relying party) 또는 챌린저 당사자(challenger party)로도 알려짐)를 용이하게 하기 위해 원격 증명 작업들을 수행할 수 있다. 증명 엔클레이브(324)는 증명되고 있는 소프트웨어를 식별하고, (실행 모드와 같은) 측정되지 않은 상태의 상세들을 결정하며, 가능한 소프트웨어 변조에 대한 평가를 제공하는 동작들을 수행할 수 있다. 일부 실시예들에서, 증명 엔클레이브(324)는 증명 서버로의 암호화된 통신 채널들을 생성 및 사용할 수 있다. 자격 증명들 또는 다른 민감한 데이터와 같은, 비밀들은 증명 엔클레이브(324)에 직접 프로비저닝될 수 있다. 더욱이, 증명 엔클레이브(324)는 원격 증명 또는 ECDSA(Elliptic Curve Digital Signature Algorithm) 기반 원격 증명을 위해 향상된 개인 정보 보호 ID(Enhanced Privacy ID)를 지원할 수 있다.
도 3에 도시된 바와 같이, UEFI 프로비저닝 애플리케이션(320)은 프로비저닝 서버(326)와 통신할 수 있다. 일부 실시예들에서, UEFI 프로비저닝 애플리케이션(320)과 프로비저닝 서버(326) 사이의 통신은 암호화될 수 있다. 예를 들어, 그리고 도 9와 관련하여 추가로 논의되는 바와 같이, UEFI 프로비저닝 애플리케이션은 프로비저닝 서버(326)와의 SSL/TLS 암호화 통신을 설정하도록 구성될 수 있다. 다른 유형들의 통신이 또한 고려된다. 예를 들어, UEFI 프로비저닝 애플리케이션(320)은 경량 암호화(Lightweight Cryptography), NSS, GnuTLS, Polar SSL, MatrixSSL을 통해 서버들에 연결될 수 있다. 게다가, UEFI 프로비저닝 애플리케이션(320)은 블록체인 동작들을 통해 서버들에 결합될 수 있다. 대안적으로, UEFI 프로비저닝 애플리케이션(320)은 암호화 없이 서버들에 결합될 수 있다. 예를 들어, 일부 실시예들에서, UEFI 프로비저닝 애플리케이션(320) 및 서버들로부터의 통신은 플랫폼들을 검증하기 위해 증명 기반 데이터와 함께 이송되는 물리적 디바이스들(예를 들어, USB 드라이브들 또는 하드 드라이브들)로 수행될 수 있다.
프로비저닝 서버(326)는 플랫폼의 아이덴티티를 검증하기 위한 동작들을 수행할 수 있다. 예를 들어, 프로비저닝 서버(326)는 플랫폼들의 화이트리스트들 또는 블랙리스트들을 검증하기 위해 인에이블 서버(enabling server)(330)와 통신할 수 있다. 인에이블 서버(330)는 미디어 바이너리(332) 및 업데이트된 키들(334)을 포함할 수 있다. 미디어 바이너리(332)는 플랫폼 초기화(302) 동안 초기화되는 플랫폼에 의해 설치되거나 조작될 수 있는 디지털 미디어일 수 있다. 업데이트된 키들(334)은 미디어 바이너리(332)를 암호화 및/또는 복호화하도록 구성된 RSA 키들을 포함할 수 있다.
프로비저닝 서버(326)는 또한 증명 서비스(328)와 통신할 수 있다. 증명 서비스(328)는 원격 상대방을 검증하기 위한 동작들을 수행할 수 있다. 증명 서비스(328)는 애플리케이션의 아이덴티티, 애플리케이션 온전성(intactness)(예를 들어, 변조되지 않았다는 것), 및 애플리케이션이 엔클레이브 내에서 안전하게 실행되고 있다는 것에 대한 검증을 제공할 수 있다. 특정 경우에, 엔클레이브의 콘텐츠가, 동일한 플랫폼으로부터가 아니라, 원격으로 액세스될 수 있다. 증명 서비스(328)는 원격 액세스가 안전하도록 하기 위해 증명 엔클레이브(324)를 용이하게 할 수 있다. 이것은 민감한 미디어의 원격 배포를 제공한다. 더욱이, 증명 서비스(328)는 대칭 및 비대칭 키 시스템들 양쪽 모두를 이용할 수 있다. 프로비저닝 서버(326)는 키들 및 증명 데이터를 암호화 통신을 통해 UEFI 프로비저닝 애플리케이션(320)에 제공할 수 있다.
프로세서가 미디어가 증명을 통과하는지 여부를 결정하는 검증 동작(340)을 프로세서가 수행할 수 있다. 서버들로부터 수신되는 키들 및 증명 데이터에 기초하여, 프로세서는 미디어가 증명을 통과했는지 여부와 잠금 해제될 수 있는지 여부를 결정할 수 있다. 검증 동작(340)이 성공적이지 않은 경우, 프로세서는 동작을 중지(halt)하며 중지 메시지(342)를 생성하고/하거나 성공하지 못한 검증을 기록할 수 있다. 검증 동작(340)이 성공적인 경우, 프로세서는 봉인된 키(346)를 사용하여 복호화 동작(344)을 수행할 수 있다. 봉인된 키(346)는 프로비저닝 서버(326) 및/또는 증명 서비스(328)로부터 수신되는 AES 키를 포함할 수 있다.
일부 실시예들에서, 암호화된 매체는 TLS(Transport Layer Security) 암호화된 채널일 수 있고, 초기 키(예를 들어, 업데이트된 키들(334))는 RSA(Rivest-Shamir-Adleman) 공개 키를 포함할 수 있으며, 봉인된 키(346)는 대칭 개인 키를 포함할 수 있고, 바이너리 파일을 수신하는 단계는 증명 엔클레이브 내의 바이너리 파일의 증명을 검증하는 단계를 포함할 수 있다.
미디어 바이너리(332)가 복호화될 때, UEFI 부트 파티션(348)은 개인 키(350)를 사용하여 봉인된 바이너리를 봉인 해제(unseal)하기 위해 복호화 동작(314)을 수행할 수 있다. 개인 키(350)는 바이너리 파일들을 복호화하도록 구성된 RSA 개인 키를 포함할 수 있다. 성공적인 복호화는 그러면 부트 미디어 동작(316)을 결과할 것이다.
도 4는 개시된 실시예들에 따른, 고객 오프라인 복구 및 업데이트 설치 프로세스를 설명하는 블록 다이어그램(400)을 예시한다. 일부 실시예들에서, 백업 및/또는 복구 파일들은 도 3에서 설명된 UEFI 기반 DRM 프로세스를 통해 전달 및 보호될 수 있다. 블록 다이어그램(400)은 플랫폼들에서 시스템 통합 및 검증을 완료하기 위한 프로세스를 설명한다. 블록 다이어그램(400)은 대상 플랫폼들에서의 고객 오프라인 복구 및 업데이트 설치에 대한 사용 사례를 설명한다.
백업 UEFI 부트 파티션(402)은 플랫폼 초기화 동안 초기화될(또는 스탠드업될) 수 있다. 부트 파티션(402)은 복수의 봉인된 UEFI 백업들(406) 및 업데이트 패키지(408)를 저장할 수 있는 고객/디렉터(director) 저장소와 통신할 수 있다. 플랫폼 초기화 동안, 백업 UEFI 부트 파티션(402)은 플랫폼의 증명 데이터에 기초하여 봉인된 UEFI 백업들(406) 중 하나 이상을 식별할 수 있다. 식별된 UEFI 백업들(406)은 UEFI 로더(306)(도 3)와 유사하게 구성될 수 있는 백업 UEFI 로더(410)에 로딩될 수 있고, 부트 엔클레이브(412)는 미디어 백업을 초기화하기 위해 부팅 동작들을 수행할 수 있다.
부팅 동작은 플랫폼 노드(420)에서 실행될 수 있다. 일단 백업 또는 업데이트 동작이 설치될 업데이트 또는 백업 패키지들을 식별하면, 패키지들은 설치를 위해 플랫폼 노드에게 전송될 수 있다. 플랫폼 노드는 또한 고객 오프라인 업데이트/복구 데이터(414)를 수신하여, 고객/디렉터 저장소(404)에 없을 수 있는 업데이트들 또는 복구를 독립적으로 설치하는 옵션을 사용자들에게 제공할 수 있다. 플랫폼 노드는 도 3과 관련하여 이전에 설명된 컴포넌트들을 포함할 수 있다. 플랫폼 노드(420)는 부트 엔클레이브(308)를 갖는 UEFI 로더(306), 및 복구 봉인된 바이너리를 복호화하도록 구성된 개인 키(350)를 갖는 UEFI 부트 파티션(348)을 포함할 수 있다.
블록 다이어그램(400)은, 일부 실시예들에서, 프로세서가 클라이언트 플랫폼에서 복구 또는 업데이트들을 위해 UEFI-시행 DRM 정책들을 사용할 수 있다는 것을 묘사한다. 도 4에 도시된 바와 같이, 복구/업데이트는 온라인 또는 오프라인으로 수행될 수 있다. 예를 들어, 일부 실시예들에서, UEFI-DRM 보호된 콘텐츠는 업데이트 복구 스크립트일 수 있고, UEFI 로더(306)는 제2 UEFI 애플리케이션을 사용하여 봉인된 바이너리 파일을 복호화한 후에 복구 명령어들을 검색하도록 구성될 수 있다.
도 5는 개시된 실시예들에 따른, 보안 하이퍼바이저를 통한 가상 머신들에서의 디지털 저작권 관리를 위한 예시적인 프로세스(500)의 플로차트이다. 프로세스(500)는 플랫폼(100)(도 1) 또는 프로세서(102)(도 2)에 의해 수행될 수 있다. 추가적으로 및/또는 대안적으로, 프로세서 내의 상이한 계층들의 애플리케이션들은 프로세스(500)의 특정 단계들을 수행할 수 있다. 예를 들어, UEFI 애플리케이션은 프로세스(500)의 일부 단계들을 수행할 수 있는 반면, 가상 머신 루트(virtual machine root)는 프로세스(500)의 다른 단계들을 수행할 수 있다. 추가적으로, SRE 테넌트는 프로세스(500)의 특정 동작들을 수행할 수 있고 가상 머신 OS는 프로세스(500)의 특정 단계들을 수행할 수 있다.
단계(502)에서, UEFI 부트 애플리케이션은 플랫폼 부트업 또는 초기화의 일부로서 초기화될 수 있다. 예를 들어, 도 3과 관련하여 추가로 설명된 바와 같이, 프로세서는 발견 동작(304)(도 3)과 같은, 발견을 위해 UEFI 애플리케이션들을 초기화할 수 있다. 단계(504)에서, 플랫폼(100)(또는 프로세서(102))은 엔클레이브를 생성할 수 있다. 예를 들어, UEFI 부트 애플리케이션을 통해, 프로세서는 부트 엔클레이브 또는, 증명 엔클레이브(324)와 같은, 증명 엔클레이브를 생성할 수 있다. 일부 실시예들에서, 단계(504)의 엔클레이브는 SGX(Software Guard Extensions) 엔클레이브를 포함할 수 있으며, 보호되고 엔클레이브 자체 외부의 임의의 프로세스에 의해 판독되거나 저장될 수 없는 콘텐츠를 갖는 개인 메모리 영역들을 정의하도록 구성될 수 있다. 더욱이, 단계(504)의 엔클레이브는 플랫폼 자체 내에서만 온 더 플라이로(on the fly) 복호화될 수 있다. 게다가, 일부 실시예들에서, 엔클레이브들은 엔클레이브 자체 내에서 실행되는 코드 및 데이터만을 조작하도록 제한될 수 있다. 그러한 구성은 엔클레이브 내의 코드를 "염탐(spy on)"되거나 다른 코드에 의해 검사되는 것으로부터 보호할 수 있다.
더욱이, 일부 실시예들에서, 단계(504)에서 생성되는 엔클레이브들 내의 코드 및 데이터는 엔클레이브가 신뢰할 수 있지만 엔클레이브 외부의 어떤 프로세스도 신뢰할 수 없는 위협 모델(운영 체제 자체 및 임의의 하이퍼바이저를 포함함)을 활용할 수 있으며, 따라서 이들은 잠재적으로 적대적인 것으로 취급된다. 그러한 실시예들에서, 엔클레이브 콘텐츠는 그의 암호화된 형태로 되어 있지 않은, 엔클레이브 외부의 임의의 코드에 의해 판독될 수 없다.
단계(506)에서, 플랫폼(100)은 키들을 검색할 수 있다. 예를 들어, 프로세서(102)(도 2)는 AES 및/또는 RSA 키들을 검색하기 위해 서버들과 통신할 수 있다. 단계(507)에서, 플랫폼은 키를 수신 및/또는 봉인하여 봉인된 키를 생성할 수 있다.
단계(508)에서, 플랫폼(100)은 단계(506)에서 검색되는 키들을 사용하여 키 유도 함수(KDF)를 수행할 수 있다. 예를 들어, 플랫폼은 UEFI 엔클레이브들 중 하나를 통해 키 유도 정책을 지정하는 동작들을 수행할 수 있다. 일부 실시예들에서, 플랫폼 엔클레이브들은 신뢰할 수 있는 값들 및/또는 엔클레이브의 속성들의 사용을 허용하는 정책들을 시행할 수 있다. 게다가, KDF는, 할당되지 않은 필드들에 자동으로 0으로 설정하는 것과 같은, 플랫폼 특정 정책들을 사용할 수 있다. 단계(508)는 플랫폼 특정 값들 또는 변수들을 또한 포함할 수 있다. 예를 들어, 단계(508)에서, 플랫폼(100)은 사용자로부터 오는 엔트로피를 추가할 수 있다(예를 들면, 소유자 에포크(owner epoch)는 유도 동안 파라미터로서 사용될 수 있다). 이 값은 패스워드의 유도에 의해 부팅 시에 구성될 수 있으며, 각각의 전원 사이클 동안 비휘발성 메모리에 저장될 수 있다.
단계(508)로부터의 유도된 키들은 이어서 플랫폼이 미디어를 봉인 해제하거나 복호화할 수 있는 단계(522)에서 미디어를 복호화하는 데 사용될 수 있다. 예를 들어, 도 3과 관련하여 논의된 바와 같이, 플랫폼(100)은 프로비저닝 서버(326)로부터 수신되는 디지털 미디어를 복호화하도록 구성될 수 있다. 미디어는 이어서 단계(524)에서 제2 KDF를 통해 및/또는 단계(520)에서 해시 함수를 이용하여 또다시 보호될 수 있다. 일단 데이터가 검색된 키들을 사용하여 복호화되고 새로운 함수들에 대한 온 다이 엔트로피를 사용하여 또다시 보호되면, 플랫폼은 단계(526)에서 UEFI 애플리케이션을 종료할 수 있다.
일부 실시예들에서, 단계들(502 내지 526)은 프로세서에서 실행되는 UEFI 애플리케이션에 의해 수행될 수 있다. 예를 들어, 프로세서(102)(도 2)에서의 UEFI 애플리케이션은 단계들(502 내지 526)의 동작들을 수행할 수 있다. 추가적으로 및/또는 대안적으로, 단계들(502 내지 526)은 가상 머신들을 론칭하기 위한 보안 엔클레이브(secure enclave)들을 생성하는 SRE UEFI 애플리케이션에 의해 실행될 수 있다.
단계(528)에서, 플랫폼(100)은 UEFI 애플리케이션으로부터 가상 머신을 부팅할 수 있다. 예를 들어, 플랫폼(100)은 보호된 환경을 론칭하기 위해 UEFI로부터 검증된 강제 부팅을 수행할 수 있으며, 이는 사용자들이 엔클레이브들을 위한 프로세서(102) 자원들을 격리시킬 수 있게 할 수 있다. 일부 실시예들에서, 단계(528)에서 론칭되는 보호된 환경은 크로스 도메인(cross-domain) 공격들로부터 프로세서(102)를 보호할 수 있는 격리된 도메인들을 생성할 수 있다. 따라서, 단계(528)에서, 플랫폼(100)은 유출, 수정 및 권한 상승(privilege escalation) 공격들을 피하는 보호된 환경을 생성할 수 있다. 보호된 환경들은 PCH(Platform Controller Hub) 및 각각의 프로세서의 고유 식별(unique identification)을 사용하여 사용자 애플리케이션들을 가상화된 게스트들에 바인딩하는 것에 의해 특정 프로세서(102) 자원들을 갖는 격리된 도메인들을 생성할 수 있다. 예를 들어, 보호된 환경은 프로세서(102)로부터의 자원들을 대응하는 엔클레이브들, 가상 머신들, 커널들, 및/또는 사용자 애플리케이션들에 할당하는 멀티 소켓 시스템을 구축할 수 있다. 일부 실시예들에서, 가상 머신의 부트는 프로세서 자원들을 격리시키기 위해 브리징 칩들 또는 PCIe 카드들의 주소들 및/또는 레지스터들을 조작할 수 있다.
더욱이, 격리된 도메인들을 보호하고 생성하기 위해, 단계(528)에서의 가상 머신의 부팅은 온 칩 방화벽 정책들을 생성할 수 있다. 일부 실시예들에서, 보호된 환경은 PCIe 디바이스를 특정 가상 머신 게스트 또는 애플리케이션 테넌트에 암호적으로 직접 매핑할 수 있다. 보호된 환경은 방화벽에 의해 셋업되는 규칙들에 기초하여 특정 자원들에 대한 액세스를 제한할 수 있는 규칙들 또는 정책들을 구현할 수 있다. 게다가, 보호된 환경은 프로세서 자원들에 대한 액세스를 제한하여 프로세서(102)의 개별, 코어, 및 메모리 자원들을 보호하는 내장된 보안 정책을 갖는 유형 0 또는 유형 1 하이퍼바이저를 구현할 수 있다. 보호된 환경들은, 특정 엔클레이브들로부터의 프로세싱 요청들을 연관시키고 이들이 특정 자원들에 액세스할 수 있는지 여부를 결정하거나 이들을 특정 도메인으로 라우팅하기 위해, 계층화된 프로토콜들, 래퍼(wrapper)들, 또는 내용 주소화 메모리 필터(content addressable memory filter)들을 포함할 수 있다. 게다가, 단계(528)에서 배포되는 보호된 환경들은 프로세싱 요청들의 액세스 또는 라우팅을 결정하기 위해 정규 표현식 매칭(regular expression matching)을 수행하거나 페이로드 스캐너(payload scanner)를 구현할 수 있다.
단계(528)에서 론칭되는 보호된 환경들 및 임의의 가상 머신들은 보호될 수 있다. 예를 들어, 단계(512)에서, 엔진 해시(engine hash)는 사용자 정책, 서명 및/또는 온 다이 엔트로피에 기초하는 해싱 함수를 생성할 수 있다. 엔진 해시는 제3 KDF(514)에 사용될 수 있다. 이러한 방식으로, UEFI 엔클레이브들 내의 고유한 암호화 자료는 가상 MSR(Mode Specific Register)에 저장될 수 있는 추가적인 고유 키들을 생성하기 위해 엔트로피의 소스로서 사용될 수 있으며, 따라서 하이퍼바이저는 이러한 키들을 단계(528) 동안 론칭된 VM들에게 이용 가능하게 만들 수 있다. 도 5에 도시된 구성은 온 다이 DRM을 VM들로 확장하여 가상 MSR 키 저장소를 사용하여 각각의 VM에 대한 고유 키들을 동시에 생성할 수 있다. 일부 실시예들에서, 단계(512)가 수행되거나 테넌트 정책에 저장될 수 있는 동안 단계들(514 및 528)이 가상 머신 루트에 의해 수행될 수 있다.
단계(516)에서, 플랫폼(100)은 인스턴스 키(instance key)마다 다중 키 전체 메모리 암호화(multi-key total memory encryption)를 수행할 수 있다. 예를 들어, 플랫폼(100)은 다수의 암호화 키들을 구축 및 지원하는 동작들을 수행할 수 있다. 그러한 실시예들에서, SRE 테넌트는 암호화 키들을 지원하기 위해 보안 동작을 수행할 수 있다. 플랫폼(100)은 또한 이용 가능한 키들의 서브세트를 구성할 수 있는 소프트웨어를 실행할 수 있다. 단계(516)는 증명 메커니즘들과 결합되고/되거나 키 프로비저닝 서비스들과 함께 사용될 때 비휘발성 메모리를 제공하는 단계를 또한 포함할 수 있다.
단계(530)에서, 플랫폼(100)은 가상 CPU의 인스턴스를 생성할 수 있고, 검증 키들을 할당하기 위해 모델 특정 레지스터 키 저장소를 사용할 수 있다. 예를 들어, 단계(530)에서, 플랫폼(100)은 단계(516)에서 지정되는 주소들에 따라 하이퍼바이저를 로딩하는 부트로더를 실행할 수 있다. 그러한 실시예들에서, 플랫폼(100)은 멀티부트 정보(Multiboot Information, MBI) 구조를 통해 메모리 정보를 전달하기 위한 sets flag들을 제공하는 멀티부트 헤더(multiboot header)로 구축되는 하이퍼바이저를 작동시킬 수 있다. 더욱이, 플랫폼(100)은 가상 MSR에 있는 키들을 사용하여 VCPU를 검증할 수 있다.
그에 따라, 일부 실시예들에서, UEFI-시행 DRM 프로세스들은 적어도 하나의 프로세서의 분리된 자원들로 가상 머신들을 론칭하도록 구성된 하이퍼바이저를 보호할 수 있다. 그러한 실시예들에서, UEFI 애플리케이션들은 고유한 온 다이 암호화 고유 자료를 사용하여 복수의 제3 키들을 생성하고 복수의 제3 키들을 플랫폼의 모드 특정 레지스터에 저장하도록 구성될 수 있다. 프로세스(500)는 복수의 제3 키들 중 적어도 하나를 사용하여 하이퍼바이저 상의 가상 머신들을 검증하는 것을 용이하게 할 수 있다.
단계(532)에서, 암호화된 디스크 및/또는 엔클레이브는 특정 운영 체제 또는 사용자 애플리케이션을 위해 사용자에게 제공될 수 있다. 예를 들어, 단계(532)에서, LUKS(Linux Unified Key Setup)가 디스크 암호화 사양으로서 사용될 수 있다. 검증된 VCPU들로부터의 다른 디스크 암호화 또는 대상 애플리케이션들이 또한 고려된다. 예를 들어, 단계(532)에서, 플랫폼(100)은 다른 유형들의 가상 머신들을 실행하거나 상이한 운영 체제들을 실행할 수 있다.
도 6은 개시된 실시예들에 따른, 엔클레이브들을 생성하는 UEFI 애플리케이션의 블록 다이어그램(600)이다. 블록 다이어그램(600)에서의 요소들은 플랫폼(100)의 일부일 수 있다. 예를 들어, 블록 다이어그램(600)의 요소들은 프로세서(102)에 의해 구현될 수 있다.
도 6에 도시된 바와 같이, 엔클레이브(602)는 보안 명령어 코드들을 엔클레이브 바이너리 이미지(604)에 통신할 수 있다. 엔클레이브(602)는 BareMetal 운영 체제에 의해 지원될 수 있고/있거나 특정 매핑들 또는 이벤트들에 대한 링크들을 포함할 수 있다. 게다가, 엔클레이브(602)는 단계(504)(도 5)에서 생성될 수 있다. 엔클레이브 바이너리 이미지(604)는 또한 UEFI 프로비저닝 애플리케이션(320) 또는 UEFI 로더(306)(도 3)를 포함할 수 있는 UEFI 애플리케이션(610)과 통신할 수 있다. UEFI 애플리케이션(610)은 도 3 및 도 5와 관련하여 설명된 UEFI 애플리케이션들 중 임의의 것일 수 있다. 대안적으로 및/또는 추가적으로, UEFI 애플리케이션(610)은 UEFI 로더(306) 또는 UEFI 부트 파티션(348)(도 4)으로서 구현될 수 있다.
UEFI 애플리케이션(610)은 파서/로더(612), 엔클레이브 호출자(enclave caller)(616), 엔클레이브 애플리케이션 프로그래밍 인터페이스(API)(614), 및 엔클레이브 페이지 캐시(EPC) API(618)를 포함할 수 있다. 파서/로더(612)는 엔클레이브 API(614) 및 EPC API(618) 둘 모두와 통신하도록 구성될 수 있다. 예를 들어, 파서/로더(612)는 생성 요청들을 엔클레이브 API(614)에게 송신할 수 있다. 일부 실시예들에서, 생성 요청들은 엔클레이브 제어 구조 및 스레드 제어 구조를 지정할 수 있다. 게다가, 파서/로더(612)는 또한, 예를 들어, 도 3과 관련하여 설명된 바와 같이 보안 키들을 사용하여 엔클레이브들을 초기화하기 위해 초기화 명령어들을 엔클레이브 API에게 송신할 수 있다. 파서/로더(612)는 또한 메모리 공간들 또는 엔클레이브 주소 지정(enclave addressing)을 EPC API(618)에 추가하라는 요청들을 송신할 수 있다. 엔클레이브 호출자(616)는 페이지들 요청을 엔클레이브 API(614)에게 전송하도록 구성 가능할 수 있다.
엔클레이브 API(614) 및 EPC API(618) 둘 모두는 CPU(608)와 통신할 수 있다. 예를 들어, 도 6에 도시된 바와 같이, 엔클레이브 API(614)는 엔클레이브를 생성하는 것, 엔클레이브를 초기화하는 것, 또는 제어를 이전하는 것을 위한 명령어들을 전송할 수 있다. 예를 들어, 엔클레이브 API(614)는 엔클레이브의 주소 공간 및 신뢰 루트(root of trust)를 정의하는 새로운 엔클레이브를 인스턴스화하기 위해 ECREATE 명령어들을 전송할 수 있다. 엔클레이브 API(614)는 또한 애플리케이션으로부터 엔클레이브 내의 미리 결정된 위치로 제어를 이전하기 위해 EENTER와 같은 명령어들을 전송할 수 있다. 추가적으로, 엔클레이브 API(614)는 엔클레이브 구조들을 검증하기 위한 명령어들을 전송하도록 구성될 수 있다. 예를 들어, 엔클레이브 API(614)는 토큰 구조(Token Structure)들을 검증하고 엔클레이브가 실행되도록 허용되는지 여부를 결정하기 위해 EINIT 명령어를 제출할 수 있다.
유사하게, EPC API(618)는 또한 CPU(608)와 통신하고 동작들을 전송하도록 구성될 수 있다. 예를 들어, 도 6에 도시된 바와 같이, EPC API(618)는 페이지들을 제거하거나 추가하기 위한 동작들을 전송할 수 있다. EPC API(618)는 새로운 페이지를 엔클레이브에 추가하기 위해 EADD 명령어들을 전송할 수 있다. 그러한 실시예들에서, CPU(608)의 운영 체제는 페이지 및 그의 콘텐츠를 선택하는 것만을 책임지고 있을 수 있다. 대안적으로 및/또는 추가적으로, EPC API(618)는 엔클레이브로부터 페이지를 영구적으로 제거하기 위해 EREMOVE의 동작들을 전송할 수 있다.
UEFI 애플리케이션(610) 내의 API들과 통신하는 것 외에도, CPU(608)는 또한 도 6에 설명된 바와 같이 콘텐츠 블록들을 포함하는 메모리 구조일 수 있는 엔클레이브 페이지 캐시(Enclave Page Cache, EPC)(606)와 통신할 수 있다. 예를 들어, 엔클레이브 페이지 캐시(606)는, SECS(SGX Enclave Control Structure)와 같은, 제어 구조를 포함할 수 있다. 각각의 엔클레이브는 그의 메타데이터(예를 들면, 그의 해시 및 크기)를 포함하는 제어 구조와 연관될 수 있다. 제어 구조는 안전한 코드(secure code)를 통해 그리고 프로세서 자체에 의해서만 액세스 가능할 수 있을 뿐이다. 엔클레이브 페이지 캐시(606)는 또한 엔클레이브 제어 액세스를 제공할 수 있는 적어도 스레드 제어 구조와 연관될 수 있다. 게다가, 스레드 제어 구조는 엔클레이브에 대한 실행 지점(execution point)을 나타낼 수 있다. 엔클레이브 페이지 캐시(606)는 또한 예외들 및 인터럽션들 처리 동안 프로세서의 상태를 저장하는 데 사용되는 하나 이상의 상태 저장 영역(save state area, SSA)을 포함할 수 있다. 더욱이, 엔클레이브 페이지 캐시(606)는 하나 이상의 스택 및 어레이 섹션을 포함할 수 있고, 엔클레이브 진입(enclave entry), 엔클레이브 페이지들, 및 엔클레이브 이탈(enclave exit)을 지정할 수 있다.
도 6에 도시된 바와 같이, CPU(608)는 엔클레이브 페이지 캐시(606)로부터 명령어들을 송수신할 수 있다. 예를 들어, CPU(608)는 페이지들을 개시하기 위한 명령어들을 전송하고 엔클레이브를 종료하기 위한 명령어들(예컨대, EEXIT 명령어들)을 수신할 수 있다. 게다가, CPU(608)는 서명들 및 베이스 주소들에 기초하여 검증 동작들을 수행할 수 있다.
블록 다이어그램(600)은 도 3과 관련하여 논의된 엔클레이브(예를 들면, 프로세서를 프로비저닝하는 것 및/또는 설치된 애플리케이션들을 결정하는 것을 위한 엔클레이브들)를 생성하는 UEFI 애플리케이션의 예시적인 구현을 도시한다. 그렇지만, 상이한 시퀀스들, 연결들 및/또는 명령어들로 다른 구현들이 가능할 수 있다.
도 7은 개시된 실시예들에 따른, UEFI 보호된 디지털 콘텐츠를 론칭하기 위한 프로세스(700)의 플로차트이다. 일부 실시예들에서, 아래에서 설명되는 바와 같이, 플랫폼(100)(도 1)은 프로세스(700)에서의 동작들을 수행할 수 있다. 예를 들어, 프로세서(102) 및/또는 UEFI/BIOS(110)는 프로세스(700)에서의 동작들을 수행할 수 있다. 추가적으로 및/또는 대안적으로, 플랫폼(100)의 다수의 요소들은 프로세스(700)의 동작들을 수행할 수 있다. 예를 들어, 프로세서(102)가 프로세스(700)의 특정 동작들을 수행할 수 있는 반면, 코프로세서(104) 또는 UEFI/BIOS(110)는 다른 동작들을 수행할 수 있다. 그렇지만, 다른 실시예들에서, 독립형 프로세서들 또는 프로세서들의 컴포넌트들은 프로세스(700)에서의 단계들을 수행할 수 있다. 그러한 실시예들에서, 프로세서(102)의 특정 요소들(도 2)이 프로세스(700)의 단계들을 수행할 수 있거나 코어들(202) 중 임의의 것이 프로세스(700)의 동작들 중 하나 이상을 수행할 수 있다.
단계(702)에서, 플랫폼(100)은 UEFI/BIOS 펌웨어를 개시할 수 있다. 예를 들어, 플랫폼(100)의 전원 켜기에 응답하여, 플랫폼(100)은 UEFI/BIOS(110)(도 1)에서의 개시 루틴들을 실행할 수 있다. 개시 루틴들의 일부로서 그리고 임의의 운영 체제를 개시하기 전에, 플랫폼(100)은 단계(704)에서 대상 미디어가 설치되었는지를 결정할 수 있다. 예를 들어, 플랫폼(100)은 대상 애플리케이션이 플랫폼(100)에 설치되었는지 여부를 결정하기 위해 메모리 블록들을 파싱할 수 있다. 대안적으로 및/또는 추가적으로, 단계(704)에서, 플랫폼(100)은 특정 디지털 미디어가 이용 가능한지 여부를 결정하기 위해 데이터 로그들 또는 매니페스트들을 검토하는 UEFI 애플리케이션을 개시할 수 있다. 일부 실시예들에서, 대상 디지털 미디어는 안전한 런타임 환경(SRE) 또는 하이퍼바이저일 수 있다.
플랫폼(100)이 대상 미디어가 설치되지 않은 것으로 결정하는 경우(단계(704): 아니요), 플랫폼(100)은 계속하여 단계(706)로 갈 수 있다. 단계(706)에서, 플랫폼(100)은 제1 UEFI 애플리케이션을 론칭할 수 있다. 예를 들어, 플랫폼(100)은 UEFI 프로비저닝 애플리케이션(320)을 론칭할 수 있다. 단계(708)에서, 플랫폼(100)은 암호화된 매체를 통해 서버와 통신할 수 있다. 예를 들어, 단계(706)의 제1 UEFI 애플리케이션을 사용하여, 플랫폼(100)은 디지털 미디어 및/또는 바이너리 파일들을 제공하는 서버와 TLS를 통해 통신할 수 있다. 일부 실시예들에서, 도 3과 관련하여 논의된 바와 같이, UEFI 프로비저닝 애플리케이션(320)은 프로비저닝 서버(326)와 통신할 수 있다. 그러한 실시예들에서, 도 9와 관련하여 추가로 논의되는 바와 같이, 제1 UEFI 애플리케이션은 암호화 셋업들 및 통신 절차들을 처리할 수 있다.
단계(710)에서, 플랫폼(100)은 바이너리 파일들 및 제1 복호화 키를 수신할 수 있다. 예를 들어, 플랫폼(100)은 (단계(704)에서 발견되는) 대상 미디어의 바이너리 파일 및 봉인 및/또는 암호 복호화 프로세스들을 위한 AES 또는 RSA 키를 수신할 수 있다. 일부 실시예들에서, 단계(710)는 증명 데이터를 검증하는 단계를 또한 포함할 수 있다. 예를 들어, 도 3과 관련하여 논의된 바와 같이, 제1 UEFI 애플리케이션 내의 증명 엔클레이브는 보안 증명 엔클레이브(secure attestation enclave) 내의 바이너리 파일들의 증명을 검증할 수 있다. 단계(712)에서, 플랫폼(100)은 수신된 바이너리를 (단계(706)으로부터의) UEFI 애플리케이션으로 봉인하고 로컬 복호화 키들을 생성할 수 있다. 예를 들어, 제1 UEFI 애플리케이션 내의 봉인 엔클레이브는 바이너리 파일들을 봉인할 수 있다. 그러한 실시예들에서, 봉인 엔클레이브는 보안 봉인 엔클레이브(secure sealing enclave)를 봉인하는 단계 내에서 수신된 키로 바이너리들의 봉인을 수행할 수 있다.
단계(714)에서, 플랫폼(100)은 대상 미디어를 봉인된 바이너리로서 설치할 수 있다. 예를 들어, 플랫폼(100)은 단계(712)에서 봉인되는 바이너리 파일을 플랫폼(100)의 저장 디바이스에 설치할 수 있다. 단계(714)는 대상 미디어의 플랫폼 프로비저닝을 결과할 수 있다.
단계(704)에서 플랫폼(100)이 대상 미디어가 설치되어 있다고 결정하는 경우(단계(704): 예), 플랫폼(100)은 단계들(706 내지 714)을 스킵하고 단계(716)로 이동할 수 있다. 즉, 일부 시나리오들에서, 플랫폼(100)은 단계(714) 이후에 계속하여 단계(716)로 갈 수 있는 반면, 다른 시나리오들에서는, 플랫폼(100)이 단계(704) 이후에 계속하여 단계(716)로 갈 수 있다.
단계(716)에서, 플랫폼(100)은 봉인된 바이너리를 제2 UEFI 애플리케이션에 로딩할 수 있다. 예를 들어, 플랫폼(100)은 단계(712)에서 봉인되는 바이너리를 단계(716)에서 UEFI 로더(306)에 로딩할 수 있다. 대안적으로 및/또는 추가적으로, 플랫폼(100)은 저장 디바이스로부터 이전에 봉인된 바이너리 파일을 검색하고 이를 부팅 엔클레이브를 갖는 UEFI 로더에 로딩할 수 있다. 일부 실시예들에서, 봉인된 바이너리는 봉인된 AES 키와 함께 보안 부트 엔클레이브에 로딩되고, 엔클레이브 내의 암호화 엔트로피는 각각의 부트 모듈 바이너리를 검증하기 위해 봉인된 키와 함께 사용된다. 제2 UEFI 로더 또는 제2 UEFI 애플리케이션을 통해, 플랫폼(100)은 단계(718)에서 봉인된 바이너리 파일을 로컬 복호화 키들을 사용하여 복호화할 수 있다. 예를 들어, 플랫폼(100)은 봉인된 바이너리들을 복호화하기 위해 로컬로 생성된 키를 사용할 수 있다.
성공적인 복호화 시에, 단계(720)에서, 플랫폼(100)은 대상 미디어를 열거나 실행할 수 있다. 예를 들어, 단계(718)에서의 복호화가 성공적인 경우, 봉인된 소프트웨어 또는 대상 미디어가 실행될 수 있다. 이 시점에서, 플랫폼(100)은 실행될 미디어의 보안과 안전 둘 모두를 보장하기 위해 온 다이 암호화를 사용하여 프로비저닝되고 검증되었을 것이다. 엔클레이브 내의 CPU 온 다이 암호화 고유 자료를 사용하는 것은 인가되지 않은 플랫폼들에서 디지털 미디어가 실행되는 것을 방지한다. 따라서, 프로세스(700)는 미디어 프로비저닝 동안 및 실행 동안 둘 모두에서 플랫폼의 암호화 검증을 강제한다. 게다가, 단계들(702 내지 718)은 운영 체제들이 프로비저닝 서버들과의 통신, 암호화, 봉인 및 또한 복호화 작업들을 위해 UEFI 애플리케이션들을 사용하여 심지어 초기화되기 전에 수행되도록 구성될 수 있다. 그러한 특징들은 최종 사용자의 개입을 필요로 하지 않는 자동화된 프로세스들로 플랫폼들의 프로비저닝을 용이하게 하면서 공격 벡터들을 최소화할 수 있으므로 컴퓨터의 기능을 향상시킬 수 있다.
단계(720)까지, 플랫폼(100)은 운영 체제를 초기화하지 않고, 그 대신에, UEFI 애플리케이션들을 사용하여 단계들(702 내지 718)을 수행했을 수 있다. 단계(720)에서, 플랫폼(100)은 운영 체제를 개시할 수 있다. 일부 실시예들에서, 단계(720)에서의 운영 체제의 개시는 단계(718)에서의 성공적인 복호화를 조건으로 할 수 있다. 단계(724)에서, 플랫폼(100)은 UEFI 엔클레이브들 중 하나에서 생성되는 고유 키들을 사용하여 하이퍼바이저에서 가상 머신들을 검증할 수 있다. 예를 들어, 도 3과 관련하여 논의된 바와 같이, 플랫폼(100)은 암호화 자료를 생성하기 위해 온 다이 엔트로피를 사용하여 키들을 생성하고 키들을 가상 MSR 키에 저장할 수 있다. 그러한 동작들은 DRM을 가상 머신들로 확장한다. 예를 들어, 플랫폼(100)은 하이퍼바이저(단계(722)에서 운영 체제와 함께 시작될 수 있음)가 VM들에 이용 가능하게 할 수 있는 고유 키들을 생성하기 위해 엔트로피 소스로서 UEFI 엔클레이브들 내의 고유 암호 자료를 사용할 수 있다. 단계(724)에서, 플랫폼(100)은 UEFI-시행 DRM 서비스들을 VM들로 확장할 수 있다. 그러한 구현은 DRM 시행이 각각의 OEM 또는 외부의 신뢰할 수 있는 플랫폼에 대해 별도의 물리적 프로비저닝 서버들을 사용할 필요가 없기 때문에 DRM의 기술 분야를 향상시킬 수 있다.
도 8은 개시된 실시예들에 따른, 원격 증명을 통한 디지털 콘텐츠의 UEFI 기반 프로비저닝을 위한 프로세스(800)의 플로차트이다. 일부 실시예들에서, 플랫폼(100)(도 1)은 프로세스(800)에서의 동작들을 수행할 수 있다. 예를 들어, 프로세서(102) 또는 UEFI/BIOS(110)는 프로세스(800)에서의 동작들을 수행할 수 있다. 추가적으로 및/또는 대안적으로, 플랫폼(100)의 다수의 요소들은 프로세스(800)의 동작들을 수행할 수 있다. 예를 들어, 프로세서(102)가 프로세스(800)의 특정 동작들을 수행할 수 있는 반면, 코프로세서(104) 또는 UEFI/BIOS(110)는 다른 동작들을 수행할 수 있다. 그렇지만, 다른 실시예들에서, 독립형 프로세서들 또는 프로세서들의 컴포넌트들은 프로세스(800)에서의 단계들을 수행할 수 있다. 그러한 실시예들에서, 프로세서(102)(도 2)의 특정 요소들이 프로세스(800)의 단계들을 수행할 수 있다. 예를 들어, 코어들(202) 중 임의의 것은 프로세스(800)의 동작들 중 하나 이상을 수행할 수 있다.
단계(802)에서, 플랫폼(100)은 플랫폼을 초기화하고 부트 펌웨어를 실행할 수 있다. 예를 들어, 플랫폼(100)은 부트업 동안 플랫폼을 초기화하고, 기본 입출력 시스템을 실행하여 플랫폼을 초기화할 수 있다. 단계(804)에서, 플랫폼(100)은 플랫폼이 프로비저닝되었는지 여부를 결정할 수 있다. 예를 들어, 플랫폼(100)은 특정 디지털 미디어가 플랫폼(100)의 저장 디바이스들에 설치되었는지 여부 또는 플랫폼에 이미 존재하는 디지털 콘텐츠가 있는지 여부를 결정할 수 있다.
플랫폼이 프로비저닝되지 않았다고 플랫폼(100)이 결정하는 경우(단계(804): 아니요), 플랫폼(100)은 계속하여 단계(806)로 갈 수 있다. 단계(806)에서, 플랫폼(100)은 UEFI 펌웨어 내에서 증명 및 봉인 엔클레이브들을 스탠드업하거나 실행할 수 있다. 예를 들어, 도 3과 관련하여 논의된 바와 같이, 플랫폼(100)은, UEFI 프로비저닝 애플리케이션(320)(도 3)과 같이, 증명 엔클레이브 및 봉인 엔클레이브를 갖는 UEFI 애플리케이션을 스탠드업할 수 있다. 단계(808)에서, 플랫폼(100)은 증명 데이터를 제공하고 프로비저닝 파일들을 요청하기 위해 암호화된 매체를 통해 서버와 통신할 수 있다. 플랫폼(100)은 증명 데이터를 프로비저닝 서버에 통신할 수 있다. 프로비저닝 서버는 증명 데이터에 기초하여 플랫폼(100)을 검증하고, 암호화된 매체들을 통해, 바이너리 파일들 및 검증 디바이스들을 통신할 수 있다. 예를 들어, 도 3 및 도 5와 관련하여 논의된 바와 같이, 플랫폼(100)은 UEFI 프로비저닝 애플리케이션(320)을 통해 프로비저닝 서버(326)와 통신할 수 있고, 프로비저닝 서버(326)는 차례로 증명 서비스(328) 및 인에이블 서버(330)와 인터페이싱할 수 있다.
단계(810)에서, 플랫폼(100)은 바이너리 파일들 및 키들을 수신할 수 있다. 예를 들어, 플랫폼(100)은 프로비저닝 서버로부터의 바이너리 미디어 파일들 및/또는 AES 또는 RSA 키들을 수신할 수 있다. 단계(812)에서, 플랫폼(100)은 UEFI 애플리케이션 내의 증명 엔클레이브를 사용하여 증명을 검증할 수 있다. 예를 들어, 일부 실시예들에서, 플랫폼(100)은 단계(812)에서 SGX 원격 증명을 수행할 수 있다. 그러한 실시예들에서, UEFI 애플리케이션 내의 증명 엔클레이브는 원격 증명의 스테이지들을 수행할 수 있다. 게다가, 플랫폼(100)은 원격 증명 요청을 하고, 로컬 증명을 수행하며, 로컬 증명을 원격 증명으로 변환하고, 원격 증명을 챌린저에게 반환하며, 원격 증명을 검증할 수 있다. 플랫폼(100)은 SGX 원격 증명을 위해 다음 스테이지들을 수행할 수 있다:
스테이지 1: 애플리케이션이 챌린저 - UEFI 엔클레이브들 내에서 안전하게 실행되고 있는지 여부를 검증하기를 원하는 엔터티 - 와의 통신을 설정하는 것.
스테이지 2: 엔클레이브 아이덴티티(인가되지 않은 당사자들에 대한 엔클레이브의 콘텐츠에 대한 액세스를 제한하는 엔클레이브의 로그의 암호화 해시)를 저장하는 것에 의해 애플리케이션들을 그의 쿼팅 엔클레이브(quoting enclave)에 링크시키는 것.
스테이지 3: 임시 공개 키 - 짧은 시간 기간 동안만 지속되는 것 - 및 챌린지에 대한 응답들을 생성하는 것. 이 키는 비밀들을 엔클레이브에 프로비저닝하기 위해 챌린저에 의해 사용될 수 있다.
스테이지 4: 키 및 그의 발신 엔클레이브(originating enclave)에 관한 정보를 포함하는 리포트(report)를 수신하고, 이 리포트를 쿼팅 엔클레이브에 포워딩하는 것.
스테이지 5: 리포트 키(report key)를 얻기 위해 하드웨어 명령어들을 호출하고, 리포트 키를 사용하여 리포트를 검증하는 것. 증명 서비스에 의해 검증 가능한 키를 사용하여, 엔클레이브에 의해 서명되는 구조를 생성하는 것.
스테이지 6: 쿼팅 엔클레이브에 의해 생성되고 서명되는 쿼트(quote)를 수신 및/또는 생성하는 것.
스테이지 7: 공개 키 인증서를 사용하여 생성되는 쿼트의 서명을 검증하여 서명을 검증하는 것.
단계(812)의 원격 증명 프로세스는 플랫폼 아이덴티티에 대한 검증을 제공할 수 있어, 디지털 미디어가 수정되지 않았다는 것과 디지털 미디어가 인에이블된 플랫폼 상의 엔클레이브 내에서 안전하게 실행될 것임을 보증할 수 있다. 이어서 증명은 원격 액세스를 안전하게 만들어, 다수의 플랫폼들에서 DRM 관리를 가능하게 하지만 플랫폼 기반 암호화를 사용하여 인에이블된 플랫폼에서 콘텐츠를 관리하거나 제한하는 것을 가능하게 한다.
단계(812)에서 증명이 검증될 때, 플랫폼(100)은 계속하여 단계(814)로 가서 봉인 엔클레이브를 사용하여 키들로 바이너리 파일들을 봉인하는 것을 수행할 수 있다. 예를 들어, 플랫폼(100)은 EGETKEY SGX 명령어들을 사용하여 특정 엔클레이브 또는 특정 저작자에 대해 바이너리 파일들을 봉인할 수 있다. 단계(816)에서, 플랫폼(100)은 봉인된 바이너리를 설치할 수 있어, 디지털 콘텐츠의 보안 및 안전을 향상시키기 위해 원격 증명 검증을 사용하여 플랫폼의 프로비저닝을 완료할 수 있다.
단계(804)에서, 플랫폼이 프로비저닝되었다고 플랫폼(100)이 결정하는 경우(단계(804): 예), 플랫폼(100)은 단계들(806 내지 816)을 스킵하고 계속하여 단계(818)로 갈 수 있다. 일부 실시예들에서, 봉인된 바이너리를 플랫폼에 설치한 후에, 플랫폼(100)은 또한 계속하여 단계(818)로 갈 수 있다.
단계(818)에서, 플랫폼(100)은 봉인된 바이너리를 UEFI 펌웨어 내의 보안 부트 엔클레이브에 로딩할 수 있다. 예를 들어, 도 3과 관련하여 논의된 바와 같이, 플랫폼(100)은 봉인된 바이너리를 실행을 위해 로딩하기 위해 UEFI 로더(306)를 사용할 수 있다. 단계(820)에서, 플랫폼(100)은 봉인된 바이너리를 복호화하기 위해 부팅 엔클레이브 내의 암호화 엔트로피 및 로컬 복호화 키를 사용할 수 있다. 예를 들어, 단계(814)의 봉인된 바이너리는 봉인된 AES 키와 함께 보안 부트 엔클레이브에 로딩될 수 있다. 게다가, 각각의 부트 모듈을 검증하기 위해 봉인된 키와 함께 엔클레이브 내의 암호화 엔트로피가 사용될 수 있다.
단계(822)에서, 플랫폼(100)은 복호화가 성공적이었는지 여부를 결정할 수 있다. 플랫폼(100)이 복호화가 성공적이지 않았다고 결정하는 경우(단계(822): 아니오), 플랫폼(100)은 계속하여 단계(824)로 가서 실행 중인 동작을 중지할 수 있으며, 플랫폼에서 소프트웨어를 실행하지 않거나 디지털 미디어를 열지 않을 것이다. 그러나 플랫폼(100)이 복호화가 성공적이었다고 결정하는 경우(단계(822): 예), 플랫폼(100)은 계속하여 단계(826)로 가서 플랫폼에서 바이너리 및/또는 관련 디지털 미디어를 실행할 수 있다. 예를 들어, 봉인된 바이너리를 설치한 후 운영 체제를 개시하기 전에, 플랫폼(100)은 봉인된 바이너리를 제2 UEFI 애플리케이션에 로딩할 수 있으며, 여기서 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함할 수 있다. 게다가, 플랫폼(100)은 제2 키 및 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 봉인된 바이너리 파일을 복호화하고 봉인된 바이너리 파일의 복호화가 성공적일 때 디지털 미디어를 열거나 실행할 수 있다.
단계(828)에서, 플랫폼(100)은 엔클레이브 내의 암호화 자료를 사용하여 새로운 키들을 생성할 수 있다. 예를 들어, 플랫폼(100)은 하이퍼바이저가 VM에 이용 가능하게 할 수 있는 가상 MSR에 저장될 수 있는 추가적인 고유 키들을 생성하기 위해 엔클레이브 내의 고유 암호 자료를 엔트로피 소스로서 사용할 수 있다. 단계(830)에서, 플랫폼(100)은 단계(828)의 고유 키들을 하이퍼바이저에 의해 지원되는 VM들에 이용 가능하게 할 수 있다.
대안적으로 및/또는 추가적으로, 플랫폼이 프로비저닝되어 있다고 플랫폼(100)이 결정할 때(단계(804): 예), 플랫폼(100)은, 제2 UEFI 애플리케이션(부트 엔클레이브를 포함하는 제2 UEFI 애플리케이션)을 론칭하는 것, 제2 키 및 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 봉인된 바이너리 파일을 복호화하는 것, 봉인된 바이너리 파일의 복호화가 성공적일 때 디지털 미디어를 실행하는 것을 포함하는, 간소화된 부팅 동작을 수행할 수 있다.
프로세스(800)는 정지 및 실행 중인 특정 하드웨어에 바인딩된 소프트웨어 바이너리를 구축하기 위해 다수의 암호화 기술들과 고유 하드웨어 암호화 자료의 조합을 용이하게 할 수 있다. 추가적으로, 프로세스(800)는 가상 MSR 키 저장소들을 구현하는 가상화 환경에서 그리고 특정 소프트웨어 설치들로 플랫폼들을 프로비저닝할 시에 DRM을 가상 머신들로 확장하는 고유한 구현을 용이하게 할 수 있다. 기술들의 이러한 조합 및 프로세스(800)의 개시된 시퀀스는 소프트웨어 복제(software cloning)를 방지하고 특정 인가된 플랫폼들에서의 소프트웨어의 설치 및 실행을 제한할 수 있다. 게다가, 프로세스(800)는 인증 서버를 사용해야 한다는 요구사항들을 피할 수 있는데, 그 이유는 프로세스(800)가 자체 완비된 검증 옵션을 제공할 수 있고 각각의 OEM 또는 외부 플랫폼들을 위한 추가적인 서버들 또는 하드웨어를 필요로 하지 않고 고객 플랫폼들에서 소프트웨어의 보안 프로비저닝을 가능하게 할 수 있기 때문이다.
도 9는 개시된 실시예들에 따른, 프로세서와 증명 서버 사이의 통신을 위한 프로세스(900)의 타이밍 다이어그램이다. 도 9에 도시된 바와 같이, 블록 다이어그램(300)의 상이한 요소들은 프로세스(900)를 수행할 수 있다. 예를 들어, UEFI 프로비저닝 애플리케이션(320)이 프로세스(900)의 일부 단계들을 수행할 수 있는 반면, 프로비저닝 서버(326)는 프로세스(900)의 다른 단계들을 수행할 수 있다. 그렇지만, 다른 실시예들에서, 플랫폼(100)이 프로세스(900)의 단계들을 수행할 수 있다. 예를 들어, 프로세서(102)(도 2)가 프로세스(900)의 단계들을 수행할 수 있다.
단계(902)에서, UEFI 프로비저닝 애플리케이션(320)은 클라이언트 시작 통신(client opening communication)을 프로비저닝 서버(326)에게 송신할 수 있다. 예를 들어, UEFI 프로비저닝 애플리케이션(320)은 TLS 통신을 개시하라는 요청을 송신할 수 있다. 단계(904)에서, 프로비저닝 서버(326)는 요청을 검증할 수 있다.
단계(908)에서, UEFI 프로비저닝 애플리케이션(320)과 프로비저닝 서버(326)는 프리 마스터(pre master) 및 마스터 키들을 교환할 수 있다. 예를 들어, UEFI 프로비저닝 애플리케이션(320)과 프로비저닝 서버(326)는 (예를 들어, Diffie-Hellman을 사용하여) 키 교환을 수행하고 마스터 키들을 유도할 수 있다.
단계(910)에서, UEFI 프로비저닝 애플리케이션(320)은 증명 데이터를 제공할 수 있다. 예를 들어, 도 8과 관련하여 논의된 바와 같이, UEFI 프로비저닝 애플리케이션(320) 내의 증명 엔클레이브는 증명 데이터를 프로비저닝 서버(326)에 제공할 수 있다. 단계(912)에서, 프로비저닝 서버(326)는 플랫폼을 검증할 수 있고, 성공적인 검증 시에, 프로비저닝 서버(326)는 단계(914)에서 키들 및 바이너리 파일들을 UEFI 프로비저닝 애플리케이션(320)에게 송신할 수 있다.
단계(915)에서, UEFI 프로비저닝 애플리케이션(320)은 프로비저닝 서버(326)와 교환된 정보의 증명을 검증할 수 있다. 단계(916)에서, UEFI 프로비저닝 애플리케이션(320)은 바이너리를 봉인하여 플랫폼에 설치할 수 있다. 예를 들어, UEFI 프로비저닝 애플리케이션(320)은 도 6과 관련하여 논의된 동작들로 바이너리 파일들을 봉인하여 설치하기 위해 CPU와 통신할 수 있다. 단계(918)에서, UEFI 프로비저닝 애플리케이션은 성공적인 복호화 및 설치를 프로비저닝 서버(326)에게 통지할 수 있다. 단계(920)에서, 프로비저닝 서버(326)는, 예를 들어, TLS 통신을 종료하는 서버 종료 통신(sever closing communication)을 전송할 수 있다.
본 개시내용의 다른 양상은, 실행될 때, 하나 이상의 프로세서로 하여금, 위에서 논의된 바와 같이, 방법들을 수행하게 할 수 있는 명령어들을 저장하는 비일시적 컴퓨터 판독 가능 매체에 관한 것이다. 컴퓨터 판독 가능 매체는 휘발성 또는 비휘발성, 자기, 반도체, 테이프, 광학, 이동식, 비이동식, 또는 다른 유형들의 컴퓨터 판독 가능 매체 또는 컴퓨터 판독 가능 저장 디바이스들을 포함할 수 있다. 예를 들어, 컴퓨터 판독 가능 매체는, 개시된 바와 같이, 컴퓨터 명령들이 저장되어 있는 저장 유닛 또는 메모리 모듈일 수 있다. 일부 실시예들에서, 컴퓨터 판독 가능 매체는 컴퓨터 명령어들이 저장되어 있는 디스크 또는 플래시 드라이브일 수 있다.
개시된 시스템 및 관련 방법들에 대해 다양한 수정들 및 변형들이 이루어질 수 있음이 본 기술분야의 통상의 기술자에게 명백할 것이다. 다른 실시예들은 개시된 시스템 및 관련 방법들의 명세 및 실시를 고려하면 본 기술분야의 통상의 기술자에게 명백할 것이다. 명세 및 예들이 단지 예시적인 것으로 간주되며, 진정한 범위는 이하의 청구항들 및 그 등가물들에 의해 나타내어지는 것으로 의도된다.
본 개시내용이 그의 특정 실시예들을 참조하여 도시되고 설명되었지만, 본 개시내용이 다른 환경들에서, 수정 없이, 실시될 수 있다는 것이 이해될 것이다. 전술한 설명은 예시 목적으로 제공되었다. 이는 총망라하는 것이 아니며 개시된 정확한 형태들 또는 실시예들로 제한되지 않는다. 수정들 및 적응들은 개시된 실시예들의 명세 및 실시를 고려하면 본 기술분야의 통상의 기술자에게 명백할 것이다. 추가적으로, 개시된 실시예들의 양상들이 메모리에 저장되는 것으로 설명되지만, 본 기술 분야의 통상의 기술자는 이러한 양상들이 또한, 보조 저장 디바이스들, 예를 들어, 하드 디스크들 또는 CD ROM, 또는 다른 형태들의 RAM 또는 ROM, USB 미디어, DVD, 블루레이, 또는 다른 광학 드라이브 매체와 같은, 다른 유형들의 컴퓨터 판독 가능 매체에 저장될 수 있다는 것을 이해할 것이다.
서면 설명 및 개시된 방법들에 기초한 컴퓨터 프로그램들은 숙련된 개발자의 기술 내에 있다. 다양한 프로그램들 또는 프로그램 모듈들은 본 기술 분야의 통상의 기술자에게 알려진 기술들 중 임의의 것을 사용하여 생성될 수 있거나, 기존의 소프트웨어와 관련하여 설계될 수 있다. 예를 들어, 프로그램 섹션들 또는 프로그램 모듈들은 .Net Framework, .Net Compact Framework(및 Visual Basic, C 등과 같은 관련 언어들), Java, C++, Objective-C, HTML, HTML/AJAX 조합들, XML, 또는 Java 애플릿들이 포함된 HTML로 또는 이들을 통해 설계될 수 있다.
더욱이, 예시적인 실시예들이 본 명세서에서 설명되었지만, (예를 들면, 다양한 실시예들에 걸친 양상들의) 동등한 요소들, 수정들, 생략들, 조합들, 적응들 및/또는 변경들을 갖는 임의의 및 모든 실시예들의 범위는 본 개시내용에 기초하여 본 기술분야의 통상의 기술자에 의해 이해될 것이다. 청구항들에서의 제한들은 청구항들에서 이용되는 표현(language)에 기초하여 광의적으로 해석되어야 하며, 본 명세서에서 설명되는 예들로 또는 출원의 심사(prosecution) 동안 제한되지 않는다. 예들은 비배타적인 것으로 해석되어야 한다. 게다가, 개시된 방법들의 단계들은, 단계들을 재정렬하는 것 및/또는 단계들을 삽입 또는 삭제하는 것을 포함하여, 임의의 방식으로 수정될 수 있다. 따라서, 명세서 및 예들은 단지 예시적인 것으로 간주되며, 진정한 범위 및 사상은 이하의 청구항들 및 이들의 등가물들의 전체 범위에 의해 나타내어지는 것으로 의도된다.
따라서, 전술한 설명은 예시 목적으로만 제시되었다. 이는 총망라하는 것이 아니며 개시된 정확한 형태들 또는 실시예들로 제한되지 않는다. 수정들 및 적응들은 개시된 실시예들의 명세 및 실시를 고려하면 본 기술분야의 통상의 기술자에게 명백할 것이다.
청구항들은 청구항들에서 이용되는 표현에 기초하여 광의적으로 해석되어야 하고, 본 명세서에 설명된 예들로 제한되지 않으며, 이러한 예들은 비배타적인 것으로 해석되어야 한다. 게다가, 개시된 방법들의 단계들은, 단계들을 재정렬하는 것 및/또는 단계들을 삽입 또는 삭제하는 것을 포함하여, 임의의 방식으로 수정될 수 있다.

Claims (20)

  1. 디지털 저작권 관리를 위한 시스템으로서,
    플랫폼 내의 적어도 하나의 프로세서; 및
    실행될 때 동작들을 수행하도록 상기 적어도 하나의 프로세서를 구성하는 명령어들을 포함하는 적어도 하나의 메모리 디바이스
    를 포함하며, 상기 동작들은:
    상기 적어도 하나의 프로세서의 운영 체제를 개시하기 전에, 디지털 미디어가 플랫폼에 로컬로 설치되어 있는지 여부를 결정하는 동작;
    상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여, 증명 엔클레이브에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI(Unified Extensible Firmware Interface) 애플리케이션을 론칭하는 동작;
    상기 서버로부터 상기 암호화된 매체를 통해, 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하는 동작;
    상기 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키 - 상기 제2 키는 상기 플랫폼에 고유함 - 를 생성하는 동작; 및
    상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하는 동작
    을 포함하는, 시스템.
  2. 제1항에 있어서, 상기 동작들은:
    상기 봉인된 바이너리를 설치한 후 상기 운영 체제를 개시하기 전에, 상기 봉인된 바이너리를 제2 UEFI 애플리케이션에 로딩하는 동작 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하는 동작; 및
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 열거나 실행하는 동작
    을 더 포함하는, 시스템.
  3. 제2항에 있어서,
    상기 암호화된 매체는 TLS(Transport Layer Security) 암호화된 채널을 포함하고;
    상기 제1 키는 RSA(Rivest-Shamir-Adleman) 공개 키를 포함하며;
    상기 제2 키는 대칭 개인 키를 포함하는, 시스템.
  4. 제1항에 있어서, 상기 바이너리 파일을 수신하는 동작은 상기 증명 엔클레이브 내의 상기 바이너리 파일의 증명을 검증하는 동작을 포함하는, 시스템.
  5. 제1항에 있어서,
    상기 디지털 미디어는 상기 적어도 하나의 프로세서의 분리된 자원들로 가상 머신들을 론칭하도록 구성된 하이퍼바이저를 포함하고;
    상기 제1 UEFI 애플리케이션은:
    고유한 온 다이 암호화 고유 자료를 사용하여 복수의 제3 키들을 생성하고;
    상기 복수의 제3 키들을 상기 플랫폼의 모드 특정 레지스터에 저장하도록
    추가로 구성되는, 시스템.
  6. 제5항에 있어서, 상기 동작들은 상기 복수의 제3 키들 중 적어도 하나를 사용하여 상기 하이퍼바이저 상의 가상 머신들을 검증하는 동작을 더 포함하는, 시스템.
  7. 제1항에 있어서, 상기 동작들은:
    상기 디지털 미디어가 로컬로 설치되어 있다고 결정하는 것에 응답하여, 제2 UEFI 애플리케이션을 론칭하는 동작 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하는 동작; 및
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 실행하는 동작
    을 더 포함하는, 시스템.
  8. 제1항에 있어서,
    상기 디지털 미디어는 업데이트 복구 스크립트이고;
    상기 동작들은 상기 제2 UEFI 애플리케이션을 사용하여 상기 봉인된 바이너리 파일을 복호화한 후에 복구 명령어들을 검색하는 동작을 더 포함하는, 시스템.
  9. 디지털 저작권 관리를 위한 방법으로서,
    플랫폼 내의 프로세서의 운영 체제를 개시하기 전에, 디지털 미디어가 상기 플랫폼에 로컬로 설치되어 있는지 여부를 결정하는 단계;
    상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여, 증명 엔클레이브에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭하는 단계;
    상기 서버로부터 상기 암호화된 매체를 통해, 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하는 단계;
    상기 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키 - 상기 제2 키는 상기 플랫폼에 고유함 - 를 생성하는 단계; 및
    상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하는 단계
    를 포함하는, 방법.
  10. 제9항에 있어서,
    상기 봉인된 바이너리를 설치한 후 상기 운영 체제를 개시하기 전에, 상기 봉인된 바이너리를 제2 UEFI 애플리케이션에 로딩하는 단계 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하는 단계; 및
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 열거나 실행하는 단계
    를 더 포함하는, 방법.
  11. 제10항에 있어서,
    상기 암호화된 매체는 TLS(Transport Layer Security) 암호화된 채널을 포함하고;
    상기 제1 키는 RSA(Rivest-Shamir-Adleman) 공개 키를 포함하며;
    상기 제2 키는 대칭 개인 키를 포함하고;
    상기 바이너리 파일을 수신하는 단계는 상기 증명 엔클레이브 내의 상기 바이너리 파일의 증명을 검증하는 단계를 포함하는, 방법.
  12. 제9항에 있어서,
    상기 디지털 미디어는 상기 적어도 하나의 프로세서의 분리된 자원들로 가상 머신들을 론칭하도록 구성된 하이퍼바이저를 포함하고;
    상기 제1 UEFI 애플리케이션은:
    고유한 온 다이 암호화 고유 자료를 사용하여 복수의 제3 키들을 생성하고;
    상기 복수의 제3 키들을 상기 플랫폼의 모드 특정 레지스터에 저장하도록
    추가로 구성되며,
    상기 방법은 상기 복수의 제3 키들 중 적어도 하나를 사용하여 상기 하이퍼바이저 상의 가상 머신들을 검증하는 단계를 더 포함하는, 방법.
  13. 제9항에 있어서,
    상기 디지털 미디어가 로컬로 설치되어 있다고 결정하는 것에 응답하여, 제2 UEFI 애플리케이션을 론칭하는 단계 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하는 단계; 및
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 실행하는 단계
    를 더 포함하는, 방법.
  14. 제9항에 있어서,
    상기 디지털 미디어는 업데이트 복구 스크립트이고;
    상기 방법은 상기 제2 UEFI 애플리케이션을 사용하여 상기 봉인된 바이너리 파일을 복호화한 후에 복구 명령어들을 검색하는 단계를 더 포함하는, 방법.
  15. 장치로서,
    하나 이상의 프로세서; 및
    명령어들을 포함하는 하나 이상의 메모리 디바이스
    를 포함하며, 상기 명령어들은
    상기 장치의 운영 체제를 개시하기 전에, 디지털 미디어가 상기 장치에 로컬로 설치되어 있는지 여부를 결정하고;
    상기 디지털 미디어가 로컬로 설치되어 있지 않다고 결정하는 것에 응답하여, 증명 엔클레이브에 증명 데이터를 생성하고 증명 기반 데이터를 암호화된 매체를 통해 서버에 통신하도록 구성된 제1 UEFI 애플리케이션을 론칭하며;
    상기 서버로부터 상기 암호화된 매체를 통해, 상기 디지털 미디어의 바이너리 파일 및 제1 복호화 키를 수신하고;
    상기 제1 UEFI 애플리케이션의 봉인 엔클레이브를 사용하여 상기 바이너리 파일의 봉인을 수행하고 상기 제1 키 및 로컬 엔트로피에 기초하여 로컬 복호화 제2 키 - 상기 제2 키는 상기 플랫폼에 고유함 - 를 생성하며;
    상기 봉인된 바이너리 파일을 상기 플랫폼의 로컬 저장소에 설치하도록
    상기 하나 이상의 프로세서를 구성하는, 장치.
  16. 제15항에 있어서, 상기 명령어들은
    상기 봉인된 바이너리를 설치한 후 상기 운영 체제를 개시하기 전에, 상기 봉인된 바이너리를 제2 UEFI 애플리케이션에 로딩하고 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하며;
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 열거나 실행하도록
    상기 하나 이상의 프로세서를 추가로 구성하는, 장치.
  17. 제15항에 있어서,
    상기 암호화된 매체는 TLS(Transport Layer Security) 암호화된 채널을 포함하고;
    상기 제1 키는 RSA(Rivest-Shamir-Adleman) 공개 키를 포함하며;
    상기 제2 키는 대칭 개인 키를 포함하고;
    상기 바이너리 파일을 수신하는 것은 상기 증명 엔클레이브 내의 상기 바이너리 파일의 증명을 검증하는 것을 포함하는, 장치.
  18. 제15항에 있어서,
    상기 디지털 미디어는 상기 적어도 하나의 프로세서의 분리된 자원들로 가상 머신들을 론칭하도록 구성된 하이퍼바이저를 포함하고;
    상기 제1 UEFI 애플리케이션은:
    고유한 온 다이 암호화 고유 자료를 사용하여 복수의 제3 키들을 생성하고;
    상기 복수의 제3 키들을 상기 플랫폼의 모드 특정 레지스터에 저장하도록
    추가로 구성되며,
    상기 명령어들은 상기 복수의 제3 키들 중 적어도 하나를 사용하여 상기 하이퍼바이저 상의 가상 머신들을 검증하도록 상기 하나 이상의 프로세서를 추가로 구성하는, 장치.
  19. 제15항에 있어서, 상기 명령어들은
    상기 디지털 미디어가 로컬로 설치되어 있다고 결정하는 것에 응답하여, 제2 UEFI 애플리케이션을 론칭하고 - 상기 제2 UEFI 애플리케이션은 부트 엔클레이브를 포함함 -;
    상기 제2 키 및 상기 부트 엔클레이브 내의 암호화 엔트로피를 사용하여 상기 봉인된 바이너리 파일을 복호화하며;
    상기 봉인된 바이너리 파일의 복호화가 성공적일 때 상기 디지털 미디어를 실행하도록
    상기 하나 이상의 프로세서를 추가로 구성하는, 장치.
  20. 제15항에 있어서,
    상기 디지털 미디어는 업데이트 복구 스크립트이고;
    상기 명령어들은 상기 제2 UEFI 애플리케이션을 사용하여 상기 봉인된 바이너리 파일을 복호화한 후에 복구 명령어들을 검색하도록 상기 하나 이상의 프로세서를 추가로 구성하는, 장치.
KR1020237021856A 2020-12-01 2021-12-01 온 다이 암호화 및 원격 증명을 통한 디지털 콘텐츠관리 KR20240016243A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202063119868P 2020-12-01 2020-12-01
US63/119,868 2020-12-01
PCT/US2021/061429 WO2022119935A2 (en) 2020-12-01 2021-12-01 Digital content management through on-die cryptography and remote attestation

Publications (1)

Publication Number Publication Date
KR20240016243A true KR20240016243A (ko) 2024-02-06

Family

ID=81854877

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237021856A KR20240016243A (ko) 2020-12-01 2021-12-01 온 다이 암호화 및 원격 증명을 통한 디지털 콘텐츠관리

Country Status (6)

Country Link
US (1) US20240037217A1 (ko)
EP (1) EP4256439A2 (ko)
JP (1) JP2023553424A (ko)
KR (1) KR20240016243A (ko)
IL (1) IL303380A (ko)
WO (1) WO2022119935A2 (ko)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501666B2 (en) * 2013-04-29 2016-11-22 Sri International Polymorphic computing architectures
US9129095B1 (en) * 2014-12-19 2015-09-08 Tresorit, Kft Client-side encryption with DRM

Also Published As

Publication number Publication date
US20240037217A1 (en) 2024-02-01
WO2022119935A3 (en) 2022-09-15
WO2022119935A2 (en) 2022-06-09
IL303380A (en) 2023-08-01
JP2023553424A (ja) 2023-12-21
EP4256439A2 (en) 2023-10-11

Similar Documents

Publication Publication Date Title
JP6484255B2 (ja) 信頼実行環境を含むホストのアテステーション
US9989043B2 (en) System and method for processor-based security
JP6142027B2 (ja) ハイパーバイザ環境においてカーネルルートキットに対する保護を実行するシステムおよび方法
CN109669734B (zh) 用于启动设备的方法和装置
US8910238B2 (en) Hypervisor-based enterprise endpoint protection
KR101158184B1 (ko) 클라이언트 플랫폼들 상의 콘텐츠 보호
US11200300B2 (en) Secure sharing of license data in computing systems
KR20090005219A (ko) 점대점 상호연결 시스템 상에서의 보안 환경 초기화 명령의실행
US11714895B2 (en) Secure runtime systems and methods
CN110874468B (zh) 应用程序安全保护方法以及相关设备
AU2020287873B2 (en) Systems and methods for processor virtualization
Zaidenberg Hardware rooted security in industry 4.0 systems
US20240037217A1 (en) Digital content management through on-die cryptography and remote attestation
aw Ideler Cryptography as a service in a cloud computing environment
Schwarz et al. Affordable Separation on Embedded Platforms: Soft Reboot Enabled Virtualization on a Dual Mode System
EP4012587A1 (en) System and method for securely transmitting or storing data
Cheruvu et al. Base Platform Security Hardware Building Blocks
US11799670B2 (en) Secure end-to-end deployment of workloads in a virtualized environment using hardware-based attestation
Quaresma TrustZone Based Attestation in Secure Runtime Verification for Embedded Systems
CN114662092A (zh) 一种容器安全执行方法、设备及存储介质
CN116049844A (zh) 一种可信平台模块调用方法、系统、装置及存储介质