RF4CE配对是一个相当简单的过程，带来一些安全隐患，可能是由于试图简化最终用户的配对过程。首先，我们有发现阶段。外围设备发送具有一些特定属性集的发现请求命令，并等待来自满足这些要求的设备的发现响应命令。配对本身从外围设备发出的配对请求命令开始。此请求包括应发生的密钥交换传输的数量（最多255个）。基站发出配对请求响应命令并开始密钥交换阶段。
加密密钥由基础生成。然后它生成n -1个随机数，其中n是配对请求命令中外围设备指定的密钥交换的数量。基地传输这些密钥种子及其序列号。在外围设备上，接收密钥种子并用于导出密钥。第n 个种子包含与其他随机种子异或的加密密钥。如果没有正确接收任何密钥种子帧，则生成新的密钥种子并以相同的序列号发送。攻击者需要拦截每个序列号的最终密钥种子，以便成功拦截密钥。密钥恢复算法如下所示：用Python编写：
将种子一起异或成一个大的“阶段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 *算法的硬件加速以及其他轻量级加密选项（如果需要）提供了多种选择来应对这些挑战，同时实现安全。
