cloudflare2026년 7월 27일

프라이버시 프록시 CLI를 오픈 소스로 공개합니다 (새 탭에서 열림)

Oblivious HTTP(OHTTP)는 여러 주체와 바이너리 인코딩을 거치기 때문에 장애 원인을 추적하기 어렵다. Cloudflare는 실제 운영 경험을 바탕으로 전체 OHTTP 요청 과정을 한 번에 실행하고 각 단계를 확인할 수 있는 오픈소스 CLI 도구 `pvcli(privacy-client)`를 만들었다. 이 도구는 복잡한 수작업과 일회성 스크립트를 줄여 개발·테스트·장애 대응을 단순화한다. ### OHTTP가 제공하는 프라이버시 구조 - OHTTP는 요청을 보낸 사람과 요청 내용을 한 주체가 동시에 알 수 없도록 설계된다. - 서로 충돌하지 않는 두 운영 주체가 필요하다. - **Relay**: 클라이언트의 신원을 gateway에 전달하지 않음 - **Gateway**: 요청을 복호화해 실제 대상 서버로 전달 - 일반적인 요청 흐름은 다음과 같다. - 클라이언트가 gateway의 공개 키를 가져온다. - 클라이언트가 HTTP 요청을 암호화해 relay로 보낸다. - relay가 클라이언트 식별 정보를 제거하고 gateway로 전달한다. - gateway가 요청을 복호화해 target 서버에 전송한다. - target의 응답을 gateway가 다시 암호화한다. - relay가 암호화된 응답을 클라이언트에 전달한다. - 클라이언트가 응답을 복호화한다. - 각 단계가 별도의 장애 지점이므로, 문제가 relay·gateway·target 중 어디에서 발생했는지 확인하기 어렵다. ### 기존 디버깅 방식의 문제 - 고객 환경에서 실제 end-to-end 테스트를 수행하려면 배포별 맞춤 클라이언트를 일회성으로 작성해야 했다. - 장애 발생 시 자체 시스템의 문제인지 고객 시스템의 문제인지 판별하는 데 시간이 많이 걸렸다. - OHTTP는 바이너리 HTTP를 사용하므로 원시 바이트를 직접 분석해야 했다. - 공개 키, 바이너리 HTTP 요청, 암호화된 OHTTP 메시지를 RFC에 따라 수작업으로 해석해야 했다. - 사람이 긴 hexadecimal 문자열을 직접 검증하는 과정은 번거롭고 실수하기 쉽다. ### 공개 키와 바이너리 HTTP의 수동 분석 - gateway에서 받은 공개 키 설정은 긴 hexadecimal 데이터로 반환된다. - RFC 9458에 따라 다음 필드를 직접 해석해야 한다. - `0029`: 공개 키 항목의 길이 - `55`: 공개 키 ID - `0020`: DHKEM(X25519, HKDF-SHA256) 비대칭 암호 방식 - 뒤따르는 32바이트: 실제 공개 키 - `0004`: 대칭 암호 방식 ID 영역의 길이 - `0001`, `0001`: HKDF-SHA256 및 AES-128-GCM 식별자 - 원래의 HTTP 요청도 RFC 9292의 바이너리 HTTP 형식으로 변환해야 한다. - 예를 들어 `POST`, `https`, 호스트명, 경로, 헤더와 본문이 각각 바이너리 필드로 인코딩된다. - 이후 공개 키를 이용해 바이너리 HTTP 요청을 OHTTP 형식으로 암호화하고, 키 ID와 암호 방식 ID를 포함한 헤더를 붙여 relay에 보낼 wrapper HTTP 요청을 만들어야 한다. ### `pvcli`의 역할 - Cloudflare는 이러한 프라이버시 프로토콜 관련 기능을 하나의 CLI에 통합했다. - 익숙한 HTTP 클라이언트 인터페이스를 제공하면서 OHTTP의 각 처리 단계를 순서대로 표시한다. - relay, gateway, origin으로 이어지는 전체 요청을 단일 명령으로 실행할 수 있다. - 예시 명령은 다음 작업을 수행한다. - `--first-hop`: relay 지정 - `--proxy`: gateway 지정 - `-X POST`: HTTP 메서드 지정 - `--header`: 요청 헤더 지정 - `--data`: JSON 요청 본문 지정 - 대상 URL: gateway가 요청을 전달할 origin - 따라서 사용자는 공개 키 조회, 바이너리 HTTP 변환, OHTTP 암호화, relay 전달, 응답 복호화 과정을 각각 수동으로 구현할 필요가 없다. ### 공개와 활용 - 도구 이름은 `privacy-client`, 실행 파일은 `pvcli`다. - Apache-2.0 라이선스로 공개되며 외부 기여를 허용한다. - 새로운 프라이버시 프로토콜이나 다양한 네트워크 아키텍처를 지원할 수 있도록 확장성을 고려했다. - 운영 환경과 유사한 end-to-end 테스트 및 장애 재현에 활용할 수 있다. 복잡한 OHTTP 시스템을 운영하거나 연동한다면, 원시 바이트와 RFC를 직접 해석하는 방식보다 `pvcli`로 전체 경로를 재현하는 것이 효율적이다. 특히 relay·gateway·origin 중 장애 위치를 빠르게 좁혀야 하는 개발 및 incident response 상황에서 유용하다.

cryptographyclioblivious-httpbinary-http+3

cloudflare2026년 6월 23일

포스트양자 시대의 EO는 중요한 이정표다. 이제 실행에 옮길 때다 (새 탭에서 열림)

미국의 행정명령 14409호는 연방기관이 2030년까지 고위험 시스템의 암호화를, 2031년까지 디지털 서명과 인증을 양자내성암호(PQC)로 전환하도록 요구한다. 이는 양자컴퓨터가 현재의 RSA와 타원곡선 암호를 무력화할 가능성에 대비한 중요한 이정표이며, 특히 이미 진행 중인 암호화 전환과 달리 인증 전환은 지금부터 서둘러야 한다. 글은 각 기관이 자산을 조사하고 단계적인 전환 계획을 세우되, 민간과 중요 인프라도 같은 준비를 시작해야 한다고 주장한다. ## 행정명령 14409호의 주요 요구사항 - 2026년 6월 22일 트럼프 대통령이 「첨단 암호 공격으로부터 국가 보호」 행정명령에 서명했다. - 대상은 주로 다음 두 종류의 연방 시스템이다. - **고가치 자산(HVA)**: 국가안보, 외교, 국민 신뢰에 중대한 영향을 주는 핵심 시스템 - **고영향 시스템**: FIPS 199 기준으로 기밀성·무결성·가용성의 영향도가 ‘높음’인 시스템 - 주요 일정은 다음과 같다. - **2026년 7월**: 각 기관이 PQC 전환 책임자를 지정 - **2026년 9월**: OMB가 자산 목록 검토, 전환 계획 수립 및 제출을 요구 - **2030년 12월**: HVA와 고영향 시스템의 키 설정을 PQC로 전환 - **2031년 12월**: 디지털 서명과 인증서를 PQC로 전환 - 국가안보시스템(NSS)은 행정명령의 일정에서 제외되며, NSA가 관리하는 별도 기밀 전환 일정이 적용된다. - 행정명령의 직접적인 법적 적용 대상은 연방기관이며, 주·지방정부, 중요 인프라, 학계, 시민사회에는 직접 의무를 부과하지 않는다. ## 양자컴퓨터가 만드는 시급성 - 양자컴퓨터가 충분히 발전하면 현재 인터넷에서 널리 쓰이는 **RSA와 타원곡선암호(ECC)**를 깨뜨릴 수 있다. - NIST는 2024년 기존 공개키 암호를 2030년까지 단계적으로 폐기하고 2035년까지 사용을 금지하는 방향을 제시했다. - 최근 연구 발전으로 ‘Q-Day’, 즉 암호학적으로 유의미한 양자컴퓨터가 등장하는 시점이 앞당겨질 가능성이 커졌다. - 미국 정부가 양자컴퓨팅 개발을 촉진하는 동시에 2031년까지 PQC 인증을 요구한 것은, 그 무렵 실용적인 양자컴퓨터가 등장할 가능성을 무시할 수 없다고 판단했음을 시사한다. ## 암호화와 인증은 서로 다른 전환이다 ### 포스트양자 암호화 - 양자컴퓨터에 안전한 키 설정과 암호화를 사용해 통신 내용을 보호한다. - 현재 가장 중요한 위협은 **‘지금 수집하고 나중에 복호화’** 공격이다. - 공격자가 오늘 암호화된 데이터를 저장해 두었다가, 미래에 양자컴퓨터로 복호화할 수 있다. - 다음과 같이 장기간 가치가 유지되는 데이터를 보유한 조직은 즉시 전환을 시작해야 한다. - 정부기관 - 은행 및 금융기관 - 의료기관 - 방위산업체 - 통신사업자 - 인터넷 전반에서 이미 전환이 진행 중이며, Cloudflare는 브라우저 트래픽의 3분의 2 이상에 PQC 암호화를 적용하고 있다고 설명한다. ### 포스트양자 인증 - 양자컴퓨터를 이용한 다음과 같은 위조 공격을 막는다. - 서버 인증서 위조 및 서버 사칭 - 악성 코드 서명 생성 - 시스템에 대한 무단 접근 - 암호화와 달리, 인증 공격은 실제로 강력한 양자컴퓨터가 등장해야 본격적으로 가능하다. - 그러나 인증 전환은 더 복잡하고 시간이 오래 걸리므로 Q-Day 이후가 아니라 지금부터 준비해야 한다. - ML-DSA 같은 PQC 디지털 서명은 기존 서명보다 크기가 커서 짧은 TLS 연결의 성능과 네트워크 비용에 영향을 줄 수 있다. - 인증 전환에는 다음 구성요소의 동시 업그레이드가 필요하다. - 클라이언트와 서버 - 인증기관(CA) - 인증서 투명성 로그 - 루트 저장소 - 웹 브라우저 - Cloudflare는 Google Chrome과 함께 Merkle Tree Certificates를 연구해 대형 PQC 서명이 TLS 성능에 미치는 영향을 줄이려 하고 있다. ## 표준화된 PQC와 QKD의 차이 - 행정명령이 NIST가 표준화한 PQC 알고리즘에 초점을 맞춘 점은 타당하다고 평가한다. - 양자키분배(QKD)는 다음 이유로 인터넷 전체에 적용하기 어렵다. - 특수 하드웨어가 필요하다. - 송신자와 수신자 사이에 전용 물리 링크가 필요하다. - 기존 인터넷 규모로 확장하기 어렵다. - 따라서 범용 인터넷과 연방 시스템의 현실적인 경로는 표준화된 PQC 알고리즘을 기존 암호 체계에 통합하는 것이다. ## Cloudflare가 제시하는 전환 현황 - Cloudflare는 2029년까지 암호화와 인증을 포함한 완전한 포스트양자 보안을 달성하는 것을 목표로 한다. - 대부분의 제품이 PQC 키 합의를 지원하며, Cloudflare One은 다음 연결 경로에 PQC 암호화를 제공한다. - TLS - MASQUE - IPsec - 암호화 전환은 이미 상당히 진행됐지만, 포스트양자 인증 배포는 아직 초기 단계다. - 글은 이번 행정명령이 이전 행정부와 민간 부문이 진행해 온 작업을 확대하는 기반이라고 평가한다. ## 실용적인 권고 - 조직은 먼저 공개키 암호가 사용되는 자산과 데이터를 목록화해야 한다. - 장기 보존 가치가 있는 데이터는 ‘수집 후 복호화’ 공격을 고려해 PQC 암호화를 우선 적용해야 한다. - 인증 전환은 인증서, 브라우저, 서버, CA 등 의존성을 함께 점검하고 장기 마이그레이션 계획을 세워야 한다. - 연방기관뿐 아니라 금융·의료·통신·방위 분야 조직도 2030~2031년 일정을 외부 기준으로 삼아 지금부터 테스트와 단계적 도입을 시작하는 것이 바람직하다.

cryptographypost-quantum-cryptographyquantum-computingelliptic-curve-cryptography+3

discord2026년 3월 27일

다단계 인증으로 디스코드 계정을 안전하게 보호하는 방법 (새 탭에서 열림)

Discord 계정 보안을 강화하려면 비밀번호만 사용하는 대신 다중 인증(MFA)을 활성화해야 한다는 글이다. 가장 권장되는 방식은 패스키이며, 패스키를 사용할 수 없다면 인증 앱을 대안으로 제시한다. 로그인 인증 이메일도 기본 보안 수단이지만, MFA를 활성화하면 해당 이메일 인증은 비활성화된다. ## 로그인 인증 이메일 - 이메일 주소를 인증한 Discord 계정은 새로운 기기나 위치에서 로그인할 때 확인 이메일을 받는다. - 이메일의 **“Verify Login”** 버튼을 눌러야 로그인이 완료된다. - 단, 이메일 계정과 Discord 계정에 같은 비밀번호를 사용하면 이메일이 탈취될 경우 보안 효과가 크게 떨어진다. - 모든 서비스에서 서로 다른 비밀번호를 사용해야 한다. ## 다중 인증(MFA)의 개념 - 비밀번호만 사용하는 로그인은 하나의 보안 장벽에만 의존하는 방식이다. - MFA는 비밀번호 외에 하나 이상의 인증 요소를 추가해 계정 탈취를 어렵게 만든다. - 인증 요소는 다음 세 가지로 나뉜다. - **알고 있는 것**: 비밀번호나 비밀 문구 - **가지고 있는 것**: 스마트폰, 컴퓨터, 보안 키 등 - **본인 자체**: 지문이나 얼굴 인식 같은 생체 정보 - 비밀번호는 유출·추측·재사용 공격에 노출될 수 있으므로 MFA 사용이 강력히 권장된다. - MFA를 활성화하면 로그인 인증 이메일 기능은 비활성화된다. ## 가장 권장되는 방식: 패스키 - 패스키는 피싱에 강하고 추측하기 어려운 최신 인증 방식이다. - 사용자의 기기와 Discord 사이에서 암호학적 인증을 수행하며, 기기의 지문·얼굴 인식·PIN으로 잠금을 해제한다. - 생체 정보 자체가 Discord로 전송되는 것이 아니라, 로그인 승인을 위한 암호화 키만 사용된다. - 기기에 연결된 인증 수단이므로 **“가지고 있는 것”**에 해당하며, 생체 인증을 사용하면 **“본인 자체”** 요소도 추가된다. - 계정 하나에 최대 16개의 패스키를 등록할 수 있다. - Android·iOS·웹 브라우저·하드웨어 보안 키·비밀번호 관리자 등에 여러 패스키를 등록할 수 있다. - 1Password나 Bitwarden 같은 자격 증명 관리자에 예비 패스키를 보관하는 것이 권장된다. ## 인증 앱과 일회용 코드 - 인증 앱은 시간 기반 일회용 비밀번호(TOTP)를 생성한다. - Discord와 인증 앱이 공유한 초기 값을 바탕으로 약 30초마다 새로운 PIN을 만든다. - Discord에서도 같은 코드를 생성해 일치 여부를 확인한다. - 이전 코드도 함께 확인하므로 실제 로그인에는 약 1분의 여유가 있다. - Authy, Microsoft Authenticator, Google Authenticator 등을 사용할 수 있다. - 인증 앱을 설정한 뒤에는 반드시 백업 코드를 저장해야 한다. - 인증 앱이나 기기를 잃어버렸을 때 백업 코드로 로그인할 수 있다. - 백업 코드는 비밀번호 관리자처럼 안전하고 잃어버리지 않을 장소에 보관해야 한다. - 백업 코드가 유출되거나 분실되었다면 **My Account > View Backup Codes > Generate New Backup Codes**에서 새로 생성할 수 있다. ## 계정 보안을 위한 권장 사항 - 가능한 경우 패스키를 하나 이상 등록한다. - 패스키를 사용할 수 없다면 인증 앱 기반 MFA를 활성화한다. - 모든 온라인 계정에 고유한 비밀번호를 사용한다. - 인증 앱을 사용할 경우 백업 코드를 미리 안전하게 보관한다. - 계정 복구 수단은 주 기기와 별도의 안전한 장소에도 준비해 두는 것이 좋다.

cryptographymulti-factor-authenticationpasskeysbiometrics+4

cloudflare2026년 2월 27일

양자 내성 암호 사용 (새 탭에서 열림)

Cloudflare는 인터넷 보안의 투명성을 높이기 위해 Radar 플랫폼에 양자 내성 암호(PQ), 메시징 시스템의 키 투명성(Key Transparency), 그리고 라우팅 보안(ASPA)과 관련된 새로운 데이터셋과 도구를 대거 도입했습니다. 이번 업데이트는 클라이언트 측에 국한되었던 보안 모니터링을 오리진 서버와 메시징 인프라까지 확장하여, 다가오는 양자 컴퓨팅 시대와 고도화되는 네트워크 공격에 대비한 가시성을 제공하는 것을 핵심으로 합니다. **오리진 서버의 양자 내성 암호(PQ) 지원 모니터링** * **지원 범위 확장:** 기존 클라이언트 측 PQ 지원 모니터링을 넘어, Cloudflare 에지 서버와 고객의 오리진 서버 간 연결에 대한 PQ 호환성 데이터를 Radar에 추가했습니다. * **하이브리드 알고리즘 추적:** 고전적 방식인 X25519와 격자 기반 PQ 방식인 ML-KEM을 결합한 'X25519MLKEM768' 알고리즘의 채택 현황을 중점적으로 추적합니다. * **성장 지표:** 오리진 서버의 PQ 지원율은 2025년 초 1% 미만에서 2026년 2월 기준 10%로 약 10배 급증했으며, 이는 OpenSSL, Go 등 주요 암호화 라이브러리의 기본 설정 변경이 주도하고 있습니다. * **실시간 테스트 도구:** Cloudflare Containers를 활용하여 특정 호스트네임의 PQ 지원 여부를 즉시 확인할 수 있는 도구를 출시했으며, 이는 실제 TLS 핸드셰이크를 수행하여 협상된 알고리즘을 보여줍니다. **종단간 암호화(E2EE) 메시징을 위한 키 투명성** * **신뢰 문제 해결:** WhatsApp이나 Signal 같은 서비스에서 사용자가 서비스 제공자의 공공 키 배포를 무조건 신뢰해야 했던 취약점을 보완하기 위해 '키 투명성(Key Transparency)' 섹션을 신설했습니다. * **공개 감사 대시보드:** Cloudflare가 독립적인 감사자(Auditor)로서 WhatsApp 등의 메시징 서비스가 제공하는 공공 키 로그의 무결성을 실시간으로 검증하고 그 결과를 공개합니다. * **조작 방지:** 공격자가 공공 키를 가로채거나 교체하는 중간자 공격(MITM)을 방지할 수 있도록, 누구나 API를 통해 감사 증명을 독립적으로 검증할 수 있는 인터페이스를 제공합니다. **라우팅 보안 및 ASPA 배포 현황** * **BGP 경로 누출 방지:** 인터넷 라우팅의 고질적인 문제인 BGP 경로 누출을 탐지하고 방지하기 위한 새로운 표준인 ASPA(Autonomous System Provider Authorization) 관련 정보를 제공합니다. * **다각적 분석:** 글로벌 수준은 물론 국가 및 개별 네트워크(AS) 단위에서 ASPA가 얼마나 도입되었는지에 대한 상세한 인사이트를 확인할 수 있습니다. **결론 및 권장 사항** 인프라 운영자는 Cloudflare Radar의 새로운 PQ 테스트 도구를 활용해 자사 오리진 서버의 양자 내성 암호 준비 상태를 점검해야 합니다. 특히 최신 보안 표준을 유지하기 위해 OpenSSL 3.5.0+, Go 1.24+ 등 하이브리드 PQ를 기본으로 지원하는 최신 암호화 라이브러리로의 업데이트를 적극 권장합니다.

cryptographynetwork-securitypost-quantum-cryptographyend-to-end-encryption+4

meta2025년 11월 20일

메신저에 도입되는 키 투 (새 탭에서 열림)

메타(Meta)는 메신저의 종단간 암호화(E2EE) 보안을 한 단계 강화하기 위해 '키 투명성(Key Transparency)' 시스템을 도입했습니다. 이 시스템은 사용자가 대화 상대의 공개 키가 변조되지 않았음을 자동으로 검증할 수 있게 하여, 메타를 포함한 그 누구도 중간에서 메시지를 가로챌 수 없도록 보장하는 강력한 신뢰 계층을 제공합니다. **키 투명성의 개념과 사용자 편의성** * 키 투명성은 메시지 암호화에 사용되는 공개 키의 변경 이력을 누구나 확인하고 감사할 수 있도록 기록하는 시스템입니다. * 기존에는 사용자가 보안 코드를 직접 비교하는 수동 검증 방식이 있었으나, 여러 기기를 사용하거나 기기를 교체할 때마다 매번 확인해야 하는 번거로움이 있었습니다. * 새로운 시스템은 이러한 검증 과정을 자동화하여, 사용자가 복잡한 절차 없이도 자신의 대화가 올바른 키로 암호화되고 있음을 확신할 수 있게 합니다. **신뢰성 확보를 위한 외부 감사 아키텍처** * 메타는 자사의 AKD(Auditable Key Directory) 라이브러리를 활용하여 키를 안전하게 배포하고 관리합니다. * 시스템의 객관성을 높이기 위해 클라우드플레어(Cloudflare)를 독립적인 외부 감사자(Auditor)로 지정했습니다. * 클라우드플레어는 키 투명성 대시보드를 통해 실시간 로그를 유지하며, 이를 통해 누구나 키 배포 과정이 투명하게 이루어지고 있는지 직접 확인할 수 있습니다. **대규모 데이터 처리를 위한 기술적 최적화** * 메신저의 방대한 규모로 인해 약 2분마다 수십만 개의 새로운 키가 추가되며, 현재 데이터베이스에는 이미 수십억 개의 키 항목이 저장되어 있습니다. * 데이터가 기하급수적으로 늘어나는 상황에서도 빠른 검증을 유지하기 위해, 키 버전이 증가해도 증명(Proof) 데이터의 크기가 일정 수준을 유지하도록 알고리즘 효율성을 대폭 개선했습니다. * 과거 트리 높이에 따라 선형적으로 증가하던 증명 크기 문제를 해결하여, 수십억 개의 노드가 존재하는 트리 구조에서도 실시간 조회가 가능하도록 최적화했습니다. * 왓츠앱(WhatsApp)의 키 투명성 운영 경험을 바탕으로, 일시적인 장애 상황에서도 데이터 순서가 뒤섞이지 않고 신속하게 복구될 수 있는 인프라 탄력성을 확보했습니다. 이 기능은 현재 메신저의 1:1 채팅에 적용되어 있으며, 사용자들은 별도의 설정 없이도 자동화된 보안 검증의 혜택을 누릴 수 있습니다. 보안에 민감한 사용자라면 클라우드플레어의 공개 대시보드를 통해 시스템의 무결성을 직접 모니터링해 보는 것을 추천합니다.

cryptographycloudflaresecurityend-to-end-encryption+2