왜 이 기술이 주목받나요?
엔드투엔드 암호화(E2EE)는 메시지 내용을 보호하지만, 메시지 안에 포함된 악성 링크 자체를 막아주지는 않습니다. 사용자가 실수로 클릭하면 피싱이나 멀웨어 설치로 이어질 수 있죠. 기존의 안전한 브라우징(Safe Browsing)은 단말기 내 모델을 사용했지만, 메타의 'Advanced Browsing Protection(ABP)'은 수백만 개에 달하는 악성 사이트 실시간 감시 목록을 활용하면서도, '어떤 링크를 검사했는지' 서버가 알 수 없도록 설계되었습니다. 이는 단순한 블랙리스트 검색을 넘어, 암호학과 시스템 엔지니어링의 결합체라 할 수 있습니다. 자세한 내용은 메타 엔지니어링 블로그의 근거자료에서 확인할 수 있습니다.
핵심 과제: 프라이버시 vs. 효율성
가장 이상적인 방법은 서버가 가진 전체 악성 URL 데이터베이스를 클라이언트에 보내는 것이지만, 이는 데이터베이스 크기와 실시간 업데이트, 보안 우회 가능성 때문에 현실적이지 않습니다. 따라서 ABP는 Private Information Retrieval(PIR) 이라는 암호학 프리미티브를 출발점으로 삼습니다. PIR의 목표는 클라이언트가 서버의 데이터베이스를 조회할 때, 서버가 클라이언트가 무엇을 물어보는지 최소한의 정보만 알게(이상적으로는 모르게) 하는 것입니다.
ABP의 기술적 핵심: URL 매칭과 규칙셋(Ruleset)
단순한 키워드 검색과 달리, URL 검사는 접두사(Prefix) 매칭이 필요합니다. 예를 들어 데이터베이스에 example.com이 등록되어 있다면, example.com/a/b/index.html도 악성으로 판단해야 합니다. 가장 단순한 방법은 URL의 모든 경로 접두사를 각각 조회하는 것이지만, 이는 서버에 정보를 과도하게 노출시킵니다.
ABP는 이 문제를 '규칙셋(Ruleset)' 이라는 독창적인 전처리 시스템으로 해결합니다. 서버는 데이터베이스 항목들을 가능한 균일한 크기의 '버킷'으로 나누기 위해 규칙셋을 생성합니다. 이 규칙셋은 특정 도메인 해시에 대해 '몇 개의 경로 세그먼트를 추가로 해싱에 포함시킬지'를 정의한 일종의 지도입니다.
# 규칙셋 적용 의사 코드 (실제 구현은 더 복잡함)
def compute_bucket_id(url, ruleset):
domain = extract_domain(url)
path_segments = extract_path_segments(url)
current_hash = hash(domain)
used_segments = 0
while True:
# 규칙셋에서 현재 해시 접두사 찾기
rule = ruleset.get(current_hash[:16]) # 8바이트(16진수 16자리) 접두사
if rule is None:
break
# 규칙에 정의된 수만큼 경로 세그먼트 추가
used_segments += rule.num_segments
new_partial_url = domain + '/' + '/'.join(path_segments[:used_segments])
current_hash = hash(new_partial_url)
# 최종 버킷 ID는 마지막 해시의 첫 2바이트
bucket_id = current_hash[:4]
return bucket_id
# 예시 규칙셋 (해시접두사: 추가할 경로 세그먼트 수)
ruleset = {
"08bd4dd11758b503": 2,
"fe891588d205cf7f": 1
}
# URL "example.com/a/b/index.html"에 대해,
# 초기 해시("example.com")가 "08bd..."로 시작하면 규칙 적용
# -> "example.com/a/b"를 재해시 후 버킷 ID 결정
이 방식을 통해, 많은 악성 URL을 보유한 단일 도메인(예: URL 단축 서비스)이 하나의 거대한 버킷을 만드는 문제를 해결하면서도, 서버는 클라이언트가 최종적으로 어떤 버킷 ID를 보내는지만 알 뿐, 정확한 전체 URL은 알 수 없게 됩니다. 이는 보안과 시스템 부하 관리의 절묘한 타협점입니다. 특히 국내에서는 악성 광고나 피싱 링크가 특정 플랫폼을 집중 타격하는 경우가 많아, 이렇게 도메인 기반의 지능적인 분류 전략이 더욱 중요할 수 있습니다.
프라이버시 강화를 위한 3중 장치
버킷 ID 조차도 서버에 노출되는 정보입니다. ABP는 이 정보 노출을 최소화하기 위해 세 가지 강력한 장치를 추가합니다.
1. 기밀 컴퓨팅(Confidential Computing)과 AMD SEV-SNP
버킷 ID를 처리하는 서버 사이드 코드는 AMD SEV-SNP 기술로 보호된 기밀 가상 머신(CVM) 내에서 실행됩니다. CVM은 메모리 암호화를 제공하며, 시작 시 생성되는 증명 보고서(Attestation Report) 를 통해 클라이언트는 자신이 통신하는 소프트웨어가 진짜 ABP 코드임을 검증할 수 있습니다. 이를 통해 악의적인 서버 운영자조차도 CVM 내부의 데이터나 실행 로직을 엿보기 어렵게 합니다. 메타는 이와 유사한 기술을 WhatsApp Private Processing에도 적용한 바 있습니다.
2. Oblivious RAM (ORAM)
기밀 컴퓨팅만으로는 메모리 접근 패턴을 숨기지 못합니다. 서버가 특정 버킷의 데이터만 메모리에서 읽어오면, 관찰자는 어떤 버킷 ID가 요청되었는지 추론할 수 있습니다. ABP는 Path ORAM 알고리즘을 사용하여, 실제로 필요한 버킷 하나를 읽더라도 외부 관찰자에게는 모든 버킷에 접근하는 것처럼 보이게 합니다. 이는 성능을 일부 희생하지만 프라이버시를 극대화하는 선택입니다.
3. Oblivious HTTP (OHTTP)와 제3자 프록시
클라이언트의 IP 주소와 같은 식별 정보를 서버로부터 숨깁니다. 클라이언트는 요청을 제3자 프록시를 통해 중계하며, 프록시는 요청을 암호화된 채로 서버에 전달합니다. 서버는 요청 내용을 복호화할 수 있지만, 요청이 어느 클라이언트에서 왔는지는 알 수 없게 됩니다.
| 기술 계층 | 목적 | ABP에서의 구현 |
|---|---|---|
| 암호학 계층 (PIR/OPRF) | 쿼리 내용 보호 | 규칙셋 기반 버킷 ID 생성 및 OPRF를 통한 정확한 매칭 |
| 시스템 보안 계층 (TEE) | 실행 환경 보호 | AMD SEV-SNP CVM에서 버킷 ID 복호화 및 처리 |
| 네트워크 프라이버시 계층 | 요청자 신원 보호 | OHTTP 및 제3자 프록시를 통한 요청 중계 |
이러한 다층적 접근은 하나의 기술적 한계를 다른 계층이 보완하는 디펜스 인 디프스(Defense in Depth) 전략의 훌륭한 사례입니다.
한계점과 실무적 시사점
ABP는 혁신적이지만 완벽하지는 않습니다. 첫째, 규칙셋 생성과 ORAM으로 인한 성능 오버헤드가 존재합니다. 대규모 트래픽을 처리하는 메신저 서비스에 이 시스템을 전체 적용하기까지는 많은 최적화가 필요했을 것입니다. 둘째, 기술의 복잡성으로 인해 외부 검증의 어려움이 있습니다. 메타는 증명 보고서의 아티팩트를 외부 연구자들이 검증할 수 있는 플랫폼 제공을 계획 중이라고 밝혔지만, 현재는 블랙박스에 가깝습니다. 셋째, 이 시스템의 근간이 되는 하드웨어 신뢰(AMD SEV-SNP) 에 대한 의존도가 높습니다. 관련 하드웨어 취약점이 발견될 경우 전체 보장 모델에 영향을 줄 수 있습니다.
다음 단계 학습 방향
- PIR의 현실적 적용 사례 심화 학습: ABP는 PIR의 이론을 실용적으로 변형한 사례입니다. 다른 실용적 PIR 프로토콜(예: Simple PIR, SealPIR)을 연구해 보는 것이 좋습니다.
- 기밀 컴퓨팅 생태계 이해: AMD SEV-SNP 외에도 Intel SGX, ARM CCA 등 다양한 TEE 기술과 그 차이점을 파악하세요. 하드웨어 기반 보안의 미래를 논하는 메타의 오픈소스 하드웨어 프로젝트도 흥미로운 참고 자료가 될 수 있습니다.
- 프라이버시 강화 기술(Privacy-Enhancing Technologies, PETs) 탐구: OPRF, ORAM, OHTTP 등은 개별적으로도 연구할 가치가 높은 기술입니다. 이들을 조합하여 새로운 프라이버시 보호 솔루션을 설계해보는 것은 훌륭한 도전 과제가 될 것입니다.
ABP는 단순한 '악성 링크 차단' 기능을 넘어, 사용자 프라이버시를 최우선으로 하는 서비스가 어떻게 복잡한 기술적 도전을 해결하는지 보여주는 교과서 같은 사례입니다. 엔드투엔드 암호화의 보완재로서, 앞으로 모든 메신저 및 협업 도구가 고려해야 할 새로운 표준이 될 수도 있습니다.