【智慧製造】使用 Cloud IoT 保護你的雲端連接設備

維護產品、設備和程式的安全性,是企業的必要需求。研究人員(或駭客!)每天都會發現新的安全漏洞。或許,有些公司認為他們的規模並不足以成為駭客的目標,但事實上,若是在分散式阻斷服務攻擊 (DDoS) 的情況下,駭客會隨機占用主機(數量越多越好)來達到特定目標。資安不能是事後諸葛,對於任何有雲端連接設備的公司來說,最好的方法就是加強身份識別、安全加密及存取控管。但在物聯網世界中,這個過程並不像聽起來那樣簡單。

接下來我們會介紹 Acme 的故事,這是一家假想的公司,它們正計劃推出新一代的雲端連接設備。以下我們將以該公司為情境案例,探討適當的解決方案。

Acme 在這個專案中有多個工作流程規劃:機械設計、PCB 設計、供應鏈、韌體開發、網路連接、雲端的後端、行動裝置和網頁應用程式、資料處理分析和支援。讓我們來看看這些工作流程中有哪些需要做安全的規劃。

情況概要

Acme 公司設備的安全保護成本高漲,部署、維護高等級資安所帶來的複雜度也隨之增加。讓我們做個統整:

  1. Acme 需要安全憑證。他們需要最高等級的數位憑證認證機構所發的憑證。 
  2. 將安全憑證的金鑰燒入到設備中(並找到合適的ODM廠商)需要一筆花費,而在製造過程中也有憑證洩露的風險,二者之間要取得平衡點。
  3. Acme 需要使用傳輸層安全性 (TLS) 來保護訊息,但現在面對設備內爆量的 TLS 堆疊已經超乎預期,並會加大記憶體的耗用量。整合了線上憑證狀態協定(代理OCSP)後, 這些資源需求將增加,因為它需要額外耗用記憶體的金鑰,並耗用 CPU。
  4. 金鑰保存變得非常困難,不可能安全地保存在韌體當中。
  5. 如果沒有單獨的安全儲存空間,則可能受到感染的韌體設備,無法透過安全的啟動程序將設備停止運行。
  6. 更新金鑰讓雲端解決方案能儲存多個身份,以便具有故障防護的功能。

Google 已認真研究了 Acme 的情況,並提出了良好的解決方案幫助類似 Acme 這樣需求的公司。以下,Google 與其合作夥伴 Microchip 將展示主要的解決方案。

步驟 1:使用安全元件

「安全元件」是一個可安全儲存金鑰的硬體材料。它通常具有防篡改的功能,該功能可防止物理攻擊入侵設備、取得金鑰。

所有物聯網設備均應具有安全元件,這是保護儲存私鑰的唯一方法。所有安全元件將各司其職發揮功能,但是某些安全元件將能做得更多。舉例來說,Microchip ATECC608A 加密共同處理晶片不僅能儲存私鑰,還能驗證韌體,並為設備提供更安全的啟動方式。

Microchip ATECC608A
Microchip ATECC608A

Microchip 在美國的專用安全設施中執行加密簽章,隔離的工廠將把客戶的中間憑證機構Certificate Authority (CA) 頒發的金鑰,儲存到一個內嵌於生產線中,高安全等級的伺服器內。對稱金鑰和憑證,皆透過合法的認證機構生產,從而可對其進行審核,並實現高等級的安全加密。

一旦安全元件生成了對稱金鑰,就會將相應的公鑰發送到客戶的 Google Cloud 帳戶,並安全地儲存在 Cloud IoT Core 設備管理器中。 由於每個 Cloud IoT Core 設備最多可以儲存 3 個公鑰,因此可以在故障保護的情況下執行金鑰輪換,不會有問題。

客戶要做的就是為 Microchip 批次的設備提供中介 CA 憑證,他們將會回傳一卷安全元件。這些安全元件卷可以發送給任何製造商,用高速焊接到最終的 PCB,而無需客製化,也沒有被複製的風險並且成本非常低。

步驟 2:使用 JWT 進行身份驗證

TLS 非常適合使用於確保設備與雲之間的通訊安全,但是身份驗證堆疊不適用於 IoT。 雙向身份驗證堆疊需要大的尺寸,而且有一個缺點:它需要知道金鑰的儲存位置。TLS 堆疊需要知道使用了什麼安全元件,以及如何溝通。OpenSSL 堆疊將假設金鑰存儲在檔案系統中,需要修改才能存取安全元件。這就要求每次更新堆疊時必須再次進行開發和測試,隨著 TLS 1.3的到來,這項工作很可能需要重複發生好幾次,對公司來說將是可觀的費用。該公司可以使用已經與安全元件相容的 TLS 堆疊(例如 WolfSSL),但是涉及授權費用,這會增加設備的成本。

Google Cloud IoT 使用常見的 JWT (JSON WebToken) 來對設備進行身份驗證,而不是依賴TLS 堆疊的雙向身份驗證。

設備將使用 TLS 與 Cloud IoT Core (mqtt.googleapis.com) 建立全球雲端點的安全連線,但不會觸發雙向身份驗證,而是會生成一個簡單的 JWT,使用其私鑰做簽章並將私鑰作為密碼。 Microchip ATECC608 提供了一個簡單的介面,可以在避免私鑰被暴露的情況下,對設備採用 JWT 安全簽署。JWT 由 Google Cloud IoT 接收,該設備的公鑰將被用於驗證 JWT 簽章。如果有效,則有效率地建立雙向身份驗證。JWT 驗證可以由客戶設置,但不能超過 24 小時,因此非常短暫。

Secure flow with Microchip and Cloud IoT’s Device Manager
Secure flow with Microchip and Cloud IoT’s Device Manager

這種作法有幾個好處:

  1. 設備身份認證和 TLS 堆疊無關,使得更新 TLS 堆疊到1.3 十分容易。 
  2. 設備不需要儲存公鑰和憑證,這將會釋放設備上大部分的記憶體。
  3. 設備不需要託管完整的 TLS 堆疊,這又會釋放應用程式的記憶體。
  4. 設備所需記憶體空間不到50KB,這點為那些使用超小型 MCU(微控制器)的廠商開啟了一扇門。

透過這兩個步驟,管理安全憑證的複雜度大幅降低,客戶可以更專注於他們的產品和用戶體驗。

想了解更多智慧製造趨勢?歡迎閱讀【工業預測性維護】系列文章!

 

結論

安全性很複雜,正如我們在引言所提,它不能是事後諸葛。幸運的是,使用 JWT 身份驗證方案以及與 Microchip 在 ATECC608 的合作關係,安全已變成一個簡單的 BOM。Google 和 Microchip 甚至同意以 50 美分的折扣出售。客戶能以不到 1 美元的價格,提升個人身份、身份驗證和加密安全,同時節省更多儲存空間,讓體積小、價格低廉的 MCU 在終端設備中運作。而由於安全元件能透過 I2C 快速溝通,此晶片能夠整合到現有設計中。希望您的每個 IoT 設計中,能將 ATECC608考慮在內。

想了解更多諮詢,請查看以下網站:

(本文翻譯改編自 Google Cloud。)