共用方式為


裝置更新安全性模型

IoT 中樞裝置更新能以安全的方法將裝置韌體、映像和應用程式的更新部署至 IoT 裝置。 這套工作流程提供端對端安全通道,以及裝置可用於證明更新是受到信任、未經修改且刻意的完整監管鏈模型。

裝置更新工作流程中的所有步驟都會受到多種安全性功能和程序的保護,以確保管線中每個步驟可安全遞交至下一步。 裝置更新代理程式參考程式碼會找出並妥善管理所有不合法的更新要求, 參考代理程式也會檢查每項下載作業,確認內容是受到信任、未經修改且為刻意。

摘要

當更新匯入裝置更新執行個體時,服務會上傳並檢查更新二進位檔案,以確認並未遭到惡意使用者修改或交換。 驗證完畢後,裝置更新服務會產生內部更新資訊清單,其中包含來自匯入資訊清單和其他中繼資料的檔案雜湊, 接著裝置更新服務便會簽署這份更新資訊清單。

更新二進位檔案和相關聯的客戶中繼資料匯入至服務並儲存至 Azure 後,Azure 儲存體服務會自動加密這些待用內容。 裝置更新服務不會自動提供額外加密,但允許開發人員在內容送至裝置更新服務以前自行加密內容。

更新從裝置更新服務部署到裝置後,系統會透過受保護的 IoT 中樞通道將已簽署的訊息傳送至裝置。 要求的簽章會由裝置的裝置更新代理程式驗證真實性。

所有產生的二進位下載內容都會受到更新資訊清單簽章驗證的保護。 更新資訊清單包含二進位檔案雜湊,因此只要資訊清單收到信任,裝置更新代理程式就會信任雜湊,並將其與二進位檔案比對。 下載的更新二進位檔案經過驗證後,會遞交給裝置上的安裝程式。

實作詳細資料

為了讓裝置更新服務確實縮小為低效能的簡單裝置,安全性模型會使用原始非對稱金鑰和原始簽章, 如 JSON Web 權杖及 JSON Web 金鑰等以 JSON 為基礎的格式。

透過更新資訊清單保護更新內容

系統會使用兩個簽章驗證更新資訊清單, 這些簽章使用由「簽署」金鑰和「根」金鑰組成的結構而建立。

裝置更新代理程式擁有用於所有裝置更新相容裝置的內嵌公開金鑰, 這些公開金鑰是「根」金鑰, 對應的私密金鑰則由 Microsoft 控管。

Microsoft 也會產生未包含在裝置更新代理程式中或未儲存在裝置上的公開/私密金鑰組, 稱為「簽署」金鑰。

當更新匯入至 IoT 中樞裝置更新,且服務產生更新資訊清單後,服務會使用簽署金鑰簽署資訊清單,並納入經過根金鑰簽署的簽署金鑰本身。 更新資訊清單傳送至裝置後,裝置更新代理程式會收到下列簽章資料:

  1. 簽章值本身。
  2. 用於產生 #1 的演算法。
  3. 用於產生 #1 的簽署金鑰的公開金鑰資訊。
  4. #3 中公開簽署金鑰的簽章。
  5. 用於產生 #3 的根金鑰的公開金鑰識別元。
  6. 用於產生 #4 的演算法。

裝置更新代理程式會使用上方定義的資訊驗證公開金鑰的簽章是否已由根金鑰簽署, 然後再驗證更新資訊清單簽章是否已由簽署金鑰簽署。 如果所有簽章都正確,裝置更新代理程式便會信任更新資訊清單。 由於更新資訊清單包含對應至更新檔案本身的檔案雜湊,因此如果雜湊相符,就代表更新檔案也可以信任。

擁有根金鑰和簽署金鑰讓 Microsoft 可採用定期變換簽署金鑰的安全性最佳做法。

JSON Web 簽章 (JWS)

updateManifestSignature 的用途是確保 updateManifest 內含的資訊並未遭到竄改。 updateManifestSignature 是使用具有 JSON Web 金鑰的 JSON Web 簽章而產生,以便進行來源驗證。 此簽章為有三個區段的 Base64Url 編碼字串,每個區段以 "." 分隔。 若要了解如何剖析及驗證 JSON 金鑰和權杖,請參閱 jws_util.h 協助程式方法 (英文)。

JSON Web 簽章是以 JSON 資料結構簽署內容時廣泛使用的建議 IETF 標準 (英文), 會藉由驗證資料簽章確保資料的完整性。 如需詳細資訊,請參閱 JSON Web 簽章 (JWS) RFC 7515 (英文)。

JSON Web 權杖

JSON Web 權杖 (英文) 是開放的業界標準方法,用於安全表示雙方之間的宣告。

根金鑰

每部裝置更新裝置都必須包含一組根金鑰, 這些金鑰是所有裝置更新簽章的信任根源, 每個簽章都必須透過其中一個根金鑰進行鏈結,才會視為合法。

根金鑰組會隨著時間而變更,因為定期輪替簽署金鑰是妥適的安全做法。 也因為如此,裝置更新代理程式軟體必須依據裝置更新小組指定的時間間隔,更新為最新的根金鑰組。 下一個規劃的根金鑰輪替將於 2025 年 5 月

從裝置更新代理程式 1.1.0 版開始,代理程式會在每次部署更新至該裝置時,自動檢查根金鑰的任何變更。 可能的變更:

  • 有新的根金鑰可供使用。
  • 現有的根金鑰已停用 (有效的「撤銷」),這表示建立信任已不再有效。

如果上述任一項或兩者都成立,裝置更新代理程式會自動從 DU 服務下載新的 根金鑰套件。 此套件包含所有根金鑰的完整集合,以及已停用清單,包含哪些根金鑰和/或簽署金鑰不再有效的相關資訊。 根金鑰套件本身會以每個根金鑰簽署,因此可以從屬於 DU 代理程式本身的原始根金鑰,以及任何後續下載的根金鑰,建立套件的信任。 驗證流程完成後,系統會將任何新的根金鑰視為受信任,以便使用指定更新資訊清單的簽署金鑰來驗證信任,而停用清單中所列的任何根金鑰或簽署金鑰則為此目的不再受信任。。

簽章

所有簽章都隨附由其中一個根金鑰簽署的簽署 (公用) 金鑰。 簽章會辨識簽署金鑰是由哪個根金鑰所簽署的。

裝置更新代理程式若要驗證簽章,必須先驗證簽署 (公用) 金鑰的簽章正確有效,且已由核准根金鑰簽署。 簽署金鑰成功通過驗證後,便可使用已受到信任的簽署公開金鑰來驗證簽章本身。

簽署金鑰的輪替步調比根金鑰更快速,因此訊息會以各種不同簽署金鑰進行簽署。

簽署金鑰的撤銷由裝置更新服務管理,因此使用者不應嘗試快取簽署金鑰, 請一律使用簽章隨附的簽署金鑰。

保護裝置

請務必確保裝置更新相關的安全性資產在裝置上受到適當保護, 避免根金鑰之類的資產遭到修改。 您可以採用多種根金鑰防護措施,例如使用安全性裝置 (TPM、SGX、HSM、其他安全性裝置),或如同目前的參考實作一樣,在裝置更新代理程式中寫入安全性裝置程式碼; 若要採用後者,則必須以數位方式簽署裝置更新代理程式碼,並啟用系統的程式碼完整性支援,以防止代理程式碼遭到惡意修改。

您可能還需要採取其他安全性措施,例如確保以安全的方式執行元件之間的遞交, 例如註冊用於執行各種元件的特定隔離帳戶,以及限制只能使用 localhost 網路通訊 (如 REST API 呼叫)。

下一步

瞭解裝置更新如何使用 Azure 角色型存取控制