Zertifikate und Trust-Center

Zertifikate und Trust-Center Public-Key-Infrastrukturen Im ersten Teil des Seminares haben wir Verfahren zur Verschlüsselung kennengelernt. Es ging dabei hauptsächlich um asymetrische Verschlüsselung. Mit den dort verwendeten Schlüsselpaaren war es möglich mit dem öffentlichen Schlüssel ein Nachricht zu verschlüsseln, die dann nur der Besitzer des privaten Schlüssels wieder decodieren kann. Und umgekehrt. Das Ganze scheint auf den ersten Blick recht sicher. Das folgende Beispiel zeigt uns aber, wie schnell die Geheimhaltung auf der Strecke bleibt. 1

Alice Mail mit Public-Key A Bob Geheimnis Geheimnis Mail mit Public-Key C Charlie Angenommen, Bob möchte Alice ein Geheimnis verraten. Um es auch geheim zu halten, wollen sie ihre Nachrichten in Zukunft verschlüsselt austauschen. Alice schickt nun ihren öffentlichen Schlüssel zu Bob. Charlie hingegen hat von der Geheimnistuerei der beiden Wind bekommen und fängt geschickt die Mail von Alice ab. Er merkt sich den Schlüssel von Alice, schreibt aber in die Mail seinen eigenen Public-Key. Diese Mail schickt er nun weiter an Bob. Bob freut sich, dass er sein Geheimnis nun sicher verschlüsselt verschicken kann. Er verschlüsselt es mit dem vermeindlichen Schlüssel von Alice und schickt die Nachricht ab. Charlie fängt diese natürlich ab und kann sie beruhigt entschlüsseln und lesen. Er verschlüsselt sie dann mit dem eigentlichen Public Key von Alice und schickt sie weiter. Alice bekommt die Nachricht, liest sie und glücklich. Weder Alice noch Bob werden je merken, dass ihre verschlüsselten Mails mitgelesen werden. 2

Alice Bob Schlüsselpaar A Schlüsselpaar C Charlie Der komplette weitere Mailverkehr läuft also nur noch über Charlie. Die Sicherheitslücke an der ganzen Geschichte ist, dass Bob den erhaltenen Schlüssel nicht als falsch erkannt hat. Um die Verwendung von Schlüsselpaaren zu perfektionieren, bedarf es also einer eindeutigen Zuordnung eines Public-Keys zu einer bestimmten Person. 3

Zertifikate Dieses löst man mit Hilfe von Zertifikaten. Zertifikate sind digitale Dokumente. 4

Zertifikate Digitale Beglaubigung eines Public Key durch Zuordnung zum Besitzer Sie sind eine Beglaubigung der Identität einer bestimmten Person. Also quasi ein digitaler Personalausweis. Damit alle Zertifikate gleich aussehen, benötigt man dafür eine Standard. Dieser ist der X.509 5

Zertifikate Digitale Beglaubigung eines Public Key durch Zuordnung zum Besitzer einheitlicher Standard X.509 X.509 ist ein Standardformat der ITU (International Telecommunication Union) für Zertifikate. Es beinhaltet den Namen des Austellers, üblicherweise eine Certification Authority, Informationen über die Identität des Inhabers sowie die digitale Signatur des Ausstellers. (Zitat dialogdata.com) 1988 eingeführt Aktuelle Version X.509v3 Der X.509 ist ein Standard der International Telecommunication Union, kurz ITU. Die ITU ist eine Vereinigung mit Sitz in der Schweiz, die weltweite Richtlinien und Standarisierungen für das Fernmeldewesen und die Telekommunikation herausgibt. Der Standard für Zertifikate wurde bereits 1988 eingeführt und bis heute weiterentwickelt. Die aktuelle Version v3 gibt es seit 1996. Doch wie genau sieht ein Zertifikat nach diesem Standard aus? 6

Certificate: Data: Version: 3 (0x2) Serial Number: 0C Issuer: C = DE O = Technische Universität Chemnitz OU = Universitätsrechenzentrum CN = TU Chemnitz Certification Authority TUC/URZ- E = ca@hrz.tu-chemnitz.de Validity: Not Before: 18.11.2003 09:59:40 GMT Not After : 17.11.2005 09:59:40 GMT Subject: C = DE O = Technische Universität Chemnitz OU = Universitätsrechenzentrum CN=mail.tu-chemnitz.de E=postmaster@hrz.tu-chemnitz.de Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: 30:81:89:02:81: :01:00:01 X509v3 extensions: Netscape Cert Type: SSL Server Signature Algorithm: md5withrsaencryption Signature Value: 98:0A:A1:6A:CD: :71:CB:5F Hier als Beispiel das Zertifikat des Mailservers der TU. Ein solches Zertifikat enthält als erstes seine Versionsnummer. Hier die 3 für X.509v3. Als nächstes bekommt es eine Seriennummer, die das Zertifikat bei dem Aussteller eindeutig macht. Es folgen Daten zum Aussteller. Hier ist es die Zertifizierungsstelle des URZ der TU. Die Abkürzungen stehen für Nationalität (country), Organsation/Firma, Teilbereich (organisation unit), dem Namen des Ausstellers (certain name) und einer Kontakadresse. Weiterhin verfügen die Zertifikate über einen Gültigkeitszeitraum. Dieses ist zwar laut X.509 nicht zwingend vorgeschrieben, aber alle modernen und sicheren Anwendungen setzen dies heute voraus. Das wichtigste kommt jetzt. Und zwar der Besitzer des Zertifikates. Also der, dessen Identität beglaubigt werden soll. Hier ist es der mail-server der TU. Diesem Besitzer wird nun ein öffentlicher Schlüssel und dessen Verschlüsselungsmethode zugeordnet. Damit sind die erforderlichen Daten komplett. Nun können weitere Versionsabhängige Erweiterungen folgen. Bei Version 3 ist das meist der Verwendungszweck des Schlüssels. Hier ist er für einen SSL-Server da. Eine weitere sinnvolles Erweiterung ist zum Beispiel die URL der Sperrliste für diesen Aussteller. Was Sperrlisten sind, taucht später nochmal auf. Um nun das ganze Zertifikat gegen Verfälschungen zu schützen, wird es nun noch vom Aussteller signiert, und dessen Public-Key eingefügt. 7

Funktionsweise: Zertifikate TTP erteilt Zertifikat überprüft Zertifikat Sender Zertifikat mit Public-Key Empfänger Doch wie funktioniert das mit den Zertifikaten? Voraussetzung ist, dass sich ein Kommunikationspartner seinen Public-Key bei einem vertrauenwürdigen Dritten (also der Trusted Third Pary) hat zertifizieren lassen. Will man nun mit jemandem verschlüsselte Informationen austauschen, so muss brauch man zuerst dessen Public-Key. Hat man diesen noch nicht, so muss dieser direkt vor der Übermittlung übergeben werden. Damit garantiert ist, dass man auch den richtigen, zur jeweiligen Person gehörenden, Schlüssel erhält, erhält man den Schlüssel zusammen mit seinem Zertifikat, welches bestätigt, das Schlüssel und Besitzer tatsächlich zusammengehören. Dieses kann nun überprüft werden, ob es wirklich von einem vertrauenswürden Aussteller kommt. Beim Aussteller kann man dann noch feststellen, ob das Zertifikat noch gültig ist oder schon auf einer Sperrliste steht. Vertraut man dem Zertifikat/seinem Aussteller kann man das Zertifikat in den meisten Programmen speichern, und somit dem zugehörigen Public-Key dauerhaft Vertrauen schenken. Ich muss damit nicht mehr jedem Kommunikationspartner einzeln vertrauen, sondern nur noch den TTPs. Also steht schonmal fest, dass nicht jeder x-beliebige Zertifikate ausstellen darf. 8

Trust Center Certification Authority () Zertifikate werden von Zertifikationstellen (oder engl. Certification Authorities) ausgestellt. Diese Stellen sind auch als TrustCenter bekannt. 9

Trust Center 1. Trust Center 2. Zeitstempeldienst 3. Personalisierungsdienst 4. Verzeichnisdienst Das Trust Center ist eigentlich nur eine Instanz im ganzen Zertifizierungsprozess. Und zwar der Teil in dem das Vertrauen der bestimmten Personen übernommen wird. Eh ein Zertifikat verwendet werden kann muss es noch drei weitere Stellen durchlaufen. Und zwar den Zeitstempeldienst, den Personalisierungsdienst und den Verzeichnisdienst. Ich werde jetzt die Enstehung eines Zertifikates für jede dieser Instanzen erläutern. 10

1. Trust Center Trust Center Erfassung grundlegender Daten zur Person oder Firma Überprüfung der Daten Schlüsselpaar erzeugen Zertifikat mit Daten und Public-Key erzeugen Zertifikat signieren Wenn ich ein zertifiziertes Schlüsselpaar benötige, so muss ich an ein TrustCenter herantreten, und dort Angaben zu meiner Person oder meiner Firma machen. Diese werden dann in öffentlichen Datenbanken überprüft. Solche Datenbanken können das Einwohnermeldeamt oder ein Handelsregister sein. Sind die Daten authentisch, vertraut mir das TrustCenter und übernimmt die Verantwortung für meine Person. Es wird ein assymetrisches Schlüsselpaar erzeugt. Für den öffentlichen Schlüssel wird nun ein Zertifikat erzeugt, in dem meine Daten und die des TrustCenters angegeben werden. Zudem wird Signatur für das Zertifikat erstellt. An diesem Prozess sollten so wenig wie möglich Personen beteiligt sein, um eine Manipulation auszuschließen. 11

1. Trust Center 2. Zeitstempeldienst Trust Center Gültigkeitsdauer hinzufügen Im zweiten Teil wird für das Zertifikat eine Gültigkeitsdauer festgelegt. 12

Trust Center 1. Trust Center 2. Zeitstempeldienst 3. Personalisierungsdienst Zertifikatsdaten, Schlüsselpaar auf Datenträger bringen Datenträger aushändigen Überprüfung Der Personalisierungsdienst ist wieder ein Prozess, der weitesgehend autonom ablaufen sollte. Hier werden dem Antragsteller die Zertifikatsdaten und sein Schlüsselpaar übergeben. Dabei werden die Daten auf einen Datenträger gebracht. Zur Zeit wird eine PINgeschützte SmartCard dafür als ausreichend sicher angesehen. Dieser Datenträger wird dem Antragsteller übermittelt. Desweiteren kann der erhalt des privaten Schlüssels überprüft werden, indem eine mit dem öffentlichen Schlüssel kodierte Nachricht vom Antragsteller decodiert werden muss. 13

Trust Center 1. Trust Center 2. Zeitstempeldienst 3. Personalisierungsdienst 4. Verzeichnisdienst Zertifikat mit Public-Key öffentlich verfügbar machen Sperrlisten (CRLs) veröffentlichen Im letzten Teil der Zertifizierung wird das Zertifikat öffentlich zugänglich gemacht. Im Verzeichnis kann es dann von jedermann abgerufen und überprüft werden. Der Verzeichnisdienst ist weiterhin zuständig für das veröffentlichen von Sperrlisten oder Certificate Revocation Lists. Das sind Listen, die die Seriennummern von Zertifikaten enthalten, die während ihrer Gültigkeitsdauer ungültig geworden sind. Gründe hierfür können sein, dass der Verschlüselungsalgorithmus des Schlüsselpaares nicht mehr als sicher gilt oder das der Besitzer nicht mehr vertrauenswürdig ist. Soweit zur Arbeitsweise von TrustCentern. 14

Public-Key-Infrastrukturen (PKI) Das Problem, dass wir mit dem TrustCenter eben aus der Welt geschafft haben, ist die korrekte Schlüsselverteilung der Public-Key. Der Begriff Public-Key-Infrastrukur, um den es jetzt gehen soll, beschreibt die Organisation der Schlüsselvergabe. Dabei gibt es verschiedene Modelle, die natürlich unterschiedliche Sicherheit bieten und einen unterschiedlichen Aufwand erfodern. Die Form, die wir ich mit den TrustCentern angeschnitten hatte, ist nur eine solche Public-Key-Infrastruktur. 15

PKI Trust Center Hierarchie Zertifikate Zertifikate Zertifikate Diese beruht darauf, dass sich jeder seine Authentizität und die seines Public- Keys durch ein Zertifizierungsinstanz beglaubigen lässt. Die Trust-Center selber müssen sich natürlich auch ausweisen können. Somit verlagert sich die Vertrauensfrage immer weiter auf ein übergeordnetes TrustCenter. Wer dieses kennt, vertraut allen Trust-Centern unter ihm und somit allen Zertifikaten. Diese hierarchische Struktur ist die sicherste vorstellbare, da man im Endeffekt nur einem TrustCenter vertrauen muss. Der Aufwand ist aber extrem hoch. Würde man strikt diese Hierarchie durchsetzten, würde an der Spitze ein TrustCenter stehen, welches global alle anderen TrustCenter vertritt und somit ständig kontrolliert. Diese Kontrolle erschwert sich dadurch, dass in jedem Land andere rechtliche Rahmenbedingungen gelten, und die unter einen Hut gebracht werden müssen. 16

PKI Trust Center Hierarchie P P P P Policy Certification Authority Dies stellt eine abgewandelte Form der TrustCenter Hierarchie dar. Hier steht nicht eine Instanz an der Spitze, sondern eine ganze Gruppe, die sich untereinander vertrauen. Jede dieser Stellen hat einen Baum von TrustCentern unter sich, die unter gleichen Spielregeln arbeiten. P steht für Policy-Certification-Authority. Oberhalb der P s könnte man sich noch eine global kontrollierende Behörde vorstellen, die selbst aber nicht als TrustCenter arbeitet. 17

PKI Trust Center Hierarchie RegTP RegTP Regulierungsbehörde für Telekommunikation und Post Eine solche Landesweite Überwachungsfunktion stellt in Deutschland die Regulierungsbehörde für Telekommunikation und Post dar. Jedes Trustcenter bedarf vor seiner Inbetriebnahme einer Genehmigung durch diese Behörde. 18

PKI Trustcenter-Hierarchie Auf diese Trustcenter-Hierarchei stolpert man hin und wieder beim täglichen Surfen im Internet. Man möchte eine sichere Verbindung nutzen und dafür ein Zertifikat als vertrauenswürdig einstufen. Einige Browser akzeptieren dies anstandslos. Andere kommerzielle Programme versuchen Stück für Stück den Baum in der Hierarchie der austellenden TrustCenter hochzuklettern, bis sie auf ein bekanntes schon als vertrauenswürdige Stelle eingestuftes TrusCenter stoßen. Es ist nicht immer sinnvoll sich in diese TrustCenter-Hierarchie einzuordnen. Will z.b. eine Firma nur seinen Firmeninternen Verkehr absichern und dafür Schlüssel verteilen, so benötigt man keinen ganz so hohen Sicherheitsstandard wie bei der TrustCenter-Hierarchie. Schließlich kennt man sich ja innerhalb der Firma. Hier reicht es zum Beispiel einen Server ins Firmennetz zu stellen, und auf diesem alle Schlüssel-Besitzer-Kombinationen zu speichern. 19

PKI Trustcenter-Hierarchie zentraler Schlüsselserver Dieses System ist natürlich nur so sicher, wie der Schlüsselserver. Daher kommt diese Methode nur zum Einsatz, wenn das Firmennetz von aussen unzugänglich ist, oder der Server ausreichend geschützt ist. 20

PKI Trustcenter-Hierarchie zentraler Schlüsselserver Trust Friends eine dritte Struktur möchte ich noch erläutern. Und zwar die verteilte Struktur Trust Friends. Diese hat keine zentrale Zertifizierungsstelle oder ein Schlüsselverzeichnis. 21

PKI- Trust Friends 3 2 4 1 5 Hier hat jeder Teilnehmer eine bestimmte Gruppe von Leuten (Friends), denen er vertraut (trust). Hier im graphischen Beispiel kennt und vertraut Person 3 nur den Personen 4 und 5. Will Person 3 nun an Person 1 eine Nachricht schicken, und sicher sein, dass diese auch bei 1 ankommt, so schickt er sie mit seiner eigenen Signatur an Person 4 oder 5. Diese Person erkennt die bekannte Signatur 3, löscht diese und hängt seine eigene Signatur an. Danach wird die Nachricht weiter an Person 2 verschickt. Diese erkennt 4 (bzw. 5) und ersetzt die Signatur durch ihre eigene. Da Person 2 Person 1 kennt, kommt die Nachricht nun zu Person 1. Der sieht, dass die Nachricht von Person 2 signiert ist, und vertraut, somit dem Inhalt. Alle bisherigen Überprüfungen der Signaturen erfolgten automatischm damit garantiert ist, dass nur der Empfänger die Nachricht lesen kann. Der Aufwand für dieses Verfahren ist nicht sonderlich hoch, da es kaum Organisationstalent bedarf. Jedoch ist nicht die Sicherheit gegeben, die es bei der Trust-Center-Hierarchie gibt, da die Nachricht an jeder Stelle der Kette geknackt werden könnte. Diese Kette ist natürlich nur so stark, wie ihr schwächstes Glied, also der unsicherste Teilnehmer. In so einem Verbund ist es also wichtig, wer Teilnehmer ist, und wer nicht. Was wiederrum einen Angriff von aussen erschwert, ist, dass man nie weiß, welchen Weg die Nachricht geht. 22

PKI Aufwand Trustcenter-Hierarchie Trust Friends zentraler Schlüsselserver Sicherheit Hier noch einmal ein Vergleich der drei Strukturen in Bezug auf Sicherheit und Aufwand. Das es mehr als diese drei Strukturen gibt, ist hoffentlich jedem klar. Welche Infrastruktur man nun in seiner Firma z.b. einsetzt hängt natürlich ganz davon ab, welchen Sicherheitsgrad man realisieren will, wieviele Mitarbeiter es gibt und welchen finanziellen, technischen oder organisatiorischen Aufwand man betreiben will 23