Wann lohnt sich der Quantensprung? Post-Quanten-Kryptographie 

Asymmetrische Kryptographie ist heute weit verbreitet. Algorithmen, die heute noch als sicher gelten, können von den Quantencomputern von morgen gebrochen werden. 

Asymmetrische Kryptographie-Algorithmen basieren auf mathematischen Problemen (Primfaktorzerlegung oder Berechnung des diskreten Logarithmus), die als schwer zu lösen gelten. Bereits Anfang der 90er-Jahre hat Peter Shor den nach ihm benannten Algorithmus entwickelt, mit dem die genannten mathematischen Probleme auf einem Quantencomputer effizient berechnet werden können. Um das zu verdeutlichen: Um eine n-Bit Zahl zu faktorisieren, sind etwa 2n Qubits nötig. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fordert bei der Verwendung von RSA eine Schlüssellänge von mindestens 2000 Bit, für den Einsatzzeitraum über das Jahr 2022 hinaus sogar mindestens 3000 Bit. Das bedeutet, dass man bei der Verwendung von RSA mit einer Schlüssellänge von 2048 Bit schon theoretisch einen Quantencomputer mit über 4000 Qubit braucht. Praktisch sind wegen technischer Herausforderungen beim Bau von Quantencomputern wesentlich mehr Qubits notwendig. Der Physikforscher Michele Mosca schätzt, dass es mit einer Wahrscheinlichkeit von 50 % einen effizienten Quantencomputer bereits ab 2030 geben wird. 

Aber nicht nur asymmetrische Verschlüsselungs- und Signaturverfahren sind gefährdet, sondern auch symmetrische Verschlüsselungsverfahren und Hashfunktionen. Denn mit dem ebenfalls in den 90er-Jahren entwickelte Such-Algorithmus „Grover“ kann die Komplexität von Suchproblemen auf ungeordnete Daten auf die Wurzel der klassischen Komplexität reduziert werden. Infolgedessen müssen die Schlüssellängen angepasst werden. Es wird heute schon bei Neuentwicklungen davon abgeraten, AES-128 zu verwenden. Stattdessen sollte AES-256 genutzt werden, da davon ausgegangen wird, dass die Verwendung einer Schlüssellänge von 256 Bit langfristig einen hinreichenden Schutz gegen Quantencomputer-Angriffe bietet. 

Auch wenn der Durchbruch in der Quanteninformatik noch einige Jahre auf sich warten lässt, müssen sich Organisationen rechtzeitig auf den reibungslosen Übergang zu quantensicheren Systemen vorbereiten. Die Auswahl geeigneter Algorithmen sowie das Umstellen auf quantensichere Systeme kann eine besondere Herausforderung für viele Organisationen sein. In den letzten Jahren wurden enorme Fortschritte in der Quanteninformatik erzielt, so dass der erste Quantencomputer, der in der Lage ist, asymmetrische Kryptographie-Verfahren zu brechen, in wenigen Jahren zur Verfügung stehen könnte. Organisationen, die die gefährdeten Verfahren verwenden, um Daten mit langen Lebenszyklen zu schützen, müssen sich am besten jetzt schon um eine geeignete Alternative kümmern. Dazu zählen z. B. Gesundheitsdaten, die 10 Jahre sicher aufbewahrt werden müssen. Wenn 2030 der erste Quantencomputer zur Verfügung stehen sollte, könnten die Angreifer die verschlüsselten Daten bereits jetzt abfangen und dann entschlüsseln (hack now – decrypt later). Für Signaturen drängt die Zeit noch weniger, denn Angriffe auf frühere Kommunikation sind nicht möglich. 

Die US-Bundesbehörde National Institute of Standards and Technology (NIST), die bereits in der Vergangenheit für den Standardisierungsprozess bekannter kryptographischer Verfahren (wie z. B. AES) zuständig war, ist bereits seit 2016 auf der Suche nach neuen kryptographischen Standards, die gegen Quantencomputer resistent sind.  

Das NIST hat bereits im Juni 2022 erste Post-Quanten-Kryptographie-Verfahren zur öffentlichen Kommentierung standardisiert. Als Beispiel wurde CRYSTALS-Kyber ausgewählt, das auf dem Learning with Error (LWE) Problem basiert, welches auf Probleme in mathematischen Gittern zurückzuführen ist. Dieses Forschungsfeld ist jedoch noch recht jung. 

Ebenfalls im Juni 2022 hat die Runde 4 des Auswahlprozesses bei NIST begonnen. Einer der Finalisten ist das codebasierte Verfahren McEliece, welches auf fehlerkorrigierenden Codes basiert. Im Gegensatz zu den gitterbasierten Verfahren wurde das McEliece-Verfahren bereits im Jahr 1973 entwickelt und konnte somit bereits lange ausgiebig erforscht werden. Jedoch ist die Schlüsselerzeugung mit einem hohen Aufwand verbunden, da große Matrizen verarbeitet werden müssen. Dafür sind die Ver- und Entschlüsselungsalgorithmen extrem schnell und der Ciphertext ist bisher der kleinste aller NIST-Post-Quanten-Kryptographie-Kandidaten. 

Auch das BSI hat bereits erste Empfehlungen ausgesprochen. Dazu zählen z. B. die Entwicklung von kryptoagilen Lösungen und die Verwendung von Post-Quanten-Kryptographie Algorithmen in hybrider Form, also in Kombination mit klassischen kryptographischen Algorithmen, da viele Verfahren noch sehr jung und wenig erforscht sind. Dies führt zu den nächsten Herausforderungen. Kryptographische Protokolle müssen weiterentwickelt werden und die Public-Key-Infrastruktur muss in der Lage sein, Zertifikate zu verarbeiten, die sowohl die längeren klassischen Schlüssel als auch die quantensicheren Schlüssel enthalten. 

Unsere Experten der HiSolutions AG analysieren für Sie Ihre spezifischen Systeme, die kryptographische Verfahren verwenden, um die notwendigen Änderungen für die Migration zu Post-Quanten-Kryptographie-Lösungen unter Berücksichtigung spezifischer Anforderungen zu identifizieren. Dabei entwickeln wir für Sie geeignete Migrations- und Übergangslösungen. Ebenfalls möchten wir das Bewusstsein für die Problematik schärfen, die sich aus der Entwicklung der Quanteninformatik ergeben. 

Für mehr Informationen zum Quantencomputer und den Gefährdungen wie Lösungsmöglichkeiten, siehe auch dieses Dokument des BSI

Da waren‘s nur noch sieben: Nächster quantensicherer Algorithmus (SIKE) gebrochen

Ein erfolgreicher Angriff auf den Verschlüsselungsalgorithmus SIKE (Supersingular Isogeny Key Encapsulation) hat die Zahl der Verfahren, in die das US-amerikanische Normungsinstitut NIST noch Hoffnung in Bezug auf Sicherheit vor dem Quantencomputer setzt, auf sieben reduziert. Damit sind nun bereits über 90 % der Kandidaten ausgeschieden: Motiviert von den offenen Wettbewerben zur Wahl von AES (1997-2000) und SHA-3 (2007-2012) hatte es 2017 ganze 69 Einreichungen für Post Quantum Cryptography (PQC) gegeben, die in der Folge immer weiter zusammenschrumpften.

SIKE fiel dabei ganz sang- und klanglos einem älteren Modell eines Nicht-Quanten-Rechners zum Opfer – und einigen mathematischen Tricks aus dem jungen Forschungsfeld der Isogenie-Graphen. Dies macht noch einmal das Risiko deutlich, welches in der Verwendung neuer Mathematik für die Kryptographie liegt. Andererseits besteht inzwischen starker Handlungsdruck, quantensichere Verfahren zu standardisieren. Denn ein ausreichend großer Quantencomputer wird wahrscheinlich in den nächsten fünf bis zwanzig Jahren alles an Kryptographie knacken, was wir im Großmaßstab im Einsatz haben, vor allem sämtliche asymmetrische (und damit auch hybride) Verschlüsselung und alle digitalen Signaturen.

Mit dem Scheitern der Isogenie als Quelle für mögliche PQC sind wir nun vorerst auf Gedeih und Verderb den verbleibenden drei Forschungsrichtungen ausgeliefert: Gitter, fehlerkorrigierende Codes und Hashsignaturen. Gerade weil jedes der betrachteten Verfahren seine spezifischen Vor- und (zum Teil gravierenden) Nachteile mitbringt, können wir nur hoffen, dass von den noch im Rennen befindlichen Kandidaten möglichst viele auch die Angriffe der nächsten Jahre heil überstehen werden.

https://t3n.de/news/algorithmus-quantencomputern-1489626/

NIST Post Quantum Cryptography Wettbewerb geht in die vierte Runde

Beim US-amerikanischen NIST ist am 5. Juli 2022 die dritte Runde des öffentlichen Wettbewerbs zur Auswahl von Verfahren für quantencomputersichere kryptographische Verfahren, Post Quantum Cryptography (PQC), zu Ende gegangen.

Nachdem bereits in den vorangegangen Runden kräftig aussortiert worden war, wurde nun ein einziges Schema (CRYSTALS-Kyber) für Verschlüsselung & Schlüsselaustausch ausgewählt. Für digitale Signaturen schafften es immerhin drei Verfahren – CRYSTALS-Dilithium, FALCON und SPHINCS+ – in die Standardisierung, die nun etwa zwei Jahre in Anspruch nehmen soll.

UPDATE 5. August 2022: Dazu sind nach dem Ausscheiden von SIKE noch drei weitere Verfahren auf dem Prüfstand.

Da dies jedoch auch im besten Fall zu wenige Verfahren sind, um sicherzustellen, dass mindestens eines pro Anwendungsfall auch die nächsten Jahre der Forschung und Kryptoanalyse überleben wird, gibt es nun zusätzlich einen neuen Aufruf zu einer vierten Runde, in der weitere Verfahren eingebracht und diskutiert werden sollen.

Abfragwürdig: Queryable Encryption wird praktikabel

Die meisten Evolutionsschritte in der Kryptographie haben nicht sofort nennenswerte Auswirkungen auf die Praxis. Schlimmstenfalls wird ein Verfahren oder ein Algorithmus durch einen neuen kryptoanalytischen Angriff unbrauchbar gemacht oder geschwächt. Aber dass neue Anwendungsfelder entstehen, geschieht nur etwa einmal im Jahrzehnt (z. B. in den 70er Jahren mit Public-Key-Kryptographie, in den 2000ern mit Blockchain oder in den 2010ern mit bestimmten quantensicheren Verfahren).

Jetzt könnte ein solcher Punkt wieder einmal erreicht sein: Mathematisch ist Queryable Encryption kein Hexenwerk. Verglichen mit ihrer großen Schwester könnte sie gar als geradezu trivial bezeichnet werden: Während homomorphe Verschlüsselung das Durchführen beliebiger Rechenoperationen auf verschlüsselten Daten ermöglicht, verspricht Queryable Encryption nur die Möglichkeit, bestimmte Operationen auszuführen, ohne die Daten zu entschlüsseln – im Wesentlichen eine (semantisch möglichst reichhaltige) Suche.

Das allein ermöglicht schon magisch klingende Anwendungsfälle: Der Cloud-Provider muss nicht mehr in unsere Daten hineinschauen. Das polizeiliche Informationssystem kann gewisse Recherchen durchführen, ohne den Inhalt der Datensätze kennenzulernen. Bestimmte bioinformatische Forschung kann auf verschlüsselten Genomen erfolgen. Die Kunst besteht jedoch darin, ein solches Kryptosystem zur Einsatzreife zu bringen.

Den Macherinnen und Machern der beliebten NoSQL-Datenbank MongoDB scheint es nun gelungen zu sein, Queryable Encryption in ihr Flaggschiff-Datenbank-Produkt Atlas einzubauen. Im aktuellen Preview ist zunächst nur die exakte Suche enthalten – das aber immerhin schon auf komplett randomisiert verschlüsselten Daten, krankte doch herkömmliche Client-Side-Verschlüsselung immer daran, dass nur deterministisch (immer gleich) verschlüsselt werden konnte, um die Daten wiederfinden zu können. Die Möglichkeit zur Suche nach Intervallen (Range) und Substrings soll in späteren Releases folgen.

Ob sich die Implementierung in MongoDB in der Praxis bewährt, wird sich erst noch zeigen. Als großer Schritt für die angewandte Kryptographie insgesamt darf das Feature aber durchaus schon gefeiert werden.

https://www.mongodb.com/blog/post/mongodb-releases-queryable-encryption-preview

Kein Ende-zu-Ende gut, alles gut bei E-Mail

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur “nicht-sensible” Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

  1. Sichere Software,
  2. Schulung (zur richtigen Verwendung) und
  3. Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder “Blödsinn” gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.

Schematische Darstellung Decryption Oracle

Von Decryption und Signing Oracles: Covert-Content-Angriffe auf E-Mail

Dieser Blog-Beitrag ist eine Zusammenfassung der Untersuchungen, welche von der Autorin im Rahmen einer Abschlussarbeit für den Studiengang Informatik/IT-Sicherheit durchgeführt wurden.

Mit der Entwicklung der Netzwerktechnologie ist die E-Mail zu einem unverzichtbaren Mittel für die tägliche Kommunikation geworden. Laut Untersuchungen der Radicati Group nutzten 2019 bereits über die Hälfte der Weltbevölkerung E-Mails. Viele sensible Informationen werden so ausgetauscht. Im geschäftlichen Kontext können das beispielsweise Liefervereinbarungen, Verträge verschiedenster Art oder vertrauliche Korrespondenz mit Kunden oder Geschäftspartnern sein. Im privaten Umfeld sind zum Beispiel personenbezogene Informationen, vertrauliche Korrespondenzen etc. nicht minder interessant für Internetkriminelle.

E-Mail-Sicherheit

E-Mail-Verschlüsselung und digitale E-Mail-Signatur schaffen im Idealfall Sicherheit für die Nutzer. So ist eine digitale E-Mail-Signatur mit einer Unterschrift im realen Leben vergleichbar. Durch das digitale Signieren einer E-Mail kann der Absender eindeutig identifiziert werden. Außerdem kann die Integrität der Nachricht sichergestellt werden. Das bedeutet, dass der Empfänger erkennen kann, ob die E-Mail unterwegs verändert wurde. Das Versenden einer E-Mail ist mit dem Verschicken einer Postkarte in der anlogen Welt vergleichbar. Die Postkarte wird in den Briefkasten geworfen, der Briefträger holt sie dort ab, und über verschiedene Stationen wird sie schließlich dem Empfänger zugestellt. Jeder, der an der Zustellung beteiligt ist, kann die Postkarte lesen. Beim Versand einer E-Mail ist es ähnlich. Standardmäßig werden E-Mails unverschlüsselt übertragen. Bis sie allerdings beim Empfänger zugestellt werden können, passieren sie viele verschiedene Mailserver und andere Netzwerksysteme. Jeder kann die unverschlüsselte E-Mail abfangen, zwischenspeichern oder mitlesen.

What’s up Johnny?

In 2019 stellten Müller et al. [1] in ihrer Veröffentlichung “Re: What’s up Johnny?” die sogenannten Covert-Content-Angriffe auf E-Mail Verschlüsselungen und E-Mail Signaturen vor. Die Autoren zeigen, dass die Schutzziele Vertraulichkeit, Authentizität und Integrität einer E-Mail bei der Nutzung bestimmter E-Mail-Clients verletzt werden können.

Die Anfälligkeit der E-Mail Kommunikation in Bezug auf die Gewährleistung der Schutzziele wird durch die Angriffe belegt. Es sind verschiedene Angriffszenarien denkbar:

  1. Übertragung falscher Daten
    1. Impersonation
    2. Manipulation von Informationen
    3. Phishing
    4. Social Engineering
  2. Unbefugter Zugriff auf Daten
    1. Wirtschaftsspionage
    2. Verletzung der Privatsphäre

Die Covert-Content-Angriffe nutzen einerseits die Eigenschaften des MIME-Standards und andererseits HTML/CSS, um den Nutzer zu täuschen. Als Backchannel wird die Antwort-Funktion des E-Mail-Clients genutzt.

Es wird dabei zwischen zwei Angriffskategorien unterschieden: Decryption Oracle und Signing Oracle.

Decryption Oracle

Das Ziel des Angriffs im Sinne des Decryption Oracle ist es, den entschlüsselten Klartext über den Backchannel unbemerkt zu extrahieren. Müller et al. beschreiben, wie es einem Angreifer gelingt, (abgefangenen) Ciphertext in einer harmlosen E-Mail an das Opfer zu verstecken. Nutzt das Opfer die Antwort-Funktion des E-Mail-Clients wird es zum „Decryption Oracle“ und sendet unbewusst den versteckten, jedoch nun entschlüsselten Klartext an den Angreifer zurück.

Das Prinzip des Angriffs wird in Abbildung 1 dargestellt. Die Voraussetzung ist, dass der Angreifer Zugang zu der verschlüsselten Kommunikation zweier Parteien. Hierfür gibt es verschiedene Szenarien. Beispielsweise hat der Angreifer aufgrund eines schwachen, leicht zu erratenen Passworts, Zugang zu dem E-Mail-Konto auf dem E-Mail-Server. Eine weitere Möglichkeit ist, dass der Angreifer die verschlüsselte E-Mail mitliest und speichert, wenn der Nutzer diese über eine unverschlüsselte Verbindung vom Mail-Server abruft.

Abbildung 1: Covert-Content-Angriff gegen E-Mail-Verschlüsselung (Decryption Oracle)

Der Angreifer kann die verschlüsselten E-Mails jedoch nicht selbst entschlüsseln, denn er ist nicht im Besitz des privaten Schlüssels. Daher sendet er eine manipulierte E-Mail an einen der beiden Original-Kommunikationspartner. Dabei ist es unerheblich, ob es sich dabei um den ursprünglichen Sender oder Empfänger der E-Mail handelt. Denn die Verschlüsselung der E-Mail erfolgt beim Sender sowohl mit seinem eigenen öffentlichen Schlüssel als auch mit dem öffentlichen Schlüssel des Empfängers. Wie Abbildung 1 zeigt, besteht die manipulierte E-Mail aus zwei Teilen. Der erste Teil ist eine unverfängliche Nachricht, die das das Opfer zu einer direkten Antwort animieren soll. Um den Angriff erfolgreich durchführen zu können, ist der zweite Teil der Nachricht encω(m) für das Opfer unsichtbar. Antwortet das Opfer auf diese manipulierte E-Mail, dann wird der entschlüsselte Klartext m, als unsichtbarer Bestandteil der E-Mail zurück an den Angreifer gesendet.

Signing Oracle

Die zweite Angriffs-Kategorie verfolgt das Ziel, eine gültig signierte E-Mail durch den vom Opfer genutzten E-Mail-Client, welcher als Signing Oracle fungiert, zu erhalten. Abbildung 2 stellt das Prinzip des Covert-Content-Angriffs für das Signing Oracle dar. Die manipulierte E-Mail besteht hierbei wieder aus zwei Textteilen. Der erste, sichtbare und unverfängliche Teil, der zum Antworten animieren soll, und der zweite, versteckte Teil der Nachricht, der für weiterführende Angriffe genutzt werden soll. Im Kontext einer harmlos erscheinenden E-Mail an das Opfer wird dieser zweite Textteil mittels CSS-Conditional-Rules versteckt. So kann der Angreifer beeinflussen, dass die E-Mail je nach E-Mail-Client unterschiedlichen Text anzeigt. Da die digitale Signatur für die vollständige originale E-Mail gültig ist, kann die E-Mail durch den Angreifer für weitere Angriffe missbraucht werden. Beispielsweise kann der Angreifer sich per E-Mail als vertrauenswürdiges Mitglied des Unternehmens ausgeben, um dringende Überweisungen von ahnungslosen Mitarbeitern zu veranlassen.

Abbildung 2: Covert-Content-Angriff gegen E-Mail-Signatur (Signing Oracle)

Re-Evaluation

Seit der Durchführung der Tests sind mittlerweile ca. zwei Jahre vergangen. Daher wurden nun im Rahmen einer Re-Evaluation folgende Fragen beantwortet:

  1. Sind die Covert-Content-Angriffe auf die untersuchten Email-Clients weiterhin möglich?
  2. Falls nein, können die Gegenmaßnahmen durch Erweiterung der Angriffe umgangen werden?

Es wurden 22 E-Mail-Clients in die Untersuchung einbezogen. Davon unterstützen 19 Clients PGP-Verschlüsselung und -Signatur, 19 Clients S/MIME-Signatur und 18 Clients S/MIME-Verschlüsselung. Die Angriffe funktionieren bei vielen der getesteten E-Mail-Clients weiterhin. Die Re-Evaluation für die Signing Oracle-Schwachstelle ergab keine nennenswerte Veränderung im Vergleich zur Evaluation von Müller et al. [1]. Sämtliche Testcases der Evaluation als auch der Re-Evaluation sind auf Github veröffentlicht und können dort heruntergeladen werden [2].

Ergebnisse

Es sind 37% der S/MIME- und 32% der PGP-fähigen E-Mail-Clients als Signing Oracle angreifbar. Bei Müller et al. waren es 41% bzw. 32% der entsprechenden E-Mail-Clients. In Bezug auf die Decryption Oracle-Schwachstelle ist von Herstellerseite am meisten nachgebessert worden. Es existieren zwar nach wie vor E-Mail-Clients, bei denen es möglich ist, Klartext zu extrahieren, wenngleich deren Zahl um die Hälfte zurückgegangen ist. Insbesondere der Angriff für den Testcase 01-reply-mix-css.eml, der zum Ziel hat, den entschlüsselten Klartext vollständig zu verstecken, schlug bei allen E-Mail-Clients fehl. Die Hersteller haben teilweise die von Müller et al. vorgeschlagenen Gegenmaßnahmen gegen die Covert-Content-Angriffe umgesetzt. Die vollständige Ergebnisübersicht ist in der Tabelle 1 dargestellt.

Abschließend wurden verschiedene Modifikationen der Angriffe vorgenommen. War es im Rahmen der Re-Evaluation nicht mehr möglich, den Klartext vollständig zu verstecken, konnte dies durch eine Modifikation des Testcase 01-reply-mix-css.eml wieder realisiert werden. So ist es möglich, bei drei der S/MIME-fähigen und bei einem der PGP-fähigen Clients den entschlüsselten Klartext für den Nutzer unsichtbar zu gestalten. Dafür werden CSS-Regeln verwendet. HTML und CSS unterliegen einer ständigen Weiterentwicklung durch das World Wide Web Consortium (W3C). Es gibt immer noch E-Mail-Clients, die auch in der Antwort-E-Mail HTML/CSS unterstützen. Dies ist auch eine der Eigenschaften, die durch die reevaluierten Angriffe ausgenutzt wird. Daher ist es eine Frage der Zeit, bis neue Modifikationen, Schwachstellen in Bezug auf die Covert-Content-Angriffe aufzeigen.

Der Nutzer hat viele verschiedene Möglichkeiten, den Client nach seinen Wünschen und Bedürfnissen zu konfigurieren. Die E-Mail-Clients wurden in den Standard-Einstellungen getestet, aber die Re-Evaluation hat gezeigt, dass das Prinzip der Covert-Content-Angriffe, die Antwort-Funktion des E-Mail-Clients als Backchannel zu nutzen, nach wie vor funktioniert. Es entsteht der Eindruck, dass die Hersteller die Verantwortung für eine sichere E-Mail-Kommunikation auf den Nutzer abschieben. Und das ist nicht im Sinne der Sicherheit. Cranor und Buchler [3] stellten bereits fest, dass Benutzer nicht gewillt sind, aktiv die Einzelheiten der Sicherheitsmerkmale zu verwalten. Die Systemdesigner sind in der Pflicht, sich im Vorfeld über die Entscheidungsanforderungen Gedanken zu machen, welche an die Benutzer gestellt werden. Fast jeder Dritte der getesteten PGP-fähigen und gut jeder Fünfte der S/MIME-fähigen Clients ist als Decryption Oracle angreifbar. Sicherheit und Benutzerfreundlichkeit werden traditionell als Kompromiss betrachtet. Nach Schneier [4] führt genau dieses „Entweder-Oder“-Denken oft zu Systemen, die weder benutzbar noch sicher sind. Die Betrachtung, ob ein sicherer E-Mail-Client weniger funktional und ein flexibler und leistungsfähiger E-Mail-Client weniger sicher ist, lassen Raum für weitere Forschung.

Tabelle 1: Re-Evaluation Covert-Content-Angriffe

Quellen

[1] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Sebastian Schinzel, und Jörg Schwenk. Re:What’s Up Johnny?: Covert Content Attacks on Email End-to-End Encryption. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 11464 LNCS:24–42, 2019. ISSN 16113349.

[2] https://github.com/RUB-NDS/Covert-Content-Attacks

[3] Lorrie Faith Cranor und Norbou Buchler. Better Together: Usability and Security Go Hand in Hand. IEEE Security Privacy, 12(6):89–93, nov 2014. ISSN 1558-4046.

[4] Bruce Schneier. Stop Trying to Fix the User. IEEE Security & Privacy, 14(05):96, 2016. ISSN 1558-4046. URL https://doi.org/10.1109/MSP.2016.101.