Wieso sind OTA-Updates die sicherheitskritischste Komponente in meinem Device?
TL;DR: Over-the-Air (OTA) Updates sind eine Kernkomponente vernetzter IoT Geräte und ein Enabler für datenbasierte Businessmodelle. Die Möglichkeit Software und Daten von remote beliebig ändern zu können macht sie außerdem zur sicherheitskritischsten Komponente auf dem Gerät. Risiken und Fallstricke in der Konzeption und Umsetzung von OTA Updates werden aufgezeigt. Mit SUIT wird dann ein generische Update Architektur vorgestellt, die als Blaupause für sichere und flexible OTA Update Komponenten genutzt werden kann. Damit können Regularien wie die UN ECE R156 (Automotive) und die ETSI EN 303 645 (Consumer IoT), die sichere Updateverfahren zwingend vorschreiben, schon heute umgesetzt werden.
Mit steigender Vernetzung bei embedded und IoT Geräten rückt die Software zunehmend in den Vordergrund. Firmware und Applikationen wachsen in Komplexität und Umfang, gleichzeitig wird eine kontinuierliche Softwarepflege gefordert. Doch wie kommen Updates auf die Geräte? Physikalische Geräteupdates gelten mittlerweile als antiquiert, sind mitunter aufwendig und teuer, wenn z.B. ein Fahrzeug für einen Tag in die Werkstatt oder ein Servicetechniker zum Kunden muss, um ein Update einzuspielen. Over-the-Air Updates sind der neue Goldstandard und bieten Kunden den Komfort, den sie beispielsweise bei Smartphones schon seit über einem Jahrzehnt gewohnt sind.
Enabler für neue Businessmodelle
Doch OTA Updates können mehr als nur kosteneffiziente Softwarepflege. Der drahtlose Datenaustausch zwischen Gerät und Cloud bildet die Basis für neue Businessmodelle. Die Variantenvielfalt bei der Fahrzeugherstellung kann damit reduziert werden und gleichzeitig können Kunden Zusatzoptionen wie Sitzheizung oder Assistenzsysteme jederzeit zum Kauf oder als Leihoption via App, Webshop oder Infotainmentsystem anbieten. Einer der größten Wachstumsmärkte für Fahrzeuge, Industrial und Consumer IoT Geräte werden jedoch neue, datenbasierte Businessmodelle sein. Dabei steht die Monetarisierung von Benutzer- und Gerätedaten im Fokus, um Dienstleistungen wie z.B. Predictive Maintenance oder günstigere KFZ-Versicherungspolicen bei gemäßigter Fahrweise anbieten zu können.
OTA Updates sind autorisierte Remote Code Executions
Doch wo ist der Haken? Eigentlich werden OTA Updates nur anders (drahtlos) übertragen, z.B. via LTE, Bluetooth oder WiFi. Das heißt aber auch, dass Geräte beliebig aus der Ferne gesteuert und ihre Software modifiziert werden kann—potenziell auch von einem Angreifer. Anders ausgedrückt, OTA Updates sind autorisierte Remote Code Executions (RCE). RCEs werden in der Schwachstellenklassifizierung wie dem CVSS (Common Vulnerability Scoring System) wegen ihrer Mächtigkeit und potenziellem Business Impact typischerweise als kritisch eingestuft.
Oftmals wird daher angenommen, dass OTA Updates besser geschützt werden müssen. Die grundsätzlichen Schutzziele, d.h. Confidentiality, Integrity und Availability (CIA), sind bei jeglichen Formen von Softwareupdates jedoch genau gleich. Im Gegensatz zu physikalischen Updates können bei OTA Updates aber selbst kleinste Fehler in der Sicherheitsarchitektur oder bei der Umsetzung fatale Auswirkungen haben. Das reicht von absichtlich herbeigeführten Fehlfunktionen, über Geräteübernahme durch Dritte (Ransomware, Zwangseinbindung in ein IoT Botnet) bis hin zu Angriffen auf komplette Geräteflotten oder gar der Firmeninfrastruktur.
Bedrohungen und Angriffe gegen Softwareupdates
Die Mächtigkeit und die damit verbundenen Möglichkeiten machen OTA Updates zu einem attraktiven Ziel für Angriffe. Diese haben das Ziel eines der CIA Schutzziele zu brechen. Im Folgenden werden vier typische Bedrohungen und mögliche Gegenmaßnahmen beschrieben.
Modifizierte Firmware (Integrity)
Das wichtigste Ziel bei Updates ist sicherzustellen, dass unautorisierte Änderungen von Dritten entdeckt werden und solch modifizierte Updates nicht auf den Geräten installiert werden können. Dies kann mit digitalen Signaturen oder Zertifikaten erreicht werden (Public Key Kryptographie). Der Hersteller signiert das Update kryptographisch (Code Signing) und das IoT Gerät kann diese Signatur vor der Installation validieren. Wurde ein einzelnes Bit in dem Original-Update geändert, hinzugefügt oder gelöscht, so schlägt die Validierung fehl.
Reverse-Engineering (Confidentiality)
Ein passiver Angreifer kann die Update Datei via Reverse Engineering analysieren, um sensitive Daten oder Intellectual Property wie Algorithmen oder Machine Learning Modelle aus den Binärdaten zu extrahieren. Zum Schutz gegen solche Angriffe kann das Softwareupdate vor der Übertragung via symmetrischer Verschlüsselungsverfahren (z.B. AES oder ChaCha20) verschlüsselt werden. Endgeräte, die im Besitz des passenden kryptographischen Schlüssels sind, können die Daten wieder entschlüsseln.
Rollback Angriffe (Integrity)
Bei einem Rollback Angriff wird eine veraltete, aber offizielle Softwareversion mit bekannten Sicherheitslücken auf dem Gerät installiert. Ziel ist die Kontrolle über das Gerät zu erlangen oder sensitive Daten auszulesen oder zu manipulieren. Eine Signaturvalidierung ist in diesem Fall unzureichend, da das Update nicht manipuliert wurde, sondern lediglich eine ältere Version installiert wird. Über eine Sequenznummer, die als Metadaten mitgeschickt wird, kann ein solcher Angriff verhindert werden, da zusätzlich geprüft wird, ob das Update eine höhere Nummer als die aktuell verwendete Software besitzt.
Resource Exhaustion (Availability)
Eine Denial-of-Service Attacke ist eine weitere Bedrohung für vernetzte Geräte, insbesondere im Industrie 4.0 Kontext, wo die Verfügbarkeit der Maschinen oberste Priorität hat. Hier wird versucht die vorhandenen Resourcen des Geräts über eine massive Anzahl von Updateanfragen einzuschränken oder das Gerät damit gar zum Absturz zu bringen. Abschwächen kann man solche Angriffe beispielsweise, indem man Metadaten zur Signaturprüfung getrennt vom eigentlichen Payload (der Updatedatei) überträgt. So muss das Gerät pro Anfrage nur einen Bruchteil der Daten bearbeiten und kann ungültige Anfragen schneller verwerfen.
SUIT – Software Updates for Internet of Things
Neben Sicherheitsaspekten sollte eine gute OTA Update Architektur weitere Eigenschaften mitbringen, um das volle Potenzial und die damit verbundenen Vorteile drahtloser Updates nutzen zu können. Dazu gehören Fehlertoleranz bei der drahtlosen Übertragung und Flexibilität um die Vielzahl von Konfiguration an Hardware, Software und Übertragungsprotokolle im IoT Bereich abdecken zu können. Ein weiterer wichtiger Aspekt ist die Effizienz, um insbesondere embedded Devices mit stark eingeschränkten Resourcen (minimaler RAM und Flash Speicher) unterstützen zu können.
Eine OTA Update Architektur zu entwerfen, die all diese Aspekte berücksichtigt, ist eine große Herausforderung. Das Dokumentenformat SUIT (Software Update for Internet of Things) der Internet Engineering Task Force beschreibt eine solche Update Architektur und bildet somit eine konzeptionelle Blaupause, um sichere und robuste OTA Updates implementieren zu können. SUIT besteht aus einer Reihe von RFCs, die neben einer generischen Update Architektur und einem Informationsmodell für Metadaten, auch Security Guidance in Form eines Bedrohungsmodells und Gegenmaßnamen enthält. SUIT definiert außerdem ein Konzept für konfigurierbare Updates. Über eine Kommandosequenz in den Metadaten kann programmatisch die Update Routine kodiert werden. Ein Interpreter im Update Handler des IoT Geräts kann diese Sequenz ausführen und das Update installieren. Das bietet die Flexibilität die Installationsroutine mit jedem Update ändern zu können, anstatt diese in der Gerätesoftware hartkodieren zu müssen.
Don’t roll your own crypto!
Die beste Sicherheitsarchitektur hilft jedoch nicht, wenn sie unsicher implementiert wird. Zumeist ist das keine Absicht, sondern einfach Unwissenheit der Entwickler, die im Bereich Security kein oder kaum Vorwissen haben. Dies zeigt sich insbesondere beim Umgang mit Kryptographie, wenn eigene Algorithmen entwickelt werden, um Sicherheits- oder Performancevorteile gegenüber Standardalgorithmen zu erzielen.
Kryptographische Eigenentwicklungen in Form von neuen Algorithmen sind zu über 99,9% unsicher. Selbst für Kryptographie Experten mit jahrzehntelanger Erfahrung ist das Entwickeln neuer Standardalgorithmen eine Königsdisziplin. So dauerte es beispielsweise fünf Jahre um den Nachfolger des Hash Algorithmus SHA-2 zu finden. Dieser wurde in einem weltweit offenen Wettbewerb bestimmt, an dem über 50 Teams mit Experten aus Forschung und Wissenschaft teilnahmen. Nach mehreren Auswahlrunden wurde der Algorithmus Keccak als Sieger ausgerufen, der nach weiteren drei Jahren zum SHA-3 Standard wurde. Anhand dieses Beispiels wird klar, warum Referenzimplementierungen bestehender Algorithmen gegenüber Eigenentwicklungen immer die bessere Wahl sind.
Security by Obscurity ist ein weiterer häufiger Irrglaube in diesem Zusammenhang. Nur weil die Funktionsweise eines Algorithmus nicht öffentlich bekannt ist, heißt das nicht, dass dieser auch sicher ist. Die mitunter fatalen Designschwächen kommen dann zum Vorschein, wenn ein Experte Zeit und Interesse in die Kryptoanalyse der Gerätesoftware investiert. Denn die Sicherheit von Krypto Algorithmen liegt nicht im Geheimhalten ihrer Funktionsweise, sondern im Geheimhalten der kryptographischen Schlüssel.
Die Lösung ist einfach. Open-source Bibliotheken bieten getestete oder gar auditierte Referenzimplementierungen für fast alle Standardalgorithmen. Um Fehler bei der Integration in die eigene Software zu minimieren, sollten Software Development Kits ausgewählt werden, deren APIs sichere Grundeinstellungen bieten (Secure-by-Design) und es schwierig ist, diese unsicher zu verwenden (Hard-to-misuse). In diesem Zusammenhang ist die Dokumentation ein weiteres zentrales Auswahlkriterium. Diese sollte für Softwareentwickler geschrieben sein und nicht für Kryptographen oder Wissenschaftler. Im embedded Bereich ist aufgrund verschiedener Kriterien die Mbed-TLS Library weit verbreitet.
Aktuelle Normen und Regularien
Steigende Vernetzung und neue datenbasierte Businessmodelle führen dazu, dass IoT Geräte immer mehr sensitive Daten verarbeiten. Security und Datenschutz spielen deshalb eine immer wichtigere Rolle. Für den Gerätenutzer ist es jedoch vollkommen intransparent, ob und in welchem Ausmaß ein Hersteller in die Sicherheit seiner Produkte investiert. Aus diesem Grund wurden in den letzten Jahren regulatorische Maßnahmen ergriffen und Vorgaben für verschiedene Branchen geschaffen:
UN ECE R156 (Automotive)
Die UN-Verordnung 156 beschreibt Anforderungen an Softwareupdates und Software Update Management Systeme bei Automobilherstellern und ihren Zulieferern. Ein Schwerpunkt sind die Sicherheitsaspekte bei OTA Updates und die Bereitstellung und Verteilung auf die Steuergeräte der Fahrzeuge. R156 wird für neue Fahrzeugmodelle verpflichtend ab Juli 2022 und für alle Neufahrzeuge ab Juli 2024.
ETSI EN 303 645 (Consumer IoT)
Die europäische Norm 303 645 beschreibt grundlegende Cybersicherheitsanforderungen für Consumer IoT Geräte. Neben sicheren Updates, stehen auch Authentifizierungsverfahren, Passwortrichtlinien oder der Supportzeitraum für Sicherheitsupdates für IoT Geräte im Vordergrund. Der Standard wurde im Juni 2020 finalisiert, Produktzertifizierungen sind seit August 2021 möglich. Eine verpflichtende Umsetzung ist aktuell nicht vorgesehen, aber das BSI plant ein IT-Sicherheitskennzeichen für verschiedene Produktgruppen, z.B. Smart TV, Smarte Lautsprecher, Kameras und smartes Spielzeug. Hersteller können durch einen entsprechenden Nachweis ein Sicherheitskennzeichen für ihre Produkte erhalten. Dadurch wird im Bereich Sicherheit und Datenschutz mehr Transparenz für den Endkunden geschaffen.
comlet ist Ihr Partner für sichere OTA Updates
OTA Updates sind eine Kernkomponente vernetzter Geräte. Aufgrund ihrer Mächtigkeit sollte Security höchste Priorität bei Entwicklung und Betrieb von IoT Geräten eingeräumt werden, um Integrität und Vertraulichkeit der Software und Daten zu schützen. Regulatorische Maßnahmen werden Sicherheitsbasisanforderungen zunehmend verpflichtend machen, sodass es sich lohnt Security direkt in der Design Phase mit zu berücksichtigen. Damit bei der Umsetzung und Integration ins eigene Portfolio keine Fehler passieren, ist es ratsam, das Entwicklerteam mit fachlicher Expertise von Security Experten zu unterstützen, beispielsweise mit
- Beratung und Sicherheitschecks bei Konzeption und Umsetzung von (I)IoT Projekten
- Entwicklungsdienstleitungen im Bereich Automotive Infotainment
- UpKit, unsere sichere OTA Solution für Microcontroller