Irgendwie muss ich beim filettieren dieses Textes hängengeblieben sein, derzeit gibt es das alles hier in diesem Ärea mehrfach. Keine Ahnung was wozu gehört, habe gerade keine Zeit das auszudividieren, sorry.

Noch eine kleine Anmerkung zu PKI und der Katastrophe darum:

• www.heise.de/security/news/foren/go.shtml?read=1&msg_id=10203620&forum_id=95895

Und noch ein Merker der hier vermutlich hin muss:

• www.heise.de/security/artikel/71726
  

Know How: S/MIME

Der einfache Weg zu S/MIME, oder wie sende und empfange ich S/MIME-eMail.

Durch den Dschungel von S/MIME und PKI zu führen und die Sache doch noch ertäglich zu machen, dafür schreibe ich diese Seiten.

Katastrophen

Wichtig für das Verständnis hinter PKI und S/MIME ist die Limitierung davon zu begreifen.

PKI ist zwar besser als nichts, aber das Schloss im Browser ist keine Garantie dafür, dass irgendetwas sicher ist. Leider wissen wir, dass durch einfachste Maßnahmen die Kritikfähigkeit der Menschen leicht beseitigt wird. Sprich, der Anschein von Sicherheit reicht aus um ein trügerisches Sicherheitsgefühl zu schaffen. In dessen Umfeld dann gedeiht Phishing und anderer Betrug.

S/MIME ist zu kompliziert

Siehe auch Rants, meinen alten Text zu diesem Thema. S/MIME ist derart kompliziert, dass man selbst mit intensivem Studium der Materie nichts bis gar nichts damit anfangen kann. Der Grund ist nicht, dass S/MIME so schwierig zu verwenden wäre, sondern dass die Entwickler der Tools für S/MIME auf einer Notenskala von 1 bis 6 (mit 6 ist durchgefallen) ungefähr bei 10^10 landen. (Es handelt sich dabei um eine untere Abschätzung, die tatsächliche Note kann einige Größenordnungen darüber liegen. Nein, das ist keine Ironie, das war Zynismus.) Die Implementierungen, die also zu finden sind, sind schlichtweg eines:

Die S/MIME-Utilities sind absolut unbrauchbar und noch weit jenseits der Unbrauchbarkeit. Sie sind kontraproduktiv, schlecht zu verstenen, kompliziert in der Nutzung und scheinen insgesamt geradezu entworfen worden zu sein, um zu garantieren, dass man in 100 Jahren diesen Verschlüsselungsstandard nicht verwenden will.

Dazu kommt, dass die gesamte PKI auf diesem Planeten von Idioten implementiert worden zu sein scheint, denn die ärgsten Löcher wurden nicht nur nicht gestopft, sondern werden als Features missbraucht um überhaupt PKI zu ermöglichen.

Softwarekatastropen

Ich werde einige der Katastrophen im Umgang mit S/MIME in einer Unterseite aufführen. Diese reichen vom unverantwortlichen Umgang von Zertifikaten von Microsoft-Tools unter Windows bis hin zu Softwarekatastrophen a la OpenSSL, die sichere Dinge dank gröbster Denkfehler unverantwortlich unsicher implementieren. Man hat also die Wahl zwischen funktionierenden Tools (OpenSSL) oder bequemen Tools (Microsoft), eine wirklich runde Sache ist mir noch nicht untergekommen. Wie solch eine runde Sache aussieht werde ich ebenfalls dort skizzieren. Hier soll nur die kurze Übersicht über die Details stehen, damit man alles schnel auf einen Blick erfassen kann.

Katastrophale Grundlagen

Nur was von amtlicher Seite geprüft ist kann man als Bürger dieses Landes vertrauen. Wer also einem Zertifikat vertraen will über das er stolpert kann dies nur tun, indem er sich vertrauensvoll an die Bundesnetzagentur wendet und so das Zertifikat manuell prüft: www.nrca-ds.de/ZDAliste.htm

Eine automatische Prüfung ist derzeit nicht möglich. Ja, ihr lest richtig. Das Schloss im Browser hat keinerlei Aussagekraft da die Klasse 6 Zertifikate falsch implementiert wurden, und zwar in bisher allen Browsern, die ich gefunden habe. Es ist so ein leichtes, in jeden Browser dieser Welt ein weiteres Root-Zertifikat einzuführen, ohne dass es der Anwender merkt.

• Klasse 0: (Demo-Zertifikate) Dies ist die niedrigste Klasse eines Schlüssels. Dieser hat an sich keinerlei Vertrauen verdient. Er ist sicher in dem Sinne, dass der Schlüssel der Schlüssel ist und man hier lediglich dem Schlüssel vertrauen kann. Wenn man einen Klasse 0 Schlüssel von jemandem persönlich erhält, dann weiß man zwar, dass dieser Schlüssel dieser Person gehört, aber im Zweifelsfall kann man das nicht beweisen. Einem Zertifikat der Klasse 0 sollte man immer nur direkt vertrauen, niemals darf es verwendbar sein, um andere Zertifikate zu signieren. In der Regel fehlt auch eine CRL (Certificate Revocation List).
• Klasse 1: (eMail-Zertifikate) Dies ist eine sehr niedrige Sicherheitsklasse die in der Regel nur genau eine Sache zertifiziert. Z. B. eine eMail-Adresse, ein URL oder irgendwelche anderen digitalen Inhalte. Zertifikate der Klasse 1 zertifizieren zwar diese Sache, aber nichts weiteres, insbesondere identifizieren sie nicht die Person oder sonstige Strukturen dahinter. Diese Zertifikate können aber zurückgerufen werden (per CRL). Sie können nicht zu wirklichen Signaturzwecken (im Sinne einer prüfbaren Signatur) verwendet werden, aber man kann sie verwenden, um Informationen verschlüsselt zu übertragen. Im Zweifelsfall kann man mit diesem Zertifikat nichts beweisen.
• Klasse 2: (Persönliche Signaturen) Diese Sicherheitsklasse ist geeignet, um gegenseitig persönliche Schlüssel auszutauschen um sich gegenseitig zu identifizieren. Diese Signaturen haben eine ähnliche Beweiskraft wie eine Unterschrift die man nicht prüfen konnte. In der Regel reichen Klasse 2 Zertifikate zwischen Personen, die sich nicht gegenseitig kennen, nicht aus um eine Identitätsfeststellung zu treffen. Es ist möglich, damit weitere Klasse 1 Zertifikate zu zertifizieren. Klasse 0 Zertifikate sollten niemals durch solche Zertifikate zertifiziert werden. Und man sollte Klasse 2 Zertifikaten nur für weiteres Signing vertrauen, wenn man der Person die einem dieses Zertifikat gab, vertraut.
• Klasse 3: (Zertifizierte Signaturen) Erst diese Signaturen genügen dem Signaturgesetz. Diese Signatur erfordert eine eingehende Identitätsfeststellung durch Ausweis. Der Aussteller des Zertifikats bestätigt damit beweiskräftig, dass der Eigentümer des Zertifikats eine bestimmte Person oder Firma ist und in ihrem Namen sprechen darf, sofern das Zertifikat dies beinhaltet. Mit diesen Zertifikaten kann man in der Regel - sofern das zugelassen wird - weitere Zertifikate der Klasse 2 zertifizieren. Zertifikate der Klasse 1 oder 0 sollten mit diesem Zertifikat nicht zertifiziert werden. Einem solchen Zertifikat kann man bedenkenlos verrauen, sofern es keine weitere Zertifizierung erlaubt (die meisten Klasse 3 Zertifikate sind deshalb für Zertifizierung weiterer Zertifikate nicht zugelassen).
• Klasse 4: (Verkettetes Zertifikat) Diese Ebene wird verwendet, damit man eigne Zertifikate der Klasse 3 erstellen kann. Beispielsweise größere Firmen, die den Aufwand scheuen, um laufend Klasse 3-Zertifikate zu erstellen, lassen sich solch ein Zertifikat ausstellen. In diesem Fall aber muss die Zertifizierungsstelle sicherstellen, dass derjenige, an den dieses Zertifikat geht, absolut vertrauenswürdig ist.
• Klasse 5: (Verkettetes Root-Zertifikat) Dieses Zertifikat wird oft verwendet um das Root-Zertifikat zu schützen. Wenn man z. B. ein SSL-Zertifikat beantragt, kann dies durch ein automatisches System unterschrieben werden, welches das Root-Zertifikat nicht verwenden kann. Die Überprüfung der so erstellten Zertifikate ist aufwendiger, da in Browsern in der Regel nur das Root-Zertifikat gespeichert ist. Das Zertifikat der Klasse 5 ist dabei (wie bei allen Verkettungen) bestandteil des ausgegebenen Zertifikats. Es kann außerdem verwendet werden, um die meist freie Verwendung des Root-Zertifikats einzuschränke (z. B. auf eine bestimmte Klasse). Auch werden solche Zertifikate gerne für Cross-Signing verwendet, da man sie leichter sperren kann ohne das Root-Zertifikat zu beeinträchtigen.
• Klasse 6: (Root-Zertifikat) Dies sind die im Browser installierten Zertifikate, die die anderen Zertifikate gültig machen. Es ist darauf zu achten, dass man keinerlei Zertifikate dieser Sorte in den Browser installiert, denen man nicht vertrauen kann! Eigentlich fängt hier die Misere der gesamten PKI ab, wie sie heutzutage verwendet wird. Kein Mensch ist in der Lage, die Root-Zertifikate zu überprüfen. Ein 3rd Person Audit wurde vergessen zu implementieren. Ich kann mir also keinen Dienstleister suchen, dessen Gültigkeitsprüfung ich zu Audit-Zwecken auf die Root-Zertifikate anwende, und zwar implizit im Browser. Eine Revocation von Root-Zertifikaten findet in der Regel ebenfalls nicht statt oder ist extrem Mühsam oder falsch implementiert. Außerdem stellen Root-Zertifikate ein ständiges Problem dar da sie aufgrund der Unzulänglichkeit der gesamten weltweiten PKI-Struktur nur eine bestimmte Zeit gültig sind. Bis heute haben es die Firmen eigentlich nicht geschafft, rechtzeitig dafür zu sorgen, dass die Root-Zertifikate automatisch angepasst werden, so dass der Anwender nach 10 Jahren nicht plötzlich mit einem ungültigen Root-Zertifikat dasteht und nicht weiß, was er jetzt machen soll oder wie er das Problem beseitigen kann. Root-Zertifikate in ihrer heutigen Verwendnung in Browsern sind absolut unsicher und kontraproduktiv in Sachen Sicherheit zu bezeichnen. Im Signaturgesetz ist deshalb nicht nur eine Browserprüfung, sondern unbedingt ein Abgleich gegenüber den bei der Bundesnetzagentur gespeicherten Zertifikaten notwendig.

Extrem wenig hilfreich dabei ist, dass die großen "Trustcentren" die Surfer sogar noch auf ein falsches Verhalten trainieren, d. h. ihre Root-Zertifikate zum Download feilbieten. Ich frage mich, wie lange es dauert, bis die Phisher auf diesen Trick kommen, nämlich per kleinem VBA-Control einfach den Browsern ein falsches Root-Zertifikat unterschummeln um dann die Leute auf ihre Phishing-Site umzuleiten um per Ajax das wirkliche Online-Banking fernzusteuern.

S/MIME in einfachen Schritten

Am Anfang ist der Key

Um an S/MIME teilzunehmen braucht es einen Schlüssel. Man hat dazu mehrere Möglichkeiten:

1. Man holt sich einen Schlüssel von einem Lieferanten. Diese gibt es in beliebigen Preislagen, von 0 EUR bis einige tausend EUR. Ein guter Anfang für Privatpersonen ist www.trustcenter.de/, denn dort gibt es den Schlüssel für private Nutzung derzeit kostenlos. Hinweis: Sollte jemand Geld für die Erstellung eines privaten Schlüssels der Klasse 1 verlangen, so ist das Nepp.