Seitenhierarchie
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Vorwort

Wir leben im Jahre 2012, (E-Mail-)Verschlüsselung und die Nutzung kryptografischer Systeme ist aber noch immer nicht einfach genug und eigentlich auf dem Stand wie von vor >10 Jahren!!!

Also bitte etwas Geduld und VIEEEEEL Verständnis mitbringen.
Eine vollständige PKI (Public Key Infrastructure) in der der Nutzer wenig wissen muss über das wie und warum, seine "Chipkarte" hat wie in großen Konzernen trägt sich finanziell und vom Aufwand schlicht nicht für KMU / Privat!

Grundlagen

Achtung: Im Sprachgebrauch wird das Wort "Zertifikat" oftmals abkürzend für eine der folgenden Bedeutungen genutzt:

  • Webserver-Zertifikat (privater oder öffentlicher Schlüssel)
  • Client-Zertifikat (privater oder öffentlicher Schlüssel)
  • Root-Zertifikat (öffentlicher Schlüssel der CA (privater Teil gelangt niemals an Öffentlichkeit, somit haben wir an der Stelle nichts damit zu tun))

Folgendes Kapitel beschränkt sich auf die Nutzung von S/MIME (Secure MIME) / x509 Zertifikaten im E-Mail-Verkehr.

S/MIME hat mit PGP (Pretty Good Privacy) oder OpenPGP (oftmals via Implementierungen á la GnuPG) nichts gemein (außer evtl. gleichartiger Verschlüsselungsalgorithmen)! 
Folgende Informationen lassen sich also nur bedingt auf diese von uns nicht genutzten Verschlüsselungen übertragen!

Nutzung verschlüsselter E-Mails allgemein

E-Mails werden grundlegend immer hybride verschlüsselt, also an den Absender UND an den Gegenüber (sonst könnte man seine eigenen gesendeten Nachrichten nicht mehr lesen). 
Beide stellen in der Regel natürliche Personen mit zugeordneten E-Mail-Adressen dar.

  1. Anton sendet signierte Mail an Berta
    • nun ist dem Berta das Zertifikat/öffentliche Schlüssel des Gegenüber bekannt
  2. Berta sendet verschlüsselte oder signierte Mail an Anton
    • da sowohl das Zertifikat des Gegenüber als auch das Root-Zertifikat vorliegt, kann die Mail direkt verschlüsselt werden. Derweil kennt aber Anton das Zertifikat von Berta noch nicht.
  3. Anton erhält signierte oder verschlüsselte eMail von Berta mit dem fremden Zertifikat/öffentlichen Schlüssel und kann nun auch eine verschlüsselte Mail an Berta senden

Dateiformate

Der Austausch von Zertifikaten kann auf vielen verschiedenen Wegen und Formaten erfolgen.

Eigene Zertifikate werden oftmals im p(kcs)12 Format gesichert. 
Dieses Format enthält in der Regel alle drei Teile:

  • den eigenen privaten Schlüssel (private-Key)
  • den eigenen öffentlichen Schlüssel
  • den zugehörigen öffentlichen Root-CA Schlüssel

Fremde öffentliche Schlüssel erhält man:

  • im Zuge einer signierten oder verschlüsselten E-Mail
  • im Dateiformat PEM (ASCII kodiert, meist als .pem oder .crt erkennbar), DER (binär kodiert, meist .der)

Fremde private Schlüssel erhält man:

  • hoffentlich nie (Zwinkern)

Kostenloser Einstieg

Zum "how to get a S/MIME cert" gibt es unter http://kb.mozillazine.org/Getting_an_SMIME_certificate denke ich ausreichend Informationen die wir nicht nochmal übersetzen müssen.
In Europa ist aber die Auswahl recht eingeschränkt da viele der kostenfreien Anbieter nur USA und Canada abdecken.

Meine S/MIME Zertifikate werden in der Regel über CACert.org ausgestellt.

Was is CAcert?

CAcert.org ist eine freie Organisation, die es sich zum Ziel gesetzt hat kostenfreie eine ROOT-CA zu betreiben und den Nutzern X509 (S/MIME) sowie GPG-Zertifikate zur Verfügung zu stellen.

Wer PGP/GPG oder andere CAs wie Thawte kennt, kennt sicherlich das Konzept des "Web of Trust".

Hierbei geht es darum, dass ein "Assurer" (bei Thawte Notar) natürlichen Personen "Punkte" vergeben darf wenn er seine Identität anhand gültiger Ausweise verifiziert.
Hat eine Person ausreichen Punkte "gesammelt" gilt er selbst glaubwürdig genug um anderen Punkte zu schenken. 
Das ganze hat also einen "Community" Charakter.

CACert.org gehört derzeit (März 2012) noch nicht in allen Browsern, Mail-Clients und Betriebssystemen zum "Standard-Repertoire".
In Microsoft Produkten wird dies auch vermutlich nie geschehen, da Sie monatlich Geld verlangt um eine CA aufzunehmen und als "glaubwürdig" zu betrachten (kann CAcert als selbsttragende Organisation nicht leisten). 
Alle anderen Produkte werden zukünftig vermutlich CAcert aufnehmen, nachdem Mozilla gemeinsam mit CAcert ein Papier entwickelt hat nachdem festgeschrieben ist welche Rahmenbedingungen erfüllt sein müssen. CAcert musste sich daraufhin allerdings erst mal an die eigene Nase greifen und stellt gerade seine Systeme um.

Das Punktesystem von CAcert ist online unter http://www.cacert.org/index.php?id=19 zu finden

Und was bieten Kommerzielle Anbieter for Free?

Comodo / InstantSSL

https://www.instantssl.com/ssl-certificate-products/free-email-certificate.html

oder https://www.comodo.com/home/email-security/free-email-certificate.php

StartSSL

StartCom / StartSSL ist "gestorben":heise.de/-3341294

 Klicken Sie hier, um zu erweitern...

StartSSL.com bzw. dessen Tochter StartSSL.org bieten sowohl für privat als auch für Firmen SSL und x509 Zertifikate.

Der Vorteil gegenüber CAcert ist, dass das Root-Zertifikat der StartSSL PKI bereits auf vielen Plattformen eingebunden ist und somit in E-Mails und Webseiten keine "Fehlermeldung" erscheinen.

Der Nachteil: Das WoT ist soweit reglementiert, als dass diejenigen die andere Beglaubigen wollen auch zahlendes Mitglied sein müssen. Allerdings hält sich dies in Grenzen (~50 € / Jahr / Person)

 

Weitere öffentliche Zertifikatsstellen (CAs) …

…die nicht unbedingt mitinstalliert sind aber von anderen gerne im E-Mail-Verkehr genutzt werden:

E-Mails und Signaturen nach Signaturgesetz

Eine Übersicht der Kosten und Leistungen akkredierter CAs nach SigG findet man unter: Elektronische Signatur

Zertifikate nach SigG werden idR. nicht Software basiert sondern auf SmartCards ausgegeben weshalb zusätzlich Hardware, Software und Wissen zum Umgang mit ebensolchem nötig ist.

Welcher Client unterstützt was, was brauche ich also noch?

Ich verweise hier mal auf E-Mail Clients

S/MIME Nutzung in KMU

Kleine und Mittelständische Unternehmen tuen sich schwer mit S/MIME, einerseits möchte man mit anderen Unternehmen E-Mails verschlüsselt austauschen, andererseits hat man nicht die Mittel wie Konzerne und ggf. nur eingeschränkt Personal sich dieser Sache zu widmen...zugegeben, letzteres ist ein schlechtes Argument ;)

In meiner Erfahrung hat sich folgendes Vorgehen bewährt:

Grundregeln

  1. Jeder Mitarbeiter kann von der Firma ein persönliches Zertifikat bekommen um Mails verschlüsselt zu erhalten / zu versenden sowie sich ggü. Web-Diensten mittels Zertifikat zu authentifizieren. 
    Alternativ kann das ein jeder persönlich (mit Vor- und Nachteilen) für sich selbst bei CAcert.org oder bspw. Comodo kostenfrei tun.
    Vorteil der von der Firma ausgerollten Zertifikate: Bei CAcert trägt jeder MA direkt seinen vollen Namen und den Organisationsnamen im Zertifikat ohne selbst am WoT teilnehmen zu müssen. 
  2. Die Firma stellt EIN Zertifikat bereit, das jeder Mitarbeiter installieren muss und auf z.B. secure@example.com ausgestellt ist.
    Im Mail-Client muss dieser "Account" dann auch eingerichtet sein.
  3. Bestimmte Gruppen wie "Management" oder "Personal" haben zusätzliche Zertifikate, für z.B. personal@example.com, die primär nur für den internen Gebrauch bestimmt sind.
  4. Die Liste der unterstützten Mail-Clients sollte klar definiert sein. Hierzu können zählen: Windows mit Outlook (kein Express / Windows Mail), Apple Mail auf dem Mac und Cross-Plattform Thunderbird
    (was sich mit den unterstützten und empfohlenen Mail-Clients decken sollte!). 
    SSL/Zertifikats-Probleme mit allen anderen möglichen Programmen wie Entourage und auch Webmailer (Horde, OWA, etc.) sollten ausgegrenzt werden!
  5. alte/abgelaufene Zertifikate können aus Browsern wie Firefox entfernt werden da diese nicht weiter für Authentifizierungen genutzt werden können, dürfen jedoch NICHT aus Mail-Clients gelöscht werden, da sonst alte Korrespondenz nicht mehr entschlüsselt werden kann.

ergänzende Informationen

  • zu 1) werden Mails alleinig zwischen Kunde und Mitarbeiter verschlüsselt ausgetauscht, ist das vielleicht zweckdienlich, allerdings unbrauchbar sollte dieser Mailverkehr in einem öffentlichen IMAP-Ordnern abgelegt werden -> siehe zu 2)
  • zu 2) da E-Mails zwischen zwei Personen nicht für Dritte einsehbar ist (ich erspare mir hier das warum (Zwinkern)), wird eine /dev/null-Adresse (nonGeek: Mülleimer-Adresse) namens: 
    secure@example.com 
    eingerichtet, an die E-Mails immer in CC (oder BCC) geschickt werden sollen. 
    Diese E-Mails, welche somit an mich selbst, den Gegenüber UND secure@ verschlüsselt sind können im IMAP abgelegt und von jedem Mitarbeiter mit dem ausgegebenen Schlüssel wieder gelesen werden. 

    Das Zertifikat wird turnusmäßig (idR. jährlich) erneuert und an alle Mitarbeiter ausgegeben. 
    Das zugehörige Passwort für den Import ist bei der Systemadministration zu erfragen und kann aus Sicherheitsgründen nicht "irgendwo hinterlegt" werden.
  • zu 3) diese Adressen verhalten sich exakt wie secure@, es stehen also keine direkten Empfänger dahinter und dienen nur als Mittel damit E-Mails im IMAP Verzeichnis verschlüsselt für eine Personengruppe abgelegt werden können. Der Austausch/Erneuerung der Zertifikate bleibt den jeweiligen Mitgliedern vorbehalten und kann / darf auch von der Systemadministration nicht erfolgen (höchstens mit Unterstützung von am Rechner des MA).

Spielregeln mit Kunden

  1. Mails sollten (wenn verschlüsselt) immer an den Kunden UND an secure@example.com verschickt werden. 
    Et vice versa.
  2. Sollte der Kunde mit der Firma noch keine verschlüsselten E-Mails ausgetauscht haben, so ist es nötig ihm folgende Informationen/Daten zu geben bzw. mit der IT abzuklären:
    • Ausstellende Zertifizierungsstelle (besonders wichtig bei CAcert.org). 
      Ist diese beim Kunden nicht bekannt muss das zunächst erfolgen damit keine Meldungen der Art "unglaubwürdige Absender" erscheinen bzw. die Entschlüsselung fehl schlägt.
    • Dem Kunden muss vor der ersten verschlüsselten Mail eine signierte Mail geschickt werden (in dem Moment bekommt er den public-Key)
    • Dem Kunden muss vor der ersten verschlüsselten Mail der public-Key von secure@ geschickt werden damit er darauf verschlüsselt antworten kann
  3. Sollten Kunden Mail-Gateways für Verschlüsselungen einsetzen, so ist unter Umständen eine verschlüsselte Antwort nicht möglich! 
    (Warnung) Beim Antworten darauf Achten, welche Daten im Reply hängen wenn etwas unverschlüsselt raus geht!!

Ungeahnte Möglichkeiten, Ungeahnte Probleme

Probleme kann das Ganze Szenario dann bringen, wenn eine Langzeit-Archivierung der E-Mails gefordert ist. Allerdings sollte dies dank des zentralen "Schlüssels" für secure@ kein Problem darstellen.

Fehlerquellen

  • wenn die CAcert Root Zertifikate nicht oder falsch importiert wurden, kann es zu Meldungen kommen wie "Zertifikat nicht vertrauenswürdig" etc.in dem Fall bitte die Root-CAs von CAcert einmal aus dem Zertifikatsmanager löschen und erneut importieren

 

Alles wird gut ...

p≡p - pretty Easy privacy

Autocrypt

Meht dazu:

 

DNS-Based Authentication for S/MIME (rfc8162)

aka SMIMEA aka TYPE53

Mehr dazu;:

 

DANE for OpenPGP Keys (rfc7929)

aka OPENPGPKEY aka TYPE61

Mehr dazu:

 

 

  • Keine Stichwörter