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?
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.
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 untergebrachtHans 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.
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
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?
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.
