보안 프로토콜 설계 원칙

보안 프로토콜 설계에서는 공격자가 네트워크를 완전히 제어한다고 가정합니다. Dolev-Yao 모델(1983)은 공격자가 전송 중인 모든 메시지를 가로채고, 읽고, 지연시키고, 재생하고, 삭제하고, 변경할 수 있다고 규정합니다. 공격자는 정직한 당사자가 보낸 메시지와 구별할 수 없는 메시지를 생성할 수 있습니다. 공격자는 알고 있는 메시지 구성 요소로 새 메시지를 구성할 수 있습니다. 하지만 공격자는 암호 기본 요소를 깨뜨릴 수는 없습니다(키 없이 복호화하거나 서명을 위조할 수 없음). 중요한 점은 공격자의 계산 능력이 다항 시간으로 제한되지만 모든 통신 채널을 제어한다는 것입니다. 프로토콜 보안이란 이러한 강력한 공격자에 맞서도 인증과 비밀성 목표를 달성하는 것이며, 기반 암호 기본 요소의 계산적 난이도에만 의존합니다.

Abadi와 Needham(1994)은 실용적인 프로토콜 설계의 교훈을 일련의 원칙으로 정리했습니다. (1) 모든 메시지는 자신의 의미를 밝혀야 합니다. 메시지의 해석은 자체적으로 완결되어야 하며 맥락에 의존해서는 안 됩니다. (2) 주체가 행동을 취하기 위한 조건은 프로토콜에 명시적으로 적어야 합니다. (3) 주체의 신원이 중요하다면 메시지에 명시적으로 표시해야 합니다. (4) 암호화를 사용하는 이유를 명확히 해야 합니다. 암호화는 기밀성을 제공하고 서명은 인증을 제공하므로, 서명을 대신하여 암호화를 사용해서는 안 됩니다. (5) 메시지는 비밀성이 필요한 프로토콜 계층에서 암호화해야 합니다. 이러한 원칙은 많은 NS 유형의 결함을 방지했습니다.

재생 공격은 가장 흔한 프로토콜 취약점에 속합니다. 최신성 메커니즘은 수신한 메시지가 오래된 세션에서 재생된 것이 아니라 최근에 생성된 것임을 보장합니다. 두 가지 접근 방식이 있습니다. (1) 논스(한 번만 사용하는 수, ONCE) — 수신자가 임의의 값을 보내고 응답에 그 값이 그대로 포함되기를 기대하는 질의-응답 방식입니다. 응답에는 논스를 암호화하거나 서명한 값이 포함되어야 하므로, 예전 기록만으로는 질의를 충족할 수 없습니다. (2) 타임스탬프 — 양쪽 당사자가 현재 시간을 포함하며, 오래된 타임스탬프가 있는 메시지는 거부합니다. 타임스탬프를 사용하려면 시계를 동기화해야 합니다(Kerberos에서는 5분의 시간 차이를 허용합니다). 시계 동기화를 사용할 수 없을 때는 논스를 선호하고, 상태를 저장하지 않는 검증에는 타임스탬프가 더 간단합니다.

하나의 암호 키를 여러 용도로 사용하면 위험한 상호작용이 발생합니다. 키 K를 암호화와 인증에 모두 사용하면 공격자가 조작한 암호문을 인증 메커니즘에 입력하여 정보를 추출할 수 있습니다. TLS 1.3은 파생되는 각 키에 서로 다른 레이블을 사용하는 HKDF-Expand-Label을 통해 이를 엄격하게 방지합니다. 예를 들어 "c hs traffic"(클라이언트 핸드셰이크), "s hs traffic"(서버 핸드셰이크), "c ap traffic"(클라이언트 애플리케이션)에 서로 다른 레이블을 사용합니다. 핸드셰이크 키가 손상되더라도 다른 HKDF 분기에서 파생된 애플리케이션 키는 안전하게 유지됩니다. 프로토콜 설계에서는 모든 키를 대상으로 여러 용도 사용 위험을 점검하고, 용도별로 별도의 키를 파생해야 합니다.

인증 자격 증명은 사용되는 특정 세션에 바인딩되어야 합니다. 바인딩이 없으면 한 세션에서 얻은 자격 증명을 다른 세션에 재생할 수 있습니다. 기법은 다음과 같습니다. (1) 서명되거나 MAC이 적용된 데이터에 세션 식별자를 포함합니다. (2) 서명에 DH 트랜스크립트를 포함합니다(STS 방식). (3) HKDF로 파생한 세션 키를 사용하여 신원에 대한 MAC을 생성합니다(SIGMA 방식). TLS 1.3의 완료 메시지: MAC(server_finished_key, transcript_hash) — MAC이 전체 트랜스크립트를 포함하므로 다른 세션의 완료 메시지를 재생하면 실패합니다. 이러한 바인딩이 초기 Kerberos 및 NS 변형에서 발견된 세션 간 공격을 방지합니다.

프로토콜은 기능에 필요한 최소한의 정보만 공개해야 합니다. 신원은 필요한 사람에게만 공개합니다. 필요하지 않다면 세션을 신원에 연결할 수 있는 인증서 일련 번호나 식별자를 포함하지 마십시오. TLS 1.3은 서버 인증서를 암호화하므로(평문인 TLS 1.2와 달리) 수동 도청자가 수집할 수 있는 정보를 줄입니다. ESNI(암호화된 SNI, 현재는 ECH — 암호화된 ClientHello)는 서버 이름 표시를 암호화하여 클라이언트가 어느 서버에 연결하는지 숨깁니다. 최소 정보 공개는 토큰 설계의 원칙이기도 합니다. JWT 클레임에는 전체 신원 기록이 아니라 권한 부여에 필요한 정보만 포함해야 합니다.

버전 협상은 일반적인 공격 표면입니다. 공격자가 ClientHello를 삭제하거나 수정하여 양쪽 당사자가 더 오래되고 취약한 프로토콜 버전을 사용하도록 강제할 수 있습니다. 방어 방법은 다음과 같습니다. (1) 인증된 버전 협상 — 협상된 버전을 서명된 트랜스크립트에 포함합니다(TLS 완료 메시지는 버전을 포함한 ClientHello를 인증합니다). (2) 다운그레이드 탐지 표식 — TLS 1.3은 TLS 1.2로 다운그레이드할 때 ServerHello.Random에 특정 매직 바이트를 설정하여 클라이언트가 다운그레이드를 감지할 수 있게 합니다. (3) 버전 비호환 방지 — 서버는 잘못 구성된 ClientHellos를 조용히 대체하지 말고 거부해야 합니다. (4) SCSV — TLS_FALLBACK_SCSV는 클라이언트가 더 낮은 버전으로 재시도하고 있음을 서버에 알리므로, 서버가 부적절한 대체를 거부할 수 있습니다.

프로토콜 메시지는 첫 번째 교환부터 커밋되어야 합니다. 비가변성이란 공격자가 암호문이나 서명을 수정한 뒤 다른 문맥에서 유효한 것으로 검증되게 만들 수 없다는 뜻입니다. AEAD는 암호문의 비가변성을 제공합니다. 암호문을 조금이라도 수정하면 인증 태그가 무효화됩니다. 프로토콜 수준의 비가변성을 위해 트랜스크립트 해싱은 핸드셰이크 마지막의 완료 메시지 교환이 전송된 모든 메시지에 커밋되도록 합니다. 따라서 잘라 붙이기 공격을 방지할 수 있습니다. 서로 다른 두 세션의 메시지를 이어 붙여서는 어느 세션에도 유효한 완료 값을 만들 수 없습니다. 커밋먼트 방식(해시 커밋먼트)은 공개 전에 사전 커밋이 필요한 프로토콜 흐름으로 이 개념을 확장합니다.

복잡한 프로토콜은 상태 머신의 경계에서 자주 실패합니다. 상태 전이가 모호하면, 예를 들어 메시지 3이 메시지 2보다 먼저 도착할 때 어떻게 처리할지 또는 예상하지 못한 메시지 유형이 도착할 때 어떻게 처리할지 정해져 있지 않으면 구현마다 동작이 달라져 공격자가 악용할 수 있는 불일치가 발생합니다. 프로토콜 명세는 완전한 상태 머신(모든 상태와 유효한 전이), 예상하지 못한 입력에 대한 동작(특정 오류와 함께 거부할지 또는 조용히 무시할지), 시간 초과와 재전송 한도, 세션 정리를 정의해야 합니다. SSL/TLS는 역사적으로 상태 머신의 구현 차이로 어려움을 겪었습니다. CVE-2014-0160(Heartbleed)은 본질적으로 상태 머신의 실패 사례로, 메모리 사용량이 적절히 제한되지 않은 상태에서 하트비트 요청이 처리되었습니다.

암호 프로토콜은 단독으로 사용되는 경우가 드뭅니다. AKE 프로토콜이 세션 키를 설정하면 애플리케이션 계층 프로토콜이 그 키를 사용합니다. AKE와 애플리케이션 프로토콜을 합성 가능성을 고려하지 않고 독립적으로 설계하면 상호 작용으로 인해 보안이 깨질 수 있습니다. 보편적 합성 가능성(UC) 프레임워크(Canetti, 2001)는 프로토콜 합성을 위한 엄밀한 모델을 제공합니다. 프로토콜이 다른 UC 보안 프로토콜과 임의로 합성된 후에도 안전하다면 UC 보안 프로토콜이라고 합니다. TLS 1.3, Signal, Noise는 합성 가능한 보안을 목표로 합니다. 실무적으로는 채널 바인딩(트랜스크립트 해시 내보내기)을 사용하여 AKE 세션을 이후 애플리케이션 인증에 연결하고, 동일한 AKE 프로토콜로 설정된 세션 사이에서 자격 증명이 전달되는 것을 방지해야 합니다.

프로토콜 설계자는 반복해서 같은 유형의 실수를 저지릅니다. (1) 직접 만든 암호 — 동료 검토 없이 맞춤형 블록 암호, MAC 또는 키 파생을 구현합니다. (2) 암묵적 신뢰 — 암호학적 증명 대신 네트워크 문맥을 바탕으로 메시지의 출처를 신뢰한다고 가정합니다. (3) 선택적 보안 — 암호화나 인증을 설정 가능하게 만들어 결국 다운그레이드로 이어집니다. (4) 폐기 기능이 없는 장기 토큰 — 긴 유효 기간과 폐기 메커니즘이 없는 JWT 또는 세션 키를 발급합니다. (5) 오류 채널 무시 — 오류 메시지를 인증하지 않으면 공격자가 오류를 주입하여 프로토콜 동작에 영향을 줄 수 있습니다. (6) 인증에 암호화 사용 — MAC이나 서명 없이는 데이터를 암호화해도 그 출처를 인증할 수 없습니다.

Abadi-Needham 원칙에 따르면, 신원이 중요한 경우 메시지에 발신자의 신원을 명시적으로 포함해야 하는 이유는 무엇입니까?

안전한 프로토콜 설계에는 확립된 원칙이 적용됩니다. Dolev-Yao 공격자 모델(네트워크를 제어하는 공격자), Abadi-Needham 원칙(명시적 신원과 자체 완결형 메시지), 논스 또는 타임스탬프를 통한 신선성, 서로 다른 레이블을 사용하는 HKDF를 통한 키 분리, 인증 자격 증명의 세션 바인딩, 최소 정보 공개, 트랜스크립트 인증을 통한 다운그레이드 방지, AEAD와 트랜스크립트 해싱을 통한 비가변성, 오류 처리가 정의된 명확한 상태 머신, UC 모델 보안 증명을 통한 합성 가능성이 이에 해당합니다. 이러한 원칙을 위반하면 알려진 거의 모든 프로토콜 수준의 암호학적 취약점이 발생합니다.