Improving BACnet Secure Connect (BACnet/SC) Deployment with Automated Certificate Management

BACnet/SC Security Certificate Management

Managing BACnet Secure Connect (BACnet/SC) certificates can be a challenging task, especially for large buildings. Just recently at the AHR Expo 2024, we learned of a project that had over 300 devices and the decision was made to use 10-year certificates due to the multiple days (3-4) of labor needed to deploy BACnet/SC certificates. The owners didn’t want to pay for the systems integrator go through the effort to manually update certificates on a regular basis. From a security perspective, using a 10-year certificate is not much better than having no security at all.

Fortunately, there is a better way. Veridify’s DOME™ platform automates BACnet/SC certificate management and renewal, and eliminates complexity and potential errors. More on this at the end of the article.

What is a Digital Certificate that is used for Security?

Digital certificates are files containing data, and generally have certain information such as the date of issue, expiration date, manufacturer, and a list of devices for which it is valid. In some ways, a digital certificate is like a passport. Digital certificates are signed by a trusted third party and are used to establish secure communications between BACnet devices. These digital certificates play a crucial role in implementing secure authentication and encryption to protect the integrity and confidentiality of data exchanged in a BACnet SC network.

Here’s a general overview of how digital certificates are used in BACnet/SC:

  1. Authentication: Digital certificates help authenticate the identity of BACnet devices within a network. Each device is issued a digital certificate, and during communication, devices use these certificates to verify each other’s identity. This helps prevent unauthorized devices from participating in the network.
  2. Encryption: BACnet/SC employs encryption to secure the communication channels between devices. Digital certificates are used to establish secure connections, ensuring that data transmitted between devices is encrypted and protected from eavesdropping or tampering.
  3. Digital Signatures: Certificates include digital signatures to verify the authenticity and integrity of messages exchanged between devices. This helps to detect any tampering with the data during transmission.
  4. Key Management: Digital certificates play a role in key management, helping devices manage encryption keys used for secure communication. This includes the generation, distribution, and renewal of cryptographic keys.

How are Digital Certificates Issued?

Digital Certificates used are generally issued and signed by a Certificate Authority (CA).

The process to issue a certificate is fairly straightforward:  the device creates a keypair, the device uses the keypair to generate a certificate signing request (CSR), the CSR is moved to the CA, the CA validates the CSR and performs any other local authentication tasks, and if all is in order the CA uses the CSR to create a signed certificate which includes the CAs public key, and the certificate is returned to the device.

While this process is straightforward on the surfacet, the implementation can be a complicated endeavor.  Specifically, this raises the three fundamental questions:

  1. How does the CSR get to the CA?
  2. How does the signed digital certificate get returned to the device?
  3. How does the CA validate the authenticity of the device and the CSR prior to signing the digital certificate?

More specifically, the question arises:  when a CA receives a CSR, how does the CA authenticate that the requesting device is who it says it is?  For example, when you go to get a driver’s license, you need to provide documentation about who you are and show proof that you have the right to drive.  Some of this documentation could involve an older license, or one from another state.  A child might bring a parent to attest to their identity. The DMV has many procedures to authenticate the request and validate the person is authorized before issuing their license.  A Certificate Authority also needs similar procedures, however these processes are in no way standardized, and each CA operates with its own set of procedures to validate a request.

In the case of BACnet/SC, the device generates a CSR and the system integrator installing the device needs to pull the CSR off of the device and manually transfer it to the CA platform. Then the installer needs to ask the CA to generate the signed certificate, providing more detailed information about the device to the CA (providing the authentication documentation).  Then the CA will sign the certificate and the Installer needs to carry it back to the device to install it. The following link has example instructions showing the manual nature and complexity of this approach.

To simply this process, some people use “self-signed” certificates. It is possible to make your own self-signed certificate, where every device acts as their own CA.  Every device signs their own certificate with their own key, asserting their own identity.

Problems with Self-Signed Digital Certificates

Self-signed digital certificates have both advantages and disadvantages, and while they can be a quick solution for certain scenarios, they come with several security challenges. Here are some of the key security challenges associated with self-signed certificates:

Lack of Third-Party Verification: One of the primary security challenges with self-signed digital certificates is the absence of third-party verification. Unlike digital certificates issued by a trusted Certificate Authority (CA), self-signed certificates are not validated by an external entity. This lack of external validation makes it easier for attackers to use fraudulent certificates.

No Root of Trust: Certificate chains establish a hierarchy of trust, where a root CA vouches for the authenticity of intermediate CAs, and intermediate CAs, in turn, vouch for end-entity certificates. Self-signed certificates break this chain of trust since there is no higher authority vouching for the authenticity of the certificate. This can lead to issues with trust and validation in a network environment.

Increased Risk of Man-in-the-Middle Attacks: Without third-party validation, there is an increased risk of man-in-the-middle (MitM) attacks. An attacker could intercept communication, present a fraudulent self-signed certificate, and potentially compromise the confidentiality and integrity of the communication.

Challenges in Certificate Distribution: Distributing self-signed digital certificates can be a logistical challenge, especially in large-scale deployments. In contrast to certificates from a trusted CA, self-signed certificates may require manual distribution or configuration on each device, increasing the likelihood of misconfigurations and errors.

Limited Revocation Mechanisms: Revoking a self-signed digital certificate is more challenging than revoking certificates issued by trusted CAs. In the absence of a standardized and widely adopted certificate revocation mechanism, dealing with compromised or outdated self-signed certificates can be less efficient.

Potential for Certificate Spoofing: Self-signed digital certificates are more susceptible to certificate spoofing attacks. If an attacker can replace a legitimate self-signed digital certificate with a malicious one, they may gain unauthorized access or conduct other malicious activities.

Difficulty in Auditing and Compliance: Organizations that need to adhere to specific security standards and compliance regulations may face challenges when using self-signed certificates. Many standards require the use of certificates from trusted CAs to ensure a higher level of security.

While self-signed digital certificates may be suitable for certain use cases, such as testing environments or small-scale deployments, they are generally not recommended for production systems, especially those where strong security and trust are paramount. In production environments, obtaining digital certificates from a reputable CA is the preferred approach to establish a secure and trusted communication infrastructure.

Automated BACnet Secure Connect Certificate Management with DOME

Recognizing the above challenges and security risks, Veridify has developed the DOME platform with capabilities to automate certificate management for BACnet/SC devices. The benefits for security management of BACnet/SC devices include:

  • A system-driven approach that improves the speed of implementation and eliminates the opportunity for errors.
  • Device registration with a simple “point-and-click” process using the DOME Mobile App™
  • No IT/Cyber expertise is needed and installation of secure devices can be completed by existing building automation technicians.

Certificates can be renewed automatically by DOME as often as desired – daily, weekly, monthly, quarterly, or annually. This eliminates the upfront and on-going labor expense of certificate management.

Learn More About Improving BACnet/SC Certificate Management

Contact Us or Request a Demo to learn more about DOME and how it can improve certificate management and deployment for BACnet/SC.

Learn More button Request a Demo button


Blog Post Summary – All of our posts listed on one page back through 2019

See the slides below to learn more about cybersecurity for building controls and smart buildings.