s2n-tls项目中OpenSSL 3.0 FIPS模式下哈希与签名机制的演进

在密码学库s2n-tls的开发过程中，团队遇到了OpenSSL 3.0 FIPS模式下哈希与签名机制的兼容性问题。本文将深入分析这一技术挑战及其解决方案。

背景与挑战

s2n-tls作为AWS开发的TLS实现，需要支持多种加密操作，包括哈希计算和数字签名。在OpenSSL 3.0 FIPS模式下，原有的实现方式遇到了两个主要限制：

1. MD5哈希算法不再被FIPS模式支持
2. EVP_MD_CTX_set_pkey_ctx函数不可用

这些限制迫使开发团队重新审视整个加密操作架构，寻找既符合FIPS要求又能保持功能完整性的解决方案。

原有架构分析

在原有实现中，s2n-tls采用了双路径架构：

哈希计算路径：

• 传统方式：使用SHA1_hash()等非FIPS方法
• EVP方式：使用EVP_Digest()等现代方法

签名计算路径：

• 传统方式：使用ECDSA_sign()等非FIPS方法
• EVP方式：使用EVP_DigestSign()等现代方法

这种架构在不同OpenSSL版本间存在兼容性问题，特别是在FIPS模式下。

解决方案设计

开发团队提出了三路径签名方案来应对OpenSSL 3.0 FIPS的挑战：

1. 传统签名：使用非FIPS方法
2. EVP签名：使用完整EVP流程
3. EVP-FIPS-140-3签名：使用EVP_pkey_sign()但不依赖EVP_MD_CTX_set_pkey_ctx

关键突破在于认识到虽然FIPS模式本身不支持MD5，但通过加载默认提供者(Default provider)可以获取MD5支持，这使得全面转向EVP接口成为可能。

架构演进

最终的架构演进路径包括三个主要阶段：

1. 清理阶段：移除不再使用的openssl-1.0.2-fips特殊处理代码
2. EVP哈希统一：
   • 实现显式获取(EVP explicit fetch)
   • 所有libcrypto实现统一使用EVP哈希
   • 清理传统哈希实现
3. EVP签名统一：
   • 添加新的EVP签名方法
   • 除awslc-fips外全部迁移到新EVP签名方法
   • 清理传统pkey实现

技术实现细节

在具体实现上，团队采用了以下策略：

1. 哈希计算：全面转向EVP接口，通过显式获取确保算法可用性
2. 签名操作：
   • 对于支持完整EVP流程的环境，使用EVP_DigestSign
   • 对于限制性环境，使用EVP_pkey_sign配合外部哈希
3. 兼容性处理：通过运行时检测自动选择最佳实现路径

总结

s2n-tls团队通过这次架构演进，不仅解决了OpenSSL 3.0 FIPS的兼容性问题，还实现了代码的简化和统一。新的架构具有以下优势：

1. 更好的FIPS合规性
2. 更清晰的代码结构
3. 更强的版本兼容性
4. 更易于维护的代码库

这一案例展示了在密码学库开发中如何平衡安全性要求、功能完整性和代码可维护性，为类似项目提供了有价值的参考。