HiSolutions Research

Vertrauen gebrochen? TPMs geben ihre Geheimnisse preis

Das Trusted Plattform Module (TPM) soll den Vertrauensanker im Rechner bilden und kann beispielsweise die benötigten Schlüssel für die Festplattenverschlüsselung bereithalten. Genau bei dieser Aufgabe haben sie gerade etwas an Vertrauen verloren, da eine Lücke in der Referenzimplementierung zu einem Auslesen oder Verändern von geschützten Daten führen kann.

Je nachdem, wie sehr die Hersteller von der Referenzimplementierung abgewichen sind, so unterschiedlich fallen die konkreten Auswirkungen aus. Die Voraussetzung für den Angriff haben sie aber alle gemein: Der Zugriff klappt nur aus einem bereits laufenden System heraus mit einem Nutzerkonto, das entsprechenden Zugang zur betroffenen TPM-Funktion „CryptParameterDecryption“ hat. Die Lücke ist also nicht geeignet, um einem ausgeschaltetem Laptop den Bitlocker-Key zu entlocken. Aber wie „Bleeping Computer“ passend anmerkte, erfüllt bereits eine Malware auf dem Laptop die nötigen Bedingungen, um möglicherweise an vertrauliche Informationen aus dem TPM zu kommen.

https://trustedcomputinggroup.org/wp-content/uploads/TCGVRT0007-Advisory-FINAL.pdf
https://www.bleepingcomputer.com/news/security/new-tpm-20-flaws-could-let-hackers-steal-cryptographic-keys/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1017
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1018

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.

HiSolutions Research

Dreh ma‘ durch den Wolf: Threema glänzt im Audit

Die Sicherheit von verschlüsselnden Messengern ist ein heiß diskutiertes Thema, versprechen diese doch Ende-zu-Ende-Security auf einem Niveau, das E-Mail niemals in großem Maßstab erreicht hat. Das in Security-Fachkreisen geschätzte Threema hat nun einen weiteren Meilenstein erreicht: Nachdem 2019 bereits das Labor für IT-Sicherheit der FH Münster ein Audit durchgeführt hatte, wurden jetzt die Kollegen von Cure53 auf die App losgelassen. Der Gesamteindruck der Codequalität und der Struktur des Projekts, das bald auch Open Source werden soll, wurde als „außergewöhnlich solide“ bewertet, schwerwiegende Schwachstellen wurden nicht entdeckt. Die geplante Veröffentlichung des Sourcecodes ist insbesondere vor dem Hintergrund relevant, dass aktuell verschiedene politische Initiativen versuchen, die Sicherheit der Verschlüsselung in Messengern zu untergraben.

https://threema.ch/de/blog/posts/audit-2020

HiSolutions Research

Mixed Feelings: Mixed Content zum Abschuss freigegeben

„Mixed Content“ im WWW bedeutet, dass sich auf einer verschlüsselten Seite auch unverschlüsselte Elemente befinden. Bisher erlaubten Browser dies noch – in der Rege mit Warnung – oder ließen es zumindest freischalten. In Chrome 80 (1/2020) werden zunächst audio+video von http: zu https: auto-remapped. Mixed Content kann immer noch freigeschaltet werden. Ab Chrome 81 (2/2020) werden auch Bilder auf https: zwangsgemapped. Mixed Content kann dann nicht mehr freigeschaltet werden. Andere Browser dürften nachziehen. Höchste Zeit also, alten Seiten mit diesem archaischen und unsicheren Überbleibsel das Gnadenbrot zu entziehen.

https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

HiSolutions Research

Chias muss nicht mehr: Weiteres Tool für VS-NfD zugelasse

Chiasmus hat Konkurrenz bekommen: Als weiteres erlaubtes Software-Verschlüsselungstool für die Nutzung im Zusammenhang mit VS-NfD/EU-RESTRICTED/NATO-RESTRICTED ist nun Gpg4win bzw. GnuPG für KMail unter Linux freigegeben worden.
https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2019/Gpg4win-mit-VS-NfD-070519.html

Liste aller zugelassenen VS-NfD-Tools (Hardware und Software):
https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_html.html