Azure IoT 裝置製造商的安全性做法

隨著越來越多的製造商發行 IoT 裝置，找出常見做法指引會對您有所幫助。 本文摘要說明在製造能與 Azure IoT 中樞裝置佈建服務 (DPS) 搭配使用的裝置時，所應考慮的建議安全性做法。

• 選取裝置驗證選項
• 在 IoT 裝置上安裝憑證
• 將信賴平台模組 (TPM) 整合到製造流程中

選取裝置驗證選項

IoT 裝置安全性量值的最終目標都是要建立安全的 IoT 解決方案。 但硬體限制、成本和安全性專業知識層級等問題全都會影響您選擇的選項。 此外，您的安全性方法也會影響 IoT 裝置用來連線到雲端的方式。 雖然有數個要考慮的 IoT 安全性要素，但每個客戶都會遇到的要素是該使用何種驗證。

三種廣泛使用的驗證類型分別是 X.509 憑證、信賴平台模組 (TPM) 和對稱金鑰。 雖然還有其他驗證類型，但大部分在 Azure IoT 上建置解決方案的客戶都會使用這三種類型的其中一種。 本文其餘部分則會調查使用各種驗證類型的優缺點。

X.509 憑證

X.509 憑證是一種可用於進行驗證的數位身分識別。 X.509 憑證標準記載於 IETF RFC 5280。 在 Azure IoT 中，有兩種方式可以驗證憑證：

• 指紋。 指紋演算法會在憑證上執行，以產生十六進位字串。 所產生的字串是憑證的唯一識別碼。
• 以完整鏈結為基礎的 CA 驗證。 憑證鏈結是要驗證終端實體 (EE) 憑證所需的所有憑證所組成的階層式清單。 若要驗證 EE 憑證，就必須驗證鏈結中的每個憑證，包括受信任的根 CA。

X.509 的優點：

• X.509 是 Azure IoT 中所支援的最安全驗證類型。
• X.509 允許進行高階控制以便管理憑證。
• 許多廠商都有提供 X.509 型的驗證解決方案。

X.509 的缺點：

• 許多客戶可能需要依賴外部廠商的憑證。
• 憑證管理成本很高，而且會讓解決方案的總成本上升。
• 如果邏輯未經過深思熟慮，就很難管理好憑證的生命週期。

信賴平台模組 (TPM)

TPM (也稱為 ISO/IEC 11889) 是可讓您安全產生及儲存密碼編譯金鑰的標準。 TPM 也是指會與實作標準的模組互動的虛擬或實體 I/O 裝置。 TPM 裝置可能會以個別硬體、整合式硬體、韌體型模組或軟體型模組的形式存在。

TPM 與對稱金鑰之間有兩大差異：

• TPM 晶片也可以儲存 X.509 憑證。
• DPS 中的 TPM 證明會使用 TPM 簽署金鑰 (EK) ，這是一種非對稱驗證。 使用非對稱驗證時，系統會使用公開金鑰來進行加密，並另外使用私密金鑰來進行解密。 相反地，對稱金鑰則會使用對稱驗證，也就是以私密金鑰同時進行加密和解密。

TPM 的優點：

• 許多 Windows 裝置將 TPM 納為標準硬體，內建作業系統支援。
• 保護 TPM 證明會比保護共用存取簽章 (SAS) 權杖型的對稱金鑰證明更容易。
• 您可以輕鬆地讓裝置認證過期並更新或變換。 每當 TPM 裝置應該重新佈建時，DPS 就會自動變換 IoT 中樞認證。

TPM 的缺點：

• TPM 複雜且難以使用。
• 除非您有實體 TPM 或高級模擬器，否則很難使用 TPM 來開發應用程式。
• 您可能必須重新設計裝置的主機板，以在硬體中納入 TPM。
• 如果您在 TPM 上變換 EK，其便會終結 TPM 的身分識別，然後建立新的身分識別。 雖然實體晶片也一樣，但其在您的 IoT 解決方案中具有新的身分識別。

對稱金鑰

使用對稱金鑰時，會使用相同的金鑰來加密和解密訊息。 因此，裝置和驗證裝置的服務都會知道同一個金鑰。 Azure IoT 支援 SAS 權杖型的對稱金鑰連線。 對稱金鑰驗證需要擁有者有極強的責任感，才能保護金鑰並實現和 X.509 驗證同樣等級的安全性。 如果您使用對稱金鑰，建議的做法是使用硬體安全模組 (HSM) 來保護金鑰。

對稱金鑰的優點：

• 若要開始實行驗證，最簡單且最低成本的方法是使用對稱金鑰。
• 使用對稱金鑰可簡化驗證程序，因為過程中不會產生任何額外項目。

對稱金鑰的缺點：

• 對稱金鑰需要花費大量心力才能保護金鑰。 裝置與雲端共用相同的金鑰，這表示您必須在兩個地方保護金鑰。 相較之下，TPM 和 X.509 憑證的挑戰則是既要證明公開金鑰的擁有權，又不能洩漏私密金鑰。
• 對稱金鑰可讓您輕鬆地遵循設計不良的安全性做法。 對稱金鑰的共同趨勢是將未加密的金鑰硬式編碼到裝置上。 雖然這種做法很方便，但會讓金鑰容易遭受攻擊。 您可以將對稱金鑰安全地儲存在裝置上，藉以降低一些風險。 不過，如果您的優先順序是終極的安全性而非便利性，請使用 X.509 憑證或 TPM 來進行驗證。

共用對稱金鑰

對稱金鑰驗證有一種稱為共用對稱金鑰的變形。 此方法牽涉到在所有裝置中使用相同的對稱金鑰。 建議您避免在裝置上使用共用對稱金鑰。

共用對稱金鑰的優點：

• 容易實作且成本低，可大規模產生。

共用對稱金鑰的缺點：

• 極易遭受攻擊。 容易實作的好處遠遠比不上需要承擔的風險。
• 只要取得共用金鑰，任何人都可以假扮您的裝置。
• 如果您依賴的共用對稱金鑰遭到入侵，您可能會失去裝置的控制權。

為裝置做出正確選擇

若要選擇驗證方法，請針對您獨特的製造流程，確實考慮每種方法的好處和成本。 在裝置驗證方面，給定方法的安全程度通常會與其便利性呈現反向關係。

在 IoT 裝置上安裝憑證

如果您使用 X.509 憑證來驗證 IoT 裝置，本節會指引您如何將憑證整合到製造流程中。 您必須做出幾項決定。 這些決定包括常見的憑證變數、產生憑證的時機，以及安裝憑證的時機。

如果您習慣使用密碼，您可能會好奇為何不能和在所有裝置使用相同密碼一樣，在所有裝置使用相同憑證。 首先，所有地方都使用相同密碼是很危險的做法。 此做法已經讓許多公司暴露在重大 DDoS 攻擊的威脅下，其中就包括幾年前讓美國東岸的 DNS 關閉的攻擊。 請永遠不要在所有地方使用相同的密碼，即使是個人帳戶也一樣。 其次，憑證不是密碼，而是唯一的身分識別。 密碼就像暗號，任何人都可以用它來打開受保護建物的大門。 您知道這一點，而且您可以將密碼提供給任何人以讓其進入。 憑證就像是附有相片和其他詳細資料的駕照，向守衛展示便可進入受保護的建物。 憑證與您的身分繫結。 只要守衛會仔細比對人員與駕照，就只有您可以使用您的駕照 (身分識別) 來進入其中。

決定憑證時所涉及的變數

請考慮下列變數，以及各個變數如何影響整體的製造流程。

信任憑證根目錄的來源

公開金鑰基礎結構 (PKI) 的管理成本很高且程序複雜。 如果貴公司沒有任何管理 PKI 的經驗，更是如此。 您的選項如下：

• 使用協力廠商 PKI。 您可以向協力的憑證廠商購買中繼簽署憑證。 或者，您也可以使用私人的憑證授權單位 (CA)。
• 使用自我管理 PKI。 您可以維護自己的 PKI 系統，並產生自己的憑證。
• 使用 Azure Sphere 安全性服務。 此選項僅適用於 Azure Sphere 裝置。

憑證的儲存位置

有幾個因素會影響憑證儲存位置的決策。 這些因素包括裝置類型、預期利潤 (您是否能夠負擔安全儲存體)、裝置功能，以及裝置上或許能夠使用的現有安全性技術。 請考慮下列選項：

• 在硬體安全性模組 (HSM) 中。 強烈建議使用 HSM。 檢查裝置的控制板是否已安裝 HSM。 如果您知道您沒有 HSM，請與硬體製造商合作，以找到符合您需求的 HSM。
• 在磁碟上的安全位置，例如受信任執行環境 (TEE)。
• 在本機檔案系統或憑證存放區中。 例如，Windows 憑證存放區。

處理站的連線能力

處理站的連線能力會決定您將如何以及何時取得要安裝到裝置上的憑證。 連線能力選項如下所示：

• 連線能力。 最好是擁有連線能力，這可簡化在本機產生憑證的程序。
• 沒有連線能力。 在此情況下，您會使用 CA 所簽署的憑證，在本機和離線情況下產生裝置憑證。
• 沒有連線能力。 在此情況下，您可以取得事先產生的憑證。 或者，您也可以使用離線 PKI 在本機產生憑證。

稽核需求

根據您產生的裝置類型，您可能會有法規需求，必須建立稽核線索來記錄裝置的身分識別安裝到裝置上的方式。 稽核會增加大量生產成本。 因此大部分情況下，請只在需要時才這麼做。 如果您不確定是否需要稽核，請洽詢貴公司的法律部門。 稽核選項包括：

• 不是敏感性產業。 不需要稽核。
• 敏感性產業。 根據合規性認證需求，憑證應該安裝到安全的空間。 如果您需要安全的空間來安裝憑證，表示您可能已經知道憑證安裝到裝置中的方式。 您可能也已經備有稽核系統。

憑證有效性長度

和駕照一樣，憑證也會在建立時就設下到期日。 以下是憑證有效性長度的選項：

• 不需要更新。 此方法會使用很長的續約期間，因此您永遠不需要在裝置的存留期內更新憑證。 雖然這種方法很方便，但也會有風險。 您可以在裝置上使用 HSM 之類的安全儲存體來降低風險。 不過，建議做法是避免使用長時間存留的憑證。
• 需要更新。 您必須在裝置的存留期內更新憑證。 憑證有效性長度取決於內容，而且您需要有更新策略。 更新策略中應包括要從何處取得憑證，以及裝置在更新過程中必須使用何種無線功能。

產生憑證的時機

處理站的網際網路連線能力會影響憑證的產生程序。 關於產生憑證的時機，您有以下幾個選項：

• 預先載入的憑證。 某些 HSM 廠商提供進階服務，會為客戶安裝憑證。 首先，客戶會提供權限給 HSM 廠商存取簽署憑證。 然後，HSM 廠商會在客戶購買的每個 HSM 上，安裝由該簽署憑證簽署的憑證。 客戶只需要在裝置上安裝 HSM 即可。 雖然此服務會增加成本，但可簡化製造流程。 此外，也能解決憑證安裝時機的問題。
• 裝置產生的憑證。 如果您的裝置會在內部產生憑證，則您必須從裝置擷取公用 X.509 憑證，才能在 DPS 中註冊憑證。
• 連線的處理站。 如果您的處理站有連線能力，您可以隨時在需要時產生裝置憑證。
• 離線處理站與您自己的 PKI。 如果您的處理站沒有連線能力，而且您使用具有離線支援的自有 PKI，則可以在需要時產生憑證。
• 離線處理站與協力廠商 PKI。 如果您的處理站沒有連線能力，而且您使用協力廠商的 PKI，則必須事先產生憑證。 而且，必須從具有連線能力的位置產生憑證。

安裝憑證的時機

為 IoT 裝置產生憑證後，便可將其安裝到裝置內。

如果您搭配使用預先載入的憑證與 HSM，則程序會簡化。 在裝置中安裝 HSM 之後，裝置程式碼便可以存取 HSM。 然後，您會呼叫 HSM API 來存取 HSM 中所儲存的憑證。 對製造流程來說，這是最方便的方法。

如果您沒有使用預先載入的憑證，則必須在生產過程中安裝憑證。 最簡單的方法是在快閃初始韌體映像的同時，於 HSM 內安裝憑證。 您的程序必須新增步驟，才能在每個裝置上安裝映像。 此步驟完成後，您可以先執行最終品質檢查和任何其他步驟，然後才封裝並寄送裝置。

有可用的軟體工具可讓您透過單一步驟就能執行安裝程序和最終品質檢查。 您可以修改這些工具來產生憑證，或從預先產生的憑證存放區提取憑證。 然後，軟體可以在需要安裝憑證的位置安裝憑證。 這類軟體工具可讓您大規模地執行生產品質製造。

在裝置上安裝憑證之後，下一步是了解如何向 DPS 註冊裝置。

將 TPM 整合到製造流程

如果您使用 TPM 來驗證 IoT 裝置，本節會提供指引。 此指引涵蓋廣泛使用的 TPM 2.0 裝置，這些裝置具有雜湊式訊息驗證碼 (HMAC) 金鑰支援。 TPM 晶片的 TPM 規格是由 Trusted Computing Group 所維護的 ISO 標準。 如需 TPM 的詳細資訊，請參閱 TPM 2.0 和 ISO/IEC 11889 的規格。

取得 TPM 的擁有權

在製造具有 TPM 晶片的裝置時，關鍵步驟是取得 TPM 的擁有權。 這是必要步驟，如此您才可以為裝置擁有者提供金鑰。 第一步是從裝置擷取簽署金鑰 (EK)。 下一步是實際宣告擁有權。 完成此作業的方式取決於您所使用的 TPM 和作業系統。 如有需要，請連絡 TPM 製造商或裝置作業系統的開發人員，以判斷如何宣告擁有權。

在您的製造流程中，您可以在不同的時間擷取 EK 和宣告擁有權，以提升彈性。 許多製造商會透過新增硬體安全模組 (HSM) 來增強其裝置的安全性，藉此利用此彈性。 本節會指引您了解何時擷取 EK、何時宣告 TPM 擁有權，以及要將這些步驟整合到製造時間表所應考量的事項。

重要

下列指引假設您使用個別 TPM、韌體 TPM 或整合式 TPM。 指引會在合適之處新增如何使用非個別 TPM 或軟體 TPM 的注意事項。 如果您使用軟體 TPM，則可能會有此指引未包含在內的其他步驟。 軟體 TPM 有各式各樣的實作，這些實作超出本文的討論範圍。 一般而言，您可以將軟體 TPM 整合到下列的一般製造時間表中。 不過，雖然軟體模擬的 TPM 適用於原型設計和測試，但無法提供和個別 TPM、韌體 TPM或整合式 TPM 相同的安全性層級。 一般做法是避免在生產環境中使用軟體 TPM。

一般製造時間表

下列時間表顯示 TPM 經歷生產過程，最後到達裝置的情況。 每個製造流程都是獨一無二的，此時間表會顯示最常見的模式。 時間表會指引您了解該於何時對金鑰採取特定動作。

步驟 1：已製造 TPM

• 如果您從製造商購買 TPM 以用於您的裝置，請了解其是否會為您擷取公開簽署金鑰 (EK_pubs)。 如果製造商有提供 EK_pubs 與所寄送裝置的清單，將會很有幫助。

  注意

  您可以在佈建服務中使用共用存取原則，向 TPM 製造商提供註冊清單的寫入權限。 此方法可讓他們為您在註冊清單中新增 TPM。 但這是製造流程的初期階段，而且您需要信任 TPM 製造商才行。 請自行承擔這麼做的風險。

• 如果您製造 TPM 來賣給裝置製造商，請考慮向客戶提供 EK_pubs 及其實體 TPM 的清單。 向客戶提供 EK_pubs 可讓客戶的流程省去一個步驟。

• 如果您製造要與自己的裝置搭配使用的 TPM，請識別流程中的哪個時間點最便於擷取 EK_pub。 您可以在時間表內的任何其他時間點擷取 EK_pub。

步驟 2：TPM 安裝到裝置上

在生產流程的這個時間點，您應該已經知道要與裝置搭配使用的 DPS 執行個體。 因此，您可以將裝置新增至註冊清單以進行自動化佈建。 如需自動佈建裝置的詳細資訊，請參閱 DPS 文件。

• 如果您尚未擷取 EK_pub，現在正是時候。
• 根據 TPM 的安裝程序，此步驟也是取得 TPM 擁有權的適當時機。

步驟 3：裝置已安裝韌體和軟體

在生產流程的這個時間點，請安裝 DPS 用戶端以及用於佈建的識別碼範圍和全域 URL。

• 現在是擷取 EK_pub 的最後機會。 如果協力廠商會在您的裝置上安裝軟體，則最好先擷取 EK_pub。
• 製造流程的這個時間點很適合用來取得 TPM 的擁有權。

  注意

  如果您使用軟體 TPM，則可以現在進行安裝。 同時請擷取 EK_pub。

步驟 4：裝置封裝並送至倉庫

裝置有時會在倉庫中放置長達一年，才使用 DPS 進行部署和佈建。 如果裝置在倉庫中放置很久才進行部署，部署裝置的客戶可能需要更新韌體、軟體或過期的認證。

步驟 5：裝置安裝到位

裝置到達其最終位置之後，便會使用 DPS 進行自動化佈建。

如需詳細資訊，請參閱佈建和 TPM 證明。

資源

除了本文中建議的安全性做法外，Azure IoT 還提供資源來協助您選取安全的硬體和建立安全的 IoT 部署：

• Azure IoT 安全性最佳做法，可引導您進行部署程序。
• 適用於雲端的 Microsoft Defender 有提供服務，可協助您建立安全的 IoT 部署。
• 如需協助以評估硬體環境，請參閱評估 IoT 安全性白皮書。
• 如需協助以選取安全的硬體，請參閱適合進行 IoT 部署的安全硬體。