Zertifizierungsstelle - Certificate authority

In der Kryptographie ist eine Zertifizierungsstelle oder Zertifizierungsstelle ( CA ) eine Instanz, die digitale Zertifikate ausstellt . Ein digitales Zertifikat bescheinigt dem benannten Subjekt des Zertifikats den Besitz eines öffentlichen Schlüssels. Dies ermöglicht es anderen (vertrauenden Parteien), sich auf Signaturen oder auf Aussagen über den privaten Schlüssel zu verlassen, der dem zertifizierten öffentlichen Schlüssel entspricht. Eine Zertifizierungsstelle fungiert als vertrauenswürdiger Dritter – sowohl vom Antragsteller (Eigentümer) des Zertifikats als auch von der Partei, die sich auf das Zertifikat verlässt. Das Format dieser Zertifikate wird durch den X.509- oder EMV- Standard vorgegeben .

Eine besonders häufige Verwendung für Zertifizierungsstellen ist das Signieren von Zertifikaten, die in HTTPS verwendet werden , dem sicheren Browserprotokoll für das World Wide Web. Eine weitere übliche Verwendung ist die Ausgabe von Personalausweisen durch nationale Regierungen zur Verwendung beim elektronischen Unterschreiben von Dokumenten.

Überblick

Vertrauenswürdige Zertifikate können verwendet werden, um sichere Verbindungen zu einem Server über das Internet herzustellen . Ein Zertifikat ist unerlässlich, um eine böswillige Partei zu umgehen, die sich zufällig auf dem Weg zu einem Zielserver befindet, der sich so verhält, als wäre er das Ziel. Ein solches Szenario wird allgemein als Man-in-the-Middle-Angriff bezeichnet . Der Client verwendet das CA-Zertifikat, um die CA-Signatur auf dem Serverzertifikat als Teil der Autorisierungen zu authentifizieren, bevor eine sichere Verbindung hergestellt wird. Normalerweise enthält Client-Software – beispielsweise Browser – einen Satz vertrauenswürdiger CA-Zertifikate. Dies ist sinnvoll, da viele Benutzer ihrer Client-Software vertrauen müssen. Ein bösartiger oder kompromittierter Client kann jede Sicherheitsüberprüfung überspringen und seine Benutzer dennoch täuschen, etwas anderes zu glauben.

Die Clients einer CA sind Server-Supervisor, die ein Zertifikat anfordern, das ihre Server den Benutzern aushändigen. Kommerzielle CAs verlangen Geld für die Ausstellung von Zertifikaten, und ihre Kunden erwarten, dass das Zertifikat der CA in den meisten Webbrowsern enthalten ist, sodass sichere Verbindungen zu den zertifizierten Servern sofort effizient funktionieren. Die Menge an Internetbrowsern, anderen Geräten und Anwendungen, die einer bestimmten Zertifizierungsstelle vertrauen, wird als Ubiquität bezeichnet. Mozilla , ein gemeinnütziges Unternehmen, stellt mit seinen Produkten mehrere kommerzielle CA-Zertifikate aus. Während Mozilla eine eigene Richtlinie entwickelt hat, hat das CA/Browser Forum ähnliche Richtlinien für CA-Vertrauen entwickelt. Ein einzelnes CA-Zertifikat kann von mehreren CAs oder deren Wiederverkäufern gemeinsam genutzt werden . Ein Root- CA-Zertifikat kann die Grundlage für die Ausstellung mehrerer CA- Zwischenzertifikate mit unterschiedlichen Validierungsanforderungen sein.

Neben kommerziellen Zertifizierungsstellen stellen einige gemeinnützige Organisationen kostenlos öffentlich vertrauenswürdige digitale Zertifikate aus, zum Beispiel Let's Encrypt . Einige große Cloud-Computing- und Webhosting-Unternehmen sind auch öffentlich vertrauenswürdige Zertifizierungsstellen und stellen Zertifikate für Dienste aus, die auf ihrer Infrastruktur gehostet werden, beispielsweise Amazon Web Services , Cloudflare und Google Cloud Platform .

Große Organisationen oder staatliche Stellen können ihre eigenen PKIs ( Public Key Infrastructure ) haben, die jeweils ihre eigenen CAs enthalten. Jede Site, die selbstsignierte Zertifikate verwendet, fungiert als ihre eigene CA.

Geschäftsbanken, die EMV- Zahlungskarten ausgeben , unterliegen der EMV-Zertifizierungsstelle, Zahlungssystemen, die an Point-of-Sale-Terminals ( POS ) initiierte Zahlungstransaktionen an eine kartenausgebende Bank weiterleiten, um die Gelder vom Bankkonto des Karteninhabers an die Bank des Zahlungsempfängers zu überweisen Konto. Jede Zahlungskarte legt neben ihren Kartendaten auch das Card Issuer Certificate am POS vor. Das Ausstellerzertifikat ist mit dem EMV CA-Zertifikat signiert. Der POS ruft den öffentlichen Schlüssel von EMV CA aus seinem Speicher ab, validiert das Ausstellerzertifikat und die Echtheit der Zahlungskarte, bevor die Zahlungsanforderung an das Zahlungssystem gesendet wird.

Browser und andere Clients ermöglichen es Benutzern charakteristischerweise, CA-Zertifikate nach Belieben hinzuzufügen oder zu entfernen. Während Serverzertifikate regelmäßig für einen relativ kurzen Zeitraum gültig sind, werden CA-Zertifikate weiter verlängert, sodass es bei wiederholt besuchten Servern weniger fehleranfällig ist, der ausgestellten CA zu vertrauen und eine Sicherheitsausnahme bei jeder Erneuerung des Serverzertifikats zu bestätigen .

Seltener werden vertrauenswürdige Zertifikate zum Verschlüsseln oder Signieren von Nachrichten verwendet. CAs geben auch Endbenutzerzertifikate aus, die mit S/MIME verwendet werden können . Die Verschlüsselung erfordert jedoch den öffentlichen Schlüssel des Empfängers, und da sich Autoren und Empfänger verschlüsselter Nachrichten anscheinend gegenseitig kennen, bleibt die Nützlichkeit eines vertrauenswürdigen Dritten auf die Signaturprüfung von Nachrichten beschränkt, die an öffentliche Mailinglisten gesendet werden.

Anbieter

Das Geschäft mit Zertifizierungsstellen ist weltweit fragmentiert, wobei nationale oder regionale Anbieter ihren Heimatmarkt dominieren. Dies liegt daran, dass viele Verwendungen digitaler Zertifikate, beispielsweise für rechtsverbindliche digitale Signaturen, mit lokalen Gesetzen, Vorschriften und Akkreditierungssystemen für Zertifizierungsstellen verknüpft sind.

Der Markt für weltweit vertrauenswürdige TLS/SSL-Serverzertifikate wird jedoch größtenteils von einer kleinen Anzahl multinationaler Unternehmen gehalten. Dieser Markt weist aufgrund der technischen Anforderungen erhebliche Eintrittsbarrieren auf. Obwohl dies gesetzlich nicht vorgeschrieben ist, können sich neue Anbieter dafür entscheiden, sich jährlichen Sicherheitsaudits zu unterziehen (wie WebTrust für Zertifizierungsstellen in Nordamerika und ETSI in Europa), um von einem Webbrowser oder Betriebssystem als vertrauenswürdiger Stamm aufgenommen zu werden.

Am 24. August 2020 vertrauen 147 Stammzertifikate, die 52 Organisationen repräsentieren, im Mozilla Firefox -Webbrowser, 168 Stammzertifikate, die 60 Organisationen repräsentieren, werden von macOS vertrauenswürdig und 255 Stammzertifikate, die 101 Organisationen repräsentieren, werden von Microsoft Windows vertraut . Ab Android 4.2 (Jelly Bean) enthält Android derzeit über 100 CAs, die mit jeder Version aktualisiert werden.

Am 18. November 2014 kündigte eine Gruppe von Unternehmen und gemeinnützigen Organisationen, darunter die Electronic Frontier Foundation, Mozilla, Cisco und Akamai, Let's Encrypt an , eine gemeinnützige Zertifizierungsstelle, die kostenlose domänenvalidierte X.509-Zertifikate sowie Software zur Aktivierung bereitstellt Installation und Pflege von Zertifikaten. Let's Encrypt wird von der neu gegründeten Internet Security Research Group betrieben , einer kalifornischen gemeinnützigen Organisation, die als steuerbefreit anerkannt ist.

Laut Netcraft im Mai 2015, dem Industriestandard für die Überwachung aktiver TLS-Zertifikate, „obwohl das globale [TLS]-Ökosystem wettbewerbsfähig ist, wird es von einer Handvoll großer Zertifizierungsstellen dominiert – drei Zertifizierungsstellen (Symantec, Comodo, GoDaddy) machen drei aus -Viertel aller ausgestellten [TLS]-Zertifikate auf öffentlich zugänglichen Webservern. Der Spitzenplatz wird seit Beginn [unserer] Umfrage von Symantec (oder VeriSign, bevor es von Symantec gekauft wurde) gehalten, mit derzeit knapp einem Drittel aller Zertifikate. Um die Wirkung unterschiedlicher Methoden zu veranschaulichen, hat Symantec unter den Millionen verkehrsreichsten Sites 44 % der gültigen, vertrauenswürdigen Zertifikate ausgestellt – deutlich mehr als sein Gesamtmarktanteil.

Eine aktualisierte W3Techs-Umfrage zeigt, dass IdenTrust , ein Cross-Signer von Let's Encrypt- Zwischenprodukten, die beliebteste SSL-Zertifizierungsstelle geblieben ist, während Symantec aufgrund der Übernahme seiner Sicherheitsdienste durch DigiCert aus der Liste herausgefallen ist . Sectigo (ehemals Comodo CA) ist mit 16,8% des Marktes die drittgrößte SSL-Zertifizierungsstelle: Digicert unterhält die Marken GeoTrust , Digicert , Thawte und RapidSSL.

Rang Aussteller Verwendungszweck Marktanteil
1 IdentTrust 45,0% 52,7%
2 DigiCert 16,5% 19,3%
3 Sectigo 14,3% 16,8%
4 Los Papa 5,5% 6,4%
5 GlobalSign 2,2 % 2,6%
6 Lass uns verschlüsseln 1,6 % 1,8 %
7 Certum 0,4% 0,5%
8 Secom 0,2% 0,2%
9 Anvertrauen 0,2% 0,2%
10 Aktalis 0,1% 0,1%
11 E-Tugra 0,1% 0,1%
12 WISeKey-Gruppe < 0,1 % 0,1%
13 Deutsche Telekom < 0,1 % 0,1%
14 Netzwerklösungen < 0,1 % 0,1%

Validierungsstandards

Die kommerziellen CAs, die den Großteil der Zertifikate für HTTPS-Server ausstellen, verwenden normalerweise eine Technik namens " Domänenvalidierung ", um den Empfänger des Zertifikats zu authentifizieren. Die für die Domänenvalidierung verwendeten Techniken variieren zwischen den Zertifizierungsstellen, aber im Allgemeinen sollen Domänenvalidierungstechniken beweisen, dass der Zertifikatsantragsteller einen bestimmten Domänennamen kontrolliert , und keine Informationen über die Identität des Antragstellers.

Viele Zertifizierungsstellen bieten auch Extended Validation (EV)-Zertifikate als strengere Alternative zu domänenvalidierten Zertifikaten an. Die erweiterte Validierung soll nicht nur die Kontrolle eines Domänennamens überprüfen, sondern auch zusätzliche Identitätsinformationen, die in das Zertifikat aufgenommen werden sollen. Einige Browser zeigen diese zusätzlichen Identitätsinformationen in einem grünen Feld in der URL-Leiste an. Eine Einschränkung von EV als Lösung für die Schwächen der Domänenvalidierung besteht darin, dass Angreifer immer noch ein domänenvalidiertes Zertifikat für die Opferdomäne erhalten und es während eines Angriffs bereitstellen können. in diesem Fall wäre der für den Opferbenutzer wahrnehmbare Unterschied das Fehlen eines grünen Balkens mit dem Firmennamen. Es ist fraglich, ob Benutzer dieses Fehlen wahrscheinlich als Hinweis auf einen laufenden Angriff erkennen würden: Ein Test mit Internet Explorer 7 im Jahr 2009 zeigte, dass das Fehlen der EV-Warnungen des IE7 von den Benutzern nicht bemerkt wurde, jedoch mit dem aktuellen Browser von Microsoft , Edge , zeigt einen deutlich größeren Unterschied zwischen EV- und domänenvalidierten Zertifikaten, wobei domänenvalidierte Zertifikate ein hohles graues Schloss haben.

Validierungsschwächen

Die Domänenvalidierung leidet unter bestimmten strukturellen Sicherheitsbeschränkungen. Insbesondere ist es immer anfällig für Angriffe, die es einem Angreifer ermöglichen, die von CAs gesendeten Domänenvalidierungstests zu beobachten. Dazu können Angriffe gegen die Protokolle DNS, TCP oder BGP (denen die kryptografischen Schutzmaßnahmen von TLS/SSL fehlen) oder die Kompromittierung von Routern gehören. Solche Angriffe sind entweder im Netzwerk in der Nähe einer Zertifizierungsstelle oder in der Nähe der Opferdomäne selbst möglich.

Eine der gebräuchlichsten Techniken zur Domänenvalidierung besteht darin, eine E-Mail mit einem Authentifizierungstoken oder einem Link an eine E-Mail-Adresse zu senden, die wahrscheinlich administrativ für die Domäne verantwortlich ist. Dies könnte die technische Kontakt E - Mail - Adresse in der der Domäne aufgelistet seine WHOIS - Eintrag oder eine administrative E - Mail wie admin @ , administrator @ , webmaster @ , Hauptleitstation @ oder Postmeister @ die Domäne. Einige Zertifizierungsstellen akzeptieren möglicherweise eine Bestätigung mit root@ , info@ oder support@ in der Domäne. Die Theorie hinter der Domänenvalidierung ist, dass nur der rechtmäßige Besitzer einer Domäne E-Mails lesen kann, die an diese administrativen Adressen gesendet werden.

Implementierungen der Domänenvalidierung waren manchmal eine Quelle von Sicherheitslücken. In einem Fall zeigten Sicherheitsforscher, dass Angreifer Zertifikate für Webmail-Sites erhalten konnten, weil eine CA bereit war, eine E-Mail-Adresse wie ssladmin@domain.com für domain.com zu verwenden, aber nicht alle Webmail-Systeme hatten den Benutzernamen "ssladmin" reserviert, um dies zu verhindern Angreifer daran, es zu registrieren.

Vor 2011 gab es keine Standardliste von E-Mail-Adressen, die für die Domänenvalidierung verwendet werden konnten, sodass E-Mail-Administratoren nicht klar waren, welche Adressen reserviert werden mussten. Die erste Version der CA/Browser Forum Baseline Requirements, die im November 2011 angenommen wurde, enthielt eine Liste solcher Adressen. Dies ermöglichte es Mail-Hosts, diese Adressen für administrative Zwecke zu reservieren, obwohl solche Vorsichtsmaßnahmen immer noch nicht universell sind. Im Januar 2015 registrierte ein Finne den Benutzernamen "hostmaster" bei der finnischen Version von Microsoft Live und konnte ein domänenvalidiertes Zertifikat für live.fi erhalten, obwohl er nicht der Besitzer des Domänennamens war.

Ausstellung eines Zertifikats

Das Verfahren zum Erhalten eines Public-Key-Zertifikats

Eine CA stellt digitale Zertifikate aus , die einen öffentlichen Schlüssel und die Identität des Besitzers enthalten. Der passende private Schlüssel wird nicht öffentlich zugänglich gemacht, sondern vom Endbenutzer, der das Schlüsselpaar generiert hat, geheim gehalten. Das Zertifikat ist auch eine Bestätigung oder Validierung durch die CA, dass der im Zertifikat enthaltene öffentliche Schlüssel zu der im Zertifikat angegebenen Person, Organisation, Server oder anderen Instanz gehört. Die Verpflichtung einer CA in solchen Schemata besteht darin, die Anmeldeinformationen eines Antragstellers zu überprüfen, damit Benutzer und vertrauende Parteien den Informationen in den Zertifikaten der CA vertrauen können. CAs verwenden dazu eine Vielzahl von Standards und Tests. Im Wesentlichen ist die Zertifizierungsstelle dafür verantwortlich, zu sagen: "Ja, diese Person ist die, die sie vorgibt, und wir, die CA, bestätigen dies".

Wenn der Benutzer der CA vertraut und die Signatur der CA verifizieren kann, kann er auch davon ausgehen, dass ein bestimmter öffentlicher Schlüssel tatsächlich dem im Zertifikat angegebenen Namen gehört.

Beispiel

Kryptografie mit öffentlichem Schlüssel kann verwendet werden, um Daten zu verschlüsseln, die zwischen zwei Parteien übertragen werden. Dies kann normalerweise passieren, wenn sich ein Benutzer bei einer Site anmeldet, die das HTTP Secure- Protokoll implementiert . Nehmen wir in diesem Beispiel an, dass sich der Benutzer auf der Homepage seiner Bank www.bank.example anmeldet, um Online-Banking zu tätigen. Wenn der Benutzer die Homepage www.bank.example öffnet, erhält er einen öffentlichen Schlüssel zusammen mit allen Daten, die sein Webbrowser anzeigt. Der öffentliche Schlüssel könnte verwendet werden, um Daten vom Client zum Server zu verschlüsseln, aber das sichere Verfahren besteht darin, ihn in einem Protokoll zu verwenden, das einen temporären gemeinsam genutzten symmetrischen Verschlüsselungsschlüssel bestimmt; Nachrichten in einem solchen Schlüsselaustauschprotokoll können mit dem öffentlichen Schlüssel der Bank so verschlüsselt werden, dass nur der Bankserver über den privaten Schlüssel verfügt, um sie zu lesen.

Der Rest der Kommunikation wird dann mit dem neuen (wegwerfbaren) symmetrischen Schlüssel fortgesetzt. Wenn der Benutzer also einige Informationen auf der Seite der Bank eingibt und die Seite sendet (sendet die Informationen an die Bank zurück), dann die Daten, die der Benutzer auf der Seite eingegeben hat werden von ihrem Webbrowser verschlüsselt. Selbst wenn also jemand auf die (verschlüsselten) Daten zugreifen kann, die vom Nutzer an www.bank.example übermittelt wurden, kann ein solcher Lauscher diese nicht lesen oder entziffern.

Dieser Mechanismus ist nur dann sicher, wenn der Benutzer sicher sein kann, dass es sich um die Bank handelt, die er in seinem Webbrowser sieht. Wenn der Benutzer www.bank.example eingibt, aber seine Kommunikation gehackt wird und eine gefälschte Website (die vorgibt, die Website der Bank zu sein) die Seiteninformationen an den Browser des Benutzers zurücksendet, kann die gefälschte Webseite einen gefälschten öffentlichen Schlüssel senden an den Benutzer (für den die gefälschte Seite einen passenden privaten Schlüssel besitzt). Der Benutzer füllt das Formular mit seinen persönlichen Daten aus und sendet die Seite. Die gefälschte Webseite erhält dann Zugriff auf die Daten des Benutzers.

Dies soll der Mechanismus der Zertifizierungsstelle verhindern. Eine Zertifizierungsstelle (CA) ist eine Organisation, die öffentliche Schlüssel und deren Besitzer speichert, und jede Partei in einer Kommunikation vertraut dieser Organisation (und kennt ihren öffentlichen Schlüssel). Wenn der Webbrowser des Benutzers den öffentlichen Schlüssel von www.bank.example erhält, erhält er auch eine digitale Signatur des Schlüssels (mit einigen weiteren Informationen in einem sogenannten X.509- Zertifikat). Der Browser besitzt bereits den öffentlichen Schlüssel der CA und kann somit die Signatur verifizieren, dem Zertifikat und dem darin enthaltenen öffentlichen Schlüssel vertrauen: Da www.bank.example einen öffentlichen Schlüssel verwendet, den die Zertifizierungsstelle zertifiziert, ist ein gefälschtes www.bank.example kann nur denselben öffentlichen Schlüssel verwenden. Da das gefälschte www.bank.example den dazugehörigen privaten Schlüssel nicht kennt, kann es die zur Echtheitsprüfung notwendige Signatur nicht erstellen.

Sicherheit

Es ist schwierig, die Richtigkeit der Übereinstimmung zwischen Daten und Entität sicherzustellen, wenn die Daten der CA (vielleicht über ein elektronisches Netzwerk) vorgelegt werden und wenn die Berechtigungsnachweise der Person/Firma/Programms, die ein Zertifikat anfordern, ebenfalls vorgelegt werden. Aus diesem Grund verwenden kommerzielle Zertifizierungsstellen häufig eine Kombination von Authentifizierungstechniken, einschließlich der Nutzung von Regierungsbüros, der Zahlungsinfrastruktur, Datenbanken und Diensten Dritter sowie benutzerdefinierter Heuristiken. In einigen Unternehmenssystemen können lokale Authentifizierungsformen wie Kerberos verwendet werden, um ein Zertifikat zu erhalten, das wiederum von externen vertrauenden Parteien verwendet werden kann. Notare müssen in einigen Fällen die Partei, deren Unterschrift beurkundet wird, persönlich kennen; Dies ist ein höherer Standard, als von vielen Zertifizierungsstellen erreicht wird. Laut dem Entwurf der American Bar Association zum Online-Transaktionsmanagement bestanden die wichtigsten Punkte der US-Bundes- und Landesgesetze in Bezug auf digitale Signaturen darin, "widersprüchliche und übermäßig belastende lokale Vorschriften zu verhindern und sicherzustellen, dass elektronische Schriften die traditionellen Anforderungen erfüllen, die mit Papierdokumenten verbunden sind. " Darüber hinaus tragen das US-E-Sign-Statut und der vorgeschlagene UETA-Code dazu bei, Folgendes sicherzustellen:

  1. einer Unterschrift, einem Vertrag oder einer anderen Aufzeichnung in Bezug auf eine solche Transaktion darf die Rechtswirksamkeit, Gültigkeit oder Durchsetzbarkeit nicht allein deshalb verweigert werden, weil sie in elektronischer Form vorliegt; und
  2. einem Vertrag in Bezug auf eine solche Transaktion darf die Rechtswirksamkeit, Gültigkeit oder Durchsetzbarkeit nicht allein deshalb verweigert werden, weil bei seiner Bildung eine elektronische Signatur oder ein elektronischer Datensatz verwendet wurde.

Trotz der Sicherheitsmaßnahmen zur korrekten Überprüfung der Identität von Personen und Unternehmen besteht die Gefahr, dass eine einzelne CA einem Betrüger ein gefälschtes Zertifikat ausstellt. Es ist auch möglich, Personen und Unternehmen mit gleichen oder sehr ähnlichen Namen zu registrieren, was zu Verwechslungen führen kann. Um diese Gefahr zu minimieren, schlägt die Initiative zur Zertifikattransparenz vor, alle Zertifikate in einem öffentlichen, fälschungssicheren Protokoll zu prüfen, was zur Verhinderung von Phishing beitragen könnte .

In groß angelegten Bereitstellungen ist Alice möglicherweise nicht mit Bobs Zertifizierungsstelle vertraut (vielleicht hat jeder einen anderen CA-Server), sodass Bobs Zertifikat auch den öffentlichen Schlüssel seiner CA enthält, der von einer anderen CA 2 signiert wurde , die vermutlich von Alice erkannt wird. Dieser Prozess führt normalerweise zu einer Hierarchie oder einem Netz von CAs und CA-Zertifikaten.

Berechtigungs-Widerrufslisten

Eine Autoritätssperrliste (ARL) ist eine Form einer Zertifikatsperrliste (CRL), die Zertifikate enthält, die an Zertifizierungsstellen ausgestellt wurden, im Gegensatz zu CRLs, die gesperrte End-Entity-Zertifikate enthalten.

Branchenorganisationen

  • Certificate Authority Security Council (CASC) – Im Februar 2013 wurde das CASC als eine Interessenvertretung der Industrie gegründet, die sich der Behandlung von Branchenfragen und der Aufklärung der Öffentlichkeit über Internetsicherheit widmet. Gründungsmitglieder sind die sieben größten Zertifizierungsstellen.
  • Common Computing Security Standards Forum (CCSF) – Im Jahr 2009 wurde das CCSF gegründet, um Industriestandards zum Schutz der Endbenutzer zu fördern. Der CEO der Comodo Group, Melih Abdulhayoğlu, gilt als Gründer der CCSF.
  • CA/Browser Forum – Im Jahr 2005 wurde ein neues Konsortium von Zertifizierungsstellen und Anbietern von Webbrowsern gegründet, um Industriestandards und grundlegende Anforderungen an die Internetsicherheit zu fördern. Der CEO der Comodo Group, Melih Abdulhayoğlu, organisierte das erste Treffen und gilt als Gründer des CA/Browser Forums.

Grundanforderungen

Das CA/Browser Forum veröffentlicht die Baseline Requirements, eine Liste von Richtlinien und technischen Anforderungen, die von CAs befolgt werden müssen. Diese sind Voraussetzung für die Aufnahme in die Zertifikatsspeicher von Firefox und Safari.

CA-Kompromiss

Wenn die CA untergraben werden kann, geht die Sicherheit des gesamten Systems verloren, wodurch möglicherweise alle Entitäten untergraben werden, die der kompromittierten CA vertrauen.

Angenommen, ein Angreifer, Eve, schafft es, eine CA dazu zu bringen, ihr ein Zertifikat auszustellen, das behauptet, Alice zu repräsentieren. Das heißt, das Zertifikat würde öffentlich angeben, dass es Alice repräsentiert, und könnte andere Informationen über Alice enthalten. Einige der Informationen über Alice, z. B. der Name ihres Arbeitgebers, können wahr sein, was die Glaubwürdigkeit des Zertifikats erhöht. Eve hätte jedoch den wichtigen privaten Schlüssel, der mit dem Zertifikat verbunden ist. Eve könnte dann das Zertifikat verwenden, um eine digital signierte E-Mail an Bob zu senden, was Bob glauben lässt, dass die E-Mail von Alice stammt. Bob könnte sogar mit verschlüsselten E-Mails antworten, weil er glaubt, dass sie nur von Alice gelesen werden könnten, wenn Eve sie tatsächlich mit dem privaten Schlüssel entschlüsseln kann.

Ein bemerkenswerter Fall von CA-Subversion wie dieser ereignete sich im Jahr 2001, als die Zertifizierungsstelle VeriSign einer Person, die behauptete, Microsoft zu vertreten, zwei Zertifikate ausstellte. Die Zertifikate tragen den Namen "Microsoft Corporation", so dass mit ihnen jemand vortäuscht, dass Updates für Microsoft-Software von Microsoft stammen, obwohl dies in Wirklichkeit nicht der Fall ist. Der Betrug wurde Anfang 2001 aufgedeckt. Microsoft und VeriSign haben Schritte unternommen, um die Auswirkungen des Problems zu begrenzen.

Im Jahr 2011 wurden betrügerische Zertifikate von Comodo und DigiNotar erhalten , angeblich von iranischen Hackern. Es gibt Hinweise darauf, dass die betrügerischen DigiNotar-Zertifikate bei einem Man-in-the-Middle-Angriff im Iran verwendet wurden.

Im Jahr 2012 wurde bekannt, dass Trustwave ein untergeordnetes Stammzertifikat ausgestellt hat, das für ein transparentes Verkehrsmanagement (Man-in-the-Middle) verwendet wurde, das es einem Unternehmen effektiv ermöglichte, SSL-internen Netzwerkverkehr mit dem untergeordneten Zertifikat zu schnüffeln.

Schlüsselaufbewahrung

Ein Angreifer, der die privaten Schlüssel einer Zertifizierungsstelle stiehlt, kann Zertifikate fälschen, als ob es sich um eine Zertifizierungsstelle handelte, ohne ständigen Zugriff auf die Systeme der Zertifizierungsstelle zu benötigen. Schlüsseldiebstahl ist daher eines der Hauptrisiken, gegen das Zertifizierungsstellen sich verteidigen. Öffentlich vertrauenswürdige CAs speichern ihre Schlüssel fast immer auf einem Hardware-Sicherheitsmodul (HSM), das es ihnen ermöglicht, Zertifikate mit einem Schlüssel zu signieren, aber im Allgemeinen die Extraktion dieses Schlüssels sowohl mit physischen als auch mit Softwarekontrollen verhindern. CAs treffen in der Regel die weitere Vorsichtsmaßnahme, indem sie den Schlüssel für ihre langfristigen Stammzertifikate in einem offline gehaltenen HSM aufbewahren , es sei denn, er ist zum Signieren von kürzerlebigen Zwischenzertifikaten erforderlich. Die Zwischenzertifikate, die in einem Online-HSM gespeichert sind, können die tägliche Arbeit des Signierens von End-Entity-Zertifikaten und die Aktualisierung der Sperrinformationen übernehmen.

CAs verwenden bei der Generierung von Signaturschlüsseln manchmal eine Schlüsselzeremonie , um sicherzustellen, dass die Schlüssel nicht manipuliert oder kopiert werden.

Implementierungsschwäche des vertrauenswürdigen Drittsystems

Die kritische Schwachstelle bei der Implementierung des aktuellen X.509-Schemas besteht darin, dass jede CA, der eine bestimmte Partei vertraut, Zertifikate für jede beliebige Domäne ausstellen kann. Solche Zertifikate werden von der vertrauenden Partei als gültig akzeptiert, unabhängig davon, ob sie legitim und autorisiert sind oder nicht. Dies ist ein schwerwiegender Mangel, da die am häufigsten anzutreffende Technologie, die X.509 und vertrauenswürdige Drittanbieter verwendet, das HTTPS-Protokoll ist. Da alle großen Webbrowser an ihre Endbenutzer vorkonfiguriert mit einer Liste vertrauenswürdiger CAs verteilt werden, die Dutzende umfasst, bedeutet dies, dass jede dieser vorab genehmigten vertrauenswürdigen CAs ein gültiges Zertifikat für jede beliebige Domäne ausstellen kann. Die Reaktion der Branche darauf ist gedämpft. Da der Inhalt der vorkonfigurierten Liste der vertrauenswürdigen Zertifizierungsstellen eines Browsers unabhängig von der Partei bestimmt wird, die die Browseranwendung verteilt oder deren Installation veranlasst, gibt es wirklich nichts, was die Zertifizierungsstellen selbst tun können.

Dieses Thema ist der treibende Antrieb für die Entwicklung des DNS-basierten Authentication of Named Entities (DANE)-Protokolls. In Verbindung mit Domain Name System Security Extensions (DNSSEC) wird DANE die Rolle vertrauenswürdiger Dritter in der PKI einer Domäne stark reduzieren, wenn nicht sogar ganz eliminieren.

Siehe auch

Verweise

Externe Links