Forum: Mikrocontroller und Digitale Elektronik Sicherheit des Fuse- Bits Software Update möglich?


von Martin Scheer (Gast)


Lesenswert?

Hallo,
ich schriebe hier für einen Internetlosen Mitstudenten.

Ich möchte meinen Code vor unerlaubten auslesen schützen, dennoch aber
die Möglichkeit haben, ein Update zu machen. Jetzt heißt es aber:
Fusebit gesetzt keinen Zugriff, Fusebit gelöscht, Code weg. Wie kann
ich das umgehen, oder muß ich bei jeden Update den gesamten Code wieder
neu schreiben, d.h. er muß in der Updatedatei enthalten sein?

Was ratet Ihr mir?

Soweit mein Kollege, ich hoffe, das ich es richtig wiedergegeben habe.

Vielen Dank für Eure Mühen,
Martin

von Mark Hämmerling (Gast)


Lesenswert?

Salve,

wonach Dein Kommilitone sucht, sind Lock-Bits - nicht Fuse-Bits.
Was genau meint er mit "Updatedatei"?

Mark

von Micha (Gast)


Lesenswert?

sicher meint er das flashen per bootloader über rs232. ich habe auch
schon versucht, mich da schlau zu machen. Habe es aber irgendwie nicht
so ganz verstanden bzw. zum damaligen Zeitpunkt mich nicht gut genug
darum gekümmer: kann ich bei peters bootloader oder per megaload auch
"updaten" ohne das quellcode herrausgefischt werden kann?

von plitzi (Gast)


Lesenswert?

Also bei der Arbeit mit einem Bootloader helfen die Lock-Bits nicht
weiter, da diese ja nur mit einem ChipErase wieder zurückgesetzt werden
können. Über SelfProgramming gibt es (meines Wissens nach) keine
Möglichkeit, ein einmal gesetztes Lockbit wieder zurückzusetzen oder
den Programmspeicher zu beschreiben, wenn der Chip per Lockbit gesperrt
ist. Damit kann nach dem Setzen der Lockbist kein Update mehr erfolgen,
der Bootloader hat sich ausgesperrt. Man kann zwar den Bootloader
selbst vor dem Überschreiben und Auslesen schützenden Schutz der
Applikation muss aber der Bootloader selbst übernehmen.

Leider bieten alle Bootloaderlösungen, die ich mir bisher angesehen
habe, dazu keine Möglichkeit. Wer weiß, wie er den Bootloader startet
und das entspechende Programm dazu hat und dieses eine Möglichkeit
bietet, den Prozessor auszulesen, der kann das auch tun und erhält den
Hex-Code Deiner Applikation (ob er damit viel anfangen kann, steht auf
einem anderen Blatt). Will man das verhindern, so muss man einen
Bootloader/PC-Programm nehmen, welche kein Zurücklesen unterstützt oder
den Bootloder um einen Ausleseschutz erweitern. Letzteres habe ich mit
einem Bootloader für AVRProg/AVR910 gemacht. Den Befehl "Lockbit Mode3
setzen" habe ich umgeleitet und schreibe eine Kennung auf das letzte
Wort im Flash. Die Befehle zum Zurücklesen funktionieren nur, wenn
diese Kennung fehlt. Ist zugegebenermaßen nicht sonderlich orginell,
sicherlich auch nicht besonders sicher(?), aber besser als nichts, es
funktioniert und was praktikableres habe ich bisher noch nicht
gefunden.

Jörg

von Peter Dannegger (Gast)


Lesenswert?

@Jörg

"Will man das verhindern, so muss man einen
Bootloader/PC-Programm nehmen, welche kein Zurücklesen unterstützt"


Mein Bootloader hat keine Auslesefunktion, sondern nur Program und
Verify.

Allerdings ist das kein Schutz, man kann nämlich an einer vermutlich
freien Stelle, eine Ausleseroutine einfügen, die einen Dump über den
kompletten Flash sendet.


Man müßte also über ein Magic auch das Schreiben blockieren und ein
zusätzliches Erase-Kommado einbauen, welches das Magic als letztes
löscht.


Peter

von Marc Gauger (Gast)


Lesenswert?

Mal ne blöde Frage aber wie läuft das Verify ab? Ließt der den
Programmcode nicht noch mal aus und schick ihn zurück zum Pc und der
vergleicht des dann mit dem was er geschrieben hat? Denn dann hat der
Bootloader ja eine Auslesen-Funktion. Und wenn der Bootloader das
Verify macht und die Leitung so schlecht ist, dass einen Fehler zweimal
verschickt dann wird der µC ja falsch programmiert oder irr ich mich?

von Scheintod (Gast)


Lesenswert?

Hallo,

Also eine der besten Möglichkeiten so etwas sicher hinzubekommen ist
die AN avr231 mit aes verschlüsselung. bzw die avr230 mit des
Verschlüsselung.

Dabei ist es sogar möglich, das Objectfile auszuliefern und den
entgültigen Benutzern das Updaten zu erlauben. Wichtig ist ja nur 1.
das obj nicht lesbar zu haben, 2. den avr nicht auslesbar zu machen &
3. nicht zu erlauben, dass Teile des flashes mit einem fremden Progrmm
überschrieben werdne.

Wie's exakt geht steht in der avr230/1. Wies mit dem gcc geht weiss
ich leider auch nicht. Siehe mein anderes Post von eben.

Schoene Gruesse,

Scheintod

von Peter Dannegger (Gast)


Lesenswert?

@Marc

"Und wenn der Bootloader das
Verify macht und die Leitung so schlecht ist, dass einen Fehler
zweimal
verschickt dann wird der µC ja falsch programmiert oder irr ich
mich?"


Stimmt, das kann passieren, wenn kein Baudratenquarz aber eine hohe
Baudrate verwendet wird.

Deshalb kann man noch die CRC-16 überprüfen, die über alle empfangenen
Bytes berechnet wird.

Das Verify ist mit dem Schreiben identisch, bloß daß bei Ungleichheit
nicht geschrieben wird, sondern ein Fehler gemeldet wird.

Im Prinzip ist damit ein Auslesen möglich, indem man erst nur das 1.
Byte verified bis kein Fehler kommt, dann das 2. usw., dauert dann eben
etwas.

Auf Geheimhaltung habe ich keinen Wert gelegt, da ich den Bootloader
nur für die Entwicklung verwende.


Peter

von Martin Scheer (Gast)


Lesenswert?

Hallöle
So, erstmal von meiner Seite Danke und der Seite meines Kommolitonen!

Also: Das Projekt ist für die Uni, und ein Präzisionsmessgerät, was die
Genauigkeit, nach seiner Aussage, von einer von Ihm entwickelten
Differentialgleichung erreicht. Selbst verstanden habe ich das nicht,
wir sind zwar im selben Semester, aber in Mathe war er schon immer
besser. Nun scheint es so zu sein, daß er die DGL weiterentwickeln
will, und somit die Updatefähigkeit erhalten möchte, andererseits
natürlich keiner an sein geistiges Wissen dran soll. Und ich sag euch
eins, eine Uni ist ein Wissenspool sondersgleichen...

Die Updatedatei soll die vorhandene DGL erweitern und, falls nötig,
komplett ersetzen können (das ist der Hauptwunsch). Weiterhin soll
zweitrangig  Anpassungen des Messverfahrens gemacht werden.

Ja, das umschriebt die Aufgabe

Schöne Grüße, Martin

von Scheintod (Gast)


Lesenswert?

Hi.

Der aes/des bootloader ist genau das ding das er sucht. Bin zwar selber
nicht begeistert von übermäßiger Geheimniskrämerei, muss mich gerade
aber auch notgedrungen damit beschäftigen.

Schau mal hier unter avr231/avr230:
http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

Schoene Gruesse,

Scheintod

von Peter Dannegger (Gast)


Lesenswert?

@Martin,

"Das Projekt ist für die Uni, und ein Präzisionsmessgerät, was die
Genauigkeit, nach seiner Aussage, von einer von Ihm entwickelten
Differentialgleichung erreicht."


Ein beliebter Anfängerfehler ist es, Genauigkeit mit Auflösung zu
verwechseln.

Als Praktiker merkt man aber schnell, daß die meisten "genialen"
Ideen auch nur mit Wasser kochen.


Die Hauptarbeit ist daher nicht die "geniale Idee", sondern der
Nachweis, daß sie auch wirklich was taugt.

Im Falle der Ermittlung der Genauigkeit gehört sich zu allererst eine
fundierte Fehlerabschätzung, d.h. die Ermittlung sämtlicher
Fehlerquellen (Temperatur usw.) und deren Einflußverhalten.

Und dann der exakte rechnerische Nachweis, daß unter sämtlichen
möglichen Worst-Case Bedingungen der maximale Fehler nicht über den
Grenzen für die geforderte Genauigkeit liegt.


Betrachtet man z.B. eine 10Bit-ADC, so ist ein Fehler von einem LSB nur
0,1% groß (1/1024).
Durch nachfolgende Mathematik (z.B. Differentialgleichungen) kann sich
bei ungünstigen Koeffizienten dieser Fehler aber bis auf 10% oder mehr
aufschaukeln.


Peter

Bitte 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
Noch kein Account? Hier anmelden.