Vaulted
업데이트됨

시크릿 공유에서 클라이언트 사이드 암호화가 중요한 이유

작성자

클라이언트 사이드 암호화는 시크릿 공유에서 핵심적인 역할을 한다. 서버가 평문 데이터를 절대 볼 수 없도록 보장하기 때문이다. 서버 사이드 암호화 방식에서는 서비스가 시크릿을 읽을 수 있고, 인프라를 침해한 공격자도 마찬가지다. Vaulted 같은 클라이언트 사이드 도구는 데이터를 전송하기 전에 브라우저에서 AES-256-GCM으로 암호화한다.

서버 사이드 암호화의 문제

기존 시크릿 공유 도구는 다음과 같은 흐름을 따른다:

  1. 폼에 시크릿을 입력한다
  2. 브라우저가 평문을 서버로 전송한다
  3. 서버가 암호화하여 암호문을 저장한다
  4. 수신자를 위한 링크가 생성된다

문제는 2단계에 있다. 시크릿이 평문 상태로 네트워크를 통해 전송된다(TLS로 보호되지만 서버에는 완전히 노출된다). 서비스는 잠깐이라도 데이터에 접근할 수 있다.

이것이 의미하는 바:

  • 서버가 침해되면 전송 중인 모든 시크릿이 노출된다 — 언제든 터질 수 있는 데이터 유출
  • 서비스 직원이 이론적으로 데이터에 접근할 수 있다
  • 법 집행 기관이나 법적 요청으로 서비스가 시크릿을 제출하도록 강제될 수 있다
  • 서버 로그에 평문 데이터가 의도치 않게 기록될 수 있다

클라이언트 사이드 암호화가 이 문제를 해결하는 방법

Vaulted는 다른 접근 방식을 택한다. 암호화가 브라우저 안에서 완전히 이루어진다:

  1. 폼에 시크릿을 입력한다
  2. 브라우저가 AES-256-GCM 암호화 키를 생성하고 시크릿을 로컬에서 암호화한다
  3. 암호화된 **암호문**만 서버로 전송된다
  4. 암호화 키는 URL 프래그먼트(#)에 저장되며, 브라우저는 이를 서버에 절대 전송하지 않는다

서버는 암호화된 데이터만 볼 수 있다. 키를 가진 적이 없으므로 시크릿을 복호화할 수 없다.

URL 프래그먼트가 중요한 이유

URL 프래그먼트 — # 기호 이후의 모든 부분 — 에는 특별한 속성이 있다. 브라우저가 HTTP 요청에 포함시키지 않는다는 것이다. 누군가 Vaulted 링크를 열면 프래그먼트는 그 사람의 브라우저 안에 머문다. 서버는 시크릿 ID에 대한 요청을 받지만 복호화 키는 절대 보지 못한다.

이것은 커스텀 프로토콜도, 임시방편도 아니다. RFC 3986에 정의된, 브라우저가 항상 그래왔던 방식이다.

실제로 무엇을 의미하는가

클라이언트 사이드 암호화를 사용하면 Vaulted 서버가 완전히 침해되더라도 공격자는 암호화된 덩어리만 얻을 수 있다 — 공유된 링크 안에만 존재하는 키 없이는 쓸모가 없다. 이것이 제로 지식 아키텍처의 핵심 원칙이다.

신뢰는 필요 없다. 암호화가 스스로 말한다.

시크릿을 안전하게 공유할 준비가 됐나요? Vaulted를 무료로 사용해보세요.

관련 항목