S/MIME:Archiv + mehrere Zertifikate für selbe Adr [geholfen]

Hallo Ulrich,

Zitat von "losgehts"

...Hier nochmals vielen Dank für die Anleitung in den FAQ, die hat mir dabei sehr geholfen. :top:

Danke

So, nun will ich mal sehen, ob ich auch noch ein paar Antworten auf deine Fragen habe.

zu a)
Diese Frage kann dir wirklich niemand beantworten.
Ich kenne ja die Qualität deines Passwortes nicht
Wenn du (so wie das ein mir sehr gut bekanntest Trustcenter macht ) deinen private-key mit einem 16-stelligen Zufallsschlüssel schützt, dann musst du dir garantiert keine Sorgen wegen der Kompromittierung machen. Dieses Passwort ist ja eigentlich auch nur das so genannte "Transportpasswort". Wenn der Schlüssel in das "Software-Kryptografiemodul" importiert wurde, schützt ja das Masterpasswort vor dem Auslesen.

Ich denke mal, wir können alles übertreiben. Ich habe hier schon mehrfach den in meiner Berufssparte gängigen Begriff des kalkulierbaren Restrisikos genannt. Das ist der Kompromiss zwischen "maximal möglich" und "sinnvoll und bezahlbar".

So mache ich das: Ich verwende mehrere kleinere TrueCrypt-Container für meine diversen kleinen privaten "Geheimnisse".

zu b)
Ja das stimmt. Aus Gründen der "kryptologischen Härte" wird auch von der hiesigen Sicherheitsinstanz dem BSI, empfohlen, dass Softwaretoken eine begrenzte Lebensdauer von einem Jahr erhalten. (Einer der Unterschiede zur GnuPG-Fraktion deren Schlüssel in der Regel unbegrenzt gültig bleiben ...)
Das bedeutet, dass du mit einem abgelaufenen Zertifikat (öffentlichen Schlüssel eines Empfängers) nicht mehr verschlüsseln, und mit deinem abgelaufenen eigenen Schlüssel nicht mehr signieren kannst. In beiden Fällen verweigert das ein Client, der dem Standard entspricht.
Aber wie du schon richtig festgestellt hast, benötigst du die abgelaufenen Schlüssel, um alte, an dich gerichtete Mails zu entschlüsseln. Dafür sind die privaten Schlüssel unbegrenzt in der Lage. Du musst und kannst sie also weiterhin unter den eigenen Zertifikaten importiert lassen. Und sie kommen sich auch nicht ins Gehege, denn: In den Kontoeinstellungen legst du ja für jedes Konto fest, welcher aktueller Schlüssel zum Entschlüsseln und signieren zu verwenden ist. Trotzdem kannst du eine "alte" Mail problemlos öffnen.

zu c)
Nun, "umgehen" kann jeder Texteditor mit verschlüsselten mbox-Dateien. Allerdings siehst du nur Müll ... .
Prinzipiell ist es möglich, dass ein Editor diese Funktion beherrscht. Ich kann sogar auf der Konsole per openSSL die entsprechenden p7m-Container öffnen. Aber ich kenne keinen Editor, der diese Funktion von Hause aus kann. (Ich behaupte auch keinesfalls, dass ich alles weiß ... .)
Du must eben Prioritäten setzen.

zu d)
Auch hier sind wir wieder bei den Prioritäten und dem kalkulierbaren Restrisiko ... .
Ich arbeite in einem TrustCenter. Und das Wort "Trust" hat wohl irgendwas mit "Vertrauen" zu tun. Sicherlich sind die Sicherheitsanforderungen nicht unbedingt zu vergleichen, aber ich gehe mal davon aus, dass meine dortigen Kollegen ihre Arbeit genau so ernst nehmen, wie ich die meinige.
Die Verbindung zwischen deinem Browser und dem Webserver des Providers ist SSL-gesichert. Jetzt kann sein, dass bereits dein Browser die Mail mit dem Zertifikat des Empfängers verschlüsselt und eine verschlüsselte Mail erst in deinem eigenen Browser mit Hilfe deines eigenen Schlüssels entschlüsselt wird. (End to End-Verschlüsselung).
Es kann aber auch sein, dass diese beiden Funktionen bereits auf dem Webserver erfolgen. Ich weiß es einfach nicht. Gehe aber persönlich von der ersten Möglichkeit aus. (Steht da wirklich nichts bei web.de geschrieben???)

Fakt ist zweierlei:
1.) Dieses Angebot von web.de ist ein ausgezeichneter Einstieg für das Versenden und Empfangen verschlüsselter E-Mails und somit ein erster Schritt in Richtung Privatsphäre. Für viele Nutzer ist S/MIME im Mailclient einfach zu kompliziert. Einfacher als per web.de geht es nicht! Also ein Schritt in die richtige Richtung.
2.) Wenn eine Firma (ein Trustcenter) dir "ein Zertifikat" bereitstellt, dann geschieht das in der Regel so, dass du eine Onlinehandlung vornimmst. Dabei generiert dein eigener Browser(!!!) den private-Key, berechnet daraus den public-Key und sendet lediglich deinen public-Key zusammen mit den notwendigen Zertifikatsdaten an den Server des Trustcenters. Diesen Vorgang nennen wir einen "Zertifikats-Request". Dabei ist garantiert, dass der private-Key niemals deinen Browser verlässt. Auf dem Server werden dein öffentlicher Schlüssel und die Zertifikatsdaten sowie Daten des Trustcenters verbunden und das ganze mit dem (wirklich streng geheim gehaltenen!!!) private-Key des Trustcenters signiert. Dieses Produkt ist das Zertifikat. Es ist rein öffentlich.
Dieses Zertifikat wird zurück an den Browser geschickt. Er kann (und sollte!!!) es mit dem dort sicher gespeicherten eigenen private-Key als "Schlüsseldatei" (.p12 oder .pfx) exportieren, wobei das Transportpasswort gesetzt werden sollte. Selbstverständlich kannst du auch nur das Zertifikat exportieren.
Dieses Verfahren wird verbindlich durch das TC-Trustcenter Hamburg angewandt, und ich gehe davon aus, dass das auch bei web.de so ist. Hier kann ich es aber mangels Kenntnis nicht mit Sicherheit sagen!

Aber, und das ist wieder eine ganz andere Qualität:
Wenn du dir zum Bsp. beim TC Hamburg eines der beliebten "Kostnix-Zertifikate holst, dann bekommst du eine Schlüsseldatei für sichere Mailverschlüsselung. Aber im Gegensatz zu den kostenpflichtigen Produkten erfolgt hier keinerlei Identitätsfeststellung! Darauf wird auch Seitens des TC hingewiesen. Es erfolgt also lediglich eine Überprüfung der Mailadresse. Niemand garantiert dir, dass der Unterzeichner einer Mail wirklich eine authentische Person ist!
[Bei einem, zugegebenermaßen teueren, Zertifikat für fortgeschrittene oder gar qualifizierte Signaturen garantieren wir, dass die eingetragene Person identifiziert wurde und authentisch ist!]
Ich weiß nicht, ob das jetzt noch so ist, aber wenn ich so 10 bis 15 Jahre zurückdenke, dann lief das bei meinem alten web.de-Zertifikat so ab: Ich musste mich nach dem Post-Ident-Verfahren bei einem Postbediensteten identifizieren, und dieser bestätigte web.de meine Authentizität. Das bedeutet, dass bei einem (zumindest damaligen!) Zertifikat von web.de die im Zertifikat eingetragene Person authentisch ist.
Auch dieses solltest du bei der Einschätzung des Zertifikates von web.de mit berücksichtigen.

MfG Peter

Freut mich, dass ich dir habe helfen können.

Wenn du
'TrueCrypt einmal installiert hast, kannst du es selbstverständlich auch ohne Admin-Rechte benutzen. Du musst für die tägliche Arbeit auch nicht jedesmal die GUI starten, sondern kannst dir kleine Verknüpfungen auf den Desktop legen, mit denen du den oder die Container einzeln startest, mountest und auch gleich einem Lw zuordnest. Dazu bietet sich z. Bsp. generell das Lw b: an.

MfG Peter