CatShare如何保护传输安全？ECDH密钥协商与AES-CTR会话加密全解析

CatShare如何保护传输安全？ECDH密钥协商与AES-CTR会话加密全解析

【免费下载链接】CatShare类原生 & 海外设备，现已加入互传联盟。项目地址: https://gitcode.com/gh_mirrors/ca/CatShare

CatShare 是一款类原生的 Android 蓝牙互传工具，它在使用ECDH 密钥协商与AES-CTR 会话加密保护传输安全的同时，支持向小米、OPPO、vivo 等海外及第三方设备互传文件。很多用户关心：一个不依赖系统特权的应用，如何在开放的无线信道里安全地交换 WiFi 凭据？本文将从零拆解 CatShare 的传输安全机制，帮你快速看懂 ECDH 密钥协商与 AES-CTR 会话加密是如何协作的。

🛡️ 互传场景下的安全隐患：为什么必须加密？

互传的本质是：蓝牙（BLE）协商 → 交换 WiFi 热点凭据 → WiFi 直连传文件。其中蓝牙这一环完全暴露在公共空口上：

💡 核心思路一句话：信道不安全没关系，只传"可以公开的"东西（公钥），私密信息（WiFi 凭据）永远用协商出来的会话密钥加密。

📡 安全架构总览：一次互传的四个阶段

┌─────────────┐ ① BLE 广播 DeviceInfo（含本方 EC 公钥） ┌─────────────┐ │ 接收方设备 │ ◄────────────────────────────────────────── │ 发送方设备 │ │ │ ② 发送方读取公钥，ECDH 协商出共享密钥 │ │ │ │ ③ AES-CTR 加密 SSID/PSK/MAC，经 BLE 写入 │ │ │ │ ◄─────────────────────────────────────────── │ │ │ │ ④ 双方凭共享的 SSID/PSK 建立 WiFi 直连传输 │ │ └─────────────┘ └─────────────┘

整个密钥交换过程没有任何中间服务器参与，两端设备直接完成握手。

🔑 ECDH密钥协商：从公钥到共享密钥

CatShare 的密钥协商实现在 BleSecurity.kt 中，流程如下：

1. 启动即生成密钥对：应用初始化时生成一组 256 位椭圆曲线（EC）公私钥。私钥只存在于内存，重启应用即销毁，从未写入磁盘。
2. 接收方广播公钥：接收方把设备信息（含 Base64 编码的本方公钥）封装为DeviceInfo，通过 BLE 状态特征对外广播，定义见 DeviceInfo.kt。
3. 发送方协商密钥：发送方读取对方公钥后调用deriveSessionKey()（BleSecurity.kt 第 26-35 行），以自身私钥 + 对方公钥执行ECDH（Elliptic-Diffie-Hellman）运算，得到与对方完全相同的共享密钥。
4. 前向保密：因为密钥对每次启动都重新生成，即便某次会话密钥未来被破解，也无法回溯或推导出其他任何会话。

为什么广播公钥是安全的？ECDH 的数学特性保证了：由"我的私钥 + 你的公钥"可以算出共享密钥，但攻击者只有两个公钥，在算力可行范围内无法反推出密钥。这就是"无需信任信道也能建立秘密"的核心。

🔐 AES-CTR会话加密：保护凭据的最后一公里

协商出共享密钥后，CatShare 用它在 SessionCipher 内部类（第 42-56 行）中完成加密，工作模式为AES/CTR/NoPadding：

• 加密对象：P2pInfo中的ssid、psk、mac三个敏感字段（结构定义见 P2pInfo.kt），密文经 Base64 编码后随 JSON 一起经 BLE 写入特征。
• 为什么选 CTR 模式：CTR 模式把分组加密变成流式加密，无填充、无"填充错误"风险，加解密对称且高速，特别适合这类只有几百字节的小数据包；同时收发两端只需一个 Cipher 实例逻辑即可复用。
• IV 的用法：会话内 IV 固定为一组常量字节。由于每次会话的密钥都由新密钥对现场协商、绝不复用，"密钥一次一用"弥补了固定 IV 的隐患——这正是该设计成立的前提。

🔍 收包侧同样对称：接收方拿到发送方的公钥后执行同样的deriveSessionKey()，即可还原出相同会话密钥解密凭据。

🔄 完整密钥交换流程：收发双方如何握手

以"发送 A → 接收 B"为例，两端协作步骤如下（代码分别位于 P2pSenderService.kt 与 GattServerService.kt）：

1. B 启动接收服务，BLE 广播/暴露DeviceInfo（含 B 的公钥、版本号）；
2. A 发现 B，建立 GATT 连接并读取状态特征，拿到 B 的公钥；
3. A 用 ECDH 协商出会话密钥，加密 SSID/PSK/MAC，并在P2pInfo中附上A 自己的公钥，整体经 BLE 写入；
4. B 收到后用 A 的公钥协商出同一把会话密钥，解密出 WiFi 凭据，随后启动接收服务；
5. 双方基于同一 SSID/PSK 完成 WiFi 点对点连接，开始文件传输。

整个过程通常在一秒内完成，用户无感知——你只需要在列表里点一下对方设备。

🧩 设计细节解读：这些选择为何合理

• 临时密钥（每次启动重新生成）：兼顾了前向保密与实现简洁，且无需证书体系——BLE 链路本身短距、短暂，公钥交换的可信度足以支撑这一场景。
• 公钥用 Base64 明文广播：公钥天生不机密，放公共广播里不增加任何风险，反而省去了证书链的复杂度。
• MAC 也参与加密：各品牌互传联盟协议把 MAC 地址作为设备认证信息的一部分，CatShare 对其加密传输，避免身份凭据在空口暴露。
• 传输层加密兜底：WiFi 直连阶段凭据本身是 WPA-PSK 加密的；应用层 WebSocket 采用 WSS，证书校验由 FakeTrustManager.kt 放宽——因为此时双方已共享同一 PSK 且信道为点对点直连，安全边界实际由 WiFi 凭据保证。

📂 想深入源码？从这几个文件开始

❓ 常见问题 FAQ

Q：我的文件会经过服务器中转吗？不会。文件全程走设备间 WiFi 点对点直连，CatShare 没有任何后端服务器。

Q：如果有人在旁边嗅探蓝牙，能拿到我的 WiFi 密码吗？拿不到。空口只流转公钥与密文；公钥无法反推私钥，密文没有会话密钥无法解密，而会话密钥只在两端内存中各协商出一份。

Q：会话密钥会被保存下来吗？不会。密钥对与派生密钥均只存在于运行期内存，应用重启后彻底销毁，实现天然的"一次性密钥"。

Q：和系统自带互传相比，安全机制有什么特别之处？思路一致——都是"公钥/凭据协商 + 无线加密信道"，但 CatShare 以纯用户态实现了临时 ECDH 会话加密，不依赖系统特权，这对第三方应用来说并不常见。

一句话总结：CatShare 用"临时 ECDH 协商 + 一次性 AES-CTR 会话密钥 + 全内存不落盘"三层设计，让互传在开放的无线环境中依然做到凭据不可窃听、身份不可仿冒、会话不可回溯。🔐

【免费下载链接】CatShare类原生 & 海外设备，现已加入互传联盟。项目地址: https://gitcode.com/gh_mirrors/ca/CatShare