AES-GCM 쉽게 풀어쓰기: 왜 요즘 암호화는 이걸 쓸까
요즘 나오는 보안 관련 글을 읽다 보면 "AES-256-GCM으로 암호화합니다"라는 문장을 자주 만납니다. 영문 약자가 줄줄이 붙어 있어 어렵게 느껴지지만, 이 이름은 사실 두 부분으로 나뉩니다. AES는 "글을 어떻게 뒤섞을 것인가"를, GCM은 "그 뒤섞는 작업을 어떤 방식으로 이어 붙이고, 중간에 바뀌지 않았는지 어떻게 확인할 것인가"를 정합니다. 이 글에서는 비유를 곁들여 두 부분을 차례로 풀고, 키·IV·인증 태그가 각각 왜 필요한지 설명합니다.
AES: 열쇠 하나로 데이터를 뒤섞는 기본 부품
AES는 Advanced Encryption Standard의 약자로, 미국 표준기술연구소(NIST)가 공개 공모를 거쳐 2000년대 초에 표준으로 채택한 암호 알고리즘입니다. 벨기에 연구자들이 만든 Rijndael이라는 설계가 뽑혔고, 지금은 전 세계 웹사이트, 와이파이, 디스크 암호화 등에 널리 쓰입니다. 공개 공모와 오랜 검증 덕분에 "설계가 비밀이 아니어도 안전해야 한다"는 현대 암호의 원칙을 잘 보여 주는 사례이기도 합니다.
AES의 가장 중요한 특징은 데이터를 16바이트(128비트) 덩어리, 즉 블록 단위로 처리한다는 점입니다. 키는 128비트, 192비트, 256비트 가운데 고를 수 있는데, 키가 길수록 모든 열쇠를 하나씩 넣어 보는 방식의 공격이 현실적으로 불가능해집니다. 256비트 키의 경우 가능한 조합의 수가 우주의 원자 수에 비교될 정도로 크기 때문에, 오늘날 공개된 지식으로는 열쇠를 무작정 대입해서 찾는 길이 사실상 막혀 있습니다. 실제로 AES가 깨지는 경우는 알고리즘 자체보다 키가 유출되거나 사용법이 잘못되었을 때입니다.
비유하자면 AES는 "16칸짜리 자물쇠 상자를 아주 정교하게 섞는 기계"입니다. 열쇠(키)를 넣고 돌리면 16바이트 입력이 알아볼 수 없는 16바이트 출력으로 바뀌고, 같은 열쇠로 반대 방향으로 돌리면 원래대로 돌아옵니다. 그런데 이 기계에는 큰 한계가 있습니다. 한 번에 16바이트만 다룰 수 있다는 것입니다. 우리가 보내는 메시지는 훨씬 길기 때문에, 여러 블록을 어떻게 이어 처리할지 정하는 "운용 방식"이 따로 필요합니다. GCM이 바로 그 운용 방식입니다.
블록을 이어 붙이는 방법이 왜 중요한가
가장 단순한 방법은 블록마다 같은 기계를 그대로 돌리는 것입니다. 이를 ECB 방식이라고 부르는데, 치명적인 약점이 있습니다. 같은 입력 블록은 항상 같은 출력 블록이 되기 때문에 원문의 패턴이 그대로 새어 나옵니다. 그림 파일을 ECB로 암호화하면 색의 윤곽이 그대로 보이는 유명한 예가 있습니다. 글자 하나하나는 가려졌지만 "어디가 같고 어디가 다른지"가 드러나는 것입니다.
이를 피하려면 블록마다 조금씩 다른 조건으로 기계를 돌려야 합니다. GCM은 이름에 들어 있는 Counter, 즉 카운터 방식을 씁니다. 번호표를 1, 2, 3 순서로 뽑아 기계에 넣어 얻은 결과를 "일회용 열쇠 흐름"으로 삼고, 원문과 섞습니다. 번호표가 매번 다르니 같은 글자가 반복되어도 결과는 달라집니다. 이 구조의 부수 효과로 블록 크기에 맞춰 글자를 억지로 채울 필요도 없어서, 원문 길이와 거의 같은 길이의 암호문이 나옵니다.
IV: 번호표의 출발점은 매번 달라야 합니다
카운터를 1부터 시작하면 두 메시지가 같은 번호표를 쓰게 됩니다. 그래서 GCM에는 IV(초기화 벡터, 또는 nonce라고도 부릅니다)라는 값을 함께 넣습니다. 번호표의 출발점을 메시지마다 다르게 정해 주는 값이라고 생각하시면 됩니다. GCM에서는 12바이트(96비트)가 표준적으로 권장되는 길이이며, 이 서비스도 12바이트 IV를 씁니다.
IV는 비밀일 필요가 없습니다. 암호문 앞에 그냥 붙여서 함께 보내도 됩니다. 대신 지켜야 할 철칙이 하나 있습니다. 같은 키로 같은 IV를 두 번 쓰면 안 된다는 것입니다. 같은 번호표 흐름으로 두 글을 가리게 되면, 두 암호문을 겹쳐서 원문끼리의 관계를 뽑아낼 수 있고, GCM에서는 인증 장치까지 무너질 수 있습니다. 그래서 보통 IV를 무작위로 뽑는데, 12바이트 무작위 값은 한 키로 아주 많은 메시지를 암호화하지 않는 한 겹칠 가능성이 매우 낮습니다. 다만 한 키로 수십억 건 이상을 처리하는 시스템이라면 겹칠 확률을 따져서 키를 교체해야 합니다. 개인 간 메시지처럼 규모가 작은 용도에서는 무작위 IV로 충분합니다.
이 서비스는 글을 암호화할 때마다 새로운 12바이트 IV를 브라우저에서 무작위로 뽑습니다. 그래서 같은 문장을 같은 번역기로 두 번 암호화해도 결과 비밀어는 매번 다르게 나옵니다. 보는 사람 입장에서는 "같은 말을 했다"는 사실조차 알아낼 수 없다는 뜻입니다.
인증 태그: 암호화만으로는 부족한 이유
많은 분이 암호화를 "내용을 못 보게 하는 것"으로만 생각하지만, 실제로는 "내용이 중간에 바뀌지 않았다는 보장"도 똑같이 중요합니다. 옛날 방식(암호화만 하는 방식)에서는 공격자가 암호문의 비트 몇 개를 바꾸면 복호화된 글도 그에 대응해 예측 가능하게 바뀌는 경우가 있었습니다. 내용은 못 읽어도 "계좌번호 숫자를 바꾸는" 식의 조작이 가능했던 것입니다.
GCM의 G는 Galois를 뜻하며, 암호문에서 계산해 내는 짧은 확인 값을 만드는 수학 구조(GHASH)를 가리킵니다. 이 값이 인증 태그입니다. 보통 16바이트(128비트)가 붙습니다. 택배 상자에 붙이는 "개봉하면 찢어지는 봉인 스티커"를 떠올리시면 됩니다. 받는 사람은 상자를 열기 전에 먼저 스티커를 확인합니다. 스티커가 다르면 내용이 단 1비트만 바뀌었어도 복호화를 아예 거부합니다. 이런 방식을 인증된 암호화(AEAD)라고 부릅니다.
그래서 틀린 키로 복호화를 시도하거나, 비밀어를 한 글자만 바꿔서 시도하면 "엉뚱한 글자들이 나오는" 것이 아니라 "실패"라는 결과가 나옵니다. 이 서비스에서도 마찬가지입니다. 비밀어가 중간에 잘리거나 한 글자가 바뀌면 깨진 글이 아니라 해독 실패로 표시됩니다. 이는 오류가 아니라 의도된 안전장치입니다.
추가 인증 데이터(AAD): 암호화하지 않지만 보호하는 부분
GCM에는 한 가지 기능이 더 있습니다. 암호화하지는 않지만 태그 계산에는 포함시키는 "추가 인증 데이터"입니다. 편지 봉투의 겉면에 적힌 정보처럼, 누구나 볼 수 있지만 바뀌면 안 되는 부분을 보호할 때 씁니다. 이 서비스의 경우 맨 앞 2바이트(형식 버전과 압축 여부를 나타내는 표시)를 AAD로 지정합니다. 누군가 이 표시를 바꿔서 해독기를 헷갈리게 하려 해도 태그 검사에서 걸러집니다.
전체 구조를 정리하면 이 서비스의 비밀어는 버전 1바이트, 플래그 1바이트, IV 12바이트, 그리고 암호문과 태그가 이어진 형태입니다. 사람이 읽는 한글 모양으로 바뀌어 있을 뿐, 안쪽은 이런 바이트 조합입니다.
GCM을 쓸 때 알아 둘 한계
AES-GCM이 만능은 아닙니다. 첫째, 앞서 말한 IV 재사용에 매우 민감합니다. 라이브러리가 아니라 직접 구현한다면 IV 관리에 가장 신경 써야 합니다. 둘째, 암호화는 길이를 가려 주지 않습니다. 암호문의 길이는 원문의 길이와 거의 같으므로 "짧은 답장이다"라는 정도의 정보는 드러납니다. 셋째, 키가 어떻게 만들어지고 전달되는지는 GCM의 영역 밖입니다. 아무리 튼튼한 자물쇠라도 열쇠를 엉뚱한 곳에 두면 소용이 없습니다. 이 서비스에서는 해독 키 재료가 주소의 # 뒤에 들어 있고, 비밀번호를 쓰면 PBKDF2(반복 600000회)와 HKDF를 거쳐 키가 만들어지지만, 주소나 비밀번호가 새면 그 앞의 암호 기술은 의미가 없어집니다.
그럼에도 AES-GCM이 널리 쓰이는 이유는 분명합니다. 오래 검증된 부품(AES)에, 암호화와 위변조 검출을 한 번에 처리하는 운용 방식(GCM)이 합쳐져 있고, 요즘 대부분의 프로세서가 AES 전용 명령을 갖고 있어 빠르며, 브라우저의 표준 기능으로도 제공되기 때문입니다. 키를 서로 어떻게 나눠 갖는지가 궁금하시다면 대칭키 암호와 공개키 암호, 무엇이 다를까를 이어서 읽어 보세요. 실제 동작을 직접 보고 싶다면 번역기 열기에서 같은 문장을 두 번 암호화해 결과가 매번 다르게 나오는지 확인해 보셔도 좋습니다.
잘못된 내용이나 보완할 점을 발견하셨다면 소개·문의의 이메일로 알려 주세요. 확인 후 글을 고치고 수정일을 갱신합니다.