Web Crypto API의 CryptoKey 객체는 브라우저 저장소에 직렬화해 둘 수 있으며, MDN은 IndexedDB를 대표적인 저장 방식으로 설명합니다. 하지만 같은 출처의 악성 스크립트가 실행되면 키 사용을 요청할 수 있으므로 저장 위치만으로 키 관리가 안전해지지는 않습니다. MDN Web Crypto API, CryptoKey.extractable, WebKit의 Web Cryptography 설명을 확인했습니다. Web Cryptography 명세 원본도 참조해 키 객체와 저장 모델의 범위를 구분합니다.

투명한 캡슐 안의 열쇠와 이를 향하는 세 화살표, 바깥쪽으로 나가는 점선 열쇠에 표시된 금지 기호가 있는 개념 일러스트

*키 내보내기 제한을 비유한 그림입니다. 허용된 암호 연산 호출이나 XSS 상황은 나타내지 않습니다.*

개념 그림이며 브라우저 보안 실험 결과가 아닙니다.

CryptoKey와 extractable의 의미

CryptoKey는 키 자료 자체를 나타내는 객체이며 algorithm, usages, type, extractable 속성을 가집니다. extractable:false는 exportKey 또는 wrapKey로 키 재료를 내보내지 못하게 하는 제한입니다. 이 속성은 실행 중인 코드가 encrypt, decrypt 등 허용된 사용을 호출하지 못하게 막는 권한 분리나 저장 암호화와 같지 않습니다. 필요한 사용만 허용하는 key usages를 선택하세요.

IndexedDB 저장은 노출을 줄일 뿐

CryptoKey는 구조화 복제 가능한 객체여서 IndexedDB에 저장하고 다시 읽을 수 있습니다. 추출 불가 키는 저장 과정에서 원시 키 바이트로 앱에 노출되지 않는 이점이 있습니다. 그러나 브라우저 프로필 탈취, 같은 출처 XSS, 취약한 인증·복구 흐름, 장치 백업과 동기화 등은 별도 위협입니다. LocalStorage에 문자열 키를 넣는 방식과 동일하게 취급하지 말고 저장 수명과 계정 분리를 설계하세요.

키 포장과 암호문 저장

키 재료를 이동해야 한다면 wrapKey와 unwrapKey를 검토할 수 있습니다. wrapped key는 별도 wrapping key로 보호되지만, 그 wrapping key의 생성·저장·복구가 약하면 보호도 무너집니다. 데이터 암호화에 쓰는 키와 포장 키를 분리하고, 알고리즘 파라미터와 복구 절차를 전문가 검토 대상으로 둡니다. 브라우저 API 호출을 조합했다는 사실만으로 제품 수준의 키 관리가 완성되는 것은 아닙니다.

위협 모델을 먼저 정하기

브라우저에서 사용자 기밀을 보호한다면 서버가 키를 볼 수 있는지, 동일 기기의 스크립트 침해를 고려하는지, 로그아웃 때 무엇을 삭제할지, 기기 간 복구를 지원할지 결정하세요. 예를 들어 XSS로 페이지 스크립트가 조작되면 키 바이트를 export하지 못하더라도, 키에 허용된 복호화를 요청해 결과를 외부로 보낼 수 있는지 검토해야 합니다. extractable:false는 export 경로를 제한할 뿐 사용 권한을 제거하지 않습니다. XSS 방지, CSP, 세션 보안과 저장소 정리도 함께 설계하세요. 민감한 데이터라면 Web Crypto 저수준 프리미티브를 조합하기 전에 전체 설계를 암호학·제품 보안 검토 대상으로 두세요.

복구와 기기 변경 경로 설계

브라우저 저장소의 CryptoKey는 브라우저 데이터 삭제, 프로필 초기화, 기기 교체 뒤에도 자동으로 복구되는 백업이 아닙니다. 계정 동기화가 키를 다른 장치로 옮기는지 가정하지 말고, 복구 키나 서버 측 봉투 암호화를 도입할 때 그 키를 누가 보유하며 침해 시 어떤 데이터가 노출되는지 모델링해야 합니다. 복구가 필요 없고 로그아웃 때 삭제한다면 실제 IndexedDB 레코드와 관련 암호문 수명도 함께 정리하세요.

개발자 도구나 애플리케이션 로그에 원시 키, wrapping key, 평문 복구 재료를 남기지 않습니다. 암호 방식, nonce 관리, 인증된 암호화, 계정 복구 경로를 함께 검토해 저장 API만 따로 평가하지 않도록 합니다.

출처