Optigo Logo to return to homepage

Q&A with Bernhard Isler and David Fisher on BACnet Secure Connect

BACnet Secure Connect (BACnet/SC) with David Fisher and Bernhard Isler

Share This Post

We recently hosted a webinar on BACnet Secure Connect (BACnet/SC) with special guests Bernhard Isler from Siemens and David Fisher from PolarSoft, two main figures behind BACnet/SC. We talked about why BACnet/SC was developed, and how it will affect everyday users.

As expected, we got a ton of audience questions, on everything from hubs to security standards and more. So of course, we pulled David and Bernhard in to help answer all these great questions. Watch our recording below, check out our recap on the BACnet/SC webinar, and read on for the audience Q&A.

The opinions expressed in this webinar are those of the authors, and do not necessarily represent the views of ASHRAE, SSPC 135, Siemens, PolarSoft, or Optigo Networks.

As BACnet/SC is not yet a published standard, it is possible that in its final form BACnet/SC may deviate from what is presented here.

Certificate Authorities

Question: On an enterprise network with, let’s say 100 building operators with mobile devices, does each of them need a certificate installed on their device? Is the installation of the certificate a manual process that has to be done by an administrator?

Answer: Yes each device needs a certificate. The installation procedure for certificates is not yet standardized for BACnet/SC. It is our plan to create a standard method for configuring and administrating SC devices over BACnet in the future. At this point, there are requirements on certificate signing request formats in the exchange between a vendor tool and the CA for signing device certificates.

Q: Installing and running a Certificate Authority is no small undertaking and significantly complicates BACnet device and network complexity. It is at least as complicated as setting up and managing VPN services and I would argue even more difficult because this is for individual devices and not just for infrastructure. How do you envision customers handling this extra complexity on top of device identifiers, BACnet network numbers, IPv4 and IPv6 addressing, which are already difficult for “non-IT” site supervisors?

A: It is true that security adds to the cost, and is typically a complex thing, technically. Vendors and tool manufacturers should take care to hide the technical complexity, and allow users to configure this in their terms.

However, if someone sees sufficient protection being provided by VPNs for BACnet/IP, this is still an available option anytime, and can be combined with some BACnet/SC networks where needed.

As a sort of compensation you no longer need to worry about IP network structures such as IP subnet boundaries and NAT boxes.

Q: Is there one key that doesn’t change for everything?

A: No there are many keys. The only shared thing is the signature on the device certificates. But in all cases, there are no shared keys involved. This is all based on a Public Key Infrastructure (PKI), with public and private keys individually for devices and hubs. What counts is the device certificate being signed by the CA used for the installation or network. So the CA essentially holds the power to give a device the “key” to enter, by signing the device’s certificate. But checks are required individually for each device certificate to be signed. To whom do you give the key?

Q: To use a certification authority, would a building be required to be connected to the Internet?

A: No. The building does not need an online connection to the CA. Once the system is set up and all devices are configured with the proper certificates, the verification of certificates does not need to contact the CA at all. Since we require mutual authentication this is valid for the hub and also devices or nodes equally. A connection peer is configured with certificates of Certificate Authorities (called CA certificates), and is required to have the CA certificate of the CA that signed the other peer’s device certificate for establishing a connection. This verification is done during the TLS handshake and the CA is not involved in this.

Note that the signature on the device certificate can be obtained by the vendor tool from the CA through any sorts of means including online access, emails etc., the tool just needs to have the signature on the device certificate before the tool puts the now-signed device certificate into the peer’s configuration.

The standardization for configuring certificates straight into the device, not requiring a vendor tool, is the top priority for future work of the committee and the IT-WG.

Q: Who issues the signed certificate?

A: That depends on site policy. In theory BACnet/SC devices should be configured using some trusted CAs. The CAs being used are not required to be linked up to a big Trusted CA like Versign or similar. You can use self-signed certificates, but this does not scale well. The standardized mechanism for certificate configuration is not yet part of BACnet/SC. It is our plan to define a standard mechanism to do this across BACnet going forward.

Hubs

Q: Can the hub be managed remotely over an enterprise network?

A: In theory this should be possible. But the current BACnet/SC proposal does not define yet how this will be done through BACnet. It is our plan to create a standard method for configuring and administrating SC devices in the future. Until then, vendors may choose to expose some status etc. in BACnet, but this representation remains a vendor’s own matter.

Q: Does the hub manage the key validation?

A: Yes, yet both peers of a connection, the node and the hub, validate each other mutually to have a certificate signed by an accepted Certificate Authority. Accepted Certificate Authorities are configured into the device by installing these CA’s certificates, referred to as CA certificates, into the device that needs to validate a peer.

Q: How is the data secured on the way to a cloud hub? VPN?

A: No, VPN is not required for BACnet/SC. The communications using BACnet/SC occur over TLS 1.3. This is the worldwide IT standard for secure communication. Data sent via TLS is encrypted before being sent.

The TLS connection (or virtual protection conduit) is directly established between BACnet devices and the BACnet hub, also when in the cloud in this case.

Q: If you have physical access anywhere between the BACnet device and hub is the traffic still encrypted? Where does the decryption take place and does this process of encryption and decryption introduce latency to the system?

A: Yes. Hub-to-Node communications are fully encrypted. The latency is negligible particularly on larger platforms. Since any platform using BACnet/SC is already using a full TCP/IP stack with TLS, it’s not going to be a small processor.

Note that in TLS, once the session keys are established, efficient shared key encryption is in place. Since the TLS connections remain open, the heavy-load key negotiation is not required and thus not much additional processing power is needed and latency can be low.

Q: Since you’re using a hub, what about network congestion? Can you daisy chain?

A: The “hub” in the BACnet/SC sense is not the physical network hub that you are used to but an application function. The actual physical infrastructure would still use regular Ethernet switches and has no additional limitations in terms of expansion on the Ethernet and IP level.

Currently, for the sake of simplicity in its first release, the BACnet/SC hubs cannot be cascaded. So there is no daisy-chain on this level. But note that a BACnet/SC connection can be established directly across any IP or Ethernet structure, including the Internet. However, more complex structures of BACnet/SC networks and hubs are possible using BACnet/SC to BACnet/SC BACnet Routers.

Q: From a risk-management perspective, what is the average cost per hub/25 devices?

A: We won’t know that until vendors begin to implement BACnet/SC. In many cases BACnet/SC will simply be software functionality that is added to existing BACnet routers or router/controllers. Some vendors may choose to implement stand-alone BACnet/SC hubs and routers. The cost of those devices we would expect to be comparable to existing BACnet router devices.  

Q: Aren’t hubs antiquated switches?

A: The “hub” in the BACnet/SC sense is not the physical network hub that you are used to. The term is used because it logically follows the idea of a “hub”, just as a bicycle wheel has a hub, or What’sApp using a logically central service for distributing messages. A BACnet/SC hub is a software function that can be on a router or other hardware, or it can be completely virtual. No change is required for existing switch-based Ethernet and other IP infrastructure.

Q: Can a hub connect to another hub?

A: No, not at this point. While there was discussion about cascaded hubs and such, we decided to go without for the sake of simplicity and standardization efforts now, yet not excluding such options for the future.

However, more complex structures of BACnet/SC networks can be achieved with the current draft using BACnet/SC to BACnet/SC BACnet Routers.

Implementation and standards

Q: On an enterprise network, what updates or upgrades are required on a central BAS server and in remote buildings?

A: That’s too general of a question to answer. Generally speaking, “updating” an existing site using BACnet to use BACnet/SC will require at least some updating of firmware in resident devices, or the introduction of BACnet/SC routers that route to existing non-SC forms of BACnet.

Q: What encryption standard are you using? How many bits is the encryption?

A: BACnet/SC uses TLS 1.3. This standard has eliminated older less secure cipher suites in favor of a small number of much more secure ciphers based on 128 bit and 256 bit elliptic curve cryptography. Please refer to RFC 8446 at IETF for reference of what cipher suites are available in TLS 1.3.

Q: Why do you believe it is inherently secure? 

A: Because BACnet/SC uses TLS 1.3 and 256 bit elliptic curve encryption, it is not practical to “hack” using brute force methods based on technology available today and in the foreseeable future. It would take decades of computing using all of the available computing power on Earth to crack these codes. As BACnet/SC also requires perfect forward secrecy, you can’t replay previous transactions, and there are time limits within which a given transaction can occur. It may be possible at some point in the future that quantum computing devices could be made that could defeat this kind of encryption. Long before that point TLS will be evolved to newer encryption that would be similarly robust and could be used with the then-current BACnet/SC. TLS 1.3 is inherently secure against known methods of attack, which is why it is used worldwide as the best practice for securing communications.

Q: Is it possible for the BACnet message payload to be compromised from the non-BACnet/SC side, and propagate to the BACnet/SC side?

A: Non-SC BACnet communications are not secure in themselves. As Bernhard has pointed out in our webinar, you can implement other kinds of security such as VPN, as a means of securing “regular” BACnet, but often this is not implemented due to cost and complexity. So if you have a mixed SC and Non-SC BACnet network, the non-SC portion(s) will not be secure. Another way of saying that is that in such situations those networks are vulnerable to “internal” hackers with physical access to the network infrastructure.

Vendors may decide to produce “BACnet/SC to other datalink” BACnet Routers that include some firewall functionality on BACnet services to mitigate such risks.

Q: What are the key things to know regarding communication across subnets?

A: BACnet/IP was limited by the requirement in IP that broadcast messages cannot cross IP subnets. The existing BACnet standard defines devices known as BBMDs that manage the distribution of broadcast messages across IP subnets. With BACnet/SC, such considerations go away because the SC hub(s) manage broadcast distribution independent of subnets, and also work through firewalls and NAT.

Q: What is the largest BACnet network BACnet/SC has been tested on? Does it scale to 2000+ BACnet/IP devices?

A: So far there have only been a few prototypes tested for interoperability. Scalability has not been tested “in the public” as yet. But from a technology perspective there is no reason why one could not make a hub that could manage 2000 connections.

Q: Have you done any pen testing?

A: No. Since the BACnet/SC is not yet part of BACnet, there are few prototype implementations. Going forward it is our expectation that many vendors will implement BACnet/SC, giving us the opportunity to do PlugFests and other forms of tests. Even so, the security aspects of BACnet/SC are just TLS 1.3 which is the worldwide standard for security and encryption.

Pen testing is done on products generally, so is out of scope of the committee doing the standard. BACnet/SC allows hardened products to be protected sufficiently to withstand pen testing as needed.

Q: Are security enhancements planned for Modbus?

A: This committee does not deal with Modbus. It is an entirely different group and the protocol is not owned by ASHRAE. So we do not know what is currently happening with Modbus.


Our thanks to Berhnard Isler and David Fisher for participating in our webinar, and for answering these audience questions!

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore