What is BACnet Secure Connect?

The new BACnet/SC data link adds authentication and encryption at the device and systems communication level.

BACnet/SC uses a mutual TLS authentication. It certifies the authenticity of BACnet protocol packets to both ends. Thus, the possibility of fake communication is reduced and an encrypted end-to-end communication is established.

The BACnet/SC addendum only defines a new, cybersecure datalink. Conceptionally, it is therefore possible to communicate with older BACnet devices on BACnet/IP and BACnet MS/TP as is always done within the BACnet world namely by “BACnet routing”. As such, it does not fundamentally change the BACnet application. Therefore, BACnet/SC is compatible with any previous and future versions of BACnet. That means building owners and managers do not need to replace devices, nor will they lose any capabilities from an existing BACnet system. For them, it is just a new TLS-secured datalink for their BACnet/SC-enabled devices.

³ As of writing, only IPv4 is supported.

BACnet/SC is a virtual datalink that is directly added into the BACnet protocol stack under the BACnet Network Layer in the application. As such, a mixture of traditional non-secure BACnet with already secured BACnet/SC parts of a project is possible. However, such mixed use-case scenarios will still require to protect the not yet BACnet/SC parts of the system by other IT-means with IT-security appliances or physical protection means, as has been common in the past.

The upper BACnet layers, specifically the application layer and network layer, have not changed at all.

The design’s architecture is centered around a so-called “hub”, which acts as a central component where all other BACnet/SC devices (called spoke-nodes) connect to. It uses that hub-and-spoke principle based on TLS-secured WebSockets to connect devices to a hub. If due to the system size, there is more than one hub in the system, a secured unicast routing mechanism between router-enabled hubs is managed by means of regular encrypted BACnet routing or, in the case of a hierarchical hub-of-hub scenario, where a hub is itself a node of another super-ordinate hub, again via the respective hub-and-spoke mechanism. The use of connection-oriented WebSockets isolates the BACnet communication better from the underlying IP-layer communication. This is an IT-friendly improvement over BACnet/IP, which uses direct UDP broadcasts and BACnet Broadcast Management Devices (BBMDs) if the BACnet system had to span more than just one IP-subnet: As BACnet broadcasts are now directly handled inside the hub-and-spoke network of interconnected WebSockets, neither does the IP-network layer has to handle any broadcasts anymore, nor does it need an artificial “bridging” of IP-subnets with BBMDs anymore.

Historically, BBMDs have been a challenge to configure in large systems due to the potential deep impact of the underlying IP-network behavior. BACnet/SC networks are completely independent of the underlying IP-network structure. In an extreme implementation, all nodes (spoke-nodes and hubs) could even be scattered arbitrarily into different IP-networks around the world. As long as the spoke-nodes can reach their hub, the BACnet/SC communication will work.

The BACnet/SC hub-and-spoke principle, or basic topology, delivers messages between devices. A BACnet/SC hub is a software function that is typically co-hosted on a BACnet router, but can also be a stand-alone hardware device, or it can be a virtual software component. Regardless, as the hub function is essential to network communication between devices, BACnet/SC can optionally be implemented with redundant hubs (so called fail-over hubs) to avoid downtime.

The hub relays all messages to the network devices. All BACnet/SC-enabled devices are required to make a connection to the primary hub. To do so, they have to provide proper digital certificates to the hub (and the hub to the devices⁴). Once the hub authenticates the devices, they can send messages through the hub, using encrypted payloads.

⁴Note: that BACnet/SC thus does a mutual TLS authentication. In contrast, the typical https protocol is only single-sided, that is: The WebServer authenticates to you by means of a digital certificate, but you have to authenticate to the WebServer application via a user account and password, PIN, mobile phone, etc. This makes BACnet/SC very secure, but also requires an individual certificate per BACnet/SC device.

An accepted certificate authority (CA) assures used certificates to have a signature. Hub connections are always established from the nodes to their hub, which allows for firewall-friendly topologies with distant hubs. As it suffices that the hub is reachable by the spoke-nodes, as the underlying secure WebSocket connections (WSS://) are always established from the nodes towards the hub, this translates to IT-firewall rules just have to make sure that the (few) hubs have to be reachable for ingest traffic, but that the (many) nodes may readily reside behind a restrictive firewall that typically might allow only outgoing traffic.

Note that the picture above illustrates the logical topology of a BACnet/SC network. This has nothing to do with the physical topology of the network. That is, the cabling of the underlying IP-network can be configured freely. It can be a star, a bus, a daisy chain or any other topology.

Still, there are of course some practical aspects: Devices connected as a daisy-chain mathematically multiply their failure probabilities along each daisy-chained device towards the end of the chain; while this is not special to BACnet/SC, it simply advises to better not put a hub at the very distant end of a daisy chain, as a hub is a critical core element of a BACnet/SC system and as such, should not be the device with the highest network failure probability at the end of the chain. On the other hand, as a node-to-node communication always has to traverse once from the source node to the hub and then again from the hub to the destination node, the number of hops a data packet has to travel in a daisy-chain also depends on where the hub is placed. Theoretically, the optimum position would be the middle of the chain. However, in real-world projects, this rarely makes a difference. As a rule of thumb, it is better to place the hub at/near the beginning of a daisy chain (that is: closest to the IP-backbone); if the building’s topology allows so, place any special time-critical devices in the daisy-chain order close to the hub (or avoid daisy-chains altogether ⁵).

⁵It is foreseeable that for cybersecurity reasons, IT-departments will over time anyway enforce mechanisms to selectively block suspicious IP-devices also for BA systems. But if these would then be part of a daisy-chain, of course all other devices behind that blocked device would also be cut-off of any communication. So the cabling paradigm for BAS will shift slowly from daisy-chains to direct cabled star-topologies.

From an engineer’s perspective, setting up a BACnet/SC system differs in the following aspects from a traditional BACnet project.

• The device that shall act as the primary hub has to be defined.
• The device that shall act as the fail-over hub has to be defined (optionally, if used, but strongly recommended to minimize on downtimes, e.g. on firmware upgrades and the like).
• Each spoke-node has to be told his hub address and its fail-over hub address, if used.
• In larger projects the network load can be reduced by mapping the nodes in a building structure along the building “scopes”, hierarchical hub-of-hub based topologies and “directed hub” traffic optimizations, see A6V11159798.
• Each device has to receive a (public) root certificate which is a commonly shared passport, proving that a device belongs to this very BACnet/SC site.
• Each device has to receive an individual, private operational certificate and corresponding private key which is an individual passport per device, used to encrypt- and decrypt traffic for that device.
• As certificates are provisioned and managed by a certification authority (CA), such has to be defined in the very beginning of a project. As certificates have a certain lifetime before they expire, but also could be compromised and then would have to be replaced, the definition of a CA and the respective workflow to issue-, sign-, renew- and replace certificates is a new workflow that has to be defined- and lived for a project over its full lifetime.
• Note that each hub has a maximum number of nodes that it can support (either directly or indirectly via a subordinate hub connected as node to it), that may not be exceeded at any time. As a hub (together with its nodes) also constitutes a BACnet network, this means that larger networks have to be split into multiple BACnet networks (and be addressed by a proper hub-of-hub topology, see A6V11159798).
• There are a few new properties (esp. in the network port object of the devices) that need to be set for example timeout values, TCP port to be used for the WebSocket communication, etc.
• Most of the times, the BACnet project will still be a mixture of BACnet/SC and non-BACnet/SC devices like BACnet IP and BACnet MS/TP. As has been before in mixed datalink projects, this has to be addressed by BACnet routing. So typically, the engineer will also have to set up the devices of a certain datalink type into a BACnet network of its own and define BACnet routing between the resulting BACnet networks.