S/MIME supported E-Mail Clients

The following excerpt should give an overview over S/MIME capable E-Mail Clients.

Im folgenden soll eine kurze Übersicht über S/MIME kompatible E-Mail Clients gemacht werden:

Full E-Mail Clients that support S/MIME

  • Microsoft Outlook 2007, 2010, 2013, 2016, 2019, Office 365 – macOS, Windows
  • Mozilla Thunderbird since Version 5 – macOS, Linux, Windows
  • Apple Mail – macOS, iOS
  • CipherMail – Android
  • Lotus Notes since Version 9- macOS, Linux, Windows
  • emClient – macOS, Windows
  • K9 Mail – Android
  • Blackberry Hub – Android
  • Zimbra – Linux, Windows Mail
  • Kopano – macOS, Linux, Windows
  • The BAT! by Ritlabs – Windows
  • Knox – Samsung Android
  • Windows Phone Mail – Windows Phone

Full E-Mail Clients that support S/MIME

  • Gmail / Googlemail Free with reduced set – Eduation / Enterprise with full set
  • Mailvelope – Browser Add-On for multiple Webmailers GMX, posteo, web.de, Gmail, mail.ru, outlookk.com, yahoo
Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , , | Hinterlasse einen Kommentar

E-Fail und S/MIME Fixes

2018 wurden unter Efail mehrere Methoden vorgestellt, E-Mail Verschlüsselungsprotokolle OpenPGP/PGP bzw. S/MIME über unzureichend abgesicherte Mailclients anzugreifen. Ziel eines Angreifers ist es dabei den Inhalt der verschlüsselten Nachricht zu erhalten.

Er macht dies indem er eine verschlüsselte E-Mail abfängt und diese mit ausführbaren Code (z.B. JavaScript) erweitert. Anschließend schickt er die Nachricht weiter an den eigentlichen Empfänger. Führt der empfangende E-Mail Client den Code aus, ist es möglich das Teile der eigentlichen verschlüsselten (aber erweiterten) Mail an den Angreifer zurückgesendet wereden.

Ein paar Punkte seien dazu gegen die allgemeine Hysterie angefügt:

  • Efail und E-Mail Signing: E-Fail wirkt sich nicht auf die Digitale Signatur via S/MIME / OpenPGP aus. Eine signierte E-Mail ist bereits im Klartext, würde ein Angreifer sie abfangen kennt er den Inhalt. Eine E-Fail Attacke wäre daher wirkungslos. E-Mail Signing mit einer unversehrten Signatur beweist, dass die E-Mail vom eigentlichen Sender stammt (Digitale Identität = Zertifikat) und nicht im Verlauf geändert wurde. Ein E-Fail Angriff würde die Signatur brechen (zumindest bei Encrypt then Sign).
  • Efail wirkt sich nicht auf Enterprise E-Mail Gateways aus: Enterprise E-Mailgateways die für S/MIME – PGP/OpenPGP Verschlüsselung / Entschlüsselung eingesetzt werden – sind nicht anfällig gegenüber E-Fail weil sie den „ausführbaren“ Code innerhalb der manipulierten Mails nicht interpretieren. Beispiele: NoSpamProxy, Reddoxx,
    SeppMail, Totemo Mail, Zertificon etc..
  • Alle gängigen E-Mail Clients haben bereites einen Patch erhalten u.u.:
    • iOS in Version 12.2
    • Thunderbird 52.9
    • Microsoft Outlook – (ja auch das im Gegensatz zu landläufiger Meinung ) – mit dem Outlook October 2018 Patch KB4461440 – wird external Content (extern refererenzierte HTML Images etc.) in S/MIME Mails blockiert. Mit den März Patches wurde dies auf S/MIME encryptete Mails eingeschränkt und bei signierten wieder aufgehoben. Das Verhalten kann auch im Outlook Trustcenter bzw. über Registry gesteuert werden
01_securemaildownload.jpg



HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\Security
Create a new key as follows;
Type=REG_DWord “DisallowSMIMEExternalContent“
Value=0

Fazit: S/MIME und OpenPGP bleiben auch nach EFail sehr sichere Methoden um E-Mails zu schützen

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , , , , | Hinterlasse einen Kommentar

„Mail Object Encryption – Verschlüsseln des Mailobjekts selbst“

Bei Mail Object Encryption wird die Verschlüsselung auf das Mailobjekt selbst angelegt. Unabhängig davon wie viele MTAs (Mail Server) im Internet überschritten werden und wie der Traffic geroutet wird, kann nur der Besitzer des Private Keys des Empfängers die Nachricht entschlüsseln. Dies ist der höchste mögliche Security Level für E-Mail Verschlüsselung. Verbreitete Standards sind S/MIME oder OpenPGP/PGP


Encryption on Mail Object Layer

OpenPGP / PGP Standards

  • Technologie:
    • Outbound E-Mail Traffic: OpenPGP verwendet einen Open Source Standard, um E-mails mit dem public PGP Key des Empfängers zu verschlüsseln. Der Public Key muss dazu vorher vom Empfänger übergeben und geprüft worden sein
    • Inbound E-Mail Traffic: Das verschlüsselte Mail Object wird mit dem private Key des Empfängers bei diesem entschlüsselt.
  • Vorteile:
    Anstelle des MTAs (Mail Transfer System) wird der eigentliche Sender der Nachricht verifiziert. Unabhängig wie viele MTAs die Mail überschreitet bleibt das Mail Object sicher verschlüsselt solange bis der Besitzer des private Keys des Empfängers die Nachricht entschlüsselt. Im Gegensatz zu einigen TLS Arten ist kein Protocol Downgrade und kein Spoofing des Empfängers möglich.
  • Nachteile: Viele Mail Clients unterstützen OpenPGP / PGP nicht. Es gibt zudem keine zentrale Sperrlisteninfrastruktur wie bei S/MIME CRls auch die Vertrauensstellung muss manuell getroffen werden und ist nicht über Public CAs einfacher skalierbar.
  • Empfehlung: Setzen sie OpenPGP/PGP ein wenn es Business Partner von Ihnen verlangen. Ansonsten verwenden Sie den einfacher zu handhabenden S/Mime Standard.

S/MIME Standard

  • Technologie:
    • Outbound E-Mail Traffic: S/MIME verschlüsselt E-Mails mit dem public S/MIME Key des Empfängers. Der Public Key muss dazu vorher vom Empfänger übergeben und geprüft worden sein
    • Inbound E-Mail Traffic: Das verschlüsselte Mail Object wird mit dem private Key des Empfängers bei diesem entschlüsselt.
  • Vorteile:
    Anstelle des MTAs (Mail Transfer System) wird der eigentliche Sender der Nachricht verifiziert. Unabhängig wie viele MTAs die Mail überschreitet bleibt das Mail Object sicher verschlüsselt solange bis der Besitzer des private Keys des Empfängers die Nachricht entschlüsselt. Im Gegensatz zu einigen TLS Arten ist kein Protocol Downgrade und kein Spoofing des Empfängers möglich. S/MIME wird von den meisten E-Mail Clients out of the box unterstützt. Im Vergleich zu OpenPGP / PGP skaliert die Technologie besser, da Trust Entscheidungen über Verwendung von Public Certification Authorities vereinfacht werden. Zudem gibt es für S/MIME zentrale Sperrlisteninfrastrukturen der Public CAs.
  • Nachteile: Manche Webmail Clients unterstützen kein S/MIME nativ sondern über Full E-Mail Clients (Outlook, Thunderbird etc.)
  • Empfehlung: Verwenden sie S/MIME für vertrauliche Nachrichten, da sie eine volle Verschlüsselung des Mail Objekts gewährleisten solange bis der Empfänger die Nachricht mit seinem Private Key öffnet.

Vgl. Q &A Secure E-Mail Communication on https://mailprotection.redbull.com : „Resason for using Secure E-Mail communication“

sowie

Q &A Secure E-Mail Communication on https://mailprotection.redbull.com/standards : „Which Standards we offer and why“

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar

Encryption on Transportlayer – im Detail

Wie im Übersichtsartikel beschrieben wird die Verschlüsselung in einem Transporttunnel zwischen dem sendenden und den ersten empfangenden MTA eingerichtet. Der TLS Tunnel verschlüsselt dabei den SMTP Protocol Exchange und im Optimalfall auch alle zwischen den MTAs ausgetauschten Maildaten. Das Mailobjekt selbst wird aber nicht geschützt – sondern nur der Tunnel!

Encryption on Transport Layer - SMTP over TLS, opportunistic TLS, forced TLS, forced TLS with certificate check
Encryption on Transport Layer

Es gibt 3 Arten diesen verschlüsselten Tunnel handzuhaben, die sich vornehmlich in der Kompliziertheit/Aufwand der Einrichtung und dem Security Level unterscheiden.

Encryption on Transport Layer - Standards - layered in security Level and complexity in setup and maintenance
Encryption on Transport Layer – Standards

Opportunistic TLS

  • Technologie:
    • Outbound E-Mail Traffic: Erstellt einen verschlüsslten TLS Tunnel zum 1. empfangenden MTA (Mail Transfer System) falls dieser MTA SMTP over TLS unterstützt und ein funktionierendes, installiertes Serverauthentifizierungs-Zertifikat besitzt.
    • Inbound E-Mail Traffic: Wenn der sendende MTA versucht verschlüsselt über SMTP over TLS zuzustellen und SMTP over TLS ist aktiviert und ein beliebiges(!) Serverauthentifzierungszertifikat ist installiert – so wird die eingehende Zustellung erlaubt.
  • Vorteile:
    Wenn beide MTAs SMTP over TLS konfiguriert haben und sich auf diese Methode einigen – wird jeglicher SMTP/Mail Verkehr vom sendenden bis zum 1. empfangenden MTA via SMTP over TLS auf der Transportebene verschlüsselt. Der Administrative Aufwand für die Einrichtung ist niedrig (beliebiges Self signed Zertifikat ist ausreichend (!)) , opportunistic TLS skaliert ohne weitere Mail Ruleset Changes gut und im Fehlerfall gehen in der Regel keinerlei Mails verloren (Fallback s.u.)
  • Nachteile:
    Wenn einer der 2 MTAs SMTP over TLS nicht unterstützt oder dabei ein temporärer Fehler auftritt so werden die E-Mails unverschlüsselt zugestellt (Protocol Downgrade). Zudem wird immer nur der Verkehr zwischen dem sendenden und dem 1. empfangenden MTA beeinflussbar verschlüsselt. Falls auf dem Weg der E-Mail mehrere MTAs überschritten werden – so ist deren Verschlüsselungsstatus nicht beinflussbar bzw. sie sind unverschlüsselt. E-Mail Spoofing und Man-in-the-Middle Angriffe sind leicht möglich: Da das Zertifikat des MTAs nicht geprüft und validiert wird kann DNS Spoofing bzw. Rerouting des Mailverkehrs und Einsatz eines Self Signed Zertifikats dazu führen, dass unautorisierte Personen/Systeme den E-Mail Verkehr abfangen, lesen bzw. deren Inhalte extrahieren ohne dass es Absender und Empfänger merken.
  • Empfehlung: Opportunistic TLS sollte auf jedem MTA als Default Einstellung gesetzt werden. Dies aber mehr aus Kompatibilitätsgründen denn aus Sicherheitsgründen. Für echte Vertraulichkeit im E-Mail Verkehr reicht diese Technologie nicht.

Forced TLS

  • Technologie:
    • Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel für eine spezifische Mail Zieldomäne (@example.com).
    • Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen/IP Adresse) versucht verschlüsselt über STMP over TLS zuzustellen, wird dies akzeptiert. Unverschlüsselte Mails vom gleichen MTA werden dagegen verworfen.
  • Vorteile: Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA für die spezifizierte Maildomäne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschlüsselt. Kein unverschlüsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Domäne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr möglich.
  • Nachteile: Forced TLS für SMTP skaliert schlecht. Für jede Zieldomäne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails können verloren gehen, wenn es temporäre Probleme mit SMTP over TLS bei der für die empfangende Domain zuständigen MTA gibt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA über den verschlüsselten Tunnel geschützt. Wenn die E-Mail mehrere MTAs durchläuft so ist ihr Verschlüsselungsstatus unklar bzw. ist sie unverschlüsselt. E-Mail Spoofing Angriffe und Man-in-the-Middle Angriffe sind weiterhin möglich, das es keinerlei Zertifkatsprüfung/Validierung gibt.DNS Spoofing / Rerouten von Traffic und Einsatz von einem selbstsignierten Zertifikat kann weiterhin dazu führen dass unautorisierte Personen/Systeme die E-Mails lesen bzw. deren Inhalte extrahieren ohne dass es die Empfänger merken.
  • Empfehlung: Setzen sie reines forced TLS nur ein, wenn es ein Businesspartner aus Compliance Gründen von Ihnen verlangt. Für einen echten Sicherheitsgewinn setzen sie dagegen forced TLS nur mit Zertifikatsvalidierung (siehe unten) oder gleich eine der Mailobjektverschlüsselungs-Technologien wie S/MIME ein.

Forced TLS with certificate check

  • Technologie: 
    • Outbound E-Mail Traffic: Erzwingt (forced) einen TLS Tunnel für eine spezifische Mail Zieldomäne (@example.com). Das digitale Zertifikat des MTAs der Zieldomäne wird zusätzlich validiert u.a.:
      • Passt der SAN/CN zur Zieldomäne?
      • Ist das Zertifikat noch gültig?
      • Ist das Zertifikat ggf. gesperrt (OCSP/CRL check)?
      • Ist das Zertifikat trusted?
      • Ist das Zertifikat vom richtigen Typ – z.B. server authentication flag.
    • Inbound E-Mail Traffic: Wenn der sendende MTA (in der Regel identifiziert durch Hostnamen/IP Adresse) versucht verschlüsselt über STMP over TLS zuzustellen und das Zertifikat wird geprüft wird dies akzeptiert. Unverschlüsselte Mails vom gleichen MTA werden dagegen verworfen.
  • Vorteile:
    Jeglicher Verkehr der zwischen dem sendenden und dem 1. empfangenden MTA für die spezifizierte Maildomäne (@example.com) gesendet wird, wird mittels SMTP over TLS auf der Transportebene verschlüsselt. Kein unverschlüsselter SMTP Verkehr kann Richtung MTA dieser spezifizierten Domäne losgeschickt werden. Protocol Downlevel Angriffe auf dieser Verbindungsstrecke sind nicht mehr möglich. Durch die zusätzlich Zertifikatsüberprüfung sind Spoofing bzw. Man-in-the-Middle Angriffe zwischen dem sendendend und dem für die Zieldomäne autorisierten Mailserver nicht mehr möglich.
  • Nachteile:  
    Forced TLS with certificate check für SMTP skaliert schlecht. Für jede Zieldomäne muss eine spezifische Rule auf dem Mailgateway erstellt werden. Mails können verloren gehen, wenn es temporäre Probleme mit SMTP over TLS bei der für die empfangende Domain zuständigen MTA gibt. Mails können verloren gehen, wenn der Zertifikatscheck des MTAs für die Zieldomäne fehlschlägt. Weiterhin wird die E-Mail nur auf der Strecke vom sendenden bis zum 1. empfangenden MTGA über den verschlüsselten Tunnel geschützt. Wenn die E-Mail mehrere MTAs durchläuft so ist ihr Verschlüsselungsstatus unklar bzw. ist sie unverschlüsselt.
  • Empfehlung:
    Setzen sie forced TLS with certificate check nur ein, wenn es ein Businesspartner aus Compliance Gründen von Ihnen verlangt oder wenn sie vertretbare Sicherheit haben wollen und keine Verschlüsselung auf Mailobjektebene mit dem Businesspartner möglich ist.

Wie schaut es nun mit der Sicherheit bei Verschlüsselung auf Mailobjekt-Ebenes aus – so viel sei verraten: deutlich besser. Mehr dazu hier


Vgl. Q &A Secure E-Mail Communication on https://mailprotection.redbull.com : „Resason for using Secure E-Mail communication“

sowie

Q &A Secure E-Mail Communication on https://mailprotection.redbull.com/standards : „Which Standards we offer and why“

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar

Überblick über die Welt der E-Mail Verschlüsselung

So lange es E-Mail gibt, so lange diskutiert man darüber wie denn ein sicherer Versand und Zustellung gewährleistet werden kann. Doch was heißt hier sicher? Neben einer adäquaten Spam und Malware Filterung und einer anständigen Verfügbarkeit des Dienstes, möchte man natürlich ein paar Dinge wissen.

  • Ist eine abgesendete Mail wirklich von demjenigen Absender der im Absenderfeld auftaucht und kommt sie genau so bei mir an, wie sie an mich versendet wurde? Denn könnte ich das gewährleisten, wären nahezu jegliche Fraudthemen passè. (Man erwarte den 2. Teil des Blogeintrags…)
  • Kann jemand auf dem langen Weg der E-Mail über die unendlichen weiten des Internets, diese abfangen, sie lesen bzw. deren Inhalt extrahieren und Ihn weitergeben?

Natürlich kann er das, wenn die E-Mail nicht verschlüsselt wurde. Im Prinzip ist es jedem möglich, der an der Leitung oder an Knotenpunkten auf dem Weg vom Sender bis zum Empfänger Netzwerkverkehr dupliziert, extrahiert oder mitschnüffelt. Das können Mailprovider, Netzwerkprovider, Telekommunikationsunternehmen, Geheimdienste , Intelligence Researcher und andere staatliche Behörden etc. sein. Bemerken kann man das nicht.

Aber man kann sich schützen. Entgegen aller Hysterie (hier der Verweis auf E-Fail) ist E-Mail Verschlüsselung je nach Art nämlich eine sehr sichere Methode genau dies zu tun – sich schützen.

Dieser Blogeintrag soll ganz unaufgeregt und auf einer sachlichen Ebene erklären, welche Arten der E-Mail Verschlüsselung es gibt, was Ihre Vor-und Nachteile sind. Ein weiterer Blogeintrag wird sich dann intensiv mit dem Thema der E-Mail Signierung beschäftigen.

Einordnung E-Mail Verschlüsselung

E-Mail Verschlüsselung ist eine Technologie, um die Vertraulichkeit einer Nachricht zu erhalten (englisch: confidentiality – das C in CIA). Kann nur der vorbestimmte Empfängerkreis einer Nachricht deren Inhalt lesen/extrahieren, so bleibt die Vertraulichkeit gewährleistet.

Diffefent Standards for certifying Sender identity (SPF, DKIM, DMARC, S/MIME, OpenPGG) and Encryption (SMTP over TLS / S/MIME)

Dieses Ziel versucht man nun im Kontext der E-Mail Security auf 2 Arten zu erreichen.

  • Auf der Ebene des Transports (Transport Security) mit der Technologie SMTP over TLS und 3 verschiedenen Subvarianten:
    • opportunistic TLS
    • forced TLS
    • forced TLS with certificate check
  • Auf der Ebene des Mailobjekts selbst (Mail Object Security) mit den 2 Standards:
    • S/MIME
    • OpenPGP

Transport Security versus Mail Object Security bei E-Mail Verschlüsselung

Achtung: „Encryption on Transport Layer“ / Verschlüsselung auf Transportebene hat bis auf TL(S) im Namen erst einmal weitgehend nichts mit der klassischen TLS Verschlüsselung im Webbereich zu tun. Beide haben völlig unterschiedliche Eigenheiten. Häufige Aussagen wie z.B. „Verschlüsselung ist eh überall das gleiche“ sind somit überwiegend falsch.

Denn: Mail-Verschlüsselung auf der Ebene des Transport Layers verschlüsselt in einem Tunnel den Datenstrom vom sendenden MTA (Mail Transfer Agent – also sendendes Mail Transfer System = Mail Server/Gateway) zum nächsten (und nur zu dem!) MTA. Nicht zum Empfänger und potentiell auch nicht an allen anderen MTAs – die sich auf dem Weg vom ersten empfangenden MTA bis zum Empfänger befinden.

„Man in the Middle anyone“?

Im Webbereich (HTTPS) passiert die Verschlüsselung vom Client immer „direkt“ zum Server. Dies hat mit den eingesetzten Zertifikaten und deren Prüfung zu tun.

Encryption on Transport Layer - SMTP over TLS, opportunistic TLS, forced TLS, forced TLS with certificate check
Encryption on Transport Layer

„Mail Object Encryption“ (Verschlüsselung auf der Mailobjekt Ebene selbst) hingegen verschlüsselt direkt das Mail Objekt auf seiner Reise zum Empfänger – so lange bis es vom private Key des Empfängers entschlüsselt wird.

Encryption on Mail Object Layer - S/MIME - OpenPGP / PGP
Encryption on Mail Object Layer

Details finden Sie in nachfolgenden Artikeln:

Encryption on Mailtransportlayer im Detail – SMTP over TLS Types

Mail Object Encryption – S/MIME und OpenPGP/PGP


Vgl. Q &A Secure E-Mail Communication on https://mailprotection.redbull.com : „Resason for using Secure E-Mail communication“

sowie

Q &A Secure E-Mail Communication on https://mailprotection.redbull.com/standards : „Which Standards we offer and why“

Veröffentlicht unter Allgemein | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar

Private Key Protection in Windows – Sichern der privaten Schlüssel

Private Schlüssel werden, sofern sie nicht auf einer Smartcard abgelegt wurden, verschlüsselt im Application Data Ordner des Benutzerprofil eines Users  bzw. dem All Users Profil des Systems abgelegt (%APPDATA%\Microsoft\Crypto\).

Geschützt werden die Schlüssel durch die Data Protection API im Windows Kernel.

Securing Private Key in WindowsEin privater Schlüssel wird zuerst durch einen symmetrischen Session Key verschlüsselt, der sich wiederum aus einem Encryption Key und dem Master Key ableitet. Der Encryption Key bildet sich aus nicht geheimen Daten des Benutzerprofils und des Systems, die eigentliche Sicherheit entsteht durch den Master Key.

Der Master Key als wichtigster Schlüssel befindet sich unter:

%USERPROFILE%\AppData\Roaming\Microsoft\Protect\{SIDdesUsers}

Der Master Key wiederum wird durch den Master Key Encryption Key  geschützt, der sich aus dem Benutzerpasswort ableitet.  Verwendete Algorithmen sind u.a. 3DES im CBC Mode sowie SHA-1 etc.

Beschädigte Mater Keys können über folgende Verfahren wiederhergestellt werden:

  • Rechner in einer Domäne legen eine mit öffentlichem Schlüssel des Domänencontrollers verschlüsselte Kopie des private Keys im Active Directory ab
  • Credential History erlaubt Zugriff auf alte Master Keys die mit alten User PW verschlüsselt wurden – somit kann auch nach der Änderung des Windows Passworts auf die alten Private Keys zurückgegriffen werden
  • Verwenden einer Windows Password Recovery Disk, die ein neues Benutzerpasswort generiert und den Master Key wiederherstellt: DPAPI generates a 2048-bit RSA public/private key pair, which is the recovery key. The current password is then encrypted with the public key and stored in the user’s profile, while the private key is stored to the PRD, which can actually be any removable media, and then removed from memory. The private key is only stored on the PRD, and nowhere else, so it is important for a user to keep the PRD in a safe place“

Enable Strong Private Key Protection

Da alle Anwendungen die im Benutzerkontext laufen unkontrolliert auf die privaten Schlüssel des Benutzers zugreifen könnten, kann ein Zertifikat so ausgestellt werden, dass bei jedem Schlüsseleinsatz des privaten Schlüssels eine zusätzliche Benutzerinteraktion oder eine Passworteingabe erforderlich ist. Dies erhöht den Schutzlevel des private Keys und verhindert ungewollte Aktionen z.B. das Anstoßen von CodeSigning durch Malware. Für noch höhere Sicherheit empfiehlt sich aber eine hardwarebasierte Ablage der Schlüssel durch bspw. Token, Smartcards oder HSMs.

Setzen Strong Private Key Protection:

  • Im Certificate Template
  • Im  Zertifikatsimport Wizard
enableStrongProtection im Import Wizard

Auswahl von „Medium“ (nur Zustimmung des Nutzers) oder „High“ (zusätzlich PW Eingabe) möglich

Auswirkung Stong Private Key Protection

Strong Private Key Protection - Medium

Vgl. De Clercq, Jan.: „Windows Server 2003 Security Infrastructures“, K. 13.4.4 – 13.4.5.

Vgl. NAI Labs, Network Associates, Inc.: „Windows Data Protection“ http://msdn.microsoft.com/en-us/library/ms995355.aspx (abgerufen am 26. November 2014).

Vgl. Radutskiy, Alex [MSFT] : „What is a strong key protection in Windows?“ http://blogs.technet.com/b/pki/archive/2009/06/17/what-is-a-strong-key-protection-in-windows.aspx (abgerufen am 26. November 2014).

Veröffentlicht unter PKI: Komponenten und Prozesse, PKI: Kryptografische Grundlagen | 3 Kommentare

Sicherheit im E-Mail Verkehr

Die klassische E-Mail ist seit jeher so sicher wie das Versenden einer Postkarte.
Das zum Versand verwendete SMTP-Protokoll arbeitet im Klartext – d.h. jedes Paket kann auf der Strecke vom Sender bis zum Empfänger mühelos abgefangen, gelesen, ggf. verändert und wieder weitergeleitet werden.
Eine Identifizierung von Absender bzw.  Empfänger und eine Prüfung der Nachrichtenintegrität findet dabei nicht statt.
Auch Mail Spoofing – also das Fälschen des Absendernamens ist daher meist einfach möglich, was zu großen unternehmensinternen Problemen führen kann, wenn z.B. illegitim Angebote, Bestellungen, Arbeitsanweisungen etc. unter einer fremden E-Mail Adresse vorgenommen werden.

Verbindlichkeit und Integrität im E-Mail Verkehr kann aber über das Instrument der Digitalen Signatur erlangt werden (siehe Digitale Signatur ), wogegen die Vertraulichkeit durch Verschlüsselung erreicht wird.
Beide Technologien lassen sich bei E-Mail über die Standards S/MIME und PGP einsetzen, wobei sich das auf PKI-Strukturen und auf X.509 Zertifikaten basierende S/MIME, auch aufgrund der nativen Implementierung in Microsoft Komponenten, weitgehend durchgesetzt hat.

Für den unternehmensinternen S/MIME Einsatz gibt es zwei grundlegende Ansätze:

End-to-End Signatur/Verschlüsselung am E-Mail Client: Bei diesem Ansatz muss jeder Mitarbeiter eigenverantwortlich die Signatur und Verschlüsselung von E-Mails am E-Mail Client ( Outlook, Thunderbird etc. ) durchführen. Während die Signatur von E-Mails – vorausgesetzt man besitzt ein entsprechendes X.509 Zertifikat für S/MIME Signatur –  noch relativ einfach zu handhaben ist, ist für den Einsatz der S/MIME Verschlüsselung eine Anwenderschulung unumgänglich.

  • Das Problem bei der Verschlüsselung liegt im Schlüsselmanagement, das auch hier beim Endanwender selbst liegt. Eine verschlüsselte Mail kann immer erst gesendet werden, wenn das entsprechende Zertifikat des Empfängers (mit dessen öffentlichen Schlüssel) sich bereits in den eigenen Kontakten befindet.
    D.h. der E-Mail Empfänger muss dem Sender vorher einmalig sein Zertifikat übermittelt haben und dieser muss es selbständig in seine Kontakte importieren.

Weitere Nachteile:

  • Der Empfänger muss für jedes Gerät (z.B. Smartphone), mit dem er verschlüsselte E-Mails abruft, den privaten Schlüssel vorhalten.
  • Stellvertreterregelungen sind schwierig, da der Stellvertreter mit den personalisierten Zertifikaten der Originalentität arbeiten müsste.
  • Verschlüsselte E-Mails können nicht von Antiviren-Software geprüft werden.

Vorteile:

  • Eignet sich, wenn nur wenige Mitarbeiter Signieren/Verschlüsseln sollen.
  • Einzige End-to-End Lösung – nur auf diesem Weg wird die Signatur/Verschlüsselung unberührt bis zum Empfänger gesendet.
  • Einfache Implementierung für firmeninternen E-Mail Verkehr bei Einsatz einer Exchange-Lösung, da die Zertifikate der Empfänger einfach über die Globale Adressliste ausgelesen werden können.

 S/MIME mittels eines Unternehmensgateways:

Spezielle Signaturgateways, entweder hardwarebasiert oder als virtuelle Appliance, bieten ein zentralisiertes Management für Digitale Signatur und Verschlüsselung mit S/MIME. Das Signaturgateway wird dem eigentlichen E-Mail Gateway vorangestellt und kann je nach Hersteller und Konfiguration auf eine der folgenden Arten arbeiten:

  •  Ein spezielles E-Mail Gatewayzertifikat wird für eine gesamte E-Mail Domäne z.B. concept.com verwendet, um ausgehenden Verkehr zu signieren. TC Trustcenter bietet bspw. solche Zertifikate an.
  • Es wird ein zentral gesteuertes 1:1 Mapping von Zertifikaten zu E-Mail Adressen durch einen Administrator angelegt.
  • Die MailSealer Lösung von Reddoxx liefert bspw.  eine eigene CA am Gateway selbst, die in die unternehmensinterne PKI eingeordnet werden kann. Die CA erstellt dann bei der ersten ausgehenden E-Mail eines Benutzers automatisch ein S/MIME Zertifikat und ordnet es dem Benutzer zu.

Vorteile (je nach Leistungsumfang):

  • Zentrales S/MIME Management durch Gateway Administratoren möglich
  • Verschlüsselte E-Mails werden zentral am Gateway entschlüsselt und können anschließend von Antivirensoftware inspiziert werden.
  • Automatisches Lernen eingehender öffentlicher Zertifikate möglich.
  • Verschlüsselung/Signierung nach bestimmten Regeln z.B. Text im Betreff der E-Mail bzw. Anwenden der Regeln auf bestimmte Gruppen.
  • Benachrichtigung des Nutzers bei erfolgreicher Signaturprüfung eingehender E-Mails z.B. durch einen angehängten Prüfbericht
  • Automatisches Abweisen von signierten oder verschlüsselten Mails ein bzw. ausgehend.

Nachteile:

  • keine echte End-to-End Signatur/Verschlüsselung, da Verifizierbarkeit nur bis zum Unternehmensgateway geht.
  • Nachrichten, die mit Gatewayzertifikaten signiert wurden, werden von vielen empfangenden E-Mail Lösungen abgelehnt, da der Name im Zertifikat nicht mit der Absenderadresse übereinstimmt.

SMIME Gateway

Vgl. Carius, Frank: „Signieren und Verschlüsseln auf dem Gateway“. http://www.msxfaq.de/signcrypt/gateway1limitierungen.htm (abgerufen am 10. September 2011).

Vgl. Carius, Frank: „Signieren und Verschlüsseln auf dem Gateway – Vorteile“. http://www.msxfaq.de/signcrypt/gateway2vorteile.htm (abgerufen am 10. September 2011).

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Signieren von Anwendungscode

Microsoft-Anwendungen, wie z.B. Internet Explorer, Windows Installationsroutinen etc.  verfügen über Sicherheitsfunktionen zur Überprüfung, ob eine digitale Signatur  für eine auszuführende Anwendung vorhanden ist und geben eine Empfehlung für das weitere Vorgehen des Benutzers aus.

Code Signierung mit X.509 Zertifikaten ist für Unternehmen sinnvoll, die selbst Softwareprodukte anbieten und nicht wollen, dass bei den Kunden Warnungen angezeigt werden bzw. um das Vertrauen in das Softwareprodukt zu erhöhen. Der Kunde kann  sicher sein dass die Software unmanipuliert und unverfälscht zur Ausführung gebracht wird.

Für nicht signierte Anwendungen bzw. von einer unbekannten CA eingesetzte Zertifikate wird dabei je nach Sicherheitseinstellungen ein roter Warnhinweis angezeigt oder die Inhalte können schlicht nicht ausgeführt werden.

Ist die Anwendung signiert und dem Zertifikat wird vertraut – so wird lediglich eine Informationsmeldung angezeigt.

CodeSigning

Anm.: Wenn der Herausgeber vom Anwender zusätzlich explizit zu den „Vertrauenswürdigen Herausgebern“ im Zertifikatmanagement  hinzugefügt wird (manuell oder mit „Immer Software von Herausgeber ausführen“ s. Grafik) so kommt zukünftig auch keine Informationsmeldung mehr, wenn Anwendungen dieses Herausgebers geöffnet werden.

Für das Signieren von Code muss ein Zertifikat mit der EKU „Code Signing“ vorhanden sein. Um Windows Code bspw. .exe Dateien zu signieren, kann das Programm Signtool.exe, das im Windows SDK enthalten ist, verwendet werden. Für eine sichere Code Signing Infrastruktur empfiehlt sich die Verwendung von HSMs oder zumindest Token/Smartphones.

Code Signing gibt es auch für Java Plattformen wie J2SE und J2ME.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Digitale Signatur in Dokumenten

Nur durch den Einsatz der Digitalen Signatur kann technisch festgehalten werden, dass ein bestimmtes  Dokument zu einer bestimmten Entität gehört und nicht manipuliert wurde.

Je nach Signaturgesetzgebung im entsprechenden Einsatzland gilt die Signatur auch als Ersatz der eigenhändigen Unterschrift auf einem Dokument (in DE nur bei qualifizierter Signatur siehe Elektronische Signaturen in Unternehmen). Für den Einsatz der Digitalen Signatur in Dokumenten ist ein X.509 Zertifikat nötig, für das die EKU „Document Signing“ freigegeben ist (siehe Zertifikatsattribute)

 Digitale Signatur in Office-Dokumenten

Office Dokumente können entweder nicht sichtbar oder sichtbar mit einer Signaturzeile digital signiert werden. Sobald ein Dokument signiert wurde, ist der Inhalt schreibgeschützt und kann nicht mehr abgeändert werden, ohne die Signatur zu zerstören.

  • Bei der nicht sichtbaren Signatur  wird das Signatursymbol schlicht in der Statuszeile des Dokuments angegeben

NichtSichtbareDigitaleSignatur

  • Bei der sichtbaren Signatur können ein oder mehrere Signaturzeilen in das Dokument eingefügt werden. Die Signaturzeile wird dann mit dem Zertifikat signiert, weiterhin kann eine Grafik mit der eigenen Unterschrift eingefügt bzw. direkt auf einem Tablet unterschrieben werden. Man kann das Dokument auch mit dem Auftrag zur Signaturerstellung manuell an den Empfänger weiterleiten. Mithilfe von Microsoft Sharepoint sind auch automatisierte Workflows zur Signaturerstellung möglich.

Sichtbare Digitale Signatur in Microsoft Office

Digitale Signatur in PDF Dokumenten

Auch PDF Dokumente können digital signiert werden. Mit Adobe Acrobat Reader ist die Signatur eines Dokuments aber nur möglich, wenn das PDF mit Signaturzeile vorher mit einer Adobe Acrobat Professional Version erstellt wurde. Als PDF Alternative bietet sich unter anderem der  günstigere Nitro PDF Professional an, der PDF Dokumente jeglicher Art signieren kann.

PDFSignatur_mit_Nitro_Professional

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Elektronische Signaturen in Unternehmen

Das deutsche Signaturgesetz unterscheidet verschiedene Signaturtypen, die in einem Unternehmen vorkommen können. Diese Signaturtypen stützen sich dabei (exklusive der einfachen Elektronischen Signatur) auf das kryptografische Verfahren der Digitalen Signatur (siehe Kapitel Digitale Signatur),  differieren dabei aber in  organisatorischen und rechtlichen Kriterien. Eine technische Umsetzung kann im Rahmen der Digitalen Signatur bei E-Mail bzw. durch den Signaturprozess auf Dokumente stattfinden (siehe 3.3.1 und 3.3.2).

Definition:

vgl. § 2 SigG (Signaturgesetz)

Eine elektronische Signatur im Sinne des Signaturgesetzes ist ein Siegel zu elektronischen Daten, das den Absender und die Unverfälschtheit der Daten erkennen lässt. Elektronisch übermittelte Daten können somit auf dem Weg vom Absender zum Empfänger nicht unbemerkt verändert werden.

Rechtliche Rahmenbedingungen:

  • EU-Richtlinie 1999/93/EG über gemeinschaftliche Rahmenbedingungen für elektronische Signatur
  • Signaturgesetz (SigG) und Signaturverordnung (SigV)
  • Bürgerliches Gesetzbuch (BGB): Vorschriften zur Schriftform (insbes.§126)
  • Zivilprozessordnung (ZPO): Beweiskraft elektronischer Dokumente (u.a. 371a/ 445)

Ausprägungen nach deutschem Signaturgesetz

Folgende Signaturtypen gelten nicht als Ersatz der Schriftform:

  • Elektronische Signatur(§ 2 Nr. 1 SigG): Erfüllt  keine besonderen Sicherheitsanforderungen (es reicht z.B. bei E-Mail ein angefügter Name des Urhebers), kann folglich  nicht zweifelsfrei einer Person zugeordnet werden und hat daher wenig Beweiswert. Einsatz nur für formfreie Verträge geeignet.
  • Fortgeschrittene elektronische Signatur (§ 2 Nr. 2 SigG): Ermöglicht eindeutige Zuordnung der Signatur zum Urheber bzw. dessen Identifizierung. Eine nachträgliche Veränderung der signierten Daten ist nicht möglich – dies entspricht der Verwendung eines ausgestellten Signaturzertifikats. Durch erhöhte Anforderungen, auch erhöhte Beweiskraft der Signatur.

Als Ersatz für die Schriftform können folgende Signaturtypen dienen, falls die elektronische Form zulässig ist (entspricht persönlicher Unterschrift):

  • Qualifizierte elektronische Signatur (§ 2 Nr. 3 SigG): Entspricht der Fortgeschrittenen Signatur, die zusätzlich auf einem qualifizierten Zertifikat beruht und mit einer sicheren Signaturerstellungseinheit[2] erzeugt wurde. Um ein qualifiziertes Zertifikat auszustellen, muss der Zertifikatsanbieter die §4 bis §14 des Signaturgesetzes einhalten und die Tätigkeit, sowie die zur Signatur nach  SigG und SigV verwendbaren Komponenten (spezielle Software, Treiber, Klasse 3 Kartenleser mit Tastatur), bei der Bundesnetzagentur anzeigen.

Vorgeschrieben ist die qualifizierte elektronische Signatur:

  • Branchenübergreifend: Elektronische Rechnungen (außer EDI), die zum Vorsteuerabzug berechtigen (am 23.09.2011 rückwirkend zum 01.07.2011 wieder abgeschafft)
  • Justiz: Elektronisches Gerichts und Verwaltungspostfach (EGVP)
  • Verwaltung: Austausch Behörden und Bürger (Projekt ELENA für elektronischen Einkommensnachweis, Arbeitnehmerdaten und Sozialleistungen – Projekt wurde am 18.07.2011 gestoppt)
  • Energiewirtschaft: Emissionshandel (CO2-Zertifikate)
  • Versicherungswesen: Einsatz anstelle von  Papierarchiven für Belege der Sozialversicherung
  • Abfallwirtschaft: Belege des Transports von Sondermüll (elektronischer Abfallnachweis)
  • Gesundheit: zukünftig – Elektronisches Rezept, Elektronische Patientenakte
  • Qualifizierte elektronische Signatur mit Anbieter Akkreditierung (§15): entspricht der Qualifizierten elektronischen Signatur, zusätzlich muss der Anbieter des Zertifikats nach §15 SigG akkreditiert sein. Die Bundesnetzagentur bescheinigt dem Anbieter erhöhte Sicherheit und ermöglicht dem Anbieter den Erhalt qualifizierter Zertifikate der Root CA der Bundesnetzagentur-PKI.

Die qualifizierte Signatur hat sich bis dato weitgehend nicht durchgesetzt, in der Regel reicht die fortgeschrittene Signatur, die auch mit einer eigenen PKI erzeugt werden kann, für die meisten Anwendungen vollkommen aus.


[1] Vgl. Bartonitz, Martin; Lenz, Joerg Matthias.: „Elektronische Signaturen ein Überblick aus der Praxis “ Vortrag zum Informationstag Elektronische Signatur am 23.9.2011 in Berlin.  http://www.slideshare.net/SOFTPROGroup/signaturtag-2011-elektronische-signatur-berblick-aus-der-praxis (abgerufen am 13. November 2011).

[2] Anm.: Smartcard / neuer Personalausweis / neue Gesundheitskarte / Heilberufsausweis / Geldkarte.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar