前言

從STM32H73x系列開始，我們引入了一個(gè)新外設(shè)模塊，OTFDEC。它的全名叫做on the fly decryption。它的引入，可以幫助大家解決代碼保護(hù)的痛點(diǎn)。

OTFDEC簡介

大家都知道，代碼存儲在片內(nèi)Flash，只要做好了JTAG調(diào)試端口的保護(hù)和片上關(guān)鍵代碼的隔離，在防止邏輯攻擊和直接探測層面，還是相當(dāng)安全的。但是片上Flash畢竟容量有限，在一些應(yīng)用中我們需要把代碼放到片外Flash存儲甚至直接從片外Flash執(zhí)行。片外Flash相比片內(nèi)Flash，在抗攻擊方面就脆弱得多。片外Flash一般沒有什么硬件層面的保護(hù)，只要知道了它的料號，它的讀寫時(shí)序都是可以查到的，那么讀出來里面的內(nèi)容就不是什么難事。

所以大家一個(gè)自然的想法就是把代碼加密后再放到片外Flash上，這樣即使別人讀出里面的密文代碼，只要沒有密鑰，也無法獲知代碼的有效信息。

就比如膠片中這樣的典型拓?fù)浣Y(jié)構(gòu)：加密代碼放在外部的Octo-SPI Flash中。

對這種自然的做法，以往的MCU在執(zhí)行片外加密代碼時(shí)，需要先調(diào)用OSPI驅(qū)動，把密文代碼讀進(jìn)來，比如放到SRAM中。然后使用MCU的軟件或者硬件解密，把代碼明文恢復(fù)到SRAM的另一個(gè)區(qū)域。最后MCU再從這塊SRAM執(zhí)行明文代碼。

現(xiàn)在我們引入了OTFDEC這個(gè)硬件模塊，它位于總線矩陣和Octo-SPI接口之間。把它配置好之后，內(nèi)核執(zhí)行片外Flash上的密文代碼（在這里Octo-SPI Flash的映射地址是0x9000 0000開始），無需中間再用SRAM倒一次手，而是在OTFDEC的作用下，直接把解密后的代碼送到總線矩陣上供內(nèi)核執(zhí)行了。也就是說，有了OTFDEC的配合，對于CPU來說，執(zhí)行外部Flash上的加密代碼，就和執(zhí)行片上Flash的明文代碼是一樣的。

為了盡量減少OTFDEC解密造成的延遲，OTFDEC被設(shè)計(jì)工作在AES-128-CTR模式下。不使用AES的鏈表模式，就是為了盡量縮短對目標(biāo)地址上密文解密的時(shí)間。因此存儲在外部Octo-SPI Flash上的加密代碼也需要使用同樣的AES-128-CTR運(yùn)算得到。

有一點(diǎn)需要注意的是：為了達(dá)到這樣的使用效果，Octo-SPI需要配置到memory map模式。

目前，STM32系列家族中，集成了這個(gè)OTFDEC模塊的有STM32H73x系列，STM32L56x系列，和STM32U585系列。

今天我們不是介紹OTFDEC怎么使用，而是回答前段時(shí)間在給客戶介紹OTFDEC的時(shí)候，大家一個(gè)比較共同的問題：相對于直接執(zhí)行外部Flash上的明文代碼，執(zhí)行外部Flash的加密代碼，OTFDEC解密操作引入的延遲有多少？

實(shí)驗(yàn)設(shè)計(jì)

我們接下來設(shè)計(jì)一個(gè)實(shí)驗(yàn)，驗(yàn)證在OTFDEC參與下，內(nèi)核執(zhí)行外部Flash上的密文代碼效率到底如何，用數(shù)據(jù)說話。

我找了mbedTLS中一個(gè)自測程序Crypto_SelfTest，驗(yàn)證一下把它加密后放在外部Flash，內(nèi)核執(zhí)行完整套自測程序需要的時(shí)間花銷，和執(zhí)行外部明文代碼的差異。為了進(jìn)一步說明問題，還加了一個(gè)場景，就是這個(gè)自測程序明文放在片內(nèi)Flash，內(nèi)核執(zhí)行它的花銷會快多少。

這個(gè)Crypto自測程序經(jīng)過最高優(yōu)化等級編譯后，大小差不多在63K作用的樣子。

第一個(gè)場景就是最普通的，直接把測試程序灌到片上Flash運(yùn)行。

我們先來看一下這個(gè)自測程序，主要就是執(zhí)行selftests這個(gè)函數(shù)數(shù)組里的自測程序。用戶可以在mebdtls_conf.h頭文件中去選擇哪些自測子項(xiàng)被包含進(jìn)去?，F(xiàn)在我選擇了6個(gè)自測子項(xiàng)。

然后在自測程序開始運(yùn)行之前，通過檢測是否有用戶按鍵按下，來決定是否開啟Cache。STM32H735集成ARM Cortex-M7內(nèi)核，自帶32K指令Cache和32K數(shù)據(jù)Cache。

因?yàn)橐獪y量運(yùn)行這給自測程序的時(shí)間花銷，因此我們使能一個(gè)內(nèi)核計(jì)數(shù)器，然后在每個(gè)測試子項(xiàng)的開始復(fù)位該計(jì)數(shù)器，在測試子項(xiàng)結(jié)束后把當(dāng)前計(jì)數(shù)器的值，記錄到全局變量的時(shí)間戳數(shù)組中。最后在6個(gè)測試子項(xiàng)都完成后，根據(jù)時(shí)間戳數(shù)組里記錄的值，和當(dāng)前內(nèi)核運(yùn)行頻率，轉(zhuǎn)換成時(shí)間花銷。

由于場景1，是最普通的用法，即程序運(yùn)行在片上Flash，因此它的鏈接文件就是STM32Cube包中的缺省配置。我這里以IAR為例，展示了這個(gè)測試場景下，code的存放地址，包括復(fù)位和中斷向量表的存放地址。

第二個(gè)場景，自測程序運(yùn)行在外部Flash。而STM32是不能從外部Flash啟動的，我們按照常規(guī)的做法，從片上Flash首地址啟動，因此在片上Flash我們放一個(gè)Bootloader。它的功能很簡單，就是初始化OSPI接口，并把它配置到memory-map模式。然后調(diào)整堆棧指針SP，以及PC指針，跳到0x9000 0000開始的OSPI外部Flash首地址運(yùn)行。而那里，則是我的Crypto自測程序。

在場景2的自測程序工程Crypto_Selftest_ext_plain中，和之前的工程相比，只需要稍微做兩處修改。鏈接文件，把復(fù)位和中斷向量表放到0x9000 0000的地方，并且調(diào)整內(nèi)核寄存器的VTOR值。這樣子，一旦有任何中斷或者異常，都是去位于0x9000 0000處的向量表取執(zhí)行地址。

第三個(gè)測試場景，boot loader工程相比第二個(gè)測試場景中，需要增加對OTFDEC的配置。而燒錄在0x9000 0000的內(nèi)容，應(yīng)該是從場景2下第二個(gè)工程生成的project.bin，加密后的密文。這里，左邊的Bootloader里是OTFDEC在解密，右邊是通過PC端工具預(yù)先把代碼做加密。

由于是AES是對稱加解密算法，因此OTFDEC的加密參數(shù)配置，要和PC端加密工具的參數(shù)一致。

我們先來設(shè)置OTFDEC的解密參數(shù)，密鑰key和初始向量IV。

密鑰由用戶自己指定，在代碼里我們設(shè)置在Key數(shù)組中。按照數(shù)組的寫法，考慮到ARM Cortex-M內(nèi)核是小段對齊，因此這16字節(jié)的密鑰，在memory中的存儲順序，應(yīng)該如左下圖所示。注意，我這里刻意讓16字節(jié)的密鑰中，每個(gè)字節(jié)的內(nèi)容都不一樣。為什么？我們接下來看。

OTFDEC的IV，HAL驅(qū)動封裝了一個(gè)結(jié)構(gòu)體給用戶來填寫。由Nounce，OTFDEC將要作用的外部Flash地址范圍，以及將要存放在外部Flash那個(gè)地址范圍里代碼的版本號。Nounce，也是由用戶自己設(shè)定，我這里仍然刻意讓8個(gè)字節(jié)的內(nèi)容都不相同。

接下來我們要配置PC端加密工具的參數(shù)了。這里我們使用openssl。

在OTFDEC的解密密鑰設(shè)置好了之后，我們在openssl中使用的密鑰要以字節(jié)為單位，在16個(gè)字節(jié)的范圍內(nèi)，頭尾交換一下。但是注意，字節(jié)里面的bit順序不變，也就是每個(gè)字節(jié)的值不變，只是換了新的位置。這就是為什么我前面故意把OTFDEC的密鑰中，16個(gè)字節(jié)的內(nèi)容每個(gè)字節(jié)值都不一樣，就是為了方便比對每個(gè)字節(jié)的移動位置。

為什么要這樣調(diào)換，這是因?yàn)镺TFDEC電路設(shè)計(jì)造成的，我們沒有必要去追究原因，知道在這樣的設(shè)計(jì)下，我們該怎么做就可以了。

大家注意膠片里貼出來的openssl的命令，-K字符后跟著就是密鑰，這是以字節(jié)為單位的字節(jié)串。也就是說第一個(gè)字節(jié)是0x9A，接著的字節(jié)分別是0xBC, 0xDE，和膠片中下面的表格中字節(jié)順序排列一樣的。

然后來看IV。

OTFDEC的IV，我們在代碼中，給HAL驅(qū)動封裝出來的OTFDEC_RegionConfig結(jié)構(gòu)體每個(gè)成員賦值好了之后。這個(gè)IV在使用openssl的時(shí)候，又需要做怎樣的調(diào)序呢？如圖所示：第一個(gè)32位的字，來自Nounce[1]。這個(gè)4字節(jié)組成的32位字里面，字節(jié)順序也是依次頭尾交換了一下。第二個(gè)32位字，來自Nounce[0]，字節(jié)調(diào)位順序也是一樣。第三個(gè)字的高2位字節(jié)來自Version，字節(jié)調(diào)位順序和前面一樣。第四個(gè)32位字來自起始地址的移位和regionID的拼接。

大家注意膠片里貼出來的openssl的命令，-iv字符后跟著就是初始向量，這也是以字節(jié)為單位的字節(jié)串。也就是說第一個(gè)字節(jié)是0x13，接著的字節(jié)分別是0x57, 0x9B，和膠片中下面的表格中字節(jié)順序排列一樣的。

openssl命令的密鑰和IV輸入的內(nèi)容確定了，還有一件很重要的需要調(diào)整的事情：OTFDEC將要解密的對象。

它并不是直接的把明文代碼Project.bin，使用openssl按照前面的參數(shù)加密就好了。仍然是由于不同AES運(yùn)算工具對字節(jié)排序的不同，需要做手動調(diào)整。這里我們使用PC端的腳本工具，srec_cat先做輸入字節(jié)流的填充，然后使用xxd工具，對字節(jié)順序做調(diào)整。調(diào)整的規(guī)則和前面的密鑰是一樣的，即，對每16字節(jié)的內(nèi)容：在16個(gè)字節(jié)的范圍內(nèi)，頭尾交換一下，字節(jié)里面的bit順序不變，也就是每個(gè)字節(jié)的值不變，只是換了新的位置。經(jīng)過調(diào)序后的字節(jié)流再送到openssl做加密，密文同樣還要經(jīng)過一次相同規(guī)則的字節(jié)調(diào)序，才得到最終可以燒寫到片外Flash（0x9000 0000），由OTFDEC做實(shí)時(shí)解密的加密代碼。

打開cmd命令窗口，切換到在這個(gè)文檔配套的參考例程包里的Utilities/ExtTools目錄下，依次輸入前一頁膠片里的命令，得到預(yù)處理階段的最后輸出，即Project_pad_pre_enc_post.bin。

我們可以使用STM32CubeProgramer來驗(yàn)證OTDEC配置好了之后，從0x9000 0000的地方看到的就是明文代碼的樣子。

驗(yàn)證步驟請參照膠片中的指示。

接下來我們讓板子脫機(jī)運(yùn)行，把場景3運(yùn)行起來。從板載的LCD屏幕可以看到自測程序完成后，打印出來的時(shí)間花銷。

根據(jù)我復(fù)位的時(shí)候是否按下用戶按鍵，可以展現(xiàn)使能Cache和不使能Cache的效果。

從total time cost這一行可以看出，不是能Cache，執(zhí)行時(shí)間要8秒；而使能了Cache，執(zhí)行時(shí)間只要0.2秒。

我們再把場景1和場景2下，啟動工程和自測工程下載到板子上分別運(yùn)行，再記錄各自的時(shí)間花銷。

圖中紅色數(shù)字是未開Cache的情況，綠色數(shù)字是開啟Cache的情況。

結(jié)論

可以得出結(jié)論：代碼運(yùn)行在外部Flash的時(shí)候，運(yùn)行明文和使用OTFDEC運(yùn)行密文，效率相差無幾；要提高代碼運(yùn)行在外部Flash的效率，主要加速措施是使能內(nèi)核自動的Cache。

文章出處：【微信公眾號：STM32單片機(jī)】

責(zé)任編輯：gt