The Risky Road Bringing Building Management Systems Online: Exploring the CEA-852 Standard

As the legacy LonTalk protocol transitions from serial connectivity to the IP layer of the networking stack, in particular for connecting building management and automation systems online, we’re seeing much of that connectivity happening over the CEA-852 standard. 

While LonTalk-over-IP (operating over both TCP and UDP) significantly improves flexibility and interoperability, it also introduces new security considerations. Exposing LonTalk over IP expands the attack surface and introduces common IP-network risks, including unauthorized access, traffic manipulation, and remote exploitation in the absence of proper security controls.

This blog uncovers security weaknesses in the CEA-852 standard, including uncovering undocumented authentication mechanisms and issues within packet types that could lead to disruption of services. 

Before analyzing the functionality and potential impact of different CEA-852 packets, it is useful to first examine the basic structure of the protocol messages themselves. Understanding how these packets are constructed lays the groundwork for exploring how commands are transmitted and processed within the CEA-852 communication framework.

The standard specifies the following packet structure for CEA-852 messages:

CEA-852 Packet Structure

The diagram above illustrates the CEA-852 packet structure, which consists of a CNIP (Component Network over IP) header, followed by a payload and, optionally, an HMAC signature (depending on the implementation defined by the protocol code within the CNIP header)

CNIP header (Green):

• Packet length: The total size of the CNIP header and the packet payload in bytes.

• Protocol code: Identifies the CEA-852 implementation. Each protocol code defines different packet types and payload formats:

  • 0x01: IP-852 

  • 0x03: RNI (Remote Network Interface)

  • 0x04: LPA (LonTalk Protocol Analyzer). Also known as LSPA (LonScanner Protocol Analyzer)
    

• Packet type: Specifies the packet type for the given protocol code.

• Extended header size: Indicates the size of the extended header, expressed as the value multiplied by 4.

• Protocol flags: An 8-bit mask, where each bit represents a protocol-specific flag.
  In particular, for the IP‑852 implementation, the fifth bit (0x20) serves as a flag indicating whether the protocol’s HMAC authenticity feature is enabled. Observations in RNI/LPA show the protocol flag is always 0x82, which implies that HMAC authenticity is required.

• Vendor code: Distinguishes between standard protocol packets and vendor-specific implementations. The default non-proprietary vendor code is 0x00.

• Session ID: Identifies the session associated with the packet.

• Sequence number: Indicates the sequence number of the packet within the session.

• Timestamp: Records the timestamp value of the packet.

• Extended header (optional): Contains additional information, often used to represent configuration server context when a packet is sent on its behalf. The size of the extended header is determined by the Extended header size field.

Payload (Purple):

The payload format varies based on the packet type specified in the CNIP header.

HMAC (Yellow):

When present, a 16-byte HMAC signature is added to a packet to verify its authenticity. The authentication employs a customized, slightly modified MD5-based algorithm. In IP-852 packets, the HMAC signature is optional and depends on whether the security flag is enabled, whereas in RNI and LPA packets it is mandatory. The complete algorithm is discussed later.

CEA-852 implementations

The CEA-852 standard can be implemented in three main variants, determined by the protocol code in the CNIP header: IP-852, RNI and LPA. While all variants share the same CNIP header structure, they differ in supported packet types, payload formats, and the HMAC signing algorithm used. RNI and LPA are largely similar, with only minor differences in the payload information accessible from their packet types, yet they share the same packet types and HMAC algorithm. In contrast, the IP-852 implementation differs in both its packet types and the HMAC algorithm it employs.

IP-852 packets

IP-852 packets represent the implementation of the CEA-852 standard identified by protocol code 0x01, as previously noted.

IP-852 packet types are divided into two groups, determined by the vendor code value in the CNIP header:

• Standard packet types (Vendor code = 0x00): These packet types are standardized; vendor-neutral packet types must be supported consistently by any implementation that adheres to the relevant IP-852. They serve various functions, including encapsulating LonTalk data, requesting a server's device information, and retrieving channel health statistics.

• Vendor-Specific packet types (Vendor Code ≠0x00) : In addition to the standard IP-852 packets, vendors often implement proprietary packet types to support advanced, device-specific features. These packets are enabled when the vendor code field is set to a unique, vendor-assigned value. For example, the code is 0x01 for Echelon and 0x02 for Loytec. This allows for extended capabilities in device control and monitoring, such as enabling NAT, initiating a remote reboot, toggling web server access, and uploading firmware updates.

Standard Packet Types

The standard IP-852 packet types are defined in LtIpPackets.h within the official LonTalk stack SDK repository, as shown below:

An example of an IP-852 standard packet is PKTTYPE_DEVCONFIGURE (0x71), which is a response from a device or server containing configuration details. Its payload includes the device’s timestamp, IP and LonTalk flags, router and node types, multicast count, channel timeout, Neuron ID (named after the legacy Neuron chip, functioning similarly to a device MAC address) and its length, unicast IP and port, channel memory and sendlist timestamps, configuration and time server addresses, and the device name. 

Echelon-Specific Packet types

EnOcean, which now leads the development of Echelon BMS controllers (the original developer of the LonTalk protocol), offers BMS controllers that serve as centralized gateway controllers for entire smart buildings. This includes the legacy i.LON controllers as well as the modern SmartServer IoT BMS controllers series. These controllers act as the backbone of smart buildings, aggregating data from sensors, managing automation logic, and providing a unified interface for controlling lighting, HVAC, and other building systems.

The following Echelon packet types, identified by a Vendor Code of 0x01, are supported by Echelon products as defined in LtIpEchPackets.hwithin the official LonTalk stack repository:

An example of an Echelon proprietary IP-852 packet type containing device identification information is PKTTYPE_ECHDEVID (0xFA). This packet is used to inform a remote device or configuration server of the sender’s identity, which is necessary when firewalls alter the source port. Its payload includes the local IP address, NAT IP address, and IP port.

Loytec-Specific Packet Types

Loytec, now part of Delta Electronics, is a leading BMS provider, acting as the invisible “nervous system” behind modern facilities such as office towers, airports, hospitals, and data centers. Its hardware and software function as a universal translator, seamlessly connecting and coordinating systems like heating, lighting, and security through a centralized platform.

The IP-852 packet channel is enabled by default, even on devices that do not support LonTalk (CEA-709) over IP or where such support has been explicitly disabled.

Researching the latest firmware available from Loytec’s website revealed Loytec-specific packet types identified by vendor code 0x02. Below, we outline the research process and summarize the key findings that led to the discovery of these proprietary packet types, along with a brief explanation of their purpose.

We demonstrate the research process on the L-INX firmware device, although the same methodology applies across the entire Loytec product line. During analysis of the firmware, we identified numerous functions with the prefixes l852 (representing “Loytec” and “CEA-852”) and cnip, both of which relate to the handling of CEA-852 messages. Among these, two functions proved especially valuable in uncovering Loytec’s proprietary packet types:

• l852_bectx_process: Handles inbound Loytec-specific IP-852 packets and is key to understanding how the firmware processes non-standard messages. Through researching, we were able to trace this function into all subordinate routines responsible for managing Loytec’s proprietary packet types.

• cnip_alloc_msg: Allocates new packets by taking a packet type and payload size in bytes. By examining all references to this function, we were able to map out the proprietary packet types and infer their intended purposes.

An example of a Loytec proprietary IP-852 packet type is the fmw_push_request (0x94), which allows a client to upload update files to a Loytec device in chunks via IP-852 messages. In the screenshot below, the function l852_alloc_fmw_push_request constructs the firmware push IP-852 packet by calling cnip_alloc_msg with 0x94 as the packet type argument and explicitly sets the vendor code to 0x02 (Loytec’s Vendor Code).

HMAC Signature

Both standard and proprietary IP-852 packet types can include a 16-byte HMAC signature and use the same HMAC algorithm, based on MD5 and a 16 byte pre-shared key, to ensure packet authenticity. In IP-852, the pre-shared key is manually configured on both endpoints and cannot be transmitted or changed dynamically over the network. When HMAC protection is enabled the fifth bit of the protocol flags byte is set to 1. 

We define the message bytes as the concatenation of the CNIP header and the payload bytes.

The HMAC signature for IP-852 messages is illustrated below:

The illustration above shows the HMAC signature computation for IP-852 messages (when the authentication bit flag is enabled). The computation is performed through a sequence of chained MD5 hashes: first, the message is hashed; the resulting digest is then concatenated with a 16-byte zero vector and hashed again. Finally, this output is concatenated with the pre-shared secret and hashed once more with MD5, producing the final 16-byte HMAC signature.

RNI and LPA Packets

RNI (Remote Network Interface) packets implement CEA-852 and use protocol code 0x03, while LPA/LSPA (LonTalk Protocol Analyzer, also known as LonScanner Protocol Analyzer) packets use protocol code 0x04. Because the packet types are the same for RNI and LPA and only the responses differ. 

Packet Types

In this section, we will explore how to identify RNI and LPA packet types by researching the compiled libraries used in EnOcean products. Unlike EnOcean’s open-source GitHub SDK for IP-852 client and server implementations, no public source code exists for RNI and LPA. Therefore, we will analyze the relevant libraries - libRNI.so for RNI and libLSPA.so for LPA. Moreover, we will cover the standard packet types common to all devices that support RNI and LPA implementations (vendor code 0x00).

Let’s take a closer look at how KEEP_ALIVE (packet type 0x00) is handled in UplinkXLP(inlibRNI.so), as shown in the screenshot below:

Above, the main actions of the function are highlighted with red rectangles, as detailed in the following list:

1. We can see the main switch-case for received packets, which handles the RNI (and LPA) packet types.

2. Here, we show the implementation of packet type 0x00, which corresponds to KEEP_ALIVE.

3. The received packet is validated in the Verify function, which checks that the sequence number, CNIP header, and HMAC signature are all correct.

4. Verifies that the KEEP_ALIVE payload length is non-zero. If it is zero, the function logs a NULL packet type response.

5. There are two types of KEEP_ALIVE packets, depending on the first byte of the payload:

   1. 0x00 - Simple periodic Keep-Alive without ACK.

   2. 0x01 - Keep-Alive with ACK, which starts a timer when sent from the server (until the next ACKed Keep-Alive).

   3. Any other value indicates a malformed Keep-Alive packet.

We summarize below the packet types we identified in the UplinkXLP function, using the names shown in this function:

HMAC Signature

The HMAC signature is generated by the hmac_md5 function in the libRNI.so library. In RNI and LPA packets, HMAC signing is mandatory, with the default MD5 pre-shared key being 16 zero bytes. In RNI/LPA, the pre-shared key can be dynamically updated over the network using the INCAUTH packet type, which transmits the difference between the new key and the current one.

The calculation proceeds as follows:

First we define the message bytes as the CNIP header along the payload bytes:

We define the MAGIC variable as a 4-byte vector with each byte set to 0x36, and use the 6-byte Neuron ID of the target device. Both values are combined to derive the 22-byte key used in the signing process together with the 16-byte pre-shared secret. The key derivation process is defined as follows:

In the illustration above is shown the key derivation which divided to two case:

• When the pre-shared secret = 0x00 (left): the key is formed by concatenating the Neuron ID twice, followed by the MAGIC value, and then the Neuron ID once more.

• When the pre-shared secret ≠ 0x00 (right): the key is formed by concatenating the pre-shared secret with the Neuron ID.

Once the key has been derived, we proceed to compute the HMAC signature of the message. To achieve this, two 64-byte values are formed from the key: the inner key and the outer key. The 22-byte key is first right-padded with zeros to a total length of 64 bytes, then XORed byte-wise with a 64-byte vector of 0x36 to produce the inner key. Similarly, the zero-padded 64-byte key is XORed byte-wise with a 64-byte vector of 0x5C to produce the outer key.

The illustration above demonstrates the generation of two variables: the inner key (in pink) and the outer key (in brown). These values are used in the final step of the HMAC signature calculation.

The illustration above demonstrates the final HMAC signature calculation using the MD5 hashing algorithm, incorporating the previously derived inner and outer keys together with the message content.

Security Weaknesses in the CEA-852 Protocol

During our research into LonTalk’s IP implementation we discovered serious vulnerabilities and design weaknesses that create remote attack vectors capable of compromising BMS gateway/server devices exposed to the Internet. This is not only a LonTalk problem: once an attacker compromises a gateway (in our tests we demonstrated this on EnOcean and Loytec devices), they can manipulate the entire building-management ecosystem. Because these servers bridge and host multiple protocols and device types (BACnet, Modbus, HTTP, etc.), a single compromise can impact critical systems and sensors across the network.

HMAC Authentication Algorithm Weakness

As described in the previous section, the authenticity mechanism relies on verifying a received message using a 16-byte HMAC signature. The HMAC computation differs slightly between the IP-852 and RNI/LPA implementations, but both are primarily based on a 16-byte pre-shared key and the MD5 algorithm. Having uncovered the HMAC algorithm for both implementations, a single captured packet suffices to perform an offline brute-force search for the 16-byte pre-shared key. 

In case of RNI/LPA the Neuron ID (UID) of the destination device is needed for computation of the HMAC. Fortunately, in RNI/LPA, the default response packet to an unrecognized message is of the IDENT packet type. This packet includes the device’s Neuron ID, as shown in the illustration below:

In the illustration above, we can see the payload structure of the IDENT packet type. The first six bytes represent the Neuron ID, which is required to compute the HMAC signature, as explained in the previous section.

It is worth noting that many devices exposed online lack proper protection: numerous IP-852 endpoints have HMAC authentication disabled, and many RNI/LPA devices are signed with the default 16-byte all-zero pre-shared key. In practice, this makes it trivial for an attacker to craft valid CEA-852 messages.

As noted earlier, the HMAC may be recovered offline by brute force from a single captured packet, without requiring any active interaction with the target device.

Throughout the following sections, we assume that the HMAC authenticity mechanism has been defeated, whether by its omission or by an attacker’s ability to compute the required HMAC.

Undocumented, Security-Sensitive Loytec IP-852 Packet Types

Analyzing the undocumented Loytec-specific packet types (vendor code 0x02) revealed several important findings. We identified packet features that can impact Loytec controllers, enabling an attacker to disrupt device operation through denial-of-service conditions. Moreover, we found a way to bypass internal security mechanisms, allowing modification of critical core device configurations.

Reboot Command over IP-852

Loytec has implemented a simple proprietary IP-852 reboot command (packet type 0x90) that triggers a controller restart. This message can be easily exploited to cause an arbitrary denial-of-service, without any additional authentication requirements beyond the previously discussed HMAC mechanism.

In future research, we’ll break down multiple critical vulnerabilities in EnOcean (formerly Echelon) SmartServer and legacy i.LON controllers. These controllers power many real-world BMS networks, but insecure design decisions leave them vulnerable. We’ll show how they can be exploited, what makes them possible, and the impact they could have on operational building systems.