BACnet/SC
BACnet Secure Connect (BACnet/SC) is a new BACnet datalink ASHRAE 135-2020 Annex AB that provides secure message transport. BACnet/SC uses the standard IP application protocol, Secure WebSocket, which is an extension to HTTPS and runs over Transport Layer Security (TLS). BACnet/SC provides a secure mechanism to authenticate and authorize a device to use the network. In addition, BACnet/SC eliminates the need for static IP addresses and network broadcast messaging. BACnet/SC works with firewall devices that are common in IT infrastructure and is fully compatible with existing BACnet IP systems and devices.
- Validate that the peer's operational certificate is well formed.
- Validate that the peer's operational certificate is active as of the current date and not expired.
- Validate that the peer's operational certificate is not revoked, if such information is available.
- Validate that the peer's operational certificate is directly signed by one of the locally configured CA certificates.
BACnet/SC certificates
To establish a connection, each device needs to determine that it trusts the device it is trying to establish a connection with. For example, if Device A and Device B want to establish a connection between them, each device sends its operational certificate to the other device to authenticate.
An operational certificate is a term that BACnet uses for the certificate that a device uses for BACnet/SC communication. Operational certificates are also known as TLS certificates or identity certificates. The operational certificate is simply a file of information about the device, along with the device's public key and a digital signature by the Certificate Authority (CA) that issued the certificate. The operational certificate that contains the public key is paired with a private key securely held only on the device that generated it. A new public-private key pair is created by the device when it is requested to generate a Certificate Signing Request. You must request an operational certificate for all your devices on the BACnet/SC network.
BACnet/SC also requires that all devices have at least one signing certificate associated with it. Normally, a site uses one signing certificate, but BACnet/SC supports a second signing certificate for each device to facilitate switch-over to a different signing certificate for the site. A device uses the signing certificates to determine if it can trust the operational certificate presented to it by other devices that want to connect to it. All devices on the site have a copy of the same one or two signing certificates, so that they can mutually trust each other.
Public keys
A public key is the public portion of a cryptographic system's public-private asymmetric key pair. The public and private keys are mathematically linked to each other, so that a device (A) can give another device (B) its public key if it wants to communicate to it through secure communication. Device B can then encrypt the messages to send to Device A with A's public key. Only Device A can decrypt the message, which requires the corresponding private key that only Device A knows and keeps secret. Any device watching the communication cannot understand the message because it does not have Device A's secret private key to decrypt the messages sent from Device B to Device A.
Certificate authority and how to sign the certificate
- You can request the customer's IT department to act as the CA.
- You can request the CA from a third party.
- You can create your own CA without the IT department or a third party. The instructions in this document describe this option.
When the CA creates the operational certificate for each device on the site, it places information in the operational certificate about the CA, or issuer. All BACnet/SC devices on a site need to have the certificate for the CAs they trust. BACnet/SC requires that all devices can trust up to two CA certificates.
When Device A receives a request from Device B to connect to it, A is presented with B's operational certificate. Device A can then examine Device B's operational certificate to determine which CA issued it. Device A checks if this is one of the CAs it knows and trusts. The exchange happens on a bi-directional basis because BACnet/SC uses mutual authentication.
All devices on a site that communicate through BACnet/SC must have an operational certificate signed by the same CA trusted by other devices on the BACnet/SC network.
Certificate signing request
A certificate signing request (CSR) is generated by a device as the first step to obtain a new operational certificate. The CSR contains information about the device and the public key from a newly generated public-private key pair. The information in the CSR becomes part of the operational certificate, along with information about the CA that created the operational certificate. After the operational certificate is issued and saved to the device, the CSR that was used is no longer needed.
The BACnet/SC topology
BACnet/SC uses a hub-and-spoke topology. The central Hub Function performs message forwarding for all broadcast messages and for point to point messages for devices that do not support more efficient direct connections. All devices support direct connections. The following figure outlines the hub-and-spoke topology for BACnet/SC.
| Number | Name | Definition |
|---|---|---|
| 1 | Hub Function | The Hub Function analyzes the traffic to determine whether it can be directed to another node or forwarded to all connected nodes. The Hub Function itself is also a node. The Hub Function is also responsible for forwarding broadcasts. Broadcasts must be sent from a node to the Hub Function, which then forwards to all other connected nodes. For more information, see also The Primary Hub and The Failover Hub. |
| 2 | Node | This can be a simple device or a more sophisticated device
that routes to an existing BACnet system or the main workstation for
the entire site. Nodes initiate a WebSocket connection to a Primary Hub or Failover Hub. Nodes can optionally initiate or accept direct connections to other nodes. |
The Primary Hub
A Primary Hub device has both a node and a Hub Function. The node on the Primary Hub device connects to the Hub Function, as if it was a different device. The Primary Hub is expected to perform the Hub Function when reachable and always accepts WebSocket connections. A BACnet/SC site supports one Primary Hub.
The following figure illustrates a scenario of the BACnet/SC network, where every node is connected to the Primary Hub.
The Failover Hub
A Failover Hub device has both a node and a Hub Function. The Failover Hub's node connects to the Primary Hub Function. If the Primary Hub Function is offline, then all nodes, including the Failover Hub's node, connect to the Failover Hub Function. The Failover Hub Function is always running on the site and always accepts WebSocket connections, even if the Failover Hub's node is connected to the Primary Hub Function. If some nodes are unable to connect to the Primary Hub Function, they connect to the Failover Hub Function, even if other nodes are able to connect to the Primary Hub Function. A BACnet/SC site supports one Failover Hub only. While it is optional to have a Failover Hub, it is best practice to configure a Failover Hub so as not to leave a site with a single point of failure.
The following figure illustrates the failover scenario of the BACnet/SC network, where the Primary Hub is offline and nodes get re-routed to the Failover Hub.