Hallo, ein AtMega16 verfügt über ein externes SPI Flash. Der AtMega seinerseits kann von einem anderen Steuergerät über ein serielles verschlüsseltes Protokoll angesprochen werden und stellt somit eine Art 'intelligenter Speicher' dar. Die Daten in dem SPI Flash dienen nicht dem AtMega, sondern dem anderen Steuergerät zur Datenablage. Der AtMega verwaltet nur den Zugriff darauf und bedient das Protokoll. Die Kommunikation erfolgt komplett verschlüsselt, nur die Daten selbst sind es nicht. Es wäre also leicht möglich die verschlüsselt empfangenen Daten am SPI-Bus unverschlüsselt abzugreifen. Mein Problem ist, dass der Datenzugriff wahlfrei möglich sein muss. Das heißt, es sollen zu jeder Zeit beliebig viele Bytes von einer beliebigen Adresse gelesen und geschrieben werden können - so wie wenn das SPI Flash direkt an dem anderen Steuergerät angeschlossen wäre. Dies habe ich bisher durch eine einfache XOR-Chiffre gelöst. Ich frage mich aber, ob es nicht bessere Möglichkeiten gibt? Welche Verfahren könnten hierfür noch geeignet sein? Blockchiffre wie AES und XTEA fallen raus, oder? Ich kann ja nicht wahlfrei zugreifen, sondern muss mich immer an die Blockung halten? Oder wäre es generell besser, die Daten auf dem (wesentlich leistungsfähigeren) Steuergerät zu ver/entschlüsseln statt auf dem AtMega? Wie macht man sowas richtig? Gruß, Alex
Alexander I. schrieb: > Oder wäre es generell > besser, die Daten auf dem (wesentlich leistungsfähigeren) Steuergerät zu > ver/entschlüsseln statt auf dem AtMega? Offensichtlich wäre das besser. Moderne Chips haben gerne sowas wie AES in Hardware dabei. Viele Blockchiffres arbeiten "untenherum" auch mit XOR, man müsste also "nur" den passenden Schlüsselstrom generieren - aber auch das braucht auf einem AVR echt Zeit (pun intended).
Wie groß ist dein SPI Flash? Eine Art One-time-pad im Flash des Mega16 würde ein XOR schon stärken. Wenn du dazu noch die Adressen würfelst. Andererseits sei dir im Klaren darüber, dass jemand der physischen Zugriff auf dein Flash hat, mit ganz anderen Werkzeugen an die Arbeit gehen kann. Was passiert im schlimmsten Fall, wenn jemand die Daten entschlüsselt? Lohnt der Aufwand?
Wie groß ist der Flash und wieviele Schreib/Lese-Zugriffe werden gefordert, mit welchem Datendurchsatz? Du kannst ja mit AES z.B. blockweise verschlüsseln, der Nachteil dabei ist, daß Du beim Lesen immer den kompletten Block einlesen und entschlüsseln mußt, beim Schreiben sogar einlesen, entschlüsseln, verändern, anschließend neu verschlüsseln und speichern. Für seltene Zugriffe wäre dies evtl. verschmerzbar.
Im Endeffekt funktioniert es aktuell so, dass der "XOR-Chiffre-Key" (nennt man das 'one-time-pad'?) mit der Adresse und einer Unique-ID gewürzt wird. Sieht also bei jedem Device anders aus, nachdem es an seinen Master in der Produktion 'gebondet' wurde. Die entschlüsselten Daten wären für Diebe grundsätzlich schon interessant, da das Systemverhalten manipuliert werden könnte (Tuning, etc.) Der Zugriff erfolgt nur sehr selten und auch langsam (unter 50kBaud). Man könnte den Speicher als eine Art 'Notfall-Backup' der Systemkonfiguration betrachten, die nur genutzt wird, wenn irgendwo wieder etwas hergestellt werden muss oder durch den Kundendienst gewartet/erweitert wird. Es ist dann nicht so schlimm, wenn der Download mal 10 Minuten dauert. Die Datenmenge bewegt sich im Bereich von 1-2 MByte, wobei meistens nur Häppchen von 50-250 KByte benötigt werden. Die Anzahl der Schreib/Lesezyklen spielt keine große Rolle. Ich schätze, innerhalb einer Betriebsdauer von 20 Jahren auf unter 1000 Speicherzugriffe, davon die meisten nur lesend. Gruß, Alex
> Die Datenmenge bewegt sich im Bereich von 1-2 MByte, wobei meistens nur > Häppchen von 50-250 KByte benötigt werden. AES-128 benötigt auf einem AVR mit 16 MHz pro 75 KBytes ca. 1 s. http://point-at-infinity.org/avraes/
AES ist für mich keine echte Option - ich habe es nur stellvertretend genannt, weil es sehr bekannt ist. Wenn schon Blockchiffre, dann eher sowas wie XTEA. Was bietet sich sonst noch an?
Alexander I. schrieb: > nennt man das 'one-time-pad'? Nein. Entscheidet für ein one-time-pad ist, dass der Schlüssel mindestens so lang ist wie die Daten und nur einmal verwendet wird. Ich gehe mal bei dir davon aus, dass du bei XOR einzelne Wörter immer mit dem gleichen Schlüssel verrechnest. In deinem Fall wären dann gleiche Daten immer gleich verschlüsselt. Kennt jemand einen Datensatz (known plaintext) kann er damit den Schlüssel berechnen und den Rest entschlüsseln.
One-Time-Pad-Verfahren kann er hier vergessen. Wo soll er denn einen Schlüssel geschützt ablegen, der genau so lang ist wie der zu schützende Datensatz und der nur einmal verwendet wird? Für OTP-Verfahren ist ein einziges XOR völlig ausreichend. Weil für jeden Datensatz gibt es einen (gleich langen) XOR-Schlüssel, der Dir aus den verschlüsselten Daten einen beliebigen Quelltext erzeugt. Ich würds mit einer Blockchiffre machen, wegen der recht einfachen Lesbarkeit und weil Schreibzugriffe sehr selten sind. Und wenn die Geschwindigkeit nicht das Problem ist, dann natürlich auch mit einer derzeit als sicher eingestuften Methode wie AES. Den Schlüssel kann man im AVR selbst ablegen, der braucht den AVR nie zu verlassen. Da müssen das schon sehr wichtige Daten sein, damit überhaupt jemand probiert, das zu knacken.
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.