RF4CE Security: An Overview

In this post, we continue our series on RF4CE by discussing the mechanisms the protocol uses for security. We encourage you to read the first post for background on the purpose of this post and discussion of security levels and keying techniques. This post will explain how RF4CE devices pair and how payloads are encrypted and protected. Additionally, we’ll explain some of the problems with RF4CE security, and discuss potential remediations.

Pairing Flow

RF4CE pairing is a fairly straightforward process that comes with a few security pitfalls, likely due to attempts to streamline the pairing process for end users. First, we have the discovery stage. A peripheral sends out a discovery request command with a few specific attributes set, and waits for a discovery response command from a device that satisfies those requirements. Pairing itself begins with a pairing request command sent out by the peripheral. This request includes the number of key exchange transfers that should take place (up to 255). The base sends out a pairing request response command and begins the key exchange phase.¹

The encryption key is generated by the base. It then generates n-1 random numbers, where n is the number of key exchanges specified by the peripheral in the pairing request command. The base transmits out these key seeds, along with their sequence number. On the peripheral, the key seeds are received and are used to derive the key. The n^th seed contains the encryption key XOR’ed with other random seeds. If any key seed frames are not properly received, a new key seed is generated and transmitted with the same sequence number. An attacker would need to intercept the final key seed with each sequence number in order to successfully intercept the key. The key recovery algorithm is shown below written in 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

The seeds are XOR’ed together into one large “phase1”. This phase1 is then split into five secondary seeds. These seeds are finally XOR’ed together to form the encryption key. Note that the diagram below assumes that the pairing request specified the use of four key seeds.

After the key exchange occurs, a pairing table entry is generated on both devices. This entry contains the physical address of the opposite device, along with the pairing key and some metadata. To confirm the pairing, a ping request and response pair must be transmitted between the two devices.

Most implementations that we have seen include a secondary pairing confirmation. This often takes the form of having a user type in a set of numbers shown on the base device’s connected screen. If the confirmation is incorrect, the pairing table entry that was just created on either device is deleted. Note that this behavior is not a part of the protocol standard and is manufacturer and device dependent, and in implementations that we have observed, the confirmation code is not used cryptographically.

Cryptographic Properties

When the security flag in the RF4CE frame’s network header is set, the payload field of the frame is encrypted. RF4CE (like other IEEE 802.15.4 security specifications) uses AES-CCM* ^{2 3} mode for encrypting data.

Messages are encrypted using both a nonce and a header. The nonce is formed as follows:

The header is prepended to the message during encryption. The following describes the header:

Message authentication is determined with the use of the Message Integrity Code (MIC). The message integrity code is the last field of an encrypted RF4CE frame; it is four bytes long and is validated against the authentication returned by the AES-CCM algorithm.

Attack Scenarios

Attacking RF4CE comes down to attacking some of the conveniences built into the specification. For example, devices choose their channel based on the “channel conditions at startup”, and can automatically change their channel if they don’t get any response. This leads to a possible attack vector that uses RF channel jamming to force paired devices onto separate channels.

Key exchange is another convenient, vulnerable phase in the use of RF4CE. Keys are sent over the air with no true encryption – instead the process involves obfuscating the key material and splitting it up with the hope that an attacker may not capture every key exchange transfer message. Any attacker with knowledge of the key-generation algorithm capable of capturing the key seed exchange would be able to obtain the encryption key and bypass any security features in RF4CE.

RF4CE is additionally vulnerable because RF4CE devices only pair at the application layer, not making use of 802.15.4 MAC layer security. Because of this, frames without RF4CE security enabled are sent entirely in plaintext over the air, making interception trivially easy.

Concerns and Considerations

RF4CE has a number of issues, both inherent to the protocol and how device makers implement the protocol. The key exchange is itself a vulnerability as an attacker present for device pairing wins by obtaining the shared key material used for all future encrypted communications. Weak key exchange could be remediated by using out of band information exchange, meaning communicating information in ways that an attacker listening in on the radio frequency space wouldn’t be able to extract it. This is an option in things like Zigbee 3.0, which allow for “installation codes” that assist in secure information exchange⁴. Additionally, per-device asymmetric key pairs or a QR-code or pin based pairing such as used in ZWave S2⁵ could also remedy this.

Security is also compromised by the fact that in many “high(er) bandwidth” uses of RF4CE (audio transmission, etc.), security is often not enabled. Any attacker in range could eavesdrop on data over the air without even needing the pairing. Device manufacturers could fix this by enforcing the use of secure mode for all communications. Although embedded engineers face challenges with implementing cryptography due to speed and power availability on devices, both hardware acceleration of AES-CCM* algorithms available on many chipsets as well as other lightweight cryptography options if needed offer a variety of options to tackle these challenges while achieving security.

Conclusion

Overall, for low power uses, RF4CE is straightforward and has a convenient security architecture. Manufacturers don’t need to dedicate production time to flashing keys, and many remote control chipsets implement dedicated AES-CCM* modules, shortening development time by allowing developers to worry less about cryptography. Unfortunately, these gains in convenience are undercut by very weak key exchange and applications that don’t fully make use of security features.

This is the second post in our series discussing RF4CE. Keep an eye out for future posts in our series where we will be releasing new open-source tools to assist with the analysis of RF4CE.

River Loop Security has been at the forefront of Zigbee security since the inception of the field, maintaining the KillerBee Zigbee toolkit, producing the ApiMote and performing a wide range of RF security assessments, including Zigbee. We encourage you to contact us if you have any questions or comments based on this post, or have questions about the security of your RF devices.