[FREE][APP][2.3+] Secret Tidings - Versteckte Botschaften

  • Vor dem Hintergrund der ganzen Diskussion um Privatsphäre habe ich mal eine Steganographieanwendung entwickelt. Verschlüsselte Nachrichten wecken den Argwohn von Angreifern, also hat man seit je her versucht Botschaften so zu verstecken, dass nur Eingeweihte diese lesen können.


    Das Tool hierfür ist Secret Tidings und ist im Google Play Store verfügbar.


    [Blockierte Grafik: https://developer.android.com/images/brand/en_generic_rgb_wo_60.png]



    Mit diesem Tool kann man Text und beliebige Datei-Anhänge in unverfänglichen Bildern verstecken. Diese Bilder per Email oder Sozialen Netzwerken teilen und ein eingeweihter Empfänger kann diese Nachrichten wieder hervorholen.



    Und so funktioniert das Prinzip der versteckten Nachrichtenübermittlung.


    [Blockierte Grafik: http://imageshack.us/a/img28/3540/fgd5.png]

  • Klingt spannend.
    Hast du als Datenformat für die Bilder auch BMP genutzt, oder unterstützt du auch andere Bildformate?

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Die versteckten Nachrichten werden im PNG-Dateiformat gespeichert. Es ist möglich beliebige Bildformate zu importieren, z.B. JPEG-Dateien direkt von der Kamera. Das Tool konvertiert die Bilder dann automatisch in das richtige Format.

  • Klingt wirklich cool. :)
    Schöner Spielkram. Ich wüsste grad nur nicht, wem ich damit Nachrichten schicken sollte. Aber ich probier's definitiv mal aus.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Ja, finde ich interessant (auch wenn das Verfahren nicht wirklich neu ist und als digitales Wasserzeichen schon lange verwendet wird).
    Was mir noch nicht klar ist, wie das insgesamt abgesichert ist.


    Ist das z.B. Open Source, damit ich prüfen kann was da eigentlich passiert und ob das Verfahren auch wirklich sicher ist?


    Und kann ich das z.B. mit einem nur mir und dem Empfänger bekannten Schlüssel irgendwie so verändern, dass nur wir beide die Daten extrahieren können falls das Bild irgendwie öffentlich wird?

  • Es besteht die Möglichkeit einen individuellen Schlüssel zu vergeben.


    Der Empfänger der Nachricht muss diesen Schlüssel dann kennen, andernfalls besteht für ihn oder Dritte keine Möglichkeit die Nachricht zu lesen.


    Ok, aber ist es Open Source so dass ich prüfen kann was genau passiert? D.h. was mich umtreibt ist die Frage woher ich weiß, dass der Schlüssel überhaupt und korrekt verwendet wird? Mit 3 Beispielübertragungen geht das vermutlich nicht... Und warum sollte man Dir (als Black-Box-Programmierer) mehr vertrauen als irgendjemand sonst?

  • Meine Meinung soweit:


    + Im Großen und Ganzen tut die App genau was sie soll. Sehr solide. :)


    - Beim Tippen der Nachricht wurde oftmals die Anzeige nach oben verschoben (meist bei einem Zeilenumbruch), so dass ich nicht mehr sehen konnte was ich bereits geschrieben hatte.


    - Die Auswahl im ersten Screen finde ich ein bisschen seltsam gelöst. Mag aber Gewohnheit sein.


    ---


    Und noch meine ganz persönliche Note dazu:


    - Ich HASSE Passwortabfragen. Damit abstrahierst du nur das ursprüngliche Problem: jemand öffnet das Bild in deiner App und kennt das Passwort nicht.
    Mit der App kannst du also folgendes tun:
    • du findest heraus, ob ein Bild verschlüsselten Kontent enthält
    • du bekommst so lange den Hinweis 'falsches Kennwort', bis du das richtige Kennwort eingibst


    Im Prinzip hast du also nur das Problem des 'verschlüsselten Containers' von einem Ordner/Zip/PDF in ein Bild gepackt.


    Damals™ hatte ich auf meinem Sony Ericsson Z610 eine App names 'Datentresor', die einen gänzlich anderen Ansatz verfolgte. Du hast deine Daten mit einem vierstelligen Zahlenpin 'verschlüsselt'.


    Beispielsweise hast du deinen Eintrag 'Kreditkartennummer' mit Inhalt 5467 7897912 3123 mit der PIN 4711 verschlüsselt.
    Wenn jetzt jemand hin ging, die App öffnete und 'Kreditkartennummer' anwählt, wird er nach der PIN gefragt. Gibt er 0815 ein, dann rödelt das Programm eine Weile und spuckt dir beispielsweise 0912 7953721 0931 aus. Und mit 1337 rödelt er wieder und liefert 1254 9873893 8893 zurück. Nur mit 4711 kommt wirklich 5467 7897912 3123 dabei raus.


    So etwas finde ich cooler. Klar, jeder Depp erkennt, dass 0912 oder 1254 keine gültigen Kreditkartennummern sind. Bei anderen Daten wie beispielsweise deinem Rechnerkennwort, deiner Geldkarten-PIN oder deiner geheimen Antwort zur Kennwortzurücksetzung bei PayPal ist das nicht so offensichtlich.
    Merke: viele nutzlose Informationen sind ein wesentlich besserer Schutz als wenige nützliche Informationen. (Und 'Falsche PIN' ist eine nützliche Information.)


    So hättest du 9.999 falsche und 1 richtige Information. Beim Hinweis mit dem Passwort hast du im schlechtesten Fall 9.999 nützliche und eine richtige Information.
    Schlimmer noch: dank der nützlichen Information weißt du ganz genau, welche die richtige Information ist.


    Also als Feature Request:
    * lass die App SÄMTLICHE unterstützten Bilder öffnen, egal ob mit verschleiertem Inhalt oder nicht. Es wird lustig, wenn Hacker versuchen Nachrichten in Bildern zu finden, die keine enthalten.


    * Nutze an Stelle eines Kennwortes (welches sicherlich irgendwo in den gespeicherten Daten im Bild stehen wird) lieber eine PIN, die du nicht mit hineinschiebst. Denk dir zu jeder möglichen PIN-Eingabe (sind ja bloß 10.000...) einen Verschiebemodus aus. (Keine Ahnung: 0123 = 1. Zeichen 10 Bit weiter, 2. Zeichen 1 Bit weiter, 3. Zeichen 2 Byte weiter, 4. Zeichen 3 Bit weiter und von vorn).
    Dann baust du beim Verschlüsseln die Eingabe entsprechend um und sie sind nicht mehr aus dem reinen Bild extrahierbar. Beim Entschlüsseln drehst du einfach die Richtung je nach Eingabe und zeigst es an. Dann schleppst du das Kennwort auch nicht mehr in der Datei mit.
    (Denn merke: Hacker haben die Angewohnheit, erst einmal alles durch einen Hex-Editor laufen zu lassen. Und wenn die dann ein Muster finden haben sie nicht nur den Inhalt sondern auch das Kennwort.)
    Natürlich kannst du den Algorithmus verkomplexidieren. Also wenn Position 1 = 0 dann 10 weiter, Position 2 = 0 wären 5 zurück, Position 3 = 0 wären 10 zurück und Position 4 = 0 wären 3 weiter...
    Oder Position 1 gibt an in welchem Bit die Daten stehen (auf 4 runterbrechen), Position 2 die Verschiebung des ersten eingegebenen Zeichens, Position 3 die Verschiebung aller geraden Zeichen gemessen an der Startverschiebung und Position 4 die Verschiebung aller ungeraden Zeichen gemessen an dieser Startverschiebung.
    Wichtig ist in dem Fall nur, dass du das vernünftig hin und her geschoben bekommst.


    ---


    Soviel zur Kritik.
    Die Interaktion mit den Austauschmöglichkeiten Alben/Kamera/Dateisystem/Dropbox finde ich astrein gelöst. Gefällt mir wirklich gut. :)


    [hns]
    Ich fürchte eine Offenlegung des Codes wäre nicht so toll. Man würde sehen, an welcher Position das Kennwort gespeichert ist, ob und wo Infos über die Art der Verschlüsselung gespeichert sind und in welchem Bit die Infos stehen. Damit könnte man dann auch problemlos wenigstens die Kennwörter solcher Bilder erschnüffeln oder unter Umgehung dieser 'Sicherheitsmaßnahmen' ein eigenes Entschlüsselungstool verbreiten.


    Wenn der Inhalt dieses Bildes hier rauskommt sitz' ich vermutlich im Knast. ;)
    Allerdings habe ich mein eigenes Kennwort vergessen, insofern... ^^


    // Nachtrag: Och, obwohl das Ding so arg verkleinert wurde ist der Zerg Creep immer noch gut zu erkennen. Na denn. =)

  • Ok, aber ist es Open Source so dass ich prüfen kann was genau passiert? D.h. was mich umtreibt ist die Frage woher ich weiß, dass der Schlüssel überhaupt und korrekt verwendet wird? Mit 3 Beispielübertragungen geht das vermutlich nicht... Und warum sollte man Dir (als Black-Box-Programmierer) mehr vertrauen als irgendjemand sonst?


    Die App ist Closed Source. Ich kann dir aber versichern das ich 15 Jahre Programmiererfahrung besitze und bei der Entwicklung der App die Sicherheit eine große Rolle gespielt hat. Closed Source bedeuted nicht automatisch Security through obscurity.



    * Nutze an Stelle eines Kennwortes (welches sicherlich irgendwo in den gespeicherten Daten im Bild stehen wird) lieber eine PIN, die du nicht mit hineinschiebst.


    Zu deiner Kritik bezüglich der Passwortsicherheit muss ich folgendes Klarstellen:


    Im Bild wird weder das Passwort, noch ein Passwort-Hash gespeichert. Es sind auch keine Muster in den Binärdaten zu erkennen die auf den Inhalt der ursprünglichen Nachricht schließen lassen würden.



    - Beim Tippen der Nachricht wurde oftmals die Anzeige nach oben verschoben (meist bei einem Zeilenumbruch), so dass ich nicht mehr sehen konnte was ich bereits geschrieben hatte.


    Wenn du beim tippen der Nachricht den Text nicht mehr siehst müsstest du ihn eigentlich mit einer Wischgeste wieder nach unten scrollen können. Hat das nicht funktionert? Alternativ kannst du das Telefon auch drehen, dann wird auf meinem Telefon die Hälfte der Bildschirmhöhe für den Text reserviert.



    Vielen Dank für dein ausführliches Feedback.


  • Die App ist Closed Source. Ich kann dir aber versichern das ich 15 Jahre Programmiererfahrung besitze und bei der Entwicklung der App die Sicherheit eine große Rolle gespielt hat. Closed Source bedeuted nicht automatisch Security through obscurity..


    Nix gegen Deine Erfahrung, aber es hat auch schon Programme gegeben wo Leute erst nach 30 Jahren einen Fehler entdeckt haben. Und auch ich mache nach vielen Jahren noch Fehler, d.h. kann nicht garantieren, dass ich den Algorithmus wirklich 100% verstehe und vor allem fehlerfrei implementiere. Dafür gibt es dann eine Qualitätskontrolle.
    Zum Einwand von Lucas de Vil: Auch Verschlüsselungsalgorithmen können völlig offengelegt sein. Z.B. ist ja bekannt wie DES oder RSA gehen. Und es gibt sogar Open-Source-Versionen. Der Trick der Sicherheit liegt dann doch darin, dass man die Umkehrung einfach nicht berechnen kann, außer wenn man den richtigen Schlüssel kennt.
    Bei einem PNG-Bild könnte man z.B. die einzelnen Bits nacheinander in den niederwertigsten Bits von Pixeln verstecken. Aber die Sequenz der Pixel-Koordinaten vom Schlüssel abhängig machen. Z.B. wenn die Pin 1234 ist, dann wird z.B. mit Pixel n=1234 angefangen. Dann kommt z.B. n := (2*n + 1) % zahl-der-pixel. Oder etwas komplizierteres (z.B. der Schlüssel einmal mit sich selber durch DES gedreht). Der Algorithmus wäre offen und wenn der Code auch noch offen ist, dann könnte man nachschauen ob ein Implementierungsfehler vorliegt. Dennoch würde der Schlüssel selbst nicht gespeichert bzw. kann nicht (einfach) herausgefunden werden. Außer der hier beschriebene Algorithmus taugt nichts und verrät (z.B. über statistische Eigenschaften) wo der Schlüssel anfängt.


  • Bei einem PNG-Bild könnte man z.B. die einzelnen Bits nacheinander in den niederwertigsten Bits von Pixeln verstecken. Aber die Sequenz der Pixel-Koordinaten vom Schlüssel abhängig machen.


    Ein solcher Algorithmus wäre anfällig für Implementierungsfehler. Besser ist es einen offengelegten Standard-Algorithmus zu verwenden. Genau das bietet meine App selbst wenn sie Closed Source ist.



    Dennoch würde der Schlüssel selbst nicht gespeichert bzw. kann nicht (einfach) herausgefunden werden.


    Wie ich weiter oben schon geschrieben habe wird der Schlüssel nicht im Bild gespeichert

  • Hoi,


    man kann sich jetzt drüber streiten wie vertrauenswürdig und sicher man dich ein stuft, darauf will ich jetzt grad mal nicht hinaus ;)


    Was ich mich grad so spontan frag ist, wie der mobile Datenverbrauch aus sieht. Jede Nachricht ist ein Bild wenn ich das richtig verstehe, ist also um ein Vielfaches größer als der Klartext. Kannst du mal das ein oder andere Wort darüber verlieren? ;)


    Zum Anderen bin ich was Verschlüsselung angeht durchaus etwas unerfahren, jedoch gibt es bei diversen Verfahren ja das Problem des Shared Secrets, das man dem Partner ja erstmal irgendwie mitteilen muss. Ist genau der Punkt dein großes Geheimnis oder kannst du auch darüber mal was erzählen?



    Gruß,
    Matze


  • Was ich mich grad so spontan frag ist, wie der mobile Datenverbrauch aus sieht. Jede Nachricht ist ein Bild wenn ich das richtig verstehe, ist also um ein Vielfaches größer als der Klartext. Kannst du mal das ein oder andere Wort darüber verlieren? ;)


    Die importierten Bilder werden entsprechend der Nachrichtenlänge automatisch verkleinert um den Datenverbrauch in Grenzen zu halten.
    Damit die Bilder bei sehr kurzen Nachrichten nicht nur noch 3x3 Pixel groß sind, beträgt die minimale Bildgröße 100x100 Pixel, das entspricht einer Dateigröße von etwa 20 KB. Damit habe ich versucht einen Kompromiss zwischen Bildgröße und Datenverbrauch zu schaffen. Evtl. biete ich noch eine Option an um die minimale Bildgröße anzupassen.


    Die Daten werden im LSB der RGB-Kanäle gespeichert, d.h pro Pixel können 3 Bit gespeichert werden.
    Der Alpha Kanal eignet sich nicht zum verstecken von Daten wenn ein Trägerbild ohne Transparenz verwendet wird und wir daher nicht zum verstecken der Daten benutzt.



    Die Nachricht wird UTF-16 codiert und verbraucht somit pro Zeichen 2 bis 4 Byte. Zusäzlich gibt es 100 Byte Protokoll Overhead sowie einen gewissen Overhead durch Byte Padding, da die Nachricht in Chunks geteilt wird um auch auf Geräten mit wenig Speicher Stück für Stück sicher ausgelesen werden zu können.


    Bei einer Bildgröße von 100x100 Pixel kann die Nachricht ungefähr 750 bis 1500 Zeichen enthalten.

  • Ich hoffe, du benutzt nicht die SecureRandom Klasse von Android.


    Genau solche Themen sind es, warum ich nach Open Source frage...
    Dann kann man immerhin selber reinschauen und sich eine Meinung bilden ob man der Software (in diesem Fall sogar Programm + Systemfunktionen) vertrauen will oder nicht.
    Das hat auch nichts mit Mißtrauen gegenüber dem Autor zu tun, sondern mit Lebenserfahrung, dass selbst der allerbeste Wille und die allerbesten Absichten nicht ausreichen um 100% Perfektion zu erreichen.

  • Ich hoffe, du benutzt nicht die SecureRandom Klasse von Android.
    http://www.heise.de/security/m…droid-Patzer-1933714.html


    Ich benutze SecureRandom nicht direkt zur Schlüsselerstellung, allerdings wird es zum salzen verwendet.


    Da die Java PRNG's ja offentsichtlich mehr Löcher als ein Schweizer Käse haben, benutze ich jetzt /dev/urandom stattdessen. Ich habe ein Update in den Play Store hochgeladen.


    Hier ist ein interessanter Artikel über die Schwächen der Zufallsgeneratoren in Java:


    http://armoredbarista.blogspot…d-weaknesses-in-java.html


    Den offiziellen Patch-Source Code findet ihr hier:


    http://android-developers.blog…ecurerandom-thoughts.html

  • Secret Tidings 2.0 ist verfügbar


    Bilder die versteckte Nachrichten enthalten können jetzt noch leichter geteilt werden. Es ist möglich die Bilder direkt mit Picasa, Hangouts, Google+ usw. zu teilen oder wie bisher das Bild per eMail zu verschicken. Weiterhin wurden Probleme mit transparenten Bildern behoben.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!