一、 引言
1. 物聯網安全背景
物聯網業務深入多個行業，全方位影響人民生活，相應的安全問題也將帶來嚴重威脅，甚至包括生命和財產安全。雖然物聯網市場發展迅速，終端數量劇增，但安全隱患大，物聯網產業鏈中安全環節佔比低。
以家庭網絡爲例，根據信通院《2019年智慧家庭網絡安全態勢報告》，智慧家庭中 IoT 設備安全風險居高不下。
在工業物聯網中，由於物聯網設備負責重要的民生設施的控制，由於網絡安全隱患帶來的風險就更大。
- 2003 年 8 月14 日美國東北部地區和加拿大聯合電網由於網絡與 XA/21 系統的漏洞，被攻擊後致使主服務器崩潰，導致發生大面積停電事故。
- 2008 年，黑客劫持了南美洲某國的電網控制系統，導致電力中斷幾分鐘。
- 2008 年美國中央情報局 (CIA) 官員湯姆唐納休 (Tom Donahue) 在“SANS”( 系統和網絡安全 ) 貿易大會上透露，美國曾發生數起黑客通過互聯網攻破當地供電網絡導致數個城市出現照明中斷的事故。
- 2008 年，美國國土安全局演示通過攻擊電力控制系統後致使一臺發電機物理損壞。
- 2011 年夏天在美國黑帽大會上黑客展示了可以利用執行內存轉儲、捕捉密碼的 PLC 的後門程序。如對 PLC 進行 24 小時的攻擊可導致電廠爆炸，這意味SCADA(Supervisory Control And Data Acquisition) 系統也將成爲直接攻擊的目標。
- 2016 年美國東海岸網絡癱瘓攻擊事件：2016 年的攻擊發生後，據統計全球感染Mirai 的設備已經超過 100 萬臺，攻擊採用了大量 IoT 設備，例如網絡攝像頭、路由器、DVR 等，實驗表明，8 萬個 IoT 殭屍能發起 500Gbps 的 DDoS 攻擊；89 萬個殭屍足以打垮全球任何一個電信運營商。
2. 物聯網安全和互聯網安全的區別
互聯網安全領域存在的問題，物聯網應用都存在。物聯網安全是互聯網安全的延伸，物聯網只會帶來新的安全風險，如下：
- 由於物聯網應用設備類型碎片化嚴重（從單片機到 ARM A系列、從沒有 OS 到Linux、Android），大多數情況下物聯網設備資源都受限，無法運行一個具備完整安全策略的操作系統，甚至連基於證書認證的 TLS 都無法運行。
- 物聯網設備通常是常年開機，沒有人機交互，或者人機交互不頻繁。很多時候，物聯網設備被攻擊了都無法被感知。比如：家裏的路由器、IP 攝像頭，如果被黑客獲取權限用來作爲發起攻擊的肉雞，用戶通常是無感知的。
- 協議的安全風險 ：物聯網的通信協議諸如 ZigBee、藍牙、NB-IOT、2\3\4\5G 等等，這些協議的在互聯網應用上並沒有使用到，互聯網安全策略也無法覆蓋到這些協議，物聯網協議帶來了協議的安全風險。
- 邊界的安全風險 ：互聯網時代更多的應用模式是 C/S（B/S），即客戶端/服務端模式。這個模式有一個非常清晰的“邊界”。企業可以通過部署防火牆、IPS 等網關類設備來提高企業服務的安全性。但在物聯網時代，設備遍佈全球各地，黑客可以直接對設備發起攻擊，沒有“邊界”的存在了，傳統網關類防護設備用處不大。
- 系統的安全風險 ：互聯網時代的終端保護（EDR），主要針對 Linux 和 Windows 兩類系統，而物聯網時代，設備採用的嵌入式操作系統諸如 UClinux、Freertos 甚至是無操作系統的設備等等，傳統的終端系統安全方案無法適用於物聯網時代的嵌入式操作系統。
- APP 的安全風險 ：互聯網時代的 APP 主要也是 C/S 模式，但物聯網時代，APP 不僅要與雲端通信，更可能與設備直接通信，APP to Device 這個鏈路中包含了許多如設備身份認證、硬件加解密、OTA 升級等安全策略，這也是互聯網時代沒有的。
- 業務的安全風險 ：物聯網的業務場景會產生許多互聯網時代收集不到的數據，比如傳感器數據、用戶行爲數據、生理數據、地理位置數據等等。這些數據的產生-傳輸-處理過程涉及到整個業務體系的安全架構，這些數據的收集、傳輸、處理過程需要新的安全防護策略和監管體系。
- 研發的安全風險 ：物聯網產品的研發流程涉及到嵌入式的安全開發，這是互聯網應用中不存在的。在嵌入式端的開發又涉及到：嵌入式系統安全、邏輯安全、加解密安全、認證安全、接口安全、存儲安全、協議安全等等新的安全風險。
- 合規的安全風險 ：目前物聯網行業還沒有一套業內普遍使用的完整法規要求，雖然等保0 涵蓋了物聯網安全，但 2019 年中才正式發佈，還處於行業推廣期。此外，對於物聯網設備的安全測評與互聯網產品的測評方式完全不同，目前也缺乏一套國家發佈的安全測評規範。現階段安全測評都是“以結果爲導向”而非“以合規爲導向”。
二、物聯網安全能力構建之路
物聯網安全要解決的兩個核心問題：身份認證和鏈路安全。
騰訊雲物聯網產品中心在探索物聯網安全的過程中經歷了以下演進：TLS 證書 -> SE 安全芯片 -> ARM TEE 安全 -> 軟件加固。
在互聯網中，基於 TLS 證書認證的 https 協議已經成爲現代互聯網安全的重要基石。物聯網中也經常會使用如下 X509 證書進行身份認證和安全通信：
1. TLS證書鏈認證
但 TLS 證書認證要在物聯網設備上落地會有不少的挑戰，首先就是資源太大，比如：
（1）使用TLS證書：
RAM：55.949 KB ROM：105.308 KB
（2）使用TLS PSK：
RAM：35.996 KB ROM：104.023KB
這裏多出的50+KB RAM 和 100+ KB 的 ROM 在物聯網終端設備上是一個非常大的不可接受的資源消耗。以出貨量較大的STM32F103系列爲例：
由於 MCU 上通常還需要運行一個 rtos 系統，那就算是最貴的系列，也無法提供足夠的資源運行 TLS 證書認證。
除了資源問題之外，還有一個存儲安全的問題：其證書或者密鑰如何存儲也是一個大問題，一旦證書或者密鑰被批量攻破，那麼 TLS 的安全性也大打折扣。
爲了解決資源消耗太大的問題，物聯網產品中心和桌面安全管家團隊一起制定了一個具備雙向認證、前向安全且資源消耗少的安全認證協議 TID，其中借鑑了部分 TLS1.3協議中的一些優點。
對於存儲安全的問題，我們引入了基於安全芯片或者 ARM TEE 進行身份密鑰信息的存儲。
2. 安全芯片
（1）從智能卡到安全芯片
智能卡很早就在我們的日常生活中扮演了重要角色，主要分爲無接觸智能卡和接觸智能卡。
最常用的無接觸智能卡就是我們的身份證了，裏面含有一塊芯片，包括：射頻模塊、存儲模塊、加密模塊和控制芯片。
最常見的接觸式智能卡就是手機中的sim卡，安全芯片就是由接觸式智能卡演變而來，且在物理硬件設計上就具備了很好的安全性，如：防側信道攻擊、防拆技術等。現在一些高端的智能手機，比如iphone、華爲高端手機中都會採用SE安全芯片來存儲指紋這類重要的隱私數據。
（2） 安全芯片接入規範
由於安全芯片行業是從智能卡發展而來，所以安全芯片的接口也大都沿用了智能卡時期的通信協議 ISO7816。
爲了使安全芯片廠家能夠接入騰訊雲 TID 物聯網安全認證體系，我們吸收了各家安全芯片廠家（NXP、ST、復旦微電子、華大電子、爲遠電子等）安全芯片接口的優點，加上 TID 認證協議的要求，制定了《安全芯片接入騰訊雲TID的規範》。
在規範中，定義了11條 APDU 指令，涵蓋了高端安全芯片和低端安全芯片在不同場景下的使用需求，如下表所示：
| 指令 | CLA | INS | 說明 |
|---|---|---|---|
| GetChallenge | 00 | 84 | 生成隨機數 |
| ImportSessionKey | 80 | 5A | 導入臨時會話密鑰，用於對稱加解密 |
| SymCrypto | 80 | F0 | 對稱加解密 |
| AsymCrypto | 80 | F2 | 非對稱加解密 |
| GenerateKeyPair | 80 | F4 | 生成臨時密鑰對 |
| GenerateSharedKey | 80 | F6 | 生成共享密鑰 |
| GenerateSessionKey | 80 | F8 | 在SE內部生成SessionKey |
| ComputeDigest | 80 | FA | 計算摘要 |
| GetTid | 80 | FC | 獲取設備TID |
| GetVendor | 80 | CA | 獲取芯片廠商信息 |
| SecurityStorage | 80/84 | E2 | 支持自定義數據的存儲和讀取 |
（3） 安全芯片TID SDK
架構如下圖所示：
主要是將不同廠家和不同總線的適配代碼剝離成一個抽象層，方便進行SDK的適配移植。
3. TEE 物聯網安全
由於安全芯片會帶來額外的物料和硬件開發成本（需要額外添加一個安全芯片及相應的電路），對於 ARM Cortex-A 系列的芯片，可以利用 TEE（Trusted Execution Environment）來接入 TID 認證體系。
其中，TEE 所能訪問的軟硬件資源是與 Rich OS 分離的。TEE 提供了授權安全軟件（可信應用，TA）的安全執行環境，同時也保護 TA 的資源和數據的保密性，完整性和訪問權限。
爲了保證TEE本身的可信根，TEE在安全啓動過程中是要通過驗證並且與 Rich OS 隔離的。在 TEE 中，每個 TA 是相互獨立的，而且不能在未授權的情況下不能互相訪問。
目前騰訊雲物聯網已經基於 OPTEE OS 開發了進行 TID 認證的 Trusted Application 和 Client Application，且符合 TEE GP規範。
4. 軟件加固
軟件加固和以上幾種安全方式相比，成本最低，不需要額外增加芯片，也不需要進行芯片支持 TEE 進行 TA 的開發。目前實現軟加固通常有兩種方案：白盒密鑰和代碼混淆，也可以將兩者混合使用。
（1）白盒密鑰
白盒密鑰的核心就是在設備端不存儲密鑰，而是存儲進行白盒處理過的動態庫或者對應的白盒密鑰表，確保沒有密鑰存儲在設備中也能實現相應的加解密操作。詳細原理如下圖所示。
左圖是正常的解密操作，需要輸入密鑰以及密文，通過算法獲取到明文。而右圖中，無需輸入密鑰，只需輸入密文，即可獲取明文。白盒處理過的解密操作複雜度大大提升，提升了黑客攻擊破解的難度。
目前已有基於白盒密鑰的 TID 端側實現方案並已經上線。
（2）代碼混淆
代碼混淆是將物聯網設備上的代碼，轉換成功能上等價但是難於閱讀和理解的形式的。最著名的和代碼混淆相關的開源項目就是 Obfuscator-LLVM，主要是三種方式：控制流扁平化、指令替換、虛假控制流程。
上圖爲 Obfuscator-LLVM 提供的一個 Control-Flow-Flattening，通過控制流扁平化之後，二進制代碼更難進行逆向。
指令替換是一種比較簡單的替換規則，就是將一些簡單的運算複雜化，比如彙編指令中最常見的加法可以被混淆成若干個條帶有隨機數的指令。比如 a = b + c; 可以被混淆爲（r = rand(); a = b + r; a = a + c; a = a – r;）在進行大量的指令替換之後，也會極大的增加黑客攻破代碼的難度。
虛假控制流是在代碼中加入大量控制流，這些加入的控制流又不會影響代碼的正常運行，只是起到了提高代碼逆向的目的。
由於 Obfuscator-LLVM 應用太廣泛，這些混淆技術被大量研究，市面上已經有deobfuscator 的工具，可以輔助進行混淆代碼的逆向分析。
基於這個原因，騰訊雲物聯網產品中心已經和桌管安全團隊進行了合作進行基於指令級別（Obfuscator-LLVM是基於代碼塊）的隨機混淆的 TID 工具庫，即將上線。
三、物聯網安全行業規範
我們在和物聯網廠家溝通時，發現大家普遍都會有一個痛點：雖然花費了不少成本來提供物聯網產品的安全，但是怎樣才能被終端用戶所認可呢？物聯網安全雖然有國標，但都是進行最低限度的要求，符合國標並不能給產品帶來額外的價值。
目前騰訊雲物聯網產品中心通過和 TEG 安全平臺團隊合作，制定了物聯網安全的行業規範，全方位的制定了物聯網安全規範，如下圖所示：
比如：針對門鎖行業，我們定義了一套安全打分標準，對於不同得分的產品授予不同的徽標。最後也希望未來有更多小夥伴加入進來，和我們一起交流合作，促進整個行業安全規範的完善和落地。
本文轉載自公衆號雲加社區（ID：QcloudCommunity）。
原文鏈接：