Remio 보안 아키텍처를 있는 그대로.

§01 · 요약

Remio는 제로 날리지 P2P 아키텍처로 만든 원격 데스크톱 애플리케이션이에요. 화면 내용, 입력 데이터, 오디오 스트림은 WebRTC 기반 제품이 모두 의존하는 보안 모델인 업계 표준 DTLS-SRTP로 기기 사이에서 종단간 암호화돼요. 중앙집중형 솔루션과 달리 Remio의 시그널링 서버는 처음 연결을 맺는 것만 돕고, 세션 데이터를 보거나 처리하거나 저장하지 않아요.

계정도, 뚫릴 비밀번호도, 자격 증명의 중앙 데이터베이스도 없어요. 기기 페어링은 호스트 화면에서 읽은 QR 코드나 기기 ID와 PIN으로 하고, 모든 세션 키는 완전 순방향 비밀성(PFS)을 갖는 일회성 키라서 키 하나가 유출돼도 과거와 미래의 세션은 암호학적으로 안전해요. 이 아키텍처는 경쟁 제품들을 괴롭혀 온 공격 유형 전체를 없애요. 훔쳐 갈 것 자체가 없으니까요.

§02 · 위협 모델

Remio의 보안 아키텍처는 기업과 개인 환경 모두에서 원격 데스크톱을 쓸 때 관련되는 위협 시나리오들에 맞서도록 설계되었어요. 무엇을 막아 주는지, 신뢰 경계가 어디에 있는지 분명히 밝혀 둘게요.

막아 주는 위협

• 도청. 모든 미디어(영상, 오디오)와 데이터 채널(입력, 키보드, 커서)은 각각 SRTP와 DTLS로 암호화돼요. 네트워크 관찰자는 암호화된 패킷만 볼 수 있고 세션 내용을 복원할 수 없어요.
• 중간자 공격(MITM). 인증서 지문을 검증하는 DTLS 핸드셰이크가 가로채기를 막아요. 시그널링 채널은 완전 순방향 비밀성을 갖는 TLS 1.3을 사용해요.
• 서버 침해. 시그널링 서버가 완전히 침해되더라도 공격자가 얻는 것은 연결 메타데이터(IP 주소, 타임스탬프)뿐이에요. 세션 내용은 저희 서버를 거쳐 전송되거나 저장되지 않아요.
• 무단 접근. 페어링하려면 호스트의 QR 코드를 스캔하거나, 호스트가 보여 주는 기기 ID와 PIN을 입력하거나, 양쪽에서 같은 Remio 계정으로 로그인해야 해요. 원격으로 접근해 공격할 수 있는 자격 증명 데이터베이스는 없어요.
• 자격 증명 탈취. 비밀번호도, 계정도, 중앙 자격 증명 저장소도 없어요. 기기 신뢰는 PIN 페어링으로 이루어지고, 세션 토큰(JWT)은 수명이 짧고 기기에 묶여 있어요.
• 세션 재전송. SRTP에 내장된 재전송 방지와 DTLS 시퀀스 번호가 가로챈 패킷을 다시 보내는 것을 막아요.
• 공급망 공격. 모든 Remio 바이너리는 코드 서명되어 있어요. macOS 빌드는 Apple의 공증을 거쳐요. iOS 빌드는 App Store를 통해서만 배포돼요.

신뢰 경계

저희 위협 모델은 세 가지 신뢰 경계를 명시적으로 정의해요.

1. 기기 경계. 각 기기는 PIN 확인 뒤에만 신뢰돼요. OS 수준 보호(샌드박스와 키체인 같은 각 시스템의 보호된 저장소)가 기기 안의 데이터를 지켜요.
2. 네트워크 경계. 전송 중인 모든 데이터는 암호화돼요. 네트워크는 적대적이라고 가정해요.
3. 서버 경계. 저희 서버도 신뢰할 수 없는 릴레이로 취급해요. 연결을 돕지만 내용을 들여다볼 수 없어요.

§03 · 아키텍처 개요

Remio는 시그널링 플레인(연결 설정)과 데이터 플레인(스트리밍)을 분리해요. 이 분리는 저희 제로 날리지 설계의 기본이에요. 연결을 도와주는 서버가 주고받는 데이터에는 절대 닿지 않아요.

시그널링 vs. 데이터 플레인

시그널링 서버의 유일한 역할은 연결을 설정하는 동안 기기 사이에서 SDP offer/answer와 ICE 후보를 중계하는 거예요. P2P 연결이 맺어지면 시그널링 서버는 더 이상 관여하지 않아요.

서버는 중계하는 내용을 해석할 수 없어요. 대상 기기만 해석할 수 있는 암호화된 바이너리 덩어리예요. 바이너리 프로토콜은 구조를 한 겹 더해서 JSON 기반 시그널링보다 인젝션 공격을 더 어렵게 만들어요.

§04 · 암호화 계층

Remio는 각 통신 채널이 요구 사항에 가장 잘 맞는 암호 프로토콜을 쓰는 다층 암호화 전략을 사용해요.

완전 순방향 비밀성

모든 Remio 세션은 ECDHE 키 교환으로 고유한 일회성 암호화 키 세트를 만들어요.

• 현재 세션 키가 유출되어도 과거 세션이 노출되지 않아요.
• 현재 세션 키가 유출되어도 미래 세션이 노출되지 않아요.
• 각 키 쌍은 한 세션이 지속되는 동안에만 존재해요.
• 키는 디스크에 저장되지 않고 메모리에만 존재해요.

암호 스위트

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

키 교체

키는 다음 시점마다 자동으로 교체돼요.

• 세션 시작. 새 DTLS 핸드셰이크가 연결마다 새로운 키를 만들어요.
• SRTP 키 파생. 미디어 키는 DTLS 핸드셰이크에서 파생되고 미디어 트랙마다 고유해요.
• 재연결. 세션이 중단되었다가 다시 연결되면 완전히 새로운 키 교환이 이루어져요.

§05 · 인증과 페어링

Remio는 전통적인 사용자 이름/비밀번호 인증을 의도적으로 피해요. 대신 원격 데스크톱 소프트웨어에서 가장 흔한 공격 경로를 없애는 PIN 기반 기기 페어링 모델을 써요.

PIN 기반 페어링

클라이언트가 처음으로 호스트에 연결하려 할 때 과정은 이렇게 진행돼요.

1. 호스트가 화면에 짧은 숫자 PIN(또는 QR 코드)을 표시해요.
2. 클라이언트가 PIN을 입력하면 시그널링 채널을 통해 호스트로 전송돼요.
3. 호스트가 PIN을 확인하고 페어링을 승인하거나 거부해요.
4. 성공하면 기기 신뢰 관계가 만들어져요.
5. 같은 기기에서의 이후 연결은 다시 페어링할 필요가 없어요.

기기 신뢰 모델

페어링되면 각 기기는 고유한 기기 ID로 식별돼요. 호스트는 신뢰하는 기기의 목록을 로컬에 유지해요. 이 신뢰 관계는 다음과 같아요.

• 호스트 기기에만 로컬로 저장돼요. Mac에서는 키체인, Windows에서는 암호화된 시스템 저장소, Linux에서는 비공개 파일처럼 각 시스템이 제공하는 보호된 저장소에 보관해요.
• 전송되지 않아요. 서버는 어떤 기기가 신뢰받는지 알지 못해요.
• 철회할 수 있어요. 호스트는 언제든 신뢰하는 기기를 제거할 수 있어요.

세션 토큰(JWT)

페어링 후에는 수명이 짧은 서명된 토큰(24시간 만료)이 시그널링 서버 인증에 쓰여요.

이 토큰은 방 생성과 메시지 중계를 위해 기기를 시그널링 서버에 인증해요. 별도의 DTLS 핸드셰이크로 보호되는 세션 내용에 대한 접근 권한은 부여하지 않아요.

AI 에이전트 접근 (Remio MCP 서버)

Remio는 같은 신뢰 모델을 AI 에이전트로 확장하고 있어요. Claude Code, Codex, Claude 앱 같은 도구가 Remio MCP 서버를 통해 내 컴퓨터를 원격으로 조작할 수 있고, 보안 경계는 사람이 쓰는 클라이언트가 넘는 경계와 똑같아요.

• 모든 것은 내 로그인으로 제한돼요. 에이전트는 내가 인증한 계정(OAuth를 통한 Google 또는 Apple 로그인)에 페어링되어 있고 온라인인 호스트에만 접근할 수 있어요. 인증된 계정이 없으면 도구도 없어요.
• Remio는 중개자이지 조작자가 아니에요. MCP 서버의 유일한 역할은 인증된 계정으로 범위가 정해진 도구 모음을 내가 연결하기로 한 AI 도구에 전달하는 거예요. Remio는 스스로 내 컴퓨터와 세션을 시작할 수 없어요. 호스트는 위의 기기 신뢰 모델과 똑같이 내 계정의 승인 증명을 제시하는 연결만 받아요.
• 같은 암호화된 전송. 에이전트 세션도 §04에서 설명한 것과 같은 종단간 암호화 채널을 타요. 저희 서버는 여전히 암호화된 덩어리만 보고, §06의 제로 날리지 속성이 그대로 적용돼요.
• 보이고, 끌 수 있고, 기록돼요. 에이전트 세션은 실행되는 동안 호스트에 표시되고, 비상 정지 스위치로 즉시 끝낼 수 있으며, 로컬 감사 로그에 기록돼요.

§06 · 제로 날리지 설계

Remio에서 제로 날리지는 홍보 용어가 아니라 아키텍처 제약이에요. 저희 시스템은 세션 내용이 Remio, 직원, 그 밖의 제3자에게 구조적으로 접근 불가능하도록 설계되어 있어요.

저희 서버가 볼 수 있는 것

• 연결하는 기기의 IP 주소(네트워킹에 필요해요).
• 연결 타임스탬프.
• 기기 ID(개인 정보와 연결되지 않는 불투명한 식별자).
• 시그널링 메타데이터: SDP offer/answer 교환, ICE 후보.

저희 서버가 볼 수 없는 것

• 화면 내용 — 영상 프레임은 SRTP로 종단간 암호화돼요.
• 오디오 — 영상과 같은 SRTP 암호화예요.
• 입력 이벤트 — 마우스, 키보드, 터치는 DTLS로 암호화돼요.
• 커서 위치 — 암호화된 데이터 채널로 전송돼요.
• 파일 내용 — 모든 파일 전송은 암호화된 채널로 이루어져요.
• 클립보드 데이터 — 암호화된 데이터 채널로 전송돼요.
• 앱 상태 — 어떤 앱을 실행 중인지, 무엇을 작업 중인지.

데이터 보관 정책

P2P 아키텍처 덕분에 사실상 보관할 것이 없어요.

• 세션 내용. 저장하지 않아요. 실시간 스트림뿐이에요.
• 시그널링 로그. 연결 메타데이터는 디버깅을 위해 최대 30일간 보관하고 삭제해요. 세션 내용은 포함되지 않아요.
• 사용자 계정. 계정이 필요 없어요. 선택 사항인 Firebase Auth 데이터는 Google의 인프라에서 관리되고 사용자가 삭제할 수 있어요.
• 기기 정보. 각 기기에 로컬로 저장돼요. 로그인을 선택하면 기기 목록이 계정에 동기화돼요(개인정보 처리방침 참고).

P2P 우선 데이터 흐름

대부분의 연결(NAT 통과에 성공하는 경우)에서 데이터는 서버를 거치지 않고 기기 사이를 직접 오가요.

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

TURN 릴레이로 대체되는 경우에도 릴레이 서버는 암호화된 패킷만 다뤄요. 단순한 통로 역할만 하고 데이터를 복호화하거나, 들여다보거나, 수정할 수 없어요.

§07 · 네트워크 보안

P2P 연결 설정

Remio는 ICE(Interactive Connectivity Establishment) 프로토콜로 기기 사이의 가장 좋은 연결 경로를 찾아요.

1. 호스트 후보 — 같은 네트워크에서의 직접 LAN 연결.
2. 서버 리플렉시브 후보(STUN) — STUN 서버로 공용 IP를 알아내는 NAT 통과.
3. 릴레이 후보(TURN) — 직접 연결을 맺을 수 없을 때 쓰는 암호화 릴레이.

ICE 에이전트는 모든 후보 쌍을 동시에 테스트해서 지연 시간이 가장 낮고 가장 안정적인 경로를 선택해요. 직접 P2P를 항상 우선해요.

설정 가능한 전송 정책

연결은 기본적으로 직접 P2P를 우선하고 암호화 릴레이로 자동 전환돼요. 모든 트래픽을 릴레이로 보내거나 LAN 탐색을 아예 건너뛰는 더 엄격한 정책은 폐쇄적인 네트워크 환경에서 쓸 수 있어요.

요청 속도 제한

시그널링 서버는 악용을 막기 위해 강력한 요청 속도 제한을 적용해요.

만료된 속도 제한기는 5분 간격으로 10분 TTL에 따라 자동으로 정리되어, 분산 공격으로 인한 메모리 고갈을 막아요.

DDoS 방어

시그널링 인프라는 Cloudflare가 보호하며 다음을 제공해요.

• 전 세계 엣지 네트워크를 갖춘 애니캐스트 DNS.
• 3, 4, 7계층 DDoS 완화.
• 웹 애플리케이션 방화벽(WAF).
• 트래픽이 원본에 닿기 전에 엣지에서 하는 요청 속도 제한.
• 봇 탐지와 확인 페이지.

§08 · 클라이언트 보안

Remio는 각 운영체제의 전체 보안 스택을 활용해서 로컬 데이터를 보호하고 애플리케이션의 무결성을 보장해요.

macOS

• 키체인 통합. 모든 민감한 데이터(기기 신뢰 토큰, JWT)는 사용자의 로그인 자격 증명과 하드웨어 암호화로 보호되는 macOS 키체인에 저장돼요.
• 앱 샌드박스. Remio는 최소한의 권한만 가진 샌드박스 환경에서 실행돼요. 화면 캡처와 손쉬운 사용은 사용자의 명시적 승인이 필요해요.
• 코드 서명. 모든 빌드는 Apple Developer 인증서로 서명돼요.
• 공증. macOS 빌드는 Apple의 공증을 거쳐 알려진 악성 코드가 없음을 확인받아요.
• 강화된 런타임. 프로덕션 빌드에서 코드 인젝션, 라이브러리 하이재킹, 디버깅을 막아요.

iOS

• App Transport Security(ATS). 모든 네트워크 연결은 HTTPS/TLS를 써야 해요. 예외는 설정하지 않았어요.
• 데이터 보호. 키체인 항목은 기기가 자체 하드웨어에서 파생한 키로 암호화되고, 이 기기에서만 사용으로 표시된 항목은 백업에서도 기기 밖으로 나가지 않아요.
• 키체인 서비스. 기기 자격 증명은 kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly 보호 클래스로 iOS 키체인에 저장돼요.
• App Store 심사. 모든 iOS 빌드는 Apple의 보안 심사 과정을 통과해요.
• 백그라운드 데이터 없음. 앱은 백그라운드에서 데이터를 수집하거나 전송하지 않아요.

코드 서명 & 검증

# Verify Remio macOS binary — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · 사고 대응

보안 이력

2026년 2월 기준으로 Remio는 보안 침해나 사고 이력이 없어요. 제로 날리지 아키텍처는 공격 표면을 크게 줄여요. 노릴 만한 자격 증명이나 세션 데이터의 중앙 데이터베이스가 없어요.

취약점 신고

보안 연구자의 책임 있는 공개를 환영해요. 잠재적인 취약점을 발견하셨다면 다음 절차를 따라 주세요.

1. 자세한 설명과 함께 security@remio.net으로 메일을 보내 주세요.
2. 해당하는 경우 재현 단계를 포함해 주세요.
3. 48시간 안에 접수를 확인해요.
4. 확인된 취약점은 30일 안에 해결하는 것을 목표로 해요.
5. 익명을 원하지 않는 한 신고자는 보안 변경 내역에 이름이 기재돼요.

책임 있는 공개 정책

• 공개하기 전에 90일의 공개 유예 기간을 요청드려요.
• 선의로 행동한 연구자에게는 법적 조치를 취하지 않아요.
• 심각도에 따라 수정 우선순위를 정해요. 치명적, 높음, 중간, 낮음 순이에요.
• 정식 버그 바운티 프로그램은 로드맵에 있어요.

사고 대응 절차

보안 문제가 확인되면 다음 순서로 진행해요.

1. 차단. 1시간 안에 영향을 받은 시스템을 격리해요.
2. 평가. 24시간 안에 범위와 영향을 파악해요.
3. 통지. 72시간 안에 영향을 받은 사용자에게 알려요(GDPR 준수).
4. 복구. 자동 업데이트 인프라를 통해 패치를 배포해요.
5. 사후 분석. 투명성 보고서를 공개해요.

§10 · 규정 준수

GDPR 준비 상태

Remio의 제로 날리지 아키텍처는 데이터 수집을 기술적으로 가능한 최소한으로 줄이기 때문에 본질적으로 GDPR에 우호적이에요.

• 데이터 최소화. 연결을 맺는 데 필요한 것만 수집해요.
• 삭제권. 사용자 콘텐츠를 저장하지 않으므로 삭제할 것이 없어요. 선택 사항인 계정 데이터는 요청 시 삭제할 수 있어요.
• 데이터 이동성. 기기 신뢰 데이터는 로컬에 저장되고 사용자가 관리해요.
• 동의. PIN 페어링은 각 기기에 대한 명시적인 동의 절차예요.
• 콘텐츠의 국경 간 이전 없음. P2P 연결은 데이터를 기기 사이에만 두고, 저희 인프라로 들어오지 않아요.

SOC 2

아직 갖추지 못한 것

• 독립적인 보안 감사 — 제3자의 침투 테스트나 코드 검토는 아직 받지 않았어요.
• SOC 2 Type I — 아직 보고서가 없어요.
• SOC 2 Type II — 아직 보고서가 없어요.
• 버그 바운티 프로그램 — 정식 책임 있는 공개 보상 제도.

데이터 상주 위치

Remio는 P2P를 우선하기 때문에 세션 데이터는 기기가 있는 곳에 있어요. 데이터는 기기 사이의 직접 연결을 벗어나지 않아요. 시그널링 서버(Cloudflare와 DigitalOcean에서 호스팅)는 연결 메타데이터만 처리하고, 이 메타데이터는 어떤 개인 정보와도 연결되지 않아요.

§11 · 대안과 비교

원격 데스크톱 업계는 세간의 이목을 끈 보안 침해로 몸살을 앓아 왔어요. Remio의 아키텍처가 중앙집중형 대안과 근본적으로 어떻게 다른지 보여 드릴게요.

중앙집중형 아키텍처가 실패하는 이유

중앙집중형 원격 데스크톱 서비스의 근본적인 문제는 한 번의 침해가 모든 사용자를 위협할 수 있다는 점이에요. 2024년 2월 AnyDesk의 프로덕션 서버가 침해되었을 때 공격자는 코드 서명 인증서를 훔쳤고, 정식 AnyDesk 소프트웨어로 위장한 악성 코드를 배포할 수 있게 되었을 가능성이 있어요. 모든 사용자의 비밀번호를 재설정해야 했어요.

2024년 6월 러시아 국가 지원 그룹 APT29가 TeamViewer의 사내 네트워크를 침해했을 때, 중앙집중형 아키텍처에서는 업체가 세션에 접근할 기술적 능력을 가지고 있기 때문에 제품 자체의 무결성에 대한 의문이 제기됐어요.

Remio는 이런 유형의 공격을 근본적으로 없애요. 시그널링 서버가 침해되어도 얻을 수 있는 것은 연결 메타데이터뿐이에요. 훔칠 자격 증명도, 접근할 세션도, 사용자의 기기를 노리는 악성 소프트웨어에 서명하는 데 쓸 수 있는 인증서도 없어요.

§12 · 맺음말

Remio의 보안은 제품에 덧붙인 기능 모음이 아니라 첫날부터 내린 아키텍처 결정의 결과예요. 중앙집중형 대신 P2P를, 비밀번호 대신 PIN 페어링을, 데이터 수집 대신 제로 날리지를 선택해서 보안이 선택형 업그레이드가 아니라 기본 상태인 원격 데스크톱을 만들었어요.

저희는 개인정보 보호는 선택 사항이 아니며, 신뢰는 이용약관으로 요구하는 것이 아니라 투명성으로 얻어야 한다고 믿어요. 이 백서도 그 약속의 일부예요.

문의, 기업 보안 검토, 취약점 신고는 다음으로 연락해 주세요.

• 보안 문의: security@remio.net
• 기업 영업: enterprise@remio.net
• 일반 문의: hello@remio.net