IoT 裝置安全連線至雲端的更簡易解決方案

作者：Stephen Evanczuk

資料提供者：DigiKey 北美編輯群

2019-01-15

雖然安全防護意識日漸增強，但開發人員的將 IoT 裝置連線至雲端時常便宜行事，未妥善顧及安全性。在許多情況下，現今適用的安全性機制太複雜、小型電池驅動式 IoT 裝置的記憶體及處理資源有限，再加上產品的運送需求，這些問題之間的相互衝突似乎無解。

為了解決這些問題並簡化 IoT 裝置安全功能的實作，Microchip Technology 與 Google 合力創造出新的做法，將 Microchip 的安全硬體功能和 JSON Web Token (JWT) 簡單數據結構相結合。最終可以輕鬆確保 IoT 裝置與 Google Cloud IoT Core 服務之間達成雙向驗證。

本文將說明 IoT 裝置的安全性威脅，並介紹目前用來對抗此威脅的裝置。文中會指出目前有哪些安全性缺陷，以及開發人員和嵌入式系統設計人員能如何使用 JWT 來彌補這些缺陷。

IoT 裝置的安全性弱點

IoT 裝置遭受攻擊的形式有很多，絕對不僅會針對大規模的 IoT 部署。有些駭客企圖控制殭屍網路中許多個別裝置的資源，以進行分散式阻斷服務 (DDoS) 等攻擊手段。對他們來說，就算是最小型的 IoT 網路，也是相當吸引人的目標。因此無論是設計哪一類的 IoT 裝置，設計人員都勢必得透過能抵禦攻擊的可靠硬體式安全機制，來保護他們的系統。

例如，使用系統記憶體或快閃記憶體來儲存用於加密和驗證的私鑰，這會讓 IoT 裝置容易受到攻擊。更糟的是，駭客可能會竊取這些私鑰，並用來存取 IoT 網路與其他連接的企業資源。

安全性 IC

一些特製的安全性裝置 (例如 Microchip Technology 的 CryptoMemory 與 CryptoAuthentication IC)，具有能保護私鑰與其他機密資料的硬體式機制。這些裝置內建的 EEPROM 陣列提供安全儲存區，並且只有利用裝置的 SPI 或 I²C 序列介面存取加密安全機制，然後才能到達該區 (圖 1)。因此，這些裝置可提供一種簡單的方式，將安全儲存區及其他安全性功能加入至任何 IoT 裝置設計中。

Microchip Technology 的 AT88SC0204C CryptoMemory IC 示意圖

圖 1：Microchip Technology 的硬體安全性裝置 (例如 AT88SC0204C CryptoMemory IC) 提供安全儲存區，使用內建的加密機制為晶片上的 EEPROM 提供存取保護。(圖片來源：Microchip Technology)

Microchip 的 CryptoAuthentication 系列產品 (例如 ATECC608A) 能強化安全儲存基礎，支援安全設計中常用的加密演算法。在硬體功能方面，該裝置能為多種演算法提供硬體加速能力，包括：

非對稱加密演算法：
- FIPS186-3 橢圓曲線數位簽章演算法 (ECDSA)
- FIPS SP800-56A 橢圓曲線迪菲-赫爾曼 (ECDH)
- NIST 標準 P256 橢圓曲線密碼學 (ECC)
對稱加密演算法：
- SHA-256 雜湊加密
- 雜湊式訊息驗證代碼 (HMAC) 加密
- AES-128 加密
- AES-GCM (高斯有限場乘法) 加密
金鑰推衍函數 (KDF)：
- 偽隨機函數 (PRF) KDF
- HMAC 式派生 KDF (HKDF)

對加密學專家來說，這些加密技術代表了全面性的防護機制，來支援更高階的安全性協定，以進行驗證與安全數據交換。例如，KDF 功能為傳輸層安全性 (TLS) 協定提供必要的驗證機制，以在數據交換前對參與交換者進行驗證。

在這個協定中，一開始執行 TLS 工作階段時，用戶端會向伺服器傳送執行安全工作階段的要求。伺服器會以數位憑證進行回應，用戶端則使用此憑證來確認伺服器的身份。當用戶端以這種方式驗證伺服器之後，會繼續進行工作階段設定，用戶端會使用伺服器的公鑰，將透過 PRF KDF 或更為強大的 HDKF 建立的某些隨機值進行加密，藉以產生工作階段金鑰。

TLS 驗證協定是網際網路安全的基礎。憑證提供者稱為憑證頒發機構 (CA)，該產業目前已進步到能支援這個關鍵的安全通訊元件。各公司可向 CA 取得信任的憑證，安裝在自己的伺服器上，以支援上述的標準 TLS 伺服器驗證協定。

有些 IoT 應用的網路連線範圍很廣，網路和企業來源深入連結，這種單向驗證不足以確保高防護水準。例如，當駭客擁有偽造的憑證時，IoT 裝置可能會將其誤認為是合法的伺服器，助長駭客發動更大的攻擊。

除了存在此風險外，IoT 開發人員也通常很難實作 TLS 雙向驗證協定，因為實作 TLS 用戶端驗證所需的憑證、金鑰以及軟體，可能超出許多 IoT 裝置的能力範圍。Microchip Technology 和 Google 合力創造出一項替代性做法，其中將 ATECC608A 功能與 JSON Web Token (JWT) 簡易數據結構相結合。最終可以輕鬆確保 IoT 裝置與 Google Cloud IoT Core 服務之間達成雙向驗證。

JWT 式驗證

依照 RFC 7519 規定，JWT 是一種業界標準容器，用於收集有關準備及傳輸 JWT 實體的資訊 (稱為宣告)。JWT 結構分成三個部分：

標頭 - 包含 JSON 名稱:值對，能顯示出用於 token 簽署的加密演算法名稱 ("alg") (例如，"EC256" 代表 ECDSA 使用 NIST P-256 曲線)，並能顯示出 token 的類型 ("typ") (這些 token 為 "JWT")
酬載 - 包含每個宣告的 JSON 名稱:值對
簽章 - 簽章使用標頭中指定的演算法，將密鑰以及標頭和宣告組進行編碼，而在加密之前，每個都會個別轉換成 base64 URL 編碼的表示方式

RFC 7519 提供了極大的彈性，方便在酬載或其他部分中指明宣告。即使 JWT 在建立時並未使用簽章或加密，這項標準仍允許這種不安全的 JWT。在此情況下，標頭中會包含演算法的名稱:值對，形式為 {"alg":"none"}。對於和 Google Cloud IoT Core 服務搭配使用的 JWT，Google 要求簽章部分以及包含三個必要宣告的酬載，包括：

"iat" –「頒佈」時間，即 token 的建立時間，使用 ISO 8601 UTC 時間戳記格式，即 1970-01-01T00:00:00Z 後算起的秒數 (例如，1561896000 代表格林威治時間 2019 年 6 月 30 日中午 12:00:00)
"exp" – 指定 token 過期的 UTC 時間戳記，最多為頒佈時間過了 24 小時後，再加上 10 分鐘的寬限期，以納入不同用戶端與伺服器之間的系統時脈誤差 (例如，1561982400 代表格林威治時間 2019 年 7 月 1 日中午 12:00:00)
"aud" – 含有開發者的 Google Cloud 專案 ID 的字串

Google 的 IoT 裝置驗證計畫結合了以 TLS 為基礎的一般伺服器驗證，以及使用 JWT 的 IoT 裝置驗證 (JWT 透過這些相對簡單的宣告建立而成)。在開始進行新的工作階段時，IoT 裝置會向伺服器開放安全通訊端，並使用前述的相同 TLS 協定來驗證伺服器。

此流程接下來會仰賴 Google IoT 雲端使用輕量型訊息佇列遙測傳輸 (MQTT) 協定，以進行 IoT 網路交易。IoT 裝置會使用經驗證之伺服器的安全通訊端，「登入」至該伺服器的 MQTT 主機服務，並使用其唯一的 JWT 作為登入密碼 (清單 1)。

複製
/* Populate the buffer with the username */
int config_get_client_username(char* buf, size_t buflen)
{
    if(buf && buflen)
    {
        int rv = snprintf(buf, buflen, "unused");
 
        if(0 < rv && rv < buflen)
        {
            buf[rv] = 0;
            return 0;
        }
    }
    return -1;
}
 
/* Populate the buffer with the user's password */
int config_get_client_password(char* buf, size_t buflen)
{
    int rv = -1;
 
    if(buf && buflen)
    {
        atca_jwt_t jwt;
        
        uint32_t ts = time_utils_get_utc();
 
        rv = atcab_init(&cfg_ateccx08a_i2c_default);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        /* Build the JWT */
        rv = atca_jwt_init(&jwt, buf, buflen);
        if(ATCA_SUCCESS != rv)
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400)))
        {
            return rv;
        }
 
        if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id)))
        {
            return rv;
        }
 
        rv = atca_jwt_finalize(&jwt, 0);
 
        atcab_release();
    }
    return rv;
}

清單 1：在 Microchip Technology 用於 Google Cloud Platform IoT Core 的軟體範例儲存庫中，有個模組會提供常式以產生虛擬使用者名稱與 JWT 物件，作為 MQTT 主機用戶端驗證的密碼。(程式碼來源：Microchip Technology)

雖然 IoT 裝置在此登入順序中會傳送使用者名稱，但這個名稱並不會用於驗證，因此會傳輸虛擬使用者名稱 (清單 2)。相反地，根據作為登入密碼傳送的 JWT，來進行 IoT 裝置驗證。因為 JWT 簽章是標頭、酬載以及裝置私鑰的組合，因此 Google Cloud IoT Core 服務得以確認 JWT 確實來自獲得授權的裝置。進行確認時，Google Cloud IoT 服務會使用裝置的公鑰，其先前由 IoT 裝置開發人員依照以下的金鑰管理流程存儲在 Google 雲端。與只使用 TLS 相比，這種混合式做法能提供雙向驗證，加快流程速度並減少 IoT 裝置的資源要求。

複製
/* Connect the MQTT Client to the host */
static int client_connect(void* pCtx)
{
    MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer;
    struct _g_client_context* ctx = (struct _g_client_context*)pCtx;
    size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;
 
    mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S;
    mqtt_options.cleansession = 1;
 
    /* Client ID String */
    mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0];
    if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Username String */
    mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring);
    if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    /* Password String */
    mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1;
    buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring);
    if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining))
    {
        return MQTTCLIENT_FAILURE;
    }
 
    return MQTTConnect(&ctx->mqtt_client, &mqtt_options);
}

清單 2：此函數取自 Microchip 軟體範例儲存庫，展示將 JWT 物件作為密碼使用，以在初期連線階段向 MQTT 伺服器驗證 IoT 裝置。(程式碼來源：Microchip Technology)

重要推手

ATECC608A 及供應鏈的功能，是這項做法的重要推手。雖然任何 MCU 最終都能從 JWT 標頭與酬載中產生加密簽章，但如果只透過軟體來執行做法，而未搭配硬體式安全金鑰儲存機制，仍然容易受到攻擊。另外，如果只透過軟體來進行實作，處理器的載入與執行必須有所延遲，但這可能會妨礙許多資源有限且需快速回應的 IoT 裝置或應用。最後，如果開發人員對安全演算法與較高階的協定沒有太多的經驗，將很難實作所需的軟體功能。Microchip 透過 CryptoAuthLib 程式庫來解決這些問題 (圖 2)。

CryptoAuthLib 硬體抽象層 (HAL) 示意圖

圖 2：因為 CryptoAuthLib 使用硬體抽象層 (HAL)，將 API 函數與核心基元從底層的硬體中分離出來，因此開發人員能將其軟體用於許多種支援裝置。(圖片來源：Microchip Technology)

Microchip 的 CryptoAuthLib 簡化了安全 IoT 功能 (例如 Google JWT 驗證協定) 的實作，將複雜的安全性運算縮減成一組透過 CryptoAuthLib 應用程式開發介面 (API) 提供的函數調用。對 IoT 開發人員來說，最重要的元素或許是 Microchip 的 CryptoAuthLib 核心函數，這種函數會完整利用 Microchip 加密 IC (例如 ATECC608A)，來加速執行設計中的安全性功能。例如，清單 1 中在進行 atca_jwt_finalize() 的調用時，使用 ATECC608A 等市售的加密元件來建立 JWT，以作為清單 2 中的密碼。在這個情況中，ATECC608A 會加快 JWT 簽章的加密速度，從設計的內建安全儲存區讀取設計的私鑰，來完成先前所描述的簽章建立過程。

然而，即使是使用複雜的軟體與安全性裝置，以往管理金鑰與憑證所需採用的方法，還是可能導致 IoT 裝置容易受到攻擊。過去，在製造、分發甚至是部署的期間，都需要在外部產生金鑰，並將金鑰載入到安全儲存裝置中。由於此裝置是唯一有必要知悉這些機密資訊的存放處，因此即使是短暫置放於外部，都會產生安全性弱點，可能會意外暴露或遭人蓄意暴露出這些弱點，即便使用硬體安全性模組與安全設施也無補於事。透過 ATECC608A 的功能，Microchip 和 Google 已大大消除這個傳統的安全性弱點。

在這個新的做法中，Microchip 的 ATECC608A 能直接產生金鑰對，私鑰完全不必離開裝置 (圖 3)。接著，Microchip 會使用客戶提供的中繼憑證來簽署裝置產生的公鑰，並存放在 Microchip 安全設施內的安全伺服器。最後，Microchip 會安全地將公鑰傳輸到客戶在 Google Cloud IoT Device Manager 的帳戶中，帳戶能配合金鑰輪換原則，為每個裝置儲存最多三個公鑰。部署完成後，IoT 裝置能使用 ATECC608A 安全性功能，建立前述雙向驗證流程中使用的 JWT。

圖 3：Microchip Technology 與 Google Cloud IoT 服務一同簡化了金鑰與憑證的佈建，提供安全的機制來強化 IoT 應用的安全性。(圖片來源：Google)

藉由 Microchip 和 Google 的這項合作，開發人員能完全擺脫這個關鍵的金鑰管理流程。如果需要進行自訂，開發人員可以使用 CryptoAuthLib API 函數 atcab_genkey() 實作自己的金鑰管理流程，讓 ATECC608A 產生金鑰對、將私鑰儲存在安全儲存區中，然後傳回關聯的公鑰。

如果要探索金鑰的建製與其他的 ATECC608A 安全性功能，開發人員可以快速建立出一個根據 Microchip 的 SAM D21 Xplained Pro 評估套件打造的全面性開發環境。SAM D21 Xplained Pro 套件以 Microchip 的 ATSAMD21J18A 32 位元 Arm^® Cortex^®-M0+ MCU 作為基礎，提供一個完整的硬體平台，並由驅動程式與程式碼模組的 Microchip Advanced Software Framework (ASF) 所支援。

要評估包含 ATECC608A 在內的 CryptoAuthentication 裝置，開發人員只要將 CryptoAuth XPRO-B 附加板擇一插入 Xplained Pro 板的兩個擴充排針座即可。Microchip 提供範例軟體，以搭配 ATECC608A 來評估 CryptoAuthLib 的安全性功能。此外，開發人員可以將 Microchip ATWINC1500-XPRO Wi-Fi 附加板插入另一個排針座中，來執行 Microchip 範例軟體，其展示出本文中所描述的雙向驗證流程，即 TLS 伺服器驗證和 JWT 裝置驗證。

結論

雖然 IoT 應用有許多安全防護要求，但真正關鍵的挑戰往往是實作 IoT 裝置及雲端資源的雙向驗證。在資源有限的 IoT 系統中，傳統協定可能超出可用的記憶體和處理資源能力範圍。藉由 Microchip Technology 的 CryptoAuthLib 程式庫與 ATECC608A CryptoAuthentication IC，開發人員可以實作更有效率、以 JSON Web Token 為基礎的做法，安全地將 IoT 裝置連線至 Google Cloud IoT 服務。