輕鬆透過 SRAM 型 PUF 金鑰與 TrustZone 隔離能力，確保 IoT 安全無虞

以物聯網 (IoT) 為基礎打造的設計越來越複雜，需要改進解決方案來確保系統安全無虞，並監控本機與遠端遭受的無情攻擊。但資源有限的 IoT 裝置，在採用安全防護上的進度一直都很緩慢，而且只能採用鬆散架構的軟體修補程式，或是其他根據複雜密碼演算法製成的昂貴精密晶片。開發人員如果要更迅速地採用和實作安全功能，就需要更完善且更容易使用的解決方案。

為了達到嵌入式與 IoT 開發人員的安全需求，許多技術紛紛問世並逐漸進化，例如靜態隨機存取記憶體 (SRAM) 架構的實體不可複製功能 (PUF)，以及 Arm 的 TrustZone。本文將介紹 PUF 與 TrustZone，以及如何透過 NXP Semiconductors、Microchip Technology 和 Maxim Integrated 等廠商的解決方案，來運用這些技術。

SRAM PUF 技術

SRAM PUF 是一種能代替傳統密碼術的簡易型驗證技術，正逐漸整合到以安全為中心的晶片裡，例如 NXP 的 LPC55S6x 系列就在其中添加信任根與佈建 (圖 1)。

圖 1：LPC55S6x 系列 MCU 的方塊圖顯示出 SRAM 架構 PUF 技術等安全建構模塊的整合作業。(圖片來源：NXP)

PUF 技術和金鑰儲存在非揮發性記憶體中的傳統作法不同，後者是 OEM 透過傳統的保險絲方法注入安全性金鑰，或是透過一次性可編程 (OTP) 記憶體技術來注入。PUF 技術則是使用 SRAM 位元單元固有的自然隨機電氣變化，將獨一無二的「指紋」變成祕密的密碼金鑰，可作為安全子系統的基礎。無論狀況為何，這個安全且高品質的金鑰，每次都能重新建構成相同的密碼金鑰。這個作法有許多優點：

• 無需在可能不安全的環境中處理第三方金鑰
• 生產晶片時不需要載入金鑰儲存與佈建系統
• 可在後續的供應鏈階段中安裝，甚至能在已部署完成的裝置上改裝
• 除非能實體取得個別 SRAM 晶片，否則幾乎無法破解這些安全金鑰
• 金鑰僅會在有需要時才會產生，而且不會持續儲存在系統上
• 金鑰不會永久儲存，而且裝置無作用時，金鑰也不會出現，因此攻擊者很難實際嘗試破壞記憶體的內容

Arm TrustZone

Arm Cortex®-M23 以及 Cortex-M33 處理平台中的 TrustZone 技術，針對超低功率嵌入式應用進行最佳化，能將許多關鍵安全例行作業置於受保護的環境，例如開機碼、安全設定、安全金鑰、加密資料庫和韌體更新等 (圖 2)。例如在可使用 TrustZone 功能的微控制器中，關鍵任務程式碼在從大型程式碼堆疊分離後，便徹底經過測試，以免因開發人員產生的錯誤而受到影響。

圖 2：TrustZone 能啟用多個軟體安全域，而且會個別限制只有信任的軟體環境才能存取安全記憶體及 I/O。(圖片來源：NXP)

在機密資料與程式碼方面，TrustZone 確保安全性的方法是隔離軟體設計的關鍵部分，並在硬體監控器上執行該軟體，而且所在的環境會針對使用者層級的軟體進行讀寫保護。

TrustZone 能讓開發人員將記憶體分為安全和非安全區域，而且就算只是嘗試除錯，若未通過驗證，仍無法取得安全程式碼及資料。此外，處於非安全狀態的 CPU，只能從非安全記憶體來存取資料，也因此只能從非安全程式記憶體執行。

很重要的一點是，TrustZone 雖然提供這些安全性功能，但依然針對安全和非安全域保有低中斷延遲。而且，不會造成程式碼和週期的額外負荷，也不會施加虛擬化解決方案的複雜性。

PUF 和 TrustZone 的實體實作

NXP 整合了來自 PUF 發明者 Intrinsic ID 的硬 IP 以及支援的軟體資料庫，以在 LPC55Sxx 微控制器中實作 PUF (圖 3)。Intrinsic ID 的嵌入式硬體 IP (QuiddiKey)，能處理金鑰的生成、儲存與佈建，以及元件的驗證和晶片資產管理。

圖 3：NXP 整合了來自 Intrinsic ID 的硬 IP 和支援性軟體資料庫，以在 LPC55Sxx 微控制器中實作 PUF。IP 會處理金鑰的生成和管理。(圖片來源：Intrinsic ID)

NXP 也在 LPC55Sxx 微控制器中採用 TrustZone。TrustZone 採用以 CPU 為中心的做法來保障 IoT 安全性，此做法能將嵌入式設計的安全部分與非安全部分隔離。

舉例來說，就如同 Microchip Technology 的 SAM L10/11 微控制器的實作情況，TrustZone 會提供涵蓋整個系統的防護，並將 IoT 設計區分成安全狀態和非安全狀態。但安全和非安全程式碼都是在單一 CPU 上執行，以達到高效率的嵌入式實作。

這個以 CPU 為中心的做法很重要，因為現代微控制器內的軟體數量快速成長，並以通訊協定堆疊，為 Wi-Fi、藍牙和傳輸層安全性 (TLS) 等連線技術提供服務。程式碼基底規模越來越大，使得 IoT 裝置暴露於惡意攻擊的風險大幅提高。舉例來說，如果智慧住家與大樓裡的協定堆疊受損，連線的門鎖、車庫門開啟器和保全攝影機就岌岌可危。

但是，如果 IoT 開發人員將關鍵任務型程式碼移到 TrustZone 防護環境裡，即使是第三方協定堆疊中的錯誤，也不會嚴重影響到裝置功能。

板級安全性

IoT 安全性典範中另一個明顯的型態與公版設計的可用性有關，公版設計能克服安全性及通訊協定方面的複雜性，藉此簡化邊緣對邊緣以及雲端對邊緣的通訊。Maxim Integrated 的 MAXREFDES155# DeepCover® 公版設計，以及 Microchip 的 AC164164 PIC®-IoT WG 開發板，就是很好的範例。

MAXREFDES155# 安全設計使用一條 300 mm 纜線，將 Arm mbed™ 擴充板板連接到感測器端點。此感測器端點包含 DS28C36 DeepCover 安全驗證器、紅外線 (IR) 熱感測器，以及紅外線感測器的瞄準雷射 (圖 4)。

圖 4：Maxim Integrated 的 MAXREFDES155# DeepCover IoT 嵌入式安全性公版設計包含 Arm mbed 擴充板、透過 I²C 連接的感測器端點，以及透過 Wi-Fi 的雲端連線能力。(圖片來源：Maxim Integrated)

DS28C36 安全晶片提供兩個經過驗證的一般用途輸入／輸出 (GPIO) 引腳，還能選配安全狀態控制與位準感測功能。如此一來，IoT 開發人員能藉由經過驗證的電氣抹除式可編程唯讀記憶體 (EEPROM) 設定，以及 17 位元的遞減計數器，來監測並限制周邊裝置的使用。能從 DS28C36 獲得助益的應用，包括雙向驗證、系統資料 (如密碼金鑰) 的安全儲存、關鍵任務型資料驗證、安全啟動，以及終端產品的使用控制。

在 MAXREFDES155# 公版設計中，mbed 擴充板包含 DeepCover 安全性輔助處理器、Wi-Fi 通訊、液晶顯示器 (LCD)、按鈕控制項，以及狀態發光二極體 (LED)。此公版設計使用 MAX32600MBED# mbed 開發板進行即時測試，而此擴充板的 Wi-Fi 電路能促進與網路伺服器的通訊。

在 MAXREFDES155# 設計中，mbed 擴充板上的安全輔助處理器是 DS28C36 驗證器晶片的輔助元件。此元件有助於滿足與雜湊架構訊息驗證碼 (HMAC) 及橢圓曲線數位簽章演算法 (ECDSA) 運算有關的要求，這些都屬於 DS28C36 安全操作的一部分。

輔助處理器提供一套密碼工具核心組合，可協助 IoT 設計人員實作密碼引擎，並整合聯邦資訊處理標準／國家標準暨技術局 (FIPS/NIST) 真實亂數產生器 (RNG)。公共與私人安全金鑰會根據 NIST 定義的標準來運作，其中包括 FIPS 186，此 ECDSA 簽章生成與驗證機制可支援雙向非對稱金鑰驗證模式。

簡化雲端連結的安全性

Microchip 的 AC164164 PIC-IoT WG 開發板雖有類似的元素，但著重於簡化 IoT 節點與 Google Cloud 等雲端平台的連結。此開發平台以 Microchip 的 PIC 微控制器為基礎打造，並使用 ATECC608A 輔助處理器來處理大型軟體架構和即時作業系統 (RTOS) 平台伴隨而來的安全漏洞。

AC164164 IoT 設計平台的邊緣對雲端連結安全性可透過一個安全元件獲得保障，此元件已預先註冊 Google Cloud IoT Core 服務，而且隨時可搭配零接觸佈建進行使用。除了 ATECC608A 安全輔助處理器，此開發板還有 PIC24FJ128GA705 微控制器，能以更少的程式碼和更低的功耗來處理複雜的應用。

獲得完整認證的 IEEE 802.11b/g/n IoT Wi-Fi 控制器，將 IoT 節點連結到 Google Cloud。因此，IoT 開發人員無需擁有無線網路協定、安全性與硬體相容性的專業，就能實現安全的 IoT 產品設計。

結論

有了專業的安全晶片 (作為 IoT 設計中主處理器或微控制器的輔助晶片)，開發人員無需成為安全專家，就能保護 IoT 節點及其與端點和雲端平台之間的連結。隨著 IoT 安全需求增加，PUF 和 TrustZone 等輔助技術的整合，進一步強化了低功耗、低成本微控制器的安全認證。

除此之外，公版設計與開發板在多種 IoT 應用中採取多重等級的嵌入式防護，能更輕易在安全防護上達到平衡。