嵌入式平台Mbed TLS PEAPv0/MSCHAPv2场景下MPPE密钥不匹配求助

看来你在PEAPv0（MSCHAPv2阶段2）的MPPE密钥生成上碰到了SHA384相关的兼容性坑——我之前也处理过类似的TLS PRF与密钥导出问题，给你列几个容易被忽略的排查方向：

OpenSSL的SSL_export_keying_material和Mbed TLS的tls_prf在处理输入参数时，很容易出现细节偏差：

• 检查标签（label）：PEAPv0阶段2导出MPPE密钥的标准标签是"client EAP encryption"和"server EAP encryption"，要确认两边的字符串完全一致（包括大小写、无额外空格或转义符）。
• 检查上下文（context）数据：PEAP要求上下文包含EAP会话ID和长度字段，要对比客户端拼接的上下文字节流和FreeRADIUS生成的是否完全匹配——尤其注意长度字段的字节序（大端/小端）是否符合RFC规范。

TLS 1.2的PRF针对SHA384会输出48字节的HMAC结果，SHA256则是32字节，而MPPE需要的是特定长度的密钥（如40/128位）：

• 直接对比两边PRF输出的原始字节流（打印十六进制）：如果前N字节就不一致，问题出在PRF实现本身；如果前N字节相同但密钥提取逻辑不同，那是后续截断/选取规则的问题。
• 确认MSCHAPv2的密钥提取逻辑：MPPE密钥是从PRF输出中按顺序截取，还是需要拆分会话密钥和加密密钥？两边的截取起始位置和长度必须完全一致。

Mbed TLS的tls_prf在处理SHA384时，可能存在与OpenSSL的实现差异：

• 对比核心实现：看Mbed TLS的mbedtls_tls_prf函数和OpenSSL的tls12_prf（SSL_export_keying_material内部调用的PRF函数），重点检查HMAC的密钥初始化、A/B块的迭代生成逻辑是否严格遵循RFC 5246。
• 确认编译选项：检查Mbed TLS是否开启了MBEDTLS_SHA384_C宏，如果未开启，可能会 fallback 到其他哈希函数，直接导致PRF输出错误。

MPPE密钥派生基于TLS会话的主密钥（Master Secret），如果主密钥本身不一致，后续PRF输出肯定不匹配：

• 对比客户端和服务器的Client Random/Server Random：确认双方交换的随机数完全相同，没有字节丢失或反转。
• 对比主密钥（Master Secret）：如果使用ECDHE套件，还要检查双方的EC公钥交换是否正确，有没有出现密钥协商过程中的字节序错误。

FreeRADIUS在处理PEAPv0和MPPE时，可能存在默认配置限制：

• 检查配置文件：查看raddb/mods-available/eap和raddb/mods-available/mschap，确认mppe模块是否允许使用SHA384相关的密钥派生，有没有配置mppe_encryption强制限制哈希算法。
• 开启调试日志：运行radiusd -X启动FreeRADIUS调试模式，搜索MPPE密钥生成的日志，提取服务器端生成的密钥十六进制值，和客户端的结果直接对比，定位差异点。

MPPE密钥不是直接从TLS PRF导出的，MSCHAPv2还有一层派生逻辑：

• 检查NT哈希的计算：确认客户端和服务器的NT哈希生成是否一致（比如用户密码的编码是否统一为UTF-16LE）。
• 检查会话密钥与PRF的结合逻辑：MSCHAPv2会用会话密钥对PRF输出做额外处理（如RC4加密），要确认这一步的实现和参数是否完全匹配。

内容的提问来源于stack exchange，提问作者teja swaroop