AVR Bootloader mit verschlüsselung

[frank (Gast)]

Ich suche einen Bootloader für Atmel Avrs.

er sollte folgendes können:
1. programmcode ins flash laden der empfangene code sollte dabei
entschlüsselt werden.
2. programmcode verifizieren. Dh den code mit dem empfangenen
vergleichen und ausgeben ob richtig oder falsch
3. max 512byte gross sein.

Gibts da was fertiges?

[Alex Trusk (Gast)]

http://www.atmel.com/dyn/products/app_notes.asp?family_id=607
appnotes "AVR230", "AVR231" und "AVR236"

[Alex Trusk (Gast)]

ok, ich seh grad, die brauchen beide ca 2k flash. effizienter wird mans
aber nicht umsetzen koennen, ausser mit einem anderen algorithmus. wie
"sicher" das in 512bytes codeumfang werden kann, ist allerdings die
andere frage...

[Nobody (Gast)]

Ich würde die Bits innerhalb der Bytes etwas herumwürfeln und dann noch
die Bytes innerhalb eines Blocks verteilen. Das ist dann zwar keine
"sichere" Verschlüsselung, dürfte aber einiges Kopfzerbrechen
bereiten und ist mit ein paar Bitschiebebefehlen realisierbar.
Also die Frage an Frank: Wie "sicher" muss diese Verschlüsselung
sein?

[Christoph Söllner (Gast)]

there is no worse security than obscurity...

[Hagen R. (hagen)]

Musst ja nicht DES oder AES benutzen. Schau dir mal RC4 genauer an. Das
ist in Hochspache ein Source aus 10 Zeilen und RC4 (Ron Rivest) ist ein
anerkannter Kryptograph. Davon abgesehen hat RC4 den Vorteil das es eine
Stromverschlüsselung ist, also Byteweise arbeiten kann (nicht Blockweise
wie DES oder AES).

Gruß Hagen

[Hagen R. (hagen)]

Oder du benutzt eine weniger sicherer Verschlüsselung, zb. ein Self
Shrinking Linear Feadback Shift Register. In der CodeLIb hir solltest
du meinen GLCD Source für das Nokia Display finden. Darin enthalten ist
ein solcher Generator der primär als guter Zufallgenerator dient. Mit
leichten Änderungen im Source (über DEFINES) kannst du diesen auch als
Stromverschlüsselung einsetzen, mit 126 Bit effektiver Sicherheit. Der
ASM Source benötigt ca. 72 Bytes !!

Gruß Hagen

[mthomas (Gast)]

Und noch eine "Schlagwort": XTEA - sollte sich auch in 512 bytes
unterbringen lassen. Habe vor einiger Zeit einen BL mit XTEA gebastelt,
allerdings mit AVR109-Protokoll und "Rueckverschluesselung" im AVR
fuer Verify mit AVRProg und damit groesser als 512bytes.

[Hagen R. (hagen)]

Problem mit TEA oder eXtended TEA ist das es nicht kryptographisch
analysiert wurde. Es ist ein anonymer Vorschlag für eine
Verschlüsselung, keiner hats math. analysiert und keiner weis wer ihn
entworfen hat mit welchen Hintergedanken ;)

RC4 ist von Ron Rivest und mit RC4 gibts nur ein Problem: man sollte in
den eigenen Source ihn nicht RC4 benennen sondern anders. Der Name ist
wohl gechützt der Rest ist auf geheimnissvolle Weise aus den
Hochsicherheitscomputern der Firma RSA Inc. "entnommen" worden ;)

Gruß Hagen

[Hagen R. (hagen)]

XTEA hat die enormen Vorteile das die Größe der lokalen Variablen sehr
sehr klein ist (8 Bytes im Gegensatz zu > 256 Bytes beim RC4) und das
die innerste Verschlüsselungschleife wirklich nur aus 4 Zeilen Source
besteht. Ist also sehr effizient und leicht auf AVRs zu portieren. Ok,
RC4 ist nun auch nicht viel komplizierter.

Gruß Hagen