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

CatShare如何保护传输安全ECDH密钥协商与AES-CTR会话加密全解析【免费下载链接】CatShare类原生 海外设备现已加入互传联盟。项目地址: https://gitcode.com/gh_mirrors/ca/CatShareCatShare 是一款类原生的 Android 蓝牙互传工具它在使用ECDH 密钥协商与AES-CTR 会话加密保护传输安全的同时支持向小米、OPPO、vivo 等海外及第三方设备互传文件。很多用户关心一个不依赖系统特权的应用如何在开放的无线信道里安全地交换 WiFi 凭据本文将从零拆解 CatShare 的传输安全机制帮你快速看懂 ECDH 密钥协商与 AES-CTR 会话加密是如何协作的。️ 互传场景下的安全隐患为什么必须加密互传的本质是蓝牙BLE协商 → 交换 WiFi 热点凭据 → WiFi 直连传文件。其中蓝牙这一环完全暴露在公共空口上威胁场景潜在风险CatShare 的对策BLE 广播被第三方嗅探设备信息泄露广播内容中不含任何私密数据只放公钥WiFi 凭据SSID/PSK明文传输攻击者可加入热点、中间人劫持用 ECDH 协商出的会话密钥做 AES-CTR 加密会话密钥长期固定一次破解、永久泄露每次启动重新生成密钥对密钥不落盘MAC 地址作为认证凭据外泄身份被仿冒MAC 与凭据同包加密随会话销毁 核心思路一句话信道不安全没关系只传可以公开的东西公钥私密信息WiFi 凭据永远用协商出来的会话密钥加密。 安全架构总览一次互传的四个阶段┌─────────────┐ ① BLE 广播 DeviceInfo含本方 EC 公钥 ┌─────────────┐ │ 接收方设备 │ ◄────────────────────────────────────────── │ 发送方设备 │ │ │ ② 发送方读取公钥ECDH 协商出共享密钥 │ │ │ │ ③ AES-CTR 加密 SSID/PSK/MAC经 BLE 写入 │ │ │ │ ◄─────────────────────────────────────────── │ │ │ │ ④ 双方凭共享的 SSID/PSK 建立 WiFi 直连传输 │ │ └─────────────┘ └─────────────┘整个密钥交换过程没有任何中间服务器参与两端设备直接完成握手。 ECDH密钥协商从公钥到共享密钥CatShare 的密钥协商实现在 BleSecurity.kt 中流程如下启动即生成密钥对应用初始化时生成一组 256 位椭圆曲线EC公私钥。私钥只存在于内存重启应用即销毁从未写入磁盘。接收方广播公钥接收方把设备信息含 Base64 编码的本方公钥封装为DeviceInfo通过 BLE 状态特征对外广播定义见 DeviceInfo.kt。发送方协商密钥发送方读取对方公钥后调用deriveSessionKey()BleSecurity.kt 第 26-35 行以自身私钥 对方公钥执行ECDHElliptic-Diffie-Hellman运算得到与对方完全相同的共享密钥。前向保密因为密钥对每次启动都重新生成即便某次会话密钥未来被破解也无法回溯或推导出其他任何会话。为什么广播公钥是安全的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.ktB 启动接收服务BLE 广播/暴露DeviceInfo含 B 的公钥、版本号A 发现 B建立 GATT 连接并读取状态特征拿到 B 的公钥A 用 ECDH 协商出会话密钥加密 SSID/PSK/MAC并在P2pInfo中附上A 自己的公钥整体经 BLE 写入B 收到后用 A 的公钥协商出同一把会话密钥解密出 WiFi 凭据随后启动接收服务双方基于同一 SSID/PSK 完成 WiFi 点对点连接开始文件传输。整个过程通常在一秒内完成用户无感知——你只需要在列表里点一下对方设备。 设计细节解读这些选择为何合理临时密钥每次启动重新生成兼顾了前向保密与实现简洁且无需证书体系——BLE 链路本身短距、短暂公钥交换的可信度足以支撑这一场景。公钥用 Base64 明文广播公钥天生不机密放公共广播里不增加任何风险反而省去了证书链的复杂度。MAC 也参与加密各品牌互传联盟协议把 MAC 地址作为设备认证信息的一部分CatShare 对其加密传输避免身份凭据在空口暴露。传输层加密兜底WiFi 直连阶段凭据本身是 WPA-PSK 加密的应用层 WebSocket 采用 WSS证书校验由 FakeTrustManager.kt 放宽——因为此时双方已共享同一 PSK 且信道为点对点直连安全边界实际由 WiFi 凭据保证。 想深入源码从这几个文件开始文件作用BleSecurity.kt密钥对生成、ECDH 协商、AES-CTR 加解密核心GattServerService.kt接收方BLE 广播公钥、解密入站凭据P2pSenderService.kt发送方读公钥、加密凭据并写入对端DeviceInfo.kt / P2pInfo.kt广播与协商阶段的数据结构❓ 常见问题 FAQQ我的文件会经过服务器中转吗不会。文件全程走设备间 WiFi 点对点直连CatShare 没有任何后端服务器。Q如果有人在旁边嗅探蓝牙能拿到我的 WiFi 密码吗拿不到。空口只流转公钥与密文公钥无法反推私钥密文没有会话密钥无法解密而会话密钥只在两端内存中各协商出一份。Q会话密钥会被保存下来吗不会。密钥对与派生密钥均只存在于运行期内存应用重启后彻底销毁实现天然的一次性密钥。Q和系统自带互传相比安全机制有什么特别之处思路一致——都是公钥/凭据协商 无线加密信道但 CatShare 以纯用户态实现了临时 ECDH 会话加密不依赖系统特权这对第三方应用来说并不常见。一句话总结CatShare 用临时 ECDH 协商 一次性 AES-CTR 会话密钥 全内存不落盘三层设计让互传在开放的无线环境中依然做到凭据不可窃听、身份不可仿冒、会话不可回溯。【免费下载链接】CatShare类原生 海外设备现已加入互传联盟。项目地址: https://gitcode.com/gh_mirrors/ca/CatShare创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考