亚洲精品一区二区观看,亚洲欧美国产精品久久久,亚洲福利影院

前言

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

OTFDEC簡介

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

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

就比如膠片中這樣的典型拓撲結構：加密代碼放在外部的Octo-SPI Flash中。

對這種自然的做法，以往的MCU在執行片外加密代碼時，需要先調用OSPI驅動，把密文代碼讀進來，比如放到SRAM中。然后使用MCU的軟件或者硬件解密，把代碼明文恢復到SRAM的另一個區域。最后MCU再從這塊SRAM執行明文代碼。

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

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

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

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

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

實驗設計

我們接下來設計一個實驗，驗證在OTFDEC參與下，內核執行外部Flash上的密文代碼效率到底如何，用數據說話。

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

這個Crypto自測程序經過最高優化等級編譯后，大小差不多在63K作用的樣子。

第一個場景就是最普通的，直接把測試程序灌到片上Flash運行。

我們先來看一下這個自測程序，主要就是執行selftests這個函數數組里的自測程序。用戶可以在mebdtls_conf.h頭文件中去選擇哪些自測子項被包含進去。現在我選擇了6個自測子項。

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

因為要測量運行這給自測程序的時間花銷，因此我們使能一個內核計數器，然后在每個測試子項的開始復位該計數器，在測試子項結束后把當前計數器的值，記錄到全局變量的時間戳數組中。最后在6個測試子項都完成后，根據時間戳數組里記錄的值，和當前內核運行頻率，轉換成時間花銷。

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

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

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

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

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

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

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

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

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

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

為什么要這樣調換，這是因為OTFDEC電路設計造成的，我們沒有必要去追究原因，知道在這樣的設計下，我們該怎么做就可以了。

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

然后來看IV。

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

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

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

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