end-to-end-encryption

10 개의 포스트

meta

종단 간 암호화와 검증 가능성을 보장하는 WhatsApp용 사기 경보 시스템 구축 방법 (새 탭에서 열림)

WhatsApp의 Scam Alert는 종단간 암호화를 유지하면서 사기 가능성이 있는 메시지를 기기에서만 분석하는 선택형 기능이다. 메시지 내용은 서버로 전송되거나 자동 신고되지 않으며, 사용자가 경고를 본 뒤 차단·신고·대화 지속 여부를 직접 결정한다. WhatsApp은 온디바이스 처리, 사용자 통제, 공개 검증 가능성을 통해 개인정보 보호와 사기 탐지의 균형을 이루려 한다. ## 온디바이스 사기 탐지 - 사용자가 기능을 켜면 사기 탐지용 머신러닝 모델이 기기에 다운로드된다. - 모델은 연락처에 등록되지 않은 사람이 보낸 메시지를 대상으로 다음 신호를 분석한다. - 대화의 구조 - 문장 및 언어적 특징 - 기존 사기 대화에서 관찰된 패턴 - 분류는 확률 기반으로 수행되며, 메시지 내용은 분류를 위해 WhatsApp·Meta·제3자 서버로 전송되지 않는다. - 모델이 사기 가능성이 높다고 판단하면 해당 사용자에게만 채팅 경고가 표시된다. 상대방에게는 경고가 보이지 않는다. ## 사용자가 결정하는 대응 방식 - 경고를 본 사용자는 다음 중 하나를 선택할 수 있다. - 대화 차단 - 신고 - 계속 대화 - 오탐이라고 판단하면 채팅을 신뢰 대상으로 표시할 수 있다. - 신뢰 처리된 채팅은 경고가 제거되고, Scam Alert가 해당 채팅을 다시 경고하지 않는다. - 사용자가 원할 경우 정확도 개선을 위해 최근 수신 메시지 5개를 WhatsApp에 공유할 수 있다. - 메시지 내용이나 사기 탐지 사실이 서버에 전달되는 유일한 경로는 사용자가 명시적으로 신고하거나 공유하는 경우다. ## 설계 원칙 - **기기 내 처리**: 머신러닝 모델과 분석 대상 메시지는 모두 사용자 기기에 남는다. - **자동 신고 금지**: WhatsApp은 사용자의 행동 없이 메시지나 탐지 결과를 서버로 보낼 수 없다. - **사용자 통제**: 기능을 언제든 켜거나 끌 수 있고, 경고에 대한 최종 판단도 사용자가 내린다. - 최근 온디바이스 머신러닝 기술 발전으로 모바일 기기에서도 성능·배터리·모델 크기의 부담을 줄이면서 텍스트 분류가 가능해졌다는 점을 활용한다. ## 개인정보 보호형 분석 WhatsApp은 기능이 실제 사기를 잘 탐지하는지, 모델 업데이트 후 성능이 악화되지 않았는지를 확인하기 위해 제한적인 통계만 수집한다. - 수집 대상은 메시지 원문이 아닌 다음 두 종류의 집계 신호다. - **경고 횟수**: 기기 내 모델이 사기 경고를 표시한 횟수 - **사용자 행동 횟수**: 경고 이후 사용자가 신뢰 처리, 차단, 신고 등을 선택한 횟수 - 이 통계는 모델의 경고 발생률과 오탐률을 평가하는 데 사용된다. - 개인별 행동이나 특정 메시지를 식별할 수 있도록 설계하지 않는다. - 차등 개인정보보호(differential privacy)를 적용해 통계에 조정된 노이즈를 추가한다. - 이에 따라 특정 개인의 데이터가 포함되거나 제외되더라도 전체 통계에 미치는 영향이 매우 작아진다. ## 기밀 연합 분석 파이프라인 집계 통계를 보호하기 위해 WhatsApp은 기밀 컴퓨팅 기반의 연합 분석 구조를 사용한다. - **로컬 집계** - 원시 이벤트는 기기를 떠나지 않는다. - 기기는 데이터를 자체적으로 횟수로 합산한 뒤 집계값만 전송한다. - 전송 시점은 무작위화되고, 기기 식별자는 포함되지 않는다. - 시간 정보도 정확한 시각이 아닌 넓은 구간으로 제한된다. - **기밀 처리** - 집계값은 CPU 기반 기밀 가상머신(CVM)과 신뢰 실행 환경(TEE)에서 처리된다. - 클라이언트는 하드웨어 기반 증명을 확인하고, 허용된 소프트웨어 바이너리인지 제3자 로그와 대조한다. - 데이터는 기기와 TEE 사이에서 암호화된다. - WhatsApp이나 Meta를 포함한 중간 전달자도 처리 중인 데이터를 볼 수 없도록 설계됐다. - **안전한 집계** - 개별 기기의 통계가 직접 노출되지 않도록 여러 기기의 데이터를 결합한다. - 최종적으로 WhatsApp과 Meta에 제공되는 것은 익명화·차등 개인정보보호가 적용된 집계 결과다. ## 모델 배포와 독립 검증 - Meta와 WhatsApp은 특정 사용자에게 특정 모델을 선택적으로 배포할 수 없도록 설계했다. - 실험 모델을 포함한 모든 모델 버전은 배포 전에 공개 투명성 원장에 기록된다. - 모델 가중치도 공개해 보안 연구자들이 모델이 사기 탐지 목적에 맞게 제작됐는지 확인할 수 있도록 한다. - 버그 바운티 프로그램을 확대해 외부 연구자들이 구현을 검증하고 취약점을 찾을 수 있게 했다. - 사용자 역시 앱 내 로그를 통해 기능의 동작을 확인할 수 있도록 했다. ## 실용적인 결론 Scam Alert는 서버에서 메시지를 검사하는 방식이 아니라, 선택형 온디바이스 모델과 사용자 주도 신고를 결합한 접근이다. 개인정보 보호가 중요한 사용자는 기능을 직접 활성화해 사기 경고를 보조 수단으로 활용할 수 있지만, 머신러닝 경고는 확률적 판단이므로 최종적으로는 송금 요구, 긴급성 유도, 신원 사칭 같은 전형적인 사기 신호를 사용자가 함께 확인해야 한다.

line

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기 (새 탭에서 열림)

LINE의 대규모 Kafka 환경에서는 TLS·인증·인가만으로는 브로커에 저장된 평문 데이터를 충분히 보호하기 어렵기 때문에, 프로듀서부터 컨슈머까지 메시지 페이로드를 암호화하는 종단 간 암호화를 도입했다. 레코드 단위 암호화와 DEK-KEK 구조를 결합해 Kafka 표준 확장성을 유지하면서 성능 오버헤드를 줄였고, 공유 KEK·평문 폴백·점진적 배포로 초당 최대 100만 건 규모의 토픽에 무중단 적용했다. ## Kafka 기본 보안 모델의 한계 - TLS/SSL은 프로듀서·컨슈머와 브로커 사이의 전송 구간만 보호한다. - SASL 인증은 클라이언트의 신원을 확인하고, ACL 인가는 토픽 접근 권한을 통제한다. - 그러나 브로커에 저장된 메시지 페이로드 자체는 평문일 수 있다. - 따라서 접근 권한이 우회되거나 브로커 내부 데이터가 노출되면 민감 정보가 보호되지 않는다. - 데이터 생성 시점부터 컨슈머의 복호화 시점까지 암호화 상태를 유지하는 심층 방어 전략이 필요하다. ## 레코드 단위 암호화 - 배치 단위 암호화는 압축 효율과 처리 성능이 좋지만, Kafka 클라이언트 내부 동작을 수정해야 한다. - Kafka의 인터셉터와 같은 공식 확장 포인트는 레코드 단위로 동작한다. - 레코드 단위 암호화는 압축 효율이 낮고 메시지 크기가 다소 증가하지만 다음 장점이 있다. - 표준 Kafka API를 활용할 수 있다. - Kafka 버전 업그레이드 시 호환성과 안정성이 높다. - 기존 프로듀서·컨슈머 클라이언트 코드를 직접 수정하지 않아도 된다. - 이러한 이유로 레코드 단위 암호화를 선택했다. ## DEK-KEK 이중 키 구조 - **DEK(Data Encryption Key)** - 메시지 페이로드 암호화에 사용하는 AES 대칭 키다. - AES-GCM을 사용해 빠른 암·복호화와 무결성 검증을 제공한다. - **KEK(Key Encryption Key)** - DEK를 암호화하는 ECC 기반 비대칭 키 쌍이다. - KMS가 키를 관리하며, 프로듀서는 공개 키를 사용하고 컨슈머는 인가된 비공개 키를 사용한다. - DEK 암호화에는 ECIES와 `secp521r1` 곡선을 사용한다. - 대용량 데이터는 빠른 대칭 키로 처리하고, 짧은 DEK에만 비대칭 암호화를 적용해 성능 부담을 줄인다. - 프로듀서는 페이로드를 한 번만 암호화하므로 컨슈머 수가 늘어도 메시지 크기를 크게 늘리지 않는다. - 공개 키를 이용한 암호화 권한과 비공개 키를 이용한 복호화 권한을 분리해 최소 권한 원칙을 적용한다. ## 암호화 메시지 구조 - **키** - Kafka 파티션을 결정하는 기존 메시지 키를 그대로 유지한다. - **헤더** - 컨슈머가 사용할 KEK ID와 KEK로 암호화된 DEK를 저장한다. - **바디** - DEK로 암호화된 실제 페이로드를 담는다. - 외부 DB나 캐시 없이 메시지 자체에 복호화 메타데이터를 포함해 시스템 의존성을 줄였다. - 컨슈머는 헤더의 KEK ID를 확인한 뒤 DEK를 복호화하고, 복호화한 DEK로 바디의 페이로드를 복호화한다. ## 프로듀서 암호화 처리 - Kafka 인터셉터가 전송 직전 DEK를 생성하고 KEK 공개 키로 암호화한다. - 암호화된 DEK는 메시지 헤더에 삽입한다. - 기존 시리얼라이저를 감싼 래퍼가 직렬화된 페이로드를 DEK로 암호화한다. - 인터셉터와 시리얼라이저가 같은 실행 스레드를 공유한다는 점을 활용해 DEK를 `ThreadLocal`로 전달한다. - 매 메시지마다 DEK를 새로 만들지 않고 일정 시간 캐싱해, 반복적인 비대칭 키 연산을 줄였다. ## 컨슈머 복호화 처리 - 컨슈머는 KMS에서 인가된 KEK 비공개 키를 조회한다. - 디시리얼라이저가 헤더에서 암호화된 DEK를 추출하고 비공개 키로 복호화한다. - 복호화된 DEK로 페이로드를 복호화한 후 기존 역직렬화를 수행한다. - 여러 프로듀서가 생성한 암호화 DEK와 복호화된 DEK의 쌍을 캐싱한다. - 동일한 암호화 DEK가 반복되면 비공개 키 연산을 생략해 컨슈머 성능을 높인다. ## KMS 기반 키 관리 - 토픽 오너가 KEK 키 쌍을 생성하고 KMS에 등록한다. - 프로듀서는 공개 키를, 승인된 컨슈머는 비공개 키를 KMS에서 조회한다. - 신규 컨슈머는 비공개 키 접근 권한을 요청하고 토픽 오너의 승인을 받아야 한다. - KEK의 생성·배포·접근 제어·교체를 KMS를 통해 일관되게 관리한다. ## 공유 KEK로 메시지 크기 제어 - 컨슈머마다 별도의 KEK를 사용하면 컨슈머 수에 비례해 헤더 메타데이터가 증가한다. - 메시지 크기 증가는 배치당 레코드 수 감소, 네트워크 대역폭 증가, CPU·메모리 사용량 증가로 이어진다. - 특히 초당 최대 100만 건의 토픽에서는 컨슈머 추가에 따른 헤더 증가가 큰 성능 문제가 된다. - 여러 컨슈머가 하나의 KEK를 공유하면 헤더에는 하나의 메타데이터만 포함되어 메시지 크기를 일정하게 유지할 수 있다. - 대신 키 격리 수준은 낮아지므로 다음 보완책을 함께 적용한다. - KMS 기반 비공개 키 접근 인가 - 주기적인 KEK 교체 - 토픽 오너 중심의 키 관리 ## 평문 폴백을 이용한 무중단 마이그레이션 - 암호화 도입 과정에서는 기존 평문 메시지와 새로운 암호화 메시지가 함께 존재할 수 있다. - 디시리얼라이저가 헤더의 암호화 메타데이터 유무를 확인해 처리 방식을 결정한다. - 헤더가 있으면 복호화 후 역직렬화한다. - 헤더가 없으면 기존 평문 역직렬화만 수행한다. - 안전한 전환 순서는 다음과 같다. - 평문과 암호화 메시지를 모두 처리할 수 있는 컨슈머를 먼저 배포한다. - 모든 컨슈머가 준비된 뒤 프로듀서 암호화를 활성화한다. - 모니터링을 통해 평문 메시지 비중이 0%가 되었는지 확인한다. - 프로듀서 암호화 비율도 한 번에 100%로 변경하지 않고 점진적으로 높여 성능 저하나 암·복호화 오류에 대응한다. ## 실용적인 결론 Kafka의 TLS·인증·인가를 대체하기보다, DEK-KEK 기반 페이로드 암호화를 추가 보안 계층으로 적용하는 것이 적절하다. 대규모 환경에서는 레코드 단위 암호화, DEK 캐싱, 컨슈머 측 DEK 캐싱, 공유 KEK, 평문 폴백과 점진적 배포를 함께 설계해야 보안성과 성능, 무중단 운영을 동시에 확보할 수 있다.

discord

디스코드의 모든 음성 및 영상 통화가 이제 종단 간 암호화됩니다 (새 탭에서 열림)

Discord는 2026년 3월부터 Stage 채널을 제외한 모든 음성·영상 통화에 종단간 암호화(E2EE)를 기본 적용했다. 이를 위해 DAVE 프로토콜을 데스크톱·모바일·웹·콘솔·봇·Social SDK 등 모든 플랫폼에 적용했으며, 사용자가 별도로 설정하지 않아도 암호화가 작동한다. Discord는 통화 품질과 지연 시간을 유지하면서도 공개 프로토콜, 오픈소스 구현, 외부 감사를 통해 검증 가능한 개인정보 보호를 제공하는 것을 목표로 했다. ## DAVE 프로토콜 도입과 전면 적용 - Discord는 2023년 음성·영상 통화 E2EE 실험을 시작했다. - 2024년 DAVE 프로토콜을 공개했다. - 오디오·비디오 통화를 위한 공개 E2EE 프로토콜 - 외부 보안 기업 Trail of Bits의 설계·구현 감사 진행 - 오픈소스 구현체 공개 - 버그 바운티 프로그램에 프로토콜 포함 - 2025년 웹 브라우저, PlayStation·Xbox 같은 게임 콘솔, Discord 봇·앱, Social SDK까지 지원 범위를 확대했다. - 2026년 3월 초 마이그레이션을 완료해 다음 통화가 기본적으로 암호화된다. - 개인 메시지 통화 - 그룹 DM 통화 - 음성 채널 - Go Live 스트림 ## 다양한 플랫폼을 동시에 지원한 설계 - Discord 통화에는 노트북, 스마트폰, 웹 브라우저, PlayStation, Xbox 사용자가 함께 참여할 수 있다. - 각 플랫폼의 암호화 구현이 서로 호환되면서도 낮은 지연 시간과 높은 통화 품질을 유지해야 했다. - Discord는 플랫폼 다양성 때문에 DAVE를 인터넷에서 가장 폭넓은 플랫폼을 지원하는 음성·영상 E2EE 구현 중 하나로 설명한다. - 모든 클라이언트가 DAVE를 지원해야 통화에 참여할 수 있도록 변경했다. - 현재는 암호화되지 않은 연결로 되돌아가는 폴백 코드를 제거하는 중이며, 제거가 끝나면 비암호화 연결은 불가능해진다. ## 공개 검증과 외부 협업 - DAVE의 설계와 구현을 공개해 커뮤니티가 직접 검토할 수 있도록 했다. - 외부 감사를 통해 보안성을 검증하고, 버그 바운티로 추가적인 취약점 제보를 유도했다. - 웹 지원 과정에서는 Firefox의 문제로 DAVE가 실제 통화에서 정상 작동하지 않는 사례가 발견됐다. - Discord는 우회책을 적용하는 대신 Mozilla와 Firefox 코드베이스를 함께 조사해 근본 원인을 수정하고 패치를 반영했다. - 이는 자체 코드뿐 아니라 관련 플랫폼과 생태계까지 개선하는 방식으로 프로젝트를 진행했음을 보여준다. ## 사용자 경험과 Stage 채널 예외 - E2EE 적용 이후에도 통화 품질과 성능은 기존 수준을 유지하도록 설계했다. - 사용자가 별도로 opt-in할 필요 없이 암호화가 투명하게 적용된다. - 유일한 예외는 대규모 방송을 위한 Stage 채널이다. - 라이브 이벤트, AMA, 커뮤니티 타운홀 등에 사용되는 방송형 구조 - 개인적인 대화 보호를 목적으로 하는 일반 통화와 설계 목적이 다름 - 따라서 현재는 E2EE 대상에서 제외된다. ## 텍스트 메시지 암호화 계획 - Discord는 현재 텍스트 메시지까지 E2EE를 확장할 계획이 없다고 밝혔다. - Discord의 다양한 텍스트 기능이 비암호화 환경을 전제로 구축되어 있기 때문이다. - E2EE를 도입하려면 검색, 관리, 신고, moderation 등 기존 기능을 대규모로 재설계해야 한다. - Discord는 음성·영상 암호화를 완료했지만 개인정보 보호 강화는 계속 진행되는 작업이라고 강조한다. 이번 변화로 Discord 사용자는 별도 설정 없이 개인 음성·영상 대화에 구조적이고 검증 가능한 보호를 받을 수 있게 됐다. 다만 Stage 채널과 텍스트 메시지는 적용 범위에서 제외되므로, 민감한 대화에는 일반 음성 채널이나 DM 통화를 사용하는 것이 적절하다.

meta

Labyrinth 1.1: 종단 간 암호화 백업을 더욱 안정적으로 만들기 (새 탭에서 열림)

메타는 메신저의 종단간 암호화(E2EE) 저장 시스템인 Labyrinth 1.1을 출시했다. 이번 버전은 기기가 오프라인이어도 메시지가 전송되는 즉시 암호화 백업에 저장되도록 개선해, 기기 분실·교체나 장기간 미로그인 상황에서도 메시지 복구 가능성을 높인다. 메시지 내용은 메타를 포함한 제3자가 읽을 수 없으며, 실제 배포 결과 백업 성공률과 전체 대화 기록 복원율이 향상되고 있다. ## Labyrinth와 메신저 암호화 백업 - Labyrinth는 메신저 계정에 연결된 여러 기기 사이에서 저장된 메시지 기록을 종단간 암호화하는 시스템이자 프로토콜이다. - 2023년 도입된 암호화 백업은 메시지 기록을 기기 간에 이동할 수 있게 하면서도 메타가 내용을 열람하지 못하도록 설계됐다. - 사용자는 기기를 바꾸더라도 백업에서 기존 대화 기록을 복원할 수 있다. ## 기존 암호화 백업의 한계 - 기존 방식에서는 메시지를 보낸 뒤 수신자의 기기가 다시 온라인 상태가 될 때까지 암호화 백업에 저장되지 않을 수 있었다. - 따라서 다음과 같은 상황에서 일부 메시지가 백업되지 않을 가능성이 있었다. - 휴대전화를 분실한 경우 - 새 기기로 교체한 경우 - 오랫동안 메신저에 로그인하지 않은 경우 - 기기 자체에 메시지가 남아 있지 않으면, 백업에 도달하지 못한 메시지를 복원하기 어려웠다. ## Labyrinth 1.1의 새로운 하위 프로토콜 - 메시지가 전송되는 시점에 수신자의 암호화 백업으로 직접 전달되도록 동작한다. - 수신자의 기기가 온라인으로 돌아올 때까지 메시지 백업을 기다리지 않아도 된다. - 각 메시지는 별도의 메시지 암호화 키로 보호된다. - 발신자는 해당 키를 수신자의 암호화 백업에 직접 넣으며, 이는 “수신자만 열 수 있는 잠긴 상자에 봉인된 편지를 넣는 것”에 비유된다. - 결과적으로 메시지 내용과 암호화된 백업은 메타가 접근할 수 없고, 대화 당사자만 메시지를 읽을 수 있다. ## 안정성 및 배포 효과 - Labyrinth 1.1은 메신저 전체에 광범위하게 배포되고 있다. - 메타에 따르면 다음과 같은 개선 효과가 나타나고 있다. - 암호화 백업에 성공적으로 저장되는 메시지 증가 - 기기 변경 후 전체 메시지 기록을 복원하는 사용자 증가 - 세부 설계와 암호화 프로토콜은 업데이트된 백서인 「The Labyrinth Encrypted Message Storage Protocol」에서 확인할 수 있다. 사용자 입장에서는 메신저의 암호화 백업 기능을 활성화하고, 기기를 교체하기 전에 백업 설정과 복구 방법을 확인하는 것이 좋다. 이번 업데이트는 특히 기존 기기에 접근할 수 없는 상황에서도 메시지 손실을 줄이는 데 초점을 둔 개선이다.

meta

메타가 종단간 암호화된 백업을 강화하는 방법 (새 탭에서 열림)

Meta는 하드웨어 보안 모듈(HSM) 기반의 백업 키 저장소를 통해 왓츠앱(WhatsApp)과 메신저(Messenger)의 종단간 암호화(E2EE) 백업 보안을 강화하고 있습니다. 이 시스템은 사용자의 복구 코드를 위변조 방지 하드웨어에 저장하여 Meta나 클라우드 제공업체를 포함한 제3자의 접근을 원천 차단하며, 최근 무선(OTA) 키 배포 방식과 배포 투명성 강화를 통해 인프라의 신뢰성을 한층 더 높였습니다. ### HSM 기반 백업 키 저장소의 구조 * 지리적으로 분산된 여러 데이터 센터에 HSM 함대(Fleet)를 구축하고, 다수결 합의(Majority-consensus) 복제 방식을 통해 하드웨어 수준의 복원력과 보안성을 확보합니다. * 사용자의 메시지 복구 코드는 HSM 내부에서만 관리되므로 외부에서는 절대 탈취할 수 없는 구조를 가집니다. * 최근 패스키(Passkeys) 지원을 통해 편의성을 높인 데 이어, 기존 비밀번호 기반 암호화 백업 인프라를 보호하기 위한 보안 업데이트를 지속적으로 적용하고 있습니다. ### 무선(OTA) 함대 키 배포 메커니즘 * 메신저 앱의 경우 앱 업데이트 없이도 새로운 HSM 함대를 유연하게 도입할 수 있도록, HSM 응답 과정에서 함대 공개 키를 무선(Over-the-Air)으로 전달하는 방식을 구축했습니다. * 키 배포의 신뢰성을 보장하기 위해 공개 키는 '검증 번들(Validation bundle)' 형태로 제공되며, 이는 Cloudflare의 서명과 Meta의 교차 서명을 통해 독립적인 암호화 증명을 제공합니다. * Cloudflare는 모든 검증 번들에 대한 감사 로그를 유지하여 배포 과정의 무결성을 외부에서 확인할 수 있도록 지원합니다. ### 배포 투명성 및 검증 가능성 * Meta는 시스템이 설계대로 작동하며 사용자 백업에 접근할 수 없음을 증명하기 위해, 새로운 HSM 함대를 배포할 때마다 보안 증거를 블로그 등을 통해 외부에 공개하기로 했습니다. * 함대 배포는 보통 수년 주기로 드물게 발생하지만, 매 배포 시마다 사용자가 기술 백서의 감사(Audit) 절차를 따라 보안성을 직접 검증할 수 있는 환경을 제공합니다. * 이러한 투명성 강화 조치는 Meta가 보안 백업 분야에서 기술적 리더십을 공고히 하고 사용자 신뢰를 얻기 위한 핵심 전략입니다. 종단간 암호화 백업 시스템의 구체적인 작동 원리와 감사 절차가 궁금한 개발자나 보안 전문가는 Meta가 공개한 "Security of End-To-End Encrypted Backups" 기술 백서를 통해 전체 사양을 상세히 확인할 수 있습니다.

meta

메신저의 고급 브라우징 보호 작동 원리 (새 탭에서 열림)

메신저의 고급 브라우징 보호(ABP) 기술은 종단간 암호화(E2EE) 환경에서 사용자의 프라이버시를 침해하지 않으면서도 악성 링크로부터 사용자를 안전하게 보호하기 위해 설계되었습니다. 이 시스템은 '프라이빗 정보 검색(PIR)' 기술과 정교한 인프라를 활용하여, 서버가 사용자가 어떤 링크를 클릭했는지 알 수 없게 하면서도 수백만 개의 악성 사이트 목록을 실시간으로 대조합니다. 결과적으로 사용자는 보안 위협으로부터 보호받는 동시에 대화 내용의 기밀성을 완벽하게 유지할 수 있습니다. ### 프라이빗 정보 검색(PIR)과 ABP의 설계 원칙 * PIR은 클라이언트가 서버의 데이터베이스를 조회할 때, 서버가 클라이언트의 쿼리 내용을 전혀 알 수 없도록 설계된 암호화 프로토콜입니다. * 가장 단순한 방법은 서버의 전체 데이터베이스를 클라이언트에 전송하는 것이지만, ABP의 데이터베이스는 크기가 너무 크고 업데이트가 빈번하여 이 방식은 불가능합니다. * 대안으로 OPRF(망각 의사 난수 함수)를 사용하고 데이터베이스를 여러 개의 '버킷(Bucket)'으로 나누어 샤딩(Sharding)하는 방식을 도입했습니다. 이를 통해 선형 탐색의 범위를 획기적으로 줄여 효율성을 높였습니다. ### URL 접두사 매칭의 복잡성과 프라이버시 문제 * 악성 URL은 단순한 문자열 일치가 아니라 접두사(Prefix) 매칭이 필요합니다. 예를 들어 `example.com`이 차단 목록에 있다면 `example.com/a/b/index.html` 같은 하위 경로도 차단되어야 합니다. * URL의 모든 가능한 접두사를 개별적으로 쿼리하는 방식은 서버에 누출되는 정보량을 증가시켜, 이론적으로 서버가 사용자의 원래 URL을 유추할 수 있게 만듭니다. * 도메인을 기준으로 버킷을 구성하면 프라이버시는 향상되지만, 단축 URL 서비스처럼 특정 도메인에 수많은 링크가 집중될 경우 버킷 크기가 비정상적으로 커져 데이터 전송 효율이 급격히 떨어지는 문제가 발생합니다. ### 규칙 세트(Ruleset)를 통한 데이터 균형 최적화 * 서버는 버킷 크기의 불균형을 해결하기 위해 클라이언트와 사전에 공유하는 '규칙 세트(Ruleset)'를 생성합니다. * 규칙 세트는 특정 해시 접두사에 대해 URL 경로 세그먼트를 몇 개 더 추가하여 다시 해싱할지를 지시하는 매핑 테이블입니다. * 클라이언트는 이 규칙에 따라 반복적으로 해싱 작업을 수행하여 최종적인 버킷 식별자를 도출합니다. 이 과정을 통해 서버는 사용자가 어떤 도메인을 조회하는지 알 수 없으면서도 균등하게 분배된 데이터 묶음을 응답할 수 있습니다. * 서버는 가장 큰 버킷을 반복적으로 쪼개는 반복 연산 과정을 통해 이 규칙 세트를 생성하며, 이를 통해 전체 시스템의 응답 속도와 대역폭 사용을 최적화합니다. ABP 기술은 암호학적 프리미티브와 대규모 인프라 공학을 결합하여 보안과 프라이버시라는 상충하는 가치를 동시에 실현한 사례입니다. 사용자 입장에서는 추가적인 조작 없이도 고도화된 보안 설정을 유지할 수 있으며, 서비스 제공자는 사용자 데이터를 열람하지 않고도 안전한 플랫폼 환경을 구축할 수 있습니다.

cloudflare

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

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를 기본으로 지원하는 최신 암호화 라이브러리로의 업데이트를 적극 권장합니다.

meta

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

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

discord

모든 디스코드 (새 탭에서 열림)

Discord는 음성·영상 통화의 표준을 DAVE 기반 종단간 암호화(E2EE)로 전환하며, 브라우저·콘솔·Social SDK까지 지원 범위를 확대한다. 2026년 3월 1일부터는 DAVE를 지원하지 않는 클라이언트와 앱이 Discord 통화에 참여할 수 없다. 브라우저 환경에서는 WebRTC Encoded Transform API, Web Worker, WebAssembly를 조합해 보안성과 성능을 확보했다. ## DAVE의 전 플랫폼 확대 - DAVE는 Discord의 음성·영상 통화에 E2EE를 제공하는 프로토콜이다. - 이미 매일 수천만 건의 통화에 적용되고 있으며, 이번 작업으로 다음 플랫폼까지 지원한다. - 웹 브라우저 - 콘솔 - Discord Social SDK - 2026년 3월 1일부터 비-DAVE 클라이언트는 음성 채널과 영상 통화에 참여할 수 없다. - 이는 기존 실험적 도입을 종료하고 DAVE를 Discord 통화의 기본 보안 표준으로 삼는 단계다. ## WebRTC Encoded Transform API 활용 - 브라우저에서는 WebRTC 미디어 파이프라인 내부의 인코딩 전후 지점에서 오디오·영상 프레임을 암호화한다. - Encoded Transform API를 사용하면 브라우저의 코덱과 WebRTC 기능을 유지하면서 DAVE 암호화를 삽입할 수 있다. - Discord는 H.265, AV1 등 최신 코덱의 하드웨어 지원도 활용할 수 있도록 설계했다. - 더 높은 화질 - 더 효율적인 대역폭 사용 - 플랫폼별 코덱 지원 유지 ## Firefox에서 발견한 교착 상태 문제 - 초기 테스트에서는 Firefox에서도 DAVE가 정상 작동했지만, 실제 Discord 통화에서는 암호화용 Web Worker가 프레임을 받지 못했다. - 원인은 Firefox의 `FrameTransformerProxy`가 비디오 데이터가 너무 일찍 전달될 때 교착 상태에 빠지는 엣지 케이스였다. - 지연 처리를 위해 저장된 비디오 데이터가 뮤텍스를 사용했으며, 변환 작업이 같은 뮤텍스에 재진입하면서 재귀적 교착이 발생했다. - Discord 팀은 Firefox를 직접 빌드해 브라우저 수준에서 문제를 추적하고 Mozilla에 패치를 제출했다. - 수정 사항은 Firefox 142.0에 포함되며, DAVE를 사용하려면 최소 Firefox 142.0이 필요하다. ## Web Worker 기반 암호화 구조 - 각 Discord 연결은 미디어 암호화와 복호화를 담당하는 전용 Web Worker를 사용한다. - 일반 통화에서는 다음 미디어를 처리한다. - 통화 오디오 - 카메라 영상 - 화면 공유나 게임 스트림은 오디오와 영상별로 별도의 Worker가 처리한다. - 각 WebRTC 스트림에는 고유한 SSRC가 있으며, DAVE는 SSRC를 기준으로 프레임에 사용할 대칭키를 식별한다. - Worker는 다음과 같은 최소한의 상태만 유지한다. - 송수신 오디오·영상 정보 - SSRC와 사용자 ID의 매핑 - 각 사용자에 대한 암호화 키 ## 메인 스레드와 암호화 Worker의 역할 분리 - 메인 JavaScript 스레드는 WebRTC 연결과 참여자, 미디어 트랙을 관리한다. - 사용자 입장·퇴장 시 필요한 MLS(Message Layer Security) 협상도 메인 스레드에서 수행한다. - MLS 그룹 변경을 Worker에서 처리하지 않기 때문에, Worker가 프레임 암호화를 끝낼 때까지 메인 스레드가 대기할 필요가 없다. - MLS 상태가 바뀌면 메인 스레드가 Worker에 비동기 메시지를 보내 암호화 상태를 갱신한다. - 이 구조는 멤버 변경 중에도 미디어 암호화를 계속 수행해 통화 지연을 줄인다. ## 검증된 C++ 구현의 WebAssembly 재사용 - Discord는 데스크톱과 모바일에서 이미 대규모로 검증된 DAVE C++ 코드베이스를 WebAssembly로 컴파일했다. - 동일한 암호화 구현을 여러 플랫폼에서 재사용하면 플랫폼별 재구현으로 인한 보안 취약점과 동작 차이를 줄일 수 있다. - WebRTC 패킷에는 라우팅과 패킷 처리를 위해 일부 메타데이터가 평문으로 남아 있어야 한다. - 암호화된 데이터가 WebRTC 패킷화기, SFU, 역패킷화기를 거치는 동안 변경되면 복호화가 실패한다. - 따라서 프레임을 바이트 단위로 파싱하고 필요한 부분만 선택적으로 암호화해야 한다. - 이 작업은 JavaScript로 직접 구현하기에는 복잡하고 오류 가능성이 높지만, WebAssembly를 사용하면 네이티브에 가까운 성능으로 처리할 수 있다. ## WebAssembly와 SubtleCrypto의 성능 절충 - WebAssembly는 프레임 파싱과 선택적 암호화 로직을 효율적으로 처리한다. - 반면 암호화 연산 자체는 브라우저의 네이티브 API인 `SubtleCrypto`보다 약간 느릴 수 있다. - Discord의 벤치마크는 두 방식의 성능 차이가 단순하지 않으며, 실제 병목이 암호화 연산뿐 아니라 프레임 처리와 데이터 이동에도 있음을 시사한다. - 최종 선택은 단순한 최고 암호화 속도보다 다음 요소를 종합한 결과다. - 검증된 코드 재사용 - 플랫폼 간 동작 일관성 - 프레임 파싱 성능 - 보안 로직의 유지보수성 ## 실용적인 권장 사항 - Discord 통화에 계속 참여하려면 2026년 3월 1일 전까지 DAVE 지원 클라이언트로 업데이트해야 한다. - Firefox 사용자는 최소 Firefox 142.0 이상으로 업그레이드해야 한다. - Discord용 앱이나 Social SDK를 개발 중이라면 DAVE 지원 여부를 확인하고, 비-E2EE 통화에 의존하는 구현을 제거해야 한다.

discord

디스코드 업데이트: (새 탭에서 열림)

디스코드(Discord)는 2024년 9월 업데이트를 통해 플랫폼 내 앱 생태계를 대폭 확장하고 사용자 보안을 한층 강화했습니다. 앱 런처(App Launcher)의 도입으로 대화 중 게임이나 영상 공유가 더욱 간편해졌으며, 종단간 암호화(E2EE)와 패스키(Passkeys) 지원을 통해 통화 보안과 로그인 편의성을 동시에 잡았습니다. 이번 업데이트는 디스코드를 단순한 채팅 도구를 넘어, 개발자와 사용자가 함께 만들어가는 강력한 커뮤니케이션 플랫폼으로 진화시키는 데 중점을 두고 있습니다. ### 앱 런처를 통한 소셜 활동의 확장 * **어디서나 간편한 앱 사용:** 이제 데스크톱과 모바일 모두에서 앱 런처를 통해 수천 개의 앱을 검색하고 채팅이나 음성 채널에 즉시 불러올 수 있습니다. 마음에 드는 앱은 계정에 추가해 언제든 쉽게 다시 사용할 수 있습니다. * **신규 액티비티(Activities) 추가:** 서버 간 전투를 벌이는 'Arena Kingdoms', 체스 퍼즐을 푸는 'Echo Chess', 바이킹 테마의 PVP 게임 'Battletabs' 등 4종의 새로운 게임이 추가되어 친구들과 함께 즐길 수 있습니다. * **이미지 편집 및 애니메이션:** 채팅창의 이미지에 마우스를 올리면 앱 런처를 통해 즉석에서 편집할 수 있습니다. 예를 들어 'Viggle' 앱의 명령어를 사용하여 정지된 사진 속 인물이 춤을 추게 만드는 등의 재미있는 상호작용이 가능합니다. * **개발자 생태계 활성화:** 개발자들은 이제 자신만의 액티비티를 직접 구축하고 출시하여 수익을 창출할 수 있으며, 앱 런처의 검색 기능을 통해 전 세계 사용자에게 노출될 기회를 얻습니다. ### 보안 강화 및 프라이버시 보호 * **A/V 통화 종단간 암호화(E2EE):** 1:1 DM, 그룹 DM, 서버 음성 채널 및 Go Live 스트리밍의 음성과 영상 통화에 종단간 암호화가 도입됩니다. 이를 통해 통화 참여자 외에는 그 누구도 데이터에 접근할 수 없으며, 사용자는 통화 중에 암호화 상태를 직접 확인할 수 있습니다. * **패스키(Passkeys) 도입:** 생체 인식 기술을 활용한 패스키 로그인을 지원합니다. 이제 복잡한 비밀번호를 입력할 필요 없이 Face ID나 Touch ID 등을 통해 즉시 로그인할 수 있으며, 생체 데이터는 기기에만 저장되어 디스코드 서버에도 전송되지 않으므로 보안성이 뛰어납니다. ### 사용자 교육 및 콘텐츠 업데이트 * **디스코드 도장(Discord Dojo):** 초보자부터 숙련자까지 플랫폼을 100% 활용할 수 있도록 단축키, 메시지 서식 지정 방법 등을 담은 교육 비디오와 블로그 리소스를 제공합니다. * **스트리트 파이터 6 콜라보레이션:** 상점에서 류, 춘리, 아쿠마 등 인기 캐릭터를 테마로 한 장식과 효과를 만나볼 수 있으며, 특정 퀘스트를 완료하면 'Battle Field' 장식을 무료로 획득할 수 있습니다. * **시스템 안정성 향상:** 엔지니어링 최적화를 통해 iOS 환경에서의 앱 충돌(Crash) 발생률을 84%나 감소시키는 성과를 거두어 더욱 쾌적한 모바일 환경을 제공합니다. 이번 업데이트를 통해 디스코드는 더욱 안전하고 다채로운 즐길 거리가 가득한 공간으로 변모했습니다. 특히 보안이 중요한 사용자라면 지금 바로 패스키를 설정하고, 친구들과 함께 새로워진 앱 런처를 통해 'Arena Kingdoms'나 'Viggle' 같은 새로운 기능을 직접 체험해 보시길 권장합니다.