패딩 오라클 공격 (Padding Oracle Attack)
쉽게 풀면
암호화할 때 데이터를 정해진 블록 크기에 맞추기 위해 끝부분에 채워 넣는 여분의 값을 패딩이라고 합니다. 만약 서버가 "패딩이 잘못됐다"와 "복호화 결과가 이상하다"를 서로 다른 오류 메시지로 알려준다면, 공격자는 이 미묘한 차이를 반복적으로 살펴보면서 암호문을 한 바이트씩 풀어낼 수 있습니다. 마치 자물쇠 다이얼을 하나씩 돌리며 딸깍 소리가 다른지 확인해 비밀번호를 알아내는 것과 비슷한 원리입니다.
왜 중요한가
암호 알고리즘 자체가 안전하더라도 오류 처리 방식이 부적절하면 정보가 새어나갈 수 있다는 것을 보여주는 대표적 사례이기 때문에, 정보보안학 분야에서는 실제 프로토콜(SSL/TLS, 웹 애플리케이션)에서 발생한 패딩 오라클 취약점 사례를 분석하고 이를 방지하는 설계 원칙을 연구합니다. 2014년 발견된 POODLE 취약점은 이 공격의 대표적 실제 사례로, SSL 3.0을 사실상 퇴출시키는 계기가 되었습니다.
논문에서는 이렇게 쓰입니다
실제로 알려진 취약점 사례를 분석하는 문맥입니다.
타이밍 정보를 이용한 변형된 공격 형태를 다루는 문맥입니다.
조금 더 깊게 보면
이 공격은 주로 CBC(Cipher Block Chaining) 모드와 PKCS#7 패딩 방식을 함께 사용할 때 발생하며, 공격자는 이전 블록의 특정 바이트를 조작한 뒤 서버의 응답(정상/오류, 또는 응답 시간)을 관찰해 원문을 한 바이트씩 복원합니다. 이를 방지하려면 패딩 오류와 인증 오류를 구분되지 않게 처리하거나, GCM과 같이 애초에 패딩이 필요 없는 인증암호(AEAD) 방식을 사용하는 것이 권장됩니다. 복호화 결과의 마지막 바이트가 유효한 패딩 길이 값과 우연히 일치할 확률이 있어, 공격자는 여러 번의 시행착오로 이 우연을 배제하며 원문을 점진적으로 복원합니다.
주의할 점
패딩 오라클 취약점은 암호 알고리즘 자체의 결함이 아니라 구현 및 오류 처리 방식의 문제인 경우가 대부분이므로, 알고리즘 강도만으로는 방어할 수 없다는 점에 유의해야 합니다. 새로운 시스템을 설계할 때는 CBC와 별도 패딩 대신 처음부터 패딩이 필요 없는 인증암호(AEAD)를 채택하는 것이 이런 취약점 자체를 원천적으로 피하는 방법으로 권장됩니다.