Das EST-Protokoll: der vergessene Standard

Duncan Jones | Head of Research Mehr zu diesem Autor >

Innerhalb der letzten Jahre ist der Einsatz von Zertifikaten schier explodiert. Zum Teil ist diese Entwicklung auf den Trend zur Miniaturisierung zurückzuführen. Die alten monolithischen Applikationen werden heute als dutzende von Mikro-Services auf Plattformen wie Kubernetes betrieben. Solche Anwendungen lassen sich je nach Anforderungsprofil nahezu beliebig in beide Richtungen skalieren. In Stoßzeiten kann die Zahl der beteiligten Instanzen in die Hundertausende gehen. Und jede einzelne von ihnen muss ihre Identität bei jeder anderen der beteiligten Instanzen nachweisen, einschließlich gegenüber externen Dritten.

Das EST-Protokoll: der vergessene Standard

Am anderen Ende der Skala befinden sich inzwischen zahllose Geräte unseres täglichen Lebens. Noch vor weniger als zehn Jahren waren unsere Küchen voll mit hauswirtschaftlichen Geräten, die nichts anderes zu tun hatten als beispielsweise Kaffee zu kochen oder Lebensmittel frisch zu halten. Jetzt sind sie vollgestopft mit WiFi-fähigen Kleincomputern, übermitteln regelmäßig Datenströme in Richtung Cloud und bekommen OTA (Over the Air) Updates. Neu errichtete Gebäude verfügen über eine Fülle von Apparaturen, die so ziemlich alles steuern, von den Sicherheitsfunktionen bis hin zur Stimmungsbeleuchtung. Man wird heutzutage keine einzige moderne Brückenkonstruktion mehr finden, bei der die Last, der Durchsatz an Fahrzeugen, die Schubspannung und so weiter nicht kontinuierlich von Sensoren überwacht werden.

Eine gängige Anforderung, die alle Szenarien gemeinsam haben ist, dass Identitätsinformationen bereitgestellt werden, nachdem ein Gerät installiert wurde. Docker Container müssen erst einmal zum Leben erwachen bevor sie eine zertifizierte Identität für eine bestimmte Umgebung bekommen. Haushaltsgeräte müssen zunächst personalisiert werden und die Erlaubnis bekommen im Namen ihres Eigentümers zu „handeln“. Ganz ähnlich ist es im industriellen Umfeld. Sensoren oder Smart Gateways werden mit Herstellerschlüsseln ausgeliefert, die vorab aufgenommen und gespeichert werden müssen, bevor die Geräte ihren Dienst aufnehmen.

Als Unternehmen (wie beispielswese Thales) damit begonnen haben solche Probleme anzugehen, haben sie zunächst die verfügbaren Standards genau untersucht und sind dabei auf ein äußerst nützliches Protokoll für die Verteilung von Zertifikaten gestoßen. In den Jahren, die besagtes Protokoll bereits existiert, hat es nie den Stellenwert erhalten, der ihm gebührt. Es ist einfach, effektiv und lässt bei der Implementierung relativ wenig Spielraum für Interpretationen. Es sollte also deutlich populärer sein als es tatsächlich ist: Das Enrollment-over-Secure-Transport-Protokoll, kurz EST.

Enrollment-over-Secure-Transport-Protokoll

EST ist ein Protokoll, das dazu dient X.509-Zertifikate über https anzufordern. Das Gerät, das ein Zertifikat anfordert, bezeichnet man als EST-Client. Dieser Client kommuniziert mit einem EST-Server, der auf Anfragen wartet, die über einen vorhersagbaren URL-Pfad an ihn gerichtet werden. Clients müssen lediglich die IP-Adresse des Servers kennen, um ihre Anfrage zu senden. Der EST-Server übernimmt in diesem Szenario die Rolle der Registrierungsstelle. Ihre Aufgabe ist es zu entscheiden, ob die Zertifikatsanfrage des EST-Client berechtigt ist. Ist das der Fall, wird die Anfrage an die Zertifizierungsstelle (CA, Certificate Authority) weitergeleitet. Diese stellt daraufhin das betreffende Zertifikat für den Client aus. Die Kommunikation zwischen dem EST-Server und der CA selbst ist nicht über das Protokoll abgedeckt und unterscheidet sich je nach Zertifizierungsstelle.

Bootstrapping

Um loszulegen braucht der EST-Client initiale Identifikationsdaten. Die nehmen entweder die Form eines Shared Secret an oder es handelt sich um einen bereits existierenden privaten Schlüssel oder ein bereits existierendes Zertifikat. Auf den ersten Blick betrachtet, kann das verwirrend sein. Was soll das heißen „man muss eine Identität bereitstellen bevor man ein Identitätsprotokoll überhaupt benutzen kann“?

Die Antwort ist, dass wir in den allermeisten Fällen davon sprechen, ein Gerät von den Werkeinstellungen aus zu personalisieren. Und man will schließlich vermeiden Zertifikate an jeden x-Beliebigen auszustellen, der eine Anfrage an einen EST-Server-Endpunkt richtet. Bei physischen Geräten ist es in aller Regel so, dass der Produzent Standardschlüssel oder geheime Informationen integriert und diese Information mit seinen Kunden teilt. Bei Containern kann üblicherweise die benutzte Plattform (wie etwa Kubernetes) grundlegende Identifikationsdaten installieren. Diese weisen nach, dass diese Container in einem bestimmten Cluster als legitim zu betrachten sind.

Umgekehrt muss der Client seinerseits den EST-Server authentifizieren. Wenn das EST-Server-Zertifikat von einer bekannten, sprich einer vertrauenswürdigen Root-CA stammt, sollte die client-seitige Authentifizierung ohne weitere Intervention funktionieren. Sollte das nicht der Fall sein, gibt es zwei weitere Optionen. Entweder man benutzt ein zertifikatloses Protokoll auf der Basis von Shared Secrets wie sie etwa in TLS-SRP (aus dem englischen übersetzt: Transport Layer Security Sichere Remote-Kennwort-Script-Suiten). Sie enthalten eine Reihe von kryptografischen Protokollen. Diese erlauben es auf Basis von Kennwörtern und mithilfe eines durch SRP-Kennwort authentifizierten Schlüsselaustauschs zu kommunizieren. Alternativ dazu kann ein Mensch involviert werden und den Fingerabdruck des EST-Serverzertifikats validieren. Diese Variante eignet sich natürlich längst nicht für alle Umgebungen.

Der vergessene Standard

Warum also hat man EST so lange übersehen? Einer der Gründe ist, dass es ein einfaches Protokoll ist. Es ist so leicht wie verlockend ähnliche Protokolle zu entwickeln ohne auch nur in Betracht zu ziehen, welche Standards schon existieren. Standards erlauben es uns, Lösungen schneller und möglichst interoperabel zu entwickeln. Sie sorgen dafür, dass bei Planung und Design weniger Fehler passieren. Eine Tatsache, die gerade bei „selbstgestrickten“ Verschlüsslungsprotokollen gang und gebe ist. Ein anderer Grund ist die nötige Aktualität. Wir stehen am Anfang eines Zeitalters mit einer Flut von zu erwartenden Zertifikaten. Und die Industrie braucht Zeit zu realisieren, dass neue Ansätze notwendig sind. EST wurde erstmals 2012 veröffentlicht. Ein Jahr in dem die Welt noch ziemlich anders aussah als heute. Mit dem Einstieg in das Zeitalter des IoT und von Cloud Computing tut die Industrie gut daran, existierende Protokolle zu nutzen um die sichere Zertifikatsausgabe zu gewährleisten. EST ist nicht die einzige Option, aber eine sehr überzeugende, die sich bereits bestens bewährt hat.

Weitere ausführliche Hintergrundinformationen zu diesem Thema finden sie im Horizons Research Portal von Thales eSecurity.