OP-TEE文件系统加密中AAD长度问题的分析与修复

在实现硬件加速AES-GCM认证加密驱动时，发现了一个与附加认证数据(AAD)长度相关的关键问题。这个问题出现在OP-TEE的文件系统加密模块(fs_htree.c)中，具体涉及authenc_init()函数的实现。

问题背景

AES-GCM是一种广泛使用的认证加密算法，它除了提供数据机密性外，还能确保数据的完整性。在GCM模式下，附加认证数据(AAD)是指那些需要被认证但不需要加密的数据部分。在文件系统加密场景中，AAD通常包含文件元数据等重要信息。

问题现象

硬件加密驱动在接收来自fs_htree.c的加密操作调用时发现异常：

1. crypto_authenc_init()调用时声明的AAD长度为68字节
2. 但后续通过多次crypto_authenc_update_aad()调用实际更新的AAD数据总和仅为52字节
3. 这种不一致导致硬件加密引擎报错

技术分析

深入分析fs_htree.c中的authenc_init()函数实现，发现问题的根源在于：

1. 初始AAD长度计算时使用了TEE_FS_HTREE_FEK_SIZE(32字节)
2. 但实际更新AAD数据时应该使用TEE_FS_HTREE_HASH_SIZE(64字节)作为基础
3. 这种不一致导致声明的AAD长度与实际更新的数据长度不匹配

解决方案

修复方案相对直接：

1. 将初始AAD长度计算从使用TEE_FS_HTREE_FEK_SIZE改为使用TEE_FS_HTREE_HASH_SIZE
2. 确保声明的AAD长度与实际更新的数据长度完全一致

技术影响

这个修复对于确保文件系统加密的正确性至关重要：

1. 防止硬件加密引擎因参数不一致而报错
2. 保证AAD数据的完整认证过程正确执行
3. 维护文件系统加密的整体安全性

最佳实践建议

在实现加密相关功能时，开发者应当：

1. 严格检查所有长度参数的一致性
2. 特别注意AAD这类特殊数据的处理
3. 在硬件加速实现中，参数检查通常更为严格，需要额外注意
4. 建立完善的测试用例覆盖各种长度组合场景

这个问题的发现和修复过程展示了在安全敏感系统中参数一致性检查的重要性，也为类似加密实现提供了有价值的参考经验。