By Marcus Barbu | August 19, 2019
In the course of security assessments we often come across protocols and communication methods that are not widely known outside of specific industry use. This article is the first in a series of deep dives on one such protocol, RF4CE. In this article, we talk about the background of RF4CE and its use cases, as well as providing an introduction to the basics of RF4CE.
Background
Conventional Remote Control
As connected home technology evolves, the need for modern wireless technologies to effectively connect these devices and quickly deliver data advances with it. As an example, early wireless remote controls utilized infrared light. There are a number of different protocols for IR remote controls, including RC-5 and RECS-80. Both of these protocols use time-width modulation to send commands from a remote to a receiver1. This process is slow and very low bandwidth; however, this method was adequate for early needs such as encoding 0-9 integers and a few other functions. As connected home devices and set top boxes advanced, manufacturers started looking for a better solution: enter Zigbee.
Zigbee
Zigbee is a specification for a protocol on top of IEEE 802.15.4, a standard which describes the wireless physical layer (frequencies, bandwidth, data rates, etc.) and the medium access control layer, or MAC (how frames actually get moved around the network) for small, local mesh networks of interconnected devices. Zigbee adds layers on top of the 802.15.4 protocol to specify networks and applications. While IEEE 802.15.4 specifies how messages are sent over radio, Zigbee specifies what the radio network actually looks like and what packets actually get transmitted.
Because of its relatively low power consumption and ease of application, many IoT developers latched on to Zigbee. It can now be found everywhere from smart light bulbs to home security systems to power meters. The Zigbee Alliance defines different application specifications for using Zigbee networks, each one tailored for a different class of device.
When home theater systems and set top boxes began requiring additional local wireless data transmissions, manufacturers looked for radio-based solutions. They formed the RF4CE Consortium2 and settled on IEEE 802.15.4 for its physical and medium access control layers; Zigbee sought to incorporate RF4CE under their umbrella. In 2009, the Zigbee Alliance added RF4CE version 1.0 to their protocol family3.
Understanding RF4CE
The RF4CE protocol is primarily intended for remote control of media devices, including: TVs, set-top-boxes, stereos, etc. It has a longer range than infrared, does not require a user to aim a remote, and does not require line of sight. RF4CE also has significantly higher data rates than infrared, allowing transmission of data including audio to be communicated from the controller to the receiver. Additionally, RF4CE is bi-directional, allowing remote controls to do things like display channel information.
Packet Structure
Understanding RF4CE starts with understanding the frame structure. The diagram below shows each field in the frame along with its length.
| Field | Contents and Notes |
|---|---|
| Frame Control | Specifies important transmission attributes, see diagram and explanation below for more information about the frame control field’s bit-fields |
| Frame Counter | Can have a value from 0 to 0xFFFFFFFF. See explanation below for information on frame counter usage. |
| Profile ID | Only present in Standard Data and Vendor data frames. Used to help devices negotiate what type of information they’re communicating. |
| Vendor ID | Only present in Vendor data frames. Used to help the device identify itself. |
| Payload | Variable length data transmitted by the device. Network commands have specific payload formats. Vendors can specify payload format for Vendor-type frames. |
| Message Integrity Code | In security enabled frames, the message integrity code is generated by the encryption algorithm. |
Frame Control
The frame control field is used to specify a number of attributes about each transmission. Each bit in the frame control field has a meaning.
| Field | Usage |
|---|---|
| Frame Type | Specifies what kind of frame is being sent. There are four frame types: 0 - Reserved, 1 - Standard Data, 2 - NWK Command, and 3 - Vendor. |
| Security Enabled Bit | Determines whether or not the payload will be encrypted and if there will be a message integrity code. |
| Protocol Version | Specifies which RF4CE protocol version is in use. |
| Channel Identifier | This can be set to 0 for channel not specified, 1 for channel 15, 2 for channel 20, or 3 for channel 25. |
Frame Counter
The frame counter is important as it’s used to prevent things like replay attacks. If a frame counter is not present, an attacker could capture a transmitted packet and then rebroadcast it later without changing anything; the packet recipient would have no way of knowing that it was a replay of an earlier packet. The frame counter is also important to the encryption scheme used by RF4CE. It can have a value from 0 to 0xFFFFFFFF. If the frame counter reaches its maximum value, it throws an error and refuses to perform any further processing. The frame counter is typically reinitialized when the device is restarted.
Network Commands
Network commands are used to handle things like device discovery and pairing. There are eight defined network commands. The first byte of a network command payload specifies the type of command being sent. The table below specifies what type of command each of those bytes represents, and whether it is a request or a response.
| Name | Request | Response | Comments |
|---|---|---|---|
| Discovery | 0x01 | 0x02 | The discovery request command is sent to the broadcast 802.15.4 address that contains information about the device vendor, the profiles supported, and optionally a vendor specified string. If a device in range identifies itself in that supported group, the device responds with a discovery request response, containing much of the same information. |
| Pairing | 0x03 | 0x04 | If a compatible device is discovered, pairing can occur. The device initiating the request shares information similar to that in the discovery request, appended with a seed count number. This number refers to the number of messages the key seed should be split into. |
| Unpairing | 0x05 | n/a | The unpairing request is sent by a device to have its pairing table entry removed on the device it is currently paired to. It requires no response. |
| Key Seed | 0x06 | n/a | The key seed command packets contain a sequence number independent of the frame counter, and an 80 byte long payload containing seed data. |
| Ping | 0x07 | 0x08 | Pings are used to verify a device’s continued presence on the network. Interestingly, these pings are required to be sent with security enabled, though no other network command imposes that requirement. This means that pings can only be sent between devices that are paired. |
Conclusion
RF4CE was designed to solve the problem of controlling an increasing number of gradually more complex home media devices. It uses an established Network, MAC, and Physical layer combination to meet that goal. In our next post, we’ll talk about the pairing mechanism, security (and security flaws) of RF4CE, and an in-depth analysis of possible solutions for the problems we’ve found.
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.
Read the second post of this series for background on the security of RF4CE.
- https://web.archive.org/web/20070210205922/http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt [return]
- https://www.engadget.com/2008/06/13/rf4ce-consortium-aims-to-develop-rf-standard-for-entertainment-c/?guccounter=1 [return]
- https://www.edn.com/electronics-news/4313430/ZigBee-Alliance-and-RF4CE-Consortium-agree-to-RF-remote-standard?utm_source=eetimes&utm_medium=relatedcontent [return]