인증된 암호화: AES-GCM 및 ChaCha20-Poly1305

Authenticated Encryption (AE)은 근본적인 문제를 해결합니다. 기존 암호화는 Data를 비밀로 유지하는 기밀성만 제공할 뿐 암호문이 변조되었는지는 확인하지 않습니다. 공격자가 암호문의 비트를 바꾸면 수신자는 변조 사실을 모른 채 잘못된 결과를 복호화할 수 있습니다. Associated Data를 포함한 인증 암호화(AEAD)는 무결성과 진위성을 동시에 보장하며, 암호화된 암호문과 모든 변경을 감지하는 인증 태그를 함께 생성합니다.

AES-GCM(Galois/Counter Mode)은 두 구성 요소를 결합합니다. 암호화에는 AES-CTR(Counter Mode)을 사용하고 무결성에는 GMAC(Galois Message Authentication Code)을 사용합니다. AES-CTR은 카운터 값을 암호화한 뒤 평문과 XOR하여 키 스트림을 생성합니다. 따라서 CBC 모드와 달리 암호화를 병렬로 처리할 수 있습니다. GMAC은 암호문과 모든 Associated Data에 대해 인증 태그를 계산합니다. 그 결과 생성된 128비트 태그는 암호문과 함께 전송되며, 단 하나의 비트라도 변경되면 태그가 무효화됩니다.

AES-GCM에는 일반적으로 96비트(12바이트)인 논스(nonce, 한 번만 사용하는 숫자)가 필요합니다. 논스는 같은 키를 사용하는 각 암호화 작업마다 반드시 고유해야 합니다. 비밀일 필요는 없지만 절대로 재사용해서는 안 됩니다. AES-GCM에서 논스를 재사용하면 치명적인 문제가 발생합니다. 같은 키와 논스로 두 메시지를 암호화하면 공격자가 암호문을 XOR하여 키 스트림을 상쇄하고, 두 평문을 모두 복구할 수도 있습니다. 이러한 취약점은 '논스 오용'이라고도 하며, 실제 키 복구 공격의 원인이 되었습니다.

AES-GCM 논스를 재사용하면 동일한 키 스트림이 두 메시지에 사용되므로 공격자는 C1 XOR C2 = P1 XOR P2(두 평문의 XOR)를 계산할 수 있습니다. 또한 논스 재사용으로 인증 키 H를 복구할 수 있어, 공격자가 임의의 메시지에 대해 유효한 인증 태그를 위조할 수 있습니다. 이는 기밀성과 무결성을 모두 완전히 무너뜨립니다. Sony PS3와 같은 시스템이 바로 이 공격의 피해를 입었습니다. 방어 방법은 CSPRNG로 생성한 무작위 논스를 사용하거나, 절대 초기화되지 않는 결정적 카운터를 사용하는 것입니다.

ChaCha20-Poly1305는 TLS 1.3에서 의무적으로 지원하는 또 다른 AEAD 암호입니다. ChaCha20은 Daniel Bernstein이 설계한 스트림 암호로, 덧셈-순환 이동-XOR(ARX) 연산을 사용해 키 스트림을 생성합니다. 조회 테이블이 없고 완전히 일정한 시간에 실행되며, AES 하드웨어 가속이 없는 CPU에서 매우 빠릅니다. Poly1305는 암호문에 대한 인증 태그를 계산하는 일회용 MAC(메시지 인증 코드)입니다. 두 기술을 함께 사용하면 AES-GCM과 동등한 보안을 제공하면서 모바일 및 IoT 기기에서 훨씬 빠르게 동작합니다.

최신 x86 및 ARM64 데스크톱·서버 프로세서에는 AES-GCM을 매우 빠르게 만드는 AES-NI 하드웨어 명령어가 포함되어 있습니다. 그러나 많은 모바일 및 IoT 프로세서에는 AES-NI가 없어 소프트웨어 AES-GCM이 상대적으로 느립니다. ChaCha20-Poly1305는 단순한 산술 연산을 사용해 소프트웨어에서 빠르게 동작하도록 설계되었으므로, 하드웨어 가속 없이도 모바일 기기에서 비슷한 성능을 제공합니다. Google은 바로 Android 기기를 위해 TLS에 ChaCha20-Poly1305를 대안으로 추가했으며, 현재는 TLS 1.3의 주요 암호 모음으로 자리 잡았습니다.

AEAD의 'AD'는 연결 데이터(Associated Data)를 의미합니다. 연결 데이터는 인증되지만 암호화되지는 않는 평문 메타데이터입니다. 이를 통해 패킷 헤더나 레코드 유형 필드처럼 읽을 수 있어야 하는 데이터를 인증하면서도 변조로부터 보호할 수 있습니다. TLS 1.3에서는 레코드 헤더 바이트가 AEAD 계산에서 연결 데이터로 포함됩니다. 공격자가 헤더를 수정하면(예: 레코드 길이 변경) 인증 태그 검증이 실패하고 연결이 종료됩니다.

AEAD가 표준이 되기 전에는 암호학자들이 암호화 후 MAC(EtM)을 권장했습니다. 평문을 암호화한 다음 암호문에 대한 MAC을 계산하는 방식입니다. 이 방식은 안전하지만 서로 다른 두 키를 사용해 두 개의 별도 작업을 수행해야 합니다. AES-GCM과 같은 AEAD 방식은 하나의 키로 두 작업을 결합하므로 구현의 복잡성이 줄어듭니다. 또한 이전 TLS 버전에서 사용된 MAC 후 암호화(MtE)(CBC + HMAC) 방식을 괴롭혔던 패딩 오라클 공격이라는 문제 유형도 제거합니다. AEAD를 사용하는 TLS 1.3은 이러한 문제를 완전히 피합니다.

AES-128-GCM과 AES-256-GCM은 모두 NIST의 승인을 받았으며 기존 컴퓨터에 대해 안전한 것으로 간주됩니다. AES-128은 128비트 보안을 제공하고 성능이 약간 더 빠르며, AES-256은 256비트 보안을 제공해 향후 암호 분석 및 양자 위협에 대해 더 큰 여유를 제공합니다. 오늘날 대부분의 애플리케이션에서는 AES-128-GCM으로 충분하지만, 정부 기밀 시스템(NSA Suite B)에서는 AES-256을 요구합니다. TLS 1.3은 두 방식을 모두 제공하며, 서버는 보안 정책에 따라 우선순위를 정할 수 있습니다.

AEAD 암호문을 복호화할 때 수신자는 복호화하기 전에 인증 태그를 검증해야 합니다. 과정은 다음과 같습니다. 수신한 암호문, 키, 논스로 예상 태그를 다시 계산하고, 일정한 시간에 실행되는 비교 함수를 사용해 수신한 태그와 비교합니다. 두 태그가 일치할 때만 복호화를 진행합니다. 일정 시간 비교는 매우 중요합니다. 비교가 처음으로 일치하지 않는 바이트에서 즉시 중단되면 공격자는 타이밍 부채널 공격을 수행해 바이트 단위로 유효한 태그를 위조할 수 있습니다. 조기 종료 비교를 사용하는 AEAD 라이브러리는 취약합니다.

AEAD 알고리즘은 현대 보안 기술 전반에서 널리 사용됩니다. TLS 1.3은 모든 레코드 암호화에 AES-GCM과 ChaCha20-Poly1305를 사용하고, WireGuard VPN은 ChaCha20-Poly1305만 사용하며, Signal Protocol은 메시지 암호화에 이를 사용합니다. 또한 HTTP/3의 기반인 QUIC 프로토콜은 AES-GCM을 사용합니다. TLS_AES_256_GCM_SHA384와 같은 암호 모음에서 SHA384는 무결성 메커니즘이 아니라 키 파생에 사용하는 HKDF 해시 함수를 의미합니다. 무결성은 GCM 태그가 처리합니다.

이 레슨에서 배운 CompTIA Security+ (SY0-701) 개념을 확인해 보세요.

이 레슨에서는 다음을 배웠습니다. AEAD 알고리즘은 인증 태그를 통해 기밀성과 무결성을 동시에 제공합니다. 인증 태그는 암호문이 수정되었는지 감지합니다. AES-GCM에서 논스를 재사용하면 치명적입니다. 키 스트림을 복구하고 인증 키를 위조할 수 있으므로 암호화마다 논스가 고유해야 합니다. 또한 ChaCha20-Poly1305는 AES 하드웨어 가속이 없는 기기에서 AES-GCM을 대신할 수 있는 성능 효율적인 대안입니다. 다음에는 비밀번호를 보호하기 위한 키 파생 함수를 살펴보겠습니다.