/ Software-Entwicklung / AuthentiCall: Protoyp für Live-Authentifizierung von Telefonaten

AuthentiCall: Protoyp für Live-Authentifizierung von Telefonaten

Gerfried Steube on August 18, 2017 - 1:21 pm in Software-Entwicklung

[ad_1]

Regelmäßig geben wir in klassischen Telefonaten brisante Informationen preis. Dabei wissen wir gar nicht, ob das Gegenüber auch das sagt, was wir hören. AuthentiCall stellt Hilfe in Aussicht.

Das öffentliche Telefonnetz ist unsicher. Angezeigte Rufnummern können leicht gefälscht werden. Und Angreifer können sich leicht in die Verbindung einklinken und Sprache verfälschen oder computergenerierte Sprache einspielen, die vom Tonfall des Gesprächspartner kaum zu unterscheiden ist. Diese Probleme will ein Forscherteam um US-Professor Brad Reaves lösen, das dafür einen Prototyp namens AuthentiCall entwickelt hat. Der Wissenschaftler hat seine Arbeit am Donnerstag auf der Konferenz Usenix Security 2017 in Vancouver vorgestellt.

Voraussetzung ist eine Datenverbindung zwischen den beiden Gesprächspartnern, die parallel zur Telefonverbindung läuft. Außerdem müssen sich beide Teilnehmer zuvor bei einer neutralen Einrichtung registriert und für ihre Telefonnummer ein kryptographisches Zertifikat erhalten haben. Ruft dann ein AuthentiCall-User einen anderen an, wird parallel ein Handshake mit dem Zertifikatsserver durchgeführt.

Dabei wird sichergestellt, dass die Zertifikate zu den beteiligten Rufnummern passen. Laut Testergebnissen verzögert das den Rufaufbau um lediglich 1 bis 1.4 Sekunden. Wenn das Zertifikat nicht passt, erhält der Angerufene eine Warnung und hebt besser nicht ab. Außerdem gibt das System einen Hinweis, wenn ein authentifizierter Gesprächspartner aufgelegt hat. Das hindert Angreifer daran, das Gespräch anstelle des ausgeschiedenen Gesprächspartners fortzusetzen.

Auch Gesprächsinhalte werden verifiziert

Während des laufenden Telefonats komprimiert AuthentiCall jede Sekunde den Ton stark und errechnet daraus Robust Sound Hashes (512 bit/s). Dabei handelt es sich nicht um kryptographische Hashes, bei denen schon kleine Veränderungen im Ausgangsmaterial sehr unterschiedliche Ergebnisse zeitigen. Robust Hashes zeitigen bei ähnlichen Ausgangsmaterialien ähnliche Ergebnisse.

Die Robust Sound Hashes (RSH) werden mit Zeitstempeln versehen und mit Schlüsseln verschlüsselt, die beim ursprünglichen Handshake vereinbart wurden. Diese Schlüssel sind nur für die jeweiligen Gesprächspartner und das jeweilige Gespräch gültig. Das Ergebnis wird in Fünf-Sekunden-Häppchen an die Gegenstelle übertragen. Dort vergleicht AuthentiCall die erhaltenen Daten mit dem über die Telefonleitung empfangenen Ton.

Dieser Vergleich darf nicht zu penibel sein, weil Telefonverbindungen grundsätzlich die Tonqualität reduzieren und auch Zeitverzögerungen aufweisen können. Die Robust Sound Hashes müssen aber eben nicht identisch, sondern nur ähnlich genug sein. Erst wenn in einem Fünf-Sekunden-Häppchen bei drei Sekunden eine zu starke Abweichung erkannt wird, schlägt AuthentiCall Alarm.

Kaum False Positives

Das verhindert häufige Fehlalarme (False Positives). Selbst unter extrem schlechten Bedingungen soll man im Schnitt mehr als 425 Stunden telefonieren müssen, bevor es einen Fehlalarm gibt. Bei einer guten Telefonverbindung, die mit dem GSM-Full-Rate-Codec komprimiert ist, sollen es sogar fast 119.000 Gesprächsstunden sein.

Dafür hat ein Angreifer die Möglichkeit, bis zu fünf Sekunden lang einen Teilnehmer zu imitieren. Doch dann schlägt AuthentiCall den Angaben zu Folge mit einer Wahrscheinlichkeit von 99,2 Prozent Alarm. Reaves und seine Kollegen haben für ihren Prototyp eine eigene App für Android-Handys sowie eine Java-Anwendung für den Handshake-Server programmiert. Die Signalisierung der Verbindung lief über Google Cloud Messaging.

Was AuthentiCall nicht beabsichtigt, ist die Gesprächsinhalte geheim zu halten. Dafür eignen sich beispielsweise die App Signal oder spezielle Telefone.

  • Das Paper “AuthentiCall: Efficient Identity and Content Authentication for Phone Calls” zum Download

(ds)

[ad_2]

Read more on: Source

Comments are disabled