Hardware-Sicherheit

Sieben Eigenschaften hochsicherer Geräte

Seite: 2/2

Firmen zum Thema

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:47043292)