Crypto算法库使用技巧之基于STM32 AES GCM应用提示.docxVIP

PAGE PAGE 1 Crypto算法库使用技巧之基于STM32 AES GCM应用提示 关于 STM32 Crypto 算法库应用中的常见的问题之一就是应用程序没有使能 （MCU） 的CRC 模块，尽管输出的数据和期望值不同，但加解密函数的调用并未返回特别。本文在此描述另外一种没有正确使用算法库的状况。  问题描述  客户应用项目中需要在固件更新过程中对固件进行加密并验证，依据推举采纳了 AES- GCM 算法完成该任务。（下载）的固件通过 AES-GCM 进行加密，并带 TAG 可以用于验证固件来源的合法性。在项目的代码中使用 X-Cube-Cryptolib 进行 AES-GCM 运算。上位机使用 cryptopp820 加密库对固件目标 bin 文件进行加密，然后在 MCU 上通过X-Cube- Cryptolib 加密库进行 AES-GCM128 解密，解密数据没有问题，但是 TAG 数据总是无法校验通过。  问题分析与定位  正常状况下，当调用 AES_GCM_Decrypt_Finish（P_pAESGCMctx， NULL， P_pOutputSize）;执行后，AESctx.mFlags 结果会提示是否通过校验。假如校验胜利，该值应当等于 0x22，而运行结果中看到的却是 0x12。  确认库函数使用方法  将调用 AES-GCM 功能的代码放在 X-Cube-Cryptolib 中一个简洁的（测试）程序的环境进行测试，查看是否有该问题，结果发觉测试程序中 AES-GCM 校验是可以胜利的，但是集成到客户应用中时就无法胜利。那我们接下来重点讨论应用程序环境。  应用程序环境  应用程序使用了 （FreeRTOS），基于 IAR 编译环境。  查看库文件的使用  确认使用了正确的库文件。  确认是否存在多线程访问  AES-GCM 的函数会在几个线程中调用，而且确认不会消失同时调用的状况，不存在 raise condi（ti）on 的问题。  查看内存使用状况  最初怀疑是否由于任务栈溢出造成，于是查看内存使用状况。IAR stack size： 0x4800  IAR heap size： 0x4000  FreeRTOS heap size： 85KB  执行AES 运算的线程 stack size： 2560B  通过 FreeRTOS 的 uxTaskGetStackHighWaterMark（） 函数查看该线程还有 500 字节左右剩余空间。  AESGCMctx_stt 结构的大小有 2360 字节，AES-GCM 加解密函数需要的 stack 大小也许在 450 字节左右，但是应用代码中将该变量定义为全局变量，以便可以在几个不同的线程中使用，这样可以确认线程栈大小没有问题，不存在 stack overflow 的问题。  查看生成代码的.map 文件  通过比较，全部 cryptolib 中的 symbol 在 map 中的大小都正常，唯一有问题的是 AESGCMctx_stt 结构变量的大小。应用代码.map：AESctx 0x2021f1f4 0x8f8 Data Gb AES_GCM_Decrypt.o ［1］  正常测试代码 .map：AESctx 0x20002e64 0x938 Data Gb AES_GCM.o ［1］  验证不过的问题应当和这个结构的数据有直接关系，接下来讨论是什么造成了这个不同。  查看项目使用的 crypto 库头文件  经检查，INCLUDE_AES192 和 INCLUDE_AES256 两个宏定义在 config.h 的定义中被解释掉，这将导致 aes_gcm.h 中 AESGCMctx_stt 数据结构的成员变量 uint32_t amExpKey［CRL_AES_MAX_EXPKEY_SIZE］;的大小发生变化，由于CRL_AES_MAX_EXPKEY_SIZE 的定义依据INCLUDE_AES128/192/256 是否定义会有所不同。  //#define INCLUDE_DES （（uint16_t）0x0001） /*！《 DES functions are included in the library. *///#define INCLUDE_TDES （（uint16_t）0x0002） /*！《 TripleDES （TDES） functions are included in the library. */#define INCLUDE_AES128 （（uint16_t）0x0004） /*！《 AES fu