Design for Security: Sichere Embedded-Lösungen entwickeln

| Autor / Redakteur: Dyfan Davies * / Michael Eckstein

Security first: In einer umfassend vernetzten Welt muss die IT-Sicherheit der beteiligten Systeme an erster Stelle stehen.
Security first: In einer umfassend vernetzten Welt muss die IT-Sicherheit der beteiligten Systeme an erster Stelle stehen. (Bild: Clipdealer)

Firmen zum Thema

Embedded-Systeme sind heute überall zu finden und bilden den Motor unserer modernen Gesellschaft. Mehr denn je entscheiden die Überlegungen und Prozesse in der Entwicklung über die Sicherheit unserer Endprodukte.

Am Anfang ist die Idee. Auch das Entwickeln einer IoT-Applikation startet damit. Security-Aspekte stehen zu diesem Zeitpunkt hingegen meist nicht im Vordergrund. Das rächt sich spätestens dann, wenn diese später im Entwicklungsverlauf nachgerüstet werden müssen. Denn IT-Sicherheit ist gerade in vernetzten Systemen – was das IoT per Definition ist – essenziell. Daher lohnt es, bewährte Embedded-Entwicklungsprozesse zu befolgen, die die Security von Beginn an einbeziehen. So können Entwickler IT-Sicherheit ihrer Produkte kontinuierlich beurteilen. Abhängig von der Anwendung führen mehrere Design-Prozesse zum Ziel, zum Beispiel:

  • MS Security Development Lifecycle (MS SDL): Microsoft hat als ersten seiner Art den MS SDL zusammen mit den Phasen eines klassischen SDLC vorgeschlagen.
  • NIST800-64: Dieser Standard deckt die Security-Überlegungen innerhalb des SDLC ab. Das National Institute of Standards and Technology (NIST) hat diese Norm entwickelt, die durch die US-amerikanischen Bundesbehörden überwacht wird.
  • OWASP CLASP (Open Web Application Security Project, Comprehensive, Lightweight Application Security Process): Dieser Prozess lässt sich einfach implementieren und beruht auf dem MS SDL. Er verknüpft die Security-Maßnahmen mit entsprechenden Rollen in einer Organisation.

Jeder Design-Prozess, der eine Bedrohungsanalyse, Security-Anforderungen, abgesichertes Design, sichere Implementierung, Test/Verifizierung für Security-Aspekte erfüllt und einen Notfallplan für mögliche Probleme nach der Produkt-Freigabe bietet, wird folgende Anforderungen erfüllen:

  • Bedrohungsszenarien-Modellierung: Untersucht mögliche Bedrohungen für das Produkt. Dabei müssen viele Bedrohungsmodelle berücksichtigt werden, etwa CIA (Confidentiality, Integrity and Availability – Vertraulichkeit, Integrität und Verfügbarkeit) sowie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege – Vortäuschungen, Manipulationen, Verstöße, Offenlegung von Informationen, Denial of Service und die Erhöhung von Berechtigungen). Die Modellierung möglicher Bedrohungen ist ein entscheidender Prozess für das Entwickeln einer abgesicherten Anwendung. Mit ihr kann der Entwickler mögliche Sicherheitslücken ermitteln und effektive Gegenmaßnahmen innerhalb seines Budgetrahmens ergreifen.
  • Security-Anforderungen: Hier geht es um die Definition der Security- und Datenschutzanforderungen, wobei auch das vorgesehene Security-Level festgelegt wird.
  • Abgesichertes Design: In der Regel sind die einfachsten Systeme am sichersten, da diese weniger Angriffspunkte bieten. Dies lässt sich durch Zugriffsbeschränkungen, das Anwenden des Prinzips minimaler Berechtigungen und – wo immer möglich – das Nutzen mehrschichtiger Abwehrmaßnahmen erzielen. In der Designphase bedeutet dies, das Design in kleinere, einfach zu handhabende Aufgaben aufzuteilen.
  • Implementierung: Die Implementierung des Designs ist der am schwierigsten auszuführende Schritt. Als hilfreich erweist sich hier, in kleinen, iterativen Schritten abgesicherte Software zu implementieren.
  • Testen: Die Aufgabe von Tests ist es, sicherzustellen, dass die Implementierung richtig ist. Security-Tests sind ein weitreichendes Thema. Für das Prüfen jeder Applikation sollte man genügend Zeit investieren. In Bezug auf Security umfassen Testverfahren statische und dynamische Analysen, Fuzz-Tests sowie eine Analyse der möglichen Angriffspunkte.
  • Freigabe: Bei der Produktfreigabe hat es sich bewährt, einen Incident-Response-Plan zu definieren und sicherzustellen, dass es eine Vorgehensweise zum Beheben sämtlicher, eventuell auftretender Security-Probleme gibt.

Das Befolgen eines abgesicherten Entwicklungsprozesses ist unabdingbar. Der folgende Abschnitt zeigt eine Reihe von Überlegungen, was beim Design im Hinblick auf die Security und den Entwicklungsablauf bei einem IoT-Gerät zu beachten ist.

Einfache, abgesicherte Lösungen lassen sich einfacher handhaben als komplexe oder verschachtelte. Daher ist es wichtig, das Design einfach zu halten. Komplexe Lösungen lassen sich in kleinere, leichter wartbare Komponenten aufspalten. Zugangsbeschränkungen zu Modulen, Testbarkeit, Auditierbarkeit, Daten-Isolation und Schadensbegrenzung lassen sich so einfacher in einer definierten, klaren Struktur realisieren.

Minimale Implementierungen erfordern lediglich das Entwickeln eines Systems mit der kleinstmöglichen Menge an abgesicherten Daten. So bedeutet etwa der Einsatz einer MCU zur Weitergabe von verschlüsselten Daten nicht automatisch, dass die MCU irgendwelche Schlüssel zur Ver- oder Entschlüsselung enthält. Das Nutzen unterschiedlicher Threads in einem Betriebssystem (OS) ist ein einfacher Weg zur Modularisierung von Software. Der Einsatz eines Betriebssystems führt wegen des kontextabhängigen Umschaltens im Scheduler zu einer gewissen Unberechenbarkeit, was als Vor- oder Nachteil für ein System gesehen werden kann. Vorteilhaft ist, dass ein Angreifer das Code-Verhalten nicht umfassend vorhersagen kann. Als Nachteil gilt, dass der Entwickler nicht alle Bedrohungen vollständig antizipieren kann, die möglicherweise mit dem Einsatz eines Betriebssystems einhergehen.

Designüberlegungen für eine sichere Entwicklung

Ein weiterer Punkt bei der Auswahl eines Betriebssystems besteht darin, dass Entwickler ein gutes Verständnis von Betriebssystemkonzepten wie Mutexes, Semaphores, Speicherpools, Thread Stacks usw. haben müssen. Nur so können sie sicherstellen, dass sich ein Thread nicht dazu nutzen lässt, einen anderen auszunutzen. Bei der Entwicklung kann es von Vorteil sein, ein bereits getestetes Betriebssystem zu nutzen, anstelle weitere Zeit in den Test einer eigenen Lösung zu investieren. Allerdings lässt sich eine Software ohne Betriebssystem für einfache Applikationen oftmals leichter implementieren und ist möglicherweise auch besser für die entwickelte Anwendung geeignet.

Die RX-Mikrocontroller-Familie (MCU) von Renesas unterstützt beide Wege. Komponenten sollten nur Zugriff auf Ressourcen haben, die absolut erforderlich sind. Daher sollten sie anfänglich ohne jegliche Benutzerprivilegien ausstattet sein und nur unbedingt erforderliche Berechtigungen erhalten. Ein LCD-Treiber sollte beispielsweise nicht in der Lage sein, auf einen A/D-Wandlertreiber zuzugreifen, wohl aber auf das Ergebnis des zugewiesenen A/D-Wandlerkanals. Dies gewährleistet, dass der Angreifer des Ausgabekanals nicht auf andere A/D-Wandlerkanäle zugreifen kann. Funktion, Leistung und Kosten sind die grundlegenden Kriterien für die Wahl einer MCU. Geeignete Security-Funktionen sollten als ein wesentliches Entscheidungskriterium unbedingt mit berücksichtigt werden. Generell kommen drei Arten von MCUs für die Entwicklung abgesicherter Anwendungen in Frage.

  • Standard-MCUs
  • Standard-MCUs mit Krypto-Engine
  • Standard-MCU mit Trusted Secure IP

Dies führt zur Frage, welcher Ansatz die meisten Vorteile bietet – Hardware-beschleunigte Kryptographie oder eine in Software implementierte Kryptographie? Hardware-beschleunigte Verschlüsselung ist wesentlich schneller als eine in Software implementierte Kryptographie. Auch benötigt sie weniger Energie. In Software implementierte Kryptographie ist für manche Applikationen zu langsam. Einen Algorithmus in Software zu implementieren, erfordert zudem zusätzlichen Zeitaufwand für das Entwickeln und Testen der Anwendung.

Bei der höchsten Stufe des Schlüsselschutzes kommt eine Hardware-Implementierung zum Einsatz, wie bei den RX-Chips mit Trusted Secure IP (TSIP). Bei einer reinen Software-Implementierung ist der Schlüsselschutz weniger stark. Die Implementierung von Hardware- oder Software-Sicherheitsalgorithmen in einem IC hängt von individuellen Designanforderungen ab. Beide Ansätze haben ihre Vorteile und lohnen der Evaluierung. Die Integrität des Schlüssels ist grundsätzlich der ausschlaggebende Punkt für eine angemessene Root-of-Trust. Dies erfordert eine sichere Hardware, etwa TSIP. Bei der Entwicklung eines sicheren Codes sind zahlreiche Dinge zu beachten: Kodierungsstandards, Compiler und das Verwenden von statischen/dynamischen Code-Analysewerkzeugen. Viele von diesen können die Leistung und Qualität der Software verbessern. Dazu müssen sie diese auf mögliche Sicherheitslücken untersuchen, zum Beispiel:

  • Pufferüberlauf (Buffer Overflow): Wird ein Array über seine Grenzen hinaus beschrieben, dann kann ein Angreifer möglicherweise Befehle injizieren und die Kontrolle über die MCU übernehmen.
  • Zuordnungsgrenzen: Den Programmiersprachen C und C++ fehlt eine starke Typsicherheit während der Compilierungszeit. Codierungsstandards können diesen Mangel abmildern, allerdings kann ein Integer-Überlauf nach wie vor auftreten und Schwachstellen verursachen.
  • Fehlender Case: Beim Schreiben einer Switch/Case-Anweisung sind manchmal nicht alle möglichen Werte abgedeckt und ein Standardfall wird nötig.
  • Stack-Überlauf: Während der Programmlaufzeit kann ein Stack-Überlauf aufgrund einer unzureichenden Stack-Größe oder aufgrund von Softwarefehlern auftreten.
  • Speicherlecks: Ein Speicherleck tritt auf, wenn eine Funktion Speicher zuweist, den Speicher aber nie freigibt. Weiß ein Angreifer um diese Schwachstelle, kann er diese dazu nutzen, den normalen Betrieb des Gerätes zu beeinträchtigen.

Die Kaskadierung von Sicherheitslücken kann schwer wiegende Lecks mit verheerenden Auswirkungen bewirken. Dies wird bei der ersten Bedrohungsanalyse oft nicht berücksichtigt. Manche abgesicherten Anwendungen verlassen sich auf bewährte Hard- und Software-Komponenten von Drittanbietern. Entwickler sollten auf zuverlässige und vertrauenswürdige Lieferanten setzen und auch sicherstellen, dass nach der Freigabe des Produkts ein Verfahren zum Beheben von Security-Problemen implementiert ist. Renesas bietet einen TSIP-Treiber für seine RX-Familie an, um die Anzahl möglicher Software-Sicherheitslücken zu begrenzen. TSIP steuert RSA-, SHA-, AES-, AES-GCM- und AES-CMAC-Ver- und Entschlüsselung. Sie beherrscht außerdem echte Zufallszahlengenerierung und kann High-Speed-Hardwareberechnungen unter Nutzung von Embedded-Hardware-Beschleunigern ausführen.

Der TSIP-Treiber hilft auch bei der sicheren Verwaltung der Benutzerdaten und Schlüssel. Diese Funktionen ermöglichen darüber hinaus eine sichere Aktualisierung des Embedded-Flash-ROMs und verhindern ein Hochfahren illegaler Firmware (Secure Booting). Dementsprechend kann diese Hardware-IP mit dedizierten Software-Treibern dabei unterstützen, eingebettete IoT-Geräte vor Viren und Lauschangriffen zu schützen. Die TSIP bietet Leistungsmerkmale wie Kryptographie-Funktionen für erhöhte Sicherheit, die sich kostengünstig in Großserienanwendungen einbetten lassen; schnelle Ausführung von AES, dem wichtigen weltweiten Standard für Kryptographie-Algorithmen sowie Unterstützung für AES-GCM, RSA und SHA, die häufig Teil der geforderten Spezifikationen für IoT-Geräte sind. Darüber hinaus sind Funktionen für abgesicherte Firmware-Updates sowie Funktionen für sicheres Hochfahren von Benutzerprogrammen integriert. Der RX-TSIP-IP-Treiber lässt sich auf kompatibler Hardware implementieren und mit anderen Geräte-Treibern auf RX-MCUs. So hilft er Designern, sichere Anwendungen zu entwickeln.

* Dyfan Davies ist Engineer in der Software Development Division der Broad-based Solution Business Unit bei Renesas Electronics Europe

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45514812 / Safety & Security)