Einfache und kompatible Verschlüsselung

Hallo anti-neutrino,

im Prinzip hast du deine Wahl ja schon getroffen ... .
Ich lasse einfach mal GnuPG außer acht, denn auch ich habe mich vor vielen Jahren von GnuPG weg und für S/MIME entschieden. Aber, auch GnuPG läuft auf allen Betriebssystemen, auch auf dem Androiden.

Wie die Verschlüsselung mit S/MIME funktioniert, bzw. was da zu tun ist, habe ich ja in meinem alten Beitrag in den FAQ ausführlich beschrieben.

Was die Versorgung mit Schlüsseln und Zertifikaten betrifft, hast du genau drei Möglichkeiten:
1.) Jeder meldet sich einzeln bei einem etablierten TrustCenter an und holt sich dort eines der beliebten "Kostnix-Zertifikate". Allerdings, seit dem eines der ältesten dt. TrustCenter an unsere Amerikanischen Freunde verkauft wurde, bin ich mir nicht mehr so ganz sicher, ob ich dieses weiterhin empfehlen sollte ... . Bis jetzt war das wirklich so, dass da nur ein Request mit dem öffentlichen Schlüssel ausgetauscht wurde, der (im eigenen Browser erzeugte!) private Schlüssel verbleibt auf dem Rechner!. Jetzt, nach amerikanischem Recht, bin ich da nicht mehr so sicher ... .

2.) Einer "spielt" TrustCenter.
Dazu installiert er sich eines der vielen guten CA-Programme. Mein absoluter Favorit: XCA, gibt es auch für die WinDOSe. Dann wird eine CA angelegt, und diese signiert dann die Zertifikate der einzelnen Nutzer. Jetzt müssen die Schlüsseldateien nur noch sicher verteilt werden. Die Zertifikate der CA und der einzelnen Nutzer kannst du ja in einen nicht verlinkten Ordner auf einer Webseite legen, wo sie von allen abgeholt werden können. Sogar Sperrlisten sind mit XCA möglich und der TB kann auch mit denen umgehen.
Wenn die XCA dann noch in einem Truecrypt-Container oder in einer VM läuft, ist das ganze eine recht sichere Angelegenheit.
Klar, wenn du die Schlüssel zentral herstellst, dann hat sie einer allesamt vorliegen. Aber bei einem geschlossenen Nutzerkreis sehe ich darin kein Problem - und außerdem kommt das Wort "Trust" ja nicht von irgendwo her.

3.) Wie unter 2., aber:
jeder installiert sich das CA-Programm, stellt für sich den eigenen priaten Schlüssel her, und schickt einen Zertifikatgsrequest mit dem öffentlichen Schlüssel zum "TrustCenter". Dieses zertifiziert ihn und schickt das Zertifikat zurück. So hat jeder den alleinigen ugriff auf seinen privaten Schlüssel, und ihr nutzt trotzdem eine gemeinsame Zertifizierungsstelle.

BTW: Ich habe vor 11 Jahren mal damit angefangen für mich, meine Familie und für Freunde Zertifikate herzustellen. Es begann mit 20 Stück pro Jahr (sie gelten bei mir wie im professionellen Bereich üblich, genau ein Jahr!). Mittlerweile hat sich das herumgesprochen, und jetzt sind es jährlich einige Hundert. Tendenz steigend. Ab und an lese ich in diversen Foren und Blogs, "dass man das ruhig machen kann ...".

Wenn du weitere Fragen hast, gerne.

edit: Zu deiner letzten Fragen:
Klar geht symmetrisch auch. Handelt es sich ausschließlich um Freunde der WinDOSe, dann sage ich nur: "Locknote" von Steganos. Ein einfacher Texteditor, der sich beim Beenden "selbst verschlüsselt", und nur nach Eingabe des Passwortes wieder als "Texteditor mit Text" zu sehen ist. Und diese .exe kann dann einfach verschickt werden. Einfacher geht es wirklich nicht.

MfG Peter

Hi anti-neutrino,

Zitat

- Als erstes erstelle ich mir eine neue Datenbank in XCA. (Passwortgesichert und möglichst auf geschützten USB-Stick)

korrekt
Wenn du dabei noch das Netzwerk deaktivierst ist alles in Ordnung.
Zumindest unter Linux schreibt das Programm auch nur in den definierten Ordner. Ich gehe aber davon aus, dass der Entwickler das auch auf der WinDOSe so eingerichtet hat, also dass er sonst keine temporären Dateien ablegt.

Zitat

- Dann brauche ich ein Herausgeberzertifikat? [unter "Zertifikate" - "Neues Zertifikat"? oder doch unter "Zertifikatsanträge"?] Auf längere Zeit anlegen und das ist bereits signiert. Das dann noch unter "Key usage" auf "Certificate sign" stellen?

Du musst als erstes ein selbst signiertes Zertifikat anlegen ("Nummer 1"). Dazu nutzt du das IMHO gleich angebotene Template "[default] CA". Bei sämtlichen TrustCentern ist das erste Zertifikat (root-, Wurzel- oder Herausgeberzertifikat genannt) immer ein selbst signiertes Zertifikat. Es sei denn, sie sitzen in der Hirarchie unter einem anderen Herausgeber und dann wird das Herausgeberzertifikat (der öffentliche Anteil des Schlüsselpaares!) durch den privaten Schlüssel dieser vorgelagerten CA signiert. Aber das trifft für dich ja nicht zu.
Gültigkeit: 10 bis 15 Jahre. Ja, es ist damit bereits signiert.
Alle Einstellungen können so bleiben, weil im Template bereits sinnvoll gesetzt. (Musst natürlich die korrekten Daten eintragen.
Da der TB damit locker umgehen kann (und mir die wenigen Sekunden längere Erzeugungszeit nichts ausmachen) verwende ich immer RSA-Schlüssel mit 4 Kbit.

Zitat

- Dann erstelle ich die Userzertifikate. Diese kann ich dann mit dem Herausgeberzertifikat signieren. Eigentlich gleiches Vorgehen wie beim Herausgeberzertifikat ("Zertifikate" - "Neues Zertifikat") nur bei "Unterschreiben" - "Verwende dieses Zertifikat zum unterschreiben..." auswählen? Als Key usage dann "Digital Signature" wählen?

Auch völlig korekt.
Du solltest einmal einen Zertifikatsantrag bis auf den echten Usernamen voll ausfüllen.
Ich schreibe bei "o" den Namen meiner CA rein, bei "OU" "user" bei Erweiterungen/Typ = Endinstanz, 1 Jahr (!) Gültigkeit, Digital Signature, key encypherment, data encypherment, E-Mail Protction und unter Netscape die von dir bereits erwähnte Bemerkung "XCA generatet Certificate. Nur für private Anwendungen und einfache Signaturen". (Wo hast du diese denn her?)
Ich lasse auch regelmäßig Sperrlisten generieren, und trage dafür unter "crl distributions point" den entsprechenden Ort ein. Aber ich denke mal, bei deinem kleinen Nutzerkreis ist das wohl etwas überdimensioniert.
Dann speichere ist dieses als Template "S/MIME-User" an, und rufe dieses Template bei jedem neuen Userzertifikat auf.
Gleiches mache ich natürlich auch für openVPN- SSL- und sonstige Zertifikate. Das spart bei der "Massenproduktion echt Zeit.
Selbstverständlich kannst du auch die Vorlage für die CA editieren und die entsprechenden Angaben (Name der CA usw.) fest vorgeben.

Zitat

Bei beiden Zertifikaten wäre SHA1 eine sinnvolle Auswahl?

SHA1 ist der immer noch übliche Algorithmus für die Signatur. Aber auch nur, weil international damit alle Mailclients zurecht kommen. Im eingeschränkten und eng begrenzten Nutzerkreis kannst du natürlich mit anderen Alg. experimentieren. Einen großen Gewinn hast du aber nicht.

Zitat

Ansonsten ist öfter von Templates die Rede, gibt es da vielleicht "Mustertemplates" für das übliche Procedere?

Wurde beantwortet.

Zitat

Brauche ich den Menüpunkt "Private Schlüssel" überhaupt?

Wo?
Bei der Erzeugung der Zertifikate ist das wohl selbsterklärend
Oder meinst du in der GUI ganz links?
So lange du die Zertifikate und Schlüsseldateien nicht exportiert hast, brauchst du die dort stehenden privaten Schlüssel selbstverständlich. Sonst kannst du sie nicht exportieren. Du kannst sie danach löschen (wenn der Empfänger die Schlüsseldatei erhalten und auch getestet hat ... .)
Die Schlüssel der CA und auch deine eigenen Schlüssel solltest du tunlichst dort stehen lassen. Und du solltest sie sogar exportieren und auf eine DVD brennen! Gemeinsam mit den exportierten Schlüsseldateien (.p12 oder .pfx) für die CA.
Ich empfehle sogar, die gesamte "Containerdatei "ca xxxxxx.xdb" nach Abschluss der Erzeugung der Zertifikate auf die DVD zu brennen. Denn: CA-Schlüssel weg = CA tot.
Und an dieser Stelle noch einmal zur Erinnerung: Die Nutzer können auch ihre Schlüssel selbst erzeugen, dir einen Request schicken, den du dann lediglich signierst. Dann hast du natürlich nur deine eigenen privaten Schlüssel vorliegen, incl. die deiner eigenen CA.

Zitat

Kann ich ganz auf Passwörter für die Zertifikate verzichten, wenn alle Zertifikate persönlich ausgetauscht werden?

Selbstverständlich kannst du das.
Für Serverzertifikate ist das sogar üblich. (Denn dort hast du ja niemanden, der bei jeder ssl-Verbindung das PW eintippt.)
Ob das "gut" ist, musst du selbst einschätzen. Das PW eines Softwaretokens ist lediglich ein Schutz auf dem Transport ("Transportpasswort")

Zitat

Mein Mailpartner erhält ja nur meinen öffentlichen Schlüssel, kann damit die Mail verschlüsseln und ich kann die Mail dann mittels des privaten Schlüssels wieder öffnen. Dafür reicht aber ein Zertifikat, oder? Mein Mailpartner erhält mittels meiner Signatur meinen öffentlichen Schlüssel und das wars?

Korrekt.
Ich empfehle folgendes:
- beim Export der Userzertifikate ("Schlüsseldateien") immer PKC #12 with Certifikate chain" anzugeben. Dabei wird in einer einzigen Containerdatei *.p12 der private Schlüssel des Users, sein Zertifikat und das Zertifikat der CA exportiert. Damit ist beim Import in den Mailclient immer gleich das Zertifikat des Herausgebers mit installiert. Diesem muss allerdings immer das Vertrauen bewusst ausgesprochen werden.
Ich übergebe immer am meine Nutzer:
- das Herausgeberzertifikat
- die jeweilige Schlüsseldatei, und
- das Zertifikat des Nutzers, welches er auch per Mail zusammen mit dem Herausgeberzertifikat an andere Nutzer übergeben kann.

Zitat

Vielleicht kann ich ja zu einer Art "XCA FAQ" mit beitragen, wenn ichs endlich ganz kapiert habe?

Wenn du dir das antun willst, gerne. Aber du solltest erst mal suchen, denn das gibt es doch garantiert schon.

Zitat

An dieser Stelle auch herzlichen Dank an Peter_Lehmann ohne den ich wohl nie so weit in die Materie eingestiegen wäre!

Gern geschenen!

MfG Peter

Hi,

Zitat von "anti-neutrino"

Ich kann mittlerweile unterschriebene Mails senden. Beim Empfänger ist meine Unterschrift aber natürlich noch nicht vertrauenswürdig, da der ja auch zusätzlich mein Root-Zertifikat ("Hauptzertifikat") braucht. Ich bin mir allerdings nicht sicher wie ich das in XCA exportiere, denn ich möchte ja auf keinen Fall meinen privaten Schlüssel o.ä. versehentlich mitsenden. Dieses Zertifikat kann ich ja theoretisch ganz offen verteilen (Homepage online stellen, an Mail anhängen etc.)?

Du musst sauber trennen zwischen Zertifikaten und den privaten Schlüsseln. Den root-Schlüssel (einzeln exportiert oder als Schlüsseldatei .p12 oder .pfx gemeinsam in einem Container mit dem Zertifikat), solltest du 1x exportieren, auf eine DVD brennen und an einer sicheren Stelle lagern.

Etwas völligt anderes ist es mit den Zertifikaten, sowohl denen der Nutzer als auch dem der CA. Diese kannst du ohne Sorge exportieren und frei verteilen. Beim Export werden die verschiedensten Formate angeboten. Am besten im .der-Format.
Das Programm "denkt mit". Immer dann, wenn du auch den privaten Schlüssel exportieren willst, wirst du nach einem (Transport-)Passwort gefragt. Exportierst du nur die Zertifikate, entfällt diese Frage.

Zitat

Möchte ich jetzt allerdings eine verschlüsselte Mail an mich senden, will Thunderbird ein persönliches Zertifikat angegeben wissen! Braucht mein Mailpartner also auch ein eigenes Zertifkat, um mir verschlüsselte Mails zu senden??? Ich dachte mein Root-Zertifikat + mein durch die unterschriebene Mail mitgesandtes Zertifikat genügen?

Wenn du eine Mail an einen Empfänger verschlüsselt versenden willst, dann benötigt dein Mailclient immer das Zertifikat (den öffentlichen Schlüssel) des Empfängers.
[So sage ich das immer in meinen Vorträgen: Der öffentliche Schlüssel ist der "Zuschließ-Schlüssel". Der private Schlüssel ist der "Aufschließ-Schlüssel".]
Wenn bei einem Empfänger das CA-Zertifikat bereits importiert ist, und diesem das Vertrauen ausgesprochen ist, dann importieren die meisten Mailclients bei einer empfangenen Mail das Zertifikat des Absenders gleich automatisch. Da sie aber in der Regel das CA-Zertifikat noch nicht importiert haben ..., funktioniert das dann nicht.

Wenn du bei deiner geschlossenen Nutzergruppe die Schlüsseldateien verteilst, dann verteile doch einfach die paar Zertifikate deiner Nutzer und dein CA-Zertifikat gleich mit. Oder schicke denen einen Link zu einer Webseite, wo sie das CA-Zertifikat und die einzelnen Benutzerzertifikate herunterladen können, verbunden mit einem kleinen Text für die Einrichtung. Im professionellen Bereich liegen die Zertifikate auf einem ldap-Server, und die Clients holen sich, was sie brauchen.
Ich verschicke meinen Usern die Zertifikate per Mail, einschließlich einem .pdf für die Anleitung.

Und noch was ist bei allen Mailclients sehr wichtig:
Du musst dem Client (jedem Mailkonto einzeln!) in den Kontoeinstellungen mitteilen, welchen eigenen privaten Schlüssel dieses Konto fürs Signieren und fürs Entschlüsseln nehmen muss.

OK?

MfG Peter

Normalerweise ... benötigst du ausschließlich zum Verschlüsseln lediglich das Zertifikat des Mailpartners und das Zertifikat des Herausgebers. Da da ja nicht signieren willst, ist kein eigener priv. Schlüssel erforderlich.

Nur, warum auch immer, verlangt Thunderbird einen solchen. Ich gehe mal davon aus, dass das so gewollt ist. Der Empfänger soll doch auch verschlüsselt antworten

MfG Peter

Darf ich hier so nebenbei erfragen welche Zertifikatsversion mit welchen Methoden mit den Tools (privat) generiert werden kann?

Lohnt sich nicht mehr
http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/

Was wollte mir BeeHaa damit nur neues mitteilen?
Es hätte meine dritte Neuigkeit an meinem heutigen "Lerntag" sein können. Nur diese Information ist leider so neu nicht (hier müsste jetzt ein Icon für "gähn" stehen).

Peter was für einen Browser nutzt du? Zeigt der echt nur den jeweils letzten Beitrag eines Threads?

Was den "letzten" Beitrag angeht ist so ein Thread natürlich nicht nur dafür da um ausschliesslich dir Nachrichten als Neuigkeiten zu vermitteln. Trotzdem danke für die Infos...

SMIME ist zwar eine Lösung, aber Es ist fast unmöglich, einen großen Prozentsatz der Kontakte zum Verschlüsseln zu überreden, weil beides: SMIME und PGP-Enigmail nicht einfach genug sind, um für alle gemacht zu sein. Man braucht leider immer noch ein wenig Komputerkenntnisse um erfolgreich zu verschlüsseln.

Es müsste eine einfache Lösung geben, wie OTR ("Off The Record")-Verschlüsselung für Chat-Nachrichten, wo die Schlüssel automatisch ausgetauscht werden.
In einem zweiten Schritt erst kann man optional die Identität noch manuell verifizieren. Aber dieser zweite Schritt ist halt nur optional.
Auf diese Weise wäre zumindest die E-Mail-Verschlüsselung ohne jegliche Kenntnisse möglich.

Das Wichtigste wäre, dass die Verschlüsselung automatisch passiert, ohne dass der Benutzer irgendwas konfigurieren muss.

Hier ist der Request, dies in Thunderbird einzubauen: https://bugzilla.mozilla.org/show_bug.cgi?id=876212
bitte hochvoten oder ein Addon Entwickeln!

hmm oder web.de und co stellen den server so ein, das man nur noch Verschlüsselt Versenden/empfangen kann, den ist schon mal der Transport verschlüsselt vom Versender zum Empfänger.

Sonst ich habe PGP nie gemacht.
Ich bin nicht wichtig für irgend wer wo böses will. vielleicht verschlüsselt man besser wenn man ein Persönlichkeit ist aus Politik/unternehmen wo jeder in kennt.
Aber so ein Normaler kleiner Bürger, lohnt sich doch nicht wenn er nicht gerade Dreck am stecken hat.
Was will man den verschlüsseln wo so wichtig ist im Privat Bereich??? wo man sowieso nicht per Mail sendet sondern persönlich bespricht.

es gibt viele gründe für jeden: https://www.google.de/search?q=why+e…crypt+emails%3F

auch falls du nichts zu verbergen hättest

Hallo,

Zitat

hmm oder web.de und co stellen den server so ein, das man nur noch Verschlüsselt Versenden/empfangen kann, den ist schon mal der Transport verschlüsselt vom Versender zum Empfänger.

Die Verschlüsselung erfolgt aber nur bis zum ersten Server und danach ist wieder alles unverschlüsslt bis zum Empfänger. Wenn du SSL/TLS meinst.

Gruß

ja genau
Aber das könnte man den durch erweiterungen sicher so weiterführen zum Empfänger?