Principes de base de la sécurité IoT — 4e partie : atténuer les menaces pendant l'exécution

Note de l'éditeur : Malgré la prolifération des dispositifs IoT, la sécurisation de ces dispositifs reste une préoccupation constante, dans la mesure où les problèmes de sécurité peuvent constituer un obstacle à l'adoption des dispositifs connectés dans les applications Internet industriel des objets (IIoT) et les applications stratégiques où les données d'entreprise et personnelles peuvent être compromises en cas d'attaque réussie. Sécuriser les applications IoT peut être intimidant, mais en réalité la sécurité des dispositifs IoT peut reposer sur quelques principes relativement simples qui sont pris en charge par les dispositifs de sécurité matériels. En suivant des pratiques de sécurité bien établies, il est possible de répondre à ces préoccupations. Cette série en plusieurs parties fournit des conseils pratiques pour aider les développeurs à s'assurer que les meilleures pratiques sont suivies dès le départ. La 1re partie traite des algorithmes de cryptographie sous-jacents aux conceptions sécurisées. La 2e partie traite du rôle des clés privées, de la gestion des clés et du stockage sécurisé dans les conceptions IoT sécurisées. La 3e partie étudie les mécanismes intégrés dans les processeurs sécurisés pour atténuer les autres types de menaces sur les dispositifs IoT. Ici, la 4e partie identifie des mécanismes de sécurité et montre comment les appliquer dans les processeurs avancés pour contribuer à assurer l'isolement requis pour atténuer les attaques sur l'environnement d'exécution des dispositifs IoT. La 5e partie décrit comment la sécurité IoT continue à s'étendre depuis les dispositifs IoT par le biais de mesures de sécurité de niveau supérieur utilisées pour connecter ces dispositifs aux ressources cloud IoT.

La cryptographie matérielle avec stockage sécurisé fournit la base requise pour mettre en œuvre des conceptions IoT sécurisées. L'amorçage sécurisé et la mise à jour sécurisée des micrologiciels en direct (FOTA) utilisent cette base pour établir une racine de confiance pour l'exécution des logiciels. Néanmoins, un dispositif Internet des objets (IoT) requiert une protection continue contre les logiciels pouvant accidentellement ou intentionnellement compromettre les ressources sécurisées auxquelles accèdent une application logicielle et le code système exécuté dans l'environnement d'exécution.

Cet article décrit comment les développeurs peuvent utiliser les mécanismes de sécurité intégrés dans certains processeurs de NXP Semiconductors, STMicroelectronics et plus pour protéger plus efficacement les systèmes contre les menaces intervenant pendant l'exécution des logiciels.

Comment les logiciels d'exécution peuvent être mis à mal

Comme nous l'avons vu dans les parties précédentes de cette série, le chiffrement, le stockage sécurisé des clés, l'amorçage sécurisé et la mise à jour sécurisée des micrologiciels constituent des éléments de base nécessaires à la sécurité IoT. Bien que ces capacités contribuent de manière essentielle à la sécurité globale des dispositifs IoT, elles peuvent présenter une solution incomplète face aux attaques conçues pour corrompre les logiciels d'exécution dans les systèmes connectés. Dans l'idéal, les tentatives de pénétration des lignes de défense fournies par ces mécanismes échoueraient grâce à l'environnement de confiance basé sur la racine de confiance créée par un processus d'amorçage sécurisé. En pratique, les systèmes construits avec ces capacités de sécurité robustes peuvent être — et ont été — compromis par des attaques qui injectent un bloc de code corrompu ou un logiciel malveillant dans le système.

En utilisant une grande variété de méthodes, les pirates informatiques peuvent exploiter les vulnérabilités de sécurité d'une partie d'un système pour attaquer d'autres parties. Les attaques par débordement de la mémoire tampon, par exemple, exploitent des applications logicielles qui permettent à de vastes flux de données d'entrée de dépasser la zone tampon prévue. Si ce débordement de données contient du code, le processeur peut l'exécuter plus tard, fournissant ainsi aux pirates un point d'entrée pour d'autres attaques. En utilisant ces méthodes et bien d'autres, les pirates informatiques étendent progressivement leurs capacités de pénétration dans d'autres parties plus vastes d'un système.

Des vulnérabilités peuvent exister dans n'importe quel composant logiciel de n'importe quelle couche de la pile logicielle d'un système. Alors que les développeurs s'efforcent de créer des systèmes plus riches sur le plan fonctionnel, le besoin de composants logiciels supplémentaires augmente le risque que leurs systèmes soient plus vulnérables. Dans le même temps, la variété des vulnérabilités que l'on trouve dans les logiciels ne cesse de croître. Par exemple, la liste officielle CVE® (Common Vulnerabilities and Exposures) des vulnérabilités de cybersécurité connues du public a montré une augmentation de 15 % en glissement annuel au premier trimestre 2020.

Les niveaux de protection protègent les logiciels critiques

L'atténuation des menaces est une bataille constante entre les pirates informatiques en chapeau noir et les spécialistes de la sécurité en chapeau blanc. Même si les menaces continuent à apparaître, les développeurs peuvent considérablement renforcer la sécurité de leurs conceptions en tirant parti de méthodes conçues pour isoler les multiples processus logiciels différents requis dans une application typique. Pendant des années, les systèmes sécurisés ont été construits sur la base d'une approche de protection à plusieurs niveaux. Dans cette approche classique, des anneaux de protection concentriques assurent des niveaux d'isolement croissants dans un système. Les applications s'exécutant sur la couche la plus externe ne peuvent accéder aux pilotes de périphériques et aux services système des couches internes, qui ne peuvent à leur tour pas accéder au noyau logiciel de la couche la plus interne (Figure 1).

Figure 1 : Les systèmes logiciels sécurisés protègent les applications, les pilotes et les noyaux de systèmes d'exploitation dans des anneaux de protection qui assurent une protection de plus en plus élevée. (Source de l'image : Wikipédia)

Les dispositifs Intel x86 commençant par 80286, maintenant disponibles chez Rochester Electronics, prennent en charge quatre niveaux, désignés à l'aide d'un registre de sélection contenant un champ de niveau de privilège requis (RPL) de deux bits. Les architectures de processeurs modernes comme Arm® TrustZone ont considérablement étendu les capacités de sécurité grâce à une variété de mécanismes conçus pour isoler les processus utilisateur pendant l'exécution. Les développeurs peuvent trouver ce type de capacité de protection à plusieurs niveaux dans un certain nombre de processeurs de systèmes embarqués, notamment :

• Microcontrôleurs SAM L11 basés sur Arm Cortex®-M23 de Microchip Technology
• Systèmes sur puce (SoC) sans fil nRF9160 basés sur Arm Cortex-M33 de Nordic Semiconductor
• Microcontrôleurs M2351 basés sur Arm Cortex-M23 de Nuvoton Technology
• Microcontrôleurs LPC55 basés sur Arm Cortex-M33 de NXP Semiconductors
• SoC sans fil EFR32BG21 basés sur Arm Cortex-M33 de Silicon Labs
• Microcontrôleurs STM32L5 basés sur Arm Cortex-M33 de STMicroelectronics

Arm TrustZone pour Cortex-M offre des capacités de sécurité améliorées aux processeurs de systèmes embarqués Arm Cortex-M, tels que le LPC55S69JBD100K de NXP et le STM32L552VET6 de STMicroelectronics. TrustZone pour Cortex-A fournit des capacités similaires pour les processeurs d'application basés sur Arm Cortex-A tels que l'i.MX 8M Mini MIMX8MM6DVTLZAA de NXP et le STM32MP157AAC3T de STMicroelectronics.

Pour chaque série Arm, TrustZone propose des mécanismes qui prennent en charge l'amorçage sécurisé et la sécurisation du code, des données et de la mémoire, entre autres caractéristiques de sécurité. Conçu pour prendre en charge les exigences de faible latence des systèmes embarqués, TrustZone pour les processeurs Cortex-M présente des améliorations de performances, notamment des interruptions sécurisées rapides et des transitions matérielles rapides entre les états de sécurité. Cet article décrit TrustZone pour les processeurs Cortex-M en ciblant deux processeurs représentatifs de cette classe : LPC55S69JBD100K de NXP et STM32L552VET6 de STMicroelectronics.

Les modes de fonctionnement des processeurs permettent une protection étendue

Au cœur de l'architecture TrustZone, les processeurs peuvent fonctionner dans plusieurs modes d'exploitation qui permettent d'isoler les processus logiciels et les ressources système. Les modes « sécurisé » et « non sécurisé » des processeurs permettent d'isoler les processus fiables des processus non fiables. Les modes « handler » et « thread » des processeurs fournissent un mécanisme de protection distinct qui offre une granularité supplémentaire en isolant les processus et les ressources.

Dans l'architecture TrustZone, un processeur fonctionnant en mode « handler » fait en sorte que le logiciel fonctionne toujours en mode privilégié. En tant que tel, c'est le mode recommandé pour exécuter des logiciels tels qu'un système d'exploitation en temps réel (RTOS) ou pour accéder à l'image d'amorçage, aux clés sécurisées et à d'autres ressources essentielles au fonctionnement du système. En mode « thread », les logiciels fonctionnent en mode non privilégié, mais les processus privilégiés peuvent modifier le niveau de privilège des logiciels fonctionnant dans ce mode. Le mode « thread » est généralement utilisé pour exécuter le code d'application.

Utilisés conjointement, les modes sécurisé/non sécurisé et handler/thread offrent le même type de protection à plusieurs niveaux que les systèmes précédents avec anneaux de protection. En utilisant le STM32L552VET6 de STMicroelectronics, par exemple, les développeurs peuvent isoler le code de confiance avec des privilèges complets du code non sécurisé avec des privilèges minimaux (Figure 2).

Figure 2 : Les processeurs TrustZone tels que le STM32L552VET6 de STMicroelectronics offrent une combinaison de modes de processeur qui permettent aux développeurs d'isoler les logiciels système de confiance tels que les images d'amorçage des codes d'application non fiables comme les piles de communications radiofréquences (RF) de tiers. (Source de l'image : Digi-Key, d'après du matériel source de STMicroelectronics)

Les mécanismes d'isolement intégrés dans ces processeurs limitent la capacité de chaque processeur à accéder à différentes zones de la mémoire de données du programme. Par exemple, lorsque le cœur LPC55S6x de NXP est à l'état sécurisé, il ne peut pas accéder à la mémoire de programme non sécurisée, bien qu'il puisse toujours accéder à la mémoire de données non sécurisée. D'autre part, lorsque le cœur LPC55S6x fonctionne dans un état non sécurisé, il ne peut accéder qu'à la mémoire de programme et à la mémoire de données non sécurisées (Figure 3).

Figure 3 : Les processeurs tels que les dispositifs LPC55S6x de NXP peuvent garantir que le cœur fonctionne à l'état sécurisé (état S) pour lire la mémoire de programme sécurisée (en vert) ou à l'état non sécurisé (état NS) pour lire la mémoire de programme non sécurisée (en rouge). (Source de l'image : NXP Semiconductors)

Lorsqu'ils fonctionnent à l'état sécurisé pour exécuter des logiciels de confiance, ces processeurs ne peuvent pas récupérer des instructions dans la mémoire de programme non sécurisée. Inversement, lorsqu'ils fonctionnent dans un état non sécurisé pour exécuter des logiciels non fiables tels que du code d'application, ces processeurs ne peuvent pas accéder au code ni aux données situés dans des zones sécurisées. Néanmoins, le code d'application nécessite généralement la capacité d'exécuter un code de confiance dans des bibliothèques sécurisées. Les processeurs TrustZone permettent aux développeurs de répondre à cette exigence en définissant des zones de mémoire appelables non sécurisées (NSC) qui fournissent des points d'entrée autorisés aux bibliothèques sécurisées (Figure 4).

Figure 4 : Les zones d'appel non sécurisées fournissent des points d'entrée sécurisés des zones de mémoire non sécurisées vers des zones sécurisées, permettant à des applications non sécurisées d'exécuter des fonctions dans des bibliothèques sécurisées. (Source de l'image : STMicroelectronics)

Les alias mémoire renforcent la sécurité

Les processeurs TrustZone tels que le LPC55S69JBD100K de NXP et le STM32L552VET6 de STMicroelectronics gèrent l'exécution par aliasing de la mémoire de programme physique dans des espaces mémoire sécurisés et non sécurisés. Par exemple, le STM32L552VET6 de STMicroelectronics aliase le code en Flash et SRAM deux fois, une fois dans une plage d'adresses non sécurisée (0x0800_0000 à 0x0BFF_FFFF) et une autre fois dans une plage d'adresses sécurisée (0x0C00_0000 à 0x0FFF_FFFF). De même, le LPC55S69JBD100K de NXP aliase la mémoire de programme physique dans un espace non sécurisé à partir de 0x0000_0000 et également dans un espace sécurisé à partir de 0x1000_0000. Chacun de ces processeurs utilise une approche similaire pour les autres types de mémoire et les périphériques, en les aliasant deux fois dans les zones sécurisées et non sécurisées.

Lorsque le processeur a besoin d'accéder à un emplacement mémoire, la possibilité d'accéder à cet emplacement est déterminée par un attribut de sécurité généré par deux unités matérielles :

• IDAU (Implementation Defined Attribution Unit), qui est une unité matérielle fixe à l'extérieur du cœur de processeur qui fournit un état de sécurité fixe du mappage mémoire tel que défini par le fabricant.
• SAU (Secure Attribution Unit), qui est une unité programmable intégrée au cœur de processeur et utilisée pour définir l'état de sécurité de jusqu'à huit zones de mémoire.

Lors de l'initialisation du système, des routines de configuration fonctionnant en mode sécurisé définissent l'état de sécurité de chaque zone en spécifiant quelques registres SAU, notamment :

• Registre de numéros de zone SAU (SAU_RNR) pour sélectionner une zone en vue d'opérations ultérieures
• Registre d'adresses de base de zone SAU (SAU_RBAR) pour définir l'adresse de départ de la zone
• Registre d'adresses de limite de zone SAU (SAU_RLAR) pour définir l'étendue de la zone

STMicroelectronics fournit plusieurs fichiers de modèles dans son progiciel STM32Cube MCU pour la série STM32L5, qui démontrent l'utilisation des fonctionnalités du processeur, y compris la configuration SAU. Comme illustré dans la Liste 1, les développeurs peuvent définir ces zones pour chaque paramètre de configuration en utilisant une macro (SAU_INIT_REGION(n)) qui spécifie les valeurs de registre dans une structure SAU utilisée lors de l'écriture des paramètres de configuration sur le dispositif.

Copier
/*
//   <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
 

Liste 1 : Inclus dans les modèles du progiciel STM32Cube MCU de STMicroelectronics pour la série STM32L5, cet extrait montre comment les développeurs définissent les zones de mémoire et leur statut de sécurité associé. (Source du code : STMicroelectronics)

Les unités IDAU et SAU travaillent de concert pour déterminer si l'emplacement de la mémoire est accessible, renvoyant le niveau de sécurité le plus élevé des deux. Comme un processeur travaille avec l'alias mémoire correspondant à son état de fonctionnement sécurisé/non sécurisé, l'attribut de sécurité généré par la combinaison des unités IDAU et SAU garantit l'accessibilité uniquement aux zones ayant le niveau de sécurité correspondant (Figure 5).

Figure 5 : Dans le LPC55S69JBD100K de NXP, les unités IDAU et SAU se combinent pour générer un attribut de sécurité pour chaque alias mémoire, supprimant ainsi le code qui n'est pas autorisé à s'exécuter de chaque zone respective. (Source de l'image : NXP Semiconductors)

Par exemple, lorsque le LPC55S69JBD100K de NXP fonctionne en mode sécurisé, l'attribut de sécurité généré par les unités IDAU et SAU empêche l'accès aux applications non sécurisées contenues dans l'alias sécurisé d'un bloc de mémoire physique, éliminant ainsi effectivement ce code non sécurisé de l'alias sécurisé. Inversement, lorsque le processeur fonctionne en mode non sécurisé, les attributs de sécurité IDAU et SAU éliminent efficacement les applications sécurisées de l'alias non sécurisé qui en résulte.

Définition des privilèges et du contrôle d'accès

Tandis que les unités IDAU et SAU appliquent directement les restrictions d'accès sécurisé et non sécurisé, elles travaillent avec des unités de protection de la mémoire (MPU) sécurisées et non sécurisées pour déterminer les droits d'accès associés à la ressource cible (Figure 6).

Figure 6 : Dans les processeurs TrustZone tels que le LPC55S69JBD100K de NXP illustré ici, l'attribut de sécurité généré par les unités SAU et IDAU se combine avec les paramètres gérés par les unités de protection de la mémoire sécurisées et non sécurisées pour fournir le niveau de privilège en plus du niveau de sécurité. (Source de l'image : NXP Semiconductors)

Intégrée à ces processeurs, l'unité de protection de la mémoire permet un contrôle fin de l'accès aux ressources mémoire. Dans le STM32L552VET6 de STMicroelectronics, par exemple, l'unité de protection de la mémoire prend en charge une variété de droits d'accès qui diffèrent selon que le processeur fonctionne en mode « handler » privilégié ou en mode « thread » non privilégié (Tableau 1).

Tableau 1 : Le STM32L552VET6 de STMicroelectronics permet aux développeurs d'utiliser son unité de protection de la mémoire pour définir différents niveaux d'accès qui fonctionnent différemment en mode privilégié et non privilégié. (Source du tableau : STMicroelectronics)

Parmi ces attributs, l'attribut Execute Never (XN) permet aux développeurs de s'assurer que le processeur ne tente jamais d'exécuter du code à partir de la zone mémoire associée, offrant ainsi un autre niveau de protection d'exécution. Par exemple, dans les systèmes exécutant du code directement à partir de la mémoire Flash, les développeurs peuvent définir l'attribut XN pour les zones SRAM inutilisées afin d'éliminer toute possibilité que le système soit compromis même si des attaques par injection de logiciels malveillants réussissent dans ces zones.

Étendre la protection à un plus grand nombre de périphériques et de mémoires

Les fonctionnalités des unités IDAU, SAU et de protection de la mémoire de ces processeurs offrent une base flexible pour protéger l'exécution des logiciels et des applications système, mais ces capacités sont limitées au processeur lui-même. Des processeurs tels que le LPC55S69JBD100K de NXP et le STM32L552VET6 de STMicroelectronics permettent de transférer les capacités de sécurité et de privilège vers d'autres interfaces et systèmes de mémoire par le biais de diverses approches.

Pour son STM32L552VET6, STMicroelectronics complète le mécanisme TrustZone natif avec son propre contrôleur TrustZone global (GTZC) conçu pour protéger les périphériques, la SRAM embarquée et les mémoires externes (Figure 7).

Figure 7 : Le processeur STM32L552VET6 de STMicroelectronics intègre un contrôleur TrustZone global (GTZC) qui étend la protection de sécurité aux périphériques et à la mémoire non inclus dans la structure TrustZone native. (Source de l'image : STMicroelectronics)

Dans le LPC55S69JBD100K de NXP, l'attribut de privilège (HPRIV) et l'attribut de sécurité (HNONSEC) sont transférés via la matrice interne AHB (Advanced High-performance Bus) pour atteindre les contrôleurs MPC (Memory Protection Checker) et PPC (Peripheral Protection Checker), et les enveloppes MSW (Master Security Wrapper) pour les autres maîtres de bus (Figure 8).

Figure 8 : Dans le LPC55S69JBD100K de NXP, les niveaux de privilège et de sécurité sont transmis à des unités matérielles supplémentaires qui appliquent ces attributs aux opérations impliquant la mémoire, les périphériques et d'autres maîtres de bus. (Source de l'image : NXP Semiconductors)

Bien qu'il soit important de comprendre les mécanismes sous-jacents de l'isolement des logiciels et de la protection des systèmes, les développeurs peuvent tirer parti du support de développement pour appliquer rapidement ces capacités dans leurs propres conceptions.

STMicroelectronics fournit les cartes d'évaluation STM32L552E-EV, STM32L562E-DK et NUCLEO-L552ZE-Q en tant que plateforme de prototypage rapide pour le développement d'applications basées sur ses processeurs STM32L5. L'environnement de développement intégré (IDE) STM32CubeIDE de la société fournit un environnement complet pour la programmation logicielle, et le STM32CubeProgrammer offre à la fois des versions d'interface utilisateur graphique (GUI) et d'interface de ligne de commande (CLI) pour la programmation de mémoires internes et externes. Grâce à cet outil, les développeurs peuvent, par exemple, définir des zones sécurisées dans la mémoire Flash (Figure 9).

Figure 9 : Le STM32CubeProgrammer de STMicroelectronics offre une approche simple pour définir des zones sécurisées en mémoire Flash. (Source de l'image : STMicroelectronics)

Pour le développement rapide de systèmes basés sur les processeurs LPC55S69 de NXP, les développeurs peuvent créer des conceptions sur la carte d'évaluation LPC55S69-EVK de NXP. Pour la configuration système et la programmation logicielle, l'IDE MCUXpresso de NXP fournit une plateforme complète pour la création d'applications basées sur les processeurs LPC55S69 de NXP.

Conclusion

La sécurité IoT dépend de mécanismes de sécurité fondamentaux pour la cryptographie et le stockage sécurisé, et des capacités à créer des applications sur une racine de confiance basée sur des mécanismes de sécurité matériels. Bien que tous ces éléments soient requis pour la sécurité, ils sont rarement suffisants pour contrer les menaces permanentes visant à exploiter les vulnérabilités des environnements d'exécution système. En utilisant les mécanismes de protection à plusieurs niveaux disponibles dans un nombre croissant de processeurs, les développeurs peuvent créer des dispositifs IoT sécurisés plus à même d'atténuer ces menaces et de réduire ou d'éliminer leur impact sur les applications IoT.