Irgendwie wissen wir es, aber durch die vollmundigen Anpreisungen und einer Unmenge von ’sicheren› Apps, mit welchen viele Unternehmen uns umgarnen, schlagen wir unsere Bedenken bezüglich der verlangten Sicherheit an das Smartphone in den Wind. So bleibt uns nur der subjektive Eindruck: «Das muss ja sicher sein…“

Aber wie steht es wirklich um die Sicherheit von mobilen Anwendungen, die von Unternehmen, wie  Banken, Versicherungen, Telekommunikationsanbieter, Transportwesen angeboten werden? Der nachfolgende Text soll Denkanstösse über die objektive Sicherheit von Smartphone-Apps geben.

Was ist eigentlich „Sicherheit“?

Die etwas sperrige aber übliche Definition von ‹Sicherheit› besagt, «dass das grundsätzliche Ziel einer sicheren Lösung in der Informatik die korrekte Verwaltung eines virtualisierten Gutes (engl. «Asset») nach Willen des Eigners ist. Kein Dritter soll sich an den Gütern in irgendeiner Form bereichern können, ohne dass dies der Wille des Eigners ist». Diese Beschreibung erscheint wie selbstverständlich in einer perfekten Welt, in der es keine «Böses-im-Sinn-habenden Personengruppen» (= Angreifer) gibt. In der realen Welt aber erzeugt der Besitz von Gütern ein Begehren durch Dritte. Je grösser der Wert der verwalteten Güter, desto stärker wird dieses Begehren, welches so lange auf die Schwächen der angebotenen Lösung einwirkt, bis über den schwächsten Punkt ein Angriff erfolgt. Zwei scheinbar unabhängige Beispiele untermauern das:

• Die sichere Lösung beim E-Banking garantiert die korrekte und fehlerfreie Verwaltung des monetären Vermögens des Kunden. Das Ziel des Angreifers ist demnach, sich am Vermögen der Kunden unberechtigt zu bereichern.
• Eine sichere Lösung im E-Health (Verwaltung von Patientendaten) garantiert die korrekte und fehlerfreie Verwahrung der Vitaldaten, sowie die gezielte Bekanntgabe von privaten Daten an Dritte (sofern vom Patienten erwünscht). Das Ziel des Angreifers ist das Erlangen des Wissens bzgl. der Vitaldaten oder sogar deren fatale Manipulation im eigenen Interesse.

Unsichere Kommunikationskanäle

Durch die vollmundigen Versprechen der einzelnen Unternehmen ist man geneigt zu akzeptieren, dass eine gut geschriebene und fehlerlose App dem Druck eines Angreifers standhalten kann und man so sicherheitskritische Aktionen auf dem Smartphone durchführen darf. Doch genau das ist nicht der Fall. Betrachten wir dazu den unwahrscheinlichen Fall, dass ein Unternehmen eine 100% fehlerfreie Lösung bereitstellt, welche sie als App ihren Kunden zur Verfügung stellt und lassen diese auf einem beliebigen Smartphone laufen. Auch in diesem Falle muss die App für die Kommunikation mit dem Menschen zwei Kanäle anbieten:

• Der Ausgabekanal zum Benutzer, damit dieser die Verwaltung der Daten (z.B. Geld oder Vitaldaten) einsehen kann und zudem erkennen kann, welche Aktionen die Sicherheitslösung damit ermöglicht. Dafür wird typischerweise das Display des Smartphones genutzt.
• Der Eingabekanal zur Sicherheitslösung, damit diese die Anweisungen des Benutzers verstehen und ausführen kann. Eingaben werden zumeist über den Touchscreen realisiert.

Es sind aber genau diese beiden Kanäle, welche durch das Smartphone in keiner Weise abgesichert werden können. Dieser «Showstopper» gilt nicht nur für Smartphones im Speziellen, sondern auch für PC, Notebooks etc. Der Benutzer kann sich nie sicher sein, ob er der Ausgabe des Displays vertrauen kann, da eine böswillige App des Angreifers (= Malware) die Ausgabe der App auf dem Display überlagern kann (= Overlay-Attack). Aus der Ausgabe für ein ‹Nein› wird so plötzlich ein ‹Ja›, ein falscher Empfänger für eine Transaktion wird durch den vermeintlich richtigen Empfänger ersetzt. Ähnliches gilt für die Eingaben, welche der Benutzer tätigt. Obwohl der Benutzer beispielsweise die Passworteingabe nur der richtigen App überlassen will, wird diese notgedrungen auch gleich der Tastatur-App mitgeteilt, welche möglicherweise vom Angreifer kontrolliert wird. Auch hier ist wieder ein Angriffspotenzial vorhanden, welches weder vom System noch vom Benutzer erkannt werden kann.

Offen für Malware 

Doch wie kommt die App des Angreifers auf ein Smartphone? Ein Smartphone ist wie jeder Computer per Definition offen für neue Software (engl. software open). Das ist genau die Eigenschaft, welche dem Smartphone zum Durchbruch gereicht hat. Es ist aber auch genau diese ‹Offenheit›, welche es verunmöglicht zu wissen, ob eine böswillige Software (=Malware) installiert ist oder nicht. Diese grundlegende Erkenntnis wurde bereits in den 1940er Jahren durch Alain Turing bewiesen. Ein Angreifer kann seine Malware in fast beliebig kleinen Teilen über mehrere Apps (und deren Berechtigungen) verteilt auf ein Smartphone bringen, sodass weder vermeintliche Malware-Filter noch der Benutzer selber diese je erkennen können.

Kalkuliertes Risiko für die Unternehmen

Wenn dem so ist, warum gibt es denn aber die vielen „sicheren“ Apps, insbesondere im Finanzbereich (E-Banking / Twint / etc.)? Der grösste Schaden für ein Unternehmen ist eine Dezimierung des Kundenstamms. Dies bringt die Unternehmen dazu, dem Kunden die Interaktion mit dem angepriesenen Produkt so einfach und angenehm wie möglich zu machen, am besten mit einer sexy Smartphone-App. Der mögliche Schaden, der dem Kunden durch einen Angriff über das Smartphone entstehen kann, ist kalkuliert und wird weitestgehend auf den Kunden abgewälzt. Um das Risiko möglichst tief zu halten, wird dem Kunden die Sorgfaltspflicht überlassen, ihm also die bewiesenermassen unmögliche Aufgabe auferlegt, das Smartphone Malware-frei zu halten. Passiert dennoch ein Schaden, welcher erwiesenermassen auf einen Angriff zurückzuführen ist, verhält sich die Bank dann kulant?

Weil wir es so wollen

Sämtliche Dienstleister, die Apps für ihre Produkte über das Smartphone anbieten, machen dies (laut deren Aussage), weil wir als Kunden das so verlangen. Für mögliche Schäden kommt in erster Linie der Kunde auf. Im Gegensatz zu monetären Verlusten, die evtl. noch rückführbar sind, ist beim Bruch der Privatsphäre der Schaden maximal und kann auch nicht rückgängig gemacht werden. So liegt es am Benutzer, das beschriebene Risiko abzuwägen. Dafür wird von jedem einzelnen von uns eine a priori Mündigkeit in diesen Belangen erwartet, womit sich die ganze Angelegenheit als gesellschaftliches Problem manifestiert, welches es zu lösen gilt.

It’s not the encryption that‘s cryptography.It’s the random number generator!

SSL/TLS ist eine in Web Browsern integrierte Sicherheitstechnologie und schützt eine Unmenge von Internet-Anwendungen. Für die Sicherheit von SSL/TLS ist u.a. der Zufallszahlengenerator zentral. Über den Zufallszahlengenerator lässt sich eine von aussen fast nicht erkennbare Hintertür einbauen. Mit der Hintertür vermag ein Dritter (Carl), SSL/TLS mit definiertem Aufwand zu entschlüsseln; dies unabhängig vom Verschlüsselungsverfahren. Gegebenenfalls kann Carl die Verbindung sogar übernehmen. Er sammelt dazu nur alle SSL/TLS Pakete im Netz. Ein Zugang zum Client oder Server ist nicht nötig. Es bedarf lediglich einer Kooperation zwischen dem Browserhersteller und Carl.

Wie eine von aussen fast nicht erkennbare Hintertür in SSL/TLS eingebaut werden kann, wird hier kurz beschrieben. „Von aussen“ meint ohne Untersuchung der Operationen auf dem Betriebssystem des Browsers und ohne Zugang zum Quellcode. Da oft keine Schnittstelle zum Zufallszahlengenerator im Browser existiert, kann die Sicherheit von SSL/TLS nicht abgeschätzt werden und bleibt also völlig diffus.

Prinzip des SSL/TLS Verbindungsaufbaus

Der SSL/TLS Aufbau erfolgt vereinfacht dargestellt wie folgt, siehe [Res] und RFC Standards für Details:

1. Einigung auf ein Geheimnis zwischen Client und Server
2. Aus dem Geheimnis werden die Schlüssel für die Verschlüsselung und die Authentizität abgeleitet.
3. Mittels Kontrollmeldung wird festgestellt, ob sich Client und Server auf dieselben Schlüssel geeinigt haben.
4. Austausch von Daten über die geschützte Verbindung.

Ob sich der Client oder User auf Ebene SSL/TLS authentisiert, ist für die Schlüsselvereinbarung unbedeutend. Nur die dafür relevanten Abläufe werden beschrieben. Dabei wird unterschieden, ob die Vereinbarung mit RSA oder mit Diffie-Hellman erfolgt.

RSA Schlüssel beim Server

Der Server besitzt einen privaten RSA Schlüssel mit dazugehörigem Zertifikat. Für die Authentisierung muss er etwas korrekt entschlüsseln. Die Schlüsselvereinbarung läuft wie folgt ab:

• Der Client sendet dem Server die von ihm erzeugte Zufallszahl RA_C. (28 Byte).
• Der Server erzeugt die Zufallszahl RA_S (28 Byte.), sendet sie mit seinem Zertifikat dem Client.
• Der Client generiert die Zufallszahl M (46 Byte) und verschlüsselt sie mit dem öffentlichen Schlüssel S im Server-Zertifikat. => E_S(M). E_S(M) wird dem Server zugestellt.
• Der Server entschlüsselt E_S(M) und erhält so M.
• Aus M, RA_C und RA_S werden die Schlüssel für die SSL/TLS Verbindung abgeleitet.
• Mittels Kontrollmeldung wird geprüft, ob sich Client und Server auf dieselben Schlüssel geeinigt haben.

Einbauen einer Hintertür

Hier eine Variante für den Einbau einer Hintertür:

• M wird nicht zufällig erzeugt. M ist der Wert einer geheimen Funktion F. F kennen nur der Browser-Hersteller und Carl.
• Input der Funktion F sind die Zufallszahlen RA_C, RA_S, eine Zufallszahl P, eine geheime Bitfolge, Informationen, welche pro Verbindung individuell sind, wie Teile vom Serverzertifikat, Versionsnummer von TLS, usw. Was als Input verwendet wird, kennen nur der Browser-Hersteller und Carl.
• Die Funktion F erzeugt mit dem Input den Output M.

Carl kennt ausser P alle Bestandteile zur Bildung von M. Diese werden wie RA_C, RA_S im Klartext versandt! Bis Carl M gefunden hat, generiert er für jeden möglichen Wert P‘ einen Kandidaten M’, bestimmt daraus die Schlüssel für die SSL/TLS Verbindung. Er prüft mit der Kontrollmeldung, ob M = M‘ ist.

Diffie-Hellman

Der Server hat einen privaten Signaturschlüssel und dazugehöriges Zertifikat. Die Schlüsseleinigung läuft wie folgt ab:

• Der Client sendet dem Server die Zufallszahl RA_C (28 Byte).
• Der Server erzeugt die Zufallszahl RA_S (28 Byte) und sendet sie mit seinem Zertifikat dem Client.
• Der Server erzeugt zufällig eine Bitfolge S und führt damit die Diffie-Hellman Operation durch => yS = g^S mod p. Dies wird vor der Server Signatur dem Client zugestellt.
• Der Client erzeugt die Zufallszahl C und führt die Diffie-Hellman Operation durch => yC = g^C mod p. Dies wird dem Server zugestellt.
• Aus g^CS mod p, RA_C und RA_S werden die kryptographischen Schlüssel für Vertraulichkeit und Authentizität abgeleitet.
• Mittels Kontrollmeldung wird geprüft, ob sich beide Seiten auf dieselben Schlüssel geeinigt haben.

Einbauen einer Hintertür

C wird nicht zufällig erzeugt. C ist der Wert einer geheimen Funktion F, die nur der Browser-Hersteller und Carl kennen. Die Inputs der Funktion sind, die Zufallszahlen RA_C, RA_S, die Zufallszahl P, eine geheime Bitfolge, Informationen, welche pro Verbindung individuell sind, wie der öffentliche Diffie-Hellman Schlüssel des Servers yS = g^S mod p, Bestandteile des Serverzertifikats, Signatur des Servers, usw. Welche Information in welcher Form hinzugezogen wird, ist Aussenstehenden unbekannt.

Carl kennt ausser P aller Bestandteile zur Erzeugung von C. Für jeden möglichen Wert von P generiert er solange ein C‘, bis g^C‘ = g^C mod p.

Erfolgsfaktoren

Damit die Hintertür unerkannt bleibt, ist u.a. wichtig:

• Die Funktion F vermag, M oder C von beiden Zufallszahlen RA_C, RA_S und weiterem Input statistisch loszulösen. Sie sollte den Zufallsgehalt des Input erhalten.
• Viel Zufallsgehalt (Entropie) zur Bildung von M oder C.
• RA_C wird möglichst zufällig erzeugt.
• Für die Inputs von F werden Werte hinzugezogen, welche durch die SSL/TLS Kontrollmeldung geprüft werden. Somit sind die Werte für M oder C mit SSL/TLS geschützt.

Von aussen kann die Hintertür nur entdeckt werden, wenn der Server bei jedem SSL/TLS Aufbau stets gleich antwortet (gleiche Zufallszahl usw.) Anhand einer Kollision bei M oder C könnte eine Unstimmigkeit entdeckt werden. Eine Kollision meint, wenn statistisch unerwartet früh, zwei gleiche M oder C generiert werden.

Rund 2^T Versuche sind nötig, damit die Wahrscheinlichkeit grösser als ½ ist, dass eine Kollision bei M oder C stattfindet, d.h. zwei gleiche M oder C generiert werden. T = (¦RA_C¦ + ¦P¦)/2, ¦P¦ = Bitlänge von P, ¦RA_C¦ = Bitlänge von RA_C = 224 Bit. Je länger P, desto höher der Aufwand für die Entschlüsselung, aber desto besser die Maskierung der Hintertür. Wird M oder C vor dem Verbindungsabbau bestimmt, so kann Carl in die SSL/TLS Verbindung eingreifen.

Schlussfolgerungen

Keinen Beweis für eine Hintertür zu finden, ist kein Beweis, dass es keine Hintertür gibt.

SSL/TLS weist Schwächen im Design auf, weil die Schlüssel für die Verschlüsselung und die Authentizität auf der Qualität nur eines Zufallszahlengenerators beruhen. Wie dieser funktioniert, ist oft unklar, damit auch die Sicherheit. Um dies zu ändern, müsste SSL/TLS angepasst werden.

Literaturangabe

[Res] Eric Rescorla, SSL and TLS, Addison-Wesley, 2001

SSL 3.0 The Secure Sockets Layer (SSL) Protocol Version 3.0, RFC 6101

TLS 1.2 The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246

Die Sicherheit – gerade beim Login auf Online-Plattformen – wird im Zeitalter ansteigender Cyberkriminalität immer wichtiger. In der Praxis gestaltet sich die Nutzung der Zwei-Faktor Authentifizierung für die Nutzer als eher mühsam. Das ETH-Spinoff «Futurae» zeigt, dass es auch anders geht…

Die Digitalisierung schreitet in enormem Tempo voran und somit steigt die Anzahl digitaler Services, die Einfachheit, Individualität und Mehrwert versprechen. Auch der Anspruch an die Sicherheit solcher Plattformen steigt stetig, insbesondere bei Plattformen mit sensitiven oder vertraulichen Daten. Gerade der Login auf Plattformen, wie zum Beispiel Bankenportalen für das E-Banking gestaltet sich heute aber oft umständlich und dauert lange.

Bei diesen Authentifizierungsprozessen kommt heute die Zwei-Faktor Authentifizierung zum Zug, bei der jeweils in zwei Schritten der Nutzer verifiziert wird. Der erste Schritt beinhaltet die Eingabe von Benutzername und Passwort, dann erfolgt in einem zweiten Schritt die Verifikation über die Eingabe eines Codes via Kartenlesegeräte (Token), Bestätigung eines SMS-Codes oder über Scan eines QR-Codes. Ein umständlicher, langer und zum Teil gar unsicherer Prozess… Gerade die SMS-Variante gilt unterdessen als unsicher und muss in Kürze in der Schweiz abgelöst werden. Zudem verursachen aktuelle Authentifizierungslösungen für die Anbieter sehr hohe wiederkehrende Kosten, so wird bei gewissen Modellen neben Lizenz-, Infrastruktur- und Supportkosten zusätzlich auch pro Login eine Gebühr fällig.

Es geht auch einfacher…
Das ETH Spin-off «Futurae», welches vor zwei Jahren aus dem Departement System Security Group entstanden ist, hat sich zum Ziel gesetzt, den Authentifizierungsprozess für den Nutzer einfacher und sicherer zu gestalten. Sie hat ein Verfahren entwickelt, welches den Login-Prozess für den Nutzer in nur einem gefühlten Schritt ermöglicht – und dies ohne manuelles Zutun. Somit entfällt die mühsame Nutzung von Kartenlesegeräten, altmodischen Streichlisten, abfotografieren von QR-Codes am Bildschirm (Foto-TAN) oder das eingeben von SMS-Codes (mTAN).

Das Produkt «SoundProof» funktioniert mittels Smartphone und nutzt die Umgebungsgeräusche des Nutzers. Um sich auf einer Webseite anzumelden, gibt man zuerst wie gewohnt Benutzername und Passwort ein. Die SoundProof-App nimmt dann über das Smartphone und das Mikrophon im Notebook die Umgebungsgeräusche auf. Die beiden Aufzeichnungen werden anschliessend mit Hilfe eines AI-Algorithmus auf dem Smartphone abgeglichen.

Und sicherer…
SoundProof basiert auf speziell entwickelten AI-Algorithmen mit einer 2048-Bit RSA und 128-bit AES Verschlüsselung. Das entspricht dem Military-Grady Encryption Standard. Man bräuchte mit dem heutigen Stand der Technik rund 15 Jahre um diesen Code zu knacken. Selbst am USENIX Symposium in Washington im Jahr 2015 (einer der wichtigsten Security Hacker-Events weltweit), hielt die SoundProof App den Angriffen stand. Das Verfahren ist absolut sicher, da Umgebungsgeräusche nicht zu fälschen sind.

Das grosse Potenzial
Futurae fokussiert in einem ersten Schritt auf die Finanzdienstleistungs- und Gesundheitsbranche, wobei auch IT Dienstleister (die solche Lösungen implementieren) eine wichtige Rolle spielen. Längerfristig sind aber alle Unternehmen weltweit angesprochen, die Kunden- oder E-Commerce-Portale anbieten und ihre Sicherheit erhöhen wollen, ohne die Benutzerfreundlichkeit zu verringern.
Der innovative Ansatz gibt dem Startup recht, es wurden bereits Aufträge realisiert und es laufen diverse Pilotprojekte bei IT-Dienstleistern und grossen Finanzinstituten in der Schweiz. Auch in Punkto Kosten, ist die SoundProof Lösung um ein Vielfaches günstiger als bestehende Angebote.

Futurae Technologies AG Intuitive Security, Today.
Futurae bietet Unternehmen eine Authentifizierungs-Suite mit AI-basierten und autonomen Authentifizierungs- und Regulierungs-kompatiblen Produkten (z.B. PSD2). Diese Produkte sorgen für höhere Produktivität und verbesserte Benutzererfahrung bei Mitarbeitenden und Kunden.
www.futurae.com