ECDSA私钥生成必须使用真随机数，优先调用硬件TRNG（如STM32 RNG、ESP32 esp_random()），无TRNG时需多源熵混合并经HKDF-SHA256提取；私钥生成后立即安全清零；推荐使用secp256r1曲线；签名前必须先哈希原始数据；验证失败多因签名编码格式不匹配，建议统一使用raw格式（r||s拼接）。
ECDSA私钥生成必须用真随机数，不能用std::rand()
物联网设备上生成ECDSA私钥，核心是确保private_key的熵源足够强。很多嵌入式项目误用std::rand()或time(0)做种子，结果私钥可预测——攻击者连设备串口日志都不用抓，直接爆破就能还原。
实操建议：
- 优先调用硬件TRNG（如STM32的RNG外设、ESP32的
esp_random()），读取后校验输出是否全零（防硬件故障） - 若无TRNG，至少用多源熵混合：ADC噪声 + RTC计数器抖动 + Flash擦写时序偏差，再经
HKDF-SHA256提取 - 生成后立即用
memset_s()（或explicit_bzero()）清零栈上私钥缓冲区，避免被core dump泄露
选曲线要兼顾安全与MCU资源，secp256r1比secp384r1更实用
物联网设备常见误区是“越长越安全”，盲目选secp384r1。实际在ARM Cortex-M4（如nRF52840）上，secp256r1签名耗时约85ms，secp384r1直接跳到210ms，且RAM占用翻倍——而NIST已确认secp256r1对当前算力仍安全。
使用场景注意点：
- 证书链中若CA用
secp256r1，设备必须保持一致，否则TLS握手会因EC_KEY_set_group()失败而中断 - MicroPython或Zephyr等RTOS通常只内置
secp256r1，强行编译secp521r1会导致链接时报undefined reference to 'ecp_nistz256_modp' - 密钥导出为PEM时，OpenSSL命令必须显式指定曲线：
openssl ecparam -name secp256r1 -genkey -noout -out key.pem
签名前必须哈希原始数据，别直接签明文
ECDSA标准要求输入是固定长度摘要，不是任意长度原始报文。曾见某LoRaWAN节点直接对12字节传感器数据调用ECDSA_do_sign()，结果因未哈希导致签名值每次不同——算法内部用了随机k，但输入不标准化，验证端用相同私钥也验不过。
正确流程：
- 对原始数据（如JSON payload）先计算
SHA-256，得到32字节摘要 - 将摘要字节数组转为大整数，作为
ECDSA_do_sign()的dgst参数 - 若用mbed TLS，必须用
mbedtls_ecdsa_write_signature_det()而非_write_signature()，后者依赖外部随机数，而确定性签名（RFC 6979）才能保证同一输入恒定输出
验证失败大概率是坐标编码格式不匹配
设备签名后，云端验证总报ECDSA_SIG_verify() returned 0，90%以上是签名值编码问题。ECDSA签名本质是两个大整数(r, s)，但不同库序列化方式不同：
- OpenSSL默认用DER编码（ASN.1结构），开头是
0x30，长度可变 - mbed TLS的
mbedtls_ecdsa_read_signature()期望纯r||s拼接（各32字节，共64字节） - 若设备用OpenSSL生成DER签名，云端用mbed TLS验证，必须先用
asn1_get_mpi()从DER中拆出r和s，再手动填充到mbedtls_mpi结构
最简排查法：用xxd -p signature.bin看前两字节——如果是3044就是DER，如果是...（纯十六进制数字流）则是raw格式。
硬件资源紧张时，别硬啃ASN.1解析。直接在设备端改用raw格式签名：OpenSSL里用BN_bn2bin()分别导出r和s，拼成64字节buffer，既省Flash又避免兼容性雷区。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
