HTTPS

HTTPS ist die Grundlage für HTTP-Protokollsicherheit auf dem Transport Layer Security (TLS). BACnet/SC stellt Cybersicherheit sicher mittels WebSocket-Protokoll (ws://) zusätzlich zur TLS-Sicherheit, mit der TLS-geschützte WebSockets (wss://) erstellt werden, und dient als Best-Practice in IT bezüglich dem Einsatz von Standard-Digitalzertifikaten (X.509v3).

BACnet/SC ist sicherer als eine normale HTTPS-Verbindung: Während HTTPS nur die Verbindung am einen Ende (Webserver zu Web-Client) authentifiziert, werden BACnet/SC-Geräte gegenseitig an beiden Enden authentifiziert. Das erfordert entsprechende Zertifikate auf jedem Gerät, nicht nur dem Webserver wie bei https.

Jedes Gerät benötigt also zwei Zertifikate:

  • Ein (gemeinsames) Root-Zertifikat, mit dem gezeigt wird, dass ein Gerät zum Projekt gehört.
  • Ein (einzelnes) Betriebszertifikat, sodass nur das adressierte Gerät die Daten entschlüsseln kann.

Gemeinsames Root-Zertifikat

Alle BACnet/SC-Geräte haben ein gemeinsames Root-Zertifikat im Projekt und jedes Gerät ein eigenes (oder Client) Zertifikat.

Digitale Zertifikate sind eine Cybersicherheitsaufgabe. Die Ausgabestelle oder Zertifizierungsstelle CA muss für einen Standort sicherstellen, dass keine falschen Geräte zertifiziert werden, alle privaten Keys geheim bleiben und über die Lebensdauer des Projekts gepflegt werden. Die CA ist auch zuständig für die Neuausgabe und Rücknahme von Zertifikaten.

Im schlechtesten Fall stoppt BACnet/SC ein System, wenn ein Zertifikat abgelaufen ist.

Digitale Zertifikate werden in BACnet/SC nicht automatisch erneuert. Bediener werden 90 Tage vor Ablauf entsprechend benachrichtigt. Werden die digitalen Zertifikate für ein Gerät (Hub oder Knoten) nicht erneuert, kann das Gerät nicht mehr über BACnet/SC kommunizieren und das System fällt aus.

Wird ein defektes Gerät ersetzt, muss das neue Gerät beide Zertifikate empfangen, damit es funktioniert. Zertifikate sind also systemkritisch. In den meisten Projekten:

  • Die IT-Abteilung stellt die Zertifikate aus (agiert als CA).
  • Zertifikate sind zeitlich limitiert (normalerweise weniger als 2 Jahre; die Vorgabe in ABT Site ist 5 Jahre).

Zu Beginn eines Projekts müssen die GA- und IT-Planer sich verständigen, wer 1) für die Ausgabe von Zertifikaten und 2) die periodische Erneuerung der Zertifikate und deren Beigabe zum SLA zuständig ist.

Workflow für Zertifikate (alle Installationen)

  • Dateien werden auf Dateiebene zwischen der Zertifizierungsstelle CA, ABT Site und allen Desigo-Geräten ausgetauscht.
  • Wird ABT als CA in Projekten mit mehreren Lieferanten eingesetzt, ist ABT für den Austausch aller Einrichtungszertifikate der anderen Lieferanten zuständig.
  • Einbezug der BACnet/SC-Geräte als Teil des Engineering für BACnet/IP.
  • Koordination aller Projektteilnehmer bei direktem Bootstrapping zu BACnet/SC oder beim Start eines Projekts auf BACnet/IP. Einbezug der BACnet/SC-Geräten während des Engineerings für BACnet/IP.
  • Umschalten der BACnet-SC-Geräte im Projekt auf reines BACnet/SC am Ende der Inbetriebnahme (z.B. durch Deaktivierung der offenen BACnet/IP-Ports). Nicht verfügbar als Teil des ersten Marktpakets, spätere Umsetzung erforderlich.
  • Testen der ganzen End-to-End-Kommunikation.
  • Wo zutreffend: Testen der Failover-Hubs.

Workflow für Zertifikate in Desigo-Geräten mit ABT Site als CA

  • ABT Site erstellt ein Root-Zertifikat (.CRT) für das Projekt.
  • ABT Site erstellt die Betriebszertifikate für alle zugehörigen Geräte und signiert diese.
  • ABT Site fügt den öffentlichen Teil des Root-Zertifikats und beide Teile des Betriebszertifikats (öffentliches Zertifikat plus privater Key) zu einer Container-Datei hinzu, die den betroffenen Geräten geliefert wird.
    • Die Container-Datei enthält den privaten Key und muss gegen nichtautorisierten Zugriff geschützt sein. ABT Site bearbeitet die privaten Keys für die Desigo-Geräte und fügt diese zu den Projektdaten hinzu (als Vertraulich klassifiziert). Normalerweise müssen die .P12-Dateien nicht verteilt werden.
  • ABT Site bestimmt die Zertifikatsablaufdaten.
  • ABT Site erneuert die zeitlich begrenzten Zertifikate (ABT Site lässt keine unbegrenzten Zertifikate zu).

Zertifikat-Workflow für Desigo CC und BACnet/SC-Drittgeräte

Ausführliche Informationen dazu in Desigo CC Zertifikate erstellen und importieren

  • ABT Site erstellt ein Root-Zertifikat (.CRT) für das Projekt.
  • Desigo CC erstellt ein eigenes Betriebszertifikate (Client-Zertifikat) und schliesst dieses mit einer Signierungsanforderung (.CSR) ein.
    • Desigo CC erstellt auch einen privaten Key (.KEY) für das (öffentliche) Betriebszertifikat. Dieser Key ist privat und geheim und liegt auf dem lokalen Desigo CC Server.
  • Desigo CC übergibt die .CSR-Datei an ABT Site.
  • ABT Site prüft die Echtheit der Signierungsanforderung und signiert das Betriebszertifikat für Desigo CC digital (erstellt eine .CER-Datei).
    • Die Signierung einer Anforderung ist kritisch. Eine Anforderung darf nie blind signiert werden. Die Gültigkeit und Echtheit der Anforderung ist immer vorgängig zu überprüfen. Beachten Sie dabei bitte: Diejenige Person, die Desigo CC aufsetzt und ABT verwendet, sendet digital signierte E-Mails oder kennt und vertraut der Person, die die Signatur anfordert etc.
  • ABT Site übergibt das Root-Zertifikat für das Projekt (.CRT) und das signierte Betriebszertifikat für die Desigo CC Datei (.CER) an Desigo CC.
  • _Desigo CC: Auf Ebene von Windows werden zwei Dateien zusammen verpackt und mit dem lokalen, privaten Key (.KEY) in ein Zwischendateiformat P12 (.PFX) gepackt und in den Zertifikatsspeicher von Windows importiert. Das Tool OpenSSL wird autonom für diesen Schritt eingesetzt: Desigo CC muss auf die Windows-Zertifikatsablage (certlm.msc) als Windows-basierte Software abstellen und die Ablage akzeptiert nur spezifische Container-Dateiformate.
    • Der Container muss passwortgeschützt sein (starke Passwörter) und enthält ebenfalls einen privaten Key.
  • In Desigo CC wird ein BACnet/SC-Treiber für das Zielprojekt erzeugt und mit den betreffenden Zertifikaten aus dem Windows-Zertifikatsspeicher verknüpft.
  • ABT Site stellt die URI (oder IP-Adresse) des BACnet/SC-Hubs auf dem Projekt bereit, mit dem Desigo CC verbinden muss.

Desigo CC konfiguriert die URI (oder IP-Adresse) mit dem Hub und wird zum regulären BACnet/SC-Knoten im Projekt.

Nur Desigo-Projekte: Eine Drittpartei ist die zuständige CA für die Zertifikate

  • ABT Site erstellt die Zertifikate für alle in Desigo integrierten Geräte.
  • ABT Site erstellt die digitalen Signierungsanforderungen für alle in Desigo integrierten Geräte.
  • ABT Site übergibt alle Zertifikate über einen Trusted-Kanal an die externe Zertifizierungsstelle.
  • Die externe Zertifizierungsstelle prüft die Gültigkeit und signiert alle Zertifikate.
  • ABT Site empfängt die signierten Zertifikate und lädt diese in die Geräte.
  • Desigo CC wendet die externe Zertifizierungsstelle genau wie ABT Site an.

Mit mehreren Lieferanten: Ein Partner von Siemens ist die zuständige CA für die Zertifikate

  • Bei Desigo-Einrichtungen ist der Prozess derselbe wie bei nur Desigo (siehe oben).
  • ABT Site als CA erstellt die Zertifikate für die Einrichtungen anderen Lieferanten:
    • Der andere Lieferant erstellt eigene Zertifikate.
    • Der andere Lieferant erstellt eine digitale Signierungsanforderung.
    • Der andere Lieferant übergibt die digitale Signierungsanforderung auf Dateibasis über einen Trusted-Kanal an ABT Site.
    • ABT Site signiert die Zertifikate und übergibt diese an den anderen Lieferanten.
    • Ein weiterer Lieferant importiert die Zertifikate in die Geräte.

Mit mehreren Lieferanten: Eine Drittpartei ist die zuständige CA für die Zertifikate

  • Bei Desigo-Einrichtungen ist der Prozess derselbe wie bei nur Desigo: "Eine Drittpartei ist die zuständige CA für die Zertifikate".