Können auf die NodeMCU-Karte geladene Programme extrahiert werden?

13

Ich verwende eine NodeMCU-Karte mit WiFi-Funktionen, um einen einfachen Asset-Tracker zu erstellen. Es ist mir gelungen, einige Arduino-Skizzen zu finden, die die Konnektivität mit Azure IoT Hub ermöglichen und Nachrichten veröffentlichen.

Einer der Schlüssel, den ich auf das Board "laden" muss, ist die Azure Device Connection-Zeichenfolge und natürlich eine WLAN-SSID und ein Kennwort.

Meine Angst ist, dass jemand einfach das Board nimmt und die Dateien "herunterlädt", um Zugriff auf die Sicherheitsdaten zu erhalten.

Ist meine Angst unbegründet oder ist der Verlust von Anmeldeinformationen eine echte Bedrohung, die ich mindern muss?

security

— Widder
quelle

3

Ich denke, die Antworten von @Mike Ounsworth und Bence Kaulics zusammen bieten mir eine gute Möglichkeit. Leider kann ich nicht beide als akzeptierte Antworten markieren.

— Widder

12

[Haftungsausschluss: Ich bin ein Security / Crypto-Experte und beschäftige mich täglich mit Fragen zur Sicherheitsarchitektur.]

Sie sind auf das Problem gestoßen, Anmeldeinformationen so zu speichern, dass ein unbeaufsichtigter Prozess darauf zugreifen kann, ein Angreifer jedoch nicht. Dies ist ein bekanntes und sehr schwer zu lösendes Problem.

Wenn Ihr IoT-Gerät über einen auf dem Motherboard integrierten Hardware-Keystore verfügt, wie z. B. einige TPMs, oder einen entsprechenden, durch Android-Hardware gesicherten Keystore oder Apple Secure Enclave, können Sie diesen verwenden.

Bei herkömmlichen Servern können Sie HSMs oder Smartcards verwenden, aber die einzige vollständige Softwarelösung, die mir bekannt ist, besteht darin, einen AES-Schlüssel aus einer Art "Hardware-Fingerabdruck" abzuleiten, der durch Kombination der Seriennummern aller Hardwaregeräte erstellt wird. Verwenden Sie dann diesen AES-Schlüssel, um die Anmeldeinformationen zu verschlüsseln. Ein Prozess, der auf demselben Server ausgeführt wird, kann den AES-Schlüssel rekonstruieren und die Anmeldeinformationen entschlüsseln. Sobald Sie die Datei vom Server extrahieren, kann sie im Wesentlichen nicht mehr entschlüsselt werden.

Das IoT wirft aus zwei Gründen einen Schraubenschlüssel hinein:

Die Annahme, dass Hardware-Seriennummern eindeutig sind, trifft wahrscheinlich nicht zu, und
Im Gegensatz zu Servern haben Angreifer physischen Zugriff auf das Gerät. Daher kann das Gerät möglicherweise eine Shell zum Ausführen des Entschlüsselungsprogramms erhalten.

Sowohl die Hardware-Verschlüsselung (TPMs) als auch die "Hardware-Fingerabdruck" -Verschlüsselung stellen bestenfalls eine Verschleierung dar, da ein Angreifer, der diesen lokalen Prozess ausführen kann, die Daten grundsätzlich auch entschlüsseln kann.

Der Standardtrick sieht also so aus, als würde er hier nicht funktionieren. Die erste Frage, die Sie sich stellen müssen, ist:

Was ist mein Bedrohungsmodell / wo steht dieses Projekt auf der Secure <--> ConvenientSkala?

Letztendlich denke ich, dass Sie dies entweder entscheiden müssen security > convenienceund einen Menschen nach jedem Start die Anmeldeinformationen eingeben lassen müssen (etwa mit der Antwort von @ BenceKaulics ), oder Sie entscheiden dies security < convenienceund legen die Anmeldeinformationen einfach auf dem Gerät ab, möglicherweise unter Verwendung einer Verschleierung, falls Sie dies wünschen Das macht den Unterschied.

Dies ist ein schweres Problem, das durch die Art der IoT-Geräte erschwert wird.

Der Vollständigkeit halber lautet die vollständige industrielle Lösung für dieses Problem:

Geben Sie jedem IoT-Gerät zur Herstellungszeit einen eindeutigen öffentlichen RSA-Schlüssel. Notieren Sie diesen öffentlichen Schlüssel in einer Datenbank mit der Seriennummer des Geräts.
Speichern Sie die vertraulichen Anmeldeinformationen auf einem geeigneten Server, nennen wir es ein "Gateway".
Wenn sich ein IoT-Gerät beim Gateway authentifiziert (unter Verwendung seines RSA-Schlüssels), öffnet das Gateway eine Sitzung für dieses Gerät unter Verwendung der gespeicherten Anmeldeinformationen und gibt das Sitzungstoken an das Gerät zurück.
Aus Sicherheitsgründen ist das Gateway ein physisches Gateway (oder VPN-Gateway), sodass der gesamte Datenverkehr vom IoT-Gerät durch das Gateway geleitet wird und Sie mehr Kontrolle über Firewall-Regeln und andere Dinge haben. Zugang zum Internet.

Auf diese Weise kann ein Angreifer, der ein Gerät kompromittiert, eine Sitzung eröffnen, hat jedoch nie direkten Zugriff auf die Anmeldeinformationen.

— Mike Ounsworth
quelle

2

Ja. Ein großer Teil des Problems ist, dass das, was hier geschützt werden soll, das gemeinsame Geheimnis ist, das ein WLAN-Passwort ist. Geteilte Geheimnisse sind eine schlechte Idee, wenn ein Gerät physisch zerlegt werden kann. Ein besseres Design würde jede Instanz des Geräts (oder eines anderen Computers) in eine eigene Sicherheitsumgebung mit einem einzigartig sicheren Kanal zwischen jedem einzelnen Gadget und den Systemen trennen, mit denen sie kommunizieren müssen. In diesem Fall ist WLAN möglicherweise ohnehin nicht sehr gut für die Anwendung geeignet, im Gegensatz zu einem Punkt-zu-Punkt-2,4-GHz-Schema oder sogar dem "Esp Now" -Protokoll.

— Chris Stratton

1

Guter Punkt. Sie können das Problem mit dem gemeinsamen geheimen Schlüssel beheben, indem Sie WPA2-Unternehmensclientzertifikate anstelle eines SSID-Kennworts verwenden (wenn das IoT-Gerät groß genug ist, um einen TLS-Stapel zu haben, sind dies viele nicht). Ich weiß nichts über Azure IoT Hub, gehe jedoch davon aus, dass diese Azure-Geräteverbindungszeichenfolgen für jedes Gerät bereits eindeutig sind. Leider scheint dies ein ziemlich sauberes Schwarz-Weiß zwischen "DIY no security" und "Industrial scale security" zu sein, wobei nicht viel dazwischen liegt.

— Mike Ounsworth

2

Ich frage mich, warum ich die Anmeldeinformationen benötige, wenn ich eine Sitzung nach Belieben eröffnen kann?

— Andrew Savinykh

1

@ AndrewSavinykh Hängt von den Anmeldeinformationen ab. Vielleicht ist alles, was sie tun, eine Sitzung zu eröffnen, in diesem Fall ja, nicht viel Grund. Möglicherweise handelt es sich jedoch um Windows-Domänen-AD-Anmeldeinformationen oder um Zugriffsberechtigungen für zusätzliche APIs, die normalerweise vom IoT-Gerät aus nicht verwendet werden. Vielleicht sind Sie mit Sitzungen von kompromittierten Geräten einverstanden, aber nicht mit Sitzungen von Laptops von Angreifern. Ja, es wird ziemlich schnell anwendungsfallspezifisch.

— Mike Ounsworth

3

Seriennummer??? Eine Seriennummer zu finden, die eindeutig ist, sollte kein Problem sein, aber Seriennummern sind nicht geheim. Sie sind nutzlos, um einen Schlüssel zu bilden. Wo in aller Welt werden Seriennummern verwendet, um einen Schlüssel zu bilden, ein „Standardtrick“?

— Gilles 'SO - hör auf böse zu sein'

6

Die Bedrohung ist real, aber zum Glück sind Sie nicht der erste oder einzige mit solchen Sicherheitsbedenken.

Was Sie brauchen, ist der ESP WiFi Manager, den Sie hier brauchen.

Mit dieser Bibliothek wechselt der ESP, der keine gespeicherte Sitzung hat, in den AP-Modus und hostet ein Webportal. Wenn Sie mit einem PC oder Smartphone eine Verbindung zu diesem AP herstellen, können Sie die WiFi-Anmeldeinformationen über eine Webseite konfigurieren.

Sie müssen die kritischen Informationen nicht fest codieren, und Sie können Ihr Gerät in jedem gewünschten WiFi-Netzwerk verwenden, ohne es erneut blinken zu müssen.

Wie es funktioniert

Wenn Ihr ESP gestartet wird, wird es im Stationsmodus eingerichtet und versucht, eine Verbindung zu einem zuvor gespeicherten Access Point herzustellen

Wenn dies nicht erfolgreich ist (oder kein vorheriges Netzwerk gespeichert wurde), wechselt der ESP in den Access Point-Modus und startet einen DNS- und einen WebServer (Standard-IP-Adresse 192.168.4.1).

Stellen Sie über ein WLAN-fähiges Gerät mit einem Browser (Computer, Telefon, Tablet) eine Verbindung zum neu erstellten Access Point her

Aufgrund des Captive-Portals und des DNS-Servers erhalten Sie entweder ein Popup vom Typ "Mit Netzwerk verbinden" oder eine beliebige Domäne, auf die Sie zugreifen möchten, wird an das Konfigurationsportal umgeleitet

Wählen Sie einen der gescannten Zugangspunkte, geben Sie das Passwort ein und klicken Sie auf Speichern

ESP versucht eine Verbindung herzustellen. Bei Erfolg gibt es die Kontrolle an Ihre App zurück. Wenn nicht, verbinden Sie sich erneut mit dem AP und konfigurieren Sie ihn neu.

(Dokumentation zu ESP WiFi Manager)

— Bence Kaulics
quelle

1

Oder laden Sie einfach die Aufzeichnungen oder was auch immer, während es im AP-Modus ist. Hoffentlich versucht das Poster nicht, WLAN selbst für die Objektverfolgung zu verwenden.

— Chris Stratton

1

@ ChrisStratton :-) Eigentlich versuche ich, das WiFi für die Anlagenverfolgung zu verwenden. Glücklicherweise ist das von mir verwendete WiFI-Netzwerk öffentlich und offen, aber ich mache mir Sorgen über die Auswirkungen, wenn ich ein anderes verwenden muss, für das ein Kennwort erforderlich ist. Außerdem befindet sich die AzureIoT Hub-Verbindungszeichenfolge auf dem Gerät.

— Widder

2

@rams Sicherlich wäre das Lesen des EEPROM des Geräts keine große Aufgabe.

— Bence Kaulics

3

@rams Auf Ihrer Hardware kann ja EPROM gelesen werden. Neuere Geräte verfügen möglicherweise über sichere Flash-Bereiche, die besser geschützt sind. Dies ist sicherlich ein bekanntes Problem, das On-Chip-Unterstützung benötigt, um es richtig zu machen.

— Sean Houlihane

2

@ SeanHoulihane - der ESP8266 hat kein EEPROM. Das SPI-Flash, das es für alles verwendet (einschließlich der Art der Emulation der Arduino-Funktionalität), befindet sich außerhalb des ESP8266. Selbst im Multi-Chip-Modul ist es ein eindeutiger Chip, der in einem anständigen Labor getestet werden kann.

— Chris Stratton

3

Ja, sie können auf Ihr Passwort zugreifen, wenn Sie es als einfachen Text belassen.

Der gute Punkt ist, dass viele WiFi-Verbindungsschnittstellen Hash-Passwörter akzeptieren. Während die, die ich verwendet habe, MD5-Hashes akzeptiert haben und MD5 nicht besonders sicher ist, ist es für Durchschnittsjoe immer noch eine sehr schwere Herausforderung. Abhängig von Ihrer Konfigurationsdatei geben Sie entweder den Namen Ihres Hashing-Algorithmus an und schreiben dann Ihr Passwort oder Sie verwenden die Standardeinstellung, die Ihre WLAN-Schnittstelle verwendet.

— Atakanyenel
quelle

3

Wenn sie ein gehashtes Passwort extrahieren können, das funktioniert, während sie gehasht haben, was hindert sie daran, es zu verwenden, ohne es jemals umzukehren?

— Chris Stratton

1

@ ChrisStratton Sie haben Recht. Wie dies für Information Security SE verhindert werden kann, wird in dieser Frage gefragt, ob der Verlust von Anmeldeinformationen verhindert werden soll. Nichtsdestotrotz können gehashte Passwörter von Mobiltelefonen nicht verwendet werden, um ohne zusätzliche Software eine Verbindung zum Netzwerk herzustellen.

— Atakanyenel

1

Ja, tatsächlich würde es einen gewissen Schutz für den Fall bieten, dass das WLAN-Passwort auf einem anderen System wiederverwendet wird, aber nicht viel gegen unbefugte Verbindung zu diesem WLAN-Zugangspunkt.

— Chris Stratton

1

@ChrisStratton Ja, zum Beispiel ist das MAC-Whitelisting viel sicherer als nur ein Passwort zu haben und es zu haschen, aber diese Schritte dienen im Allgemeinen der WLAN-Sicherheit und nicht der Vertraulichkeit von Anmeldeinformationen auf öffentlichen Geräten.

— Atakanyenel

2

Nein, das MAC-Whitelisting ist ein Witz - es gibt überhaupt kein Geheimnis . Und natürlich lässt sich der MAC leicht aus dem gestohlenen ESP8266 oder dessen SPI-Flash extrahieren. Über den einzigen Ort, an dem MAC-Whitelists hilfreich sind, richten Sie sich gegen Personen, die eine grafische Benutzeroberfläche verwenden, um WLAN-Netzwerken beizutreten, oder wenn ein Zugriffspunkt dort auf eine Verbindung von einem Client gewartet hat, der möglicherweise eines Tages angezeigt wird, aber noch nie eine Verbindung dazu hergestellt hat - d. H , Schwert im Steinsachen.

— Chris Stratton

1

Einfache Antwort - JA. Es kann getan werden. Sie müssen zumindest eine Art Verschleierung vornehmen , um einen minimalen Schutz zu gewährleisten.

— Amit Vujic
quelle

1

Durch die Verschleierung wird es schwieriger, die Funktionsweise des Geräts zu ermitteln, es ist jedoch sinnlos, das Gerät vor dem Klonen zu schützen . Es ist sinnlos, sich vor der Entnahme von Anmeldeinformationen zu schützen: Alles, was Sie tun müssen, ist, die Firmware in einem Emulator auszuführen.

— Gilles 'SO - hör auf böse zu sein'

Stimme voll und ganz zu. Meine Motivation, eine solche Antwort zu geben, war die Feststellung, dass <IoT-Netzwerksicherheit berücksichtigt werden muss>. @Mike Ounsworth gab detaillierte Antworten und schlug Lösungen mit AES- und / oder RSA-Infrastruktur vor. Ich überlege, noch eine Antwort zu geben, bin mir aber nicht sicher, wie es mit Kryptografie weitergehen soll (ich bin auch seit vielen Jahren in Zahlungs- und Banklösungen tätig). Meines Erachtens müssen wir praktische / ausgewogene Ratschläge geben, da die Leute es normalerweise vermeiden, sich eingehend mit Kryptografie zu befassen, um IoT-Geräte in seinem Hinterhof zu schützen.

— Amit Vujic

1

Wenn Leute unsichere Geräte herstellen möchten, weil sie nicht die Mühe haben, herauszufinden, wie sichere Geräte hergestellt werden, sehe ich keinen Grund, sie zu aktivieren.

— Gilles 'SO - hör auf böse zu sein'

Ich habe die Erfahrung gemacht, dass Menschen lernen wollen, aber auch hier muss ein Gleichgewicht zwischen Sicherheitsstufe und Komplexität bestehen. In der Zahlungsindustrie gibt es eine berühmte Geschichte in Bezug auf SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ), die sehr sicher ist / war, aber komplex zu implementieren ist und aus diesem Grund in der Praxis gescheitert ist.

— Amit Vujic

2

Verschleierung erhöht die Komplexität, ohne die Sicherheit zu verbessern. Das ist kein Gleichgewicht.

— Gilles 'SO - hör auf böse zu sein'