Interview: Sicherheit und Architektur von TeleGuard

Frage:
Im Artikel von 404media wird behauptet, dass private Schlüssel von TeleGuard-Nutzern auf Server übertragen werden und dadurch potenziell Kommunikation mitgelesen werden kann. Wie reagieren Sie darauf?

Antwort:
Diese Darstellung entspricht nicht den tatsächlichen Gegebenheiten. Die angesprochenen Schlüssel stehen nicht im Zusammenhang mit der Verschlüsselung von Nachrichten. Die Ende-zu-Ende-Verschlüsselung erfolgt über separate, ausschliesslich auf den Endgeräten erzeugte symmetrische Schlüssel (Salsa20), die den Server zu keinem Zeitpunkt in verwertbarer Form erreichen.

Frage:
Warum wird dann überhaupt ein RSA-Schlüssel verwendet?

Antwort:
Der RSA-Schlüssel dient ausschliesslich dem Einladungs- und Kontaktmechanismus, also dem initialen Schlüsselaustausch zwischen zwei Nutzern.
Er wird einmalig verwendet, um eine sichere Basis für die spätere Kommunikation zu schaffen, und spielt danach keine Rolle mehr für die Nachrichtenverschlüsselung.

Frage:
Im Video wird gezeigt, dass ein MITM-Angreifer offenbar Schlüssel abgreifen und Nachrichten entschlüsseln kann. Ist das korrekt?

Antwort:
Das Video zeigt ein technisch mögliches, aber künstlich konstruiertes Szenario.
Alle beteiligten Komponenten – Clients und Analysewerkzeug – laufen auf demselben Gerät. Dadurch erhält das Angriffssystem Zugriff auf Informationen, die unter realen Bedingungen nicht verfügbar wären. Dieses Setup ist nicht repräsentativ für reale Nutzungsszenarien.

Frage:
Sie sagen, ein Angreifer bräuchte einen „entschlüsselten privaten RSA-Schlüssel“. Was bedeutet das konkret?

Antwort:
Der private RSA-Schlüssel ist nicht frei zugänglich, sondern wird geschützt verarbeitet.

Um ihn tatsächlich nutzen zu können, wären zusätzliche Voraussetzungen notwendig – insbesondere Zugriff auf Nutzerdaten, clientseitige Ableitungsprozesse sowie die Kontrolle über den Kommunikationszeitpunkt. Ohne diese Kombination ist der Schlüssel für einen Angreifer praktisch nicht verwertbar.

Frage:
Wie genau wird dieser RSA-Schlüssel geschützt? Und hat der Server Zugriff auf alle nötigen Informationen zur Entschlüsselung?

Antwort:
Der Schlüssel wird ausschliesslich in geschützter Form übertragen. Der Server fungiert dabei lediglich als Transportinstanz.
Er besitzt keine vollständige Informationsbasis, um den Schlüssel eigenständig zu rekonstruieren. Entscheidende Teile der Verarbeitung und Ableitung erfolgen ausschliesslich clientseitig.

Frage:
Ist es faktisch korrekt, dass ein MITM-Angreifer über den RSA-Mechanismus letztlich Nachrichten entschlüsseln kann?

Antwort:
Unter realistischen Bedingungen: nein.
Ein solcher Angriff würde eine Kombination mehrerer hochkomplexer Voraussetzungen erfordern – darunter Zugriff auf Endgeräte, erfolgreiche Netzwerkmanipulation zum richtigen Zeitpunkt sowie zusätzliche interne Kenntnisse.
Die Darstellung eines „trivialen“ Angriffs ist daher nicht zutreffend.

Frage:
Warum veröffentlichen Sie kein vollständiges Whitepaper, wie es andere Messenger tun?

Antwort:
Aktuell stellen wir kein umfassendes Whitepaper zur vollständigen Architektur öffentlich zur Verfügung.

Unsere Sicherheitsarchitektur basiert jedoch transparent auf etablierten Prinzipien:

• Ende-zu-Ende-Verschlüsselung mittels Salsa20
• initialer Schlüsselaustausch über RSA im Einladungsprozess
• Absicherung der Transportebene durch HTTPS/TLS

Wir prüfen fortlaufend, in welchem Umfang wir zusätzliche technische Dokumentation bereitstellen können.

Frage:
In Ihrer FAQ wird HTTPS zusammen mit Ende-zu-Ende-Verschlüsselung genannt. Wie ist das technisch zu verstehen?

Antwort:
Hier ist eine klare Unterscheidung wichtig:

• HTTPS/TLS schützt den Transportweg zwischen Client und Server
• Ende-zu-Ende-Verschlüsselung (Salsa20) schützt die Inhalte der Kommunikation

Nachrichten werden direkt auf dem Gerät des Senders verschlüsselt und nur auf dem Gerät des Empfängers entschlüsselt.
Der RSA-Mechanismus dient lediglich der initialen Schlüsselvereinbarung, nicht der eigentlichen Nachrichtenverschlüsselung.

Frage:
Sie haben angekündigt, den „Legacy-Mechanismus“ zu entfernen. Warum?

Antwort:
Dieser Mechanismus stammt aus einer früheren Entwicklungsphase und diente der Gerätekompatibilität.
Auch wenn daraus keine reale Gefährdung entsteht, kann er missverstanden werden. Deshalb wird er entfernt – in Android- und Desktop-Versionen ist dies bereits erfolgt, iOS folgt.

Frage:
Abschliessend: Wie stehen Sie grundsätzlich zur Kritik durch Medien und Experten?

Antwort:
Wir begrüssen fundierte, sachliche Kritik ausdrücklich.
Gleichzeitig halten wir es für wichtig, technische Zusammenhänge korrekt darzustellen und zwischen theoretischen Szenarien und realistischen Angriffen zu unterscheiden.
Unser Ziel bleibt unverändert: maximale Privatsphäre für unsere Nutzer!

Wir möchten in diesem Zusammenhang nochmals auf das von 404media veröffentlichte Video eingehen.

Es wurde aus tatsächlichen Gegebenheiten nicht korrekt dargestellt und hat dadurch leider ein verzerrtes Bild unserer technischen Kompetenz sowie der Sicherheit unseres Produkts vermittelt.

Auch der gewählte Kommunikationsweg von 404 Media war leider nicht ideal: Eine einzelne Support-Anfrage mit sehr kurzer Reaktionsfrist wird der Komplexität eines solchen Themas nicht gerecht und entspricht nicht dem üblichen Vorgehen bei verantwortungsvoller Sicherheitsberichterstattung.

Nochmals zum Video:
Das dargestellte Szenario basiert auf einer künstlich geschaffenen Testumgebung. Im gezeigten Fall hatte der hypothetische Angreifer Zugriff auf die privaten Schlüssel beider Kommunikationspartner. Dies war jedoch nur deshalb möglich, weil die Erstellung der Accounts, der Versand der Einladungen sowie die anschliessende Kommunikation auf ein und demselben Gerät stattfanden.

Das eingesetzte Analyse- bzw. Angriffssystem war direkt mit diesem Gerät verbunden und konnte dadurch im Rahmen einer simulierten MITM-Situation auf Informationen zugreifen, die unter realen Bedingungen nicht verfügbar sind.

Ein vergleichbares Szenario unter realistischen Bedingungen würde voraussetzen, dass ein Angreifer gleichzeitig Zugriff auf beide Endgeräte erlangt – sei es physisch oder durch kompromittierende Software –, zusätzlich gezielte Netzwerkmanipulationen (z. B. DNS-Spoofing oder Eingriffe in Provider-Infrastruktur) durchführt und dies exakt zum Zeitpunkt des Einladungsvorgangs koordiniert.

Die im Video gezeigte Konstellation ist daher nicht mit realistischen Einsatzbedingungen vergleichbar.