PHP重大漏洞顯示IoT設備的資安風險不只存在於應用程式，更可能延伸至韌體與底層控制。透過安全啟動、MCU韌體驗證、TPM平台量測及安全元件金鑰保護，可建立多層防線，降低攻擊擴散風險。
PHP等應用程式漏洞所引發的遠端程式碼執行(RCE)風險，再次凸顯軟體安全對物聯網(IoT)設備的重要性。對採用Linux、Web管理介面與遠端維護服務的IoT設備而言，應用程式漏洞不只是網站維運問題，也可能成為攻擊者進入設備內部網路與控制系統的入口。
然而，取得應用程式層的程式執行能力，不代表攻擊者就能直接修改韌體、控制微控制器(MCU)，或讀取受到硬體保護的金鑰。攻擊能否深入，取決於程序權限、系統隔離、韌體更新流程及硬體信任根的設計。當上層軟體失守，底層硬體能否守住關鍵資源，成為衡量IoT產品韌性的重要指標。
從Boot ROM、安全啟動(Secure Boot)，到可信任平台模組(TPM)與獨立安全元件(Secure Element, SE)，不同技術分別承擔信任建立、平台量測、設備身分與金鑰保護等任務。另一方面，人工智慧(AI)正加速進入IoT與工業控制領域，也使資安風險從傳統軟體與韌體延伸至模型、資料及自主控制流程。隨著歐盟《網路韌性法案》(Cyber Resilience Act, CRA)逐步實施，產品安全更進一步延伸至漏洞處理、技術文件、軟體更新與全生命週期管理。
「硬體信任根」從晶片建立韌體信任與防護
IoT閘道器通常整合Web管理介面、Linux作業系統、韌體更新服務及MCU。若PHP管理服務存在可被利用的RCE漏洞，攻擊者可能取得Web服務程序的執行權限，進一步嘗試竊取憑證、橫向移動或提升權限。但能否取得系統管理權限、修改韌體或控制下游MCU，仍取決於設備的安全架構。
硬體信任根(Hardware Root of Trust, HRoT)是系統建立初始信任的基礎，通常由不可任意修改的硬體、Boot ROM、受保護的金鑰及相關安全機制組成。透過安全啟動、金鑰保護、硬體存取控制與韌體更新驗證，可降低未經授權的程式執行及韌體遭竄改的風險。
但硬體信任根並非單一功能，也不能保證設備永遠不受攻擊。完整防護仍須涵蓋啟動、執行、更新、異常偵測與安全復原，並明確界定各層的權限與責任。
從Boot ROM與密碼學IP建立信任鏈
Boot ROM通常是晶片啟動時最先執行的程式碼，可依設計驗證下一階段Bootloader或韌體的數位簽章，逐步建立信任鏈。若簽章驗證、信任金鑰配置或啟動流程存在缺陷，後續韌體即使具備安全功能，也可能無法建立可靠的信任基礎。
密碼學IP可加速雜湊、數位簽章驗證及加解密運算，但運算加速不等於金鑰安全。若私鑰仍可被一般軟體讀取，或金鑰使用權限缺乏限制，硬體加速器也無法充分防止金鑰外洩或遭濫用。晶片還需要適當的金鑰儲存、記憶體隔離、周邊存取控制與除錯介面管理。
近年開放式硬體信任根也逐漸受到產業關注。Caliptra是起源於Open Compute Project(OCP)、目前由CHIPS Alliance推動的開放原始碼硬體信任根專案，整合硬體IP、ROM與韌體，提供晶片身分識別、量測式啟動及硬體證明等能力。
Caliptra目前主要面向資料中心級的系統單晶片(SoC)——例如CPU、GPU、DPU與TPU，並非專為一般低功耗IoT晶片設計；然其價值在於提供可參考、整合與驗證的硬體信任根架構，而非要求所有IoT產品直接採用。一般IoT晶片仍須依功耗、成本、處理能力與產品風險，選擇適當的安全架構。
資料來源：CHIPS Alliance、Open Compute Project。
MCU安全必須貫穿啟動、更新與復原
Physical AI帶動人工智慧從雲端走向實體世界，機器人、智慧製造及自主設備逐漸整合感測器、邊緣運算與即時控制，MCU承擔更多感知、決策與控制任務後，可望迎來新一波的成長曲線，但與此同時，其韌體完整性、更新安全與執行環境防護的重要性也同步提高。
MCU廣泛應用於感測器、馬達控制、工業自動化及低功耗設備。即使不執行複雜的作業系統，也可能直接參與設備控制；韌體遭未授權修改，將影響設備行為甚至營運安全。其安全架構至少應涵蓋四個面向：
- 安全啟動(Secure Boot)：啟動時驗證韌體來源與完整性，避免未經授權的映像執行，但不能修補執行中的軟體漏洞，也不能取代更新階段的授權控制。
- 韌體更新與防回滾(Anti-Rollback)：驗證韌體簽章、裝置適用性與版本資訊，避免植入未授權韌體或降回已知存在漏洞的舊版本，並透過可信任的單調計數器或版本管理機制維護安全狀態。
- 除錯介面管理：JTAG、SWD等介面有助於開發與故障分析，但量產設備必須限制未授權存取，避免敏感記憶體遭讀取或程式遭修改。
- 安全復原：當更新中斷、韌體損毀或系統偵測到異常時，提供可信任的復原方式，避免持續執行不可信任韌體。
NIST SP 800-193將韌體保護、未授權變更的偵測及安全復原列為平台韌性的重要能力。MCU廠商不能只在規格表上標示Secure Boot，還應驗證更新、防回滾與復原流程能否在實際產品中正確運作。
資料來源：新唐科技
TPM與安全元件守住平台信任與設備金鑰
TPM與SE都能提供硬體層級的金鑰保護與密碼學功能，但設計目的與能力不同。
TPM：以平台量測建立可信任的設備狀態
TPM依Trusted Computing Group(TCG)規格提供金鑰管理、平台量測與證明功能。透過平台組態暫存器(PCR)，系統可保存啟動流程各階段的量測結果，並支援遠端證明，讓管理系統依據量測資料與安全政策判斷設備狀態。
Secure Boot與TPM可以互補：前者依既定政策驗證啟動映像，後者保存平台量測結果，支援後續的狀態驗證與遠端證明。不過，TPM不會自動判斷所有軟體是否安全，也不一定直接控制主處理器的啟動流程。即使量測結果可信，高權限的惡意程序仍可能濫用系統權限。
SE：守護設備身分與金鑰安全
獨立安全元件通常是與主處理器或MCU分開的安全晶片，可提供受保護的金鑰儲存、憑證管理及密碼學操作。例如，IoT閘道器可將設備私鑰存放在安全元件中，透過受限制的介面執行簽章或身分認證，降低私鑰暴露於一般檔案系統的風險。
安全元件不一定具備TPM的PCR、平台量測與標準化遠端證明能力，也不一定直接控制主處理器的啟動流程。即使私鑰無法被讀出，遭入侵的程序仍可能要求安全元件執行未經適當授權的簽章操作，造成金鑰遭濫用。
簡言之，TPM、獨立安全元件與MCU內建安全功能應依產品需求分工，而非互相取代：TPM偏重平台量測與證明，安全元件偏重設備身分及金鑰保護，MCU安全機制則確保自身韌體與控制流程的完整性。
ARM TrustZone與 RISC-V：安全性取決於實際實作
部分ARM平台透過TrustZone建立安全與非安全執行環境，隔離一般應用程式與受保護的安全服務。這有助於保護金鑰操作及敏感資料，但若安全服務介面存在授權不足、參數驗證缺陷或不當的周邊配置，隔離機制仍可能遭到濫用。
RISC-V是開放式指令集架構，不同廠商可依需求設計處理器核心與SoC。其安全能力取決於具體實作，包括啟動ROM、記憶體隔離、密碼學功能、除錯控制與可信任執行環境(TEE)等。
無論採用哪種架構，都應檢查啟動信任鏈、金鑰管理、權限隔離及韌體更新流程，而非只確認晶片是否支援特定安全功能。處理器信任根、TPM 或安全元件與上層軟體必須妥善整合，才能形成完整且可驗證的安全架構。
AI對IoT資安的影響：攻擊面擴大，也帶來防禦能力
AI正逐步進入IoT閘道器、工業控制器、智慧攝影機與機器人等設備，從雲端模型推論延伸至邊緣AI與自主決策。這不僅改變設備的運作方式，也讓資安風險從傳統作業系統與韌體，擴展至模型、資料、推論服務及AI代理的操作權限。
AI模型與資料成為新的攻擊目標
攻擊者可能透過惡意輸入、資料投毒、模型竄改或模型供應鏈漏洞，影響AI的辨識結果與設備決策。例如，智慧攝影機可能因輸入資料遭操縱而產生錯誤辨識，工業設備則可能因異常感測資料或模型輸出遭干擾而採取不適當的控制行為。
若AI系統能直接呼叫設備API、控制馬達或執行遠端操作，模型遭操縱便可能轉化為實體控制風險。AI決策無法取代設備原有的安全控制機制，涉及人身、設備及營運安全的操作，仍須受到獨立的權限驗證與安全政策約束。
邊緣AI擴大軟硬體整合的安全範圍
邊緣AI設備可能同時使用Linux、容器、第三方推論框架、模型檔案與遠端更新服務。即使底層MCU具有Secure Boot，也不代表模型、推論環境或AI應用程式都可信任。
除了韌體簽章，也應建立模型來源驗證、版本控管、完整性檢查及更新授權機制。模型與資料集的來源、訓練流程、第三方套件及部署版本，也應納入供應鏈管理，避免不可信任的模型或元件進入產品。
AI也能成為資安防禦工具
另一方面，AI能協助分析網路流量、辨識異常設備行為、關聯漏洞資訊及進行威脅事件分類，提升IoT設備的異常偵測與安全維運效率。例如，透過分析設備通訊模式，可以協助發現異常連線、非預期指令或設備行為偏移。
但AI偵測結果不能直接取代安全政策與人工驗證，尤其涉及工業控制及實體設備操作時，必須保留權限限制、人工覆核與安全失效機制。
對產品製造商而言，AI資安應納入原有產品安全生命週期，涵蓋模型與資料來源、第三方套件、推論服務、設備權限及更新流程。AI帶來的並非單純新增一項軟體功能，而是擴大整體產品的信任邊界。
閘道器與MCU協同防護，避免攻擊跨層擴散
在工業物聯網(IIoT)系統中，閘道器通常負責網路通訊與遠端管理，MCU則負責感測器、馬達或即時控制任務。兩者可能透過UART、SPI、CAN等介面交換資料。若閘道器遭入侵，攻擊者可能向下游MCU發送未授權指令，或利用韌體更新流程植入不安全映像。
閘道器上的TPM可協助記錄平台量測，安全元件可保護設備憑證與私鑰，但兩者都不會自動驗證終端MCU的韌體。若MCU不驗證更新映像，即使閘道器具備TPM，也無法單靠TPM保證MCU執行的韌體可信任。反之，若MCU具備獨立的Secure Boot、簽章驗證與防回滾機制，即使上游系統遭入侵，仍可能拒絕未授權或不符合安全版本政策的韌體。
跨晶片架構應明確劃分責任：上游設備可以提出控制或更新請求，下游MCU仍須依自身安全政策驗證關鍵操作。涉及安全風險的控制指令，還應視產品需求加入裝置身分驗證、訊息完整性保護、重放攻擊防護與操作授權。若設備整合AI決策功能，也應限制模型或代理直接執行高風險控制指令，確保關鍵操作受到獨立安全政策約束。
從上市到退場，EU CRA全面擴大安全責任
歐盟《網路韌性法案》針對適用範圍內的具數位元素產品，建立涵蓋安全設計、漏洞管理、技術文件與產品支援的網路安全要求。法規並未強制採用特定晶片或安全元件，而是要求製造商依產品風險落實適當防護，將資安責任納入產品設計與開發流程。
在法規要求下，製造商必須進一步建立持續性的漏洞管理與供應鏈追蹤機制。2026年9月11日起，CRA第14條漏洞與嚴重資安事件通報義務已開始適用，主要產品安全要求則自2027年12月11日起適用。從PHP、Linux、Bootloader到AI模型、推論框架及第三方套件，都應納入元件盤點、漏洞評估與版本管理，並透過軟體清單(SBOM)、風險評估及技術文件掌握供應鏈安全狀態。
因此，產品安全不能止於出廠前的檢測，而須延伸至部署、更新與維護階段，持續確認晶片、韌體、作業系統、應用程式及AI模型的來源與完整性，確保信任鏈各環節皆可驗證、可追溯。製造商也須明確劃分供應鏈各方責任，確保元件更新與漏洞修補不破壞既有信任關係。
從晶片建立信任，讓系統在失守時仍有防線
從Boot ROM、MCU安全啟動與韌體更新，到TPM平台量測、遠端證明及安全元件金鑰保護，IoT設備須整合不同層級的安全機制，建立從晶片、韌體到系統的完整信任鏈。面對AI技術加速導入IoT設備，信任鏈也須延伸至模型、資料及推論服務，透過完整性驗證與存取控制，降低模型遭竄改或錯誤決策帶來的風險。
真正的產品韌性，始於晶片透過硬體信任根建立初始信任，再由Bootloader驗證韌體與作業系統，逐層延伸至應用程式及AI模型的來源與完整性，形成完整的信任鏈(Chain of Trust)。唯有將信任鏈從晶片延伸至軟體、AI與供應鏈，確保各層信任關係可驗證、可追溯，才能在局部環節遭入侵時維持整體防護能力，避免單點失守演變成全面性風險。