Google Cloud Key Vault 서비스

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

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

참고: 이 문서는 아직 작업 중이며 구현 세부사항이 아직 완성되지 않았습니다. 시스템이 안정화되고 더 많은 문서를 작성할 수 있게 되면 (특히 관련 오픈소스 릴리스와 함께) 보다 자세한 정보를 포함하여 이 백서를 업데이트할 예정입니다.

개요

일반적으로 데이터 개인 정보 보호를 위해 사용되는 암호화에는 공격자의 관점에서 엔트로피가 높은 보안 비밀을 사용해야 합니다. 암호화 체계는 올바른 보안 비밀을 찾을 때까지 가능성이 있는 모든 보안 비밀의 공간을 탐색하는 무차별 대입 공격을 막아야 하므로 높은 엔트로피가 필요합니다. 오늘날의 컴퓨팅 성능 가용성을 감안할 때 암호화 보안 비밀에 대한 합당한 최소 엔트로피 요구사항은 70~80비트 정도일 수 있습니다. 안타깝게도 인간은 특히 그 정도의 엔트로피가 있는 비밀번호1를 기억하고 안정적으로 기억하는 것을 매우 어렵게 느끼며, 특히 사용 빈도가 낮은 경우에는 엔트로피가 높은 비밀번호를 자주 사용하는 것은 어렵고 지루한 일입니다. 따라서 까다로운 문제가 발생합니다. 사용자가 기억할 가능성이 매우 높은 '지식 인자'가 되도록 하려면 암호화 기술로 비공개 데이터를 어떻게 보호할 수 있을까요? 이 문제는 여러 가지 이유로 해결하기가 매우 어려우므로 Cloud Storage 서비스는 일반적으로 사용자가 자신의 보안 비밀을 기억하도록 하는 대신 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 칩2이 설치된 특별히 지정된 Google 서버에서 실행됩니다. Google에서 설계한 Titan 칩은 신뢰할 수 있는 하드웨어 모듈에서 하드웨어 구성요소 역할을 하며, Google의 프로토콜 및 보안 시행 메커니즘을 구현하는 맞춤 부트로더와 펌웨어를 특별히 프로비저닝합니다 (여기 설명 참고). Google에서는 Google 프로토콜이 Titan 하드웨어에서 실제로 실행되고 있는지 확인하기 위해 하드웨어 증명 기법을 사용합니다.

CKV 서비스는 하드웨어 고장 (예: 번아웃 칩)으로 인해 상당한 양의 사용자 데이터가 손실되거나 데이터 센터 유지보수로 인한 장시간 중단 발생으로 인해 수십억3 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은 프레임워크가 Google의 하드웨어 증명을 확인하는 데 사용할 '신뢰할 수 있는 루트'의 공개 키를 제공합니다. 이 신뢰할 수 있는 루트의 서명 키는 오프라인으로 저장되며 서명하려면 여러 직원이 참여해야 하도록 신중하게 보호됩니다. 이 신뢰할 수 있는 루트의 공개 키는 Android OS에 베이킹되며 OS 업데이트를 통해서만 변경할 수 있습니다.

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

Vault Creation

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

Vault Opening

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

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

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

보안 대책

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 서비스를 지원하기 위해 추가된 새 프레임워크 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를 볼 수 없도록 프로토콜이 설계되었다는 것입니다. 클라이언트 측에서는 프레임워크만 이러한 정보를 볼 수 있어야 하므로 복구 에이전트의 잠재적인 버그나 보안 취약점을 악용하기가 훨씬 더 어려워집니다. 복구 에이전트는 수명 주기 이벤트와 클라우드와 프레임워크 간의 데이터 전달을 관리하는 데 주로 사용됩니다. 유일한 예외는 사용자가 이전 기기의 LSKF를 입력해야 하는 경우 Vault Opening 프로토콜 직전의 복구 중에 발생합니다. 이때 이전 기기의 소유권 주장이 제기된 LSKF를 수집하는 UI가 복구 에이전트4에 구현됩니다. 하지만 복구 에이전트 구현은 프레임워크가 복구 클레임 생성을 인계받는 즉시 소유권이 주장된 LSKF를 '삭제'합니다.

프로토콜의 보안 기능

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

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

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

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

하드웨어 보호

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

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

소프트웨어 보호

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

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

세부적인 프로토콜 사양

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

Notes

  1. "인간의 메모리에 있는 56비트 보안 비밀의 안정적인 저장소를 향하여 | USENIX." 2014년 8월 1일, https://www.usenix.org/node/184458
  2. "Google Cloud Platform 블로그: Titan 심층 분석: 일반 텍스트를 이용한 보안" 2017년 8월 24일, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html
  3. 'Google은 Android에서 월간 활성 기기 20억 대 이상을 발표합니다', 2017년 5월 17일, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users.
  4. 이를 통해 다른 기기의 LSKF를 입력하기 위한 유연한 UI를 제공할 수 있습니다. 현재 기기의 프레임워크에는 이전 기기의 LSKF를 입력하기 위한 적절한 UI가 없을 수 있습니다.