Ich habe mich gefragt wie es mit der Sicherheit von Mikrocontrollern ausschaut. Angenommen ein µC ladet User generierte Daten und verarbeitet diese. Hat ein Angreifer eine Möglichkeit das Programm auf dem µC zu untersuchen? Beachten sollte man vielleicht, dass nicht jede Analyse Methode den Zugriff auf den Programmcode (Assembler) erfordert, z.B. durch bewusst falsche Daten sichtbare Fehler im Programm zu provozieren. Könnte man durch mögliche Sicherheitslücken im Programm des µC, bei der Verarbeitung der User generierten Daten, diese Daten so manipulieren das die Funktion des Programm auf dem µC verändert wird? Ein Exploit. Oder einfach gesagt, die üblichen Sicherheitsprobleme von PC Anwendungen. Inwiefern betreffen diese die üblichen Mikrocontroller?
Im Prinzip sind die Probleme genau gleich. Ein Microcontroller kann es einem Angreifer aber schwerer machen, da er nicht so einfach ausgelesen werden kann, wie z.B. eine Festplatte. Auch kann man nicht einfach mal an den RAM ran, oder Code in einer VM starten und untersuchen. Trotzdem kann auch ein gesicherter Controller ausgelesen werden. Auch die anderen Angriffe, wie BufferOverflows usw. sind theoretisch in gleichem Maße möglich. Allerdings ist so eine Allgemeine Anfrage ziemlich sinnlos. Hast du bedenken wegen eines konkreten Programms/Problems? Ansonsten ist das alles nur Geschwurbel. gruß cyblord
:
Bearbeitet durch User
Ein relativ guter Schutz ist die Verwendung eines µC mit Harvard-Architektur. Dadurch dass Ram und Rom getrennt sind ist es sehr schwer exploits anzubringen. Mit einem Buffer-Overflow kann man maximal den Ram beeinträchtigen, man kann also nicht einfach befehle an die CPU schicken. Das Prob ist halt, dass ein fw update deutlich aufwendiger ist.... PS: Es besteht zwar immernoch die theoretische Möglichkeit über overflow-tricks den µC zu Sprüngen zu bringen, man kann aber nur die Befehle verwenden (bei angenommener voller kontrolle über den programmcounter, in der praxis eigtl. unmöglich) die der Programmierer in seinem Code verwendet hat.
Ich überlege ein Gerät zu bauen, dass ein Problem lösen soll: Setzt man eine gute Verschlüsselung ein, kann diese Sicherheit durch die Angreifbarkeit des PCs bzw. des Betriebssystems beeinträchtigt werden. So bringt eine Verschlüsselung nichts, wenn der Angreifer schon auf dem Rechner ist und entschlüsselte Inhalte mitlesen kann bzw. zu verschlüsselnde Texte vorher abgreifen. Ich dachte mir, ich bastel ein kleines Gerät mit einem Display, übertrage mit einem Kabel die verschlüsselten Daten, trenne die Kabelverbindung und das Gerät entschlüsselt und zeigt den Text an. Der Klartext befindet sich also zu keinem Zeitpunkt auf dem PC sondern auf einem sehr minimalistischen Gerät das auf diese eine Aufgabe reduziert ist mit seinen Fähigkeiten. Ich fürchte keine Angriffe, aber interessiere mich für die theoretische Möglichkeit. Vorstellen kann ich mir, dass ein Trojaner auf dem PC, einen verschlüsselten Text vor der Übertragung auf das Gerät so manipuliert und erweitert, dass es z.B. den µC dazu veranlasst den entschlüsselten Klartext zu speichern und bei der nächsten PC Verbindung an den Trojaner zu übertragen. Angesichts bestimmter denkbarer Szenarien, kann man dann halt nicht behaupten, dass es unmöglich sei das der PC Zugriff auf den Klartext erlangt. Es wäre schön wenn man selbst solche theoretischen Szenarien ausschließen könnte.
Max D. schrieb: > Ein relativ guter Schutz ist die Verwendung eines µC mit > Harvard-Architektur. > Dadurch dass Ram und Rom getrennt sind ist es sehr schwer exploits > anzubringen. Mit einem Buffer-Overflow kann man maximal den Ram > beeinträchtigen, man kann also nicht einfach befehle an die CPU > schicken. Naja, bei PC-Architekturen ist das ja mittlerweile ganz genauso (NX bit und so). Und dennoch gibts mehr Exploits und Sicherheitslücken denn je... > PS: Es besteht zwar immernoch die theoretische Möglichkeit über > overflow-tricks den µC zu Sprüngen zu bringen, man kann aber nur die > Befehle verwenden (bei angenommener voller kontrolle über den > programmcounter, in der praxis eigtl. unmöglich) die der Programmierer > in seinem Code verwendet hat. Zum Glück gibts davon nicht so viele. Bei großen Programmen findet sich gewiss einiges was man gebrauchen kann. Wenn das beim PC funktioniert, warum nicht beim µC? Erschwerend hinzu kommt, dass viele µC-Programme nicht von "richtigen" Programmierern sondern "nur" von ETechnikern etc. programmiert werden die es mit solchen Details wie Buffer-Größen vielleicht nicht immer so genau nehmen...
Keks schrieb: > Ich dachte mir, ich bastel ein kleines Gerät mit einem Display, > übertrage mit einem Kabel die verschlüsselten Daten, trenne die > Kabelverbindung und das Gerät entschlüsselt und zeigt den Text an. Ich meine das Prinzip ist ja nicht neu. Schau dir die ganzen RSA Tokens an, fürs einloggen. Dann hat die Kreissparkasse ja jetzt so ein Kästchen als TAN Generator. Oder die ganzen EC-Terminals, Personalausweis-Leser usw usw. Die arbeiten ja alle so und nach diesem Prinzip. gruß cyblord
Hallo, wenn du so etwas auf einem kleine 8Bit µC wie z.B. nem ATMega mit vielleicht 8kB Flash programmierst kannst du das gegen Softwareangriffe sichern, da das Programm so einfach aufgebaut ist, das es keine Programmfehler gibt. Wenn der Programmcode z.B. nur Empfangen und kein Senden vorsieht, dann wird der PC selbst bei angeschlossenem Kabel keine Chance haben, an die entschlüsselten Daten heranzukommen. Viele Sicherheitslücke beruhen auf Komplexität und Unübersichtlichkeit der Programm, von daher lassen sich kleine µCs sehr sicher Programmieren. Enthält das Programm keinen Befehl zum Schreiben auf den Flashspeicher, so kann auch per Software der Inhalt des Flashspeichers nicht geziehlt geändert werden. Gruß Kai
Keks schrieb: > Vorstellen kann ich mir, dass ein Trojaner auf dem PC, einen > verschlüsselten Text vor der Übertragung auf das Gerät so manipuliert > und erweitert, dass es z.B. den µC dazu veranlasst den entschlüsselten > Klartext zu speichern und bei der nächsten PC Verbindung an den Trojaner > zu übertragen. Warum soll der Trojaner den Text nicht direkt entschlüsseln? Warum der Umweg über den µC? Irgendwie ist deine Aufgabenstellung wirr. Und sie hat irgendwie wenig mit der Angreifbarkeit von µC-Programmen zu tun.
Kai S. schrieb: > da das Programm so einfach aufgebaut ist, das es keine > Programmfehler gibt. Genau, das kommt hinzu. Bei kleinen Programmen kann man das ganze theoretisch verifizieren. Für alle möglichen Eingaben und Zustände, WEIL die Eingaben eben so extrem beschränkt sind. Natürlich ist es möglich, bestimmte Verschlüssungen hinreichend sicher zu implementieren, auch im Bezug auf Trojaner. Du solltest aber mal die Aufgabenstellung konkreter machen. Was genau willst du tun? Willst du so eine Art Passwort-Anzeige-Gerät machen? Also verschlüsselte Passwörter auf dem PC speichern und dann per Gerät entschlüsseln und anzeigen? gruß cyblord
:
Bearbeitet durch User
Dr. Sommer schrieb: > Warum soll der Trojaner den Text nicht direkt entschlüsseln? Warum der > Umweg über den µC? Irgendwie ist deine Aufgabenstellung wirr. Und sie > hat irgendwie wenig mit der Angreifbarkeit von µC-Programmen zu tun. Na weil der Trojaner den Schlüssel für die Entschlüsselung nicht besitzt. Die Entschlüsselung läuft ja im µC ab. Wenn ein Angreifer also die Verschlüsselung nicht brechen kann, muss er irgendwie den µC angreifen, weil dort die Entschlüsselung stattfindet.
Bei komplexeren µCs (etwa ARM) hat man ggf. schon ziemlich ähnliche Probleme. Dazu kommt, das die fast immer eine JTAG Schnittstelle bieten. Ist erst einmal wieder Aktiviert, ist fast alles für einen Angreifer offen - zumindest in der Theorie. In der Regel besteht auch die Möglichkeit den Code Bereich zu beschreiben, etwa für Bootloader. Bei einfachen µCs (etwa PIC12, 8051) gibt es da eher weniger Möglichkeiten. Zum Teil hat man nur einmal beschreibbaren Programmspeicher und mehr oder weniger gut funktionierende Schutzbits die ein Auslesen des Codes verhindern. Für spezielle Fälle gibt es auch extra gut geschützte µCs - mit entsprechend eher weniger Information darüber. Durch die geringe Größe des Codes, kann man auch tatsächlich fehlerfreien Code haben (nicht 100% sicher, aber doch sehr Wahrscheinlich) - so dass es ggf. solche Lücken wie Buffer overflow einfach nicht gibt. Einen nur durch ein Password oder ähnliches geschützten Zugang braucht man in vielen Anwendungen auch gar nicht. Da fehlt schon die Tür und nicht nur der Schlüssel. Der Schutz ist bei vielen µCs nicht perfekt (z.B. Schutzbits beim AVR lassen sich angeblich unter umgehen, sei es auch nur mit öffnen des Gehäuses). Die Funktion des Programms kann man natürlich per externem Logic-analyser Dokumentieren - bei einfachen Funktionen ließe sich die ggf. auch duplizieren.
>Es wäre schön wenn man selbst solche theoretischen Szenarien >ausschließen könnte. Das kann man nicht ausschliessen. Das ist nicht plausibel zu begründen ohne in die Tiefe zu gehen. Das Hauptargument ist, das es keinen Weg gibt zu beweisen, dass ein Programm (und in Deinem Fall ja auch noch der uC) unter allen Umständen immer nur genau das macht, was er soll. Ich vermute mal, das es darum geht, dass Du solch ein Produkt entwickeln und anpreisen willst. Wenn Du Dich mal mit Testmethoden beschäftigst, dann wirst Du sehen das diese darauf beruhen die Korrektheit für eine Auswahl an Testdaten zu zeigen, nicht aber für die Gesamtheit der möglichen Daten und Umweltbedingungen. Wenn Du Dir dazu mal einige Exploits und versuche von Reverse-Engineering ansiehst, wirst Du sehen, das es oft exotisch scheinende, ja geradezu absurde Umstände sind, die ein System angreifbar machen. Sowas kann man prinzipiell nicht voraussehen.
Falls die Funktion in etwa so ist, wie gedacht, dann stellt sich die Frage, warum überhaupt an den PC anschließen? Denn irgendwie muss der Klartext ja erstmal verschlüsselt werden und das soll ja auf dem PC passieren. Und da kann der Trojaner auch zuschlagen. Also Gerät komplett autark machen, Eingaben direkt am Gerät tätigen. Zugriff auf Gerät durch Master-Passwort schützen, mit diesem Master-Passwort den gesamten Inhalt verschlüsseln. Somit kommt auch bei Verlust des Geräts niemand an deine Daten, auch nicht durch auslesen der Speicher. gruß cyblord
Auch das ist hier schon bis zum Abscheifen der Chips von den Chinesen und unter Elektronenrastermikroskopen behandelt worden. Du mußt hier nur suchen.
Solange es keinen Physischen Zugriff auf die Box gibt, kann man so etwas einfaches wie die Verschlüsselung auch "Sicher" machen, so dass es vom PC aus nichts Böses rüber kommt. Angreifbar bleibt so ein System aber z.B. über eine Kamera (wenn man es dumm anstellt auch die Webcam am PC) oder eventuell Elektromagnetische Abstrahlungen, wenn man nicht aufpasst.
Keine Sau wird sich für das System von Keks interessieren wenn damit nicht wenigstens sechstelliger Umsatz gemacht wird. Vorher muss man sich kaum Sorgen um Angriffe machen. Lohnt sich nicht.
HertzFrequenz schrieb: > Ich vermute mal, das es darum geht, dass Du solch ein Produkt entwickeln > und anpreisen willst. Eigentlich nicht. Ich lerne und versuche ja gerade noch zu verstehen wie sicher µC eigentlich sind. > Wenn Du Dich mal mit Testmethoden beschäftigst, dann wirst Du sehen das > diese darauf beruhen die Korrektheit für eine Auswahl an Testdaten zu > zeigen, nicht aber für die Gesamtheit der möglichen Daten und > Umweltbedingungen. Wenn Du Dir dazu mal einige Exploits und versuche von > Reverse-Engineering ansiehst, wirst Du sehen, das es oft exotisch > scheinende, ja geradezu absurde Umstände sind, die ein System angreifbar > machen. Sowas kann man prinzipiell nicht voraussehen. Das stimmt. Es liegt wohl in einem grundlegenden Prinzip der Natur begründet, dass zu keinem Zeitpunkt alle möglichen Variablen der Gegenwart und Zukunft betrachtet werden können. Eine Art Evolution, jede geniale Überlebenstechnik muss mit einem zukünftigen Raubtier rechnen der diesen Schutz effektiv überwinden kann. Aufgrund der vielleicht unendlichen Möglichkeiten. Dennoch lässt sich Sicherheit aber effektiv erhöhen. Und ich glaube das ist der Fall, wenn man sensible Daten, von einer so komplexen Umgebung wie die eines PC Betriebssystems, auf eine einfachere und besser kontrollierbare Umgebung verschiebt.
cyblord ---- schrieb: > Denn irgendwie muss der > Klartext ja erstmal verschlüsselt werden und das soll ja auf dem PC > passieren. Und da kann der Trojaner auch zuschlagen. Auch die Verschlüsselung sollte logischerweise auf dem µC stattfinden. holger schrieb: > Lohnt sich nicht. Es geht aber nicht um meine Daten. Und sich Gedanken über Sicherheitskonzepte zu machen lohnt sich immer. Ich jedenfalls interessiere mich allgemein für IT Sicherheit.
HertzFrequenz schrieb: > Das Hauptargument ist, das es keinen Weg gibt zu beweisen, dass ein > Programm (und in Deinem Fall ja auch noch der uC) unter allen > Umständen immer nur genau das macht, was er soll. Doch, natürlich gibt es diese Möglichkeit. Es ist nur eine Frage der Komplexität, ob sie praktikabel anwendbar ist. Bei den verhältnismäßig kleinen Programmen in µC mit sehr überschaubaren Möglichkeiten zur "Eingabe" ist sie es oft.
Keks schrieb: > cyblord ---- schrieb: >> Denn irgendwie muss der >> Klartext ja erstmal verschlüsselt werden und das soll ja auf dem PC >> passieren. Und da kann der Trojaner auch zuschlagen. > > Auch die Verschlüsselung sollte logischerweise auf dem µC stattfinden. Und wie kommt der Klartext da rein?
Keks schrieb: > cyblord ---- schrieb: >> Und wie kommt der Klartext da rein? > > Über eine einfache Tastatur. Und wozu dann überhaupt eine Verbindung zum PC? Beschreib doch einfach nochmal was du genau machen willst. Evt. ein Beispiel wäre gut.
:
Bearbeitet durch User
Kai S. schrieb: > Wenn der Programmcode z.B. nur Empfangen und kein > Senden vorsieht, dann wird der PC selbst bei angeschlossenem Kabel keine > Chance haben, an die entschlüsselten Daten heranzukommen. Ich glaube das kann man so nicht sagen. Bei einem Exploit kann neuer Code eingeschleust und ausgeführt werden. Das könnte durch einen Fehler passieren durch die Verarbeitung der empfangenen Daten. Wenn der Angreifer den µC kennt, kann er auch die entsprechenden Befehle einschleusen um eine Sendefunktion auszuführen.
cyblord ---- schrieb: > Evt. ein Beispiel wäre gut. Nehmen wir Alice und Bob :D Alice will eine Nachricht an Bob senden. Alice setzt eine Verschlüsselungsmethode ein die sehr sicher ist. Doch Alice kann nicht ausschließen das ihr PC einen Trojaner enthält. Der Klartext könnte vor der Verschlüsselung ausspioniert werden. Alice hat ein kleines Gerät mit einem Display und einer Tastatur. Das ganze wird von einem oder mehreren µC angetrieben. Es ist auf die nötigste Funktionalität begrenzt. Es kann Text auf dem Display anzeigen, Text verschlüsseln und entschlüsseln und mit dem PC kommunizieren oder halt mit einem Speichermedium wie einer SD-Card. Alice schreibt ihren geheimen Text auf dem Gerät, lässt es verschlüsseln, verbindet das Gerät mit dem PC, überträgt die Datei auf den PC und sendet diese z.B. mit einer Email an Bob. Bob empfängt den verschlüsselten Text. Aber auch Bob kann nicht ausschließen ob sein PC wirklich sicher ist. Also verbindet Bob sein Gerät mit dem PC, überträgt den verschlüsselten Text, trennt die Verbindung zum PC und lässt sich den entschlüsselten Text auf dem kleinen Gerät anzeigen. Ein Angreifer der die Kommunikation von Alice und Bob abhören will, hat es nun viel schwieriger an den entschlüsselten Text zu kommen. Ihnen bringen nun die tausenden Exploits nichts mehr die es für PC Betriebssysteme und PC Programme gibt (siehe legalen Handel mit Exploits und Schwarzmarkt). Der Angreifer ist gezwungen den µC anzugreifen um an den Klartext zu kommen. Ich schließe aber Methoden aus, wo der Angreifer physisch vor Ort sein muss. Wenn sich z.B. Firmen da schützen wollen, müssen die eben noch andere Sicherheitsvorkehrungen haben, als nur so ein Gerät für die Verschlüsselung.
Im Grunde ist die Idee schon ganz gut. USB ist allerdings relativ aufwändig und benötigt in Mikrocontrollern auch recht viel unübersichtliche Hardware Module. Die Playstation3 wurde das erste mal für jedermann über eine Schwachstelle im USB Stack (gut, da war es USB Host aber trotzdem) gehackt. Du könntest einen externen USB Controller Chip wie einen FTDI Nutzen, der dir die Daten seriell gibt. Das ist programmiertechnisch billig erkaufte Sicherheit, denn du lagerst den USB Stack in einen externen Prozessor aus. Wenn jemand den USB Stack hackt seis drumm, dann ist er auch nicht viel weiter. Du musst dann nurnoch ein simples serielles Protokoll implementieren, dies sollte relativ sicher werden. Dazu noch ein Tastaturinterface (am besten PS/2) und ein Display. Dürfte sich in Grenzen halten mit der Angreifbarkeit. Professionell ist natürlich anders. Die STM32 Prozessoren haben entsprechende Fuses, hier ist mir auch kein Angriffsvektor bekannt. Diese deaktivieren JTAG, Bootloader, sogar das Lesen des Flashes von außerhalb. Zusätzlich kannst du, falls du Code von extern ausführen willst, in den OTP Speicher die Checksumme/Signatur des Second-Stage Bootloaders brennen, und diese beim Start prüfen. Das sollte aber nicht nötig sein. Dann musst du eben höllisch aufpassen, nirgends (vor allem im USB Teil) Lücken zu lassen. Sollte aber auch machbar sein.
@ Keks >Dennoch lässt sich Sicherheit aber effektiv erhöhen. Das ist, wenn ich Dich recht verstehe, ein Missverständnis. Mein Einwand bezog sich auf folgenden Wunsch von Dir: >Es wäre schön wenn man selbst solche theoretischen Szenarien >ausschließen könnte. nicht darauf, ob es wünschenswert wäre, die Sicherheit wenigstens graduell zu erhöhen. Das ist, soweit es eben klar ist, dass es sich um eine graduelle Sicherheit handelt, nicht um eine absolute durchaus möglich. @ cyblord >Doch, natürlich gibt es diese Möglichkeit. Es ist nur eine Frage der >Komplexität, ob sie praktikabel anwendbar ist. Wieder einmal eine Deiner genial irrelevanten Bemerkungen. Es ist völlig, klar, das es bei sehr einfachen Systemen, d.h. solchen mit wenigen Variablen, möglich ist ihr Verhalten abdeckend zu tested. Aber ein System, von dem wir hier reden, das einen Mikrocontroller beinhaltet, der Daten von einer Länge wie sie einer üblichen Nachricht entsprechen, verarbeitet, fällt darunter mit so einer geringen Wahrscheinlichkeit, dass mir und jedem vernünftigen Praktiker mit mir, denke ich, diese Einschränkung überflüssig erschien. Kurz gesagt, trifft meine Bemerkung viel wahrscheinlicher zu, als Deine korrekte Erweiterung der Aussage hier relevant ist. Wenn man bei jeder Erklärung jeden möglichen Sonderfall berücksichtigen würde, wäre jede Antwort ein Lehrwerk für sich.
HertzFrequenz schrieb: > @ cyblord >>Doch, natürlich gibt es diese Möglichkeit. Es ist nur eine Frage der >>Komplexität, ob sie praktikabel anwendbar ist. > > Wieder einmal eine Deiner genial irrelevanten Bemerkungen. > Lern erstmal zitieren du Vogel, bevor du blödsinn redest. Das Zitat ist nicht von mir.
Wenn man Hardwarezugriff hat, kann man mit einfachsten Mitteln die Sicherheitsmechanismen bei jedem üblichen Mikrocontroller problemlos umgehen und das Programm auslesen/modifizieren, ohne den uC öffnen zu müssen etc. Auf der folgenden Seite hat sich mit diesem Thema jemand in seiner PhD Thesis beschäftigt: http://www.cl.cam.ac.uk/~sps32/mcu_lock.html Softwareseitig wurde alles denke ich schon gut ausgedappt. Wenn dein Programm eben durch irgendwas durcheinandergebracht werden kann, kann man es dadurch hacken. Bei einem kleinen Programm, das wenig macht, bleiben die Möglichkeiten gering und man sollte sich sehr gut dagegen absichern können, sofern man programmieren kann. Ebenso besteht aber auch noch die Möglichkeit, dass der uC ein Bug in der Hardware hat, der zu einem Fehlverhalten führt. Das kannst du im voraus natürlich nicht wissen.
Keks schrieb: > Angenommen ein µC ladet User generierte Daten und verarbeitet diese. Erst gestern (?) wurde die Xilinx AES Verschlüsselung mit einer Side Channel Attacke gebrochen. AES erzeugt auf dem FPGA eine detektierbare Stromschwankung... das 30.000 gemacht+Modell+Statistik und man hatte den Key. TMC Pro wurde mit der Annahme aufgehebelt das sich Daten ständig wiederholen. Alte Mikrocontroller konnte man mit Power Glitches während dem Auslesen umbiegen. Ein paar PIC-Serien kann man aufätzen und die Fuses starkem UV-Licht aussetzen (Flash+RAM abkleben)... dann kriechen die Elektronen unter die Metallschicht und man kommt ans EEPROM.
Der GnuPG hack sollte ja mittlerweile auch jedem bekannt sein: http://www.cs.tau.ac.il/~tromer/acoustic/ Aufgrund von solchen hacks halte ich es für illusorisch zu denken man könnte (auch bei einem einfachen Gerät) anhaltende absolute Sicherheit bieten. Aber eine momentan (für die nächsten Monate oder wenigstens Tage) sichere Verbindung ist ja auch schon was. Halte die Idee von dem Gerät grundsätzlich für gut, würde aber unbedingt die serielle Schnittstelle statt USB wählen. Dadurch sollten sich auch SMS- oder Email-Module einfach und ohne komplizierten (= angreifbaren) USB-Host stack realisieren. Lässt sich natürlich noch weiter perfektionieren mit Servern (zum umverschlüsseln und zur zeitlichen Versetzung von absenden und empfangen) etc.. Also einfache, dafür verschlüsselte SMS- oder e-mail Maschinen. Zum selberbauen, denn lange dürfte so etwas in vielen Ländern nicht vertrieben werden (Beispiel BlackBerry die immer mehr Ländern eine Entschlüsselung der eigentlich sicheren BB-Verbindung anbieten müssen um nicht blockiert zu werden http://indianblogger.com/why-blackberry-is-banned-in-many-countries/ ).
:
Bearbeitet durch User
Sicherheit von uC-Systemen: Schnell entwickeln, schnelle Markteinführung und starkes Marketing. Wenn ein relevanter Teil der Zielgruppe erreicht wurde und der Markt von Kopisten und Plagiatoren aufgegriffen wird, sollte man schon das nächste heiße Eisen schmieden. Ist auf jeden Fall zielführender als Zeit mit der vermeintlichen Absicherung eines Systems zu verschwenden. Es gilt ja auch: je höher der Aufwand beim Schutz, desto lohnender der Crack...
Keks schrieb: > Ich lerne und versuche ja gerade noch zu verstehen wie > sicher µC eigentlich sind. Der Begriff Sicherheit wird letzthin sehr inflationär gebraucht, ist aber für sich allein ziemlich bedeutungslos. Für eine Analyse müßte man das Bedrohungsszenario zumindest mal umreißen. Was soll denn sicher sein und wovor? Geht es um die Kenntnis des Programmcodes im Flash? Um den EEPROM-Inhalt (etwa einen dort liegenden Schlüssel)? Um interne Zustände (Register und/oder RAM)? Passives Mitlesen oder aktives Verfälschen von Daten? Manipulationen an der Software? Worauf hat ein Angreifer Zugriff? Hat er nur eine Netzverbindung (z.B. eine RF Schnittstelle) oder hat er vollen Zugriff auf die Hardware? usw. usf. Eine Aussage "System X ist sicher" ist i.d.R. vollkommen sinnlos und auch das bessere "System X ist sicherer als System Y" ist wenig aussagekräftig ohne daß man dazu sagt, für welches Bedrohungsszenario man diese Aussage tätigt. XL
Ein Negativ-Beispiel: An der Supermarkt Kasse steht ein Terminal, um mit der EC Karte bezahlen zu können. Die Kommunikation zur Karte und Bank macht dieses kleine Gerät. Die Kasse übermittelt lediglich den zu zahlenden Betrag und empfängt eine Erfolgsmeldung. Hier hat man die Sicherheit der Kasse erhöht, indem der Zahlungsvorgang durch einen externen Mikrocontroller durchgeführt wird. Und doch wurden sie in großem Stil gehackt, nämlich durch direkten Zugriff auf die Hardware vor Ort am helligsten Tag direkt vor den Augen der Kassierer. Ein anderes Beispiel: Beim Installieren einer Android App stimmt der Benutzer zu, dass die App auf bestimmte Daten zugreift. Doch währen der Benutzer darüber nachdenkt, ob er "ja" oder "nein" anklicken soll, kann die App auf ALLE Daten zugreifen und es wurde bereits in großem Umfang so gemacht - mit einer Taschenlampen App! Selbst richtig gut ausgeklügelte Software wird manchmal auf erschreckend primitive Weise umgangen. Denke bei Deinem Konzept über solche Szenarien nach. Frage dich: Wie kann man mein Gerät gänzlich umgehen oder austauschen? Wie kann man das Gerät missbrauchen oder dessen Funktion von außen reverse-engineeren.
Stefan us schrieb: > Ein anderes Beispiel: Beim Installieren einer Android App stimmt der > Benutzer zu, dass die App auf bestimmte Daten zugreift. Doch währen der > Benutzer darüber nachdenkt, ob er "ja" oder "nein" anklicken soll, kann > die App auf ALLE Daten zugreifen und es wurde bereits in großem Umfang > so gemacht - mit einer Taschenlampen App! Quelle? Das mag ich nicht so recht glauben.
Zumindest Google-Play fragt erst nach den Rechten bevor es auch nur damit beginnt die App zu downloaden. Wie der Android-interne Installer das macht weiß ich nicht sicher.
Stefan us schrieb: > An der Supermarkt Kasse steht ein Terminal, um mit der EC Karte bezahlen > zu können. Die Kommunikation zur Karte und Bank macht dieses kleine > Gerät. Die Kasse übermittelt lediglich den zu zahlenden Betrag und > empfängt eine Erfolgsmeldung. > > Hier hat man die Sicherheit der Kasse erhöht, indem der Zahlungsvorgang > durch einen externen Mikrocontroller durchgeführt wird. Wer behauptet denn sowas? Inwiefern wird denn die Sicherheit der Kasse dadurch erhöht? Geht es nicht vielmehr um eine ganz neue Funktion (bargeldloses Bezahlen)? Und nochmal die Frage: die Sicherheit vor was? Vor einem Raub ja wohl offensichtlich nicht. Vor dem Betrug durch gefälschte Barcodes auch nicht. XL
@ cyblord >Lern erstmal zitieren du Vogel, bevor du blödsinn redest. Das Zitat ist >nicht von mir. Vogel? He he. Qualitativ nicht viel anders als c-hater oder MaWin. Hat also keinen Falschen getroffen. Darfst Dich angesprochen fühlen. Viel Spaß dabei.
Max D. schrieb: > Zumindest Google-Play fragt erst nach den Rechten bevor es auch nur > damit beginnt die App zu downloaden. Wie der Android-interne Installer > das macht weiß ich nicht sicher. Auch nicht viel anders. Ein .apk ist ein aufgepimptes ZIP Archiv. Bevor der Installer die Berechtigungen abfragt, muß er zumindest reinschauen. Allerdings läuft mit Sicheheit auch nicht das kleinste Codefetzelchen aus dem Archiv, bevor der Nutzer zugestimmt hat. Die letzte große Android-Lücke in diesem Bereich war AFAIK die Signatur- prüfung. Grob gesprochen konnte man zum .apk Files hinzufügen ohne daß sich die Prüfsumme ändert. Idiotischerweise verwendet Google für die Prüfung im Installer eine andere Unzip-Implementierung als später beim Ausführen der App. Wenn man also den Installer eine andere Version des MANIFEST sehen lassen kann, fragt er nach anderen Rechten als die App nachher hat. XL
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.