Nachstehend finden Sie die Antworten auf die häufigsten Fragen, die im Rahmen des Projekts "Automatisierte Verschlüsselung von elektronischer Post und Verwendung digitaler Signaturen" des Städtetags Baden-Württemberg von Teilnehmern, Interessenten, Politikern oder der Presse gestellt wurden.
Das Verschlüsselungsprojekt des Städtetags Baden-Württemberg hat kein bestimmtes Produkt als Verschlüsselungsbasis gewählt, sondern lediglich das Austauschformat "OpenPGP Message Format" gemäß dem Internet-Standard RFC 2440 für die Pilotphase des Projekts festgelegt. Dieses Format kann z. B. über das Programm PGP ("Pretty Good Privacy") von Network Associates Inc. (Privatnutzung kostenlos, behördliche Nutzung lizenzpflichtig) erzeugt werden, aber auch über deutsche Produkte wie "AK-Mail" (Shareware) oder "Gnu Privacy Guard" (Freeware).
Die Kernidee des Projekts (flächendeckender Verschlüsselungseinsatz durch automatisierte Ver-/Entschlüsselung auf dem Mail-Server und Vermeidung von Fehlermöglichkeiten/Schulungsaufwand beim Endbenutzer) ist auch vom "OpenPGP Message Format" unabhängig. Daher werden zukünftig auch weitere Verschlüsselungsformate in die Fortschreibung des Projekts integriert werden, sobald sie das Internet-Standardisierungsverfahren erfolgreich durchlaufen haben.
Die automatischen Signaturen des Projekts erfüllen die Kriterien für sog. "einfache elektronische Signaturen" gemäß § 2 Abs. 1 des (novellierten) deutschen Signaturgesetzes. Sie dürfen daher für alle Zwecke genutzt werden, für die nicht ein deutsches Gesetz explizit eine höhere Sicherheitsstufe (z. B. "fortgeschrittene elektronische Signaturen" gemäß § 2 Abs. 2 SigG oder "qualifizierte elektronische Signaturen" gemäß § 2 Abs. 3 SigG) vorschreibt.
(Für "fortgeschrittene elektronische Signaturen" sind nur Signaturschlüssel von natürlichen Personen und nicht solche eines zentralen Mail-Servers zulässig, und für "qualifizierte elektronische Signaturen" darf die Signatur sogar nur durch einen expliziten Willensakt des Signierenden unmittelbar vor jeder Signaturanbringung erfolgen und somit nicht automatisiert werden. Daher eignen sich diese beiden Signaturtypen nicht für das vorliegende Projekt, dessen Kernidee ja gerade die automatisierte und zentrale Abwicklung der Verschlüsselung/Signatur ist.)
Das Lösungskonzept des Projekts kann bei Bedarf jederzeit mit anderen Verschlüsselungs- und Signaturverfahren kombiniert werden, da es ein "kooperatives Nebeneinander" zwischen der automatisierten Ver-/Entschlüsselung auf dem Mail-Server und einer "Ende-zu-Ende"-Sicherung (Signatur oder Verschlüsselung) für einzelne Arbeitsplätze mit speziellen Anforderungen unterstützt. Dabei wird die Masse der Vorgänge automatisiert und flächendeckend abgewickelt (wobei jeder Arbeitsplatz auch ohne Schulung, Chipkarte oder Änderung der E-Mail-Software angebunden werden kann). Die wenigen Vorgänge, für die eine zentrale automatisierte Abwicklung nicht zulässig ist, werden - je nach Größe der Stadt - entweder weiterhin per normaler Post oder über Zusatzkomponenten (wie im Sphinx-Projekt des BSI) an den (wenigen) betroffenen Arbeitsplätzen abgewickelt.
Die Erfahrungen haben gezeigt, daß im Internet nur offizielle Standards der IETF (Internet Engineering Task Force) eine langfristige Überlebenschance haben. Die IETF lehnt jedoch sowohl lokale Modifikationen als auch proprietäre Verfahren ab, weil diese dem "Offenheitsprinzip" des Internets widersprechen.
MailTrusT baut auf einem Internet-Standardentwurf auf (PEM = Privacy Enhanced Mail), der mittlerweile von der IETF wegen "technischer Mängel und fehlender Akzeptanz" zurückgezogen wurde, und fügt dieser Basis lokale Modifikationen von 8 deutschen Firmen hinzu.
In dieser Form hat MailTrusT trotz Favorisierung durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) derzeit keine Aussicht auf erfolgreiches Durchlaufen des IETF-Standardisierungsprozesses und somit auf allgemeine Akzeptanz. Daher ist es nicht verwunderlich, daß sich die praktische Verbreitung von MailTrusT im wesentlichen auf das Pilotprojekt Sphinx (mit derzeit weniger als 500 verbundenen Arbeitsplätzen) beschränkt.
Mittlerweile haben die an MailTrusT beteiligten Firmen angekündigt, die Verschlüsselungsbasis schrittweise von PEM auf S/MIME 3.x umstellen zu wollen. Falls nach Abschluß einer solchen Umstellung MailTrusT im IETF-Standardisierungsprozeß erfolgreich sein sollte, wird ein solcher Standard natürlich in das vorliegende Projekt integriert werden (siehe die Anwort auf Frage 1).
"web.de"/"Freemail" bietet eine für den Anwender recht komfortabel nutzbare Verschlüsselung/Signatur auf Basis des Verfahrens S/MIME 2.0 an. Leider hat das Sicherheitsmodell von "web.de" jedoch eine ernsthafte Sicherheitslücke: der Provider ist dabei im Besitz der privaten Schlüssel seiner Kunden!
Das "web.de"-Modell entspricht daher etwa einer automatisierten Ver-/Entschlüsselung auf einem Mail-Server, der beim Internet-Provider (und nicht im eigenen Haus) steht. Da der Kunde keine Kontrolle über die Mitarbeiter des Providers oder die dort eingesetzten Sicherheitsmaßnahmen hat, kann der Städtetag Baden-Württemberg dieses Modell für die kommunale Nutzung nicht empfehlen.
E-Mails mit Dateianlagen, die kryptographisch verschlüsselt sind, können naturgemäß erst nach dem Entschlüsseln auf Viren u. ä. geprüft werden. Bei einer "Ende-zu-Ende"-Verschlüsselung wird daher tatsächlich ein zentraler Virenschutz unterlaufen, und es sind geeignete Zusatzmaßnahmen zu ergreifen, damit an jedem Arbeitsplatz entschlüsselte Dateien nicht ohne vorherige Virenprüfung ausgeführt werden können.
Bei einer automatischen Ver-/Entschlüsselung auf dem Mail-Server tritt dieses Problem jedoch gar nicht auf. Da alle eingehenden E-Mails bereits auf dem Mail-Server entschlüsselt werden, können unmittelbar danach alle gewünschten Inhaltsüberprüfungen genau wie bei unverschlüsselten Mails stattfinden.
Bei der vom Städtetag Baden-Württemberg empfohlenen Vorgehensweise ist daher keine Änderung des Schutzverfahrens gegen Viren u. ä. erforderlich.
Da die Ver-/Entschlüsselung von E-Mails automatisch auf dem Mail-Server stattfindet, ist der Schulungsaufwand beim normalen Endbenutzer gleich Null. Der Endbenutzer muß entweder gar nichts tun (bei voreingestellter Zwangsverschlüsselung mit bestimmten E-Mail-Partnern oder beim Beantworten verschlüsselter E-Mails) oder lediglich markieren, daß eine ausgehende E-Mail verschlüsselt und/oder signiert werden soll (bei neuen E-Mails an Empfänger, für die eine optionale Verschlüsselung/Signatur eingestellt ist).
Lediglich der Administrator des Mail-Server-PCs muß das Prinzip der asymmetrischen Verschlüsselung und die Schritte eines sicheren Schlüsselmanagements kennen. Er sollte daher das Tutorial des vorliegenden Projekts durchgearbeitet haben.