보안 및 위협 모델

최종 업데이트: 2026-08-02

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

요약하면: 같은 네트워크에서는 실시간 파일과 메시지가 기기 사이를 직접 이동합니다. 네트워크 간 브라우저 세션은 종단간 암호문만 운반하고 콘텐츠 키는 갖지 않는 릴레이를 사용합니다. 세션마다 새 키가 항상 사용되며, 여기에 선택적인 검증 코드를 대역 외로 비교하면 시그널링 가로채기까지 탐지할 수 있습니다. 자세한 내용은 아래와 같습니다.

브라우저 실시간 파일 암호화(X25519 + AES-256-GCM)

브라우저의 실시간 파일 전송에서는 전송마다 각 기기에서 새로운 임시 X25519 키 쌍이 생성됩니다. 두 브라우저는 키 교환을 수행하여 공유 AES-256-GCM 키를 도출합니다. 각 파일 청크는 그 키와 고유한 논스로 암호화되므로 시그널링 서버와 릴레이는 파일 평문이 아닌 암호문을 봅니다. CLI 전송은 아래에 설명된 별도의 직접 TLS 1.3 프로토콜을 사용합니다.

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

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

WebRTC 내장 암호화(DTLS)는 키 지문을 시그널링 서버를 통해 교환하므로, 정직하지 않은 서버가 중간에 끼어들어 키를 바꿔치기할 수 있습니다. 이를 탐지하기 위해 Relayium은 양쪽 공개 키에서 6자리 Short Authentication String(SAS)을 도출해 두 화면에 표시할 수 있습니다. 일치하는 코드가 가장 강한 가로채기 탐지 보장을 제공하려면 두 사람이 반드시 대역 외로 비교해야 합니다. 이 코드를 표시하고 대조를 위해 멈출지는 설정입니다 — 웹에서는 «고급 검증»(기본값 꺼짐), CLI에서는 `--verify`. 끄면 화면에 무엇을 보여줄지와 어떤 단계에서 확인을 위해 멈출지만 달라지며, 암호화는 달라지지 않습니다. 아래의 커밋 후 공개 핸드셰이크는 모든 연결에서 실행되고 공개 값이 맞지 않으면 연결을 거부합니다. 키는 기기에서 생성되어 저희에게 전송되지 않고, 릴레이는 암호문만 운반하며, 브라우저에서는 파일 수신 시 저장 전에 확인을 요청합니다 — 네이티브 macOS 앱은 묻지 않고 설정된 저장 위치(기본값은 다운로드 폴더)에 바로 저장합니다. 이 확인은 원치 않는 디스크 쓰기를 막기 위한 것이지 상대가 누구인지 보장하지 않으며, 그것은 코드 대조만이 확인해 줍니다.

단순한 6자리 코드(약 20비트)는 원칙적으로 중계 서버가 일치하는 코드를 무차별 대입으로 만들어낼 여지가 있습니다. Relayium은 커밋 후 공개 핸드셰이크로 이 틈을 막습니다. 각 측은 먼저 키 해시로 커밋하고 상대방의 커밋을 받은 뒤 키를 공개합니다. CLI 전송은 고정된 TLS 인증서 지문을 커밋 후 공개 방식으로 교환해 도출하는 별도의 SAS를 사용합니다. 이 코드도 실제로 누군가 대역 외로 비교할 때만 의미가 있으며, 그 대조를 위해 멈추는 것이 `--verify`입니다.

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

서버가 보거나 복호화할 수 없는 평문

본 서비스는 서버가 다음 평문을 보거나 복호화할 수 없도록 설계되었습니다:

브라우저 실시간 모드에서 같은 네트워크의 파일과 메시지 데이터는 두 기기 사이에서 직접 흐릅니다. 네트워크를 넘을 때는 암호문으로 TURN을 통과하며 릴레이는 콘텐츠 키를 갖지 않습니다. 다만 시그널링 서비스는 연결 설정 데이터를 처리하며 공개 IP, 룸 소속, 시각, 사용자가 선택한 기기 별칭과 접속 상태 같은 메타데이터를 볼 수 있습니다.

• 파일의 내용.
• 파일의 이름.
• 텍스트 메시지의 평문.
• 사용자의 암호화 키.

브라우저 파일과 텍스트가 중계될 때(TURN)

브라우저의 네트워크 간 파일 및 텍스트 전송 — 페어링 코드 세션과 참여 링크 — 은 대체 수단이 아니라 설계상 TURN 서버를 거칩니다. 제한적인 NAT과 방화벽 때문에 앱은 처음부터 릴레이 경로를 강제합니다. 같은 네트워크의 브라우저 세션에는 중계 자격 증명이 발급되지 않고 직접 연결됩니다. CLI 파일과 텍스트 전송은 TURN을 사용하지 않으며 직접 연결만 쓰고, 직접 경로를 찾지 못하면 실패합니다.

• 중계 서버는 암호문만 전달합니다. 파일이나 메시지를 읽을 수 없으며 종단간 암호화가 유지됩니다.
• 월간 릴레이 허용량을 적용하고 남용을 방지하기 위해 계정별로 릴레이된 바이트 수를 기록합니다——중계 내용은 절대 검사하지 않으며, 오직 바이트 수만 기록합니다.
• 중계된 콘텐츠를 검사하지 않습니다.

임시 텍스트 전송

브라우저 텍스트 세션은 Web 프로토콜을 사용합니다. 피어는 임시 X25519 교환을 수행하고 파일 전송 키와 분리된 도메인에서 방향별 AES-256-GCM 하위 키를 도출합니다. 유효한 UTF-8 메시지는 각각 독립된 프레임으로 인증되고 암호화됩니다. 네트워크를 넘는 브라우저 세션은 설계상 TURN을 사용하며, 릴레이는 암호문만 전달하고 메시지 키를 갖지 않습니다. 고급 검증을 켠 뒤 SAS를 대역 외로 비교하면 시그널링 가로채기까지 탐지할 수 있습니다.

CLI 텍스트는 인증서를 고정한 TLS 1.3 위의 별도 직접 연결 전용 프로토콜입니다. 브라우저의 X25519/AES 메시지 프레이밍이나 TURN을 사용하지 않으며, 직접 경로를 만들 수 없으면 실패합니다. Relayium은 메시지 본문을 저장하지 않지만, 어느 엔드포인트든 수신 후 텍스트를 복사, 기록, 캡처하거나 다른 방식으로 보관할 수 있습니다.

• 두 사람 모두 동시에 온라인이어야 하며, Relayium은 오프라인 텍스트 전달이나 서버 측 메시지 기록을 제공하지 않습니다.
• 서버는 IP 주소, 룸 소속, 시각, 브라우저 세션의 기기 별칭과 접속 상태, 해당되는 경우 페어링 코드를 만든 계정 연결 등 접속에 필요한 메타데이터를 처리합니다.
• TURN 세션에서는 허용량 적용과 남용 방지를 위해 중계 바이트 수를 기록할 수 있지만 메시지 평문은 검사하지 않습니다.

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

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

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

파일 무결성(SHA-256)

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

Relayium이 방어하지 못하는 것

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

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

브라우저 지원과 그 한계

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

• 데스크톱 Chrome과 Edge는 File System Access API가 있어 큰 파일을 디스크로 직접 스트리밍하며, 실질적인 메모리 상한이 없습니다.
• Firefox와 Safari, 그리고 모든 모바일 브라우저(iOS에서는 어떤 브라우저든 WebKit입니다)에는 그 API가 없어 실시간 수신 경로에서는 파일을 메모리에서 조립합니다. 그래서 약 256MB를 넘으면 앱이 미리 경고합니다 — 실측한 한계가 아니라 일부러 보수적으로 잡은 추정값입니다. 그 정도 크기의 파일에는 데스크톱 Chrome/Edge를 사용하거나 다운로드 링크 모드를 이용하십시오. 다운로드 링크의 내려받기 페이지는 service worker를 통해 디스크로 흘려보낼 수도 있습니다.
• WebRTC는 보안 컨텍스트(HTTPS)를 요구합니다. 앱은 일반 HTTP에서는 연결되지 않습니다.

오픈 소스 및 문제 신고

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