使用加密晶片在 IoT 裝置設計中添加安全啟動功能

儘管開發人員已經盡全力，物聯網 (IoT) 設計仍有可能遭到預期用來保持安全性的程式碼攻擊。駭客往往會攻擊看似相當安全的設計，方法是用安全受損的程式碼取代韌體。安全啟動方法可以降低這些風險，但要正確實作則有難度。

開發人員需要使用更簡易的方法來實作安全啟動，而這也只是確保 IoT 裝置安全性整體策略中的一部分而已。

本文概述 IoT 裝置設計中常見的攻擊層面，以及基本的安全防護方法 (包含安全金鑰儲存、加密以及驗證) 所扮演的角色。本文接著會介紹一款安全晶片，能讓開發人員在整體策略中添加安全啟動和其他必要功能，以便確保 IoT 裝置的安全性。

IoT 裝置弱點

對駭客來說，IoT 裝置有非常多的攻擊入口點，能讓裝置本身、所處網路甚至是其最終應用都遭到中斷。雖然開發人員能使用多種技術來強化網路與應用的安全性，但 IoT 裝置的記憶體以及處理資源有限，因此確保裝置安全性一直都是一大挑戰。

雖然開發人員逐漸採用加密方法來保護資料，但許多裝置的設計並沒有必要的安全驗證功能，無法預防駭客偽裝成授權伺服器、閘道器或其他 IoT 裝置來攔截通訊。在某些情況下，若裝置使用有效卻薄弱的驗證方法，仍舊無力招架複雜的攻擊。這些複雜攻擊會攔截看似私密的通訊工作階段中所使用的有效安全金鑰，然後再次利用。

IoT 裝置更新

另一項更重要的安全弱點，涉及到目前愈來愈多 IoT 裝置內建的空中 (OTA) 更新能力。在快速變遷的 IoT 市場中，OTA 更新是重要的功能。開發人員只要在部署的裝置上升級韌體，即可因應客戶對於新功能 (或錯誤修正) 的要求。在典型的 OTA 更新流程中，IoT 裝置會定期尋找更新、在新的程式碼推出時進行下載，並執行一連串系統調用來完成更新流程。

舉例來說，對於 Microchip Technology 的 SAM D21 MCU 架構 IoT 元件來說，裝置的韌體包含 OTA 更新程式碼，會從預設的端點下載映像檔、檢查是否順利完成，然後才會切換到新的韌體組 (清單 1)。以下是 Microchip 進階軟體架構套件的列表，在 OTA 韌體初始化 (m2m_ota_init()) 後，回調常式 OtaUpdateCb() 會在 OTA 韌體下載新的程式碼映像後切換到新的韌體組 (m2m_ota_switch_firmware())，然後在系統重置後使 MCU 重新啟動至更新的韌體。

複製

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

   if(u8OtaUpdateStatusType == DL_STATUS) {

       if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

           //switch to the upgraded firmware

           m2m_ota_switch_firmware();

       }

}

   else if(u8OtaUpdateStatusType == SW_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

           M2M_INFO("Now OTA successfully done");

           //start the host SW upgrade then system reset is required (Reinitialize the driver)

}

}

}

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

   case M2M_WIFI_REQ_DHCP_CONF:

{

       //after successfully connection, start the over air upgrade

       m2m_ota_start_update(OTA_URL);

}

   break;

   default:

break;

}

int main (void)

{

   tstrWifiInitParam param;

   tstr1xAuthCredentials gstrCred1x    = AUTH_CREDENTIALS;

   nm_bsp_init();

   m2m_memset((uint8*)&param, 0, sizeof(param));

   param.pfAppWifiCb = wifi_event_cb;

   //Initialize the WINC Driver

   ret = m2m_wifi_init(&param);

   if (M2M_SUCCESS != ret)

{

       M2M_ERR("Driver Init Failed <%d>\n",ret);

       while(1);

}

   //Initialize the OTA module

   m2m_ota_init(OtaUpdateCb,NULL);

   //connect to AP that provide connection to the OTA server

   m2m_wifi_default_connect();

   while(1)

{

       //Handle the app state machine plus the WINC event handler                                                                    

       while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

}

}

}

列表 1：在這個 Microchip 進階軟體架構套件的空中 (OTA) 程式碼範例中，Wi-Fi 事件處理常式的回調 wifi_event_cb() 會使用指定的 URL 來開始 OTA 更新 m2m_ota_start_update(OTA_URL)，然後在 OtaUpdateCb() 成功完成時切換至新的韌體 m2m_ota_switch_firmware()。(程式碼來源：Microchip Technology)

為了檢查下載的程式碼是否有效，開發人員長期以來都仰賴認可的憑證機構所核發的程式碼簽章憑證。即便如此，安全資料的儲存、驗證技術的實作，以及憑證的保護上依舊有弱點，能為駭客開放許多接管 IoT 裝置的方便之門。

即便使用傳統的安全技術，裝置本身的韌體更新流程還是可能會遭到欺騙，將有效的程式碼更換為受損的程式碼。在重新啟動時，裝置會成為駭客的工具，可用來深入滲透到 IoT 網路、IoT 應用，甚至是企業的內部資源中。

在此情況下，安全啟動 IoT 裝置的能力便成為重要的防線。但對開發人員來說，要達到安全啟動，在安全儲存、加密、驗證以及程式碼驗證機制上就有眾多要求。

在軟體中實作安全啟動，會讓更新流程受到攻擊，這些攻擊方法著重於從裝置儲存空間擷取安全金鑰、攔截加密資料、欺騙驗證機制以及破壞程式碼的驗證演算法。在實務上，IoT 設計通常缺乏額外的記憶體及處理能力，而這正是軟體解決方案在任何狀況下所需要的。即便如此，硬體作法一樣無法永遠保障安全性。

若要在硬體中實作安全啟動，IoT 裝置以往都需要使用一些專門元件，但會大幅增加設計複雜性和成本，這種狀況一直到近期才有改變。即便開發人員將這些個別元件進行整合，駭客若有決心，還是能輕鬆獲得目標 IoT 裝置的樣品，並透過匯流排與訊號互連元件來攻擊個別安全元件。相對來說，Microchip Technology 的 ATECC608A 則屬於單晶片解決方案，能讓開發人員添加安全啟動功能，而不會外露內部機密或安全機制。

安全 IC

ATECC608A 屬於八引腳安全元件，能透過簡易的序列介面，提供精密的輔助安全功能，藉此支援主機 MCU (圖 1)。

圖 1：ATECC608A 屬於八引腳加密輔助處理器，具有安全的硬體式金鑰儲存功能。(圖片來源：Microchip Technology)

此裝置提供完整的硬體式安全解決方案，兼具整合式加密加速器以及晶片上安全儲存空間，可支援 SHA-256 和 AES-128 在內的多種加密演算法，以及完備的橢圓曲線演算法，包含橢圓曲線數位簽章演算法 (ECDSA)、橢圓曲線迪菲-赫爾曼 (ECDH) 和 NIST 曲線 P-256。除了這些加密機制之外，此裝置還支援更高階的傳輸層安全性 (TLS) 通訊協定，包括 TLS 1.3。與之前的裝置不同的是，ATECC608A 能產生並安全地儲存工作階段金鑰，有助於減緩在使用 TLS 驗證時經常面臨的威脅來源。

雖然這些特點對於確保 IoT 裝置正常運作扮演相當重要的角色，但 ATECC608A 對安全啟動功能的支援，則進一步將安全性涵蓋範圍延伸到基本的韌體更新流程。在此，ATECC608A 會驗證新的程式碼組，並將訊息回傳到 MCU，指出成功或失敗。視現有的安全原則而定，MCU 此時也許會再次嘗試更新、傳送警告訊息至安全監視端點、停止或略過更新，以及重新啟動成原始程式碼。

硬體整合

對開發人員來說，若要在 MCU 架構設計中增添安全啟動功能以及其他安全功能，ATECC608A 的額外要求相對較少。就硬體層面來說，設計人員最多只需要處理四個連接，包括 V_CC、GND、序列時脈輸入 (SCL) 以及序列數據 (SDA)。剩下四個引腳則未連接。除了將 V_CC 連接到 2.0 V 至 5.5 V 的電源之外，剩下唯一要做的決定就是與 MCU 建立序列連接。

設計人員能將裝置的 SCL 與 SDA 引腳連接到 MCU，達到傳統 I²C 連接。或者，設計人員也能善加利用裝置對 Microchip 單線介面的支援。在此，開發人員將裝置的 SDA 埠接至 MCU GPIO 引腳，並使用 Microchip 的單線時序協定來傳輸邏輯數值 0 與 1 (圖 2)。

圖 2：在 Microchip 單線序列通訊協定中，指定持續時間的一連串波形傳輸可發出邏輯 0 或邏輯 1 訊號。(圖片來源：Microchip Technology)

在此通訊協定中，ATECC608A 和 MCU 之間的邏輯值傳輸過程，首先會以指定持續時間的起始脈衝 (t_START) 開始。在起始脈衝發出之後，通訊協定會將邏輯 0 定義為一個零傳輸高脈衝週期 (t_ZHI)，伴隨著指定持續時間的零傳輸低脈衝 (t_ZLO)。以此類推，若是持續的高位準，則代表是邏輯 1 傳輸。

無論何種情況，此通訊協定都會預期訊號在指定的位元時間 (t_BIT) 內變為低位準。在一連串位元傳輸後，若序列線路在指定的 IO 逾時時間後沒有活動，就可將裝置設定成自動進入睡眠模式。若要搭配 ATECC608A 使用，開發人員不太需要擔心此通訊協定的時序細節：Microchip 將關鍵的時序參數制訂成相容於 230.4 Kbaud 運作的標準 UART。

裝置配置

ATECC608A 在裝置層級只需進行最低程度的配置設定。透過 I²C 或單線序列介面，開發人員就能載入 I²C 位址等設定，或設定一些特點，例如在喚醒或啟動時執行自我測試。此裝置提供的一項配置設定，與超低功率 IoT 設計特別相關。

在這些設計中，ATECC608A 在閒置或睡眠模式 (在典型 IoT 設計中最常見的狀態) 下增加的整體功率預算相對來說非常少。在閒置模式下，此裝置的耗電量約為 800 μA；睡眠模式下的耗電量為 150 nA 或更低，視配置而定。當 MCU 喚醒此裝置進行某些安全程序時，裝置的耗電量在進行作業時也仍只有 14 mA。即便如此，功率預算非常吃緊的設計可能仍需要更低的有功功率位準。

為了支援這些設計，此裝置提供一種配置選項，能讓開發人員選擇三種不同的操作模式，犧牲執行速度以換取更低的功耗。因此，開發人員能將有功功率從 14 mA (最大執行速度) 降低至 6 mA 或 3 mA (對應更低的執行速度)。

除了多種低階配置項目之外，如果在開發前早就準備好 ATECC608A 等安全裝置的安全資訊，裝置會更有效。如果安全金鑰與證明書在開發期間就出現錯誤或漏洞，就算在安全性上做了最大的努力，也可能前功盡棄。為了因應這項可能的威脅，Microchip 的可信賴佈建服務會載入包括金鑰和憑證在內的安全資料，作為製造流程的一部分。

當原廠在安全環境中載入安全資訊後，即使在裝置經過供應鏈的一般搬運過程時，此安全資訊也會持續受到保護，不受意外或蓄意性的探索影響。ATECC608A 含有特殊的運送鎖定功能，會持續停用裝置，直到使用從最終主機 MCU 傳來的金鑰，以加密方式啟用裝置為止。

經主機 MCU 啟用後，ATECC608A 會隨機產生稱為 IO 防護金鑰的安全金鑰，並與 MCU 共享。ATECC608A 與 MCU 之間後續的通訊會使用這個 IO 防護金鑰來加密，此機制會在安全啟動以及其他安全流程期間提供額外的驗證。

若駭客要透過方法來騙過驗證流程，例如攔截與 ATECC608A 的連線，然後將其專屬的「成功」訊號饋送到 MCU，這個 IO 防護金鑰機制會讓 MCU 忽略假訊號。就算駭客以某種方式入侵了 ATECC608A 裝置，並嘗試在其他系統中使用此裝置，IO 防護金鑰機制仍可有效避免裝置的使用。

軟體整合

ATECC608A 雖有眾多精密的功能與防護機制，但仍可直覺的套用到 MCU 架構設計中。除了實作簡單的硬體介面與先前提到的配置設定外，開發人員還能使用應用程式開發介面 (API)，將安全性運作的細節進行抽象化。Microchip 的 CryptoAuthLib 加密驗證程式庫提供全面的軟體套件，內含定義、結構，以及必要的 API 調用以完整發揮 ATECC608A 的特點。這個程式庫可當作硬體中立層，透過硬體抽象層 (HAL) 的 API 以及特定硬體目標的驅動程式來運作 (圖 3)。

圖 3：Microchip 的 CryptoAuthLib 程式庫在應用程式與底層硬體之間提供加密服務層，可透過硬體專屬驅動程式上方的硬體抽象化層進行存取，為不同硬體組合提供可攜性。(圖片來源：Microchip Technology)

開發人員使用 CryptoAuthLib API 常式，如 io_protection_set_key() 來產生 IO 防護金鑰，並使用 atcab_secureboot() 來執行 ATECC608A 的安全啟動驗證機制，以比對調用參數中所含的程式碼摘要或簽章。

雖然 API 的命令相當直覺，但實作安全性所需的特定設定、管理及操作步驟可能頗具挑戰性。開發人員嘗試實行的安全性機制，若遺漏關鍵步驟或是以錯誤的順序執行，可能會造成延遲。

透過 Microchip 的 SAM D21 MCU 架構 ATSAMD21-XPRO 開發套件及搭載 ATECC608A 的 ATCRYPTOAUTH-XPRO-B 附加電路板，開發人員就能快速累積使用這些一般機制以及 ATECC608A 指定功能的相關經驗。Microchip 提供豐富的安全啟動軟體套件，可在 ATSAMD21-XPRO 與 ATCRYPTOAUTH-XPRO-B 上執行，並可使用 Microchip 的 ATOLED1-XPRO 為範例應用程式提供基本的顯示介面 (圖 4)。

圖 4：開發人員能使用 Microchip 軟體和 SAM D21 MCU 架構 ATSAMD21-XPRO 開發套件，加上搭載 ATECC608A 的 ATCRYPTOAUTH-XPRO-B 附加電路板以及 ATOLED1-XPRO 顯示器附加板，來快速評估安全啟動流程。(圖片來源：Microchip Technology)

SAM D21 展示套件內含完整的安全啟動常式，可說明用來設置、執行和檢查安全啟動操作狀態的主要軟體設計模式 (列表 2)。使用這個硬體平台和展示軟體套件，開發人員就能快速評估 ATECC608A 在遠端啟動的使用情況，並對範例軟體進行必要的修改，以符合自身需求。

複製

/** \brief Handles secure boot functionality through initialization, execution,

*         and de-initialization.

*  \return ATCA_SUCCESS on success, otherwise an error code.

*/

ATCA_STATUS secure_boot_process(void)

{

   ATCA_STATUS status;

   secure_boot_parameters secure_boot_params;

   uint8_t secure_boot_mode;

   bool secure_boot_app_valid = false;

   /*Initialize secure boot */

   if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

{

       return status;

}

   do

{

       .

.

.

       #if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

.

.

.

       /*Get IO Protection Key*/

       if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

{

return status;

}

       if ((status = atcab_secureboot_mac(secure_boot_mode,

                                          (const uint8_t*)&secure_boot_params.app_digest,

                                          (const uint8_t*)&secure_boot_params.memory_params.signature,

                                          (const uint8_t*)secure_boot_params.randomnum,

                                          (const uint8_t*)secure_boot_params.io_protection_key,

                                          &secure_boot_app_valid)) != ATCA_SUCCESS)

{

break;

}

       #else

       if ((status = atcab_secureboot(secure_boot_mode,

                                      0,

(const uint8_t*)&secure_boot_params.app_digest,

(const uint8_t*)&secure_boot_params.memory_params.signature,

                                      NULL)) != ATCA_SUCCESS)

{

break;

}

       secure_boot_app_valid = true;

       #endif

       /*Check whether the secure boot command executed successfully with the correct return mac  */

       if (!secure_boot_app_valid)

{

break;

}

.

.

.

}

   while (0);

   /* De-initialize memory interface and release its resources*/

   secure_boot_deinit_memory(&secure_boot_params.memory_params);

return status;

}

清單 2：此程式碼片段來自 Microchip 的 SAM D21 展示套件，示範了安全啟動所需的主要設計模式，包含檢查 IO 防護金鑰 (io_protection_get_key())，以及使用摘要、簽章和其他參數 (atcab_secureboot_mac() 或 atcab_secureboot()，視選定的配置而定) 來驗證韌體。(程式碼來源：Microchip Technology)

結論

IoT 裝置具有多個威脅層面，駭客能蓄意利用這些遭破壞的裝置當作侵入 IoT 網路、應用程式及企業資源的入口。在各項風險減緩技術中，安全啟動技術在全面安全策略中竄升成為重要的一環。然而，安全啟動的實作本身有其要求，若未正確處理，可能會讓系統暴露在風險之中。

Microchip Technology 的 ATECC608A 安全 IC 在單一套件中提供全面性解決方案，能讓開發人員輕鬆添加到任何 MCU 架構設計中。使用 ATECC608A，開發人員就可大幅增強安全性，並確保在 IoT 設計中達到安全啟動。