Partner-StammCA

Konsumieren Bayern mehr Cannabis als anderen Bundesländern oder warum sind mit der Bundesanstalt für Arbeit und Nürnberg als auch der Freistaat Bayern gleich zwei staatliche Organisationen mit eigenen PKIs unterwegs und fordern Kommunikationspartner zur Installation der RootCA auf? DATEV als Defakto-Software in den meisten Firmen installiert seine eigenen RootCAs gleich automatisch.

Gleich vorneweg: Wer einer RootCA sein vertrauen schenkt, vertraut ohne weitere Vorkehrungen allen davon abgeleiteten Zertifikaten und SubCA's. Der Betrieb einer RootCA muss gewissen Sicherheitsstandards entsprechen und die sind wohl nicht erfüllt, wenn die RootCA's nicht Teil des RootCA-Programme von Microsoft, Google, Mozilla sind.


Bild: https://pixabay.com/photos/trust-man-hood-map-prompt-4321822/

Worum geht es?

Wer verschlüsselt oder signiert kommunizieren möchte, kommt heute an Zertifikat nicht vorbei. Ihr Browser verbindet sich per HTTPS mit einem Webserver, der seine Identität durch ein Zertifikat nachweist. Ein Zertifikat ist im Wesentlichen ein Name, ein öffentlicher Schlüssel und eine Signierung durch eine Zertifizierungsstelle oder Kette. Ihr Client "vertraut" durch die Installation des Betriebssystems oder einer Software, z.B. des Browsers, einer gewissen Zahl von "vertrauenswürdigen Stammzertifizierungsstellen. Wenn Name, Aussteller Verwendungszweck und Gültigkeitszeitraum passen, dann kommt die Verbindung zustande. Als Anwender können Sie dann ziemlich sicher sein, dass Sie beim richtigen Server gelandet sind und die Daten nicht durch fremde Personen gelesen werden können.

 

Sicherheit

Das Prinzip basiert natürlich darauf, dass die Liste der Stammzertifizierungsstellen (RootCA) sicher ist und sich hier keine fremde RootCA einschmuggelt. Das passiert leider schneller, als ihnen lieb ist, z.B.

  • Firmenrichtlinie
    Wenn Endgeräte durch Firmen verwaltet werden und die Firma einen Proxy-Server mit "TLS-Inspection" einsetzt, dann wird die TLS-Verbindung aufgebrochen. Dazu stellt der Proxy oder die Firewall ein eigenes Zertifikat für die angesprochene Webseite aus und ihr Client vertraut der Firewall als RootCA. Anbieter können durch HSTS (HTTP Strict Transport Security) dies unterbinden und Apps können dies über Zertifikatspinning prüfen. Aber im Grund ist das Vorgehen legitim und wird Millionenfach gemacht. Eine Firma hat ein Interesse, sich zu schützen und als Nutzer eines Firmengeräts sollten sie dann eben nicht ihre privaten Geschäfte über diesen Weg abwickeln.
  • Installationsquellen
    Jedes Software, die sie als Administrator auf ihrem PC installieren, kann auch die Liste der Stammzertifizierungsstellen unbemerkt erweitern. Das kann z.B. bei Fehleranalysewerkzeugen wie Fiddler erwünscht sein. Eine Software muss aber z.B. nicht den Speicher für Root-Zertifikate von Windows nutzen, sondern kann seinen eigenen Speicher mitbringen (z.B. Firefox).
  • Fehler in Produkten
    Manchmal kommt aber auch ein Stammzertifikat auf ihren PC, mit dem sie nicht gerechnet haben. Eher zufällig habe ich das im Jahr 2019 beim Intel Treiber-Assistent gefunden. (Siehe Intel RootCA Fehler (CVE-2019-11095)
  • Staatlicher Einfluss
    Bislang habe ich nicht erlebt, dass in demokratischen Staaten eine "staatliche RootCA" verpflichtend installiert wird. Aber es gibt schon Bestrebungen, dass Softwareprodukte entsprechende Hintertüren einbauen müssen oder entsprechende RootCAs in die Hardware oder das BIOS integriert werden müssen. Wobei auch die EU durch eIDAS und QWAKs auf dem schlechten Weg in diese Richtung ist.
  • MDM Profile
    Es mag andere Staaten geben, in denen das schon der Regelfall ist und über SIM-Karten-Profile und andere MDM-Lösungen können Mobilfunkprovider wohl auch entsprechende Einstellungen vornehmen.

Das ganze Prinzip der Zertifizierungsstellen basiert darauf, dass die RootCA-Betreiber nur Zertifikate für Zwischenzertifizierungsstellen ausstellen, die einen gewissen Sicherheitslevel erfüllen. Leider gab es schon in der Vergangenheit genug Fälle, dass genau dies nicht immer gewährleistet ist.

Ist das schlimm?

Eine RootCA hat ein Zertifikat, welches von ihr selbst unterschrieben wurde und ziemlich lange gültig ist. Sie können dies z.B. im Windows Zertifikatsspeicher einfach sehen: Hier eine Momentaufnahme:

Die meisten Zertifikat haben als Schlüsselverwendung nur die Freigaben für:

Zertifikatsignatur
Offline Signieren der Zertifikatsperrliste
Signieren der Zertifikatsperrliste (06)

Schauen Sie aber in die "Erweiterte Schlüsselverwendung", dann sind bei einigen Stammzertifikaten viele andere Möglichkeiten offen. Aber selbst ohne diese Öffnung kann der Betreiber einer RootCA jederzeit eine untergeordnete CA aufbauen, die dann Zertifikate für Webseiten, Mailadressen u.a. ausstellt.

Sie sollten also immer im Blick haben, welchen Stammzertifizierungsstellen Sie vertrauen.

Partner CAs

Kommen wir nun zu den Vertretern, die eine eigene RootCA betreiben. Das ist im auch nicht verwerflich, solange diese RootCA nur auf Client der Firma vertrauenswürdig ist. Dann ist dies eine effektive Funktion für Netzwerkauthentifizierung per 802.1x, Absicherung des VPN-Zugangs oder generell die Verschlüsselung und Identifizierung von internen Diensten per TLS. Kritisch wird es aus meiner Sicht, wenn diese Zertifikate auch extern eingesetzt werden und die Zugriff ohne weitere Vorkehrungen die klassischen "Zertifikatsfehler" liefern.

Bitte sagen Sie nie ihren Anwendern, dass Sie eine Zertifikatswarnung einfach wegklicken. Die machen das später auch bei einer Bank-Seite o.ä. und erlauben den Abgriff von Anmeldeinformationen.

Daher sehe ich es kritisch, wenn eine RootCA von Partnern bitteschön als "vertrauenswürdig" eingetragen werden soll. Ich habe hier drei  Beispiele gefunden. Ich bin aber sicher, dass es noch viel mehr Firmen mit solchen Konstruktionen gibt:


Quelle: Mail der Bundesanstalt für Arbeit


https://www.aldi-nord.de/cert/


S/MIME-verschlüsselte E-Mail-Kommunikation mit der Stadt Gunzenhausen
https://gunzenhausen.de/smime.html


https://www.datev.de/web/de/service-und-support/signatur-und-verschluesselung/signierte-e-mails-von-datev/

Sie können Sich nun überlegen, ob Sie sich als Administrator oder Anwender auf diesen Wunsch einlassen. Sie schwächen ihre eigene Sicherheit, denn Sie vertrauen einer RootCA, deren Sicherheit sie nicht kennen. Kritisch wird es, wenn Sie die andere Seite die Nutzung der RootCA nötigt. Das muss gar nicht direkt rüber kommen. Durch die Blume kann man schon sagen, dass ansonsten keine verschlüsselte Kommunikation möglich sei und man daher von einer weiteren Zusammenarbeit absehe.

Der einzige, der dabei gewinnt ist ihr Gegenüber, denn der Betrieb einer RootCA kann er günstig bereitstellen und spart sich den Kauf von "öffentlichen Zertifikaten". Vielleicht sollten Sie im Gegenzug auch eine eigene RootCA aufbauen und ihren Kommunikationspartner "bitten", dass er ihrer RootCA sein Vertrauen schenkt. Ich bin relativ sicher, dass dies aber nicht passiert.

In dem Zuge sollten Sie auch staatliche Programme im Blick haben. Zwar nutzt das Finanzamt mit "Elster" eine Webseite aber bietet auch Module für 3rd-Party Produkte zur Integration an. Auch für den ePerso brauchen Sie die "AusweisApp2", die sich mit privilegierten Rechten installiert. Theoretisch könnte auch so eine neue RootCA addiert werden. In anderen Ländern schreiben Verwaltungen wohl die Installation staatlicher Programme für bestimmte Amtsvorgänge vor. Da sollte man als Security-Beauftragter doch genau hinschauen, ob solche Clients dann noch "trusted" sind.

CA Einschränkungen

Nun lesen wir ja bei Aldi Nord und der Bundesanstalt, dass es hier ja eigentlich nur um verschlüsselte E-Mails (SMIME) geht und die anderen Seite gar kein Interesse daran haben sollte, z.B. ein Zertifikat für www.elster.com oder www.<ihrebank>.de auszustellen. Bei der IssuingCA kann dies über entsprechende Templates sogar in Grenzen gesteuert werden. Wir machen das z.B. auch bei Firmen, wenn es eine "offline RootCA" gibt, die dann zwei Issuing-CAs signiert. CA1 stellt nur Computer- und Webserver-Zertifikate aus. Die können eine kurze Laufzeit haben und schnell zurückgezogen werden. Vor allem brauchen wir keinen private Key zu "sichern". Die zweite CA hingegen stellt dann Zertifikate aus, deren privater Key über einen Key Recovery Agent gesichert wird. Wäre doch blöde, wenn der Anwender seinen PC samt Zertifikat verliert und damit keinen Zugriff auf seine früheren Mails erhält.

Leider funktioniert diese Einschränkung nicht auf die RootCA. Der Betreiber kann also nach belieben neue IssuingCAs aufbauen, die dann auch Webserver-Zertifikate ausstellen kann. Die RootCA ist ja gerade der Anker, der einen kompromittierte IssuingCA über seine CRL als ungültig kennzeichnen kann.

Bei den PartnerCAs ist aber das Problem, dass ja auch die RootCA vermutlich einfacher kompromittiert werden kann oder sie gar nicht mitbekommen, wenn der Partner nicht konforme Zertifikate ausstellt und vielleicht über eine eigene Partner-Software auch noch auf ihrem PC installiert.

Sie können aber nun sagen, dass sie nicht der RootCA vertrauen und stattdessen nur der IssuingCA. Die von der IssuingCA ausgestellten Zertifikate könnten ja auf "SMIME" beschränkt sein und sie könnten die IssuingCA durch ihre eigene RootCA Cross-zertifizieren. Damit sind sie relativ sicher, dass von dieser IssuingCA keine Zertifikate für andere Dienste untergeschoben werden. Da sie aber nicht der originären RootCA vertrauen, vertrauen Sie auch nicht deren CRL. Sie bekommen also nicht mit, wenn die RootCA die IssuingCA zurückziehen möchte

Einschätzung

Im Grunde spricht ja nichts dagegen, dass Sie eine eigene interne RootCA (Die Zertifikatsstelle in der eigenen Firma) aufbauen, und diese bei ihren eigenen Clients auch als vertrauenswürdig addieren. Die Chancen und Risiken müssen Sie hier dann selbst abwägen aber sie gefährden erst einmal niemand sonst. Wenn Sie als Firma aber mit Zertifikaten dieser privaten PKI auf ihre Partner, Lieferanten u.a. losgehen, dann haben Sie das Prinzip einer PKI entweder nicht verstanden, oder möchten aus eigener Bequemlichkeit und Kostenüberlegungen sich das Leben einfach machen und nehmen damit in Kauf, dass ihre Partner "unsicherer" sind.

Ich kann nur hoffen, dass ihre Partner sich hier nicht überrumpeln lassen und einfach gehorsam ihr RootCA als Trusted installieren. Aus meiner Sicht ist es eine Frechheit, so etwas überhaupt zu fordern und die Tragweite der Änderung hinsichtlich Risiken zu verschweigen. Das ist keine Kommunikation auf Augenhöhe.

Sollte mich mal eine Firma auffordern, ein RootCA zu installieren, dann lasse ich mir zusichern, dass Sie auch mein RootCA installiert oder sie uneingeschränkt haftbar für Missbrauch ihrer RootCA sind. Vermutlich werde ich aber einfach auf eine Zusammenarbeit verzichten.

Ein Vertrauen für diese RootCAs

Ich bin mal gespannt, ob ich irgendwann eine Mail bekomme und prüfen kann, ob die PKI vielleicht die "Name Contraint"-Funktion implementiert hat.

Dann könnte das Ausstellen von Zertifikaten weiter eingeschränkt werden.

Weitere Links