브라우저는 강력한 암호 기술을 실행할 수 있지만, 브라우저에 전달되는 코드도 여전히 신뢰할 수 있어야 합니다.
브라우저는 네이티브 메시징 앱을 설치하지 않고도 포스트 양자 키 설정을 포함한 종단 간 암호화를 로컬에서 수행할 수 있습니다. 어려운 질문은 그 수학 연산이 탭에서 실행될 수 있느냐가 아닙니다. 전달된 애플리케이션, 키 처리 방식, 업데이트 경로에 대화가 요구하는 신뢰를 둘 수 있느냐입니다.
설치할 수 없는 상황에서는 웹 기반 접근이 편리할 수 있습니다. 그렇다고 앱이 검열, 침해된 호스팅, 악성 확장 프로그램 또는 침해된 기기에 영향을 받지 않는 것은 아닙니다.
브라우저의 암호학적 구성 요소
WebCrypto는 암호화, 키 유도, 서명, 키 관리를 위한 저수준 연산을 제공합니다. 일반적인 구현은 AES-GCM과 ECDH 같은 기본 요소를 제공합니다. 이러한 연산은 구성 요소일 뿐, 인증을 갖춘 완전한 메시징 프로토콜은 아닙니다.
필요한 네이티브 API를 사용할 수 없다면 웹 애플리케이션은 JavaScript나 WebAssembly를 이용해 검토된 ML-KEM 구현을 추가할 수 있습니다. 브라우저 지원은 변하므로 개발자는 모든 브라우저가 같은 알고리즘을 제공한다고 가정하지 말고 정확한 대상 버전에서 기능 지원을 검사해야 합니다.
개념적인 하이브리드 흐름은 다음과 같습니다.
- 암호학적으로 안전한 난수를 사용해 적절한 키를 생성합니다.
- 프로토콜의 신원 메커니즘으로 상대방의 키 자료를 인증합니다.
- 고전적 방식과 포스트 양자 방식의 공유 비밀 기여분을 얻습니다.
- 지정된 키 스케줄과 대화 맥락에 따라 이들을 결합합니다.
- nonce와 상태를 올바르게 처리하면서 유도된 키로 인증 암호화를 수행합니다.
이는 설명을 위한 개요이지 구현 지침이 아닙니다. FIPS 203은 ML-KEM을 표준화하지만, 특정 브라우저 애플리케이션을 인증하거나 채팅 프로토콜의 모든 단계를 정의하지는 않습니다.
HTTPS 전달도 신뢰 모델의 일부입니다
서버는 보통 평문을 처리할 JavaScript와 WebAssembly를 제공합니다. 악의적으로 변경된 애플리케이션은 암호 라이브러리가 건전한 알고리즘을 사용하더라도 암호화 전이나 복호화 후에 메시지를 읽을 수 있습니다.
HTTPS는 전달 출처를 인증하고 네트워크 간섭으로부터 전달을 보호하는 데 도움을 줍니다. 원본 사이트 운영자, 배포 시스템 또는 의존성이 침해되지 않았음을 증명하지는 않습니다. 일반 HTTPS 웹페이지가 자동으로 독립적으로 서명된 애플리케이션 패키지가 되는 것도 아닙니다.
W3C WebCrypto 보안 고려 사항은 스크립트 주입과 애플리케이션 무결성 보호의 필요성을 다룹니다. 콘텐츠 보안 정책, 신중한 의존성 관리 및 기타 웹 보안 통제는 위험을 줄이지만, 어느 것도 임의의 동일 출처 스크립트를 애플리케이션 데이터에 손댈 수 없는 비신뢰 관찰자로 만들지는 않습니다.
WebAssembly도 애플리케이션의 보안 경계를 공유합니다. 샌드박스는 정의된 인터페이스를 통한 호스트 접근을 제한할 뿐, 이를 호출하는 페이지를 신뢰할 수 있게 만들지는 않습니다. C를 Wasm으로 컴파일한다고 원본 언어가 메모리 안전성을 갖게 되는 것은 아닙니다.
키가 반드시 RAM에만 존재하는 것은 아닙니다
브라우저 메신저는 사용자가 같은 신원으로 돌아올 수 있도록 키나 암호화된 상태를 영구 저장할 수 있습니다. 기기 연결이나 암호화된 복구를 제공할 수도 있습니다. 이러한 동작은 없다고 가정할 것이 아니라 문서로 명시해야 합니다.
물어볼 만한 질문은 다음과 같습니다.
- 어떤 키를 어떤 브라우저 저장소에 영구 저장하나요?
- 사이트 데이터를 지우거나 비공개 탐색 세션을 종료하면 어떻게 되나요?
- 추출 불가능한 키도 애플리케이션 맥락에서 실행되는 악성 코드가 사용할 수 있나요?
- 새로 전달된 업데이트가 이전 로컬 상태에 접근할 수 있나요?
- 복구는 신원, 메시지 기록, 아니면 둘 다 복원하나요?
추출 불가능한 WebCrypto 키는 API를 통한 내보내기를 제한합니다. 이것만으로 적대적인 애플리케이션 코드가 허용된 연산을 요청하거나 평문을 수집하는 것을 막지는 못합니다.
웹과 네이티브 클라이언트는 서로 다른 절충점이 있습니다
| 고려 사항 | 브라우저 클라이언트 | 네이티브 클라이언트 |
|---|---|---|
| 배포 | 원본 사이트, 호스팅, 웹 업데이트 경로 | 앱 스토어 또는 패키지 배포 및 서명 경로 |
| 로컬 영구 저장 | 브라우저 저장소와 프로필 동작 | OS 앱 저장소와 애플리케이션 수명 주기 |
| 노출 면 | 동일 출처 스크립트, 확장 프로그램, 브라우저 취약점 | 애플리케이션 의존성과 OS/앱 취약점 |
| 가용성 | 접근 가능한 도메인과 필요한 네트워크 서비스 | 설치된 앱도 필요한 네트워크 서비스가 있어야 함 |
구현을 살펴보지 않으면 어느 열도 우위를 입증하지 못합니다. 웹 앱은 앱 스토어에서 삭제된 후에도 접근할 수 있을지 모르지만, 도메인이 차단되거나 네트워크 경로가 없으면 여전히 접근이 막힐 수 있습니다.
성능은 약속하지 말고 측정하세요
FIPS 203에 따르면 ML-KEM-768은 1,184바이트 캡슐화 키와 1,088바이트 암호문을 사용합니다. 이 크기는 프로토콜이 모든 짧은 메시지에 새 자료를 붙이는 대신 KEM 업데이트를 일정에 따라 수행할 수 있는 이유를 설명합니다. 애플리케이션 전체의 대역폭이나 속도를 측정한 값은 아닙니다.
유용한 벤치마크는 브라우저, 기기, 빌드, 준비 실행 방식, 측정 연산, 소요 시간 분포를 명시합니다. 페이지 시작, 모듈 로딩, 메모리 사용, 저사양 기기, 네트워크 오버헤드를 포함해야 합니다. “모든 최신 휴대전화에서 2밀리초 미만” 같은 주장에는 공개된 측정치가 필요하며, 이 글은 그런 측정치를 제공하지 않습니다.
Livara에 적용하기
Livara의 보안 개요는 LVR1과 복구 경계를 문서화합니다. Proof Lab은 일부 로컬 P-256, HKDF, AES-GCM 연산을 시연하며, 해당 페이지는 전체 LVR1/LGS1 구성이 이 시험대의 범위 밖임을 명시합니다. 따라서 시연이 성공했다고 배포된 모든 웹 코드의 보안이 입증되는 것은 아닙니다.
브라우저에서 민감한 대화를 하기 전에 정식으로 유지 관리되는 클라이언트를 사용하고, 현재 위협 모델을 검토하고, 브라우저 프로필을 보호하며, 지원되는 키 확인 절차로 상대방을 검증하세요. 웹 전달 경계를 평가에 계속 포함한다면 편의성과 유용한 암호 기술은 공존할 수 있습니다.
