분산 시스템에서 데이터에 대한 의미 있는 제어.
Oak는 분산 시스템을 구축하기 위한 소프트웨어 플랫폼으로, 시스템 동작에 대해 외부에서 검증 가능한(또는 반증 가능한) 주장을 투명한 방식으로 제공합니다.
Oak는 Enclave Application, 즉 실행되는 호스트로부터 격리되고 원격으로 증명 가능한 애플리케이션을 구축하는 데 사용되는 빌딩 블록을 제공합니다.
이 문서에서는 이기종 "노드"로 구성된 분산 시스템에 초점을 맞춥니다. 노드는 서버(예: 사설 데이터 센터, 퍼블릭 클라우드 제공자 등)에서 실행되는 Enclave Application일 수도 있고, 클라이언트 기기(예: 휴대폰, 노트북)에서 실행되는 일반 애플리케이션일 수도 있으며, 일반 HTTP 또는 gRPC 서비스, 스토리지 시스템 등일 수도 있습니다. 두 노드가 서로 통신할 때, 둘 중 하나 또는 둘 다가 Enclave Application일 수 있습니다. 두 노드 간의 각 상호작용에 대해 우리는 이들을 "initiator"와 "responder"라고 부릅니다. 일부 경우 "initiator" 노드가 실제로 "서버"에서 실행 중일 수 있기 때문에(모든 조합이 가능함) 우리는 이러한 역할에 대해 "client"와 "server"라는 용어를 사용하지 않습니다.
Oak 분산 시스템의 Enclave Application은 다른 노드에 자신을 원격으로 증명할 수 있습니다. 이는 로컬 암호화 키(변조 방지 하드웨어에 저장되어 키를 유출하거나 복사할 수 없음을 보장함)에 바인딩된 자체 소프트웨어 및 하드웨어 신원에 대한 증거를 제공하는 것으로 구성되며, 궁극적으로 해당 노드의 호스트에서 사용 가능한 하나 이상의 소프트웨어 또는 하드웨어 신뢰 루트에 의해 서명됩니다. Enclave Application의 소프트웨어 신원은 이에 기여하는 실행 파일 바이너리의 측정값(즉, 다이제스트/해시)과 추가 데이터(예: 구성)로 구성됩니다.
Oak는 Enclave Application의 하드웨어 신뢰 루트로서 VM 기반 신뢰 실행 환경(TEE) (예: AMD SEV-SNP, Intel TDX)에 초점을 맞춥니다. 이를 통해 Enclave Application은 TEE 내의 하드웨어 바인딩 키로 서명된 원격 증명 보고서를 제공할 수 있으며, 이러한 키는 서비스 제공자가 접근할 수 없습니다. 이 키들은 궁극적으로 TEE 제조사(예: AMD, Intel)에 뿌리를 두고 있으며, 이는 신뢰를 서로 공모하지 않는 여러 행위자에 분산시킴으로써 해당 노드의 증거를 검증하기 위해 서비스 제공자를 신뢰해야 할 필요성을 줄여줍니다(이상적으로는 제거합니다).
시작 시 각 Enclave Application은 로컬 키 쌍을 생성하고 공개 키를 자체 증거에 바인딩합니다. 노드가 Enclave Application과 통신하려고 할 때(initiator 또는 responder로서), 두 노드 사이에 종단 간 암호화된 채널이 설정됩니다. 채널 설정의 일부로 각 노드는 자신의 증거(있는 경우)를 상대 노드에 제공하며, 상대 노드가 제공한 증거를 사용하여 데이터 교환 여부를 결정하기 전에 상대 노드의 신뢰성을 확립할 수 있습니다.
이 암호화되고 증명된 채널은 다음을 제공합니다:
Enclave Application의 공격 표면과 신뢰 컴퓨팅 기반(TCB)을 최소화하기 위해 Oak는 분할 아키텍처를 권장합니다:
Enclave 애플리케이션: 오픈 소스 코드로부터 (재현 가능하게) 빌드되어 TEE 내부에서 실행되는 바이너리입니다. Enclave 애플리케이션은 증명 증거(attestation evidence)에 바인딩된 복호화 키에 접근할 수 있으며, 다른 노드로부터 들어오는 요청을 복호화하고 처리한 뒤 응답을 암호화하여 통신 채널을 통해 다시 전송합니다. 이 바이너리가 외부에서 검증 가능한 클레임과 연관된 바이너리입니다. 다른 어떤 바이너리도 들어오는 요청을 평문으로 접근할 수 없습니다.
호스트 애플리케이션: 호스트(신뢰할 수 없는) 서버 환경에서 실행되며 Enclave 애플리케이션의 프런트엔드 역할을 하는 바이너리로, 다른 노드가 외부에서 접근할 수 있는 gRPC 엔드포인트를 노출합니다. 이 바이너리는 암호화된 데이터만 취급하며, 주요 역할은 TEE 내에 Enclave 애플리케이션 인스턴스를 생성하고 유지하며 암호화된 데이터를 Enclave 애플리케이션으로 전달하고 다시 받아오는 것입니다. 또한 서비스 제공자 인프라에서 실행되는 데 필요한 제어 평면(control plane)이나 기타 내부 시스템과 상호작용하기 위한 독점 로직을 포함할 수도 있습니다.
이 아키텍처 덕분에 서비스 제공자는 탐지되지 않은 채로 Enclave 애플리케이션 바이너리를 다른 (잠재적으로 악의적인) 바이너리로 교체할 수 없습니다. 만약 서비스 제공자가 Enclave 애플리케이션에 백도어를 삽입하려 한다면, 해당 바이너리에 서명하고 Transparent Release 프로세스를 통해 검증 가능한 로그에 게시해야 하며, 이는 백도어를 외부 관찰자에게 되돌릴 수 없이 가시화하게 만듭니다.
Oak의 대표적인 용도는 프라이버시를 보존하는 sealed computing 애플리케이션을 구축하는 것입니다.
sealed computing 애플리케이션에서 노드(보통 클라이언트 장치)는 데이터를 enclave 애플리케이션(보통 서버)으로 전송하며, enclave 애플리케이션을 호스팅하는 서비스 제공자가 연산의 입력, 출력 또는 부수 효과를 볼 수 없는 상태에서 데이터를 처리합니다.
다음은 단순화된 아키텍처 다이어그램입니다.
Oak는 Enclave 애플리케이션이 배포될 수 있는 TEE 내 운영 체제의 두 가지 방식을 지원합니다:
Oak Restricted Kernel: 단일 CPU와 단일 애플리케이션만 지원하는, 매우 최소한으로 직접 작성된 커스텀 마이크로커널입니다. 애플리케이션에 매우 제한된 시스템 콜 집합만 노출함으로써 애플리케이션이 할 수 있는 일에 매우 엄격한 제약을 둡니다. Oak Restricted Kernel 애플리케이션은 TEE 내부의 전체 신뢰 코드 기반(trusted code base)에 대한 검토가 중요한 경우, 그리고 제한된 기능과 감소된 성능이 수용 가능한 트레이드오프인 경우에 적합합니다. 이상적으로는 한 명의 전문가가 Oak Restricted Kernel의 코드 전체를 몇 주 안에 검토할 수 있어야 합니다.
Oak Containers: Enclave 애플리케이션이 OCI 런타임 번들의 일부로 제공됩니다. 여기에는 전체 Linux 커널과 컨테이너 런타임 엔진을 갖춘 Linux 배포판이 TEE 내부에 포함됩니다. OCI 런타임 번들을 호환성 계층으로 사용하면 더 익숙한 개발 경험과 더 많은 유연성을 제공합니다. Oak Containers는 TEE 내에서 여러 CPU도 지원하므로 높은 성능 요구 사항이 있는 경우에 적합합니다. 이 접근 방식의 단점은 TEE에서 실행되는 전체 신뢰 코드 기반의 크기가 상당히 커진다는 점입니다. 한 명의 사람이 전체 Linux 커널과 Linux 배포판의 코드를 검토하는 것은 불가능하기 때문입니다. 이 접근 방식의 신뢰 모델은 더 넓은 Linux 생태계의 보안에 의존합니다. Linux 커널이 애플리케이션에 제공하는 추가 기능과 유연성은 애플리케이션의 동작을 추론하기 어렵게 만들고, 이는 다시 검토 프로세스를 더 복잡하게 만듭니다.
원격 증명은 TEE가 자신의 상태와 TEE 내부에서 실행 중인 워크로드(Enclave 애플리케이션)의 신원에 대한 증거를 원격 당사자에게 제공하는 프로세스입니다.
Oak는 부팅 과정에서 각 계층의 정체성(부트로더뿐만 아니라 그 이후의 계층까지)을 측정하고 이를 TEE 증거와 암호학적으로 결합하기 위해 다단계 프로토콜을 사용합니다. Oak Stage 0 가상 펌웨어는 VM 메모리에 미리 로드되며, TEE 증명 보고서에 포함됩니다. 이후의 부팅 단계를 포괄하기 위해 Oak는 Device Identifier Composition Engine (DICE) 접근 방식을 사용하며, 여기서 각 부팅 단계는 다음 단계를 측정할 책임이 있습니다. Oak는 이 추가 증거로 증명 보고서를 보강하여 워크로드의 모든 구성 요소(예: 커널 및 애플리케이션)의 정체성이 증거에 포함되도록 합니다.
노드가 Enclave Application에 연결할 때, 먼저 증명 증거와 관련 보증(endorsement)을 요청합니다. 보증에는 증명 보고서가 합법적인 AMD CPU에 의해 서명되었음을 증명하는 AMD로부터의 인증서 체인과, 선택적으로 enclave 내부에서 실행되는 다양한 구성 요소 개발자들의 서명된 진술이 포함됩니다. 그런 다음 다른 노드는 이러한 보증을 사용하여 증거를 검증하고 자신의 기대치와 일치하는지 확인합니다. 클라이언트 노드는 enclave 애플리케이션이 최신 상태이고 올바르게 구성된 TEE(예: CPU가 최신 버전의 마이크로코드와 SNP 펌웨어를 실행 중이고 디버깅이 비활성화되어 있음)에서 실행되고 있는지, 그리고 enclave 내부에서 실행되는 다양한 구성 요소의 정체성이 기대치와 일치하는지 확인해야 합니다.
노드가 enclave 애플리케이션이 모든 기대치를 충족한다고 확인하면, 증거에 바인딩된 공개 키를 사용하여 enclave 애플리케이션과의 암호화된 채널을 설정합니다.
enclave 애플리케이션이 기대에 따라 데이터를 처리할 것임을 확신하기 위해, 외부 검토자는 TEE에서 실행되는 코드를 검토해야 합니다. Oak는 대부분의 Oak 구성 요소에 대한 출처(provenance) 정보를 게시하여 이를 가능하게 합니다. 이는 검토자가 증명 증거의 바이너리 측정 다이제스트를 통해 각 구성 요소를 빌드하는 데 사용된 정확한 소스 코드 커밋을 조회할 수 있게 해주는 역 인덱스 역할을 합니다. 모든 Oak 구성 요소는 재현 가능하게 빌드 가능하며(아래 Transparent Release 참조), 이는 검토자가 특정 소스 코드 커밋을 가져와 구성 요소를 다시 빌드하여 동일한 정확한 측정 다이제스트가 생성되는지 확인할 수 있음을 의미합니다. 이를 통해 검토자는 자신이 검토하는 코드 버전이 시작 중에 enclave에 로드된 것과 정확히 동일한 코드 버전임을 확신할 수 있습니다.
Transparent Release는 개발자가 바이너리 아티팩트에 대한 주장(claim)을 투명하고 부인 불가능한 방식으로 게시하고 소비할 수 있게 해주는 형식과 도구의 집합입니다.
원격 증명 프로세스의 일부로, 노드는 하나 이상의 바이너리 다이제스트(예: 일반적으로 부팅 체인의 각 계층마다 최소 하나씩) 형태로 Enclave Application의 정체성을 획득하며, 그런 다음 이러한 측정값이 신뢰할 수 있는지 여부를 확립해야 합니다.
첫 번째 근사치로서, 클라이언트가 하드코딩을 통해 어떤 다이제스트를 기대해야 하는지 정확히 알고 있으며 실제 값을 로컬에서 기대값과 검증할 수 있다고 가정할 수 있습니다. 이는 작동하지만, 서버 애플리케이션의 진화 측면에서 매우 제한적입니다. 새로운 릴리스의 일부로 Enclave Application 바이너리 중 하나라도 변경되는 즉시 노드는 Enclave Application을 신뢰하지 않게 되고, 둘은 더 이상 상호작용할 수 없게 됩니다.
다이제스트 자체 대신 바이너리 다이제스트에 서명하는 데 사용되는 공개 키를 노드에 하드코딩하여 이 문제를 해결할 수 있습니다. 이렇게 하면 Enclave Application 바이너리가 변경될 때 개발자가 자신이 보유한 해당 개인 키로 서명하고, 이 서명을 원격 증명 보고서와 함께 노드에 배포할 수 있으며, 노드는 이 서명의 유효성을 검증할 수 있습니다. 이는 작동하지만, Enclave Application이 서로 다른 노드에 서로 다른 서명을 제시할 수 있게 되어 사용자가 탐지하기 매우 어렵다는 문제가 있습니다.
구현된 해결책은 새 릴리스가 생성될 때 다이제스트에 서명할 뿐만 아니라, 이 서명을 외부의 추가 전용 검증 가능 로그에 기록하는 것입니다. Oak는 이를 위해 Rekor(Sigstore 제공)를 외부 검증 가능 로그로 활용합니다. Transparent Release 프로세스의 일환으로 서명이 Rekor에 기록되고, 그로부터 포함 증명(또는 포함 약속)을 얻으며, 이는 Rekor의 루트 키로 서명됩니다. 그런 다음 이는 해당 바이너리 아티팩트와 함께 저장되어, Enclave Application의 신원을 검증하려는 노드에 제공됩니다. 이로써 개발자가 검증 가능 로그에 기록하지 않고서는 Enclave Application에 백도어를 삽입하는 것이 불가능해집니다.
완벽한 보안은 불가능하다는 점을 인정합니다. 일반적으로 신뢰 컴퓨팅 기반(TCB)이 작을수록 좋으며, Oak는 TCB를 신뢰해야 하는 최소 구성 요소로 축소하려고 노력합니다.
Oak는 다음을 신뢰할 필요 없이 검증 가능하게 신뢰할 수 있도록 설계되었습니다:
