安全与漏洞赏金

用通俗的话说明数据如何受到保护

配对从电脑上显示的二维码开始。二维码中包含一个两分钟后失效的一次性密钥，因此只有真正看到屏幕的设备才能完成配对。随后两台设备会显示相同的 6 位数字，由您确认两者一致。

• 每个连接都使用 Noise 协议（X25519、ChaCha20-Poly1305、BLAKE2s）进行端到端加密。每台设备都有一把永不离开本机的专属密钥，设备之间依靠这把密钥相互识别，而不是依靠 IP 地址、名称或账号。
• 每个连接、每条数据流都使用全新的密钥（前向保密）：即使日后密钥被盗，也无法解密此前记录的通信。
• 加密位于网络层之上，因此无论是在 Wi-Fi 中、通过互联网（QUIC、TCP 或 WebRTC），还是经由我们的会合服务，保护方式都完全相同。会合服务只转发它无法读取的密封消息。
• 完成配对并不等于拥有全部权限：每台设备只能获得您授予的权限，远程输入和摄像头在每次会话中都需要您的同意。
• 收到的文件、链接和剪贴板数据在使用前都会经过检查：无法逃出下载文件夹，危险类型的链接会被拒绝，大小也有上限。

完整的技术规范和威胁模型记录在我们的安全文档中，可提供给研究人员和审计人员。

审计状态

我们宁可说得准确，也不夸大其词：

• 内部安全审查：已完成。我们依据成文的威胁模型审查了设计、配对、会话加密、权限和输入校验，各项安全规则都由每次变更都会运行的自动化测试覆盖。
• 自动化检查：每次变更都会检查依赖项的安全公告和许可证；读取不可信输入的部分每周进行模糊测试。
• 外部审计：计划在 1.0 版本之前进行，目前尚未开展。完成后，我们会在本页公布审计机构、审计范围和发现问题的摘要。

在此之前，Personal Device Bridge 仍是预览版。将其用于高度敏感的数据之前，请考虑这一点。

验证您下载的文件

下载的文件是否可信，您不必只听我们的一面之词：

• 校验和：每个版本都附带覆盖全部文件的 SHA256SUMS 文件，您可以确认手中的文件与我们发布的完全一致。
• 可复现构建：Linux 命令行工具采用确定性构建。任何拥有对应发布标签源代码的人都可以重新构建，并得到逐位相同的文件；自动检查会在不同环境中构建两次，只要有一个字节不同就判定失败。
• 构建来源证明：我们的发布工作流已配置为给每个文件附加带签名的 SLSA 来源证明（Sigstore），记录它由哪个工作流、哪个提交生成，可用“gh attestation verify”命令验证。源代码仓库公开后 GitHub 才会启用此功能，启用时我们会在本页告知。
• 代码签名：我们的发布流水线会为 Windows 程序和安装包加上 Authenticode 签名（Azure Artifact Signing）；运行前可在文件“属性”→“数字签名”中查看发布者。

Windows 和 Android 版本目前还不能复现构建，相关工作已在计划中。适用于 bash 和 PowerShell 的分步验证说明收录在可复现构建指南中，可应要求提供。

持续测试

所有读取来自其他设备或网络数据的解码器——消息信封、配对链接、设备发现广播、文件名以及各功能的消息——每周都会用 libFuzzer 进行模糊测试，输入数以百万计的畸形数据，以发现崩溃和失效的安全检查。

此外，每次变更都会在 Windows 和 Linux 上运行单元测试、集成测试和端到端测试，其中包括两个真实进程通过网络完成配对并传输文件的测试。

适用范围

如果您在以下范围内发现可能损害用户安全或隐私的问题，请向我们报告：

• 核心引擎：设备身份与密钥存储、二维码配对、加密会话、通信协议、传输层（QUIC、TCP、WebRTC）、设备发现、信任与权限，以及全部功能（文件传输、剪贴板、链接、Continue、MyDrop、SmartPrint、文件浏览、通知、远程输入、摄像头）。
• 应用：pdb 命令行工具、Windows 桌面应用及其安装包、Android 应用。
• 我们为互联网连接运营的会合服务。
• 本网站（personaldevicebridge.com）。
• 我们的发布流程：构建与发布工作流、代码签名、校验和与来源证明。

我们特别关注以下问题：不看二维码即可配对、破解加密或设备认证、已配对设备越权操作、读写预期文件夹之外的文件、通过收到的数据执行代码，以及会合服务获知或篡改消息内容。

不在范围内的情况

• 单纯依靠大流量造成的拒绝服务、对我们托管服务的压力测试，以及垃圾信息。
• 针对我们团队或用户的社会工程、网络钓鱼，以及物理攻击。
• 需要以设备或用户账户已被攻陷为前提的攻击（例如以用户身份运行的恶意软件）、已 root 或越狱的手机，或需要物理接触已解锁设备的攻击。
• 按设计在本地网络中可见的信息，例如设备是否存在、流量大小。
• 安全文档中已经说明的限制，除非您证明其影响更严重。
• 第三方平台自身的缺陷（Cloudflare、Railway、GitHub、Google）请向相应厂商报告；我们使用这些平台的方式所带来的问题属于适用范围。
• 未证明存在安全影响的报告：静态页面缺少响应头、邮件 SPF/DMARC 设置、self-XSS、版本号暴露，或没有概念验证的扫描器结果。

如何报告

请发送邮件至 [email protected]，主题写为“[SECURITY] 简短标题”，使用韩语或英语。请包含以下内容：

• 受影响的应用或组件及其版本；
• 问题是什么，攻击者可以借此做什么（欢迎附上 CVSS 向量）；
• 分步复现方法或概念验证，以及您测试时使用的平台；
• 是否希望署名以及署名方式。

请不要通过公开的 Issue 或社交媒体报告漏洞。

加密：我们尚未公开 PGP 密钥。公开后，密钥将放在本网站的 /.well-known/ 目录中，并写入 security.txt (personaldevicebridge.com/.well-known/security.txt)。在此之前，如果您的报告包含敏感的利用细节，请先发送一封不含这些细节的简短邮件，我们会与您商定安全的沟通渠道。

我们的源代码为专有软件，不对外开放。如果您为研究或确认问题需要查看源代码，请向我们申请，我们会逐一审核。

报告之后的处理流程

• 我们会在 72 小时内确认收到您的报告。
• 我们会在 7 天内完成分级——判断有效性、严重程度和受影响的版本——并在问题解决前至少每 14 天向您通报一次进展。
• 自分级起的修复目标：严重（Critical）30 天内（尽可能在 7 天内提供缓解措施），高危（High）60 天内，中危（Medium）90 天内，低危（Low）在后续的常规版本中修复。

我们是一个小团队。如果无法按目标完成，我们会告诉您原因以及预计的修复时间。

奖励

奖励由我们酌情发放，取决于影响程度、报告质量以及我们此前是否已知该问题；同一问题的首位报告者有资格获得奖励。我们以最新版本为准，使用 CVSS（v3.1 或 v4.0）评定严重程度，并向您说明评定依据。

重复报告、超出范围的问题以及违反本政策的报告不予奖励。多个问题串联利用时，按最终严重程度计为一项发现。

奖励以韩元支付，美元金额仅为近似值。支付需要提供韩国税法和银行要求的信息；法律或制裁禁止的情况下无法支付。您也可以请我们将奖励捐赠给慈善机构。

安全港（免责）

只要您本着善意遵守本政策，我们即视您的研究为经过授权。我们不会因此对您采取或支持任何法律行动，也不会向执法机关举报。如果有第三方因您遵守本政策的研究而对您采取行动，我们会公开说明您的研究已获得我们的授权。

善意行事是指您：

• 只测试您自己的设备、安装实例、配对关系和会合邮箱；
• 不访问、修改或保留他人的数据——如果偶然接触到，请立即停止、告知我们并删除；
• 不干扰我们的服务，也不留下持久性的更改；
• 在公开之前给我们留出修复时间；
• 绝不以不公开为条件索要报酬。

对于不属于我们的系统，我们无权授权测试。如有疑问，请先与我们联系。

协调披露

在公开细节之前，请给我们自报告之日起 90 天的时间（如果修复版本更早发布，则以发布为准）。修复较复杂时，我们可能请求短暂延期，并与您共同商定公开日期。

修复后，我们会在发布说明中发布安全公告，并注明您的贡献，除非您希望匿名。如果问题正被实际利用，我们可能与您协商后提前公开。

供安全工具使用的联系方式

我们的联系方式也以标准的机器可读格式（RFC 9116）发布在 security.txt (personaldevicebridge.com/.well-known/security.txt) 中，并指向本页。我们使用韩语和英语答复。

名人堂

感谢每一位帮助我们守护用户安全的人。报告有效问题的研究人员，经本人同意后将列于此处。

目前还没有入选的报告者——第一位也许就是您。