Hallo, ich hatte vor auf dem Controller eine hybride Verschlüsselung zu realisieren. Dann habe ich hier Beitrag "Public Key Cryptography mit Mikrocontroller?" gelesen, dass es keinen Sinn macht eine asymmetrische Verschlüsselung zu implementieren. Ist es denn so nicht sicherer? (http://de.wikipedia.org/wiki/Hybridverschl%C3%BCsselungsverfahren) Bitte um begründete Antworten. Gruß Faruk
Die Verschlüsselung im verlinkten Thread ist nicht nur nicht machbar, sondern wie dort erklärt überhaupt nicht sinnvoll. Der PC könnte sich gegenüber dem uC authentifizieren mittels asymmetrischer Kryptographie, wie es bei SSH getan wird - das Protokoll an sich wird dabei nicht verschlüsselt. Allerdings könnte man auch hierbei die Software für den PC Reverse-engineeren um an den Schlüssel zu kommen. Schreib lieber mal genauer, welchen zweck die Verschlüsselung hat.
Hallo, zunächst einmal danke für die schnelle Rückmeldung. Ich bin zurzeit Praktikant in einer Firma und es soll eine abhörsichere Kommunikation (Steuerbefehle) zwischen uC und dem PC realisiert werden. Ich arbeite am uC. Eine symmetrische Verschlüsselung(aes) mit avr-cyrpto-lib hat schon super geklappt. Das genügt aber nicht, da sonst der Key immer fest sein müsste oder bei der Übertragung das Risiko eingegangen werden muss, das der Schlüssel abgefangen wird. Daher möchte ich einen privaten Schlüssel fest in den uC einkompiliern mit dem ein Sessionkey entschlüsselt werden kann, wie in dem wiki-link beschrieben. In der Avr-Crypto-Lib gibt es auch eine RSA Implementierung. Diese habe ich mal ausprobiert und musste feststellen, dass dies extrem lange (15min.) dauert. Deswegen frage ich... ist es prinzipiell machbar 16 bzw. 32Byte mit RSA auf dem uC zu decodieren (in akzeptabler Zeit)? Mit Reverse-Engeneering könnte man doch nur an den Sessionkey kommen, der dann verfallen würde, oder liege ich falsch? Gruß Faruk
Faruk Gürlek schrieb: > Mit Reverse-Engeneering könnte man doch nur an den Sessionkey kommen, > der dann verfallen würde, oder liege ich falsch? wenn sich jemand wirklich arbeit machen will löst er das chipgehäuse auf und bonded den flash/eeprom einfach auf einem wafer.. schon kommt er an den ganzen quellcode - selbst wenn es einen verschlüsselten bootloader gibt hat man den mit der heutigen rechenpower in sekunden bis minuten geknackt. für einen 8bit controller sollte AES reichen, wenn es wirklich komplexer wird sollte es schon SSL mit zertifikaten sein - auf einem leistungsfähigem ARM kein problem
In dem Fall einer RE der PC Software hat Mallory alles Wissen, welches Bob (die PC Software) hat. Alice (der uC) kann somit mit keiner Challenge Bob von Mallory unterscheiden. Ein solches System kann nicht abgesichert werden. Mallory wird in der Lage sein einen eigenen Kanal zu öffnen, bzw dem Schlüsselaustausch zu folgen. Dabei ist es egal ob Mallory das Wissen von Alice besitzt (also ob Session- und privaten Schlüssel. Der Betrachtungsfall muss also für "sichere Kommunikation" anders ausgeschlossen werden. Nichteinmal die Authentifizierung von Alice (obwohl ihr Schlüssel nicht kompromitiert wurde) ist mehr gewährleistet, da Mallory ebenfalls in einem Man-in-the-middle Szenario als Relay für diese fungieren kann.
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.