HTTPS

HTTPS forms the basis for HTTP protocol cybersecurity on top of the Transport Layer Security (TLS). BACnet/SC ensures cybersecurity in a similar manner by deploying the WebSocket protocol (ws://) on top of the same TLS security to create TLS-protected WebSockets (wss://) and represents best practice in IT, specifically, the use of standard (X.509v3) digital certificates.

BACnet/SC is even more secure than a normal HTTPS connection: While HTTPS only authenticates the connection at one end (web server to web client), BACnet/SC devices mutually authenticate at both ends. This however also requires the corresponding certificates on each device and not just on the web server side, as is the case for https.

More precisely, each device requires two certificates:

  • A (common) root certificate that proves that a device belongs to this project (i.e. is not a rogue device).
  • An (individual) operational certificate so that only the addressed device can decrypt the traffic.

Common root certificate

All BACnet/SC devices share a common root certificate in a project but each device also has an individual operational (or client) certificate.

Digital certificates are a cybersecurity-relevant task. The issuing authority or Certification Authority (CA) for a site must ensure that no rogue devices are certified, that all private keys are kept secret, and maintained throughout the life of the project and is also responsible for renewing or revoking certificates as needed.

Worst case is that BACnet/SC communication stops the system when a certificate expires.

Digital certificates are not automatically renewed in BACnet/SC. The operator is notified starting at 90 days prior to expiration of the pending expiration. Failure to renew the digital certificates for a device (hub or node) will render the device unable to communicate on BACnet/SC and can cause the system to fail.

A device that replaces a defective device must receive both certificates (root and operational) to go operational and certificates are system critical. On most projects:

  • The customer's IT department acts as the Certification Authority.
  • Certificates are limited in time (typically less than 2 years; ABT Site default is 5 years).

Early in a project, the building automation and IT planners must agree on 1) who is responsible for initially issuing certificates and 2) the periodic renewal of the certificates with the latter added to the appropriate SLA accordingly.

Certificate workflow (applicable to all installations)

  • Exchange files on the file level between the Certification Authority (CA), ABT Site, and all Desigo devices.
  • Where ABT acts as the CA on multi-vendor projects, ABT is responsible for exchanging all equipment certificates from the other vendors.
  • Include the BACnet/SC devices as part of the engineering phase for BACnet/IP.
  • Coordinate with all project participants when bootstrapping directly to BACnet/SC or when starting a project on BACnet/IP. On the latter, include the BACnet/SC devices during the engineering phase for BACnet/IP.
  • Switch the project's BACnet/SC devices to pure BACnet/SC at the end of commissioning (i.e. by disabling open BACnet/IP ports). This is not available as part of the initial market package and may require subsequent implementation.
  • Test all end-to-end communications.
  • Where applicable: Test any failover hubs.

Certificate workflow for embedded Desigo devices with ABT Site as CA

  • ABT Site creates a root certificate (.CRT) for the project.
  • ABT Site creates operational certificates for all embedded devices and signs them.
  • ABT Site adds the public part of the root certificate and both parts of the operational certificate (public certificate and the private key) to a container file (.P12) and supplies it to the embedded devices.
    • The container file includes the private key and must be protected against unauthorized access. ABT Site handles the private keys for Desigo devices and adds them to overall project data (classified as confidential). There is no need as a rule to distribute the .P12 files.
  • ABT Site sets certificate expiration dates.
  • ABT Site renews certificates that are limited in duration (ABT Site does not permit certificates of unlimited duration).

Certificate workflow for Desigo CC and third-party BACnet/SC devices

For a more detailed description, see Desigo CC Creating and Importing Certificates

  • ABT Site creates a root certificate (.CRT) for the project.
  • Desigo CC creates its own operational certificate (client certificate) and includes it with a signing request (.CSR).
    • Desigo CC also creates a private key file (.KEY) belonging to its (public) operational certificate. This private key is kept secret and resides on the local Desigo CC server.
  • Desigo CC hands over the .CSR file to ABT Site.
  • ABT Site checks the authenticity of the signing request and digitally signs Desigo CC's operational certificate (creating a .CER file).
    • Signing a request is critical. Never blindly sign a request. Always check the validity and authenticity of the request before proceeding. Please note that this is a local issue: The same person that sets up both Desigo CC and uses ABT, sends digitally signed emails, or knows and trusts the person requesting the signature, etc.
  • ABT Site hands over the root certificate file for the project (.CRT) and the signed operational certificate for the Desigo CC file (.CER) to Desigo CC.
  • Desigo CC: On the Windows level, the two files are packaged together with the locally maintained private key (.KEY) into an intermediate P12 file format (.PFX) and imported to the Windows certificate store. The OpenSSL tool is still used as a standalone tool for this step: Desigo CC must rely on the Windows certificate repository (certlm.msc) as a Windows-based software and the repository accepts only specific container file formats.
    • The container must be password protected (strong) since it also includes a private key.
  • Within Desigo CC, a BACnet/SC driver is generated for the target project and connected to the corresponding certificates from the Windows certificate store.
  • ABT Site provides the URI (or the IP address) of the BACnet/SC hub on the project that Desigo CC must connect to.

Desigo CC configures the URI (or the IP-address) to that hub and becomes a regular BACnet/SC node on the project.

Desigo-only projects: A third party is responsible as CA for the certificates

  • ABT Site creates certificates for all Desigo embedded devices.
  • ABT Site creates digital signing requests for all Desigo embedded devices.
  • ABT Site hands over all the certificates over a trusted channel to the external Certification Authority.
  • The external Certification Authority checks validity and signs all certificates.
  • ABT Site receives the signed certificates and loads them to the devices.
  • Desigo CC applies to the external Certification Authority exactly as it would to ABT Site.

Multi-vendor projects: A Siemens partner is responsible as CA for the certificates

  • For Desigo equipment, the process is the same as Desigo-only (see above).
  • For equipment from other vendors, ABT Site acts as the Certification Authority:
    • The other vendor creates its own certificates.
    • The other vendor also creates a digital signing request.
    • The other vendor hands over the digital signing request on a file level over a trusted channel to ABT Site.
    • ABT Site signs the certificates and returns them to the other vendor.
    • Another vendor imports certificates to its devices.

Multi-vendor projects: A third party is responsible as CA for the certificates

  • For the Desigo equipment, the process is the same as Desigo-only case: "A third party is responsible as CA for certificates" above.