非對稱式Security Boot/Security Update的實作

Security Boot是一種用於確保系統內運作的應用程式碼被授權的方法，通常由設計與構建系統的廠商提供。通過確保應用程式碼為正確的授權版本可以防止不可預測的系統程式造成機器性能異常、安全性受損甚至財產損失。大多數電子系統使用可編程非揮發性存儲器(Flash)存放其應用程式碼(Application Code)，無論大小都可以利用Security Boot保護該程式碼不被惡意竄改。本文說明Security Boot的基本觀念，同時深入地介紹其處理方式並提供解決方案。

Security Update流程

前置作業：下圖紅色方框所代表的角色為程式碼簽發者(Code Publish)，其包含一組唯一的公鑰(Public Key)和私鑰(Private Key)

要進行升級的應用程式(Firmware update)應該要先透過Hash Function(例如SHA256)獲取其Digest (此步驟就如同用XOR計算出程式碼的Checksum，只是SHA256 Digest為256-bit遠大於Checksum，具有絕對唯一性)。接著程式碼的簽發機構(Code Publish)需要針對該程式碼的Digest透過其私鑰進行「加密」 (ECDSA SIGN)，加密過後的資料我們稱作數位簽章(Digital Signature)。

因為擁有該私鑰即擁有權力簽發正式版本程式碼的數位簽章，故一般而言私鑰將會被存放於硬體保護的晶片裡(如ATECC608A)，避免對外流傳。將更新應用程式與數位簽章(Data to Send)透過有線或是無線的方式傳送至待更新的裝置(Device to Upgrade)。進行更新之前，待更新裝置必須驗證此應用程式與數位簽章的正確性。

在非對稱的算法中，每個存在的私鑰會有一個相對的公鑰存在，其私鑰用來「加密」(ECDSA SIGN)，公鑰則用來「解密」 (ECDSA VERIFY)，故更新裝置中應該要預先配備相對的公鑰。為了能限制僅搭配特定的程式碼簽發機構(Code Publish)作「解密」，其公鑰必須存放在一次性燒錄的記憶體中(OTP)，避免被更換為駭客私鑰的對應公鑰。

更新裝置(Device to Upgrade)在收到更新程式(Firmware update)後即先透過Hash function(例如SHA256)獲取其Digest(如同第1步驟)，為確認該Digest是否正確，必須透過公鑰對同步收到的數位簽章作解密並判斷是否符合更新程式的Digest(ECDSA VERIFY)。若是符合，則該更新程式允以更新該裝置。反之，假設該更新程式並非官方發行程式碼(沒有透過Code Publish簽發數位簽章)，經過第5步驟的驗證，因為其計算出來的Digest將不同於透過公鑰所解密的數位簽章，該程式碼則不予運作。

Security Boot流程

如同Security Update流程第5步驟，開機後即先透過Hash Function(例如SHA256)計算應用程式之Digest，接著確認該Digest是否正確：透過公鑰對數位簽章作解密並判斷是否符合該應用程式的Digest (ECDSA VERIFY)。

運行Security Update之裝置需求：

一次性燒錄的記憶體：為了能夠完成Security Update/Security Boot流程，其中步驟4提到裝置必須預先配備公鑰於一次性燒錄的記憶體中(OTP)，目前市售MCU提供OTP功能的並不多，或者價錢相對不便宜。

進行ECDSA VERIFY運算：

步驟5中提到需要對應用程式Digest與程式碼數位簽章利用OTP區的公鑰進行ECDSA VERIFY運算。該運算量相當龐大，如下圖若以Cortex-M0+進行運算將耗費5秒。開機若需要耗費如此多的時間將不容易被使用者接受。

Microchip提供ATECC608A可外掛支援Security Boot 功能

ATECC608A提供基於硬體的密鑰儲存與加密算法加速器，用以實現各種身分驗證和加密協議，基於落實Security Boot。使用者能預先將公鑰存放於ATECC608A的Secured EEPROM中，並透過ECDSA 硬體加速器進行Digest和數位簽章的驗證運算(Verify)。而運算結果亦可以透過輸出保護密鑰(IO Protection Key)輸出，駭客無法判讀或進行複製。更多Microchip資訊請至官網。(文章由Microchip顏睿余提供，賴品如整理報導)