Hi! Ich habe bei meinem AlarmSau-Projekt noch eine Frage, auf die ich keine gute Antwort finde. Und zwar, lohnt es sich, den Inhalt des internen EEPROMS (Userdaten) zu verschlüsseln? Das Programm sowie der EEPROM-Inhalt werden durch die Lockbits geschützt, das liest so schnell erstmal keiner aus. Die EESAVE-Fuse nehme ich natürlich auch zurück wenn das Programm fertig ist, sprich beim Chip-Erase bleibt der EEPROM-Inhalt auch nicht mehr stehen. Die Daten finde ich also ziemlich sicher da drin aufgehoben, daß sowieso niemand einfach drankommt. Zweites Problem: Wenn ich die Daten verschlüssele, dann muß ich im Flash auch den Code für die Entschlüsselung und das Kennwort hinterlegen, sonst kommt das eigene Programm nicht mehr an seine Daten. Ich vermute, wenn es jemand schafft, trotz der Absicherungen oben den EEPROM auszulesen, schafft es es mit dem Flash genauso und hätte damit auch kein Problem, die Daten aus dem EEPROM zu entschlüsseln. Richtig oder falsch? Was machen kommerzielle Projekte in solchen Fällen, die noch mehr auf Sicherheit achten müssen als ich mit meinem kleinen Hobbyprojekt? Danke euch!
:
Bearbeitet durch User
Ben B. schrieb: > Richtig oder falsch? Richtig. A und O bei Verschlüsselung ist das key management. > Was machen kommerzielle Projekte in solchen Fällen, die noch mehr auf > Sicherheit achten müssen als ich mit meinem kleinen Hobbyprojekt? Wenn es richtig ums Geld geht, nimmt man gleich einen Cryptoprozessor. Ansonsten kann man noch sowas wie einen ATECC508 benutzen, aber der Aufwand allein für das Konzept ist nicht unbeträchtlich, und selbst für die Tests kannst du einige dieser Teile als Verlust einplanen, denn viele der dort implementierten Funktionen sind "Einbahnstraßen": erst, nachdem du einen Teil des Chips beschrieben und versiegelt hast, kann der nächste Teil drauf zugreifen. Wenn sich dann rausstellt, dass du was falsch gemacht hast, kann das Ding in die Tonne, und es geht von vorn los.
Okay danke Dir. Also ist beim AVR mit unverschlüsseltem EEPROM und gesetzten Lockbits bereits das Maximum an Sicherheit erreicht? Oder ist eine Obfuscation der Daten im EEPROM trotzdem sinnvoll? Im Internet macht man sich ja gelegentlich darüber lustig, wenn Daten, die aus irgendwelchen Gründen nicht unknackbar verschlüsselt übertragen werden können, im Klartext übertragen werden. Wahrscheinlich würde man sich über seine sinnlos Verschlüsselung genau so lustig machen, ich weiß nicht was besser ist oder was man selbst machen sollte wenn man so ein Problem hat. Ich überlege außerdem auch noch, die Kommunikation mit dem Terminal zu verschlüsseln, falls da jemand einen Keylogger oder ähnliches dranpopeln möchte. Aber um das sicher zu bekommen müsste man den Schlüsselaustausch/Synchronisierung auch so abwickeln, daß nicht der Hauptschlüssel übertragen wird, sondern ein Teil im Flash der beiden Controller liegenbleibt, wäre auch nicht sicherer zu bekommen als das Programm im Flash ist. Aber das baue ich evtl. noch, einfach weil's cool ist. ;)
Beitrag #5717078 wurde von einem Moderator gelöscht.
Ganz unsinnig ist die Frage nicht. Aktuelles Beispiel: https://hackaday.com/2019/01/29/dont-toss-that-bulb-it-knows-your-password/ Aber ich denke auch, daß hier der Schutz über die Fuses ausreicht. Abzuwägen ist immer, wie sensibel die Daten sind und wie hoch die Gefahr eines Angriffs ist. Ben B. schrieb: > Aber das baue ich evtl. noch, einfach weil's cool ist. ;) Und weil es der Definition eines Hobbies entspricht, maximalen Aufwand bei minimalen Nutzen zu erreichen.
Welche hoch geheimen Daten willst Du denn auf dem AVR speichern? Die Zugangsdaten Deines schweizer Nummernkontos? In der Regel reicht es völlig, daß niemand weiß, was die Variablen im EEPROM bedeuten, denn dazu bräuchte er den Quelltext Deines Programms. Man speichert ja nur irgendwelche Settings im EEPROM, die dann das Hauptprogramm konfigurieren. Außerhalb des Programms sind sie völlig nutzlos. Was soll z.B. jemand mit den PID-Parametern Deiner Heizungsregelung anfangen.
Welches Szenario betrachtest Du eigentlich? Wenn ich das richtig interpretiere meint "AlarmSau" ja irgendwas mit Alarmanlage oder so. Wer da physischen Zugriff auf dem µC hat, der braucht dein Programm einfach nicht mehr. Der hat jetzt viel Zeit, da er ja das Hinderniss (Tür, Fenster, ... Versteck der AlarmSau) bereits überwunden hat. Zweitens kann jemand der einen gesperrten EEprom in einem Controller auslesen kann mit einem Stück Klingeldraht deutlich schneller die komplette Funktionalität "Nachbilden". In der IT gilt ziemlich oft, das physicher Zugriff eines Angreifers gleich einem Verlust der Sicherheit ist. Daher die Frage vom Anfang, Welche Sicherheit soll die Verschlüsselung bringen? Wie lässt sich verhindern, das das einfach umgangen wird? --- Prometheus
1.Aufwand und Nutzen=? 2.Auf die Ewigkeit gesehen, kann es natürlich vorkommen, daß einer seine Alarmanlage von außen manipulieren möchte. Dann sollte es aber reichen, wenn ein bestimmter lokaler Zustand abgeprüft wird,BEVOR man was tun darf. Das könnte eine Brücke am Gerät oder die Kühlschranktür sein :-) Es haben sich schon mehr Leute mit fehlendem oder vergessenem Schlüssel ausgesperrt als manche Verschlüsslung wert ist.
Ben B. schrieb: > Also ist beim AVR mit unverschlüsseltem EEPROM und gesetzten Lockbits > bereits das Maximum an Sicherheit erreicht? > > Oder ist eine Obfuscation der Daten im EEPROM trotzdem sinnvoll? Hast in deinem EEPROM die Abschusscodes für deine Atomraketen oder was genau soll hier eigentlich vor wem gesichert werden?
Ben B. schrieb: > Wenn ich die Daten verschlüssele, dann muß ich im Flash > auch den Code für die Entschlüsselung und das Kennwort hinterlegen Der Code ist egal, im Gegenteil, nur bekannte (Opensource) Verschlüsselungsprogramme gelten als zwar nicht 100%ig, aber maximal sicher. Selbstgeschriebenes zeugt eher von Selbstüberschätzung. Das Kennwort ist der Schwachpunkt, aber bei einem abgeschlossenen System halt notwendig. Klar könntest du das Kennwort verschlüsseln, aber dafür brauchst du ja zum Entschlüsseln wieder das (2.) Kennwort. Das verschlüsselst du dann auch, aber irgendwann gehen dir die Resourcen aus. Ben B. schrieb: > Oder ist eine Obfuscation der Daten im EEPROM trotzdem sinnvoll? Für jemand, der das Programm analysieren kann, ist Obfuscation nur eine (wahrscheinliche geringe) Mehrarbeit. Bei 99,9% aller existierenden Systeme sind die Daten das einfach nicht wert. Du kannst auch nicht ernsthaft annehmen, dass NSA oder CIA ihre gigantischen Computeranlagen auf deine Steuerung loslassen. Falls deine Alarmsau in Wirklichkeit eine hochgeheime Entwicklung einer Massenvernichtungswaffe ist nehme ich natürlich alles zurück. Georg
georg schrieb: > Falls deine Alarmsau in Wirklichkeit eine > hochgeheime Entwicklung einer Massenvernichtungswaffe ist nehme ich > natürlich alles zurück. In dem Fall reicht ein günstiger großer Schraubenschlüssel und 15 Minuten Zeit und er singt das Passwort wie ein Kanarienvogel. (siehe XKCD).
:
Bearbeitet durch User
> Was Du noch machen kannst ist, den Schlüssel auf einem > geeigneten Weg extern einzuspeisen. Geht nicht. Ohne die intern hinterlegten PINs der Benutzer (die es sich lohnen würde zu schützen) kann man mit dem Ding rein gar nichts anfangen. >> kleinen Hobbyprojekt > ? Bis jetzt ist es nur ein Hobbyprojekt. Ich weiß auch nicht wie ich wen finden soll, der es als Projekt kauft und vermarktet. Und ob ich es selbst in Deutschland vermarkten will... ich glaube da kann ich mich dank der ganzen Bestimmungen auch gleich selbst einknasten. > Und weil es der Definition eines Hobbies entspricht, > maximalen Aufwand bei minimalen Nutzen zu erreichen. Das hat damit nichts zu tun. Wenn ich mir schon Gedanken über eine Alarmanlage mache, muß ich auch darüber nachdenken, durch welche Wege und Mittel ein potentieller Angreifer den Schutz möglicherweise überwinden kann... und wie ich das verhindere. Die offene Kommunikation mit dem Terminal via USART ist jetzt die letzte echte Schwachstelle die ich kenne. Da könnte man die Eingaben mitlesen oder man könnte auch mit einem PC drangehen und automatisiert Schlüssel durchprobieren. Wenn man zumindest den Kanal vom Terminal zur eigentlichen Alarmanlage verschlüsselt, war's das fürs mitlesen oder Daten einspeisen via PC. Das was vom Kontrollmodul zum Terminal gesendet wird ist uninteressant, entweder kommt das sowieso auf dem Display wieder raus oder es sind einfache Steuerkommandos wie LED-Farbe usw. Ein Angriff darauf ist zum Brechen des Schutzes sinnlos. > In der Regel reicht es völlig, daß niemand weiß, was die > Variablen im EEPROM bedeuten, denn dazu bräuchte er den > Quelltext Deines Programms. Genau da muß ich widersprechen, die Tabelle mit den User-PINs wäre problemlos lesbar wenn man sie im Klartext vorliegen hat. > Wer da physischen Zugriff auf dem µC hat, der braucht dein > Programm einfach nicht mehr. Der hat jetzt viel Zeit, da > er ja das Hinderniss (Tür, Fenster, ... Versteck der AlarmSau) > bereits überwunden hat. Die AlarmSau ist eine frei konfigurierbare GSM-Alarmanlage mit bis zu 50 Benutzern, 6 Alarmschleifen, 2 Alarmausgängen und einem via SMS steuerbaren Fernschalter (unabhängig von den Alarmen). Das Hauptmodul wird über USART an ein Terminal angebunden, so daß man das Hauptmodul sehr gut schützen kann und der Zugang zum Terminal kein Sicherheitsrisiko (Ausnahme Erraten eines brauchbaren Schlüssels) darstellt. Einen physikalischen Einbruch verhindern kann das Ding natürlich nicht. Mein Ziel war zumindest, daß ein potentieller Angreifer nicht unbemerkt an dem Ding vorbeikommt. Beim Versuch sollen ihm entweder die Ohren dröhnen oder still eine Alarm-SMS gesendet werden (oder beides). Und selbst wenn jemand das Terminal zerstören würde, bliebe das Hauptmodul scharf und funktionsfähig. Daran anschließend die Aufgabenstellung, daß ein Angreifer möglichst schwer an eine gültige PIN kommt, selbst wenn er Zugang zum Terminal oder zur Kommunikation auf der USART-Verbindung hat. Dazu habe ich mir natürlich so ein paar nette Gecks einfallen lassen... Wenn man in geschärftem Zustand 3mal einen falschen Code eingibt, hat man danach 5 Minuten Zeit zum Warten, bis man wieder Codes eingeben kann. Macht man sich den Spaß dann nochmal, wird zusätzlich zu den 5 Minuten warten eine SMS verschickt, daß irgendein Doof gerade Codes durchprobiert. Hobby-Projekt hin oder her. Wenn ich sowas mache, dann mache ich keine halben Sachen! >:-)=)
Bei dem kompletten "Sicherung von Mikrocontrollern"-Thema muss man sich immer genau überlegen was man eigentlich schützen möchte. Ansonsten gibt es da einen Haufen komplizierte Maßnahmen, die im Endeffekt nichts bewirken, weil es kein Szenario gibt in dem sie eine Rolle spielen. Denkbare Szenarien sind denke ich: - "Keiner darf den Code meiner Glühbirne haben" -- dafür reicht vermutlich das Lockbit setzen. Aber bleiben wir mal realistisch: den will sowieso keiner. Wen sollte das interessieren und warum, bzw. was soll die Person damit anfangen, wenn sie ihn bekommt? - "Der Code auf dem Controller darf nicht verändert werden, weil das ein Angriffszenario darstellt" -- das ist denke ich vor allem, aber nicht ausschließlich, für Geräte mit Remote-Update-Funktion interessant. Dafür ist es vermutlich sinnvoll, irgendwas Secure Boot-ähnliches zu nehmen, weil man zwingend Hardwareunterstützung für das sichere Speichern der Schlüssel braucht. - "Auf dem Controller sind sensible Nutzerdaten gespeichert, die man wenn man die Hardware in der Hand hat nicht auslesen können soll" -- das ist vermutlich der schwierigste Fall. Ich denke, hier ist die einzige Maßnahme die hilft ein Controller mit Encrypted Boot, d.h. der Controller selbst entschlüsselt das Firmware-Image mit einem in Hardware sicher gespeicherten (und von Software nicht auslesbaren) Key. Dann kannst du im Firmware-Image einen Schlüssel für das Sichern der Nutzerdaten haben.
Ben B. schrieb: > man könnte auch mit einem PC drangehen und automatisiert Schlüssel > durchprobieren. Dagegen gibt es eine recht einfache Methode, jede fehlerhafte Eingabe verdoppelt die Sperrzeit für eine erneute Eingabe (10s,20s,40s usw.).
Sven B. schrieb: > - "Keiner darf den Code meiner Glühbirne haben" -- dafür reicht > vermutlich das Lockbit setzen. Aber bleiben wir mal realistisch: den > will sowieso keiner. Wen sollte das interessieren und warum, bzw. was > soll die Person damit anfangen, wenn sie ihn bekommt? Tja, mal nachdenken, warum könnte wohl jemand dein WLAN-Passwort haben wollen? Schon mal darüber nachgedacht, dass "du" auch ein Unernehmer/Unternehmen sein könntest, in dessen Netzwerk einbrechen sich lohnen könnte, um Firmengeheimnisse abzugreifen? Oder dass "du" ein investigativer Journalist sein könntest, dessen geheime Quellen man gerne kennen würde? Da ist es natürlich praktisch, wenn man über eine "smarte" Glühbirne ans WLAN-Passwort kommt. Und ist man erstmal im Heimnetz, braucht es nur wieder mal eine ungefixte Windows-Schwachstelle, um auf die einzelnen Rechner zu kommen. Oder im besten Fall vielleicht nicht mal das.
Ben B. schrieb: > Genau da muß ich widersprechen, die Tabelle mit den User-PINs wäre > problemlos lesbar wenn man sie im Klartext vorliegen hat. Nur muß dazu ja der Angreifer schon eingedrungen sein, den Standort der Alarmanlage gefunden haben, diese außer Betrieb gesetzt haben, sie geöffnet haben und ein Programmiergerät angeschlossen haben. Das direkte Auslesen des EEPROM sollte also für eine Alarmanlage keine Gefahr darstellen. Ein Angreifer muß also erstmal die zugänglichen Kommunikationswege überwinden.
Ben B. schrieb: > Das hat damit nichts zu tun. Wenn ich mir schon Gedanken über eine > Alarmanlage mache, muß ich auch darüber nachdenken, durch welche Wege > und Mittel ein potentieller Angreifer den Schutz möglicherweise > überwinden kann... und wie ich das verhindere. Ganz ehrlich, du erwartest wirklich, daß sich da jemand Zutritt zu dem Gerät verschafft, um dann ein irgendwie geartetes elektronisches Gerät an die Usart anzuklemmen, um da Codes auszulesen und die Sau stillzulegen? Du schaust zu viele schlechte Filme. Ben B. schrieb: > Hobby-Projekt hin oder her. Wenn ich sowas mache, dann mache ich keine > halben Sachen! >:-)=) Das sei Dir unbenommen. Als Denksportübung macht das alles sicherlich Spaß. Irgend einen realen Sinn hat alles aber nicht. Maximaler Aufwand für minimalen Effekt. Oliver
Peter D. schrieb: > Ben B. schrieb: >> Genau da muß ich widersprechen, die Tabelle mit den User-PINs wäre >> problemlos lesbar wenn man sie im Klartext vorliegen hat. > > Nur muß dazu ja der Angreifer schon eingedrungen sein, den Standort der > Alarmanlage gefunden haben, diese außer Betrieb gesetzt haben, sie > geöffnet haben und ein Programmiergerät angeschlossen haben. > Das direkte Auslesen des EEPROM sollte also für eine Alarmanlage keine > Gefahr darstellen. > Ein Angreifer muß also erstmal die zugänglichen Kommunikationswege > überwinden. Die alte Regel gilt immer noch: Je mehr Mühe sich jemand gibt, irgendwelche Programme oder Daten zu schützen, desto weniger sind es die Programme / Daten überhaupt wert, geschützt zu werden.
1 | Wer EEPROM auslesen kann, kann auch Flash auslesen. |
2 | Wer sich für sooo klug hält, trennt erstmal die Module und verbindet |
3 | diese wireless, anstatt alles in einem Gehäuse zu halten. |
4 | Bei dir reicht es, die Karte aus GSM-Modul rauszunehmen, danach kann |
5 | man in aller Ruhe die restlichen Kabeln trennen und schon ist deine |
6 | geniale Alarmanlage geknackt. |
7 | Deine Alarmausgänge gehen über Relais, da weiss der Einbrecher sofort, |
8 | wo die Kabel zu trennen sind. |
9 | Ein Tamponschutz für Gehäuse ist auch viel nützlicher als Schutz |
10 | für Alarmschleifen. |
11 | Normalerweise komunizieren die Module wireless miteinander, z.B. |
12 | alle 500ms werden Nachrichten ausgetauscht, wenn die Nachricht nicht |
13 | ankommt oder bestätigt wird, löst der GSM-Modul Alarm aus. |
14 | Wo sich der GSM-Modul (oder mehrere) befindet, weiss der Einbrecher |
15 | aber nicht. |
16 | |
17 | Natürlich ist es dein Projekt, du kannst es machen wie es dir |
18 | beliebt, aber in jedem zweitem Satz "meine AlarmSau" zu erwähnen |
19 | und darüber nachzudenken, dies auch noch irgendwo zu vermarkten, |
20 | zeugt nur von massloser selbstüberschätzung. |
:
Bearbeitet durch User
> Bei dir reicht es, die Karte aus GSM-Modul rauszunehmen, > danach kann man in aller Ruhe die restlichen Kabeln trennen > und schon ist deine geniale Alarmanlage geknackt. Zugegeben, wenn Du es denn schaffst, das Hauptmodul mit der SIM-Karte zu finden, da schneller Zugriff drauf bekommst als die SMS raus ist, die Deinen Einbruch meldet und die Sirene losgeht. Dafür bleiben Dir nach dem Auslösen einer Alarmschleife maximal zwei Sekunden wenn die Schleife nicht verzögert ist. Das Terminal bekommst Du in der Zeit vielleicht kaputt, aber das nutzt nichts wenn das steuernde Teil funktionsfähig bleibt. Und nein, das Hauptmodul wird nicht direkt unter oder neben dem Terminal liegen, sonst hätte ich mir den Spaß mit dem Terminal auch komplett sparen können. GSM macht sowieso nur Sinn wenn der Einbrecher nicht weiß, daß GSM da ist. Ansonsten reicht ein Handykiller, um den Versand von SMS zu blockieren. Da kann ich auch nicht viel gegen machen. Aber dann gibts wenigstens ordentlich was auf die Ohren.
Hi
>Aber dann gibts wenigstens ordentlich was auf die Ohren.
Bauschaum.
MfG Spess
Ben B. schrieb: > Und nein, das Hauptmodul wird nicht direkt unter oder neben > dem Terminal liegen, sonst hätte ich mir den Spaß mit dem Terminal auch > komplett sparen können. Aber elektrische verbunden. Dann lege ich ein paar kV auf die Terminalleitung und dein Hauptmodul wird gegrillt.
Moin, vn n. schrieb: > Schon mal darüber nachgedacht, dass "du" auch ein > Unernehmer/Unternehmen sein könntest, in dessen Netzwerk einbrechen sich > lohnen könnte, um Firmengeheimnisse abzugreifen[...] Viel zu kompliziert gedacht. Kaum ein Journalist dürfte sich die Mühe mit dem Hacking machen. Normalerweise reicht ein "social engeneering" völlig, die Leute verwenden immer die gleichen 50 Paßwörter, die PW stehen am Monitor oder kleben unter der Tastatur oder liegen auf einem Zettel in der obersten Schublade, häufig ist das PW auch die Jahreszahl. Alternativ flirte ich mit der Sachbearbeiterin und linse ihr über die Schulter. Und dort, wo das 4-Augen-Prinzip gilt, kennen beide Benutzer meist beide PW (fall's der Kollege 'mal krank ist). Wenn die Firmendaten geklaut werden sollen und die Alarmsau überwunden wurde, dann würde ich nicht die PINs aus der Alarmsau auslesen, sondern die Festplatten aus dem Firmenserver ausbauen und mitnehmen. Und sagt nicht, daß wäre unrealistisch, denn ich habe oben beschriebene Szenarien bereits selbst erlebt.
Marc V. schrieb: > Ein Tamponschutz für Gehäuse ist auch viel nützlicher als Schutz > für Alarmschleifen. Da hat wohl die Autokorrektur zugeschlagen. Nennt sich Tamper Protection.
vn n. schrieb: > Sven B. schrieb: >> - "Keiner darf den Code meiner Glühbirne haben" -- dafür reicht >> vermutlich das Lockbit setzen. Aber bleiben wir mal realistisch: den >> will sowieso keiner. Wen sollte das interessieren und warum, bzw. was >> soll die Person damit anfangen, wenn sie ihn bekommt? > > Tja, mal nachdenken, warum könnte wohl jemand dein WLAN-Passwort haben > wollen? Hast du mal den Rest meines Beitrags gelesen? Ich habe die Fälle differenziert "der Code soll geschützt werden" und "sensible Nutzerdaten sollen geschützt werden". Du hast mit Annahmen des letzteren Szenarios auf meinen Vorschlag zum ersteren geantwortet.
>> Aber dann gibts wenigstens ordentlich was auf die Ohren. > Bauschaum. Bauschaum auf die Ohren find ich gut. ;) Nee, dafür müsste man drankommen, auch schlecht wenn's mehrere Hupen gibt. > Aber elektrische verbunden. Dann lege ich ein paar kV auf > die Terminalleitung und dein Hauptmodul wird gegrillt. Welcher Einbrecher hat ein paar kV dabei? Außerdem grillst Du damit nur die Schutzschaltung für diese Kabel, danach funktioniert das Terminal nicht mehr, aber der eigentliche Controller wird das überstehen. > Nennt sich Tamper Protection. Hat das Ding in Form einer Photodiode und ein Mikrotaster am Deckel bzw. hinten zur Wand hin ist auch nicht so das große Problem.
Angehängte Dateien:
-
20190131_120308.jpg
480 KB
Ben B. schrieb: > Wenn ich die Daten verschlüssele, dann muß ich im Flash > auch den Code für die Entschlüsselung und das Kennwort hinterlegen Schau dir die ganzen "Crypto-Chips" von Atmel an - die sind doch gerade dafür gedacht Passwörter zu speichern etc. Hier die Übersicht: http://ww1.microchip.com/downloads/en/DeviceDoc/doc8705.pdf Dazu gibt es auch App Notes und ein Xplained Kit.
:
Bearbeitet durch User
Ich denke ich lasse den EEPROM unverschlüsselt und begnüge mich mit dem Schutz durch die Lockbits.
> Schau dir die ganzen "Crypto-Chips" von Atmel an - die sind doch gerade > dafür gedacht Passwörter zu speichern etc. Das kann grundsätzlich alles nichts helfen, wenn die Komponente, die die Software-Anwendung ausführt, die das Passwort schlussendlich benötigt, nicht von einem Controller gestartet wird, der einen (außer vom Boot-ROM) nicht auslesbaren Schlüsselspeicher hat. Was hindert mich als Angreifer sonst daran, mich gegenüber dem externen Kryptochip als die Software auszugeben?
:
Bearbeitet durch User
Ben B. schrieb: > Ich denke ich lasse den EEPROM unverschlüsselt und begnüge mich > mit dem Schutz durch die Lockbits. Sehr gut. Vor allem aber solltest Du hier nicht weiter öffentlich technische Details ausplaudern, das hilft am meisten.
Ich finde es eigentlich gut, einige technische Details "auszuplaudern". Nur so kann mir jemand Tips geben wenn ich Fehlerquellen oder mögliche Angriffszenarien übersehen habe. Die Anlage sollte selbst dann eine hohe Zuverlässigkeit erreichen, wenn der Angreifer solche Details kennt.
Anton M. schrieb: > Sehr gut. > Vor allem aber solltest Du hier nicht weiter öffentlich technische > Details ausplaudern, das hilft am meisten. Erkläre uns dann bitte warum gängige Verschlüsselungsmethoden öffentlich dokumentiert sind und trotzdem sicher sein können. Erzähle bitte nicht so einen Unsinn, nur weil du nicht mit Wissen belastet bist.
svensson schrieb: > Viel zu kompliziert gedacht. Kaum ein Journalist dürfte sich die Mühe > mit dem Hacking machen. Normalerweise reicht ein "social engeneering" > völlig, Zum Beispiel jetzt hier. Cyblord -. schrieb: > Erzähle bitte nicht so einen Unsinn, nur weil du nicht mit Wissen > belastet bist. Bevor man von Unsinn spricht sollte man erst mal den Sinn verstanden haben.
Ben B. schrieb: > > Also ist beim AVR mit unverschlüsseltem EEPROM und gesetzten Lockbits > bereits das Maximum an Sicherheit erreicht? > Das Maximum davon, was der AVR hergibt. Dir ist ja bewusst, dass es Tools gibt, die die Lockbits nicht interessieren? Da ich dein Alarmsau-Projekt nicht kenne: ich vermute mal, dass du a priori nicht willst, dass dein Alarm nicht durch einen einfachen Kniff entschärft wird. Dementsprechend hast du ja bereits schon laut überlegt: Was soll da Sinn machen, den Code zu reverse-engineeren? (Ausser, du hast private Schlüssel im Klartext im EEPROM hinterlegt). Was die Sicherheit angeht, kann ich aus Erfahrung mit Schliesssystemen sagen: Der geschriebene Code ist meist das grössere Sicherheitsrisiko als aufwendig selbst erdachte Schutzmechanismen. Dementsprechend sollte dein System so designt sein, dass du den Code offenlegen kannst (ohne irgendwelche hinterlegte Schlüssel...).
Ein Wesen der Kryptographie ist, daß es keine mathematisch beweisbar sicheren Methoden gibt - mit einer Ausnahme: der Schlüssel ist länger als die Nachricht. Die öffentliche Diskussion soll helfen, Schwachstellen empirisch zu finden, um wenigstens abschätzen zu können, wann die Sicherheit nicht mehr gegeben ist. Der andere Weg ist die vollkommene Geheimhaltung.
Fitzebutze schrieb: > Dir ist ja bewusst, dass es Tools gibt, die die Lockbits nicht > interessieren? Allerdings ziemlich aufwändige, nicht zerstörungsfreie. Interessanter ist da für die Kryptoanalytiker schon sowas, wie die Stromaufnahme in Abhängigkeit vom Schlüsselmaterial zu analysieren und dergleichen.
svensson schrieb: > Der andere Weg ist die vollkommene Geheimhaltung. ... gepaart mit Wissen und Können! Das scheint mir der Erfolg versprechendere...
Das mit Sicherheit durch Geheimhaltung hat in der Vergangenheit so oft nicht funktioniert, daß ich von dem Prinzip nicht viel halte. Ich sage nur DVD/CSS, da haben sich einige Leute bestimmt den Kopf deutlich mehr drüber zerbrochen als ich mit meinem kleinen AVR und trotzdem war's irgendwie nichts. Wenn jemand zum Auslesen des EEPROM oder Flash den Controller öffnen muß um die Lockbits zu löschen oder was auch immer, dann ist mir das "teuer genug" - so viel Interesse hat bestimmt niemand an ein paar PIN-Codes und der Verlust des Controllers würde auch sehr schnell auffallen, weil die Anlage ohne den nicht mehr funktioniert.
Ben B. schrieb: > Das mit Sicherheit durch Geheimhaltung hat in der Vergangenheit so > oft nicht funktioniert, daß ich von dem Prinzip nicht viel halte. Ich > sage nur DVD/CSS DVD/CSS hat mit Geheimhaltung wenig zu tun, das war öffentlich zugänglich. Genügend Geister drauf angesetzt und schon wars vorbei mit dessen Sicherheit. > Wenn jemand zum Auslesen des EEPROM oder Flash den Controller öffnen muß > um die Lockbits zu löschen oder was auch immer, dann ist mir das "teuer > genug" - so viel Interesse hat bestimmt niemand an ein paar PIN-Codes Wenn das der Lerneffekt dieses Threads ist hat es sich ja für Dich gelohnt.
Genau, in der Praxis ist dann die Alarmsau geklaut worden. Dann brauchst Du eh eine neue und kannst neue PINs vergeben. Wahrscheinlich wäre das aber ein kleineres Problem, denn dann IST bereits jemand erfolgreich eingebrochen. Und der wollte bestimmt nicht nur die Alarmsau stehlen...
Na so weit kommts noch, meine AlarmSau klauen!! Den Typen, der daran auch nur denkt, dem trete ich persönlich so tief in den Arsch, daß Chuck Norris vor Neid erblasst!
Beitrag #5717695 wurde vom Autor gelöscht.
Peter D. schrieb: > Da hat wohl die Autokorrektur zugeschlagen. > Nennt sich Tamper Protection. LOL, habe es gar nicht bemerkt. Ich weiss es, aber die AK offensichtlich nicht. Manchmal glaube ich selber nicht, was und wie da alles "korrigiert" wird.
:
Bearbeitet durch User
Ben B. schrieb: > Wenn jemand zum Auslesen des EEPROM oder Flash den Controller öffnen muß > um die Lockbits zu löschen oder was auch immer, dann ist mir das "teuer Den muss man nicht öffnen. Das Zauberwort heisst Glitch-Attacke, da gibt es Dienstleister, die dir das ROM auf Wunsch (und gegen Bares) per JTAG auslesen. Klappt allerdings nicht bei allen AVR und die Thematik ist sehr unbeliebt, deswegen möchte ich da keine weiteren Hinweise geben. Ich würde einfach, wenn ich Du wäre, alles möglichst simpel halten, die Wahrscheinlichkeit, dass ein "Feind" diesen Weg geht, dürfte sehr gering sein. Und wenn, was hättest Du dabei zu verlieren? Ich würde mir mehr Gedanken machen, ob einer das Ding anbohren, draufhauen, oder schlicht den Strom abstellen kann. Das ist nämlich das Erste, was ein mässig effektives Schliess/Alarm-System ad absurdum führt.
Beitrag #5718432 wurde von einem Moderator gelöscht.
Im Grunde reicht es mir, wenn ich das Maximum an Sicherheit erreiche, was die Hausmittel eines ATMega1284 bieten. Wenn das die Lockbits schon so weit sicherstellen, daß EEPROM und Flash gleich schwer auszulesen sind, dann reicht mir das. Wenn ich es schaffe, beides auszulesen und es keine externen Schlüssel gibt, kann ich alles was verschlüsselt ist sowieso mit relativ wenig Aufwand entschlüsseln. Die Frage war mehr ob eine Verschleierung des EEPROM-Inhalts trotz der relativ einfachen Überwindbarkeit sinnvoll ist oder nicht. Per JTAG auslesen. Ich muß mal aufs Datenblatt schauen, glaube die JTAG-Pins sind nicht belegt... vielleicht kann man eine der Schutzdioden dieser Pins zerstören, dann war's das für JTAG. ;) Strom abstellen... Also erstens gibts einen Netzausfall-Alarm, einfacher kann man nicht auffliegen. Zweitens läuft das Ding in scharfgeschaltetem Zustand an einem alten 15Ah-Akku weit über eine Woche (weiß nicht wie lange, hab noch nicht ausprobiert wie lange der reicht) und bei 11,3 oder 11,5V gibts nochmal eine Warnung, daß der Akku langsam schwach wird. Das wird also nichts. Klar, wenn man die Zentrale mechanisch zerstört, dann war's das. Also die AlarmSau ist zugegebenermaßen vielleicht nicht ganz atombombensicher. Allerdings sollte sich die Zentrale immer weit im geschützten Bereich befinden und man sollte nicht drankommen, ohne vorher den Alarm auszulösen - vor allem nicht wenn man es leise und zerstörungsfrei versucht. Mir gehts auch nicht um Einbrecher, denen alles egal ist, die in drei Minuten mehr Schaden machen als sie klauen und die vor ausgelöstem Alarm keinen Respekt haben weil sie nach drei Minuten sowieso wieder weg sind bevor irendwer da erscheinen kann und sie aufmischt. Gegen sowas kann man technisch nicht viel machen solange man selbst oder die Polizei nicht gerade 100 Meter weiter danebensteht. Also im erlaubten Rahmen kann man nicht viel machen. Ein paar SM-70 in der Werkstatt würden das Problem lösen, sind aber völkerrechtlich schwer vertretbar.
:
Bearbeitet durch User
Ben B. schrieb: > Im Grunde reicht es mir, wenn ich das Maximum an Sicherheit erreiche, > was die Hausmittel eines ATMega1284 bieten. Wenn das die Lockbits schon > so weit sicherstellen, daß EEPROM und Flash gleich schwer auszulesen > sind, dann reicht mir das. Dann belass es dabei. > Die Frage war mehr ob > eine Verschleierung des EEPROM-Inhalts trotz der relativ einfachen > Überwindbarkeit sinnvoll ist oder nicht. Nicht sinnvoll. Ist wie eine verschlossene Wohnungstür, bei der jeder weiß, dass der Schlüssel unter dem Abstreicher liegt. JTAG könntest du noch per Fuse abschalten, das würde diese Stelle nochmal zusätzlich erschweren. Aber das betrifft ja am Ende nur noch das Szenario, dass jemand das ganze Gerät klaut nur um rauszufinden, was er denn beim nächsten Versuch anders machen müsste.
Ben B. schrieb: > Was machen kommerzielle Projekte in solchen Fällen, die noch mehr auf > Sicherheit achten müssen als ich mit meinem kleinen Hobbyprojekt? Du mußt nur mal vergleichen, was andere so machen. Deinen EEPROM schützen ist doch pillepalle. Ich habe hier so ein GSM-Chinateil mit Funk-Sensoren für 35EUR. Sowas sollte ein Angreifer erst mal überwinden. Wenn du die Sensoren öffnest, gibt es Alarm. Mann kann über APP steuern. Akkugepuffert. Bei Stromunterbrechung gibt es Alarm. Geräuschaufzeichnung, man kann in das Objekt hineinhören. .... ebay 283272319572 Und das ist wirklich noch nicht professionell. Kostet nur 2x Mittagessen in einer deutschen Kneipe.
JTAG deaktiviere ich sowieso immer sofort bei einem neuen Controller, habe ich noch nie benutzt. Aber wenn es jemand schafft, die Lockbits zu überwinden, schafft er es mit der JTAG-Fuse wohl auch. > Aber das betrifft ja am Ende nur noch das Szenario, dass jemand das > ganze Gerät klaut nur um rauszufinden, was er denn beim nächsten > Versuch anders machen müsste. Das würde keinen Sinn machen, das nächste Gerät könnte andere Hardware-Schlüssel im Flash haben und die Codes sind sicher auch nicht mehr die gleichen. Ich möchte nur den Fall absichern, daß jemand die Alarmanlage zu überwinden versucht, ohne daß man es merkt. Wenn die ganze Anlage fehlt, merkt man das sehr schnell. Wenn jemand die Anlage klaut ohne daß man es merkt, das wäre schlecht und soll verhindert werden. @Michael Kaufen kann jeder, das ist langweilig!
Beitrag #5718529 wurde von einem Moderator gelöscht.
Beitrag #5718535 wurde von einem Moderator gelöscht.
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.