ZigBee 安全探究

時間 2019-12-10

標籤 zigbee 安全探究欄目系統安全简体版

原文原文鏈接

ZigBee 安全探究

0x02 ZigBee安全機制

（注：對於本節內容，可能在新版ZigBee協議標準中會有所變化，請以新版爲準。）算法

ZigBee主要提供有三個等級的安全模式：安全

一、非安全模式：爲默認安全模式，即不採起任何安全服務，所以可能被竊聽；網絡

二、訪問控制模式：經過訪問控制列表(Access Control List, ACL，包含有容許接入的硬件設備MAC地址) 限制非法節點獲取數據；加密

三、安全模式：採用AES 128位加密算法進行通信加密，同時提供有0，32，64，128位的完整性校驗，該模式又分爲標準安全模式（明文傳輸密鑰）和高級安全模式（禁止傳輸密鑰）。在一些模式裏面又分有多種安全子級，總體來看能夠直接參考Wireshark裏面提供的安全級別（Edit=>Preferences=>Protocols=>ZigBee NWK）【如圖3】，裏面也支持預設密鑰用於解析數據包。spa

若是使用安全模式，那麼它會提供3種類型的密鑰用於保證通信安全：code

主密鑰（Master Key）：用於配合ZigBee對稱密鑰的創建（SKKE）過程來派生其它密鑰，也就是說，設備要先擁有信任中心（ZigBee網絡中有且僅有的一個可信任設備，負責密鑰分發與管理，以及網絡的創建與維護）生成的主密鑰才能派生網絡密鑰和鏈路密鑰給其它設備，它能夠由信任中心設置，也可基於用戶訪問數據，好比我的識別碼（PIN），口令或密碼等信息；ip

網絡密鑰（Network Key）：用於保護廣播和組數據的機密性和完整性，同時也爲網絡認證提供保護，被網絡中的多個設備所共享，僅在廣播消息中使用；ci

連接密鑰（Link Key）：用於保護兩個設備之間單播數據的機密性和完整性，僅通信中的2個設備持有，而單個設備須要多個連接密鑰來保護每一個端對端會話。get

在ZigBee Pro（更高安全級別的ZigBee版本）中，管理員使用對稱密鑰創建方法來派生設備上使用的網絡密鑰和連接密鑰，可是這要求設備擁有從信任中心生成的主密鑰，同時要求設備已經加入網絡。關於密鑰生成的方法主要有兩種方式：產品

一、密鑰傳輸：採用此方法後，網絡密鑰與連接密鑰可能以明文形式發送到網絡中的其它設備，所以密鑰有可能被竊聽到，從而解密出全部通信數據，或者僞造合法設備去控制相應智能設備。爲了不密鑰明文傳輸，以及實現不一樣廠商設備之間的兼容性，協議還提供有默認的信任中心連接密（TCLK：0x5A 0x69 0x67 0x42 0x65 0x65 0x41 0x6C 0x6C 0x69 0x61 0x6E 0x63 0x65 0x30 0x39）去加密傳輸的密鑰，這就引入新的安全風險。這次BlackHat大會的ZigBee Exploited議題也正是經過該默認密鑰去ZLL燈泡進行攻擊，實現遠程控制。

二、預安裝：在設備上直接配置好密鑰，若是須要更改，就須要從新刷設備固件，雖然這種方式更加安全可信，但也是最繁瑣複雜的方式。這次360安全團隊在Defcon大會上演示的正是對某種智能燈泡的固件進行逆向，從中找到密鑰，從而實現對智能設備的控制。

0x03 安全風險

一、竊聽攻擊

當ZigBee採用非安全模式時，對傳輸數據將不做加密處理，所以可能被外部竊取到通信數據【如圖4】。

二、密鑰攻擊

因爲在密鑰傳輸過程當中，可能會以明文形式傳輸網絡/連接密鑰【如圖5】，所以可能被竊取到密鑰，從而解密出通信數據，或者僞造合法設備。也有可能經過逆向一些智能設備固件，從中獲取密鑰進行通信命令解密，而後僞造命令進行攻擊。

有些聯合廠商在ZigBee基礎上做了改進，好比ZigBee Light Link（ZLL）全球互聯照明標準（源自2014年第二屆家電節能與智能化技術大會）就採用ZLL密鑰對傳輸密鑰進行一次AES 128位加密再發出去【如圖6】，以免密鑰泄露的狀況，該ZZL密鑰是ZigBee聯盟在產品認證後授予的。