Google Cloud Key Vault Service

암호화 키에 대한 액세스가 낮은 엔트로피의 지식 인증 정보(예: 잠금 화면 PIN)로 보호되도록 보안 하드웨어를 사용하여 암호화 키를 저장하는 클라우드 서비스에 대해 설명합니다. 보안 하드웨어는 올바른 지식 인증 정보의 입력 시도에 일정한 횟수 이상 실패하면 저장된 암호화 키를 영구적으로 불러오지 못하게 함으로써 무차별 암호 대입 공격을 방지합니다.

작성자: Shabsi Walfish
버전 날짜: 2018-03-06

참고: 아직 이 문서를 작성하는 중이며 구현 세부 사항을 최종 마무리하는 단계를 진행 중입니다. 시스템이 안정화되고 더 많은 문서를 만들 수 있게 되면 (특히 관련 오픈소스 릴리스와 함께) 더 자세한 정보를 덧붙여 이 백서를 업데이트하겠습니다.

개요

일반적으로 (개인정보 보호를 목적으로 사용되는) 암호화에서는 공격자의 관점에서 엔트로피가 높은 암호를 사용해야 합니다. 암호화 방식은 올바른 암호를 찾을 때까지 가능한 모든 암호 공간을 탐색하는 무차별 암호 대입 공격을 막아내야 하므로 높은 엔트로피가 필요합니다. 오늘날 사용 가능한 전산 처리 능력을 감안할 때, 암호화 기술에 따라 암호가 제 기능을 발휘하는 합리적 수준의 최소 엔트로피 요구사항은 대략 70~80비트 정도라 할 수 있습니다. 하지만 사람의 통상적인 기억력으로는 그 정도 양의 엔트로피를 지닌 비밀번호나 다른 암호를 잘 기억해 두었다가 확실히 다시 떠올리기란 지난한 일이고¹, 특히 거의 사용되지 않는 암호라면 더욱 그러합니다. 설령 기억력이 탁월해 이처럼 높은 엔트로피의 암호를 정확히 외우고 있더라도 자주 사용해야 한다면 무척이나 귀찮은 일이 될 것입니다. 따라서 까다로운 문제가 주어집니다. 사용자 자신은 잘 기억할 수 있지만 다른 사람으로선 도저히 쉽게 알 수 없는 "지식 인증 정보"가 될 만한 암호를 사용할 수 있도록 하려면 어떻게 암호화 기술로 개인 데이터를 보호할 수 있을까요? 이 문제는 다양한 이유로 해결하기가 너무 어려워 클라우드 저장소 서비스에서는 일반적으로 사용자가 자신의 암호를 기억하는 방식에 의존하지 않고 클라우드 서비스 공급자가 스스로 관리하는 암호로 데이터를 암호화할 뿐입니다.

암호화 기술에 따른 암호와 인간이 기억할 수 있는 암호에 대한 요구사항 사이의 격차를 해소하는 한 가지 접근 방식은 CKV(Cloud Key Vault) 서비스를 사용하여 높은 엔트로피의 '복구 키'를 저장하고 이를 인간이 기억할 수 있는 낮은 엔트로피의 암호로 보호하는 것입니다. CKV 서비스는 인간이 기억할 수 있는 암호를 정확히 알고 있음을 증명하는 자에게만 복구 키를 공개합니다. CKV 서비스는 인간이 기억할 수 있는 암호를 알고 있음을 증명하기 위한 암호 입력 시도 횟수에 절대적인 제한을 두어 무차별 암호 대입 공격을 저지할 수 있습니다. 복구 키 자체는 어디에든 안전하게 저장할 수 있는 대량의 데이터(예: 디스크 백업)를 손쉽게 암호화할 수 있는 (인증된) 암호화 방식에 사용하기에 적합한 표준 암호화 대칭 키입니다. 이처럼 암호화된 데이터는 복구 키를 얻을 수 없는 사람에게는 무용지물일 뿐입니다.

이 백서에서는 THM(Trusted Hardware Module)을 이용한 Cloud Key Vault 서비스 생성에 대한 접근 방식을 설명합니다. Google CKV 서비스의 첫 구현은 사용자의 LSKF(Lock Screen Knowledge Factor), 즉 스마트폰 잠금 해제에 사용되는 비밀 PIN, 비밀번호 또는 스와이프 패턴으로 복구 키를 보호하도록 되어 있습니다. 인간은 자신이 설정한 LSKF를 확실히 기억할 수 있습니다. 그와 동시에, 이러한 LSKF 암호는 대개 공격을 시도해 볼 수 있는 횟수가 극히 제한적인 공격자를 막기에 딱 충분할 정도의 엔트로피를 가지고 있으므로 CKV 서비스에 적합합니다.

Cloud Key Vault 서비스는 클라이언트측 암호화 Android 백업을 활성화하는 데 처음으로 적용될 것입니다. 이전에는 Android 기기에 로컬로 암호화된 파일은 사용자의 LSKF로 보호되는 키를 사용했지만, 클라우드에 저장되고 암호화된 파일의 백업은 잠금 화면으로 보호되지 않았습니다. Cloud Key Vault는 최초로 클라우드에 저장된 Android 백업을 위해서도 잠금 화면 보호 기능을 사용합니다. 이는 곧 Google의 서버는 암호화된 백업의 내용에 액세스하거나 이를 복원할 수 없고, 사용자의 LSKF가 있는 기기만이 백업을 암호화를 해제할 수 있다는 의미입니다.

핵심 개념

처음에는 Cloud Key Vault 서비스를 위해 유일하게 지원되는 클라이언트 플랫폼은 곧 나올 Android P 운영체제가 될 것이므로, 이 백서에서 언급하는 클라이언트는 곧 Google Mobile Service로 Android P 운영체제를 실행하는 기기를 지칭합니다. 서버 측 구현은 여분의 Titan 칩² 이 설치되어 있고 특별히 지정된 Google 서버에서 작동합니다. Google에서 디자인한 Titan 칩은 THM에서 하드웨어 구성 요소 역할을 하는데, Google은 이 글에서 설명하는 Google의 프로토콜과 보안 적용 메커니즘을 구현하는 사용자설정 부트로더 및 펌웨어와 함께 특별히 이 칩을 준비해 제공합니다. Google에서는 프로토콜이 Titan 하드웨어에서 실제로 작동할지 확신을 얻기 위해 하드웨어 증명 기법을 사용합니다.

CKV 서비스는 하드웨어 고장(예: 칩 소손)으로 인해 상당량의 사용자 데이터를 잃거나 데이터 센터 유지 관리 작업으로 인해 장시간 서비스가 중단되는 일 없이 수십억 개의³ Android 기기에서 발생하는 트래픽을 처리하도록 확장해야 합니다. 이 때문에, Titan 칩이 설치되어 있는 서버는 코호트로 구성되며, 각각의 코호트는 제각기 동일한 키 자료의 복사본이 들어 있는 여러 개의 독립된 THM으로 구성됩니다. 주어진 코호트는 각기 다른 유지 관리 지역에서 물리적으로 떨어진 여러 데이터 센터에 분산되는데, 이는 시스템이 가용성 및 신뢰성 목표를 충족할 수 있도록 하기 위함입니다. 확장성을 위해 클라이언트는 서로 다른 여러 코호트로 분할될 것이므로, 단지 서버를 더 추가하는 방법으로 서비스 용량을 조정하여 사용 가능한 코호트의 수를 늘릴 수 있습니다.

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

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

LSKF(Lock Screen Knowledge Factor): 짧은 PIN, 3 x 3 도트 그리드 상의 스와이프 패턴 또는 비밀번호처럼 인간이 기억할 수 있는 암호입니다. 이 암호는 기기를 로컬에서 잠금 해제하는 기능을 보호하는 데 사용되며, 사용자의 로컬 기기 화면 잠금에 대한 기본(또는 '강력한') 인증 요소로 간주됩니다.

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

Android Framework: Android 운영체제의 다음 릴리스(Oreo 릴리스를 잇는 릴리스로, 이 글을 쓰는 시점 현재에는 아직 이름이 정해지지 않음) 또는 그 이후 릴리스에 사용되는 API를 지칭하려고 이 일반적인 용어를 사용하며, 이전 릴리스를 가리키지는 않습니다.

Google 모바일 서비스: 최종 사용자 기기에서 실행되는 서비스와 앱의 모음으로, 이 서비스를 사용하여 Google의 계정 시스템과 사용자설정 서버 API로 작업할 수 있습니다.

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

복구 클레임: 사용자가 복구 키를 검색하고 싶을 때는 사용자가 알려고 청구하는 LSKF의 암호화된 복사본을 가진 복구 클레임을 만들어야 합니다. 일반적으로, 사용자는 이전 기기의 복구 키에 대한 액세스를 시도 중인 새 기기에 이전 기기의 LSKF를 입력하라는 요구를 받게 됩니다.

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

CKV(Cloud Key Vault) 서비스: 클라이언트 기기가 인간이 기억할 수 있는 LSKF로 보호되는 암호화 키를 저장할 수 있도록 지원하는 인터넷 서비스입니다.

코호트: 서로의 중복 복제본으로 사용할 수 있는 Vault Server/THM의 모음입니다.

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

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

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

Vault Server: THM(Trusted Hardware Module)을 추가하기 위해 특별히 도입한, Google 데이터 센터 내에서 작동하는 범용 컴퓨터입니다.

프로토콜 디자인

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

초기화

Google은 시스템 초기화를 위해 Android Framework가 Google의 하드웨어 증명을 확인하기 위해 사용할 '신뢰할 수 있는 루트'를 위한 공개 키를 제공합니다. 이 신뢰할 수 있는 루트를 위한 서명 키는 오프라인에 저장되고 이 키로 서명하려면 복수의 직원이 참여해야 하는 방식으로 신중한 보안 조치가 취해집니다. 이 신뢰할 수 있는 루트를 위한 공개 키는 Android OS로 구워지고 OS 업데이트를 통해 변경될 수 있을 뿐입니다.

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

Vault Creation

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

Vault Opening

새 기기의 복구 에이전트가 특정 Vault에 저장되어 있는 복구 키에 대한 액세스 권한을 얻을 필요가 있을 때, 사용자에게 해당 Vault를 생성했던 원래 기기의 LSKF를 입력하라는 프롬프트를 표시합니다. 그런 다음, 복구 에이전트는 Framework에 사용자가 입력한 LSKF를 사용하여 복구 클레임을 생성할 것을 요청합니다. Framework는 청구자 키를 새로 생성하고, Vault를 처음 암호화할 때 사용한 것과 똑같은 코호트 공개 키를 사용하여 청구자 키뿐 아니라 청구된 LSKF의 해시도 암호화합니다. 그 결과로 암호화되는 블롭을 복구 클레임이라고 하고, Framework는 복구 클레임을 복구 에이전트에게 전달하고 복구 에이전트는 CKV 서비스에 이 클레임을 제시합니다.

CKV는 복구 클레임과 그에 해당하는 Vault를 올바른 코호트에 속한 Vault Server로 라우팅합니다. 그러면 Vault Server의 THM이 복구 클레임을 암호화 해제하고 (내부 암호화 키를 파생하기 위해) 청구된 LSKF 해시를 사용하여 원래 Vault에서 복구 키 추출을 시도합니다. 원래 LSKF 해시와 청구된 LSKF 해시가 일치하면 THM이 Vault에서 복구 키를 추출하고 복구 클레임에 있었던 청구자 키로 복구 키를 다시 암호화합니다. 일치하지 않으면 THM이 실패한 시도 카운터를 범프합니다. 실패한 시도 카운터가 한계에 도달하면 THM이 이 Vault에 대한 이후의 복구 클레임 처리를 거절합니다.

마지막으로, 모든 것이 잘 진행된 경우 다시 암호화된 복구 키(지금 청구자 키 아래에서 암호화된 키)는 Vault Server에서 Framework로 완전히 되돌려 보내집니다. Framework는 청구자 키의 복사본을 사용하여 복구 키를 암호화 해제하며, 이제 프로토콜이 완전한 상태입니다.

보안 대책

Cloud Key Vault 시스템은 여러 수준의 스택에서 보안 보호를 포함함으로써 '심층 방어' 효과를 제공하는 것을 목표로 삼습니다. 이러한 보호가 어떤 효과기 있는지 체감할 수 있도록 하기 위해, Google은 클라이언트에 대해 설명하는 일부터 시작해서 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로 표시되고 이러한 API를 Google Play Service와 같은 OEM 승인 시스템 앱에만 사용할 수 있도록 보장하는 특별한 권한이 필요합니다. 대체로 이를 통해 사용자가 기기에 설치하는 앱에 노출될 수 있는 직접 공격 표면을 모두 제거할 수 있습니다.

Framework API는 또한 Vault가 신뢰할 수 있는 루트에 의해 증명된 코호트 공개 키용으로만 생성되도록 보장합니다. 신뢰할 수 있는 루트는 OEM이 미리 Framework에 구운 상태로 제공되므로 OS를 업데이트하지 않으면 변경할 수 없습니다. 따라서 LSKF가 하드웨어 기반 무차별 암호 대입 공격으로부터 적절히 보호해 줄 Vault를 만드는 데만 사용된다고 확신할 수 있습니다. LSKF에 대한 무차별 암호 대입 공격 보호를 위해 Cloud Key Vault 서비스의 THM을 사용하면 (Google Pixel 2 기기와 마찬가지로) 같은 효과를 위해 기기에 보안 하드웨어를 사용하는 것에 필적하는 수준의 보안을 실현할 수 있습니다.

LSKF가 보안 하드웨어 외부의 기기에 저장될 것이라 생각하지는 않으므로, 새 Vault는 기기 잠금 해제 직후에만 생성할 수 있습니다. 사용자가 기기 잠금 해제를 위해 LSKF를 입력할 때 LSKF는 RAM에서 잠깐 Framework가 사용할 수 있는 상태가 됩니다. 바로 그 순간에 Vault를 생성하는 새 API가 LSKF를 사용합니다. 기기가 잠겨진 동안에는 LSKF를 사용할 수 없으므로 새 LSKF로 보호되는 Vault를 만들 수 없습니다.

복구 에이전트 보안

Google이 복구 에이전트에서 제공하는 기본 보안 보호 대책으로, 복구 에이전트가 현재 기기의 LSKF나 어떤 복구 키도 전혀 볼 수 없도록 프로토콜을 설계했습니다. 클라이언트측에서는 오직 Framework만이 이런 정보를 볼 수 있도록 하여 복구 에이전트에 있을 수 있는 버그나 보안 취약점을 악용하기 훨씬 더 어렵게 만들었습니다. 복구 에이전트는 수명 주기 이벤트를 관리하고 Cloud와 Framework 간의 데이터 전달을 관리하는 데 주로 사용됩니다. 이에 대한 유일한 예외는 사용자가 이전 기기의 LSKF를 입력해야 하는 시점인 Vault Opening 프로토콜 직전에 복구하는 동안에 발생합니다. 이때 이전 기기에 대해 청구된 LSKF를 수집하는 UI가 복구 에이전트에 구현됩니다⁴. 하지만 복구 에이전트 구현은 Framework가 복구 클레임 생성을 인수하자마자 청구된 LSKF를 '잊습니다'.

프로토콜의 보안 기능

프로토콜의 완전한 분석은 이 문서의 범위를 벗어나지만, 프로토콜에 내장된 보호 기능 몇 가지만 강조하고자 합니다. 특히, 이 프로토콜은 끝까지 LSKF의 해시만 사용합니다. 즉, LSKF의 엔트로피가 높은 경우(예: 훌륭한 하이 엔트로피 비밀번호인 경우) Vault를 저장하는 것은 엄밀히 말해 비밀번호 해시를 저장하는 것보다 낫고, 이 경우 비밀번호 해시는 THM의 보안과는 상관없는 보안 대책을 제공할 수 있습니다. 이런 이유로, Google은 프로토콜의 일부로서 LSKF의 '메모리 하드' 해싱을 지원합니다. 또한, Vault를 만든 기기에 대한 식별자에 Vault를 암호화 방식으로 바인드하고 Vault Opening 프로토콜 중에 인증 질문으로 사용되는 난스에 복구 클레임을 바인드하여 복구 클레임이 새것임을 보장합니다.

복구 키는 Vault를 생성할 때마다 새로 생성되므로, 기존 Vault 항목을 새로 생성된 Vault로 덮어쓰는 방법으로 키 순환을 구현합니다. Vault가 사용하는 실패한 시도 카운터의 주소는 Vault 생성 중에 선택되고, Android Framework는 LSKF가 변경되었거나 코호트 공개 키의 새로 증명된 목록이 있는 경우가 아니라면 임의의 후속 Vault용으로 사용되는 카운터 주소가 바뀌지 않도록 보장합니다. 따라서 LSKF에 대한 무차별 암호 대입 공격 보호 기능에 해를 끼치지 않고 복구 키 순환을 완료할 수 있습니다.

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

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

하드웨어 보호

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

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

소프트웨어 보호

THM이 적용하는 엄격한 Vault당 실패 제한 외에, CKV 서비스는 소프트웨어 기반 속도 제한도 구현합니다. 속도 제한은 하이재커가 사용자의 계정으로 침투하여 복구 시도 실패 횟수 제한을 빠르게 소진하지 못하게 함으로써, 사실상 실제 사용자가 복구 키에 액세스하지 못하게 하도록 설계되었습니다. 화면 잠금 해제 시도에 너무 많이 실패한 후에 다시 시도하려면 사용자 기기에서 일정한 시간 지연을 적용하는 것과 유사하게, CKV 서비스는 후속적으로 실패하는 Vault Opening 요청이 있을 때마다 늘어나는 시간 지연을 강제로 적용합니다.

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

세부적인 프로토콜 사양

세부적인 프로토콜 사양은 아직 작업을 진행 중이며, 올해 말에 Android Open Source Project에 클라이언트 코드를 게시하는 것과 때를 맞추어 상세 사양을 포함하도록 본 문서를 업데이트하겠습니다.

참고