|
Die Standardwerke zur
Administration von Der nachfolgende Text ist eine Ergänzung zu den
Büchern
|
|||||||||||||||||||||
|
Grundsätzliche Forderungen an Kryptosysteme Angriffe gegen Verschlüsselungssysteme Einigung auf Schlüssel mittels Diffie-Hellman Echtheitsbestätigung übertragener Daten Die Problematik bei der Übertragung von Daten über nicht vertrauenswürdige Netzwerke wie beispielsweise dem Internet ist, daß unberechtigte Dritte diese Daten unter verschiedenen Umständen lesen können. Bei geschicktem Vorgehen können die übertragenen Daten möglicherweise auch abgefangen, verändert und an den Empfänger weitergeleitet werden. Allgemein sind solche Manipulationen an übertragenen Daten als "Man in the Middle"-Angriff bekannt. Kommt Verschlüsselung zum Einsatz, sind solche Angriffe schwierig durchzuführen. Es besteht aber die Gefahr, daß ein Angreifer den symmetrischen Schlüssel errät oder den geheimen Schlüssel des Empfängers weiß. Damit könnte der Angreifer die übertragenen Daten abfangen, manipulieren, wieder wie der Absender verschlüsseln und an den Empfänger weitersenden. Dieser hat ohne eine digitale Signatur des Absenders (außer einer Plausibilitätskontrolle) keine Möglichkeit zu überprüfen, ob dies wirklich die Daten sind, die vom Absender losgeschickt wurden. Dieses gilt auch für den im vorigen Kapitel genannten Austausch der öffentlichen Schlüssel. An dieser Stelle muß also eine digitale Signatur eingeführt werden, durch die nachgewiesen ist, daß es wirklich genau die Daten sind, die vom Absender geschickt wurden. In der Praxis kommen hier Hashfunktionen zum Einsatz, die vom Absender mit seinem geheimen Schlüssel verschlüsselt werden. Dabei handelt es sich um eine Art Unterschrift, da davon ausgegangen werden kann, daß der geheime Schlüssel des Absenders wirklich nur diesem bekannt ist. Außerdem bestehen heute weitere Möglichkeiten, die Echtheit von Schlüsseln zu überprüfen. Dazu sind Trust Center da, die auch Certificate Authorities (CA) genannt werden. Um die gesamte Thematik verstehen zu können, sind allerdings Grundlagen notwendig, die in den nachfolgenden Kapiteln Schritt für Schritt erklärt werden. Mathematische Einwegfunktionen Mathematische Einwegfunktionen sind Funktionen mit der Eigenschaft, daß für eine Funktion f(x)=y keine Umkehrfunktion f-1(y)=x existiert. Das hört sich sehr kompliziert an, aber eine Betrachtung, die nicht streng mathematisch ist, macht die Eigenschaften solcher mathematischer Einwegfunktionen klarer. Eine "Einwegfunktion im richtigen Leben" ist beispielsweise, wenn ein Teller auf einen Steinfußboden fällt und in viele kleine Stücke zerspringt. Die arme Person, die den Teller fallengelassen hat, kann ewig warten, bis sich die Teile des Tellers von selbst wieder zusammentun und als ganzer Teller wieder in die Hände des Menschen zurückspringt. Ein anderes Beispiel macht klar, daß auch, wenn der Originalzustand mit viel Aufwand wieder hergestellt werden könnte, es nicht sicher ist, ob es wirklich das Original ist - damit ist im mathematischen, aber auch im "normalen" Sinne, keine eindeutige Umkehrung möglich. In fast jedem Büro befinden sich Aktenvernichter, mit denen beispielsweise vertrauliche Papiere in kleinste Streifen oder Stücke geschnitten werden, bevor sie im Altpapier landen. Ein solches vernichtetes Papier kann mit viel Mühe und einigen Metern an Klebestreifen möglicherweise wieder lesbar gemacht werden. Voraussetzung ist hierfür, daß alle Papierstückchen vorhanden sind und die Person viel Geduld hat. Hilfreich ist auch, daß möglicherweise auf der Vorderseite ein Text abgedruckt ist, der die richtige Reihenfolge der einzelnen Stückchen vorgibt. Bei einer solchen Aufgabe handelt es sich im Prinzip um ein Puzzle. Ist aber kein Text vorhanden, sehen bei einem guten Aktenvernichter alle Stückchen gleich aus. Sicherlich kann es jemand schaffen, aus ihnen wieder ein ganzes Blatt Papier herzustellen, aber es ist nicht sicher, ob die einzelnen Teile wirklich in genau der richtigen Reihenfolge zusammengeklebt sind. Es ist nicht unterscheidbar - und damit hat die Person, die das Papier zusammengeklebt hat, zwar eine Lösung. Sie ist aber nicht eindeutig, da auch eine andere Kombination von Papierstückchen zu dem augenscheinlich gleichen Ergebnis geführt hätte. Diese Eigenschaft zeichnet auch gute mathematische Einwegfunktionen aus. Die Anwendung mathematischer Einwegfunktionen ist in der Kryptographie weit verbreitet. Genau genommen handelt es sich auch bei der A nwendung von Verschlüsselungsalgorithmen um mathematische Einwegfunktionen, die aber eine Hintertür haben. Diese Hintertür ist der Schlüssel, mit dem beispielsweise die Verschlüsselung wieder rückgängig gemacht werden kann: die Entschlüsselung. Ist der Schlüssel nicht bekannt, muß ein Brute-Force Angriff gemacht werden, also das Ausprobieren aller möglichen Schlüssel, bis der richtige (durch Zufall) gefunden wurde. Eine Eindeutigkeit ist aber nicht von Haus aus sichergestellt, hierfür müßten wirklich alle Schlüssel probiert und nicht der erste vermeintlich passende angewendet werden. Einwegfunktionen sind also von der mathematischen Seite her die Grundlage für Verschlüsselung und auch für die Nutzung von Hashfunktionen, die eine Basis für die Anwendung von digitalen Signaturen sind. Hashfunktionen Heute ist immer wieder die Rede von Hashfunktionen, Hashes, Message Digests oder Prüfsummen. Durch sie soll die Integrität übertragener Daten sichergestellt werden. Wie aber funktionieren solche Funktionen? Hashfunktionen sind im Prinzip mathematische Einwegfunktionen, die nicht umkehrbar sind: f(x)=y. Bei Hashfunktionen ist x der Eingabewert, der beliebig lang sein kann. Er kann beispielsweise ein kurzer Text von einer E-Mail sein oder aber auch eine sehr große Datei. Eine spezielle Eigenschaft von Hashfunktionen ist, daß der Ausgabewert y (auch "Hash" oder "Message Digest" genannt) immer die gleiche Länge hat. Ist der Ausgabewert sehr groß, bestehen so viele verschiedene Möglichkeiten für die in Frage kommende Eingabe, daß also ein Zurückrechnen nicht möglich ist. Anforderungen an gute Hashfunktionen Nicht alle beliebigen Einwegfunktionen eignen zur Bildung des Hashes. Ein Beispiel für eine ungeeignete Einwegfunktion ist f(x)=3. Hier wird jeder beliebige Eingabewert x immer auf die Zahl 3 abgebildet und damit ist eine Unterscheidung von Hashes verschiedener Eingabewerte nicht mehr möglich. Damit ist aber auch gleichzeitig klar, daß ein Zurückrechnen bei einer mathematischen Einwegfunktion nicht möglich ist (oder zumindest möglich sein sollte). Was bleibt, ist, alle möglichen Kombinationen auszuprobieren - also einen Brute-Force Angriff durchzuführen. Bei dem oben genannten Beispiel hilft das Wissen um das Ergebnis "3" wirklich nichts, es müssen alle möglichen Eingabeparameter ausprobiert werden. Insofern ist diese "Hashfunktion" aber auch eine gute, weil aus dem Ergebnis das Zurückrechnen auf den Eingabewert wirklich nicht möglich ist. Eine Forderung an Hashfunktionen ist, daß sie kollisionsfrei sein sollten. Damit ist gemeint, daß unterschiedliche Eingaben auch wirklich unterschiedliche Ergebnisse liefern. Es muß sich darauf verlassen werden können, daß bei einer Änderung der Eingabe auch wirklich ein vollkommen anderer Hash herauskommt. Ansonsten bestünde die Möglichkeit, daß ein Angreifer die Eingabe kennt und sie so modifiziert, daß wiederum der gleiche Hash als Ergebnis herauskommt. Wäre dem der Fall, könnte man sich die Bildung des Hashes gleich sparen. Es kommen heute trotz dieses Nachteils aber solche nicht-kollisionsfreien Algorithmen zum Einsatz, allerdings nur in unkritischen Bereichen. Ein solches Verfahren ist der Cyclic Redundancy Check, kurz CRC. Hierbei handelt es sich um ein Verfahren, bei dem Prüfsummen (also eine Art Hash) berechnet werden, die beispielsweise auf einem FTP-Server sicherstellen sollen, daß es sich bei den Dateien, die heruntergeladen werden können, um die Original-Dateien handelt. Sie könnten zwar auf dem FTP-Server im Originalzustand zum Abruf bereitliegen, aber während der Übertragung durch Dritte verändert werden. Um hier eine Sicherheit zu schaffen, liegen die CRC-Prüfsummen auf dem FTP-Server zum Abruf bereit. Um sichere Hashes oder gar digitale Signaturen zu erzeugen, reichen aber solche Prüfsummenverfahren zur Sicherstellung der einwandfreien und unmanipulierten Datenübertragung nicht aus. Message Digest 5 (MD5) Diese Hashfunktion ist heute (noch) sehr weit verbreitet. Es ist die Weiterentwicklung des vorhergehenden Standards MD-4. Der Name ist an den einer Hashfunktion angelehnt: Message Digest Nr. 5. Das grundsätzliche Prinzip ist, daß der beliebige Eingabewert x immer auf eine Zahl mit einer Länge von 128 Bit abgebildet wird. Damit dies möglich ist, wird der Eingabewert in mehreren Schritten nacheinander bearbeitet. Zuerst wird er auf ein ganzzahliges Vielfaches von 512 Bit aufgefüllt. Es folgt eine Aufteilung in einzelne Blöcke mit einer Länge von diesen 512 Bit. Danach werden mathematische Kompressionsfunktionen durchlaufen, die jeden einzelnen Block auf eine Zahl von 128 Bit abbilden. Diese einzelnen Zahlen werden wieder zusammengefügt und wiederum auf die Länge eines ganzzahligen Vielfachen von 512 Bit aufgefüllt. Es folgt wiederum die Abbildung der einzelnen Blöcke auf 128 Bit. Insgesamt wird diese Schleife so lange durchlaufen, bis als Ergebnis lediglich eine einzige 128-Bit-Zahl übrig ist. Das Schließen von einem Hash auf den Eingabewert ist theoretisch möglich, aber nicht wirklich durchführbar. Die Länge des Hashes von 128 Bit ergibt theoretisch ca. 1038 verschiedene Möglichkeiten, wie der Eingabetext ausgesehen haben könnte. Sicherlich gibt es Maschinen, mit denen diese Möglichkeiten alle ausprobiert werden können. Aber selbst dann, wenn alle Möglichkeiten vorliegen, ist nicht bekannt, wie oft der Algorithmus durchlaufen wurde. Die Anzahl möglicher Eingaben potenziert sich. Selbst wenn also ein möglicher Eingabewert gefunden wurde, ist nicht sichergestellt, daß der gefundene tatsächlich der richtige Wert ist. Secure Hash Algorithm 1 (SHA-1) Der Secure Hash Algorithmus gehört zu den Standards, die in den USA für die sichere Datenübertragung gelten. Er wurde von der National Security Agency (NSA) entwickelt und eingeführt. Bei SHA-1 handelt es sich um den Nachfolge-Algorithmus von SHA. Er arbeitet mit einem Hash, der eine Länge von 160 Bit hat. Unter der Voraussetzung, daß es sich um einen sicheren und kollisionsfreien Algorithmus handelt, ist die Sicherheit aufgrund der Länge des Hashes höher als bei anderen Verfahren wie beispielsweise MD5. SHA-1 ist auch in Deutschland als sicherer Hash-Algorithmus gesetzlich anerkannt. Inzwischen gibt es auch SHA-2, einer Erweiterung von SHA-1. Im Gegensatz zu SHA-1 bietet SHA-2 verschiedene Längen für die Hashes. Unterstützt werden einerseits die aus SHA-1 bekannten 160 Bit, andererseits gibt es Erweiterungen mit Längen von 256 Bit, 384 Bit bzw. 512 Bit. Diese werden dann z.B. mit SHA-384 benannt. CHeck Point Next Generation unterstützt diesen relativ neuen Standard (noch) nicht. RIPE Message Digest 160 (RIPE-MD160) Der zweite Algorithmus, der in Deutschland nach dem Gesetz zur digitalen Signatur anerkannt wird, ist RIPE-MD160. Er wurde innerhalb der Europäischen Union entwickelt und arbeitet ebenfalls mit einem Hash von 160 Bit Länge. Insofern ist er von der Sicherheit ähnlich wie SHA-1 einzustufen und wird auch in Deutschland gesetzlich anerkannt. RIPE-MD160 wird als "nicht-amerikanischer" Hash von der Check Point FireWall-1 derzeit nicht unterstützt. Digitale Signatur Das Internet wird heute nicht mehr nur im »Sinne seiner Väter« für die ausfallsichere Datenübertragung, sondern kommerziell genutzt. Daher müssen weitere Verfahren greifen, die einerseits sicherstellen, daß die Daten während der Übertragung nicht manipuliert wurden, aber auch den Absender dieser Daten eindeutig identifizieren. Ansonsten besteht das Risiko, daß beispielsweise jemand eine (aufwendige) Bestellung über das Internet tätigt und bei Auslieferung der Ware mit mehreren LKWs bestreitet, diese Bestellung jemals getätigt zu haben. Gleiches gilt auch beispielsweise für die Abgabe von Angeboten und Auftragsbestätigungen mit Lieferzeiten und Preisen über das Internet. Zu leicht kann eine einfache E-Mail von außen verändert werden und damit beide Vertragspartner in arge Schwierigkeiten bringen. Beispielsweise kann es sich um die verbindliche Zusage eines Liefertermins handeln, der von einem Dritten, der durch "Zufall" die E-Mail abfing, leicht verändert wurde. Es reicht ja bereits, wenn die angekündigte Kalenderwoche mit dem Liefertermin manipuliert wird. Für solche verbindlichen Dinge ist eine im Klartext übertragene E-Mail ohne weitere Maßnahmen denkbar ungeeignet. Prinzip der Digitalen Signatur Beim Einsatz einer digitalen Signatur muß vorweg betont werden, daß es sich hierbei lediglich um ein Verfahren handelt, mit dem die Echtheit und der Absender sicher bestimmbar sind. Vertrauliche Datenübertragung kann durch ein Signieren der übertragenen Daten grundsätzlich nicht erreicht werden. Hierzu ist die Verschlüsselung der Daten notwendig. Der parallele Einsatz einer digitalen Signatur erhöht die Sicherheit bei einer verschlüsselten Datenübertragung, ersetzt sie aber nicht. Bei asymmetrischen Verschlüsselungsverfahren wird mit zwei Schlüsseln gearbeitet, dem geheimen und dem öffentlichen Schlüssel. Der öffentliche Schlüssel ist prinzipiell bekannt und steht jedem zur Verfügung. Um eine digitale Signatur zu erzeugen, kann der Absender beispielsweise den Text mit seinem geheimen Schlüssel verschlüsseln und die Daten dann in dieser Form übertragen. Wichtig ist hier nochmals der Hinweis, daß es sich dabei nicht um eine vertrauliche Datenübertragung handelt, auch wenn die Daten selbst verschlüsselt sind! Jeder kann den öffentlichen Schlüssel haben und demnach auch die verschlüsselten Daten auch wieder entschlüsseln. Durch die Verschlüsselung der Daten wird aber erreicht, daß nachgewiesen ist, von wem die Daten stammen. Genau betrachtet ist formal aber nur nachgewiesen, daß sie mit dem zum vorliegenden öffentlichen Schlüssel passenden geheimen Schlüssel verschlüsselt wurden. Problematik großer Datenmengen und die Lösung Soll eine große Menge von Daten digital signiert werden, hat die eben vorgestellte Methode einen erheblichen Nachteil. Bei asymmetrischen Verschlüsselungsverfahren wird mit sehr großen Zahlen gearbeitet. Daher ist der zeitliche Aufwand für das Ver- und Entschlüsseln sehr hoch, wodurch das eben genannte Prinzip eigentlich für große Datenmengen unbrauchbar ist. Um den Zeit- und Rechenaufwand gering zu halten, werden die Vorteile einer digitalen Signatur mit denen von Hashfunktionen kombiniert. Der Ablauf kann also wie folgt sein: Der Absender schreibt beispielsweise einen längeren Text, den er dann später signiert per E-Mail an einen Geschäftspartner übertragen möchte. Wenn er den Text fertig geschrieben und die entsprechenden Korrekturen gemacht hat, wendet er eine Hashfunktion wie beispielsweise MD-5 an. Das Ergebnis ist ein Hash, auch Message Digest genannt, mit einer Länge von 128 Bit. Dieser Hash wird dann mit dem geheimen Schlüssel des Absenders verschlüsselt und an die E-Mail angehängt.
Der Empfänger liest die E-Mail des Absenders und hat grundsätzlich zwei Möglichkeiten. Die erste ist bei den meisten Anwendern zu finden: der enthaltene Text wird einfach geglaubt. Kritische Zeitgenossen werden aber schnell entdecken, daß eine digitale Signatur angehängt ist. Sie entschlüsseln sie mit dem öffentlichen Schlüssel des Absenders und erhalten so den Hash, den der Absender mit seinem geheimen Schlüssel verschlüsselt hat. Bei einer solchen E-Mail ist mit angegeben, welcher Algorithmus für die Bildung des Hashes eingesetzt wurde. Diesen nimmt der Empfänger und wendet ihn auf den Text der E-Mail an. Er erhält einen Hashwert, der jetzt mit dem entschlüsselten Hashwert des Absenders verglichen wird. Sind beide gleich, ist sichergestellt, daß der Text wirklich vom Absender stammt und auf dem Weg nicht manipuliert wurde.
Abbildung 5: Prinzip der digitalen Signatur am Beispiel einer E-Mail Wenn eben leicht optimistisch behauptet wurde, daß der Text wirklich vom Absender stammt, muß diese Behauptung relativiert werden. Streng genommen ist lediglich sicher, daß der Hash mit dem zum vorliegenden öffentlichen Schlüssel passenden geheimen Schlüssel verschlüsselt wurde - mehr nicht. So kann beispielsweise ein Angreifer seinen öffentlichen Schlüssel unter falschem Namen an den Empfänger schicken. Dieser glaubt dann alle Nachrichten, die vermeintlich von einem vertrauenswürdigen Absender stammen. Trust Center und Zertifikate zur Echtheitsbestätigung von Schlüsseln Prinzipiell ist mit der Einführung digitaler Signaturen ein Mechanismus vorhanden, über den der Empfänger von Daten kontrollieren kann, ob die Nachricht während der Übertragung verändert wurde. Dazu nutzt er den öffentlichen Schlüssel zum Entschlüsseln des angehängten Hashes und kontrolliert ihn, indem er selbst den gleichen Hash-Algorithmus auf die Daten anwendet. Stimmen beide Hashes überein, sind die Daten echt. Damit ist sichergestellt, daß die beiden Schlüssel korrespondieren. Eigentlich ist keine weitere Aussage möglich, wenn nicht kontrolliert wurde, zu wem dieses Schlüsselpaar tatsächlich gehört. An dieser Stelle könnte der Autor durchaus seinen eigenen öffentlichen Schlüssel bekannt geben und viele Leser würden glauben, daß es sich tatsächlich um den öffentlichen Schlüssel von Matthias Leu handelt. Zumindest die Leser, die den Autor und seine Art zu schreiben kennen, würden eventuell tatsächlich glauben, daß es sich um den richtigen Schlüssel handelt. Aber: Nachgewiesen, daß es sich um den richtigen Schlüssel zur richtigen Person handelt, ist nichts. Diese Problematik taucht besonders im Internet auf. Dort ist es üblich, daß Personen ihren öffentlichen Schlüssel anderen frei zugänglich zur Verfügung stellen. Einerseits geschieht dies dadurch, daß der öffentliche Schlüssel auf dem Web- oder FTP-Server abrufbar ist oder per E-Mail zugestellt wird. Besonders bei diesen Übertragungsmethoden ist aber nicht sichergestellt, ob nicht doch der öffentliche Schlüssel manipuliert oder ausgetauscht wurde. Besser ist es, wenn die öffentlichen Schlüssel auf Key-Servern hinterlegt werden. Bei großen Key-Servern besteht auch die Möglichkeit, nach Namen zu suchen. Durch eine solche Anfrage wird der entsprechende öffentliche Schlüssel, der zu dem gesuchten Namen gehört, herausgesucht und angezeigt. Das Grundproblem ist aber, daß die verbindliche Zuordnung des öffentlichen Schlüssels zum Namen nicht gegeben ist. Beispielsweise besteht kein Zwang für Benutzer, beim Generieren des Schlüsselpaars und dem Hinterlegen des öffentlichen Schlüssels auf den entsprechenden Servern auch wirklich den richtigen Namen anzugeben. Um sicher zu sein, daß die Zuordnung wirklich stimmt, muß also eigentlich jemand, dem vertraut wird, bestätigen, daß es der richtige Schlüssel ist, der genau dieser Person zugeordnet ist. Diese vertrauenswürdigen Stellen heißen Trust Center oder auch Certificate Authorities, kurz CA. Gültigkeitsdauer von Schlüsseln Sofern öffentliche Schlüssel publik gemacht und kommerziell genutzt werden, sollte sich jeder Benutzer überlegen, wie lange er sein Schlüsselpaar benutzen möchte. Im privaten Bereich ist diese Gültigkeitsdauer nicht so kritisch: Ein Benutzer kann ein Schlüsselpaar generieren und festlegen, daß diese Schlüssel immer und ewig gelten sollen. Bei einer kommerziellen Nutzung ist die Frage, ob ein solches Vorgehen sinnvoll ist. Die Schlüssel sind an Personen gebunden und nicht an ein Unternehmen. Das ist der erste Grund, warum eine zeitliche Beschränkung der Gültigkeit sinnvoll ist. Was passiert, wenn der Mitarbeiter, dem die Schlüssel gehören, nach drei Jahren das Unternehmen verläßt? Vielleicht wäre es hier sinnvoller, die Schlüssel jeweils immer nur ein Jahr gelten zu lassen. Ist dieser Zeitraum abgelaufen, wird ein neues Schlüsselpaar generiert und der neue öffentliche Schlüssel beim Trust Center hinterlegt. Ein anderes Argument für die zeitliche Beschränkung der Gültigkeitsdauer ist auch, daß vielleicht in fünf Jahren die bisher angewendeten Schlüssellängen als nicht mehr zeitgemäß angesehen werden, weil sich die verfügbare Rechenleistung zur Durchführung von Brute-Force Angriffen verhundertfacht hat. Werden immer wieder neue Schlüsselpaare generiert, besteht die Möglichkeit, so auf dem Stand der Zeit zu bleiben. Eine weitere Möglichkeit, die gegeben sein muß, ist das kontrollierte Zurückziehen öffentlicher Schlüssel. Es müssen Listen zur Verfügung stehen, in denen abzurufen ist, daß ein Zertifikat nicht mehr gültig ist, auch wenn die offizielle Gültigkeitsdauer noch nicht abgelaufen ist. Solche Listen heißen Certificate Revocation Lists, kurz CRL. Sie werden von den jeweiligen Trust Centern geführt. Kommt eine Anfrage nach einem Zertifikat, das auf einer solchen Liste steht, wird lediglich bestätigt, daß dieses Zertifikat mit der entsprechenden Seriennummer zurückgezogen oder ungültig wurde. Die Clients müssen diese Listen tatsächlich nutzen, damit die gewünschte Sicherheit erreicht wird. Warum ist es sinnvoll, solche Listen zu führen? Einerseits gelten solche Listen als Verzeichnis von Schlüsseln, die einmal gültig waren, es zum jetzigen Zeitpunkt aber nicht mehr sind. Aber auch von der Norm abweichende Situationen können fordern, daß die Schlüssel nicht mehr gültig sind. Beispiele hierfür sind, wenn der geheime Schlüssel, aus welchen Gründen auch immer, kompromittiert wurde oder aber der Benutzer sein Paßwort für die Benutzung des geheimen Schlüssels vergessen hat. Zertifikate Bei Trust Centern wird mit Zertifikaten gearbeitet, mit denen die Echtheit des öffentlichen Schlüssels bestätigt wird. Zertifikate gibt es in verschiedenen Stufen und dementsprechend ist auch die Qualität von Zertifikaten unterschiedlich. Grundsätzlich ist aber allen Zertifikaten gemeinsam, daß sie vom Trust Center ausgegeben werden. Es handelt sich hierbei um Informationen, die unter anderem der öffentlichen Schlüssel einer Person enthalten und mit dem geheimen Schlüssel des Trust Centers digital signiert sind.
Abbildung 6: Prinzip eines Zertifikates Der Empfänger einer E-Mail kann also den öffentlichen Schlüssel des Absenders über einen Trust Center beziehen. Durch die Entschlüsselung des angehängten Hashwerts und Vergleich mit dem direkt erhaltenen Wert kann er also sicher sein, daß er den richtigen öffentlichen Schlüssel des Absenders vorliegen hat. Um den Vergleich machen zu können, muß er vorher den öffentlichen Schlüssel des Trust Centers besitzen. Ganz wichtig ist hier, daß der Nutzer sicher ist, den richtigen öffentlichen Schlüssel zu besitzen. Es kommen heute Methoden zur Überprüfung dieses Schlüssels zum Einsatz, die auch über einen direkten Kontakt oder andere vertrauenswürdige Wege gehen. Neben dem öffentlichen Schlüssel einer Person können in einem Zertifikat auch weitere Informationen enthalten sein. Diese Informationen können beispielsweise weitere Daten über die Person sein, zu der dieser öffentliche Schlüssel gehört. Beispiele für Zertifikate sind in Abbildung 7 dargestellt.
Abbildung 7: Beispiele für Zertifikatsklassen Aus diesen Beispielen wird deutlich, daß nicht alle Zertifikate gleichwertig sind. Beispielsweise kann jeder auch unter falschem Namen ein Zertifikat der Klasse 0 beantragen, da keine weitere Kontrolle stattfindet. Auch die Klasse 1 ist nicht viel besser, wenn berücksichtigt wird, wie leicht E-Mail Adressen bei verschiedenen Institutionen beantragt werden können. Hat irgend jemand bei beispielsweise Hotmail die Möglichkeit zu überprüfen, wer wirklich hinter einem Account für E-Mail steckt? Etwas, aber nicht viel sicherer ist die Klasse 2, bei der zumindest eine Telefonnummer funktioniert. Damit ist aber noch lange nicht sicher, wer das Telefon beantwortet hat. Es ist höchstens zu bewerten, daß sich eine männliche Stimme mit diesem Namen auf einen Anruf hin gemeldet hat. Lediglich die oben als Klasse 3 bezeichnete Möglichkeit bietet Sicherheit, indem nämlich zusätzlich ein offizielles Dokument vorlag und vom Trust Center kontrolliert wurde. Im Kapitel über die Authentisierung von Benutzern durch Account Units wurde bereits das Thema LDAP und der Standard X.500 kurz beschrieben. Wichtig ist der Distinguished Name DN, also der vollständige Name des Benutzers innerhalb des LDAP-Servers. Für Zertifikate gibt es ebenfalls einen Standard: X.509. Nach ihm enthalten Zertifikate neben dem eigentlichen öffentlichen Schlüssel und dem Namen des Benutzers weitere Daten. Insgesamt sind derzeit drei verschiedene Versionen bekannt, die aufeinander aufbauen. X.509v1 Diese erste Version von X.509 arbeitet mit den grundlegenden Informationen, die eine sichere Zuordnung eines öffentlichen Schlüssels an eine Person zulassen.
Über die genannten Informationen wird ein Hash-Algorithmus angewendet. Der resultierende Hash wird dann mit dem geheimen Schlüssel des Trust-Centers unterschrieben. Durch ein solches Zertifikat hat der Anwender die Information, daß der Schlüssel wirklich zu der im Zertifikat angegebenen Person gehört. X.509v2 In diesem Standard sind neben den im vorherigen Standard enthaltenen Daten zusätzlich noch im Zertifikat genannt:
Zusätzlich sind alle Informationen des X.509v1 enthalten. X.509v3 Dieser Standard, der heute sehr weit verbreitet ist, gestattet es, sehr viele Informationen über den Benutzer und das Trust Center zu verbreiten. Erinnert sei an dieser Stelle nochmals, daß die Informationen durch das Trust Center bestätigt sind – ihnen also Vertrauen entgegengebracht werden kann. Nachfolgend ein Beispiel für ein solches Zertifikat:
Abbildung 8: Beispiele für ein Zertifikat nach X.509v3 In diesen Zertifikaten können auch weitere Informationen enthalten sein. Das geht soweit, daß beispielsweise darin auch Informationen über die Kreditwürdigkeit von Personen enthalten sein können. Die Betonung liegt hier allerdings auf dem letzten Wort. PKI Die gesamte Infrastruktur, die für die Erstellung, Verwaltung und Ausgabe von Zertifikaten in Verbindung mit Trust-Centern steht, wird Public Key Infrastructure, kurz PKI, genannt. Dieser Begriff ist leicht zu merken, weil die gesamte Problematik hauptsächlich für die Verwaltung der öffentlichen Schlüssel und deren sichere Zuordnung zu Personen umfaßt. Dieses ist der Hauptauslöser für die Einrichtung einer PKI. Die zur Verwaltung notwendige Umgebung setzt neben einer Software weitere Maßnahmen voraus. Hierzu gehört der ausfallsichere und vor allem sichere Betrieb der Server, von denen die Zertifikate abzurufen sind. Dazu gehört aber auch, daß nur vertrauenswürdiges Personal in Trust Centern beschäftigt wird und auch die baulichen Maßnahmen geeignet sind, die notwendige Sicherheit zu garantieren. Ansonsten besteht das Risiko, daß, wenn schon kein unberechtigter Zugang über das Netzwerk möglich ist, der »klassische« Weg gewählt wird. Einbrecher dringen in das Gebäude ein, schalten die Server mit den Zertifikaten einfach aus oder ersetzen sie durch eigene Maschinen. Für die Umsetzung ist zusätzlich eine Software notwendig. Hier gibt es verschiedene Ansätze, die von unterschiedlichen Herstellern angeboten werden. Um eine funktionierende Zusammenarbeit zwischen der FireWall-1 beziehungsweise VPN-1 und einer PKI zu erreichen, ist eine Kompatibilität des Produkts von Check Point mit dem Hersteller der PKI notwendig. Seit Version 4.0 wird der Einsatz einer PKI grundsätzlich von Check Point unterstützt. Die Lösung von Entrust ist besonders in den USA sehr weit verbreitet. Mit Version 4.1 werden aber auch andere Hersteller unterstützt. Heute unterstützt Next Generation die Lösungen von Baltimore (UniCERT PKI), Entrust (Entrust/PKI), iPlanet (Certificate Management System, CMS), RSA Security (RSA Keon), SSH Communications Security (SSH Certifier) und VeriSign (Go Secure!). Damit steht eine breite Basis auch von Drittherstellern zur Verfügung, um die Next Generation in bestehende PKIs zu integrieren. Diese PKIs werden einerseits unternehmensintern eingesetzt, aber auch von offiziellen und staatlichen Stellen. Eine aktuelle Übersicht unterstützter PKIs findet sich unter http://www.opsec.com/solutions/sec_pki.html.
Abschließend noch ein Wort über die allgemeine Problematik bei Trust-Centern. Bisher wurde immer davon ausgegangen, daß ein Trust Center die vertrauenswürdige Stelle ist, über die Zertifikate und damit die öffentlichen Schlüssel von Personen sicher und verifiziert bezogen werden können. Trust Center sind im Bereich E-Business ein Schlüsselfaktor – und damit stellt sich im Prinzip die Frage, wie vertrauenswürdig Trust Center eigentlich selbst sind. Sie werden aus kommerziellen Gründen betrieben und damit besteht prinzipiell eine Gefahr, daß sich geschäftstüchtige Personen &qout;mal eben&qout; an diesem Kuchen beteiligen wollen. Übertrieben wäre sicherlich, daß sich eine Person mit einem virtuellen Web-Server im Internet auf der CeBIT in Hannover oder der Systems in München einen Mini-Stand aufbaut und große Plakate mit dem Wort &qout;Trust Center&qout; aufhängt. Jeder kann gegen eine Gebühr seinen öffentlichen Schlüssel abgeben, eine Überprüfung des Personalausweises findet statt. Sollte aber ein falscher Personalausweis vorgelegt werden, ist dies auch kein Problem: gegen die zehnfache Gebühr wird auch dieser anerkannt – schließlich ist man ein auf Profit ausgerichtetes Unternehmen... Solch ein Fall ist sicherlich in Deutschland (noch?) nicht zu finden. Aber die Problematik ist deutlich. Insofern ist es notwendig, daß für die rechtsgültige Anerkennung einer digitalen Signatur auch von staatlichen Stellen Trust Center zertifiziert sein müssen beziehungsweise sollten. In Deutschland gibt es seit 1997 das Signaturgesetz (SigG), das Bestandteil des Gesetzes des Bundes zur Regelung der Rahmenbedingungen für Informations- und Kommunikationsdienste ist. Praktisch ist es am 28. September 1998 in Kraft getreten. An diesem Tag wurde die sogenannte Wurzelinstanz in Betrieb genommen. Damit ist gemeint, daß eine staatliche PKI, die von der RegTP betrieben wird, vorhanden ist, die öffentliche Schlüssel zertifizierter Trust Center in Form von Zertifikaten bereit hält. Um eine solche Zertifizierung zu erhalten, muß der Maßnahmenkatalog des Bundesamtes für Sicherheit in der Informationstechnologie, BSI, eingehalten und die Umsetzung überprüft sein. Derzeit sind nur wenige Trust Center nach diesem Gesetz staatlich anerkannt: Das Produktzentrum TeleSec der Deutschen Telekom AG (http://www.telesec.de), Signtrust der Deutsche Post eBusiness GmbH (http://www.signtrust.de) und das der Bundesnotarkammer (http://dir.bnotk.de). Weitere Institutionen sind die DATEV eG und Steuerberaterkammern Nürnberg, Saarland, Bremen, München, Berlin, und Stuttgart sowie die Rechtsanwaltskammern Koblenz und Bamberg (alle http://www.zs.datev.de) und die Medizon AG (http://dir.medizon.de). Weitere Unternehmen befinden sich gerade in der Zertifizierungsphase. Durch die Zertifizierung einzelner Trust Center ist neben der grundsätzlichen Vertrauenswürdigkeit auch sichergestellt, daß die Rahmenbedingungen dem Gesetz entsprechen. So darf beispielsweise eine digitale Signatur nicht automatisch getätigt werden, der geheime, private Schlüssel muß sich auf einer SmartCard befinden und auch die baulichen Gegebenheiten des Trust Centers müssen den Bestimmungen entsprechen. Neben den staatlich zertifizierten Trust Centern gibt es in Deutschland noch weitere, die sicherlich auch Vertrauen verdienen. Unternehmen können sich darauf verständigen, welche Trust Center sie als vertrauenswürdig ansehen und dem entsprechend handeln. Auch besteht im Bereich E-* nicht der Zwang, daß nur solche PKIs zum Einsatz kommen, die staatlich anerkannt sind. Durchaus berechtigt ist beispielsweise die Einigung von zwei Unternehmen, für deren gegenseitige Bestätigung der Echtheit von E-Mail PGP einzusetzen. PGP ist nach dem Gesetz zur Digitalen Signatur in Deutschland aus verschiedenen Gründen nicht anerkannt. Insgesamt bilden Trust Center für den heute immer wichtigeren Bereich vertraulicher und gleichzeitig verbindlicher
Datenübertragung über nicht vertrauenswürdige Netzwerke eine Art Rückgrat, dessen Bedeutung in den nächsten Jahren noch
erheblich zunehmen wird. |
|||||||||||||||||||||
|
Dieser Server wird gesponsert von |
