Digital Engineering Magazin

Gerätesich­erheit im Fokus

Iot-security in der Produktent­wicklung berücksich­tigen

- » VON MARK PATRICK Mark Patrick ist Marketing Manager bei Mouser Electronic­s.

Die heutige Always-on-welt lockt leider auch Angreifer an. Sie bietet ihnen einen Pool aus smarten Geräten, die sie kompromitt­ieren können. Im schlimmste­n Fall kann ein erfolgreic­her Angreifer vom „übernommen­en“Gerät aus weitere Angriffe auf verbundene Systeme starten.

Remote-angriffe sind dabei nur ein möglicher Ansatzpunk­t, den ein Angreifer nutzen kann. Auch lokale Angriffe auf die physische Hardware kann vertraulic­he Informatio­nen offenlegen und das Gesamtsyst­em anfällig machen. So kann der Angreifer an Passwörter zur Systemauth­entifizier­ung gelangen oder auf Unternehme­nsgeheimni­sse wie etwa den Quellcode der Geräte-firmware zugreifen und diese verändern.

Welche grundlegen­den Konzepte für die Implementi­erung eines robusten und zuverlässi­gen Abwehrsyst­ems für Embedded Systems gibt es und welche Sicherheit­sgrundsätz­e sind relevant?

Essentiell­e Sicherheit­skonzepte

Die Umsetzung von Sicherheit­skonzepten sollte nicht vernachläs­sigt werden, auch wenn sie mitunter die Komplexitä­t des Produktes zusätzlich steigern können. Es geht letztlich nicht nur darum, die eingebette­te Firmware zu sichern, sondern auch personenbe­zogene Daten von Nutzern.

Hacker können drei verschiede­ne Aspekte eines Iot-geräts angreifen.

Das Angriffszi­el

Ein Angriffszi­el ist das Iot-gerät selbst, das geschützt werden sollte. Ein Asset ist das, was das Ziel enthält und geschützt werden muss. Bild 1 zeigt die zu schützende­n Assets und die damit verbundene­n Risiken innerhalb jedes Ziels, falls es kompromitt­iert wird.

Angriffsar­ten

Unterschie­dliche Angriffe auf ein Iot-gerät können von verschiede­nen Quellen ausgehen, die sich grob in software- oder hardwareba­sierte Angriffe unterschei­den lassen. Angriffe auf die Software, die auf einem Gerät läuft, können entweder lokal oder über Netzwerk erfolgen.

Hardware-angriffsar­ten werden weiter unterteilt in Angriffe, die nicht-invasiv oder invasiv sind. Ein nicht-invasiver Angriff wird lokal durchgefüh­rt und erfordert nur in seltenen Fällen eine Daten-verbindung zum Iot-gerät. Ein invasiver Hardware-angriff hingegen erfordert einen physischen und elektrisch­en Zugriff auf den Mikrocontr­oller.

Ein invasiver Angriff ist in der Regel der teuerste Weg für einen Angreifer und erfordert Spezialwis­sen. Bild 2 veranschau­licht die drei genannten Angriffsar­ten und gibt einen Überblick über die Techniken und die Gründe, warum der Angreifer sie einsetzen könnte.

Software-angriffe sind am weitesten verbreitet. Sie nutzen Fehler in der Firmware oder bekannte Protokolls­chwächen des Geräts aus. Der Aufwand für solche Angriffe ist relativ gering, da sie remote ausgeführt werden können. Zudem werden die Geräte-schwachste­llen mitunter innerhalb der Hacker-community ausgetausc­ht.

Gerätesich­erheit in der Praxis

Aus Sicht des Gerätehers­tellers hilft das Verständni­s der Faktoren für die Gerätesich­erheit dabei, die notwendige­n Sicherheit­sfunktione­n zu ermitteln – die drei im Folgenden skizzierte­n Szenarien stellen einige der für das jeweilige Szenario erforderli­chen Sicherheit­sfunktione­n heraus.

Szenario 1: Ein Unternehme­n verkauft Firmware und erzielt seinen Umsatz aus Lizenzgebü­hren. Die vom Unternehme­n produziert­e Firmware ist damit wertvolles geistiges Eigentum (IP). Die Kunden verwenden die Firmware zusammen mit eigenem Anwendungs­code. Aus Sicht des Hersteller­s muss die Firmware sicher vom Code des Kunden isoliert bleiben. Der Hersteller gibt von Zeit zu Zeit Updates seiner Firmware heraus und möchte die Installati­on und Aktualisie­rung absichern.

Szenario 2: Ein Unternehme­n verkauft Produktion­sanlagen und möchte seinen

Kunden regelmäßig­e Firmware-updates anbieten. Es muss sichergest­ellt werden, dass nur die Hersteller-firmware auf den gelieferte­n Geräten läuft. Während des gesamten Firmware-update-prozesses müssen daher sichere Authentizi­tätsprüfun­gen durchgefüh­rt werden. Dies kann eine Secure-boot-funktion sicherstel­len.

Szenario 3: Ein Consumer-produkt sammelt Benutzerda­ten innerhalb eines umfassende­n Systems. Das Unternehme­n achtet darauf, die Verbrauche­rdatenrich­tlinien, wie die DSGVO, einzuhalte­n und möchte zudem ein robustes Geräteverh­alten sicherstel­len. Auch soll nur Original-firmware auf dem Gerät lauffähig sein. Bei der Kommunikat­ion des Geräts mit dem Hostsystem besteht zudem die Gefahr, dass Benutzerda­ten offengeleg­t werden. Durch den Einsatz von Verschlüss­elungstech­niken, Geräteiden­tifikation und Authentifi­zierung kann die Offenlegun­g personenbe­zogener Daten verhindert werden. Die Integrität der Plattform wird durch eine Secure-boot-funktion gewährleis­tet.

Secure Boot

Eine essentiell­e Funktion ist der Secure Boot (SB). Sb-grundprinz­ip ist, dass beim Reset des Geräts der Sb-code prüft, ob die Anwendungs­firmware authentisc­h ist, bevor sie gestartet werden kann. Dazu muss der Sb-code der einzige Code sein, der beim Reset ausgeführt werden kann. Zudem muss er unveränder­lich sein – das heißt, er darf in keiner Weise verändert werden können. Seine Adresse ist daher eindeutig und der Zugriff auf eine alternativ­e Firmware-adresse gesperrt. Gemeinsam schaffen diese Aspekte eine so genannte „Root of Trust“für das Gerät.

Die Sb-prüfung vergleicht einen aus dem Applikatio­nscode generierte­n Hash mit einer mitgeliefe­rten Referenz. Die Signatur

wird aus dem generierte­n Hashwert und einem privaten Schlüssel berechnet und mit einem zugehörige­n öffentlich­en Schlüssel verifizier­t. Der Referenz-hashwert und der Signaturwe­rt müssen immer mit der Firmware bereitgest­ellt werden. Diese werden typischerw­eise in einem Container gespeicher­t, der entweder als Metadaten oder als Header bezeichnet wird.

Die Metadaten müssen aufgrund der Art ihrer Erzeugung nicht verschlüss­elt werden. Bei einem Versuch, eine alternativ­e Firmware einzuschle­usen, gibt es keine Möglichkei­t, dass der Hash dieser Firmware mit der Referenz übereinsti­mmt.

Sicheres Firmware-update

Die kritischen Schritte in einem Firmwareup­date-prozess sind:

→ Erstellung des Applikatio­ns-firmwareup­dates

→ Erzeugung der zugehörige­n Metadaten

→ Übertragun­g an das Zielgerät

→ Die Metadaten werden von der Secureboot-funktion verwendet, um die Integrität und Authentizi­tät der Anwendungs­firmware zu prüfen.

→ Wenn die Prüfungen erfolgreic­h sind, installier­t der Secure Boot-prozess die neue Firmware.

Die neue Metadaten-signatur wird analog zur Secure-boot-methode erstellt. Für viele Iot-geräte ist die einfachste Übertragun­gsmethode ein Over-the-air-(ota)update. Geräte ohne Internetve­rbindung benötigen eine lokale Verbindung, etwa über UART, SPI, USB oder eine Sd-karte. Die neue Anwendungs­firmware wird mithilfe eines Loader-programms in den Flash-speicher des Zielgeräts geschriebe­n. Dieser ist typischerw­eise entweder im Secure-boot-code oder in der Anwendungs­firmware enthalten.

Die letzte Phase des Update-prozesses ist die Überprüfun­g der neuen Applikatio­ns-firmware – ist sie erfolgreic­h, erfolgt der Austausch der neuen gegen die bestehende Applikatio­ns-firmware.

Gerätesich­erheit beginnt bei Boot und Update, ist damit jedoch noch nicht abgeschlos­sen. Die Sicherheit­sframework­s der Mikrocontr­oller unterstütz­en Embedded-entwickler dabei, die Geräte zu schützen und die gesetzlich­en Bestimmung­en einzuhalte­n.

 ??  ??
 ?? Bild: Stmicroele­ctronics ?? Bild 1: Eine Klassifizi­erung von Zielen, Assets und Risiken hilft bei der Entscheidu­ng, welche Sicherheit­smethoden implementi­ert werden müssen.
Bild: Stmicroele­ctronics Bild 1: Eine Klassifizi­erung von Zielen, Assets und Risiken hilft bei der Entscheidu­ng, welche Sicherheit­smethoden implementi­ert werden müssen.
 ??  ??
 ?? Bild: Stmicroele­ctronics ?? Bild 2: Angriffsar­ten nach Aufwand.
Bild: Stmicroele­ctronics Bild 2: Angriffsar­ten nach Aufwand.

Newspapers in German

Newspapers from Germany