Sichere eMail durch Zertifikate
Weiterführende Informationen zu diesem Thema finden Sie beispielsweise unter: GnuPG (GPG) Tutorial
Problemlage
Eine unverschlüsselte E-Mail ist nicht sicherer als eine Postkarte und geht unter Umständen durch viele Server und Knoten im Internet, bevor sie im Postfach des Empfängers landen. Soweit es sich um die eigenen Daten handelt, bleibt es jedem selbst überlassen, ob sie oder er die Daten offen durch das Internet schickt. Spätestens dann, wenn es sich um personenbezogene Daten anderer handelt, sollte man vorsichtiger werden. Verschicken Stellen personenenbezogene Daten per eMail, muss der Schutz vor unbefugter Kenntnisnahme gewährleistet sein.
Ein weiterer Punkt betrifft die Authentizität des Absenders einer eMail. Jeder, der für wenige Euro im Monat einen Webhosting-Account betreibt, ist in der Lage, eMails mit beliebigen Absenderangaben zu generieren. Nach wie vor gibt es offene eMail-Server, die es jedermann erlauben, eMails mit einem beliebigen "From:" zu erzeugen. Man kann sich nur bedingt darauf verlassen, dass solchermaßen erzeugte eMails als Spam klassifiziert und aussortiert werden. Eigentlich müsste man bei jeder eingehenden eMail in die Protokolldaten schauen, um zu untersuchen, ob es Anhaltspunkte dafür gibt, dass diese Mail nicht vom genannten Absender stammt.
Problemlösung
Da dies kein tragbarer Zustand war und ist, wurden Möglichkeiten für einen sicheren eMail-Versand gesucht. Dafür braucht es vier Bausteine:
Durch eine passende Kombination dieser Bausteine kann man die gerade benötigte Sicherheitsfunktion bewerkstelligen. Dabei haben die Anwender mit diesen Bausteinen direkt nichts zu tun, diese setzen nur Häkchen vor Signieren bzw. Verschlüsseln oder vor beides. Wenn man jedoch eine Vorstellung davon bekommen möchte, wie die Sicherheit eigentlich zustande kommt, muss man die Kombination der Bausteine betrachten.
Problemlage
Eine unverschlüsselte E-Mail ist nicht sicherer als eine Postkarte und geht unter Umständen durch viele Server und Knoten im Internet, bevor sie im Postfach des Empfängers landen. Soweit es sich um die eigenen Daten handelt, bleibt es jedem selbst überlassen, ob sie oder er die Daten offen durch das Internet schickt. Spätestens dann, wenn es sich um personenbezogene Daten anderer handelt, sollte man vorsichtiger werden. Verschicken Stellen personenenbezogene Daten per eMail, muss der Schutz vor unbefugter Kenntnisnahme gewährleistet sein.
Ein weiterer Punkt betrifft die Authentizität des Absenders einer eMail. Jeder, der für wenige Euro im Monat einen Webhosting-Account betreibt, ist in der Lage, eMails mit beliebigen Absenderangaben zu generieren. Nach wie vor gibt es offene eMail-Server, die es jedermann erlauben, eMails mit einem beliebigen "From:" zu erzeugen. Man kann sich nur bedingt darauf verlassen, dass solchermaßen erzeugte eMails als Spam klassifiziert und aussortiert werden. Eigentlich müsste man bei jeder eingehenden eMail in die Protokolldaten schauen, um zu untersuchen, ob es Anhaltspunkte dafür gibt, dass diese Mail nicht vom genannten Absender stammt.
Problemlösung
Da dies kein tragbarer Zustand war und ist, wurden Möglichkeiten für einen sicheren eMail-Versand gesucht. Dafür braucht es vier Bausteine:
- Sicherstellung der Unverfälschtheit
- Verschlüsselung
- Öffentliche und private Schlüssel
- Echtheitsbestätigungen (Zertifikate) der öffentlichen Schlüssel
Durch eine passende Kombination dieser Bausteine kann man die gerade benötigte Sicherheitsfunktion bewerkstelligen. Dabei haben die Anwender mit diesen Bausteinen direkt nichts zu tun, diese setzen nur Häkchen vor Signieren bzw. Verschlüsseln oder vor beides. Wenn man jedoch eine Vorstellung davon bekommen möchte, wie die Sicherheit eigentlich zustande kommt, muss man die Kombination der Bausteine betrachten.
Unverfälschtheit: Dazu dient ein sog. Fingerprint. Es ist informationstechnisch möglich, mit einem bestimmten Verfahren jedem beliebigen Text eine Zeichenkette fester Länge so zuzuordnen, dass auch nur die Veränderung eines Buchstabens des Textes in unvorhersagbarer Weise eine völlig andere Zeichenkette generiert. Es ist auch aussichtslos, eine Kombination von mehreren Veränderungen zu finden, die dieselbe Zeichenfolge wie der Originaltext erzeugt. Damit hat man eine Möglichkeit festzustellen, ob ein Text originär ist oder geändert wurde.
Verschlüsselung: Es mag zunächst verwundern, wieso man noch eine Verschlüsselung braucht, wenn es den Baustein "Öffentliche und private Schlüssel" gibt. Um eine akzeptable Verschlüsselungsgeschwindigkeit und ein überschaubares Datenvolumen auch bei großen Texten oder anderen Daten zu haben, braucht es die ganz normale Verschlüsselung mit einem Kennwort. Die Daten werden mit diesem Kennwort (schnell) verschlüsselt und mit demselben Kennwort wieder entschlüsselt.
Öffentlicher und privater Schlüssel: Auch wenn es verwunderlich erscheinen mag, gibt es ein informationstechnisches Verfahren, das es erlaubt, bestimmte Paare von Zeichenfolgen so zu erzeugen, dass man mit dem zugrundeliegenden Verfahren mit der einen Zeichenfolge Daten verschlüsseln und mit der anderen Zeichenfolge wieder entschlüsseln kann. Der springende Punkt ist der, dass keine Chance besteht, aus der einen Zeichenfolge auf die andere zu schließen, wenn man die Zeichenfolgen hinreichend lang macht. Die eine Zeichenfolge nennt man dann "Privater Schlüssel" und wird geheimgehalten, die andere ist dann der "Öffentliche Schlüssel", der in öffentlichen Verzeichnissen (ähnlich Telefonbüchern) allgemein zugänglich gemacht wird.
Verschlüsselung: Es mag zunächst verwundern, wieso man noch eine Verschlüsselung braucht, wenn es den Baustein "Öffentliche und private Schlüssel" gibt. Um eine akzeptable Verschlüsselungsgeschwindigkeit und ein überschaubares Datenvolumen auch bei großen Texten oder anderen Daten zu haben, braucht es die ganz normale Verschlüsselung mit einem Kennwort. Die Daten werden mit diesem Kennwort (schnell) verschlüsselt und mit demselben Kennwort wieder entschlüsselt.
Öffentlicher und privater Schlüssel: Auch wenn es verwunderlich erscheinen mag, gibt es ein informationstechnisches Verfahren, das es erlaubt, bestimmte Paare von Zeichenfolgen so zu erzeugen, dass man mit dem zugrundeliegenden Verfahren mit der einen Zeichenfolge Daten verschlüsseln und mit der anderen Zeichenfolge wieder entschlüsseln kann. Der springende Punkt ist der, dass keine Chance besteht, aus der einen Zeichenfolge auf die andere zu schließen, wenn man die Zeichenfolgen hinreichend lang macht. Die eine Zeichenfolge nennt man dann "Privater Schlüssel" und wird geheimgehalten, die andere ist dann der "Öffentliche Schlüssel", der in öffentlichen Verzeichnissen (ähnlich Telefonbüchern) allgemein zugänglich gemacht wird.
Mit diesen drei Bausteinen steht man kurz davor, einen eigenen Text vor Verfälschung schützen und dem Empfänger die Gewähr geben zu können, dass man selbst der Absender ist: Man erzeugt den Fingerprint des Textes und verschlüsselt diesen mit dem eigenen privaten Schlüssel. Diese Daten fügt man der eMail hinzu. Der Empfänger nimmt dann den öffentlichen Schlüssel des Absenders und entschlüsselt damit den Fingerprint. Dann bestimmt er den Fingerprint des erhaltenen Textes. Stimmen die beiden Fingerprints überein, steht fest, dass der Text nicht verfälscht wurde und wer der Absender ist (das ganze läufte natürlich automatisch im eMail-Client ab). Die Sache hat nur einen kleinen Haken: Woher weiß der Empfänger, dass der öffentliche Schlüssel, den er sich beispielsweise über einen Verzeichnisdienst im Internet beschafft, echt ist? Deshalb:
Echtheitsbestätigungen (Zertifikate) der öffentlichen Schlüssel: Das Verfahren, mit dem Schlüsselpaare erzeugt werden können, ist öffentlich bekannt. Jeder, der sich näher damit befasst, kann sich selbst beliebig viele solcher Paare erzeugen. Es braucht deshalb Instanzen (Zertifizierungsstellen), die die Echtheit öffentlicher Schlüssel bestätigen. Informationstechnisch tun sie dies dadurch, dass sie einen Text, der aus den Adressdaten, der eMail-Adresse des Inhabers, dessen öffentlichem Schlüssel und weiteren Angaben wie etwa die Gültigkeitsdauer besteht, mit ihrem privaten Schlüssel vor vorstehend erläutert signieren. Die Empfänger von eMails können die Echtheit des verwendeten öffentlichen Schüssel automatisch überprüfen, wenn sie in ihrem eMail-Programm den öffentlichen Schlüssel der Zertifizierungsstelle vorhalten.
Und schließlich Sicherer eMail-Versand:
Und schließlich Sicherer eMail-Versand:
Nach den vorstehenden Erläuterungen würde man vielleicht wie folgt vorgehen wollen: Man nimmt den öffentlichen Schlüssel des Empfängers, prüft dessen Richtigkeit mit dem öffentlichen Schlüssel der Zertifizierungsstelle, verschlüsselt mit dem öffentlichen Schlüssel des Empfängers den Text der eMail und schickt diese ab. Der Empfänger nimmt dann seinen privaten Schlüssel und erzeugt wieder Klartext. Das ist im Prinzip auch richtig, praktisch geht man allerdings her und erzeugt eine zufällige Zeichenfolge als Kennwort, verschlüsselt damit mit einem gängigen Verschlüsselungsverfahren den Text, verschlüsselt das Kennwort mit dem öffentlichen Schlüssel des Empfängers und versendet diese Daten per eMail. Der Empfänger beschafft sich dann zuerst mit seinem privaten Schlüssel das Kennwort im Klartext und entschlüsselt damit die Daten. Dies alles läuft natürlich automatisch in den eMail-Programmen der Kommunikationspartner ab. Der Zwischenschritt mit der normalen Verschlüsselung hat den Vorteil, dass die Datenmengen nicht wesentlich größer sind als sie es wären, wenn man unverschlüsselt verschickt.
Das Vorgehen bei Signatur mit Verschlüsselung liegt dann auf der Hand.
Qualität der Zertifikate, OKR-Zertifikate
Um sicher mit eMails kommunizieren zu können, brauchen die Kommunikationspartner also ihre Schlüsselpaare und eine zentrale Instanz, die die Echtheit der öffentlichen Schlüssel bestätigt. Es gibt kommerzielle Zertifizierungsstellen, die sich darauf spezialisiert haben, ihren Kunden den vertraulichen Versand von eMails zu ermöglichen. Es gibt Internetprovider wie etwa Web.de, die ihre Kunden umsonst mit Zertifikaten ausstatten. Es gibt Internetprovider wie etwa T-Online, die gegen einen monatlichen Betrag ein Zertifikat zur Verfügung stellen. Worin liegt der Unterschied?
Hinter der Identifizierung einer Person oder einer Stelle steht ein Aufwand, der Kosten verursacht. Web.de vertraut den Angaben, die die Kunden auf den Anmeldeformularen machen, eine Überprüfung dieser Angaben erfolgt nicht. Insofern fallen hier nur geringe Kosten an und die Zertifikate können umsonst bereitgestellt werden. T-Online benutzt das Post-Ident-Verfahren, um den privaten Schlüssel auszuhändigen. Dies bedeuted, dass der Schlüsselinhaber sich auf einer Postfiliale mit seinem Ausweis identifizieren muss, bevor er den Brief mit den Zertifizierungsunterlagen ausgehändigt bekommt. Ähnlich verfahren Krankenkassen, wenn sie eine Zertifizierungsinstanz betreiben, auch dort müssen die Versicherten auf einer Außenstelle persönlich erscheinen, um die Unterlagen überreicht zu bekommen. Es gibt noch aufwendigere Verfahren, um zu gewährleisten, dass die mit dem öffentlichen Schlüssel ausgewiesene Person tatsächlich der Schlüsselinhaber ist bis hin zu Einsatz von Chipkarten als Aufbewahrungsort für den privaten Schlüssel.
Neben dem Aufwand für die Authentifizierung kann auch die Schlüsselerzeugung Kosten verursachen. Erfolgt die Schlüsselerzeugung zentral, müssen sich die Empfänger darauf verlassen können, dass nicht Kopien ihrer privaten Schlüssel bei der zentralen Instanz vorgehalten werden. Das bedeuted eine Automatisierung der Erstellung der Versand-Unterlagen. Ferner bedarf es einer Instanz, die prüft und testiert, dass dies alles korrekt abläuft. Ein Alternative dazu ist, dass die Schlüsselinhaber mit einem entsprechenden Programm ihre Schlüssel selbst erzeugen und der Zertifizierungsstelle den öffentlichen Schlüssel zur Bestätigung vorlegen. Dann fallen dort nur die Authentifizierungskosten an. Ein ganz anderer Ansatz besteht darin, ganz auf die zentrale Instantz zu verzichten und ein "Web-of-Trust" aufzubauen: A vertraut B, B vertraut C, also vertraut A auch C (natürlich nicht allgemein, sondern nur bei der Korrektheit der Authentifzierung). Dies ist der Ansatz von PGP (Pretty Good Privacy). Allerdings erlaubt auch das PGP-Verfahren die Etablierung zentraler Instanzen, dies hängt lediglich daran, wie das Verfahren betrieben wird.
Beim Evangelischen Oberkirchenrat Stuttgart (Referat Informationstechnologie) wurde ein Open Source Public-Key-Verfahren auf den Belange der Landeskirche adaptiert. Es können nunmehr zentral auch größere Mengen an Zertifikaten, etwa für alle Pfarrämter, in einem Durchgang erzeugt werden. Dem liegt zugrunde, dass korrekte Daten etwa der Pfarrstellen dem Oberkirchenrat in elektronischer Form vorliegen und sich eine Authentifizierung erübrigt. Soweit Zertifikate für weitere Personen oder Stellen verlangt werden, fungieren die Dekanatsämter als Authentifizierungsstellen. Ferner werden Kopien der erzeugten privaten Schlüssel beim Oberkirchenrat gespeichert. Dem liegt zugrunde, dass nicht eine vertrauliche Kommunikation zwischen Personen ermöglich werden soll, sondern dass die eMails ohne die Möglichkeit einer Kenntnisnahme über das Internet zwischen OKR und Pfarrämtern und anderen Kommunikationspartnern transportiert werden können. Dies ist deshalb erforderlich, weil es weder beabsichtigt ist noch Sinn macht, alle Stellen der Landeskirche in das OKR-Netz zu integrieren. Es wird auf Dauer erforderlich sein, mittels eMail über das Internet zu kommunizieren.
Ein bislang nicht genannter Kostenfaktor besteht darin, dass nicht allen Mitarbeiterinnen und Mitarbeiter des OKR's ein Schlüsselpaar zugewiesen wurde (was einiges an Problemen aufgeworfen hätte), sondern der OKR als Stelle einen öffentlichen und einen privaten Schlüssel hat. Andererseits kommunzieren bestimmte Mitarbeiterinnen und Mitarbeiter mit den Stellen und Personen der Landeskirche. Damit dies vereinbar ist, werden beim OKR eingehende verschlüsselte eMails zentral entschlüsselt und dann im OKR-Netz dem Postfach des jeweiligen Mitarbeiters bzw. der jeweiligen Mitarbeiterin zugeführt. Für die dafür benötigte Software müssen Lizenzgebühren entrichtet werden, weshalb auch der OKR für seine Zertifikate Gebühren verlangt.
Nach oben
Das Vorgehen bei Signatur mit Verschlüsselung liegt dann auf der Hand.
Qualität der Zertifikate, OKR-Zertifikate
Um sicher mit eMails kommunizieren zu können, brauchen die Kommunikationspartner also ihre Schlüsselpaare und eine zentrale Instanz, die die Echtheit der öffentlichen Schlüssel bestätigt. Es gibt kommerzielle Zertifizierungsstellen, die sich darauf spezialisiert haben, ihren Kunden den vertraulichen Versand von eMails zu ermöglichen. Es gibt Internetprovider wie etwa Web.de, die ihre Kunden umsonst mit Zertifikaten ausstatten. Es gibt Internetprovider wie etwa T-Online, die gegen einen monatlichen Betrag ein Zertifikat zur Verfügung stellen. Worin liegt der Unterschied?
Hinter der Identifizierung einer Person oder einer Stelle steht ein Aufwand, der Kosten verursacht. Web.de vertraut den Angaben, die die Kunden auf den Anmeldeformularen machen, eine Überprüfung dieser Angaben erfolgt nicht. Insofern fallen hier nur geringe Kosten an und die Zertifikate können umsonst bereitgestellt werden. T-Online benutzt das Post-Ident-Verfahren, um den privaten Schlüssel auszuhändigen. Dies bedeuted, dass der Schlüsselinhaber sich auf einer Postfiliale mit seinem Ausweis identifizieren muss, bevor er den Brief mit den Zertifizierungsunterlagen ausgehändigt bekommt. Ähnlich verfahren Krankenkassen, wenn sie eine Zertifizierungsinstanz betreiben, auch dort müssen die Versicherten auf einer Außenstelle persönlich erscheinen, um die Unterlagen überreicht zu bekommen. Es gibt noch aufwendigere Verfahren, um zu gewährleisten, dass die mit dem öffentlichen Schlüssel ausgewiesene Person tatsächlich der Schlüsselinhaber ist bis hin zu Einsatz von Chipkarten als Aufbewahrungsort für den privaten Schlüssel.
Neben dem Aufwand für die Authentifizierung kann auch die Schlüsselerzeugung Kosten verursachen. Erfolgt die Schlüsselerzeugung zentral, müssen sich die Empfänger darauf verlassen können, dass nicht Kopien ihrer privaten Schlüssel bei der zentralen Instanz vorgehalten werden. Das bedeuted eine Automatisierung der Erstellung der Versand-Unterlagen. Ferner bedarf es einer Instanz, die prüft und testiert, dass dies alles korrekt abläuft. Ein Alternative dazu ist, dass die Schlüsselinhaber mit einem entsprechenden Programm ihre Schlüssel selbst erzeugen und der Zertifizierungsstelle den öffentlichen Schlüssel zur Bestätigung vorlegen. Dann fallen dort nur die Authentifizierungskosten an. Ein ganz anderer Ansatz besteht darin, ganz auf die zentrale Instantz zu verzichten und ein "Web-of-Trust" aufzubauen: A vertraut B, B vertraut C, also vertraut A auch C (natürlich nicht allgemein, sondern nur bei der Korrektheit der Authentifzierung). Dies ist der Ansatz von PGP (Pretty Good Privacy). Allerdings erlaubt auch das PGP-Verfahren die Etablierung zentraler Instanzen, dies hängt lediglich daran, wie das Verfahren betrieben wird.
Beim Evangelischen Oberkirchenrat Stuttgart (Referat Informationstechnologie) wurde ein Open Source Public-Key-Verfahren auf den Belange der Landeskirche adaptiert. Es können nunmehr zentral auch größere Mengen an Zertifikaten, etwa für alle Pfarrämter, in einem Durchgang erzeugt werden. Dem liegt zugrunde, dass korrekte Daten etwa der Pfarrstellen dem Oberkirchenrat in elektronischer Form vorliegen und sich eine Authentifizierung erübrigt. Soweit Zertifikate für weitere Personen oder Stellen verlangt werden, fungieren die Dekanatsämter als Authentifizierungsstellen. Ferner werden Kopien der erzeugten privaten Schlüssel beim Oberkirchenrat gespeichert. Dem liegt zugrunde, dass nicht eine vertrauliche Kommunikation zwischen Personen ermöglich werden soll, sondern dass die eMails ohne die Möglichkeit einer Kenntnisnahme über das Internet zwischen OKR und Pfarrämtern und anderen Kommunikationspartnern transportiert werden können. Dies ist deshalb erforderlich, weil es weder beabsichtigt ist noch Sinn macht, alle Stellen der Landeskirche in das OKR-Netz zu integrieren. Es wird auf Dauer erforderlich sein, mittels eMail über das Internet zu kommunizieren.
Ein bislang nicht genannter Kostenfaktor besteht darin, dass nicht allen Mitarbeiterinnen und Mitarbeiter des OKR's ein Schlüsselpaar zugewiesen wurde (was einiges an Problemen aufgeworfen hätte), sondern der OKR als Stelle einen öffentlichen und einen privaten Schlüssel hat. Andererseits kommunzieren bestimmte Mitarbeiterinnen und Mitarbeiter mit den Stellen und Personen der Landeskirche. Damit dies vereinbar ist, werden beim OKR eingehende verschlüsselte eMails zentral entschlüsselt und dann im OKR-Netz dem Postfach des jeweiligen Mitarbeiters bzw. der jeweiligen Mitarbeiterin zugeführt. Für die dafür benötigte Software müssen Lizenzgebühren entrichtet werden, weshalb auch der OKR für seine Zertifikate Gebühren verlangt.
Nach oben