브라우저 암호화 기능: 최신 브라우저가 할 수 있는 것

최신 브라우저는 전용 보안 라이브러리에 맞먹는 네이티브 암호화 기능을 탑재하고 있습니다. Chrome, Firefox, Safari, Edge 모두 Web Crypto API(crypto.subtle)를 노출하고, TLS 1.3을 HPKP 후속 메커니즘과 함께 구현하며, 피싱 방지 인증을 위한 WebAuthn/패스키를 지원하고, Site Isolation으로 각 출처를 샌드박스화하며, Windows의 TPM과 macOS/iOS의 Secure Enclave를 통한 하드웨어 지원 키 저장소를 제공합니다. 암호화 파일 전송 도구를 구축하는 개발자에게 이것은 AES-256-GCM 암호화, PBKDF2 키 파생, FIDO2 인증이 외부 라이브러리 없이 무료로 제공된다는 의미입니다. 2026년 각 브라우저가 실제로 할 수 있는 것을 알아보겠습니다.

Web Crypto API: 공통 기준선

네 가지 주요 브라우저 모두 거의 동일한 표면 영역을 가진 W3C Web Cryptography API를 지원합니다. 핵심 알고리즘:

• 대칭: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256비트)
• 비대칭: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (최대 4096비트), ECDSA 및 ECDH (P-256, P-384, P-521)
• 해싱: SHA-1, SHA-256, SHA-384, SHA-512
• 키 파생: PBKDF2, HKDF
• MAC: HMAC

부족한 것: ChaCha20-Poly1305(브라우저 미지원), Argon2(브라우저 미지원), Ed25519/X25519(Safari 17+와 Firefox 129+에서 지원, Chrome은 추가 중). 이를 위해서는 여전히 libsodium.js나 @noble/curves 같은 JavaScript 또는 WASM 라이브러리가 필요합니다.

Chrome과 Edge는 같은 암호화 구현(V8을 통한 BoringSSL)을 공유합니다. Firefox는 NSS를 사용합니다. Safari는 Apple의 FIPS 검증 라이브러리인 CoreCrypto를 사용합니다. 성능은 다양합니다. Firefox의 PBKDF2 반복은 동등한 하드웨어에서 Chrome보다 약 20% 느립니다. Apple Silicon의 하드웨어 가속이 있는 Safari의 AES-GCM은 같은 Mac의 Chrome보다 약 2배 빠릅니다.

TLS 1.3과 인증서 투명성

모든 주요 브라우저는 지원되는 출처에서 기본적으로 TLS 1.3을 사용하고 레거시 서버에 대해서만 1.2로 폴백합니다. Chrome은 Chrome 84(2020년 7월)에서 TLS 1.0과 1.1 지원을 제거했습니다. Firefox는 Firefox 78에서 제거했습니다. Safari는 macOS 11 / iOS 14에서 제거했습니다.

인증서 투명성이 적용됩니다. 2018년 4월 이후 발급된 인증서는 최소 두 개의 CT 로그에 나타나야 하며, 그렇지 않으면 Chrome과 Safari가 거부합니다. 이는 CA 오발행을 공개적으로 감사 가능하게 만들어 DigiNotar 스타일의 공격을 조기에 포착했습니다.

출처 격리와 샌드박스

Chrome의 Site Isolation은 2018년(데스크톱) 및 2019년(Android) 이후 각 출처를 자체 OS 프로세스에 배치합니다. Firefox의 Fission은 Firefox 94 이후 동일하게 달성합니다. Safari는 WebKit의 프로세스당 모델을 사용합니다. 암호화에 대한 의미: 악의적인 크로스 출처 스크립트가 형제 탭의 메모리에서 복호화된 파일을 읽을 수 없습니다. 형제가 자체 힙을 가진 다른 프로세스에 살기 때문입니다.

Cross-Origin-Opener-Policy(COOP), Cross-Origin-Embedder-Policy(COEP), Cross-Origin-Resource-Policy(CORP)는 페이지가 더 엄격한 격리를 선택하도록 합니다. Cross-Origin-Opener-Policy: same-origin과 Cross-Origin-Embedder-Policy: require-corp를 설정하면 크로스 출처 격리가 가능해지고, 이는 SharedArrayBuffer와 고해상도 타이머를 잠금 해제합니다. AES 구현에 대한 Spectre 스타일 타이밍 공격이 공격자가 출처에서 SAB를 열 수 없을 때 완화되기 때문에 암호화와 관련이 있습니다.

인증을 위한 WebAuthn과 패스키

FIDO2 WebAuthn은 Chrome 67+, Firefox 60+, Safari 14+, Edge 18+에서 지원됩니다. 애플리케이션이 하드웨어 키(YubiKey, Titan), 플랫폼 인증기(Face ID, Windows Hello, Android 생체 인식) 또는 iCloud Keychain, Google Password Manager, 1Password를 통해 사용자 기기에 동기화된 패스키로 사용자를 인증하도록 합니다.

파일 전송 애플리케이션에서 WebAuthn은 저장된 공유 링크에 대한 접근을 보호하는 요소로서 비밀번호를 대체합니다. WebAuthn은 피싱 방지입니다. 서명이 출처에 바인딩되어 있으므로 유사 도메인이 자격 증명을 캡처할 수 없습니다. Chrome과 Safari는 2023~2024년에 패스키 기본 흐름으로 이동하여 대부분의 소비자 사용에서 물리적 키 요건을 없앴습니다.

하드웨어 지원 키 저장소

Windows에서 TPM 2.0 칩(Windows 11에서 필수)은 Windows CNG 브릿지를 통해 비추출 가능으로 생성된 Web Crypto 키를 저장할 수 있습니다. macOS와 iOS에서 Secure Enclave는 Face ID, Touch ID, 패스키에 사용되는 키를 보유합니다. Android에서는 StrongBox(하드웨어) 또는 TEE(신뢰 실행 환경)로 지원되는 Keystore가 유사한 보호를 제공합니다.

실용적 의미: 최신 노트북에서 extractable: false로 Web Crypto를 통해 생성된 키는 주 메모리가 아닌 TPM이나 Secure Enclave에 있을 수 있습니다. JavaScript 메모리를 덤프하는 완전한 브라우저 익스플로잇도 원시 키 바이트를 제공하지 않습니다. 파일 전송 도구에서 이것은 장기 수신자 키에 가장 유용합니다. 임시 파일별 AES 키는 이 보호가 필요하지 않습니다.

암호화 배율기로서의 Content Security Policy

악의적인 스크립트가 암호화 전에 평문을 읽을 수 있다면 암호화는 무의미합니다. CSP 헤더는 사이트가 실행 허용 스크립트를 선언하도록 합니다. 엄격한 정책:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

이는 인라인 스크립트와 제3자 코드를 차단하여 주입된 암호화 탈취 페이로드의 공격 표면을 남기지 않습니다. 모든 주요 브라우저가 CSP Level 3을 지원합니다. 파일 전송 앱의 경우 허용된 제3자 JS가 변조되지 않았음을 보장하기 위해 외부 스크립트에 SRI(Subresource Integrity)와 CSP를 결합하세요.

File System Access API와 OPFS

File System Access API(Chrome 86+, Edge 86+, Safari 15.2+ 부분 지원)는 웹 앱이 사용자 권한으로 로컬 파일을 읽고 쓰도록 합니다. Origin Private File System은 암호화와 특히 관련이 있습니다. 이것은 출처별 프라이빗 파일 시스템으로, 브라우저 관리이며 업로드 전에 전체를 메모리에 로드하지 않고 대형 암호화 페이로드를 스테이징하는 데 사용됩니다.

Firefox는 FSA 채택이 느렸지만 Firefox 111 이후 OPFS를 지원합니다. Safari는 전체적으로 OPFS를 지원하지만 더 광범위한 File System Access API에서는 더 제한적인 동작이 있습니다.

브라우저가 아직 잘 할 수 없는 것

몇 가지 공백이 남아 있습니다:

• Argon2 키 파생은 Web Crypto에 없습니다. PBKDF2 이상의 비밀번호 해싱을 위해 WASM 라이브러리를 사용하세요.
• ChaCha20-Poly1305는 노출되지 않습니다. AES-GCM이 대부분의 필요를 커버하지만 ChaCha는 AES-NI가 없는 기기(구형 ARM)에서 도움이 됩니다.
• 하드웨어 지원 키를 위한 키 증명이 제한적입니다. WebAuthn은 증명을 제공하지만, 더 광범위한 Web Crypto API는 제공하지 않습니다.
• 스트리밍 AEAD는 아직 스펙에 없습니다. 대형 파일 암호화에는 청킹 로직이나 WASM이 필요합니다.
• 포스트 양자 알고리즘(Kyber, Dilithium)은 아직 브라우저에 없습니다. Google은 TLS 핸드셰이크에 Kyber를 탑재했지만(Chrome 116+) JavaScript 노출 포스트 양자 암호화는 여전히 라이브러리 영역입니다.

2026년 파일 전송에 사용할 것

2026년의 신뢰할 수 있는 브라우저 기반 파일 전송 스택:

• 파일 콘텐츠를 위한 crypto.subtle.encrypt를 통한 AES-256-GCM
• 비밀번호 파생 키를 위한 600,000회 반복의 PBKDF2-SHA-256
• 솔트와 논스를 위한 crypto.getRandomValues()(절대 Math.random 사용 금지)
• 서버 노출 없이 클라이언트 사이드로 키를 전달하는 URL 프래그먼트(#key=...)
• HSTS가 활성화된 최소 TLS 1.3, 격리를 위한 COOP/COEP가 있는 HTTPS
• 인라인 스크립트 없는 CSP strict-dynamic
• 저장 계정 기능을 위한 WebAuthn 패스키
• Chrome/Edge/Safari 16+에서 대형 파일 스테이징을 위한 OPFS

HexaTransfer는 본질적으로 이 스택을 실행합니다. SwissTransfer, Tresorit Send, Cryptpad, Proton Drive Share도 마찬가지입니다. 프리미티브는 성숙하고 브라우저 전반에 일관됩니다. GDPR, HIPAA, 개인정보보호법(PIPA) 모두 이러한 클라이언트 사이드 암호화 접근 방식을 규정 준수 친화적으로 만드는 데 도움이 됩니다.

브라우저 간 테스트

항상 네 가지에서 테스트하세요. 실제 버그: Firefox는 Chrome이 조용히 수락하는 PBKDF2 입력에서 OperationError를 발생시킵니다. Safari의 FileReader는 2GB 이상 파일에서 느립니다. Chrome의 OPFS 쓰기는 일부 버전에서 4GB 이상을 청킹합니다. WebAuthn 사용자 확인 프롬프트는 상당히 다릅니다(Face ID vs Touch ID vs Windows Hello vs Android 생체 인식). 출시 전 테스트를 위해 BrowserStack, Sauce Labs, 또는 실제 기기의 로컬 매트릭스를 사용하세요.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.