Frage:
Sollten Firmware-Images für IoT aus Sicherheitsgründen verschlüsselt werden?
VC_work
2017-09-01 18:28:49 UTC
view on stackexchange narkive permalink

Wird bei der Arbeit mit Internet of Things-Geräten empfohlen, Firmware-Images, die an Clients gesendet werden, zu verschleiern oder zu verschlüsseln? Dies erschwert das Reverse Engineering.

(Sie sollten natürlich signiert sein)

Was hat Reverse Engineering mit Sicherheit zu tun?
Machen wir es uns einfach: Verschlüsselung ist ein Werkzeug zur Risikominderung. Wenn die Risiken, die Sie in der IoT-Firmware haben, durch Verschlüsselung gemindert werden können, ist Verschlüsselung sinnvoll
Firmware ist Software, die in eine Hardware eingebettet ist.Wenn Sie über ein öffentliches Netzwerk senden, sollte diese Übertragung verschlüsselt sein.
@LeonanCarvalho - Es ist nicht erforderlich, die Firmware für die Übertragung zu verschlüsseln, sondern nur zu signieren und zu überprüfen (was keine Verschlüsselung ist). Es spielt keine Rolle, ob jemand weiß, was die Firmware enthält, es ist nur wichtig, ob jemand die Firmware manipulieren kann, die er erhältEingerichtet.
Muss die Firmware entschlüsselt werden, um auf dem Gerät ausgeführt zu werden?Wenn ja, erhalten Kunden die Schlüssel auf eine Weise, die böswillige Benutzer (die auch Kunden sein können) nicht können?
"Wir haben einige Verbesserungen an der Firmware Ihrer mit dem Internet verbundenen Infrarot-Schlafzimmerkamera vorgenommen. Die neue Firmware ist verschlüsselt, aber wir versprechen, dass ihre einzige Absicht darin besteht, etwas harmloses zu tun."
Es ist interessant, diese Frage zu finden, da ich sie kürzlich im Unterricht besprochen habe.Hier ist eine Quelle, aus der ich mich im DQ (Discussion Question) geäußert habe: https://www.symantec.com/content/dam/symantec/docs/white-papers/iot-security-reference-architecture-en.pdf
@schroeder, ein paar Dinge (1) das Design muss möglicherweise selbst gesichert werden, z.Aus IP-Gründen (2) könnte es unter die Sicherheitsbedenken "Entdeckung" fallen, bei denen die Kenntnis des Entwurfs tatsächliche Explosionen ermöglichen könnte.
Acht antworten:
Polynomial
2017-09-01 18:38:54 UTC
view on stackexchange narkive permalink

Nein. Sie sollten sich nicht auf die Unklarheit Ihrer Firmware verlassen, um potenzielle Sicherheitslücken zu verbergen, die unabhängig bestehen, unabhängig davon, ob Sie Ihre Firmware verschlüsseln / verschleiern.

Ich habe einen radikalen Vorschlag : genau das Gegenteil tun. Machen Sie Ihre Firmware-Binärdateien öffentlich verfügbar und herunterladbar und für jeden, der sie möchte, frei zugänglich. Fügen Sie auf Ihrer Website eine Seite mit Details dazu hinzu, wie Sie sich wegen Sicherheitsproblemen an Sie wenden können. Arbeiten Sie mit der Sicherheitsgemeinschaft zusammen, um die Sicherheit Ihres Produkts zu verbessern.

Noch besser: Stellen Sie einen (großen) Preis für Sicherheitslücken bereit, wobei schwerwiegendere Schwachstellen (gemessen am maximalen Schaden, den sie verursachen können) einen größeren Preis erhalten.Dies wird hoffentlich einige Möchtegern-Cracker davon überzeugen, die Details offenzulegen (bestimmter Preis), anstatt zu versuchen, sie auszunutzen (unsicherer, möglicherweise größerer, aber wahrscheinlich kleinerer Preis plus Risiko, erwischt zu werden).
Ich würde sogar empfehlen, die Firmware [freie Software] (https://en.wikipedia.org/wiki/Free_software) oder [Open Source] (https://opensource.org/) zu erstellen.
@wizzwizz4 Viele Unternehmen haben nicht das Kapital, um ein vollwertiges Bug-Bounty-Programm zu betreiben, insbesondere KMU und selbst finanzierte Startups.Im Allgemeinen habe ich gesehen, dass diese Unternehmen je nach Art des Geschäfts und der Marke alternative Vergütungen anbieten, z. B. kostenlose oder stark reduzierte Produkte, T-Shirts, Beute usw.Bug Bounties müssen nicht unbedingt formal und kostspielig sein.
@Polynomial Viele Unternehmen haben nicht das Kapital, um ein Bug-Bounty-Programm zu betreiben.Wenn ein großer Verstoß festgestellt wird, ist es sicherlich wert, dass $ x nicht gefunden wird, wenn Ihre Kunden Sie wegen eines durch einen Verstoß verursachten Schadens verklagen.
@wizzwizz4 Ich bezweifle, dass das Fehlen eines Bug-Bounty-Programms jemals der verwirrende Faktor bei einem Verstoß sein würde.Kopfgelder sind großartig, aber sie sind eine optionale Ebene in fast jedem Verteidigungsbudget eines Unternehmens, vielleicht mit Ausnahme von öffentlich-rechtlichen Organisationen.Wenn das Ziel darin besteht, einen Verstoß zu vermeiden, können die Kosten und die Zeit, die mit der Durchführung eines BBP verbunden sind, besser in direktere Verteidigungsmaßnahmen wie die Schulung des Personals und die Verbesserung der Fähigkeiten des blauen Teams investiert werden.BBPs sind großartig, wenn Sie bereits alles andere abgedeckt haben und über ein freies Budget verfügen oder wenn die Wahrnehmung der Sicherheitsmärkte in Ihrer Branche gut ist.
@BasileStarynkevitch's Vorschlag ist nicht so weit weg, wie es scheinen mag.Vermutlich ist die Firmware für jemanden, der das betreffende Gerät nicht hat, von geringem nicht-akademischem Nutzen.Das Unternehmen verkauft physische Geräte und möglicherweise Dienstleistungen, aber nicht wirklich Software.Unter solchen Umständen kann die Freigabe der Software für alle Beteiligten im schlimmsten Fall neutral sein und möglicherweise einen PR-Schub geben.Bonuspunkte, wenn es für einen normalen (aber technisch kompetenten) Benutzer tatsächlich eine Möglichkeit gibt, modifizierte Firmware auf das Gerät zu laden.
Vermutlich ist die Firmware für ihre Konkurrenten hilfreich.
Dies ist auch das Beste für die Welt insgesamt, aber nicht unbedingt für das Unternehmen, das die Firmware veröffentlicht.(So oder so werden die Schwachstellen gefunden und das Unternehmen wird leiden. Wollen sie früher leiden, weil sie leichter zu finden waren?)
@immibis Wenn eine Sicherheitsanfälligkeit separat entdeckt und ihnen nicht verantwortungsbewusst mitgeteilt wird, haben sie die PR-Priorität.Die Alternative besteht darin, das Unvermeidliche zu verzögern und es zu einem schlechteren Ergebnis zu machen.
@Polynomial Vielleicht unter sicherheitsbewussten Menschen.Die breite Öffentlichkeit sieht immer noch "XYZ-Produkt gehackt".
Sicherheitsforscher werden sich keinen lokalen IOT-Anbieter ansehen, der beschissene Firmware herstellt.Warum prüfen Leute Firmware?Ruhm, Glück?Welche Sichtbarkeit erhalten Sie, wenn Sie einen Fehler in einer schlecht geschriebenen Firmware eines kleinen lokalen Unternehmens finden?Wie viel Kopfgeld solltest du geben?
@Silver Ich bin Sicherheitsforscher und schaue mir ständig die Firmware von IoT-Anbietern an.Ich erwarte kein Kopfgeld.Ich mache es zum Spaß.
Josh Ross
2017-09-01 18:52:36 UTC
view on stackexchange narkive permalink

Zweifellos wäre es von Vorteil. Es ist bei weitem eine bessere Option, es Open Source als Closed Source zu pushen. Es mag zunächst albern und sogar kontrovers erscheinen, aber die Öffnung eines Projekts für die Öffentlichkeit hat viele Vorteile.

Während es Menschen mit böswilligen Absichten gibt, gibt es auch Menschen, die helfen und das Internet zu einem Internet machen wollen besserer Ort. Open Source ermöglicht es mehr Augen, über das Projekt zu schauen, nicht nur über potenzielle Funktionen, Fehler und Probleme zu sehen, sondern auch die Sicherheit und Stabilität des "Dings" zu erhöhen.

Und der Antwort von Polynomial zuzustimmen Eine Community und der Aufbau einer Basis von Mitarbeitern, die Ihnen bei der Sicherheit helfen, erhöhen den Kundenstamm erheblich.

Open Source kann für ein kommerzielles Produkt ein Schritt zu weit sein, und das Prinzip "viele Augen" ist im Allgemeinen fehlerhaft (siehe: der Status von OpenSSL vor Heartbleed).Wenn das Projekt jedoch einen GPL-lizenzierten Code ohne besondere Zustimmung des Autors verwendet, muss die vollständige Quelle trotzdem zur Verfügung gestellt werden.
@Polynomial Wenn das Projekt GPL-lizenzierten Code verwendet, müssen * die Teile, die den GPL-Code direkt berühren *, als Quellcode verfügbar gemacht werden.Nicht alles davon.Es gilt weiterhin die bloße Aggregation.
Ich kann sehen, wie das ein Problem mit vollständig Open Source sein könnte.Außerdem kommt es normalerweise auf die Semantik an, wenn es um Open Sourcing für GPL-Code geht.Ich werde mich auch mit der OpenSSL-Angelegenheit befassen, danke dafür!
Ich denke wirklich, eine gute Antwort sollte das Problem "Wenn meine Software proprietär sein muss, lohnt es sich zu verschlüsseln / zu verschleiern" ansprechen.Es kann viele Gründe geben, Software proprietär zu halten, die nichts mit Sicherheit zu tun haben (Verträge mit Kunden, Bürokratie durch das Management, wertvolle Algorithmen).Ich glaube auch, dass das Veröffentlichen Ihres Quellcodes keine gute Möglichkeit ist, einen unsicheren Softwareentwicklungsprozess zu beheben, und nicht überbetont werden sollte, indem die gesamte Antwort darauf gewidmet wird.
Mavaddat Javid
2017-09-01 23:33:33 UTC
view on stackexchange narkive permalink

Eine gut gestaltete Firmware sollte sich eher auf die Stärke ihres Zugriffsschlüssels als auf die Unkenntnis des Angreifers über das Systemdesign verlassen. Dies folgt dem grundlegenden Prinzip der Sicherheitstechnik, das als Kerckhoffs Axiom bekannt ist:

Ein Informationssystem sollte sicher sein, auch wenn alles am System außer dem Systemschlüssel vorhanden ist. ist öffentlich bekannt.

Der amerikanische Mathematiker Claude Shannon empfahl ausgehend von der Annahme, dass "der Feind das System kennt", dh "man sollte" Systeme unter der Annahme zu entwerfen, dass der Feind sofort mit ihnen vertraut wird ".

Sie könnten interessiert sein zu wissen, dass Sicherheitsingenieure vor dem späten 19. Jahrhundert häufig Dunkelheit und Geheimhaltung als gültiges Mittel zur Sicherung von Informationen. Diese wissensantagonistischen Ansätze stehen jedoch im Widerspruch zu mehreren Prinzipien des Software-Engineering-Designs - insbesondere der Modularität.

Silver
2017-09-05 12:50:19 UTC
view on stackexchange narkive permalink

Einige Leute argumentieren, dass Open Source-Code von vielen geprüft werden kann und daher kleine Fehler enthält. Auf der anderen Seite haben Angreifer denselben einfachen Zugriff und suchen auch nach denselben Sicherheitslücken. Hier gibt es definitiv einen Kompromiss, der in früheren Antworten nicht korrekt beschrieben wurde.

Andere erwähnen, dass Code von Natur aus sicher sein sollte und daher keine Verschleierung / Verschlüsselung / Verstecken erfordert. Es ist richtig, dass ein System so konzipiert sein sollte, dass es sicher ist, auch wenn Sie wissen, wie es funktioniert. Dies bedeutet nicht, dass dies immer der Fall ist UND die Implementierung fehlerfrei ist. In der Praxis ist Code niemals 100% sicher. (Sehen Sie sich die Sicherheit von Webanwendungen an: Warum benötigen wir Sicherheitsheader, um uns vor XSS- und CSRF-Angriffen zu schützen, wenn die Webanwendung keine Sicherheitslücken aufweist?) Zusätzliche Sicherheitsmaßnahmen können ergriffen werden, indem versucht wird, den Code durch Verschlüsselung und Verschleierung zu verbergen . In der mobilen Welt wird Reverse Engineering sogar als ernstes Risiko angesehen: OWASP Mobile Top 10-Risiken.

Da kein System 100% sicher ist, können wir nur versuchen, den Aufwand zu erhöhen, der erforderlich ist, um es zu beschädigen.

Nun also der Kompromiss zwischen Open Source / leicht verfügbarem Code und verschlüsseltem und verschleiertem Code. Das Zulassen einer öffentlichen Überprüfung Ihres Quellcodes kann dazu beitragen, die Anzahl der Fehler zu verringern. Wenn Sie jedoch ein kleines Unternehmen sind, in dem die Öffentlichkeit wenig Anreiz hat, Ihren Code frei zu prüfen, hat die Veröffentlichung Ihres Codes keinen Vorteil, da niemand ihn mit guten Absichten betrachten wird. Angreifer können jedoch Schwachstellen leichter erkennen. (Wir sprechen nicht über die neueste iOS-Version, die jeder Sicherheitsforscher zu knacken versucht).

In diesem Fall geht es nicht einmal um Open Sourcing des Codes zur öffentlichen Überprüfung. Wir sprechen über die Verschlüsselung der Firmware während des Transports. Sicherheitsforscher werden Ihr Gerät wahrscheinlich nicht kaufen, um den Code zum Erkennen und Veröffentlichen von Schwachstellen zu erhalten. Daher verringert sich die Wahrscheinlichkeit, dass die Guten die Schwachstellen finden, während die Bösen sie finden.

Tom
2017-09-02 10:49:21 UTC
view on stackexchange narkive permalink

Sind Sie sicher, dass Sie zwei kryptografische Methoden nicht verwechseln?

Sie sollten Ihre Firmware-Updates aus Sicherheitsgründen unbedingt signieren . Auf diese Weise kann das Gerät überprüfen, ob sie von Ihnen stammen.

Um sie zu verschlüsseln, wird ein wenig Dunkelheit hinzugefügt, und das war's. Da das Entschlüsselungsgerät nicht unter Ihrer Kontrolle steht, wird es früher oder später von jemandem gehackt, der Entschlüsselungsschlüssel extrahiert und im Internet veröffentlicht.

Sie könnten es immer illegal machen, den Entschlüsselungsschlüssel zu verteilen!Zahlen illegal zu machen funktioniert definitiv ...
Steve Sether
2017-09-02 00:40:08 UTC
view on stackexchange narkive permalink

Sie müssen sich diese Frage stellen. Ist jemand klug genug und interessiert genug, um Ihre Firmware herunterzuladen und nach Schwachstellen zu suchen, die durch eine zusätzliche Firmware-Verschlüsselungsschicht abgeschreckt werden, in der der Schlüssel enthüllt werden muss?

Dies ist nur ein weiterer Rahmen, durch den Sie springen müssen, nein anders als herauszufinden, in welchem ​​Festplattenformat sich Ihr Firmware-Image befindet. Dies ist nicht einmal ein besonders schwieriger Rahmen. Denken Sie daran, dass alle weitaus ausgefeilteren Methoden für DRM-Beträge gebrochen wurden.

Die Chancen stehen gut genug, um Ihre mit dem Internet verbundene Kaffeemaschine / Geschirrspüler zu hacken, und lassen sich nicht von einer zusätzlichen abschrecken Verschlüsselungsschicht.

Sergio A. Figueroa
2017-09-08 11:53:14 UTC
view on stackexchange narkive permalink

Im Sinne von "Verhindert die Verschlüsselung der Firmware die Erkennung von Schwachstellen in meinem Code?" Andere Antworten haben sich mit dem Kern befasst: Obwohl dies einige Angreifer entmutigen kann, führt Sicherheit durch Dunkelheit zu einem falschen Gefühl der Unverwundbarkeit, das kontraproduktiv ist.

Ich möchte jedoch ein zusätzliches Bit hinzufügen Grundlage meiner Erfahrung. Ich habe gesehen, dass die Firmware-Pakete manchmal verschlüsselt sind, aber die Motivation dafür ist nur, das geistige Eigentum eines Unternehmens zu bewahren, anstatt eine Kontrolle gegen Angreifer zu sein.

Natürlich finden Hacker oft Wege, dies zu umgehen. " Kontrolle ", aber das ist eine andere Geschichte.

gnasher729
2017-09-02 02:03:46 UTC
view on stackexchange narkive permalink

Mehrere Leute sagten, Sie sollten sich nicht darauf verlassen, den Code durch Verschlüsselung zu verschleiern, sondern ihn nur sicher zu machen. Vor kurzem wurde die Verschlüsselung einer ziemlich kritischen Software in Apples iPhones geknackt (was bedeutet, dass Hacker jetzt den eigentlichen Code nicht mehr sehen können). Es hat jeden drei Jahre lang daran gehindert, den Code zu untersuchen, sodass die Zeit von der Veröffentlichung bis zum ersten Riss um drei Jahre verlängert wurde. Das scheint eine sehr erfolgreiche Verschleierung zu sein.

Und Verschlüsselung passt sehr gut zur Codesignatur. Wenn Ihr Gerät eine neue Firmware erhält, kann es jede gefälschte Firmware ablehnen. Nun, dieser Teil wird nicht nur empfohlen, das ist absolut notwendig.

Verschlüsselung und Signierung sind orthogonal.Beide mögen Wert haben, aber sie lösen unterschiedliche Probleme und tun dies getrennt.
Beides ist sehr schwierig, wenn Sie eine Kryptobibliothek nicht richtig verwenden, und einfach, wenn Sie dies tun.Wenn Sie das eine tun, verursacht das andere nur sehr wenig Aufwand.Und beide lösen das gleiche Problem: Wir helfen, die Hardware sicher zu halten.
Was Sie vermissen, ist, dass die Verschlüsselung in der von Ihnen erwähnten Anekdote * nur relevant ist *, da der Code überall außer in der vertrauenswürdigen Ausführungseinheit verschlüsselt ist.Selbst wenn ein Update im Flug oder im Speicher verschlüsselt wird, muss es für einen normalen Prozessor * von etwas auf dem Gerät * gespeichertem entschlüsselt werden, um ausgeführt zu werden.Es ist ziemlich schwierig, es so zu machen, dass jemand, der eine Kopie der Hardware besitzt, nicht an den entschlüsselten Code gelangen kann, und nur in den ungewöhnlichen Situationen, in denen dies effektiv durchgeführt wird, wird das Update in Flugsachen verschlüsselt.
@gnasher729 Je länger der erste Hack dauert, desto schlimmer.Drei Jahre später ist es viel schwieriger, den Fehler zu beheben - der Hersteller ist möglicherweise noch nicht einmal da und wer weiß, ob er noch über die Werkzeuge verfügt.Und drei Jahre später könnte das Gerät vergessen und nicht mehr gewartet werden.Drei Jahre später werden mehr Geräte im Einsatz sein. Je früher Fehler gefunden werden, desto eher (und wahrscheinlicher) werden sie behoben.(Und woher weißt du, dass ein wirklich böser Kerl nichts von dem Fehler wusste und drei zusätzliche Jahre Zeit hatte, ihn auszunutzen?)


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...