Hallo, hab im Anhang ein C# 2010 Projekt, Es soll eine verschlüsselte Datenübertragung zu verfügung stellen, dieses Projekt ist derzeit nur der Client, bevor ich den Server schreibe, wollte ich mal alle hier fragen ob das so grob funktionieren kann. Ich wäre euch dankbar wenn ihr mir Tipps datzu gebt, auch in Sachen Sicherheit der Übertragung und Funktion. Mit freundlichen Grüßen Sebastian Neusch
Wozu? Mir erschließt sich der Sinn nicht. Außerdem ist unklar was du nun genau gemacht hast und was dein Ziel ist.
Immerhin schonmal CBC statt ECB. Dennoch kannst das aus Sicherheitssicht in die Tonne kloppen: keine authenticated encryption.
Ich sehe das so: Der Client nimmt ein Passwort bzw Key des Users entgegen. Der andere User muss den selben Key verwenden (ausser senden und empfangen wird mit jeweils einem eigenen Key gemacht). Der Server vermittelt nur die Daten so das der Client zum anderen Client anonym (IP) bleibt. Das einzige Problem wird der Schlüssel selber sein: wie kommt er sicher zum anderen User?
1. Wieviele Clients soll es geben? 2. Wie soll der Schlüssel sicher an die Clients übermittelt werden, wenn die Clients gegenseitig anonym bleiben sollen? 3. Darf der Server die Identität der Clients kennen? Mein Vorschlag für ein einfaches Multi-User-System mit vertrauenswürdigem(!) Server bei dem die Clients lediglich die IP des jeweils anderen nicht wissen dürfen würde so aussehen: Voraussetzung 1. Der Server verfügt über ein digitales Zertifikat 2. Clients nutzen zur Kommunikation mit dem Server TLS 3. Der Server vergibt an jeden Client eine eindeutige ID sowie einen einzigartigen, zufälligen AES-Schlüssel Anwendung: 1. Clients verbinden sich per TLS zum Server, durch Prüfung des Zertifikats wird dessen Identität und Authentizität sichergestellt 2. Client A teilt dem Server mit, dass er mit Client B kommunizieren möchte. 3. Der Server sendet Client A den Schlüssel von Client B 4. Der Server teil Client B den Kommunikationswunsch mit und übermittelt ihm den Schlüssel von Client A 5. Bei der Kommunikation verschlüsselt Client A und mit dem Schlüssel von Client B und entschlüsselt mit seinem Schlüssel A. Client B verschlüsselt mit dem Schlüssel von Client A und entschlüsselt mit seinem Schlüssel B. Das lässt sich jetzt noch beliebig weiter verfeinern, z.B. indem nicht direkt die Schlüssel von A und B verwendet werden sondern abgeleitete Session-Schlüssel, dadurch sind diese nur für eine Session gültig und der Originalschlüssel kann nicht von anderen Teilnehmern missbraucht werden, da er nur dem jeweiligen Client und dem Server bekannt ist. Voraussetzung hier: Server und Client sind in der Lage jeweils die gleiche Schlüsselableitung durchzuführen. Viele Grüße Daniel
Also: Es sollte nur einen server und einen client geben. Ich will mit dem client den server fernsteuern, vorerst will ich aber nur dateien übertragen. Ich dachte an einen starken Namen des Clients, damit klar ist, dass nicht jemand "falsches" verbindet. Zur Schlüsselübertragung habe ich direkt keine sichere Idee ich dachte an die Verschlüsselung des AES-Schlüssels (IV, Key) durch RSA.
Einfach mal bei http://de.wikipedia.org/wiki/Kryptografie beginnen. Ohne rudimentäre Grundlagen kommst Du bei dem Thema nicht weit. Starke Verschlüsselung bekommst Du per Library. Die Schlüsselverteilung ist das Problem. ???
Sebastian N. schrieb: > Es sollte nur einen server und einen client geben. > Ich will mit dem client den server fernsteuern, vorerst will ich aber > nur dateien übertragen. Dann nimm TLS mit Client-Authentisierung und tunnel dein Übertragungsprotokoll dadurch. Genau für solche Anwendungsfälle wurde TLS entworfen. Irgendwas Eigenes zu basteln ohne über tiefere Krypto-Kenntnisse zu verfügen ist grob fahrlässig.
Sebastian N. schrieb: > Ist die grundidee der verschlüsselten Übertragung oke? Noch ein Nachtrag, die Grundidee etwas zu verschlüsseln ist nie verkehrt ;) Das Problem ist eben, wie du schon gemerkt hast, dass es mit Verschlüsselung alleine nicht getan ist. Die Verschlüsselung an sich ist eigentlich trivial. Man nehme einen (idealerweise verbreiteten und standardisierten) Algorithmus wie AES und ver-/entschlüssele damit Daten. Normalerweise kann man hier (Implementierungsfehler mal außen vor) nicht viel falsch machen. Die Herausforderung liegt leider an anderen Stellen: 1. Wie erzeugt man sichere Schlüssel? 2. Wie verteilt man Schlüssel sicher an die einzelnen Teilnehmer? 3. Wie sichert man die Authentizität der einzelnen Teilnehmer? 4. Wie sichert man die Authentizität/Integrität der übertragenen Daten? 5. Wie sichert man das System gegen Kompromittierung von Schlüsseln? 6. Wie sichert man das System gegen betrügerische Teilnehmer? 7. Usw. usw. Daher auch mein Vorschlag mit TLS, da dir hierdurch schon einmal ein paar Sorgen genommen werden. Insbesondere kannst du damit schon einmal sicherstellen, dass jeder Teilnehmer über eine sichere Verbindung zum Server verfügt UND dass die Authentizität des Servers verifiziert werden kann, die Clients also dem Server vertrauen können. Sofern es erlaubt ist, dass der Server die übertragenen Daten lesen kann bist du hier dann auch schon fast fertig, denn die verschlüsselte Übertragung wird ja bereits bereits per TLS erledigt, der Server muss also nur noch dafür sorgen, dass die Daten empfangen und dann zum richtigen Teilnehmer weitergeleitet werden. Darf der Server die Daten nicht lesen wird es etwas komplizierter. Hier hatte ich in meinem vorigen Vorschlag einen Denkfehler, denn wenn der Server als Key Distribution Center arbeitet (also Schlüssel verteilt und speichert) kann er ja nach wie vor die Kommunikation mitlesen, wenn er möchte. Hier müsste man dann auf Clientseite mit digitalen Zertifikaten oder aber z.B. mit Diffie-Hellman-Schlüsselaustausch arbeiten. Letzterer ist jedoch ohne weitere Absicherung über Signaturen oder MACs anfällig für Man-in-the-middle-Angriffe. Letztenendes kommt es also darauf an, welches Sicherheitsniveau du benötigst und welcher Teilnehmer im System was machen darf. Ist der Server vertrauenswürdig und darf alles mitlesen, dann brauchst du im Prinzip nur TLS und kannst deine Nutzdaten dann im Klartext darüber tunneln.
Ist das folgende der richtige Ansatz: http://www.codeproject.com/Articles/2642/SSL-TLS-client-server-for-NET-and-SSL-tunnelling
Daniel H. schrieb: > Normalerweise kann man hier (Implementierungsfehler mal außen > vor) nicht viel falsch machen. Haha! Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen. Das kannst du nicht. Das kann ich nicht. Und niemand sonst hier im Forum. Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für Normalsterbliche wie uns: Keyczar. cryptlib. NaCl.
Beitrag nicht gelesen und/oder nicht verstanden? Genau von selber Stricken habe ich abgeraten. Das von dir (aus dem Zusammenhang gerissene) Zitat bezieht sich allein darauf, dass die reine Durchführung der Verschlüsselung einfach ist und man nicht viel falsch machen kann wenn man standardisierte Algorithmen wie z.B. AES nutzt. Das ist aber eben nicht alles, was man berücksichtigen muss. Stefan Rand schrieb: > Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen. Wie kommst du auf OpenSSL? Habe ich das irgendwo erwähnt? Ehrlich gesagt bist du der erste, der dieses Wort hier im Thread gepostet hast. Vielleicht den Beitrag wieder nicht richtig gelesen/verstanden? Dir ist schon bewusst, dass ich TLS nur das Protokoll ist? Stefan Rand schrieb: > Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für > Normalsterbliche wie uns: Keyczar. cryptlib. NaCl. Und OpenSSL ist eine Low-Level-API oder was? Nur weil du damit nicht umgehen kannst heißt das nicht, dass andere es nicht können. Das nächste mal bitte erst nachdenken, bevor du deine überheblichen Worte in die Tastatur hackst. Sebastian N. schrieb: > Ist das folgende der richtige Ansatz: Das sieht schonmal gut aus, aber im Detail habe ich es mir jetzt nicht weiter angeschaut.
:
Bearbeitet durch User
Daniel H. schrieb: > Beitrag nicht gelesen und/oder nicht verstanden? Dafür, daß du keine Ahnung hast, riskierst du aber ne dicke Lippe. > Genau von selber Stricken habe ich abgeraten. Das von dir (aus dem > Zusammenhang gerissene) Zitat bezieht sich allein darauf, dass die reine > Durchführung der Verschlüsselung einfach ist und man nicht viel falsch > machen kann wenn man standardisierte Algorithmen wie z.B. AES nutzt. Das > ist aber eben nicht alles, was man berücksichtigen muss. Haha. Zeig mal, wie du AES implementierst. AES ist verdammt schwierig zu implementieren, wenn man Timing-Attacken ausschließen will. > Stefan Rand schrieb: >> Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen. > > Wie kommst du auf OpenSSL? Habe ich das irgendwo erwähnt? Ehrlich gesagt Mir war nicht klar, daß du Krypto selbst implementieren willst. Aber daß jemand so idiotische Ideen hat, damit muß man auch nicht rechnen. Und so ziemlich jeder, der nach gut abgehangenen und reviewten Krypto-Primitiven mit Bindings in so ziemlich alle Sprachen sucht, nimmt OpenSSL. Oder was würdest du nehmen, außer natürlich deinem Eigen-Gefrickel? > Vielleicht den Beitrag wieder nicht richtig gelesen/verstanden? Dir ist > schon bewusst, dass ich TLS nur das Protokoll ist? Du bist TLS nur das Protokoll. Soso. Stell die Flasche weg. > Stefan Rand schrieb: >> Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für >> Normalsterbliche wie uns: Keyczar. cryptlib. NaCl. > > Und OpenSSL ist eine Low-Level-API oder was? Nur weil du damit nicht Ja, ist es. Sag mal, hast du überhaupt schonmal grob gehört, was NaCl oder Keyczar sind und machen? > umgehen kannst heißt das nicht, dass andere es nicht können. Ja, ein paar Leute können das. Du und ich nicht. > Das nächste mal bitte erst nachdenken, bevor du deine überheblichen > Worte in die Tastatur hackst. Ich finde es schön, daß ich dich so aufregen konnte. Mehr als ad-hominem kommt von dir aber eh nicht, deshalb: Tür zu! Von außen!
Stefan Rand schrieb: > Tür zu! Von außen! Richtig. Zankt euch per PN weiter. Es bringt auch nichts, wenn jeweils der Eine den Post vom Anderen meldet...
Hallo, warum gräbst du den Thread nach neun Tagen wieder aus nachdem hier nun Ruhe herrschte? Ich hab ihm eine PN geschrieben und meinen Standpunkt dargelegt, darauf kam seither keine Reaktion, also ist die Sache für mich gegessen, ich gehe nach wie vor davon aus, dass wir hier ein massives Missverständnis hatten. Viele Grüße Daniel
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.