Google Cloud Key Vault 서비스

낮은 엔트로피 지식 계수 (예: 잠금 화면 PIN)로 액세스를 보호하기 위해 보안 하드웨어를 사용하여 암호화 키를 저장하는 클라우드 서비스에 대해 설명합니다. 보안 하드웨어는 올바른 지식 계수를 제공하려는 시도가 너무 많이 실패하면 저장된 암호화 키를 영구적으로 가져올 수 없도록 하여 무차별 대입 공격을 방지하도록 설계되었습니다.

작성자: Shabsi Walfish
버전 날짜: 2018년 3월 6일

참고: 이 문서는 아직 작업 중이며 구현의 세부사항은 아직 완성되는 중입니다. 시스템이 안정화되고 더 많은 문서를 생성할 수 있게 됨에 따라 (특히 관련 오픈소스 버전과 함께) 이 백서를 보다 자세한 정보로 업데이트할 예정입니다.

개요

기본적으로 데이터 개인 정보 보호를 위해 사용되는 암호화에는 공격자의 관점에서 엔트로피가 높은 보안 비밀을 사용해야 합니다. 암호화 체계는 올바른 보안 비밀을 찾을 때까지 가능한 모든 보안 비밀의 공간을 탐색하는 무차별 대입 공격을 방지해야 하므로 높은 엔트로피가 필요합니다. 오늘날의 컴퓨팅 성능을 고려할 때 암호화 보안 비밀의 합당한 최소 엔트로피 요구사항은 약 70~80비트일 수 있습니다. 안타깝게도 인간은 특히 이러한 양의 엔트로피¹를 가진 비밀번호 또는 기타 보안 비밀을 기억하고 안정적으로 기억하는 것이 매우 어렵다고 생각합니다. 특히 엔트로피가 높은 비밀번호를 자주 사용하는 것은 어렵고 지루한 일입니다. 이로 인해 까다로운 문제가 발생합니다. 사용자가 기억할 가능성이 매우 높은 '지식 계수'가 되도록 보안 비밀이 되도록 하려면 암호화 기술로 어떻게 비공개 데이터를 보호할 수 있을까요? 여러 가지 이유로 이 문제는 해결하기가 매우 어려우며, Cloud Storage 서비스는 일반적으로 사용자가 자신의 보안 비밀을 기억하도록 의존하지 않고 클라우드 스토리지 제공업체가 자체적으로 관리하는 보안 비밀로만 데이터를 암호화합니다.

암호화 보안 비밀과 인간이 기억할 수 있는 보안 비밀에 대한 요구사항 간의 격차를 해소하는 한 가지 방법은 Cloud Key Vault(CKV) 서비스를 사용하여 높은 엔트로피의 '복구 키'를 저장하는 것입니다. 이 키는 인간이 기억할 수 있는 낮은 엔트로피의 보안 비밀로 보호됩니다. CKV 서비스는 인간이 기억할 수 있는 올바른 비밀번호를 알고 있음을 증명하는 당사자에게만 복구 키를 공개합니다. 기억하기 쉬운 보안 비밀에 대한 무차별 대입 공격은 CKV 서비스에 의해 저지될 수 있습니다. CKV 서비스는 보안 비밀 지식을 증명하기 위해 실패한 시도 횟수를 절대적으로 제한합니다. 복구 키 자체는 어디서나 안전하게 저장할 수 있는 대용량 데이터 (예: 디스크 백업)를 쉽게 암호화할 수 있는 (인증된) 암호화 체계에 사용하기에 적합한 표준 암호화 대칭 키입니다. 이러한 암호화된 데이터는 복구 키를 얻을 수 없는 사람에게는 쓸모가 없습니다.

이 백서에서는 신뢰할 수 있는 하드웨어 모듈 (THM)을 사용하여 Cloud Key Vault 서비스를 구성하는 방식에 대해 설명합니다. CKV 서비스의 첫 번째 구현은 사용자의 LSKF(잠금 화면 지식 계수)(스마트폰 잠금 해제에 사용되는 비밀 PIN, 비밀번호 또는 스와이프 패턴)로 복구 키를 보호하도록 설계되었습니다. 인간은 LSKF를 안정적으로 기억할 수 있습니다. 동시에 이러한 LSKF 보안 비밀은 일반적으로 시도 횟수가 매우 제한된 공격자를 막을 만큼 엔트로피가 충분하므로 CKV 서비스에 적합합니다.

Cloud Key Vault 서비스는 가장 먼저 클라이언트 측에서 암호화된 Android 백업을 사용 설정할 예정입니다. 이전에는 Android 기기에서 로컬로 암호화된 파일은 사용자의 LSKF로 보호되는 키를 사용했지만, 클라우드에 저장되고 암호화된 파일의 백업은 LSKF로 보호되지 않았습니다. Cloud Key Vault는 최초로 클라우드에 저장된 Android 백업에 대해서도 잠금 화면 보호를 사용 설정합니다. 즉, Google 서버는 암호화된 백업의 콘텐츠에 액세스하거나 이를 복원할 수 없으며 사용자의 LSKF가 있는 기기만 백업을 복호화할 수 있습니다.

핵심 개념

처음에 Cloud Key Vault 서비스에 지원되는 유일한 클라이언트 플랫폼은 Android 9 Pie 운영체제였으며, 이 백서에서 언급될 때는 Google Play 서비스로 Android 9 Pie 운영체제를 실행하는 기기를 가리킵니다. Google의 서버 측 구현은 추가 Titan 칩²이 설치된 특별히 지정된 Google 서버에서 실행됩니다. Google에서 설계한 Titan 칩은 Google의 신뢰할 수 있는 하드웨어 모듈의 하드웨어 구성요소 역할을 하며, Google의 프로토콜 및 보안 시행 메커니즘을 구현하는 맞춤 부트로더 및 펌웨어를 특별히 제공합니다 (여기에 설명됨). Google에서는 프로토콜이 Titan 하드웨어에서 실제로 실행되고 있는지 확인하기 위해 하드웨어 증명 기법을 사용합니다.

CKV 서비스는 하드웨어 고장 (예: 번아웃 칩)이나 데이터 센터 유지보수로 인한 장시간 중단으로 인해 상당한 양의 사용자 데이터가 손실되는 일 없이 수십억³의 Android 기기에서 발생하는 트래픽을 처리할 수 있도록 확장되어야 합니다. 이러한 이유로 Titan 칩이 설치된 서버는 코호트로 구성되며, 각 코호트는 각각 동일한 키 자료의 사본을 포함하는 여러 개의 독립적인 THM으로 구성됩니다. 시스템이 가용성 및 안정성 목표를 충족할 수 있도록 특정 사용자 집단은 물리적으로 서로 다른 데이터 센터에 분산됩니다. 확장성을 위해 클라이언트는 여러 다른 사용자 집단으로 샤딩되므로 서버를 더 추가하는 것만으로 사용 가능한 동질 집단 수를 늘리는 방식으로 서비스 용량을 조정할 수 있습니다.

이제 Cloud Key Vault 서비스 아키텍처의 주요 구성 요소를 열거할 준비가 끝났습니다.

아키텍처 구성 요소 / 용어 설명

잠금 화면 지식 계수 (LSKF): 짧은 PIN, 3x3 점 그리드를 통한 스와이프 패턴, 비밀번호와 같이 사람이 기억할 수 있는 보안 비밀입니다. 이 보안 비밀은 기기를 로컬에서 잠금 해제하는 기능을 보호하는 데 사용되며 사용자의 로컬 기기 화면 잠금의 기본 (또는 '강력한') 인증 요소로 간주됩니다.

클라이언트: Android 9 Pie 운영체제와 Google Play 서비스 또는 동등하게 지원되는 소프트웨어를 실행하는 최종 사용자 기기입니다.

Android 프레임워크: Android 9 Pie 이상에 있는 API를 지칭하기 위해 이 일반적인 용어 (또는 프레임워크)를 사용하며, 이전 버전을 의미하는 것은 아닙니다.

Google Play 서비스: 최종 사용자 기기에서 실행되는 서비스 및 앱의 모음으로, Google의 계정 시스템 및 맞춤 서버 API와 호환됩니다.

복구 에이전트: Android 9 Pie 기기 (또는 이와 유사한 기기)의 사용자 공간에서 Google Play 서비스의 일부로 실행되는 시스템 애플리케이션입니다. 복구 에이전트는 다양한 프로토콜의 클라이언트 측을 실행하고, LSKF와 관련된 프로토콜 메시지를 작성하기 위해 필요에 따라 Android 운영체제와 인터페이스하는 역할을 합니다.

복구 클레임: 사용자가 복구 키를 검색하려는 경우 복구 클레임을 만들어야 합니다. 이 복구 클레임에는 사용자가 알고 있다고 주장하는 LSKF의 암호화된 사본이 있습니다. 일반적으로 사용자에게 이전 기기의 복구 키에 액세스하려는 새 기기에 이전 기기의 LSKF를 입력하라는 메시지가 표시됩니다.

복구 키: Cloud Key Vault 서비스로 보호되고 클라이언트 기기에서 데이터를 암호화 및 인증하는 데 사용되는 암호화 비밀번호 키입니다. 복구 키를 Vault에 입력하면 (아래 참조) 클라이언트에서 복구 키를 사용하여 데이터를 암호화하는 즉시 로컬 사본을 삭제할 수 있습니다.

Cloud Key Vault (CKV) 서비스: 클라이언트 기기에서 사람이 기억할 수 있는 LSKF로 보호되는 암호화 키를 저장할 수 있는 인터넷 서비스입니다.

코호트: 서로의 중복 복제본 역할을 할 수 있는 Vault 서버/THM의 모음입니다.

코호트 공개 키: 특정 THM 코호트에 의해 생성된 키 쌍의 공개 키입니다. 해당하는 비공개 키는 키 생성 시 코호트에 있던 THM 내부에서만 사용할 수 있습니다.

신뢰할 수 있는 하드웨어 모듈 (THM): 신뢰할 수 있는 최소한의 컴퓨팅 환경을 제공하도록 설계된 전용 보안 모듈(마이크로 컨트롤러)입니다. 최소한 보안 요소는 보안 키를 생성 또는 저장하고 비휘발성 진화 상태를 유지할 수 있어야 합니다. 그래야 이전 상태로 재설정하는 것과 관련된 공격을 방지할 수 있습니다.

Vault: CKV 서비스 데이터베이스의 특정 항목으로, 단일 기기의 LSKF 보호 복구 키를 포함합니다. 최종 사용자는 여러 Vault를 파일에 둘 수 있으며, 각 Vault는 각기 다른 기기 또는 LSKF에 상응합니다. Vault 서버의 THM만 Vault의 콘텐츠를 검사하거나 추출할 수 있습니다.

Vault 서버: THM (신뢰할 수 있는 하드웨어 모듈)을 추가하기 위해 특별히 개조한 Google 데이터 센터에서 작동하는 범용 머신입니다.

프로토콜 디자인

CKV 프로토콜은 다음과 같이 여러 단계로 구성됩니다.

초기화

시스템을 초기화하기 위해 Google은 Framework가 Google의 하드웨어 증명을 확인하는 데 사용할 '신뢰할 수 있는 루트'의 공개 키를 제공합니다. 이 신뢰할 수 있는 루트의 서명 키는 오프라인에 저장되며 여러 직원이 참여해야 서명할 수 있도록 신중하게 보호됩니다. 이 신뢰할 수 있는 루트의 공개 키는 Android OS에 베이킹되며 OS 업데이트를 통해서만 변경할 수 있습니다.

또한 Google은 목록에 있는 증명과 함께 각 THM 코호트의 공개 키 목록을 주기적으로 게시합니다. 목록의 증명은 신뢰할 수 있는 루트에 다시 연결하는 서명을 사용합니다. 게시된 목록의 각 업데이트에는 순서 번호도 포함되므로 롤백을 방지할 수 있습니다. 복구 에이전트는 가장 최근에 게시된 코호트 공개 키 목록을 가져와 Framework에 제공합니다. 그런 다음 Framework는 증명을 확인하고 Vault 생성 단계에서 사용할 동질 집단 공개 키를 목록에서 무작위로 선택합니다.

Vault Creation

코호트 공개 키 목록을 가져와 프레임워크가 초기화를 완료하도록 한 후 복구 에이전트는 프레임워크에 새 Vault를 만들도록 요청합니다. 다음에 사용자가 LSKF를 입력할 때마다 프레임워크는 새로운 복구 키를 생성하고 먼저 LSKF의 해시에서 파생된 키로 암호화한 다음 초기화 중에 프레임워크에서 선택한 코호트 공개 키로 암호화합니다. 그 결과로 암호화된 blob은 Framework에 의해 복구 에이전트로 다시 전달된 Vault이며, Vault에서는 이를 Google의 CKV 서비스에 업로드합니다.

Vault Opening

새 기기의 복구 에이전트가 특정 Vault에 저장된 복구 키에 액세스해야 하는 경우 먼저 Vault를 만든 원래 기기의 LSKF를 입력하라는 메시지가 사용자에게 표시됩니다. 그러면 복구 에이전트는 Framework에 해당 LSKF를 사용하여 복구 클레임을 생성하도록 요청합니다. 프레임워크는 새로운 신고자 키를 생성하고, Vault가 원래 암호화될 때 사용한 것과 동일한 코호트 공개 키를 사용하여 신고자 키와 소유권이 주장된 LSKF의 해시를 암호화합니다. 그 결과로 암호화된 blob을 복구 클레임이라고 하며, Framework는 이를 복구 에이전트로 전달하고 복구 에이전트는 CKV 서비스에 제공합니다.

CKV는 복구 클레임 (및 상응하는 Vault)을 올바른 사용자 집단에 속한 Vault 서버로 라우팅합니다. 그러면 Vault 서버의 THM이 복구 클레임을 복호화하고 내부 암호화 키를 파생하기 위해 소유권 주장이 제기된 LSKF 해시를 사용하여 원래 Vault에서 복구 키를 추출하려고 시도합니다. 원래 LSKF 해시와 소유권이 주장된 LSKF 해시가 일치하면 THM은 Vault에서 복구 키를 추출하고 복구 클레임에 있던 신고자 키로 다시 암호화합니다. 일치하지 않으면 THM이 실패한 시도 카운터를 범프합니다. 실패한 시도 카운터가 한도에 도달하면 THM은 이 Vault에 대한 후속 복구 클레임 처리를 거부합니다.

마지막으로 모든 것이 잘 진행되면 다시 암호화된 복구 키 (현재 신고자 키에서 암호화됨)가 Vault 서버에서 프레임워크로 다시 전송됩니다. 프레임워크는 신고자 키의 사본을 사용하여 복구 키를 복호화하며, 이제 프로토콜이 완성됩니다.

보안 대책

Cloud Key Vault 시스템은 여러 수준의 스택에 보안 보호를 포함함으로써 '심층 방어'를 제공하는 것을 목표로 합니다. 이러한 보호가 어떻게 작동하는지 이해하기 위해 먼저 클라이언트를 설명하고 스택을 올라가서 Cloud Key Vault Service까지 진행해 보겠습니다.

클라이언트 보안

특정 OEM 및 기기에 따라 LSKF (Lock Screen Knowledge Factor)는 일반적으로 OEM에 따라 다른 다양한 방법을 사용하여 기기에 저장되고 보호됩니다. 예를 들어 Google의 Pixel 2 기기는 조작 방지 하드웨어 보안 모듈을 사용하여 저장 LSKF를 저장하고 LSKF 유효성 검사에 하드웨어 기반 비율 제한을 적용합니다. Cloud Key Vault를 사용할 수 있도록 도입되는 새로운 Framework API는 기기에서 이러한 하드웨어 보안 모듈을 사용하여 LSKF의 저장소를 보호하는 경우에도 기존 보안 보장을 최대한 보존하도록 설계되었습니다.

이 섹션에서는 LSKF와 관련된 모든 보안 메커니즘을 완벽하게 설명하기보다는 새로운 Cloud Key Vault 기능에 영향을 미치는 관련 보안 문제 및 보호 조치를 중점적으로 설명합니다.

Framework API 보안

CKV 서비스를 지원하기 위해 추가된 새로운 Framework API는 @SystemApi로 표시되며 Google Play 서비스와 같이 OEM 승인 시스템 앱에서만 사용할 수 있도록 하는 특별 권한이 필요합니다. 이렇게 하면 사용자가 기기에 설치하는 앱에 노출될 수 있는 직접적인 공격 표면을 모두 제거할 수 있습니다.

또한 Framework API는 신뢰할 수 있는 루트에 의해 증명된 동질 집단 공개 키에 대해서만 Vault가 생성되도록 합니다. 신뢰할 수 있는 루트는 OEM이 프레임워크에 베이킹하며, OS 업데이트 없이 변경할 수 없습니다. 따라서 LSKF가 하드웨어 기반의 무차별 대입 보호를 올바르게 시행하는 Vault를 만드는 데만 사용된다는 확신을 가질 수 있습니다. LSKF에 대한 무차별 대입 보호에 Cloud Key Vault 서비스의 THM을 사용하면 Google Pixel 2 기기와 마찬가지로 기기의 보안 하드웨어를 사용하는 것과 동일한 보안을 구현할 수 있습니다.

LSKF가 보안 하드웨어 외부의 기기 어디에도 저장될 것이라고 가정하지 않으므로 새 Vault는 기기 잠금 해제 직후에만 만들 수 있습니다. 사용자가 기기의 잠금을 해제하기 위해 LSKF를 입력할 때 LSKF는 잠시 프레임워크에서 RAM에 제공됩니다. 바로 그 순간에 Vault를 생성하는 새 API가 LSKF를 사용합니다. LSKF를 사용할 수 없으므로 기기가 잠겨 있는 동안에는 새 LSKF 보호 Vault를 만들 수 없습니다.

복구 에이전트 보안

복구 에이전트에서 제공하는 기본 보안 보호 기능은 복구 에이전트가 현재 기기 또는 복구 키의 LSKF를 볼 수 없도록 프로토콜이 설계되어 있다는 것입니다. 클라이언트 측에서는 Framework만 이러한 정보를 볼 수 있어야 하므로 복구 에이전트의 잠재적인 버그나 보안 취약점을 악용하기가 훨씬 더 어려워집니다. 복구 에이전트는 수명 주기 이벤트와 클라우드와 프레임워크 간의 데이터 전달을 관리하는 데 주로 사용됩니다. 유일한 예외는 Vault Opening 프로토콜 직전의 복구 중에 사용자가 이전 기기의 LSKF(이전 기기의 소유권 주장이 제기된 LSKF를 수집하는 UI가 복구 에이전트⁴에서 구현됨)를 입력해야 하는 경우에 발생합니다. 하지만 복구 에이전트 구현은 프레임워크가 복구 클레임 생성을 인계받는 즉시 클레임된 LSKF를 '삭제'합니다.

프로토콜의 보안 기능

프로토콜의 전체 분석은 이 문서의 범위를 벗어나지만 프로토콜에 내장된 몇 가지 보호 기능을 강조하고 싶습니다. 특히 이 프로토콜은 전체적으로 LSKF의 해시만 사용합니다. 즉, LSKF의 엔트로피가 높은 경우 (예: 양호한 하이 엔트로피 비밀번호인 경우) Vault를 저장하는 것이 비밀번호 해시를 저장하는 것보다 엄밀히 나으며, 이 경우 비밀번호 해시는 THM의 보안과 별개로 보안 조치를 제공할 수 있습니다. 이러한 이유로 Google에서는 프로토콜의 일부로 LSKF의 솔트 처리된 '메모리 하드' 해싱을 지원합니다. 또한 Google은 Vault를 생성된 기기의 식별자에 암호화 방식으로 바인딩하고, Vault Opening 프로토콜에서 챌린지로 사용되는 nonce에 복구 클레임을 바인딩하여 복구 클레임을 최신 상태로 유지합니다.

복구 키는 Vault를 만들 때마다 새로 생성되므로 기존 Vault 항목을 새로 만든 Vault로 덮어쓰는 방식으로 키 순환을 구현합니다. Vault에서 사용하는 실패한 시도 카운터의 주소는 Vault 생성 중에 선택되며, 프레임워크는 LSKF가 변경되었거나 코호트 공개 키의 새로운 증명된 목록이 없는 한 후속 Vault에 사용되는 카운터 주소가 변경되지 않도록 합니다. 따라서 LSKF의 무차별 대입 보호를 손상하지 않고 복구 키를 순환할 수 있습니다.

Cloud Key Vault 서비스를 위한 서버 보안

서버는 일반적인 서버 하드웨어에서 실행되는 소프트웨어와 특수 하드웨어 (Titan 칩)에서 실행되는 펌웨어의 조합을 사용하여 구현됩니다. 각 레이어에서 제공되는 보호 조치를 설명합니다.

하드웨어 보호

CKV 서비스의 서버 측에서 구현된 기본 보안 보호는 Google의 자체 맞춤 설계된 Titan 칩을 사용하여 빌드된 신뢰할 수 있는 하드웨어 모듈 (THM)입니다. 이 칩은 CKV 프로토콜을 구현하는 데 필요한 API를 노출하는 펌웨어를 실행합니다. 특히 키 쌍을 생성하여 동질 집단의 다른 구성원과 안전하게 공유할 수 있습니다. 그러면 펌웨어 로직이 비공개 키가 동질 집단의 Titan 칩 외부로 누출되지 않도록 보호할 수 있습니다. 또한 Vault Opening 작업을 수행할 수 있으며, 실패한 시도의 Vault별 카운터를 엄격하게 증가시킬 수 있습니다 (Titan 칩 내에 저장된 상태로 카운터가 지원됨). CKV Titan 칩 펌웨어에서 실행하는 프로토콜에 관한 더 자세한 설명은 이 문서의 향후 버전에서 제공됩니다.

서버 보안이 Titan 칩의 펌웨어 로직에서 파생되므로 칩이 보안 비밀을 유출하거나 카운터 제한을 무시할 수 있는 방식으로 로직이 변경되지 않도록 해야 합니다. 이 목표를 달성하기 위해 Titan 부트로더를 변경하여 업데이트가 적용되기 전에 칩의 저장된 데이터 (예: 동질 집단의 비공개 키)가 완전히 삭제되도록 합니다. 이 보호 기능의 단점은 데이터 손실을 경험하지 않고 펌웨어의 버그를 패치할 수 없다는 것입니다. 펌웨어를 업데이트하는 것은 기존 하드웨어를 폐기하고 새 칩으로 교체하는 것과 기능적으로 동일합니다. 중요한 펌웨어 패치가 필요한 경우 Google은 증명된 동질 집단 공개 키의 완전히 새로운 목록을 만들어 게시하고 모든 사용자를 점진적으로 새 목록으로 이전해야 합니다. 이러한 위험을 완화하기 위해 Google은 펌웨어 코드베이스를 상당히 최소화하고 잠재적인 보안 문제가 있는지 신중하게 감사하려고 합니다.

소프트웨어 보호

THM이 적용하는 엄격한 Vault당 장애 제한 외에도 CKV 서비스는 소프트웨어 기반 비율 제한도 구현합니다. 비율 제한은 계정 도용자가 사용자 계정에 침입하여 복구 시도 실패 한도를 빠르게 소진하는 것을 방지하여 실제 사용자의 복구 키 액세스를 효과적으로 차단하기 위해 설계되었습니다. 화면 잠금 해제 시도가 너무 많이 실패한 후 사용자 기기에 적용되는 시간 지연과 마찬가지로, CKV 서비스는 이후에 실패한 Vault 열기 요청이 있을 때마다 늘어나는 시간 지연을 적용합니다.

또한 엄격한 액세스 제어, 모니터링, 감사를 포함하여 사용자 데이터를 호스팅하는 Cloud 서비스에 대한 표준 보안 조치를 구현합니다.

세부적인 프로토콜 사양

세부 프로토콜 사양은 아직 진행 중이며, 올해 말 Android 오픈소스 프로젝트에 클라이언트 코드를 게시하는 것과 함께 이러한 세부정보를 포함하도록 이 문서를 업데이트할 예정입니다.

Notes