In einem vorhergehenden Blog habe ich die Sicherheitsanforderungen für eingebettete Speicher diskutiert und betont, dass die Erhöhung der Sicherheit von Produkten wie IoT-fähigen Geräten eine viel höhere Priorität haben sollte, als dies derzeit der Fall ist. Und in einem weiteren Blog habe ich skizziert, wie eingebetteter Speicher angegriffen werden könnte, und einige einfache Lösungen angeboten. Jetzt ist es an der Zeit, darüber zu sprechen, wie eingebetteter Speicher vor Cyber-Angriffen geschützt werden kann.
Anwendungen, die viel Speicher (insbesondere NVM) verwenden, sind attraktive Ziele für Hacker, da sich dort die Daten befinden, nach denen sie suchen (und / oder die Funktionalität, die sie kompromittieren möchten).
Partitionierung
Das erste, was zu tun ist, um den eingebetteten Speicher zu sichern, ist die erzwungene Hardwarepartitionierung. Viele Mikrocontroller teilen ihren internen Speicher in sichere und nicht sichere Bereiche auf, wobei nur erstere für ausführbaren Code verwendet werden sollten. Beispielsweise sind viele ARM-basierte Mikrocontroller mit internen Speicherschutzeinheiten (MPUs) erhältlich, eine für jeden Speicherbereich.
Viele Systeme benötigen jedoch oft zusätzlichen Speicher, um eine einfache Erweiterung zu einem späteren Zeitpunkt zu unterstützen und/oder das gleiche Mikro (Mikrocomputer) im Herzen einer Produktfamilie zu haben; d.h. Sie können bei Ihrem bevorzugten Mikro bleiben.
Eine MPU kann während der verschiedenen Betriebsmodi des Systems steuern, auf welche Speicherbereiche zugegriffen werden kann (und mit welchen Berechtigungen – z. B. nur Lesen oder Lesen/Schreiben).
In einem früheren Blog habe ich beispielsweise erklärt, wie Speicherpufferüberlaufangriffe funktionieren; im Wesentlichen durch das Kopieren von Daten in einen Puffer (Speicherbereich), um diesen in den Bereich des Ausführungscodes überlaufen zu lassen.
Eine strikte Hardwarepartitionierung würde verhindern, dass während des normalen Systembetriebs etwas in den Speicherplatz geschrieben wird, der für ausführbaren Code vorgesehen ist. Diese Praxis wird oft als Schutz des ausführbaren Speicherplatzes (ESP) bezeichnet.
Es gibt jedoch noch andere Schwachstellen, beispielsweise sind viele eingebettete Systeme während des Bootloads anfällig.
Die Rolle des Speichers für das Secure Bootloading
Die meisten Bootloader – sicherlich in schlichten, kostengünstigen Embedded-Systemen – sind einfach und führen Prüfsummen durch, um zu überprüfen, ob das Software- / Firmware-Image vollständig ist. Ein Bootloader hat jedoch die Fähigkeit, eine Vertrauenskette (Chain of trust) aufzubauen, die für verbundene eingebettete Systeme wie IoT-Geräte und solche, die Upgrades im Feld durch physischen Zugriff ermöglichen, unerlässlich ist.
Wie die meisten Leser wissen werden, ist der Bootloading-Prozess ungefähr wie folgt. Für neue Firmware wird eine Prüfsumme (auch bekannt als Hash) generiert und dann mit einem privaten Schlüssel verschlüsselt, um eine Signatur zu erstellen. Die Firmware, die manchmal auch verschlüsselt ist, und die Signatur werden dann im Feld in das System gebootet. Das System verwendet dann einen öffentlichen Schlüssel, um die Prüfsumme und gegebenenfalls die Firmware zu entschlüsseln. Authentifizierte und intakte (wie durch die Prüfsumme verifiziert) Software/Firmware kann dann geladen werden.
Um jedoch sichere Bootloads zu ermöglichen, muss der Mikrocontroller des Systems im Feld eine Reihe von Dingen unterstützen. Dazu gehören eine kryptografische Engine, eine sichere Speicherung von Schlüsseln und natürlich ein Speicherschutz.
Das Betriebssystem und die Softwaresprache
Während der Fokus des Blogs auf dem physischen Speicher liegt, müssen wir die Themen Betriebssysteme und die Sprache, in der das eingebettete System programmiert ist, erwähnen.
Ein sicheres Betriebssystem (auch bekannt als Trusted OS, vertrauenswürdiges Betriebssystem) ist eines, das anhand des international anerkannten Common Criteria (CC) Sicherheitsbewertungsstandards getestet und mit einem Evaluation Assurance Level (EAL) -Ranking eingestuft wurde. Es gibt sieben CC-EAL-Stufen, die nicht nur auf Betriebssysteme, sondern auch auf IT-Produkte und eingebettete Systeme angewendet werden können. Sie können sich über CC EAL in unserem Leitfaden zur Sicherung eingebetteter Systeme informieren.
Zu den Dingen, die ein Betriebssystem vertrauenswürdig machen, gehören Speicherschutz, Dateischutz, Benutzerauthentifizierung und Zugriffskontrolle für E/A-Geräte.
Was die Programmiersprachen betrifft, so und wie in einem früheren Blog angedeutet, sind Low-Level-Sprachen (wie C) uneingeschränkt; und der Grund dafür, dass Speicherüberläufe möglich sind, versehentlich oder absichtlich. Mit einer höheren Sprache sind Sie besser beraten, beispielsweise überprüft Java automatisch Array-Grenzen, sodass Speicherpufferüberläufe im Allgemeinen nicht möglich sind.
Das Herz des Systems
Wie bereits erwähnt, ist der Speicherschutz etwas, das ein guter Mikrocontroller bieten sollte. Auf der Grundlage, dass die Authentifizierung für die Abwehr von Cyberangriffen von entscheidender Bedeutung ist, sollten Sie jedoch einen zusätzlichen Schutz neben Ihrem Mikrocontroller (oder Mikroprozessor) in Betracht ziehen.
Microchip Technology verfügt beispielsweise über eine Familie kleiner, stromsparender CryptoAuthentication–ICs, die mit jedem Mikrocontroller/Mikroprozessor funktionieren. Zu den Gerätefunktionen gehören eine eindeutige und nicht veränderbare 72-Bit-Seriennummer (von Microchip festgelegt), eine 512-Bit-OTP-Zone (One-Time Programmable), ein Zufallszahlengenerator und ein SHA-256-Hash-Algorithmus für die Datenverschlüsselung. Dazu gehören auch APIs zum Speichern, Abrufen und Bearbeiten von X.509-Zertifikaten für die TLS-Integration (Transport Layer Security).
Diese Technologie ist sehr effektiv, weil sie eine Rolle bei der Etablierung der oben genannten Vertrauenskette (Chain of Trust) spielt.