介紹

從技術的角度來看，我們生活在一個激動人心的時代?！盎ヂ撋睢钡膲粝胝趯崿F，許多普通產品正在配備互聯網連接，以實現這個便利的新世界。但是，互聯網可能是一個危險的地方，保護這些新連接的產品免受威脅至關重要。否則，這種無與倫比的便利性可能會變成一場噩夢。作為系統設計人員，我們有責任成為解決方案的一部分，以取悅我們的最終用戶，并成為他們數據的好管家，讓您高枕無憂。

物聯網 （IoT） 產品開發的挑戰之一是安全性很困難。安全產品必須防御所有可能的攻擊，但攻擊者只需要找到一個薄弱環節即可利用系統。它們還具有時間優勢：攻擊總是變得更好，而不是更糟，計算能力，工具和如何使用它們的知識變得越來越便宜和廣泛。此外，成本、上市時間、尺寸和客戶便利性等標準壓力導致許多設計人員快速、便捷地實施安全規定，或者只是不正確或不完整的安全規定。

本文特別關注小型無線連接系統，這些系統通常由電池供電并運行輕量級、低帶寬射頻協議，如低功耗藍牙 （LE）、藍牙網狀網絡、Zigbee、螺紋、Z 波、LoRa 或專有 ISM 頻段協議。這里介紹的大多數挑戰和解決方案也常見于大型系統（智能手機，筆記本電腦等）。

彈性設計

在詳細了解可能出錯的地方之前，計劃一些事情會出錯是有幫助的：漏洞和錯誤將被發現并需要解決。為系統預配安全的固件更新機制，最好是使用簽名、加密和版本化的升級包以及具有回滾保護的更新管理器。此外，使用硬件信任根預配安全啟動，以確保只有授權代碼才能在您的產品上運行。

不要制作自己的安全協議

當面臨安全需求時，再加上潛在的有限設備資源（代碼空間、電池壽命、缺乏加密加速器）和有限的時間，許多嵌入式設計人員選擇設計自己的安全協議，而不是采用合適的行業驗證解決方案來滿足安全要求。不幸的是，很容易提出一個看起來牢不可破的系統，并且識別這種設計中的缺陷更具挑戰性。

創建安全連接需要驗證鏈接遠程端的真實性，對消息進行加密，并驗證通過鏈接傳遞的消息的完整性和真實性。

Web 瀏覽器用于保護用戶與其銀行之間的“https：”連接的傳輸層安全性 （TLS） 會話可滿足所有這些安全要求。銀行網站的真實性通過使用基于證書的公鑰加密來解決;機密性是使用對稱密碼學實現的;并且完整性由消息身份驗證代碼解決。

在小型嵌入式處理器上建立TLS連接似乎有些過分。幸運的是，還有其他重量較輕的既定標準，例如DTLS（在 Thread 中使用），可以采用這些標準。

管理設備真實性的最靈活的工具之一是 X.509 證書與公鑰基礎結構 （PKI） 相結合。這允許使用與上述銀行網站示例相同的加密工具和方法對設備進行身份驗證。該證書包含一些特定于設備的信息，例如唯一 ID、有效期、加密算法信息以及公司名稱和其他數據。該證書由公司的私鑰（受到強烈保護）簽名，但可以通過任何人都可以訪問的公鑰進行驗證。此外，如果設備或私鑰遭到破壞，則可以吊銷證書或證書系列，從而限制損壞范圍。

將獨特的設備證書注入產品或設備可能看起來很麻煩或昂貴，但由于物聯網的高需求和普遍需求，許多MCU和SoC供應商，分銷商和第三方以適度的成本提供這些功能作為其設備定制和預編程服務的一部分。

大多數基于標準的射頻協議，如藍牙、Zigbee、螺紋和Z-Wave，已經規定或至少推薦了建立安全認證鏈路的方法。所有這些協議都提供了一種建立機密傳輸通道的方法，設計人員絕對應該利用該協議提供的安全功能。某些設計人員可能希望在傳輸層之上添加其他安全性，以提供身份驗證支持或應用程序級加密。

常見漏洞

2014年，麻省理工學院的研究人員調查了2011年至2014年間常見漏洞和披露（CVE）數據庫中記錄的最常見漏洞。他們對加密庫和應用程序之間的漏洞來源進行了分類。有趣的是，只有17%的加密漏洞是在加密庫中發現的，而大部分漏洞（83%）是在錯誤使用庫的應用程序中發現的。最小化漏洞暴露的一種方法是選擇正確的加密庫。沒有一個庫是完全沒有漏洞或錯誤的;但是，一個開源的、積極維護的庫，其維護者遵循漏洞披露的最佳實踐，可能是一個良好的開端。mbed TLS 庫就是這樣一個例子，它也針對資源受限的物聯網系統進行了優化。

審核編輯：郭婷