Public Key Infrastructure (PKI): Difference between revisions
mNo edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Eine Öffentlicher-Schlüssel-Infrastruktur ermöglicht das überprüfen von und bürgen für Identitäten durch eine vertrauenswürdige dritte Partei. Zur Authentifizierung werden asymmetrische Kryptosysteme benutzt. Die öffentlichen Schlüssel befinden sich zu diesem Zweck in personen- oder maschienengebundenen Zertifikaten, die von der Trusted Third Party signiert wurden. |
|||
| ⚫ | |||
In der Praxis ist i.d.R. eine zentrale Stelle zum Erstellen und Signieren eines Zertifikats verantwortlich. Sie selbst kann, um ihre Vertrauenswürdigkeit zu garantieren, auch von anderen Parteien zum Ausstellen letztgenannter autorisiert worden sein (siehe hierzu [http://de.wikipedia.org/wiki/Verisign VeriSign], [http://de.wikipedia.org/wiki/Web_of_trust Web Of Trust] oder [http://de.wikipedia.org/wiki/Thawte Thawte]). Die CA ist selbst im Besitz eines Schlüsselpaares. Mit ihrem geheimen Schlüssel signiert sie jedes Zertifikat. |
|||
== Authentizität mittels asymmetrischer Kryptosysteme == |
|||
=== Ausstellen eines Zertifikats === |
|||
Ein Zertifikat enthält Daten über den Zertifikatnehmer (z.B. seinen öffentlichen Schlüssel) und wird nach dessen Erstellung mit dem privaten Schlüssel der CA signiert. Meist werden Schlüsselpaar und Zertifikat vom Benutzer von der CA erstellt und gemeinsam mit dem public key der CA an ihn über einen sicheren Kanal weitergegeben. |
|||
PKIs benutzen asymmetrische Kryptosysteme. Es werden zwei Schlüssel generiert, die in besonderer mathematischer Beziehung zu einander stehen. Daten, die mit einem der Schlüssel chiffriert wurden, lassen sich ausschließlich mit dem jeweils anderen dechiffrieren. Möchte der Besitzer eines solchen Schlüsselpaares seine Identität beweisen, genügt es mit dem geheimen Schlüssel eine Nachricht zu kodieren. Den Beleg bildet die durch den öffentlichen Schlüssel dechiffrierte Nachricht. |
|||
Es ist aber ebenso denkbar, dass sich der Client das Schlüsselpaar selbst generiert und den öffentlichen Schlüssel samt anderer zertifikatsrelevanter (und somit nicht geheimer) Daten an die Zertifizierungsstelle schickt. Diese sendet ein von ihr signiertes Zertifikat zurück. Mit dem öffentlichen Schlüssel der Certification Authority kann nun vom Benutzer geprüft werden, ob das Zertifikat echt ist. Da alle gesendeten Daten nicht geheim sind, kann diese Prozedur also ebenfalls über einen unsicheren Kanal erfolgen -- vorrausgesetzt man traut dem öffentlichen Schlüssel der Zertifizierungsstelle. |
|||
| ⚫ | |||
Die CA signiert den öffentlichen Schlüssel eines ZN mit ihrem geheimen Schlüssel. Es genügt allein die Kenntnis über den öffentlichen Schlüssel der Zertifizierungsstelle, um die Signatur du entschlüsseln und zu prüfen ob das Zertifikat gültig ist. Beliebig viele vorgeprüfte Identitäten können auf diese Weise mit einem einzigen Schlüssel kontrolliert werden. |
|||
== Certificate Revocation List == |
== Certificate Revocation List == |
||
| Line 15: | Line 16: | ||
Die Zertifikatsperrliste enthält schadhafte oder durch Kompromittierung aufgefallene Zertifikate, die dadurch vor ihrem Ablauf ungültig wurden. |
Die Zertifikatsperrliste enthält schadhafte oder durch Kompromittierung aufgefallene Zertifikate, die dadurch vor ihrem Ablauf ungültig wurden. |
||
== Funktionsweise == |
|||
Jeder Eigentümer eines Zertifikats besitzt außerdem einen eigenen privaten |
|||
Schlüssel sowie den öffentlichen Schlüssel der Zertifizierungsstelle. Zwei |
|||
Benutzer übersenden sich zum Aufbau einer Verbindung ihre Zertifikate und prüfen |
|||
ihre Gültigkeit mit dem öffentlichen Schlüssel der Certification Authority. Aus |
|||
einem Zertifikat kann nun der öffentliche Schlüssel seines Besitzers gelesen |
|||
werden. Der Abender einer Nachricht verschlüsselt diese mit dem öffentlichen |
|||
Schlüssel seines Gegenübers, so dass nur der vorgesehene Empfänger die Nachricht |
|||
lesen kann (''Vertraulichkeit''). Jede Nachricht wird mit dem geheimen |
|||
Schlüssels des Absenders signiert, so dass einerseits ihre ''Authentizität'' |
|||
gesichert ist und andererseits die Urheberschaft eindeutig ist |
|||
(''Verbindlichkeit''). Die ''Integrität'' einer Nachricht kann man durch den |
|||
Einsatz von Hash-Funktion belegen. Die Authentifikation ist bidirektional, jeder |
|||
Kommunikationspartner muss sich identifizieren. |
|||
Die Vertrauenswürdigkeit beliebig vieler öffentlicher Schlüssel (und somit deren |
|||
Besitzer) kann also mit der Kenntnis eines einzigen, dem public key der |
|||
Zertifizierungsstelle, gewährleistet werden. |
|||
---- |
---- |
||
Latest revision as of 23:50, 24 September 2006
Eine Öffentlicher-Schlüssel-Infrastruktur ermöglicht das überprüfen von und bürgen für Identitäten durch eine vertrauenswürdige dritte Partei. Zur Authentifizierung werden asymmetrische Kryptosysteme benutzt. Die öffentlichen Schlüssel befinden sich zu diesem Zweck in personen- oder maschienengebundenen Zertifikaten, die von der Trusted Third Party signiert wurden.
Certification Authority (CA)
In der Praxis ist i.d.R. eine zentrale Stelle zum Erstellen und Signieren eines Zertifikats verantwortlich. Sie selbst kann, um ihre Vertrauenswürdigkeit zu garantieren, auch von anderen Parteien zum Ausstellen letztgenannter autorisiert worden sein (siehe hierzu VeriSign, Web Of Trust oder Thawte). Die CA ist selbst im Besitz eines Schlüsselpaares. Mit ihrem geheimen Schlüssel signiert sie jedes Zertifikat.
Ausstellen eines Zertifikats
Ein Zertifikat enthält Daten über den Zertifikatnehmer (z.B. seinen öffentlichen Schlüssel) und wird nach dessen Erstellung mit dem privaten Schlüssel der CA signiert. Meist werden Schlüsselpaar und Zertifikat vom Benutzer von der CA erstellt und gemeinsam mit dem public key der CA an ihn über einen sicheren Kanal weitergegeben.
Es ist aber ebenso denkbar, dass sich der Client das Schlüsselpaar selbst generiert und den öffentlichen Schlüssel samt anderer zertifikatsrelevanter (und somit nicht geheimer) Daten an die Zertifizierungsstelle schickt. Diese sendet ein von ihr signiertes Zertifikat zurück. Mit dem öffentlichen Schlüssel der Certification Authority kann nun vom Benutzer geprüft werden, ob das Zertifikat echt ist. Da alle gesendeten Daten nicht geheim sind, kann diese Prozedur also ebenfalls über einen unsicheren Kanal erfolgen -- vorrausgesetzt man traut dem öffentlichen Schlüssel der Zertifizierungsstelle.
Certificate Revocation List
Die Zertifikatsperrliste enthält schadhafte oder durch Kompromittierung aufgefallene Zertifikate, die dadurch vor ihrem Ablauf ungültig wurden.
Funktionsweise
Jeder Eigentümer eines Zertifikats besitzt außerdem einen eigenen privaten Schlüssel sowie den öffentlichen Schlüssel der Zertifizierungsstelle. Zwei Benutzer übersenden sich zum Aufbau einer Verbindung ihre Zertifikate und prüfen ihre Gültigkeit mit dem öffentlichen Schlüssel der Certification Authority. Aus einem Zertifikat kann nun der öffentliche Schlüssel seines Besitzers gelesen werden. Der Abender einer Nachricht verschlüsselt diese mit dem öffentlichen Schlüssel seines Gegenübers, so dass nur der vorgesehene Empfänger die Nachricht lesen kann (Vertraulichkeit). Jede Nachricht wird mit dem geheimen Schlüssels des Absenders signiert, so dass einerseits ihre Authentizität gesichert ist und andererseits die Urheberschaft eindeutig ist (Verbindlichkeit). Die Integrität einer Nachricht kann man durch den Einsatz von Hash-Funktion belegen. Die Authentifikation ist bidirektional, jeder Kommunikationspartner muss sich identifizieren.
Die Vertrauenswürdigkeit beliebig vieler öffentlicher Schlüssel (und somit deren Besitzer) kann also mit der Kenntnis eines einzigen, dem public key der Zertifizierungsstelle, gewährleistet werden.