Prefer X25519 for legacy WSS full handshakes

Prioritize X25519 while retaining enabled curve fallbacks and log the negotiated ECDHE group. Extend ABI checks, crypto benchmarks and backend group probes, and document the updated APP package.
This commit is contained in:
chenjintao
2026-09-16 15:32:22 +08:00
parent 3a0714c735
commit 551a7bb1e6
10 changed files with 189 additions and 26 deletions
+16 -4
View File
@@ -63,7 +63,19 @@ APP 通过 SDK 导出的 `mbedtls_ssl_handshake_step` 驱动同一 TLS 1.2 握
同一 Windows 主机上用实际 SDK crypto/X.509 源码验证相同证书链,各运行 20 次:关闭 NIST 优化平均 36.8 ms,开启后 10.2 ms,约 3.6 倍。两种配置均通过证书链、错误域名、不可信根、证书日期与 AES-GCM 检查。这是主机算法对比,不是板端总握手时间预测。可运行 `tools/test_mbedtls_cert.py --compare-nist` 复测;`tools/test_wss_handshake.py` 验证计时握手循环的状态推进、WANT、真实错误、超时与 tick 回绕。
最新包是 `artifacts/wss/tls-speed/EG800AKCN_11LG-legacy-wss-fast.zip`,本次需要重新编译并烧录内核和 APP。`recv-fix` 包保留为已上板通过的回退版本。优化包仍需采集阶段日志确认实际收益;若主要耗时在网络等待,再评估会话恢复或提前连接,不能用主机基准推断网络影响。
第一轮加速包是 `artifacts/wss/tls-speed/EG800AKCN_11LG-legacy-wss-fast.zip`,相对早期版本需更新内核和 APP。14:38 上板已确认 TLS 握手 1820 ms,其中证书校验 965 ms、服务器密钥交换 160 ms、客户端密钥交换 445 ms,HTTP 101 正常。
### 完整握手的曲线协商优化
用户要求每次完整握手且不提前建连。WSS 的 `ssl_conf.curve_list` 改为 X25519、P-256、P-384、P-521 优先,其他原已启用曲线继续作为回退;不启用会话恢复、不改变按键/休眠/提示音逻辑。SDK 没有向 APP 导出 `mbedtls_ssl_conf_curves`,因此采用其实现同样的配置字段赋值。ABI 检查扩展到该字段、握手参数及 ECDH 上下文,验证 ARMCC 内核与 GCC APP 的实际布局一致。协商日志直接读取已匹配的上下文,`WSS TLS negotiated ECDHE group: 9` 表示 X25519(P-256=3、P-384=4、P-521=5)。
`tools/probe_wss_groups.py` 用同一固件根 CA、TLS 1.2 和证书/域名校验进行独立完整握手,读取固件的曲线数组进行验证:实际后台在 SDK 默认顺序下选择 P-521,在新固件顺序下选择 X25519;密码套件均为 ECDHE-ECDSA-AES256-GCM-SHA384。证据见 `artifacts/wss/full-handshake/group-probe.json`。X25519 是标准的约 128 位安全强度密钥交换;P-521 的参数更大,单纯参数更大不等于更适合本设备。当前服务端叶证书是 P-256 ECDSA,证书链、有效期和域名校验保持必需。
主机实际 SDK 新建 ECDH(每组 20 次,重新生成临时密钥并计算共享密钥)平均:X25519 1.55 ms、P-256 1.90 ms、P-384 3.40 ms、P-521 5.15 ms;X25519 测试峰值额外堆 1144 字节,P-521 6376 字节(包含测试对端共享密钥校验的内存)。每次校验双方计算结果相同并检查内存释放。板端仍需实测,主要目标是降低客户端密钥交换开销,不能把基准比例套用到整个握手。
另对比 ECP window=4/5/6:证书校验约 10.35/10.20/10.45 ms,峰值分配约 11913/16009/18697 字节,收益不稳定,因此固件保留 window=4。可在 MSVC 开发者终端运行 `tools/test_mbedtls_cert.py --compare-windows` 复测。
最新包 `artifacts/wss/full-handshake/EG800AKCN_11LG-legacy-wss-x25519.zip` 沿用已验证的 NIST 内核,只更新 APP。当前工作区可 `build.bat app`、`build.bat firmware`;全新检出仍需先构建匹配的内核。旧 `tls-speed` 包保留,作为板端 1820 ms 的对照。
## 根证书来源与验证
@@ -95,18 +107,18 @@ build.bat firmware
导出到下述路径后运行 `ql-cross-tool\win32\owtoolchain\Python\python.exe tools\verify_wss_package.py`,核对 ZIP CRC、APP/内核与当前构建的字节一致性、无 GNSS 入口以及内核 ECDSA/GCM/日期校验符号。SDK 有既有编译警告,不能仅凭外层批处理退出码认定成功。
最新优化包位于 `artifacts/wss/tls-speed/EG800AKCN_11LG-legacy-wss-fast.zip`,标准输出为 `target/EG800AKCN_11LG/EG800AKCN_11LG.zip`,两者字节一致。这是完整多分区烧录包。本次新增内核 NIST 加速,需依次 `build.bat kernel`、`build.bat app`、`build.bat firmware`,不能仅更新 APP。运行 `ql-cross-tool\win32\owtoolchain\Python\python.exe tools\verify_wss_package.py` 校验默认最新包;也可显式传入该 ZIP 路径。
最新优化包位于 `artifacts/wss/full-handshake/EG800AKCN_11LG-legacy-wss-x25519.zip`,标准输出为 `target/EG800AKCN_11LG/EG800AKCN_11LG.zip`,两者字节一致。这是完整多分区烧录包,内核与上一版 NIST 加速包字节一致。运行 `ql-cross-tool\win32\owtoolchain\Python\python.exe tools\verify_wss_package.py` 校验默认最新包;也可显式传入该 ZIP 路径。
`ecc-fix/EG800AKCN_11LG-legacy-wss-ecc.zip` 保留用于对照接收错误。原 `artifacts/wss/EG800AKCN_11LG-legacy-wss.zip` 存在缺失 ECDSA 的问题,请勿用于验证本次修复。旧板明文 WS 包仍保留在 `artifacts/legacy-no-gnss/`。
## 上板验收
443 `/ws` 已通过主机握手测试;ECC/RTC 和接收修复已在板端通过 TLS、HTTP 101,用户确认功能正常。本次 NIST 加速/计时包仍需上板检查:
443 `/ws` 已通过主机握手测试;ECC/RTC、接收修复和 NIST 加速已在板端通过 TLS、HTTP 101。本次 X25519 优先配置仍需上板检查:
1. 无 GNSS 旧板正常启动、蜂窝网络就绪、RTC 时间正确。
2. 先出现 `WSS root CA parsed successfully`,再出现 `WSS TLS handshake and certificate/hostname verification passed`。
3. 出现 `WebSocket upgrade verified: HTTP 101` 和 `ws connect okay`。
4. 服务器确认原设备鉴权成功,再测试收发音频、断网重连和休眠唤醒。
5. 记录 `WSS TLS phase` 和 `WSS TLS handshake total`,同一网络环境多次对比原约 9.6 秒的 TLS 握手耗时。
5. 确认 `WSS TLS negotiated ECDHE group: 9`;记录 `WSS TLS phase` 和 `WSS TLS handshake total`,同一网络环境多次对比上一版 1820 ms 的 TLS 握手耗时。
TLS 成功、WebSocket 成功、设备鉴权成功是三个不同阶段,不能只看其中一条日志就认定业务已跑通。