Sieben Eigenschaften hochsicherer Geräte

Autor / Redakteur: Galen Hunt, George Letey und Edmund B. Nightingale, Microsoft Azure Sphere Team / Sebastian Gerstl

In den nächsten zehn Jahren werden mehrere Milliarden Geräte mit Netzanbindung in Betrieb gehen. Die gute Nachricht ist, dass Endanwender und Unternehmen erkannt haben, wie wichtig ein umfassender Geräteschutz hier ist. Die schlechte Nachricht ist, dass vielen Stakeholdern nicht bewusst ist, dass von jedem IoT-Gerät ein Höchstmaß an Sicherheit gefordert werden muss. Microsoft hat sieben Grundeigenschaften identifiziert, die ein hochsicheres Gerät besitzen muss.

Firmen zum Thema

Die meisten vernetzten Geräte bieten in der Regeln nur zwischen einem oder drei Sicherheitslevel. Laut Microsoft gibt es allerdings sieben Eigenschaften, die ein hochgradig sicheres und vernetztes Gerät erfüllen muss.
Die meisten vernetzten Geräte bieten in der Regeln nur zwischen einem oder drei Sicherheitslevel. Laut Microsoft gibt es allerdings sieben Eigenschaften, die ein hochgradig sicheres und vernetztes Gerät erfüllen muss.
(Bild: Clipdealer)

Vielen Unternehmen, die IoT-Geräte herstellen und einsetzen, ist nicht ausreichend bewusst, wie wichtig ist es ist, dass jedes vernetzte Gerät ein Höchstmaß an Cybersicherheit bietet. Vernetzte Kinderspielzeuge, Haushaltsgeräte und Industrieanlagen müssen vor Angriffen aus dem Internet geschützt werden. Angesichts hoher Entwicklungs- und Wartungskosten sind umfassende Sicherheitsfunktionen bislang jedoch eher hochpreisigen oder margenstarken Geräten vorbehalten.

Microsoft hat sich zum Ziel gesetzt, für jedes IoT-Gerät ein Höchstmaß an Sicherheit vorzusehen, besonders für die Milliarden mikrocontrollergesteuerter Geräte. Speziell für diese Gerätekategorie birgt die Netzanbindung hohe Sicherheitsrisiken. Endanwender und Unternehmen sind aufgrund der mangelnden Investitionen in die Sicherheitserfordernisse dieser und anderer preissensitiven Geräte zunehmend Gefahren durch unzureichende Gerätesicherheit und Angriffen auf die Privatsphäre ausgesetzt.

In zehn Jahren werden alle Geräte vernetzt sein. Dank stark sinkender Konnektivitätskosten lässt sich jede Art von Elektrogerät mit dem Internet verbinden – vom Spielzeug über Haushaltsgeräte bis hin zu Industrieanlagen. Das Internet der Dinge (IoT) wird zur Triebfeder der Wirtschaft. Es wird zahllose Innovationen ermöglichen, wenn die digitale Transformation in allen Bereichen Einzug hält, von der Kinderbetreuung bis hin zur Altenpflege, vom Gastgewerbe bis hin zum Bergbau, von Bildung bis hin zum Transportwesen. Die Auswirkungen dieser universellen Gerätekonnektivität lassen sich nicht gänzlich vorhersehen, doch die Erwartungen sind hoch [1] [2].

Unserer Erfahrung nach ist vielen Unternehmen, die IoT-Devices herstellen und einsetzen, nicht ausreichend bewusst, wie wichtig ist es ist, dass jedes vernetzte Gerät ein Höchstmaß an Cybersicherheit bietet. Schon das einfachste Gerät kann bei Angriffen über das Internet eine Gefahr darstellen: ein Spielzeug wird zum Spion [3], ein Gerät kann sich selbst zerstören oder einen Denial-of-Service-Angriff [4] auslösen, Anlagen können Beschädigungen oder Zerstörung [5] verursachen. Angesichts derartiger Bedrohungen nicht nur für Leib und Leben, sondern auch für Ruf und Eigentum sind einstufige Verteidigungsmaßnahmen und halbherzige Lösungen nicht genug. Viele vernetzte Geräte werden in komplexeren IoT-Systemen eingesetzt; dabei kann die Kompromittierung von nur einem Gerät schnell zu einer Anhäufung von Risiken durch Datenverschmutzung oder Seitenkanal- bzw. Denial-of-Service-Attacken führen.

Es liegt uns fern, Panik zu verbreiten. Auch wenn es derzeit bei der Cybersicherheit von Geräten mit Netzanbindung noch viel Luft nach oben gibt, sind wir zuversichtlich, was die künftigen Entwicklungen betrifft. Wir halten es für machbar, alle Geräte, auch die kostengünstigsten, so auszulegen, dass mit angemessenen Schutzmaßnahmen selbst die massivsten Angriffe entschlossener Hacker abgewehrt werden können.

Unsere Befürchtungen und unsere Hoffnungen, was den Schutz vernetzter Geräte betrifft, fußen auf den jahrzehntelangen Erfahrungen, die Microsoft im Bereich der Internetsicherheit gesammelt hat. Als Reaktion auf Angriffe auf vernetzte PCs begann Microsoft mit Windows 95 schon vor langer Zeit, Geräte im Feld remote zu aktualisieren [6]. Angesichts immer häufigerer Attacken führte Microsoft mit Windows XP die automatische Fehlerberichterstellung bei Sicherheitsangriffen sowie die automatische Evidenzanalyse ein [7]. Um Schwachstellen bei Geräten im Feld zu begegnen, entwickelte Microsoft Technologien und Tools zur Erkennung und Behebung von Schwachstellen, die bereits im Geräteentwurf berücksichtigt werden. [8] [9].

Wir wollen es Geräteherstellern sämtlicher Branchen ermöglichen, in jedem vernetzten Gerät ein Höchstmaß an Cybersicherheit umzusetzen. Solche hochgradig geschützten Geräte sollen jedem Endanwender und jedem Unternehmen zur Verfügung stehen. Wir haben vorhandene Geräte und deren Cybersicherheit unter die Lupe genommen und dabei sieben Eigenschaften identifiziert, die für hochgradig geschützte, vernetzte Geräte unerlässlich sind: ein Hardware-Vertrauensanker (Hardware Root of Trust), tiefgehende Verteidigung (Defense in Depth), eine kleine Trusted Computing Base, dynamische Abschottung (Compartments), passwortlose Authentifizierung, Fehlerberichterstellung und erneuerbare Sicherheit.

Voraussetzung für ausreichenden Schutz ist, dass ein Gerät mit Netzanbindung alle sieben Eigenschaften besitzt oder damit ausgestattet wird. Die Hardware und Software (Firmware) des Geräts wirken hier zusammen – die Gerätesicherheit ist in der Hardware implementiert und wird von fortlaufend verbesserter Sicherheitssoftware überwacht. Wenn eine oder mehrere der sieben Eigenschaften im Gerät nicht oder unzureichend implementiert sind, erfordert dieses Defizit zusätzliche externe Maßnahme und Prozesse, die erhebliche Kosten nach sich ziehen. So muss beispielsweise ein Gerät ohne vollautomatisch erneuerbare Sicherheit manuell aktualisiert werden. Im unvermeidlichen Fall einer neu auftretenden, massiven Sicherheitsbedrohung müssen dann Techniker Updates an den Geräten vor Ort vornehmen – ein kostenintensives Unterfangen. Unserer Erfahrung nach ist dieser letzte Punkt kritisch: Gerätehersteller unterschätzen meist immer noch, dass angesichts ständig neu auftretender Sicherheitsbedrohungen häufige Updates erforderlich sind. Selbst extrem professionell entwickelte Geräte erfordern in der Regel mehrere Updates jährlich.

Wie sich herausgestellt hat, fehlt dieser umfassende Schutz besonders in mikrocontrollerbasierten Geräten. In manchen Mikrocontroller-Familien sind inzwischen hardwareseitig mehr Sicherheitsfunktionen vorgesehen, z.B. durch kryptographische Engines oder Trusted Execution Environments. Doch diese Optimierungen gehen nicht weit genug. Mit Crypto-Beschleunigung oder Private Key Storage allein lässt sich kein umfassender Geräteschutz sicherstellen, wenn der Mikrocontroller selbst keine Defense-in-Depth-Mechanismen oder dynamische Abschottung unterstützt. Die wenigsten Mikrocontroller, auch nicht neuere Modelle mit weiterentwickelten Sicherheitsfeatures, erfüllen die Voraussetzungen für eine robuste Implementierung aller sieben Eigenschaften hochgradig geschützter Geräte.

Um die Bedrohungen der Cybersicherheit vernetzter, mikrocontrollerbasierter Geräte zu adressieren, haben wir MediaTek ins Boot geholt und gemeinsam einen MediaTek-Mikrocontroller umgebaut. Aus dem MT7687 wurde Sopris, ein hochgradig geschützter Mikrocontroller als Proof of Concept (Beschreibung in Abschnitt 3.1). Auf Basis des Sopris konnten wir mikrocontrollerbasierte Versuchsgeräte mit vollständigen Implementierungen der sieben Eigenschaften entwickeln. Die wichtigsten Hardware-Neuerungen im Sopris: 1) Integration eines Hardware-Vertrauensankers, eingebettet in einem Sicherheitsprozessor im Mikrocontroller-Chip und 2) Integration einer Speicherverwaltungseinheit (MMU) im Primärprozessor des Mikrocontrollers. Durch diese Neuerungen entstand eine Mikrocontroller-Architektur, die wir – mit der geeigneten Software – als geeignete Basis für hochgradig geschützte Geräte sehen.

Die sieben Eigenschaften hochgradig geschützter Geräte

Sichere Geräte zu bauen ist eine große Herausforderung. Doch wie sich gezeigt hat, ist Sicherheit mehr eine Wissenschaft als eine Kunst. Es gilt, anerkannte Prinzipien und Vorgehensweisen einzuhalten, vom Entwurf bis hin zur Bereitstellung. Bei unseren Untersuchungen konnten wir sieben Eigenschaften identifizieren - und wir behaupten, dass diese für den umfassenden Schutz jedes vernetzten Gerätes unerlässlich sind.

Im folgenden werden die sieben Eigenschaften hochsicherer Geräte vorgestellt, sowie jeweils mindestens ein konkretes Beispiel und Fragen, die sich Entwickler zur Evaluierung der jeweiligen Eigenschaft stellen sollten.

1. Hardware Root-of-Trust: Die Geräte-Identität und -integrität werden durch die Hardware geschützt. Physische Gegenmaßnahmen schützen vor Seitenkanalangriffen.

Fragen zur Evaluierung: Hat das Gerät eine eindeutige, fälschungssichere Identität, die untrennbar mit der Hardware verbunden ist? Wird die Integrität der Gerätesoftware durch die Hardware geschützt?

2. Tiefgehende Verteidigung (Defense in Depth): Gegen Bedrohungen werden multiple Mitigationsmaßnahmen durchgeführt. Gegenmaßnahmen mindern die Auswirkungen eines erfolgreichen Angriffs auf einen beliebigen Vektor.

Fragen zur Evaluierung: Bleibt das Gerät geschützt, auch wenn ein Sicherheitsmechanismus verletzt wird?

3. Trusted Computing Base (TCB): Private Schlüssel sind in einem hardwaregeschützten Vault gespeichert, auf den die Software keinen Zugriff hat. Aufteilung der Software in selbstschützende Ebenen.

Fragen zur Evaluierung: Ist der sicherheitskritische Gerätecode vor Bugs in der weiteren Gerätesoftware sicher?

4. Dynamische Abschottung (Dynamic compartments): Hardwarebasierte Schutzgrenzen zwischen Softwarekomponenten verhindern, dass ein Sicherheitsverstoß in einer Komponente auf weitere Komponenten übergreift.

Fragen zur Evaluierung: Beschränkt sich ein Ausfall einer Gerätekomponente auf diese eine Komponente? Lassen sich neue Abschottungen schaffen, um neuen Sicherheitsbedrohungen zu begegnen?

5. Passwortlose Authentifizierung (Password-less authentication): Ein mit einem fälschungssicheren Kryptoschlüssel signiertes Token dient dem Nachweis der Geräte-Identität und -Authentizität.

Fragen zur Evaluierung: Authentifiziert sich das Gerät selbst über Zertifikate oder andere mit dem Hardware-Vertrauensanker signierte Token?

6. Fehlerberichterstellung (Error reporting) : Ein Softwarefehler, z.B. ein durch einen Angreifer ausgelöster Pufferüberlauf, wird an ein cloudbasiertes Fehleranalysesystem übermittelt.

Fragen zur Evaluierung: Liefert das Gerät Fehlerberichte, damit überprüft werden kann, ob es korrekt in der Einsatzumgebung ausgeführt wird und um neue Bedrohungen identifizieren zu können?

7. Erneuerbare Sicherheit (Renewable security): Updates bringen das Gerät in einen sicheren Zustand und widerrufen kompromittierte Ressourcen bei bekannten Sicherheitslücken oder -verletzungen.

Fragen zur Evaluierung: Wird die Gerätesoftware automatisch aktualisiert? Lässt sich die TCB-Sicherheitssoftware des Gerätes ohne Repackaging des übrigen Gerätecodes schnell aktualisieren?

Hochgradig geschützte Geräte haben einen Hardware-Root-of-Trust

Die Hardware schützt den privaten Identitätsschlüssel eines Gerätes, validiert die Gerätesoftware-Identität und beinhaltet zudem Schutzfunktionen für Seitenkanalangriffe. Im Gegensatz zur Software hat die Hardware zwei wichtige Eigenschaften, die für den Geräteschutz vonnöten sind. Zum einen kann ein Angreifer Hardware mit festgelegter Funktionalität nicht zum Ausführen unerwünschter Aktionen missbrauchen. Zum anderen kann die Hardware physische Angriffe erkennen und abschwächen. Beispielsweise lässt sich eine Impulsprüfung des Reset-Pins zur Vermeidung von Glitch-Attacken einfach in der Hardware implementieren [10]. Für den Schutz geheimer Daten und deren Integrität schafft die Hardware einen robusten Vertrauensanker, auf dem die Softwarefunktionen sicher und zuverlässig implementiert werden können.

In IoT-Anwendungen muss ein Hardware-Root-of-Trust mindestens zwei Aufgaben erfüllen: Schutz der Geräte-Identität und Schutz der Software-Integrität durch Secure-Boot. Ein gerätespezifischer geheimer Wert, der privat im Gerät gespeichert ist, dient als Vertrauensanker für die Geräte-Identität. Mithilfe eines orthogonalen öffentlichen Schlüssels des Geräteherstellers, der geschützt im Gerät gespeichert ist, kann über eine Signaturverifikation die Integrität der Software authentifiziert werden, die auf dem Gerät laufen soll. Weiterentwickelte Hardware-Vertrauensanker unterstützen das sichere Erzeugen privater Schlüssel im Gerät, die Messung der gesamten Software und Firmware einschließlich ROM, Schutz der ruhenden Daten, Hardwareschreibschutz, vertrauenswürdige Entropiequellen für die Zufallszahlengenerierung sowie irreversible Speicherung für den Rollbackschutz.

Hochgradig geschützte Geräte verwenden tiefgehende Verteidigungsmechanismen

In hochgradig geschützten Geräten werden für jede Bedrohungsklasse mehrere Risikominderungen angewendet. Bei Geräten mit nur einer Sicherheitsebene, wie z.B. den meisten RTOS-basierten Geräten, kann bereits ein einziger Fehler im Design oder in der Implementierung schwerwiegende Schäden zur Folge haben. Da neue Bedrohungen oft völlig unerwartet auftreten, sind mehrstufige Maßnahmen oft ausschlaggebend dafür, ob ein Gerät gut geschützt ist oder Schaden nimmt.

Schon einfache Defense-in-Depth-Maßnahmen schützen ein Gerät vor Sicherheitsverstößen. Umfassendere Maßnahmen mindern darüber hinaus auch die Folgen solcher Verstöße. Eine tiefgehende Verteidigung sollte sowohl hardwareseitig als auch softwareseitig vorgesehen werden. Write-Once-Latches an Konfigurationsregistern und Write-Protect-Latches am Programmcode beispielsweise sorgen dafür, dass ein Gerät nur in geringem Ausmaß umfunktioniert werden kann, auch wenn die Gerätesoftware vorübergehend kompromittiert ist. Auch das Ausführen kritischer Tasks auf isolierten Cores ist eine Defense-in-Depth-Maßnahme. Wie bei der Hardware können Defense-in-Depth-Ebenen in der Gerätesoftware verhindern, dass bei Kompromittierung eines Netzwerkstacks die Gerätefirmware im Flash-Speicher überschrieben wird.

Fast alle Defense-in-Depth-Designs fußen auf dem Assume-Breach- und Zero-Trust-Modell – die Entwickler evaluieren die Wirksamkeit jedes Schutzmechanismus, damit die Sicherheit gewährleistet wird, auch wenn ein Angreifer bereits andere Teile des Geräts kompromittiert hat. So könnte die defensive Programmierung im Boot-ROM eines geschützten Chips davon ausgehen, dass ein Angreifer die Spannung und das Taktsignal des Prozessors kompromittiert hat, um Glitch-Attacken auf das ROM durchzuführen.

Hochgradig geschützte Geräte haben eine kleine Trusted Computing Base

Eine Trusted Computing Base (TCB) ist “eine kleine Menge Software und Hardware, von der die Sicherheit abhängt und die wir von einer viel größeren Menge unterscheiden, die sich schlecht verhalten kann, ohne die Sicherheit zu beeinträchtigen“ [11]. Innerhalb eines Gerätes kann sich die TCB je nach Operation unterscheiden. Die TCB für den Schutz ruhender Daten kann beispielsweise den Hardware-Vertrauensanker, die Ver- und Entschlüsselungssoftware sowie Software für das Ver- und Entsiegeln der Kryptoschlüssel enthalten; die TCB für die sichere Kommunikation dagegen auch eine TLS-Implementierung. Die TCB sollte für alle Operationen so klein wie möglich sein, um die Angriffsfläche zu minimieren und die Wahrscheinlichkeit zu verringern, dass ein Softwarefehler oder ein Feature dazu missbraucht wird, Sicherheitsmaßnahmen zu umgehen. Der TCB-Code sollte von unkritischem Gerätecode isoliert sein, damit die sichere Ausführung gewährleistet wird, selbst wenn der Code außerhalb der TCB kompromittiert wurde. In weniger geschützten Geräten ist die TCB oft nicht isoliert – der Sicherheitscode in diesen Geräten wird im gleichen abgeschotteten Bereich ausgeführt wie der restliche Gerätecode. Hier kann schon ein einziger Fehler im Gerätecode zu schwerwiegenden Schäden im ganzen Gerät führen.

In Minimal-Implementierungen werden kritische Kryptoschlüssel-Operationen isoliert in einer kleinen TCB ausgeführt. Der private Identitätsschlüssel eines Gerätes und der Zugriff auf diesen Schlüssel sollten auf die kleinstmögliche Teilmenge der Gerätehardware und -software beschränkt sein. In hochwertigeren Implementierungen ist die TCB mehrschichtig, um den Zugriff auf persistenten Speicher oder kritische E/A-Ressourcen abzusichern, um eine Kompromittierung des Codes außerhalb der TCB zu identifizieren und zu beheben und um ein Failover auf eine sichere Backup-Software zu ermöglichen, wenn ein Gerät massiv kompromittiert wurde. Erfahrene Fachleute, die mit den neuesten Tools und Vorgehensweisen der Angreifer vertraut sind, sollten den Code innerhalb der TCB umfassend auf potentielle Schäden prüfen.

Hochgradig geschützte Geräte bieten dynamische Abschottung

In Computing-Geräten sind Schutzabschottungen hardwarebasierte Grenzen, die verhindern, dass ein Sicherheitsverstoß oder Fehler in einem Softwarebereich auf andere Softwarebereiche übergreift. Die Abschottung schafft zusätzliche Schutzgrenzen und damit weitere Verteidigungsebenen. Mithilfe der dynamischen Abschottung lassen sich über die Lebensdauer eines Gerätes weitere Grenzen zur Abwehr von Sicherheitsbedrohungen erzeugen.

Minimal-Implementierungen dynamischer Abschottung verwenden Betriebssystemprozesse oder unabhängige virtuelle Maschinen zur Abschottung. Geräte mit dynamischer Abschottung lassen sich im Feld aktualisieren und so erheblich besser vor neu auftretenden Sicherheitsbedrohungen und Angriffen schützen. Weniger geschützte Geräte, und dazu gehören die meisten kostengünstigen Geräte mit Echtzeit-Betriebssystem (RTOS), haben entweder keine oder nur fix abgeschottete Softwarebereiche, die sich nach Inbetriebnahme eines Gerätes nicht mehr umkonfigurieren lassen. Dies schränkt die Fähigkeit, neu auftretende Sicherheitsbedrohungen abzuwehren, natürlich ein.

Hochgradig geschützte Geräte verwenden die passwortlose Authentifizierung

Die passwortlose Authentifizierung, z.B. über ein Zertifikat, dient zum Identitätsnachweis bei der gegenseitigen Authentifizierung, wenn lokale Geräte miteinander oder mit Clouddiensten kommunizieren. Ein Zertifikats- oder anderes passwortloses Authentifizierungstoken weist die Identität und Autorisierung nach, die mit einem geheimen privaten Schlüssel signiert ist und sich gegen einen bekannten öffentlichen Schlüssel validieren lässt. Im Gegensatz zu Passwörtern oder anderen Authentifizierungsmechanismen, die auf geteilten Geheimnissen basieren, können passwortlose Authentifizierungsmechanismen, die durch einen Hardware-Vertrauensanker unterstützt werden, nicht gestohlen, gefälscht oder anderweitig zur Authentifizierung eines Eindringlings verwendet werden.

In einer Minimal-Implementierung attestieren Zertifikate nicht nur die Identität der Hardware, sondern auch die Identität der auf dem Gerät ausgeführten Software – z.B. wird bestätigt, dass das Gerät mit der neuesten Software läuft und somit alle bekannten Sicherheitsschwachstellen adressiert werden. Wird basierend auf der Attestierung ein Zertifikat oder Authentifizierungstoken ausgestellt, so können die vom Gerät aufgerufenen Services anfordern, dass das Gerät zunächst ein Softwareupdate durchführt, falls es mit einer älteren Softwareversion läuft, bei der eine bekannte Kompromittierung vorliegt.

Hochgradig geschützte Geräte bieten Online-Fehlerberichterstellung

Wenn bei einem hochgradig geschützten Gerät ein Fehler auftritt, wird automatisch ein Fehlerbericht erstellt und zügig an ein Fehleranalysesystem übermittelt. Im besten Fall wurde der Fehler durch unzulängliche Programmierung verursacht, im schlimmsten Fall durch einen Angreifer, der im Gerät nach neuen Angriffsvektoren sucht. In jedem Fall korreliert das Fehleranalysesystem die Fehlerberichte mit der gesamten Geräteflotte und ermöglicht so die automatische Fehlerdiagnose. Wenn ein ausreichend großer Umfang an Berichten vorliegt, lassen sich auch sehr seltene Fehlerbedingungen diagnostizieren und beheben, und neue Angriffsvektoren können identifiziert und isoliert werden, ehe sie großflächig ausgenutzt werden [7]. Die Fehlerberichterstellung schafft eine umfassende „Immunität“ innerhalb einer hochgradig geschützten Geräteflotte. Ohne automatische Online-Fehlerberichterstellung tappen Gerätehersteller bezüglich der im Feld auftretenden Gerätefehler im Dunklen und können von neuen Angriffen überrumpelt werden.

In Minimal-Implementierungen werden Daten über in der Hardware und Software erkannte Fehler erfasst und an den Gerätehersteller übermittelt. Die Fehler werden nahezu in Echtzeit analysiert; Gerätehersteller – oder deren Softwareanbieter – führen routinemäßig datengestützte Prüfungen durch, um Fehler in laufenden Geräten zu diagnostizieren und diese mittels Softwareupdates zu beheben.

Hochgradig geschützte Geräte haben erneuerbare Sicherheit

Ein Gerät mit erneuerbarer Sicherheit kann sich automatisch aktualisieren und so in einen sichereren Zustand versetzen, auch nachdem es kompromittiert wurde. Erneuerbare Sicherheit ist unerlässlich, denn es kommt zu immer schwerwiegenderen Sicherheitsbedrohungen durch Angreifer, die neue Angriffsvektoren entdecken und neue Angriffsmethoden und -tools verwenden. Um neu auftretenden Bedrohungen zu begegnen, muss die Gerätesicherheit regelmäßig erneuert werden. In Extremfällen, z.B. wenn abgeschottete Bereiche der Systemsoftware und deren Schichten von Zero-Day-Exploits kompromittiert werden, müssen tiefer liegende Schichten neu erzeugt und so die Sicherheit der darüber liegenden Schichten im Gerät wiederhergestellt werden. Remote-Attestierung und Rollback-Schutz verhindern, dass ein Gerät mit erneuerter Sicherheit wieder in einen bekannten, gefährdeten Zustand versetzt werden kann. Ein Gerät ohne erneuerbare Sicherheit stellt ein hohes potentielles Risiko dar.

In einer Minimal-Implementierung lässt sich jede Verteidigungsebene der Gerätesoftware voneinander unabhängig und automatisch aktualisieren, ohne die anderen Ebenen zu beeinträchtigen. Ein Fehler in einem Netzwerkprotokoll – wie die Schwachstelle KRACK, die 2017 in WPA2 Wifi-Protokollen identifiziert wurde [12] – kann beispielsweise behoben werden, ohne die Echtzeit-Regelschleifen eines Gerätes aktualisieren oder neu testen zu müssen. Automatische Aktualisierung bedeutet, dass für die Aktualisierung kein manueller Eingriff am Gerät erforderlich ist. Neben voneinander unabhängigen Schichten und automatisierten Prozessen verwenden sichere Implementierungen erneuerbarer Sicherheit robuste Mechanismen, die sicherstellen, dass sich ein Gerät auch von fehlgeschlagenen Updates oder externen Ereignissen, z.B. Strom- oder Netzwerkausfällen während eines Updates, erholt.

Sopris – Der Prototyp eines hochgradig geschützten Mikrocontrollers

Microsofts Hypothese ist, dass sich selbst die preissensibelsten Geräte für ein hohes Maß an Schutz auslegen lassen. Da die meisten der weltweit eingesetzten Geräte mikrocontrollergesteuert sind, lässt sich unsere Hypothese am eindeutigsten anhand eines mikrocontrollerbasierten Gerätes beweisen, welches alle sieben Eigenschaften mitbringt, die für umfassende Sicherheit unerlässlich sind.

Das Unternehmen hat dazu einen sicheren Mikrocontroller-Prototypen mit dem Codenamen Sopris sowie ein sicheres Betriebssystem entwickelt, auf Sopris basierende Geräte gebaut und dann die Sicherheit dieser Geräte gegen die sieben Eigenschaften evaluiert. Dazu haben 150 hochkarätige Sicherheitsexperten Penetrationstests durchgeführt.

Einen robusten Root-of-Trust schaffen

Es galt zu beweisen, dass nahezu jedes Gerät mit nur wenigen Änderungen umfassend geschützt werden kann und behaupten, dass sich dies wie folgt umsetzen lässt:

  • 1) Integration eines isolierten Sicherheitsprozessors im Primärprozessor des Gerätes, um einen Hardware-Vertrauensanker zu erzeugen und
  • 2) Modifizieren der weiteren Gerätehardwarearchitektur, um Defense-in-Depth- und Abschottungsmechanismen zu unterstützen.

Um einen Hardware-Vertrauensanker zu schaffen, wurde der Microsoft Pluton Sicherheitsprozessor integriert, der ursprünglich für die Microsoft-Spielkonsole Xbox One entwickelt und optimiert wurde. Die Integration von Pluton oder einem anderen entsprechend ausgestatteten Embedded-Sicherheitsprozessor im Primärprozessor des Gerätes schafft die wesentlichen Voraussetzungen für umfassenden Geräteschutz und bedeutet eine signifikante Verbesserung gegenüber Off-Chip-Sicherheitsmodulen wie z.B. TPMs [13].

TPMs werden über einen Kommunikationskanal, meist eine Busschnittstelle, mit der CPU verbunden. Ist die Busschnittstelle der primäre Kommunikationskanal, so besteht immer das Risiko einer physischen Attacke [14]. Im Pluton-Design sind Schutzfunktionen direkt im Chip integriert, damit wird das Risiko eines Angriffs auf den Kommunikationskanal vollständig eliminiert.

Der Pluton-Sicherheitsprozessor wird im Mikrocontroller oder einem anderen Primärprozessor des Gerätes eingebaut. Er enthält eine spezielle CPU, kryptographische Engines, einen Hardware-Zufallszahlengenerator (random number generator; RNG), einen Schlüsselspeicher sowie ein Kryptographievorgangsmodul (Cryptographic operation engine; COE). Die kryptographischen Engines im Pluton beinhalten eine Verschlüsselungs-Engine (AES) zur asymmetrischen und symmetrischen Verschlüsselung [15], eine Hash-Engine (SHA) [16] zur Codemessung und Zertifikatsprüfung sowie eine Public-Key-Engine zur Beschleunigung der RSA- [17] und ECC-Public-Key-Operationen [18]. Der Hardware-RNG randomisiert die Ausführung der Boot-Firmware, so dass ein Angreifer keine zeitlich abgestimmte Attacke planen kann, dient der Schlüsselgenerierung und erfüllt weitere Anforderungen des Kryptoverfahrens. Die COE führt Operationen aus, die mehr als eine kryptographische Engine erfordern.

Einen sicheren Mikrocontroller bauen

Bild 1: Architektur des Wifi-basierten MT7687 Mikrocontrollers
Bild 1: Architektur des Wifi-basierten MT7687 Mikrocontrollers
(Bild: Microsoft)

Die Ausgangsbasis für Sopris war ein hochentwickelter Mikrocontroller, der Wifi-basierte MT7687 [19] von MediaTek. Der ursprüngliche MT7687 hat eine 192MHz ARM Cortex-M4 CPU, 352KByte RAM, 28 GPIO-Pins, einen 12-Bit AD-Wandler, ein vollständiges Wifi-Subsystem mit Wifi 4 (802.11n) Funk (Basisband und MAC) sowie einen Controller für den SiP-Flash-Speicher (siehe Bild 1).

Bild 2: Architektur des Wifi-basierten, hochgradig geschützten Sopris-Mikrocontrollers.
Bild 2: Architektur des Wifi-basierten, hochgradig geschützten Sopris-Mikrocontrollers.
(Bild: Microsoft)

Durch vier Änderungen wurde aus MT7687 ein Sopris (siehe Bild 2): Der Pluton-Sicherheitsprozessor ist als Hardware-Vertrauensanker integriert; durch ein Upgrade der Primär-CPU im ARM 8 Cortex-M4 auf ARM Cortex-A7 wurde eine Memory Management Unit (MMU) bereitgestellt, und das integrierte SRAM von 352KByte yte auf 6MByte sowie den Second-Die-Flash von 2MByte auf 16MByte erhöht, um unterschiedliche Versuche durchführen zu können.

Aus Sicherheitsperspektive waren die wichtigsten Änderungen die Integration des Pluton-Sicherheitsprozessors und die Implementierung einer Adressübersetzung in der CPU mittels MMU. Der Pluton-Sicherheitsprozessor bildet im Sopris den Hardware-Vertrauensanker und steuert darüber hinaus die gesamte Bootsequenz. Im Gegensatz zu der viel einfacheren Memory Protection Unit (MPU) des Cortex-M4 bzw. ähnlichen MPUs der meisten Mikrocontroller unterstützt die MMU im Sopris Cortex-A7 mehrere Isolationsebenen und mehrere unabhängige Adressräume, mit denen im Betriebssystem isolierte Bereiche geschaffen werden können.

Bild 3: Sopris Developer-Board. Sopris ist der rot eingekreiste, quadratische schwarze Chip.
Bild 3: Sopris Developer-Board. Sopris ist der rot eingekreiste, quadratische schwarze Chip.
(Bild: Microsoft)

Die MMU dient der feingranularen Zugriffssteuerung und Adressübersetzung, nicht jedoch dem Paging, anders als dies in embedded MPUs und größeren SoCs der Fall ist. Entgegen unserer Erwartungen wirkte sich das Upgrade auf Cortex-A7 nur geringfügig auf die Chipfläche und -kosten aus – dank der Optimierungen durch die Synthese des Cores auf eine geringe Taktrate. Der erweiterte SRAM ermöglicht ein einfaches Experimentieren mit zahlreichen Betriebssystemkonfigurationen ohne Sicherheitseinbußen des integrierten Speichers. Bild 3 zeigt den Prototypen eines USB-getriebenen Entwicklungsboards basierend auf Sopris.

Ein geschütztes Betriebssystem bauen

Bild 4: Architektur unseres Betriebssystem-Prototyps. Die Schichten 0-2 werden im Pluton-Sicherheitsprozessor ausgeführt, die Schichten 3-6 im Primärprozessor.
Bild 4: Architektur unseres Betriebssystem-Prototyps. Die Schichten 0-2 werden im Pluton-Sicherheitsprozessor ausgeführt, die Schichten 3-6 im Primärprozessor.
(Bild: Microsoft)

Um die sieben Eigenschaften eines hochsicheren Gerätes zu implementieren, muss sowohl bei der Hardware als auch bei der Software angesetzt werden. Bild 4 zeigt die mehrschichtige Architektur des Betriebssystem-Prototyps unseres Sopris-Devices. Die Schichten 0-2 werden im Pluton-Sicherheitsprozessor ausgeführt. Schicht 0, die Pluton COE, ist in Hardware-Zustandsautomaten implementiert; die Schichten 1 und 2 (Pluton Boot-ROM und Pluton-Runtime) werden auf der CPU des Sicherheitsprozessors jeweils aus dem ROM bzw. Flash-Speicher heraus ausgeführt. Die Schichten 3-6 werden auf dem Cortex-A7 Prozessor aus dem Flash heraus ausgeführt; Schicht 3, die Sicherheitsüberwachung, läuft in der geschützten TrustZone-Umgebung und Schicht 4, der Betriebssystem-Kernel, im Supervisor-Mode. Die Schichten 5 und 6 – die On-Chip-Clouddienste und Application Sandboxes - werden in isolierten Adressräumen im User Mode ausgeführt.

Der Betriebssystem-Prototyp wendet Defense-in-Depth-Mechanismen zwischen den Betriebssystem-Schichten und innerhalb dieser Schichten an. Die niedriger liegenden Schichten basieren auf dem Zero-Trust-Modell: Jede Schicht nimmt an, dass die höherliegenden Schichten von einem Angreifer umfassend verletzt wurden. Somit sind Aufrufe und Daten aus höherliegenden Schichten erst dann vertrauenswürdig, wenn sie vollständig validiert wurden. Der Schreibzugriff auf den Flash-Speicher wird beispielsweise durch die Sicherheitsüberwachung und die Pluton-Laufzeiten strikt geregelt. So kann auch kein kompromittierter Betriebssystem-Kernel im Flash gespeicherte Anwendungen oder Kernel-Images überschreiben.

Innerhalb jeder Betriebssystem-Schicht sorgen Hardwareschutzmechanismen für zusätzlichen Schutz über das Niveau hinaus, das sich mit bewährten Programmiertechniken erzielen lässt. So greifen das Pluton-ROM und auch die Pluton-Runtime auf die MPU-Mechanismen der CPU im Sicherheitsprozessor zurück und mindern so das Angriffspotential bei Schwachstellen in der Datenverarbeitung. Ebenso nutzen die Schichten des auf dem Cortex-A7 ausgeführten Betriebssystems dessen MMU-Mechanismen, um das Angriffspotential bei Schwachstellen in der Datenverarbeitung weiter zu mindern und um ROP-Angriffe mithilfe von MMU-basierten Verteidigungsmechanismen zu reduzieren, z.B. Sparse Address Spaces, Guard Pages und Randomisierung des Adressraumlayouts (ASLR).

Evaluierung auf Basis der Eigenschaften

Die folgende Tabelle zeigt die Geräteeigenschaften des hochgradig geschützten des Sopris im Vergleich zu den Eigenschaften herkömmlicher Mikrocontroller, wie z.B. des MT7687, aus dem der Sopris weiterentwickelt wurde. Sopris unterstützt alle Eigenschaften, die vonnöten sind, um ein hochgradig geschütztes Gerät wie beschrieben zu entwickeln.

Eigenschaft Unterstützt in herkömmlichen MCUs Unterstützt in Sopris
Hardware Root-of-Trust nein ja
Tiefgehende Verteidigung (Defense in Depth) nein ja
Trusted Computing Base (TCB) nein ja
Dynamische Abschottung (Dynamic compartments) nein ja
Passwortlose Authentifizierung (Password-less authentication) nein ja
Fehlerberichterstellung (Error reporting) nein ja
Erneuerbare Sicherheit (Renewable security) nein ja

Der Proof-of-Concept Sopris bietet einen On-chip Hardware-Root-of-Trust – geheime Daten und die Software-Integrität werden vom Pluton-Sicherheitsprozessor geschützt. Sopris hat eine kleine Trusted Computing Base (TCB) – bei vielen Operationen ist die Sopris-TCB im Prozessor innerhalb des Pluton-Sicherheitsprozessors isoliert. Sopris unterstützt tiefgehende Verteidigungsmechanismen – bis zu sieben Verteidigungsebenen sind zwischen der um eine MMU erweiterten CPU und dem Pluton-Sicherheitssystem implementiert. Sopris unterstützt die dynamische Abschottung – mittels der MMU isolierte Adressräume werden in separate Bereiche umgesetzt, und durch Softwareupdates lassen sich neue Abschottungen schaffen. Sopris unterstützt die hardwaregeschützte, passwortlose Authentifizierung – im Pluton-Sicherheitsprozessor gespeicherte private Schlüssel sind die Grundlage für eine sichere, gerätespezifische Zertifikatskette, die auch im Falle eines kompromittierten Betriebssystemkerns vor Identitätsdiebstahl geschützt ist. Der Chip verfügt zudem über eine Online-Fehlerberichterstattung. Dies umfasst Exception Handling, die Erhebung von Fehlerdaten und Wifi-gestützte Übermittlung dieser Daten an ein Fehleranalysesystem. Schließlich unterstützt Sopris die erneuerbare Sicherheit – dank mehrerer Sicherheitsebenen lassen sich fortlaufend verbesserte Sicherheitsmechanismen umsetzen, um neu auftretenden Sicherheitsbedrohungen zu begegnen, ohne die höherliegenden Schichten des Softwarestacks neu validieren oder neu zertifizieren zu müssen.

Im Gegensatz zum Sopris erfüllen herkömmliche Mikrocontroller nicht die Voraussetzungen für hochgradigen Geräteschutz. Selbst wenn ein Mikrocontroller z.B. Hardware-Crypto-Engines verwendet, sind softwaregesteuerte Schlüssel im Primärprozessor des Mikrocontrollers nicht sicher, wenn in dieser Software ein Fehler auftritt. Mit der Sopris-Architektur lassen sich die sieben Verteidigungsebenen in der Betriebssystem-Architektur aufbauen; die meisten herkömmlichen Mikrocontroller unterstützen dagegen in der Regel höchstens zwei oder drei Ebenen. In der Praxis verwenden fast alle RTOS-basierten Geräte nur eine Verteidigungsebene. In solchen Geräten kann nahezu jede Software-Schwachstelle dazu führen, dass ein Angreifer die Verteidigungsebene überwindet, den Flash-Speicher umprogrammiert und so vollständig und langfristig die Kontrolle über das Gerät übernimmt.

Der größte Nachteil von MPUs in herkömmlichen Mikrocontrollern ist, dass sie keine Adressübersetzung bieten. Das heißt, die Code- und Datenadressen sowohl im SRAM und Flash lassen sich nicht neu mappen. Infolgedessen kann eine MPU keine bewährten Defense-in-Depth-Mechanismen implementieren, z.B. Sparse Address Spaces, Guard Pages und Randomisierung des Adressraumlayouts (ASLR). Der hier vorgestellte Betriebssystem-Prototyp hat die unabhängige Service-Bereitstellung für jede Betriebssystem-Schicht und Applikation problemlos unterstützt. In der Praxis ist die unabhängige Service-Bereitstellung jedoch in keinem MPU-basierten Mikrocontroller-RTOS implementiert. Dies liegt daran, dass das RTOS und die Geräte-Firmwarekomponenten außerhalb der TCB fast immer in einem Binärbild miteinander verbunden sind und sich die unabhängige Service-Bereitstellung ohne Adressübersetzung nicht effizient umsetzen lässt.

Evaluierung mithilfe von Penetrationstests

Die sieben Eigenschaften beziehen sich auf die Fähigkeit, ein Höchstmaß an Gerätesicherheit zu erzielen. Jedoch ist anhand von zusätzlichen Tests nachzuweisen, dass diese Eigenschaften so implementiert sind, dass Angriffe wirksam abgewehrt werden können. Beispiel: Ein Gerät hat eine kleine Trusted Computing Base (TCB), doch innerhalb der Implementierung dieser TCB gibt es vielleicht Schwachstellen. Konkret lässt sich die Sicherheit eines Gerätes am wirkungsvollsten mittels Penetrationstests durch ein sogenanntes „Red Team“ von Angreifern evaluieren: Eine Gruppe erfahrener Hacker attackiert das Gerät mithilfe der neuesten Tools und Methoden, die ein potentieller Angreifer nutzen würde.

Um die Wirksamkeit der Sicherheitsmaßnahmen in unserem Sopris-Prototypen zu evaluieren, führte Microsoft eine Red Team Security Challenge mit 150 Sicherheitsexperten durch. Jeder Hacker erhielt ein Entwicklungsboard und Dokumentation. Die Hacker hatten jeweils 60 Tage lang Zeit, ihr Sopris-Gerät erfolgreich zu attackieren. Identifizierte Schwachstellen wurden zur Verifikation an HackerOne übermittelt. Deren Sicherheitsanalysten untersuchten und klassifizierten alle identifizierten Schwachstellen auf Basis des CWE-Standards [20] und führten ein Severity-Ranking basierend auf dem CVSS v3.0 Standard [21] durch.

Sopris konnte alle Attacken abwehren, die von den 150 Sicherheitsexperten im Rahmen der 60-tägigen Challenge durchgeführt wurden. Nur zwei Bugs – beide auf Datenlevel – ergaben sich, doch keiner davon hatte eine Datenweitergabe, Remote-Codeausführung oder Privilegienerweiterung zur Folge. Rückblickend war ein Manko der Sopris Security Challenge, dass die Hacker keinen Software-Quellcode zur Verfügung hatten. Auch wenn fehlender Quellcode einen Hacker erfahrungsgemäß nicht lange ausbremst, würde unserer Meinung nach die Bereitstellung von Quellcode die Gründlichkeit der Penetrationstests erhöhen.

Die Ergebnisse aus der Evaluierung durch das Red Team belegen, dass die sieben Eigenschaften bei korrekter Implementierung ausreichen, um stabile Sicherheit zu gewährleisten. Die Evaluierung zeigte zudem, dass sich die sieben Eigenschaften auch in einem mikrocontrollerbasierten Gerät wie dem Sopris effizient implementieren lassen. Ein knappes Budget sollte kein Grund für unzureichende Sicherheit sein.

Vom Sopris zu Azure Sphere

Die Experimente mit Sopris haben bei Microsoft zu Azure Sphere geführt – eine End-to-End-Lösung, mit der jeder Gerätehersteller hochgradig geschützte Geräte bauen kann. Azure Sphere besteht aus drei Komponenten: Mikrocontroller, Betriebssystem und Clouddienst. Die Azure Sphere Chips bauen auf dem Pluton-Sicherheitsprozessordesign des Sopris auf und haben zusätzliche Hardware-Sicherheitsfeatures, wie Sticky Bits, um eine Kompromittierung aufgrund einer unerwarteten Privilegienerweiterung innerhalb der Software zu vermeiden, sowie In-Fabric-Kommunikationsfirewalls, um zusätzliche Verteidigungsebenen innerhalb der Hardware zu schaffen. Dank der In-Fabric-Kommunikationsfirewalls unterstützten die Azure Sphere Chips die sicherheitskritische Echtzeitverarbeitung und hochsichere Netzwerk-Konnektivität. Das Azure Sphere Betriebssystem basiert auf dem Architekturdesign des Sopris-Prototyps und gewährleistet die zuverlässige, vollautomatische und komplett unabhängige Aktualisierung jeder Betriebssystemschicht. Der Azure Sphere Security Service (AS3) stellt sicher, dass der Chip und das Betriebssystem die Voraussetzungen für die Anbindung hochsicherer Geräte in der Cloud erfüllen – passwortlose Authentifizierung, Online-Fehlerberichterstattung und cloudgetriebene erneuerbare Sicherheit.

Azure Sphere erfüllt nicht nur die Anforderungen für die Implementierung der sieben Eigenschaften, sondern ermöglicht es zudem auch jedem Gerätehersteller – egal mit welcher Expertise in Sachen Sicherheit – hochgradig geschützte Geräte zu bauen. Zum einen bietet Azure Sphere die industrieweit besten Implementierungen aller sieben Eigenschaften [22]. Zum anderen wird Azure Sphere nicht als Baukasten bereitgestellt, der aufwändig implementiert werden muss, wie dies bei vielen RTOS der Fall ist, sondern als einsatzbereite Microsoft-Lösung „as a Service“. Ein Gerätehersteller, der Azure Sphere verwendet, muss im Falle eines schwerwiegenden Problems mit der Internetsicherheit, z.B. bei Identifizierung einer Schwachstelle in einem häufig eingesetzten Netzwerk-Prototypen [12], nicht erst ein RTOS-Patch abwarten, die Firmware mit dem neuen RTOS-Patch rekompilieren, diese neu testen und validieren, an die Kunden verteilen oder Techniker aussenden, um sicherzustellen, dass die weltweit eingesetzten Geräte mit der neuen Firmware aktualisiert werden – noch dazu schnellstmöglich, wenn es sich um eine Zero-Day-Attacke handelt. Mit Azure Sphere kan der Gerätehersteller entspannt dabei zuzusehen, wie das Azure Sphere Team ein Update für sämtliche Geräte erstellt und durchführt. Eine Neuzertifizierung des Herstellercodes ist nicht erforderlich, auch nicht für den sicherheitskritischen Echtzeitcode. Dank der tiefgehenden Verteidigungsmechanismen von Azure Sphere und der integrierten erneuerbaren Sicherheit können die TCB, der Netzwerksicherheitscode und alle anderen Betriebssystem-Komponenten voneinander unabhängig aktualisiert und damit die Gerätesicherheit verbessert werden.

(Übersetzung S.Pagler)

Literatur und Quellenangaben

[1] C. MacGillivray and A. Wright, "Worldwide Internet of Things Connectivity Forecast, 2017–2021," IDC, 2017.

[2] D. W. Cearley, B. Burke and M. J. Walker, "Top 10 Strategic Technology Trends for 2016," Gartner, 2016.

[3] C. Wiking, "If Your Child Has This Doll You Should Get Rid of It Now," 17 Feb. 2017. [Online]. Available:https://mom.me/news/39826-if-your-child-has-doll-you-might-want-destroy-it/. [Accessed 17 Feb. 2017].

[4] N. Perlroth, "Hackers Used New Weapons to Disrupt Major Websites Across U.S.," New York Times, 21 Oct. 2016.

[5] E. Mills, "Internet-Connected Coffee Maker Has Security Holes," CNET, 17 Jun. 2008.

[6] C. Gkantsidis, T. Karagiannis, P. Rodriguez and M. Vojnovic, "Planet Scale Software Updates," in ACM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, Pisa, Italy, 2006.

[7] K. Kinshuman, K. Glerum, S. Greenberg, G. Aul, V. Orgovan, G. Nichols,D. Grant, G. Loihle and G. Hunt, "Debugging in the (Very) Large: Ten Years of Implementation and Experience," Communications of the ACM, vol. 54, no. 7, pp. 111-116, 2011.

[8] E. Bounimova, P. Godefroid and D. Molnar, "Billions and Billions of Constraints: Whitebox Fuzz Testing in Production," in International Conference on Software Engineering, San Francisco, CA, 2013.

[9] P. Godefroid, P. de Halleux, M. Y. Levin, A. V. Nori, S. K. Rajamani, W. Schulte and N. Tillmann, "Automating Software Testing Using Program Analysis," IEEE Software, vol. 25, no. 5, pp. 30-37, 2008.

[10] J. Boone and I. Zhuravlev, "There’s A Hole In Your SoC: Glitching The MediaTek [MT8163V] BootROM," 15 October 2020. [Online]. Available: https://research.nccgroup.com/2020/10/15/theres-a-hole-in-your-soc-glitching-the-mediatek-bootrom/. [Accessed 15 October 2020].

[11] B. Lampson, M. Abadi and M. Burrows, "Authentication in Distributed Systems: Theory and Practice," ACM Transactions on Computer Systems, 1992.

[12] M. Vanhoef and F. Piessens, "Key Reinstallation Attacks: Forcing NonceReuse in WPA2," in Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS), Dallas, TX, 2017.

[13] International Organization for Standardization (ISO), "ISO/IEC 11889-1:2009 -Information Technology -Trusted Platform Module".

[14] D. Andzakovic, "Extracting BitLocker Keys from a TPM," 13 March 2019. [Online]. Available: https://pulsesecurity.co.nz/articles/TPM-sniffing. [Accessed 15 October 2020].

[15] National Institute of Standards and Technology, "197, Advanced Encryption Standard (AES)," Federal Information Processing Standards (FIPS), 2001.

[16] National Institute of Standards and Technology, "180-4, Secure Hash Standard," Federal Information Processing Standard (FIPS), 2012. [17] R. Rivest, A. Shamir and L. Adleman, "A Method for Obtaining Strong Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, vol. 21, no. 2, pp. 120-126, 1977. [18] V. S. Miller, "Use of elliptic curves in cryptography," in Conference on the Theory and Application of Cryptographic Techniques, Springer, Berlin, Heidelberg, Germany, 1985. [19] MediaTek, Inc., "MT7687F Datasheet," Hsinchu, Taiwan, 2016.[20] MITRE, Common Weakness Enumeration, cwe.mitre.org.

[21] FIRST, Common Vulnerability Standard, Version 3.0, https://www.first.org/cvss/.

[22] E. B. Nightingale and P. Orwick, "Nineteen cybersecurity best practies used to implement the seven properties of highly secured devices in Azure Sphere," July 2020. [Online]. Available: https://azure.microsoft.com/en-us/resources/best-practices-for-implementing-seven-properties-in-azure-sphere/. [Accessed 15 October 2020].

[23] Databeans, Inc., "Q1 2017 Microcontroller Market Tracker," Reno, NV, 2017.

(ID:47039685)