Hi, Wie im Betreff zu sehen, möchte ich gern was verschlüsseln. Und zwar will ich von ne embedded Gerät über HTTP Daten an eine Webseite schicken. Das für MICH einfachste ist die GET Methode wobei aber alle Werte in Klartext mit der URL übertragen werden. Daher würde ich die Daten n bissl verschlüsseln wollen, zumal auch User und PW mit dabei sind. Da ich aber nicht so viel Rechenleistung zur Verfügung habe, hab ich mir folgendes überlegt: Statt ...?name=wert&name2=wert2&... Alles nach dem Fragezeichen mit einem einfach Algorithmus zu verschlüsseln ( wird gut lang, 23 Wertepaare ) Der verwendete Schlüssel wird nach der Verschlüsselung an nur Sender und Empfänger bekannten Positionen im GET-String untergebracht Die letzten 10 oder 100? Schlüssel werden von der Webseite nicht mehr akzeptiert Und vor dem Verschlüsseln wird noch eine Checksumme an die zu verschlüsselnden Daten angehängt und die erfolgreiche Entschlüsselung zu überprüfen. Irgendwie so hab ich mir das vorgestellt, macht das Sinn oder ist das zu schwach? Wie gesagt es sind zu viele Daten/Zeit und zu wenig Rechenpower für AES. Für andere Ideen oder Fragen, wär ich auch offen und dankbar. MfG Hans
Hans M. schrieb: > Der verwendete Schlüssel wird nach der Verschlüsselung an nur Sender und > Empfänger bekannten Positionen im GET-String untergebracht Damit ist das Security By Obscurity und somit Quatsch. Kannste dir imo gleich sparen. Wie wär's mit SSL?
Das dürfte das nicht spezifizierte "embedded Gerät" möglicherweise überfordern, könnte ja ein AVR sein ...
Was soll denn vor wem geschützt werden? Darf es einen gemeinsamen Schlüssel geben? Warum willst du den Schlüssel mit übertragen kannst du ihn nicht beiden Seiten direkt bekannt machen?
Ui das ging ja fix ;) Die Hintergedanken waren: evtl mehrere Geräte an eine Webseite Durch die wechselnden Schlüssel werden Attacken durch wiederholen erkannt Da Schlüssel und posi wechseln wird es schwerer Muster zu erkennen. Aber hab grad gesehen, das bei GET laut spec bei 255 Zeichen Schluss ist. Jup, isn mega2560/16mhz an nem wiznet.
@Peter Sind eigentlich nur Temperaturen und loging für die hp! Aber im SMART-Zeitalter sind einige Gedanken zur Sicherheit doch nie fehl am Platz ;)
Wenn es nur darum geht Werte zu übertragen und festzustellen ob diese verändert wurden dann könnte man auch HMAC (http://de.wikipedia.org/wiki/Keyed-Hash_Message_Authentication_Code) benutzen. Du hast aber auch noch was von Benutzername und Passwort geschrieben. Eventuell kann man hier auch ein einfaches Challenge-Response Verfahren benutzen. Für beides braucht man keine echte Verschlüsselung sondern nur eine Hash-Funktion.
Hallo, Rufus Τ. Firefly schrieb: > Das dürfte das nicht spezifizierte "embedded Gerät" möglicherweise > überfordern, könnte ja ein AVR sein ... Da gibt's doch was (nein, nicht von Ratiopharm): http://avrcryptolib.das-labor.org/trac/wiki/AES Keine Ahnung, ob (und wie performant) das funktioniert, aber wenn ich mich recht entsinne, war eines der Designziele des AES-Algorithmus ein besonders geringer Ressourcenverbrauch, um ihn auch in limitierten Umgebungen wie Smartcards einsetzen zu können. Ein weiterer Vorteil dieses gebräuchlichen Algorithmus ist, daß es serverseitig fertige Entschlüsselungsroutinen gibt. HTH, Karl
Joar, als Nicht-Cryptologe liefert das auch gleich die Garantie mit die Primitive falsch und unsicher zu benutzen. Als normaler Programmierer bitte nie Crypto-Primtive nutzen, nie Crypto-Protokolle implementieren yet designen, sondern nur fertige und für die Architektur geprüfte Implementierungen verwenden. Danke.
Hans M. schrieb: > Der verwendete Schlüssel wird nach der Verschlüsselung an nur Sender und > Empfänger bekannten Positionen im GET-String untergebracht Hans M. schrieb: > Aber hab grad gesehen, das bei GET laut spec bei 255 Zeichen Schluss > ist. Und wie lange braucht ein moderner Computer 254 Möglichkeiten durchzuprobieren? -> Quatsch
NSA schrieb: > Und wie lange braucht ein moderner Computer 254 Möglichkeiten > durchzuprobieren? Mit einem 254 Zeichen langen String kann man nur 254 Möglichkeiten codieren? Faszinierend.
> Hans M. schrieb: > Aber hab grad gesehen, das bei GET laut spec bei 255 Zeichen Schluss > ist. Wo denn? Kenne nur Empfehlungen aber kein hartes Limit. Wenn du alle beteilgten Parteien unter Kontrolle hast gibt es kein Limit, aber dann bräuchtest du wohl keine Verschlüsselung. Ansonsten eben SSL.
Rufus Τ. Firefly schrieb: > NSA schrieb: >> Und wie lange braucht ein moderner Computer 254 Möglichkeiten >> durchzuprobieren? > > Mit einem 254 Zeichen langen String kann man nur 254 Möglichkeiten > codieren? > > Faszinierend. Nein, aber man hat nur (254-Schlüssellänge) Positionen, an denen der Schlüssel einkodiert sein kann (der OP will ihn ja an einer "geheimen" Position mitschicken). Wenn ich den OP richtig verstanden habe, dann will er Benutzername, Passwort und ein paar Messwerte übertragen. In diesem Fall ist eine einfache, halb-sichere Methode, den Benutzernamen im Klartext zu übertragen und die Messwerte + Checksumme mit dem Passwort symmetrisch zu verschlüsseln. Der Server kann dann mit dem hinterlegten Passwort entschlüsseln und über die Checksumme feststellen, ob der Schlüssel (also das Passwort) korrekt war. Allerdings hängt auch hier die erreichbare Sicherheit von der Wahl und Implementierung des Verschlüsselungsalgorithmus ab (und natürlich von dem Passwort, welches möglichst nicht woanders genutzt werden sollte, falls sich die Implementierung als anfällig erweist). Wenn der OP allerdings auf dem Server keine Benutzerverwaltung möchte (bzw. keine Passwörter hinterlegen möchte), dann sollte er sich mit den Methoden des sicheren Schlüsselaustausches vertraut machen. Um das Mithören des Schlüsselaustausches zu verhindern muss dann eine asymmetrische Verschlüsselung zumindest für den Schlüsselaustausch implementiert werden (wobei hier die Rechenzeit eher kein Problem darstellt, da dies ja nur beim ersten Anschluss an den Server ausgeführt werden muss). Schöne Grüße, Martin
Hans M. schrieb: > Der verwendete Schlüssel wird nach der Verschlüsselung an nur Sender und > Empfänger bekannten Positionen im GET-String untergebracht Also ist dann ja die Position der Schlüssel (da nur diese Geheim ist) und vermutlich durch Analyse sehr leicht zu ermitteln. Außerdem ist dein Verfahren nicht gegen Replay und MITM Attacken gesichert. WENN du das also willst (z.B. für den Zugriff von außen) wäre es wohl besser einen SSL-Proxy davorzuschalten der die Verschlüsselung übernimmt und die Daten entschlüsselt weiterleitet. Wobei man sich gerade bei GET auch Gedanken machen muss über so Dinge wie Browserhistory etc.
Warum bastelst Du dir nicht noch nen kleinen xMega dazu welcher dir den String mit AES verschlüsselt?
wie wärs damit? sender und empfänger haben ein shared secret, z.b. eine bytefolge (32byte). der sender schickt dem empfänger eine zufällige bytefolge (auch 32 byte), der empfänger concateniert diese 32byte mit den 32byte des shred secret und bildet aus den jetzt 64 byte einen hash (sha1-256, je nachdem wie breit die nutzdaten sind). in diesen hash xored der empfänger die daten und schickt das ergebnis dem sender zurück, der das entschlüsseln kann.
Alex W. schrieb: > Warum bastelst Du dir nicht noch nen kleinen xMega dazu welcher dir den > String mit AES verschlüsselt? weil er dann immer noch das gleiche Problem hat - den Schlüsselaustausch. AES sollte auf jeden Atmel möglich sein, wenn es nur um ein paar Bytes geht.
Erstaunlich wie mit den Resource verfahren wird. Eine Verschluesselung muss nicht absolut sicher sein, sondern nur so sicher, dass es niemand probiert. Oder fast niemand probiert. Wie gut auch immer die Benutzer verknuepft sind. Fuer ein paar nichtssagende Temperaturen sollte ein dynamisch generiertes Polynom eine genuegend gute Verschluesselung bieten. Ein statisches XOR reicht nicht wenn der Benutzer die Temperaturen, sprich des Sensor manipulieren kann. Dasselbe wie mit dem Baeren, vor dem man wegrennen muss. Man muss nicht schneller wie der Baer sein, nur schneller wie der Kollege. Das Haus muss nicht absolut sicher gegen Einbrecher sein, nur sicherer wie das Haus des Nachbarn. :-)
Im Zeitalter wo alle nen DynDNS laufen haben, wir wäre es auf der Webseite zu prüfen, welche IP in deiner DynDNS hinterlegt ist und diese IP mit dem Absender der Daten zu vergleichen? Dann sendest du zwar immernoch alles im Klartext (wenn es auf einer Webseite landet, wird das aber ja eh jeder abrufen können?) aber der Server kann immerhin den Absender "überprüfen"... Und Daten von anderen IPs kannst du ja einfach ablehnen bzw. so tun als würdest du sie toll finden und dann verwerfen - je nachdem ob du überhaupt einen Rückgabewert hast...
Es gibt auch richtige Cipher, die wenig Ressourcen (RAM/Flash) brauchen, z.B. XXTEA. Nimm doch den, der hat auch variable Blockgröße, daher ist ein mode of operation nicht zwingend erforderlich. Du solltest aber noch einen IV/Nonce nutzen und Authentifizierung wäre auch nicht übel. Am besten bekannte Verfahren nutzen. Kryptographie ist äußerst komplex und ohne besondere Kenntnisse sollte man nie selbst irgendwelche "Lösungen" entwickeln.
Solange es nur eine Lösung ist, die 1-2 mal für etwas wenig wichtiges genutzt wird, ist Security by Obscurity kombiniert mit etwas trivialem wie XOR Verknüpfung gar nicht so schlecht - sogar besser als eine nicht mehr zeitgemäßer Standard mit zu geringer Schlüsselbreite.
XTEA ist auch ein netter Algorithmus: Implementation frisst nicht viel Platz und relativ schnell ist er auch. Laut Wikipedia auch ziemlich sicher. LG Tom
AES auf Atmel AVR: http://www.heise.de/developer/artikel/Cryptography-Engineering-Teil-4-AES-auf-AVR-ATmega-1442338.html
Ich habe XTEA mal im Simulator getestet. Damit das ganze verwertbar ist muss es mit Base64 codiert werden. Beispiel: Key: 1234567812345678 Text: Test 1 2 3 4 5 6 7 8 Base64ChipherText: rnFZJgJ6qL2PCLslL22Fq4vKeYw2V:c;pqRiIf3esCQ= Bei einem PHP-Skript auf der Seite http://www.php-einfach.de/sonstiges_generator_xtea.php#ausgabe kann man XTEA mit Base64 ebenfalls ver und entschlüsseln. Das Ergebnis von einem Bascom-Crypt ist aber nicht dekodierbar (umgekehrt auch nicht). Wo liegt der Fehler? Ist : rnFZJgJ6qL2PCLslL22Fq4vKeYw2V:c;pqRiIf3esCQ= Soll: AAQAQ1S5A1gyh1TS0/sFGopLsIplkL2h4kwxO3ukwto= Wo liegt der Unterschied?
Hans M. schrieb: > Daten n bissl verschlüsseln wollen In Filmen hatten Leute nur eine zerissene Postkarte.
Hi und wieder da ;) Sry, war mit lesen und testen der Vorschläge beschäftigt. Zu Erst einmal vielen Dank für die vielen Antworten! Nun noch etwas zum Hintergrund: Zur Webseite sollen ein Arduino ( in C programmiert mit Wiznet Chip ) und ein HiLink HLK-RM04 (Openwrt + LUA Script) Verbindung aufbauen und Temperaturdaten schicken. Die XTEA Geschichte geht mit dem Mega und php ganz gut, XTEA und LUA nicht so. AES CBC mit Mega ( bissl zu langsam aber hinnehmbar ) aber mit LUA passt. Nun ist aber das Problem, das PHP kein "native" AES256 kann. Mit Mega und LUA funktioniert AES_enc und AES_dec. Auch untereinander, nur in verbindung mit php kommt Mist raus. Die Standart mccrypt macht wohl iwie anderes AES... :( Aber ich bleib dran, iwie klappt das schon ;)
Ach du und der ursprüngliche Plan war den Schlüssel nicht am Stück mit zu schicken, sondern ihn in 8Bit zu zerlegen und im POST_String an dem Sender und Empfänger bekannten Positionen zu hinterlegen.
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.