Zertifikate, Schlüssel und Hashing – ein paar Insider-Grundlagen

Mit diesem Beitrag erreichen wir die Mitte meiner Security-Serie - einige Probleme wurden schon aufgezeigt und Lösungen vorgestellt. Schauen wir nun ein wenig tiefer in das Thema hinein und lasst mich in meinen Worten (ich verspreche, es knackig zu halten) einige grundlegende Sicherheitsmechanismen erklären. Und danach - im nächsten Beitrag - werden wir sehen, wie diese Mechanismen funktionieren und in welche Lösung sie integriert werden. 

Fast alle gängigen asymmetrischen Verschlüsselungen basieren auf Primzahlen, denn - keine Sorge, ich erspare Ihnen die Details - der Grundgedanke ist, dass es, da es sich um eine Primzahl handelt, keinen kleineren Teiler gibt, so dass ein Brute-Force-Angriff nicht stattfinden kann (mit einem kleinen Teiler). Wenn also ein Angreifer versucht, einen Schlüssel zu knacken, müsste er oder sie viele große Zahlen berechnen, was einen Angriff sehr ineffizient macht.

Ein weiteres wichtiges Credo: Ein Schlüssel ist gut, aber 2 Schlüssel sind besser. Der Gedanke dahinter ist: Wo zwei Parteien kommunizieren, besteht ein Schlüssel im Wesentlichen aus zwei Schlüsseln: einem privaten und einem öffentlichen. Wie der Name schon sagt, ist der öffentliche Schlüssel den Teilnehmern bekannt, so dass eine Nachricht an ihn damit  verschlüsselt werden kann. Ist die verschlüsselte Nachricht angekommen so kann der Besitzer des Schlüsselpaares diese mit seinem, nur ihm bekannten, privaten Schlüssel entschlüsseln.

Ein weiterer wichtiger Begriff: Zertifikat. Grundsätzlich verpackt ein Zertifikat verschiedene Metainformationen in einen Schlüssel (in den meisten Fällen den öffentlichen). Ein Schlüssel kann z.B. an einen anderen Schlüssel gebunden werden, so dass Hierarchien aufgebaut werden können, während andere enthaltene Informationen eine Internet-URL oder die Inhalte einer Datei sein können.

Diese Kombination (öffentliche/private Schlüssel + Zertifikatsinformationen) hat bereits große Auswirkungen:

• Dieser Aufbau von Hierarchien ermöglicht es, Vertrauen gegenüber Dritten aufzubauen (ein neues Zertifikat kann sich auf das älteste Zertifikat in der Hierarchie beziehen und das ältere Zertifikat kann die Glaubwürdigkeit des neueren Zertifikats bestätigen). Dieser Prozess bezieht sich auf den Sicherheitsaspekt in einer "offenen Welt", in der neue Parteien teilnehmen können. 

• So wird beispielsweise ein normaler Laptop mit einigen allgemeinen Zertifikaten von VeriSign oder Microsoft ausgeliefert. Nehmen wir an, dass Sie es mit einer brandneuen Komponente aktualisieren, die einen speziellen Treiber benötigt, um ordnungsgemäß zu funktionieren, obwohl Ihr Laptop das Zertifikat dieses neuen Treibers nicht kennt. Aber der Laptop vertraut bereits auf das Microsoft-Zertifikat auf dem Laptop. Deshalb signiert der Treiberhersteller seinen Treiber mit seinem Zertifikat UND verknüpft ihn mit dem Microsoft-Zertifikat -> der Treiber wird geladen! Wenn Sie allerdings nur die Kommunikation bekannter Geräte über das Internet absichern wollen ist dieser Mechanismus nicht erforderlich und würde nur einen übergroßen Verwaltungsaufwand verursachen Um dies umzusetzen ist  der Mechanismen die gleichen, aber Sie müssen keine Dritten in den Authentifizierungsprozess einbeziehen, da Server und Gerät ja wohlbekannt sind.

• Im Laufe der Zeit sind Unternehmen wie Verisign oder Globalsign entstanden, die Zertifikate verkaufen und sie mit den in den Geräten integrierten Root-Zertifikaten verknüpfen. Normalerweise müssen diese Zertifikate alle 2-4 Jahre ausgetauscht werden, da sie ablaufen und natürlich neu bezahlt werden müssen. Während dies im offenen Internet für z.B. Internet-Banking sinnvoll ist (siehe auch das Beispiel mit dem neuen Treiber zuvor), ist es für Embedded-Geräte nicht immer wünschenswert. Hier ist eine Verknüpfung mit diesen Root-Zertifikaten nicht erforderlich oder nicht erwünscht (so haben Sie tatsächlich mehr Kontrolle und können unerwünschte SW ausschließen). Abgesehen von der Verlängerung des Ablaufdatums (immer im Hinterkopf behalten, welche Dinge geschützt werden müssen) der Zertifikate, müssen Sie für diese Zertifikate nicht bezahlen, da Sie sie in einer privaten CA generieren können.

Die traurige Wahrheit in der Realität:

• Diese Art der Ver-/Entschlüsselung ist sehr CPU-zeitaufwendig. Um die Performance zu verbessern, werden Dateien nicht verschlüsselt, sondern sind im Klartext gehalten. Auf sie wird eine Einweg-Funktion angewendet, so dass Sie einen fast einzigartigen Fingerabdruck dieser Datei erhalten. Das nennt man Hashing und "Einweg", weil man diesen Fingerabdruck nicht zurückrechnen kann. Nur dieser Hash ist in das Zertifikat integriert und stellt so eine Art Manipulationsschutz dar.

• Wie bereits erwähnt, ist diese Art der Ver-/Entschlüsselung sehr CPU-intensiv. Wenn also eine Datei oder E-Mail verschlüsselt wird, geschieht dies in der Regel mit symmetrischer Verschlüsselung. Symmetrische Verschlüsselung funktioniert wie die meisten WIFI-Zugangspunkte. Tatsächlich ist es oft ein allen Parteien bekanntes Geheimnis, wie etwa ein WIFI-Passwort. Das schließt den Kreis zu unserer verschlüsselte Datei oder E-Mail, nur wird hier das "Passwort" auf die höherentwickelte asymmetrische (öffentlicher + privater Schlüssel) Weise gespeichert.

• Dennoch gibt es einen Weg, um "besser zu verschlüsseln" und es gibt bereits viele Tools, die umfassende Sicherheit für das angeschlossene Gerät bieten können. Vor nicht allzu langer Zeit hatten die meisten bestehenden Installationen nur ein Zertifikat für alle Geräte der gesamten Installation, so dass es (jedenfalls soweit ich es erlebt habe) also nicht ein dediziertes Zertifikat pro Gerät gab. Das liegt einfach daran, dass früher das Provisioning für einzelne Geräte recht zeitaufwendig war. Das hat sich jedoch geändert und bei den meisten Embedded-Herstellern ist dies heute gegen eine geringe Servicegebühr möglich. Na klar, S&T / Kontron bietet das natürlich auch an.

Die für die Device-to-Device-Kommunikation entwickelten Zertifikate und andere Sicherheitsmechanismen haben ihren Weg in die Hardware der heutigen Embedded-Systeme gefunden - wie sie dort integriert sind, werde ich in meinen nächsten beiden Blogs behandeln.