Resilio Sync 系統安全設計模型缺失與風險評估

Resilio Sync 是許多重視隱私的使用者選擇的 P2P 同步工具：沒有中央伺服器、端到端加密、資料只在你的裝置間流動。官方安全文件強調「使用密碼學而非帳號密碼系統」——聽起來更安全。

但這個設計有一個被忽視的代價。

概要

Resilio Sync 以 P2P、端到端加密與不經第三方雲端儲存為賣點，官方安全文件強調其在傳輸與協定層的強度，並宣稱「使用密碼學而非帳號密碼系統」作為核心設計。然而，在身份與信任模型上，產品採用「device / identity key 即身份」的設計，一旦該 key 外洩，攻擊者即可在任意節點完整複製此身份並取得該 identity 下所有分享資料夾的存取權限，等同於將整個系統託付在單一長期憑證上，形成顯著的結構性風險。

本報告分析 Resilio Sync 的安全架構、身份與存取控制模型、其優點與缺陷，並從威脅模型角度說明「前方銅牆鐵壁，後方門戶大開」的情境，提出實務風險控管建議及替代方案思考。

系統與協定安全架構

P2P 與加密傳輸

Resilio Sync 採用分散式 P2P 架構，檔案在節點間直接傳輸，不經中央伺服器儲存內容，官方強調資料僅存在於使用者自有基礎設施，避免第三方雲端被入侵的風險。傳輸層使用 SSL（實作上為 TLS）與 AES-128 進行加密，並搭配 X.509 憑證作為雙向認證與檔案變更驗證機制，確保中間人攻擊與未經授權修改在協定層難以成功。

Resilio 官方的安全與隱私簡報重複強調幾點：資料只在選擇的節點間直接複製、所有傳輸加密、Resilio 不保存內容、不掌握用戶登入／存取紀錄，並以「不持有任何使用者資料」作為主要安全哲學。就傳輸機制與協議選擇而言，這些設計在目前業界屬於相對穩健與主流做法（Resilio 安全與隱私簡報）。

Key 結構與密碼學強度

官方說明中給出標準 folder key 的結構：第一碼代表 key 類型，其餘約 32 字元為 Base32 編碼的 20 bytes 隨機值，並使用 ED25519 與 SHA3 生成非對稱簽章與派生 read-only key、share ID 與 session 加密金鑰（Key structure and flow）。A/B/D/E/F/M 等前綴代表不同用途，包括可讀寫、唯讀與 encrypted node 專用 key，以及 M 類 identity key。

在此設計下，暴力猜測有效 key 或偽造合法簽章在理論上難度極高，實務上可視為不可行，第三方技術分析亦普遍認為密碼學層面本身並非主要弱點，真正風險在於憑證外洩與封閉原始碼帶來的可審計性不足。

身份與信任模型設計

Identity / device key（M key）

在 2.x / 3.x 版本中，Resilio 引入「Sync Identity」概念：首次啟動時使用者輸入一個 identity name，Sync 會為該 instance 產生 X.509 憑證與隨機 fingerprint，此身份用於後續與其他 peer 建立連線與顯示裝置身份。在 Pro / v3 版本中，可以將多台裝置 link 成同一 identity，統一出現在「My devices」列表中，實現所謂 universal access：一旦裝置被連結進同一 identity，該 identity 底下的 Sync folders 會自動在所有這些裝置上可用（Sync Private Identity & Linking My Devices）。

官方文件明確說明：若將某裝置的 M key 取出並放入另一裝置，後者會「取得前者的 identity name、fingerprint，並取得該 identity 所配置的所有 shares」，等同於在第二台機器上完整複製第一台的 Sync 身份與權限。這意味著 identity / device key 是一把高權限、可完全複製身份的長期憑證。

Folder key 與 link 模型

在標準 folder 同步中，Resilio 使用 A/B/D/E/F 類 key 進行授權：A 為讀寫 key，B 為由 A 派生的 read-only key，D/E/F 則對應 encrypted node 的讀寫／讀取／僅儲存權限。Sync links（btsync:// / link.resilio.com）以 URL 包裝 folder ID、暫時 key、大小估計與到期時間等資訊，用於簡化分享流程，實際授權仍取決於底層 key 與 owner 是否批准連線（Link structure and flow）。

官方分享對話框與安全文件提到，可以設定「看到誰試圖連線並選擇同意或拒絕」，以及在分享對話框中的 security 設定，例如僅允許 link 一次性使用或設定需要 owner 批准新 peer。然而，這些機制主要作用在 folder-level，而非 identity-level。

系統設計的關鍵缺失

1. 身份與授權完全繫於單一長期憑證

在目前設計中，identity / device key（M key）同時扮演「使用者身份」與「裝置身份」，且可被完整複製到任意裝置上，不需額外帳號或第二因子驗證。一旦 M key 或包含該身份憑證的設定檔外洩，攻擊者即可在自己的 Sync instance 上重建同一 identity，並自動取得該 identity 底下「My devices」所能看到的所有 Sync folders 的訪問權限。

官方在「裝置被偷」的處理指引中承認此點（If your device is stolen）：若被偷裝置的磁碟未加密，竊賊可在該裝置上執行 Sync，進而檢視、修改或刪除其他已連結裝置上的資料；此時建議的補救措施是「解除所有裝置與目前 identity 的連結、重新安裝、重新建立新 identity 並重新分享所有資料夾」。這反向說明了 identity 在信任模型中是單一且脆弱的 root trust anchor。

2. 缺乏帳號層與強制 2FA

Resilio Sync 強調「使用密碼學而非帳號密碼系統」，因此並無傳統意義上的帳號登入流程與集中帳號資料庫。雖然企業產品 Resilio Connect 在 Management Console 層面提供本地帳號與 2FA，但那是管理後台登入用，與個人版 Sync 的節點身份驗證是完全不同的層次；在 P2P 節點間，仍完全依賴憑證與 key 來表徵身份，沒有額外第二因子可用。

這導致 identity / device key 實際上扮演了「無法細粒度撤銷的 root API token」角色：一旦外洩，即使使用者本人仍然持有這把 key，系統也無法區分「原主裝置」與「複製出來的惡意裝置」，必須透過全面重建 identity 來重新建立信任邊界。

3. Folder-level 安全選項無法防禦 identity 外洩

分享對話框與安全設定提供若干保護，例如：

• 新 peer 需要 owner 批准後才能開始同步
• link 可設定過期時間與最大使用次數
• 允許設定讀寫或唯讀權限，以及 selective sync 等控管選項

然而，這些機制假設攻擊者是「持有某個 folder link 或 key 的外部節點」，並未針對「持有完整 identity key 的節點」設計。當攻擊者透過 M key 將自己的裝置 link 進同一 identity 時，系統直接將其視作「My devices」成員，享有 universal access 與自動 share propagation 的好處，因此 folder-level 的 new-peer approval 並非針對這種威脅模型。

換言之，folder 安全選項可以減少「單一 folder key 洩漏」的損失範圍，卻無法緩解「identity / device key 洩漏等於整個同步拓樸失守」的系統性風險。

4. 封閉原始碼與可審計性不足

Resilio Sync 為閉源軟體，安全研究社群多次指出，無法進行完整的程式碼審計與獨立安全驗證，尤其是對 key 管理、協議細節與可能的內建後門難以給出第三方保證（Reddit：Resilio Sync 安全與可疑做法）。

封閉原始碼本身不必然意味不安全，但在搭配前述「單一 identity key 為信任根」與「缺乏帳號層再認證」的架構下，使用者難以獨立驗證是否存在實作層面的 key 洩漏、弱隨機數、憑證 reuse 或其他缺陷。

威脅模型分析

攻擊場景一：裝置被竊或遭惡意複製

在此情境中，攻擊者取得一台已安裝並使用 Resilio Sync 的裝置，或者取得其設定檔與資料目錄的完整備份：

• 若該裝置磁碟未加密，攻擊者可直接啟動現有 Sync instance，或將設定資料移至自己的機器上運行，繼續以合法 peer 身份與其他裝置同步
• 由於該 instance 持有 identity 憑證與指紋，其他裝置無從區分其為合法使用者或竊賊

此時的防禦手段僅剩：於其他裝置停止 Sync、移除本地同步資料、解除所有裝置與目前 identity 的連結，重新安裝並建立新 identity，再重新分享所有資料夾——實際上是全面重建信任網路。

此流程成本高、容易出錯，且在發現與重建前的時間窗中，攻擊者仍可持續讀取或刪改資料。

攻擊場景二：identity / device key 外洩

若使用者以任何方式洩漏 M key（例如誤將含 key 的設定檔備份到公共雲端、透過未加密管道傳輸、被惡意程式讀取），攻擊者可在自己的裝置上執行 Sync，輸入該 key 或還原設定，取得完整 identity：

• 攻擊者裝置將出現在「My devices」清單中，並自動獲得所有該 identity 下 Sync folders 的存取權限
• 即使使用者在 folder-level 設定了新 peer 需批准的選項，對於 identity 內部新裝置的自動分享可能仍適用「自動信任已 linked 裝置」的流程
• 使用者之後新增的任何新 Sync folder，只要設定為在「My devices」間可用，也會自動同步到攻擊者裝置

此種情境下，identity key 成為單點失敗點：一旦外洩，不僅現有資料夾被動暴露，未來所有新資料亦持續外洩，直到 identity 被整體重建。

攻擊場景三：惡意或半信任節點

Resilio Sync 的 P2P 模型只分「持有合法 key 的節點」與「未授權節點」。當使用者將某些資料夾分享給第三方時，若不小心將對方加入為同一 identity（或誤分享 M key），則該節點享有 universal access——等同於授予對方在 Sync 層的超額信任。

Reddit 等論壇中不乏使用者因誤解 device name、user name 與 identity 的差別，而將多位使用者實際運行在同一 identity 底下的案例（Device name/User name/Identity 討論），導致權限邊界模糊。

與其他架構的對照

對比傳統雲端儲存服務

傳統雲端儲存服務雖然在內容儲存上有被雲端供應商入侵的風險，但在身份與信任模型上通常具備：帳號層（Email＋密碼）、多因子驗證（TOTP、SMS、硬體 key）、裝置／session 管理與風險感知登入、session / token 細粒度撤銷。

相比之下，Resilio Sync 刻意避免集中帳號系統與伺服器端狀態，使得身份驗證完全依賴本地憑證，沒有中央控制平面可用於細粒度撤銷或風險偵測，犧牲了部分安全管控能力以換取資料完全不經第三方儲存的優點。

對比 Syncthing

開源替代方案 Syncthing 採用類似的 P2P 模型，同樣透過裝置 ID 與憑證進行節點認證；然而，其開源性使得協定實作可被獨立審計，並允許社群針對信任模型與安全性提出改善建議（Syncthing vs Resilio Sync 比較）。對於高度敏感的使用情境，安全社群更傾向選擇可審計的開源方案，或在 P2P 層外再疊加獨立的端到端加密工具。

風險評估

綜合上述分析，Resilio Sync 的安全性可拆分為兩層：

協定與傳輸層：安全性高 使用成熟密碼學（AES-128、X.509、ED25519、SHA3）與點對點架構，有效降低中間人與集中式雲端被攻擊的風險。在假設密鑰不外洩的情況下，未授權第三方幾乎不可能透過被動監聽或暴力攻擊取得內容。

身份與信任模型層：結構性高風險 將整個身份與授權繫於單一長期 identity / device key，使其成為單點失敗，且缺乏帳號層與 2FA 來分離「誰」與「哪台裝置」。Folder-level 安全選項無法防禦 identity 外洩情境，導致一旦 M key 被複製，攻擊者可在任意節點完全重建身份並持續取得所有新舊同步資料。封閉原始碼與無中央控制平面使得細粒度撤銷與異常偵測困難。

實務防禦與使用建議

1. 將 identity / device key 視為最高敏感憑證

• 不以任何形式截圖、貼到 IM、Email 或未加密備份中，避免誤傳或雲端外洩
• 僅在必要時短暫用於新裝置 link，完成後即刪除包含 key 的中介檔案或訊息
• 若需要搬遷設定，優先在可信任裝置間以安全管道直接複製設定資料夾，而非經第三方服務

2. 強制所有裝置啟用磁碟加密

官方明確指出：若被偷裝置磁碟已加密，竊賊無法存取 Sync 資料；未加密時則可能直接存取並藉此攻擊其他裝置。對於行動裝置與筆電，建議一律開啟全碟加密（BitLocker、FileVault、Android/iOS 預設加密），並設強密碼或生物辨識解鎖。

3. 嚴格區分「My devices」與第三方節點

• 僅將完全受本人控制的裝置 link 進同一 identity
• 對第三方節點一律使用 folder key 分享，尤其是 B 類 read-only key 或 encrypted node 模式，將其限制在單一資料夾或加密內容的消費者角色

4. 定期檢查「My devices」與分享列表

週期性確認「My devices」僅包含預期裝置，並移除不再使用的節點；定期檢視每個 Sync folder 的分享對象與權限設定，避免不必要的讀寫授權擴散。

5. 高敏感資料再加一層端到端加密

對於密碼資料庫、API key、身分證件等高機密檔案，建議先置於獨立加密容器（VeraCrypt、Cryptomator、GPG 加密檔案），再透過 Resilio Sync 同步加密後的容器。如此即便 identity key 被攻陷，攻擊者仍需額外突破容器密碼，形成分層防護。

6. 建立即時應變流程

事先規劃 identity 憑證外洩或裝置被竊時的標準作業程序，依官方指引快速執行：停止 Sync、清除本地資料、解除舊 identity、重建新 identity 並重新分享資料夾。將此流程文件化，避免在事件發生時才臨時摸索。

結語

Resilio Sync 在傳輸與協定層提供了「前方銅牆鐵壁」般的安全性：強加密、無中央儲存、P2P 直連，對抗被動竊聽與雲端平台入侵有明顯優勢。然而，其身份與信任模型卻將整個系統安全高度集中在單一 identity / device key 上，缺乏帳號層與多因子驗證所提供的更細緻信任控制，使得一旦該 key 或裝置設定外洩，後方「門戶大開」，整個同步拓樸與未來資料皆可能被持續監控與操控。

對於重視隱私而風險承受度中等的使用者，Resilio Sync 在妥善的裝置安全與運維紀律下仍然可用；但對風險感知敏銳、持有高價值憑證與敏感資料的專業使用者而言，必須將 identity key 視為 root token，以分層加密、嚴格節點分級與預先應變計畫降低此設計缺陷帶來的系統性風險。

References

1. Can others see my files? - Resilio Help
2. Key structure and flow - Resilio Sync
3. Sync Security and Privacy Brief - Resilio Blog
4. Sync Private Identity & Linking My Devices
5. If your device is stolen - Resilio Sync
6. Link structure and flow - Resilio Sync
7. Resilio / BitTorrent Sync security and shady practices - Reddit
8. Syncthing or Resilio Sync - noted.lol
9. Device name/User name/Identity - Reddit
10. BTSync Keys - E2Encrypted