KR102466793B1

KR102466793B1 - 추상적 엔클레이브 신원

Info

Publication number: KR102466793B1
Application number: KR1020197021608A
Authority: KR
Inventors: 마누엘 코스타
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2017-01-24
Filing date: 2017-12-20
Publication date: 2022-11-11
Also published as: AU2017395731B2; EP3574432A1; JP7059291B2; EP3574432B1; CL2019002005A1; CN110226167B; RU2762141C2; AU2017395731C1; AU2017395731A1; CO2019007651A2; IL267935A; US11443033B2; JP2020505701A; KR20190108572A; NZ754509A; RU2019126638A; WO2018140160A1; US20180211035A1; RU2019126638A3; PH12019550121A1

Abstract

추상적 엔클레이브 신원이 제시된다. 추상적 신원은 여러 관련된, 그러나 동일하지 않은, 엔클레이브 인스턴스화에 대해 동일할 수 있는 보안 신원일 수 있다. 엔클레이브 신원 값은 인스턴스화된 엔클레이브에 관해서 추상적 엔클레이브 신원 타입으로부터 판정될 수 있다. 데이터를 추상적 신원에 실링하는 것, 단조 카운터를 점증시키는 것, 신뢰 시간 측정을 행하는 것과 같은 다양한 엔클레이브 동작이 추상적 신원으로써 수행될 수 있다.

Description

추상적 엔클레이브 신원

이 개시는 보안 컴퓨팅 시스템(secure computing system)에 관련된다.

보안 격리 영역(secure isolated region) 또는 신뢰 실행 환경(trusted execution environment)은 격리 영역 외부의 영역 내에 덜 신뢰되는 코드를 또한 가질 수 있는 컴퓨터 상에서 신뢰 코드(trusted code)를 실행하기 위한 보안 컨테이너(secure container)(본 문서에서 엔클레이브(enclave)로 지칭됨)를 제공한다. 엔클레이브의 격리 영역은 엔클레이브 외부에 주재하는(residing) 코드의 실행 동안에 보호되는 메모리의 부분을 포함한다. 격리된 메모리는 엔클레이브를 위한 코드 및 데이터 양자 모두를 포함할 수 있고, 이 메모리의 보호는 엔클레이브 메모리로부터 판독하는 것 또는 엔클레이브 메모리에 기록하는 것에 대한 제한에 더하여 엔클레이브 메모리에 담긴 코드를 실행하는 것의 제한을 포함할 수 있다. 엔클레이브 보안의 양상, 예컨대 메모리 격리 및 실행 제한은, 예를 들어, 컴퓨터 프로세서 내의 하드웨어에 의해 시행될 수 있다. 소프트웨어 증명(software attestation)은 특정한 엔클레이브의 격리 보안에 대한, 그리고 그 특정한 엔클레이브의 격리된 메모리 영역 내에 로딩된(loaded) 엔클레이브 코드에 대한 신뢰를 제공할 수 있다. 증명은 증명되는 엔클레이브가 가동(running) 중인 하드웨어 및 소프트웨어 플랫폼의 무결성(integrity)의 증거를 추가적으로 제공할 수 있다.

엔클레이브 시스템, 예컨대 마이크로소프트(Microsoft)의 가상 보안 모드(Virtual Secure Mode: VSM) 및 인텔(Intel)의 소프트웨어 가드 확장(Software Guard Extensions: SGX)은 사용자 모드(user mode)에서든 또는 커널 모드(kernel mode)에서든 가동되는 다른 코드로부터 엔클레이브를 격리시킴으로써 부분적으로 보안을 제공한다. 무결성 및 기밀성(confidentiality) 보장은 엔클레이브 내에서 가동되는 코드의 진본성(authenticity)에 대한 신뢰와, 엔클레이브 코드의 안전한 실행에 대한 신뢰의 더 높은 수준을 엔클레이브에 제공할 수 있다. 무결성 보장은 특정한 엔클레이브의 소프트웨어 증명에 의해 제공될 수 있다. 소프트웨어 증명은 엔클레이브 내부의 콘텐츠(명령어 및 데이터)의 암호학적으로 서명된 해시(cryptographically signed hash)를 포함할 수 있고 엔클레이브 환경에 대한 데이터와 조합될 수 있다. 엔클레이브가 하드웨어 보안 모듈(Hardware Security Module: HSM), 예컨대 신뢰 컴퓨팅 그룹(Trusted Computing Group: TCG) 신뢰 플랫폼 모듈(Trusted Platform Module: TPM) 표준에 부합하는(conforming) 하드웨어와의 조합이 되어 사용되는 경우에, 엔클레이브는 추가적인 수준의 보안 및 기밀성 보장을 제공할 수 있다.

엔클레이브의 격리 외부의 비신뢰 로컬 코드(untrusted local code)로부터의 신뢰 로컬 엔클레이브(trusted local enclave)의 격리에 의해 제공되는 보안에 더하여, 엔클레이브의 소프트웨어 증명은 원격 신뢰 컴퓨팅(remote trusted computing)을 가능하게 할 수 있다. 원격 엔클레이브의 증명은 엔클레이브에 의해 처리된 데이터의 기밀성에 대해서뿐만 아니라, 엔클레이브 내에서의 명령어의 실행의 무결성에 대해서도 신뢰를 제공할 수 있다. 신뢰되는 제조자로부터 하드웨어에 의해 원격 엔클레이브의 증명이 제공되는 경우에, 엔클레이브는 심지어 신뢰되지 않는 당사자가 소유하고 유지하는 미지의 컴퓨터 상에 엔클레이브가 주재하는 경우에도 신뢰될 수 있다. 이는, 예를 들어, 컴퓨팅 리소스가 인터넷 클라우드 기반 컴퓨팅 리소스 상에서 임차된 경우에, 흔히 있는 일이다.

엔클레이브 플랫폼을 추상화하기(abstracting) 위한 방법 및 시스템이 제시된다. 방법은, 엔클레이브 추상화 플랫폼(enclave abstraction platform)에 의해, 엔클레이브 클라이언트로부터 엔클레이브를 사용하기 위한 제1 요청을 수신하는 것을 포함할 수 있다. 제1 요청은 클라이언트 추상화 프로토콜(client abstraction protocol)에 부합할 수 있다. 제1 요청은 엔클레이브 네이태브 플랫폼(enclave native platform)과 연관된 엔클레이브 네이티브 프로토콜에 부합하는 제2 요청으로 변환될 수 있다. 제2 요청은 이후 엔클레이브 네이티브 플랫폼에 발신될 수 있다. 제1 요청은, 예를 들어, 엔클레이브를 인스턴스화하기(instantiate) 위한 요청, 엔클레이브의 증명 보고(attestation report)를 확인하기(verify) 위한 요청, 엔클레이브 내로 콜인을 하기(call into) 위한 요청, 또는 엔클레이브 및 엔클레이브 클라이언트 양자 모두와 공유된 메모리를 할당하기 위한 요청일 수 있다. 네이티브 플랫폼은 Intel 소프트웨어 가드 확장(Software Guard Extensions: SGX) 엔클레이브 아키텍처에 부합할 수 있고 네이티브 플랫폼은 Microsoft 가상 보안 모드(Virtual Secure Mode: VSM) 엔클레이브 아키텍처에 부합할 수 있다.

도 1은 엔클레이브 시스템의 예시적인 고수준 블록도를 묘사한다.
도 2는 기밀성 보장이 있는 메시지 통과(message passing)를 위한 예시적인 프로세스를 묘사한다.
도 3은 무결성 보장이 있는 메시지 통과를 위한 예시적인 프로세스를 묘사한다.
도 4는 선도(freshness) 보장이 있는 메시지 통과를 위한 예시적인 프로세스를 묘사한다.
도 5는 엔클레이브의 소프트웨어 증명을 위한 예시적인 프로세스를 묘사한다.
도 6은 예시적인 디피-헬만 키 교환(Diffe-Hellman Key Exchange: DKE) 프로토콜을 묘사한다.
도 7은 소프트웨어 증명을 위한 예시적인 신뢰 체인(chain of trust)을 묘사한다.
도 8은 예시적인 로컬 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다.
도 9는 추상화 계층을 가진 예시적인 로컬 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다.
도 10은 추상화 계층을 가진 예시적인 원격 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다.
도 11은 예시적인 일반 목적(general purpose) 컴퓨팅 환경을 묘사한다.
도 12는 네이티브 엔클레이브 플랫폼을 추상화하는 방법을 위한 예시적인 흐름도를 묘사한다.
도 13은 네이티브 엔클레이브 플랫폼을 추상화하는 방법을 위한 예시적인 흐름도를 묘사한다.
도 14는 추상적 엔클레이브 신원(abstract enclave identity)으로써 엔클레이브 동작(enclave operation)을 수행하는 방법을 위한 예시적인 흐름도를 묘사한다.
도 15는 추상적 엔클레이브 신원으로써 엔클레이브 동작을 수행하는 방법(1500)을 위한 예시적인 흐름도를 묘사한다.
도 16은 추상적 엔클레이브 신원 동등성(equivalence)을 가진 예시적인 시스템을 묘사한다.
도 17은 두 개의 동등한 엔클레이브로써의 병렬 처리를 위한 예시적인 흐름도를 묘사한다.
도 18은 두 개의 동등한 엔클레이브로써의 직렬 처리를 위한 예시적인 흐름도를 묘사한다.
도 19는 예시적인 분산 데이터 실링 시스템(distributed data sealing system)의 블록도이다.
도 20은 분산 데이터 실링 및 실링해제(unsealing)을 위한 예시적인 흐름도이다.
도 21은 예시적인 키 볼트(key vault) 엔클레이브의 블록도이다.
도 22는 몇몇 키 볼트 엔클레이브 동작을 위한 예시적인 흐름도이다.
도 23은 볼트 잠금된 키(vault-locked key)로써의 키 볼트 엔클레이브 동작을 위한 예시적인 흐름도이다.

엔클레이브를 위한 추상화 모델(abstraction model)이 개시되는데 이는 엔클레이브 클라이언트 및 엔클레이브 내부에서 가동되는 소프트웨어의 개발을 단순화한다. 추상화 모델은 Intel의 SGX 및 Microsoft의 VSM과 같은 네이티브 엔클레이브 플랫폼 아키텍처의 단순화 및 단일화일 수 있다. 추상화 계층 소프트웨어 컴포넌트는 엔클레이브 클라이언트 및 하나 이상의 네이티브 플랫폼 간의, 엔클레이브 내부의 소프트웨어 및 하나 이상의 네이티브 엔클레이브 플랫폼 간의, 그리고 엔클레이브 내부의 소프트웨어 및 엔클레이브 클라이언트 간의 통신을 전환(translate)할 수 있다. 그러한 추상화 플랫폼은 단일 버전의 엔클레이브 소프트웨어 및 엔클레이브 클라이언트 소프트웨어가 SGX 및 VSM과 같은 여러 네이티브 엔클레이브 플랫폼 위에서 가동될 수 있게 하는 이로움을 제공할 수 있다. 엔클레이브 및 엔클레이브 클라이언트를 위한 소프트웨어를 작성하는 작업(task)을 단순화하는 것에 더하여, 그것은 엔클레이브의 최종 사용자로 하여금 특정 컴퓨터의 네이티브 엔클레이브 플랫폼에 맞춰진(tailored) 엔클레이브 및 엔클레이브 클라이언트 소프트웨어 양자 모두의 버전을 찾을 필요 없이 임의의 지원되는 네이티브 엔클레이브 아키텍처를 지원하는 컴퓨터 상에서 엔클레이브 및 엔클레이브 클라이언트 소프트웨어를 가동할 수 있게 한다.

엔클레이브 추상화 모델은, 예를 들어, 다음을 위한 프리미티브(primitiive)를 포함할 수 있다: 엔클레이브의 라이프사이클(lifecycle)을 관리하는 것, 엔클레이브의 로컬 및 원격 증명, 엔클레이브에 데이터를 실링하는 것, 엔클레이브 내에의 및 엔클레이브로부터의 프로그램 전송 제어, 그리고 단조 카운터(monotonic counter) 및 신뢰 시간(trusted time)과 같은 다른 보안 특징. 엔클레이브의 추상적 또는 계층화된 신원이 또한 제시되는데 이는 엔클레이브의 신원을 엔클레이브의 콘텐츠의 단일 바이너리(binary) 또는 단일 해시(hash)를 넘어서 추상화한다. 추상화 모델 프리미티브를 사용하여 엔클레이브 및 엔클레이브 클라이언트 프로그램의 개발을 위해 소프트웨어 컴포넌트 인터페이스, 예컨대 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API) 또는 애플리케이션 바이너리 인터페이스(Application Binary Interface: ABI)가 제시된다.

추상적 신원은 엔클레이브 인스턴스의 그룹을 보안적으로(securely) 식별하는 데에 사용될 수 있는 내포형(nested) 신원 또는 신원 계층구조(hierarchy)를 포함할 수 있다. 본 문서에서의 엔클레이브 인스턴스(enclave instance)는 동일한 머신(machine) 상에서 엔클레이브 내에 로딩된 동일한 엔클레이브 바이너리 코드를 지칭하며 동일한 신원을 가질 수 있다. 반면에, 바이너리 코드의 새로운 버전, 또는 상이한 머신 상으로 로딩된 동일한 바이너리 코드는 상이한 인스턴스로 간주될 수 있다. 이들 상이한 인스턴스는 또한 신원 계층구조 내의 더 높은 수준에서 동일한 신원을 가질 수 있다. 추상화된 엔클레이브 신원은 관련된 엔클레이브 바이너리의 그룹으로 하여금 관련된 것으로 식별될 수 있게 한다. 예를 들어, 동일한 엔클레이브의 상이한 버전, 예컨대 버그(bug)가 고쳐지기 전 및 고쳐진 후의 엔클레이브 바이너리의 버전에는, 버전과는 관계없이, 동일한 명칭이 주어질 수 있다. 추상화의 더 높은 계층에서, 엔클레이브의 계통(family) 내의 모든 엔클레이브에는 단일의 계통 명칭 또는 신원이 주어질 수 있다. 이 경우에, 관련되지만 상이한 기능을 수행하는 모든 엔클레이브는 함께 식별될 수 있다. 다른 신원 계층 또는 신원의 그룹화가 아래에서 기술된다.

추상적 신원의 임의의 계층은 다양한 암호학적 동작, 예컨대 데이터를 실링하는 것, 엔클레이브의 증명, 또는 (단조 카운터를 통해) 데이터 선도를 보장하는 것을 위해 사용될 수 있다. 예를 들어, 하나의 엔클레이브 인스턴스에 의해 산출된 데이터를 상위 수준 신원에 실링함으로써, 그러고 난 이후에 그 데이터는 동일한 상위 수준 엔클레이브 신원을 가진 상이한 엔클레이브 인스턴스에 의해 보안적으로 소비될(consumed) 수 있다. 데이터를, 예를 들어, 엔클레이브 계통에 실링함으로써, 그 계통의 멤버(member)인 임의의 엔클레이브 인스턴스는, 또 그 계통의 멤버만이, 데이터를 실링해제할 수가 있을 것이다. 엔클레이브 인스턴스로부터의 계통 신원(family identity)에 대한 증명은 엔클레이브 인스턴스가 그 계통의 멤버라는 보증을 제공한다. 신원 추상화에 결부된 단조 카운터는 추상화 신원의 멤버인 모든 엔클레이브 인스턴스에 관련된 선도 보증을 제공할 수 있다.

개시된 추상화 모델은 엔클레이브 및 엔클레이브 호스트의 소프트웨어 개발을 단순화할 수 있는, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface: API) 또는 애플리케이션 바이너리 인터페이스(Application Binary Interface: ABI)와 같은 소프트웨어 컴포넌트 인터페이스를 포함한다. API는 소프트웨어를 창출하기 위한 프로그래밍 서브루틴 정의, 프로토콜 및 도구(tool)의 세트이다. API는 소프트웨어 컴포넌트의 입력 및 출력, 소프트웨어 컴포넌트에 의해 사용되는 데이터 타입, 그리고 소프트웨어 컴포넌트의 기능 또는 동작을 소프트웨어 컴포넌트의 임의의 특정한 구현에 관계없이 정의할 수 있다. API는 C, C++, C# 및 유사한 것과 같은 고수준 컴퓨터 언어로 정의될 수 있다. API의 정식화된 정의는 소프트웨어 컴포넌트, 예를 들어 다른 시간에 또는 다른 저자에 의해 작성된 두 소프트웨어 컴포넌트 간의 상호작용을 가능하게 할 수 있다. API는 인터페이스 서술 언어(Interface Description Language: IDL), 예컨대 마이크로소프트 인터페이스 정의 언어(Microsoft Interface Definition Language: MIDL) 또는 오브젝트 관리 그룹(Object Management Group: OMG) IDL로써 부분적으로 정식화될 수 있다. ABI도 소프트웨어 컴포넌트 간의 인터페이스이나, 오브젝트 코드 인터페이스(object code interface)이다. 예를 들어, ABI는 진입점(entry point)이 콜되는(called) 경우에 인자(argument)를 유지하는 머신 레지스터(machine register)를 지정하는 프로토콜과 같은, 그 진입점을 사용하기 위한 프로토콜과 더불어 API의 소스 코드 구현을 컴파일하는 것에서 기인하는 오브젝트 코드의 진입점(또는 명령어 주소)이다.

위에서 기술된 바와 같은 엔클레이브 신원의 상이한 수준으로써 상호작용을 가능하게 하는 것에 더하여, 엔클레이브 API는 엔클레이브 플랫폼 아키텍처 간의, 예를 들어 Intel의 소프트웨어 가드 확장(Software Guard Extensions: SGX), Microsoft의 가상 보안 모드(Virtual Secure Mode:VSM) 및 ARM 트러스트존(TrustZone), AMD의 보안 암호화된 가상화(Secure Encrypted Virtualization: SEV)에 의해 제공되는 보안 격리 실행(secure isolated execution)을 위한 아키텍처 및 필드 프로그램가능 게이트 어레이(Field Programmable Gate Array: FPGA)에 기반한 아키텍처 간의 차이를 추상화해버릴 수 있다. API는 추상화된 엔클레이브 아키텍처의 몇몇 세부사항을 추상화하는 엔클레이브 플랫폼을 위한 인터페이스를 포함한다. 이들 엔클레이브 플랫폼 인터페이스는 엔클레이브 호스트 API, 엔클레이브 플랫폼 API 및 원격 증명 API를 포함한다. 엔클레이브 호스트 API는 엔클레이브로의 그리고 엔클레이브로부터의 통신을 제공함은 물론 엔클레이브의 라이프사이클을 관리하기 위하여 비신뢰 호스트 프로세스(untrusted host process)에 의해 사용될 수 있다. 엔클레이브 플랫폼 API는 신뢰 엔클레이브 플랫폼(trusted enclave platform)에 의해 엔클레이브에 제공될 수 있고, 메모리 관리 및 쓰레드 스케줄링(thread scheduling)과 같은 코어 런타임 지원(core runtime support)뿐만 아니라, 엔클레이브 컴퓨터를 호스팅하는(host) 컴퓨터 상에서 가동되는 비신뢰 코드와의 통신과, 실링과, 증명을 위한 보안 프리미티브를 포함할 수 있다. 원격 증명 API는 원격 증명을 수행하는 데에 사용될 수 있는데, 엔클레이브 및 그것의 클라이언트는 동일한 컴퓨터 상에서 호스팅되지 않는다. 예를 들어, 원격 증명 API는 원격 컴퓨터 상에서 엔클레이브 플랫폼에 의해 제공되는 격리 하에서 가동되는 어떤 신원을 갖는 엔클레이브로부터 데이터가 유래하였음(또는 발신되었음)을 확인하기 위해 로컬 클라이언트에 의해 사용될 수 있다. 더욱 일반적으로 원격 증명 API는 로컬 클라이언트 및 원격 엔클레이브 간의 보안 통신 채널을 수립하는 데에 사용될 수 있다.

엔클레이브는 일반적으로 컴퓨터 기술의 부문에 특유한, 그리고 이로부터 생기는 문제점에 대한 해결안을 제공한다. 더욱 구체적으로, 엔클레이브는 신뢰되는 코드를 비신뢰 코드로부터 분리하기 위한 메커니즘을 제공하는데 신뢰되는 코드 세그먼트와 신뢰되지 않는 코드 세그먼트 양자 모두는 단일 컴퓨터 프로세서의 주소 공간(address space) 내에 주재한다. 예를 들어, 엔클레이브는 민감하거나 사적인 데이터를 액세스하여야 하는 코드와 동일한 일반 목적 컴퓨터 상에서 가동되는 잠재적으로 신뢰되지 않는 코드(예컨대 버그든 또는 바이러스(virus)든 잠재적으로 포함하는 코드)의 문제점에 대한 보안 해결안을 제공한다. 이 개시의 실시예는 컴퓨터 기술의 부문으로부터 생기는 그러한 보안 문제점에 대한 더욱 개선된 해결안을 제공하는데, 다음을 포함한다: 단일 엔클레이브 또는 엔클레이브 클라이언트가 다수의 네이티브 엔클레이브 플랫폼을 위해 작성될 수 있게 함으로써 소프트웨어 개발을 단순화하는 것; 특정한 컴퓨터의 구체적 하드웨어 특징에 맞춤화되어야(customized) 하는 소프트웨어 컴포넌트의 수를 줄임으로써 기업 컴퓨터 관리를 단순화하는 것; 그리고 다수의 컴퓨터 상에서 호스팅되는 엔클레이브에 걸쳐서 보안 엔클레이브 처리를 분산하는 것과 같은, 분산 데이터 실링으로써 새로운 보안 컴퓨팅 시나리오를 가능하게 하는 것.

도 1은 몇몇 신뢰 관계와 더불어 엔클레이브 시스템의 고수준 블록도를 묘사한다. 엔클레이브 시스템(100)은 엔클레이브(176)(혹은 엔클레이브 컨테이너 또는 보안 실행 환경으로 칭해짐)를 포함하는데, 이는 코드(180) 및 데이터(182)를 포함하는 메모리의 보안 격리 영역을 포함한다. 코드(180)는 공용(public) 또는 사적(private)일 수 있고, 데이터(182)는 공용 또는 사적일 수 있다. 예를 들어, 사적 데이터 또는 코드는 데이터 소유자(142)에게 속할(또는 사적일) 수 있는 한편, 공용 데이터 또는 코드는 소프트웨어 제공자(148)와 같은 다른 당사자에 의해 제공되었을 수 있다. 하나의 실시예에서, 엔클레이브 컨테이너(176) 내에서 가동되는 코드가 완전히 공용이며 사적이지 않을 수 있는 한편, 공용 엔클레이브 코드가 입력으로서 사용하거나 출력으로서 산출하는 데이터가 사적일 수 있다. 다른 실시예에서, 반대도 가능한데, 코드는 사적인 한편 데이터는 공용이다. 또 다른 실시예에서, 코드 및 입력 데이터 양자 모두가 공용일 수 있는 한편, 입력 데이터로써 코드를 가동하는 것의 출력은 사적일 수 있다. 코드, 입력 데이터 및 출력 데이터의 다른 공용 및 사적 조합이 가능하다.

엔클레이브(176) 컨테이너는 비신뢰 소프트웨어(untrusted software)(174)를 동시에 호스팅할 수 있는 신뢰 하드웨어(trusted hardware)(172) 상에서 호스팅된다. 엔클레이브 시스템(100)의 주 목적은 다음으로 이루어진 리스트로부터 선택된 적어도 하나의 양상을 포함할 수 있다: 코드(180)의 무결성을 유지하는 것, 코드(180)의 기밀성을 유지하는 것, 데이터(182)의 무결성을 유지하는 것, 그리고 데이터(182)의 기밀성을 유지하는 것. 비신뢰 소프트웨어(174)(가령, 비신뢰 소프트웨어에의 노출, 비신뢰 소프트웨어에 의한 수정, 또는 유사한 것)로부터 엔클레이브(176)의 콘텐츠를 보호하는 것이 목표일 수 있다. 신뢰 하드웨어가 제조자(162)에 의해 구축되고, 인프라스트럭처 소유자(152)에 의해 소유되고 관리된다.

엔클레이브 클라이언트(104)는 엔클레이브(176)가 코드(180) 및 데이터(182)로써 그것의 계산을 수행하는 엔클레이브 컨테이너 외부의 프로세스 또는 프로그램일 수 있다. 로컬 엔클레이브 실시예에서, 엔클레이브 클라이언트(104)는 또한 신뢰 하드웨어(172) 상에서 가동되고 있을 수 있다. 원격 엔클레이브 실시예에서, 엔클레이브 클라이언트는 하나의 컴퓨터 상에서 가동될 수 있는 한편 신뢰 하드웨어(172)는 네트워크를 통해 엔클레이브 클라이언트의 컴퓨터에 연결된 상이한, 원격 컴퓨터이다. 로컬 엔클레이브 경우에, 엔클레이브 클라이언트 프로세스가 로컬 엔클레이브(176)의 생성을 관리할 수 있다는 점에서 엔클레이브 클라이언트 프로세스는 또한 엔클레이브 컨테이너(176)의 엔클레이브 호스트 프로세스일 수 있다. 원격 엔클레이브 경우에, 엔클레이브(176)는, 예를 들어, 인터넷 클라우드 컴퓨터 상에서 가동될 수 있는데 인프라스트럭처 소유자(152)가 클라우드 컴퓨팅 서비스 제공자이고, 클라우드 컴퓨터는 제조자(162)에 의해 제조된 신뢰 하드웨어(172)를 포함한다.

엔클레이브 클라이언트(104)는 엔클레이브(176)에 의한 요청된 계산을 셋업하는(setup) 셋업(106) 방법을 포함할 수 있다. 셋업(106) 방법은 엔클레이브(176)의 보안 컨테이너의 생성을 유발하는 것, (예를 들어, 엔클레이브의 인스턴스화를 청하기 위해 비신뢰 소프트웨어(174)에 요청을 발신함으로써) 엔클레이브의 인스턴스화를 유발하는 것(이는 보안 컨테이너 내에 바이너리 코드를 복사하는 것을 포함할 수 있음), 그리고, 예를 들어 보안 컨테이너 내에 복사된 코드 내의 메쏘드(method)를 콜함으로써, 엔클레이브 내의 계산을 유발하거나 요청하는 것. 요청된 계산은 코드(180)를 실행하는 것을 포함할 수 있고, 데이터(182)는 요청된 계산에 입력될 수 있거나, 요청된 계산의 결과일 수 있다. 요청된 계산에 입력된 데이터는 엔클레이브 외부에 있을 때 암호화될(encrypted) 수 있고, 암호화된 입력 데이터는 엔클레이브 내부에서 사용되기 전에 복호화될(decrypted) 수 있다. 일단 엔클레이브(176)가 요청된 작업을 완료하면, 작업의 결과를 나타내는 데이터가 암호화되고 엔클레이브 클라이언트(104)에 도로 발신된다. 엔클레이브 클라이언트(104)가 암호화된 결과를 수신하는 경우에, 확인(108) 방법은 수신된 결과의 무결성 및 선도를 확증할(confirm) 수 있다. 단일 소프트웨어 제공자(148)는 엔클레이브(176) 내부에서 가동할 코드(180)도, 또 엔클레이브 클라이언트(104)의 일부로서 가동되는 확인(108) 방법의 적어도 일부분도 제공할 수 있다.

엔클레이브(176)에 의해 산출된 결과의 정확성에 대한 확신뿐만 아니라, 코드(108)의 사적 부분 및 데이터(182)의 사적 부분의 프라이버시(privacy)에 대한 데이터 소유자의 확신은, 신뢰 관계에 기반할 수 있다. 예를 들어, 데이터 소유자(142)는 엔클레이브 클라이언트(104)를 신뢰할 수 있는데, 이는 엔클레이브 컨테이너 그 자체 내에서 가동되고 있지 않을 수 있다. 데이터 소유자는 엔클레이브 그 자체의 소프트웨어 제공자(148)를 또한 신뢰할 수 있다. 그리고 데이터 소유자는 신뢰 하드웨어(172)의 제조자를 신뢰할 수 있다. 신뢰 하드웨어(172)는 사용된 엔클레이브 아키텍처에 따라서 많은 형태를 취할 수 있고, 하드웨어 보안 모듈(Hardware Security Module: HSM)을 포함할 수 있는데, HSM은, 예를 들어, 신뢰 플랫폼 모듈(Trusted Platform Module: TPM) 표준에 부합한다. 신뢰 하드웨어(172)는, 예를 들어, TPM을 포함할 수 있고 그렇지 않으면 오직 하드웨어를 포함할 수가 있다. 예를 들어, Microsoft의 VSM 엔클레이브 아키텍처를 사용한 신뢰 하드웨어(172)의 구현은 TPM 및 운영 체제 가상화 명령어를 위한 명령어를 가진 상용 프로세서(commodity processor)를 포함할 수 있다. Microsoft의 VSM 엔클레이브 아키텍처는 게스트 파티션(guest partition)(가상 프로세서)를 관리하기 위한 하이퍼바이저(hypervisor)를 포함할 수 있고, 하이퍼바이저는 게스트 파티션이 하이퍼바이저와 상호작용할 수 있도록 하기 위하여 하이퍼콜(hypercall) 인터페이스를 게스트 파티션에 노출시킬 수 있다. Microsoft의 VSM 아키텍처 내의 엔클레이브 컨테이너는 특수 타입의 게스트 파티션으로서 구현될 수 있다. Intel의 SGX 엔클레이브 아키텍처를 가진 신뢰 하드웨어(172)의 예는 보안 기능 및 특수한 엔클레이브 특정적 명령어를 가진 프로세서를 포함할 수 있다.

엔클레이브, 예컨대 엔클레이브(176)는 코드 또는 데이터, 예컨대 코드(180) 및 데이터(182)를 보호할 수 있는 격리 실행 환경을 제공할 수 있으니, 메모리의 영역을 그런 보호된 영역으로부터의 읽기, 쓰기 또는 실행하기에 대한 제한과 함께 제공함에 의해서이다. 이 보호된 메모리 영역은 기밀성 코드 및 데이터를 위한 보안 컨테이너이다. 엔클레이브의 보호된 메모리 영역으로부터 실행하는 것에 대한 제한은 엔클레이브 외부의 코드에서 엔클레이브 내부의 코드로 및 반대로 그 사이의, 콜(call) 또는 점프(jump) 명령어와 같은, 실행 전이(execution transfer)에 대한 제한을 포함할 수 있다. 엔클레이브 외부로부터 엔클레이브 내로 콜인하는 것 및 엔클레이브 내부로부터 엔클레이브 밖으로 콜아웃하는 것 간에 상이한 제한이 시행될 수 있다. 엔클레이브 내부 및 외부 간의 이들 실행 전이의 시행은, 예를 들어 상용 가상화 하드웨어 기술을 가진 또는 Intel의 SGX 플랫폼과 같은 특제 하드웨어를 가진 하드웨어에 의해 제공될 수 있다.

도 2는 기밀성 보장이 있는 메시지 통과를 위한 예시적인 프로세스(200)를 묘사한다. 기밀성 보장은 두 당사자, 예컨대 이 예에서 앤(Anne)(210) 및 벤(Ben)(230) 간의 통신은, 네트워크(218)와 같은 공용 또는 비보호(unprotected) 통신 매체를 통해서 메시지가 전해지는 경우에 제3자로부터 은닉된 채 있다는 어떤 수준의 보증을 제공한다. 이 예에서, Anne(212)은 기밀성 메시지를 Ben(230)에게 발신하기를 바란다. 기밀성 데이터를 포함하는 메시지 블록(212)은 암호화(214) 동작에 의해 공개 키(public key)(216)를 사용하여 암호화된다. 암호화(214) 동작은, 예를 들어, 고급 암호화 표준 갈로와/카운터 모드(Advanced Encryption Standard Galois/Counter Mode: AES-CGM)일 수 있으나, 디지털 암호법의 당업자에게 알려진 임의의 암호화 동작일 수도 있다. 암호화된 블록(220)은 네트워크(218)를 거쳐 Ben에게 갈 수 있는데 암호화된 블록(234)은 Ben을 위한 암호화되지 않은 메시지 블록(232)을 산출하기 위해 개인 키(private key)(23)로써 복호화된다. 키 및 암호화 알고리즘의 신중한 선택으로써, 컴퓨터 데이터 암호화의 업계에서 알려진 바와 같이, 메시지는 공용 네트워크를 통과하는 경우에도 기밀성 있는 채로 남아 있을 수 있다.

도 3은 무결성 보장이 있는 메시지 통과를 위한 예시적인 프로세스(300)를 묘사한다. 무결성 보장은 두 당사자, 예컨대 이 예에서 Anne(310) 및 Ben(350) 간의 통신은, 네트워크(340)와 같은 공용 또는 비보호 통신 매체를 통해서 메시지가 전해지는 경우에 변조된 또는 아니면 기타 바뀐 것이 아니라는 어떤 수준의 보증을 제공한다. 도 3의 예에서, Anne(310)은 Ben(350)에게 메시지(314)를 발신하는바 Ben(350)이 그것을 수신하는 경우에 메시지(314)가 변조된 또는 아니면 와전된(corrupted) 것이 아니라는 확신이 있다. 이 무결성 보장을 제공하기 위하여, 보안 해싱(secure hashing)(316) 프로세스가 메시지(314)에 대해 동작하여 해시 값(318)을 산출한다. 그러면 해시 값(318)은 시그니처(signature)(342)를 산출하기 위해 Anne의 개인 키를 사용하여 서명(320) 프로세스에 의해 서명된다. 시그니처(342)는 메시지(344)로서의 메시지(314)의 복사와 더불어 공용 네트워크(340) 또는 다른 비보호 통신 프로세스를 가로질러 발신될 수 있다. 그러면 Ben은 Ben이 무결성을 확인하기를 바라는 메시지(354)를 수신하는바, Ben은 메시지가(354)가, 비신뢰 네트워크(340)를 거쳐 간 후에 Anne이 발신한 메시지(314)와 동일하다는 확신을 가질 수 있다. 무결성을 확인하기 위하여, 수신된 메시지(354)는 해시 값(358)을 산출하는 보안 해싱(316)과 동일한 보안 해싱(356)에 의해 처리된다. 수신된 시그니처(342)는 Anne의 공개 키를 사용하여 시그니처 확인(360) 프로세스에 의해 확인된다. 시그니처(342)로부터 추출된 해시 값(318)은 시그니처가 동일함을 확인하기(380) 위하여 이후에 해시 값(358)과 비교된다. 그것들이 동일한 경우, 메시지는 무결성을 갖는 것으로서 받아들여진다(384). 혹은, 메시지(314)가 메시지(354)로서 수신되기 전에 어떤 식으로든 바뀌었다면, 시그니처는 정확하지 않을 것이며 메시지는 거부될 것이다(388).

몇몇 실시예에서, 보안 해싱(316) 및 보안 해싱(356)은 암호학적 해시 함수(cryptographic hash function)일 수 있다. 암호학적 해시 함수는 임의적인 크기의 데이터를 (전형적으로 훨씬 더 작은) 고정된 크기의 비트 스트링(bit string)으로 맵핑하는 일방향(one-way) 함수이다. 해시 함수의 출력은 해시 값 또는 간단히 해시라고 불릴 수 있다. 좋은 해시 함수는 해시 출력만 주어지면 임의적 크기로 된 입력을 판정하기가 어려울 것이라는 점에서 일방향일 것이다. 좋은 해시 함수로써, 입력에서의 작은 변화조차도 출력에서의 변화를 산출할 것이다.

통신 시스템은 기밀성 및 무결성 보증을 조합할 수 있다. 예를 들어, 도 2의 메시지 블록 암호화는 도 3의 메시지 해시의 서명과 조합될 수 있다. 조합 시스템은 공개/개인 키 쌍의 두 세트를 요구할 수 있는데, 하나는 발신기를 위한 것이고 하나는 수신기를 위한 것이다. 조합 시스템은 메시지를 복호화하기 위해 수신기에서 하나의 개인 키(도 2에서와 같이 Ben의 개인 키)를 사용할 수 있는 반면, 메시지 해시를 서명하기 위해 다른 개인 키(도 3에서와 같이 Anne의 개인 키)를 사용한다.

도 4는 선도 보장이 있는 메시지 통과를 위한 예시적인 프로세스(400)를 묘사한다. 선도 보장은 하나의 당사자로부터 다른 당사자로, 예컨대 이 예에서 Anne(410)으로부터 Ben(450)으로 여러 메시지가 발신되는 경우에, 수신기에서 수신된 메시지는 가장 최근의 메시지라는 어떤 수준의 보증을 제공한다. 선도 보장은 무결성 보장에 기해 구축될 수 있고, 재전송 공격(replay attack)을 방지할 수 있다. 무결성 보장으로써, 불법적인 의도를 가진 제3자가 그 자신의 메시지를 생성하고 Ben이 메시지를 Anne에 의해 생성되었다고 이해하도록 그것을 Ben에게 발신하기는 어렵다. 그러나, 제3자는 Anne에 의해 실제로 생성된 메시지(아마도 그것이 공용 네트워크를 통하여 발신되었을 한때에 관측됨)를 취할 수 있고, 제3자는 그것을 다른 후제에 Ben에게 재발신할 수 있다(즉 메시지를 재전송함). Ben은 메시지가 Anne에 의해 실제로 생성되었음을 (그것이 그러하기 때문에) 판정할 것이나, Ben은 Anne이 그때에 그것을 발신한 사람이 아니라는 것을 알지 못할 것이다. 이것은 제3자에 의한 Ben 또는 Anne에 대한 재전송 공격이라고 불릴 수 있다. 도 4는 논스(nonce) 및 타임스탬프(timestamp)를 사용하여 선도 보장을 제공함으로써 재전송 공격을 방지하기 위한 예시적인 해결안이다. 논스는 일회용(single-use) 난수(random number)인데, 동일한 수가 한 번 넘게 논스로서 결코 사용되지 않음을 보장하기 위한 시스템과 커플링된다(coupled). 몇몇 시스템에서 논스는 단순히 단조 증가하는(monotonically increasing) 수일 수 있는바, 사용된 수 하나하나는 그것 전에 나온 모든 수보다 더 크다.

도 4에서, Anne의 메시지(414)는 논스(434) 및 타임스탬프(432)와 더불어 메시지(436)로서 공용 네트워크(430)를 통하여 발신될 수 있다. 논스(434)는 암호학적 보안 의사난수 생성기(Cryptographically Secure PseudoRandom Number Generator: CSPRNG)(426)에 의해 생성되고, 타임스탬프(432)는 동기화된 클록(clock)(425)에 의해 산출된다. 디지털 암호법의 당업자에게 알려진 많은 CSPRNG 시스템이 있다. 네트워크(430)의 Anne 측의 동기화된 클록(424)은 네트워크의 Ben 측의 동기화된 클록(480)과 동기화된다. Ben 측에서, 메시지(454)가 수신된 경우에, 동반된 논스(434)는 최근의 논스(470)의 캐시(cache) 내에 저장된다. 그 수신된 메시지(450)의 선도는 두 테스트로써 확인될 수 있다. 첫째, 논스(434)는 박스(460)에서 테스트되는데 현재 수신된 논스(434)가 전에 보였는지를 판정하기 위하여 논스(434)를 최근의 논스(470)의 캐시와 비교함에 의해서이다. 수신된 논스(434)가 전에 보였던 경우, 박스(468)에서 메시지(454)는 재전송 메시지로서 거부된다. 수신된 논스(434)가 전에 보이지 않았던 경우, 이 첫 번째 테스트에 대해 박스(464)에서 메시지는 OK라고 판정된다. 둘째, 수신된 타임스탬프(432)가 로컬의 동기화된 클록(490)과 비교된다. 타임스탬프가 최신인 경우, 박스(494)에서 메시지(454)는 수락가능(acceptable)하다고 판정되고, 그렇지 않은 경우 박스(498)에서 메시지(454)는 만료된(expired) 것으로서 거부된다. 박스(490)에서 최근의 타임스탬프가 최신인지를 판정하는 경우에 용인되는 지연의 양은 동기화된 클록(424) 및 동기화된 클록(480) 간의 예상되는 클록 스큐(clock skew) 및 메시지 처리 및 네트워크(430)를 통한 송신에서의 시간 지연에 의존할 수 있다.

통신 시스템은 도 2에서와 같은 기밀성 보장과, 도 3에서와 같은 무결성 보장 어느 한쪽이든 또는 양자 모두와 선도 보장을 조합할 수 있다. 셋 모두를 조합하는 시스템에서, 네트워크(430)를 통하여 발신된 메시지(436)는 Anne의 원래의 메시지(414)의 암호화된 버전일 것이고, 메시지(414)의 서명된 해시를 포함하는 시그니처는 타임스탬프(432), 논스(434) 및 메시지(436)와 함께 포함될 것이다.

도 5는 엔클레이브의 소프트웨어 증명을 위한 예시적인 프로세스(500)를 묘사한다. 소프트웨어 증명은, 키 합의 프로토콜(key agreement protocol), 예컨대 도 6의 키 합의 프로토콜과 조합된 경우, 그것이 신뢰 하드웨어에 의해 생성된 격리된 컨테이너 내부에서 호스팅되는 소프트웨어의 특정 부분으로써 공유 시크릿(shared secret)을 수립하였음을 확인자(verifier)에게 보증할 수 있다. 도 5의 실시예에서, 엔클레이브 클라이언트(510)(증명 확인자)는 신뢰 플랫폼(530) 상에서 엔클레이브의 보안 계산 서비스를 사용하기를 희망할 수 있다. 신뢰 플랫폼(530)은 컴퓨터(도시되지 않음) 상에서 호스팅되어서 신뢰 플랫폼(530)은 호스팅 컴퓨터의 서브세트를 포함할 수 있다. 신뢰 플랫폼(530)은 호스팅 컴퓨터의 하드웨어 요소 및 소프트웨어 요소를 포함할 수 있다. 엔클레이브는 보안 엔클레이브 컨테이너(536) 및 그것의 내부의 코드 및 데이터, 예컨대 공용 코드 및 데이터(538) 및 비밀 코드(secret code) 및 데이터(542)를 포함한다.

예시적인 프로세스(500)에서 3개의 프로세스가 조합된다: 공유 키(shared key)(SK)를 산출하는 키 교환 프로세스; 신뢰 플랫폼(530) 상의 엔클레이브의 엔클레이브 클라이언트(510)에 대한 증명을 위한 증명 프로세스; 그리고 보안 계산이 행해짐. 제1 프로세스로부터의 공유 키(SK)는 보안 계산의 입력 및 출력을 통신하기 위해 사용된다. 키 교환에서, 엔클레이브 클라이언트는, 예를 들어 도 6의 디피-헬만 키 교환(Diffe-Hellman Key Excahnge: DKE) 프로토콜에 대해 아래에서 기술되는 바와 같이, 엔클레이브의 개인 키 A 및 생성기 함수 g로부터 g^A(박스(512)에서 저장됨)를 계산한다. 계산된 g^A는 이후 메시지(520) 내에서 신뢰 플랫폼(530)에 발신된다. 메시지(520)는 암호화 없이, 그리고 증명이 완료되기 전에, 안전하게 발신될 수 있다. 보안 엔클레이브 컨테이너(536) 내부의 소프트웨어는 동일한 생성기 함수 g를 사용하여 g^B를 계산하는 데에 엔클레이브 개인 키 B를 사용할 수 있다. 박스(540)에서 B 및 g^B 양자 모두가 엔클레이브 컨테이너 내에 저장될 수 있다.

(보안 엔클레이브 컨테이너(536) 내부에서 어떤 코드가 가동되는지에 대한 보증을 제공하기 위하여) 엔클레이브의 신원을 증명하기 위하여, 증명 메시지(522)가 엔클레이브 클라이언트(510)에 발신된다. 증명 메시지는 도 3에서와 같이 무결성을 위해 서명된 특수 메시지일 수 있다. 특수 메시지는 엔클레이브에 대한 신원 정보를 포함할 수 있다. 도 5의 실시예에서와 같이 DKE와 조합된 경우, 특수 메시지는 키 교환 파라미터를 또한 포함할 수 있다. 도 5의 실시예에서, 보안 엔클레이브 컨테이너(536)가 가진, 공용 코드 및 공용 데이터의 초기 상태(initial state)(538)는 엔클레이브 신원으로서 사용되는데, 다만 다른 신원이 가능하다. 증명 메시지 내에 전체 초기 상태(538)를 발신하는 것말고, 초기 상태의 해시 M = Hash(Initial State)가 대신 발신된다. 증명 메시지(522)는 메시지 콘텐츠(M 및 g^B)와, 메시지 콘텐츠의 시그니처(Sign_AK(Hash(g^B), M))를 포함한다. 메시지 콘텐츠의 시그니처는, 예를 들어, 보안 엔클레이브 컨테이너(536) 내부의 소프트웨어가 계산된 g^B의 해시 및 엔클레이브의 신원을 증명할 것을 엔클레이브를 호스팅하는 신뢰 플랫폼(530)에 청함으로써 생성될 수 있다. 신뢰 플랫폼(530)은 Sign_AK(Hash(g^B), M)을 산출하기 위하여 플랫폼 증명 키(Attestation Key: AK)(532)를 사용하여 시그니처를 제공함으로써 그것을 행할 수 있다. 이 예에서, 엔클레이브 신원은 초기 상태(38)의 해시 M이나, 다른 신원 표현(identity statement)이 가능하다. 이 증명 시그니처 Sign_AK(Hash(g^B), M)은 값 g^B를 엔클레이브 신원 M에 바인딩하고(bind) g^B 및 M 양자 모두를 신뢰 플랫폼(530)에 또한 바인딩한다. 이후 엔클레이브 클라이언트(510)는 증명 시그니처 및 엔클레이브 신원을 확인함으로써 증명 메시지를 확인할 수 있다. 시그니처는 증명 키(Attestation Key: AK)에 대응하는 공개 키를 사용하여 도 3에서와 같이 확인될 수 있다. 시그니처를 확인하는 것은 증명 메시지 내의 엔클레이브 신원의 무결성 보장을 제공할 수 있다. 엔클레이브 신원은 증명 메시지 내의 신원 정보를 독립적으로 알려진 신원 값과 비교함으로써 확인될 수 있다. 예를 들어, 증명 메시지 내의 신원 정보가 엔클레이브의 초기 상태의 해시인 경우, 엔클레이브 클라이언트(510)는 초기 상태의 해시를 알 수 있거나, 알려진 초기 상태로부터 그러한 해시를 계산하는 것이 가능할 수 있고, 이후 이 값은 증명 메시지 내에서 제공되는 신원 값과 비교될 수 있다.

공유 키(Shared Key: SK)를 산출하기 위하여, 엔클레이브 클라이언트(510) 및 보안 컨테이너(536) 내부의 코드 양자 모두는 공유 키(Shared Key: SK)로서의 역할을 할 수 있는 g^AB(A 곱하기 B라는 곱에 적용된 생성기 함수 g)를 생성할 수 있다. 공유 키(Shared Key: SK)는 엔클레이브 클라이언트(510) 및 엔클레이브 간의 기밀성을 위해 메시지를 암호화하기 위해, 예를 들어 엔클레이브 컨테이너(536) 내부의 코드에 입력 데이터를, 그리고 이로부터 출력 데이터를 발신하기 위해, 사용될 수 있다. 엔클레이브든 또는 엔클레이브든 다른 이의 개인 키를 알지 않고서 박스(540 및 514)에서 통신 채널의 각 측에서 독립적으로 공유 키가 산출된다는 점에 유의한다. 예를 들어, 도 5의 실시예에서, 비밀 코드 및 데이터는 이전에 수립된 공유 키(Shared Key: SK)로써 비밀 코드 및 데이터를 암호화하여, Enc_SK(secret code/data)를 신뢰 플랫폼(530)에 메시지(524)에서 그것을 발신하기 전에 산출함으로써 엔클레이브 클라이언트(510)에 의해 보안적으로 제공될 수 있다. 다른 실시예에서, 보안 엔클레이브 컨테이너(536) 내에서 실행되거나 이에 의해 사용되는 비밀 코드 및 데이터(542)는 다른 위치로부터 유래할 수 있다. 보안 계산은 계산 결과(544)를 산출하기 위하여 비밀 코드 및/또는 데이터(542)를 사용하여 보안 엔클레이브 컨테이너(536) 내부에서 수행될 수 있다. 이후 계산 결과(516)는 결과를 메시지(526) 내에서 엔클레이브 클라이언트에 그것을 발신하기 전에 공유 키(Shared Key: SK)로써 암호화함으로써(Enc_SK(results)) 엔클레이브 클라이언트(510)에 도로 보안적으로 통신될 수 있다.

위에서 기술된 도 5의 프로세스는 엔클레이브 클라이언트에게, 그것이 어떤 신원의 "실제" 엔클레이브와 통신하고 있다는, 그리고 엔클레이브가 엔클레이브 플랫폼에 의해 보호된다는 보장을 제공한다. 그것은 엔클레이브 컨테이너 내부의 코드에게 통신 채널의 다른 측의 개체(entity)에 대해 어떤 보장도 제공하지 않는다. 대체 실시예(묘사되지 않음)에서, 엔클레이브 클라이언트에 대한 그러한 보장은 엔클레이브 그 자체로서 엔클라이브 클라이언트를 가동함으로써 제공될 수 있다. 이 대체 실시예에서, 엔클레이브 클라이언트는 g^A의 해시 상에서의 시그니처를 신뢰 엔클레이브 플랫폼에 청할 수 있는데, 이는 이후 다른 엔클레이브에 의해 확인될 수 있다.

증명은 로컬로 또는 원격으로 행해질 수 있다. 도 5에서, 엔클레이브 클라이언트(510)는 신뢰 플랫폼(530)과 동일한 컴퓨터 상에 주재할 수 있거나 그렇지 않을 수 있는바, 엔클레이브 클라이언트(510) 및 신뢰 플랫폼(530) 간의 통신은 (예를 들어 동일한 컴퓨터 상의 상이한 프로세스 간에 데이터 버퍼를 전함으로써) 단일 컴퓨터 내에서 발생할 수 있거나, 엔클레이브 클라이언트(510)를 신뢰 플랫폼(530)에 연결하는 컴퓨터 네트워크를 통하여 발생할 수 있다. 로컬 증명은 엔클레이브 클라이언트(510) 및 신뢰 플랫폼(530)이 동일한 로컬 컴퓨터 상에서 호스팅되는 경우에 수행될 수 있다. 로컬 증명의 아티팩트(artifact) 또는 결과는 증명 보고라고 불리며, 도 5의 예에서 Sign_AK(Hash(g^A), M)이다. 원격 증명은 엔클레이브 클라이언트(510) 및 신뢰 플랫폼(530)이 상이한 컴퓨터 상에서 호스팅되는 경우에 발생할 수 있다. 원격 증명의 아티팩트 또는 결과는 증명 인용(attestation quote)라고 불리는데, 이는 몇몇 경우에 로컬 증명 보고와 매우 유사하거나 동일할 수 있다. 다른 경우에 증명 인용은 인용을 제공하는 컴퓨터나 네이티브 플랫폼에 관련된 신뢰의 추가적인 아티팩트를 포함할 수 있다. 신뢰의 그러한 추가적인 아티팩트는 TPM과 연관된 TCG 로그와 같은 호스트 건전성 증서(host health certificate)를 포함할 수 있다. 엔클레이브의 증명은 엔클레이브의 신원의 임의의 계층 상에서 수행될 수 있다. 엔클레이브는 내포형 또는 계층구조형(hierarchical) 신원을 가질 수 있고, 신원의 더 높은 수준에 대한 증명은 인스턴스화된 엔클레이브가 신원 수준이 증가함에 따라 잠재적 엔클레이브 인스턴스화의 점진적으로 더 큰 그룹의 멤버임을 증명할 수 있다. 더 높은 수준은 더 낮은 수준의 잠재적 엔클레이브 인스턴스화의 수퍼세트(superset)에 대응할 수 있다. 신원의 예시적인 계층구조가 포함할 수 있는 것은, 최하위의, 가장 구체적인 수준으로부터 더 높은, 덜 구체적인 수준으로 다음일 수 있다: ExactHash, InstanceHash, ImagelD, FamilylD 및 AuthorlD.

엔클레이브의 신원은 엔클레이브의 보안 컨테이너 내에 로딩된 바이너리 파일(엔클레이브 바이너리)로부터 도출될 수 있다. 엔클레이브 바이너리는 그것의 작성자에 의해 작성자의 개인 키를 사용하여 서명될 수 있다. ExactHash 수준 증명에 있어서, 증명 보고를 계산하는 데에 사용되는 초기 상태(증명 보고를 산출하는 해시 함수로의 입력)는, 신뢰 플랫폼(530)과 연관된 바이너리를 제외하고, 보안 컨테이너(536) 내에 로딩된 매 바이너리 파일의 전체 콘텐츠를 포함할 수 있다.

InstanceHash 신원 수준에서의 증명은 초기 상태(538)의 서브세트를 포함할 수 있다. 서브세트는 보안 컨테이너(536) 내에 로딩된 엔클레이브 바이너리 파일(바이너리 파일)이 그 엔클레이브 바이너리 파일의 작성자에 의해 원래 서명되었던 때에 지정될 수 있다. 예를 들어, 제1 (또는 일차적(primary)) 엔클레이브 바이너리 파일은 제1 엔클레이브 바이너리 파일이 의존하는 다른 엔클레이브 바이너리 파일의 신원의 리스트를 포함할 수 있다. 나열된 각각의 신원에 대해, InstanceHash 증명 보고를 산출하기 위해 해시 함수에 의해 각각의 나열된 바이너리 파일이 측정된(measured) 것인지 여부를 나타내기 위하여 제1 바이너리 파일에 플래그(flag)가 포함될 수 있다.

엔클레이브 ID의 더 높은 수준에 대한 증명은 해시 함수를 통해서 어떤 엔클레이브 바이너리의 전체 콘텐츠를 가동하는 것도 포함하지 않을 수 있다. 대신에, ID의 데이터 구조만이 해시 함수를 통해 가동될 수 있다. 예를 들어, 엔클레이브 바이너리 파일은, 그 특정 엔클레이브 바이너리 파일에 고유한 이미지 ID(ImageID), 그 특정 엔클레이브 바이너리 파일을 포함하고 동일한 작성자에 의해 작성된 엔클레이브 바이너리 파일의 그룹에 고유한 계통 ID(FamilyID), 그리고 동일한 작성자에 의해 모두 작성된 엔클레이브 바이너리 파일의 계통의 그룹에 고유한 작성자 ID(AuthorID)를 나타내는, 보편적 고유 식별자(Universally Unique IDentifier: UUID)와 같은 상위 수준 엔클레이브 식별자의 리스트를 포함할 수 있다. ImageID, FamilyID 및 AuthorID는 엔클레이브 바이너리의 작성자에 의해, 바이너리가 원래 서명된 때에, 할당될 수 있다. 엔클레이브 클라이언트가 엔클레이브 바이너리를 액세스하고 작성자의 공개 키(또는 작성자와 연관된 공개 키)를 사용하여 그 바이너리들 상에서의 작성자의 시그니처를 확인할 수 있는 경우에 엔클레이브 신원의 스푸핑(spoofing)이 방지될 수 있다. 이는, 작성자에 의해 할당된 임의의 상위 수준 신원을 비롯하여, 엔클레이브 바이너리의 무결성을, 그 엔클레이브 작성자에 의해 생성된 것으로 확인한다.

도 6은 예시적인 디피-헬만 키 교환(Diffe-Hellman Key Exchange: DKE) 프로토콜(600)을 묘사한다. DKE는 오직 무결성 보장을 가진 통신 채널에 걸쳐서 공유 키 K를 수립하기 위한 하나의 예시적 프로세스인데; 디지털 암호법의 업계에서 알려진 공유 키를 생성하기 위한 다른 프로세스가 사용될 수 있다. 도 6의 DKE 예에서, 비밀 키(secrete key) K는, Anne(610) 및 Ben(650) 간의 공용 (비보안) 통신 매체를 통하여 결코 K를 명시적으로 통신하지 않고서, Anne(610) 및 Ben(650) 간에 공유된다. 프로세스가 시작하기 전에, 1) 큰 소수(prime number) p 및 2) Z p에서의 생성기 g가 수립되고 Anne 및 Ben 둘 모두가 알 수가 있다. 그러면 Anne 및 Ben 둘 모두가 1과 p 사이의 난수(random number)를 택하는 것으로 프로세스가 시작된다. Anne의 난수는 박스(612)에서 선택된 A이고, Ben의 난수는 박스(652)에서 선택된 B이다. 박스(614)에서 Anne은 g^A mod p를 계산하는 데에 그녀의 난수를 사용하고, 박스(656)에서 Ben에 의해 수신된 그 양을 박스(616)에서 송신한다. 박스(654)에서 Ben은 g^B mod p를 계산하는 데에 그의 난수를 사용하는데, 이는 박스(656)에서 Anne에게 송신되고 박스(618)에서 수신된다. 박스(620)에서 Anne은 공유 키 K를 (g^B mod p)^A = g^AB mod p로서 산출할 수 있고 박스(660)에서 Ben은 공유 키 K를 (g^A mod p)^B= g^AB mod p로서 산출할 수 있다. 중간자 공격(man-in-the-middle attack)을 방지하기 위해서, 박스(616 및 658)에서의 비보호 네트워크를 통한 Anne 및 Ben 간의 통신은 메시지 무결성 보장(예를 들어 도 3의 것과 같은 프로세스를 사용하여 생성됨)을 포함할 수 있다.

도 7은 소프트웨어 증명을 위한 예시적인 신뢰 체인(700)을 묘사한다. 소프트웨어 증명에서의 신뢰 체인은 도 5의 신뢰 플랫폼(530)과 같은 신뢰 플랫폼의 제조자가 소유한 서명 키(signing key)에 근본을 둘 수 있다. 신뢰 플랫폼은 보안 프로세서 또는 하드웨어 보안 모듈(Hardware Security Module: HSM)과 같은 하드웨어 컴포넌트를 포함할 수 있고, 따라서 제조자는 컴퓨터 하드웨어의 제공자일 수 있고 신뢰 플랫폼을 위한 소프트웨어를 또한 제공할 수 있다. 제조자는 확인자(702)에 의해 신뢰될 수 있고, 확인자는 제조자 루트 키(root key)(736)의 공개 키 PubRK(732)를 알 수 있다. 도 5의 엔클레이브 클라이언트(510)는 보안 컨테이너(708)에 대한 보증을 갖기를 희망할 수 있는 확인자(702)의 예이다. 제조자는 증서 인가기관으로서 행동하고 그것이 산출한 신뢰 플랫폼의 각 인스턴스(예를 들어 각 보안 프로세서)에 고유한 증명 키(722)(이는 증명 시그니처를 산출하는 데에 사용됨)를 제공할 수 있다. 제조자는 또한 각 증명 키(722)에 대해 승인 증서(endorsement certificate)(728)를 발행한다. 제조자 루트 키(736)는 승인 증서(728)를 서명하는 데에 사용되는 개인 키 PrivRK(734)를 포함한다. 승인 증서의 서명은, 예를 들어 도 3에 도시된 바와 같이, 무결성 보장을 제공한다.

승인 증서(728)는 증명 키(722)의 공개 키 PubAK(724)를 포함한다. 승인 증서(728)는 증명 키(722)가 소프트웨어 증명을 위해 사용될 것임을 나타낼 수 있고, 확인자(702)에게 통신될 수 있다. 확인자는 보안 컨테이너(708)의 증명을 확인하기를 희망하는 임의의 개체일 수 있는데, 예를 들어 확인자(702)는 보안 컨테이너(708) 내부에서 보안 계산이 행해지기를 희망하는 도 5의 엔클레이브 클라이언트(510)일 수 있다. 확인자(702)는 승인 증서의 무결성 및 기원(origin)을 확인하기 위하여 PubRK(732)를 사용하여 승인 증서를 점검할 수 있다. 확인자는 승인 증서로부터 PubAK(724)를 또한 추출할 수 있다. 승인 증서는 승인 정책과 연관될 수 있는데, 이는 증명 키(722)가 오직 증명 시그니처를 산출하는 데에 사용되는 것, 그리고 증명 키(722)의 개인 키 PrivAK(726)가 신뢰 플랫폼의 일반적으로 액세스가능한 컴퓨터 메모리와는 별개인 스토리지(storage) 내에, 예컨대 변조 억제 하드웨어(tamper-resistant hardware)(730)의 스토리지 내에, 배타적으로 유지될 것을 요구할 수 있다. 변조 억제 하드웨어는, 예를 들어, 신뢰 플랫폼 모듈(Trusted Platform Module: TPM) 표준에 부합하는 하드웨어일 수 있다.

보안 컨테이너(708)는 신뢰 플랫폼(736) 상에서 인스턴스화될 수 있다. 보안 컨테이너(708)의 인스턴스화는 비보안 처리에 의한 액세스가 제한된 보안 컨테이너를 위한 격리된 메모리 공간을 정의하는 것을 포함할 수 있다. 비보안 처리는, 예를 들어, 신뢰 플랫폼 외부로부터의, 그러나 신뢰 플랫폼을 호스팅하는 컴퓨터 상에서의 액세스, 또는 신뢰 플랫폼 내부의 다른 보안 컨테이너 내에서부터의 액세스를 포함할 수 있다. 보안 컨테이너(708)의 인스턴스화는 보안 컨테이너 내에 공용 코드 및 데이터, 예를 들어 도 5의 초기 상태(535)를 로딩하는 것을 또한 포함할 수 있다.

인스턴스화된 보안 컨테이너(708)는 기밀성 통신을 위한 공유 키를 수립하기 위하여 확인자(702)와 키를 교환할 수 있다. 키 교환 프로세스는 도 5의 키 교환 프로세스 또는 도 6의 DKE 프로세스일 수 있다. 확인자는, 예를 들어 도 6의 박스(616)에서와 같이, 키 교환 메시지 1(704)를 신뢰 플랫폼(736)에 발신하고, 신뢰 플랫폼(736)은, 예를 들어 도 6의 박스(658)에서와 같이, 키 교환 메시지 2(706)를 도로 확인자(702)에 발신한다.

증명 시그니처(710)는 보안 컨테이너(708)가 인스턴스화되고 키 교환이 완료된 후에 생성될 수 있다. 인스턴스화된 보안 컨테이너(708)는 보안 컨테이너의 전부 또는 일부 상에서 암호학적 해시 함수를 가동함으로써 측정될 수 있다. 이것은 격리된 메모리, 보안 컨테이너의 인스턴스화 동안에 사용되거나 영향을 받는 신뢰 플랫폼과 연관된 임의의 다른 메모리, 또는 이들의 임의의 서브세트 또는 일부분 내에 로딩된 바이너리 파일, 그리고 격리된 메모리의 콘텐츠 상에서 해시 함수를 가동하는 것을 포함할 수 있다. 이 해시 함수를 가동하는 것의 출력은 측정(measurement)(712)인데, 이는 증명 시그니처(710)의 일부이다. 키 교환 메시지(704 및 706)의 암호학적 해시가 또한 증명 시그니처(710)에 함께 포함될 수 있는데, 데이터(714)로서 묘사된다. 측정(712) 및 데이터(714)는 증명 개인 키 PrivAK(726)를 사용하여 서명될 수 있다. 증명 시그니처는 이후 측정(712) 및 데이터(714)와 더불어 확인자(702)에게 발신될 수 있다. 확인자는, 도 7의 예에서, 측정(712) 및 데이터(714)의 무결성의 확인을 또한 가능하게 하는, 승인 증서로부터의 PubAK(724)를 사용하여 증명 시그니처의 무결성을 확인할 수 있다. 확인자(702)는 예상되는 결과(예를 들어, 측정(712)의 동일한 해시를 로컬로 수행함으로써 판정된 예상 결과)에 대비하여 측정(712)을 비교함으로써 보안 컨테이너(708)의 무결성을 확인하고, (예를 들어 데이터(714)의 해시가 키 교환 메시지 2(706)에 결부되어 있기 때문에) 데이터(714)를 점검함으로써 이 특정한 확인자(702) 통신 경로 인스턴스를 위해 증명 시그니처가 생성되었음을 확인할 수 있다. 이들 확인 동작 및 위의 승인 증서의 확인 후, 이제 확인자는 그것이 보안 컨테이너(708)와의 기밀성 및 무결성 양자 모두를 갖는 통신을 수립된 공유 키를 사용하여 수립할 수 있다는, 신뢰 플랫폼 하드웨어가 그것의 제조자에 따라 신뢰될 수 있다는, 그리고 보안 컨테이너를 생성하는 데에 사용된 신뢰 플랫폼의 소프트웨어 상태가 알려졌다는 어떤 보증을 갖는다. 이제 확인자(702)는 사적 코드 및/또는 사적 데이터를 사용하여 보안 컨테이너(708) 내의 보안 처리를 요청할 준비가 되었다.

엔클레이브 추상화 플랫폼 및 프리미티브

도 8은 예시적인 로컬 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다. 엔클레이브 시스템(800)은 엔클레이브(814) 및 엔클레이브의 클라이언트(816)를 호스팅하는 네이티브 엔클레이브 플랫폼(812)을 가진 컴퓨터(810)를 포함한다. 네이티브 플랫폼(812)은, 예를 들어, Intel의 SGX 또는 Microsoft의 VSM에 기반한 하드웨어 및/또는 소프트웨어 컴포넌트일 수 있다. 엔클레이브(810)는 도 1의 엔클레이브(176)일 수 있다. 엔클레이브를 위한 네이티브 프로토콜(844)이 엔클레이브(814), 클라이언트(816) 및 네이티브 플랫폼(812) 간의 통신을 위해 사용될 수 있다. 도 8에 묘사된 바와 같이, 네이티브 프로토콜(844)은 엔클레이브(814) 내의 인터페이스(820), 네이티브 플랫폼 내의 인터페이스(822 및 824), 그리고 클라이언트 내의 인터페이스(826)를 포함한다. 이들 인터페이스는 소프트웨어 컴포넌트 내의 API 또는 ABI일 수 있다.

이들 소프트웨어 인터페이스(820, 822, 824 및 826)의 사용은 소프트웨어 컴포넌트 간의 실행 제어 전이(execution control transfer)를 포함할 수 있다. 제어 전이는 소프트웨어 컴포넌트(이에 제어가 전이되고 있음) 내의 진입점(명령어의 주소)으로의 콜 또는 점프 명령어를 실행하는 것을 포함할 수 있다. 예를 들어, 네이티브 플랫폼(812)이 소프트웨어 컴포넌트인 경우, 네이티브 플랫폼(812)으로부터 클라이언트(816)로의 제어 전이는 네이티브 플랫폼(812) 내의 콜 또는 점프 명령어가 클라이언트(816)(이에 콜 또는 점프함) 내의 주소를 지정하여 실행되는 경우에 소프트웨어 인터페이스(826)를 통해 발생할 수 있다. 클라이언트(816) 내부의 지정된 주소는 인터페이스(816) 내의 함수 또는 메쏘드를 위한 진입점일 수 있다. 제어 전이는 도 8에서의 화살표로서 나타내어지는데, 예를 들어: 네이티브 플랫폼(812)으로부터 엔클레이브(814)로 인터페이스(820)를 통해; 엔클레이브(814)로부터 네이티브 플랫폼(812)으로 인터페이스(822)를 통해; 클라이언트(816)로부터 네이티브 플랫폼(812)으로 인터페이스(824)를 통해, 그리고 네이티브 플랫폼(812)으로부터 클라이언트(816)로 인터페이스(826)를 통해. 네이티브 프로토콜(844)은 인터페이스(820, 822, 824 및 826)를 통한 통신의 패턴을 포함할 수 있다.

몇몇 실시예에서, 네이티브 플랫폼(812)은 적어도 부분적으로는 하드웨어 컴포넌트로서, 예를 들어 엔클레이브를 관리하기 위한 특수 프로세서 명령어로써 구현될 수 있다. 그러한 특수 하드웨어 명령어는 네이티브 플랫폼(812) 소프트웨어 컴포넌트의 일부로서 실행될 수 있다. 대체 실시예에서 네이티브 플랫폼(812)의 기능의 일부 또는 전부를 위한 어떤 소프트웨어 컴포넌트도 없을 수 있다. 이들 대체 실시예에서, 네이티브 플랫폼 인터페이스(822 및 824)는 소프트웨어 진입점 대신에 하드웨어 명령어일 수 있으니, 네이티브 플랫폼(812)의 기능이 엔클레이브(814) 또는 클라이언트(816)에 의해 사용될 수 있거나, 콜 또는 점프 명령어를 실행하는 것 대신에, 각각, 엔클레이브(814) 또는 클라이언트(816) 내에서 대신 특수 하드웨어 명령어를 실행함으로써 사용될 수 있다.

몇몇 실시예에서, 엔클레이브(814)의 클라이언트(816)는 그 자체가 엔클레이브일 수 있다. 예를 들어, 엔클레이브 클라이언트(816)는 엔클레이브(814)가 생성될 것을 요청하기 위하여 인터페이스(824)를 사용할 수 있다. 이들 실시예에서, 네이티브 플랫폼(812)을 통한 엔클레이브(814) 및 클라이언트(816) 간의 통신은 실제로 두 엔클레이브 간의 통신이다. 클라이언트(816)가 또한 엔클레이브인 경우에, 엔클레이브 클라이언트(816)는 또한 인터페이스(822)를 사용하며 820과 유사한 인터페이스(묘사되지 않음)를 노출할 수 있다.

도 9는 추상화 계층을 가진 예시적인 로컬 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다. 엔클레이브 시스템(900)은 네이티브 프로토콜(944) 및 추상화 프로토콜(940, 942) 간에 전환하기 위한 추상화 플랫폼(912)을 포함한다. 네이티브 플랫폼(918)은 도 8의 추상화 플랫폼(812)과 유사할 수 있고, 인터페이스(928 및 930)는 도 8의 인터페이스(820, 822, 824 및 825)의 함수를 조합할 수 있다. 엔클레이브 추상화 프로토콜(940)은 엔클레이브(914)를 위한 인터페이스(920, 922)를 포함하는 반면, 클라이언트 추상화 프로토콜(942)는 클라이언트(916)를 위한 인터페이스(924, 926)를 포함한다. 도 8에서와 같이, 컴퓨터(910) 상에서 가동되는 클라이언트(916)는 인터페이스(924)를 통해 엔클레이브(914)의 생성을 요청할 수 있다. 추상화 계층(912)은 네이티브 플랫폼(918)과의 인터페이스(928, 930) 및 네이티브 프로토콜(944)을 사용하여 엔클레이브(914)의 생성을 유발할 수 있다. 클라이언트(916) 및 엔클레이브(914)는 네이티브 플랫폼(918) 및 네이티브 프로토콜(944)이 Intel SGX 또는 Microsoft VSM과 같은 상이한 엔클레이브 아키텍처에 기반하는 경우에 추상화 프로토콜(940 및 942)을 사용할 수 있다. 도 8에서와 같이, 엔클레이브(914)의 클라이언트(916)는 그 자체가 엔클레이브일 수 있고, 네이티브 플랫폼(918)은 하드웨어 및/또는 소프트웨어 컴포넌트를 포함할 수 있다.

엔클레이브(914) 및 클라이언트(916)는 직접적으로 통신하지 않을 수 있고 대신에 추상화 플랫폼(912)을 통해 통신할 뿐일 수 있다. 직접 통신은, 예를 들어 엔클레이브(914) 메모리의 격리로 인해, 가능하거나 바람직하지 않을 수 있다. 엔클레이브 메모리 격리는 엔클레이브의 격리된 메모리로부터 읽기, 이에 쓰기, 또는 이를 실행하기(이 안에 또는 이로부터 점프하기)를 방지할 수 있다.

엔클레이브(914)는 컴퓨터(910)의 엔클레이브 보안 컨테이너 내부에 위치된 명령어를 포함할 수 있다. 클라이언트(916)는 컴퓨터(910)의 메모리 주소 공간 내에, 그러나 엔클레이브(914)의 보안 컨테이너 외부에 위치된 명령어를 포함할 수 있다. 추상화 플랫폼(912)은 다양한 방식으로(엔클레이브(914)의 보안 컨테이너 내부에 또는 외부에 있는 명령어로서의 것을 포함함) 구현될 수 있고 하이퍼콜로부터 실행되는 명령어를 또한 포함할 수 있다. 추상화 플랫폼(912)이 적어도 부분적으로는 엔클레이브(914)의 보안 컨테이너 내에 포함된 경우에, 보안 컨테이너 내부의 추상화 플랫폼 코드는 엔클레이브(914)의 코드의 나머지와는 별도로 작성될 수 있고 공용 API/ABI를 통해 다른 엔클레이브 코드와 상호작용할 뿐일 수 있다. 그러한 추상화 플랫폼 코드는 엔클레이브 보안 컨테이너 내부의 코드의 나머지에 정적으로 링크되거나(linked) 동적으로 링크될 수 있다. 정적으로 링크된 추상화 플랫폼 코드는, 추상화 플랫폼과 연관되고, 엔클레이브(914)에 더욱 특정적인 코드와 더불어, 바이너리 이미지(이로부터 엔클레이브(914)가 인스턴스화될 수 있음) 내에 포함된(정적으로 링크된) 오브젝트 코드일 수 있다. 동적으로 링크된 추상화 플랫폼의 경우에, 엔클레이브(914)에 더욱 특정적인 엔클레이브 코드 및 더욱 일반적으로 추상화 플랫폼과 연관된 코드는 개별적인 바이너리 이미지로부터 조달될(sourced) 수 있다. 동적으로 링크된 예에 대해서, 도 14를 보시오.

도 10은 추상화 계층을 가진 예시적인 원격 엔클레이브 시스템을 위한 소프트웨어 컴포넌트 인터페이스의 블록도이다. 원격 엔클레이브 시스템(1000)은 컴퓨터(1010) 상의 엔클레이브(1014)와, 별개의 컴퓨터(1050) 상의 엔클레이브(1014)의 클라이언트(1056)를 포함한다. 클라이언트 스텁(client stub)(1016) 및 추상화 원격화 플랫폼(abstraction remoting platform)(1052)의 조합은 엔클레이브(1014) 및 클라이언트(1056) 간의 상호작용을 가능하게 할 수 있다. 컴퓨터(1010) 내의 많은 요소가 도 9의 컴퓨터(910)의 동일하게 명명된 요소와 동일하거나 유사할 수 있다. 특히, 추상화 플랫폼(1012), 프로토콜(1040, 1042, 1044) 및 네이티브 플랫폼(1018)은 각각 대응하는 요소(912, 940, 942, 944 및 918)와 유사하거나 동일할 수 있다.

클라이언트 스텁(1016)은 네트워크 통신(1080)을 통해 추상화 원격화 플랫폼(1052)와 통신할 수 있다. 원격 클라이언트 프로토콜(1082) 및 인터페이스(1064, 1066)는 클라이언트 추상화 프로토콜(1042) 및 인터페이스(1024, 1026)와 유사할 수 있다. 그러나 원격 클라이언트 프로토콜은 원격화를 위한 추가적인 기능을 포함할 수 있다. 예를 들어, 엔클레이브의 생성을 요청하는 CreateEnclave와 같은 인터페이스(1064) 내의 메쏘드는 엔클레이브가 생성되도록 요청되는, 컴퓨터(1010)와 같은 엔클레이브 호스트 컴퓨터를 지정하는 능력을 추가적으로 포함할 수 있다. 원격 클라이언트 프로토콜을 통해 클라이언트(1056)에 제공되는 엔클레이브(1014)의 증명 인용은 증명 보고 대신에, 또는 이에 더하여, 제공될 수 있다. 클라이언트(1056)를 가진 컴퓨터(1050)는 네이티브 엔클레이브 플랫폼(1058)을 포함할 수 있거나 그렇지 않을 수 있다. 네이티브 플랫폼(1058)이 존재하는 경우, 그것은 샘플 엔클레이브 아키텍처 네이티브 플랫폼(1018)에 부합할 수 있거나 그렇지 않을 수 있고, 따라서 네이티브 프로토콜(1044) 및 원격 네이티브 프로토콜(1084)은 동일하지 않을 수 있다.

대체 실시예(묘사되지 않음)에서, 클라이언트 스텁(1016)은 존재하지 않을 수 있고, 추상화 플랫폼(1012)은 네트워크를 통하여 추상화 원격화 플랫폼(1052)과 직접적으로 통신할 수 있다.

도 9 및 도 10의 940, 942, 1040, 1042, 1082와 같은 엔클레이브 추상화 프로토콜은 Intel SGX 및 Microsoft VSM과 같은 여러 네이티브 플랫폼 상에 구축된 엔클레이브를 관리하고 사용하기 위하여 다양한 인터페이스 메쏘드 또는 진입점을 포함할 수 있다. 이들 메쏘드는 여러 네이티브 플랫폼 상에 구현될 수 있는 엔클레이브 프리미티브를 제공할 수 있는바, 따라서 네이티브 플랫폼의 "추상화"를 제공한다. 여기에 개시된 엔클레이브 프리미티브는 엔클레이브 라이프사이클 관리, 증명, 데이터 실링, 제어 전이, 단조 카운터 및 신뢰 시간을 포함한다.

엔클레이브 라이프사이클 관리를 위한 프리미티브는 엔클레이브(914)와 같은 엔클레이브의 인스턴스화 또는 종결(termination)을 유발하기 위한 메쏘드를 포함할 수 있다. 라이프사이클 관리 프리미티브는 클라이언트 추상화 프로토콜(942)의 일부일 수 있고, 더욱 구체적으로, 클라이언트(916)에 의한 사용을 위한 인터페이스(924)의 일부로서 추상화 플랫폼(912)에 의해 구현될 수 있다.

엔클레이브를 인스턴스화하거나 생성하기 위한 방법은 보안 엔클레이브 컨테이너의 격리된 메모리 내에 로딩될 코드 및/또는 데이터의 실행가능 이미지를 지정하는 것을 포함할 수 있다. 이 코드는, 그것이 엔클레이브 컨테이너 내에 로딩되기 전에 또는 로딩된 후에, (도 5에 관해 위에서 설명된 바와 같이) 인스턴스화된 엔클레이브의 증명을 위해 사용되는 초기 상태의 일부가 될 수 있다. 예를 들어, 엔클레이브의 실행가능 이미지(엔클레이브 바이너리)는 실행가능 이미지를 포함하는 메모리 내의 버퍼에 대한 포인터(pointer)를 제공함으로써 엔클레이브 클라이언트에 의해 지정될 수 있다. 혹은, 엔클레이브 이미지는 엔클레이브 바이너리를 포함하는 파일 시스템 내의 파일을 나타냄으로써 지정될 수 이씨다. 몇몇 실시예에서, 지정된 엔클레이브 이미지는 암호화될 수 있고; 다른 실시예에서, 엔클레이브는 암호화되지 않을 수 있으며; 다른 실시예에서, 엔클레이브는 부분적으로 암호화될 수 있다. 증명을 위한 엔클레이브 바이너리의 측정은 암호화된 실행가능 이미지 상에서 또는 복호화 후에 발생할 수 있다.

초기에 엔클레이브 내에 로딩될 코드 및/또는 데이터는 엔클레이브 일차적 이미지(primary image)를 포함하는 파일을 지정함으로써 나타내어질 수 있다. 이 코드 및/또는 데이터에 더하여, 엔클레이브 일차적 이미지는 추가적인 메타데이터, 예컨대 엔클레이브의 요망되는 크기(엔클레이브 컨테이너 내부에서 요구되는 메모리의 양), 파일 내의 코드 내의 진입점의 위치, 그리고 종속적(dependent) 이미지 파일의 리스트를 포함할 수 있다. 종속적 이미지 파일은 일차적 이미지 파일 내의 코드 및 데이터와 더불어 엔클레이브 내에 또한 로딩될 수 있는 다른 (일차적이지 않은(non-primary)) 이미지 파일이다. 종속적 이미지 파일은 그 자체가 추가의 종속적 이미지 파일의 리스트를 포함할 수 있다. 도 9의 로컬 엔클레이브 시스템의 경우에, 일차적 및 종속적 이미지는 임의의 액세스가능한 저장 디바이스 내에, 예컨대 로컬로 액세스가능한 파일 시스템을 통해, 파일링될(filed) 수 있다. 도 10의 원격 엔클레이브 시스템의 경우에, 일차적 이미지 파일은 컴퓨터(1010)든 또는 컴퓨터(1050)든 액세스할 수 있는 임의의 저장 디바이스 내에 있을 수 있다. 클라이언트(1056)가 컴퓨터(1050) 상에 위치된 일차적 이미지를 사용하여 컴퓨터(1010) 상의 엔클레이브의 생성을 요청하는 경우, 추상화 원격화 플랫폼 및 클라이언트 스텁(1016)은 지정된 일차적 이미지 파일을 컴퓨터(1010)에 복사하도록 편제될(coordinate) 수 있다.

CreateEnclave는 엔클레이브를 인스턴스화하기 위한 예시적인 메쏘드이다. CreateEnclave 메쏘드는 의사코드로써 기술될 수 있다:

본 문서에서 메쏘드를 기술하는 데에 사용되는 의사코드는 API 인터페이스를 정의하기 위해 몇 가지 의사코드 규약을 사용할 수 있다. 예를 들어, 위의 enclavePath와 같은 함수 파라미터는 파라미터가 각각 입력 또는 출력 파라미터임을 나타내기 위하여 "_In_" 또는 "_Out_"으로써 수식될(decorated) 수 있다. "_Out_opt_"는 선택적인 출력 파라미터를 나타낼 수 있다. 전부 대문자인 단어는 데이터 타입을 나타낼 수 있다. HANDLE은 무언가를 간접적으로 가리키는 데에 사용되는, 32 비트 수와 같은 수일 수 있다. 예를 들어, 위의 CreateEnclave 메쏘드는 CreateEnclave의 호출자(caller)에게 HANDLE을 리턴하고, 그 HANDLE은 생성된 엔클레이브의 핸들(handle)일 수 있고; PCWSTR은 어떤 타입의 텍스트 스트링(text string)에 대한 포인터일 수 있고; DWORD는 무부호(unsigned) 32 비트 양일 수 있고; PCVOID는 지정되지 않은 타입의 데이터에 대한 포인터일 수 있고; BOOL은 바이너리 값일 수 있다.

CreateEnclave는 클라이언트, 예컨대 클라이언트(916)로 하여금, 엔클레이브를 생성하고 엔클레이브 내의 일차적 이미지를 로딩할 수 있도록 할 수 있다. 이 이미지 내의 임의의 엔클레이브 구성 정보는 인스턴스화된 엔클레이브와 연관될 수 있다. CreateEnclave는 다음의 파라미터를 포함할 수 있다:

lpEnclaveName: 엔클레이브 일차적 이미지로의 경로를 지정할 수 있는데, 이는 구현에서, 열린 파일에 대한 핸들, 일률적 리소스 식별자(Uniform Resource Identifier: URI), 또는 외부 룩업(external lookup)에서 사용되는 식별자와 같은, 엔클레이브 일차적 이미지의 코드 및/또는 데이터를 식별하기 위한 어떤 다른 타입의 식별자일 수 있다. 예를 들어, 전역적 고유 식별자(Globally Unique IDentifier: GUID)가 일차적 이미지의 데이터베이스 내에의 키로서 사용될 수 있다. 다른 구현에서, 이 파라미터는 엔클레이브 일차적 이미지를 포함하는 메모리 영역을 식별할 수 있다.

flEnclaveType: (엔클레이브 이미지가 여러 타입을 지원하는 경우에) 생성할 엔클레이브의 타입을 지정할 수 있다. 바이너리가 오직 하나의 엔클레이브를 지원하거나 개발자가 디폴트(default)를 명시적으로 지정한 경우에 DEFAULT로 설정될 수 있다. dwFlags: 엔클레이브를 생성하고 엔클레이브 일차적 이미지를 로딩하는 경우에 취해질 하나 이상의 사전결정된 조치를 지정할 수 있다.

enclaveInformation: 엔클레이브의 런타임 구성을 위한 선택적인 입력 파라미터일 수 있다.

lpEnclaveError: 아키텍처 특정적 에러 코드를 리턴하도록 선택적 파라미터를 지정할 수 있다.

성공적인 완료 시에, CreateEnclave는 엔클레이브에 대한 핸들을 리턴할 수 있다. 에러 시에, NULL이 리턴될 수 있다. 이 개시의 범위로부터 벗어나지 않고서 다른 식별자(GUID, URI, 기타 등등)가 또한 리턴될 수 있다. 단순성을 위해, 이 명세서는 핸들을 사용하여 API를 기술할 것이다. 엔클레이브 생성은, 예를 들어, 엔클레이브 메모리의 부족, 추상화 플랫폼 또는 네이티브 플랫폼 내의 지정된 엔클레이브 타입에 대한 지원의 부족으로 인해 실패할 수 있거나, 생성은 지정된 타입의 엔클레이브가 시스템 상에서 가동되지 못하게 하는 명시적인 구성 정책으로 인해 실패할 수 있다.

CreateEnclave 및 아래에 기술된 다른 API 메쏘드의 구현은 기술된 메쏘드 파라미터 중 하나 이상을 배제할 수 있다. 예를 들어, CreateEnclave에 관해서, 그 특정한 API를 위한 구체적인 사전결정된 값을 사용하여, lpEnclaveName, flEnclaveType, dwFlags 및 enclaveInformation이 배제될 수 있다. lpEnclaveError 인자가 API로부터 또한 배제될 수 있고, API 콜에서의 에러에 대해 체크하는 대안적인 방법이 선택적으로 구현될 수 있다.

CreateEnclave는 엔클레이브 일차적 이미지 내에 지정된 바와 같은 모든 종속적 모듈을 로딩하는 것을 책임질 수 있다. 엔클레이브 일차적 이미지는 일차적 이미지가 의존하는 다른 바이너리 이미지 파일을 지정하는 포터블 실행(Portable Execution: PE) 파일일 수 있다. CreateEnclave는 네이티브 플랫폼 특정적 초기화, 예컨대 증명을 위한 측정을 완결하는 것, 전송 계층 보안(Transport Layer Security: TLS) 및/또는 다른 키 합의를 위한 구조 및 통신 프로토콜을 할당하는 것, 기타 등등을 또한 수행할 수 있다. 엔클레이브 추상화 프로토콜 인터페이스(920, 922)(예를 들어, 데이터 실링 및 증명을 위한 메쏘드를 포함함)는 일단 엔클레이브 초기화가 완료되면 동작가능할 수 있다.

TerminateEnclave는 엔클레이브를 종결하기 위한 예시적인 메쏘드이다.

TerminateEnclave는 엔클레이브를 파기하는(destroy) 데에 사용될 수 있다. 구현에서, 엔클레이브를 파기하는 것은 모든 엔클레이브 쓰레드가 호스트로 복귀하거나 종결하도록 강제하는 것, 그리고/또는 엔클레이브와 연관된 메모리를 해소하는 것을 포함할 수 있다. 가동 중인 엔클레이브 상에서 TerminateEnclave를 콜하는 것은 그것을 종결하고 엔클레이브와 연관된 모든 리소스를 해제할 수 있다.

엔클레이브 추상화 플랫폼(912)은, 예를 들어, 엔클레이브 및 그것의 클라이언트 간에 제어를 전이하는 데에 사용될 수 있는 실행 제어 전이 프리미티브를 포함할 수 있다. 실행 제어 전이 프리미티브는 엔클레이브(914) 및 클라이언트(916) 간의 통신을, 다른 컴포넌트 내의 진입점에서 코드의 실행을 시작함으로써 가능하게 할 수 있다. 실행 제어 전이 프리미티브는 파라미터로 하여금 제어 전이 요청과 연관될 수 있게 함으로써 엔클레이브 내에의/밖으로의 데이터의 전달을 가능하게 하고; 파라미터는 개별 데이터 항목을 지정(파라미터 그 자체가 통신됨)할 수 있거나 파라미터는 메모리 영역에 대한 포인터(파라미터가 가리키는 버퍼가 통신됨)일 수 있다. 이들 프리미티브는 엔클레이브 컨테이너에 대한 보안 제한으로 인해 엔클레이브(914) 및 클라이언트(916) 간에 직접적으로 콜하거나 점프하는 것에 대한 제한에도 불구하고 제어 전이를 가능하게 할 수 있다.

엔클레이브에 콜인하는 것을 위해, 인터페이스(924)는 클라이언트(916)로 하여금 인터페이스(920)를 통해 엔클레이브(914)에 콜인할 수 있도록 하는 메커니즘을 포함할 수 있다. 예를 들어, 인터페이스(924)는 GetProcAddress 및 CallEnclave 메쏘드를 포함할 수 있다:

엔클레이브 클라이언트, 예컨대 클라이언트(916)는, GetProcAddress()에 의해 리턴된 함수 포인터를 사용하여, 엔클레이브, 예컨대 엔클레이브(914)에 콜인할 수 있다. lpProcName 파라미터는 엔클레이브 일차적 이미지 내에 이출된(exported) 함수와 매칭될 수 있다. 예를 들어:

GetProcAddress의 다른 실시예에서, lpProcName은 특정 이출된 함수의 다른 식별자, 예를 들어 수, 예를 들어 엔클레이브 이미지로부터 이출된 진입점의 열거로부터의 선택, 또는 함수에 대응하는 다른 비-텍스트(non-textual) 식별자일 수 있다. CallEnclaveIn의 다른 실시예는 콜인될 엔클레이브를 지정하는 입력 파라미터, 예를 들어, 핸들 리턴된 CreateEnclave를 추가적으로 취할 수 있다.

엔클레이브에 콜인하는 경우에, 클라이언트 프로세스 내의 쓰레드는 유예될(suspended) 수 있고 (별개의 쓰레드 ID를 가진) 엔클레이브 쓰레드는 요청 내의 콜을 서비스하는 데에 사용될 수 있다. 이후, 엔클레이브 쓰레드 상에서 가동되는 엔클레이브 코드는, 엔클레이브에 콜인하기 전에 엔클레이브 클라이언트가 이전에 이용할 수 있었던 메모리에의 액세스를 가질 수 있다. 예를 들어, 클라이언트는 CallEnclaveIn 추상화 메쏘드를 콜하기 전에 pParameter에 의해 가리켜진 버퍼 내에 데이터를 넣을 수 있고, 그러면 엔클레이브는 요청 내의 콜을 서비스하는 동안에 pParameter에 의해 가리켜진 버퍼에의 액세스를 가질 수 있다. 콜 아웃(call out) 시에, 원래의 (클라이언트) 호출 쓰레드는 콜 아웃을 서비스하는 데에 사용될 수 있다. 재진입성(reentrancy)이 지원될 수 있다(예를 들어 호스트에서의 콜 아웃은 다시 엔클레이브에 콜인할 수 있다).

엔클레이브에서 콜아웃하는것을 위해, 인터페이스(922)는 엔클레이브(914)로 하여금 엔클레이브 클라이언트(916)로 콜 아웃할 수 있도록 하는 위의 CallEnclaveIn 메쏘드에 관련된 메쏘드를 포함할 수 있다. 예를 들어, 엔클레이브(914)는 특정한 타입, 예를 들어 ENCPROC 함수 타입의 호스트 프로세스 내의 임의의 함수에 콜아웃할 수 있다. 상동의 것을 위한 함수 포인터는 엔클레이브에게 파라미터 내에서 콜을 사용하여 전해질 수 있다.

인터페이스(920)는 위의 "CallinExample" 함수로서 등록된 진입점을 포함할 수 있고, 인터페이스(926)는 위의 "Callout" 함수로서 등록된 진입점을 포함할 수 있다. 예를 들어, 엔클레이브 일차적 이미지가 포터블 실행가능(Portable Executable: PE) 이미지 포맷으로 된 경우에, 이미지 내의 함수 진입점은 "이출" 진입점으로서 나열될 수 있고, 각각의 그러한 이출된 진입점은 그 엔클레이브 PE 이미지 내의 진입점을 식별하고 구별하기 위하여, "CallinExample"와 같은 텍스트 이름을 포함할 수 있고; 다른 구현에서 함수 진입점은 추가적인 메타데이터, 예컨대 함수가 엔클레이브를 위한 진입점일 수 있음을 나타내는 하나의 비트로써 마킹될(marked) 수 있다. 엔클레이브에서 콜아웃하는 것을 위해 위의 예에서, 콜아웃 함수의 주소는 0xF00으로 주어지며 단지 예이다. 콜아웃 함수의 실제 주소는 다양한 방식으로 결정될 수 있다. 예를 들어, 클라이언트 내부의 콜아웃 함수 주소는 콜인 함수를 위한 파라미터로서 엔클레이브 내로 전해질 수 있다. 다른 예에서, 콜아웃 함수의 주소는 RegisterCallOut과 같은 함수를 사용하여 클라이언트에 의해 등록될 수 있다:

엔클레이브 내부의 코드는 GetCallOut과 같은 상보적인 함수를 콜하는 것에 의해 콜아웃 함수의 주소를 획득할 수 있다:

다른 실시예에서, CallEnclaveIn 및 CallEnclaveOut 메쏘드는 실제로 동일한 메쏘드일 수 있다. 예를 들어, 단일의 CallEnclave 메쏘드가 엔클레이브로 콜인하고 엔클레이브로부터 콜아웃하는 데에 사용될 수 있다. 엔클레이브 클라이언트(916)가 또한 엔클레이브인 상황에서, 엔클레이브(914)로부터 클라이언트(916)로 콜아웃하는 것은 또한 엔클레이브 내에 콜인하는 것일 것이다.

추상화 플랫폼(912)은 엔클레이브에 대해 데이터를 실링하기 위한 프리미티를 제공할 수 있다. 예를 들어, 인터페이스(922)는 엔클레이브(914)에 서비스, 예컨대 엔클레이브 신원에 대해 데이터를 실링하고 실링해제하는 것을 제공할 수 있다. 위에서 설명된 바와 같이, 엔클레이브는 다수의 내포형 신원을 가질 수 있고, 데이터는 임의의 그러한 신원에 대해 실링될 수 있다. 가능한 엔클레이브 인스턴스화의 세트에 대응하는 신원에 대해 데이터가 실링된 경우에, 실링된 데이터는 그 대응하는 세트의 엔클레이브 인스턴스화 중 임의의 것에 의해 실링해제될 수 있다. 예를 들어:

enclaveIdType의 각 값에 대해, 엔클레이브는 맵핑 ID에 대해 실링할 것이다. 가능한 엔클레이브 신원 타입(그리고 enclaveIdType의 값)은 다음을 포함한다:

플랫폼은 또한 추가적인 디버그 구성(debug configuration)(작성됨 및 런타임)을 실링 정책에 적용할 수 있다. 상이한 디버그 정책을 위해, 상이한 실링 키가 사용될 수 있다. 예를 들어, 디버그 및 릴리즈(release) 구성은 상이한 실링 키를 사용할 수 있다.

추상화 플랫폼(912)은 증명을 위한, 예컨대 증명 보고 및 인용을 산출하기 위한, 그리고 보고 및 인용을 확인하기 위한 프리미티브를 제공할 수 있다. 예를 들어:

VerifyReport()는 보고의 무결성을, 그리고 보고가 동일한 머신 상에서 엔클레이브에 의해 생성되었음을 확정하기 위하여 엔클레이브에 의해 사용될 수 있다.

CreateQuote에서, quoteType은 인용 제공자로 맵핑될 수 있는데, 이는 특정 인용을 생성하는 신뢰의 소스일 수 있다. CreateQuote에서, authData는 CreateQuote의 호출자에 의해 생성되고, 이에 의해 정의된 포맷으로 된 데이터에 대한 포인터일 수 있다. authData는 추상화 플랫폼(912)에 의해 이해될 필요가 없다. authData는 결과적인 인용 내에 패킹될(packed) 수 있다. 인용 제공자는 이것을 지원하도록 기대될 수 있다.

위에서 기술된 엔클레이브 프리미티브에 더하여, 엔클레이브 추상화 플랫폼은 다음을 제공할 수 있다: (예를 들어, 메모리, 예컨대 엔클레이브에 제한된 메모리 또는 엔클레이브 및 그것의 클라이언트 간에 공유된 메모리를 할당하고 해소하는) 메모리 관리; (예를 들어, 엔클레이브 코드를 실행하는 동안에 발생하는 에러 또는 예외를 다루는) 예외 핸들링(exception handling); 쓰레드 동기화; 그리고 암호학적 기능(예를 들어 암호화, 해시 함수 및 서명).

위에서 기술된 기법은 아래에 기술된 바와 같이, 하나 이상의 컴퓨팅 디바이스 또는 환경 상에서 구현될 수 있다. 도 11은, 예를 들어, 신뢰 하드웨어(172), 신뢰 플랫폼(736), 또는 컴퓨터(810, 910, 1010 및 1050) 중 하나 이상을 체현할 수 있는, 예시적인 일반 목적 컴퓨팅 환경을 묘사하는데, 여기에서 본 문서에 기술된 기법 중 일부가 체현될 수 있다. 컴퓨팅 시스템 환경(1102)은 적합한 컴퓨팅 환경의 단지 하나의 예이며 본 개시된 주제의 사용 또는 기능의 범위에 대한 어떤 한정도 시사하도록 의도되지 않는다. 컴퓨팅 환경(1102)은 예시적인 운영 환경(1102) 내에 보여진 컴포넌트 중 임의의 것 또는 이의 조합에 관한 어떤 종속성이나 요구를 갖는 것으로 해석되어서도 안 된다. 몇몇 실시예에서 다양한 묘사된 컴퓨팅 요소는 본 개시의 구체적 양상을 인스턴스화하도록 구성된 회로를 포함할 수 있다. 예를 들어, 개시에서 사용된 용어 회로는 펌웨어 또는 스위치에 의해 기능(들)을 수행하도록 구성된 전문화된 하드웨어 컴포넌트를 포함할 수 있다. 다른 예시적 실시예에서, 용어 회로는 기능(들)을 수행하도록 동작가능한 로직(logic)을 체현하는 소프트웨어 명령어에 의해 구성된 일반 목적 처리 유닛, 메모리, 기타 등등을 포함할 수 있다. 회로가 하드웨어와 소프트웨어의 조합을 포함하는 예시적 실시예에서, 구현자는 로직을 체현하는 소스 코드를 작성할 수 있고 소스 코드는 일반 목적 처리 유닛에 의해 처리될 수 있는 머신 판독가능 코드로 컴파일될 수 있다. 당업자는 하드웨어, 소프트웨어, 또는 하드웨어/소프트웨어의 조합 간에 별로 차이가 없는 데까지 최신 기술이 진전되었음을 인식할 수 있으므로, 특정 기능을 이룩하기 위한 하드웨어 대 소프트웨어의 선택은 구현자에게 남겨진 설계 선택이다. 더욱 구체적으로, 당업자는 소프트웨어 프로세스가 동등한 하드웨어 구조로 변형될 수 있고, 하드웨어 구조 그 자체가 동등한 소프트웨어 프로세스로 변형될 수 있음을 인식할 수 있다. 그러므로, 하드웨어 구현 대 소프트웨어 구현의 선택은 설계 선택의 하나이고 구현자에게 남겨진다.

컴퓨터(1102)는, 모바일 디바이스 또는 스마트폰, 태블릿, 랩톱, 데스크톱 컴퓨터, 또는 네트워킹된 디바이스의 모음(collection), 클라우드 컴퓨팅 리소스, 기타 등등 중 임의의 것을 포함할 수 있는데, 전형적으로 갖가지 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 탈거가능(removable) 및 비탈거가능(non-removable) 매체, 휘발성(volatile) 및 비휘발성(nonvolatile) 매체 양자 모두를 포함하며 컴퓨터(1102)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 시스템 메모리(1122)는 판독 전용 메모리(Read Only Memory: ROM)(1123) 및 랜덤 액세스 메모리(Random Access Memory: RAM)(1160)와 같은 휘발성 및/또는 비휘발성 메모리의 형태로 된 컴퓨터 판독가능 저장 매체를 포함한다. 예컨대 시동(start-up) 동안에, 컴퓨터(1102) 내의 요소 간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입력/출력 시스템(Basic Input/Output System: BIOS)(1124)는 전형적으로 ROM(1123) 내에 저장된다. RAM(1160)은 전형적으로 데이터 및/또는 프로그램 모듈(이는 처리 유닛(1159)이 즉각적으로 액세스할 수 있고/거나 처리 유닛(1159)이 이에 대해 현재 동작하고 있음)을 포함한다. 한정이 아니고, 예로서, 도 11은 하이퍼바이저(1130), 운영 체제(Operating System: OS)(1125), 애플리케이션 프로그램(1126), 엔클레이브 클라이언트(1165)를 포함하는 다른 프로그램 모듈(1127), 그리고 엔클레이브(1128)를 보여준다.

컴퓨터(1102)는 다른 탈거가능/비탈거가능, 휘발성/비휘발성 컴퓨터 저장 매체를 또한 포함할 수 있다. 단지 예로서, 도 11은 비탈거가능, 비휘발성 자기적 매체로부터 판독하거나 이에 기록하는 하드 디스크 드라이브(1138), 탈거가능, 비휘발성 자기적 디스크(1154)로부터 판독하거나 이에 기록하는 자기적 디스크 드라이브(1139), 그리고 CD ROM 또는 다른 광학 매체와 같은 탈거가능, 비휘발성 광학 디스크(1153)로부터 판독하거나 이에 기록하는 광학 디스크 드라이브(1104)를 보여준다. 예시적인 운영 환경에서 사용될 수 있는 다른 탈거가능/비탈거가능, 휘발성/비휘발성 컴퓨터 저장 매체는 자기적 테이프 카세트, 플래시 메모리 카드, 디지털 다기능 디스크(digital versatile disk), 디지털 비디오 테이프, 솔리드 스테이트(solid state) RAM, 솔리드 스테이트 ROM, 그리고 유사한 것을 포함하나, 이에 한정되지 않는다. 하드 디스크 드라이브(1138)는 전형적으로 인터페이스(1134)와 같은 비탈거가능 메모리 인터페이스를 통해서 시스템 버스(1121)에 연결되고, 자기적 디스크 드라이브(1139) 및 광학 디스크 드라이브(1104)는 전형적으로 인터페이스(1135 또는 1136)와 같은 탈거가능 메모리 인터페이스에 의해 시스템 버스(1121)에 연결된다.

위에서 논의되고 도 11에서 예시된 드라이브 및 그것의 연관된 컴퓨터 저장 매체는 컴퓨터(1102)를 위해 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장을 제공할 수 있다. 도 11에서, 예를 들어, 하드 디스크 드라이브(1138)는 운영 체제(1158), 애플리케이션 프로그램(1157), 다른 프로그램 모듈(1156), 예컨대 엔클레이브 클라이언트 애플리케이션 및 엔클레이브 바이너리 파일, 그리고 프로그램 데이터(1155)를 저장하는 것으로서 예시된다. 이들 컴포넌트는 운영 체제(1125), 애플리케이션 프로그램(1126), 다른 프로그램 모듈(1127) 및 프로그램 데이터(1128)와 동일하거나 아니면 상이할 수 있다. 운영 체제(1158), 애플리케이션 프로그램(1157), 다른 프로그램 모듈(1156) 및 프로그램 데이터(1155)에는, 최소한, 그것들이 별도의 사본임을 보여주기 위하여 여기에서 상이한 번호가 주어진다. 사용자는 키보드(1151) 및 포인팅 디바이스(1152)(흔히 마우스(mouse), 트랙볼(trackball) 또는 터치 패드(touch pad)로 지칭됨)와 같은 입력 디바이스를 통해서 컴퓨터(1102) 내에 명령 및 정보를 입력할 수 있다. 다른 입력 디바이스(도시되지 않음)는 마이크(microphone), 조이스틱(joystick), 게임 패드(game pad), 위성 안테나(satellite dish), 스캐너(scanner), 망막 스캐너(retinal scanner), 또는 유사한 것을 포함할 수 있다. 이들 및 다른 입력 디바이스는 시스템 버스(1121)에 커플링된 사용자 입력 인터페이스(1136)를 통해서 처리 유닛(1159)에 흔히 연결되나, 병렬 포트, 게임 포트 또는 범용 직렬 버스(Universal Serial Bus: USB)와 같은 다른 인터페이스 및 버스 구조에 의해 연결될 수 있다. 모니터(1142) 또는 다른 타입의 디스플레이 디바이스는 비디오 인터페이스(1132)와 같은 인터페이스를 통해 시스템 버스(1121)에 또한 연결된다. 모니터에 더하여, 컴퓨터는 출력 주변기기 인터페이스(1133)를 통해서 연결될 수 있는, 스피커(1144) 및 프린터(1143)와 같은 다른 주변기기 출력 디바이스를 또한 포함할 수 있다.

컴퓨터(1102)는 원격 컴퓨터(1146)와 같은 하나 이상의 원격 컴퓨터로의 논리적 연결을 사용하여 네트워킹된 환경(networked environment) 내에서 동작할 수 있다. 원격 컴퓨터(1146)는 개인용 컴퓨터, 서버, 라우터(router), 네트워크 PC, 피어 디바이스(peer device) 또는 다른 공통 네트워크 노드(node)일 수 있고, 전형적으로 컴퓨터(1102)에 관해 위에서 기술된 요소 중 다수 또는 전부를 포함하는데, 다만 오직 메모리 저장 디바이스(1147)가 도 11에 예시되었다. 도 11에 묘사된 논리적 연결은 로컬 영역 네트워크(Local Area Network: LAN)(1145) 및 광역 네트워크(Wide Area Network: WAN)(1149)를 포함하나, 다른 네트워크를 또한 포함할 수 있다. 그러한 네트워킹 환경은 사무실, 전사적(enterprise-wide) 컴퓨터 네트워크, 인트라넷, 인터넷 및 클라우드 컴퓨팅 리소스에서 예삿일이다.

LAN 네트워킹 환경에서 사용되는 경우에, 컴퓨터(1102)는 네트워크 인터페이스 또는 어댑터(adapter)(1137)를 통해서 LAN(1145)에 연결된다. WAN 네트워킹 환경에서 사용되는 경우에, 컴퓨터(1102)는 전형적으로 인터넷과 같은 WAN(1149)를 통한 통신을 수립하기 위한 모뎀(1105) 또는 다른 수단을 포함한다. 모뎀(1105)은 내적 또는 외적일 수 있는데, 사용자 입력 인터페이스(1136) 또는 다른 적절한 메커니즘을 통해 시스템 버스(1121)에 연결될 수 있다. 네트워킹된 환경에서, 컴퓨터(1102)에 관해 묘사된 프로그램 모듈, 또는 이의 부분은, 원격 메모리 저장 디바이스 내에 저장될 수 있다. 한정이 아니고, 예로서, 도 11은 원격 애플리케이션 프로그램(1148)을 메모리 디바이스(1147) 상에 주재하는 것으로서 예시한다. 도시된 네트워크 연결은 예이며 컴퓨터 간의 통신 링크를 수립하는 다른 수단이 사용될 수 있음이 인식될 것이다.

도 12는 네이티브 엔클레이브 플랫폼을 추상화하는 방법(1200)을 위한 예시적인 흐름도를 묘사한다. 도 9의 912와 같은 추상화 플랫폼은 박스(1202)에서 엔클레이브 플랫폼에 대한 요청을 수신할 수 있다. 요청은 클라이언트(914)와 같은 엔클레이브 클라이언트로부터, 또는 엔클레이브(916)와 같은 엔클레이브로부터 올 수 있다.

엔클레이브로부터의 요청은 추상화 플랫폼 프리미티브를 수행하라는 요청일 수 있고, 예를 들어, 다음을 하라는 요청을 포함할 수 있다: 엔클레이브의 증명 보고 또는 인용을 생성하기; 엔클레이브에 데이터를 실링하기; 엔클레이브의 클라이언트 내의 함수를 콜(클라이언트로 콜아웃)하기; 단조 카운터를 판독(단조 카운터의 현재 값을 제공)하기; 신뢰 시간 측정을 제공하기; 그리고 (예를 들어, 엔클레이브에 콜인하거나 엔클레이브에서 콜아웃하는 경우에 공유 메모리에 대한 포인터가 파라미터로서 전달될 수 있도록 하기 위하여) 엔클레이브 및 그것의 클라이언트 간에 공유될 수 있는 메모리를 할당하기. 몇몇 실시예에서, 엔클레이브 클라이언트의 전체 가상 메모리 공간은 엔클레이브와 공유될(그리고 이로부터 액세스가능할) 수 있는바, 공유 메모리를 할당하라는 요청은 엔클레이브의 클라이언트를 위해 메모리를 할당하라는 요청으로서 구현될 수 있다. 몇몇 실시예에서, 공유 메모리를 할당하는 방법은 엔클레이브 및 그것의 클라이언트 양자 모두가 이용할 수 있다.

엔클레이브 클라이언트로부터의 요청은 추상화 플랫폼 프리미티브를 수행하라는 요청일 수 있고, 예를 들어, 다음을 하라는 요청을 포함할 수 있다: 엔클레이브를 인스턴스화하기; 엔클레이브의 증명 보고를 확인하기; 엔클레이브 내부의 함수를 콜(엔클레이브에 콜인)하기; 그리고 엔클레이브 및 그것의 클라이언트 간에 공유될 수 있는 메모리를 할당하기.

동작(1204 내지 1208)에서 추상화 플랫폼 요청은 네이티브 플랫폼 요청으로 전환될 수 있다. 수신된 요청 내에 포함되거나 암시된 파라미터는, 예를 들어, 원래의 요청 내의 파라미터의 데이터 포맷이 네이티브 플랫폼에서의 그 파라미터를 위한 데이터 포맷과 동일하지 않다고 판정되는 경우 선택적인 단계(1204)에서 변환될 수 있다. 예를 들어, 엔클레이브 또는 클라이언트로부터의 요청이 엔클레이브 추상화 신원과 같은, 추상화 포맷 증명 보고로부터 도출된 파라미터를 포함하는 경우, 네이티브 엔클레이브 신원과 같은, 네이티브 포맷 증명 보고에서 사용되는 파라미터로 변환될 것이다.

수신된 요청 및 네이티브 플랫폼의 호출 규약이 상이하다고 판정된 경우, 호출 규약은 선택적인 단계(1206)에서 변환될 수 있다. 호출 규약은, 예를 들어, 콜 스택(call stack) 상의 파라미터를 재순서화하는 것, 프로세서 레지스터 및 콜 스택 간에 파라미터를 이동시키는 것, 그리고 에러 상태 통신 메쏘드 간에 변환하는 것, 예컨대 에러 값을 리턴하는 것 및 예외 핸들러(exception handler)를 콜하는 것에 의해 변환될 수 있다.

몇몇 실시예에서, 네이티브 플랫폼은 몇몇 요청에 있어서 추상화 플랫폼과 동일할 수 있는데, 그 경우에 박스(1204 및 1206)의 변환 동작은 생략될 수 있다.

박스(1208)에서, 변환된 요청은 네이티브 플랫폼으로 발신되어 요청이 네이티브 플랫폼에 의해 수행되게 한다. 예를 들어, 네이티브 플랫폼이 Intel 소프트웨어 가드 확장(Software Guard Extensions: SGX) 엔클레이브 아키텍처에 부합하는 경우에, 네이티브 플랫폼은 엔클레이브를 위한 프로세서 명령어를 포함할 수 있다. 이 경우에, 박스(1208)에서 요청을 발신하는 것은 엔클레이브를 위한 하나 이상의 프로세서 명령어를 실행하는 것을 포함할 수 있다. 다른 예에서, 네이티브 플랫폼은 Microsoft 가상 보안 모드(Virtual Secure Mode: VSM) 엔클레이브 아키텍처에 부합할 수 있는데, 이는 엔클레이브를 위한 하이퍼콜이 있는 하이퍼바이저를 포함할 수 있다. 하이퍼콜은 하이퍼바이저 코드로의 소프트웨어 트랩(trap)이며, 하이퍼콜은 특권(privileged) 동작이 허용될 수 있는 콘텍스트(context)로의 프로세서 콘텍스트의 변화를 유발할 수 있다. 이 VSM 예에서, 박스(1208)에서 요청을 발신하는 것은 하이퍼바이저에의 하이퍼콜을 행하는 것 및/또는 특권 동작이 허용될 수 있는 콘텍스트로 실행 콘텍스트를 스위칭하는 다른 메커니즘을 포함할 수 있다.

여기서 네이티브 플랫폼에 요청을 발신하는 것은 일반적으로 네이티브 플랫폼의 특징을 사용하여 요청을 수행하는 것을 의미한다. 네이티브 플랫폼(1208)에 요청을 발신하는 동작은 네이티브 플랫폼과의 여러 동작을 수반할 수 있고, 요청된 동작(또는 프리미티브), 예컨대 엔클레이브를 생성하는 것, 증명, 데이터 실링, 제어 전이, 또는 단조 카운터 및 신뢰 시간의 사용에 따라서 달라질 수 있다.

CreateEnclave 프리미티브는 엔클레이브를 인스턴스화하는 데에 사용될 수 있다. 엔클레이브를 인스턴스화하라는 CreateEnclave 요청은 추상화 플랫폼으로 하여금 (예를 들어 어떤 메모리를 할당하고 그 메모리를 위한 보안 또는 격리 경계를 수립함으로써) 보안 컨테이너를 생성하고, (예를 들어 엔클레이브 이미지로부터) 그 보안 컨테이너 내에 엔클레이브 코드를 복사하며, (예를 들어 엔클레이브 이미지 내의 진입점 메타데이터에 따라) 엔클레이브 코드 내에 진입점을 구성하거나 가능화하도록 할 수 있다.

엔클레이브 가능화된 하이퍼바이저(enclave-enabled hypervisor)(VSM과 같이, 엔클레이브 관리 기능을 제공하는 하이퍼바이저)를 가진 네이티브 플랫폼에 CreateEnclave 요청을 발신하는 것은, 메모리를 할당하는 것 및 엔클레이브 컨테이너 외부의 코드가 그 메모리를 액세스하지 못하게 하는 방식으로 메모리를 위한 프로세서 페이지 테이블을 셋업하기 위해 하이퍼콜을 행하는 것을 포함할 수 있다. 추상화 플랫폼으로부터의 엔클레이브 생성 하이퍼콜은 또한 하이퍼바이저로 하여금 명시된 진입점에서의 엔클레이브 내에의 제어 전이를 위한 구성 정보를 셋업하도록 할 수 있다. 이후, 보안 컨테이너 외부의 코드는 보안 컨테이너 내부의 명시된 진입점에서 실행을 전이하기 위하여 제어 전이 하이퍼콜을 행할 수 있다.

엔클레이브 가능화된 프로세서(SGX와 같이, 엔클레이브 관리 프로세서 명령어를 가진 프로세서)를 가진 네이티브 플랫폼에 CreateEnclave 요청을 발신하는 것은, 추상화 플랫폼이 ECREATE와 같은 명령어를 실행하여 CPU에게 어떤 메모리 영역이 보안 엔클레이브 컨테이너로서 생성되어야 함을 통지하는 것과, EADD와 같은 명령어를 실행하여 데이터 페이지를 그 엔클레이브 컨테이너에 추가하는 것을 포함할 수 있다. 엔클레이브 내에의 제어 전이를 위해 엔클레이브 내의 진입점을 명시하기 위해 메모리 내의 특수한 페이지를 생성하는 데에 특수한 프로세서 명령어가 또한 사용될 수 있다. 이후, 보안 컨테이너 외부의 코드는 명시된 진입점 중 하나를 지정하는 EENTER와 같은 명령어를 실행하여 실행 제어를 그 엔클레이브 진입점에 전이할 수 있다.

CreateReport 프리미티브는 증명 보고를 생성하는 데에 사용될 수 있다. 엔클레이브의 증명 보고를 생성하라는 CreateReport 요청은 도 5 및 도 7에 관해 위에서 설명된 바와 같은 추상화 계층에 의해 수행될 수 있다. 엔클레이브 가능화된 하이퍼바이저로써, 추상화 계층은 실행 상태를, 예를 들어, 보고 서명에 사용될 수 있는 도 7의 PrivAK(726)와 같은 비밀 키에 대한 액세스를 갖는 보안 모니터 콘텍스트(security monitor context)로, 변경하는 하이퍼콜을 행함으로써 네이티브 플랫폼에 요청을 발신할 수 있다. 이 비밀 키는 TPM에 기반을 둔 TCG 로그로써 확인되는 바와 같은 양호한 구성에서 컴퓨터가 부팅되었으면(booted) 보안 모니터 콘텍스트에게만 가용한 것일 수 있다. 보안 모니터는 보고 데이터를 증명되고 있는 엔클레이브의 신원으로써 태깅할(tag) 수 있다.

엔클레이브 가능화된 프로세서로써, CreateReport 요청은 보고를 생성하고 그것을 보고를 서명하기 위한 개인 키에 대한 액세스를 가질 특수한 엔클레이브에 발신하는, EREPORT와 같은 명령어를 실행함으로써 네이티브 플랫폼에 발신될 수 있다.

EnclaveSeal 프리미티브는 엔클레이브에 데이터를 실링하는 데에 사용될 수 있다. 데이터를 엔클레이브에 실링하는 것은 데이터를 엔클레이브와 연관된 키로써 또는 방식으로 암호화한다. EnclaveSeal 요청은 엔클레이브 내부에 위치된 데이터, 예컨대 엔클레이브의 상태의 전부 또는 일부를 실링 정책을 사용하여 엔클레이브에 실링하라는 요청일 수 있다. 위의 SEALING_POLICY와 같은 실링 정책은 어느 엔클레이브가 데이터를 실링해제할 수 있어야 하는지를 나타내는 엔클레이브 신원 타입을 지정할 수 있다. 실링 프로세스 그 자체는 실링 정책 내에 지정된 엔클레이브 신원과 연관된 암호화 키를 사용할 수 있다. 이후, 새로운 엔클레이브 인스턴스화는 지정된 신원 타입에서의 새로운 엔클레이브의 신원 값이 지정된 신원 타입에서의 실링 엔클레이브의 신원 값과 동일한 경우 데이터를 실링해제하는 것이 가능할 수 있다.

데이터 실링은 비밀 또는 민감한 엔클레이브 데이터로 하여금 비보안 스토리지에, 예컨대 엔클레이브의 보안 컨테이너 외부의 메모리에 또는 하드 디스크와 같은 영구적 스토리지(persistent storage)에 안전하게 복사될 수 있도록 한다. 실링된 데이터가 엔클레이브 상태 데이터인 경우, 실링하는 것은 엔클레이브로 하여금 이전의 상태로 재설정될 수 있도록 하고, 보안 엔클레이브 동작으로 하여금 중단되어(interrupted) 나중에 다른 엔클레이브 내에서 계속될 수 있게 한다.

엔클레이브 상태를 재설정하기 위하여, 엔클레이브에 그것의 상태를 실링함으로써 우선 엔클레이브의 상태가 세이브된다. 실링은 상태 데이터를 엔클레이브와 연관된 키로써 암호화함으로써 행해질 수 있다. 이후, 아마도 엔클레이브의 상태가 바뀐 후에, 실링된 상태 데이터는, 실링된 데이터를 복호화하고 이후 엔클레이브의 현재 상태를 복호화된 데이터로 대체함으로써 (예를 들어 복호화된 데이터를 엔클레이브의 보안 컨테이너 내에 복사함으로써) 동일한 엔클레이브에 실링해제될 수 있다.

보안 동작을 중단하고 다른 엔클레이브 내에서 계속하기 위하여, 보안 동작은 제1 엔클레이브 내에서 여러 프로세서 명령어를 포함하는 동작을 실행함으로써 시작한다. 제1 엔클레이브가 중단된 경우에, 그 엔클레이브의 상태는 실링 정책 내에 지정된 엔클레이브 신원에 실링될 수 있고, 실링된 데이터는 이후 비보안 스토리지, 예컨대 로컬 또는 클라우드 기반 영구적 스토리지 내에 세이브될 수 있다. 그러면 제1 엔클레이브는 (선택적으로) 종결되거나 다른 엔클레이브 동작을 시작할 수 있다. 실링된 상태 데이터를 제2 엔클레이브 내에 실링해제함으로써 중단된 동작을 계속하기 위하여 제2 엔클레이브가 인스턴스화되거나 용도 변경될(repurposed) 수 있다. 중단된 동작은 제1 엔클레이브가 멈춘 데에서 제2 엔클레이브 내에서 계속될 수 있다.

엔클레이브 가능화된 하이퍼바이저로써, 추상화 계층은 하이퍼콜을 행하는 것에 의해 네이티브 플랫폼에 EnclaveSeal 요청을 발신할 수 있다. 하이퍼콜은 실행 상태를, 데이터를 실링하거나 실링해제하는 데에 사용될 수 있는 엔클레이브와 연관된 비밀 실링 키에 대한 액세스를 가질 콘텍스트, 예를 들어 보안 모니터 콘텍스트로 변경할 수 있다. 실링 키는 보안 모니터만 이용할 수 있는 비밀 플랫폼 키 및 엔클레이브 신원의 조합으로부터 도출될 수 있다. 이 플랫폼 키는 양호한 구성에서 머신이 부팅된 경우에 보안 모니터에게만 가용한 것일 수 있고, 부트 구성은 TPM에 기반한 TCG 로그로써 확인된다. 이 엔클레이브 가능화된 하이퍼바이저 실시예에서, 엔클레이브 코드는 결코 실링 키에 대한 액세스를 갖지 않는다.

엔클레이브 가능화된 프로세서로써, EnclaveSeal 요청은 암호화 키를 얻는, EGETKEY와 같은 명령어를 실행함으로써 네이티브 플랫폼에 발신될 수 있다. 이 알고리즘은 엔클레이브에 고유한 실링 키를 생성할 수 있다. 실링 키는 엔클레이브의 신원 및 프로세서 내에 임베딩된(embedded) 시크릿으로부터 도출될 수 있다. 그러면 엔클레이브 내부의 코드는 실링 키로써 데이터를 암호화할 수 있다. 데이터는, 예를 들어 엔클레이브 내부의 코드에 의해, 추상화 플랫폼에 의해, 또는 네이티브 플랫폼에 의해, 실링 키로써 암호화함으로써 실링될 수 있다. EnclaveUnseal은 실링해제 키를 생성하기 위하여 마찬가지로 EGETKEY를 사용할 수 있다.

제어 전이 요청은 프로세서 실행 제어를 엔클레이브 내부의 명령어로부터 밖으로 엔클레이브 외부의 진입점으로(예를 들어 CallEnclaveOut), 또는 반대로 엔클레이브 외부의 명령어로부터 엔클레이브 내부의 진입점으로(예를 들어 CallEnclaveIn) 전이하라는 요청일 수 있다. 이것은, 예를 들어, 보안 데이터베이스 동작을 위해 행해질 수 있다. 데이터베이스 엔클레이브를 인스턴스화한 후에, 엔클레이브 클라이언트는 엔클레이브가 특정 동작을(예컨대 데이터베이스 질의(database query)를, 그 질의를 수행할 데이터베이스 엔클레이브 내부의 진입점으로 제어를 전이하기 위하여 CallEnclaveIn 프리미티브를 사용함으로써) 수행할 것을 요청할 수 있다. 엔클레이브가 질의를 완료한 후에, 질의의 결과는 질의 결과를 수신할 수 있는 클라이언트 내의 진입점에서 도로 클라이언트에 제어를 전이하기 위하여 CallEnclaveOut 프리미티브로써 클라이언트에 (가능하게는 결과를 암호화한 후에) 리턴될 수 있다. CallEnclaveIn 및 CallEnclaveOut 프리미티브는 엔클레이브 및 그것의 클라이언트 간에 공유될 수 있는 메모리 버퍼에 대한 포인터를 취할 수 있다(버퍼는 엔클레이브에 의해서든 또는 그것의 클라이언트에 의해서든 판독가능, 기록가능 및/또는 실행가능할 수 있다).

엔클레이브 가능화된 하이퍼바이저로써, 추상화 계층은 하이퍼콜을 행하는 것에 의해 네이티브 플랫폼에 CallEnclaveIn 요청을 발신할 수 있다. 하이퍼콜은 실행 상태를, CPU 레지스터를 세이브하고, (가능하게는 엔클레이브 메모리로부터) 엔클레이브 CPU 레지스터 값의 이전에 세이브된 세트를 복원하며, 엔클레이브의 보호되는 메모리로의 액세스를 허용하도록 페이지 테이블 구성을 변경하고, 엔클레이브 내부의 함수 진입점을 호출할 콘텍스트, 예를 들어 보안 모니터 콘텍스트로 변경할 수 있다. 유사하게, 추상화 플랫폼이 CallEnclaveOut 요청을 수신하는 경우에, 요청은, 엔클레이브 CPU 레지스터를 세이브하고(가능하게는 엔클레이브 메모리에 세이브함) 엔클레이브 클라이언트를 위한 이전에 세이브된 CPU 레지스터를 복원하며, 엔클레이브 메모리로의 액세스를 방지하도록 페이지 테이블 구성을 변경하고, 엔클레이브 외부의 엔클레이브 클라이언트 내의 진입점으로 프로세서 제어를 전이할 하이퍼콜에 의해 네이티브 플랫폼 상으로 발신될 수 있다.

엔클레이브 가능화된 프로세서로써, CallEnclaveIn 요청은, CPU로 하여금 (가능하게는 엔클레이브 메모리로부터) 엔클레이브 CPU 레지스터의 세트를 복원하고 엔클레이브 내부의 함수를 호출(진입점으로 제어를 전이)하게 할 수 있는, EENTER와 같은 명령어를 실행함으로써 네이티브 플랫폼에 발신될 수 있다. CallEnclaveOut 프리미티브는 엔클레이브 외부의 명령어로 제어를 전이하고/하거나 엔클레이브 외부에 제어를 전이하는 장애(fault)를 유발할 수 있는, EEXIT와 같은 명령어를 실행할 수 있다.

단조 카운터는 다양한 용도를 갖는다. 예를 들어, 엔클레이브는 그것의 상태가 도로 복귀될 수 범위를 제한하기를 원할 수 있다. 단조 카운터는, 도 4에 관해 위에서 논의된 바와 같이, 예를 들어, 메시지의 선도를 보장하는 논스로서 사용될 수 있다. 단조 카운터는 일반적으로, 판독될 및 점증될(incremented) 능력을 갖지만, 점감될(decremented) 수가 없다. 엔클레이브의 상태를 복귀시키는 것 또는 롤백(rollback)을 제한하기 위하여, 엔클레이브 내부의 코드는 연관된 단조 카운터를 점증시키고, 이후에 엔클레이브의 내부 상태와 더불어 카운터의 값을 세이브할 수 있다. 상태 및 카운터 값은, 예를 들어, EnclaveSeal 프리미티브로써 세이브될 수 있다. 이후, 예를 들어 EnclaveUnseal 프리미티브를 사용하여, 엔클레이브 상태를 복원하는 경우에, 엔클레이브 내부의 코드는 단조 카운터의 현재 값을 판독할 수 있고 그것을 실링해제된 상태에 있어서의 카운터 값과 비교한다. 실링해제된 상태를 가진 카운터의 값이 카운터의 현재의 값보다 작은 경우, 엔클레이브는 실링해제된 상태의 사용을 방지할 수 있다.

엔클레이브 가능화된 하이퍼바이저로써, 추상화 계층은 엔클레이브에 노출된 하이퍼콜을 행함으로써 단조 카운터를 판독하거나 점증시키기 위해 네이티브 플랫폼에 요청을 발신할 수 있다. 카운터를 읽거나 점증시키는 하이퍼콜이 호출된 경우에, 프로세서는 실행 상태를, 하이퍼콜을 행하는 엔클레이브의 신원을 확인하고, 이후, 예를 들어 TPM 칩과 같은 비휘발성 스토리지 내에 저장된 대응하는 단조 카운터로부터 읽는 것 또는 이를 점증시키는 것을 각각 할 콘텍스트, 예컨대 보안 모니터로 변경할 것이다. 대안적으로 보안 모니터는 원격 신뢰 서버(remote trusted server) 또는 원격 신뢰 서버의 세트 상에 저장된 카운터를 읽거나 점증시킬 수 있는데, 그러한 서버와의 보안 통신 채널을 수립함 및 지정된 단조 카운터를 읽거나 점증시킬 것을 그것에게 요구함에 의해서이다. 원격 신뢰 서버 또는 서버들은 엔클레이브 내부에 카운터를 유지하여 그것을 호스트 컴퓨터 내의 코드의 나머지로부터 격리할 수 있다.

엔클레이브 가능화된 프로세서로써, 명령어를 실행함으로써 네이티브 플랫폼에 요청이 발신될 수 있다. 그러한 프로세서로써, 단조 카운터 프리미티브는 컴퓨터 마더보드(motherboard) 내의 칩 내의 비휘발성 메모리 스토리지 내의 카운터를 읽거나 점증시킴으로써 구현될 수 있다. 대안적으로 이들 프리미티브는 엔클레이브 가능화된 하이퍼바이저에서와 마찬가지로 신뢰 원격 서버를 사용하여 또한 구현될 수 있다.

도 13은 네이티브 엔클레이브 플랫폼을 추상화하는 방법(1300)을 위한 예시적인 흐름도를 묘사한다. 엔클레이브 추상화 플랫폼은 박스(1302)에서 엔클레이브 또는 엔클레이브 클라이언트로부터 요청을 수신할 수 있다. 박스(1304)에서, 추상화 플랫폼은, 예를 들어, 네이티브 플랫폼이 SGX에 부합되는지를 판정함으로써, 네이티브 플랫폼이 엔클레이브 프로세서 명령어를 포함하는지를 판정할 수 있다. 만일 그렇다면, 박스(1306)에서 엔클레이브 프로세서 명령어가 실행된다. 박스(1308)에서, 추상화 플랫폼은, 예를 들어 네이티브 플랫폼이 VSM에 부합되는지를 판정함으로써, 네이티브 플랫폼이 엔클레이브 하이퍼콜을 포함하는지를 판정할 수 있다. 만일 그렇다면, 네이티브 플랫폼은 엔클레이브 하이퍼콜을 행한다. 엔클레이브 명령어를 실행하는 것 또는 엔클레이브 하이퍼콜을 호출하는 것으로부터의 결과는 박스(1312)에서 일소된다(cleaned up). 일소는, 예를 들어, 엔클레이브 하이퍼콜 또는 엔클레이브 프로세서 명령어의 예외 핸들링 또는 출력 파라미터를 추상화 계층 인터페이스의 포맷 또는 프로토콜로 변환하는 것을 포함할 수 있다. 변환된 출력 파라미터는 이후 박스(1314)에서 원래의 요청자(엔클레이브 또는 클라이언트)에 리턴된다.

추상적 엔클레이브 신원

도 14는 엔클레이브를 인스턴스화하는 데에 사용되는 예시적인 엔클레이브 바이너리 이미지를 묘사한다. 엔클레이브는 엔클레이브 컨테이너(1490)와 같은 보안 컨테이너를 생성하고, 하나 이상의 엔클레이브 이미지의 부분을 컨테이너 내에 복사함으로써 인스턴스화될 수 있다. 엔클레이브 컨테이너(1490)는 일차적 엔클레이브 이미지(1410)에 대한 참조에 의해 생성되었을 수 있다. 일차적 이미지는 다른 종속적 엔클레이브 이미지에 대한 참조를 포함할 수 있다. 이 예에서, 일차적 이미지(1410)는 종속적 엔클레이브 이미지(1420 및 1450)에 대한 참조로서 각각 종속성1(Dependency1) 및 종속성2(Depencency2)를 포함한다. 이미지(1420)는 이미지(1430 및 1440)에 대한 추가의 종속성을 포함하는 한편, 이미지(1450)는 이미지(1460)에 의존한다. 일단 모든 이 이미지들(또는 이의 부분)이 컨테이너(1490) 내에 복사되면, 결과적인 엔클레이브는 비-플랫폼 이미지(1402)(이는 인스턴스화된 엔클레이브에 고유하거나 특정적인 코드 및 데이터를 포함할 수 있음)와, 추상화 플랫폼(1404) 이미지와, 네이티브 플랫폼 이미지(1406)를 포함할 수 있다.

각각의 엔클레이브 이미지, 예컨대 일차적 이미지(1410)는, ID, 종속성, 코드, 데이터, 그리고 이미지의 작성자의 시그니처를 포함할 수 있다. 이미지(1410)의 예에서, 2개의 ID(1410.1 및 1410.2)가 포함된다. 이들 ID는, 예를 들어, 개별적으로 또는 집합적으로, 해당 엔클레이브 이미지로써 인스턴스화된 임의의 엔클레이브를 식별하는 데에 사용될 수 있는 ImageID, FamilyID 또는 AuthorID 값에 대응하는 추상적 신원 값을 지정하는 UUID일 수 있다. 묘사된 바와 같이, 이미지(1410)는 두 ID를 갖지만, 더 적거나 더 많은 ID가 실현가능하다. 이미지(1410) 내의 코드는 엔클레이브 컨테이너(1490)를 호스팅하는 컴퓨터의 프로세서에 의해 실행가능한 바이너리 명령어일 수 있다. 이미지(1410) 내의 데이터는 컨테이너(1410) 내에 로딩된 임의의 코드에 의해 사용될 수 있다. 이미지(1410)는 ID, 종속성 참조, 코드 및 데이터와 같은, 이미지의 다른 콘텐츠 중 임의의 것 또는 전부의 무결성을 보장하는 시그니처 Sig 1410를 또한 포함할 수 있다. 다른 이미지(1420 내지 1460)는 유사하게 ID, 종속성 참조, 코드, 데이터 및 시그니처를 포함할 수 있다.

종속성 지시자(dependency indicator), 예컨대 이미지(1410)의 종속성1 및 종속성2, 이미지(1420)의 종속성1 및 종속성 2, 그리고 이미지(1450)의 종속성 1은, 다양한 방식으로 지정될 수 있다. 이미지(1410 내지 1460)가 컴퓨터 시스템의 메모리 내에 저장된 경우, 종속성 지시자는 단순히 메모리 내의 주소일 수 있다. 엔클레이브 이미지가 파일 시스템 내의 파일인 경우, 참조는 파일 이름일 수 있다. 몇몇 실시예에서, 참조는 논리적 식별자일 수 있다. 논리적 식별자는 UUID와 같은 고유 번호일 수 있거나, 달리 종속성 이미지를 식별하는, 텍스트 스트링과 같은 다른 데이터일 수 있다. 예를 들어, 텍스트 스트링은 종속적 바이너리 이미지의 작성자, 소스, 제품 명칭(product name), 제품 계통(product family) 및/또는 버전 번호(version number)를 나타낼 수 있다. 논리적 식별자는 웹 또는 인터넷 위치, 예컨대 종속적 바이너리의 사본이 검색될 수 있는 위치를 포함한다.

몇몇 실시예에서, 엔클레이브 이미지 파일은 참조된 엔클레이브 이미지의 현재 버전 또는 로컬 사본에 대한 포인터를 찾기 위하여 엔클레이브 이미지의 레지스트리(registry) 내에서 논리적 식별자와 같은 종속성 지시자를 찾아봄으로써 위치 파악이 될 수 있다. 몇몇 경우에, 신뢰되는 서비스는 종속성 지시자를 특정한 엔클레이브 이미지 또는 이미지 위치의 식별로 분석해내는(resolve) 데에 사용될 수 있다.

몇몇 실시예에서, 종속성 지시자는 의도된 종속적 엔클레이브 바이너리 이미지의 암호학적 해시와 같은 암호학적 보안 식별자(cryptographically secure identifier)일 수 있다. 그러한 해시는 종속적 바이너리의 전부, 또는 이의 오직 일부분을 포함할 수 있다. 종속성 지시자에 포함된 종속적 바이너리의 부분은 추상적 신원 값, 예컨대 ID(1401.1) 또는 ID(1420.2)를 포함할 수 있고, 추상적 신원 값일 수 있다. 암호학적 보안 식별자를 위한 분석 서비스는 논리적 식별자와 마찬가지로 신뢰되는 것일 필요는 없을 수 있는데, 엔클레이브 종속성을 판정하는 개체는 종속적 바이너리 그 자체의 해시를 계산함으로써 정확한 종속적 이미지가 발견되었음을 확인하는 것이 가능할 수 있기 때문이다.

도 15는 추상적 엔클레이브 신원으로써 엔클레이브 동작을 수행하는 방법(1500)을 위한 예시적인 흐름도를 묘사한다. 엔클레이브를 위한 추상적 신원 값은 어떤 특징을 공통으로 갖지만 정확히 동일하지는 않은 두 엔클레이브 간의 동등성을 판정하기 위한 근거를 제공할 수 있다. 신원 값은 증명 보고 내에 포함될 수 있고 추상적 신원 타입(예컨대 ExactHash, InstanceHash, ImageID, FamilyID 또는 AuthorID)과 연관될 수 있다. 정확히 동일하지는 않은 두 엔클레이브는 추상적 신원 타입을 위한 동일한 추상적 신원 값을 가질 수 있다. 추가적으로, 두 개의 상이한 네이티브 엔클레이브 플랫폼 상에서 보안 컨테이너 내로 인스턴스화된 동일한 엔클레이브 코드는 또한 동일한 추상적 신원 값을 가질 수 있다. 방법(1500)은, 예를 들어, 네이티브 엔클레이브 플랫폼 및 엔클레이브 아니면 엔클레이브 클라이언트 간의 추상화 플랫폼 계층에 의해 수행될 수 있다.

박스(1502)에서, 엔클레이브는 도 14의 일차적 엔클레이브 이미지(1410)와 같은 엔클레이브 이미지로부터 인스턴스화된다. 엔클레이브 이미지는 엔클레이브 코드, 데이터, 신원의 리스트, 임의의 종속적 엔클레이브 이미지의 리스트 및 시그니처를 포함하는 일차적 이미지일 수 있다. 엔클레이브 이미지의 무결성을 보장하기 위하여, 이미지는 엔클레이브 이미지의 작성자에 대응할 수 있는 개인 키로써 서명될 수 있다. 엔클레이브 이미지 내의 엔클레이브 신원 ID의 리스트는, 다른 관련된 엔클레이브 이미지와 더불어 집합적으로 엔클레이브 이미지를 식별하도록 각각 의도된 ImageID, FamilyID 및 AuthorID와 같은 추상적 신원 타입에 대응할 수 있다. 종속적 엔클레이브 이미지의 리스트는 일차적 엔클레이브 이미지 내의 코드가 의존하는 엔클레이브 코드를 포함하는 다른 엔클레이브 이미지를 참조할 수 있다. 종속적 엔클레이브 이미지는 동일한 작성자에 의해 작성될 수 있거나 그렇지 않을 수 있고, 몇몇 종속적 엔클레이브 이미지는 일차적 엔클레이브 이미지 또는 일차적 엔클레이브 이미지의 작성자와 특별히 연관된다기보다는 일반적으로 엔클레이브 플랫폼(추상화 플랫폼이든 또는 네이티브 플랫폼이든)과 연관될 수 있다. 엔클레이브는 임의의 네이티브 엔클레이브 플랫폼을 사용하여 보안 엔클레이브 컨테이너를 생성함 및 일차적 이미지 및 임의의 종속적 엔클레이브 이미지의 일부분 또는 전부를 보안 컨테이너 내에 복사함으로써 인스턴스화될 수 있다.

박스(1503)에서, 엔클레이브 신원 타입과 더불어, 예를 들어 엔클레이브 또는 엔클레이브 클라이언트에 의해, 엔클레이브 동작이 요청된다. 신원 타입은 추상적 신원의 타입, 예컨대 ImageID 또는 AuthorID를 지정하고, 특정한 인스턴스화된 엔클레이브에 관련될 수 있으나, 그 엔클레이브를 위한 AuthorID 값을 지정하지는 않는다. 박스(1503)에 후속하는 방법(1500)의 나머지는 인스턴스화된 엔클레이브가 인스턴스화된 엔클레이브의 그 신원 타입에 대해 도출된 신원 값을 사용하는 (증명, 데이터 실링, 또는 단조 카운터의 사용, 기타 등등과 같은) 동작을 수행하기 위한 동작을 기술한다. 신원은 엔클레이브 이미지(들)의 서브세트의 해시를 사용하여 판정될 수 있다. 엔클레이브 이미지(들)의 어느 서브세트가 해시로의 입력으로서 사용되는지는 엔클레이브 동작에서 사용되도록 요망되는 신원 타입에 부분적으로 기반할 수 있다.

박스(1504)에서, 본 문서에서 신원 부분(identity portion)으로 불리는, 엔클레이브 이미지의 일부분이 신원 타입에 기반하여 판정된다. 신원 부분은 박스(1502)에서 엔클레이브를 인스턴스화하는 데에 사용된 다양한 엔클레이브 바이너리 이미지 중 전부 또는 일부를 포함할 수 있거나 그 중 아무 것도 포함하지 않을 수 있다. 신원 부분은 엔클레이브 이미지 내에 포함된 엔클레이브 코드의 전부 또는 일부를 포함할 수 있거나 그 중 아무 것도 포함하지 않을 수 있다. 신원 부분은 포함된 엔클레이브 이미지의 비-코드 부분 내에 나열된 0개의, 하나의 또는 그보다 많은 신원 ID를 또한 포함할 수 있다. 신원 부분은 엔클레이브 이미지에 포함된 엔클레이브 데이터를 또한 포함할 수 있거나 그렇지 않을 수 있다. 신원 부분은 엔클레이브 이미지의 이들 다양한 부분의 임의의 조합을 포함할 수 있다. 예를 들어, 신원 부분은 모든 코드를 포함하고, 데이터 중 아무 것도 포함하지 않으며, 2개 또는 4개의 가용 신원 ID를 포함할 수 있다. 선택적인 박스(1506)에서, 어느 종속적 엔클레이브 이미지가 신원 부분에 포함될 것인지가 판정되고, 각각의 포함된 이미지의 신원 부분이 판정된다.

종속적 이미지의 신원 부분은 일차적 엔클레이브 이미지의 신원 부분과 동일할 수 있거나 그렇지 않을 수 있다. 예를 들어, 모든 코드 및 ImageID가 일차적 이미지의 신원 부분 내에 포함되는 한편, 종속적 이미지의 어떠한 코드도 종속적 이미지의 신원 부분에 포함되지 않을 수 있고 종속적 이미지의 FamilyID만 이에 포함될 수 있다.

엔클레이브 코드가 신원 부분에 포함된 경우, 신원 부분에서의 엔클레이브 코드의 부분은 어느 종속성이 신원 부분에 포함될 것인지의 표시 및 신원 타입의 조합에 의해 판정될 수 있다. 신원 타입 InstanceHash는, 예를 들어, 일차적 이미지 내의 엔클레이브 코드를 포함할 수 있으나, 어떤 종속적 이미지도 포함하지 않는 반면, 신원 타입 ExactHash는 엔클레이브 플랫폼의 일부로 간주되지 않는 모든 종속적 이미지 내의 엔클레이브 코드를 포함할 수 있다. 예를 들어, 엔클레이브 플랫폼 작성자의 개인 키로써 서명되지 않은 모든 종속적 엔클레이브 이미지는 엔클레이브 플랫폼의 일부가 아니라고 간주될 수 있다. 대안적으로 또는 추가로, 일차적 이미지는 InstanceHash 또는 ExactHash 신원 타입을 위해 신원 부분 내에 어느 종속적 엔클레이브 이미지가 포함되거나 배제될 것인지의 리스트를 포함할 수 있다.

엔클레이브 신원 ID는 엔클레이브 이미지 내에 메타데이터로서 포함될 수 있는데, 엔클레이브 코드 대신에 또는 이에 더하여 엔클레이브 이미지의 신원 부분 내에 포함될 수 있다. 예를 들어, 신원 타입 ImageID, FamilyID 및 AuthorID를 위한 신원 부분은 엔클레이브 이미지로부터의 대응하는 ID 메타데이터를 포함할 수 있다. 신원 타입이 내포되거나 계층화된 경우, 더 낮은 수준 타입을 위한 신원 부분은 더 높은 수준 타입을 위한 ID 데이터를 포함할 수 있다. 예를 들어, ImageID를 위한 신원 부분은 ImageID, FamilyID 및 AuthorID를 위한 ID 데이터를 포함할 수 있는 반면, AuthorID를 위한 신원 부분은 AuthorID를 위한 ID 데이터를 포함할 뿐일 수 있다.

InstanceHash 및 ExactHash와 같은, 엔클레이브 코드를 포함하는 신원 타입은, 어떤 엔클레이브 코드가 엔클레이브 내부에서 가동되고 있다는 더 높은 수준의 보증을, 예를 들어 엔클레이브 클라이언트에 증명을 통해 제공한다. 그러나, 엔클레이브의 신원은 엔클레이브의 신원 부분 중 어떤 것이든 바뀌는 경우에 반드시 바뀔 것이다. 예를 들어, 보안 수정(security fix) 또는 다른 버그가 엔클레이브 이미지의 새로운 버전에서 고쳐진 경우, 새로운 코드에 기반한 결과적인 신원 값은 또한 바뀔 것이다. 엔클레이브 코드의 어떤 부분이 신원 해시 계산으로부터 배제되기 위한 메커니즘을 제공함으로써 엔클레이브의 신원은 엔클레이브 코드의 배제된 부분에의 변경과는 무관해질(decoupled) 수 있다. 예를 들어, 하나의 작성자의 엔클레이브 코드가 엔클레이브 플랫폼에 의해 제공된 엔클레이브 코드에 의존하는 경우에, 엔클레이브 신원은 의존하는 플랫폼에 대한 정정과는 무관해질 수 있다.

박스(1508)에서, 신원 값이 판정되는데 이는 박스(1502)에서 인스턴스화된 엔클레이브의 신원을 나타낼 수 있다. 신원 값은 엔클레이브 이미지 또는 이미지들의 이전에 판정된 신원 부분 상에서 해시를 계산함으로써 판정될 수 있다(신원 값은 해시 함수의 출력인데 신원 부분이 해시 함수에 대한 입력임). 몇몇 실시예에서, 해시 함수에 대한 입력은 원래의 엔클레이브 이미지(들)의 부분일 것인 반면, 다른 실시예에서, 해시 함수에 대한 입력은 이미지의 신원 부분을 컨테이너 내에 복사(하고 가능하게는 원래의 엔클레이브 이미지가 암호화된 경우에는 신원 부분을 복호화)한 후의 엔클레이브 컨테이너의 부분일 것이다.

박스(1510)에서, 결과적인 신원 값의 무결성은 원래의 엔클레이브 이미지(들)의 무결성을 확인함으로써 선택적으로 확인될 수 있다. 엔클레이브 이미지의 무결성은 엔클레이브 이미지를 서명하는 데에 사용된 개인 키에 대응하는 공개 키로써 확인될 수 있다. 그러한 공개/개인 키 쌍은, 예를 들어, 엔클레이브 이미지(들)의 작성자와 연관될 수 있어서, 결과적인 신원 값에 대한 신뢰는 엔클레이브의 작성자의 신뢰에 근본을 둘 수 있다.

끝으로, 박스(1512)에서, 인스턴스화된 엔클레이브에 관련된 동작이 신원 값을 사용하여 수행될 수 있다. 예를 들어: 인스턴스화된 엔클레이브의 증명 보고가 신원 타입에 대해 생성되거나 확인될 수 있고; 신원에서 데이터가 인스턴스화된 엔클레이브에 실링되거나 이로부터 실링해제될 수 있고; 인스턴스화된 엔클레이브 및 신원 타입에 결부된 단조 카운터 또는 신뢰 시간이 사용될 수 있다.

더 높은 수준의 신원 타입을 사용하는 엔클레이브 동작은 가능한 엔클레이브 인스턴스화의 그룹 간의 상호작용을 가능하게 한다. 고수준 신원 타입에 대한 증명은 동일한 고수준 신원을 갖는 모든 엔클레이브를 위해 증명 보고 동등성을 제공할 수 있다. 예를 들어, AuthorID 신원 타입에 대한 증명 보고는 동일한 AuthorID 메타데이터를 포함하는 일차적 이미지로부터 인스턴스화된 모든 엔클레이브로부터의 증명 보고와 동등할 수 있다. 고수준의 신원 타입에 실링된 데이터는 동일한 고수준 신원 값을 가진 임의의 엔클레이브에 의해 실링해제될 수 있다. 예를 들어, AuthorID 신원 타입을 갖는 인스턴스화된 엔클레이브에 실링된 데이터는 그것의 엔클레이브 일차적 이미지 내에 동일한 AuthorID 메타데이터를 가진 임의의 다른 인스턴스화된 엔클레이브에 의해 실링해제될 수 있다.

엔클레이브 신원 동등성

도 16은 추상적 엔클레이브 신원 동등성을 가진 예시적인 시스템을 묘사한다. 엔클레이브 클라이언트(1602)는 추상화 플랫폼(1614)을 통해 제1 네이티브 플랫폼(1616)의 보안 엔클레이브 컨테이너 내에 인스턴스화된 제1 엔클레이브(1612)와 통신할 수 있고, 클라이언트(1602)는 추상화 플랫폼(1624)을 통해 제2 네이티브 플랫폼(1626)의 보안 엔클레이브 컨테이너 내에 인스턴스화된 제2 엔클레이브(1622)와 또한 통신할 수 있다. 제1 네이티브 플랫폼(1616)은 제2 네이티브 플랫폼과 동일한 컴퓨터 상에 주재할 수 있거나 그렇지 않을 수 있다. 엔클레이브 클라이언트(1602)는 네이티브 플랫폼 중 어느 쪽과든 동일한 컴퓨터 상에 주재할 수 있거나, 별개의 제3 컴퓨터 상에 주재할 수 있다. 제1 네이티브 플랫폼(1616)은 제2 네이티브 플랫폼(1626)과 동일하지 않을 수 있다. 예를 들어 제1 네이티브 플랫폼(1616)은 동일한 네이티브 플랫폼 제조자로부터의 제2 네이티브 플랫폼의 더 오래된 버전일 수 있다. 혹은, 제1 네이티브 플랫폼(1616) 및 제2 네이티브 플랫폼(1626)은 VSM 및 SGX와 같은 완전히 상이한 엔클레이브 아키텍처에 부합할 수 있다.

엔클레이브 클라이언트는 증명 보고로부터 도출된 신원 값을 비교함으로써 엔클레이브가 동등함을 보안적으로 판정할 수 있다. 엔클레이브 클라이언트(1602)는 제1 엔클레이브(1612) 및 제2 엔클레이브(1622)로부터 별개의 증명 보고를 수신함으로써 엔클레이브 각각을 보안적으로 식별할 수 있다. 신원 값은 이들 증명 보고 각각에 포함(되거나 이로부터 도출)될 수 있다. 신원 값이 동일한 경우, 엔클레이브 클라이언트(1602)는 제1 엔클레이브(1612) 및 제2 엔클레이브(1622)가 어떤 의미에서 동등하다는 확신을 가질 수 있다. 증명 보고로부터의 신원 값은 특정한 추상적 신원 타입(예컨대 ExactHash, InstanceHash, ImageID, FamilyID, 또는 AuthorID)에 대응하는 추상적 신원 값, 또는 그러한 추상적 신원 값의 해시일 수 있다. 이 경우에, 동등성이 판정될 수 있는데 엔클레이브가 정확히 동일하지는 않다. 두 엔클레이브는 정확히 동일하지 않지만, 예를 들어 엔클레이브 컨테이너 내로 로딩된 엔클레이브 이미지가 동일한 기능의 상이한 버전, 또는 상이한 종속적 이미지를 갖는 동일한 일차적 이미지, 또는 상이한 엔클레이브 아키텍처의 엔클레이브 컨테이너 내로 로딩된 동일한 엔클레이브 이미지인 경우에, 여전히 동등하다고 판정될 수 있다.

제1 엔클레이브(1612)는 동등하다고 간주되나 다양한 상황에 있어서 제2 엔클레이브(1622)와 동일하지 않을 수 있다. 제1 예에서, 엔클레이브 컨테이너 내로 초기에 로딩된 코드의 서브세트만이 동일하다(예를 들어, 추상적 신원 타입 ExactHash 또는 InstanceHash에 대해 동등함). 제2 예에서, 엔클레이브 코드의 작성자는 두 개의 상이한 엔클레이브 바이너리 이미지 내에, 설사 그 두 바이너리 이미지 내의 코드가 상이한 경우에도, 동일한 ID를 포함시켰을 수 있다(예를 들어, 신원 타입 ImageID, FamilyID 또는 AuthorID에 대해 동등함). 제3 예에서, 각각의 엔클레이브 내의 코드가 전적으로 동일하지만, 상이한 네이티브 플랫폼 상으로 로딩된다(인스턴스화된다). 이 제3 예에서, 제1 네이티브 플랫폼(1616) 및 제2 네이티브 플랫폼(1626)은 상이한 제조자에 의해 제조될 수 있고 따라서 상이한 증명 보고의 신뢰는 상이한 제조자의 상이한 증서 인가(도 7, 요소(738)를 보시오)에 근본을 둔다. 두 네이티브 플랫폼이 상이한 예가 서버 팜(server farm) 내에 또는 클라우드 컴퓨팅(cloud computing) 내에 있는데 여기서 제1 및 제2 엔클레이브의 처리 작업부하를 위해 할당된 서버는 동일한 네이티브 엔클레이브 플랫폼을 지원하지 않는 서버이다.

대체 실시예에서, 제1 엔클레이브는 제2 엔클레이브의 클라이언트일 수 있는바 박스(1602 및 1612)는 조합된다. 이 실시예에서 엔클레이브 동등성을 판정하는 것은, 제1 엔클레이브 내에서, 제2 엔클레이브의 증명 보고로부터의 신원 값이 (특정한 추상적 신원 수준에서) 제1 엔클레이브 자신의 신원 값과 동일함을 판정하는 것을 포함할 수 있다.

도 17은 두 개의 동등한 엔클레이브로써의 병렬 처리를 위한 예시적인 흐름도를 묘사한다. 프로세스(1700)는, 예를 들어, 둘 이상의 상이한 엔클레이브의 클라이언트에 의해 수행될 수 있다. 박스(1702)에서, 예를 들어 도 16에서 묘사된 바와 같이, 상이한 네이티브 플랫폼 인스턴스 상에서 두 엔클레이브가 인스턴스화된다. 엔클레이브는 추상화 플랫폼(1614 및 1624)의 CreateEnclave 메쏘드를 통해 (도 14의 일차적 이미지(1410)와 같은) 엔클레이브 바이너리 이미지를 엔클레이브 클라이언트가 지정함으로써 인스턴스화될 수 있다. 두 엔클레이브를 인스턴스화하기 위하여 지정된 엔클레이브 바이너리 이미지는 동일하거나 상이할 수 있다. 박스(1704)에서 각각의 인스턴스화된 엔클레이브를 위한 증명 보고가 생성된다. 증명 보고는, 예를 들어, 엔클레이브 클라이언트의 요청으로 또는 엔클레이브 그 자체의 요청으로 생성될 수 있다. 두 엔클레이브의 동등성을 판명하기를 희망하는 개체, 예컨대 엔클레이브 클라이언트는, 두 증명 보고 모두의 사본을 획득한다. 박스(1706)에서 증명 보고는 선택적으로 확인될 수 있다. 예를 들어, 보고의 무결성은 증명 보고를 산출한 네이티브 플랫폼의 승인 증서(예컨대 도 7, 요소(728))로써 증명 시그니처를 확인함으로써 확인될 수 있다. 또한, 승인 증서는 네이티브 플랫폼 제조자의 공개 키(예컨대 도 7, 요소(732))로써 확인될 수 있다. 박스(1708)에서 신원 값(또는 이의 해시)은 각각의 증명 보고로부터 추출될 수 있고, 두 엔클레이브의 동등성은 추출된 신원 값이 각 엔클레이브에 대해 동일함을 확인함으로써 판정될 수 있다. 이들 신원 값은 신원 타입과 연관된 추상적 신원 값(또는 이의 해시)일 수 있다.

일단 엔클레이브 클라이언트가 박스(1708 및 1710)에서의 동작으로부터 두 엔클레이브 인스턴스화의 동등성을 엔클레이브 클라이언트가 판명하였다면, 도시된 동등성의 타입에 따라, 두 엔클레이브는 교환가능하게 사용될 수 있다. 박스(1712 내지 1720)는 두 개의 인스턴스화된 동등한 엔클레이브를 병렬 처리 방식으로 사용하기 위해 동등한 엔클레이브를 사용하는 예시적 방법을 묘사한다. 박스(1712 및 1716)에서, 입력 데이터세트의 부분, 예컨대 데이터베이스의 부분 또는 디지털 이미지 파일의 부분이, 제1 및 제2 엔클레이브 내에 복사된다. 복사된 데이터세트의 부분은 당면한 처리 작업에 따라 동일하거나 상이할 수 있다. 처리 동작은 동시에 부분적으로 박스(1714)에서 제1 엔클레이브 내에서 동작을 수행하고 부분적으로 박스(1718)에서 제2 엔클레이브 내에서 동작을 수행함으로써 병렬로 보안적으로 수행될 수 있다. 동작은, 예를 들어, 데이터베이스를 탐색하거나 이미지 처리 동작을 수행하는 것일 수 있다. 제1 엔클레이브는 데이터베이스의 제1 반절(half)을 탐색하거나 이미지의 제1 반절에 대해 이미지 처리 동작을 수행할 수 있는 반면, 제2 엔클레이브는 데이터베이스의 제2 반절을 탐색하거나 이미지의 제2 반절에 대해 이미지 처리 동작을 수행할 수 있다. 끝으로, 박스(1720)에서, 제1 및 제2 엔클레이브에서의 병렬 처리의 결과는, 예를 들어 데이터베이스의 두 정렬된 반절을 조합하거나, 두 이미지 반절을 도로 합함으로써 조합될 수 있다.

도 18은 두 개의 동등한 엔클레이브로써의 직렬 처리를 위한 예시적인 흐름도를 묘사한다. 도 18에 묘사된 바와 같이, 엔클레이브 동작, 예컨대 데이터베이스 동작 또는 이미지 처리 동작은, 두 개의 별개의 엔클레이브 내의 두 개의 순차적 부분에서 보안적으로 행해진다. 프로세스(1800)는, 예를 들어, 도 16의 엔클레이브 클라이언트(1602)에 의해 수행될 수 있다. 박스(1802)에서, 제1 엔클레이브는 제1 네이티브 엔클레이브 플랫폼 상에서 생성되고, 박스(1804)에서 제1 엔클레이브의 증명 보고가 생성된다. 박스(1806)에서, 예를 들어 도 17의 박스(1706)에 관해 위에서 기술된 바와 같이, (제1 엔클레이브의) 이 제1 증명 보고가 확인될 수 있다. 박스(1808)에서, 보안 동작이 제1 엔클레이브에서 시작되나, 완료되지 않는다. 박스(1810)에서 제1 엔클레이브의 상태는 제1 엔클레이브 밖으로 안전하게 이동되도록 선택적으로 실링될 수 있다. 예를 들어 제1 엔클레이브 상태는 제1 엔클레이브의 신원 타입에 실링될 수 있다. 일단 엔클레이브 상태가 세이브되었다면, 제1 엔클레이브는 종결될 수 있다(도시되지 않음).

제2 엔클레이브는 박스(1812)에서 시작하여 사용된다. 박스(1812)에서, 제2 엔클레이브는 제2 네이티브 플랫폼 상에 인스턴스화된다. 도 16 및 도 17에서와 같이, 제2 네이티브 플랫폼은 제1 네이티브 플랫폼과 동일한 컴퓨터 상에 호스팅될 수 있거나 그렇지 않을 수 있고, 제1 및 제2 네이티브 플랫폼은 동일하거나 상이할 수 있다. 박스(1814)에서 제2 네이티브 플랫폼의 증명 보고가 생성되고, 선택적으로, 박스(1816)에서 이 제2 증명 보고가 확인될 수 있다. 박스(1818)에서 제1 및 제2 증명 보고로부터의 신원 값은 제1 및 제2 엔클레이브의 동등성을 확인하기 위하여 비교될 수 있다. 대체 실시예에서, 박스(1808)에서 제1 엔클레이브 내에서 보안 동작이 시작되기 전에 제2 엔클레이브가 인스턴스화되고 동등성 확인될 수 있다(박스(1812 내지 1818)). 제1 엔클레이브에서 시작된 보안 동작을 계속하기 위하여, 제1 엔클레이브로부터의 실링된 상태는 박스(1820)에서 제2 엔클레이브 내로 복사되고 실링해제될 수 있다. 박스(1822)에서, (제1 엔클레이브로부터 보안적으로 복사된 엔클레이브 상태를, 그 상태가 복사되었다면 사용하여) 제2 엔클레이브 내에서 보안 동작이 완료된다.

분산 데이터 실링

도 19는 예시적인 분산 데이터 실링 시스템의 블록도이다. 데이터 실링은 여러 엔클레이브에 걸쳐서 분산될 수 있는데, 그 엔클레이브들은 별개의 네이티브 엔클레이브 플랫폼 상에서, 그리고/또는 별개의 컴퓨터 상에서 호스팅된다. 위에서 설명된 바와 같이, EnclaveSeal 및 EnclaveUnseal 추상화 프리미티브는 엔클레이브가 가동되고 있는 네이티브 엔클레이브 플랫폼 또는 물리적 컴퓨터에 결부된 키를 사용하여 엔클레이브를 위한 데이터를 실링하고 실링해제할 수 있다. 이것은 동일한 컴퓨터 또는 동일한 네이티브 엔클레이브 플랫폼 인스턴스 상에서 호스팅되는 엔클레이브에만 실링해제를 제한할 수 있다. 도 19는 분산 데이터 실링 시스템을 묘사하는데, 데이터를 실링하거나 실링해제하는 것은 엔클레이브를 호스팅하는 네이티브 플랫폼 및 컴퓨터와는 상이한 네이티브 플랫폼 또는 컴퓨터 상에서 발생할 수 있다. 시스템(1900)은 컴퓨터(1910, 1930, 1950)를 포함하는데, 네트워크(1902)는 컴퓨터(1910 및 1930)를 연결하고, 네트워크(1304)는 컴퓨터(1930 및 1950)를 연결한다. 컴퓨터(1910)는 소스 엔클레이브(source enclave)(1912)(실링될 데이터가 이로부터 조달될 수 있음)를 호스팅하고; 컴퓨터(1930)는 분산된 실링 및 실링해제 요청을 서비스하기 위한 분산 실링 엔클레이브(Distributed Sealing Enclave: DSE)(1932)를 호스팅하며; 컴퓨터(1950)는 이전에 실링된 데이터가 실링해제되는 목적지 엔클레이브(destination enclave)(1952)를 호스팅한다. 도 9에 관해 위에서 설명된 바와 같이, 엔클레이브(1912, 1932, 1952)는 엔클레이브 추상화 프로토콜을 통해 각각 추상화 플랫폼(1914, 1934, 1954)와 통신할 수 있고, 추상화 플랫폼(1914, 1934, 1954)은 네이티브 프로토콜을 통해 각각 네이티브 플랫폼(1916, 1936 및 1956)과 통신할 수 있다. 대체 실시예에서, 하나 이상의 엔클레이브(1912, 1932, 1950)는 매개 추상화 플랫폼 없이 네이티브 플랫폼(1961, 1936, 1956) 상에서 직접적으로 호스팅될 수 있다. 실링된 데이터(1938)는 DSE(1932) 또는 그것의 호스팅 네이티브 플랫폼(1936)과 연관된 키를 사용하여 DSE(19322)에 실링된 데이터일 수 있다. 실링된 데이터(1938)는 덜 보호되는 위치에, 예컨대 DSE(1932)의 보안 엔클레이브 컨테이너 외부의 컴퓨터(1930) 상에, 예를 들어 컴퓨터(1930)의 메모리 공간 내에서 다른 데에 또는 하드 디스크의 파일 시스템 내에 저장될 수 있다.

분산 데이터 실링은, 예를 들어 네트워크(1902)를 통한 DSE(1932)의 증명에 의해, 소스 엔클레이브에의 DSE(1930)의 인증(authentication)을 포함할 수 있다. 일단 소스 엔클레이브(1912)가 DSE(1932)를 신뢰하면, 소스 엔클레이브(1912)는 DSE(1932)에 의한 실링을 위해 실링 정책과 더불어 DSE(1932)에 보안 통신 채널을 통하여 민감한 데이터를 발신할 수 있다. 그러면 DSE(1932)는 엔클레이브(1912)로부터의 데이터를 그 자체가 실링하고 실링된 데이터를 비보안 스토리지 내에 저장할 수 있다. 이후, 목적지 엔클레이브(1952)는 이전에 실링된 데이터를 요청할 수 있다. 데이터를 실링해제하기 위하여, DSE(1932)는, 예를 들어 네트워크(1904)를 통한 증명에 의해, 목적지 엔클레이브(1952)를 인증하고, 소스 엔클레이브(1912)에 의해 제공된 실링 정책에 따라 목적지 엔클레이브(1952)를 위한 실링해제가 허가됨을 확인할 수 있다. DSE(1932)는 소스 엔클레이브(1912)로부터의 이전에 실링된 데이터를 실링해제하고, 실링해제된 데이터를 이후에 보안 통신 채널을 통하여 목적지 엔클레이브(1952)에 발신할 수 있다. 엔클레이브 데이터는 네트워크(1902 및 1904)를 통하여 엔클레이브 데이터를 암호화함으로써 DSE(1932)에, 그리고 이로부터 보안적으로 통신될 수 있다. 예를 들어, 네트워크(1902)를 통하여 발신된 엔클레이브 데이터는 소스 엔클레이브(1912)에 대한 DSE(1932)의 증명 동안에 생성된 키로써 암호화될 수 있고, 네트워크(1904)를 통하여 발신된 데이터는 DSE(1932)에 대한 목적지 엔클레이브(1952)의 증명 동안에 생성된 키로써 암호화될 수 있다. 다른 보안 통신 채널이 가능한데, 예컨대 목적지의 공개 키, 예를 들어 DSE와 연관된 공개 키 또는 목적지 엔클레이브와 연관된 공개 키로써 암호화하는 것이다.

분산 실링 및 실링해제에서 사용되는 엔클레이브 신원은 추상적 엔클레이브 신원일 수 있거나 그렇지 않을 수 있다. 예를 들어, 추상화 플랫폼 계층이 있는 몇몇 실시예에서, 실링 정책, 예컨대 소스 엔클레이브에 의해 지정되고 DSE에 의해 승인된 것은, 허가된 실링해제 엔클레이브 신원을 식별할 수 있는데 허가된 실링해제 엔클레이브 신원은, 예를 들어, 추상적 엔클레이브 신원의 리스트, 또는 소스 엔클레이브의 추상적 신원 값과의 조합이 된 추상적 신원 타입의 리스트이다. 다른 상황에서, 추상적이지 않은(non-abstract) 신원이 사용될 수 있다. 예를 들어, 몇몇 실시예에서, DSE는 공개적 이용가능 코드로써 구현될 수 있어서, DSE에 대한 신뢰는 그것의 코드의 작성자에 대한 신뢰가 아니라 그것의 코드에 대해 아는 바에 대한 신뢰이다. 이 예에서, DSE의 증명은 DSE의 공개 코드의 전부의 서명된 해시일 수 있고, 해시 함수에 대한 입력은 작성자에 의해 할당된 추상적 신원 값을 포함하지 않을 수 있다.

몇몇 실시예에서 네이티브 플랫폼(1916, 1936, 1956)은 별개의 네이티브 플랫폼인데, 설사 네이티브 플랫폼((1916, 1936, 1956)이 동일한 네이티브 엔클레이브 플랫폼 아키텍처의 동일한 버전을 따르더라도, 그것들이 상이한 컴퓨터(1910, 1930, 1950) 상에서 호스팅되기 때문이다. 다른 실시예에서, 네이티브 플랫폼(1916, 1936, 1956)은 상이한 플랫폼 아키텍처 또는 동일한 네이티브 엔클레이브 플랫폼 아키텍처의 상이한 버전에 부합할 수 있다. 실링 정책에서의 추상적 신원의 사용은 상이한 네이티브 플랫폼 아키텍처 상에서 소스 및 목적지 엔클레이브를 호스팅하는 것을 가능하게 할 수 있다.

도 19에 도시되지 않은 분산 데이터 실링의 다른 실시예에서, (별개의 컴퓨터(1910, 1930, 1950)와 같은) 3개의 별개의 컴퓨터가 있지 않을 수 있다. 예를 들어, 소스 및 목적지 엔클레이브가 하나의 컴퓨터 상에 (그리고 아마도 단일 네이티브 플랫폼 상에) 있을 수 있는 반면, DSE는 별개의 컴퓨터 상에 있다. 혹은, DSE는 소스 엔클레이브를 호스팅하는 컴퓨터 아니면 목적지 엔클레이브를 호스팅하는 컴퓨터와 동일한 컴퓨터 상에서 호스팅될 수 있다. 이들 분산 데이터 실링 실시예에서, 데이터 실링 및 실링해제는, EnclaveSeal 및 EnclaveUnseal 추상화 프리미티브에 관해 위에서 기술된 바와 같이, 단일 컴퓨터에 전적으로 국부적이지는 않다.

분산 데이터 실링은, 예컨대 추상화 플랫폼(1914, 1934, 1954)에 의해, 추상화 계층 API에 구현될 수 있다. 예를 들어, DistributedEnclaveSeal 및 DistributedEnclaveUnseal 프리미티브는 위에서 논의된 로컬 데이터 실링 프리미티브 EnclaveSeal 및 EnclaveUnseal와 유사하다.

DistributedEnclaveSeal은, 엔클레이브(1910)와 같은 호출 엔클레이브(calling enclave)로 하여금, pPlaintext 파라미터를 통해 제공된 데이터를 실링해제하도록 인가된 엔클레이브 신원의 세트를 지정할 수 있도록 하는 추가적인 SetOfTargetEnclaves 파라미터를 취함으로써 EnclaveSeal을 확장한다. SetOfTargetEnclaves를 통해 어떤 신원도 제공되지 않는 경우, 디폴트의 인가된 엔클레이브 신원은 실링 엔클레이브의 신원, 예를 들어 실링 엔클레이브의 ExactHash 또는 InstanceHash라고 가정될 수 있다.

예를 들어 소스 엔클레이브의 컴퓨터 상의 추상화 플랫폼(1914)의 메쏘드로서의 DistributedEnclaveSeal의 구현은 예컨대 네트워크(1902)를 통하여 메시지를 암호화함으로써, DSE와의 보안 통신 채널을 수립하는 것을 포함할 수 있다. 이 암호화를 위한 키(들)는, 예를 들어, 위에서 기술된 바와 같이, 증명 프로세스 동안에 생성될 수 있거나, DSE(1932)와 연관된 임의의 공개 키일 수 있다.

DistributedEnclaveSeal은 (위의 DistributedEnclaveSeal 함수 프로토타입에 도시되지 않은) 추가적인 파라미터 KeyForData를 취함으로써 또한 일반화될 수 있다. 몇몇 실시예에서, 단일 엔클레이브 또는 단일 엔클레이브 신원에 대해 동시에 여러 세트의 데이터가 실링된 채로 유지될 수 있다. 이 경우에, KeyForData는 데이터의 어느 세트가 실링되고 있는지의 지정을 가능케 한다. KeyForData는 임의의 종류의 데이터 식별자, 예컨대 스트링, 수, 또는 특성의 세트일 수 있다. 몇몇 실시예에서, KeyForData는 DistributedEnclaveSeal에의 입력 파라미터이며 실링 엔클레이브에 의해 생성될 수 있는바, 사실상 실링 엔클레이브가 데이터 세트를 명명할 수 있게 한다. 다른 실시예에서, KeyForData는 출력 파라미터일 수 있는데, DSE는 데이터가 실링될 때 KeyForData 식별자를 생성한다.

DistributedEnclaveUnseal은 추상화 플랫폼(1954) 내에 구현되고, 목적지 엔클레이브(1952)로부터의 요청에 응답하여 동작할 수 있다. DistributedEnclaveUnseal은 DSE(1932)로의 보안 통신 채널을 수립할 수 있는데, 예를 들어, 다만 DSE(1932)에 대한 목적지 엔클레이브(1952)의 증명 동안에 생성된 키로써 메시지를 암호화하는 것, 또는 목적지 엔클레이브의 공개 키로써 목적지 엔클레이브에 발신된 메시지를 암호화하는 것에 의한다. DSE는 예컨대 증명에 의해 요청 (목적지) 엔클레이브의 신원을 확인하고, 요청된 실링된 데이터를 실링해제하며, 실링해제된 데이터를 요청 엔클레이브에 보안적으로 발신할 수 있다. 요청 엔클레이브가 여러 신원을 갖는 실시예에서, 특정한 신원이 Identity 파라미터 내에 지정될 수 있다. 단일 엔클레이브 신원을 위해 여러 엔클레이브 데이터 세트가 저장되는 실시예에서, KeyForData 파라미터는 데이터 세트가 실링되었을 때 DistributedEnclaveSeal에서 사용된 동일한 KeyForData 값을 사용함으로써 (지정된 신원을 위한) 어느 실링된 데이터 세트가 요청되는지를 지정할 수 있다.

몇몇 실시예에서, 데이터를 실링해제하도록 인가된 엔클레이브의 신원은 타겟 인가된 타겟 엔클레이브의 공개 키에 의해 (예컨대 SetOfTargetEnclaves 파라미터 내에) 지정될 수 있다. 이 실시예에서, DSE에 대한 목적지 엔클레이브의 증명은 필수적이지 않을 수 있으나, 실링해제된 데이터는 지정된 공개 키 중 하나를 사용하여 암호화된 바와 같이 이후에 제공될 뿐일 수 있다. 타겟팅된(targeted) 엔클레이브만이 복호화하기 위해 대응하는 개인 키에 대한 액세스를 갖는다고 가정하면, 타겟팅된 엔클레이브만이 실링해제된 데이터에 대한 액세스를 가질 것이다.

도 19에 도시되지 않은 실시예에서, 분산 실링 엔클레이브(Distributed Sealing Enclave: DSE)(1932)의 기능은 그 자체가 여러 DSE에 걸쳐서 분산될 수 있다. 예를 들어 DSE 기능은 잉여성(redundancy) 및 내고장성(fault tolerance)를 위해 여러 컴퓨터 상에서 여러 DSE에 걸쳐서 분산될 수 있다. 이 예에서, 임의의 복제된 DSE가 실링 또는 실링해제 요청을 서비스하는 것이 가능할 수 있다. 실링된 데이터(1938)는, 일단 실링/암호화되면, 클라우드 저장 서버들에 걸쳐서 복제되는 것을 비롯하여, 어디든 안전하게 저장될 수 있음에 유의한다.

분산 데이터 실링은 컴퓨터 간의 엔클레이브 작업부하의 이동을 가능케 할 수 있다. 예를 들어, DSE에 의해 실링된 소스 엔클레이브 데이터는 제1 클라우드 서버 상의 소스 엔클레이브의 상태 데이터일 수 있는데, 이는 실링해제 후에 제2 클라우드 서버 상의 목적지 엔클레이브 내로 로딩될 수 있다. 이것은 도 18에 관해 위에서 기술된 바와 유사하게 행해질 수 있다. 보안 동작은 소스 엔클레이브 내의 실행을 시작할 수 있다. 이후, 아마도 소스 엔클레이브 내의 실행이 중단된 후에, 소스 엔클레이브의 상태는 DSE에 실링될 수 있고, 그러면 소스 엔클레이브 내에서 시작되었던 보안 동작을 목적지 엔클레이브가 계속할 준비가 된 경우 목적지 엔클레이브에 실링해제될 수 있다.

도 20은, 실링 엔클레이브 또는 DSE에 의해 수행될 수 있는 분산 데이터 실링 및 실링해제를 위한 예시적인 흐름도이다. 박스(2002 내지 2006)는 분산 데이터 실링에 대응하는 반면, 박스(2008 내지 2010)는 분산 데이터 실링해제에 대응한다. 소스 엔클레이브로부터 유래하는 엔클레이브 데이터 세트를 실링하라는 요청에 응답하여, 실링 엔클레이브(또는 DSE)는, 박스(2002)에서 소스 엔클레이브에 증명 보고 또는 인용을 발신함으로써, 그 자신을 소스 엔클레이브에 증명할 수 있다. 소스 엔클레이브는, 실링 엔클레이브의 증명 보고 내의 신원 값 및 시그니처를 점검함으로써, 실링 엔클레이브의 신원을 진짜(genuine)이고 신뢰되는 실링 엔클레이브로서 확인할 수 있다. 박스(2004)에서, 실링 엔클레이브는 허가된 리스트 및 실링될 엔클레이브 데이터를 수신한다. 이들은 도 19에 관해 위에서 기술된 바와 같이 보안 채널을 통해 수신될 수 있다. 선택적인 박스(2006)에서, 실링 엔클레이브는 소스 엔클레이브의 데이터를, 예를 들어 데이터가 실링 엔클레이브의 보안 컨테이너 외부에, 예컨대 컴퓨터 파일 시스템 내에 저장된 경우, 그 자신에게 실링할 수 있다. 목적지 엔클레이브를 위해 데이터를 실링해제하기 위하여, 목적지 엔클레이브는, 박스(2008)에서, 예컨대 증명 보고 또는 인용을 제공함으로써, 그 자신을 실링 엔클레이브에 증명할 수 있다. 박스(2010)에서, 목적지 엔클레이브의 신원은, 예컨대 목적지 엔클레이브의 증명 보고를 점검함으로써 확인될 수 있다. 박스(2012)에서, 실링 엔클레이브는 목적지 엔클레이브의 인증된 신원이 데이터와 함께 수신된 허가된 리스트 내에 포함됨을 확인함으로써 목적지 엔클레이브가 소스 엔클레이브로부터 데이터를 실링해제하도록 허가되는지를 판정한다. 일단 허가가 확증되었다면, 엔클레이브 데이터는 그것이 실링되었던 경우 실링해제되고, 이후 박스(2014)에서 보안 채널을 통해 목적지 엔클레이브에 발신될 수 있다.

키 볼트 엔클레이브

키 볼트는 엔클레이브로써 구현될 수 있다. 키 볼트는 키 볼트의 클라이언트를 위한 키, 예컨대 데이터를 암호화하고 복호화하기 위한 암호화 시스템의 키를 보안적으로 유지한다. 키 볼트는 추가적으로 키로써 동작을 수행할 수 있는데, 예컨대 데이터를 암호화하고 복호화하는 것, 데이터를 설명하는 것, 그리고 기존의 키로부터 새로운 키를 도출하는 것이다. 키 볼트는, 엔클레이브로서 구현된 경우, 비밀 암호화 키의 매우 보안적인 저장 및 비밀 암호화 키로써의 처리를 제공할 수 있다. 추가적으로, 키 볼트 엔클레이브의 소프트웨어 증명은 볼트 클라이언트에게 그것이 진정한(authentic) 그리고 신뢰되는 키 볼트와 통신하고 있다는 높은 수준의 보증을 제공할 수 있다. 대단히 보안적인 시스템이 키 볼트 엔클레이브 상에 볼트 잠금된 키로써 구축될 수 있는데, 키 볼트 내부에 저장된 키는 결코 키 볼트 외부의 어떤 클라이언트에게도 릴리즈되지 않으며, 몇몇 경우에 볼트 잠금된 키는 키 볼트 엔클레이브 내부에 저장된 (또는 가능하게는 이에 실링된) 바와 같이 그저 언제든 존재할 수 있다.

도 21은 예시적인 키 볼트 엔클레이브의 블록도이다. 엔클레이브(2122)는 제2 네이티브 엔클레이브 플랫폼(2126)의 보안 엔클레이브 컨테이너 내부의 키 볼트이다. 도 21의 예에서, 키 볼트 엔클레이브(2122)의 클라이언트(2112)는 또한 엔클레이브이며, 제1 네이티브 엔클레이브 플랫폼(2116)의 보안 엔클레이브 컨테이너 내부에서 호스팅된다. 엔클레이브(2112, 2122)는 각자의 엔클레이브 추상화 플랫폼(2114, 2124)을 통해 그들 각자의 네이티브 플랫폼(2116, 2126)과 상호작용할 수 있다. 다른 실시예에서, 하나 또는 두 추상화 플랫폼(2114, 2124) 모두가 존재하지 않을 수 있는데 엔클레이브(2112 및/또는 2122)가 네이티브 플랫폼(2116, 2126)과 직접적으로 상호작용한다.

키 볼트 엔클레이브(2122)는 통신 채널(2150)을 통해 볼트 클라이언트(2112)와 통신할 수 있다. 몇몇 실시예에서, 통신 채널(2112)은 통신 채널(2150)을 통하여 발신된 메시지의 기밀성, 무결성 및/또는 선도의 보증을 제공하는 보안 통신 채널일 수 있다. 예를 들어, 도 2 및 도 3에서와 같이, 암호화 및 시그니처로써, 도 5 및 도 6에서와 같이, 증명 프로세스의 일부로서 생성된 공유 키를 사용하여, 그러한 보안 통신 채널의 기밀성 및 무결성이 수립될 수 있다.

소프트웨어 증명은 부분적으로 통신 채널의 다른 측의 개체의 신원의 보증을 제공함으로써 보안을 제공한다. 키 볼트 엔클레이브(2122)를 볼트 클라이언트에 증명함으로써, 클라이언트는 키 볼트에 시크릿, 예컨대 키 또는 다른 평문 데이터를 발신하기 전임을 나타내는 자가 키 볼트 엔클레이브(2122)라는 보증을 얻을 수 있다. 도 21에 묘사된 바와 같이, 엔클레이브이기도 한 클라이언트에 대해 그 반대도 또한 참이다. 볼트 엔클레이브(2112)를 키 볼트 클라이언트(2122)에 증명함으로써, 키 볼트는 시크릿, 예컨대 키 또는 다른 평문 데이터를 클라이언트에 드러내기 전임을 나타내는 자가 클라이언트라는 보증을 얻을 수 있다.

볼트 잠금된 키 및 도출된 키(특히 암호화 키가 볼트 잠금된 키로부터 도출됨)를 가진 키 볼트 시스템은 융통성 있고 매우 안전한 보안 시스템을 구축하는 데에 사용될 수 있다. 키 도출 함수는, 공용일 수 있거나 그렇지 않을 수 있는데, 제1 키로부터 여러 키를 생성하는 데에 사용될 수 있다. 제1 키(루트 시크릿(root secret))는 최고 수준의 보안을 위해 볼트 잠금될 수 있고, 제1 키로부터 도출된 키가 암호화 목적으로 사용될 수 있다. 도출된 키가 훼손된(compromised) 경우, 제1 키를 유지하는 키 볼트를 액세스하거나 바꿀 필요 없이 기존의 시스템 내에서 새로운 도출된 키가 생성될 수 있다.

예시적인 키 볼트 엔클레이브(Key Vault Enclave: KVE)는 엔클레이브를 사용하여 키 저장, 생성, 도출, 분배, 암호화, 복호화 및 시그니처를 제공하는 클라우드 기반 키 볼트 시스템이다. KVE는 그것의 정확한 해시(그것의 보안 컨테이너의 콘텐츠의 해시)에 의해, 또는 그것의 생성자에 의해 할당되거나 이와 연관된 임의적인 식별자에 의해 식별될 수 있다. 후자의 경우에, 식별자의 상충으로 인한 부조화 및 보안 침해를 막기 위하여 엔클레이브는 그것의 생성자의 개인 키로써 서명될 수 있다.

키 볼트 클라이언트는 다음의 예시적인 프리미티브를 사용하여 키-볼트 시스템과 상호작용할 수 있다. 예시적인 StoreKey 함수 프로토타입은 다음이다:

StoreKey([in] Keyname, [in] KeyType, [in] KeyValue, [in] Policy)

StoreKey는 주어진 키를 키-볼트 내에 저장하고 그것을 주어진 이름과 연관시킨다. 키 타입은 또한 키와 연관되며 키로써 행해질 수 있는 것을 제한한다. 예를 들어, 몇몇 키는 단지 암호화를 위해 사용되어야 하고, 다른 것은 시그니처를 위해 사용되어야 하며, 기타 등등이다. 그리고 특정 키는 단지 특정 암호 알고리즘과 함께 사용될 수 있다. 정책은 키의 사용을 또한 제한하는 정책을 지정할 수 있다. 예를 들어, 그것은 키를 검색하고/거나 키를 사용하도록 허용된 엔클레이브 신원의 세트를 지정할 수 있다. 그것은 또한 시간적인 속성, 예를 들어, 어떤 날짜에 키가 파기되어야 함, 또는 키를 사용하는 동작의 레이트(rate)가 제한되어야 함을 지정할 수 있다.

예시적인 GenerateKey 함수 프로토타입은 다음이다:

GenerateKey([in] keyName, [in] keyType, [in] Policy)

Generate Key는 어떤 타입의 새로운 키를 생성하고 그것을 키-볼트 내부에 저장된 채로 유지하는바, 즉, 키는 키-볼트를 결코 떠나지 않는다.

예시적인 GetKey 함수 프로토타입은 다음이다:

GetKey([in] KeyName, [out] KeyValue)

GetKey는 키-볼트 내부에 저장된 키를 페치한다(fetch). 이들 프리미티브는 전형적으로 보안 통신 채널을 통하여 구현되며 프리미티브를 콜하는 코드는 전형적으로 신뢰 환경에서 가동된다. 그러한 콘텍스트에서, 흔히 키-볼트로부터 키를 검색하는 것은 용인가능하다.

예시적인 DeleteKey 함수 프로토타입은 다음이다:

DeleteKey([in] keyName)

DeleteKey는 키-볼트로부터 키를 삭제한다.

예시적인 DeriveKey 함수 프로토타입은 다음이다:

DeriveKey([in] newKeyName, [in] KeyName, [in] kdfIdentifier, [in] AdditionalData)

DeriveKey는 keyName에 의해 식별된 키 및 AdditionalData 내에서 전달된 데이터에 기반하여 새로운 키를 도출하기 위하여 kdfIdentifier에 의해 식별된 암호학적 키 도출 함수(Key Derivation Function: KDF)를 사용한다.

예시적인 Encrypt 함수 프로토타입은 다음이다:

Encrypt([in] KeyName, [in] algorithm, [in] data, [out]encryptedData)

Encrypt는 요청된 알고리즘을 사용하여, KeyName에 의해 식별된 키로써 데이터를 암호화한다.

예시적인 Decrypt 함수 프로토타입은 다음이다:

Decrypt([in] KeyName, [in] algorithm, [in] encrytedData, [out]data)

Decrypt는 요청된 알고리즘을 사용하여, KeyName에 의해 식별된 키로써 데이터를 복호화한다.

예시적인 Sign 함수 프로토타입은 다음이다:

Sign([in] KeyName, [in] algorithm, [in] data, [out] signature)

Sign은 요청된 알고리즘을 사용하여, KeyName에 의해 식별된 키로써 데이터를 서명한다.

예시적인 VerifySignature 함수 프로토타입은 다음이다:

VerifySignature([in]KeyName, [in] algorithm, [in] signature, [out} bool signatureIsCorrect)

VerifySignature는 요청된 알고리즘을 사용하여, KeyName에 의해 식별된 키로써 시그니처를 확인한다.

위의 키 볼트 프리미티브 전부는 KVE와의 보안 채널을 수립함으로써 구현될 수 있다. 채널은 도 5 및 도 6에 관해 위에서 기술된 바와 같이 증명을 사용하고 디피-헬만 키 교환을 수행하여 수립될 수 있다. 통신 채널이 수립된 후, 요청은 채널을 통하여 보안적으로 발신되며 응답은 채널로부터 판독된다. 채널은 교환된 데이터의 기밀성 및 무결성의 보장을 제공할 수 있다.

다른 실시예에서, KVE가 처음 가동될 때, 그것은 공개/개인 키 쌍을 생성하고 그것은 공개 키를 위해 인용(quote)을 생성한다. 그러면 그것은 인용 및 공개 키를 써내는 반면, 엔클레이브 내부에 개인 키를 유지한다. 이후 공개 및 인용은 키-볼트를 사용하기를 희망하는 모든 시스템/코드에 분배될 수 있다. 이 경우에, 위의 프리미티브의 구현은 인용을 확인하여 그것이 진짜 KVE와 대화하고 있음을 확실히 해두며, 이후 KVE의 공개 키를 사용하여 요청을 암호화한다. 요청의 일부로서, 프리미티브의 구현은 KVE로부터 발신된 결과를 암호화하고 무결성 보호하는 키를 포함할 수 있다. 이 실시예는 증명 없이 보안 양방향(two-way) 통신 채널을 제공할 수 있다.

도 22는 몇몇 키 볼트 엔클레이브 동작을 위한 예시적인 흐름도이다. 박스(2202)에서 프로세스(2200)는 암호화 시스템에서 사용되는 키를 키 볼트 엔클레이브 내에 보안적으로 저장함으로써 시작한다. 키는, 예를 들어, 데이터를 암호화하거나 복호화하여, 암호학적 시그니처를 생성하는 데에 사용될 수 있거나, 단지 루트 키(이로부터 다른 키를 도출함)로서 사용될 수 있다. 키는 키 볼트 엔클레이브 내에 보안적으로 저장될 수 있는데, 예를 들어, 엔클레이브의 보안 컨테이너의 메모리 공간 내에 키를 저장함에 의해서이다. 다른 실시예에서, 키는 키 볼트 엔클레이브에 키 데이터를 실링함으로써 보안 엔클레이브 컨테이너 외부에 보안적으로 유지될 수 있거나, 도 19 및 도 20에 관해 기술된 바와 같이 분산 실링 엔클레이브로써 원격으로 실링함으로써 보안적으로 유지될 수 있다.

박스(2204)에서, 키 볼트 엔클레이브는 볼트 클라이언트에 키 볼트 엔클레이브의 신원을 증명하기 위한 증명 프로세스를 수행한다. 이것은 키 볼트가 사칭자(imposter)가 아니며 암호화된 키 또는 데이터와 같은 시크릿으로써 신뢰될 수 있다는 보증을 클라이언트에게 줄 수 있다. 키볼트 엔클레이브의 증명은 키 볼트 엔클레이브의 증명 보고 또는 증명 인용을 볼트 클라이언트에 발신하는 것을 포함할 수 있다. 그러면 키 볼트 클라이언트는 키 볼트 엔클레이브의 네이티브 엔클레이브 플랫폼과 연관된 공개 키로써 증명 보고 내의 시그니처를 확인함으로써 증명 보고의 무결성을 확인할 수 있다. 예를 들어, 키 볼트(2122)의 증명 보고는 제2 네이티브 플랫폼(2126)에 의해 생성될 수 있고, 볼트 클라이언트(2112)는 제2 네이티브 플랫폼(2126)과 연관된 공개 키를 사용하여 보고 내의 시그니처를 확인할 수 있다. 이 증명 프로세스는, 예를 들어 도 5 및 도 6에 도시된 바와 같이, 볼트 클라이언트 및 키 볼트 엔클레이브 간의 보안 통신 채널을 위해 사용되는 키를 또한 생성할 수 있다. 증명 보고는, 예를 들어 도 14 및 도 15에 관해, 위에서 기술된 바와 같이 다양한 방식으로 판정될 수 있는 키 볼트 엔클레이브의 신원을 포함할 수 있다. 신원은, 예를 들어, 키 볼트 엔클레이브의 보안 컨테이너의 전체 콘텐츠의 해시, 키 볼트 엔클레이브의 작성자/생성자에 의해 할당된 고유 식별자만의 해시, 또는 고유 식별자 및 컨테이너의 콘텐츠의 일부분의 조합의 해시에 기반할 수 있다.

몇몇 키 볼트 엔클레이브 동작은 볼트 클라이언트의 신원의 보증을 또한 요구할 수 있다. 예를 들어, (예컨대 Decrypt 또는 GetKey 프리미티브로써) 데이터를 복호화하는 것 또는 키를 공표하는 것(divulging)은 그러한 보증을 요구할 수 있다. 이들 상황에서, 볼트 클라이언트가 또한 엔클레이브인 경우, 선택적인 박스(2208)는, 키 볼트 엔클레이브에 의해, 볼트 클라이언트의 신원을 확인하기 위한 증명 프로세스를 포함한다. 박스(2208)의 증명 프로세스는, 키 볼트 엔클레이브에서, 볼트 클라이언트의 증명 보고 또는 인용을 수신하는 것을 포함할 수 있다.

선택적인 박스(2210)에서, 키 볼트 및 키 볼트 엔클레이브 간에 보안 통신 채널이 수립될 수 있다. 볼트 클라이언트 및 키 볼트 엔클레이브 간에 시크릿, 예컨대 암호화될 키 또는 데이터를 전달하기 위해 보안 통신이 요구될 수 있다. 박스(2004 또는 2008)의 증명 프로세스는, 예를 들어 도 5 및 도 6에 도시된 바와 같이, 볼트 클라이언트 및 키 볼트 엔클레이브 간의 보안 통신 채널을 생성하는 데에 사용될 수 있는 키를 생성할 수 있다. 혹은, 보안적으로 메시지를 발신하는 데에 메시지의 목적지의 임의의 알려진 공개 키가 사용될 수 있다.

박스(2212)에서, 키 동작, 예컨대 위에서 기술된 키 볼트 프리미티브 중 하나가, 키 볼트 엔클레이브 내부에서 수행될 수 있다. 이 동작 동안에, 키 데이터는 키 볼트 엔클레이브의 보안 컨테이너의 주소 공간 내에만 저장될 수 있다. 예시적인 프리미티브는 DeriveKey, Decrypt, Sign 및 다른 것을 포함한다.

프로세스(2200)는 키 볼트 엔클레이브가 키를 이미 알고 있다고 상정한다. 몇몇 키 볼트 엔클레이브 동작 또는 프리미티브, 예컨대 StoreKey 또는 GenerateKey에 대해, 동작의 순서는 프로세스(2200) 내에 묘사된 것과는 상이할 수 있다. 예를 들어, GenerateKey에 있어서, (박스(2212)에서와 같은) 키 생성 동작은 박스(2202)의 보안 저장 동작 전에 발생할 것이다. 그러한 동작 순서가 도 23, 박스(2302-2308)에 묘사된다.

도 23은 볼트 잠금된 키로써 키 볼트 엔클레이브를 생성하고 사용하기 위한 예시적인 흐름도이다. 프로세스(2300)의 박스(2302 내지 2308)에서, 키 볼트 엔클레이브 내에서 새로운 키가 도출된다. 박스(2310 내지 2316)에서, 새로 도출된 키는 복호화 동작을 수행하는 데에 사용된다. 이것은 볼트 잠금된 키의 예시적인 사용인데, 모든 키 동작은 키 볼트 엔클레이브로써 수행되고 키는 결코 볼트 클라이언트에 제공되지 않는다. 또한, 이 예에서의 새로운 키는 결코 키 볼트 엔클레이브 외부에 존재하지 않는데, 그것이 키 볼트 엔클레이브 그 자체 내에서 생성(도출)되었고, 결코 볼트 클라이언트 또는 다른 데에서 키 볼트 엔클레이브에 제공되지 않았기 문이다. 몇몇 실시예 및 키 사용 정책에 있어서, 볼트 잠금된 키는, 심지어 키 볼트 엔클레이브에 키를 실링한 후에도, 그것이 키 볼트 엔클레이브의 보안 컨테이너를 결코 떠나지 않는다는 점에서 단명할(ephemeral) 수 있다. 그러한 단명 키는, 통신 채널을 일시적으로 보안화하는 데에 사용되는 도출된 키로 발생할 수 있는데, 키 볼트 엔클레이브의 컨테이너가 파기되거나 종결된 경우에 어디에서든 소멸할 수 있다. 도 23의 프로세스는 볼트 잠금된 키가 어떻게 사용될 수 있는지 예시하나, 예를 들어 키 사용 정책이 키로 하여금 그것의 생성을 요청한 클라이언트에게 돌아갈 수 있게 한 경우, 도 23의 프로세스는 또한 볼트 잠금되지 않은 키와 함께 사용될 수 있다.

박스(2302)에서, 키 볼트 엔클레이브는 그 자신을 볼트 클라이언트에 증명한다. 이것은 클라이언트에 의해 요구될 수 있는데 박스(2312)에서 클라이언트는 암호화될 시크릿을 제공할 것이기 때문이다. 박스(2304)에서, 키 볼트 엔클레이브는, 예를 들어 볼트 클라이언트로부터, 키 사용 정책의 표시를 수신할 수 있다. 표시는, 예를 들어, 정책을 명시하는 데이터 구조일 수 있거나, 키 사용 정책의 레지스트리와 함께 사용될 식별자일 수 있다. 키 사용 정책 그 자체는 이 키가 결코 어떤 볼트 클라이언트에게도 제공되어서는 안 된다는 것을 나타낼 수 있다. 박스(2306)에서, 예를 들어 위에서 기술된 DeriveKey 프리미티브로써, 이전에 알려진 루트 키로부터 새로운 키가 도출된다. 새로운 키를 도출하라는 요청(묘사되지 않음)은, 예를 들어, 볼트 클라이언트로부터, 키 볼트 엔클레이브에 의해 수신될 수 있다. 박스(2308)에서, 새로 도출된 키는 수신된 키 사용 정책에 따라 보안적으로 저장될 수 있다.

박스(2310)에서 볼트 클라이언트는 그 자신을 키 볼트 엔클레이브에 증명할 수 있다. 증명 프로세스는, 키 볼트 엔클레이브에서, 볼트 클라이언트의 증명 보고 또는 인용을 수신하는 것을 포함할 수 있다. 수신된 키 사용 정책은 새로운 키의 몇몇 또는 모든 사용을 소프트웨어 증명을 통해 인증된 요청자로부터의 요청에 제한할 수 있다. 박스(2312 내지 2316)에서, 예컨대 위의 Decrypt 프리미티브를 위한 복호화 동작은, 박스(2306)에서 도출된 키를 사용하여 수행된다. 다른 실시예에서, 볼트 잠금된 키로써 다른 동작, 예컨대 암호화, 서명, 시그니처를 확인하기, 그리고 박스(2306)에서 도출된 키로부터 다른 새로운 키를 도출하기(루트 키로부터 제2 생성 키를 도출하기)가 수행될 수 있다. 박스(2312)에서, 암호화된 데이터 버퍼가 볼트 클라이언트로부터 수신된다. 수신된 암호화된 데이터는 박스(1314)에서, 도출된 키로써 복호화되고, (복호화된 데이터 버퍼 내의) 결과적인 복호화된 데이터는 박스(2316)에서 보안 통신 채널을 통해 볼트 클라이언트에 발신된다.

실시예에서, 엔클레이브(enclave) 식별 방법은 프로세서 및 메모리를 포함하는 컴퓨팅 디바이스에 의해 수행되는데, 위 방법은 다음을 포함한다:

인스턴스화된(instantiated) 엔클레이브에 관련된 동작에 대한 요청 및 신원 타입(identity type)을 수신하는 것;

엔클레이브 이미지(이로부터 위 엔클레이브는 인스턴스화되었음)로부터 도출된 정보 및 위 신원 타입에 기반하여 위 엔클레이브를 위한 신원 값(identity value)을 판정하는 것; 및

위 신원 값으로써 위 동작을 수행하는 것.

실시예에서, 위 방법은 다음을 더 포함한다:

위 엔클레이브 이미지의 작성자(author)에 관련된 공개 키(public key)로써 위 엔클레이브 이미지 내의 시그니처(signature)를 확인함으로써 위 신원 값의 무결성(integrity)을 확인하는 것.

실시예에서, 위 신원 값은 해시 함수(hash function)의 출력으로서 판정되고, 다음을 더 포함한다:

위 신원 타입에 적어도 부분적으로 기반하여, 위 엔클레이브 이미지의 신원 부분(identity portion)을 판정하는 것; 및

위 신원 부분 상에서 위 해시 함수를 계산하는 것.

실시예에서, 위 엔클레이브 이미지는 추가적인 종속적 엔클레이브 이미지에 대한 참조를 포함하고, 다음을 더 포함한다:

위 신원 타입에 적어도 부분적으로 기반하여, 위 해시 함수에 대한 입력으로서 위 추가적인 종속적 엔클레이브 이미지 중 어느 것이 포함되는지를 판정하는 것.

실시예에서, 위 신원 부분은 다음 중 하나 이상을 포함한다: 위 인스턴스화된 엔클레이브의 인스턴스화 동안에 보안 엔클레이브 컨테이너 내로 복사된 바이너리 코드, 그리고 실행가능 코드가 아닌 하나 이상의 식별자.

실시예에서:

위 신원 값은 해시 함수의 출력으로서 판정되고;

위 엔클레이브는 복수의 엔클레이브 이미지로써 인스턴스화되었으며;

위 신원 타입은 위 신원 값을 판정하기 위해 적어도 부분적으로 위 해시 함수에 위 복수의 엔클레이브 이미지 중 어느 것이 포함되는지를 나타낸다.

실시예에서:

위 동작은 위 신원 값으로써 증명 보고(attestation report)를 생성하는 것을 포함한다.

실시예에서:

위 동작은 위 신원 값으로써 데이터를 실링함(sealing)으로써 위 엔클레이브에 데이터를 실링하는 것을 포함한다.

실시예에서, 위 동작은 단조 카운터(monotonic counter)를 점증시키는 것(incrementing)을 포함하되, 위 단조 카운터는 위 신원 값에 의해 식별된다.

실시예에서, 위 동작은 신뢰 시간(trusted time) 측정을 행하는 것을 포함하되, 위 신뢰 시간은 위 신원 값에 기반하여 판정된다.

실시예에서, 시스템은 적어도 프로세서 및 메모리를 포함하되, 위 메모리는, 위 시스템에 의해 실행되는 경우에, 적어도 다음을 유발하는 명령어를 그 위에 저장한다:

인스턴스화된 엔클레이브에 관련된 동작에 대한 요청 및 신원 타입을 수신하는 것;

엔클레이브 이미지(이로부터 위 엔클레이브는 인스턴스화되었음)로부터 도출된 정보 및 위 신원 타입에 기반하여 위 엔클레이브를 위한 신원 값을 판정하는 것; 및

위 신원 값으로써 위 동작을 수행하는 것.

실시예에서, 위 명령어는 또한 적어도 다음을 유발한다:

위 엔클레이브 이미지의 작성자에 관련된 공개 키로써 위 엔클레이브 이미지 내의 시그니처를 확인함으로써 위 신원 값의 무결성을 확인하는 것.

실시예에서, 위 신원 값은 해시 함수의 출력으로서 판정되고, 위 명령어는 또한 적어도 다음을 유발한다:

위 신원 타입에 적어도 부분적으로 기반하여, 위 엔클레이브 이미지의 신원 부분을 판정하는 것; 및

위 신원 부분 상에서 위 해시 함수를 계산하는 것.

실시예에서, 위 엔클레이브 이미지는 추가적인 종속적 엔클레이브 이미지에 대한 참조를 포함하고, 위 명령어는 또한 적어도 다음을 유발한다:

실시예에서, 위 신원 값은 해시 함수의 출력으로서 판정되고;

실시예에서, 위 동작은 위 신원 값으로써 증명 보고를 생성하는 것을 포함한다.

실시예에서, 위 동작은 위 신원 값으로써 데이터를 실링함으로써 위 엔클레이브에 데이터를 실링하는 것을 포함한다.

실시예에서, 위 동작은 단조 카운터를 점증시키는 것을 포함하되, 위 단조 카운터는 위 신원 값에 의해 식별된다.

실시예에서, 위 동작은 신뢰 시간 측정을 행하는 것을 포함하되, 위 신뢰 시간은 위 신원 값에 기반하여 판정된다.

실시예에서, 엔클레이브 식별 방법은 다음을 포함한다:

위 엔클레이브의 컨테이너(container) 내에 저장된 데이터 및 위 신원 타입에 기반하여 위 엔클레이브를 위한 신원 값을 판정하는 것; 및

위 신원 값으로써 위 동작을 수행하는 것.

청구항 21의 엔클레이브 식별 방법으로서:

위 엔클레이브의 위 컨테이너 내에 저장된 위 데이터는 복수의 신원 값을 포함하고,

위 신원 값은 위 신원 타입에 기반하여 위 복수의 신원 값 중에서 선택함으로써 판정된다.

앞부분에서 기술된 프로세스, 방법 및 알고리즘 각각은 하나 이상의 컴퓨터 또는 컴퓨터 프로세서에 의해 실행되는 코드 모듈 내에 체현되고, 전적으로 또는 부분적으로 이에 의해 자동화될 수 있다. 코드 모듈은 임의의 타입의 비일시적 컴퓨터 판독가능 매체 또는 컴퓨터 저장 디바이스, 예컨대 하드 드라이브, 솔리드 스테이트 메모리, 광학 디스크 및/또는 유사한 것 상에 저장될 수 있다. 프로세스 및 알고리즘은 부분적으로 또는 전체적으로 애플리케이션 특정 회로 내에 구현될 수 있다. 개시된 프로세스 및 프로세스 단계의 결과는 휘발성 또는 비휘발성 스토리지와 같은 임의의 타입의 비일시적 컴퓨터 스토리지 내에, 영구적으로 또는 다른 식으로, 저장될 수 있다. 위에서 기술된 다양한 특징 및 프로세스는 서로 독립적으로 사용될 수 있거나, 다양한 방식으로 조합될 수 있다. 모든 가능한 조합 및 부조합은 이 개시의 범위 내에 속하도록 의도된다. 추가로, 몇몇 구현에서 어떤 방법 또는 프로세스 블록은 생략될 수 있다. 본 문서에서 기술된 방법 및 프로세스는 또한 어떤 특정한 순차에도 한정되지 않으며, 이에 관한 블록 또는 상태는 적절한 다른 순차로 수행될 수 있다. 예를 들어, 기술된 블록 또는 상태는 구체적으로 개시된 것이 아닌 순서로 수행될 수 있거나, 여러 블록 또는 상태가 단일 블록 또는 상태로 조합될 수 있다. 예시적인 블록 또는 상태는 직렬로, 병렬로 또는 어떤 다른 방식으로 수행될 수 있다. 블록 또는 상태가 개시된 예시적 실시예에 추가되거나 이로부터 제거될 수 있다. 본 문서에 기술된 예시적 시스템 및 컴포넌트는 개시된 것과는 상이하게 구성될 수 있다. 예를 들어, 요소가 개시된 예시적 실시예에 추가되거나, 이로부터 제거되거나, 이에 비해 재배열될 수 있다.

사용되는 동안 다양한 아이템이 메모리 내에 또는 스토리지 상에 저장된 것으로서 예시되고, 이들 아이템 또는 이의 부분이 메모리 관리 및 데이터 무결성의 목적으로 메모리 및 다른 저장 디바이스 간에 이전될 수 있음이 또한 인식될 것이다. 대안적으로, 다른 실시예에서 소프트웨어 모듈 및/또는 시스템의 일부 또는 전부가 다른 디바이스 상의 메모리 내에서 실행되고 컴퓨터간 통신을 통해 예시된 컴퓨팅 시스템과 통신할 수 있다. 나아가, 몇몇 실시예에서, 시스템 및/또는 모듈의 일부 또는 전부는 다른 방식으로, 예컨대 적어도 부분적으로 펌웨어 및/또는 하드웨어(하나 이상의 애플리케이션 특정 집적 회로(Application-Specific Integrated Circuit: ASIC), 표준 집적 회로(standard integrated circuit), 제어기(controller)(가령, 적절한 명령어를 실행함으로써, 그리고 마이크로제어기 및/또는 임베디드(embedded) 제어기를 포함함), 필드 프로그램가능 게이트 어레이(Field-Programmable Gate Array: FPGA), 복합 프로그램가능 로직 디바이스(Complex Programmable Logic Device: CPLD), 기타 등등을 포함하나, 이에 한정되지 않음)로 구현되거나 제공될 수 있다. 모듈, 시스템 및 데이터 구조의 일부 또는 전부는 컴퓨터 판독가능 매체, 예컨대 적절한 드라이브에 의해 또는 적절한 연결을 통해 판독될 하드 디스크, 메모리, 네트워크 또는 포터블 매체 물품 상에 (가령, 소프트웨어 명령어 또는 구조화된 데이터로서) 또한 저장될 수 있다. 이 명세서 및 청구항을 위해, 구문 "컴퓨터 판독가능 저장 매체"(computer-readable storage medium) 및 이의 변형물은 파동, 신호 및/또는 다른 일시적(transitory) 및/또는 무형적(intangible) 통신 매체를 포함하지 않는다. 시스템, 모듈 및 데이터 구조는 또한 생성된 데이터 신호로서 (가령, 반송파(carrier wave) 또는 다른 아날로그 또는 디지털 전파 신호(propagated signal)의 일부로서) 무선 기반 및 유선/케이블 기반 매체를 포함하는 다양한 컴퓨터 판독가능 송신 매체 상에서 송신될 수 있고, (가령, 단일의 또는 다중화된 아날로그 신호의 일부로서, 또는 여러 이산 디지털 패킷 또는 프레임으로서) 다양한 형태를 취할 수 있다. 그러한 컴퓨터 프로그램 제품은 또한 다른 실시예에서 다른 형태를 취할 수 있다. 따라서, 본 개시는 다른 컴퓨터 시스템 구성으로써 실시될 수 있다.

본 문서에서 사용되는 가정적 표현(conditional language), 예컨대, 무엇보다도, "할 수 있다", "할 수가 있다", "하는 수가 있다", "할 수도 있다", "가령” 및 유사한 것은, 달리 구체적으로 언급되거나, 사용된 맥락 내에서 달리 이해되지 않는 한, 일반적으로 어떤 실시예가 어떤 특징, 요소 및/또는 단계를 포함하는 한편, 다른 실시예는 이를 포함하지 않는다는 것을 전하도록 의도된다. 그러므로, 그러한 가정적 표현은 일반적으로, 특징, 요소 및/또는 단계가 하나 이상의 실시예에 어떤 식으로든 요구된다거나 하나 이상의 실시예가 반드시 이들 특징, 요소 및/또는 단계가 어떤 특정한 실시예에서 수행되어야 하는지 또는 이에 포함되는지를, 작성자 입력 또는 촉발(prompting)이 있든 또는 없든, 정하기 위한 로직을 포함한다는 것을 시사하도록 의도되지 않는다. 용어 "포함하는", "포함한", "갖는" 및 유사한 것은 동의어이고, 개방형(open-ended fashion)으로, 포괄적으로(inclusively) 사용되며, 추가적인 요소, 특징, 행위, 동작 및 기타 등등을 배제하지 않는다. 또한, 용어 "또는"은 그것의 포괄적인 의미로 사용되(고 그것의 배타적인(exclusive) 의미로 사용되지 않)는바, 예를 들어, 요소의 리스트를 연결하는 데에 사용되는 경우, 용어 "또는"은 리스트 내의 요소 중 하나, 몇몇 또는 전부를 의미한다.

어떤 예시적 실시예가 기술되었으나, 이들 실시예는 단지 예로서 제시되었으며 본 문서에 개시된 발명의 범위를 한정하도록 의도되지 않는다. 그러므로, 전술된 설명 내의 어떤 것도 임의의 특정한 특징, 특성, 단계, 모듈 또는 블록이 필수적이거나 불가결함을 시사하도록 의도되지 않는다. 사실, 본 문서에 기술된 신규한 방법 및 시스템은 다양한 다른 형태로 체현될 수 있고; 나아가, 본 문서에 개시된 발명의 사상으로부터 벗어나지 않고서 본 문서에 기술된 방법 및 시스템의 형태에서의 다양한 변경, 대체 및 생략이 행해질 수 있다. 첨부된 청구항 및 그것의 균등물은 본 문서에 개시된 발명 중의 얼마간의 것의 범위 및 사상 내에 속할 그러한 형태 또는 수정을 포섭하도록 의도된다.

Claims

프로세서 및 메모리를 포함하는 컴퓨팅 디바이스에 의해 수행되는 엔클레이브(enclave) 식별 방법으로서,
인스턴스화된 엔클레이브에 관련된 동작에 대한 요청 및 신원 타입(identity type)을 수신하는 단계 - 상기 엔클레이브가 인스턴스화된 엔클레이브 이미지는 추가적인 종속적(dependent) 엔클레이브 이미지들에 대한 참조들을 포함함 - 와,
상기 신원 타입에 적어도 부분적으로 기반하여, 해시 함수에 대한 입력으로서 상기 추가적인 종속적 엔클레이브 이미지들 중 어느 것이 적어도 부분적으로 포함되는지를 판정하는 단계와,
상기 엔클레이브 이미지로부터 도출된 정보 및 상기 신원 타입에 적어도 부분적으로 기반하여 상기 해시 함수를 계산하여 상기 해시 함수의 출력으로서 상기 엔클레이브에 대한 신원 값(identity value)을 제공하는 단계와,
상기 엔클레이브에 관한 보안을 제공하기 위해 상기 신원 값을 이용하여 상기 동작을 수행하는 단계를 포함하는
엔클레이브 식별 방법.
제1항에 있어서,
상기 엔클레이브 이미지의 작성자에 관련된 공개 키(public key)로 상기 엔클레이브 이미지 내의 시그니처(signature)를 확인함으로써 상기 신원 값의 무결성(integrity)을 확인하는 단계를 더 포함하는
엔클레이브 식별 방법.
제1항에 있어서,
상기 방법은,
상기 신원 타입에 적어도 부분적으로 기반하여, 상기 엔클레이브 이미지의 신원 부분(identity portion)을 판정하는 단계를 더 포함하고,
상기 해시 함수를 계산하는 단계는,
상기 신원 부분에 대하여 상기 해시 함수를 계산하는 단계를 포함하는,
엔클레이브 식별 방법.
삭제
제3항에 있어서,
상기 신원 부분은,
상기 인스턴스화된 엔클레이브의 인스턴스화 동안에 보안 엔클레이브 컨테이너 내로 복사된 바이너리 코드와,
실행가능 코드가 아닌 하나 이상의 식별자
중 하나 이상을 포함하는,
엔클레이브 식별 방법.
제1항에 있어서,
상기 엔클레이브는 복수의 엔클레이브 이미지로 인스턴스화된 것이며,
상기 신원 타입은 상기 신원 값을 판정하기 위해 적어도 부분적으로 상기 해시 함수에 상기 복수의 엔클레이브 이미지 중 어느 것이 포함되는지를 나타내는,
엔클레이브 식별 방법.
제1항에 있어서,
상기 동작은 상기 신원 값으로 증명 보고(attestation report)를 생성하는 것을 포함하는,
엔클레이브 식별 방법.
제1항에 있어서,
상기 동작은 상기 신원 값으로 데이터를 실링함(sealing)으로써 상기 엔클레이브에 데이터를 실링하는 것을 포함하는,
엔클레이브 식별 방법.
제1항에 있어서,
상기 동작은 단조 카운터(monotonic counter)를 점증시키는 것(incrementing)을 포함하되, 상기 단조 카운터는 상기 신원 값에 의해 식별되는,
엔클레이브 식별 방법.
제1항에 있어서,
상기 동작은 신뢰 시간(trusted time) 측정을 행하는 것을 포함하되, 상기 신뢰 시간은 상기 신원 값에 기반하여 판정되는,
엔클레이브 식별 방법.
적어도 프로세서 및 메모리를 포함하는 시스템으로서, 상기 메모리는 명령어를 저장하되, 상기 명령어는 상기 시스템에 의해 실행되는 경우,
인스턴스화된 엔클레이브에 관련된 동작에 대한 요청 및 신원 타입을 수신하는 것 - 상기 신원 타입은 적어도 하나의 공통 특징을 갖는 복수의 엔클레이브들을 식별하는데 사용가능하고, 상기 복수의 엔클레이브들은 인스턴스화된 상기 엔클레이브를 포함함 - 과,
상기 엔클레이브가 인스턴스화된 엔클레이브 이미지로부터 도출된 정보 및 상기 신원 타입에 적어도 부분적으로 기반하여 해시 함수를 계산하여 상기 해시 함수의 출력으로서 상기 엔클레이브에 대한 신원 값을 제공하는 것 - 상기 엔클레이브 이미지는 복수의 추가적인 종속적(dependent) 엔클레이브 이미지들 각각에 대한 복수의 참조들을 포함하고, 상기 신원 타입은 상기 추가적인 종속적 엔클레이브 이미지들 중 어느 것이 상기 해시 함수에 대한 입력으로서 포함되는지를 나타냄 - 과,
상기 엔클레이브에 관한 보안을 제공하기 위해 상기 신원 값을 이용하여 상기 동작을 수행하는 것
을 적어도 수행하는 것인,
시스템.
제11항에 있어서,
상기 명령어는 또한,
상기 엔클레이브 이미지의 작성자에 관련된 공개 키로 상기 엔클레이브 이미지 내의 시그니처를 확인함으로써 상기 신원 값의 무결성을 확인하는 것을 적어도 수행하는 것인,
시스템.
제11항에 있어서,
상기 명령어는 또한,
상기 신원 타입에 적어도 부분적으로 기반하여, 상기 엔클레이브 이미지의 신원 부분을 판정하는 것을 적어도 수행하는 것이고,
상기 해시 함수를 계산하는 것은,
상기 신원 부분에 대하여 상기 해시 함수를 계산하는 것을 포함하는,
시스템.
삭제
인스턴스화된 엔클레이브에 관련된 동작에 대한 요청 및 신원 타입을 수신하고 - 상기 엔클레이브가 인스턴스화된 엔클레이브 이미지는 추가적인 종속적 엔클레이브 이미지들에 대한 참조들을 포함함 -,
상기 신원 타입에 적어도 부분적으로 기반하여, 해시 함수에 대한 입력으로서 상기 추가적인 종속적 엔클레이브 이미지들 중 어느 것이 적어도 부분적으로 포함되는지를 판정하며,
상기 엔클레이브 이미지로부터 도출된 정보 및 상기 신원 타입에 적어도 부분적으로 기반하여 상기 해시 함수를 계산하여 상기 해시 함수의 출력으로서 상기 엔클레이브에 대한 신원 값을 제공하고,
상기 엔클레이브에 관한 보안을 제공하기 위해 상기 신원 값을 이용하여 상기 동작을 수행하도록 구성된
컴퓨팅 디바이스.