Arbeitsweise

Ähnlich wie bei IRC besteht ein SILC-Netz aus mehreren Servern – damit enden aber schon die Gemeinsamkeiten. Selbst wenn man es von der Bedienung und der bisherigen Beschreibung glauben möchte, basiert SILC nicht auf IRC, sondern ist eine komplette Neuentwicklung. Dies bedeutet umgekehrt, dass SILC nicht mit IRC oder anderen Protokollen kompatibel ist. Nimmt man es ganz genau, besteht das SILC-Protokoll sogar aus drei einzelnen Protokollen, deren Spezifikationen mit neu eingeführten Fachbegriffen nur so um sich werfen. Die folgenden Anwendungsbeispiele illustrieren, wie SILC funktioniert.

Alice im Serverland

Angenommen, Alice möchte ihrem Freund Bob eine verschlüsselte Nachricht schicken. Sie startet zunächst ihre Chat-Software, den SILC-Client, mit dem Alice einen SILC-Server in ihrer Nähe eine Verbindung kontaktiert. Er soll die verschlüsselte Nachricht dann sicher an Bob weiterleiten.

Alices Client schickt dem Server zunächst eine Liste mit allen von ihm unterstützten Sicherheitsfunktionen und Verschlüsselungsalgorithmen. Der Server wählt dann aus dieser Liste die Sicherheitsmerkmale aus, die er selbst unterstützt. Das Ergebnis teilt er dem Client mit. Auf diese Weise einigen sich die beiden Parteien schon im Vorfeld auf die zu verwendenden Sicherheitsfunktionen.

Theoretisch könnte der Client jetzt schon lossenden – würde da nicht noch der Schlüssel fehlen, mit dem die Nachricht chiffriert wird. Diesen Schlüssel handeln Client und Server nach einem ausgeklügelten System kurzerhand selbst aus: Nach ihrem ersten Start erzeugen Client und Server jeweils ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel (siehe Kasten "Public-Key-Kryptographie" ). Diese zwei Paare verwenden Client und Server in unterschiedlichen Lebenslagen – wie beispielsweise jetzt im Rahmen des altbekannten Diffie Hellman-Algorithmus. Während seiner Ausführung passieren gleich mehrere Dinge: Client und Server tauschen ihre öffentlichen Schlüssel aus, die sie umgehend als Teil einer Prüfsumme zur Integritätsprüfung verwenden. Anschließend einigen sich die beiden Parteien auf einen so genannten Session Key. Er sichert ab sofort den Kommunikationskanal zwischen Client und Server. Jeder Session Key gilt nur für eine bestimmte Zeitspanne. Letztere dauert normalerweise eine Stunde, maximal jedoch bis die Sitzung endet. Nach ihrem Ablauf wird der Session Key automatisch neu ausgehandelt.

Public-Key-Kryptographie

Die so genannte Public-Key-Verschlüsselung funktioniert ähnlich wie ein Safe mit zwei Schlüsseln: Zunächst erzeugt Bob mit einem trickreichen, mathematischen Verfahren ein Schlüsselpaar. Einen der beiden veröffentlicht er im Internet, den anderen, privaten, behält er gut unter Verschluss. Sobald ihm nun Alice eine Nachricht zukommen lassen möchte, greift sie zum öffentlichen Schlüssel und chiffriert damit ihren Text. Das Ergebnis kann ab sofort nur noch Bob mit seinem zugehörigen, privaten Schlüssel öffnen.

Mit dem Session Key in der Hand endet auch die erste Phase des Verbindungsaufbaus. Alle bis hierhin vorgestellten Abläufe regelt das so genannte SILC Key Exchange Protokoll (kurz SKE). Sein einziges Ziel ist die Ermittlung des Sitzungsschlüssels, mit dem nun die folgenden beiden Protokolle weiterarbeiten.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023