주요 암호 오용 패턴

전자 코드북(ECB) 모드는 각 블록을 동일한 키로 독립적으로 암호화합니다. 동일한 평문 블록은 동일한 암호문 블록을 생성합니다. 대표적인 예가 "ECB 펭귄"입니다. 비트맵 이미지를 ECB로 암호화하면 이미지의 블록 수준 구조가 그대로 유지되어 암호문에서 펭귄의 윤곽이 뚜렷하게 보입니다. ECB 모드는 의미론적 보안을 제공하지 않으므로 실제 암호화 목적으로는 절대 사용해서는 안 됩니다.

암호학 기본 요소를 처음부터 구현하는 것은 소프트웨어 개발에서 가장 위험한 관행 중 하나입니다. 암호학에서는 공격자가 있는 환경에서도 완벽하게 올바르게 동작해야 합니다. 미세한 시간 정보 누출, 패딩에서 1만큼 어긋난 오류, 보안 요구 사항에 대한 오해만으로도 정상적인 테스트에서는 올바른 동작과 구별되지 않는 악용 가능한 취약점이 생길 수 있습니다. 전문 암호학자도 구현 실수를 저지르므로 애플리케이션 개발자는 충분히 검토된 라이브러리만 사용해야 합니다.

MD5는 2004년부터 충돌 공격으로 안전하지 않으며, 동일한 MD5 해시를 갖는 두 파일을 만드는 일은 계산상 매우 쉽습니다. SHA-1 충돌 공격은 2017년 Google의 SHAttered 공격으로 실제 가능함이 입증되었으며, 동일한 SHA-1 해시를 갖는 두 PDF 파일을 생성했습니다. MD5와 SHA-1은 디지털 서명, 콘텐츠 무결성, 비밀번호 저장, HMAC 등 어떠한 보안 목적에도 사용해서는 안 됩니다. 최신 환경에서는 SHA-256, SHA-3 또는 BLAKE2를 사용하십시오.

time()이나 예측 가능한 다른 값을 의사 난수 생성기의 시드로 사용하는 것은 PRNG 출력이 보안 목적으로 사용될 때 치명적인 취약점이 됩니다. 공격자가 키가 생성된 대략적인 시점을 알고 있다면 시드 공간, 즉 작은 시간 범위에 있는 가능한 모든 타임스탬프를 무차별 대입하여 키를 복구할 수 있습니다. 대표적인 예로 Netscape 초기 버전은 SSL 키 생성을 위한 시드에 시간과 프로세스 ID를 사용했으며, 같은 시스템의 공격자는 이 두 값을 모두 관찰할 수 있었습니다.

C의 rand(), java.util.Random, Python의 random 모듈은 통계적 품질이 중요한 시뮬레이션을 위해 설계된 결정론적 선형 합동 생성기나 메르센 트위스터를 사용하며, 보안을 위해 설계된 것이 아닙니다. 공격자가 이러한 생성기에서 충분한 출력을 관찰하면 내부 상태를 재구성하여 이후의 모든 출력을 예측할 수 있습니다. 보안 목적으로는 OS가 제공하는 CSPRNG를 사용하십시오. Python에서는 secrets.token_bytes(), Node.js에서는 crypto.randomBytes(), Linux에서는 /dev/urandom을 사용하면 됩니다.

인증 없이 암호화하면 기밀성만 제공할 뿐 무결성은 제공하지 않습니다. 평문을 읽을 수 없는 공격자도 암호문을 변경하여 평문을 예측 가능한 방식으로 바꿀 수 있습니다(특히 CTR 또는 CBC 모드에서 그렇습니다). 이러한 변조 가능성은 공격을 가능하게 합니다. 예를 들어 암호화된 은행 거래를 가로챈 공격자는 평문을 알지 못해도 비트를 뒤집어 송금액이나 수취 계좌를 변경할 수 있습니다. 항상 인증된 암호화(AEAD)를 사용하십시오.

암호화 키나 초기화 벡터를 소스 코드에 하드코딩하는 것은 치명적인 취약점입니다. 소스 코드는 버전 관리 저장소에 커밋되는 경우가 많으며, 그중에는 공개 저장소도 있습니다. 비공개 저장소라 하더라도 코드에 접근할 수 있는 사람은 누구나 키를 알 수 있습니다. 하드코딩된 키를 사용하면 모든 인스턴스가 동일한 키를 사용하게 되고, 키를 교체하려면 다시 배포해야 합니다. 키는 환경 변수, 비밀 관리 시스템(HashiCorp Vault, AWS Secrets Manager) 또는 하드웨어 보안 모듈에 저장해야 합니다.

동일한 키로 여러 번 암호화하면서 같은 초기화 벡터를 사용하면 심각한 취약점이 발생합니다. CTR 모드에서 IV를 재사용하면 동일한 키 스트림이 생성되어 XOR을 통해 평문을 복구할 수 있습니다. CBC 모드에서 IV를 재사용하면 공격자가 두 메시지가 동일한 평문 블록으로 시작하는지 알아낼 수 있습니다. GCM에서 논스(IV)를 재사용하면 치명적인 결과가 발생합니다(논스 재사용 단원을 참조하십시오). 각 암호화 작업마다 새로운 무작위 IV를 생성하고, 복호화 컨텍스트와 함께 저장할 수 있도록 암호문 앞에 IV를 덧붙이십시오.

MD5, SHA-256 또는 그 밖의 빠른 암호학적 해시로 비밀번호를 해시하여 저장하는 것은 충분하지 않습니다. 최신 GPU는 초당 수십억 개의 SHA-256 해시를 계산할 수 있으므로, 도난당한 해시 데이터베이스를 대상으로 한 오프라인 무차별 대입 공격을 매우 빠르게 수행할 수 있습니다. 비밀번호 해싱에는 목적에 맞게 설계된 느리고 메모리 집약적인 함수인 bcrypt, scrypt 또는 Argon2id가 필요합니다. 이러한 함수는 특수 하드웨어를 사용하더라도 무차별 대입에 큰 비용이 들도록 설계되어 오프라인 공격을 현실적으로 실행하기 어렵게 만듭니다.

SSL/TLS 인증서 검증을 비활성화하면(Python에서 ssl.CERT_NONE을 설정하거나, curl에 -k를 전달하거나, Android에서 trustAllCerts=true를 설정하는 경우) 중간자 공격에 대한 보호가 사라집니다. 공격자는 어떤 인증서든 제시하여 모든 통신을 가로챌 수 있습니다. 이러한 방식은 자체 서명 인증서 오류를 우회하기 위해 개발 환경에서 사용되지만, 운영 환경까지 남아 있는 경우가 많습니다. 항상 올바른 인증서 검증을 사용하고, 근본적인 인증서 문제를 올바르게 해결해야 합니다.

암호화 함수는 반환값이나 예외를 통해 실패를 알립니다. 이를 무시하면 복호화 결과가 무의미한 값이거나, 검증이 실패했거나, 키 생성 중 오류가 발생한 것처럼 유효하지 않은 상태에서 실행이 계속될 수 있습니다. OpenSSL과 같은 C 기반 API에서는 반환값을 무시하는 것이 특히 위험합니다. 초기화되지 않은 메모리를 사용한 채 프로그램이 계속 실행될 수 있기 때문입니다. 암호화 함수의 모든 반환값을 항상 확인하고, 실패를 안전하게 처리해야 합니다.

데이터를 암호화할 때 ECB(Electronic Codebook) 모드가 안전하지 않은 것으로 간주되는 이유는 무엇입니까?

피해야 할 대표적인 오용 패턴은 다음과 같습니다. ECB 모드를 절대 사용하지 말 것(블록 패턴 노출), 암호 기본 요소를 직접 구현하지 말 것, 보안 목적으로 MD5와 SHA-1을 거부할 것, PRNG는 time()이 아니라 CSPRNG로 시드할 것, 보안에 민감한 모든 무작위 값 생성에 CSPRNG를 사용할 것, 암호화된 데이터를 항상 인증할 것(AEAD), 키나 IV를 소스 코드에 직접 기록하지 말 것, 암호화마다 새로운 IV를 생성할 것, 비밀번호에는 빠른 해시가 아니라 Argon2id를 사용할 것, TLS 인증서를 항상 검증할 것, 암호화 함수의 모든 반환값을 확인할 것입니다.