安全:保护什么,不保护什么

基本原则

LiveSSH 从你的设备直接通过 SSH 连接到你指定的服务器。你的连接信息不会经过 LiveSSH 服务器。

开启 LiveSSH Cloud(付费)后,主机、代码片段、SSH 密钥等项目会先在设备上加密再同步。解密密钥只能由你的主密码和恢复密钥生成。这种设计称为端到端加密,也叫零知识。

保险库的加密方式

同步的项目按如下方式保护:

• 每个项目在设备上使用随机生成的数据密钥,以 XChaCha20-Poly1305(认证加密)加密。
• 数据密钥由主密码经 Argon2id(内存 64 MiB,迭代 3 次)派生出的密钥包裹后保存。
• 同一个数据密钥还会用恢复密钥单独包裹一次。恢复密钥是 52 个字符的 base32 字符串,通过 HKDF 派生密钥。
• 包裹后的数据密钥以 keyset(JSON)的形式保存在服务器上。
• 更改主密码时只会重新包裹 keyset。项目保持不变,恢复密钥也继续有效。

恢复密钥

如果忘记主密码,可以用恢复密钥打开保险库并设置新的主密码。

如果主密码和恢复密钥都丢失,任何人都无法恢复你的数据。服务器上没有解密所需的密钥,我们也不例外。恢复密钥需要你自己妥善保管。

服务器保存的内容

LiveSSH Cloud 服务器是自行托管的 Supabase。它保存的内容如下:

数据库通过行级访问控制按账号隔离,与服务器之间的通信受 TLS 保护。保存期限和受托方请见隐私政策。

主机密钥固定(TOFU)

首次连接服务器时,应用会显示其主机密钥指纹(SHA-256),你确认后就会与该主机一起保存(Trust On First Use,首次使用即信任)。

此后如果指纹发生变化,应用会拒绝连接并发出警告。可能是服务器被更换,也可能是连接被中间人拦截。你可以在主机的编辑界面重置已保存的指纹。

首次连接时的指纹是否真实,仍需要你自己判断;TOFU 无法防御首次连接时发生的攻击。

推送通知包含的内容

推送通知走的是与加密保险库不同的路径。服务器上的通知钩子把通知发给 LiveSSH 服务器,再由 LiveSSH 服务器通过 Google Firebase Cloud Messaging(iOS 则经由 Apple Push Notification service)送达你的设备。

通知包含标题、正文(例如代理给出的确认请求文字,最多 300 个字符)、tmux 会话名称和主机标签。在这条路径上不是端到端加密的,因此会经过 LiveSSH 服务器以及 Google 或 Apple。服务器的设计是不把通知正文写入日志。如果代理的确认请求可能包含敏感内容,请不要开启通知功能。

崩溃报告

只有在你首次启动时同意的情况下,崩溃报告才会发送到 Firebase Crashlytics,并且可以随时在 设置 → 安全 中关闭。关闭后,尚未发送的报告会被删除。

报告包含崩溃原因(堆栈跟踪)、操作系统和应用版本以及设备型号。错误信息只保留第一行,并在发送前遮蔽 IP 地址、电子邮件地址、路径和主机名。不会包含主机地址、用户名、命令、终端输出、文件名和密钥。应用不使用广告 SDK 和使用情况分析 SDK。

这种设计无法防护的情况

• 感染恶意软件的设备或处于解锁状态的设备,应用无法保护。保险库打开期间,应用会处理已解密的数据;如果启用生物识别解锁,主密码会保存在设备的安全存储中。
• 弱主密码容易被暴力破解。Argon2id 只是让每次尝试变慢,并不能阻止尝试。
• LiveSSH 服务器可以看到项目类型、ID、时间戳和项目数量等元数据。
• SSH 服务器一侧的安全(密钥管理、服务器被入侵、通知钩子令牌在服务器上的保管)由你和服务器管理员负责。
• 应用源代码未公开,也未经过第三方审计。本页的说明由开发者撰写,并未经过独立验证。

报告安全问题

如果你发现了漏洞,或发现行为与本页描述不一致,请发邮件至 contact@xiu.kr。