Remio 的安全架構，直白說明。

§01 · 摘要

Remio 是一款建立在零知識、點對點架構上的遠端桌面應用程式。螢幕內容、輸入資料與音訊串流，使用業界標準的 DTLS-SRTP 在裝置之間做端對端加密——也就是每一個以 WebRTC 為基礎的產品所依賴的同一套安全模型。與集中式的解決方案不同，Remio 的連線伺服器只協助建立最初的連線——它絕不會看到、處理或儲存連線資料。

不需要帳號、沒有可被入侵的密碼、沒有集中的憑證資料庫。裝置配對使用 QR 碼，或從主機自己的螢幕上讀取的裝置 ID 與 PIN，而且所有連線金鑰都是短暫的，並具備完美前向保密：即使有一把金鑰外洩，過去與未來的連線在密碼學上依然安全。這個架構消除了整類長期困擾競爭對手的攻擊——因為根本沒有東西可以偷。

§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 驗證後才受到信任。作業系統層級的保護（沙箱，以及各系統的受保護儲存空間，例如鑰匙圈）會保護裝置上的資料。
2. 網路邊界。所有傳輸中的資料都經過加密。我們假設網路是有敵意的。
3. 伺服器邊界。我們自己的伺服器被視為不受信任的中繼。它們協助建立連線，但無法檢視內容。

§03 · 架構概覽

Remio 把連線通道（連線設定）與資料通道（串流）分開。這種分離是我們零知識設計的根本——幫你連線的伺服器，絕不會碰到你所交換的資料。

連線通道與資料通道

連線伺服器唯一的職責，是在連線設定期間，於裝置之間中繼 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 App 這類工具，可以透過 Remio MCP 伺服器遠端操作你的電腦——而安全邊界，與真人用戶端所跨越的邊界完全相同：

• 一切都由你的登入把關。代理只能連到在線上、且與你所驗證的帳號配對的主機（透過 OAuth 以 Google 或 Apple 登入）。沒有驗證過的帳號，就沒有工具。
• Remio 是中介，不是操作者。MCP 伺服器唯一的工作，是提供一組僅限於你已驗證帳號範圍的工具，並交給你選擇連接的 AI 工具。Remio 無法自行與你的電腦開始連線——主機只接受出示了你帳號授權證明的連線，就像上面的裝置信任模型一樣。
• 同樣的加密傳輸。代理連線使用 §04 所述的同樣端對端加密通道。我們的伺服器仍然只會看到加密的資料——§06 中的零知識特性完全適用。
• 看得見、停得下來、有稽核。代理連線在執行時會顯示在主機上，可以用緊急停止開關立即終止，並記錄在本機的稽核記錄中。

§06 · 零知識設計

在 Remio，零知識不是行銷術語——而是架構上的限制。我們的系統經過設計，讓連線內容對 Remio、它的員工或任何第三方，在結構上都無法存取。

我們的伺服器看得到什麼

• 連線裝置的 IP 位址（網路連線所必需）。
• 連線時間戳記。
• 裝置 ID（不透明的識別碼，與個人資訊無關）。
• 連線中繼資料：SDP offer/answer 交換、ICE 候選。

我們的伺服器看不到什麼

• 螢幕內容——影像畫面採用 SRTP 端對端加密。
• 音訊——與影像相同的 SRTP 加密。
• 輸入事件——滑鼠、鍵盤、觸控都採用 DTLS 加密。
• 游標位置——透過加密的資料通道傳送。
• 檔案內容——任何檔案傳輸都透過加密通道進行。
• 剪貼簿資料——加密的資料通道。
• 應用程式狀態——你正在執行哪些 App、正在做什麼。

資料保留政策

由於我們的 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. 主機候選——在同一個網路上的直接區域網路連線。
2. 伺服器反射候選（STUN）——透過 STUN 伺服器做 NAT 穿透，以探索公用 IP。
3. 中繼候選（TURN）——無法建立直接連線時使用的加密中繼。

ICE 代理會同時測試所有候選配對，並選出延遲最低、最可靠的路徑。永遠優先採用直接 P2P。

可設定的傳輸政策

連線預設優先採用直接 P2P，並自動退回加密中繼。針對受到嚴格管制的網路環境，也提供更嚴格的政策——強制所有流量都經過中繼，或完全略過區域網路探索。

速率限制

連線伺服器實施積極的速率限制，以防止濫用：

過期的速率限制器會每 5 分鐘自動清理一次，存活時間為 10 分鐘，以防止分散式攻擊造成記憶體耗盡。

DDoS 防護

我們的連線基礎設施由 Cloudflare 保護，提供：

• 搭配全球邊緣網路的 Anycast DNS。
• 第 3、4 與 7 層的 DDoS 緩解。
• 網頁應用程式防火牆（WAF）。
• 在流量抵達來源之前，於邊緣進行速率限制。
• 機器人偵測與挑戰頁面。

§08 · 用戶端安全

Remio 運用每個作業系統完整的安全技術堆疊，來保護本機資料並確保應用程式的完整性。

macOS

• 鑰匙圈整合。所有敏感資料（裝置信任權杖、JWT）都儲存在 macOS 鑰匙圈中，由使用者的登入憑證與硬體加密保護。
• App 沙箱。Remio 在權限最小的沙箱環境中執行。螢幕擷取與輔助使用，需要使用者明確核准。
• 程式碼簽署。所有版本都以 Apple 開發者憑證簽署。
• 公證。macOS 版本經過 Apple 公證，確認不含已知的惡意軟體。
• 強化的執行環境。在正式版本中，防止程式碼注入、函式庫劫持與偵錯。

iOS

• App Transport Security（ATS）。所有網路連線都必須使用 HTTPS/TLS。沒有設定任何例外。
• 資料保護。鑰匙圈項目以裝置從自身硬體衍生的金鑰加密，標記為僅限此裝置的項目絕不會離開裝置，連備份也不會。
• 鑰匙圈服務。裝置憑證以 kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly 保護等級，儲存在 iOS 鑰匙圈中。
• App Store 審查。所有 iOS 版本都通過 Apple 的安全審查流程。
• 沒有背景資料。App 在背景時不會蒐集或傳送資料。

程式碼簽署 & 驗證

# 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

尚未具備

• 獨立資安稽核——目前還沒有進行第三方滲透測試或程式碼審查。
• 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