보안 및 위협 모델

최종 업데이트: 2026-07-01

Relayium은 서버가 아니라 파일을 전송하는 당사자가 키를 갖도록 설계되었습니다. 이 페이지에서는 무엇이 어떻게 보호되는지, 그리고 그 보호의 한계를 설명합니다.

요약하면: 실시간 모드에서 파일은 당사 서버를 전혀 거치지 않습니다. 암호화 키는 각 기기에서 새로 생성되어 기기를 떠나지 않습니다. 그리고 짧은 검증 코드로 두 사람은 악의적인 서버를 탐지할 수 있습니다. 자세한 내용은 아래와 같습니다.

종단간 암호화(X25519 + AES-256-GCM)

전송마다 각 기기에서 새로운 임시 X25519 키 쌍이 생성됩니다. 두 기기는 키 교환을 수행하여 두 브라우저 안에만 존재하는 공유 AES-256-GCM 키를 도출합니다. 각 청크는 그 키와 고유한 논스로 암호화되므로, 시그널링 서버와 모든 중계 서버는 오직 암호문만 보게 됩니다.

키는 임시적이며 전송마다 별개입니다 — 세션 간에 재사용되지 않습니다.
공유 키는 두 기기에서 도출되며, 어떤 서버로도 전송되거나 저장되지 않습니다.
암호화는 WebRTC 자체의 전송 계층 보안 위, 애플리케이션 계층에서 적용되므로 전송 계층이 침해되어도 유효성을 유지합니다.

검증 코드(SAS) — 악의적인 서버 탐지

WebRTC 내장 암호화(DTLS)는 키 지문을 시그널링 서버를 통해 교환하므로, 정직하지 않은 서버가 중간에 끼어들어 키를 바꿔치기할 수 있습니다. 이를 탐지하기 위해 Relayium은 양쪽의 공개 키에서 6자리 Short Authentication String(SAS)을 도출하여 두 화면 모두에 표시합니다. 두 코드가 일치하면 중간에 아무도 없는 것입니다.

단순한 6자리 코드(약 20비트)는 원칙적으로 중계 서버가 일치하는 코드를 무차별 대입으로 만들어낼 여지가 있습니다. Relayium은 커밋 후 공개 핸드셰이크로 이 틈을 막습니다. 각 측은 먼저 키의 해시를 보내 커밋하고, 상대방의 커밋을 받은 후에야 키를 공개합니다. 따라서 서버는 나중에 충돌하는 키를 고를 수 없으며, 짧은 코드는 신뢰할 수 있는 상태로 유지됩니다.

가장 강력한 보장을 위해서는 코드를 대역 외로 — 직접 만나거나 음성 통화로 — 대조하십시오.
두 코드가 다르면 전송을 중단하십시오. 누군가 연결을 가로채고 있을 수 있습니다.

서버가 절대 보지 못하는 것

본 서비스는 다음 정보가 어떤 모드에서도 당사 서버에 도달하지 않도록 설계되었습니다:

실시간 모드에서는 파일 데이터가 서버를 전혀 거치지 않고 두 기기 사이에서 직접 흐릅니다. 시그널링 서버는 연결 설정 메시지만 중계하며, 룸 소속(사용자의 공개 IP), 사용자가 선택한 기기 별칭, 접속 상태만 볼 수 있습니다.

파일의 내용.
파일의 이름.
사용자의 암호화 키.

파일이 중계될 때(TURN)

두 기기가 네트워크를 가로질러 직접 연결할 수 없는 경우(제한적인 NAT 또는 방화벽), 전송을 완료할 수 있도록 암호화된 스트림이 TURN 서버를 통해 중계됩니다. 언제나 직접 피어 투 피어를 먼저 시도하며, 중계는 대체 수단이고, 중계 자격 증명은 페어링 코드와 공유 링크 세션에만 발급됩니다.

중계 서버는 암호문만 전달합니다. 파일을 읽을 수 없으며 종단간 암호화가 유지됩니다.
서비스 운영을 위해 전송별 중계 바이트 수만 기록하며, 이를 전송을 생성한 로그인 사용자에게 귀속시킵니다.
중계된 콘텐츠를 검사하지 않습니다.

임시 보관 다운로드 링크 — 키는 브라우저를 떠나지 않습니다

선택적 다운로드 링크 모드는 수신자가 온라인이 아닐 때를 위한 것입니다. 브라우저는 무언가 업로드되기 전에 파일을 AES-256-GCM으로 암호화하며, 복호화 키는 URL 프래그먼트 — # 뒤 부분 — 에만 놓입니다. 브라우저는 이를 서버로 보내지 않습니다.

서버는 암호문과, 할당량 및 정리를 위한 암호문 크기와 타임스탬프만 저장하며, 평문·파일 이름·키는 절대 저장하지 않습니다.
완전한 링크를 가진 사람은 누구나 복호화할 수 있으므로, 링크를 파일 자체처럼 취급하고 신뢰할 수 있는 경로로 공유하십시오.
링크는 만료(1, 3, 또는 7일)를 설정하거나 첫 번째 완전한 다운로드 후 소멸되도록 설정할 수 있습니다.

파일 무결성(SHA-256)

기밀성뿐만 아니라 각 파일의 무결성도 검증됩니다. 각 청크에는 AES-GCM 인증 태그가 있고, 수신 측에서는 파일별 SHA-256 해시를 종단간으로 확인하므로, 손상되거나 변조된 파일은 조용히 수용되는 대신 탐지됩니다.

Relayium이 방어하지 못하는 것

종단간 암호화는 정직한 두 엔드포인트 사이의 전송 중 데이터를 보호합니다. 설계상 다음은 방어할 수 없습니다:

어느 한쪽 기기나 브라우저의 침해 — 멀웨어, 악성 브라우저 확장 프로그램, 또는 화면을 훔쳐보는 사람.
서버가 필연적으로 다루는 메타데이터: 전송이 일어났다는 사실, 그 크기와 시각, 그리고 (로그인한 경우) 이를 생성한 계정.
수신자가 파일을 받은 후 보관하거나 전달하기로 선택하는 것.
복호화 키가 링크 안에 담겨 이동하므로, 신뢰할 수 없는 경로로 다운로드 링크를 공유하는 것.

브라우저 지원과 그 한계

Relayium은 HTTPS를 통해 WebRTC를 사용할 수 있는 모든 최신 브라우저에서 작동합니다. 일부 기능은 브라우저에 따라 다릅니다:

Chrome과 Edge는 큰 파일을 디스크로 직접 스트리밍하며, 실질적인 메모리 상한이 없습니다.
Firefox와 Safari는 파일을 메모리에 버퍼링하므로 매우 큰 파일(대략 200MB 초과)은 실패할 수 있습니다 — Chrome/Edge를 사용하거나 그런 파일에는 다운로드 링크 모드를 이용하십시오.
WebRTC는 보안 컨텍스트(HTTPS)를 요구합니다. 앱은 일반 HTTP에서는 연결되지 않습니다.

오픈 소스 및 문제 신고

프로토콜 설계와 클라이언트·서버의 모든 코드는 GitHub에 공개되어 있어 누구나 암호화를 감사하고, 자신의 서버를 운영하고, 기여할 수 있습니다. 보안 문제를 발견하면 공개 이슈를 여는 대신 저장소의 GitHub 비공개 취약점 신고를 통해 비공개로 신고해 주십시오.