애플리케이션 레이어 전송 보안

작성자: 시저 갈리, 애덤 스터블필드, 에드 냅, 지앙타오 리, 베네딕트 슈미트, 줄리앙 뵈프

여기에 포함된 콘텐츠는 2017년 12월 기준으로 작성되었으며, 이 백서는 작성된 당시의 상황을 나타냅니다. Google이 지속적으로 고객 보호를 개선함에 따라 Google Cloud의 보안 정책 및 시스템은 향후 변경될 수 있습니다.

PDF 버전 다운로드

CIO 수준 요약

Google의 애플리케이션 레이어 전송 보안(ALTS)은 Google이 개발한 상호 인증 및 전송 암호화 시스템으로, 일반적으로 Google 인프라 내에서 리모트 프로시져 콜(RPC) 통신의 보안을 유지하는 데 사용됩니다. ALTS는 상호 인증 TLS와 개념적으로 비슷하지만, Google 데이터 센터 환경의 요구 사항을 충족하도록 설계 및 최적화되었습니다.
ALTS 신뢰 모델은 클라우드처럼 컨테이너화된 애플리케이션에 맞춤 설계되었습니다. ID는 특정 서버 이름 또는 호스트가 아니라 개체에 바인딩됩니다. 이 신뢰 모델은 원활한 마이크로 서비스 복제, 부하 분산, 여러 호스트에 걸친 일정 조정을 촉진합니다.
ALTS는 Handshake 프로토콜(세션 재개 포함)과 Record 프로토콜이라는 두 가지 프로토콜에 의존합니다. 이러한 프로토콜은 세션의 설정, 인증, 암호화 및 재개 방식을 지배합니다.
ALTS는 Google에서 사용하는 커스텀 전송 계층 보안 솔루션입니다. Google의 프로덕션 환경에 적합하게 ALTS를 맞춤설정했으므로, ALTS와 업계 표준인 TLS 사이에 절충사항이 있습니다. 자세한 사항은 절충사항 섹션에서 확인할 수 있습니다.

소개

Google의 프로덕션 시스템은 전체적으로 리모트 프로시져 콜(RPC)을 초당 O(10¹⁰)회 실행하는 마이크로서비스¹의 무리로 구성됩니다. Google 엔지니어가 프로덕션 워크로드²를 예약하면 해당 워크로드에 의해 실행되거나 수신된 모든 RPC는 기본적으로 ALTS로 보호됩니다. Google의 애플리케이션 레이어 전송 보안(ALTS)이 이러한 별도의 구성이 필요 없는 자동 보호 기능을 제공합니다. RPC를 통해 제공되는 자동 보호 기능 외에, ALTS는 손쉬운 서비스 복제, 부하 분산, 여러 프로덕션 머신에서 일정 조정의 편리성도 제공합니다. 이 백서에서는 ALTS에 대해 설명하고 Google의 프로덕션 인프라에 ALTS를 배포하는 방법을 살펴봅니다.

대상: 이 문서는 Google에서 규모에 맞게 인증 및 전송 보안을 수행하는 방법에 대해 관심 있는 인프라 보안 전문가를 대상으로 합니다.

기본 요건: 이 소개 외에도 Google의 클러스터 관리에 대한 기본적인 지식이 있다고 가정합니다.

애플리케이션 레벨 보안 및 ALTS

웹브라우저에서 VPN까지 수많은 애플리케이션이 전송 중 데이터를 보호하기 위해 TLS(전송 계층 보안) 및 IPSec과 같은 보안 통신 프로토콜을 사용합니다³. Google에서는 RPC 통신을 보호하기 위해 애플리케이션 수준에서 작동하는 상호 인증 및 전송 암호화 시스템인 ALTS를 사용합니다. 애플리케이션 수준 보안을 사용하면 애플리케이션이 인증된 원격 피어 ID를 갖도록 할 수 있고, 이 ID를 사용하여 세분화된 승인 정책을 구현할 수 있습니다.

TLS를 사용하지 않는 이유

대다수의 인터넷 트래픽이 TLS를 사용하여 암호화되는 오늘날, Google이 ALTS와 같은 커스텀 보안 솔루션을 사용하는 것이 이상하게 보일 수 있습니다. Google에서는 2007년에 ALTS 개발을 시작했습니다. 그 당시에는 TLS가 Google의 최소 보안 기준을 충족하지 못하는 수많은 기존 프로토콜을 위한 지원 기능과 함께 번들로 묶여 제공되었습니다. Google에서 필요한 TLS 구성요소를 채택하고 원하는 TLS 구성요소를 구현함으로써 보안 솔루션을 설계할 수도 있었겠지만, 처음부터 Google에 더욱 적합한 시스템을 빌드함으로써 얻는 이점이 기존 시스템을 패치하는 이점보다 컸습니다. 뿐만 아니라 ALTS는 Google의 니즈에 더 알맞고 지난 기록을 살펴보더라도 기존의 TLS보다 더 안전합니다. 아래에 TLS와 ALTS의 주요 차이점을 정리해 두었습니다.

HTTPS 시맨틱스를 사용하는 TLS와 ALTS의 신뢰 모델⁴에는 상당한 차이점이 있습니다. 전자의 경우 서버 ID가 특정 이름과 그에 상응하는 명명 체계에 구속됩니다. 하지만 ALTS에서는 같은 ID를 여러 명명 체계에서 사용할 수 있습니다. 이 정도의 간접성 수준은 더 많은 유연성을 제공하고 마이크로서비스 복제, 부하 분산, 호스트 간의 일정 조정 프로세스를 대폭 간소화해 줍니다.
TLS에 비해 ALTS는 더 간단하게 설계하고 구현할 수 있습니다. 결과적으로, 소스 코드 또는 광범위한 퍼징에 대한 수동 검사를 이용해 버그 및 보안 취약점을 더 쉽게 모니터링할 수 있습니다.
ALTS는 프로토콜 버퍼를 사용하여 인증서와 프로토콜 메시지를 직렬화하는 반면, TLS는 ASN.1로 인코딩된 X.509 인증서를 사용합니다. Google의 프로덕션 서비스는 통신에 대부분 프로토콜 버퍼, 때로는 스토리지를 사용하므로 ALTS가 Google의 환경에 더욱 적합합니다.

ALTS 설계

ALTS는 최소한의 사용자 관여로 서비스 간 인증과 보안을 허용하는 고도로 안정적이고 신뢰할 수 있는 시스템으로서 설계되었습니다. 이를 실현하기 위해 아래에 나열된 속성이 ALTS의 설계에 포함됩니다.

투명성: ALTS 구성은 애플리케이션 레이어에 투명합니다. 기본적으로 서비스 RPC는 ALTS를 사용하여 보호됩니다. 따라서 애플리케이션 개발자는 사용자 인증 정보 관리나 보안 구성에 대해 걱정할 필요 없이 서비스의 함수 논리에 집중할 수 있습니다. 서비스 간 연결 설정 중, ALTS는 세분화된 승인 검사와 감사에 사용할 수 있는, 인증된 원격 피어 ID를 애플리케이션에 제공합니다.
최첨단 암호화: ALTS가 사용하는 모든 암호화 기본 형식과 프로토콜은 현재 알려진 공격에 대해 최신 상태입니다. ALTS는 Google이 제어하는 머신에서 작동합니다. 즉, 지원되는 모든 암호화 프로토콜을 쉽게 업그레이드하고 빠르게 배포할 수 있다는 뜻입니다.
ID 모델: ALTS는 호스트 이름이 아니라 ID를 기준으로 주로 인증을 수행합니다. Google에서는 모든 네트워크 개체(예: 회사 사용자, 물리적 머신 또는 프로덕션 서비스나 워크로드)에 연결된 ID가 있습니다. 서비스 간의 모든 통신은 상호 인증됩니다.
키 배포: ALTS는 사용자 인증 정보 집합으로 표현되는 ID를 가진 각 워크로드에 의존합니다. 이러한 사용자 인증 정보는 사용자 관여 없이 초기화 중에 각 워크로드에 배포됩니다. 동시에, 머신과 워크로드에 이러한 사용자 인증 정보에 대한 신뢰할 수 있는 루트와 신뢰 체인이 설정됩니다. 이 시스템은 애플리케이션 개발자의 관여 없이 자동 인증서 순환 및 취소를 허용합니다.
확장성: ALTS는 대규모 Google 인프라를 지원하기 위해 매우 용이하게 확장 가능하도록 설계되었습니다. 이 요구 사항이 효율적인 세션 재개 개발의 원동력이었습니다.
수명이 긴 연결: 인증된 키 교환 암호화 작업은 상당량의 컴퓨팅 리소스가 필요합니다. Google의 인프라 규모를 수용하기 위해, 최초 ALTS 핸드셰이크 후 전체 시스템 성능을 개선하기 위해 더 오랫동안 연결을 유지할 수 있습니다.
단순성: TLS는 기본적으로 기존 프로토콜 버전과 이전 버전과의 호환성을 위한 지원 기능과 함께 제공됩니다. 기본적으로 ALTS를 지원하도록 설계된 클라이언트와 서버를 모두 Google이 제어하기 때문에 ALTS가 훨씬 더 단순합니다.

ALTS 신뢰 모델

ALTS는 호스트가 아니라 주로 ID를 기준으로 인증을 수행합니다. Google에서는 모든 네트워크 개체(예: 회사 사용자, 물리적 머신 또는 프로덕션 서비스)에 연관된 ID가 있습니다. 이러한 ID는 ALTS 인증서에 삽입되고 보안 연결 설정 중에 피어 인증에 사용됩니다. Google이 추구하는 모델은 프로덕션 서비스가 사이트 안정성 엔지니어(SRE)가 관리할 수 있는 프로덕션 개체로 실행되는 모델입니다⁵. 이러한 프로덕션 서비스의 개발 버전은 SRE와 개발자가 모두 관리할 수 있는 테스트 개체로 실행됩니다.

예를 들어 서비스 프론트엔드와 서비스 백엔드라는 두 가지 서비스를 가진 제품이 있다고 가정해 봅시다. SRE는 이러한 서비스의 프로덕션 버전인 service-frontend-prod와 service-backend-prod를 실행할 수 있습니다. 개발자는 테스트 목적으로 이러한 서비스의 개발 버전인 service-frontend-dev와 service-backend-dev를 빌드하고 실행할 수 있습니다. 프로덕션 서비스의 승인 구성은 서비스의 개발 버전은 신뢰하지 않도록 구성됩니다.

ALTS 사용자 인증 정보

ALTS 사용자 인증 정보에는 세 가지 유형이 있는데, 모두 프로토콜 버퍼 메시지 형식으로 표현됩니다.

마스터 인증서: 원격 Signing Service에 의해 서명되고 핸드셰이크 인증서를 확인하기 위해 사용됩니다. 마스터 인증서는 마스터 비공개 키와 연결된 공개 키를 포함합니다(예: RSA 키 쌍). 이 비공개 키는 핸드셰이크 인증서 서명에 사용됩니다. 아래에서 설명하는 ALTS 정책과 함께 실행 시, 이러한 인증서는 본질적으로 제약 조건이 있는 중간 CA(인증 기관) 인증서입니다. 마스터 인증서는 일반적으로 Borgmaster⁶와 같이 컨테이너화된 워크로드의 스케줄러와 프로덕션 머신용으로 발급됩니다.
Handshake 인증서: 마스터 비공개 키가 로컬에서 생성하고 서명하는 인증서입니다. 이 인증서는 ALTS 핸드셰이크(보안 연결 설정) 중에 사용되는 매개변수(예: 정적 디피-헬만(DH) 매개변수 및 핸드셰이크 암호)를 포함합니다. 또한 핸드셰이크 인증서는 파생 출처인 마스터 인증서, 즉 핸드셰이크 인증서에 서명하는 마스터 비공개 키와 연결된 인증서를 포함합니다.
재개 키: 재개 티켓 암호화에 사용되는 암호. 이 키는 같은 ID를 사용하여 같은 데이터 센터 셀에서 실행 중인 모든 프로덕션 워크로드에 대해 고유하고 이러한 워크로드 사이에서 공유되는 재개 식별자 ID_R에 의해 식별됩니다. ALTS에서 세션 재개에 관한 자세한 내용은 세션 재개를 참조하세요.

그림 1은 Signing Service 확인 키, 마스터 인증서 및 핸드셰이크 인증서로 구성된 ALTS 인증서 체인을 보여줍니다. Signing Service 확인 키는 ALTS의 신뢰할 수 있는 루트이고 프로덕션 및 회사 네트워크의 모든 Google 머신에 설치됩니다.

그림 1: ALTS 인증서 체인

ALTS에서는 Signing Service가 차례로 핸드셰이크 인증서를 인증하는 마스터 인증서를 인증합니다. Handshake 인증서가 마스터 인증서보다 자주 생성되므로, 이 아키텍처는 Signing Service에 대한 부하를 줄여줍니다. 인증서 순환은 특히 핸드셰이크 인증서에 대해 Google에서 자주 발생합니다⁷. 이처럼 잦은 순환은 핸드셰이크 인증서를 통해 전달되는 정적 키 교환 쌍을 보완합니다⁸.

인증서 발급

ALTS 보안 핸드셰이크에 참가하려면 네트워크의 개체를 핸드셰이크 인증서로 프로비저닝해야 합니다. 먼저 발급자는 Signing Service에 의해 서명된 마스터 인증서를 얻고 이를 선택적으로 개체로 전달합니다. 그런 다음, 연결된 마스터 비공개 키에 의해 핸드셰이크 인증서가 생성되고 서명됩니다.

일반적으로 머신과 사람에게 인증서를 발급할 때는 Google 내부 인증 기관(CA)이 발급자이고, 워크로드에 인증서를 발급할 때는 Borgmaster가 발급자입니다. 하지만 다른 어떤 개체(예: 테스트 데이터 센터 셀의 제한된 Borgmaster)라도 발급자일 수 있습니다.

그림 2는 Signing Service가 마스터 인증서 생성에 사용되는 방식을 보여줍니다. 이 프로세스는 다음과 같은 단계로 구성됩니다.

그림 2: 인증서 발급

Certificate Issuer가 Signing Service에 Certificate Signing Request(CSR)를 보냅니다. 이 요청은 Signing Service에 ID A를 위한 인증서를 생성할 것을 요구합니다. 예를 들어 이 ID는 회사 사용자 또는 Google 프로덕션 서비스의 ID일 수 있습니다.
Signing Service는 (CSR에 포함된) 인증서의 발급자를 요청자(이 경우에는 Certificate Issuer)로 설정하고 서명합니다. 해당 Signing Service 공개(확인) 키는 모든 Google 머신에 설치된다는 점을 떠올려 보세요.
Signing Service는 서명된 인증서를 되돌려 보냅니다.
ID A를 위한 핸드셰이크 인증서가 생성되고 마스터 인증서에 연결된 비공개 키에 의해 서명됩니다.

위 프로세스에 표시된 것처럼, ALTS를 사용할 때 인증서의 발급자와 서명자는 두 개의 서로 다른 논리적 개체입니다. 이 경우, 발급자는 Certificate Issuer 개체이고 서명자는 Signing Service입니다.

ALTS에는 Human, Machine, Workload라는 일반적인 인증서 카테고리 세 가지가 있습니다. 다음 섹션에서는 이러한 각각의 인증서가 ALTS에서 어떻게 생성되고 사용되는지 개괄적으로 살펴봅니다.

Human 인증서

Google에서는 인간 사용자가 프로덕션 서비스에 발급한 RPC를 보호하기 위해 ALTS를 사용합니다. RPC를 발급하려는 사용자는 유효한 핸드셰이크 인증서를 제공해야 합니다. 예를 들어 앨리스가 ALTS로 보호되는 RPC를 발급하는 애플리케이션을 사용하고 싶은 경우 내부 CA에 대해 인증할 수 있습니다. 앨리스는 자신의 사용자 이름, 비밀번호, 2단계 인증을 사용하여 CA에 대해 인증합니다. 이 작업을 수행하면 앨리스는 20시간 동안 유효한 핸드셰이크 인증서를 받게 됩니다.

Machine 인증서

Google의 데이터 센터에 있는 모든 프로덕션 시스템에는 시스템 마스터 인증서가 있습니다. 이 인증서는 해당 머신에 있는 핵심 애플리케이션(예: 머신 관리 데몬)을 위한 핸드셰이크 인증서를 생성하는 데 사용됩니다. 머신 인증서에 임베딩되는 기본 ID는 해당 머신의 일반적인 목적을 가리킵니다. 예를 들어 서로 다른 종류의 프로덕션 및 개발 워크로드를 실행하는 데 사용되는 머신의 ID는 서로 다를 수 있습니다. 마스터 인증서는 확인된 소프트웨어 스택을 실행하는 머신에서만 사용될 수 있고, 어떤 경우에는 이 신뢰가 커스텀 보안 하드웨어에 기반합니다⁹. 모든 프로덕션 머신 마스터 인증서는 CA에 의해 발급되고 몇 개월마다 순환됩니다. 또한 모든 핸드셰이크 인증서는 몇 시간마다 순환됩니다.

Workload 인증서

ALTS의 주요 이점은 여러 컴퓨터에서 손쉬운 서비스 복제, 부하 분산, 일정 조정을 촉진하는 작업 부하 ID라는 개념을 기반으로 작동한다는 점입니다. Google은 프로덕션 네트워크에서 규모에 맞는 클러스터 관리와 머신 리소스 할당을 위해 Borg¹⁰라는 시스템을 사용합니다. Borg는 ALTS 머신 독립적 워크로드 아이덴티티 구현의 일부로 인증서를 발급합니다.

Google 프로덕션 네트워크의 각 워크로드는 Borg 셀에서 실행됩니다. 각 셀에는 Borgmaster라는 논리적인 중앙 집중식 컨트롤러와 해당 셀에 있는 각 머신에서 실행되는 Borglet이라는 여러 개의 에이전트 프로세스가 있습니다. 워크로드는 Borgmaster가 발급한 연결된 Workload Handshake Certificate로 초기화됩니다. 그림 3은 Borg를 사용하는 ALTS의 워크로드 인증 프로세스를 보여줍니다.

그림 3: Google 프로덕션 네트워크에서 Handshake 인증서 생성

이제 Borgmaster가 ALTS를 사용해야 하는 워크로드를 예약할 준비가 되었습니다. 클라이언트가 Borg에서 주어진 ID로 실행할 워크로드를 예약할 때 아래 절차가 진행됩니다.

각 Borgmaster는 Machine Master Certificate와 연결된 비공개 키(그림에는 표시되지 않음)가 사전 설치된 상태로 제공됩니다.
ALTSd¹¹는 Borgmaster Handshake Certificate를 생성하고 Machine Master 비공개 키를 사용하여 서명합니다. 이 Handshake Certificate를 통해 Borgmaster가 ALTS로 보호되는 RPC를 발급할 수 있습니다.
Borgmaster가 Base Workload Master Certificate와 이에 상응하는 비공개 키를 생성합니다. Borgmaster는 이 Base Workload Master Certificate가 Signing Service에 의해 서명을 받기 위한 요청(ALTS로 보호되는 RPC)을 시작합니다. 결과적으로 Signing Service는 Borgmaster를 이 인증서에 대한 발급자로 표시합니다.
Borgmaster는 클라이언트가 워크로드 구성에 지정된 ID로 워크로드를 실행하도록 승인받았는지 확인합니다. 승인받은 경우, Borgmaster는 Borglet에서 Borg 워크로드를 예약하고 Workload Handshake Certificate와 그에 상응하는 비공개 키를 발급합니다. 이 인증서는 Base Workload Master Certificate에서 체인 연결됩니다. 그런 다음 Workload Handshake Certificate와 이 인증서의 비공개 키는 Borgmaster와 Borglet 사이의 상호 인증된 ALTS 보호 채널을 통해 Borglet으로 안전하게 전송됩니다. Borgmaster는 Base Workload Master Certificate를 순환하면서 실행 중인 모든 워크로드에 대해 대략 이틀마다 Handshake Certificate를 다시 발급합니다. 그 밖에도 같은 셀에서 같은 사용자로 실행 중인 각 워크로드는 Borgmaster가 프로비저닝하는 같은 재개 키와 식별자(ID_R)를 수신합니다.
작업 부하가 ALTS로 보호되는 RPC를 만들 필요가 있을 때는 핸드셰이크 프로토콜에서 Workload Handshake Certificate를 사용합니다. ID_R은 세션 재개를 시작하기 위해 핸드셰이크의 일부로 사용되기도 합니다. ALTS에서 세션 재개에 대한 자세한 내용은 세션 재개를 참조하세요.

ALTS 정책 적용

ALTS 정책은 어떤 발급자가 어떤 ID에 대해 특정 카테고리의 인증서를 발급하도록 승인되었는지를 보여주는 문서입니다. 이 정책은 프로덕션 네트워크에 있는 모든 머신에 배포됩니다. 예를 들어 CA는 ALTS 정책을 적용하여 머신과 사람에게 인증서를 발급할 수 있습니다. Borgmaster 또한 워크로드에 인증서를 발급할 수 있습니다.

인증서 발급과는 반대로, 인증서 확인 도중의 정책 적용은 다양한 유형의 배포에 다양한 정책을 적용할 수 있으므로 더욱 유연한 접근 방식이라는 사실을 발견했습니다. 예를 들어 프로덕션 클러스터의 정책보다 테스트 클러스터의 정책이 더 많은 권한을 허용하기를 원할 수 있습니다.

ALTS 핸드셰이크 도중 인증서 유효성 검사에는 ALTS 정책 검사가 포함됩니다. 이 정책은 유효성 검사를 받는 인증서에 나열된 발급자가 해당 인증서를 발급하도록 승인을 얻었음을 보장합니다. 그렇지 않을 경우 인증서가 거부되고 핸드셰이크 프로세스가 실패합니다. 그림 4는 정책 적용이 ALTS에서 어떻게 이루어지는지 보여줍니다. 그림 2의 시나리오에 따라 맬러리(자신의 권한을 높이고 싶어 하는 회사 사용자)가 네트워크를 다시 구성할 수 있는 강력한 ID인 Network Admin에게 마스터 인증서를 발급하고 싶어 한다고 가정해 봅시다. 맬러리가 ALTS 정책에서 이 작업을 수행할 권한이 없다는 점은 말할 나위도 없는 일입니다.

그림 4: 인증서 발급 및 사용

맬러리는 Network Admin ID에 대한 마스터 인증서를 발급하고 Signing Service의 서명을 받습니다. 이는 그림 2의 첫 세 단계와 유사합니다.
맬러리는 생성된 마스터 인증서와 연결된 마스터 비공개 키를 사용하여 Network Admin에 대한 핸드셰이크 인증서를 로컬 위치에 생성하고 서명합니다.
맬러리가 생성된 핸드셰이크 인증서를 사용하여 Network Admin ID를 가장하려는 경우, 맬러리가 통신을 시도하는 피어에서 ALTS 정책 시행자가 이 작업을 차단합니다.

인증서 해지

Google에서는 인증서가 만료되거나 인증서 해지 목록(CRL)에 포함될 때 무효화됩니다. 이 섹션에서는 Google의 내부 인증서 해지 메커니즘의 설계에 대해 설명합니다(이 백서를 쓰는 시점에서 여전히 배포 테스트를 진행 중).

인간 회사 사용자에게 발급되는 모든 인증서는 매일 만료되도록 타임스탬프에 지정되어 있으므로 사용자가 매일 다시 인증할 수밖에 없습니다. 프로덕션 머신에 발급되는 인증서 중 다수는 만료 타임스탬프를 사용하지 않습니다. 프로덕션 인증서 만료를 타임스탬프에 의존하면 클럭 동기화 문제로 인해 서비스 중단으로 이어질 수 있으므로 Google은 이에 의존하지 않습니다. 대신 우리는 CRL을 인증서의 순환과 이슈 대응 처리를 위한 정보 소스로 사용합니다. 그림 5는 CRL의 작동 방식을 보여줍니다.

그림 5: RevocationID를 사용한 마스터 인증서 생성

CA의 인스턴스가 초기화되면¹² CRL Service에 접속하여 해지 ID 범위를 요구합니다. 해지 ID는 8비트의 인증서 카테고리(예: human 또는 machine 인증서)와 56비트의 인증서 식별자라는 두 구성요소로 이루어진 64비트 길이의 ID입니다. CRL Service는 이러한 ID의 범위를 선택하여 CA로 반환합니다.
CA는 마스터 인증서에 대한 요청을 수신할 때 인증서를 생성하고 범위에서 선택하는 해지 ID를 임베딩합니다.
동시에 CA는 새로운 인증서를 해지 ID에 매핑하고 이 정보를 CRL Service로 보냅니다.
CA는 마스터 인증서를 발급합니다.

핸드셰이크 인증서에 할당된 해지 ID는 인증서 사용 방식에 따라 다릅니다. 예를 들어 인간 회사 사용자에게 발급되는 핸드셰이크 인증서는 사용자의 마스터 인증서의 해지 ID를 상속합니다. Borg 워크로드에 발급되는 핸드셰이크 인증서의 경우, Borgmaster의 해지 ID 범위에 의해 해지 ID가 할당됩니다. 이 ID 범위는 그림 5에 나타난 것과 유사한 프로세스로 CRL Service에 의해 Borgmaster에 할당됩니다. 피어는 ALTS 핸드셰이크에 관여할 때마다 CRL 파일의 로컬 복사본을 검사하여 원격 피어 인증서가 취소되지 않았음을 확인합니다.

CRL Service는 ALTS를 사용하는 모든 Google 머신으로 푸시 가능한 단일 파일로 모든 해지 ID를 컴파일합니다. CRL 데이터베이스는 수백 메가바이트이지만, 생성되는 CRL 파일은 다양한 압축 기술 덕분에 몇 메가바이트에 불과합니다.

ALTS 프로토콜

ALTS는 Handshake 프로토콜(세션 재개 포함)과 Record 프로토콜이라는 두 가지 프로토콜에 의존합니다. 이 섹션에서는 각 프로토콜에 대해 개략적으로 설명합니다. 이러한 개요 정보는 프로토콜의 상세한 사양으로 해석해서는 안 됩니다.

Handshake 프로토콜

ALTS 핸드셰이크 프로토콜은 Perfect Forward Secrecy(PFS)와 세션 재개를 둘 다 지원하는 디피-헬만 기반 인증 키 교환 프로토콜입니다. ALTS 인프라는 각 클라이언트와 서버가 제각기 ID를 가진 인증서와 신뢰할 수 있는 Signing Service 확인 키에 체인 연결되는 타원 곡선 디피-헬만(ECDH) 키를 가지도록 보장합니다. ALTS에서는 PFS가 기본적으로 사용되지 않습니다. 이런 정적 ECDH 키는 PFS가 핸드셰이크에서 사용되지 않더라도 forward secrecy를 갱신하기 위해 자주 업데이트되기 때문입니다. 클라이언트와 서버는 핸드셰이크 중에 공유 전송 암호화 키를 안전하게 협상하고 Record 프로토콜에서는 암호화 키를 사용하여 보호합니다. 예를 들어 클라이언트와 서버는 AES-GCM을 사용하여 RPC 세션을 보호하는 데 사용할 128비트 키에 동의할 수 있습니다. 핸드셰이크는 직렬화된 프로토콜 버퍼 메시지 4개로 구성되며 그 개요를 그림 6에서 확인할 수 있습니다.

그림 6: ALTS Handshake 프로토콜 메시지

클라이언트는 ClientInit 메시지를 보내 핸드셰이크를 시작합니다. 이 메시지는 클라이언트의 핸드셰이크 인증서와 핸드셰이크 관련 암호 및 클라이언트가 지원하는 레코드 프로토콜의 목록을 포함합니다. 클라이언트가 종료된 세션을 재개하려고 시도할 경우 이 메시지에는 재개 식별자와 암호화된 서버 재개 티켓이 포함됩니다.
서버는 ClientInit 메시지를 수신할 때 클라이언트 인증서를 확인합니다. 유효한 경우 서버는 클라이언트에서 제공하는 목록에서 핸드셰이크 암호와 레코드 프로토콜을 선택합니다. 서버는 ClientInit 메시지에 포함된 정보와 서버 자체의 로컬 정보 조합을 사용하여 DH 교환 결과를 계산합니다. 그 결과는 다음 세션 보안 비밀을 생성하기 위해 프로토콜의 스크립트 작성과 함께 키 파생 함수¹³에 대한 입력으로 사용됩니다.
- 페이로드 메시지를 암호화 및 인증하는 데 사용되는 레코드 프로토콜 보안 비밀 키 M.
- 향후 세션에서 재개 티켓에 사용할 재개 보안 비밀 R.
- 인증자 보안 비밀 A.
서버는 인증서, 선택한 핸드셰이크 암호, 레코드 프로토콜, 선택사항인 암호화된 재개 티켓을 포함하는 ServerInit 메시지를 보냅니다.
서버는 핸드셰이크 인증자를 포함한 ServerFinished 메시지를 전송합니다¹⁴. 이 인증자에 대한 값은 사전 정의된 비트 문자열과 인증자 보안 비밀 A를 통해 계산된 해시 기반 메시지 인증 코드(HMAC)를 사용하여 계산됩니다.
클라이언트가 ServerInit를 수신하면 서버 인증서를 확인하고, 서버와 유사한 DH 교환 결과를 계산하고, 똑같은 M, R 및 A 보안 비밀을 파생합니다. 클라이언트는 파생된 A를 사용하여 수신된 ServerFinished 메시지의 인증자 값을 확인합니다. 이때 핸드셰이크 프로세스에서 클라이언트는 M을 사용하여 메시지 암호화를 시작할 수 있습니다. 클라이언트가 이제 암호화된 메시지를 보낼 수 있으므로, ALTS에 RTT 핸드셰이크 프로토콜이 하나 있다고 말할 수 있습니다.
핸드셰이크 종료 시, 클라이언트는 사전 정의된 다른 비트 문자열을 통해 계산된 유사한 인증자 값(3단계 참조)과 함께 ClientFinished 메시지를 보냅니다. 필요한 경우 클라이언트는 향후 세션을 위해 암호화된 재개 티켓을 포함할 수 있습니다. 서버가 이 메시지를 수신하고 확인하면 ALTS 핸드셰이크 프로토콜이 종결되고 서버가 M을 사용하여 추가 페이로드 메시지를 암호화 및 인증하기 시작할 수 있습니다.

Handshake 프로토콜은 Google 내부 보안 분석팀의 타이 즈엉이 검토하고 브루노 블란쳇이 마틴 아바디의 도움을 받아 Proverif¹⁵ 도구를 사용하여 정식으로 확인했습니다.

Record 프로토콜

Handshake 프로토콜 섹션에서는 Handshake 프로토콜을 사용하여 Record 프로토콜 암호를 협상하는 방법을 설명했습니다. 이 프로토콜 암호는 네트워크 트래픽을 암호화하고 인증하는 데 사용됩니다. 이러한 작업을 수행하는 스택의 레이어를 ALTS Record Protocol(ALTSRP)이라고 합니다.

ALTSRP는 다양한 크기의 키와 보안 기능이 있는 일련의 암호화 스키마를 포함합니다. 클라이언트는 핸드셰이크 중에 선호도 순으로 정렬된 선호 스키마 목록을 보냅니다. 서버는 클라이언트 목록에서 서버의 로컬 구성과 일치하는 첫 번째 프로토콜을 선택합니다. 이런 스키마 선택 방법을 이용하면 클라이언트와 서버가 둘 다 다른 암호화 설정을 가질 수 있으므로 암호화 스키마로 단계적으로 진입하거나 이러한 스키마를 제거할 수 있습니다.

프레이밍

프레임은 ALTS에서 가장 작은 데이터 단위입니다. 크기에 따라 각각의 ALTSRP 메시지는 하나 이상의 프레임으로 구성될 수 있습니다. 각 프레임은 다음과 같은 필드를 포함합니다.

길이: 프레임의 길이를 표시하는 32비트의 부호 없는 값(바이트). 이 4바이트의 길이 필드는 총 프레임 길이의 일부로 포함되지 않습니다.
유형: 프레임 유형(예: 데이터 프레임)을 지정하는 32비트의 값.
페이로드: 전송 중인 실제 인증된 데이터와 선택적으로 암호화된 데이터.

프레임의 최대 길이는 1MB + 4개의 길이 바이트입니다. 현재 RPC 프로토콜의 경우, 프레임이 짧을수록 버퍼링 메모리가 덜 필요하므로 프레임 길이를 추가로 제한합니다. 또한 보다 큰 프레임은 서버를 결핍시키기 위해 이루어지는 서비스 거부(DoS) 공격 중에 잠재적 공격자가 악용할 수 있습니다. Google은 프레임 길이를 제한할 뿐 아니라, 같은 레코드 프로토콜 보안 비밀 M을 사용하여 암호화할 수 있는 프레임의 수도 제한합니다. 이 제한은 프레임 페이로드를 암호화 및 복호화하는 데 사용되는 암호화 스키마에 따라 달라집니다. 이 제한에 도달하면 연결이 닫혀야 합니다.

페이로드

ALTS에서는 각 프레임에 무결성이 보호되고 선택적으로 암호화되는 페이로드가 포함됩니다¹⁶. 이 자료를 발간하는 시점 현재, ALTS는 다음 모드를 지원합니다.

AES-128-GCM, AES-128-VCM: 각각 128비트 키가 있는 AES-GCM 및 AES-VCM 모드. 이러한 모드는 각각 GCM과 VCM 스키마¹⁷를 사용하여 페이로드의 기밀성과 무결성을 보호합니다.
AES-128-GMAC, AES-128-VMAC: 이러한 모드는 태그 계산을 위해 각각 GMAC와 VMAC를 사용하여 무결성 전용 보호 기능을 지원합니다. 페이로드는 무결성을 보호하는 암호화 태그가 있는 일반 텍스트로 전송됩니다.

Google에서는 위협 모델과 성능 요구 사항에 따라 다양한 보호 모드를 사용합니다. 통신 개체가 Google이나 Google의 대리인이 통제하는 동일한 물리적 경계 내에 있는 경우 무결성 전용 보호 기능이 사용됩니다. 이러한 개체는 데이터의 민감도에 따라 인증된 암호화로 업그레이드할 수 있습니다. 통신 개체가 Google이나 Google의 대리인이 통제하는 다른 물리적 경계 내에 있어 통신이 광역 통신망(WAN)을 통해 전달되는 경우, Google은 선택한 모드와는 무관하게 연결의 보안을 인증된 암호화로 자동으로 업그레이드합니다. 데이터가 Google이나 Google의 대리인이 통제하는 물리적 경계 외부로 전송될 때 똑같이 엄격한 보안 조치를 적용할 수 없으므로 Google은 전송 중 데이터에 다른 보호 조치를 적용합니다.

각 프레임은 별도로 무결성이 보호되고 선택적으로 암호화됩니다. 두 피어 모두 정상 작업 중에 동기화되는 요청 카운터와 응답 카운터를 유지합니다. 서버가 비정상적인 요청 또는 반복되는 요청을 수신하는 경우 암호화 무결성 확인에 실패하여 요청이 삭제됩니다. 마찬가지로 클라이언트는 반복되거나 잘못된 응답을 삭제합니다. 또한 프레임 헤더에 값을 포함하는 것과는 반대로, 양쪽 피어 모두 카운터를 유지하도록 하면 유선 연결에서 바이트 수가 추가로 절감됩니다.

세션 재개

ALTS 사용자는 집중적인 비대칭 암호화 작업을 수행할 필요 없이 이전 세션을 재개할 수 있습니다. 세션 재개는 ALTS Handshake 프로토콜에 빌드된 기능입니다.

ALTS 핸드셰이크를 사용하면 클라이언트와 서버는 향후 연결을 재개하는 데 사용될 수 있는 재개 티켓을 안전하게 교환하고 캐시할 수 있습니다¹⁸. 캐시된 각각의 재개 티켓은 같은 ID를 사용하여 같은 데이터 센터 셀에서 실행 중인 모든 워크로드에 대해 고유한 재개 식별자(ID_R)에 의해 색인이 생성됩니다. 이러한 티켓은 해당 식별자와 연결된 대칭 키를 사용하여 암호화됩니다.

ALTS는 다음 두 가지 유형의 세션 재개를 지원합니다.

서버 측 세션 재개: 클라이언트는 서버 ID와 파생된 재개 보안 비밀 R을 포함한 재개 티켓을 만들고 암호화합니다. 재개 티켓은 핸드셰이크 종료 시 ClientFinished 메시지에 포함되어 서버로 전송됩니다. 향후 세션에서는 서버가 ServerInit 메시지에 티켓을 포함하여 클라이언트로 되돌려보내 세션을 재개할 수 있습니다. 클라이언트는 티켓을 받으면 재개 보안 비밀 R과 서버의 ID를 모두 복구할 수 있습니다. 클라이언트는 이 정보를 사용하여 세션을 재개할 수 있습니다.

ID_R은 항상 특정 연결이 아니라 ID와 연결됩니다. ALTS에서는 여러 클라이언트가 같은 데이터 센터에서 같은 ID를 사용할 수 있습니다. 이를 통해 클라이언트는 이전에는 통신한 적이 없을 수 있는 서버와 세션을 재개할 수 있습니다(예: 부하 분산기가 같은 애플리케이션을 실행 중인 다른 서버로 클라이언트를 보내는 경우).
클라이언트 측 세션 재개: 핸드셰이크 종료 시 서버는 ServerFinished 메시지에 암호화된 재개 티켓을 포함하여 클라이언트로 보냅니다. 이 티켓은 재개 보안 비밀 R과 클라이언트의 ID를 포함합니다. 클라이언트는 이 티켓을 사용하여 같은 ID_R을 공유하는 임의의 서버와 연결을 재개할 수 있습니다.

세션이 재개될 때 재개 보안 비밀 R을 사용하여 새로운 세션 보안 비밀 M’, R’, A’를 파생합니다. M’는 페이로드 메시지를 암호화하고 인증하는 데 사용되고, A’는 ServerFinished 및 ClientFinished 메시지를 인증하는 데 사용되고, R’는 새로운 재개 티켓에 캡슐화됩니다. 같은 재개 보안 비밀 R은 절대로 두 번 이상 사용되지 않는다는 점에 유의하세요.

절충사항

키 손상 가장 공격

ALTS 핸드셰이크 프로토콜은 그 설계 특성상 키 손상 가장(KCI) 공격에 민감합니다. 악의적 사용자가 워크로드의 DH 비공개 키 또는 재개 키를 손상하는 경우, 키를 사용하여 다른 워크로드를 대해 해당 워크로드로 가장할 수 있습니다¹⁹. ID의 한 인스턴스에서 발급된 재개 티켓을 해당 ID의 다른 인스턴스가에서 사용할 수 있는만큼, 이는 Google의 재개 위협 모델에 명시되어 있습니다.

KCI 공격으로부터 보호하는 ALTS 핸드셰이크 프로토콜의 변형이 있지만, 재개가 바람직하지 않은 환경에서만 사용할 가치가 있습니다.

Handshake 메시지의 개인정보 보호

ALTS는 어떤 내부 ID가 통신 중인지 가장하도록 설계되어 있지 않으므로, 피어의 ID를 숨기기 위해 핸드셰이크 메시지를 암호화하지 않습니다.

Perfect Forward Secrecy

ALTS에서는 Perfect Forward Secrecy(PFS)가 지원되지만 기본적으로 사용되는 것은 아닙니다. 대신에 대부분의 애플리케이션에 대해 자주 인증서 순환을 사용하여 forward secrecy를 설정합니다. TLS 1.2 및 이전 버전에서는 세션 재개가 PFS로 보호되지 않습니다. PFS가 ALTS와 함께 사용될 경우 PFS 또한 재개된 세션에 대해 사용됩니다.

제로 왕복 재개

TLS 1.3은 제로 왕복(0-RTT)을 요구하는 세션 재개를 제공하지만, 보안 속성이 더 약합니다²⁰. Google에서는 RPC 연결의 수명이 일반적으로 길기 때문에 ALTS에 0-RTT 옵션을 포함하지 않기로 했습니다. 때문에 채널 설정 지연 시간 단축은 0-RTT 핸드셰이크가 요구하는 추가적인 복잡성이나 보안 수준 축소에 대해 흡족할 만한 절충안은 아니었습니다.