Public Key Infrastructure (PKI): Difference between revisions
No edit summary |
mNo edit summary |
||
| (One intermediate revision by the same user 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 |
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) == |
== Certification Authority (CA) == |
||
| Line 10: | Line 10: | ||
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. |
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. |
||
Nachdem ein Schlüsselpaar erstellt wurde, hält die CA |
|||
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. |
|||
| Line 22: | Line 19: | ||
== Funktionsweise == |
== Funktionsweise == |
||
Jeder Eigentümer eines Zertifikats besitzt außerdem einen eigenen privaten |
|||
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. |
|||
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 |
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.