Grundlagen der IoT-Sicherheit - Teil 4: Minderung von Laufzeit-Bedrohungen

Hinweis des Herausgebers: Trotz der Verbreitung von IoT-Geräten ist die Sicherung dieser Geräte weiterhin ein ständiges Anliegen, da Sicherheitsprobleme ein Hindernis für den Einsatz angeschlossener Geräte im industriellen IoT (IIoT) und in unternehmenskritischen Anwendungen darstellen können, bei denen Unternehmens- und persönliche Daten im Falle eines erfolgreichen Angriffs kompromittiert werden können. Die Sicherung von IoT-Anwendungen kann entmutigend sein, aber in Wirklichkeit kann die Sicherheit von IoT-Geräten auf einigen wenigen, relativ einfachen Prinzipien aufbauen, die von Hardware-Sicherheitsgeräten unterstützt werden. Durch die Befolgung gut etablierter Sicherheitspraktiken können diese Bedenken ausgeräumt werden. Diese mehrteilige Serie bietet praktische Anleitungen, die den Entwicklern helfen sollen, sicherzustellen, dass die besten Praktiken von Anfang an befolgt werden. Teil 1 erörtert die kryptographischen Algorithmen, die sicheren Designs zugrunde liegen. Teil 2 erörtert die Rolle von privaten Schlüsseln, Schlüsselverwaltung und sicherer Speicherung in sicheren IoT-Designs. Teil 3 untersucht die Mechanismen, die in sichere Prozessoren eingebaut sind, um andere Arten von Bedrohungen für IoT-Geräte abzuschwächen. In Teil 4 wird aufgezeigt, wie Sicherheitsmechanismen in fortschrittlichen Prozessoren angewendet werden können, um die Isolierung zu gewährleisten, die zur Abschwächung von Angriffen auf die Laufzeitumgebung von IoT-Geräten erforderlich ist. Teil 5 beschreibt, wie die IoT-Sicherheit von IoT-Geräten durch Sicherheitsmaßnahmen auf höherer Ebene weitergeführt wird, um diese Geräte mit IoT-Cloud-Ressourcen zu verbinden.

Hardware-basierte Kryptographie mit sicherer Speicherung bietet die erforderliche Grundlage für die Implementierung sicherer IoT-Designs. Secure Boot und Secure Firmware Over-the-Air (FOTA) Update nutzen diese Grundlage, um eine Vertrauensbasis für die Ausführung von Software zu schaffen. Nichtsdestotrotz muss ein Gerät für das Internet der Dinge (Internet of Things, IoT) weiterhin vor Software geschützt werden, die versehentlich oder absichtlich sichere Ressourcen gefährden kann, auf die von einer Software-Anwendung und Systemcode zugegriffen wird, die in der Laufzeitumgebung ausgeführt werden.

Dieser Artikel beschreibt, wie Entwickler in einigen Prozessoren von NXP Semiconductors, STMicroelectronics und anderen integrierte Sicherheitsmechanismen verwenden können, um Systeme effektiver vor Bedrohungen zu schützen, die während der Softwareausführung auftreten.

Wie Runtime-Software untergraben werden kann

Wie bereits in früheren Teilen dieser Serie erörtert, bieten Chiffren, sichere Schlüsselspeicherung und sichere Boot- und Firmware-Aktualisierung notwendige Bausteine für die IoT-Sicherheit. Obwohl diese Fähigkeiten entscheidend zur allgemeinen Sicherheit von IoT-Geräten beitragen, können sie eine unvollständige Lösung für Angriffe darstellen, die darauf abzielen, Runtime-Software in verbundenen Systemen zu untergraben. Im Idealfall würden Versuche, in die von diesen Mechanismen bereitgestellten Verteidigungslinien einzudringen, dank der vertrauenswürdigen Umgebung scheitern, die auf der Wurzel des Vertrauens beruht, das durch einen sicheren Bootvorgang geschaffen wird. In der Praxis können Systeme, die mit diesen robusten Sicherheitsfunktionen gebaut wurden, durch Angriffe, bei denen ein Stück korrupter Code oder Malware in das System eingeschleust wird, kompromittiert werden - und wurden es auch schon.

Mit einer Vielzahl von Methoden können Hacker Sicherheitslücken in einem Teil eines Systems ausnutzen, um andere Teile anzugreifen. Pufferüberlauf-Attacken z.B. nutzen Software-Anwendungen aus, die es großen Eingangsdatenströmen erlauben, über den vorgesehenen Pufferbereich hinaus zu schreiben. Wenn dieser Datenüberlauf Code enthält, könnte der Prozessor diesen später ausführen und damit Hackern einen Einstiegspunkt für weitere Angriffe bieten. Mit diesen und anderen Methoden dringen Hacker nach und nach in weitere Teile eines Systems ein.

Schwachstellen können in jeder Softwarekomponente in jeder Schicht des Softwarestapels eines Systems vorhanden sein. In dem Maße, wie die Entwickler daran arbeiten, funktional reichhaltigere Systeme zu schaffen, erhöht der Bedarf an mehr Software-Komponenten die Wahrscheinlichkeit, dass ihre Systeme mehr Schwachstellen aufweisen. Gleichzeitig nimmt die Vielfalt der in Software gefundenen Schwachstellen weiter zu. Zum Beispiel zeigte die maßgebliche Common Vulnerabilities and Exposures (CVE®)-Liste öffentlich bekannter Cyber-Sicherheitslücken (Common Vulnerabilities and Exposures) im 1. Quartal 2020 einen Anstieg von 15% im Jahresvergleich.

Schutzebenen schützen kritische Software

Die Eindämmung von Bedrohungen ist ein ständiger Kampf zwischen Black Hat-Hackern und White Hat-Sicherheitsspezialisten. Auch wenn weiterhin Bedrohungen auftreten werden, können Entwickler die Sicherheit in ihren Entwürfen deutlich erhöhen, indem sie Methoden nutzen, die darauf ausgelegt sind, die vielen verschiedenen Softwareprozesse zu isolieren, die in einer typischen Anwendung erforderlich sind. Seit Jahren werden sichere Systeme auf einem mehrstufigen Schutzansatz aufgebaut. Bei diesem klassischen Ansatz sorgen konzentrische Schutzringe für zunehmende Isolation in einem System. Anwendungen, die auf der äußersten Schicht laufen, dürfen nicht auf Gerätetreiber und Systemdienste in den inneren Schichten zugreifen, die ihrerseits nicht auf den Software-Kernel in der innersten Schicht zugreifen dürfen (Abbildung 1).

Abbildung 1: Sichere Softwaresysteme schützen Anwendungen, Treiber und Betriebssystemkerne in Schutzringen, die einen zunehmend größeren Schutz bieten. (Bildquelle: Wikipedia)

Intel x86-Bausteine, die mit 80286 beginnen, jetzt verfügbar ab Rochester Electronics, unterstützten vier Stufen, die mit einem Selektorregister bezeichnet wurden, das ein RPL-Feld (Request Privilege Level) mit zwei Bits enthielt. Moderne Prozessorarchitekturen wie z.B. Arm's® TrustZone haben die Sicherheitsfunktionen durch eine Vielzahl von Mechanismen zur Isolierung von Benutzerprozessen während der Laufzeit erheblich erweitert. Entwickler können diese Art von abgestufter Schutzfunktion in einer Reihe von Prozessoren für eingebettete Systeme finden, darunter auch:

• Mikrochip-Technologie's SAM L11 Mikrocontroller-Familie basierend auf dem Arm Cortex®-M23
• Nordic Semiconductor's nRF9160 drahtlose On-Chip-Systeme (SoCs) basierend auf dem Arm Cortex-M33
• Nuvoton Technology's M2351 Mikrocontroller basierend auf dem Arm Cortex-M23
• NXP Semiconductors' LPC55 Mikrocontroller auf der Basis des Arm Cortex-M33
• Silicon Labs' EFR32BG21 Familie drahtloser SoCs, die auf dem Arm Cortex-M33 basieren
• STMicroelectronics' STM32L5 Mikrocontroller-Familie basierend auf dem Arm Cortex-M33

Arm TrustZone für Cortex-M bringt verbesserte Sicherheitsfunktionen für Prozessoren eingebetteter Systeme von Arm Cortex-M, wie z.B. den NXP LPC55S69JBD100K und STMicroelectronics' STM32L552VET6. TrustZone für Cortex-A bietet ähnliche Fähigkeiten für Anwendungsprozessoren auf der Basis von Arm Cortex-A, wie den NXP i.MX 8M Mini MIMX8MM6DVTLZAA und STMicroelectronics' STM32MP157AAC3T.

Für jede Arm-Serie bietet TrustZone Mechanismen an, die neben anderen Sicherheitsmerkmalen einen sicheren Bootvorgang und sicheren Code, Daten und Speicher unterstützen. TrustZone für Cortex-M-Prozessoren wurde entwickelt, um die Anforderungen eingebetteter Systeme an niedrige Latenzzeiten zu unterstützen, und zeichnet sich durch Leistungsverbesserungen wie schnelle sichere Unterbrechungen und schnelle hardwarebasierte Übergänge zwischen Sicherheitszuständen aus. Dieser Artikel beschreibt TrustZone für Cortex-M-Prozessoren mit Schwerpunkt auf einem Paar von Prozessoren, die für diese Klasse repräsentativ sind: NXP LPC55S69JBD100K und STMicroelectronics STM32L552VET6.

Prozessor-Betriebsarten ermöglichen erweiterten Schutz

Im Herzen der TrustZone-Architektur können Prozessoren in mehreren Betriebsmodi laufen, die die Isolierung von Softwareprozessen und Systemressourcen unterstützen. Die Prozessor-Modi "sicher" und "nicht sicher" bieten eine Möglichkeit, vertrauenswürdige Prozesse von nicht vertrauenswürdigen Prozessen zu isolieren. Prozessor-"Handler"- und "Thread"-Modi bieten einen separaten Schutzmechanismus, der eine weitere Granularität bei der Isolierung von Prozessen und Ressourcen bietet.

In der TrustZone-Architektur bewirkt ein im Handler-Modus laufender Prozessor, dass Software immer im privilegierten Modus ausgeführt wird. Daher wird dieser Modus für die Ausführung von Software wie einem Echtzeitbetriebssystem (RTOS) oder für den Zugriff auf das Boot-Image, sichere Schlüssel und andere für den Systembetrieb wichtige Ressourcen empfohlen. Im Thread-Modus läuft Software im unprivilegierten Modus, aber privilegierte Prozesse können die Privilegstufe der in diesem Modus laufenden Software ändern. Der Thread-Modus wird normalerweise zum Ausführen von Anwendungscode verwendet.

In Kombination verwendet, bieten die Modi sicher/nicht sicher und Handler/Thread dieselbe Art von abgestuftem Schutz wie frühere Systeme mit Schutzringen. Mit dem STMicroelectronics STM32L552VET6 beispielsweise können Entwickler vertrauenswürdigen Code mit vollen Privilegien von nicht vertrauenswürdigem Code mit minimalen Privilegien isolieren (Abbildung 2).

<Abbildung 2: TrustZone-Prozessoren wie der STMicroelectronics STM32L552VET6 bieten eine Kombination von Prozessormodi, die es Entwicklern ermöglichen, vertrauenswürdige Systemsoftware, wie z.B. Boot-Images, von nicht vertrauenswürdigem Anwendungscode, wie z.B. Radiofrequenz (RF)-Kommunikationsstacks von Drittanbietern, zu isolieren. (Bildquelle: DigiKey, aus dem Quellenmaterial von STMicroelectronics)

In diese Prozessoren integrierte Isolationsmechanismen schränken die Fähigkeit jedes Prozessors ein, auf verschiedene Bereiche des Programmdatenspeichers zuzugreifen. Wenn sich der NXP LPC55S6x-Kern beispielsweise im sicheren Zustand befindet, kann er nicht auf nicht sicheren Programmspeicher zugreifen, obwohl er immer noch auf nicht sicheren Datenspeicher zugreifen kann. Wenn der LPC55S6x-Kern hingegen im nicht-sicheren Zustand läuft, kann er nur auf nicht-sicheren Programmspeicher und Datenspeicher zugreifen (Abbildung 3).

Abbildung 3: Prozessoren wie die LPC55S6x-Bausteine von NXP können sicherstellen, dass der Kern im sicheren Zustand (S-Zustand) läuft, um sicheren Programmspeicher zu lesen (grün), oder im nicht sicheren Zustand (NS-Zustand), um nicht sicheren Programmspeicher zu lesen (rot). (Bildquelle: NXP Semiconductors)

Wenn sie im sicheren Zustand ausgeführt werden, um vertrauenswürdige Software auszuführen, können diese Prozessoren keine Befehle aus dem nicht sicheren Programmspeicher abrufen. Umgekehrt können diese Prozessoren, wenn sie im nicht sicheren Zustand ausgeführt werden, um nicht vertrauenswürdige Software wie z.B. Anwendungscode auszuführen, nicht auf Code oder Daten zugreifen, die sich in sicheren Bereichen befinden. Dennoch erfordert Anwendungscode in der Regel die Fähigkeit, vertrauenswürdigen Code in sicheren Bibliotheken auszuführen. TrustZone-Prozessoren ermöglichen es Entwicklern, diese Anforderung zu erfüllen, indem sie nicht-sichere aufrufbare (NSC) Speicherbereiche definieren, die erlaubte Einstiegspunkte zu sicheren Bibliotheken bieten (Abbildung 4).

<Abbildung 4: Nicht sichere aufrufbare Bereiche bieten sichere Einstiegspunkte von nicht sicheren zu sicheren Speicherbereichen, so dass nicht sichere Anwendungen Funktionen in sicheren Bibliotheken ausführen können. (Bildquelle: STMicroelectronics)

Speicher-Aliase erhöhen die Sicherheit

TrustZone-Prozessoren wie der NXP LPC55S69JBD100K und STMicroelectronics STM32L552VET6 verwalten die Ausführung durch Aliasing des physischen Programmspeichers in sichere und nicht sichere Speicherbereiche. Beispielsweise codieren die Aliase STMicroelectronics STM32L552VET6 im Flash und SRAM zweimal in einen nicht sicheren Adressbereich (0x0800_0000 bis 0x0BFF_FFFFFF) und wieder in einen sicheren Adressbereich (0x0C00_0000 bis 0x0FFF_FFFFFF). In ähnlicher Weise aliasiert der NXP LPC55S69JBD100K physischen Programmspeicher in einen nicht sicheren Bereich ab 0x0000_0000 und ebenfalls in einen sicheren Bereich ab 0x1000_0000. Jeder dieser Prozessoren verwendet einen ähnlichen Ansatz für andere Speichertypen und Peripheriegeräte, indem er sie zweimal in sichere und unsichere Bereiche aliasiert.

Wenn der Prozessor auf eine Speicherstelle zugreifen muss, wird die Zugriffsmöglichkeit auf diese Stelle durch ein Sicherheitsattribut bestimmt, das von zwei Hardware-Einheiten generiert wird:

• Implementation Defined Attribution Unit (IDAU), bei der es sich um eine feste Hardware-Einheit außerhalb des Prozessorkerns handelt, die einen festen Sicherheitsstatus der Speicherabbildung gemäß der Definition des Herstellers bietet.
• Secure Attribution Unit (SAU), eine in den Prozessorkern integrierte programmierbare Einheit, die zur Definition des Sicherheitsstatus von bis zu acht Speicherbereichen dient.

Während der Systeminitialisierung definieren Konfigurationsroutinen, die im Sicherheitsmodus ausgeführt werden, den Sicherheitsstatus jeder Region, indem sie einige SAU-Register einschließlich einiger SAU-Register festlegen:

• SAU-Regionsnummernregister (SAU_RNR) zur Auswahl einer Region für weitere Operationen
• SAU-Region-Basisadressregister (SAU_RBAR) zur Definition der Startadresse der Region
• SAU-Region Limit Address Register (SAU_RLAR) zur Definition der Ausdehnung der Region

STMicroelectronics stellt in seinem Softwarepaket STM32Cube MCU für die STM32L5-Serie mehrere Vorlagendateien zur Verfügung, die die Verwendung von Prozessorfunktionen einschließlich der SAU-Konfiguration demonstrieren. Wie in Listing 1 dargestellt, können Entwickler diese Bereiche für jeden Konfigurationsparameter mit Hilfe eines Makros (SAU_INIT_REGION(n)) definieren, das die Registerwerte in einer SAU-Struktur festlegt, die beim Schreiben von Konfigurationseinstellungen in das Gerät verwendet wird.

Kopieren
/*
//   <e>Initialize SAU Region 0
//   <i> Setup SAU Region 0 memory attributes
*/
#define SAU_INIT_REGION0    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START0     0x0C03E000      /* start address of SAU region 0 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END0       0x0C03FFFF      /* end address of SAU region 0 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC0       1
/*
//   </e>
*/
 
/*
//   <e>Initialize SAU Region 1
//   <i> Setup SAU Region 1 memory attributes
*/
#define SAU_INIT_REGION1    1
 
/*
//     <o>Start Address <0-0xFFFFFFE0>
*/
#define SAU_INIT_START1     0x08040000      /* start address of SAU region 1 */
 
/*
//     <o>End Address <0x1F-0xFFFFFFFF>
*/
#define SAU_INIT_END1       0x0807FFFF      /* end address of SAU region 1 */
 
/*
//     <o>Region is
//         <0=>Non-Secure
//         <1=>Secure, Non-Secure Callable
*/
#define SAU_INIT_NSC1       0
/*
//   </e>
*/
   .
   .
   .
**
  \brief   Setup a SAU Region
  \details Writes the region information contained in SAU_Region to the
           registers SAU_RNR, SAU_RBAR, and SAU_RLAR
 */
__STATIC_INLINE void TZ_SAU_Setup (void)
{
 
#if defined (__SAUREGION_PRESENT) && (__SAUREGION_PRESENT == 1U)
 
  #if defined (SAU_INIT_REGION0) && (SAU_INIT_REGION0 == 1U)
    SAU_INIT_REGION(0);
  #endif
   .
   .
   .
#define SAU_INIT_REGION(n) \
    SAU->RNR  =  (n                                     & SAU_RNR_REGION_Msk); \
    SAU->RBAR =  (SAU_INIT_START##n                     & SAU_RBAR_BADDR_Msk); \
    SAU->RLAR =  (SAU_INIT_END##n                       & SAU_RLAR_LADDR_Msk) | \
                ((SAU_INIT_NSC##n << SAU_RLAR_NSC_Pos)  & SAU_RLAR_NSC_Msk)   | 1U
 

Listing 1: Dieses Schnipsel zeigt, wie Entwickler Speicherregionen und den zugehörigen Sicherheitsstatus definieren. Es ist in den Vorlagen des STM32Cube MCU-Softwarepakets von STMicroelectronics für die STM32L5-Serie enthalten. (Codequelle: STMicroelectronics)

IDAU und SAU arbeiten zusammen, um festzustellen, ob auf den Speicherplatz zugegriffen werden kann, wodurch die höchste Sicherheitsstufe der beiden erreicht wird. Da ein Prozessor mit dem Speicher-Alias arbeitet, der seinem sicheren/nicht sicheren Betriebszustand entspricht, gewährleistet das durch die Kombination von IDAU und SAU erzeugte Sicherheitsattribut die Zugänglichkeit nur für Regionen mit der entsprechenden Sicherheitsstufe (Abbildung 5).

Abbildung 5: Im NXP LPC55S69JBD100K erzeugen IDAU und SAU zusammen ein Sicherheitsattribut für jeden Speicher-Alias, wodurch Code, der nicht aus der jeweiligen Region ausgeführt werden darf, effektiv entfernt wird. (Bildquelle: NXP Semiconductors)

Wenn beispielsweise der NXP LPC55S69JBD100K im Sicherheitsmodus betrieben wird, verhindert das von IDAU und SAU generierte Sicherheitsattribut den Zugriff auf nicht sichere Anwendungen, die im sicheren Alias eines Blocks des physischen Speichers enthalten sind, wodurch dieser nicht sichere Code effektiv aus dem sicheren Alias eliminiert wird. Umgekehrt, wenn der Prozessor im nicht sicheren Modus betrieben wird, eliminiert das IDAU- und SAU-Sicherheitsattribut sichere Anwendungen effektiv aus dem resultierenden nicht sicheren Alias.

Einstellung von Privilegien und Zugriffskontrolle

Während IDAU und SAU sichere und nicht-sichere Zugriffsbeschränkungen direkt durchsetzen, arbeiten sie mit sicheren und nicht-sicheren Speicherschutzeinheiten (MPUs), um die mit der Zielressource verbundenen Zugriffsrechte zu bestimmen (Abbildung 6).

<Abbildung 6: Bei TrustZone-Prozessoren wie dem hier abgebildeten NXP LPC55S69JBD100K wird das von der SAU und IDAU generierte Sicherheitsattribut mit Einstellungen kombiniert, die von sicheren und nicht sicheren MPUs verwaltet werden, um neben der Sicherheitsstufe auch die Privilegstufe zu gewährleisten. (Bildquelle: NXP Semiconductors)

Eingebaut in diese Prozessoren bietet die MPU eine feinkörnige Zugriffskontrolle der Speicherressourcen. Im STMicroelectronics STM32L552VET6 beispielsweise unterstützt die MPU eine Vielzahl von Zugriffsrechten, die sich unterscheiden, wenn der Prozessor im privilegierten Handler-Modus oder im unprivilegierten Thread-Modus läuft (Tabelle 1).

Tabelle 1: Das STMicroelectronics STM32L552VET6 ermöglicht es Entwicklern, mit seiner MPU verschiedene Zugriffsebenen zu definieren, die im privilegierten und unprivilegierten Modus unterschiedlich funktionieren. (Tabellenquelle: STMicroelectronics)

Unter diesen Attributen ermöglicht es das Attribut "Niemals ausführen" (XN) Entwicklern sicherzustellen, dass der Prozessor niemals versucht, Code aus dem zugehörigen Speicherbereich auszuführen, was eine weitere Ebene des Laufzeitschutzes bietet. Beispielsweise können Entwickler in Systemen, auf denen Code direkt aus Flash ausgeführt wird, das XN-Attribut für unbenutzte SRAM-Bereiche setzen, um jede Möglichkeit auszuschließen, dass das System kompromittiert wird, selbst wenn Malware-Injektionsangriffe in diesen Bereichen erfolgreich sind.

Ausdehnung des Schutzes auf mehr Peripheriegeräte und Speicher

Die IDAU-, SAU- und MPU-Funktionen dieser Prozessoren bieten eine flexible Grundlage für den Schutz der Laufzeitausführung sowohl von Systemsoftware als auch von Anwendungen, aber diese Fähigkeiten sind auf den Prozessor selbst beschränkt. Prozessoren wie der NXP LPC55S69JBD100K und der STMicroelectronics STM32L552VET6 übertragen die sicheren und privilegierten Fähigkeiten durch eine Vielzahl von Ansätzen auf andere Speichersysteme und Schnittstellen.

Für seinen STM32L552VET6 ergänzt STMicroelectronics den nativen TrustZone-Mechanismus durch einen eigenen globalen TrustZone-Controller (GTZC), der zum Schutz von Peripheriegeräten, eingebettetem SRAM und externen Speichern entwickelt wurde (Abbildung 7).

Abbildung 7: Der STMicroelectronics-Prozessor STM32L552VET6 integriert einen globalen TrustZone-Controller (GTZC), der den Sicherheitsschutz auf Peripheriegeräte und Speicher ausweitet, die nicht im nativen TrustZone-Rahmenwerk enthalten sind. (Bildquelle: STMicroelectronics)

Im NXP LPC55S69JBD100K werden das Privilege-Attribut (HPRIV) und das Secure-Attribut (HNONSEC) über die interne Advanced High-Performance Bus (AHB)-Matrix übertragen, um Memory Protection Checkers (MPCs), Peripheral Protection Checkers (PPCs) und Master Security Wrapper (MSWs) für andere Busmaster zu erreichen (Abbildung 8).

Abbildung 8: Im NXP LPC55S69JBD100K werden die Privilegien- und Sicherheitsstufen an zusätzliche Hardwareeinheiten übertragen, die diese Attribute auf Operationen anwenden, die Speicher, Peripheriegeräte und andere Busmaster betreffen. (Bildquelle: NXP Semiconductors)

Obwohl es wichtig ist, die zugrundeliegenden Mechanismen der Software-Isolation und des Systemschutzes zu verstehen, können Entwickler die Entwicklungsunterstützung nutzen, um diese Fähigkeiten schnell in ihren eigenen Entwürfen anzuwenden.

STMicroelectronics bietet mit seinen STM32L552E-EV, STM32L562E-DK und NUCLEO-L552ZE-Q Evaluierungsboards eine Rapid-Prototyping-Plattform zur Erstellung von Anwendungen auf der Basis seiner STM32L5-Prozessoren an. Die integrierte Entwicklungsumgebung (IDE) des Unternehmens STM32CubeIDE bietet eine umfassende Umgebung für die Software-Programmierung, und der STM32CubeProgrammer bietet sowohl Versionen mit grafischer Benutzeroberfläche (GUI) als auch mit Befehlszeilenschnittstelle (CLI) für die Programmierung interner und externer Speicher. Mit diesem Tool können Entwickler beispielsweise sichere Regionen im Flash-Speicher definieren (Abbildung 9).

<Abbildung 9: Der STMicroelectronics STM32CubeProgrammer bietet einen einfachen Ansatz zur Definition sicherer Bereiche im Flash-Speicher. (Bildquelle: STMicroelectronics)

Für die schnelle Entwicklung von Systemen, die auf den LPC55S69-Prozessoren von NXP basieren, können Entwickler Designs auf dem Evaluation-Board NXP LPC55S69-EVK aufbauen. Für die Systemkonfiguration und Softwareprogrammierung bietet die NXP MCUXpresso IDE eine umfassende Plattform zur Erstellung von Anwendungen, die auf NXP LPC55S69-Prozessoren basieren.

Fazit

IoT-Sicherheit hängt von grundlegenden Sicherheitsmechanismen für Kryptographie und sichere Speicherung ab, sowie von der Fähigkeit, Anwendungen auf einer Vertrauensbasis aufzubauen, die auf Hardware-Sicherheitsmechanismen basiert. Obwohl sie alle für die Sicherheit notwendig sind, reichen sie selten aus, um anhaltenden Bedrohungen zu begegnen, die darauf abzielen, Schwachstellen in System-Laufzeitumgebungen auszunutzen. Mithilfe von abgestuften Schutzmechanismen, die in einer wachsenden Anzahl von Prozessoren verfügbar sind, können Entwickler sichere IoT-Geräte entwickeln, die diese Bedrohungen besser eindämmen und ihre Auswirkungen auf IoT-Anwendungen reduzieren oder beseitigen können.