Google Cloud Key Vault 서비스

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

작성자: 샤브시 월피시
버전 날짜: 2018년 3월 6일

참고: 이 문서는 아직 진행 중이며 구현 세부정보는 아직 확정되지 않았습니다. 시스템이 안정화되고 더 많은 문서를 제작할 수 있게 되면 특히 관련 오픈소스 출시와 함께 이 백서를 더 자세한 정보로 업데이트할 예정입니다.

개요

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

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

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

Cloud Key Vault 서비스의 첫 번째 애플리케이션은 클라이언트 측 암호화 Android 백업을 사용 설정하는 것입니다. 이전에는 Android 기기에서 로컬로 암호화된 파일이 사용자의 LSKF로 보호된 키를 사용했지만 클라우드에 저장되고 암호화된 이러한 파일의 백업은 LSKF로 보호되지 않았습니다. Cloud Key Vault는 이제 처음으로 Cloud에 저장된 Android 백업에도 잠금 화면 보호 기능을 제공합니다. 즉, Google 서버는 암호화된 백업의 콘텐츠에 액세스하거나 복원할 수 없습니다. 사용자의 LSKF가 있는 기기만 백업을 복호화할 수 있습니다.

핵심 개념

처음에는 Cloud Key Vault 서비스에 지원되는 유일한 클라이언트 플랫폼이 Android 9 Pie 운영체제였으며 이 백서에서 클라이언트를 언급할 때는 Google Play 서비스와 함께 Android 9 Pie 운영체제를 실행하는 기기를 의미합니다. 서버 측 구현은 추가 Titan 칩²이 설치된 특별히 지정된 Google 서버에서 실행됩니다. Google에서 설계한 Titan 칩은 신뢰할 수 있는 하드웨어 모듈의 하드웨어 구성요소 역할을 하며, 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 보호 복구 키가 포함되어 있습니다. 최종 사용자는 각각 다른 기기 또는 LSKF에 해당하는 여러 Vault를 보유할 수 있습니다. Vault 서버의 THM만 Vault의 콘텐츠를 검사하거나 추출할 수 있습니다.

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

프로토콜 디자인

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

초기화

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

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

Vault Creation

복구 대리인은 동질 집단 공개 키 목록을 가져와 프레임워크의 초기화를 완료한 후 프레임워크에 새 보관소를 만들도록 요청합니다. 사용자가 다음에 LSKF를 입력할 때마다 프레임워크는 새 복구 키를 생성하고 먼저 LSKF 해시에서 파생된 키로 암호화한 다음 초기화 중에 프레임워크에서 선택한 사용자 집단 공개 키로 암호화합니다. 이렇게 암호화된 blob은 Framework에서 복구 상담사에게 다시 전달되는 보관소이며, 복구 상담사는 이를 Google의 CKV 서비스에 업로드합니다.

Vault Opening

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

CKV는 복구 요청 (및 해당 보관소)을 올바른 사용자 집단에 속한 보관소 서버로 라우팅합니다. 그런 다음 보관소 서버의 THM이 복구 요청을 복호화하고, 주장된 LSKF 해시를 사용하여 원래 보관소에서 복구 키를 추출하려고 시도합니다 (내부 암호화 키를 가져오기 위해). 원래 LSKF 해시와 주장된 LSKF 해시가 일치하면 THM은 보관소에서 복구 키를 추출하고 복구 요청에 있던 신고자 키로 다시 암호화합니다. 일치하지 않으면 THM이 실패한 시도 카운터를 범프합니다. 실패 시도 카운터가 한도에 도달하면 THM은 이 보관소에 대한 후속 복구 요청을 처리하지 않습니다.

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

보안 대책

Cloud Key Vault 시스템은 스택의 여러 수준에 보안 보호 기능을 포함하여 '심층 방어'를 제공하는 것을 목표로 합니다. 이러한 보호 기능이 작동하는 방식을 이해할 수 있도록 먼저 클라이언트를 설명하고 스택을 거쳐 Cloud Key Vault 서비스까지 살펴보겠습니다.

클라이언트 보안

특정 OEM 및 기기에 따라 잠금 화면 지식 계수 (LSKF)는 일반적으로 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는 신뢰 루트로 증명된 사용자 집단 공개 키에 대해서만 보관소가 생성되도록 합니다. 신뢰의 루트는 출고 시 OEM에 의해 프레임워크에 굽혀지며 OS 업데이트 없이는 변경할 수 없습니다. 이를 통해 LSKF가 하드웨어 기반 무차별 대입 보호를 적절하게 적용하는 보관소를 만드는 데만 사용되고 있음을 확신할 수 있습니다. Cloud Key Vault 서비스의 THM을 사용하여 LSKF의 무차별 대입 보호를 실행하면 Google Pixel 2 기기에서와 같이 기기에서 동일한 작업을 위해 보안 하드웨어를 사용하는 것과 비슷한 보안을 달성할 수 있습니다.

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

복구 에이전트 보안

복구 도구에서 제공하는 기본 보안 보호는 복구 도구가 현재 기기의 LSKF 또는 복구 키를 볼 수 없도록 프로토콜이 설계되었다는 것입니다. 클라이언트 측에서는 프레임워크만 이러한 항목을 볼 수 있으므로 복구 도구의 잠재적 버그나 보안 취약점을 익스플로잇하기가 훨씬 더 어려워집니다. 복구 도구는 주로 수명 주기 이벤트와 클라우드와 프레임워크 간에 데이터를 주고받는 것을 관리하는 데 사용됩니다. 유일한 예외는 사용자가 Vault Opening 프로토콜 직전에 복구하는 동안 이전 기기의 LSKF를 입력해야 하는 경우입니다. 이전 기기의 소유권 주장이 제기된 LSKF를 수집하는 UI는 Recovery Agent⁴에 구현됩니다. 그러나 프레임워크가 복구 소유권 주장 생성을 인계받는 즉시 복구 상담사 구현은 소유권 주장이 제기된 LSKF를 '잊어버립니다'.

프로토콜의 보안 기능

프로토콜에 대한 전체 분석은 이 문서의 범위를 벗어나지만 프로토콜에 내장된 몇 가지 보호 기능을 강조하고자 합니다. 특히 프로토콜은 전체적으로 LSKF의 해시만 사용합니다. 즉, LSKF의 엔트로피가 높은 경우 (예: 좋은 높은 엔트로피 비밀번호인 경우) Vault를 저장하는 것이 비밀번호 해시를 저장하는 것보다 훨씬 낫습니다. 이 경우 비밀번호 해시는 THM의 보안과는 별개로 보안을 측정할 수 있습니다. 따라서 프로토콜의 일부로 LSKF의 솔트 처리된 '메모리 기반' 해싱을 지원합니다. 또한 Vault를 이를 만든 기기의 식별자에 암호화 방식으로 바인딩하고, 복구 요청이 최신 상태인지 확인하기 위해 Vault 열기 프로토콜 중에 챌린지로 사용되는 nonce에 복구 요청을 바인딩합니다.

복구 키는 각 보관소 생성 시 새로 생성되므로 새롭게 생성된 보관소로 기존 보관소 항목을 덮어써서 키 순환을 구현합니다. 보관소에서 사용하는 실패한 시도 카운터의 주소는 보관소 생성 중에 선택되며, 프레임워크는 LSKF가 변경되었거나 새로운 증명된 사용자 집단 공개 키 목록이 있는 경우가 아니라면 후속 보관소에 사용되는 카운터 주소가 변경되지 않도록 합니다. 따라서 LSKF의 무차별 대입 방지를 손상시키지 않고도 복구 키를 순환할 수 있습니다.

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

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

하드웨어 보호

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

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

소프트웨어 보호

CKV 서비스는 THM에서 적용하는 볼트당 하드 실패 한도 외에도 소프트웨어 기반 비율 제한을 구현합니다. 비율 제한은 계정 도용자가 사용자의 계정에 침입하여 복구 시도 실패 한도에 도달하여 실제 사용자가 복구 키에 액세스할 수 없도록 하는 것을 방지하기 위해 설계되었습니다. 화면 잠금 해제 시도에 실패한 횟수가 너무 많아 사용자 기기에서 적용하는 시간 지연과 마찬가지로 CKV 서비스는 보관함 열기 요청이 실패할 때마다 점점 더 긴 시간 지연을 적용합니다.

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

세부적인 프로토콜 사양

자세한 프로토콜 사양은 아직 진행 중이며, 올해 안으로 Android 오픈소스 프로젝트에 클라이언트 코드가 게시되면 이 문서에 세부정보가 포함되도록 업데이트될 예정입니다.

참고