✦安全白皮书 · v1.1

Remio 的安全架构,直白呈现。

最后更新于 2026-07-17·阅读约 15 分钟·版本 1.1

§01 · 执行摘要

Remio 是一款基于零知识、点对点架构构建的远程桌面应用。屏幕内容、输入数据和音频流在设备之间采用业界标准的 DTLS-SRTP 做端到端加密,这与所有基于 WebRTC 的产品所依赖的安全模型相同。与中心化的方案不同,Remio 的信令服务器只协助建立初始连接,它从不查看、处理或存储会话数据。

无需账号,没有可被攻破的密码,也没有中央凭据数据库。设备配对使用从主机自己屏幕上读出的六位数字码,所有会话密钥都是临时的,并具备完美前向保密:即使某个密钥泄露,过去和将来的会话在密码学上依然安全。这套架构消除了困扰竞争对手的整整几类攻击,因为根本没有什么可偷的。

关键结论

Remio 无法访问你的数据,原因不在政策,而在数学。这套架构在结构上使得除配对设备之外,任何人都不可能解密会话内容。

§02 · 威胁模型

Remio 的安全架构是针对一组与企业和个人场景下的远程桌面使用相关的威胁情景而设计的。我们明确说明我们防范什么,以及信任边界在哪里。

我们防范的威胁

信任边界

我们的威胁模型明确定义了三条信任边界:

  1. 设备边界。每台设备只有在 PIN 验证之后才被信任。操作系统级别的保护(沙盒、钥匙串、Secure Enclave)保护设备上的数据。
  2. 网络边界。传输中的所有数据都经过加密。我们假定网络是不怀好意的。
  3. 服务器边界。我们自己的服务器被视为不可信的中继。它们协助建立连接,但无法查看内容。

§03 · 架构概览

Remio 把信令平面(连接建立)与数据平面(串流)分开。这种分离是我们零知识设计的根本:帮助你建立连接的服务器,从不接触你们交换的数据。

客户端
iOS / macOS 应用
查看端设备
信令
WebSocket 服务器
仅中继,不存储
主机
macOS 主机应用
源设备
图 3.1:P2P 连接的建立。SDP offer/answer 通过 WSS 中继;连接一经建立,信令服务器就不再参与。
信令
TLS 1.3 + ECDHE
WSS 传输
媒体
SRTP / AES-128
视频 + 音频
数据通道
DTLS 1.2+
输入、键盘、光标、配置
图 3.2:数据平面的加密层。三条相互独立的加密管道;其中一条被攻破,并不会连累其他两条。

信令平面与数据平面

信令服务器唯一的职责,是在连接建立期间,在设备之间中继 SDP offer/answer 和 ICE 候选。一旦 P2P 连接建立,信令服务器就不再参与。

服务器无法解析所中继的内容:那是一段只有目标设备才能解读的加密二进制数据块。与基于 JSON 的信令相比,这个二进制协议增加了一层额外的结构,使注入攻击更加困难。

§04 · 加密层

Remio 采用多层加密策略,每条通信通道都使用最适合其需求的密码学协议。

层协议密码 / 曲线涵盖内容
传输DTLS 1.3(旧版应用为 1.2)ECDHE、AES-128输入、键盘、光标、配置、Dock
媒体SRTP(RFC 3711)AES-128 计数器模式 + HMAC-SHA1 认证视频和音频流
信令TLS 1.3(WSS)AES-GCM / ChaCha20-Poly1305SDP、ICE 候选、加入房间
密钥交换ECDHE(PFS)ECDSA P-256 证书所有会话密钥,每次会话

完美前向保密

每个 Remio 会话都会通过 ECDHE 密钥交换生成一组独一无二的临时加密密钥。

密码套件

# 信令:TLS 1.3 密码套件(按优先级排序)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# 媒体:SRTP 保护配置(WebRTC 行业默认)
SRTP_AES128_CM_SHA1_80   # AES-128 计数器模式,HMAC-SHA1-80 认证

# DTLS 证书
自签名 ECDSA(P-256),通过 SDP 指纹带外验证

密钥轮换

密钥会在以下节点自动轮换:

§05 · 身份验证与配对

Remio 有意避开传统的用户名/密码认证,而是采用基于 PIN 的设备配对模型,消除了远程桌面软件中最常见的攻击途径。

基于 PIN 的配对

当客户端首次想要连接主机时,流程如下:

  1. 主机在屏幕上显示一个简短的数字 PIN(或二维码)。
  2. 客户端输入该 PIN,PIN 通过信令通道发送给主机。
  3. 主机验证 PIN,确认或拒绝配对。
  4. 成功后,建立设备信任关系。
  5. 同一设备此后的连接无需重新配对。
为什么不用密码?

密码会产生一个中心化的凭据数据库,这是价值极高的攻击目标。配对则需要看到主机自己的屏幕:一个你可以随时更换的六位数字码。没有什么需要集中存放,没有什么可被攻破,也没有什么可被钓鱼。

设备信任模型

一旦配对,每台设备都由唯一的设备 ID 标识。主机在本地维护一份受信任设备的列表。这种信任关系:

会话令牌(JWT)

配对之后,使用短期有效的签名令牌(24 小时过期)向信令服务器认证。

这些令牌用于向信令服务器认证设备,以便创建房间和中继消息。它们不会授予对会话内容的访问权,会话内容由独立的 DTLS 握手保护。

AI 智能体访问(Remio MCP Server)

Remio 正在把同样的信任模型延伸到 AI 智能体。Claude Code、Codex 或 Claude 应用这样的工具,可以通过 Remio MCP Server 远程操作你的机器,而安全边界与人类客户端跨越的完全相同:

§06 · 零知识设计

在 Remio,零知识不是营销术语,而是一条架构约束。我们的系统被设计成,会话内容对 Remio、它的员工或任何第三方在结构上都无法访问。

我们的服务器能看到什么

我们的服务器看不到什么

零知识检验

如果 Remio 收到法律传票,要求提供某位用户的会话内容,我们没有任何东西可以提交。不是因为我们删除了,而是因为我们从来就没有过。这些数据从不以可解密的形式经过我们的基础设施。

数据保留政策

由于我们的 P2P 架构,实际上没有什么需要保留的:

P2P 优先的数据流

在大多数连接中(NAT 穿透成功时),数据直接在设备之间流动,不经过任何服务器:

# 最佳情形:直接 P2P
Client <—— DTLS-SRTP(加密)——> Host
              ↑ 无服务器参与

# 后备:TURN 中继
Client <— DTLS-SRTP —> TURN 服务器 <— DTLS-SRTP —> Host
                            ↑ 仍然是端到端加密
                            ↑ 服务器只能看到加密数据块

即使在 TURN 中继后备的情形下,中继服务器处理的也只是加密数据包。它只是一根哑管道:无法解密、检查或修改数据。

§07 · 网络安全

P2P 连接的建立

Remio 使用 ICE(交互式连接建立)协议,在设备之间找到最佳的连接路径:

  1. 主机候选:同一网络内的局域网直连。
  2. 服务器反射候选(STUN):通过 STUN 服务器进行 NAT 穿透,以发现公网 IP。
  3. 中继候选(TURN):无法建立直连时使用的加密中继。

ICE 代理会同时测试所有候选对,并选择延迟最低、最可靠的路径。始终优先选择点对点直连。

可配置的传输策略

连接默认优先使用点对点直连,并自动退回到加密中继。对于被严格限制的网络环境,还提供更严格的策略:强制所有流量经由中继,或完全跳过局域网发现。

速率限制

信令服务器实施严格的速率限制,以防止滥用:

端点限制突发范围
HTTP 请求100/min20每个 IP
WebSocket 连接10/min3每个 IP
消息100/sec150每个连接
创建房间5/min2每台设备

过期的速率限制器会每隔 5 分钟自动清理,TTL 为 10 分钟,以防止分布式攻击耗尽内存。

DDoS 防护

我们的信令基础设施由 Cloudflare 保护,提供:

§08 · 客户端安全

Remio 利用每个操作系统的完整安全堆栈,来保护本地数据并确保应用的完整性。

macOS

iOS

代码签名与验证

# 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
为什么这很重要

2024 年 2 月,AnyDesk 的代码签名证书在一次入侵中被盗。攻击者可以用合法的 AnyDesk 凭据为恶意软件签名。Remio 按设备建立信任的模型意味着,没有可被盗取的中央证书,每一次设备配对都是独立的。

§09 · 事件响应

安全记录

截至 2026 年 2 月,Remio 没有任何安全入侵或事件的历史。我们的零知识架构大大减小了攻击面:没有可供攻击的凭据或会话数据的中央数据库。

漏洞报告

我们鼓励安全研究人员负责任地披露。如果你发现了潜在漏洞:

  1. 请发邮件到 [email protected],并附上详细说明。
  2. 如适用,请附上复现步骤。
  3. 我们会在 48 小时内确认收到。
  4. 我们力争在 30 天内解决已确认的漏洞。
  5. 除非报告者希望匿名,否则我们会在安全更新日志中致谢。

负责任披露政策

事件响应流程

一旦确认出现安全问题:

  1. 遏制。在 1 小时内隔离受影响的系统。
  2. 评估。在 24 小时内确定范围和影响。
  3. 通知。在 72 小时内通知受影响的用户(符合 GDPR)。
  4. 修复。通过自动更新基础设施发布补丁。
  5. 复盘。发布透明度报告。

§10 · 合规

GDPR 准备情况

Remio 的零知识架构天然对 GDPR 友好,因为我们把数据收集压缩到了技术上绝对必需的最低限度:

SOC 2 路线图

进行中

SOC 2 Type II 认证在我们 2026–2027 年的路线图上。我们目前正在建立审计流程所需的组织控制措施和文档。对于现在就需要合规文档的企业客户,请联系我们的团队,获取详细的安全问卷回复。

计划中的合规里程碑

数据驻留

由于 Remio 以 P2P 为先,会话数据就存放在你的设备所在之处。你的数据从不离开你设备之间的直接连接。信令服务器(托管在 Cloudflare 和 DigitalOcean)只处理连接元数据,而且这些元数据与任何个人信息都没有关联。

§11 · 与其他方案的对比

远程桌面行业一直饱受重大安全入侵事件的困扰。下面是 Remio 的架构与中心化方案的根本区别。

方面AnyDeskTeamViewerParsecRemio
架构中心化中心化中心化(Unity)点对点优先
是否需要账号需要需要需要不需要
数据路由厂商服务器厂商服务器厂商服务器点对点直连
端到端加密TLS(服务器持有密钥)TLS(服务器持有密钥)DTLS-SRTPDTLS-SRTP
零知识不需要不需要部分完全
已知入侵事件2024 年 2 月2024 年 6 月无公开记录无
入侵的影响所有用户(证书被盗)企业网络(APT29)—仅限单台设备
厂商访问数据可能可能可能(Unity)不可能

为什么中心化架构会失败

中心化远程桌面服务的根本问题在于,一次入侵就可能危及所有用户。2024 年 2 月,AnyDesk 的生产服务器遭到入侵,攻击者盗取了代码签名证书,有可能借此发布伪装成合法 AnyDesk 软件的恶意软件。所有用户的密码都不得不重置。

2024 年 6 月,APT29(一个有俄罗斯国家背景的组织)入侵了 TeamViewer 的企业网络,这引发了对产品本身完整性的疑问:因为中心化的架构意味着厂商在技术上有能力访问会话。

Remio 彻底消除了这一类攻击。我们的信令服务器被攻破,也只会泄露连接元数据。没有凭据可偷,没有会话可访问,也没有可用来签署针对我们用户设备的恶意软件的证书。

§12 · 结论

Remio 的安全不是附加在产品上的一堆功能,而是从第一天起就做出的架构决策的结果。选择 P2P 而不是中心化,选择 PIN 配对而不是密码,选择零知识而不是数据收集,我们打造出了一款安全是默认状态、而不是可选升级的远程桌面。

我们相信,隐私不是可选项,信任应通过透明来赢得,而不是靠服务条款来索取。这份白皮书正是这一承诺的一部分。

如有疑问、需要企业安全审查,或要报告漏洞:

Remio 应用图标

隐私不该是付费功能。

在你想连接的电脑上安装主机,在你用来连接的设备上安装客户端。端到端加密,点对点,无需云账号。上面的架构就是它如今实际发布的样子,而不是未来的方向。