Permalink

Howto: E-Mail-Verschlüsselung und -Signierung mit S/MIME und OpenPGP (bei Apple Mail) einrichten

Wenn es um die Verschlüsselung oder Signierung von E-Mails geht, und da darf sich jeder mal selbst an die Nase packen, ist der Durchschnittsinternetnutzer doch eher zurückhaltend. Dem einen ist es zu kompliziert, dem anderen zu aufwendig und wieder andere sehen den Inhalt ihrer E-Mails nicht als schützenswert an.

Nun, die ersten beiden Argumente lassen sich relativ schnell entkräften. Das letzte lasse ich einfach mal unkommentiert im Raum stehen… ;)

Bildschirmfoto 2014-11-11 um 11.34.38

Generell muss man sich beim Verschlüsseln und Signieren von E-Mails zwischen zwei Protokollen entscheiden: S/MIME und OpenPGP, die beide nicht miteinander kompatibel sind und auch ‘nur’ den Inhalt der E-Mail verschlüsseln. Die Metadaten, wie Absender, Empfänger und Betreff, bleiben unverschlüsselt.

Ich möchte jetzt gar nicht groß ins technische Detail gehen oder den Glaubenskrieg fortführen, der zwischen den Nutzern dieser Protokolle herrscht. Ich möchte vielmehr die praktische Seite von S/MIME und OpenPGP beleuchten und kurz zeigen wie einfach man sie unter OS X oder iOS einrichten kann.

S/MIME vs OpenPGP

Nüchtern betrachtet gibt es vom Standpunkt der Sicherheit keinen Favoriten. Beide Protokolle entsprechen aktuellen Sicherheitsanforderungen; unterscheiden sich aber in grundlegenden Dingen, die in der Praxis durchaus von Bedeutung sind.

S/MIME benötigt beispielsweise keine große Einrichtung und lässt sich out-of-the-box sowohl am Mac, als auch unter iOS nutzen. OpenPGP erfordert dahingegen unter OS X etwas Handarbeit und hat die Einschränkung, dass es von Apples mobiler Mail.app unter iOS leider nicht unterstützt wird.

Der wichtigste Unterschied zwischen den beiden Protokollen liegt aber im Verfahren zur Authentifizierung. Während S/MIME über ein hierarchisches System mit einen Zertifikat die Echtheit garantiert, nutzt OpenPGP mit dem so genannten Web of Trust einen anarchischen Ansatz.

S/MIME-Zertifikat

Für die Verschlüsselung von E-Mails mit S/MIME sind die schon angesprochenen Zertifikate der wichtigste Bestandteil. Diese gibt es in verschiedenen Sicherheitsstufen, die alle unterschiedliche Ausprägungen bei der Validierung von Daten haben und unterschiedlich kosten. Für den Privat-Anwender sind diese Sicherheitsstufen in der Regel aber uninteressant, so dass man auch mit kostenlosen Zertifikaten, die meistens ein Jahr lang gültig sind, seine E-Mails verschlüsseln und signieren kann.

Fragt man DuckDuckGo, Google oder Bing nach kostenlosen E-Mail Zertifikaten, werden einem eine Reihe Anbieter wie Comodo oder StartSSL angezeigt.

 Bildschirmfoto 2014-11-11 um 19.50.05-minishadow

Wichtig, neben dem Namen und der E-Mail Adresse, für die das Zertifikat beantragt werden soll, ist die Schlüssellänge (bei Comodo, wie im Screenshot zu sehen, 2048 Bit) und das Revoke-Passwort, mit dem das Zertifikat im Fall der Fälle als ungültig erklärt werden kann.

Ist dieses Online-Formular ausgefüllt, erhält man nach dem Absenden eine Bestätigungsemail, mit der man das Zertifikat herunterladen kann.

Bildschirmfoto 2014-11-11 um 19.55.29-minishadow

Je nach Konfiguration landet das Zertifikat, das in meinem Fall den Dateinamen CollectCCC.p7s hat, im Downloadordner des Macs.

Startet man diese Datei per Doppelklick öffnet sich die OS X Schlüsselbundverwaltung, in die man das Zertifikat nur hinzufügen muss.

Bildschirmfoto 2014-11-11 um 21.02.29-minishadow

Anschließend startet man die Mail.app neu, die das Zertifikat automatisch erkennt und ab sofort E-Mails verschlüsselt und signiert versenden kann.

Dazu gibt es bei Mail beim Schreiben einer neuen E-Mail zwei neue Schaltflächen. Zum einen ein Schloss, welches die Verschlüsselung der E-Mail aktiviert. Zum anderen einen Haken, der die E-Mail signiert. Der Haken ist per Default immer aktiviert. Es wird also jede E-Mail signiert versendet. Das Schloss kann dahingegen nur angeklickt werden, wenn der Adressat ebenfalls ein gültiges S/MIME Zertifikat besitzt.

Bildschirmfoto 2014-11-11 um 20.06.05-minishadowBildschirmfoto 2014-11-12 um 12.48.52-minishadow copy

Oben rechts sieht man zudem, sofern man OpenPGP schon nutzt, eine blaue S/MIME Schaltfläche. Setzt man einzig und alleine auf S/MIME, ist diese Schaltfläche nicht zu sehen.

Besonderheit iOS

Das iOS mit dem vom Comodo zugesendeten Zertifikat im *.p7s Format nichts anfangen kann, muss man es zunächst in ein für iOS lesbares Format umwandeln.

Dazu nutzt man die OS X Schlüsselbundverwaltung, in der man per Rechtsklick das entsprechende Zertifikat, mit einem Passwort geschützt, ins *.p12 Format konvertieren kann.

Bildschirmfoto 2014-11-11 um 21.40.39

Nachdem man das Zertifikat per E-Mail o.ä. aufs iPhone, iPad oder den iPod touch übertragen und installiert hat, muss man S/MIME in den Einstellungen > Mail, Kontakte, Kalender > E-Mail Account > Account > Erweitert aktivieren und findet in der mobilen Mail.app nun ähnliche Schaltflächen wie schon unter OS X.

IMG_2400 IMG_2401

OpenPGP-Schlüsselpaar

Wie schon erwähnt, wird dieses Protokoll im Gegensatz zu S/MIME nicht von iOS unterstützt. Daher ist die folgende Anleitung auch ausschließlich für OS X ausgelegt.

Zunächst muss man sich die GPG Suite, deren Source Code auch bei Github zu finden ist, herunterladen und installieren. Für OS X Yosemite wurde erst kürzlich eine kostenlose Beta veröffentlicht. Das Ganze wird aber, wie die Entwickler schon Mitte Oktober 2014 angekündigt haben, in der finalen Version nicht kostenlos bleiben. Wie hoch die small fee für das Mail Plugin GPGMail, welches Bestandteil der GPG Suite ist, ausfallen wird, bleibt abzuwarten aber alleine vom Sicherheitsgedanken sollte man darüber nicht groß nachdenken.

Bildschirmfoto 2014-11-11 um 21.45.01-minishadow Bildschirmfoto 2014-11-11 um 21.45.33-minishadow

Nach der Installation findet man das Plugin GPGMail, welches schlussendlich für das Verschlüsseln und Signieren von E-Mails verantwortlich ist, in den Mail Einstellungen.

Bildschirmfoto 2014-11-11 um 21.47.00-minishadow

Da (Open)PGP keine Zertifikate braucht, sondern die benötigten Schlüssel dezentral über einen öffentlichen Schlüsselserver verwaltet, gestaltet sich die weitere Einrichtung wesentlich einfacher als bei S/MIME.

Mit der Installation der GPG Suite hat sich neben dem Mail Plugin u.a. auch eine App namens GPG Keychain ins OS X Programme-Verzeichnis installiert. Neben dem Erstellen neuer bzw. Widerrufen vorhandener Schlüsselpaare für die eigenen E-Mail Adressen, werden hier auch die öffentlichen Schlüssel von Adressaten verwaltet.

Bildschirmfoto 2014-11-11 um 21.49.48-minishadow

Wichtig beim Erstellen ist der Haken bei Upload public key, der den eigenen öffentlichen Schlüssel auf den Schlüsselserver hoch lädt. Andernfalls ist es Adressaten, die ebenfalls (Open)PGP nutzen, nicht möglich verschlüsselte E-Mails zu schreiben, die mit dem privaten Schlüssel, der auf dem eigenen Rechner liegt, entschlüsselt werden.

Bildschirmfoto 2014-11-11 um 21.52.23-minishadow

Das Fenster zum Schreiben neuer Mails hat in der Mail.app nun auch wieder die beiden zusätzlichen Schaltflächen zum Verschlüsseln und Signieren von E-Mails. Bei installiertem S/MIME gibt es darüber hinaus oben rechts eine grüne OpenPGP Schaltfläche, die zwischen den Protokollen umschalten kann.

FAZIT

Ich hoffe, dass einigermaßen klar wird, dass das Verschlüsseln und Signieren von E-Mails kein Hexenwerk ist, für das man kryptische Informatik studiert haben muss.

Es empfiehlt sich außerdem S/MIME und OpenPGP parallel installiert zu haben. Zum einen sind, wie schon erwähnt, beide Protokolle zueinander nicht kompatibel. Zum anderen hat sich bisher auch kein Favorit herauskristallisiert, so dass momentan jeder das nutzt, was er für richtig hält.

Die Anleitung kann im Übrigen natürlich auch auf andere OS X Mail-Clients wie MailMate (siehe Screenshot) oder auch Airmail 2 angewendet werden.

Bildschirmfoto 2014-11-12 um 15.22.49-minishadow 

Für einen tieferen technischen Hintergrund um S/MIME und OpenPGP empfehle ich einen Artikel von Christian Kirsch.

Permalink

Touch ID und die trügerische Sicherheit

Apples Touch ID ist zum Anmelden bei Apps ist eine sehr komfortable Geschichte. Es vergeht seit der Veröffentlichung von iOS 8, mit dem Touch ID für 3rd Party Apps verfügbar wurde, kaum eine Woche, in der nicht irgendein anderer Entwickler mit der Integration dieses Features in seiner App hausieren geht.

Doch wie sieht es mit der Sicherheit von Touch ID, fernab der hinlänglich bekannten Sicherheitsprobleme, die bei der Verwendung eines Fingerabdrucks entstehen, aus?!

2014-11-03_12h42_57

Andreas Kurtz beschäftigt sich in seinem Blogeintrag ausgiebig mit diesem Thema und zeigt am Beispiel der Dropbox App welch trügerische Sicherheit Apple mit dem Local Authentication Framework, einer API, die Apple zur Verwendung von Touch ID den Entwicklern zur Verfügung stellt, dem Nutzer vorgaukelt.

Since I first heard about this new framework, I have questioned its usefulness. Ultimately, Local Authentication becomes only important when an unlocked device falls into the wrong hands. Than Local Authentication is designed to ensure that, when an app is launched, an additional login screen is displayed to prevent access to the app’s contents. However, in this very moment it is still possible, e.g., to directly access all app data via the USB interface (for example, by creating a backup). After all, the device is already unlocked (otherwise you wouldn’t need Local Authentication).

Ähnliche Sicherheitsbedenken hat auch die Subsembly GmbH aus München, die erst letzte Woche Touch ID in ihre großartige Online-Banking App Banking 4i integriert hatte. Wie auf der Facebook-Seite des Entwicklers zu lesen, ist man mit Apples Umsetzung des Local Authentication Frameworks unzufrieden, hat aber dennoch über einen sogenannten Zweitschlüssel einen Weg gefunden, der das eigentliche Passwort zum Entsperren der App nicht lokal auf dem iPhone oder iPad speichert.

Die übliche, von Apple empfohlene Vorgehensweise für die Implementierung von Touch ID sieht vor, dass das mit Touch ID zu schützende Passwort einfach im Schlüsselbund auf dem Gerät gespeichert wird. Unser Grundprinzip, das Passwort niemals irgendwo in irgendeiner Weise zu speichern wäre damit gebrochen. Nun kann man argumentieren, dass der Schlüsselbund in iOS sehr sicher ist, und die Speicherung des Passworts im Schlüsselbund deshalb kein Risiko darstellt. Ich glaube das nicht. So kann zum Beispiel ein “trojanisches Pferd” auf einem iPhone mit Jail-Break den Schlüsselbund einfach auslesen.

-> iOS 8 Touch ID Authentication API
-> Touch ID in Banking 4i

Permalink

iSafe · Kostenloser Passwort-Manager für das iPhone und OS X

Wenn man auf dem Mac oder unter iOS einen schicken Passwort-Manager für alle möglichen Daten haben möchte, greift man in der Regel zu 1Password.

Wer es günstiger haben möchte nimmt LastPass oder iSafe, welches heute für OS X neu erschienen ist und es für das iPhone schon seit November 2008 gibt.

iSafe legt alle eingegebenen Daten mit AES 256 bit Verschlüsselung ab und erlaubt darüber hinaus auch ein iCloud Backup aller Daten. Dazu lassen sich auch Passwörter generieren.

Der Funktionsumfang von iSafe ist bei weitem aber nicht mit 1Password vergleichbar; eine Browser Extension fehlt momentan leider auch aber vielleicht lohnt sich dennoch ein Blick für den einen oder anderen Leser.

FEATURES:

  • AES 256 bit Verschlüsselung
  • iCloud Backup (verschlüsselt)
  • Speichere Einträge
  • Speichere Dateien
  • Exportiere / Importiere Backup Datei per Email und zu und von anderen unterstützenden Apps (z.B. Evernote, Dropbox, FileDrop, etc.)
  • Kategorien für Ihre Einträge
  • Sichere Passwörter generieren
  • Synchronisierung mit iSafe für iPhone und iPod Touch
  • Intuitives Bedienung und Interface

Zur Installation auf dem Mac wird OS X 10.8 Mountain Lion bzw. unter iOS ein iPhone mit iOS 6 minimal vorausgesetzt.

Artikel wurde nicht gefunden
Artikel wurde nicht gefunden

Permalink

mPass Pro – Secure Password Manager & Private Data Vault to Lock Your Secrets Safe (iOS Universal)

Ein Passwort-Manager mit Passwort-Generator, integriertem Browser, Kategorien, Cloud-Sync u.s.w. für iOS.

Die App erinnert im Grunde genommen sehr an 1Password for iOS

 

1Key Pro - Secure Password Manager (AppStore Link) 1Key Pro - Secure Password Manager
Hersteller: Appxy Information Technology Co., Ltd.
Freigabe: 4+
Preis: Gratis Download
Permalink

Apple veröffentlicht Safari Update mit Java Plug-In Steuerung

Vor ein paar Minuten hat Apple über die Softwareaktualisierung bzw. den Mac App Store seinen Webbrowser Safari auf Version 6.0.4 (OS X Lion, Mountain Lion) bzw. Version 5.1.9 (Mac OS X Snow Leopard) aktualisiert.

Darüber hinaus wurde ein Sicherheitsupdate für Java veröffentlicht.

HT5678 Manage 002 en

Diese neue Safari-Version ermöglicht es dem Benutzer, das Java Plug-In für jede Webseite individuell anzupassen. Mehr Informationen zum Thema finden sich in diesem Apple Knowledge Base Artikel.

Dennoch empfehle ich nach wie vor, sofern keine dringende Notwendigkeit besteht, Java vom Mac zu deinstallieren bzw. das Plug-In im Browser komplett zu deaktivieren.

Permalink

Detectify: Sicherheit deiner Webseite überprüfen

Bildschirmfoto 2013 01 10 um 07 20 54

Mit Detectify ist ein neuer Dienst aus der geschlossenen Beta jetzt für alle gestartet, mit dem man seine Webseite auf potentielle Sicherheitslücken abscannen kann. Bisher kostenlos. Dazu muss man sich einen Account anlegen, mit Mail-Verifikation. Die entsprechenden Domains muss man selbstverständlich auch verifizieren, entweder in dem man ein Stück Quellcode in die entsprechende Webseite packt oder eine Datei mit einem speziellen Namen anlegt. Danach kann man den Schauprozess anstoßen. Diesen kann man auch zeitlich einstellen, so dass dieser Job zum Beispiel in der Nacht läuft, wo wahrscheinlich eher weniger los ist. Der Scanprozess dauert recht lange und belastete meine getesteten Seite kaum.

Ich finde diesen Dienst sehr sinnvoll. Überprüft doch mal eure Webanwendungen und staunt, an was man so alles nicht gedacht hat.

https://detectify.com