S/MIME privater Schlüssel bei Comodo ? [erl.]

Hallo Nils,

und willkommen im Forum!
Bevor ich dir jetzt alles erkläre, zuerst eine Frage: Hast du meinen Beitrag zu diesem Thema in unseren FAQ schon gelesen? Eigentlich werden dort deine Fragen alle beantwortet.

Nur so viel:
1.) Du hast deinen privaten Schlüssel schon importiert - sonst könntest du nicht signieren.
2.) Das TrustCenter hat deinen privaten Schlüssel nicht.
3.) Zum Verschlüsseln benötigst du den öffentlichen Schlüssel deines Mailpartners.
4.) Deinen privaten Schlüssel benötigst du zum Entschlüsseln und zum Signieren.

MfG Peter

Hallo Nils,

zwei Vorbemerkungen:
1.) Mein Einkommen hängt nicht davon ab, ob du deine Mails per S/MIME oder mit GnuPG verschlüsselt. Ich will also niemanden missionieren.
2.) Wie Vic~ schon sagte: "Ich habe mir die verlinkte Seite von Dir mal angeschaut und finde sie nicht sehr seriös." Ich setze noch einen drauf: bereits der erste Satz ist absoluter Schwachsinn!

Ich bleibe ausnahmesweise bei diesem Beitrag:
Was danach kommt (Bundestag und DE-Mail) stimmt leider. Es zeigt wie realitätsfern dort gearbeitet und gedacht wird. An Stelle den Leuten dort mit Hilfe von Schulung nahezu bringen, wie eine Mail sicher zu verschlüsseln und vor allem zu signieren ist, lässt man das einen Server machen. Ich gehe weiter zu Gesetzen wie dem, welches "Zenurursula" sinnfrei losgetreten hat, über einigen anderen bis hin zur DE-Mail. Ich werde zu DE-Mail in der jetzt im Gesetz festgelegten Form nie Vertrauen haben! Ein einziges Bundesland (*) hat eine end-to-end-Verschlüsselung gefordert. Dieser Antrag wurde abgeschmettert!
Oder denkt man dort vielleicht gar nicht mal so realitätsfern?
Wurde "Zensurursula" nur vorgeschickt, um dem Wahlvolk nahezubringen, dass von Steuermitteln eine Sperr-Infrastruktur aufzubauen ist? Eine, die selbstverständlich nicht nur gegen KiPos in Stellung gebracht werden kann? Was man einmal hat, wird auch angewandt ... .
Und haben nicht Innenminister reihenweise versucht, dem dt. Michel die private Verschlüsselung zu verbieten? Schon Herr Kanther hatte solche Ideen. Jetzt kann man sagen, ihr könnt doch zum Schutz eurer Privatsphäre (und natürlich gegen Löhnung ...) DE-Mail nutzen.

Ich bleibe bei diesem Beitrag. Konkret beim ersten Satz.
Warum wohl wird weltweit von Behörden und Regierungen sowie von weltweit agierenden großen Firmen fast ausschließlich S/MIME mit sachgerecht produzierten (!!!) X.509-Zertifikaten benutzt? Weil es unsicherer ist? Wohl kaum!
Weil es nämlich im Gegensatz zum Bundestag üblich ist, eine saubere end-to-end-Verschlüsselung mit Hilfe von Schlüsseln auf Chipkarte anzuwenden. Und du solltest das auch nicht mit den zu Werbezwecken verschenkten Kostnix-Zertifikaten vergleichen! Aber dazu später.

Als erstes solltest du dich noch einmal an Hand seriöser Quellen über die Funktionsweise der asymmetrischen Kryptologie informieren. Da scheinen bei dir wirklich noch große Lücken zu bestehen. Hier gibt es übrigens noch keine Unterschiede zwischen S/MIME und GnuPG!
Vor allem die Punkte 1-4 meines ersten Beitrages noch einmal lesen!

Welchen Sinn sollte es machen, mit einem öffentlichen Schlüssel zu signieren? Was willst du mit einer el. Signatur erreichen, und kann das mit einem öffentlichen Schlüssel realisiert werden?
Wenn du also wirklich schon signieren kannst, dann muss sich dein privater Schlüssel schon auf deinem Rechner befinden!

Wenn du bei einem seriösen (!) Trustcenter ein Zertifikat kaufst (!), dann bietet dieses Trustcenter auf seiner Webseite eine so genannte Policy an, in welcher nachzulesen ist, wie die Schlüssel generiert werden. Und wenn man, so wie ich, auch amerikanische Regelwerke kennt, dann weiß man, dass es da "gewisse Unterschiede" zu deutschen Recht gibt. Im Prinzip wurde das auch schon erwähnt.

Und dann musst du auch noch genau unterscheiden, ob es sich um das beliebte "Kostnix-Zertifikat", welches in erster Linie Werbezwecken oder dem Heranführen an die Mailverschlüsselung dient, oder um eine zu Recht teuere Chipkarte handelt. Dazwischen liegen Welten! Speziell bei der Herstellung der Schlüssel!

Fangen wir mit dem Kostnix-Zertifikat und auch bei einem in Deutschland befindlichen TrustCenter an.
1.) Es erfolgt keinerlei Identitätsfeststellung des Antragstellers (=> das ist die Sache, die richtig teuer ist!)
2.) Der Antragsteller übergibt in dem Webformular seine Zertifikatsdaten. In der Regel sind das der Name des Inhabers (CN), und zumindest die Mailadresse. Weitere Angaben wie Wohnort, Bundesland usw. sind optional. Das Land (DE) wird automatisch eingetragen.
3.) Jetzt wird der Browser des Antragstellers aufgefordert ein kleines PlugIn herunterzuladen und auszuführen. Entweder JS oder ActivX. Dieses bewirkt, dass die Kryptoengine des eigenen Browsers einen privaten Schlüssel erzeugt und diesen im Zertifikatsstore speichert. Dann wird per RSA-Verfahren daraus der öffentliche Schlüssel berechnet und dieser ergänzend zu den Zertifikatsdaten an das TrustCenter gesendet. Kurze Zeit später bekommst du eine Mail, wo du aufgefordert wirst mit exakt dem gleichen Browser auf einen zugeschickten Link zu gehen, und dir das Zertifikat abzuholen (Download). In deinem Browser wird der dort gespeicherte private Schlüssel mit dem Zertifikat verbunden.
4.) Jetzt kannst du zwei Dateien aus dem Zertifikatsstore deines Browsers exportieren:
- das auf deinen Namen ausgestellte X.509-Zertifikat. Es enthält nur deinen öffentlichen Schlüssel, deine Zertifikatsdaten (s. oben), die Gültigkeit, Hashwert und einige weitere öffentliche Angaben wie das ausstellende TrustCenter, und es wurde mit dem geheimen Schlüssel des TrustCenters signiert. Dieses Zertifikat ist identisch mit dem, was jeder vom TrustCenter herunterladen kann und welches jeder signierter Mail beigefügt wird.
- und deine so genannte Schlüsseldatei. Diese Datei enthält auch zusätzlich zum Zertifikat deinen privaten Schlüssel. Du erkennst das auch daran, dass beim Export immer ein Passwort einzugeben ist. Dateiendung: .pfx oder .p12, auch .pem möglich aber unüblich. (Und diese Datei ist erkannbar größer als das reine Zertifikat.)

Diese Art der Zertifikats- und Schlüsselerzeugung hat zwei Nachteile:
1.) Keinerlei Identifizierung des Antragstellers (also auf Niveau GnuPG ...) => damit keine Beweiskraft bei der Signatur.
2.) der private Schlüssel wird durch den primitiven Pseudozufallsgenerator auf dem Rechner des Antragsstellers erzeugt (auch wie bei GnuPG).

Da, wie wir alle wissen, es bei sachgerechter Implementierung der heute üblichen Kryptoalgorithmen kaum noch möglich ist, außer natürlich mit extrem langwierigen und deshalb entsprechend teueren brutalen Angriffen => Austesten aller Schlüssel, an ein fremdes Geheimnis zu kommen, ist gerade die Art und Weise der Produktion der privaten Schlüssel und auch deren Lagerort ein sehr wichtiges Kriterium bei der Einschätzung der kryptologischen Sicherheit. Und ein durch einen normalen PC generierter und auch dort gelagerter Pseudozufallsschlüssel steht nun mal am untersten Ende der Skala. Kein Rechner ist in der Lage, echte Zufallszahlen zu erzeugen. Trotz Salt und einer großen Prise Entrophie ... .

Jetzt habe ich eigentlich alles wiederholt, was ich in meinem FAQ-Beitrag geschrieben habe.
Ich bin gern bereit - sachliches Interesse vorausgesetzt - auch noch etwas zu professionelleren Methoden zu schreiben.

Quote

Das Zertifikat wurde bei Comodo erstellt und liegt denen somit vor. Wenn der private wie auch öffentliche Schlüssel im Zertifikat enthalten ist, hätte Comodo die Möglichkeit meine E-Mails zu entschlüsseln.

Wenn du von denen direkt die Schlüsseldatei bekommen hast - ja.
Wenn du das nach dem von mir beschriebenen Request-Verfahren gemacht hast - nein???
??? => ich kenne die US-Amerikanischen Kryptoregularien ... . (Amerikanische Gesetze kann jeder nachlesen.)

Quote

So wie ich es gelesen habe, ist die genau das Prinzip bei DE Mail das den Strafverfolgungsbehörden die Möglichkeit bietet verschlüsselte E-Mails zu lesen.

Das hast du gesagt ... . "Wolfgang" lässt grüßen!

Quote

Fragen über Fragen

Nun, zumindest ist es gut, dass du dich damit befasst ... .

Nachtrag:
(*) Es war Brandenburg. Ich glaube, die Menschen aus meiner alten Heimat wissen genau, warum sie diesen Antrag eingebracht haben!

MfG Peter

Quote from "Nils"

Wenn ich nun dieses Zertifikat.p12 wieder in den Browser importiere erscheint folgende Meldung :
"Ihre Sicherheitszertifikate und privaten Schlüssel wurden erfolgreich wiederhergestellt."

Diese oder eine ähnliche Meldung besagt, dass du in deinem Browser, Mailclient oder sonstigem Zertifikate nutzenden Programm (openVPN usw.) deinen eigenen privaten, öffentlichen und den öffentlichen Schlüssel des ausstellenden TrustCenters importiert hast.

Quote

Wie gesagt wenn ich das Zertifikat bzw. die p12 Datei auf einem Fremden Rechner importiere klappt es auch.
Ich denke das ist somit der Beweis das auch der private Schlüssel entweder in der p12 Datei enthalten ist, zusammen mit dem Zertifikat, oder irgendwie anders mit dem Zertifikat verbunden.

Wie ich wohl schon mehrfach geschrieben habe, ist in einer Schlüsseldatei immer der private Schlüssel enthalten.

Quote

Woran ich mich störe ist, das ich erwarten würde das ich Zugang zu 3 Dateien habe.
1. privaten Schlüssel
2. öffentlichen Schlüssel
3. Zertifikat

Auch diese Frage habe ich schon beantwortet, also was der Inhalt des "Zertifikates" ist, und was dieses von der "Schlüsseldatei" unterscheidet. Selbstverständlich kannst du jederzeit auch aus einer Schlüsseldatei den öffentlichen, den privaten Schlüssel und die reinen Zertifikatsdaten "herausexportieren". Du kannst alle Schlüssel und das Zertifikat in verschiedenen Formaten (binär oder als ASKII-Datei, .pem) darstellen. Der Inhalt und die Funktion bleiben immer gleich. Für ein openVPN werden in der Regel die beiden Schlüssel im .pem-Format verwendet.

Quote

Es geht auch mit 2 Dateien
1. privaten Schlüssel
2. Zertifikat mit öffentlichen Schlüssel zertifiziert und somit kann daraus der öffentliche Schlüssel heraus gelesen werden.

genau

Quote

Als ich das Zertifikat heruntergeladen habe hat es sich in meinem Browser eingenistet, ohne das ich reproduzieren konnte ob es wirklich meinen privaten Schlüssel in irgendeiner Weise nutzt.

Auch das gern noch ein letztes mal:
Der Browser erzeugt deinen privaten Schlüssel, errechnet per RSA deinen öffentlichen, schickt diesen zum Server ...
Und irgendwo muss dieser private Schlüssel ja gespeichert werden, bis dein Browser aus diesem und dem Zertifikat dann die Schlüsseldatei zusammenstellen kann.
Dazu hat ein jeder (nennenswerte) Browser seinen CSP (Cryptografic Service Provider). Ob der nun Zertifikatsmanager, Zertifikatsstore, Passwortmanager oder wie auch immer genannt wird. Auf der WinDOSE siehst du diesen über den Internet-Ex und alle Kryptografie nutzende Programme greifen auf diesen zu, und Mozilla bringt für seine Produkte einen eigenen mit. Ob das was damit zu tun hat, dass OpenSource im Quelltext vorliegt und sich jeder (der dazu in der Lage ist) von der korrekten Funktion überzeugen kann - im Gegenteil zu ClosedSource?

Quote

Wenn ich dieses Zertifikat exportiere wird, wie oben beschrieben ersichtlich anhand der Meldung, der private Schlüssel mit in diese p12 Datei geschoben.

genau.

Quote

Es fehlt die Transparenz.

OK, und deswegen breche in an dieser Stelle ab.
Ich habe nämlich nicht den Beruf eines Missionars ergriffen. Die können so was.
Ich kann nur so viel sagen, dass ich aus langjähriger Tätigkeit in einem TrustCenter weiß, wie die Abläufe sind. Und ich kenne auch die enormen Aufwände, die unternommen werden um einen extrem hohen Sicherheitsstandard zu gewährleisten. Und ich kann für das, was wir produzieren die Hand ins Feuer legen.

Aber manchmal ist es besser den Kopf einzuziehen und mit Frau und Hund spazieren zu gehen, als gegen Wände aus Unverständnis zu rennen ... .

Das, was ich beschrieben habe, ist im Übrigen nur die primitivste Art der Erzeugung von Zertifikaten. Sie wird in der Regel nur für die genannten "Kostnix-Zertifikate" genutzt. Richtig interessant (und sicher!) wird es erst, wenn Schlüssel direkt auf evaluierten Chipkarten generiert und gespeichert werden ... .

MfG Peter