配對流程
RF4CE配對是一個相當簡單的過程，帶來一些安全隱患，可能是由於試圖簡化最終用戶的配對過程。首先，我們有發現階段。外圍設備發送具有一些特定屬性集的發現請求命令，並等待來自滿足這些要求的設備的發現響應命令。配對本身從外圍設備發出的配對請求命令開始。此請求包括應發生的密鑰交換傳輸的數量（最多255個）。基站發出配對請求響應命令並開始密鑰交換階段。
加密密鑰由基礎生成。然後它生成n -1個隨機數，其中n是配對請求命令中外圍設備指定的密鑰交換的數量。基地傳輸這些密鑰種子及其序列號。在外圍設備上，接收密鑰種子並用於導出密鑰。第n 個種子包含與其他隨機種子異或的加密密鑰。如果沒有正確接收任何密鑰種子幀，則生成新的密鑰種子並以相同的序列號發送。攻擊者需要攔截每個序列號的最終密鑰種子，以便成功攔截密鑰。密鑰恢復算法如下所示：用Python編寫：
- def deriveKey(seeds):
- phase1 = 0
- for current_seed in seeds:
- phase1 = phase1 ^ current_seed
- phase2_seeds = []
- for i in range(5):
- start = i*16
- end = (i+1)*16
- s = phase1[start:end]
- phase2_seeds.append(s)
- key = 0
- for current_seed in phase2_seeds:
- key = key ^ c
將種子一起異或成一個大的“階段1”。然後將該階段1分成五個二級種子。這些種子最終被異或一起形成加密密鑰。請注意，下圖假設配對請求指定使用四個密鑰種子。
密鑰交換髮生後，在兩個設備上生成配對錶條目。此條目包含對方設備的物理地址，以及配對密鑰和一些元數據。要確認配對，必須在兩個設備之間傳輸ping請求和響應對。
我們看到的大多數實現都包括輔助配對確認。這通常採用在基本設備的連接屏幕上顯示的一組數字中的用戶類型的形式。如果確認不正確，則刪除剛在任一設備上創建的配對錶條目。請注意，此行爲不是協議標準的一部分，並且取決於製造商和設備，並且在我們觀察到的實現中，確認代碼未以加密方式使用。
加密屬性
當設置RF4CE幀的網絡頭中的安全標誌時，幀的有效載荷字段被加密。RF4CE（與其他IEEE 802.15.4安全規範一樣）使用AES-CCM * 2 3模式加密數據。
消息使用隨機數和標頭加密。nonce形成如下：
使用消息完整性代碼（MIC）確定消息驗證。消息完整性代碼是加密RF4CE幀的最後一個字段; 它長度爲四個字節，並根據AES-CCM算法返回的身份驗證進行驗證。
攻擊場景
攻擊RF4CE歸結爲攻擊規範中內置的一些便利。例如，設備根據“啓動時的信道條件”選擇其頻道，如果沒有得到任何響應，則可以自動更改頻道。這導致可能的攻擊向量，其使用RF信道干擾來迫使成對的設備進入單獨的信道。
密鑰交換是使用RF4CE的另一個方便，易受攻擊的階段。密鑰是通過無線發送的，沒有真正的加密 - 相反，該過程涉及混淆密鑰材料並將其拆分，希望攻擊者可能無法捕獲每個密鑰交換傳輸消息。任何具有能夠捕獲密鑰種子交換的密鑰生成算法知識的攻擊者都能夠獲得加密密鑰並繞過RF4CE中的任何安全功能。
RF4CE還容易受到攻擊，因爲RF4CE設備僅在應用層配對，而不是使用802.15.4 MAC層安全性。因此，沒有啓用RF4CE安全性的幀將通過無線方式完全以明文形式發送，從而使攔截變得非常簡單。
關注和考慮因素
RF4CE存在許多問題，這些問題都是協議固有的以及設備製造商如何實現協議。密鑰交換本身就是一個漏洞，因爲攻擊者通過獲取用於所有未來加密通信的共享密鑰材料來獲得設備配對。弱密鑰交換可以通過使用帶外信息交換來補救，這意味着以攻擊者收聽無線電頻率空間的方式傳送信息將無法提取信息。這是像Zigbee 3.0這樣的選項，它允許“安裝代碼”，有助於安全的信息交換4。此外，每個設備的非對稱密鑰對或基於QR碼或引腳的配對（例如ZWave S2 5中使用的配對）也可以解決這個問題。
由於在RF4CE（音頻傳輸等）的許多“高（呃）帶寬”使用中，通常不啓用安全性，因此安全性也受到損害。範圍內的任何攻擊者都可以通過無線方式竊聽數據，甚至無需配對。設備製造商可以通過對所有通信強制使用安全模式來解決此問題。雖然由於設備的速度和功率可用性，嵌入式工程師面臨着實施加密技術的挑戰，但許多芯片組上提供的AES-CCM *算法的硬件加速以及其他輕量級加密選項（如果需要）提供了多種選擇來應對這些挑戰，同時實現安全。