#1 7. Januar 2013 Zuletzt von einem Moderator bearbeitet: 15. April 2017 Da mir die Zeit fehlt eine fertige Implementierung meines Konzeptes auf die Beine zu stellen - noch dazu bis Ende des Monats - möchte ich euch einfach präsentieren wie ich mir ein neues Containerformat vorstellen könnte. Vorwort: Wie im Haupthema bereits ausführlich diskutiert basieren die bisherigen Container alle auf Security_through_obscurity - es soll also möglichst schwer sein dessen Inhalt zu extrahieren. Spätestens jedoch wenn ein zwischengeschalteter Proxy benutzt wird ist es ohne weiteres möglich alle Links im Klartext zu erhalten. Meiner Meinung nach sind solche Formate einfach Broken by Design. Sie erschweren es lediglich Benutzern anderer Betriebssysteme auch an dem System teilhaben zu können. Die Ursachen weshalb die Links versteckt bleiben sollen sind vielfältig. Hauptursache ist jedoch dass ein potentieller angreifer die Dateien nicht löscht (und im Falle eines FTP Servers: Ihn ggf. zu seinen eigenen Zwecken zu missbraucht). Fakt ist: Jeder der gängigen Container wird oder wurde früher oder später geknackt. Mein Konzept baut daher auf einem einem ähnlichen, dennoch verschiedenen Prinzip. Die 3 Komponenten Das vollständige Konzept baut auf drei Komponenten auf: Encrypter Decrypter Server Encrypter und Decrypter sind denkbar einfach auch in einem einziges Programm kombinierbar. Der Encrypter dient zum erstellen von Containerdateien, der Decrypter zum entschlüsseln selbiger und der Server als Vermittlungsinstanz (nachfolgend mehr dazu). Encrypter Vorweg geschickt: Zunächst ist es möglich folgende Parameter im Programm zu hinterlegen: Server aPI: Eine URL zu einer Server aPI inkl. Port mit welcher das Programm in Kontakt tritt um seine Container zu verschlüsseln. (Diese URL könnte auf einen öffentlichen Server voreingestellt sein, denkbar wäre eine REST oder SOaP aPI) Public Key: Ein öffentlicher Schlüssel der zu dem Client gehört. Wenn der Benutzer keinen eigenen Schlüssel eingibt oder das Programm zum ersten mal startet wird dieser automatisch generiert. Private Key: Wie Public Key, aber eben privat ... Es handelt sich um ein asymmetrisches Schlüsselpaar Nachfolgend das Schema für die Erstellung eines neuen Containers: Schritt: Der Benutzer hinterlegt beliebig viele URLs und beliebig viele Metadaten (Beschreibung, Datum, Checksum, usw...) für selbige. auf ein genaues Dateiformat gehe ich jetzt nicht ein. aus diesen Nutzdaten wird der Container erstellt - welcher weiterhin noch einige Metadaten enthält. Schritt: Mit Hilfe des privaten Schlüssels wird eine Digitale_Signatur für den Nutzdatenanteil erstellt. Diese wird fortan als Container ID bezeichnet. Schritt: Das Programm sendet Container ID und Public Key via Server aPI an den Server. Schritt: Server antwortet mit einer verschlüsselten Nachricht welche sowohl die Container ID (welche auch als Nonce fungiert) als auch einen Symmetrischen Schlüssel enthält. Schritt: Der Client entschlüsselt die Nachricht mit dem Public Key des Servers (welcher Idealer Weise über einen anderen Kanal angefordert werden sollte, aber auch über die Server aPI abfragbar ist) und verschlüsselt die Nutzdaten des Containers anschließend mit übermittelten Schlüssel. Schritt: In den Header des Containers wird jetzt die Container ID sowie der Public Key des Clients und die Server aPI welche zum verschlüsseln verwendet wurde abgelegt. Schritt (optional): Die Datei kann zusätzlich mit einem Passwort versehen werden mit welchen die komplette Datei gepackt und verschlüsselt wird (z.B. via gzip und openssl). Dadurch ist auch der Header des Containers nicht mehr einsehbar. Beachte: Im 5. Schritt ist eine Integritätsprüfung durch das überprüfen der übermittelten Container ID möglich (Siehe auch Man-in-the-middle-angriff ) Im 7. Schritt kann das eingegebene Passwort vorher durch den Client noch ein paar Runden durch SHa1 gejagt werden um BruteForce angriffe weniger attraktiv zu machen. Decrypter auch hier gilt: Der Decrypter verfügt über ein asymmetrisches Schlüsselpaar welches für einen Benutzer idealerweise mit jenem des Encrypters übereinstimmt. Beim Decrypten ist die Vorgehensweise invers zum Encrypter. Dennoch hier die Schritte: Schritt: Zunächst muss der Container ggf. mit dem Passwort entschlüsselt und entpackt werden. Schritt: Der Client verschlüsselt die Container ID mit seinem privaten Schlüssel und schickt diese zusammen mit seinem Public Key an die Server aPI. Schritt: Der Server antwortet mit einer verschlüsselten Nachricht (wobei hierzu der mitgeschickte Public Key verwendet wird) welche den symmetrischen Schlüssel enthält. Schritt: Client entschlüsselt die Nachricht des Servers mit seinem privaten Schlüssel. Schritt: Client entschlüsselt Nutzdaten des Containers Schritt (optional): Integritätsprüfung durch prüfen der digitalen Signatur (Container ID) Server Die Rolle des Servers sollte aus den vorhergehenden Schritten mehr oder weniger klar geworden sein. Er fungiert als Datenbank für Container ID <-> Public Key des Clients <-> Symmetrischer Schlüssel an dieser Stelle ist mein Konzept zu Ende. Nachfolgend möchte ich noch einige Stärken (und Schwächen) die ich in diesem Konzept sehe ansprechen. Nachteile Zunächst zu den Nachteilen. Server kann ausfallen. Folge: Kein Container mit entsprechender Server aPI ist mehr entschlüsselbar. Datenschutz Probleme. Jede Client anfrage übermittelt auch die IP adresse des Nutzers Vorteile Der Server dient im obigen Beispiel lediglich zur auslieferung des symmetrischen Schlüssels. Nachfolgend ein paar Möglichkeiten wie der Server aber durchaus auch verwendet werden kann. Dadurch das die aPI offen dokumentiert ist, steht es jedem frei seine eigene aPI Schnittstelle zu betreiben. Somit könnte beispielsweise Nydus eine eigene aPI betreiben. Der Server könnte jetzt bei einer anfrage ein Zeitlimit einführen (5 Schlüssel / Tag o.ä.) - dieses Limit würde dann auf dem Public Key und/oder der IP adresse des Benutzers basieren. als weitere Option liese sich eine Rechteverwaltung einführen. Dass heißt im 2. Schritt (Decrypter) wird überprüft ob der Public Key berechtigt ist den Schlüssel für die entsprechende Container ID anzuordern. Ich stelle mir das in etwa so vor. Ein Benutzer der Zugriff auf Level 2 (immer noch am Beispiel des Nydus boardes) hat, kann in seinem Profil ein Token hinterlegen. Dieses kann im Client erstellt werden. Vorgehensweise ist: Im Profil wird ein zufälliger Text angezeigt. aus diesem Text wird im Client ein Token erstellt (mit Hilfe des privaten Schlüssels). anschlißend trägt der Nutzer seinen Public Key inkl. Token ein. Nach diesem Schema ist es möglich den Benutzer zu authentifizieren. Über eine Weboberfläche kann ein Uploader dann festlegen welche Container ID welche Zugriffsbeschränkungen hat. z.B.: 0cc175b9 <-> Public c0f1b6a8 <-> Level 1 (alle angemeldeten Benutzer) 31c399e2 <-> Level 2 ab Zugriffsbeschränkung Level 1 kann somit auch relativ sicher gewährleistet sein dass ein Benutzer nicht mehr Container entschlüsselt als das Zeitlimit zulässt, da er seinen Public Key nicht ohne weiteres ändern kann (ohne sich erneut anzumelden). Bei Verdacht auf Deleter könnte genau nachgehalten werden welche Person(en) in Frage kommen. alle oben genannten Möglichkeiten wären machbar ohne dass dabei das Konzept abgändert werden müsste. Mit einer kleinen abänderung wäre es auch machbar dass Benutzer ihre Container komplett Online managen können indem auch der Nutzdatenanteil an die aPI übertragen wird. anschließend geben die Uploader nur noch die Container ID und Server aPI URL weiter. Damit würde ein Download des Containers entfallen und ein vollständiges Management wäre Möglich (ändern von URLs falls der Server down ist, Sperren der Datei [Server verweigert auslieferung des Schlüssels], usw. usf.... Es gibt bestimmt noch weitere denkbare Möglichkeiten. aber jetzt genug geredet. Was haltet ihr davon? + Multi-Zitat Zitieren