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

BACnet Secure Connect (BACnet/SC) with David Fisher and Bernhard Isler
Got questions on BACnet/SC? Get the answers to audience questions from our webinar

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!

Recent Blog Posts

Have a troublesome network and a pcap file, but don’t know where to start with Visual BACnet? 

Trying to keep up with rampant device issues, constant network changes, or vendors pointing fingers instead of solving problems?

Interview between Monica McMahen, Marketing Director, and Pook-Ping Yao, CEO of Optigo Networks.

The worlds of IT and Operational Technology (OT) are merging more and more these days as the Internet of Things grows in prominence.

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.

Recent Projects

Data center expansion with OTI and Optigo Connect

DATA CENTER EXPANSION

Stack Infrastructure is a portfolio of hyperscale computing data centers. OTI completed work on Phases I and II, and returned for the Phase III build-out of a 4-megawatt data hall and brand new central plant. The Optigo Connect network put in place in Phases I and II was expanded on this project. The team achieved quick roll-out of a large, multi-service redundant network using the Optigo OneView management interface. Going forward, the facility management team can use OneView to remotely monitor equipment, manage power usage, and meet up-time goals.

Optigo Connect MR Soluciones The Landmark

THE LANDMARK

The Landmark is a sophisticated mixed-use high-rise in Mexico. The owners wanted to integrate all OT systems in the skyscraper, while maintaining separate networks for each application. The Landmark is the fourth joint project between Optigo Networks and MR Soluciones. Together, these companies provide robust services to meet any challenge.

Australian Bureau of Statistics at 45 Benjamin Way with Delta Building Automation

45 BENJAMIN WAY

Delta Building Automation (Australia) had a big job renovating the Headquarters for the Australian Bureau of Statistics (ABS) at 45 Benjamin Way. The building owner wanted to improve the building’s energy use and increase their National Australian Built Environment Rating System (NABERS) score to more than 4.5 stars, out of a possible total of six. Securing the network both internally and externally was a big priority, as well.

Penn State University Optigo Networks Visual BACnet

PENN STATE UNIVERSITY

When Tom Walker looked at Penn State University’s Navy Yard network, he saw huge issues. The system was busy and loud, to the point where the overrun network was bringing down the entire building. Because this was happening on the MS/TP network, pinpointing the problem would mean boots on the ground to segment and test the chain, piece by piece.

Penn State University Optigo Networks Visual BACnet

PENN STATE UNIVERSITY

When Tom Walker first started working at Penn State University four years ago, there were a lot of network issues. Buildings were dropping offline. Broadcast traffic was pushing 90,000 packets per hour. Walker was on the phone almost every single night because devices were down or had to be reset.

 

Torre Manacar Mexico City Optigo Connect

TORRE MANACAR

When MR Soluciones began work on Torre Manacar, they knew they needed a flexible and scalable network infrastructure to support a wide array of integrated systems. Optigo Networks was a natural fit for the massive project, designing a robust network at a competitive cost.

short

SHORT PUMP TOWN CENTER

Short Pump Town Center, an upscale retail center, underwent a complete renovation in 2014. The flexibility of Optigo Networks’ solution meant the retail center’s unknown final design was not a barrier to placing IP surveillance equipment in the field.

BOULEVARD MALL

BOULEVARD MALL

Optigo Networks connected New York-based Boulevard Mall’s security surveillance devices in December 2015, using a Passive Daisy Chain topology.

Visual BACnet tech support team

TECH SUPPORT TEAM

One tech support team at a manufacturer purchased an account with Visual BACnet in April 2017, for technical problems around the world.

Aster Conservatory Green Optigo Connect

ASTER CONSERVATORY GREEN

The Aster Conservatory Green is a community comprising 352 residences across 24 low-rise buildings. The buildings use advanced surveillance and access control technology, including 40 HD video cameras and 60 FOB-access-tele-entry points for access control.