Hallo, ich bin dabei ein Pärchen aus einer Mikrocontroller-Firmware und einer PC-Software zu bauen, deren Kommunikation verschlüsselt ablaufen muss. Der hierzu notwendige gemeinsame Schlüssel (die Verschlüsselung ist symetrisch) muss logischerweise zur Laufzeit dem Programm zur Verfügung stehen. Jetzt möchte ich eigentlich nicht, dass im Quelltext irgendwo der Schlüssel zu sehen ist, denn dann ist die Chance groß, dass zufällig oder fahrlässig der Schlüssel mal irgendwohin kopiert wird. Für die PC-Software habe ich gedacht, dass der Schlüssel in einer Datei liegt, die mit einem weiteren Schlüssel verschlüsselt ist und vom Benutzer geladen werden muss. Das ist zwar lästig, aber es gibt eben nie eine Datei in der der Schlüssel in Klarschrift drin liegt. Selbst wenn das Benutzerpasswort auf irgendeinem Zettel am PC steht, wer die Datei versehentlich an ein E-Mail ranhängt wird nicht auch noch ein Foto des "Gelben Zettels" beifügen. Aber bei der Firmware habe ich keine Idee wie ich das machen könnte. Man könnte den Schlüssel bei der Inbetriebnahme des Systems eintragen, aber dann landet er in einem EEProm/Flash-Speicher welcher ggf. überschrieben werden könnte, insofern wäre es wirklich sicherer, der Schlüssel wäre im ausführbaren Code vorhanden. Kann man das mit einem Linker-Script machen, so dass der Schlüssel nur im HEXfile aber nicht im Quelltext drin ist? Also so ähnlich wie im PC Programm wo der Benutzer des Compilers beim Erzeugen des HEX-files erstmal sein eigenes Passwort eingeben muss? Vielen Dank für Eure Ideen! Gruß Ekkehard
Spricht was dagegen den Schlüssel auf dem Device zu generieren? Dazu kann man eindeutige IDs benutzen. Dann kann der Schlüssel für den PC einmalig mit einem Programm und dem angeschlossenen Gerät generiert werden. Dann hast du keinen Schlüssel auf dem Gerät abgelegt, dieser wird immer beim Starten frisch generiert.
Ekkehard D. schrieb: > ich bin dabei ein Pärchen aus einer Mikrocontroller-Firmware und einer > PC-Software zu bauen, deren Kommunikation verschlüsselt ablaufen muss. > Der hierzu notwendige gemeinsame Schlüssel (die Verschlüsselung ist > symetrisch) muss logischerweise zur Laufzeit dem Programm zur Verfügung > stehen. Da ist das Problem. Warum arbeitest Du nicht asymmetrisch? > Aber bei der Firmware habe ich keine Idee wie ich das machen könnte. > Man könnte den Schlüssel bei der Inbetriebnahme des Systems eintragen, > aber dann landet er in einem EEProm/Flash-Speicher welcher ggf. > überschrieben werden könnte, insofern wäre es wirklich sicherer, der > Schlüssel wäre im ausführbaren Code vorhanden. Kann man das mit einem > Linker-Script machen, so dass der Schlüssel nur im HEXfile aber nicht im > Quelltext drin ist? Also so ähnlich wie im PC Programm wo der Benutzer > des Compilers beim Erzeugen des HEX-files erstmal sein eigenes Passwort > eingeben muss? Safe ist das Verfahren ja sowieso nicht, da der Key immer unverschlüsselt im RAM liegt. Aber darum geht es Dir ja nicht, also ein paar Ideen: Nimm für die Zusammensetzung des Master Keys nichtssagende Variablen, z.B strA, strB, iX. Fülle die Variablen an unterschiedlichen Zeilen mit beliebigen Werten. XOR'e das ganze mehrmals in dem Du die chars nach ASCII Werte unberechnest. Konkateniere dann das Ganze an unerwarteten Stellen. Wenn Du dahinter // define Master key schreibst kann es eh jeder lesen wo der Schlüssel berechnet wird, aber er kommt nicht so schnell dahinter wie dieser zusammengesetzt ist. Du kannst auch eindeutige IDs (Hostname, fixe IP, MAC Adresse, etc) nach Ascii Werten umformen und beliebig XORen, quasi eine Pseudo Hash Funktion. Da du einen gemeinsamen Schlüssel brauchst, müssen natürlich beide Seiten die Fix Werte kennen. Wenn es Dein Protokoll vorsieht, könntest Du damit auch eine sehr einfache Diffie Hellman Implementation machen. Dazu müsste der Master Key niemals im Klartext über's Netz. Andere Idee wäre, dass Du die SW den Schlüssel berechnet und an den Cient, die Firmware schickt. Zur Berechnung kannst Du MD5 oder blowfish oder nehmen. Hasht einfach (time(in YYYYMMDD) + GetMacAdress(local)) und das was raus kommt ist der key.
:
Bearbeitet durch User
Philipp G. schrieb: > Da ist das Problem. Warum arbeitest Du nicht asymmetrisch? Was ändert das? Auch asymmetrisch brauchst du einen Schlüssel um dich zu authentifizieren... Philipp G. schrieb: > Nimm für die Zusammensetzung des Master Keys nichtssagende Variablen, du empfiehlst ernsthaft "security by obscurity"?
Michael R. schrieb: > Was ändert das? Auch asymmetrisch brauchst du einen Schlüssel um dich zu > authentifizieren... Aber zum Verschlüsseln einen anderen als zum Entschlüsseln. Das ist ja gerade der Witz dabei (public/secret).
@Michael Reinelt: Und? Wo ist Dein (beserer) Vorschlag? Du scheinst es ja ganz genau zu wissen wie man auf gar keinen Fall machen darf. Also: Lass doch das Licht Deiner Weisheit über uns leuchten...
Michael R. schrieb: > Philipp G. schrieb: >> Da ist das Problem. Warum arbeitest Du nicht asymmetrisch? > > Was ändert das? Auch asymmetrisch brauchst du einen Schlüssel um dich zu > authentifizieren... Das ändert alles, ja. > Philipp G. schrieb: >> Nimm für die Zusammensetzung des Master Keys nichtssagende Variablen, > > du empfiehlst ernsthaft "security by obscurity"? GANZ GENAU - denn darum geht es: Ekkehard D. schrieb: > Jetzt möchte ich eigentlich nicht, dass im Quelltext irgendwo der > Schlüssel zu sehen ist, denn dann ist die Chance groß, dass zufällig > oder fahrlässig der Schlüssel mal irgendwohin kopiert wird Ist alles nur eine Frage, welches Sicherheitslevel Du brauchst. Die Möglichkeiten sind unbegrenzt. Du könntest auch mit Fixwerten im Code arbeiten: PC: iX = 324; iY = 23939; s = (iX + iY) + 3 \ 3.4 Key(s) schickst Du an den Client, der Client rechnet dann das Umgekehrte, und bestimmt so den Masterkey.
Michael R. schrieb: > du empfiehlst ernsthaft "security by obscurity"? Was empfiehlst du? Bis jetzt hast du nur gesagt, wie er es NICHT machen soll. Jetzt wäre es an der Zeit für einen Vorschlag, WIE er es machen soll.
OliverHB schrieb: > @Michael Reinelt: Und? Wo ist Dein (beserer) Vorschlag? Du scheinst es > ja ganz genau zu wissen wie man auf gar keinen Fall machen darf. Also: > Lass doch das Licht Deiner Weisheit über uns leuchten... Kräuterli schrieb: > Was empfiehlst du? > Bis jetzt hast du nur gesagt, wie er es NICHT machen soll. > Jetzt wäre es an der Zeit für einen Vorschlag, WIE er es machen soll. Was ist denn mit euch los? schlecht geschlafen? Freitag? Das Problem ist kein triviales; und ich habe mir erlaubt darauf hinzuweisen dass triviale Lösungen nicht unbedingt zielführend sind... Philipp G. schrieb: > PC: > > iX = 324; > iY = 23939; > > s = (iX + iY) + 3 \ 3.4 wie zum Beispiel diese... Aber: Philipp G. schrieb: > Wenn es Dein Protokoll vorsieht, könntest Du damit auch eine sehr > einfache Diffie Hellman Implementation machen. Dazu müsste der Master > Key niemals im Klartext über's Netz. Das kommt der Sache schon näher...
Michael R. schrieb: > Das kommt der Sache schon näher... Ach? Diffie Hellman wäre eine Option für Dich, aber asymmetrische Verschlüsselung hast Du oben in den Wind geschlagen? Der TO möchte, dass man aus dem Quelltext den Masterkey nicht auf die Schnelle herauslesen kann, so habe ich das verstanden. Das ist die Anforderung. Ansonsten hätte ich ihm eine HSM mit Intrusion detection Level 7 empfohlen, gell?
Philipp G. schrieb: > Ach? Diffie Hellman wäre eine Option für Dich, aber asymmetrische > Verschlüsselung hast Du oben in den Wind geschlagen? ach... mit den vollen Kryptographie-Experten mag ich mich grad nicht rumschlagen, schon gar nicht am Freitag ;-)
Michael R. schrieb: > Philipp G. schrieb: >> Ach? Diffie Hellman wäre eine Option für Dich, aber asymmetrische >> Verschlüsselung hast Du oben in den Wind geschlagen? > > ach... mit den vollen Kryptographie-Experten mag ich mich grad nicht > rumschlagen, schon gar nicht am Freitag ;-) Na, dann danken wir Dir für die wertvollen Tips.
Michael R. schrieb: > ach... mit den vollen Kryptographie-Experten mag ich mich grad nicht > rumschlagen, schon gar nicht am Freitag ;-) Nach deiner Kritik, wie man es nicht machen soll, hätte ich nun vermutet, du sagst dank deiner Fach- und Sachkenntnis endlich mal, wie man es statt dessen richtig macht. Aber nein, nur heisse Luft und Ausflüchte. Danke für's Gespräch.
Philipp G. schrieb: > Na, dann danken wir Dir für die wertvollen Tips. Kräuterli schrieb: > Nach deiner Kritik, wie man es nicht machen soll, hätte ich nun > vermutet, du sagst dank deiner Fach- und Sachkenntnis endlich mal, wie > man es statt dessen richtig macht. Aber nein, nur heisse Luft und > Ausflüchte. ich glaub es ja nicht... und ich wiederhole mich: Michael R. schrieb: > Was ist denn mit euch los? schlecht geschlafen? Freitag? > > Das Problem ist kein triviales; und ich habe mir erlaubt darauf > hinzuweisen dass triviale Lösungen nicht unbedingt zielführend sind... [ ] Philipp kennt den Unterschied zwischen symmetrischer/asymmetrischer Verschlüsselung und (DH-) Schlüsselaustausch Für "wie macht mans richtig" fehlen ein paar wesentliche Infos (welcher Kommunikationskanal? Kabel? IP? UART? Funk? WLAN? Ist MITM ein Szenario? Muss nur Kommunikation sicher sein, oder auch der Client? ...) Für "wie macht mans falsch" sind genügend Infos vorhanden... und offensichtlich genügend "Experten"
Michael R. schrieb: > Für "wie macht mans falsch" sind genügend Infos vorhanden... Aber die Frage vom TO hast du gelesen? ;-) Ekkehard D. schrieb: > Jetzt möchte ich eigentlich nicht, dass im Quelltext irgendwo der > Schlüssel zu sehen ist, Nochmal: Er schrieb "im Quelltext"!
Michael R. schrieb: > Für "wie macht mans richtig" fehlen ein paar wesentliche Infos (welcher > Kommunikationskanal? Kabel? IP? UART? Funk? WLAN? Ist das nicht der Sinn von Verschluesselung, dass das danach egal ist? wendelsberg
Eine sehr einfache und wenig technische Lösung für das Dilemma wäre folgende: Während der Produktion immer mit einem wertlosen Schlüssel aka 012345 arbeiten. Das PC Programm zeigt beim Start dann immer eine Message "Achtung, Testschlüssel wird verwendet!". Erst in dem Auslieferungsbuild wird dann der richtige Schlüssel eingetippt und sichergegangen dass die Message nicht mehr erscheint. Die professionelle Lösung ist in der Tat ein asymetrisches Schlüsselaustauschverfahren wie Diffie Hellman z.B. Nachteil ist dass dies etwas rechenkapazität auf dem Mikrocontroler erfordert und die Implementation nicht grad ohne ist. Vieleicht gibt es aber bereits eine nutzbarer Library die auf eurem Gerät kompilierbar ist!
:
Bearbeitet durch User
wendelsberg schrieb: > Ist das nicht der Sinn von Verschluesselung, dass das danach egal ist? Je nach Anforderung macht es einen Unterschied ob man ein "shared medium" nutzt.
Manche Geräte laden ihre Schlüssel von Chipkarten und werden ggf. in bewachte Käfige gestellt.
Beitrag #5327191 wurde vom Autor gelöscht.
Die heißen Hsm. Unsere löschen sich wenn man laut hustet. Aber nochmal zum Thema: -starke- Verschlüsselung ist IMHO nich gefordert, sondern lediglich Verschleierung des keys im source.
Vielen Dank für die Ideen und Hinweise. Eine asymetrische Verschlüsselung ist mir zu aufwendig, zumal dann das Problem mit dem privaten Schlüssel im Quelltext der Firmware, bzw im HEX-File, immer noch bleibt. Die Idee einen ID-Wert aus dem Zielsystem zu verwenden um damit den Schlüssel zu verändern gefällt mir dagegen gut, u.a. weil so ein Wert tatsächlich zur Verfügung steht. Wie gut der sich tatsächlich eignet muss noch ergründet werden, es ist kein zufälliger Wert. Was mir daran nicht gefällt ist folgendes: - Entweder muss auf der PC-Seite für jedes Gerät ein Schlüssel vorgehalten werden. Zusätzlich muss man dann auch wissen mit wem man gerade redet. - Oder, falls man den ID-Wert hernimmt um den globalen Schlüssel zu dekodieren, jedes Gerät eine spezielle Fimware benötigt. Ggf. lässt sich das aber mit einer geschickten externen Manipulation des HEX-Files oder einem geeigneten Include oder Linker-Script elegant(er) lösen. Das Ziel aber, dass jemand der das Hex-File oder den Quelltext in die Hände bekommt nicht durch bloßes hinschauen, bzw. durch Simulation und Debuggen den Schlüssel herausfindet wäre gegeben. Gruß Ekkehard
Ganz einfach: Das Elektronik-Gerät bekommt ein kleines Display. Auf diesem generiert es einen Schlüssel, der bei der ersten Verbindung mit einem bestimmten Computer in diesem eingegeben werden muss. Neuer Computer oder andere Baugruppe = neuer Schlüsselaustausch
Neben dem Quelltext gibt es noch andere Möglichkeiten, Schlüssel zu hinterlegen. Die gute alte Chipkarte nannte ich bereits. Denkbar wären auch SD Karten oder EEproms, gerne auch im µC integriert.
Bei vielen µP ist es möglich den Speicher vor dem Auslesen zu schützen. Mag ja sein, dass das nicht der Weisheit letzter Schluss ist, aber in den meisten Fällen ist das ausreichend. Hilft natürlich nicht bei der Bewahrung von Staatsgeheimnissen. Aber wer besitzt die schon?
Ekkehard D. schrieb: > Vielen Dank für die Ideen und Hinweise. > Eine asymetrische Verschlüsselung ist mir zu aufwendig, zumal dann das > Problem mit dem privaten Schlüssel im Quelltext der Firmware, bzw im > HEX-File, immer noch bleibt. Glaube du weisst nicht so ganz was asymetrische Verschlüsselung bedeutet! Der private schlüssel wird nicht einmal generiert, sondern jedes mal wenn sich der Controler mit dem PC verbindet! Jede Verbindung verwendet dann einen anderen, privaten Schlüssel. Gespeichert wird er dann nur im Ram und bei Abschaltung somit gelöscht. Der Trick sind die berühmten Falltürfunktionen die man in einer Richtung sehr schnell ausrechnen kann, rückwärts aber extrem langsam. Darum kann auch jemand der den Übertragungsweg komplett abhört, nicht den generierten, privaten Schlüssel ermitteln. Anderserseits: Haben andere leute in eurem Team, Ahnung von Software-Security? Wenn nämlich nicht, dann wird die PC-Software selbst garantiert der deutlich einfacher zu knackende Weg für einen Angreifer sein... Bzw. der wird nicht darauf warten müssen, dass bei euch irgendwas leakt.
:
Bearbeitet durch User
Alex G. schrieb: > Glaube du weisst nicht so ganz was asymetrische Verschlüsselung > bedeutet! Also ein Client der einen Server kontaktieren will, nimmt dessen öffentlichen Schlüssel und verschlüsselt mit ihm eine Nachricht, die einen symetrischen session-key enthält. Diese Nachricht kann der Server mit seinem privaten Schlüssel entschlüsseln. Der Server benötigt also ein Schlüsselpaar bestehend aus öffenlichem und privatem Schlüssel. Wenn mein Mikrocontroller einen solchen Server darstellt, benötigt er einen privaten Schlüssel und muss ihn entsprechend vorhalten. Gruß Ekkehard
Gut, das ist richtig, aber das ist nur eines der möglichen Verfahren. Das ist das Konzept welches man im Web verwendet wo man verlässliche Drittanbieter für den public key hat. Das wäre in eurem Fall aber nicht der richtige Ansatz, da für "Man in the middle" angreifbar wenn es nur 2 Parteien gibt! Hier eine Erklärung zum bereits mehrfach erwähnten Diffie Hallman welcher perfekt für euer vorhaben ist: https://www.elektronik-kompendium.de/sites/net/1909031.htm P.s. schaut mal ob diese library auf eurem Mikrocontroler kompilierbar ist: https://github.com/jedisct1/libhydrogen
:
Bearbeitet durch User
Ekkehard D. schrieb: > und muss ihn entsprechend vorhalten. ... und dafür möchtest Du ihn im Quelltext verstecken..? Manche Bank-Schließfächer brauchen 2 Schlüssel. Erzeuge 100 Schlüssel, die keiner braucht und beschrifte sie überzeugend. Bis die alle durchprobiert sind ist Feierabend. Steganographie ist die Kunst der verborgenen Speicherung.
Ich stimme einigen Vorpostern zu und schlage vor: Schreibe einen bekannte Testschlüssel in deinen Quelltext. Ein Controller, der nur diesen Schlüssel hat, verweigert den eigentlichen Dienst, bis ihm vom PC ein neuer Schlüssel zugewiesen wurde. Diesen schreibt er in sein EEPROM oder Flash (und, wenn das kein Problem ist, löscht ihn bei Werksreset wieder). Damit kannst du vom PC aus neuen Geräten einmalig einen neuen Schlüssel zuweisen. Ob der Schlüssel nun pro Gerät verschieden oder immer gleich ist (oder für je 5 Geräte gleich) ist, entscheidet das PC-Programm. Letzteres kannst du besser aktualisieren als die Firmware des Controllers. Weder PC-Programm noch Controller-Quelltext enthalten den Schlüssel. Kryptographie löst keine Probleme, sie macht aus den Problemen nur Schlüssel-Management-Probleme. Für deine Ursprungsfrage: Ja, das kannst du machen, ist aber nicht unbedingt sicher. Hier zwei Ansätze: a) In deiner Firmware deklarierst du ein (leeres) Array passender Größe im Flash und generierst deine Hex-Datei. Ein weiteres Programm liest - möglicherweise nach Passworteingabe - aus der ELF- oder MAP-Datei die genaue Adresse des Arrays aus und trägt den Schlüssel dann an passender Stelle in die Hex-Datei ein oder generiert eine neue Hex-Datei. b) Du gibst dem Compiler den zu verwendeten Schlüssel auf der Kommandozeile mit (-DKEY=....). Dann steht der Schlüssel zwar im Makefile (bzw. in den Projekteinstellungen), aber immerhin nicht im Quelltext. Das wäre die vermutlich einfachste Variante.
Guten Morgen und nochmals Danke an alle die sich beteiligt haben. Das es keinerlei Bedenken hinsichtlich der Lösung auf der PC-Seite gab (Schlüssel ist durch Passphrase verschlüsselt in Datei/Datenbank etc. gespeichert), bietet sich an, dies auch auf der Mikrocontroller-Seite so zu handhaben. Ich werde also (sehr wahrscheinlich) einen Schlüssel für alle Systeme verwenden. Im Quelltext wird der Platz für den Schlüssel mit einem Dummy gefüllt sein, der Wert im HEX-File wird erst kurz vor dem Programmieren des Zielsystems durch ein anderes Programm gepatcht werden. Dieses Feld wird zudem nur den Schlüssel in verschlüsselter Form enthalten. Das Passwort zum entschlüsseln wird dann eine Geräteabhängige ID sein. Somit enthält kein Quelltext einen Schlüssel, der unwahrscheinliche Verlust eines gepatchten HEX-Files kompromitiert ebenfalls nicht den Schlüssel, denn er ist ähnlich gesichert wie der Schlüssel auf der PC-Seite. Das Einspielen eines neuen Schlüssels (auch einmalig nach Erstinstallation) auf dem Zielsystem finde ich eher ungünstig, denn dann könnte versehentlich oder absichtlich der Schlüssel so geändert werden, dass der tatsächliche Besitzer ausgesperrt ist. Besser erscheint mir, dass der Schlüssel unveränderbar in der schreibgeschützen Firmware zu liegen kommt. Eine schöne Woche! Gruß Ekkehard
Michael R. schrieb: > Für "wie macht mans richtig" fehlen ein paar wesentliche Infos (welcher > Kommunikationskanal? Kabel? IP? UART? Funk? WLAN? Ist MITM ein Szenario? > Muss nur Kommunikation sicher sein, oder auch der Client? ...) Kann mich einem Vorposter nur anschließen: Verschlüsselung sollte es eben unnötig machen genau die von dir genannten Punkte in Betracht zu ziehen. MITM ist in den meisten Fällen ein mögliches Szenario, wo Informationen über eine ausreichend große Strecke - und damit meine ich jetzt nicht von Controller A zu Controller B über 2 cm Leiterbahn auf derselben Platine - über ein beliebiges Medium übertragen werden. Dass der Client auch sicher sein sollte, ergibt sich irgendwie aus der Problemstellung - du baust dir doch auch keine Stahltür ins Haus, die 365 Tage im Jahr offen steht, oder? Michael R. schrieb: > wendelsberg schrieb: >> Ist das nicht der Sinn von Verschluesselung, dass das danach egal ist? > > Je nach Anforderung macht es einen Unterschied ob man ein "shared > medium" nutzt. Dafür, dass dir angeblich so notwendige Informationen fehlen, verwirbelst du das Thema hier immer wieder mit unnötigen Infos und trägst aber keine konkrete Lösungsidee vor. @TO: Normalerweise ist das die erste Frage bei so einem Thema, daher wundert es mich, dass sie so noch niemand hier gestellt hat, aber: Was ist denn das für ein System bzw. welcher Controller wird eingesetzt? Und kannst du etwas präziser erläutern, wann die Konfiguration des Kommunikationsschlüssels frühestens zu erfolgen hat? Wie ein Vorposter bereits erwähnt hatte, könnte man ja einfach den Leseschutz für einen bestimmten Bereich des Flash aktivieren, und somit ungewolltes Auslesen verhindern. Das sollte z.B. mit allen STM32 möglich sein. Einfach im Linker-Skript mitteilen, dass eine bestimmte Flash-Page für den Code tabu ist, da dort der Schlüssel abgelegt und anschließend vom Auslesen geschützt wird. Dann kann man im Code einfach so etwas wie
1 | #define KEY_ADDRESS 0x08000000
|
schreiben und überall dort, wo der Schlüssel benötigt wird, einfach mit der Adresse darauf zugreifen und niemand sonst kennt den Inhalt. Ist das eine Option? Gruß Arno
:
Bearbeitet durch User
A.. P. schrieb: > @TO: > Normalerweise ist das die erste Frage bei so einem Thema, daher wundert > es mich, dass sie so noch niemand hier gestellt hat, aber: Was ist denn > das für ein System bzw. welcher Controller wird eingesetzt? Und kannst > du etwas präziser erläutern, wann die Konfiguration des > Kommunikationsschlüssels frühestens zu erfolgen hat? Da dass System das meines Kunden ist, kann und will ich da nicht allzuviel verraten. Aber das System wird nach der Produktion vergossen und ins Lager gelegt und dann ausgeliefert. Anschließend ist es für Jahre "unterwegs". Die Erstprogrammierung erfolgt noch vor dem Vergießen, da kommt dann ein Bootloader rein, der es ermöglicht später die (erweiterte) Firmware einzuspielen. Der Kommunikationskanal ist das Internet via einem GSM-Modem, also alles ziemlich offen. Es ist also wichtig die Kommunikation zu schützen. Zum einen um den Eintrag von Schadcode zu verhindern, zum anderen aber auch um die Kundendaten des laufenden Betriebs zu sichern. Anlass des Threads, bzw. der Frage, ist das Design des Bootcodes. Da hier eben im laufenden Betrieb keine Änderungen mehr möglich sind, bin ich über Hinweise ziemlich dankbar. Zur zweiten Frage. Es lassen sich Bereiche des Flashspeichers sperren und ich werde das benutzen um den Bootcode zu schützen, aber leider ist das nicht so flexibel möglich, wie in anderen Systemen. Die Erfahrungen werden dann alle in ein neues HW-Design fließen :-) Gruß Ekkehard
Ekkehard D. schrieb: > Es ist also wichtig die Kommunikation zu schützen. Zum einen um den > Eintrag von Schadcode zu verhindern, zum anderen aber auch um die > Kundendaten des laufenden Betriebs zu sichern. Das ist nunmal nicht möglich sofern physikalischer Zugriff auf die Hardware gegeben ist. Es gibt dafür aber teils eingebaute Lösungen in µC für exakt dieses Problem, eine asym. Verschlüsselung ist dabei nur eine Möglichkeit. Manche µC bieten einen speziellen geschützten Speicherbereich. Aber spätestens beim Rechner dürftest du verloren haben.
Ekkehard D. schrieb: > Da dass System das meines Kunden ist, kann und will ich da nicht > allzuviel verraten. Brauchst du auch nicht, ich wollte ja nicht wissen, ob du das für's Militär oder nur für den lokalen Bingoverein entwickelst :P Aber eine Controller-Bezeichnung wäre doch noch sehr hilfreich, einfach damit man mal selber einen Blick ins Datenblatt werfen kann. Vielleicht findet man ja noch einen nützlichen Weg. ich kann mir nämlich gerade schlecht vorstellen, dass dein Controller flexibel genug ist, um den Bootloader vor dem Auslesen zu schützen, aber man diesen geschützten Bereich nicht noch um 20-30 Byte für den Schlüssel erweitern kann. Und weil du gerade vom Bootloader sprachst: Handelt es sich bei dem Schutz des Schlüssels nun um den Bootloader oder den Anwendungscode? Ich habe das noch nicht ganz verstanden. Und noch was: Ich weiß ja nichts über die Brisanz dieser Kundendaten oder die Größenordnung dieses Systems, aber wenn du tatsächlich vor hast, ein und denselben Schlüssel auf ALLE Systeme zu verteilen Ekkehard D. schrieb: > Ich werde also (sehr wahrscheinlich) einen Schlüssel für alle Systeme > verwenden. würde ich mir an deiner Stelle doch etwas mehr Gedanken über einen stärkeren Schutz bzw. ein anderes Konzept machen. Wenn die Kundendaten gerade so (un)wichtig sind, dass nicht jeder Hans Wurst mitkriegen soll, was da so für Daten durch die Luft fliegen, davon aber auch kein Menschenleben abhängt, kann das so ausreichen, wie du dir das vorstellst. Wenn sich an der Wichtigkeit der Daten aber mal was ändern sollte, was du ja im Nachgang nicht mehr beeinflussen kannst, dann hast du mit deinem Konzept einem potenziellen Angreifer gleich n Einfallstore für einen möglichen Angriff gegeben. Und trotz des Einsatzes von bewährten Krypto-Bibliotheken in der Client-Software oder eines Ausleseschutzes auf dem Controller: Es gibt bekanntlich keine 100%-ige Sicherheit und nichts ist für die Ewigkeit. Da würde ich mich dann nicht auf ein einfaches Passwort verlassen, was maximal irgendwo von einer Geräte-ID abhängt und an einer bestimmten Stelle im Flash liegt und vor dem Auslesen geschützt ist - vorerst. Und von irgendwelchem selbstgefrickelten Verschleierungscode, der an "unvorhersehbaren" Stellen irgendeine schwarze Magie anwendet, oder gar "Pseudo-Hashfunktionen", wie es hier jemand aufgeführt hat, wollen wir erst gar nicht reden. Ich will jetzt hier nicht alle möglichen Szenarien ausmalen und durchkauen, das musst du natürlich selbst abwägen und entscheiden. Aber vielleicht sparen dir diese Überlegungen im Zweifelsfall in Zukunft sehr viel Änderungsaufwand und die Erkenntnis "Ach hätte ich mich damals besser für den (etwas) komplizierteren Weg entschieden..." Gruß Arno P.S.: Noch ein Nachwort zu der Aussage eines Vorposters, man könne ja den Schlüssel an "unvorhersehbaren" Stellen im Code zusammenbauen: In den allermeisten Computersystem und somit auch Programmiersprachen gibt es kein "Unvorhersehbar". Für den Computer ist immer alles vorhersehbar - genauer gesagt deterministisch (außer, wenn du deinen Kaffee über die Tastatur gießt). Sonst wüsste der Prozessor nicht, welcher Task als nächstes läuft und du wüsstest nicht, ob dein Rechner nun startet oder nicht. Hat alles etwas mit endlichen Automaten zu tun und damit, dass so ziemlich alle Programmiersprachen, Compiler und alles was eben damit zusammenhängt darauf zurückzuführen sind. Könntest du also ein "unvorhersehbares" Programm schreiben, so müsstest du auch einen Compiler haben, der dir ein unvorhersehbares Ergebnis ausspuckt, bei dem dann aber unvorhersehbar ist, wie groß es ist und wie lange es überhaupt läuft. Und da so viele Unvorhersehbarkeiten schon im echten Leben scheiße sind, will man sowas erst gar nicht in einem technischen System haben :) Somit wären also die Stellen, an denen so ein Passwort zusammengebaut oder verwürfelt wird, für den Menschen scheinbar unvorhersehbar, aber für ein entsprechendes Programm wären diese Stellen sehr wohl vorhersehbar und mit dem nötigen Aufwand müsste sich ein Angreifer dann nur noch an diesen Stellen einklinken und dein Passwort auslesen.
:
Bearbeitet durch User
A.. P. schrieb: > ich kann mir nämlich gerade schlecht > vorstellen, dass dein Controller flexibel genug ist, um den Bootloader > vor dem Auslesen zu schützen, aber man diesen geschützten Bereich nicht > noch um 20-30 Byte für den Schlüssel erweitern kann. Man kann einen Bereich festlegen der gesperrt ist. Der kann natürlich so groß sein, wie er sein muss. Ich schrieb ja, dass ich den Schlüssel dann ins HEX-File eintragen will. > Und weil du gerade vom Bootloader sprachst: Handelt es sich bei dem > Schutz des Schlüssels nun um den Bootloader oder den Anwendungscode? Ich > habe das noch nicht ganz verstanden. Ich denke nur für den Bootloader, denn die Kunden werden wohl ihre Daten selbst in ihrer Hand halten wollen. Das führt dann dazu, dass diese Kundenschlüssel im EEProm bzw. im ungeschützten Flash liegen werden. Also konzentriere ich mich zunächst mal auf den Bootloader. > Und noch was: Ich weiß ja nichts über die Brisanz dieser Kundendaten > oder die Größenordnung dieses Systems, aber wenn du tatsächlich vor > hast, ein und denselben Schlüssel auf ALLE Systeme zu verteilen > würde ich mir an deiner Stelle doch etwas mehr Gedanken über einen > stärkeren Schutz bzw. ein anderes Konzept machen. Die Frage mit dem Schlüssel ist ein Dilemma. Fall A: Ein Schlüssel für alle Geräte. Dann würde es auch nur eine Datei mit Softwareupdate geben die mit diesem Schlüssel verschlüsselt ist. Fall B: Je ein Schlüssel pro Gerät. Dann müsste es für jedes Gerät jeweils eine Datei mit dem Softwareupdate passend für dieses Gerät geben. In Fall A wird die Kompromitierung des Schlüssels dazu führen, dass alle Geräte offen stehen. Allerdings ist anhand der wenigen Daten ein Angriff auf den Schlüssel schwierig. In Fall B kann aber die Masse der Daten mit dem gleichen Inhalt (vor Verschlüsselung) dazu führen, das die Schlüssel viel leichter zu kompromitieren sind. > Wenn die Kundendaten > gerade so (un)wichtig sind, dass nicht jeder Hans Wurst mitkriegen soll, > was da so für Daten durch die Luft fliegen, davon aber auch kein > Menschenleben abhängt, kann das so ausreichen, wie du dir das > vorstellst. Das ist eine sehr gute Frage. Dinge an denen unmittelbar Menschenleben hängen, mache ich grundsätzlich nicht :-) Das System soll verantwortlich mit den Daten umgehen, ich erwarte eigentlich keinerlei Angriffe, denn bisher (ohne Bootloader!) ist alles sehr offen und es hat sich nie jemand beschwert. E-Mails gehen z.B. ja auch überwiegend unverschlüsselt durchs Netz und nur selten ist was Verfälschtes dabei. Ich denke aber, dass man die Haustüren nicht offenstehen lassen sollte, die Vermeidung der "Verleitung zum Kameradschaftsdiebstahl" steht an erster Stelle.
Ekkehard D. schrieb: > Dieses Feld wird zudem nur den Schlüssel in verschlüsselter > Form enthalten. Das Passwort zum entschlüsseln wird dann > eine Geräteabhängige ID sein. Naja, wenn du einen Schlüssel für alle Geräte benutzen möchtest, um eine Firmware-Datei auf allen Geräten einspielen zu können, dann bringt es nur wenig, diesen Schlüssel auch noch zu verschlüsseln. Es macht technisch keinen Unterschied, ob du den Schlüssel so ins Flash legst, oder ob du ihn verschlüsselst und alle nötigen Informationen danebenlegst. In beiden Fällen hast du die Informationen, wie man an den Schlüssel kommt, im Quelltext stehen (nur den Schlüssel selbst nicht). Ekkehard D. schrieb: > In Fall A wird die Kompromitierung des Schlüssels dazu führen, dass alle > Geräte offen stehen. Allerdings ist anhand der wenigen Daten ein Angriff > auf den Schlüssel schwierig. Ein externer Angreifer wird bevorzugt den Upgrade-Mechanismus angreifen, also den Schlüssel aus dem Updater selbst extrahieren. Die Frage ist, wogegen du dich schützen möchtest.
A.. P. schrieb: > P.S.: Noch ein Nachwort zu der Aussage eines Vorposters, man könne ja > den Schlüssel an "unvorhersehbaren" Stellen im Code zusammenbauen: In > den allermeisten Computersystem und somit auch Programmiersprachen gibt > es kein "Unvorhersehbar". Das ist mir schon klar. Wir arbeiten hier mit HSMs und True Random Generatoren. In der Natur ist nix zufällig ausser kosmische Hintergrundstrahlung. Da der TO anfangs nur von 'Passwort im Quellcode verschleiern' gesprochen hat, und dann plötzlich mit 'Reverse Engineering verhindern/debugging' geschrieben hat, habe ich mich aus dem Thread ausgeklinkt. Ohne die Anforderungen genau zu kennen ist es hier sehr schwierig die optimale Lösung vorzuschlagen.
Bootloader, der macht einen Checksum über die Flash und wenn diese nicht stimmt, dann wird der Code nicht ausgeführt. Bei verschlüsseltem Bootloader wird verschlüsselt die Checksum runtergeladen, zusammen mit einer seed und einer Auth-ID sowie einem Flag und eventuellem firmware-id. Die Auth-id muss stimmen. Seed wird mit einem LFRS generator als random number genutzt, je nach Flag wird vorher ein Xor mit der UID oder SID gemacht, bzw auch die daten mit dem Inhalt des Flashes mittels crypto verschluesselt bzw auch die bits einfach ge"shuffled". Je nach dem wie die Update-Daten aussehen, ist das system offener oder geschlossener, bzw lassen sich alle Controller, oder nur einige, bzw ein einziger updaten. Auch wird das reverse engeenering des Keys über valid Opcodes erschwert.
Man sollte stets Aufwand und Nutzten im Verhältnis sehen. Ein Dieb klaut lieber das unangeschlossene Rad als eins mit 7 Schlössern angeschlossen. Wenn allderdings der Besitzer sich SELBST ausgesperrt haben sollte wird es knifflig! z.B. Zertifikate haben Verfallszeiten... S. R. schrieb: > Ein externer Angreifer wird bevorzugt den Upgrade-Mechanismus angreifen, Wenn z.B. nur ein Teil des Schlüssels beim Kunden liegt (ID) und der Rest erst durch Verarbeitung gelieferter Daten errechnet wird, könnte man zwar trotzdem den Cache untersuchen. Macht aber Arbeit!
schon mal über den einsatz von einem DS28CM00 nachgedacht? in der software auf dem computer müsste dann einfach diese serienummer "registriert" werden... diese eindeutige identifikation kann auch zur verschlüsselung verwendet würde. vorteile: - man kann devices auch ganz bewusst trennen (verlust, diebstahl) - da vergossen (und ggf zusätzlichem abschleifen) verschleierbar - einmaliger code - günstig nachteile: - nur 48 bit (ausser man bohrt den schlüssel irgendwie auf und dann sind wir wieder beim sourcecode-hack) - bei "hardcopy" des devices mit der nachgestellten nummer ist das device in dieser umgebung zu ersetzen.
Philipp G. schrieb: > Michael R. schrieb: >> Das kommt der Sache schon näher... > > Ach? Diffie Hellman wäre eine Option für Dich, aber asymmetrische > Verschlüsselung hast Du oben in den Wind geschlagen? Diffie-Hellman ist symmetrisch, nicht asymmetrisch. Im Prinzip ist es aber egal, da der TO nichts Richtiges will.
Hallo Ekkehard, der Entwickler einer Programmiersuite für AVRs hatte dazu vor einiger Zeit eine ziemlich coole Lösung für ein solches Problem: Die Controller die ihre Kommunikation untereinander austauschen lauschen gemeinsam an einem offenen ADC o.Ä. und generieren sich aus dem untersten, springendem Bit durch Bitsammeln synchronisiert einen Schlüssel beliebiger Länge. Dieser Schlüssel wird dann zur Kommunikationsverschlüsselung verwendet. Das Ganze kann entweder bei der Initialisierung/vor Auslieferung oder bei jedem Start erfolgen und/oder in gewissen Zeitabständen automatisiert aufgefrischt werden. Mit einer entsprechenden Beschaltung lässt sich Ggf. auch erkennen, ob am entsprechenden Pin gelauscht oder manipuliert wird und den Betrieb sperren. Die Beschreibung müsste ausreichen, wenn gewünscht kann ich aber nochmal nach dem Link zum Artikel schauen (Luna Studio für AVR) Gruß, Horst
Ekkehard D. schrieb: > ich bin dabei ein Pärchen aus einer Mikrocontroller-Firmware und einer > PC-Software zu bauen, deren Kommunikation verschlüsselt ablaufen muss. > Der hierzu notwendige gemeinsame Schlüssel (die Verschlüsselung ist > symetrisch) muss logischerweise zur Laufzeit dem Programm zur Verfügung > stehen. > Jetzt möchte ich eigentlich nicht, dass im Quelltext irgendwo der > Schlüssel zu sehen ist, denn dann ist die Chance groß, dass zufällig > oder fahrlässig der Schlüssel mal irgendwohin kopiert wird. Ohne es getestet zu haben, würde ich den Schlüssel in eine Datei namens "secretkey.h" schreiben, etwa so:
1 | #define SECRETKEY "ici le clef"
|
Die Datei wird dann mit
1 | gpg --encrypt-files -r hab@ich.net secretkey.h |
per GnuPG verschlüsselt, heraus kommt die Datei "secretkey.h.gpg" und "secretkey.h" kann dann gelöscht werden. Mit dem Schalter "-r" wird angegeben, welche(r) Empfänger die Datei entschlüsseln, mithin: die Software übersetzen können soll(en). Der Schalter kann auch mehrmals angegeben werden, wenn das mehrere Kollegen sein können. Von denen muß natürlich jeder ein GPG-Schlüsselpaar besitzen, das von demjenigen, der "secretkey.h.gpg" erzeugt, importiert werden muß. Im Makefile wird dann vor dem Übersetzen der .c-Datei, die den Schlüssel einbindet, mit
1 | gpg --decrypt-files secretkey.h.gpg |
wieder die originale "secretkey.h" erzeugt, dann die betreffende .c-Datei übersetzt, und "secretkey.h" danach wieder gelöscht. Problematisch kann das nur werden, wenn es mit einer IDE übersetzt wird, also das Makefile von der IDE aufgerufen wird. Keine Ahnung, ob und wie GnuPG dann nach der Passphrase des Kompilierenden fragen kann. Da muß man (ggf. in einem eigenen Unterverzeichnis) eventuell vorher die Objektdatei der obengenannten .c-Datei per Kommandozeile erzeugen.
Alex G. schrieb im Beitrag #5327302 > Der private schlüssel wird nicht einmal generiert, sondern jedes mal > wenn sich der Controler mit dem PC verbindet! > Jede Verbindung verwendet dann einen anderen, privaten Schlüssel. Entschuldige, aber Du verwechselst hier die privaten Schlüssel des Schlüsselpaares mit dem symmetrischen Session-Schlüssel, der mit den öffentlichen Schlüsseln zweier Schlüsselpaare ausgehandelt wird.
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.