Zigbee采用AES加密,我把一幀空中抓到的控制命令,再次發給目標設備,目標設備有MAC層的ACK,說明目標設備收到控制包了,但是沒有執行對應動作,說明目標設備具有防止重放攻擊的功能。
但是AES防止重放攻擊的原理是什么?我只看到SDK里面的AES CCM的加密/解密介面是這樣的:
AESCCM_Encrypt( uint8_t *key, uint8_t *input, uint16_t inputLen, uint8_t *outPut, uint8_t *nonce, uint8_t nonceLen, uint8_t *MIC, uint8_t MIC_len);
AESCCM_Decrypt( uint8_t *key, uint8_t *input, uint16_t inputLen, uint8_t *outPut, uint8_t *nonce, uint8_t nonceLen, uint8_t *MIC, uint8_t MIC_len);
我對協議堆疊仿真,看到協議堆疊每次加密的時候都填入了13位元組的nonce, nonce由Zigbee的8位元組IEEE地址,4位元組的counter,1位元組的常陣列成。加密后除了密文,還會產生4位元組的MIC。加密后的無線資料幀,空中資料包除了有密文,還會帶上nonce和MIC。
請問這個MIC可以用于防重放攻擊么?組成Nonce中的counter是每發一幀就會累加的。而且Zigbee設備每次掉電時的counter必須小于下次上電時的counter,也就是說Zigbee設備每次上電的時候,counter的值要初始化成一個比上次掉電時較大的值,否則就會出現發出去的報文,對方不能識別,但是對方也復位一次就好了。
但是如果Zigbee設備是靠記錄counter來判斷重放,那么一個Zigbee設備要開辟多大的空間來保存已經失效的counter,而且每個counter還要對應一個IEEE地址。
uj5u.com熱心網友回復:
MIC是AES加密里面的東西,由AES-32,64,128對應不同的MIC長度,你不用研究它。重放攻擊的防護就是依靠這個Counter判斷,開啟NV_restore與加密之后,每次上電都會在上一次的基礎上對這個Counter增加一點;
存盤空間應該是在設備的neighborTable里,其中包括周邊設備的長短地址和linkInfo,linkInfo里面包含密鑰序列號和上一次的Counter;每個設備實際上只需要確認傳到自己的資料是網路中的合法資料就足夠了,不需要保存網路中所有節點的資訊。
uj5u.com熱心網友回復:
neighborTable,router table長期不通信的設備,應該會被清理掉。而且可能是記錄MAC地址+counter。我之前懷疑過由counter+MAC地址組成的nonce會在硬體暫存器中生成特殊的校驗值,nonce被重復使用的話校驗值會出錯。
uj5u.com熱心網友回復:
只有在長期不通信,且表被占滿了之后才會替換,而且之后還可以重新由nwkLink建立連接;要不你試試在運行程序中直接修改neighborTable里面linkInfo的Counter,看看還能否進行通信?
uj5u.com熱心網友回復:
好幾個表里面都有linkInfo_t,里面有個uin32的inFrmCntr,看來就是這個counter
uj5u.com熱心網友回復:
想明白了,一個設備只需要記錄associate list和neighbor table的MAC地址和counter就夠了,NWK Key的解密只是對能夠直接通信的設備進行解密。
uj5u.com熱心網友回復:
如果是door lock和door lock controlor這樣的關系,還有應該在應用層加上非對稱加密才行。Zigbee 3.0的安全機制可能會不夠用。我的想法是door lock會在不同時間隨機產生不同的nonce,door lock controlor每次開鎖前需要獲取door lock的nonce,而AES-Key只有door lock和door lock controlor知道,網關都不知道,采用物理接觸的方式讓door lock和door lock controlor擁有相同的key
uj5u.com熱心網友回復:
這個在應用層生成一段隨機序列號,然后做比對不是就可以實作了嗎,
uj5u.com熱心網友回復:
只有在長期不通信,且表被占滿了之后才會替換,而且之后還可以重新由nwkLink建立連接;
要不你試試在運行程序中直接修改neighborTable里面linkInfo的Counter,看看還能否進行通信?
如果是door lock和door lock controlor這樣的關系,還有應該在應用層加上非對稱加密才行。Zigbee 3.0的安全機制可能會不夠用。我的想法是door lock會在不同時間隨機產生不同的nonce,door lock controlor每次開鎖前需要獲取door lock的nonce,而AES-Key只有door lock和door lock controlor知道,網關都不知道,采用物理接觸的方式讓door lock和door lock controlor擁有相同的key
這個在應用層生成一段隨機序列號,然后做比對不是就可以實作了嗎,
這個是肯定需要的,但是還是要對序列號進行加密才行啊。
另外還有zigbee自動售貨柜的,格子太多,每個格子一個Endpoint不顯示,可以每個格子一個Attribute(cluster為獨立的manufacturer code使能型)。格子的Attribute可以是一個隨機系列號,每次補貨的時候更新隨機序列號。應用層的加密協議才能知道隨機序號對應的開鎖密鑰。這種設計還有一個好處就是防止重復扣費。中途有訊息丟包導致無法開格子,那么原先的隨機序號就一直存在。
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/55664.html
標籤:數據結構與算法
上一篇:edge瀏覽器插件Video Download Helper無法使用
下一篇:字典中none值處理問題
