OCSP 서비스에 대한 자율 충돌 공격: 설계 결함이 초래하는 인증서 위조 위험

📝 Abstract

The paper describes two important design flaws in Online Certificate Status Protocol (OCSP), a protocol widely used in PKI environments for managing digital certificates’ credibility in real time. The flaws significantly reduce the security capabilities of the protocol, and can be exploited by a malicious third party to generate forged signed certificate statuses and, in the worst scenario, forged certificates. Description of the flaws, along with expected exploitation routes, consequences for consuming application layer protocols, and proposed countermeasures, is given.

💡 Analysis

**

1. 핵심 결함 요약

2. 공격 흐름 – “자율 충돌 공격”(Autonomous Collision Attack)

1. 충돌 목표 설정 – 공격자는 목표 인증서와 동일한 해시값을 갖는 가짜 인증서(또는 시리얼 번호)를 생성한다.
2. OCSP 요청 조작 – 가짜 인증서의 시리얼 번호를 포함해 OCSP 요청을 전송한다.
3. 응답 위조 – OCSP 응답에 포함된 tbsResponseData(서명 전 데이터)와 동일한 해시값을 갖는 가짜 응답을 미리 준비해 두었다가, 서버가 실제 응답을 반환하기 전에 자율적으로(자동으로) 전송한다.
4. 서명 검증 회피 – 응답 서명은 원본 OCSP responder의 인증서로 검증되지만, 해시 충돌로 인해 검증 로직이 다른 인증서에 대한 정상적인 응답으로 오인한다.
5. 위조 인증서 발급 – 최악의 경우, 공격자는 위조된 OCSP 응답을 이용해 인증서 자체를 위조(예: 인증서 서명에 사용된 해시값을 조작)하고, 이를 신뢰 체인에 삽입한다.

핵심 포인트: OCSP 응답 서명은 시리얼 번호와 해시값만을 보호한다. 인증서 전체 내용이 서명에 포함되지 않으므로, 해시 충돌이 발생하면 서명 검증이 무의미해진다.

3. 실제 파급 효과

4. 논문의 기여와 한계

5. 현재 상황과 향후 과제

1. 해시 알고리즘 전환

   • 대부분의 CA가 SHA‑256 이상을 사용하고 있으므로, 충돌 공격 비용이 현저히 증가한다. 그러나 시리얼 번호 자체가 충돌 대상이 될 수 있기 때문에, 단순 해시 교체만으로는 완전한 방어가 되지 않는다.

2. OCSP 응답에 인증서 전체 해시 포함

   • RFC 6960에 “CertificateHash” 확장을 추가하는 방안이 제안되고 있다. 이를 채택하면 시리얼 번호만으로는 위조가 불가능해진다.

3. Nonce 사용 강제 및 검증

   • 현재 대부분의 브라우저와 TLS 라이브러리는 Nonce를 기본 비활성화한다. 표준화 기구와 주요 구현체가 Nonce를 기본값으로 활성화하도록 정책을 바꾸는 것이 시급하다.

4. OCSP Stapling과 CT(증명서 투명성) 결합

   • 서버가 미리 서명된 OCSP 응답을 제공하고, Certificate Transparency 로그와 교차 검증함으로써 위조된 응답을 탐지할 수 있다.

5. 경량 프로파일 재검토

   • 대량 트래픽을 처리하기 위해 사전 계산된 응답을 사용하는 경량 프로파일은 응답 최신성을 보장하지 못한다. 실시간 검증이 필요한 고위험 서비스(은행, 정부 등)에서는 경량 프로파일 사용을 금지하고, 대신 캐시된 응답에 서명된 타임스탬프를 부여하는 방안을 검토해야 한다.

결론

“Autonomous collision attack on OCSP services” 논문은 OCSP 프로토콜이 시리얼 번호와 해시 기반 식별에만 의존한다는 근본적인 설계 결함을 지적함으로써, 인증서 폐기 검증 체계 전체에 대한 심각한 위협을 제시한다. 비록 최신 해시 알고리즘 도입으로 충돌 비용이 상승했지만, Nonce 검증 미비, 경량 프로파일 등 실무 구현상의 허점은 여전히 존재한다.

따라서 실무자는 다음을 즉시 검토·적용해야 한다:

1. Nonce 확장 강제 사용 및 검증
2. OCSP 응답에 인증서 전체 해시(또는 인증서 자체) 포함
3. 경량 프로파일 사용 제한 및 실시간 검증 보장
4. OCSP Stapling + Certificate Transparency 융합

이러한 조치를 통해 현재 PKI 환경에서 OCSP 기반 인증서 검증의 신뢰성을 크게 향상시킬 수 있다.

📄 Content

자율 충돌 공격에 대한 OCSP 서비스

Ken Ivanov
EldoS Corporation
Revision 1.0 (2016년 8월)

초록

본 논문은 실시간으로 디지털 인증서의 신뢰성을 관리하기 위해 PKI 환경에서 널리 사용되는 온라인 인증서 상태 프로토콜(OCSP) 에 존재하는 두 가지 중요한 설계 결함을 기술한다. 이 결함들은 프로토콜의 보안 능력을 크게 저하시키며, 악의적인 제3자가 위조된 서명된 인증서 상태를 생성하거나 최악의 경우 위조된 인증서를 만들 수 있게 한다. 결함의 상세 설명, 예상 악용 경로, 응용 계층 프로토콜에 미치는 영향, 그리고 제안된 방어책을 제시한다.

1. 서론

온라인 인증서 상태 프로토콜(OCSP)[1]은 현대 공개키 기반구조(PKI)에서 인증기관(CA)으로부터 최신 인증서 상태 정보를 얻는 두 가지 일반적인 방법 중 하나이다(다른 하나는 인증서 폐기 목록[2] 기반). 최신 인증서 상태를 얻고자 하는 엔터티—예를 들어 웹 브라우저나 디지털 서명의 유효성을 확인해야 하는 프로그램—는 CA 또는 그와 제휴된 기관이 운영하는 전용 웹 서비스, 즉 OCSP 응답자(Responder) 에 연결하여 해당 인증서의 식별자를 포함한 요청을 전송한다. OCSP 응답자는 요청자에게 인증서 식별자, CA가 유지하는 최신 상태(‘활성’, ‘폐기’, ‘알 수 없음’), 마지막 상태 업데이트 시각, 그리고 다음 업데이트 시점을 포함하는 인증서 상태 레코드를 반환한다. 이 상태 레코드, 즉 OCSP 응답은 OCSP 응답자의 인증서로 디지털 서명되어 CA를 대신해 진위가 검증 가능한 독립적인 PKI 엔터티가 된다.

OCSP 기반 검증 스킴은 특히 고급 전자 서명(CAdES, PAdES, XAdES, ASiC)[3]에서 널리 사용된다. 전형적인 OCSP 사용 시나리오에는 TLS 서버 인증 시와 같이 최신 인증서 상태를 실시간으로 동기식 확인하는 경우와, 장기 전자 서명에 삽입하기 위해 OCSP 인증서 상태 레코드를 획득하는 경우가 포함된다.

2. 용어 정의

읽는 이가 PKI 전문가일 필요는 없지만, X.509 기반 공개키 환경의 기본 원리와 실제 구현에 익숙하면 본 논문에서 다루는 취약점이 환경에 미치는 영향을 이해하기가 수월하다. 특히 인증서, 인증기관(CA), 신뢰의 세계, 인증, 폐기, 디지털 서명과 같은 개념에 대한 사전 지식이 큰 도움이 된다. 아래는 논문에서 사용되는 주요 개념에 대한 정의이며, 논의와 직접적인 관련이 없는 세부 사항은 제외하였다.

3. OCSP: 프로토콜 및 적용 사례

3.1 프로토콜 상세

프로토콜 개요
OCSP는 일반적으로 HTTP(S) 전송 위에서 동작하는 경량 무상태(one‑step) 요청‑응답 프로토콜이다. 인증서가 정당하고 발급자가 폐기하지 않았음을 확인하려는 주체는 해당 OCSP 응답자의 위치를 파악한 뒤, 인증서에 대한 상태 요청을 전송한다. 요청에서는 인증서를 시리얼 번호(같은 CA 내에서 유일)로 식별한다. 시리얼 번호 외에도 CA 인증서에 대한 정보와, 필요에 따라 무작위 논스(Nonce)와 같은 확장 필드를 포함할 수 있다. 일부 OCSP 응답자는 요청자가 서명한 요청을 요구하지만, 이 옵션은 본 논문에서 다루는 취약점에 영향을 주지 않는다.

응답 생성 흐름
응답자는 요청을 받으면 로컬 데이터베이스에서 해당 인증서의 최신 상태를 조회한다. 이후 tbsResponseData(to‑be‑signed response data) 구조에 인증서 식별자, 상태 플래그, 시간 정보(마지막 업데이트, 다음 예상 업데이트, 응답 생성 시각) 등을 결합하고, 자신의 OCSP 인증서로 서명한다.

핵심 포인트는 요청과 응답 모두 인증서를 시리얼 번호만으로 식별한다는 점이다. 즉, 양쪽 모두 인증서 내용에 대한 사전 지식 없이도 유효한 요청·응답을 구성할 수 있다. 이 특성은 뒤에서 설명할 취약점 악용에 중요한 역할을 한다.

아래 그림은 [1]에 정의된 OCSP 요청·응답 포맷을 보여준다. 프로토콜은 ASN.1 형식[4]을 사용하고, 모든 메시지는 DER 인코딩 규칙[5]을 따른다.

Fig. 1. 요청자가 OCSP 응답자에게 전송하는 OCSP 요청 포맷.
Fig. 2. OCSP 응답자가 요청자에게 반환하는 OCSP 응답 포맷.

BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData      SEQUENCE {
        version              [0] EXPLICIT Version DEFAULT v1,
        responderID          ResponderID,
        producedAt           GeneralizedTime,
        responses            SEQUENCE OF SEQUENCE {
            certID           CertID,
            certStatus       CertStatus,
            thisUpdate       GeneralizedTime,
            nextUpdate   [0] EXPLICIT GeneralizedTime OPTIONAL,
            singleExtensions [1] EXPLICIT Extensions OPTIONAL
        },
        responseExtensions [1] EXPLICIT Extensions OPTIONAL
    },
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL
}
OCSPRequest ::= SEQUENCE {
    tbsRequest                  SEQUENCE {
        version                 [0] EXPLICIT Version DEFAULT v1,
        requestorName           [1] EXPLICIT GeneralName OPTIONAL,
        requestList             SEQUENCE OF SEQUENCE {
            reqCert             SEQUENCE {
                hashAlgorithm   AlgorithmIdentifier,
                issuerNameHash  OCTET STRING, -- Issuer DN hash
                issuerKeyHash   OCTET STRING, -- Issuer public key hash
                serialNumber    CertificateSerialNumber
            },
            singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL
        },
        reques

<div style="text-align:center; margin:30px 0;">
  <a href="https://arxiv.org/pdf/1609.03047.pdf" target="_blank" style="padding:12px 25px; background:#007bff; color:white; border-radius:8px; text-decoration:none; font-weight:bold;"> ArXiv 원문 보기</a>
</div>

<p style="font-size:0.8em; color:gray;">이 글은 AI가 자동 번역 및 요약한 내용입니다.</p>