Crypto Challenge #1 - Neues Loader Containerformat

Dieses Thema im Forum "Kontest" wurde erstellt von N0S, 2. Januar 2013 .

  1. 2. Januar 2013
    Neues Containerformat für einen FTP/HTTP Leecher. (Wer es nicht kennt: Schaut euch den SFT Loader an SFT Loader und SFT Encrypter)

    Allgemein:
    • Alle Programmiersprachen sind grundsätzlich erlaubt.
    • Erwartet wird eine beispielhafte Implementierung eines Encrypter und Decrypter. Der sollte Open-Source gemacht werden.
    • Crypto-Libs sind erlaubt
    • Beliebig viele asymmetrische/symmetrische Verschlüsselungsverfahren oder Hashverfahren sind erlaubt.
    • Überlegt euch ein Sicherheitskonzept, wie kann man eueren Code so absichern, dass es keiner nachmachen kann, wenn er wirklich produktiv eingesetzt werden soll? Der beispielhafte Prototyp muss natürlich noch nicht so abgesichert sein. Das Open-Source machen einer beispielhaften Implementierung sollte eurem Containerformat grundsätzlich nicht schaden.

    Anforderungen:
    • Beliebig viele FTP Links speicherbar mit folgenden Informationen: Benutzername, Passwort, Port, Domain/IP, Pfad, Datei, SSL erlaubt/zwingend, SSL Typ, Active möglich, Passive möglich
    • Beliebig viele HTTP Links speicherbar mit folgenden Informationen: Benutzername, Passwort, Port, Domain/IP, Pfad, Datei, SSL erlaubt/zwingend, SSL Typ
    • Sonstige Informationen speichern, überlegt was noch sinnvoll sein kann.
    • Benutzer kann die Container-Datei mit einem Passwort schützen. Bruteforce sollte die einzige Möglichkeit sein an das Passwort zu kommen. Bruteforce sollte aber nahezu unmöglich sein, entweder weil die Geschwindigkeit zu niedrig ist oder weil der Key viel zu lang ist.
    • Das Format sollte möglichst unabhängig von der Programmiersprache sein, d. h. keine Objekt-Serialisierung (z. B. java.io.Serializable).
    • Möglichst klein, Kompression?
    • Wenn euch irgendetwas noch einfällt, kann das gerne berücksichtigt werden.



    Der späteste Abgabetermin ist der Sonntag am 27.01.2013.

    Am Ende wird es einen Gewinner geben. Das beste Containerformat gewinnt. Jede Lösung soll in einen neuen Thread gepostet werden. Dadurch können mögliche Schwächen/Stärken diskutiert werden und das beste Format hat folgende Eigenschaften:
    - Am wenigsten Schwächen
    - Erfüllt mindestens alle genannten Anforderungen

    Die Programmiersprache kann natürlich eine Schwäche sein. Bytecode Programmiersprachen können trotzdem gewinnen, wenn ein gutes Sicherheitskonzept vorliegt.
     
  2. 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat



    Man sollte also auf alles verzichten, dass es maßgeblich erschwert die eigene Lösung in eine andere Sprache zu übersetzen?
     
  3. 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Nette Aufgabe auch wenn mir für die Teilname komplett die Grundlagen fehlen. Eine Frage hätte ich jedoch. Gibt es grundsätzliche Ansätze um eine Open Source Verschlüsselung abzusichern? Wenn ich überlege dass eine Zeichenkette mit einem (a)symmetrischen Schlüsselsatz gesichert ist und ich das Verfahren kenne, sollte es dann nicht immer möglich sein die Keys aus der exe zu extrahieren? Natürlich kann man die via PE Crypting/Obfuscating "verstecken" aber es muss sich ja nur eine fähige Person mal hinsetzten und der Key kommt trotzdem irgendwie raus und man kann sich nen decrypter bauen.
     
  4. 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Versteh ich nicht? Aber ja sollte sprachunabhängig sein. Der SFT Loader benutzt Delphi Serialisierung. Ich finde das er dadurch nicht schwerer oder leichter zu knacken ist. Weil ein Angreifer ja auch einfach Delphi benutzen kann.
    Vorteil ist eben, dass der Encrypter und Decrypter jeweils in einer anderen Sprache sein könnte. Muss ja nicht so sein... Stichwort auch Plattformunabhängigkeit :-D

    ja also das Problem ist immer, dass irgendetwas geheim bleiben muss. Letztendlich muss man klug wählen was das Geheimnis sein soll. Einfach AES mit einem einfachen geheimen Schlüssel ist natürlich bisschen zu billig. Wie das Geheimnis grundsätzlich aussehen sollte bzw. wie es abgesichert sein sollte, erwarte ich dann in einem "Sicherheitskonzept".
     
    1 Person gefällt das.
  5. 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Warum sollten Programmiersprachen mit Bytecode eine Schwäche sein, wenn das Teil eh open-source ist?
     
  6. 2. Januar 2013
    Zuletzt bearbeitet: 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Das Problem ist halt, dass man so was vom Konzept her nicht sicher gestalten kann. Verstehe nicht wie man da am Ende die Sicherheit bewerten soll. Security through obscurity und Open Source beißen sich da ja schon ein wenig

    Ich sehe den Sinn darin nicht 1000 Verschlüsselungs-Algorithmen zu stacken (und darauf wird es in irgendeiner Form hinauslaufen).
     
  7. 2. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Coole Aufgabe, 2-3 Ideen hätte ich auch schon, aber leider fehlt mir dieses Mal wirklich die Zeit. Deswegen werde ich definitiv nichts einreichen.

    Bin aber gespannt auf die Lösungen
     
  8. 3. Januar 2013
    Zuletzt bearbeitet: 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Beißt sich eine Referenzimplementierung eines Open-Source En/Decrypters nicht mit der "Sicherheit" des Formats? Oder sollen hier nur Konzepte gesammelt werden?

    Nicht falsch verstehen, die Idee an sich finde ich super, auch wenn ich nicht den nötigen Skill habe aktiv daran teilzunehmen.
     
  9. 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    ja klar, aber die Referenzimplementierung soll schon sicher sein, aber noch nicht perfekt abgesichert. Letztendlich muss es ja closed source sein, aber wenn es gut ist, sollte eine open-source Referenzimplementierung nicht schaden. Geht ja auch um die Demonstration des Formats an sich.

    Das spannende an der Aufgabe sind doch die Ideen. Man muss nur eine gute Idee haben. Besser als das SFT Format wird es bestimmt auf jeden Fall. Das Problem bei SFT ist auch, dass man das Benutzerpasswort leicht mit sehr hoher Geschwindigkeit bruteforcen kann.
     
  10. 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Ich werde wohl was kleines machen, und da es Open Source sein soll lege ich den Schwerpunkt auf Passwort Sicherheit, ich denke alles andere macht wenig Sinn.

    Mfg Rushh0ur
     
  11. 3. Januar 2013
    Zuletzt bearbeitet: 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Ich frage mich ob es so sinnvoll ist jeden Teilnehmer blind programmieren zu lassen für einen Container, der nichtmal ordentlich besprochen wurde. Wieso wird hier nicht erstmal darüber diskutiert, wie dieser auszusehen hat und wie man ihn so sicher wie nur möglich gestalten kann (ggf. auch den Zugriff auf diesen)? Zumal ich sowieso bedenken habe: Richtig sicher wird ein Container nie sein, d.h. wie weit soll das gehen?

    Trotzdem viel Spaß beim Contest. Vielleicht kommt ja etwas sinnvolles dabei heraus.

    PS: Hab das Thema mal angepinnt.
     
  12. 3. Januar 2013
    Zuletzt bearbeitet: 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Verstehe ich dass richtig: Für den Endbenutzer soll es ohne entsprechnden Client aber MIT dem Passwort des Containers, möglichst schwer sein die Links im Klartext auszulesen? (Bzw.: Er muss auf einen existierenden Client zurückgreifen da die Implementierung "geheim" ist?) - Also so wie es bei den ganzen exisiterenden Formaten sowieso schon der Fall ist? (sei es SFT, DLC, RSDF oder CCF)

    // Edit: Oder sind auch Ansätze erlaubt wie es für das DLC 2 Format mal vorgesehen war?
    // Edit 2: Ist es auch erlaubt eine Trusted Thrid Party in Form eines Servers einzuführen?
     
  13. 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    ja genau so. Möglichst ohne Server.


    Vielleicht sollte man die Aufgabe in Teile zerlegen:

    1) Containerformat entwickeln ohne Verschlüsselung/Sicherheit. Allein hier kann man doch schon viel falsch oder richtig machen. Header? Kompression? Integrität prüfen? usw.

    2) Einfache Absicherung. Eine symmetrische Verschlüsselung braucht man wohl auf jeden Fall. Diese muss man natürlich nicht selber entwickeln. Crypo-Lib nehmen...

    3) Benutzerpasswort erlauben. Ideen?? Bruteforce sicher? Auch ein 5-stelliges Passwort soll ausreichend Sicherheit bieten.

    4) Decrypter und Encrypter in 2 separate ausführbare Dateien? Fehler des SFT Loaders: Encrypter und Decrypter haben die gleiche Implementierung, zwei unterschiedliche exe Dateien, ein Angreifer hat die Wahl, welche EXE er angreift. Man nimmt natürlich die leichtere? Lösung mit asymmetrische Verschlüsselung denkbar?

    5) ..........

    irgendwann ganz am ende kommt dann

    6) Ideen zur Absicherung des Geheimnisses. Vielleicht gibt es mehrere Geheimnisse, die ein Angreifer rausfinden muss? Was soll geheim bleiben? Worst-case: Programmiersprache bietet Angriffsmöglichkeiten mit Decompiler? http://java.decompiler.free.fr/ ILSpy wie verhindern?


    Es gibt hier keine perfekte Lösung. Alles kann irgendwie umgangen werden. Aber genau deshalb ist die Aufgabe so spannend. Es geht hier um Ideen für ein Problem das keine perfekte Lösung hat.
     
  14. 3. Januar 2013
    Zuletzt bearbeitet: 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    War auch mein erster Gedanke. Ist aber auch relativ leicht auszuhebeln.

    Warum?
     
  15. 3. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Na gut, Server wäre auch OK. Braucht aber auch eine gute Idee. Die ganze Encryption/Decryption auf den Server auszulagern ist wohl nicht gut. Ziel wäre da möglichst wenig zu übertragen.
     
  16. 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    es wäre aber noch zu gewährleisten das wenn der server off genommen wird keiner im Dunklen steht
     
  17. 4. Januar 2013
    Zuletzt bearbeitet: 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Nur mal als Einwand:

    Warum ein komplett neues Format?

    Wieso nicht einfach ein AES-512 verschlüsseltes Tarball mit nem salted-pw-hash?

    Da hast dann ne binary mit nem array drin oder noch einfacher, ein textfile.

    Um das PW zu verschlüsseln haben dann der De- und Encrypter noch eine interne Zeichenfolge, um welche dieses erweitert wird.
    Und klar, wenn man den Quellcode hat, kann man es immer umgehen.
     
  18. 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Die Daten im Container sollen geheim bleiben selbst wenn der Benutzer das Passwort hat. Daher sollte der Container nur sehr schwer zu reversen sein.

    Ein statischer salt ist daher zu einfach.
     
  19. 4. Januar 2013
    Zuletzt bearbeitet: 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Und ein fester, nicht öffentlicher Postfix der an das UserPW angehängt wird?

    Dann gibt der User nur ein Teilpasswort weiter ohne es zu wissen.

    Den Postfix hat natürlich der De- und Encrypter.

    Ich weiss, das ist was du meinst, aber solange der Quelltext nicht bekannt ist, kannst du nur mit dem rohen container rein gar nichts anfangen.

    //edit:

    Bleibt nur das Problem, dass die Dateien irgendwo hin entpackt werden müssen. Ohne kurzzeitiges Zwischenspeichern im Temp geht leider nicht,,
     
  20. 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Sorry wenn ich mal dazwischen Frage, bin da Unwissend aber neugierig^^, wenn der Decrypter Open Source ist wie soll man verhindern das der Decrypter dann nicht einfach verwendet wird zum Ausgeben der Daten ohne Verschlüsselung?

    Oder geht es jetzt nur darum das man einen Container hat und ein Passwort aber nicht weiß das er zu dem Decrypter gehört und an Hand der Datei man auch nicht herausfinden soll das es sich um eine solche Datei handelt?


    (vielleicht stehe ich gerade auf dem Schlauch ?( )
     
  21. 4. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    -----------------

    Ja, ich hatte da auch eher an ein Netzwerk gedacht welches nicht einen SPOF hat. Vielleicht können andere Benutzer die Rolle des "Servers" übernehmen (P2P - wobei es da dann Probleme mit IP Adressen/Datenschutz geben würde) - Ich überlege noch
     
  22. 5. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Also ich verstehe auch nicht wirklich den Sinn, hinter der ganzen Sache.
    Wenn der De- und Encrypter opensource ist, dann kommt man doch immer in das was drin gespeichert ist, weil was sollte jemanden dran hindern es auszulesen.
    Im Prinzip nimmt man eine handvoll Verschlüsselungsverfahren packt die zusammen lässt mit einen Tool den Code ein bissen verschleiern und das war es.
    Was soll sonst helfen, wenn jemand kommt der genug Zeit und Interesse mit bringt kann er jedes Containerformat Reverse Engineering und dann bleibt immer noch die Möglichkeit es mit Wireshark zu sniffen.
     
  23. 5. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    @darkside2k4

    Na dann, wenn du denkst das das die beste Lösung ist. Mach einen open-source Prototyp bei dem du weniger als eine "handvoll" Verschlüsselungsalgorithmen implementierst und in deinem Sicherheitskonzept steht dann "ich würde in der closed-source 'real world' Variante noch eine handvoll mehr Verschlüsselungsalgorithmen-Layers hinzufügen".
     
  24. 5. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Ich habe nicht gesagt das dies die beste Lösung ist, mir würde so jetzt nichts besseres einfallen. Da ich auch das ganze Thema für den Popo finde, denn wenn jemand an die Links will kommt er dran und wenn es halt über einen Umweg, z.B. Wireshark, geht.
    Es ist doch immer so, wenn ich den Verschlüsselungsweg und das Passwort kenne komme ich doch immer an den Klartext, oder habe ich da einfach eine Denkblockade?
    Ich bin dafür offen, wenn jemand sagt es geht doch.
     
  25. 5. Januar 2013
    AW: Crypto Challenge #1 - Neues Loader Containerformat

    Du hast schon recht, solange dein PC eine Verbindung zu dem Server aufbauen wird, ist es immer möglich an die Daten zu kommen. Es soll wohl darum gehen, das so schwierig wie möglich zu gestalten.
    Den Ansatz hier Opensource-Programme mit Ideen zu sammeln verstehe ich allerdings auch nicht wirklich, da es ja letztendlich immer nur auf Security through obscurity hinauslaufen kann, es sei denn, man will den gesamten Traffic über einen trusted Server leiten.
     
  26. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.