Hallo, ich habe hier ein Projekt, in dem ich auf einem Controller einen Webserver entwickele. Es soll möglich sein auf diesen Webserver von dem Internet aus zuzugreifen. Die DATEN die vom Webserver aus gesendet werden, sollen VERSCHLÜSSELT werden. Meine Frage ist nun, ob es Verschlüsselungsverfahren gibt die auch ein Mikrocontroller händeln kann. vorhandene Hardware NEC V850 50 Mhz 128kB RAM SSL Verschlüsselung ist wegen des hohen Rechenaufwands nicht realisierbar. Ich freue mich auf eure Antworten. Gruß Micha
Michael schrieb: > Meine Frage ist nun, ob es > Verschlüsselungsverfahren gibt die auch ein Mikrocontroller händeln > kann. klar XOR, ceasar, ...
SSL hat halt den Vorteil, daß es von den WebBrowsern auch entschlüsselt werden kann. SSL erlaubt verschiedene Verschlüsselungsalgorithmen, ich nehme an, du hast alle bereits ausgeschlossen. Wenn es unwichtig ist, daß jemand das auch entschlüsseln kann weil du es eh proprietär machst, kannst du alles senden, möglichst dann nicht als kaputte HTML Seite sondern verpackt als XML RPC Request wie AJAX oder so. Dann würde ich aber nicht mehr von einem WebServer sprechen.
Je nach Datenmenge geht AES per Software. Manche Controller haben dies sogar als Peripheriemodul in Hardware mit an Bord, dann gehts natürlich auch mit grösseren Datenmengen.
Wie willst Du drauf zugreifen ? Mit einem Browser ? - dann geht wohl nur SSL. Mit einem anderen Client ? - dann kannst Du alles was Du willst implementieren. Symmetrisch, Asymmetrisch - Algorithmus of your choice - und was die HW hergibt.
Für SSL kannst Du dir mal MatrixSSL anschauen. Vielleicht wär das auf deinem Controller möglich. Das wurde auf einem Cortex M3 schon gemacht und funktionierte gut. Gruß Stumpf
SSL ist doch nur ein Protokoll?! Je nach Version werden eine viele symetrischer Verschlüsselungen unterstützt. AES kann man mit 8bit AVRs machen... Ist der V850 nicht ein 32bit Teil, auf dem sogar µLinux läuft? Wofür dann noch den Webserver selber schreiben?
Einfach auf jedes byte einen (oder jede beliebige andere Anzahl) oben drauf. So schnell knackt man das auch nicht.
Sven H. schrieb: > Einfach auf jedes byte einen (oder jede beliebige andere Anzahl) oben > drauf. So schnell knackt man das auch nicht. Das soll wohl ein schlechter Witz sein! Sogar Cäsar lässt sich sich noch per Hand ohne Pc in Minuten knacken.
wenn man jetzt die verschiebung nach einer bestimmten funktion/schlüssel ändert, dann hat man sogar schon ein Upgrade ala Vigenère ich denke der sollte für einfache datensicherheit dann auch reichen wenn du natürlich hoch sensibele daten übertragen willst, dann wird das noch lustig^^
Wie sicher ist die Verschlüsselung xtea? Ich konnte bei google nichts handfestes finden...
Stell dir XTEA einfach als eine etwas modernere* DES-Verschlüsselung vor. Okay, meine Kollegen würden mich verprügeln wegen dieser groben Vereinfachung, aber so in etwa kommt es für dich als Implementierer raus. *Modern = ohne Weak Keys, ohne problematisch gewählte S-Boxen, recht einfach zu coden, dafür aber eine hohe Rundenzahl = "sieh zu daß du die Runden in Assembler codest und auf Laufzeit optimierst, sonst wird das recht lahm". Sicherheitsmäßig liegt es aber definitv noch unter AES, Serpent und Twofish. Schließlich ist die Menge aller Blöcke bei einer Blockgröße von 64bit in absehbarer Zeit darstellbar. Andy
Andy P. schrieb: > Modern = ohne problematisch gewählte S-Boxen Soweit ich weiß sind die gewählten S-Boxen bei DES optimal gegen bekannte Angriffe. Wie kommst du darauf dass diese problematisch gewählt sind? Etwa allein von der Herkunft der S-Boxen?
Andy P. schrieb: > Sicherheitsmäßig liegt es aber definitv noch unter AES, Serpent und > Twofish. Schließlich ist die Menge aller Blöcke bei einer Blockgröße von > 64bit in absehbarer Zeit darstellbar. Das ist aber nur dann ein Problem, wenn der Algorithmus im ECB-Modus (Electronic Code Book) eingesetzt wird, in anderen Modi (z.B. CBC oder Counter) hat die Blockgrösse deutlich weniger Einfluss auf die Sicherheit. Einen sicheren Cryptoalgorithmus einzusetzen ist generell nur die halbe Miete. Durch Fehler im Protokolldesign kann das Ergebnis trotzdem trivial knackbar sein. Bestes Beispiel: WEP. Der dabei eingesetzte Algorithmus (RC4) an sich gilt AFAIK bei korrekter Implementierung nachwievor als sicher. Jedoch wurden beim Design des WEP-Protokolls derart grobe Fehler gemacht, dass WEP-gesicherte WLANs heute fast im Vorbeigehen geknackt werden können. Schon kleine Änderungen (verwerfen der ersten paar Bytes des generierten Schlüsselstroms) hätten WEP erheblich sicherer gemacht. Wenn man selbst nicht absolut sattelfest in Bezug auf Crypto ist, sollte man immer jemanden mit der entsprechenden Erfahrung einen Blick auf das gesamte Protokoll werfen lassen. Andreas
Hier mal was zur Sicherheit von RC4 http://blog.moremoremore.de/zur-sicherheit-von-rc4-ist-rc4-unsicher/
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.