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)
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)
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.
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.
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
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.
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 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.
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.
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.