Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

다자간 컴퓨팅 아키텍처

Google Cloud 다자간 계산은 기관의 디지털 애셋 운영을 위한 암호화 신뢰 인프라를 제공합니다. 멀티 단일 테넌트 아키텍처를 사용합니다. 사용자가 만드는 각 인스턴스는 자체 네트워크 인그레스, 자체 스토리지, 암호화 작업을 위한 자체 하드웨어 격리 컴퓨팅을 갖춘 전용 격리 환경입니다.

핵심 구성요소

다자간 계산 아키텍처 다이어그램

각 다자간 컴퓨팅 인스턴스에는 세 가지 주요 구성요소가 있습니다. 거버넌스 로직, 요청 라우팅, 암호화 계산은 별도의 구성요소에서 실행됩니다.

MPC API

Multi-party Compute API는 다음 리소스를 관리합니다.

사용자 및 팀: 인스턴스에서 역할을 보유하는 ID와 키 정책이 참조하는 서명자 그룹입니다.
키링 및 키 정책: 키를 그룹화하는 키링으로, 각 키링에는 키 공유를 보유하는 팀과 사용자를 결정하고 서명을 승인해야 하는 키 공유 수를 결정하는 키 정책이 있습니다.
TransactionPolicies: 트랜잭션을 허용하거나 금지하는 Cedar 규칙과 이를 활성화하거나 사용 중지하는 정책 작성자 승인입니다.
KeyLists: 트랜잭션 정책에서 참조할 수 있는 명명된 주소 목록입니다.

다자간 계산 API는 각 트랜잭션의 상태와 트랜잭션에 기록된 승인을 추적하고 조정자에게 키 생성 및 서명을 조정하도록 요청합니다. Spanner는 요청과 서명된 승인을 저장합니다. 작업자 TEE는 승인 서명을 처리하기 전에 직접 확인합니다.

코디네이터

다자간 계산 API는 컨트롤러를 참여자 TEE에 연결합니다.

키 공유 검색 및 요청 라우팅: 키 생성 중에 새 키 공유를 보유할 정상 TEE를 할당하고 나중에 요청을 적절한 TEE로 라우팅합니다.
상태: 참여자 TEE 상태를 모니터링하고 서명 요청의 부하 분산기 역할을 합니다.
내구성: 키 공유를 교체해야 할 때 다시 공유하는 작업을 관리합니다.

코디네이터는 프로토콜의 보안에 영향을 미치지 않습니다. 키 공유를 보유하지 않으며 승인 또는 정책 결과를 확인하지 않습니다. 이 확인은 참여자 TEE 내에서 이루어집니다.

작업자 TEE

각 작업자는 Confidential Space에서 실행되는 TEE입니다. 작업자 TEE는 다음 두 부분을 실행합니다.

암호화 엔진: 키 공유를 보유하고 다른 작업자 TEE와 함께 보안 임곗값 키 생성 및 서명 프로토콜을 실행합니다.
정책 평가자: 활성 트랜잭션 정책 집합을 기준으로 트랜잭션을 평가합니다.

트랜잭션 서명 흐름

다자간 계산에서는 단일 API 호출인 CreateTransaction를 사용하여 페이로드에 서명합니다. 트랜잭션 정책 평가, 서명자 승인, 기준점 서명은 모두 이 호출로 시작됩니다. 다음은 고정된 순서의 흐름입니다.

요청 서명자가 키에서 CreateTransaction를 호출합니다. 요청에는 서명자의 승인 키로 서명된 서명자 자체 승인이 포함됩니다. IAM은 호출자가 메서드를 호출할 수 있는지 확인하고 요청은 Cloud 감사 로그에 기록됩니다.
정책 평가. 트랜잭션은 활성 트랜잭션 정책 집합을 기준으로 평가됩니다. 정책 평가에서는 각 결과(APPROVED 또는 REJECTED)에 대한 영구 감사 로그를 생성합니다.
개시자 승인. 시작자의 승인만으로 키 정책의 기준점을 충족하는 경우 CreateTransaction는 즉시 5단계로 이동합니다.
서명자 승인 시작자의 승인만으로는 키 정책의 기준을 충족하지 못하는 경우 트랜잭션이 PENDING_AUTHORIZATION 상태로 전환됩니다. 키의 키 공유를 보유한 다른 서명자는 RecordSignerDecision 호출을 사용하여 트랜잭션을 승인하거나 거부하며, 각 호출은 승인 키로 서명됩니다. 트랜잭션은 키 정책의 기준을 충족할 만큼 충분한 서명자가 승인할 때까지 PENDING_AUTHORIZATION 상태로 대기합니다. 충분한 수의 서명자가 거부하여 기준을 더 이상 충족할 수 없으면 트랜잭션이 REJECTED 상태로 전환됩니다. 만료 시간 전에 충분한 승인을 받지 못하면 EXPIRED됩니다.
임곗값 서명. 기준점이 충족되면 키의 공유를 보유한 신뢰할 수 있는 실행 환경 (TEE)이 기준점 서명 프로토콜을 실행하고 트랜잭션에 대한 서명을 생성합니다.

참여자 TEE는 키 공유를 사용하기 전에 서명하도록 요청된 정확한 페이로드가 거래 정책에 따라 평가되었는지 확인합니다. 클라이언트, 운영자 또는 기타 서비스 구성요소는 평가되지 않은 페이로드에 참여자가 서명하도록 할 수 없습니다.

사용자, 팀, 키링, 트랜잭션 정책과 같은 관련 리소스는 다자간 계산 개요를 참조하세요.

보안 모델

TEE에 고정된 키 공유 각 키 공유는 이를 생성한 TEE에서만 읽을 수 있습니다. 키 공유는 조정자, 컨트롤러 또는 Google 운영자를 포함한 다른 구성요소가 읽을 수 있는 형식으로 TEE를 벗어나지 않습니다.
고객 키 보관. 고객은 고객의 Google Cloud 조직에서 Cloud Key Management Service를 사용하여 항상 암호화 키를 완전히 관리합니다.
하드웨어 격리. 참여자 TEE는 Confidential Space에서 실행되며, Confidential Space는 하드웨어 메모리 암호화를 사용하여 호스트 및 Google 인프라에서 사용 중인 데이터를 보호합니다. 증명은 각 TEE를 확인된 컨테이너 이미지에 바인딩합니다.
E2E 암호화 작업자 TEE는 엔드 투 엔드 암호화된 gRPC를 통해 직접 통신합니다.
서명된 승인 서명자, 정책 작성자, 관리자는 비공개 부분이 절대 유출되지 않는 승인 키로 승인에 서명합니다. 참여자 TEE는 거래에 서명하거나, 거래 정책을 수락하거나, 관리자 또는 정책 작성자 역할 변경을 수락하기 전에 이러한 서명을 확인합니다. 이렇게 하면 트랜잭션이 조작 방지되고 영구적인 감사 로그가 남습니다.
정책 작성자 정족수. 새로운 거래 정책 또는 정책 사용 중지 요청은 필요한 수의 정책 작성자가 승인한 후에만 적용됩니다.
관리자 정족수. 관리자 또는 정책 작성자 역할을 부여하거나 삭제하는 것은 필요한 수의 관리자가 승인한 후에만 적용됩니다. 자세한 내용은 역할 변경에 대한 관리자 승인을 참고하세요.

로드맵

향후 출시 버전에서 다음 기능이 제공될 예정입니다.

외부 TEE: 고객이 AWS Nitro Enclaves와 같은 Google Cloud외부에서 실행하는 TEE에 보관된 키 공유입니다.
모바일 키 공유: 사용자의 휴대기기에 보관된 키 공유입니다.
재공유: 키를 변경하지 않고 기존 키의 공유를 보유하는 사용자를 변경하거나 분실된 공유를 대체합니다.

시스템 속성

다자간 계산 트러스트 인프라는 다음 시스템 속성을 유지합니다.

안전성 (암호화 컨텍스트의 건전성)

어떤 상황에서도 시스템은 허용되지 않는 방식으로 작동해서는 안 됩니다. 예를 들어 DKLS23 프로토콜에 따라 k명 미만의 참여자 그룹은 서명을 위조할 수 없습니다. 정확한 보안 정의는 문헌의 범용 구성 가능 프레임워크에서 공식화됩니다.

암호화 시스템이 실제 구현에 포함되는 경우 보안 속성을 저해하는 가정에 의존하지 않도록 주의해야 합니다. 예를 들어 프로토콜의 각 당사자는 독립적이어야 합니다. 즉, 침해에 대한 취약성이 독립적이어야 합니다.

이 속성을 보장하기 위해 다자간 계산은 증명된 TEE에서 각 참여자를 실행하고 각 키 공유는 이를 생성한 TEE에 고정됩니다. 프로토콜에서 한 참여자의 침해는 다른 참여자에게 영향을 미치지 않습니다.

다자간 계산에 관한 학술 문헌은 거의 전적으로 건전성에 초점을 맞추고 있으며, 참여자 집합이 변경 불가능하고, 모든 참여자가 항상 사용 가능하며, 참여자가 이상적이고 항상 사용 가능한 점대점 인증 채널을 사용하여 통신하는 단순한 세상을 가정합니다. 실제 제품의 경우 몇 가지 추가 문제를 해결해야 합니다.

활성

시스템은 결국 진행됩니다. 가장 평범한 생존 속성은 교착 상태가 없는 것으로, DKLS23 프로토콜에 적용됩니다. 임곗값 키는 키 정책의 임곗값을 충족할 수 있을 만큼 충분한 수의 TEE가 공유를 보유하고 있는 한 서명에 사용할 수 있습니다. 예를 들어 3개 중 2개 키를 사용하는 경우 3개 공유 중 2개만 있으면 서명을 완료할 수 있습니다.

내구성

영구적으로 실패한 참여자는 교체해야 합니다. 그렇지 않으면 시스템에서 결국 공유 비밀번호를 영구적으로 잃게 됩니다. 예를 들어 하드웨어에 장애가 발생하면 해당 하드웨어에서 실행 중인 참여자의 상태가 손실됩니다. 키 공유는 TEE에 고정되므로 조정자는 각 키의 공유를 보유하는 TEE를 추적합니다. v1beta에서는 키 정책의 기준점을 충족할 만큼 충분한 공유가 남아 있는 동안 키를 사용할 수 있습니다. 손실된 공유를 교체하려면 다시 공유해야 하며, 이는 향후 출시 버전에서 지원될 예정입니다.

구성 변경사항

하드웨어 장애 (TEE에서 데이터 손실)와 조직 변경 (신규 직원이 비밀 키의 공유를 통해 프로토콜에 참여) 모두 키의 공유를 보유하는 사용자를 변경해야 합니다. 다자간 계산은 DKLS23의 건전성 속성을 보존하는 보안 재공유 프로토콜을 통해 이를 지원할 계획입니다. 재공유에 참여하는 악의적인 새 당사자는 다른 악의적인 당사자와 마찬가지로 비밀의 공유를 최대 하나만 유출합니다.