安全性:保護什麼,不保護什麼

基本原則

LiveSSH 從你的裝置直接透過 SSH 連線到你指定的伺服器。你的連線資訊不會經過 LiveSSH 伺服器。

開啟 LiveSSH Cloud(付費)後,主機、程式碼片段、SSH 金鑰等項目會先在裝置上加密再同步。解密金鑰只能由你的主密碼與復原金鑰產生。這種設計稱為端對端加密,也叫零知識。

保管庫的加密方式

同步的項目依下列方式保護:

• 每個項目在裝置上使用隨機產生的資料金鑰,以 XChaCha20-Poly1305(驗證式加密)加密。
• 資料金鑰由主密碼經 Argon2id(記憶體 64 MiB,迭代 3 次)衍生出的金鑰包裹後保存。
• 同一把資料金鑰也會以復原金鑰另外包裹一次。復原金鑰是 52 個字元的 base32 字串,透過 HKDF 衍生金鑰。
• 包裹後的資料金鑰以 keyset(JSON)的形式儲存在伺服器上。
• 變更主密碼時只會重新包裹 keyset。項目維持不變,復原金鑰也仍然有效。

復原金鑰

若忘記主密碼,可以用復原金鑰開啟保管庫並設定新的主密碼。

若主密碼與復原金鑰都遺失,任何人都無法復原你的資料。伺服器上沒有解密所需的金鑰,我們也不例外。復原金鑰需要你自行妥善保管。

伺服器儲存的內容

LiveSSH Cloud 伺服器是自行代管的 Supabase。它儲存的內容如下:

資料庫透過資料列層級的存取控制依帳號隔離,與伺服器之間的通訊受 TLS 保護。保存期限與受託處理者請見隱私權政策。

主機金鑰固定(TOFU)

第一次連線到伺服器時,App 會顯示其主機金鑰指紋(SHA-256),你確認後就會與該主機一併儲存(Trust On First Use,首次使用即信任)。

之後若指紋改變,App 會拒絕連線並發出警告。可能是伺服器被更換,也可能是連線遭到中間人攔截。你可以在主機的編輯畫面重設已儲存的指紋。

第一次連線時的指紋是否真實,仍須由你自行判斷;TOFU 無法防禦首次連線當下發生的攻擊。

推播通知包含的內容

推播通知走的是與加密保管庫不同的路徑。伺服器上的通知 hook 會把通知傳給 LiveSSH 伺服器,再由 LiveSSH 伺服器透過 Google Firebase Cloud Messaging(iOS 則經由 Apple Push Notification service)送達你的裝置。

通知包含標題、內文(例如代理給出的確認要求文字,最多 300 個字元)、tmux 工作階段名稱與主機標籤。在這條路徑上並非端對端加密,因此會經過 LiveSSH 伺服器以及 Google 或 Apple。伺服器的設計是不將通知內文寫入記錄。如果代理的確認要求可能包含敏感內容,請不要開啟通知功能。

當機報告

只有在你首次啟動時同意的情況下,當機報告才會傳送到 Firebase Crashlytics,並且可以隨時在 設定 → 安全性 中關閉。關閉後,尚未傳送的報告會被刪除。

報告包含當機原因(堆疊追蹤)、作業系統與 App 版本以及裝置型號。錯誤訊息只保留第一行,並在傳送前遮蔽 IP 位址、電子郵件地址、路徑與主機名稱。不會包含主機位址、使用者名稱、指令、終端機輸出、檔名與金鑰。App 不使用廣告 SDK 與使用情況分析 SDK。

這種設計無法防護的情況

• 感染惡意軟體的裝置或處於解鎖狀態的裝置,App 無法保護。保管庫開啟期間,App 會處理已解密的資料;若啟用生物辨識解鎖,主密碼會存放在裝置的安全儲存空間中。
• 弱主密碼容易遭到暴力破解。Argon2id 只是讓每次嘗試變慢,並不能阻止嘗試。
• LiveSSH 伺服器看得到項目類型、ID、時間戳記與項目數量等中繼資料。
• SSH 伺服器端的安全(金鑰管理、伺服器遭入侵、通知 hook 權杖在伺服器上的保管)由你與伺服器管理員負責。
• App 的原始碼並未公開,也未經過第三方安全稽核。本頁的說明由開發者撰寫,並未經過獨立驗證。

回報安全問題

若你發現漏洞,或發現行為與本頁描述不一致,請來信 contact@xiu.kr。