引言

X-CUBE-CRYPTOLIB 是基于 STM32 的 Crypto 算法庫，支持對稱密鑰、非對稱密鑰、哈希等多種算法。正確地使用 Cyrptolib 算法庫，可以在應(yīng)用程序中實(shí)現(xiàn)數(shù)據(jù)加密、設(shè)備身份認(rèn)證、加密通信等多種應(yīng)用層所需的安全功能。相反，若不能正確地使用算法庫往往會帶來加解密數(shù)據(jù)錯誤等系列問題。

關(guān)于 STM32 Crypto 算法庫應(yīng)用中的常見的問題之一就是應(yīng)用程序沒有使能 MCU 的CRC 模塊，盡管輸出的數(shù)據(jù)和期望值不同，但加解密函數(shù)的調(diào)用并未返回異常。本文在此描述另外一種沒有正確使用算法庫的情況。

問題描述

客戶應(yīng)用項目中需要在固件更新過程中對固件進(jìn)行加密并驗證，根據(jù)推薦采用了 AES- GCM 算法完成該任務(wù)。下載的固件通過 AES-GCM 進(jìn)行加密，并帶 TAG 可以用于驗證固件來源的合法性。在項目的代碼中使用 X-Cube-Cryptolib 進(jìn)行 AES-GCM 運(yùn)算。上位機(jī)使用 cryptopp820 加密庫對固件目標(biāo) bin 文件進(jìn)行加密，然后在 MCU 上通過X-Cube- Cryptolib 加密庫進(jìn)行 AES-GCM128 解密，解密數(shù)據(jù)沒有問題，但是 TAG 數(shù)據(jù)總是無法校驗通過。

問題分析與定位

正常情況下，當(dāng)調(diào)用 AES_GCM_Decrypt_Finish（P_pAESGCMctx， NULL， P_pOutputSize）;執(zhí)行后，AESctx.mFlags 結(jié)果會提示是否通過校驗。如果校驗成功，該值應(yīng)該等于 0x22，而運(yùn)行結(jié)果中看到的卻是 0x12。

確認(rèn)庫函數(shù)使用方法

將調(diào)用 AES-GCM 功能的代碼放在 X-Cube-Cryptolib 中一個簡單的測試程序的環(huán)境進(jìn)行測試，查看是否有該問題，結(jié)果發(fā)現(xiàn)測試程序中 AES-GCM 校驗是可以成功的，但是集成到客戶應(yīng)用中時就無法成功。那我們接下來重點(diǎn)研究應(yīng)用程序環(huán)境。

應(yīng)用程序環(huán)境

應(yīng)用程序使用了 FreeRTOS，基于 IAR 編譯環(huán)境。

查看庫文件的使用

確認(rèn)使用了正確的庫文件。

確認(rèn)是否存在多線程訪問

AES-GCM 的函數(shù)會在幾個線程中調(diào)用，而且確認(rèn)不會出現(xiàn)同時調(diào)用的情況，不存在 raise condition 的問題。

查看內(nèi)存使用情況

最初懷疑是否因為任務(wù)棧溢出造成，于是查看內(nèi)存使用情況。IAR stack size： 0x4800

IAR heap size： 0x4000

FreeRTOS heap size： 85KB

執(zhí)行AES 運(yùn)算的線程 stack size： 2560B

通過 FreeRTOS 的 uxTaskGetStackHighWaterMark（） 函數(shù)查看該線程還有 500 字節(jié)左右剩余空間。

AESGCMctx_stt 結(jié)構(gòu)的大小有 2360 字節(jié)，AES-GCM 加解密函數(shù)需要的 stack 大小大概在 450 字節(jié)左右，但是應(yīng)用代碼中將該變量定義為全局變量，以便可以在幾個不同的線程中使用，這樣可以確認(rèn)線程棧大小沒有問題，不存在 stack overflow 的問題。

查看生成代碼的.map 文件

通過比較，所有 cryptolib 中的 symbol 在 map 中的大小都正常，唯一有問題的是 AESGCMctx_stt 結(jié)構(gòu)變量的大小。應(yīng)用代碼.map：AESctx 0x2002f1f4 0x8f8 Data Gb AES_GCM_Decrypt.o ［1］

正常測試代碼 .map：AESctx 0x20002e64 0x938 Data Gb AES_GCM.o ［1］

驗證不過的問題應(yīng)該和這個結(jié)構(gòu)的數(shù)據(jù)有直接關(guān)系，接下來研究是什么造成了這個不同。

查看項目使用的 crypto 庫頭文件

經(jīng)檢查，INCLUDE_AES192 和 INCLUDE_AES256 兩個宏定義在 config.h 的定義中被注釋掉，這將導(dǎo)致 aes_gcm.h 中 AESGCMctx_stt 數(shù)據(jù)結(jié)構(gòu)的成員變量 uint32_t amExpKey［CRL_AES_MAX_EXPKEY_SIZE］;的大小發(fā)生變化，因為CRL_AES_MAX_EXPKEY_SIZE 的定義根據(jù)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 functions with key size of 128 bit are included in the library. *///#define INCLUDE_AES192 （（uint16_t）0x0008） /*！《 AES functions with key size of 192 bit are included in the library. *///#define INCLUDE_AES256 （（uint16_t）0x0010） /*！《 AES functions with key size of 256 bit are included in the library. *///#define INCLUDE_ARC4 （（uint16_t）0x0020） /*！《 ARC4 functions are included in the library. *///#define INCLUDE_CHACHA （（uint16_t）0x0040） /*！《 ChaCha functions are included in the library. *///#define INCLUDE_CHACHA20POLY1305 （（uint16_t）0x0080） /*！《 oly1305- AES functions are included in the library */

問題解決

將 config.h 里面被注釋掉的兩行定義打開，重新編譯，此時 TAG 驗證能夠正常通過。#define INCLUDE_AES128 （（uint16_t）0x0004） /*！《 AES functions with key size of 128 bit are included in the library. */#define INCLUDE_AES192 （（uint16_t）0x0008） /*！《 AES functions with key size of 192 bit are included in the library. */#define INCLUDE_AES256 （（uint16_t）0x0010） /*！《 AES functions with key size of 256 bit are included in the library. */

小結(jié)

簡言之，如果使用 X-Cube-Cryptolib 庫的話，作為用戶就不要改動 config.h 的內(nèi)容， 不可想當(dāng)然地自行調(diào)整配置。其實(shí)，庫是預(yù)先編譯好了的，所有的功能都已經(jīng)包含，只是鏈接的時候根據(jù)用戶使用到的函數(shù)去鏈接最終的目標(biāo)文件。

這個客戶就是按照以為關(guān)閉某些配置可以節(jié)省代碼空間的想法，貿(mào)然注釋掉了他以為自己不需要的功能，造成數(shù)據(jù)結(jié)構(gòu)大小發(fā)生變化等，影響加密庫的正常使用。

編輯：jq