it-swarm-eu.dev

Vorteile von Client-Zertifikaten für die Client-Authentifizierung?

Ich bin kein Sicherheitsexperte. Bitte fragen Sie einfach in einem Kommentar, ob ich meine Frage nicht klar genug für eine Antwort gestellt habe.

Das Szenario

Wir haben einen Server, auf dem WCF-Dienste ausgeführt werden, und eine Reihe von Clients, die eine Verbindung herstellen. Diese Clients sind eigentlich Linux-PCs, die wir bauen. Wir müssen eine sichere Kommunikation zwischen unserem Server und unseren Kunden herstellen (wir bauen sie erneut auf und stellen sie an Kundenstandorten bereit).

Client vertraut dem Server

Wir werden dies implementieren, indem wir dem Client ermöglichen, eine vertrauenswürdige Verbindung mit dem Server über die Implementierung der SSL-Kommunikation herzustellen.

Server vertraut dem Client

Wir haben jetzt die Aufgabe, den Client zu authentifizieren. Dies geschieht natürlich, indem auf dem Client Anmeldeinformationen gespeichert werden. Sobald der Client verbunden ist, kann er die Anmeldeinformationen an den Server senden und der Server kann sie überprüfen.

Eine Option für diese Anmeldeinformationen besteht darin, eine Art Guid oder eine andere ID/ein anderes Kennwort zu speichern, die von der WCF-basierten Anwendung generiert wird. Nach Erhalt der Anmeldeinformationen führt der WCF-Dienst eine Suche in der Datenbank durch und überprüft, ob diese korrekt sind.

Eine andere Möglichkeit besteht darin, mithilfe der Zertifikatdienste Clientzertifikate zu erstellen, die vor dem Versenden auf den Client-PC kopiert werden. Nach dem Herstellen der sicheren Verbindung sendet der Client das Zertifikat an den Server, der das Zertifikat mit Certificate Services authentifiziert.

Die Fragen

Welche Vorteile hat die Verwendung eines Zertifikats zur Authentifizierung des Clients gegenüber einem Benutzernamen/einer Guid? Welche Nachteile hat es?

Beachten Sie bitte:

  • Sicherheit
  • Komplexität der Implementierung
  • Komplexität der Programmierung Integration in die Anwendung. Dies umfasst den Workflow zum Erstellen des Authentifizierungstokens, zum Zuordnen geeigneter Metadaten (Autorisierung/Zuordnung), zum Verwalten der Authentifizierung, z. B. zum Deaktivieren des Zugriffs usw.
34
Shaun Rowan

Das Bereitstellen von Client-Zertifikaten könnte hier passen. Die Vorteile der Verwendung eines Zertifikats gegenüber dem Benutzernamen sind recht einfach. Jeder kann von jedem Clientgerät aus einen Benutzernamen eingeben. Wenn Sie eine Kombination aus Benutzername und Guid verwenden, hängt die "Sicherheit" oder Zusicherung, dass der Client eine Verbindung von einem bekannten/autorisierten Clientgerät herstellt, von der Stärke und Eindeutigkeit der Guid ab. Wenn es eine Möglichkeit gibt, die Guid zu klonen oder zu fälschen (Mac-Adressen können ziemlich leicht gefälscht werden), würde sich die Sicherheitsstufe verringern.

Client-Zertifikate können mit oder ohne Gültigkeitsprüfung für Clients bereitgestellt werden (abgesehen von Gültigkeitsdatum, CN, Ski/Aki, Fingerabdruck usw.). On-Demand-Gültigkeitsprüfungsmechanismen wie ocsp erfordern, dass die Serveranwendung jedes Mal, wenn der Client eine Verbindung herstellt/versucht, eine Authentifizierung durchzuführen, mit einem ocsp-Server überprüft wird. In der Beschreibung habe ich jedoch nicht gelesen, dass die Gültigkeitsprüfung genauso wichtig ist wie die Bindung eines Zertifikats an das Clientgerät.

Ein wichtiges Detail bei Client-Zertifikaten (Zertifikate im Allgemeinen) ist, dass es exportiert werden kann und die meisten Implementierungen die Portabilität des Zertifikats nicht blockieren. Unabhängig davon, ob oder wie die Client-Zertifikate ohne geeignete Maßnahmen gespeichert werden sollen, kann das Zertifikat problemlos von Gerät zu Gerät kopiert werden. Einige Implementierungen speichern das Zertifikat im Dateisystem (Dateien, die mit .cer, .der, .key, .crt enden, sind normalerweise Hinweise darauf, dass Zertifikate im Dateisystem gespeichert sind). Stärkere Implementierungen (anwendungsabhängig) können die Zertifikate und Schlüssel in einem Schlüsselspeicher speichern (dh Java Schlüsselspeicher). Der Schlüsselspeicher kann zusätzlichen Schutz bieten, z. B. sicherstellen, dass der private Schlüssel nicht exportierbar ist Die Gewissheit, dass der Schlüssel nicht exportiert wurde, ist nur so stark wie der Schlüsselspeicher selbst. Hardware-Schlüsselspeicher (z. B. Smartcards, USB-Hsm, Ironkey usw.) bieten eine viel stärkere Gewissheit, dass der private Schlüssel nicht exportierbar ist als Software-Schlüsselspeicher.

Übrigens betrifft der obige Punkt auch Serverschlüssel. Die meisten Implementierungen speichern den privaten Schlüssel in einem Software-Schlüsselspeicher und werden normalerweise als exportierbar markiert. Außerdem ist der private Schlüssel normalerweise nicht kennwortgeschützt, sodass jeder, der Zugriff auf den Server hat, den privaten Schlüssel verwenden kann. Wenn ein Zertifikat kopiert werden kann, bietet es keine Nicht-Zurückweisung.

Um Ihre Frage zu beantworten: Wenn es eine gute Möglichkeit gibt, eine Art Hardware-ID (Guid, Seriennummer, in HSM gespeichertes Zertifikat usw.) zu nutzen, bietet dies wahrscheinlich mehr Sicherheit als die Verwendung einer softwarebasierten ID (einschließlich Client-Zertifikaten). . Die Verwendung von Client-Zertifikaten mit aktiviertem Kennwortschutz für den Zugriff auf private Schlüssel bietet eine etwas stärkere Validierung, da ein Client nicht nur Zugriff auf den privaten Schlüssel haben muss, sondern auch auf das Kennwort, um ihn verwenden zu können.

Wenn Sie sich für die Verwendung von Client-Zertifikaten entscheiden, müssen Sie eine vorhandene PKI-Infrastruktur erstellen oder verwenden. Anbieter wie Codomo, Entrust, Symantec (früher vrsn, thawte und geotrust), Godaddy und eine Reihe anderer bieten sowohl öffentliche als auch private Infrastruktur zur Nutzung an. Die Kosten für die Implementierung eines softwarebasierten Client-Zertifikats sind jedoch wahrscheinlich höher als die Verwendung einer softwarebasierten Hardware-ID oder möglicherweise sogar einer hardwarebasierten eindeutigen ID.

Bestimmen Sie gegebenenfalls das gewünschte Maß an Sicherheit und entscheiden Sie, ob Software, Software + Kennwort oder Hardware ausreichend sind.

19
bangdang

Bei der Clientzertifikatauthentifizierung verlässt das Geheimnis (der private Schlüssel) niemals den Client und geht nicht zum Server. Unabhängig davon, ob Sie dem Server vertrauen oder nicht (Sie sollten dies jedoch trotzdem zuerst überprüfen), wird Ihr privater Schlüssel nicht durchgesickert. Dies ist ein Vorteil gegenüber der herkömmlichen formularbasierten oder HTTP Basic-Authentifizierung.

Sie können sogar einige kryptografische Hardware-Token/Smartcards verwenden, die so konzipiert sind, dass der private Schlüssel das Token nie verlässt (die am TLS-Handshake beteiligten Signaturen finden an Bord statt).

Wenn Sie Client-Zertifikate (höchstwahrscheinlich) im Kontext einer Public-Key-Infrastruktur verwenden, können Sie auch die Vorteile der PKI nutzen. Dies ist vor allem für große Strukturen nützlich, aber Sie können:

  • Erkennen Sie die Identität von Benutzern, die Sie noch nie registriert haben.

    Dafür sind Zertifizierungsstellen da. Wenn Sie der Zertifizierungsstelle vertrauen, vertrauen Sie dem von ihr ausgestellten Zertifikat. Wenn sich unbekannte Benutzer ohne ein bereits vorhandenes Konto bei Ihrem System anmelden und Zertifikate vorlegen, denen Sie vertrauen, können Sie deren Identität erkennen, für die die Zertifizierungsstelle bürgt. Möglicherweise möchten Sie weitere Details vom Benutzer erhalten oder nicht, aber die Hauptidentität wurde bei der Zertifizierungsstelle bestätigt und hat dort einen Verwaltungspfad hinterlassen.

  • Dieselbe Identität, die durch das Zertifikat bestätigt wird, kann auf mehreren unabhängigen Websites verwendet werden (vorausgesetzt, sie vertrauen derselben Zertifizierungsstelle), möglicherweise als Form der einmaligen Anmeldung.

  • Ein kompromittiertes Zertifikat kann von der Zertifizierungsstelle direkt widerrufen werden.

  • Über die Zertifizierungsstelle entkoppeln Sie das Problem des Nachweises der Identität des Benutzers von der Bereitstellung des Dienstes selbst. Andere Methoden wie OpenID erreichen dieses Ziel ebenfalls, bieten jedoch kaum das gleiche Maß an Sicherheit wie CAs (vorausgesetzt, CAs erledigen ihre Arbeit korrekt). Das Maß an Sicherheit hängt von der Qualität der Zertifizierungsstelle ab.

    Dies hat den Vorteil, dass Sie ein neues Zertifikat mit unterschiedlichen Schlüsseln an denselben Benutzer erneut ausstellen können (wenn das vorherige Zertifikat abgelaufen ist oder wenn der private Schlüssel kompromittiert wurde) und auf allen Systemen, die diesem vertrauen, dieselbe Kennung (Betreff) beibehalten CA.

(Sie können Client-Zertifikate auch außerhalb des Kontexts einer PKI verwenden, müssen jedoch Ihre eigenen Vertrauensregeln definieren, was sehr langwierig sein kann.)

Client-Zertifikate können auch unabhängig von dem Protokoll verwendet werden, das auf SSL/TLS ausgeführt wird. Sie können sie gegebenenfalls sogar für S/MIME verwenden.

Ein weiterer Vorteil ist, dass die Authentifizierung, da sie nicht auf HTTP-Ebene erfolgt, praktisch zustandslos ist, wenn Ihnen Dinge wie der Architekturstil REST) wichtig sind.

Einige Webdienste verwenden dies möglicherweise auch für die Sicherheit auf Nachrichtenebene, wodurch möglicherweise ein Prüfpfad für die Nicht-Zurückweisung bestimmter Nachrichten hinterlassen wird, falls dies erforderlich ist.

Der Hauptnachteil besteht darin, dass Sie Ihre Benutzer in die grundlegenden Konzepte der Kryptografie mit öffentlichen Schlüsseln einweisen müssen. Dies ist besonders wichtig, wenn Sie keine Hardware-Token verwenden (sondern nur die Zertifikate und den privaten Schlüssel in der Software des Benutzers behalten).

  • Im Gegensatz zu Passwörtern können sich Benutzer nicht an den privaten Schlüssel/das private Zertifikat erinnern. Sie müssen einen Computer verwenden, auf dem das Zertifikat installiert wurde (oder auf dem ein geeigneter Kartenleser für Hardwarelösungen vorhanden ist). Einige sind möglicherweise versucht, ihre privaten Schlüssel nicht so sorgfältig zu pflegen, wie sie sollten (sie sind normalerweise selbst passwortgeschützt).

  • Bei der Erklärung kann der Begriff "Zertifikat" verwirrend sein. Sogar Experten verkürzen manchmal Sätze. Wenn Sie "Verwenden Sie Ihr Zertifikat zum Anmelden" sagen, meinen Sie tatsächlich "Verwenden Sie den privaten Schlüssel und Ihr Zertifikat zum Anmelden": Der private Schlüssel ist in diesem Ausdruck enthalten. Im Gegensatz dazu sollten Sie Ihren privaten Schlüssel nicht verwenden, wenn Ihnen jemand sagt, dass Sie mir Ihr Zertifikat senden sollen. Wenn Sie sich nach Dokumentation umsehen, finden Sie eine Reihe von Verweisen auf PKCS # 12-Dateien (.p12 oder .pfx) und PEM-Zertifikatdateien (.pem oder .crt, typischerweise). In der Regel enthält der erstere den privaten Schlüssel, während der zweite dies nicht tut (obwohl dies möglicherweise auch der Fall ist). All diese Begriffe verwirren Benutzer, wenn sie nicht wissen, was sie tun.

  • Die Benutzeroberflächen des Browsers für Client-Zertifikate sind im Allgemeinen recht schlecht. Aus Sicht der Benutzeroberfläche ist es ziemlich schwierig, sich von einer Website abzumelden, auf der Sie sich beispielsweise mit einem Client-Zertifikat authentifiziert haben (wie z. B. HTTP Basic). (Dies macht den CSRF-Schutz noch wichtiger.) Wenn Ihre Clients "Maschinen" und keine Benutzer über einen Browser sind, ist dies kein so großes Problem.

Wenn Sie in Bezug auf die Infrastruktur nicht bereit sind, die Dienste einer kommerziellen Zertifizierungsstelle für Ihre Clientzertifikate zu verwenden, müssen Sie Ihre eigene Zertifizierungsstelle bereitstellen. Beachten Sie, dass die zur Authentifizierung der Clients verwendete Zertifizierungsstelle unabhängig von der zur Authentifizierung des Servers verwendeten Zertifizierungsstelle sein kann. Sie können eine Website mit einem Zertifikat betreiben, das von einer bekannten Zertifizierungsstelle ausgestellt wurde, aber Client-Zertifikaten Ihrer eigenen Zertifizierungsstelle vertrauen. Es gibt verschiedene Tools für die CA-Verwaltung, einschließlich Open Source-Tools . Einige können sogar Schlüssel im Browser generieren, sodass der private Schlüssel im Browser bereit ist (der Nachteil dabei ist, dass der Benutzer denselben Browser erneut verwenden muss, um das Zertifikat nach seiner Ausstellung zu importieren).

Die Konfiguration der Server erfordert ein gewisses Verständnis der Zertifikate (CA-Zertifikate, Serverzertifikat), ist jedoch nicht so kompliziert. Die meisten Server unterstützen dies auf die eine oder andere Weise.

Client-Zertifikate bieten Ihnen nur eine Authentifizierung. Möglicherweise müssen Sie noch weitere Attribute abrufen (z. B. von LDAP oder einer Datenbank für die Subjekte der Zertifikate). Darüber hinaus benötigen Sie wie bei jedem anderen Authentifizierungssystem eine Autorisierungslogik. Es ist typisch, einen Betreff-DN einer lokalen Kennung in Ihrem System zuzuordnen.

(Es gibt fortgeschrittenere Anwendungen, bei denen Sie die Authentifizierung mithilfe von Proxy-Zertifikaten delegieren oder Autorisierungstoken über Attributzertifikate übergeben können. Diese sind jedoch ungewöhnlicher und werden nicht von allen Software-Stacks akzeptiert.)

19
Bruno