American football players at arena . Mixed media

(Bild: Fotolia)

| von Warren Kurisu

Auch wenn es eine hundertprozentige Sicherheit für tragbare IoT-Geräte niemals geben wird, sollten Softwareentwickler und -architekten ihren Teil dazu beitragen, Gefahren durch Hackerangriffe und Datenschutzverletzungen zu minimieren. Viele der erforderlichen Sicherheitsmaßnahmen sind bereits heute verfügbar. In einigen Fällen muss sich jedoch die Denkweise rund um die Entwicklung von Sicherheitsmaßnahmen ändern. Grundsätzlich darf man die Sicherheit beim Design von Embedded-Systemen nie als nachrangig einstufen. Sicherheitsaspekte sind bereits vom ersten Tag der Konzeption an zu berücksichtigen. Die Entwicklung von Sicherheitsmaßnahmen sollte als Schutz des Designs betrachtet werden – als eine Investition und nicht als Kostenfaktor.

Sicherheit beginnt bei der Konzeption eines Geräts und erstreckt sich über Planung, Entwicklungsprozesse und Technologiefragen. Dieser Artikel konzentriert sich auf Schlüsseltechnologien, die für die Entwicklung sicherer tragbarer Geräte hilfreich, wenn nicht sogar entscheidend sind.

Authentifizierungsmaßnahmen

Bild 1: Zur Code-Authentifizierung sind ein öffentlicher und ein privater Schlüssel erforderlich.

Bild 1: Zur Code-Authentifizierung sind ein öffentlicher und ein privater Schlüssel erforderlich. Mentor Graphics

Eine wichtige Sicherheitstechnik sind Authentifizierungsmaßnahmen. Dazu gehört etwa die Code-Authentifizierung, bei der es im Wesentlichen um eine Authentifizierung des binären Betriebssystem-Images geht. Entwickler können ihr System einrichten und dann überprüfen, ob die eingehenden Daten vom Original Equipment Manufacturer (OEM) stammen. Zudem müssen sie untersuchen, ob irgendein Teil des Codes verändert wurde.

Bild 2: Prinzipieller Ablauf zur Authentifizierung des sicheren Bootens.

Bild 2: Prinzipieller Ablauf zur Authentifizierung des sicheren Bootens. Mentor Graphics

Code-Authentifizierung (Bild 1) und Authentifizierung des sicheren Bootens (Bild 2) sind grundlegende Schritte zur Absicherung von Embedded-IoT-Geräten: Zur Code-Authentifizierung sind ein öffentlicher und ein privater Schlüssel erforderlich. Der öffentliche Schlüssel wird allen im Netzwerk über eine öffentlich zugängliche Quelle oder ein Verzeichnis zur Verfügung gestellt. Der private Schlüssel ist vertraulich und nur für den jeweiligen Eigentümer bestimmt. Da das Schlüsselpaar mathematisch verknüpft ist, kann alles was mit einem öffentlichen Schlüssel verschlüsselt ist, nur von dem entsprechenden privaten Schlüssel entschlüsselt werden – und umgekehrt. Diese Art der Authentifizierung erreicht ein hohes Maß an Vertraulichkeit.

Die Authentifizierung des sicheren Bootens beginnt mit der Ausführung eines First-Stage-Boot-Loaders, der in einem sicheren Flash-Speicher gespeichert ist und von Trusted-Platform-Module-Hardware (TPM) zur Verfügung gestellt wird. Dieser Boot-Loader befindet sich in einem geschützten Speicher, sodass Hacker ihn nicht austauschen können. In diesem geschützten Speicher sind auch die Signatur und der Krypto-Schlüssel für den Second-Stage-Boot-Loader gespeichert. Der First-Stage-Boot-Loader berechnet die Signatur des Second-Stage-Boot-Loaders mithilfe der Verschlüsselungshardware und des Krypto-Schlüssels. Wenn die berechnete Signatur für den Second-Stage-Boot-Loader mit der gespeicherten Signatur übereinstimmt, dann ist der Second-Stage-Boot-Loader gültig und darf ausgeführt werden.

Vertrauenskette etablieren

Bild 3. Nach der ersten Boot-Phase beginnt der Prozess zum Aufbau einer Vertrauenskette.

Bild 3. Nach der ersten Boot-Phase beginnt der Prozess zum Aufbau einer Vertrauenskette. Mentor Graphics

Sobald die erste Boot-Phase bestätigt wurde, kann der Prozess zum Aufbau einer Vertrauenskette fortgesetzt werden. Durch Nutzung der gleichen öffentlichen/privaten Schlüssel lassen sich die ausführbare Module herunterladen, verifizieren, laden und ausführen (Bild 3). Die Vertrauenskette beginnt an der Basis, der Hardware. Der Prozess startet mit dem Authentifizierungsschritt und gewährleistet so, dass die Hardware den Boot-ROM authentifiziert. Der Boot-ROM authentifiziert dann das Betriebssystem und anschließend authentifiziert das Betriebssystem die Anwendungsebene.

Das Ziel dieser Strategie ist zu verhindern, dass nicht signierte und nicht authentifizierte Anwendungen ausgeführt werden. Wenn das System hochgefahren ist und läuft, kann der Anwender Angriffe und das Hochladen von schädlichem Code verhindern, indem er sicherstellt, dass jede heruntergeladene Datei signiert und authentifiziert ist. Interessant wird der Ansatz einer Vertrauenskette insbesondere bei komplexen tragbaren Geräten, die in Abhängigkeit der funktionalen Anforderungen, die zu einem bestimmten Zeitpunkt erforderlich sind, verschiedene Betriebsumgebungen und Anwendungen laden.

Trennung der Prozesse

Viele der heute verfügbaren IoT-Geräte bieten eine verbesserte Systemleistung zur Ausführung robuster Anwendungen. Da Größe, Leistungsaufnahme und Kosten weiter reduziert werden müssen, wird von Software-Entwicklern gefordert, dass sie komplexe Applikationen trotz begrenzter Speicherressourcen realisieren. Gerade bei solchen Anwendung ist eine Trennung von Prozessen sinnvoll. Auch wenn die Prozesstrennung mittels System-MMU oder MPU allein noch keine Garantie für Sicherheit bietet, sorgt sie doch dafür, dass fehlerhafte Anwendungen keine anderen Anwendungen oder den Kernel selbst beeinträchtigen.

In einem Echtzeit-Betriebssystem (RTOS) wie dem Nucleus-RTOS von Mentor Graphics ermöglicht das Prozessmodell eine Partitionierung des Speichers, die geschützte Speicherbereiche zur vollständigen Isolierung von Kernel und Middleware-Ressourcen erzeugt. Auf diese Weise können Probleme wie etwa Stapelüberläufe, die sich im Anwendungscode befinden, den Betrieb der System-Software nicht mehr länger beeinträchtigen oder beschädigen. Das Nucleus-Prozessmodell partitioniert den Speicher und erzeugt ohne Speichervirtualisierung geschützte Speicherbereiche. Dies ist besonders für speicherplatzbeschränkte Anwendungen wichtig, wo es auf einen minimalen Footprint ankommt. Speicherpartitionierung bietet den Rahmen, um mit Cloud-Diensten neue Anwendung zu laden oder die Möglichkeit, große Algorithmen in kleinere Komponenten aufzuteilen.

Sicherheitszertifiziertes Betriebssystem

Wie bei der Verwendung eines Prozessmodells garantiert auch ein sicherheitszertifiziertes Betriebssystem für sich genommen noch keine Sicherheit. Auf Grundlage einer sicherheitszertifizierten Basis können Entwickler sich jedoch darauf verlassen, dass sich der Code wie beabsichtigt verhält, was die Zuverlässigkeit des Systems verbessert. Sicherheitszertifizierte Umgebungen vermeiden kritische Situationen, die von Softwarefehlern herrühren, welche sich über das System verbreiten und zu Sicherheitslücken in damit nicht zusammenhängenden Codebereichen führen können.

Nucleus RTOS SafetyCert verkürzt mit einer vollständig zertifizierten Lösung, die alle erforderlichen Dokumentationen und Artefakte enthält, den Weg zur behördlichen Zertifizierung. Anwender brauchen diese Zertifizierung für die Entwicklung kritischer Applikationen. Diesem sicherheitszertifizierten RTOS wurde bescheinigt, dass es die Anforderungen für tragbare oder medizinische Geräte erfüllt, die eine Zertifizierung gemäß International Electrotechnical Commission (IEC) Standard 62304 benötigen.

Sicherheit durch Unterteilung

Bild 4. Die ARM TrustZone eignet sowohl für Einzelkern-Konfiguration (links) als auch für Mehrkern-Architekturen (rechts).

Bild 4. Die ARM TrustZone eignet sowohl für Einzelkern-Konfiguration (links) als auch für Mehrkern-Architekturen (rechts). Mentor Graphics

Die ARM-TrustZone-Architektur (Bild 4) bietet eine Lösung zur Unterteilung der SoC-Hardware. Dazu definiert sie Prozesse, Peripheriekomponenten, Speicheradressen und sogar Bereiche des L2-Cache als „sicher“ beziehungsweise „nicht sicher“ ablaufende Hardware. Ein SoC mit ARM-TrustZone-Technologie kann mit nur wenigen Taktzyklen Verzögerung ein System dynamisch in eine „sichere Welt“ überführen, wo ein Teil der Hardware und der Daten für den Rest des Systems unsichtbar ist. Der andere Teil wird entsprechend als „unsichere Welt“ beziehungsweise „normale Welt“ definiert.

Bild 4 rechts

Mentor Graphics

Die ARM TrustZone gewährleistet, dass eine unsichere Verarbeitung nur unsichere Ressourcen adressiert und nur unsichere Interrupts empfängt. Zum Beispiel kann der zugehörige Hardware-Teilbereich die UART- und USB-Schnittstellen enthalten, aber vom Ethernet-Zugriff ausgeschlossen sein. Ethernet könnte stattdessen der sicheren Welt zugeordnet werden, wo separate Echtzeitbetriebssysteme oder Anwendungen laufen, um den Ethernet-Traffic zu managen –unabhängig vom Software-Stack der unsicheren Welt.

Die ARM-TrustZone-Architektur verhindert, dass Software aus der unsicheren Welt auf die Ressourcen der sicheren Welt zugreift. Es ist wichtig zu verstehen, dass die ARM TrustZone sonst nur wenig zur Verbesserung der Safety oder Security von Software in der sicheren Welt beiträgt, außer eben den unerwünschten Zugriff auf die sichere Welt durch Software aus der unsicheren Welt zu verhindern. Für eine vollständig vertrauenswürdige und sichere Welt muss das System zunächst in einen vertrauenswürdigen Zustand booten. Darüber hinaus ist es der Entwickler, der durch sorgfältige Entwicklungsprozesse, Tests, Zertifizierung und Unterstützung einer Strategie der Vertrauenskette in der sicheren Welt festlegt, welche Software vertrauenswürdig ist.

Eck-Daten

Die Sicherheit von IoT-Geräten ist ein komplexes Thema. Sicherheitsfunktionen, wie beispielsweise sicheres Booten, Code-Authentifizierung und Vertrauenskette, muss heute jedes tragbare Gerät in irgendeiner Form aufweisen. Mentor Graphics unterstützt Entwickler mithilfe von Tools, Betriebssystemen, Plattformen und Dienstleistungen dabei, ihre IoT-Geräte sicherer zu machen.

Warren Kurisu

Director Product Management bei der Embedded Systems Division von Mentor Graphics

(ku)

Kostenlose Registrierung

*) Pflichtfeld

Sie sind bereits registriert?