IoT-beveiligingsbeginselen - deel 4: beperking van runtime bedreigingen

Noot van de redactie: Ondanks de proliferatie van IoT-apparaten blijft de beveiliging van deze apparaten een voortdurende zorg, in die mate zelfs dat beveiligingsproblemen een belemmering kunnen vormen voor de adoptie van aangesloten apparaten in industriële IoT (IIoT) en missiekritische toepassingen waar bedrijfs- en persoonlijke gegevens in gevaar kunnen worden gebracht in het geval van een succesvolle aanval. Het beveiligen van ivd-toepassingen kan ontmoedigend zijn, maar in werkelijkheid kan de beveiliging van ivd-apparaten worden gebaseerd op een paar relatief eenvoudige beginselen die worden ondersteund door hardwarebeveiligingsapparaten. Door gevestigde beveiligingspraktijken te volgen, kunnen deze problemen worden aangepakt. Deze meerdelige serie biedt praktische begeleiding om ontwikkelaars te helpen ervoor te zorgen dat vanaf het begin de beste praktijken worden gevolgd. Deel 1 bespreekt de cryptografische algoritmen die aan veilige ontwerpen ten grondslag liggen. Deel 2 bespreekt de rol van private sleutels, sleutelbeheer, en veilige opslag in veilige IoT-ontwerpen. In deel 3 wordt ingegaan op de mechanismen die zijn ingebouwd in veilige processoren om andere soorten bedreigingen voor ivd-apparaten te beperken. In deel 4 wordt aangegeven hoe beveiligingsmechanismen in geavanceerde processoren kunnen worden toegepast om de isolatie te waarborgen die nodig is om aanvallen op de runtime-omgeving van ivd-apparaten te beperken. In deel 5 wordt beschreven hoe de beveiliging van het ivd zich uitstrekt van ivd-apparaten tot beveiligingsmaatregelen op hoger niveau die worden gebruikt om die apparaten te verbinden met ivd-cloudbronnen

Hardware-gebaseerde cryptografie met veilige opslag biedt de basis die nodig is om veilige IoT-ontwerpen te implementeren. Secure boot en secure firmware over-the-air (FOTA) update maken gebruik van deze basis om een vertrouwensbasis op te bouwen voor de uitvoering van software. Een apparaat van het internet der dingen (ivd) moet echter voortdurend worden beschermd tegen software die per ongeluk of opzettelijk veilige bronnen waartoe een softwaretoepassing toegang heeft, kan compromitteren, alsmede tegen systeemcode die in de runtime-omgeving wordt uitgevoerd.

In dit artikel wordt beschreven hoe ontwikkelaars gebruik kunnen maken van beveiligingsmechanismen die in sommige processoren van NXP Semiconductors, STMicroelectronics en anderen zijn geïntegreerd om systemen doeltreffender te beschermen tegen bedreigingen die zich voordoen tijdens de uitvoering van software.

Hoe runtime software ondermijnd kan worden

Zoals besproken in eerdere delen van deze reeks, vormen ciphers, veilige sleutelopslag, en veilig opstarten en firmware-updates de noodzakelijke bouwstenen voor IoT-beveiliging. Hoewel deze mogelijkheden een cruciale bijdrage leveren aan de algemene beveiliging van ivd-apparatuur, kunnen zij een onvolledige oplossing bieden voor aanvallen die zijn ontworpen om runtime-software in aangesloten systemen te ondermijnen. In het ideale geval zouden pogingen om door de verdedigingslinies van deze mechanismen heen te dringen mislukken dankzij de vertrouwde omgeving die is gebouwd op de vertrouwensbasis die door veilig opstarten tot stand is gebracht. In de praktijk kunnen systemen die met deze robuuste beveiligingsvoorzieningen zijn gebouwd, worden - en zijn - aangetast door aanvallen waarbij een stuk corrupte code of malware in het systeem wordt geïnjecteerd.

Via allerlei methoden kunnen hackers kwetsbaarheden in de beveiliging van een deel van een systeem uitbuiten om andere delen aan te vallen. Bufferoverloopaanvallen, bijvoorbeeld, maken gebruik van softwareapplicaties die het mogelijk maken dat grote gegevensstromen voorbij het bedoelde buffergebied worden geschreven. Als die overloopgegevens code bevatten, kan de processor die later uitvoeren, waardoor hackers een ingang hebben voor verdere aanvallen. Met behulp van deze en andere methoden dringen hackers geleidelijk steeds verder door in bredere delen van een systeem.

Kwetsbaarheden kunnen voorkomen in elke softwarecomponent in elke laag van de softwarestack van een systeem. Naarmate ontwikkelaars werken aan systemen met meer functies, neemt door de behoefte aan meer softwarecomponenten de kans toe dat hun systemen meer kwetsbaarheden vertonen. Tegelijkertijd blijft de verscheidenheid aan kwetsbaarheden die in software worden aangetroffen, toenemen. De gezaghebbende Common Vulnerabilities and Exposures (CVE®)-lijst van algemeen bekende kwetsbaarheden in de cyberbeveiliging vertoonde in het eerste kwartaal van 2020 bijvoorbeeld een toename van 15% ten opzichte van dezelfde periode een jaar eerder.

Beschermingsniveaus beschermen kritieke software

Het beperken van bedreigingen is een voortdurende strijd tussen "black hat"-hackers en "white hat"-beveiligingsspecialisten. Hoewel er bedreigingen zullen blijven verschijnen, kunnen ontwikkelaars de beveiliging van hun ontwerpen aanzienlijk verbeteren door gebruik te maken van methoden die zijn ontworpen om de vele verschillende softwareprocessen die in een typische toepassing nodig zijn, te isoleren. Jarenlang zijn veilige systemen gebaseerd geweest op een trapsgewijze benadering van bescherming. In deze klassieke benadering zorgen concentrische ringen van bescherming voor een toenemend niveau van isolatie in een systeem. Toepassingen die op de buitenste laag draaien, hebben geen toegang tot de stuurprogramma's en systeemdiensten in de binnenste lagen, die op hun beurt geen toegang hebben tot de softwarekernel in de binnenste laag (figuur 1).

Figuur 1: Veilige softwaresystemen beschermen toepassingen, stuurprogramma's en kernels van besturingssystemen in ringen van bescherming die een steeds grotere bescherming bieden. (Bron afbeelding: Wikipedia)

Intel x86-apparaten, te beginnen met de 80286, die nu verkrijgbaar is bij Rochester Electronics, ondersteunden vier niveaus, die werden aangegeven met een selectorregister dat een twee-bits veld voor het gevraagde privilegeniveau (RPL) bevatte. Moderne processorarchitecturen zoals Arm's ® TrustZone hebben de beveiligingsmogelijkheden aanzienlijk uitgebreid door middel van een verscheidenheid aan mechanismen die zijn ontworpen om gebruikersprocessen tijdens runtime te isoleren. Ontwikkelaars kunnen dit soort gelaagde beschermingsmogelijkheden vinden in een aantal processoren voor ingebedde systemen, waaronder:

• Microchip Technology's SAM L11 microcontroller familie gebaseerd op de Arm Cortex®-M23
• Nordic Semiconductor' s nRF9160 draadloze systemen-op-chip (SoC's) op basis van de Arm Cortex-M33
• De M2351 microcontroller van deTechnologie van Nuvoton, gebaseerd op de Arm Cortex-M23
• NXP Semiconductors' LPC55 microcontrollers gebaseerd op de Arm Cortex-M33
• Silicon Labs' EFR32BG21 familie van draadloze SoC's gebaseerd op de Arm Cortex-M33
• STMicroelectronics' STM32L5 microcontroller-familie gebaseerd op de Arm Cortex-M33

Arm TrustZone voor Cortex-M biedt verbeterde beveiligingsmogelijkheden voor Arm Cortex-M embedded systeemprocessoren, zoals de NXP LPC55S69JBD100K en STMicroelectronics' STM32L552VET6. TrustZone for Cortex-A biedt soortgelijke mogelijkheden voor op Arm Cortex-A gebaseerde applicatieprocessoren, zoals de NXP i.MX 8M Mini MIMX8MM6DVTLZAA en STMicroelectronics' STM32MP157AAC3T.

Voor elke Arm-serie biedt TrustZone mechanismen die beveiligd opstarten en beveiligde code, gegevens en geheugen ondersteunen, naast andere beveiligingskenmerken. Ontworpen om lage-latency vereisten van embedded systemen te ondersteunen, TrustZone voor Cortex-M processoren bevat prestatieverbeteringen waaronder snelle beveiligde interrupts en snelle hardware-gebaseerde overgangen tussen beveiligingstoestanden. Dit artikel beschrijft TrustZone voor Cortex-M processoren met de nadruk op een paar processoren die representatief zijn voor deze klasse: NXP LPC55S69JBD100K en STMicroelectronics STM32L552VET6.

Processor bedrijfsmodi maken uitgebreide bescherming mogelijk

In het hart van de TrustZone-architectuur kunnen processoren in meerdere bedrijfsmodi werken die de isolatie van softwareprocessen en systeembronnen ondersteunen. Processor "veilige" en "niet-veilige" modi bieden een manier om vertrouwde processen te isoleren van niet-vertrouwde processen. Processor "handler"- en "thread"-modi bieden een afzonderlijk beschermingsmechanisme dat verdere granulariteit biedt bij het isoleren van processen en bronnen.

In de TrustZone architectuur zorgt een processor die in handler modus draait ervoor dat software altijd in bevoorrechte modus draait. Het is dan ook de aanbevolen modus voor het draaien van software zoals een real-time besturingssysteem (RTOS) of toegang tot het bootimage, beveiligde sleutels en andere bronnen die van kritiek belang zijn voor de werking van het systeem. In thread-modus draait software in ongeprivilegieerde modus, maar geprivilegieerde processen kunnen het privilegeniveau wijzigen van software die in deze modus draait. Thread mode wordt meestal gebruikt voor het uitvoeren van applicatiecode.

In combinatie leveren de modi secure/non-secure en handler/thread dezelfde soort gelaagde bescherming als in eerdere systemen die beschermingsringen ondersteunen. Met de STMicroelectronics STM32L552VET6, bijvoorbeeld, kunnen ontwikkelaars vertrouwde code met volledige rechten isoleren van niet-vertrouwde code met minimale rechten (figuur 2).

Figuur 2: TrustZone-processoren zoals de STMicroelectronics STM32L552VET6 bieden een combinatie van processormodi waarmee ontwikkelaars vertrouwde systeemsoftware, zoals boot images, kunnen isoleren van onvertrouwde applicatiecode, zoals radiofrequentie (RF) communicatiestacks van derden. (Afbeelding bron: DigiKey, van STMicroelectronics bronmateriaal)

In deze processoren geïntegreerde isolatiemechanismen beperken de mogelijkheden van elke processor om toegang te krijgen tot verschillende gebieden van het programmagegevensgeheugen. Wanneer de NXP LPC55S6x-kern zich bijvoorbeeld in de beveiligde toestand bevindt, heeft hij geen toegang tot niet-beveiligd programmageheugen, hoewel hij nog wel toegang heeft tot niet-beveiligd datageheugen. Anderzijds, wanneer de LPC55S6x kern in de niet-beveiligde toestand draait, heeft hij enkel toegang tot het niet-beveiligde programmageheugen en data-geheugen (figuur 3).

Figuur 3: Processoren zoals de LPC55S6x-apparaten van NXP kunnen ervoor zorgen dat de kern in de veilige staat (S-status) draait om beveiligd programmageheugen te lezen (groen) of in de niet-veilige staat (NS-status) om niet-beveiligd programmageheugen te lezen (rood). (Bron afbeelding: NXP Semiconductors)

Wanneer deze processoren in de veilige status draaien om vertrouwde software uit te voeren, kunnen zij geen instructies ophalen uit het niet-veilige programmageheugen. Omgekeerd hebben deze processoren, wanneer zij in de niet-veilige status werken om niet-vertrouwde software zoals applicatiecode uit te voeren, geen toegang tot code of gegevens die zich in beveiligde gebieden bevinden. Niettemin vereist applicatiecode doorgaans de mogelijkheid om vertrouwde code uit te voeren in veilige bibliotheken. TrustZone-processoren stellen ontwikkelaars in staat aan deze eis te voldoen door het definiëren van niet-beveiligde oproepbare (NSC) geheugengebieden die toegestane toegangspunten bieden tot beveiligde bibliotheken (figuur 4).

Figuur 4: Niet-beveiligde opvraagbare regio's bieden veilige toegangspunten van niet-beveiligde naar beveiligde geheugengebieden, waardoor niet-beveiligde toepassingen functies in beveiligde bibliotheken kunnen uitvoeren. (Bron afbeelding: STMicroelectronics)

Geheugenaliassen verhogen de veiligheid

TrustZone-processoren zoals de NXP LPC55S69JBD100K en STMicroelectronics STM32L552VET6 beheren de uitvoering door het fysieke programmageheugen te aliassen in beveiligde en niet-beveiligde geheugenruimten. De STMicroelectronics STM32L552VET6 aliast bijvoorbeeld code in flash en SRAM tweemaal, eenmaal in een niet-beveiligd adresbereik (0x0800_0000 tot 0x0BFF_FF) en eenmaal in een beveiligd adresbereik (0x0C00_0000 tot 0x0FFF_FFFF). Evenzo aliast de NXP LPC55S69JBD100K het fysieke programmageheugen in een niet-beveiligde ruimte die begint bij 0x0000_0000 en ook in een beveiligde ruimte die begint bij 0x1000_0000. Elk van deze processoren gebruikt een soortgelijke aanpak voor andere geheugentypen en randapparatuur, door deze tweemaal te aliassen in veilige en niet-veilige gebieden.

Wanneer de processor toegang moet krijgen tot een geheugenplaats, wordt de toegang tot die plaats bepaald door een veiligheidsattribuut dat door twee hardware-eenheden wordt gegenereerd:

• Implementation Defined Attribution Unit (IDAU), een vaste hardware-eenheid buiten de processorkern die zorgt voor een vaste beveiligingsstatus van de geheugenkaart zoals gedefinieerd door de fabrikant.
• Secure Attribution Unit (SAU), een in de processorkern geïntegreerde programmeerbare eenheid die wordt gebruikt om de beveiligingsstatus van maximaal acht geheugengebieden te bepalen.

Tijdens de systeeminitialisatie definiëren de configuratieroutines in de veilige modus de veiligheidsstatus van elk gebied door een aantal SAU-registers in te stellen, waaronder:

• SAU-regionummerregister (SAU_RNR) om een regio te selecteren voor verdere bewerkingen
• SAU Region Base Address Register (SAU_RBAR) om het startadres van de regio te bepalen
• SAU Region Limit Address Register (SAU_RLAR) om de omvang van het gebied te bepalen

In het softwarepakket STM32Cube MCU voor de STM32L5-serie biedt STMicroelectronics meerdere sjabloonbestanden die het gebruik van processorfuncties demonstreren, waaronder SAU-configuratie. Zoals te zien is in Lijst 1, kunnen ontwikkelaars deze regio's voor elke configuratieparameter definiëren met behulp van een macro (SAU_INIT_REGION(n)) die de registerwaarden in een SAU-structuur instelt die wordt gebruikt wanneer configuratie-instellingen naar het apparaat worden geschreven.

Kopieer
/*
//   <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: Dit fragment, dat is opgenomen in sjablonen in het STMicroelectronics softwarepakket STM32Cube MCU voor de STM32L5-serie, laat zien hoe ontwikkelaars geheugenregio's en de bijbehorende beveiligingsstatus definiëren. (Code bron: STMicroelectronics)

De IDAU en SAU werken samen om te bepalen of de geheugenplaats toegankelijk is, waarbij het hoogste beveiligingsniveau van de twee wordt teruggegeven. Aangezien een processor werkt met de geheugenalias die overeenkomt met zijn beveiligde/niet-beveiligde bedrijfstoestand, garandeert het veiligheidsattribuut dat wordt gegenereerd door de combinatie van de IDAU en de SAU dat alleen gebieden met het overeenkomstige beveiligingsniveau toegankelijk zijn (figuur 5).

Figuur 5: In de NXP LPC55S69JBD100K genereren de IDAU en SAU samen een beveiligingsattribuut voor elke geheugenalias, waardoor code die niet uit elk respectief gebied mag lopen, effectief wordt verwijderd. (Bron afbeelding: NXP Semiconductors)

Wanneer de NXP LPC55S69JBD100K bijvoorbeeld in veilige modus werkt, zal het veiligheidsattribuut dat door de IDAU en SAU wordt gegenereerd toegang verhinderen tot niet-veilige toepassingen in de veilige alias van een blok fysiek geheugen, waardoor die niet-veilige code effectief uit de veilige alias wordt verwijderd. Omgekeerd zullen, wanneer de processor in niet-beveiligde modus werkt, de IDAU- en SAU-beveiligingsattributen effectief veilige toepassingen elimineren van de resulterende niet-beveiligde alias.

Instellen van privileges en toegangscontrole

Terwijl de IDAU en SAU rechtstreeks beveiligde en niet-beveiligde toegangsbeperkingen afdwingen, werken zij met beveiligde en niet-beveiligde geheugenbeschermingseenheden (MPU's) om de toegangsrechten te bepalen die bij de doelbron horen (figuur 6).

Figuur 6: In TrustZone-processoren zoals de hier geïllustreerde NXP LPC55S69JBD100K wordt het door de SAU en IDAU gegenereerde veiligheidsattribuut gecombineerd met instellingen die worden beheerd door beveiligde en niet-beveiligde MPU's om samen met het beveiligingsniveau ook het privilegeniveau te leveren. (Bron afbeelding: NXP Semiconductors)

De MPU, die in deze processoren is ingebouwd, biedt fijnkorrelige toegangscontrole van geheugenbronnen. In de STMicroelectronics STM32L552VET6, bijvoorbeeld, ondersteunt de MPU een verscheidenheid van toegangsrechten die verschillen wanneer de processor in geprivilegieerde handler-modus of in ongeprivilegieerde thread-modus draait (tabel 1).

Tabel 1: De STMicroelectronics STM32L552VET6 biedt ontwikkelaars de mogelijkheid de MPU te gebruiken om verschillende toegangsniveaus te definiëren die verschillend werken in geprivilegieerde en ongeprivilegieerde modus. (Bron: STMicroelectronics)

Een van deze attributen, het Execute Never (XN) attribuut, stelt ontwikkelaars in staat ervoor te zorgen dat de processor nooit code probeert uit te voeren vanuit het geassocieerde geheugengebied, waardoor een extra niveau van runtime bescherming wordt geboden. In systemen met code die rechtstreeks uit flash komt, kunnen ontwikkelaars bijvoorbeeld het XN-attribuut voor ongebruikte SRAM-gebieden instellen om te voorkomen dat het systeem wordt gecompromitteerd, zelfs als malware-injectieaanvallen met die gebieden slagen.

Uitbreiding van de bescherming tot meer randapparatuur en geheugen

De IDAU-, SAU- en MPU-functies van deze processoren bieden een flexibele basis voor de bescherming van de runtime-uitvoering van zowel systeemsoftware als toepassingen, maar deze mogelijkheden zijn beperkt tot de processor zelf. Processoren zoals de NXP LPC55S69JBD100K en STMicroelectronics STM32L552VET6 dragen de beveiligings- en voorkeursmogelijkheden over op andere geheugensystemen en interfaces door middel van een verscheidenheid van benaderingen.

Voor de STM32L552VET6 vult STMicroelectronics het ingebouwde TrustZone-mechanisme aan met zijn eigen global TrustZone controller (GTZC), ontworpen om randapparatuur, ingebed SRAM en externe geheugens te beschermen (afbeelding 7).

Figuur 7: De STMicroelectronics STM32L552VET6-processor integreert een globale TrustZone-controller (GTZC) die de beveiliging uitbreidt tot randapparaten en geheugen die niet in het eigen TrustZone-framework zijn opgenomen. (Bron afbeelding: STMicroelectronics)

In de NXP LPC55S69JBD100K worden het privilege-attribuut (HPRIV) en het beveiligings-attribuut (HNONSEC) over de interne Advanced High-performance Bus (AHB)-matrix getransporteerd om de geheugenbeveiligingscheckers (MPC's), de perifere beveiligingscheckers (PPC's) en de masterbeveiligingswrappers (MSW's) voor andere busmasters te bereiken (figuur 8).

Figuur 8: In de NXP LPC55S69JBD100K worden de privilege- en beveiligingsniveaus doorgegeven aan bijkomende hardware-eenheden die deze attributen toepassen op bewerkingen met betrekking tot geheugen, randapparatuur en andere bus masters. (Bron afbeelding: NXP Semiconductors)

Hoewel het belangrijk is inzicht te hebben in de onderliggende mechanismen voor software-isolatie en systeembeveiliging, kunnen ontwikkelaars gebruik maken van ontwikkelingsondersteuning om deze mogelijkheden snel in hun eigen ontwerpen toe te passen.

STMicroelectronics biedt haar STM32L552E-EV, STM32L562E-DK, en NUCLEO-L552ZE-Q evaluatiekaarten aan als een snel prototyping platform voor het bouwen van toepassingen gebaseerd op haar STM32L5 processoren. De STM32CubeIDE geïntegreerde ontwikkelingsomgeving (IDE) van het bedrijf biedt een uitgebreide omgeving voor softwareprogrammering, en de STM32CubeProgrammer biedt zowel versies met een grafische gebruikersinterface (GUI) als met een opdrachtregelinterface (CLI) voor het programmeren van interne en externe geheugens. Met dit hulpmiddel kunnen ontwikkelaars bijvoorbeeld veilige gebieden in flashgeheugen definiëren (figuur 9).

Figuur 9: De STMicroelectronics STM32CubeProgrammer biedt een eenvoudige aanpak voor het definiëren van veilige gebieden in flashgeheugen. (Bron afbeelding: STMicroelectronics)

Voor de snelle ontwikkeling van systemen op basis van NXP's LPC55S69-processoren kunnen ontwikkelaars ontwerpen bouwen op de NXP LPC55S69-EVK-evaluatiekaart. Voor systeemconfiguratie en softwareprogrammering biedt de NXP MCUXpresso IDE een uitgebreid platform voor het maken van toepassingen op basis van NXP LPC55S69-processoren.

Conclusie

De veiligheid van het ivd hangt af van fundamentele beveiligingsmechanismen voor cryptografie en veilige opslag, alsmede van de mogelijkheden om toepassingen te bouwen op een vertrouwensbasis op basis van hardwarebeveiligingsmechanismen. Hoewel al deze maatregelen noodzakelijk zijn voor de veiligheid, zijn zij zelden afdoende om het hoofd te bieden aan bedreigingen die erop gericht zijn kwetsbaarheden in runtime-omgevingen van systemen uit te buiten. Met behulp van gelaagde beschermingsmechanismen die beschikbaar zijn in een groeiend aantal processoren, kunnen ontwikkelaars veilige ivd-apparaten bouwen die beter in staat zijn om deze bedreigingen te beperken en hun impact op ivd-toepassingen te beperken of weg te nemen.