nicht angemeldet
Verschlüsselte Übertragung ohne SSL?
Hallo,
ich bin (leider) Strato-Kunde, habe dementsprechend keine Möglichkeit, Daten per SSL, TLC etc. verschlüsselt zu übertragen.
Meine Idee ist jetzt, mit Hilfe von JavaScript Clientseitig Formulardaten mit dem PGP-Prinzip (also mit Public- und Privatekeys)zu verschlüsseln. Die Idee kam mir, als ich folgende Feature-Artikel gelesen hatte: http://www.teamone.de/selfaktuell/artikel/md5.htm
Diese Daten lass ich mir dann per Mail zusenden (z.B. über ein CGI) und kann Sie dann zu Hause in "sicherer" Umgebung wieder mit meinem Privat-Key entschlüsseln.
Mir ist bekannt, daß dies mit Sicherheit nicht die beste Lösung ist, da der User auf jeden Fall JavaScript unterstützen muß, aber rein technisch sollte es doch kein Problem darstellen, da JavaScript ja durchaus bitweise Operationen gestattet.
Was meint Ihr dazu?
Alexander
-
Hi,
Was meint Ihr dazu?
mir ist der genaue Algorithmus von PGP nicht bekannt; aber soweit ich es einschätze, dürfte das Verfahren auf nicht ganz so schnellen Rechnern ein wenig den Rahmen tolerabler Geschwindigkeit sprengen.
Wenn Du es allerdings (mit unserer Hilfe ;-) schaffst, das Verfahren halbwegs performant hinzubekommen, würde sich die Netzwelt sicher darüber freuen. Zwar fehlt vermutlich das Vertrauen der User in die Sicherheit, und die Problematik des nichtaktivierten JavaScripts muß auch beachtet werden, aber für viele (wie Dich) wäre das so ziemlich die einzige Alternative.
Wir können daraus ja mal 'ne Kollektiv-Entwicklung als Open Source machen (wenn Du einverstanden bist). Dazu bräuchten wir:
- eine Kurzanleitung, wie man als Webmaster an PGP-Keys kommt (aller Anfang ist schwer) ;-)
- ein Kurzprogramm, evtl. in JavaScript, vielleicht direkt online verfügbar, das den Public Key in eine effiziente JavaScript-Struktur bekommt (vermutlich wird ein Präparsing des Keys die Performance immens erhöhen),
- den JavaScript-Code, der onSubmit aufgerufen wird (inkl. des Setzens eines <input type="hidden" name="jsactive"> von value="no" auf "yes"),
- den serverseitigen Perl(?)-Code zur Entschlüsselung der Daten (falls nötig), am besten modular, und natürlich
- eine Anleitung, inkl. Beispieltext zur Erklärung, den man sich auf die Homepage packen kann.
Wer macht mit?
Cheatah
-
Hi,
Was meint Ihr dazu?
mir ist der genaue Algorithmus von PGP nicht bekannt; aber soweit ich es einschätze, dürfte das Verfahren auf nicht ganz so schnellen Rechnern ein wenig den Rahmen tolerabler Geschwindigkeit sprengen.
Das Problem mit der Geschwindigkeit an sich ist kein Problem. Da darfst nicht vergessen, daß Du lediglich die Daten mit dem Key ver- bzw. entschlüsselst. Das geht wesentlich schneller als einen kompletten Key zu erstellen.
die Problematik des nichtaktivierten JavaScripts muß auch beachtet werden, aber für viele (wie Dich) wäre das so ziemlich die einzige Alternative.
Das ist in der Tat das größte Problem. Da ist halt ausführliche Aufklärungsarbeit von den Anbietern gegenüber den usern gefragt.
Eine andere Möglichkeit wäre, daß nur Zugang zu den Formularen, die verschlüsselt übertragen werden sollen, möglich ist, wenn man JS aktiviert hat. Das kann man ganz einfach mit JS herbeiführen, indem man den User mittels JS weiterleitet. So ist sichergestellt, daß der JS unterstützt.Wir können daraus ja mal 'ne Kollektiv-Entwicklung als Open Source machen (wenn Du einverstanden bist). Dazu bräuchten wir:
Ich hab da nichts gegen :)
- eine Kurzanleitung, wie man als Webmaster an PGP-Keys kommt (aller Anfang ist schwer) ;-)
Ich begebe mich da mal auf die Suche. Wir brauchen ja nicht den original PGP-Algorythmus nehmen (den werden wir wohl auch nicht bekommen...), sondern nur einen hohen Algorythmus, der nach der Public- und Private-Key-Verschlüsselung funktioniert.
- den serverseitigen Perl(?)-Code zur Entschlüsselung der Daten (falls nötig), am besten modular, und natürlich
- eine Anleitung, inkl. Beispieltext zur Erklärung, den man sich auf die Homepage packen kann.
Wie gesagt, ich begebe mich mal auf die Suche und melde mich dann hier im Forum oder per Mail.
Bis dann...
Alexander
-
Hallo Ihr 2 Helden
wenn man bedenkt, welch Aufwand hinter SSL, PGP SET und allen anderen Security-, Signatur- und Cryptographie-Programmen steckt,
kann man Euch nur viel Spass an so einem Vorhaben wünschen.
In Gedanken bin ich immer bei Euch *g*
Gruss
Christian -
Hi,
Das Problem mit der Geschwindigkeit an sich ist kein Problem. Da darfst nicht vergessen, daß Du lediglich die Daten mit dem Key ver- bzw. entschlüsselst. Das geht wesentlich schneller als einen kompletten Key zu erstellen.
das ist schon klar; nur fürchte ich eben, daß die Verschlüsselung an sich in JavaScript kaum zufriedenstellend lösbar ist.
Eine andere Möglichkeit wäre, daß nur Zugang zu den Formularen, die verschlüsselt übertragen werden sollen, möglich ist, wenn man JS aktiviert hat.
Extrem schlechte Wahl. Es gibt Leute, die können (technisch oder von den Fähigkeiten her) oder dürfen JavaScript nicht aktivieren. Vielmehr muß dem Benutzer klar sein, daß es zwar auch ohne funktioniert, aber die Daten dann eben nicht verschlüsselt sind.
Wie gesagt, ich begebe mich mal auf die Suche und melde mich dann hier im Forum oder per Mail.
Bitte im Forum :-)
Cheatah
-
Re Hi,
Hört sich interessant an.
Aber grundsätzlich noch folgende Fragen:
- Soll es wirklich ein assymetrisches Verfahren sein oder reicht auch ein symmetrisches Verschlüsselungsverfahren?
- Wie und wo wird bei einem assymetrischen Verfahren das Schlüsselpaar Private-/Public-Key generiert?
- Wie gelangt in diesem konkreten Anwendungsfall der Public-Key zum Empfänger der Nachricht (Server?)?
Da nämlich die Übertragung des Public-Keys auch gesichert erfolgen müsste, könnte doch auch einfach ein symetrisches Verfahren mit nur einem Schlüssel eingesetzt werden.
Bin gespannt, in welche Richtung sich das Ganze entwickelt.
Grüsse
Eisbär
-
Re Hi,
Hört sich interessant an.
Aber grundsätzlich noch folgende Fragen:
- Soll es wirklich ein assymetrisches Verfahren sein oder reicht auch ein symmetrisches Verschlüsselungsverfahren?
Es MUSS ein assymetrisches Verfahren sein. Mit dem Public-Key, der im übrigen ruhig "ungesichert" übertragen werden darf, kann nur VERSCHLÜSSELT werden. Das heißt, wenn ein Angreifer diesen kennt, kann er zwar Nachrichten verschlüsseln, diese dann aber nicht (mit diesem Key) wieder entschlüsseln.
NUR mit dem Private-Key, der entweder "sicher", d.h. zugriffbeschützt auf dem Server liegt, oder sicher bei mir auf der lokalen Platte, kann ich die mit dem Public-Key verschlüsselten Nachrichten wieder entschlüsseln. Den darf natürlich keiner kennen, sonst ist die Sache witzlos.
- Wie und wo wird bei einem assymetrischen Verfahren das Schlüsselpaar Private-/Public-Key generiert?
Wie, das ist die Frage des verwendeten Algorythmus. Ob er z.B. Datum, Uhrzeit, Usernamen etc. beinhaltet, ist in sofern nicht ganz so wichtig. Wichtig ist nur, daß der Key auf einer Basis generiert wird, die von einem potentiellen Angreifer nicht zu "erraten" bzw. zu ermitteln ist (was nicht heißt, daß er den Algorythmus nicht kennen darf - wobei ihm die Sache das etwas erleichtet).
- Wie gelangt in diesem konkreten Anwendungsfall der Public-Key zum Empfänger der Nachricht (Server?)?
Der Empfänger der Nahricht benötigt den Public-Key zum Entschlüsseln nicht. Er benötigt nur den Private-Key. Und der liegt ja sicher auf dem Server.
Falls Du mit Empfänger den User meinst, der die verschlüsselten Daten übertragen will, so ist dies ganz einfach: Der Public-Key wird ungesichert im Quellcode übertragen, ebenso wie der Algorythmus zum VERSCHLÜSSELN.
Da nämlich die Übertragung des Public-Keys auch gesichert erfolgen müsste, könnte doch auch einfach ein symetrisches Verfahren mit nur einem Schlüssel eingesetzt werden.
Da liegt der Kern des Problems. Wenn ich nur einen Schlüssel habe, den ich zum ENT- und VERSCHLÜSSELN einer Nachricht verwende, muß der Schlüssel geheim, oder vielmehr sicher übertragen werden. Da das ja nicht möglich ist, ist diese Methode pinzipiell ungeeignet.
Machen wir das ganze an einem Beispiel fest:
Ich generiere mit Algorythmus 1 (A1) und einer frei wählbaren Codebasis (z.B. "123") einen Public-Key (PK) (z.B. "321") und einen Private-Key (OK) (z.B. " 213").
Der PK ist im Quelltext der Datei eingebettet, die zum User ungesichert übertragen wird.Der User verschlüsselt dann seiner Nachricht (z.B. "toll") mit PK
und Algorythmus 2 (A2) verschlüsselt (Ergebnis: "t3o2l1l").Diese so verschlüsselte Nachricht wird dann zum Server übertragen (ungesichert, denn eine gesicherte Verbindung haben wir ja nicht). Diese verschlüsselte Nachricht kann dann auf dem Server NUR mit dem OK und Algorythmus 3 (A3) wieder entschlüsselt werden. Das heißt auch wenn jemand den PK kennt, kann er die Ncahricht nicht entschlüsseln.
Und ich habe dann wieder auf dem Server die entschlüsselte Nachricht.
Leider funktioniert das ganze nur in eine Richtung (zum Server hin) gesichert. Das stellt aber im Gegensatz zur bereits vorgestellten (und vor allem mit JS verwirklichten) MD5-Verschlüsselung in sofern einen Fortschritt dar, daß man codierte NAchrichten wieder entschlüsseln kann, was ja mit der MD5 Methode NICHT geht. Bei MD5 kann man verschlüsselte Strings nur vergleichen und so sagen, ob die ursprüngliche Nachricht übereinstimmt. Das reicht für einen Passwortschutz sicher aus, aber um z.B. Kontonummern oder Kreditkartennummern sicher zu übertragen nicht. Da ich ja nicht verschlüsselte Kartennummer bracuhe, sondern die entschlüsselte.
Ich hoffe, meine Idee ist nun richtig verstanden worden. ;)
Bin gespannt, in welche Richtung sich das Ganze entwickelt.
Ich auch ;)
Viele Grüße
Alexander
-
Hi Alexander
Es MUSS ein assymetrisches Verfahren sein. Mit dem Public-Key, der im übrigen ruhig "ungesichert" übertragen werden darf, kann nur VERSCHLÜSSELT werden. Das heißt, wenn ein Angreifer diesen kennt, kann er zwar Nachrichten verschlüsseln, diese dann aber nicht (mit diesem Key) wieder entschlüsseln.
...
Ok. Ich hatte Dich andersrum vertsanden, aber so rum macht es Sinn.
Wir werden also ein assymmetrisches Verschlüsselungs-Verfahren in Javascript entwickeln, das auf Clientseite mit dem offen übertragenen Public-Key die Nachricht/Daten verschlüsselt und normal per POST oder GET "unverschlüsselt" zum Server überträgt.
Serverseitig werden wir ein Entschlüsslungs-Algoritmus in Perl, Java, Php, etc. entwickeln, welcher die übertragenen Daten mit dem lokal gespeicherten Private-Key entschlüsselt. Ggf. greifen wir dazu auf bestehende Krypto-APIs zurück.Soweit verstanden :-)
Dann hier mal ein Link zu einer teilw. deutschen Krypto-FAQ:
http://www.iks-jena.de/mitarb/lutz/security/cryptfaq/index.htmlWenn ich das so durchlese kommt nur das RSA- und DSA-Verfahren in Frage.
Wobei ich mich erinnern mag, dass vor ca. einem halben Jahr ein weiteres Verfahren zum "neuen" assymetrischen Kryptostandard erhoben wurde. Dazu werde ich noch weiter recherchieren.Bei der Wahl zwichen RSA und DSA würde ich mich wegen der Patentlage (RSA ist frei!) und dem grösseren allgemeinen Erfahrungsstand für RSA entscheiden. Was ist Deine Meinung?
Bei PGP wird jedoch auch das DH/CSS-Verfahren (Diffie-Hellman?) eingesetzt. Ich weiss aber noch nicht, welche Vorteile das gegenüber dem RSA-Verfahren hat.Es wird auf jeden Fall von Vorteil sein, wenn wir ein Verfahren anwenden, wo wir zur Key-Generation auf bestehende Tools (z.B. PGP) zurückgreifen können.
Ausserdem hätten wir dann mit PGP auch eine Art Debug-Umgebung, mit der wir das Verschlüsseln, bzw. Entschlüsseln unabhängig testen (gegenchecken) können.Um Rückmeldung aller Art zur Auswahl des geeigneten Verfahren sind wir hier an dieser Stelle sicher dankbar.
Und zum Schluss noch einige Links:
Deutsche PGP-Seite: [http://home.nexgo.de/kraven/pgp/pgpindex.html]
RFC2440 zu OpenPGP: http://www.ietf.org/rfc/rfc2440.txt
Robert's Crypto & PGP Links: http://crypto.yashy.com/www/
Handbook of Applied Cryptography: http://cacr.math.uwaterloo.ca/hac/Bin gespannt, in welche Richtung sich das Ganze entwickelt.
Ich auch ;)
Na dan mal los ;-))
Grüsse
Eisbär
-
Nochmals Hi
Ein weiterer Link zum Thema: http://www.uni-mainz.de/~pommeren/DSVorlesung96/index.html
Wenn ich mir das ganze so durchlese sehe ich beim RSA-Verfahren folgende Probleme:
- Das Produkt n=p*q muss zum Verschlüsseln an den Client übermittelt werden. Somit ist das Modul n im JS-COde als Klartext zu sehen. Dabei stellt sich die Frage, ob aus diesem Modul Rückschlüsse auf die beiden Primzahlen p und q gezogen werden können und damit das Verschlüsselungsverfahren schwach wird.
- Weiter ist die Frage, wie wir an dieses Modul n herankommen. Wenn wir z.B mit PGP die Keys erzeugen, weiss ich nicht wie ich an dieses Modul n herankomme. Ausserdem stellt sich die Frage, wie in der verschlüsselten E-Mail-Kommunikation dieses Modul n=p*q vom Absender an den Empfänger übermittelt wird oder ob es dazu einen Standardwert gibt, den alle RSA-fähigen Kryptoprogramme verwenden.
Es wäre schön, wenn noch ein paar Leute versuchen mitzumachen...
Alleinunterhaltung ist eigentlich nicht meine Sache ;-(Grüsse
Eisbär
-