• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Verschlüsselung von Kommunikation

Archon Short

Forumsgott/göttin
Um bei mir die Kommunikation der Scripte zu verschlüsseln nutze ich folgende kleine Funktion:


Global lege ich einen Verschlüsselungscode fest:
string S_crypt_string = "fdslkjfsdlkjbklfsdkbnlsdfknbg";
- Dieser String muss im Sender- und im Empfängerscript identisch sein


Jetzt kommt die Verschlüsselung:

Die zu verschlüsselnde Kommunikation wird erstmal in eine Liste gepackt:
string s = llList2CSV([hier den Kram rein]);


Dann kommt an einer Stelle im Script die eigentliche Verschlüsselung:
string crypted = llXorBase64( llStringToBase64(s),llStringToBase64(S_crypt_string));
- Hier wird nun die ehemalige Liste nochmal komplett verschlüsselt

- Dieser String kann nun versendet werden (llSay,llMessageLinked,.....)


Jetzt kommt die Entschlüsselung:

Das Scipt empfängt die Kommunikation als String str
Diese wird erstmal entschlüsselt und danach wieder zur Ausgangsliste zurückformatiert:
string decrypted = llBase64ToString(llXorBase64(str, llStringToBase64(S_crypt_string)));
list templist = llCSV2List(decrypted);




Manchmal möchte man nicht, daß andere Nutzer die Projektinterne Kommunikation nutzbar mitschneiden können.
Das ist nun der Punkt an dem es zur Erstellung eines sicheren Verschlüsselungscodes kommt:


S_crypt_string muss also aus Daten bestehen, die nur sehr kurzzeitig nutzbar sind:

Man kann z.B. den Objektkey, die aktuelle Position, OwnerKey, Unixtime, ... verwenden.
Dies ändert sich ja auch nicht während der Übermittlung.

Somit ist es mit einfachen Mitteln möglich eine Kommunikation, die nicht geknackt werden kann, für Projekte zu haben, bei denen die Eigentümer unterschiedliche Personen sind.




Ich hoffe dies ist verständlich geschrieben, falls nicht arbeite ich das auch gern nochmal nach.

LG Archon
 
XORBase64 ist zwar ziemlich schnell - aber leider auch eine äußerst schwache Verschlüsselung.

Daher sollte man den Key/verschlüsselungscode an wichtigen Dingen (oder auch nur ein RP-HUD für Waffen..) nicht nur wie oben erwähnt nur ein einziges mal verwenden, sondern diesen auch so wählen, dass er nicht zu kurz ist - er sollte am besten so lange sein wie der Text, der damit verschlüsselt werden soll (sonst wird der Schlüssel von der XOR-Funktion in Teilen einfach wiederholt).

Als Schlüssel eignet sich daher wunderbar z.B. die Funktion llGetTimeStamp - wenn man diesen String hinter den Minuten abschneidet. Und ihn nicht nur mehrfach verwendet in den Code-String einbaut, sondern irgendwie so "ineinander" verwurstelt (z.B. nach eine oder 2 Operationen mit dem Eingangs-String dann über llSHA1String mitten drin irgendwie) , dass da kein klares Muster mehr erkennbar ist.

s = llGetSubString(llGetTimeStamp(),0,15) + "irgenwas dran hängen noch";
s = Verwirbelungsfunktion (s);
usw.

Die Sekunden in llGetTimeStamp werden nebenbei abgeschnitten, damit Server und Client ein Fenster von 60s haben, in welchem die Kommunikation mit dem Key funktioniert. D.h. Keys gelten nur 60s lang.Verwendet man z.B. llGetUnixTime kann der Schlüssel bei bisschen lag möglicherweise nicht synchron in Client und Server generiert werden. Da muss man das dann möglicherweise auf 5 oder 10 Sekunden-Intervalle umrechnen. Einfach weil die Scripts dann zum Zeitpunkt der Key-Generationen verschiedene Unix-Zeiten haben.

Zudem sollte man jeden verschlüsselten Code mit einem "Marker" versehen, der dem Script anzeigt, dass ein Script korrekt entschlüsselt wurde. Eben weil es auch bei dem 60s-Fenster (oder 10s Fenster) Überschneidungen geben kann bei der Kommunikation, so dass kein gemeinsamer Key generiert wird. So kann man dann auch ein kurzes "Kommando Bekommen" oder "Übermittlungsfehler" vom Server an den Client schicken. (Und umgekehrt).

llOwnerKey und ähnliches eignet sich nur bedingt für eine XOR-Verschlüsselung weil sich der Key dabei nie ändert. Was bei dieser Verschlüsselung eine Schwachstelle ist. Wer auf eine sichere Verschlüsselung mit statischem Key bei wichtigen Dingen zurückgreifen möchte (z.B. weil nicht übermittelte Nachrichten ganz schlecht wären...), der sollte AES oder ähnliches einsetzen. Das ist auch mit statischem Key noch relativ sicher.
Siehe http://wiki.secondlife.com/wiki/Category:LSL_Encryption
und http://wiki.secondlife.com/wiki/AES_Strong_Encryption , http://wiki.secondlife.com/wiki/AES_LSL_Implementation ,da gibts eine AES-Implementation in LSL, die man über Link Messages verwenden kann. (braucht leider klein bisschen Einarbeitungszeit...)

Zusätzlich kann man nebenbei llGetTimeStamp noch verwenden um an Server und Client gleichzeitig die Kommunikations-Kanäle in Abhängigkeit von den aktuellen Minuten-Zahlen einzustellen. Was ein zufälliges Abhören und damit Hacken auch noch mal erschwert.
 
Grundproblem ist hierbei der Schlüsselaustausch. Bzw. die Art der Generierung bei Shirleys Vorschlag. Denn das ist nur halbwegs sicher, wenn der Algorithmus geheim bleibt ... was für Verschlüsselungen eigentlich ein Killerkriterium ist. Ein Verschlüsselung muss auch bei bekanntem Algorithmus noch sicher sein. Besser wäre da ein private/public Key-Verfahren.
 
Ich habe bisher auf Verschluesselungen fuer kommunikation verzichtet. Gut, bei meinem Kram ist so etwas auch nicht wirklich notwendig, dennoch verwende ich in manchen Produkten gewisse Optionen die Kommunikation zweier Produkte sicherer zu machen. Dabei verwende ich einfach einen Dynamischen Channel, der sich synchron mit dem anderen Produkt regelmaessig aktuallisiert. Das bedeutet, selbst wenn bekannt wird was ueberhaupt uebermittelt wird, kann man mit dieser Information recht wenig anfangen, da neben permanent wechselnden Channel noch gewisse andere Voraussetzungen erfuellt sein muessen, damit das Empfaenger-Script ueberhaupt darauf reagiert.

LG
Dae
 
Kommunikation ausserhalb von Objekten geschieht mit llRegionSayTo.
Da ist abhören sehr schwierig.

Intern wird es dann komplizierter:
Ich hab es so gelöst, daß der Cryptoschlüssel immer genauso lang ist, wei der zu verschlüsselnde String.
Als Zeitfenster habe ich ebenfalls 10 Sekunden, danach entsteht ein völlig neues Chaos, das jedoch nicht wirklich chaotisch, sondern berechenbar.
 
Um dein Chaos unberechenbar zu machen gaebe es vielleicht eine Moeglichkeit.
Dein kontrolliertes Chaos folgt doch einem bestimmten Algorithmus, den du als Variable angeben kannst. Wie waere es wenn du mehrere solcher Variablen in einer Liste speicherst und die in gewissen Abstaenden wechselst?

LG
Dae
 
Da ist dann die Frage: wofür das Ganze?
Es geht hierbei und einfache Verschlüsselung und Schutz in SL.
Bri meiner genutzten Methode wären sie verschlüsselten Strings nur alle 12 Stunden relativ identisch.
Und das auch nur wenn sich sonst nichts verändert.
Mit relativ meine ich, daß in dem Fall 60-70% des Strings identisch wären.

Mir persönlich reicht es, denn niochtmal meine Emails oder sonstige Kommunikation wird real so gut verschlüsselt.

Als Tip würde ich dann noch sagen:
Man kann mehr als einen Kryptoschlüssel verwenden, man kann Strings neu anordnen und man kann die Reihenfolge davon beliebig ändern.
 
Da ist dann die Frage: wofür das Ganze?

Wenns ums Geld geht... ;)

Normalerweise wuerde ich mir so eine frage auch stellen, aber wenn es darum geht zu verhindern das jemand irgend welche Luecken ausnutzt um sich einen Vorteil zu verschaffen, habe ich dafuer verstaendniss. Bei Vendoren zum Beispiel koennte es sehr nuetzlich sein, denn es koennte herben Verlust bedeuten und bei Spielen (RP und aehnliches) macht es Sinn zu vermeiden, das jemand cheated und dadurch allen anderen den Spielspass verdirbt.

LG
Dae
 

Users who are viewing this thread

Zurück
Oben Unten