Linux und Ich

Blog über Ubuntu, Linux, Android und IT

RedPhone verschlüsselt Android-VoIP-Telefonate

Open-Source-App RedPhone verschlüsselt Android-VoIP-Telefonate

| 23 Kommentare

Das Thema Verschlüsselung ist eigentlich immer kompliziert. Selten gibt es Lösungen, wo man keine Schlüssel generieren und austauschen muss, wo man nirgends etwas einrichten müsste. Kurz: Lösungen, die einfach funktionieren, gibt es selten. Von daher finde ich RedPhone einen absoluten Knaller. Über RedPhone führt ihr von Handy zu Handy verschlüsselte Telefonate, ganz als ob ihr normal telefonieren würdet, nur dass das Gespräch über SRTP und AES verschlüsselt wird. Und das beste? Red Phone ist Open-Source und steht unter der GPL.

RedPhone stammt von den Sicherheits-Spezialisten von Whisper Systems, einem Unternehmen das im November 2011 von Twitter gekauft wurde. Neben RedPhone bietet Whisper Systems auch kommerzielle Tools an, Android-Systeme gegen Angriffe zu schützen. WhisperCore und WhisperFirewall verschlüsseln das System oder rüsten Firewalls nach, so dass Android gegen den Zugriff Unbefugter abgesichert wird. Zudem gibt es von Whisper Systems mit TextSecure auch noch eine App um Nachrichten verschlüsselt zu übertragen.

Ihr müsst eure Handy-Nummer registrieren, ändert die Nummer aber in +49…

Mit RedPhone veröffentlicht das Unternehmen nun eine VoIP-Telefonie-App, die sich nahtlos in Android einbindet. Gespräche werden bei RedPhone nicht über GSM wie ein normales Handy-Telefon übertragen, sondern über die 3G- oder WLAN-Verbindung. Verschlüsselte Telefonate kosten daher auch kein Geld, sie belasten nur euer Inklusiv-Volumen bei eurem Handy-Anbieter. Der Quellcode der kompletten App wurde unter GPL veröffentlicht, er kann von GitHub heruntergeladen werden. Außerdem wurden auch die Spezifikationen des Protokolls offengelegt, Entwickler können sich daher das Ganze schnappen und eigene RedPhone-Applikationen auf anderen Plattformen schreiben.

Einfach verschlüsselt Telefonieren

Nach der Installation werdet ihr kaum mehr merken können, ob ein Gespräch nun über das normale Handy-Netz eingeht oder über RedPhone verschlüsselt übertragen wird, da sich das Telefon nicht viel anders verhält, als bei einem normalen Gespräch. Ruft einer euren streng geheimen Kontakte an, dann klingelt – zumindest auf einem Vanilla-Android 4.0 bzw 4.1 – das Telefon wie bei einem normalen Anruf.

Zur Verschlüsselung nutzt RedPhone das Secure Real-Time Transport Protocol, dem AES als Kryptosystem zugrunde liegt. Whisper Systems bläßt da jetzt nicht viel heiße Luft raus, wie sicher so ein Telefonat nun ist, aber via RedPhone verschlüsselte Telefonate sollten nach Stand der Technik ohne weiteres kaum abhörbar sein.

Nicht registrierte Nummer, kann man über RedPhone nicht anrufen.

Nach der Installation der Anwendung über den Google Play Store müsst ihr eure Handy-Nummer einmalig bei RedPhone registrieren. Ähnlich wie etwa bei WhatsApp seid ihr so direkt über eure Handy-Nummer erreichbar, ohne dass ein Anrufer einen Account-Namen von euch benötigt.

Kleiner Tipp am Rande: Auf meinem Testgerät mit Android 4.1 Jelly Bean las RedPhone meiner Telefonnummer falsch aus dem System, es muss korrekt +49 179… und nicht +0049 179… heißen. Ändert daher die Nummer und entfernt die zwei Nullen vor dem Plus, sonst kann RedPhone keinen Account für euch generieren.

Das Telefonbuch sieht in RedPhone nicht viel anders aus, wie das normale Android-Adressbuch.

Die RedPhone-App liest das Telefonbuch aus den Android-Kontakten und die Telefon-Historie aus der Telefonie-App aus, innerhalb der Anwendung habt ihr daher Zugriff auf alle eure Kontakte, Nummern und Ruflisten. RedPhone-Gespräche sind allerdings nur zwischen registrierten Nummern möglich, versucht ihr eine fremde Nummer anzurufen, gibt euch die App entsprechend Bescheid.

Das Telefonat hier läut nicht über GSM, sondern wird von RedPhone verschlüsselt übertragen.

Ausgehende, wie auch eingehende RedPhone-Telefonate erscheinen so, als ob ein ganz normales Telefonat eintreffen würde, einzig das Freizeichen hört sich ein kleines bisschen anders an. Der einzige optische Hinweis ist der Balken mit “Checkup Supportive” unter dem Feld zum Auflegen und das kleine grüne Telefon in der Statuszeile.

Die Sprachqualität habe ich zwischen einem Handy, das über WLAN an einer 16Mbit-Leitung hing, und einem zweiten Androiden, das über UMTS Internetzugang hatte, getestet. Es war deutlich eine Latenz von etwa einer halben Sekunde und auch eine noch verbesserungsdürftige Echo-Unterdrückung zu spüren, doch das Gespräch an sich kam in ausreichender Qualität über die verschlüsselte Leitung.

Autor: Christoph

Hallo, ich bin Christoph -- Linux-User, Blogger und pragmatischer Fan freier Software. Wie Ihr ohne Zweifel bemerkt haben solltet schreibe ich hier über Linux im Allgemeinen, Ubuntu im Speziellen, sowie Android und andere Internet-Themen. Wenn du Freude an meinen Artikel gefunden haben solltest, dann kannst du mir über Facebook, Google+ oder Twitter oder natürlich dem Blog folgen.

23 Kommentare

  1. Pingback: Anonymous

  2. Pingback: Android-VoIP-Telefonate verschlüsselt mit Open-Source-App RedPhone | Linux | Laufen | Android| Nerd

  3. Ich teile deine Begeisterung über RedPhone.
    Nur noch ein kleiner ergänzender Hinweis: Die Worte “checkup” und “supportive” wurden aus dem Sitzungsschlüssel generiert und waren nur für diesen einen Anruf gültig. Die beiden Gesprächspartner können sich leicht vergewissern, dass an beiden Enden der Leitung das gleiche Wortpaar erscheint, und damit mit großer Sicherheit ausschließen, dass jemand mithört (“Man in the middle-Attack”).

    • > Die Worte “checkup” und “supportive” wurden
      > aus dem Sitzungsschlüssel generiert

      Bei einem man-in-the-middle-attack wären diese Schlüsselwörter also mit sehr großer Wahrscheinlichkeit anders, das ist die Sicherheit.
      Die Anrufenden sollten also zu Beginn des Gesprächs diese beiden Schlüsselwörter vergleichen, um solch einen Angriff auszuschließen.
      Demnach wäre der Server auch unwichtig.

  4. WhisperCore und WhisperFirewall verschlüsseln das System oder rüsten Firewalls nach, so dass Android gegen den Zugriff Unbefugter abgesichert wird.

    BND,MAD usw. lachen über sowas in der Kantine!!!

    • Ja gut Anonymous
      Schon möglich das BND, MAD usw. ohne Gehhilfen ala IMSI-Catcher etc. auskommen aber hast Du auch eine Alternative ?. Erzähl doch mal, von mir aus auch aus dem Nähkästchen. Ich glaube nämlich zu wissen wozu die Hornbrillenträger in der Lage sind und wozu nicht, aber ich lerne gern noch dazu. Mein RedPhone läuft übrigens über eigene Server und UDP-Tunnel…

      • Ich möchte gerne wissen, wie du das über einen eigenen Server und UDP-Tunnel hast laufen lassen… Kontaktmöglichkeit?

        • Hui, das ist jetzt schon eine Weile her. Ich lese diese Eleven Boarde nicht so häufig.
          Ja, ich kann mir vorstellen das Du das wissen möchtest aber…
          Ich vermiete entsprechende Accounts und von daher nur ein paar Hinweise. BND & Co. lachen nur deshalb über Redphone o.ä. weil Sie
          direkt oder auf dem Wege der “Amtshilfe” Zugriff auf die Server haben und die Keys manipulieren können. Den Algorithmus selbst haben Sie in aller Regel nicht geknackt. Der Quellcode von Redphone & Co. Liegt offen und den Rest kannst Du Dir sicher denken.

          • Es ist klar, dass Redphone, wenn das Unternehmen in DE sitzt, den Behörden bei Bedarf oder vermutlich auch nur so, Schnittstellen bieten muss.
            Den Server kann man aus dem Quellcode sicher leicht finden, aber ist die Serversoftware denn auch OpenSource?

            • Ja, leider ist das klar aber spätestens seit der TkÜV und Novellen eben nur den Fachleuten. Klar ist aber auch das unter dem Vorwand von Terrorismusbekämpfung o.ä. hier Unrecht per Gesetz legalisiert wird und seit der “NSA Affäre” wissen nun auch alle warum. Generell gilt, wer wert auf seine Privatsphäre legt oder seine Betriebs- und sonstige Geheimnisse schützen will braucht die komplette Kontrolle über seine Kommunikationswege. Die Ende zu Ende Verschlüsselung ist da nur ein Teil davon. So etwas muss im Übrigen nicht sehr teuer sein weil geeignete TK-Anlagen für kleine Anforderungen schon für wenig Geld zu haben sind.
              Für einen begrenzten Nutzerkreis modifiziere ich solche Systeme schon für 300,- Euro excl. Hardware. Da hat dann auch der NSA kaum noch Chancen, jedenfalls bin ich jederzeit bereit es darauf ankommen zu lassen denn die kochen auch nur mit Wasser.

              • Was denkst du denn darüber;

                Wäre es möglich, dass es durch direkten Zugriff auf Android/IOS Systeme der N*S*A o.ä. möglich wäre, diese verschlüsselten P2P-Telefonate abzuhören oder reicht das nicht, um die Schlüssel zu finden?

                Außerdem, wie erreicht man dich für die Aufsetzung von so einem Server :)

  5. Die Verschlüsselung bei Redphone steht und fällt, wenn ich das richtig verstehe, mit dem Master Server. Wenn man den nicht kennt, nicht weiß wo der steht usw., dann ist doch über die Sicherheit rein gar nichts bekannt, oder?

  6. Ich sehe das genau so, die app könnte dann sicher werden, wenn auch die Funktion des dazu gehörenden Servers offengelegt wird bzw. opensource ist. Die app redphone sollte eine eigene schlüsselverwaltung & serverfunktion bereitstellen in der man eine eigene Authentifizierungliste der Gesprächspartner anlegen kann . Eine richtige ende zu ende verschlüsselung ist dann gegeben, wenn ich auch herr des servers bin. andefalls kann der fremdverschlüsselte datenstrom abgefangen, repliziert und entschlüsselt werden.
    oder gibt es bereits diese funktionen?

  7. Entschuldigung, aber mir scheint, dass zumindest die letzten drei Kommentare (d.h. alle seit Juni) nicht berücksichtigen, was End-to-end-Verschlüsselung bedeutet. Der Witz dabei ist ja gerade, dass es “trustless” hinsichtlich des Übertragungswegs ist. Beliebige Teile des Übertragungswegs können komprimiert sein, aber da die Ver- und Entschlüsselung sowie die Verifizierung der Schlüssel lokal auf den Geräten von Sender und Empfänger stattfindet, ist die Kommunikation trotzdem sicher. Das ist der Witz an Systemen wie OpenPGP oder eben auch RedPhone. Aus vielen Gründen. Wenn z.B. sichere verschlüsselte Emails nur über spezielle vertrauenswürdige Mailservern gesendet und empfangen werden könnten, würde das nie skalieren. Hinzu kommt, dass ich kaum die Vertrauenswürdigkeit eines fremden Mailservers beurteilen kann, selbst wenn mir (wie im letzten Kommentar vorgeschlagen) der Quellcode gezeigt wird, der (angeblich!) auf diesem Server ausgeführt wird.

    • Mittlerweile hatte ich auch schon auf github nachgeschaut und -gefragt wg. dem Server Quelltext:

      https://github.com/WhisperSystems/RedPhone/issues/63#issuecomment-21199986

      Der ist zwar (noch) nicht erhältlich, aber anscheinend ist der Kommentar von Anonymous vom 17. Mai 2013 um 00:34 Uhr (und meiner dann natürlich auch) nicht qualifiziert, der Server tut nur durchleiten und kann nichts verunsichern.

      Was mir nicht klar ist bei RedPhone, aber das kann ich noch dort nachlesen, wie findet der Schlüsselaustausch beim ersten Mal statt, kann sich da kein Mann-in-der-Mitte (oder eine Behörde) dazwischen schalten?

      • Selbst beantwortet:
        Durch die RedPhone Software bestimmt, kann ein MITM Angriff mit sehr hoher Wahrscheinlichkeit nicht die selben Schlüsselwörter (die bei Verbindungsbeginn im Display angezeigt werden, s.o.) generieren, was die Garantie ist, dass die Verbindung Ende-zu-Ende verschlüsselt sein muss.

        Ein berechtigter Einwand (Kommentar) auf github ist allerdings, dass durch die Registrierung der Telefonnummern durch RedPhone zwar keine Inhalte, aber doch durchaus die Verkehrsdaten (wer mit wem wie lange?) vom Server abgegriffen werden könnten.
        Das könnte man somit mit einem eigenen Server schon ausschließen, sofern man ihn aufsetzen könnte, wenn man denn den Code überhaupt einst bekäme.

        Das muss man natürlich berücksichtigen.

    • Gut, ganz so einfach ist es nicht. Eine genügend große Schlüssellänge gilt sicher gegen Brutforce Attacken aber Tatsache ist das schon der zweite Versuch ein Treffer sein kann, wir reden hier also über Wahrscheinlichkeiten. Die Wahrscheinlichkeit das von einem okkupiertem System aus der Schlüssel auf einem Endgerät kompromittiert wird ist ungleich NULL, ganz abgesehen davon das die Verbindungsdaten nachvollziehbar werden. Dazu kommt die Möglichkeit auch verschlüsselte Übertragungen mit zu schneiden um Sie ggf. später verwerten zu können, falls der Code mal geknackt wird. Außerdem gibt es da noch so ein paar Verfahren deren Erläuterung hier zu weit führen würde. Mit der Kontrolle des Übertragungsweges fallen alle diese Szenarien weg und das deklassiert alle Provider gebundenen Systeme, ohne Ausnahme.

  8. Das Problem sind die Verkehrsdaten. Denn mit der Preisgabe der Telefonnummer gibt es keine Anonymität. Und das Speichern der Verkehrsdaten regelt das Gesetz.

    Das Nächste was ich mich stets frage ist, wie ist das Geschäftsmodell des Anbieters. Dieses wiederum kann man seit dem Kauf durch Twitter erahnen. Was dann auch das Interesse an der Telefonnummer erklärt.

  9. Wo steht eigentlich der Server von Redphone, oder der Switch, wie die ihn selbst bezeichnen?
    Falls er in den USA steht, dürfte es mittlerweile ja klar sein, dass dank des FISC weder Sicherheit noch Ehrlichkeit der Betreiber zu diesen Thema zu erwarten sind.

    • Ich habe mal im Quellcode gesucht und in der Datei: src/org/thoughtcrime/redphone/Release.java die Serveradressen gefunden:

      public static final String SERVER_ROOT = “.whispersystems.org”;
      public static final String MASTER_SERVER_HOST = “master.whispersystems.org”;
      public static final String RELAY_SERVER_HOST = “relay.whispersystems.org”;
      public static final String DATA_COLLECTION_SERVER_HOST = “redphone-call-metrics.herokuapp.com”;
      public static final int SERVER_PORT = 31337;

      Laut Central Ops ist der whispersystems.org auf den Kanaren.
      Der herokuapp.com allerdings in Kalifornien (U/NSA).
      Dieser “DATA_COLLECTION_SERVER_HOST” kommt dann in …/monitor/Uploader.java zum Einsatz, dort werden laut Quelltext Daten über die Verbindungsqualität (“Uploads call quality data to the statistics server”) zu diesem Server hochgeladen.
      Ich vermute aber, dass man das mit den Einstellungen von RedPhone unter Analyseeinstellungen deaktivieren kann.

      Ich kenne die spanischen Überwachungsgesetze zwar nicht, aber so schlimm wie in GB oder U/NSA können sie nicht sein ;)

  10. Also ich habe RedPhone zwischen einem Galaxy S3 und einem Huawei Y300 bisher nur im selben WLAN nutzen können.
    Eine Seite war Telekom über DSL – andere Seite war Kabel-BW mit 12 Mbit down und 0,38 Mbit im Upstream…
    Auf beiden Seiten eine Fritzbox – aktueller Stand! –
    und trotzdem war das Ergebnis richtig fürchterlich! – verzerrte und verlangsamte Stimmen usw.

    Möglich auch, daß Kabel-BW VOIP blockiert!?? – Wer weiss da was?

    Eine Mail an den Support von wispersystems wurde leider bisher nicht beantwortet.

    po

  11. Moin,

    gestern mit derselben Gerätekombi in zwei verschiedenen Wlans über einmal Kabel D und einem DSL-Anbieter telephoniert. Gesprächspartner waren ordentlich zu hören, aber nocht weit weg von einer guten Gesprächsqualität. Der Aufbau der Verbindung hat auch ein bischen gedauert. Also bei Kabel D sehe ich kein Anzeichen dafür, dass Voip irgendwie anders priorisiert wird.

    Gruß
    Daniel

Hinterlasse eine Antwort

Auf Linux und Ich darf anonym kommentiert werden. Die Felder für Name und E-Mail-Adresse dürfen beim Eintragen eures Kommentars leer bleiben. Ich freue mich aber über jeden Kommentar, zu dem der Autor mit seinem Namen steht.