Datenschutz ELK-WUE

<?xml version="1.0" encoding="ISO-8859-1" ?> <?xml-stylesheet type="text/xsl" href="dsbweb.xsl"?> DATENSCHUTZ evangelische Landeskirche Württemberg: Praxis Zertifikate Seite Sichere eMail durch Zertifikate des DATENSCHUTZWEBs Kirche, Datenschutz, Praxis, Signatur, Sichere eMail, Zertifikate, Download, Übungssoftware, Zertifizierungsstelle, Sicherheitsanforderungen, OpenSSL, Wurzelzertifikat, Signaturgesetz, Trustcenter Dr. Axel Gutenkunst dsb@elk-wue.de 2001-04-25 <Überschrift> Praxis Sichere eMail durch Zertifikate Praxis Download von Übungssoftware für Zertifikate Mit Hilfe von OpenSSL-Software aus dem Internet wurde eine Übungsdiskette erstellt, die es auf einfache Weise erlaubt, sowohl Wurzelzertifikate als auch Benutzerzertifikate im X.509v3 Format zu erstellen und im kleinen Kreis auszuprobieren. Die hinter den Begriffen wie öffentliche/private Schlüssel und Zertifikaten stehenden Funktionalitäten sind nicht einfach. Für eine Beurteilung, inwieweit diese Verfahren geeignet sind, Datenschutzbelange umzusetzen, kann ein eigenständiges Ausprobieren innerhalb einer kleinen Testgruppe hilfreich sein. Genau zu diesem Zweck wurde die nachfolgende Software zusammengestellt. In diesem Abschnitt geht es ausschliesslich darum, das technische Verfahren für Testzwecke aufzusetzen. Das verwaltungsmäßige Verfahren sowie die Diskussion der Risiken geschieht in den nachfolgenden Abschnitten. Zum Download der entsprechenden Zip-Datei bitte hier klicken: http://ilias-elk-wue.de/drupal6/sites/default/files/openssl.zip " sprache="dsb" zip="zip">Zertifikate Es wird dabei das Betriebssystem Windows 9x oder aktueller vorausgesetzt. Für die Verwendung dieser Programme ist entscheidend, dass die angelegte Ordnerstruktur eingehalten wird. Achten Sie deshalb beim Extrahieren bitte darauf, dass die Option Pfadangaben verwenden aktiviert ist. Die Ordnerstruktur kann auch auf einer Diskette angelegt werden! Sie muß mit z.B. a:\usr beginnen, im Ordner usr befindet sich der Ordner local usw. Folgendes kann mit Hilfe der Übungsdiskette durchgeführt werden: Erstellen eines Wurzelzertifikats. Dazu ist die Stapeldatei cawurzel.bat zu starten. Durch einen Einblick in diese Datei mit einem Editor kann der entsprechende openSSL-Befehl angesehen werden. Als Kennwort zum Probieren gibt man am besten lolli ein, da dieses in den nachfolgenden Stapeldateien bereits eingetragen ist. Als Ergebnis dieses Befehls befindet sich im Ordner bin die Datei cacert.pem und im Unterordner private die Dateien RND und cakey.pem. cakey.pem wäre im Ernstfall der private Schlüssel der Zertifizierungsstelle, der niemals in falsche Hände kommen dürfte. Das Binärformat eines Zertifikates ist nach ASN.1 codiert. Die Regeln der Codierung folgen den Distinguished Encoding Rules (DER). Das oben erzeugte PEM (Privacy Enhanced Mail) Format ist jedoch ein in BASE64 codiertes Zertifikat, das noch durch die Zeilen -----------BEGIN CERTIFICATE ------------ und -----------END CERTIFICATE --------------- am Anfang und Ende ergänzt ist. Um das erzeugte Wurzelzertifikat in den Internet Explorer importiert zu bekommen, muß in das DER Format konvertiert werden. Dazu ist die Stapeldatei cader.bat zu starten. Durch einen Einblick in diese Datei mit einem Editor kann der entsprechende openSSL-Befehl angesehen werden. Erstellen einer Anforderung für ein Zertifikat. Dazu ist die Stapeldatei demoreq.bat zu starten. Durch einen Einblick in diese Datei mit einem Editor kann der entsprechende openSSL-Befehl angesehen werden. Bei dieser Anforderung werden die beiden Dateien demoreq.pem (öffentlicher Schlüssel, ergänzt durch Identifikationsinformationen) und demokey.pem (der von der anfordernden Person geheim zu haltende private Schlüssel) erzeugt.Zertifizieren der mit demoreq.bat erstellten Zertifikatsanforderung. Dazu ist die Stapeldatei democert.bat zu starten. Durch einen Einblick in diese Datei mit einem Editor kann der entsprechende openSSL-Befehl angesehen werden. Hier schließt das zugrundeliegende Programm openssl.exe mit einer Fehlermeldung bezüglich einer Umbenennung von Dateien ab. Durch Ausführen von korrekt.bat kann dieser Mangel behoben werden. In diesem Schritt wird die Datei democert.pem erzeugt, d.h. die durch die digitale Unterschrift mit dem Wurzelzertifikat als korrekt bestätigte Anforderung. Im Unterordner "newcerts" des Ordners "bin" wird eine durchnummerierte Kopie davon abgelegt, also 01.pem. Die Datei serial wird um eins erhöht, in der Textdatenbank index.txt erfolgt ein Eintrag über das erzeugte Zertifikat. Um das fertige Zertifikat in den Internet Explorer importieren zu können, muß die Datei democert.pem in das PKCS12-Format umgeschrieben werden. Dazu ist die Stapeldatei demopfx.bat zu starten. Bei der Ausführung des Programms muß man den "geheimzuhaltenden" privaten Schlüssel angeben, den man bei der Erstellung der Zertifikatsanforderung gewählt hat. Um den geheimen Schlüssel bis zum Import in den Browser zu schützen, muß zusätzlich ein Export-Paßwort angegeben werden. Beim Import in den Internet Explorer wird nach diesem Kennwort gefragt. Erstellen eigener Zertifikate. Dazu speichert man, um die Übersicht zu wahren, zunächst die verwendeten Stapeldateien demoreg.bat, democert.bat und demopfx.bat unter geeigneten sprechenden Namen ab, z.B. "ben1req.bat, ben1cert.bat und ben1pfx.bat". In einem zweiten Schritt ändert man mit einem Editor die Dateien inhaltlich um, die Datei "ben1req.bat" enthält dann den Eintrag: "openssl req -new -out ben1req.pem -keyout ben1key.pem -newkey rsa:512" Entsprechend enthält die Datei ben1cert.bat den Eintrag: openssl ca -in ben1req.pem -out ben1cert.pem -key lolli ("lolli" steht dabei für das Kennwort, das man bei der Erzeugung des Wurzelzertifikates angegeben hat. Diese Angabe ist nur erforderlich, weil sonst das Programm openssl.exe mit einer Fehlermeldung abbricht. Es sei darauf hingewiesen, dass es hier darum geht, wesentliche Abläufe bei der Entstehung von Zertifikaten zu erkennen. Es soll nicht ernsthaft eine Zertifizierungsstelle betrieben werden.) Analog gilt für die Datei ben1pfx.bat: openssl pkcs12 -in ben1cert.pem -out ben1cert.pfx -export -inkey ben1key.pem -name "Benutzer1" Die so erzeugten Dateien führt man dann in dieser Reihenfolge aus (bitte "korrekt.bat" zum Abschluß nicht vergessen). Beim Ausführen von ben1req.bat macht man entsprechende Benutzerangaben zu den erscheinenden Eingabeaufforderungen. Entscheidend ist die Angabe der eMail-Adresse, da dann darüber z.B. beim Import in Outlook die Zuordnung zu den Zertifikaten stattfindet. Anmerkung: Die Übungssoftware wurde zusammengestellt, um Interessierten ein grundlegenderes Verständnis zu ermöglichen, was beim Zertifizieren, bei der digitalen Unterschrift und beim Verschlüsseln vor sich geht, nicht um damit eine Zertifizierungsstelle in größerem Umfang zu betreiben. Gut möglich ist jedoch, innerhalb eines kleinen Kreises von Testpersonen oder in der Bekanntschaft die Dinge auszuprobieren. Falls mit OpenSSL eine Zertifizierungsstelle betrieben werden soll, sei auf die sehr empfehlenswerte Seite DFN-Cert Zentrum für sichere Netzdienste GmbH verwiesen. Dort findet sich insbesondere das Open SSL-Handbuch und weitere sehr nützliche Materialien. Einfügen des Zertifikates in den Browser Wie bekommt man nun das selbsterzeugte Wurzelzertifikat und die selbsterzeugten Benutzerzertifikate in den Zertifikatsspeicher des Internetexplorers? Dazu ist wie folgt vorzugehen: Um das Wurzelzertifikat zu importieren, gibt man in der Eingabezeile des Internetexplorers den Pfad zur Datei cacert.der an, also beispielsweise "a:\usr\local\bin\cacert.der", danach bestätigt man die Eingabe. Sollte der Hinweis erscheinen (hängt von der verwendeten Version des Internet Explorers ab), dass das Stammzertifikat nicht vertrauenswürdig sei, ist dies korrekt. Genau durch den Akt des Imports wird diesem Zertifikat das Vertrauen ausgeprochen!. Unter "Ansicht/Internetoptionen/Inhalt" können unter "Agenturen" die anderen in der Regel bereits vorhandenen Zertifizierungsstellen eingesehen werden, denen Sie bereits Ihr Vertrauen ausgesprochen haben. Möglicherweise sind diese Zertifikate bereits abgelaufen. Auch Benutzerzertifikate werden über die Registerkarte "Ansicht/Internetoptionen/Inhalt" des Internet Explorers in den Zertifikatsspeicher importiert. Auf dieser Registerkarte ist nun die Schaltfläche "Eigene" anzuklicken. In die entsprechende Eingabezeile wird der Pfad zur erzeugten pfx-Datei eingetragen, also beispielsweise "a:\usr\local\bin\democert.pfx". In einer weiteren Eingabezeile ist das Exportkennwort, das man bei der Erzeugung der pfx-Datei gewählt hat, einzugeben. Damit ist das selbsterzeugte Benutzerzertifikat importiert. Wie verteilt man nun seinen öffentlichen Schlüssel beispielsweise in einer Testgruppe oder im Bekanntenkreis? Dies geschieht einfach, indem Sie diesen Personen eine von ihnen signierte eMail zusenden. Das Signieren schalten Sie z.B. in Outlook über die Registerkarte "Extras/Optionen/Sicherheit" ein. Dort kann die Option "Ausgehenden Nachrichten eine Signatur anfügen" angeklickt werden, über die Schaltfläche "Einstellungen" kann festgelegt werden, welches Benutzerzertifikat dabei zur Anwendung kommen soll. Bei diesem Stand erhalten die Empfänger Ihrer eMails eine Meldung, dass die eingehende eMail eine Signatur einer nicht vertrauenswürdigen Zertifizierungsinstanz enthält. Diese Meldung verschwindet, wenn Sie den Empfängern Ihr Wurzelzertifikat, also z.B. "cacert.der" z.B. als eMail-Anhang zukommen lassen und diese es importieren, wie oben beschrieben. Durch den Akt des Importierens sprechen sie diesem Wurzelzertifikat das Vertrauen aus. Es ist dieses gemeinsame Wurzelzertifikat, das die Gruppe gegenseitigen Vertrauens definiert. Empfangene öffentliche Schlüssel werden von den meisten eMail-Clients automatisch in das Adressbuch aufgenommen. Öffentliche Schlüssel müssen also nicht extra noch importiert werden. Falls es doch notwendig sein sollte, stehen Export-Funktionen zu Verfügung, mit denen öffentliche Schlüssel exportiert und den Empfänger z.B. als eMail-Anhänge zugeschickt werden können. Hat man den öffentlichen Schlüssel einer Person oder Stelle, kann man auch verschlüsselte Nachrichten übermitteln. Dazu muß auf der entsprechenden Registerkarte die Option "Inhalte und Anlagen für ausgehende Nachrichten verschlüsseln" ausgewählt werden. Für eine Vertiefung dieses Themas sei das Buch Verschlüsselung im betrieblichen Einsatz von Rainer W. Gerling beim DATAKONTEXT-FACHVERLAG, ISBN 3-89577-139-2 empfohlen. Sicherheitsanforderungen an die Zertifizierungsstelle Die Zertifikate sind vergleichbar mit Personalausweisen, die ausgegeben werden und die von den betreffenden Personen dazu verwendet werden sich auszuweisen. Diejenigen, gegenüber denen sie sich ausweisen, vertrauen darauf, dass die Angaben stimmen. Meist hat die Aufforderung, sich auszuweisen, einen Grund, z.B. im eMail-Verkehr zwischen einem vertrauenswürdigeren engeren Kreis und dem Rest der Welt zu unterscheiden. Zertifikate können auch eingekauft werden. Ein genauer Preis-Leistungsvergleich ist mir nicht bekannt, deshalb folgende Anhaltspunkte: Das TrustCenter von Web.de bietet kostenlose Zertifikate für eMails "ohne umständliche Authentifikation" an. Damit ist der eigentliche Sinn der Zertifikate verfehlt, aber für Testzwecke sind die Zertifikate vielleicht brauchbar. Die Telekom bietet ebenfalls Zertifikate an, die Preise können einer Preisliste der entsprechenden Webseite entnommen werden. Ein Server-Zertifikat kostet etwa 220 € pro Jahr, ein einzelnes Benutzerzertifikat ist für 7,60 € zu haben. Diese Seite enthält auch Erläuterungen zu den Zertifikaten und wie man damit umgeht. Die Firma DSEK-Datenschutz e.K. in Würzburg verlang für ein SSL-Zertifikat für die sichere Übertragung von Webservern 324.-DM pro Jahr. Es muß unterschieden werden zwischen Zertifikaten, die dem Signaturgesetz genügen und die nur in zertifizierten Trust-Centern unter scharfen Sicherheitsbestimmungen erzeugt werden und solchen die diesen Anforderungen nicht genügen. Sofern ein Unternehmen oder eine Institution für eigene interne Zwecke selbst Zertifikate erzeugt und verteilt, genügen diese nicht dem Signaturgesetz, d.h. erlangen keine Rechtsverbindlichkeit. Die Benutzer sollten darauf von vornherein hingewiesen werden. Für ein Unternehmen oder eine Institution, die selbst für interne Zwecke Zertifikate ausstellt und nutzt, ist entscheidend, dass sie von Anfang an mit grosser Sorgfalt agiert. Vertrauen ist leicht und schnell verloren, es ist dagegen mühselig und braucht Zeit, es zu gewinnen. Dass die selbsterzeugten Zertifikate nicht dem Signaturgesetz genügen heißt nicht, dass sie zweitklassig sind, sie haben lediglich einen anderen Zweck, für den die (teuer einzukaufende) Rechtsverbindlichkeit nicht benötigt wird. Es sollte von vornherein organisatorisch strikt zwischen Anordnung und Vollzug unterschieden werden. Die anordnende Person bestimmt wer ein Zertifikat mit welchen Angaben bekommen soll, die vollziehende Person schafft die edv-technischen Gegebenheiten, d.h. zertifziert die entsprechende Anforderung und stellt die Zertifikate zu. Um die strikte Trennung zwischen Anordnung und Vollzug technisch durchzusetzen, kann es angebracht sein, der vollziehenden Person keine Löschrechte auf die Liste der erstellten Zertifikate und die Nummernvergabe zu geben (in obigem Beispiel index.txt und serial). Damit kann die anordnende Person immer kontrollieren, ob ausschließlich angeordnete Zertifikate mit den korrekten Inhalten erstellt wurden. Der private Schlüssel der Zertifizierungsstelle (im Beispiel cakey.pem) und Kopien davon sollten sicher verwahrt werden. Bekommt jemand unberechtigt Zugriff auf diesen privaten Schlüssel, kann er eigenmächtig und unkontrolliert Zertifikate seiner Institution oder seines Unternehmens erstellen und in Umlauf bringen. Dann wieder zu klaren Verhältnissen zu kommen kann einen erheblichen Aufwand bedeuten und ist immer mit einem Vertrauensschaden verbunden. Durch Zugriffsrechte sollte auch gewährleistet sein, dass die anordnende Person den privaten Schlüssel oder Kopien davon nicht von ihrem Arbeitsplatz entfernen kann. Für Unternehmen oder Institutionen bietet sich an, zwischen Zertifikaten für Stellen, Bereiche, Abteilungen, Funktionalitäten und Zertifikaten für Personen zu unterscheiden. Ersteren kann eine längere Lebensdauer gegeben werden. Hier steht nicht die Person, sondern das Amt oder die Aufgabe im Vordergrund. Konflikte zwischen privat und dienstlich können so von vornherein vermieden werden. Für nichtpersonengebundene Zertifikate ist es auch unproblematischer, Kopien der privaten Schlüssel an geeigneter Stelle zu hinterlegen, es sei den, es sind besondere Geheimhaltungspflichten zu beachten. Damit sind auch verschlüsselte eMails z.B. für Vertretungen oder Vorgesetzte immer lesbar, wie es auch bei konventionelle Briefen der Fall wäre. Hier liegt jedoch wohl das eigentliche zu klärende organisatorische Problem, die edv-technische Umsetzung ist meist harmloser. Es sollte geklärt sein, wie die Inhaber der Zertifikate mit den zugehörigen privaten Schlüsseln umgehen. Sofern personenbezogene Zertifikate ausgestellt werden muß darauf geachtet werden, daß die Anforderung so durchgeführt wird, daß der erzeugte private Schlüssel von vornherein immer im Bereich der beantragenden Person verbleibt. Dies könnte beispielsweise so realisiert werden, daß die Anforderung über eine entsprechend programmierte Webseite in der Weise erfolgt, daß die Erzeugung des Paares öffentlicher/privater Schlüssel auf dem PC des Antragstellers oder der Antragsstellerin erfolgt und im Zuge der Anforderung lediglich der öffentliche Schlüssel übermittelt wird. Wird bei personenbezogenen Zertifikaten der private Schlüssel zentral erzeugt und zugestellt, besteht für die betroffenen Person immer die Verunsicherung, ob nicht doch eine Kopie davon irgendwo verblieben ist. Dies ist technisch möglich auf der Basis des ActiveX-Controls xenrol.dll, das von Microsoft auf seinem Webserver einschließlich Dokumentation zur Verfügung gestellt wird. Am Anfang sollte mit einem begrenzten Personenbereich begonnen werden, um die zu lösenden organisatorischen Probleme zu erkennen und abzuarbeiten. Erst wenn aus diesem Personenkreis für einige Zeit keine offenen Fragen mehr auftauchen ist wohl genügend geklärt, um den Benutzerkreis auszuweiten. Verschlüsselungsverordnung Zur Zeit keine Führungen