본문으로 건너뛰기
J
피드

양자 컴퓨팅 시대의 HTTPS 인증서

security 약 5분
tags
#quantum#tls#cryptography#ietf#pki
vote
0
댓글
북마크

IETF PLANTS 워킹그룹이 포스트-양자 시대를 대비해 CA 서명 체인을 머클 트리 기반 발급 로그로 대체하는 새로운 인증서 체계를 제안함. ML-DSA-44 서명이 Ed25519 대비 37배 크지만, 머클 증명은 384바이트로 축소 가능함.

  • 1

    ML-DSA-44 서명은 Ed25519 대비 37배 크기로 현재 인증서 체인(3.5KB)의 단순 전환이 불가능함

  • 2

    PLANTS는 CA의 append-only 발급 로그 + 제3자 옵저버 검증 구조를 제안하며 full(133KB)과 signatureless(384B) 두 가지 인증서 타입을 도입함

  • 3

    Google이 2027년 말까지 Chrome에서 실험적 시스템을 배포하고 실제 도입은 2029~2030년 예상

양자 컴퓨팅 시대에 대비한 HTTPS 인증서 체계의 근본적 재설계가 IETF에서 논의되고 있음. 핵심은 포스트-양자 서명의 거대한 크기 문제를 머클 트리로 우회하는 접근법임.

문제: 포스트-양자 서명의 크기 폭발

  • 현재 인증서 체인은 약 3.5KB로, LWN 프론트페이지 HTML(압축 후)의 약 1/3 수준임
  • ML-DSA-44(포스트-양자 서명)는 Ed25519 대비 37배 더 큰 서명을 생성함
  • 단순 전환 시 인증서가 웹사이트 콘텐츠보다 더 큰 대역폭을 차지하게 됨
  • 다만 인증 키는 "지금 저장, 나중에 복호화" 공격에 취약하지 않아 키 교환보다 긴급도는 낮음

PLANTS 워킹그룹의 핵심 아이디어

  • PLANTS(PKI, Logs, and Tree Signatures) 워킹그룹이 CA 서명과 투명성 로그의 관계를 역전시키는 방식을 제안함
graph TD
    subgraph "현재 방식"
        A1[CA가 인증서 생성] --> A2[투명성 로그에 기록]
        A2 --> A3[로그 서명을 인증서에 포함]
        A3 --> A4[클라이언트에 서명 체인 전송]
    end

    subgraph "PLANTS 제안"
        B1[CA가 append-only 발급 로그 유지] --> B2[제3자 옵저버가 로그 검증/서명]
        B2 --> B3{클라이언트 상태}
        B3 -->|첫 방문| B4["Full 인증서 ~133KB
CA + 옵저버 서명 포함"]
        B3 -->|체크포인트 보유| B5["Signatureless 인증서
머클 증명만 ~384B"]
    end
  • CA가 자체 append-only 발급 로그를 유지하고, 기존 투명성 로그 운영 조직들이 이를 모니터링/미러링함
  • 브라우저는 신뢰할 옵저버와 쿼럼 기준을 자체적으로 설정 가능함

두 가지 인증서 타입

  • Full 인증서: CA와 옵저버 서명 + 머클 증명 포함, ML-DSA-44 기준 약 133KB
  • Signatureless 인증서: 머클 증명만 포함, 브라우저가 이미 해당 CA의 체크포인트를 검증한 경우 사용 가능

머클 트리의 효율성

  • 머클 트리 증명은 트리 크기에 대해 로그 스케일로 성장함
  • 해시 기반이라 양자 공격에 취약하지 않아 포스트-양자 전환 시에도 크기가 변하지 않음
  • Let's Encrypt 기준 하루 약 600만 건 인증서 발급 → 1분 간격 체크포인트 시 인증서당 해시 12개(SHA-256 기준 384바이트) 필요
  • 이는 ML-DSA-44 서명 1개 크기의 16%에 불과함

폐기(Revocation) 처리

  • 만료된 인증서는 리프 노드 삭제로 자연스럽게 정리됨 (append-only 속성과 모순되지 않음)
  • 오발급 인증서는 별도 폐기 세트로 관리되며, 체크포인트 서명에 포함됨
  • 브라우저가 full 인증서를 검증할 때마다 최신 폐기 목록도 함께 수신함

도입 타임라인

  • Google이 Chrome에서 머클 트리 기반 인증서의 성능 영향을 평가할 계획임
  • 2027년 말까지 PLANTS 초안 기반의 실험적 포스트-양자 CA 시스템 배포 목표
  • 실제 CA/서버 운영자/사용자 업데이트는 2029~2030년 예상

❗중요

> 프로토콜의 실질적 효용은 브라우저가 같은 CA의 여러 사이트를 방문하며 체크포인트를 충분히 최신 상태로 유지하느냐에 달려 있음. Google이 Chrome 데이터로 이를 실증할 예정이나, 비-Chrome 브라우저 사용자는 당분간 측정 대상에서 제외됨.

포스트-양자 서명의 크기 문제를 해결하기 위해 서명 자체를 줄이는 게 아니라, 서명이 필요 없는 구조로 전환하는 역발상이 핵심임. 이 접근법은 양자 내성 없이도 기존 인증서 효율 개선에 활용 가능함.

prev

이전 기사 (P)

댓글

댓글

댓글을 불러오는 중...

관련 기사

security

AI 에이전트 보안, 이제 권한이 아니라 ‘실행 증거’ 싸움으로 간다

오페이크가 AI 에이전트의 ID, 실행 환경, 도구 호출, 정책 적용 여부를 암호학적으로 검증하는 오페이크 3.0을 공개했다. 핵심은 에이전트 매니페스트와 컨피덴셜 MCP라는 두 오픈소스 기술이며, 기밀 컴퓨팅과 서명된 실행 증거를 결합해 감사자나 규제기관도 독립적으로 확인할 수 있게 하는 방향이다. AI 에이전트가 업무 시스템과 데이터를 직접 만지는 시대에는 접근 권한보다 ‘무슨 일을 했는지 증명할 수 있느냐’가 더 중요해지고 있다.

security

취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

security

스패로우, AI가 만든 코드 취약점 잡는 ‘Sparrow MCP’ 출시

스패로우가 AI 코딩 에이전트가 생성한 코드의 보안 취약점과 사용된 오픈소스를 실시간으로 검사하는 보안 어시스턴트 ‘Sparrow MCP’를 출시했다. 핵심 기능은 취약점 분석과 소프트웨어 자재명세서(SBOM) 생성이며, 앤트로픽의 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI와 연결할 수 있다는 점이다. AI 코딩이 빨라질수록 보안 검증과 오픈소스 추적이 개발 파이프라인 안으로 더 깊게 들어오는 흐름이다.

security

오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

오픈AI가 트레일 오브 비츠와 함께 주요 오픈소스 프로젝트의 취약점을 AI로 찾고, 사람 검토를 거쳐 실제 패치까지 연결하는 프로그램을 시작했다. 파이썬, 고, cURL, 시그스토어, NATS 서버 같은 핵심 프로젝트가 초기 대상이고, 지금까지 수백 건의 보안 이슈와 수십 건의 병합된 패치가 나왔다. 핵심은 AI가 보안팀을 대체하는 게 아니라, 탐지·검증·패치·공개 조율을 빠르게 만드는 보조 엔진이라는 점이다.

security

오픈AI, 취약점 찾기부터 패치까지 돕는 ‘코덱스 시큐리티’ 공개

오픈AI가 사이버보안 이니셔티브 데이브레이크를 확대하면서 보안 전용 도구 코덱스 시큐리티와 GPT-5.5-사이버를 공개했다. 목표는 취약점 탐지에서 끝나는 게 아니라 검증, 위험도 평가, 패치 개발, 테스트, 배포까지 AI로 지원하는 것이다. cURL, Go, Python, Sigstore 등 30개 이상 오픈소스 프로젝트도 패치 지원 프로그램에 참여한다.