Menü
Gutheil-Schoder-Gasse 8-12, 1100 Wien
sales@mission-embedded.com
<a href=”tel:+43 1 9971993 0″>+43 1 9971993 0</a>
Gutheil-Schoder-Gasse 8-12, 1100 Wien
sales@mission-embedded.com
<a href=”tel:+43 1 9971993 0″>+43 1 9971993 0</a>
Das Thema Security für Embedded Systeme ist ein wichtiger Teil vieler unserer Projekte unabhängig von der Branche des jeweiligen Kunden – sei es aufgrund von Vorgaben der EU-Datenschutzgrundverordnung (DSGVO), Cloud-Konnektivität, Safety-Anforderungen oder anwendungsspezifischen Anforderungen und Bestimmungen. Dieser Artikel zeigt auf Basis eines aktuellen Projektes auf, wie ein solches Security-Konzept implementiert werden kann und gibt Beispiele typischer oder wiederkehrender Hürden und Herausforderungen.
Einer unserer Kunden bat um Unterstützung bei einem Projekt, unsere Security-Expertise erforderte. Der Kunde wollte einen klaren Fahrplan etablieren, um sein Geräte-Portfolio, das sich aus bestehenden und geplanten Medizin-Geräten zusammensetzt, um eine Cloud-Konnektivität zu erweitern. Dabei stellte sich bald heraus, dass drei Lösungen notwendig werden. Dies ist oft der Fall, insbesondere wenn bestehende Geräte oder Maschinen bereits im Feld im Einsatz sind.
Die gewünschte neue Funktion umfasste die Möglichkeit, Daten vom Gerät zu einem Cloud-Service zu übertragen. Die dabei übertragenen Daten beinhalteten nicht nur personalisierte medizinische Daten, sondern auch andere sensible Daten, z.B. Server Credentials. Diese Daten mussten jedenfalls geschützt werden. Ein weiterer wichtiger Punkt war der Schutz des Systems gegen Angriffe von außen via das Netzwerk sowie lokal, um eine Gefährdung des Patienten oder Nutzers auszuschließen.
Aus diesen Gründen hatte Cyber-Security einen besonders wichtigen Stellenwert für den Kunden. Da dieses Thema für den Kunden eine neue Herausforderung war, lieferten die Experten von Mission Embedded technisches Knowhow sowie Prozess-Expertise.
Dem hier beschriebenen Design-Prozess folgend, wurden der genaue Security-Scope sowie die anzuwendenden Standards (hier AAMI TIR 57 für Medizingeräte) definiert und mit dem Kunden sowie Zulassungsbehörden abgestimmt. Entschieden wurde, dass das System einem Security Level 3 entsprechen soll (gemäß IEC 62443-4-2, SL3).
Mission Embedded entwickelte ein Konzept, um alle drei erforderlichen Lösungen zu adressieren und sowohl neue als auch bestehende Geräte mit den relevanten Security-Funktionen auszustatten (z.B. sichere Datenspeicherung, sichere Kommunikation).
Dieser Ansatz hat den entscheidenden Vorteil, dass alle anderen Elemente der Systemarchitektur, Benutzer- und Bediener-Handbücher sowie Zertifizierungsartefakte ohne Modifizierung wiederverwendet werden können.
Das folgende Kapitel behandelt das Security-Konzept näher und zeigt auch, wie und warum es implementiert wurde.
Der erste Schritt laut ME Security Management Prozess war ein Risk Assessment. Gemeinsam mit dem Kunden wurden rund 50 Risiken identifiziert und kategorisiert. Diese Anzahl an Risiken ist nicht ungewöhnlich für solche Projekte. Es folgt ein Auszug typischer Risiken, die in unseren Projekten häufig vorkommen, insbesondere in Bezug auf Bestandssysteme:
Risiko 1 Eine schwache Passwort-Verwaltung und Authentifizierung ermöglicht es Nutzern oder Angreifern auf das System zuzugreifen und Gerätekonfigurationen und Einstellungen zu verändern. (Auf den ersten Blick mag dieses Risiko nicht als hochprioritär eingestuft werden. Doch aufgrund seiner hohen Eintrittswahrscheinlichkeit und seiner möglichen schlimmen Folgen, vor allem da es sich um ein Medizingerät handelt, musste dieses Risiko unbedingt minimiert werden.)
Risiko 2 Eine ungeschützte Klartext-Speicherung ermöglicht die Manipulation von Daten, welche in weiterer Folge auch auf den Server übertragen werden könnten. Falsche Daten, die am Server gespeichert werden, können die Integrität und Authentizität aller am Server gespeicherten Datensätze kompromittieren.
Risiko 3 Aufgrund eines fehlendernsicheren Speichers werden Schlüssel, Zertifikate und andere sensible Informationen im Klartext auf dem unverschlüsselten Dateisystem gespeichert.
Risiko 4 Ein ungesicherter Kommunikationskanal, ein ungesichertes Backend oder Schwachstellen in der Anwendung selbst führen dazu, dass durch manipulierte Daten ein fehlerhafter Code ausgeführt werden kann, d.h. Buffer-Overflow-Attacke, Return-Oriented-Programming (ROP), etc. Diese mögliche Code-Ausführung, kann das gesamte System kompromittieren. Das bedeutet auch, dass unverschlüsselte Daten aus dem System abgefragt werden können.
Risiko 5 Wegen der fehlenden Härtung des Betriebssystems (Eng.: OS hardening; z.B. durch eine Firewall) kann das System aufgespürt werden, Spoofing– und Denial-of-Service-Angriffe werden ermöglicht. Wenn nicht oder schwach gesicherte Schnittstellen offen liegen, kann darüber hinaus durch einen Root Exploit ein Systemzugriff mit schwerwiegenden Folgen ermöglicht werden.
Risiko 6 Eine ungesicherte Debug-Schnittstelle ermöglicht den Zugriff auf das gesamte System und seine Daten entweder durch einen Insider (Standard-Passwort) oder durch schwache Passwort-Richtlinien, usw. Folglich können falsche Daten angezeigt werden, Algorithmen manipuliert werden etc.
Risiko 7 Ein verfälschtes Firmware-Image kann durch Dritte von einer SD-Karte gebootet/installiert werden. Durch fehlende Code-Signaturen und andere Kontrollen wird das gesamte System kompromittiert, was für den Bediener oder Nutzer nicht sichtbar ist. Daher besteht die Gefahr einer Manipulation von Daten und Algorithmen, usw.
Auf Basis der identifizierten und kategorisierten Risiken werden die Zielsetzungen für das System definiert. Jedes Ziel steht in Zusammenhang zu einem oder mehreren identifizierten Risiken, um die Zuordenbarkeit zu gewährleisten. Die folgende Abbildung sowie die untenstehende Liste beinhalten typische Zielsetzungen, die in vielen Fällen adressiert werden müssen:
Um zu verhindern, dass das System in einen manipulierten Zustand eintritt, muss sichergestellt werden, dass nur jene Firmware gebootet wird, die authentifiziert wurde und entsprechend auch Integrität bietet. Dies kann mithilfe von Code-Signaturen erreicht werden, welche die Herkunft der Firmware aus einer vertrauenswürdigen Quelle durch eine Überprüfung ebendieser während des Boot-Prozesses sicherstellen.
Um die Angriffsfläche des Systems einzuschränken, müssen nicht verwendete Schnittstellen deaktiviert und/oder adäquat gesichert (d.h. durch Passwörter) werden.
Um das System vor Angriffen von außen zu schützen, muss das Betriebssystem gehärtet werden. Dies umfasst unter anderem Einstellungen bezüglich der Firewall, Deaktivierung nicht benötigter Services, Malware-Erkennung, Integritätsprüfung, regelbasierte Zugriffskontrolle (Mandatory Access Control System, MAC), um Nutzer und Applikationen einzuschränken, sowie die Konfiguration der Login-Schnittstellen, um unter anderem Brute-Force-Attacken zu verhindern.
Um hochkritische Daten, wie Zertifikate, Kodierungsschlüssel, Server Credentials sowie Messdaten, ausreichend sichern zu können, muss ein sicherer Speicher im System implementiert/verfügbar sein, und zwar durch die Verschlüsselung des Dateisystems basierend auf sicherer Hardware.
Um zu gewährleisten, dass Daten sicher vom System zum Server übermittelt werden, müssen Vertraulichkeit, Integrität und Authentizität für den Kommunikationskanal gesichert werden. Das bedeutet, dass die übertragenen Daten verschlüsselt werden und eine Signatur umfassen. Die Kommunikationspartner am Kommunikationskanal müssen zuvor authentifiziert werden.
Um zu verhindern, dass das System in einen manipulierten Zustand eintritt, müssen Updates gesichert installiert werden können. Das beinhaltet Code-Signaturen und Verifikationen bevor das Update eingespielt wird.
Im nächsten Abschnitt werden die einzelnen Zielsetzungen näher beleuchtet und wir werfen einen Blick darauf, wie sie für das vorliegende Projekt umgesetzt wurden.
Um diese Zielsetzungen zu erfüllen, wurde eine Chain-of-Trust etabliert (siehe hier). In dem Beispielprojekt wurde folgende Chain-of-Trust auf Basis der Mechanismen der spezifischen Systemarchitektur (Linux + NXP i-MX SoC) implementiert. Die Root-of-Trust bildet dabei das Fundament, auf das alle weiteren Mechanismen aufbauen – in dem vorliegenden Projekt das CAAM (Cryptographic Accelerator and Assurance Module). In anderen Projekten nutzen wir beispielsweise Trusted Platform Modules (TPM).
Die gewählte Prozessor-Plattform bietet eine Hardware-seitige Root-of-Trust durch One-time Programmable Keys. Wenn richtig aufgesetzt und abgesichert, validiert der ROM-Bootloader, welcher das High Assurance Boot (HAB) stützt, den 2nd Stage Bootloader durch die Validierung einer Code-Signatur beim Booten. Das System setzt das Booten nur dann fort, wenn die Signatur verifiziert wurde, andernfalls stoppt der Bootvorgang. Daraus folgt, das der 2nd Stage Bootloader in dieser Phase voll vertrauenswürdig ist, da er nur erreichbar ist, wenn er aus einer vertrauenswürdigen Quelle stammt. In diesem speziellen Fall ist der 2nd Stage Bootloader ein maßgeschneidertes und erweitertes U-Boot.
Das U-Boot wiederum validiert den Linux-Kernel (z.b. zImage) und stellt so sicher, dass alle Security-relevanten Kernel-Module vorhanden sind. Darüber hinaus validiert U-Boot das initRamFS (initRD) und die rootFS Signatur. Die letzten beiden Komponenten werden von einer Kernel Security Extension benötigt, die verwendet wurde, um sicherzustellen, dass das Root-Filesystem nicht manipuliert wurde. Diese Extension kalkuliert und vergleicht die Authentizität des rootFS (rootFS-Signatur). So ist sichergestellt, dass keine manipulierte Firmware o.ä. ausgeführt werden kann.
Alle Schnittstellen wurden mit starken Passwort-Policies geschützt, die den aktuellen NIST (National Institute of Standards and Technology) Richtlinien entsprechen. Darüber hinaus wurden die Debug-Schnittstellen in einen Modus gesetzt, der ebenfalls eine Authentifizierung voraussetzt. USB-Schnittstellen wurden auf eine begrenzte Anzahl an Geräte-Klassen beschränkt. Der System-Zugriff via USB ist ebenso durch eine Authentifizierung geschützt.
Um das Betriebssystem abzusichern, wurden verschiedene Maßnahmen umgesetzt. An erster Stelle wurden die Passwort-Richtlinien durchgesetzt, Firewalls konfiguriert und aufgesetzt. Nur die benötigten Services und Applikationen laufen (d.h. Telnet wurde deaktiviert, etc.) und die Applikationen verfügen nur über die minimal erforderlichen Berechtigungen, um Root Exploits zu verhindern.
Des Weiteren zeichnet das System Audit-Logs auf. Um diese Datensätze zu schützen und die Möglichkeit von Root Exploits zu minimieren wurde ein MAC (Mandatory Access Control System) eingesetzt und konfiguriert. Das bedeutet, dass auch der Root User bestimmen Einschränkungen unterliegt, um beispielsweise die Löschung des Audit-Log durch Root zu verhindern. Die richtige Konfiguration des MAC war einer der herausforderndsten Teile in der Implementierung.
Die Herausforderung bei der Konfiguration eines MAC ist, dass jedes System einzigartig ist und bis zu einem gewissen Grad eine angepasste Vorgehensweise erfordert. Daher ist es besonders wichtig, das richtige MAC-System für den richtigen Zweck einzusetzen, um einen guten Ausgleich zwischen Kosten, Nutzen und Komplexität zu erreichen.
Um einen sicheren Speicher implementieren zu können, muss die Hardware des SoC beispielsweise eine Verschlüsselung und Entschlüsselung von Daten durch eine per Prozessor einzigartige Verschlüsselung (eng. Processor Unique Encryption) unterstützen. Diese Funktion wurde zum Beispiel gemeinsam mit den oben genannten Systemerweiterungen genutzt, um schlussendlich die Dateipartitionen zu verschlüsseln. Um das zu erreichen, wurde das CAAM (Cryptographic Accelerator and Assurance Module) des SoC verwendet. Mithilfe dieses sicheren Speichers und weiteren Verschlüsselungsmethoden sind sensible Daten wie Schlüssel und Zertifikate geschützt. Ein sicherer Speicher ist für das Key Management auf dem Gerät unerlässlich, da er Schlüssel vor nicht autorisierten Zugriffen (Manipulation oder Weitergabe) schützt. Jedes Gerät verfügt über eine einmalige Identität, da die Schlüssel-Generierung des Gerätes in Kombination mit einer PKI (Public Key Infrastructure) verwendet wird, um signierte Zertifikate für jedes Gerät zu erhalten, die für die sichere Kommunikation verwendet werden können.
Daten, die übertragen werden, werden mittels einer Zwei-Wege-Authentifizierung geschützt. Diese stellt sicher, dass das Gerät nur mit einem gültigen Server kommuniziert und dass der Server verifizieren kann, dass er mit dem validen Gerät kommuniziert.
Um sicherzustellen, dass Firmware und Daten unbeaufsichtigt und sicher upgedatet werden können, wurde von Mission Embedded ein sicherer Update-Mechanismus integriert, der sich im Feld bewährt hat. Eine ausfallsichere Dual-Boot-Erweiterung wurde ebenfalls in den sicheren Update-Mechanismus integriert, um schwerwiegende Fehkonfigurationen durch Updates zu verhindern.
Penetrationstests beinhalten üblicherweise Port-Scans, Sniffing, Replay-Attacken, Brute-Force und Dictionary Attacken, Probing, Firmware Upgrade/Downgrade, Installation manipulierter Firmware, usw. Diese Tests dienen dazu, das korrekte Funktionieren der implementierten Mechanismen zu verifizieren und die festgelegten Ziele und Security Levels für das System garantieren zu können. Alle eingesetzten Mechanismen wurden intern anhand der vordefinierten Testfälle bestätigt. Darüber hinaus unterstützen wir unsere Kunden auch dabei, den Zulassungsprozess bei den zuständigen Behörden erfolgreich zu meistern.
Dieser Artikel gibt einen Überblick darüber, wie die Gerätesicherheit auf einer modernen SoC-Plattform für ein mobiles Medizingerät implementiert werden kann. Dies beinhaltet sicheres Booten, sicheren Speicher, sichere Kommunikation, sichere Updates und andere Mechanismen.
Das Projekt ist ein ausgezeichnetes Beispiel für die Integration unserer Yocto Security Layers in einem Kundenprojekt. Diese Layers ergänzen den Bootloader und das Kernel/OS um Security-Funktionalitäten, wie etwa die Basiskonfiguration der Firewall, Passwort-Richtlinien, einen sicheren Update-Mechanismus sowie Security-relevante Kernel-Module. Diese grundlegenden Security-Layers werden kontinuierlich erweitert sowie verbessert und bilden damit das Fundament für zukünftige Projekte und Anwendungen.
Gutheil-Schoder-Gasse 8-12
1100 Wien, Österreich
© 2024 BY MISSION EMBEDDED GMBH | MEMBER OF THE FREQUENTIS GROUP