§01 · 执行摘要
Remio 是一款基于零知识、点对点架构构建的远程桌面应用。屏幕内容、输入数据和音频流在设备之间采用业界标准的 DTLS-SRTP 做端到端加密,这与所有基于 WebRTC 的产品所依赖的安全模型相同。与中心化的方案不同,Remio 的信令服务器只协助建立初始连接,它从不查看、处理或存储会话数据。
无需账号,没有可被攻破的密码,也没有中央凭据数据库。设备配对使用从主机自己屏幕上读出的六位数字码,所有会话密钥都是临时的,并具备完美前向保密:即使某个密钥泄露,过去和将来的会话在密码学上依然安全。这套架构消除了困扰竞争对手的整整几类攻击,因为根本没有什么可偷的。
Remio 无法访问你的数据,原因不在政策,而在数学。这套架构在结构上使得除配对设备之外,任何人都不可能解密会话内容。
§02 · 威胁模型
Remio 的安全架构是针对一组与企业和个人场景下的远程桌面使用相关的威胁情景而设计的。我们明确说明我们防范什么,以及信任边界在哪里。
我们防范的威胁
- 窃听。所有媒体(视频、音频)和数据通道(输入、键盘、光标)分别用 SRTP 和 DTLS 加密。网络上的观察者只能看到加密的数据包,无法重建会话内容。
- 中间人攻击(MITM)。带证书指纹验证的 DTLS 握手可防止被拦截。信令通道使用具备完美前向保密的 TLS 1.3。
- 服务器被攻破。即使我们的信令服务器被完全攻破,攻击者也只能获得连接元数据(IP 地址、时间戳)。会话内容从不经过我们的服务器传输,也从不存储在其上。
- 未经授权的访问。基于 PIN 的配对要求亲身在场,或知道屏幕上显示的 PIN。不存在可被远程访问、可供攻击的凭据数据库。
- 凭据窃取。没有密码,没有账号,没有中央凭据存储。设备信任通过 PIN 配对建立;会话令牌(JWT)有效期很短,并与设备绑定。
- 会话重放。SRTP 内置的重放保护和 DTLS 序列号可防止被截获的数据包被重放。
- 供应链攻击。所有 Remio 二进制文件都经过代码签名。macOS 版本经过 Apple 公证。iOS 版本只通过 App Store 分发。
信任边界
我们的威胁模型明确定义了三条信任边界:
- 设备边界。每台设备只有在 PIN 验证之后才被信任。操作系统级别的保护(沙盒、钥匙串、Secure Enclave)保护设备上的数据。
- 网络边界。传输中的所有数据都经过加密。我们假定网络是不怀好意的。
- 服务器边界。我们自己的服务器被视为不可信的中继。它们协助建立连接,但无法查看内容。
§03 · 架构概览
Remio 把信令平面(连接建立)与数据平面(串流)分开。这种分离是我们零知识设计的根本:帮助你建立连接的服务器,从不接触你们交换的数据。
信令平面与数据平面
信令服务器唯一的职责,是在连接建立期间,在设备之间中继 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-Poly1305 | SDP、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 指纹带外验证
密钥轮换
密钥会在以下节点自动轮换:
- 会话开始。每次连接,新的 DTLS 握手都会生成全新的密钥。
- SRTP 密钥派生。媒体密钥由 DTLS 握手派生,每条媒体轨道各不相同。
- 重新连接。如果会话中断后重新连接,会进行一次全新的密钥交换。
§05 · 身份验证与配对
Remio 有意避开传统的用户名/密码认证,而是采用基于 PIN 的设备配对模型,消除了远程桌面软件中最常见的攻击途径。
基于 PIN 的配对
当客户端首次想要连接主机时,流程如下:
- 主机在屏幕上显示一个简短的数字 PIN(或二维码)。
- 客户端输入该 PIN,PIN 通过信令通道发送给主机。
- 主机验证 PIN,确认或拒绝配对。
- 成功后,建立设备信任关系。
- 同一设备此后的连接无需重新配对。
密码会产生一个中心化的凭据数据库,这是价值极高的攻击目标。配对则需要看到主机自己的屏幕:一个你可以随时更换的六位数字码。没有什么需要集中存放,没有什么可被攻破,也没有什么可被钓鱼。
设备信任模型
一旦配对,每台设备都由唯一的设备 ID 标识。主机在本地维护一份受信任设备的列表。这种信任关系:
- 仅存储在本地的主机设备上,位于操作系统钥匙串中。
- 从不传输:服务器不知道哪些设备受信任。
- 可撤销:主机可以随时移除受信任的设备。
会话令牌(JWT)
配对之后,使用短期有效的签名令牌(24 小时过期)向信令服务器认证。
这些令牌用于向信令服务器认证设备,以便创建房间和中继消息。它们不会授予对会话内容的访问权,会话内容由独立的 DTLS 握手保护。
AI 智能体访问(Remio MCP Server)
Remio 正在把同样的信任模型延伸到 AI 智能体。Claude Code、Codex 或 Claude 应用这样的工具,可以通过 Remio MCP Server 远程操作你的机器,而安全边界与人类客户端跨越的完全相同:
- 一切都由你的登录把关。智能体只能连接在线、且与你认证的账号(通过 OAuth 使用 Google 或 Apple 登录)配对的主机。没有认证的账号,就没有工具。
- Remio 是中间人,不是操作者。MCP 服务器唯一的工作,是暴露一组限定在你已认证账号范围内的工具,并交给你选择连接的 AI 工具。Remio 自己无法与你的机器发起会话:主机只接受出示了你账号授权证明的连接,与上述设备信任模型完全一样。
- 同样的加密传输。智能体会话走的是 §04 中描述的同样的端到端加密通道。我们的服务器仍然只能看到加密的数据块,§06 中的零知识特性原样适用。
- 可见、可终止、可审计。智能体会话运行时会在主机上显示,可以用终止开关立即结束,并记录在本地审计日志中。
§06 · 零知识设计
在 Remio,零知识不是营销术语,而是一条架构约束。我们的系统被设计成,会话内容对 Remio、它的员工或任何第三方在结构上都无法访问。
我们的服务器能看到什么
- 连接设备的 IP 地址(组网所必需)。
- 连接时间戳。
- 设备 ID(不透明的标识符,与个人信息无关)。
- 信令元数据:SDP offer/answer 交换、ICE 候选。
我们的服务器看不到什么
- 屏幕内容:视频帧经 SRTP 端到端加密。
- 音频:与视频一样的 SRTP 加密。
- 输入事件:鼠标、键盘、触控均经 DTLS 加密。
- 光标位置:通过加密的数据通道传输。
- 文件内容:任何文件传输都经由加密通道进行。
- 剪贴板数据:加密的数据通道。
- 应用状态:你正在运行什么应用,正在做什么工作。
如果 Remio 收到法律传票,要求提供某位用户的会话内容,我们没有任何东西可以提交。不是因为我们删除了,而是因为我们从来就没有过。这些数据从不以可解密的形式经过我们的基础设施。
数据保留政策
由于我们的 P2P 架构,实际上没有什么需要保留的:
- 会话内容。从不存储。仅为实时串流。
- 信令日志。连接元数据最多保留 30 天用于调试,然后删除。不包含会话内容。
- 用户账号。无需账号。可选的 Firebase Auth 数据由 Google 的基础设施管理,用户可以删除。
- 设备信息。存储在每台设备本地。如果你选择登录,你的设备列表会同步到你的账号(参见隐私政策)。
P2P 优先的数据流
在大多数连接中(NAT 穿透成功时),数据直接在设备之间流动,不经过任何服务器:
# 最佳情形:直接 P2P
Client <—— DTLS-SRTP(加密)——> Host
↑ 无服务器参与
# 后备:TURN 中继
Client <— DTLS-SRTP —> TURN 服务器 <— DTLS-SRTP —> Host
↑ 仍然是端到端加密
↑ 服务器只能看到加密数据块
即使在 TURN 中继后备的情形下,中继服务器处理的也只是加密数据包。它只是一根哑管道:无法解密、检查或修改数据。
§07 · 网络安全
P2P 连接的建立
Remio 使用 ICE(交互式连接建立)协议,在设备之间找到最佳的连接路径:
- 主机候选:同一网络内的局域网直连。
- 服务器反射候选(STUN):通过 STUN 服务器进行 NAT 穿透,以发现公网 IP。
- 中继候选(TURN):无法建立直连时使用的加密中继。
ICE 代理会同时测试所有候选对,并选择延迟最低、最可靠的路径。始终优先选择点对点直连。
可配置的传输策略
连接默认优先使用点对点直连,并自动退回到加密中继。对于被严格限制的网络环境,还提供更严格的策略:强制所有流量经由中继,或完全跳过局域网发现。
速率限制
信令服务器实施严格的速率限制,以防止滥用:
| 端点 | 限制 | 突发 | 范围 |
|---|---|---|---|
| HTTP 请求 | 100/min | 20 | 每个 IP |
| WebSocket 连接 | 10/min | 3 | 每个 IP |
| 消息 | 100/sec | 150 | 每个连接 |
| 创建房间 | 5/min | 2 | 每台设备 |
过期的速率限制器会每隔 5 分钟自动清理,TTL 为 10 分钟,以防止分布式攻击耗尽内存。
DDoS 防护
我们的信令基础设施由 Cloudflare 保护,提供:
- 带全球边缘网络的 Anycast DNS。
- 第 3、4、7 层 DDoS 缓解。
- Web 应用防火墙(WAF)。
- 在流量到达源站之前,于边缘实施速率限制。
- 机器人检测和质询页面。
§08 · 客户端安全
Remio 利用每个操作系统的完整安全堆栈,来保护本地数据并确保应用的完整性。
macOS
- 钥匙串集成。所有敏感数据(设备信任令牌、JWT)都存储在 macOS 钥匙串中,由用户的登录凭据和硬件加密保护。
- App Sandbox。Remio 在权限极少的沙盒环境中运行。屏幕采集和辅助功能需要用户明确批准。
- 代码签名。所有构建都使用 Apple 开发者证书签名。
- 公证。macOS 构建经过 Apple 公证,确认不含已知的恶意软件。
- 强化运行时。防止正式版构建遭到代码注入、库劫持和调试。
iOS
- App Transport Security(ATS)。所有网络连接都必须使用 HTTPS/TLS。没有配置任何例外。
- Secure Enclave。在可用的情况下,加密密钥在 Secure Enclave 硬件中生成并存储。
- Keychain Services。设备凭据存储在 iOS 钥匙串中,采用
kSecAttrAccessibleWhenUnlockedThisDeviceOnly保护类别。 - 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
2024 年 2 月,AnyDesk 的代码签名证书在一次入侵中被盗。攻击者可以用合法的 AnyDesk 凭据为恶意软件签名。Remio 按设备建立信任的模型意味着,没有可被盗取的中央证书,每一次设备配对都是独立的。
§09 · 事件响应
安全记录
截至 2026 年 2 月,Remio 没有任何安全入侵或事件的历史。我们的零知识架构大大减小了攻击面:没有可供攻击的凭据或会话数据的中央数据库。
漏洞报告
我们鼓励安全研究人员负责任地披露。如果你发现了潜在漏洞:
- 请发邮件到 [email protected],并附上详细说明。
- 如适用,请附上复现步骤。
- 我们会在 48 小时内确认收到。
- 我们力争在 30 天内解决已确认的漏洞。
- 除非报告者希望匿名,否则我们会在安全更新日志中致谢。
负责任披露政策
- 我们请求在公开披露之前,留出 90 天的披露窗口。
- 对于善意行事的研究人员,我们不会采取法律行动。
- 我们按严重程度确定修复的优先级:严重、高、中、低。
- 正式的漏洞赏金计划已在我们的路线图上。
事件响应流程
一旦确认出现安全问题:
- 遏制。在 1 小时内隔离受影响的系统。
- 评估。在 24 小时内确定范围和影响。
- 通知。在 72 小时内通知受影响的用户(符合 GDPR)。
- 修复。通过自动更新基础设施发布补丁。
- 复盘。发布透明度报告。
§10 · 合规
GDPR 准备情况
Remio 的零知识架构天然对 GDPR 友好,因为我们把数据收集压缩到了技术上绝对必需的最低限度:
- 数据最小化。我们只收集建立连接所必需的内容。
- 被遗忘权。由于我们不存储用户内容,没有什么可删除的。可选的账号数据可应要求删除。
- 数据可携带。设备信任数据存储在本地,由用户掌控。
- 同意。PIN 配对是针对每台设备的明确同意机制。
- 内容不跨境传输。P2P 连接让数据只在设备之间流动,从不进入我们的基础设施。
SOC 2 路线图
SOC 2 Type II 认证在我们 2026–2027 年的路线图上。我们目前正在建立审计流程所需的组织控制措施和文档。对于现在就需要合规文档的企业客户,请联系我们的团队,获取详细的安全问卷回复。
计划中的合规里程碑
- 独立安全审计:专业的渗透测试和代码审查,计划于 2026 年进行。
- SOC 2 Type I:初步的组织控制措施评估。
- SOC 2 Type II:持续的合规验证。
- 漏洞赏金计划:正式的负责任披露奖励。
数据驻留
由于 Remio 以 P2P 为先,会话数据就存放在你的设备所在之处。你的数据从不离开你设备之间的直接连接。信令服务器(托管在 Cloudflare 和 DigitalOcean)只处理连接元数据,而且这些元数据与任何个人信息都没有关联。
§11 · 与其他方案的对比
远程桌面行业一直饱受重大安全入侵事件的困扰。下面是 Remio 的架构与中心化方案的根本区别。
| 方面 | AnyDesk | TeamViewer | Parsec | Remio |
|---|---|---|---|---|
| 架构 | 中心化 | 中心化 | 中心化(Unity) | 点对点优先 |
| 是否需要账号 | 需要 | 需要 | 需要 | 不需要 |
| 数据路由 | 厂商服务器 | 厂商服务器 | 厂商服务器 | 点对点直连 |
| 端到端加密 | TLS(服务器持有密钥) | TLS(服务器持有密钥) | DTLS-SRTP | DTLS-SRTP |
| 零知识 | 不需要 | 不需要 | 部分 | 完全 |
| 已知入侵事件 | 2024 年 2 月 | 2024 年 6 月 | 无公开记录 | 无 |
| 入侵的影响 | 所有用户(证书被盗) | 企业网络(APT29) | — | 仅限单台设备 |
| 厂商访问数据 | 可能 | 可能 | 可能(Unity) | 不可能 |
为什么中心化架构会失败
中心化远程桌面服务的根本问题在于,一次入侵就可能危及所有用户。2024 年 2 月,AnyDesk 的生产服务器遭到入侵,攻击者盗取了代码签名证书,有可能借此发布伪装成合法 AnyDesk 软件的恶意软件。所有用户的密码都不得不重置。
2024 年 6 月,APT29(一个有俄罗斯国家背景的组织)入侵了 TeamViewer 的企业网络,这引发了对产品本身完整性的疑问:因为中心化的架构意味着厂商在技术上有能力访问会话。
Remio 彻底消除了这一类攻击。我们的信令服务器被攻破,也只会泄露连接元数据。没有凭据可偷,没有会话可访问,也没有可用来签署针对我们用户设备的恶意软件的证书。
§12 · 结论
Remio 的安全不是附加在产品上的一堆功能,而是从第一天起就做出的架构决策的结果。选择 P2P 而不是中心化,选择 PIN 配对而不是密码,选择零知识而不是数据收集,我们打造出了一款安全是默认状态、而不是可选升级的远程桌面。
我们相信,隐私不是可选项,信任应通过透明来赢得,而不是靠服务条款来索取。这份白皮书正是这一承诺的一部分。
如有疑问、需要企业安全审查,或要报告漏洞:
- 安全咨询: [email protected]
- 企业销售: [email protected]
- 一般咨询: [email protected]