Comment tirer parti des fonctionnalités de sécurité Arm TrustZone du LPC5500

Découvrez comment fonctionne l'extension Arm TrustZone pour la série LPC5500 et comment commencer à utiliser les mesures de sécurité dans les applications personnalisées sécurisées et non sécurisées.

Avec des appareils de plus en plus connectés et la sophistication croissante des pirates informatiques, de nombreuses entreprises, comme NXP Semiconductors, ont reconnu le besoin de contre-mesures. NXP a développé la série LPC5500 MCU, dotée de fonctionnalités de sécurité améliorées pouvant être utilisées pour protéger les projets intégrés.

NXP a adopté un générateur de nombres aléatoires conforme à la norme FIPS, sélectionné l'algorithme de décryptage « Prince » (permettant au cœur d'exécuter du code crypté symétriquement) et a implémenté une clé sur puce éphémère de 4096 bits avec la technologie PUF. Lorsqu'ils sont combinés à l'accélérateur matériel cryptographique sur puce « CASPER », les microcontrôleurs LPC5500 sont adaptés aux applications IoT à la périphérie du réseau nécessitant des contre-mesures de cybersécurité robustes et un provisionnement de clés sur l'ensemble du cycle de vie.

De plus, la puce exploite la technologie Arm TrustZone pour les appareils basés sur Cortex-M. Dans cet article, découvrez comment fonctionne l'extension TrustZone de la série LPC5500 et comment commencer à utiliser les mesures de sécurité dans les applications personnalisées.

Qu'est-ce que la technologie Arm TrustZone pour Cortex-M ?

Le principe de base de TrustZone est mieux expliqué à travers un exemple. Le fabricant du MCU fournit souvent un code propriétaire personnalisé tel que des bibliothèques de sécurité, un chargeur de démarrage ou des algorithmes DSP rapides dans la ROM du microcontrôleur. Cependant, les auteurs de ces applications ont souvent de bonnes raisons de protéger leur propriété intellectuelle :ils ne souhaitent peut-être pas que les utilisateurs ou les concurrents décompilent les binaires pour désosser les algorithmes.

D'une part, les programmeurs souhaitent utiliser ces bibliothèques logicielles prédéfinies. D'un autre côté, cependant, le fabricant ne souhaite pas que le code soit exposé à une partie potentiellement malveillante.

Figure 1. Le code utilisateur non sécurisé et le contenu de la ROM sécurisée résident sur le même MCU physique.

Le fournisseur souhaite masquer les détails de l'implémentation, tout en s'assurant que les développeurs peuvent accéder aux fonctions. Le code utilisateur est capable d'appeler les méthodes exposées du logiciel caché, mais il n'a pas d'accès direct à la mémoire détenue par la ROM sécurisée. Le résultat est une structure qui se compose de deux sous-systèmes isolés. Les transitions entre ces deux mondes sont régies par l'extension de sécurité TrustZone.

Cela signifie qu'un microcontrôleur utilisant TrustZone sera architecturé en deux projets distincts. Le premier projet démarre dans l'état sécurisé. Il configure ensuite les attributions de sécurité pour les ressources sur puce et peut publier des fonctions sécurisées dans une table accessible depuis l'état non sécurisé. Le second contient le code non sécurisé et a un accès limité aux fonctions exposées du monde sécurisé.

Différences par rapport aux architectures antérieures

Les cœurs Cortex-M3 et -M4 connaissent deux modes de processeur :le mode thread et le mode gestionnaire. Le logiciel d'application s'exécute en mode thread et le mode gestionnaire gère les exceptions. Le code peut fonctionner à un niveau privilégié ou non privilégié, qui contrôle l'accès à certaines fonctionnalités du processeur.

Avec l'extension TrustZone dans les cœurs Cortex-M33, deux nouveaux états ont été introduits, comme indiqué ci-dessus. Ce changement a entraîné quatre modes de processeur différents :gestionnaire non sécurisé, mode de gestionnaire sécurisé, thread non sécurisé et thread sécurisé.

Figure 2. L'extension TrustZone dans le noyau M33 crée quatre modes de processeur.

Outre d'autres mises à jour, de nouvelles minuteries SysTick ont ​​également été introduites avec les nouveaux états. Alors maintenant, il existe des minuteries distinctes pour l'état sécurisé et l'état non sécurisé.

Partition mémoire

Comme mentionné précédemment, la mémoire du MCU est partitionnée en zones sécurisées et non sécurisées. Le cœur du processeur du MCU ne peut accéder aux régions de mémoire sécurisées que s'il fonctionne dans l'un des modes sécurisés. Il ne peut pas accéder aux instructions qui résident dans d'autres partitions de mémoire. Cependant, il peut lire et écrire des segments sécurisés et non sécurisés de la RAM de données. Si le cœur du processeur est dans un état non sécurisé, il ne peut accéder qu'aux blocs d'instructions et de mémoire de données non sécurisés.

TrustZone décore les plages d'adresses dans la carte mémoire avec des attributions de sécurité. Il existe trois attributions de sécurité :sécurisée (S), non sécurisée (NS) et appelable non sécurisée (NSC). L'accès à chaque zone de mémoire est autorisé ou refusé, selon l'état de sécurité actuel du cœur.

Figure 3. Le CPU peut accéder à différentes zones en mode sécurisé et non sécurisé.

Sur le périphérique LPC55S69, la mémoire était divisée en segments sécurisés et non sécurisés en fonction de l'adresse. Si le bit d'adresse mémoire 28 est BAS, la mémoire n'est pas sécurisée. Sinon, c'est sécurisé. La seule exception est la mémoire du programme, qui peut être configurée via l'unité d'attribution de sécurité.

Les éléments constitutifs d'une application sécurisée

Le code non sécurisé ne peut pas faire d'appels directs vers la partie sécurisée de l'application. Au lieu de cela, la partie sécurisée expose une liste de fonctions auxquelles un utilisateur peut accéder. Cette liste s'appelle placage-table car il s'agit d'une couche très mince qui est visible de l'extérieur, mais cache les détails intérieurs. La table de placage est située dans une région de mémoire avec l'attribut TrustZone NonSecure Callable.

Habituellement, la source de la pièce sécurisée n'est pas visible. Au lieu de cela, il est compilé, donnant une bibliothèque d'objets et la table de placage comme fichier d'en-tête. Notez qu'aucun de ces fichiers ne contient aucune des instructions réelles, mais ensemble, ils contiennent les informations nécessaires pour appeler des fonctions sécurisées. La table de placage ne contient qu'une passerelle et une instruction de branchement vers l'emplacement mémoire sécurisé où résident les instructions réelles.

Transition entre les fonctions sécurisées et non sécurisées

Les processeurs avec l'extension TrustZone prennent en charge deux nouvelles fonctions pour la transition entre sécurisé et non sécurisé :l'instruction SG et BXNS.

Lorsque le code utilisateur veut une fonction sécurisée, il effectue un appel via la table de placage, qui se trouve dans la partie NSC de la mémoire. L'instruction SG est ensuite utilisée pour basculer le CPU en mode sécurisé. Lorsque l'exécution est terminée, le contrôle est renvoyé au code utilisateur avec l'instruction BXNS :

Figure 4. Le code utilisateur doit appeler une fonction sécurisée via le gatekeeper TrustZone.

Si l'utilisateur tente une opération illégale liée à la sécurité, comme accéder directement à une zone protégée, une exception Secure Fault est déclenchée.

Un exemple sécurisé Hello World

Le SDK pour le LPCXpresso55S69 est fourni avec quelques exemples TrustZone qui peuvent être chargés dans MCUXpresso. Comme mentionné précédemment, ces exemples consistent en deux projets distincts :la partie sécurisée et le code utilisateur non sécurisé.

La partie sécurisée ressemble presque exactement à tout autre projet MCUXpresso. Cependant, il y a une différence, qui est l'appel de fonction suivant :

Cette fonction doit être appelée le plus tôt possible. Après cela, il appartient au projet sécurisé de configurer la mémoire et le projet non sécurisé :

Étant donné que le projet sécurisé gère tous les appels d'installation, le projet non sécurisé n'a pas à le faire, sa fonction principale est donc courte :

Cependant, cette application n'appelle que les fonctions sécurisées définies dans l'autre projet. La définition suivante pour la fonction PRINTF_NSE est la suivante :

Si cette définition est suivie, elle pointe vers la table de placage, définie dans le projet sécurisé. Il est important de se rappeler que le projet non sécurisé ne connaît que le fichier d'en-tête qui décrit la table de placage. Cependant, dans ce cas, nous pouvons jeter un oeil à la fonction correspondante dans le code source :

La décoration "__attribute__((cmse_nonsecure_entry))" force la fonction à être exportée dans le fichier objet.

Partitionnement de la mémoire

Les attributs de sécurité définissent quelles parties de la mémoire sont sécurisées, NSC ou non sécurisées. Ceux-ci sont vérifiés à chaque accès. À cette fin, le MCU a été étendu avec du matériel qui gère ces vérifications et se compose de trois blocs logiques :

1. Unité d'attribution de sécurité (SAU)
2. Unité d'attribution définie par la mise en œuvre (IDAU)
3. Logique d'attribution de sécurité

Le SAU est programmé par le projet sécurisé au sein de la fonction BOARD_InitTrustZone(). Cela permet à la mémoire d'être partitionnée en huit régions avec des paramètres de sécurité différents. Notez que toute région non explicitement définie reste sécurisée par défaut.

L'IDAU permet au fabricant du MCU - NXP dans ce cas - de définir plus de régions personnalisées. Ici, les régions dépendent du 28e bit de l'adresse. Sur le MCU LPC55S69, le bas de la carte mémoire (0x0000_0000 à 0x2FFF_FFFF) est par défaut non sécurisé, il est donc libre de configurer avec le SAU.

L'arbitre s'assure que les paramètres IDAU et SAU correspondent. Pour qu'une région de mémoire soit marquée comme non sécurisée, les deux blocs logiques doivent être définis sur non sécurisé. Sinon, la mémoire reviendra à l'état sécurisé par défaut. Il en va de même pour les régions mémoire NSC. Pour qu'une section soit NSC, le SAU doit être marqué comme NSC et l'IDAU doit être défini sur non sécurisé.

Il existe un outil dans MCUXpresso qui permet à l'utilisateur de définir rapidement et facilement des régions de mémoire. Pour accéder à l'outil, utilisez la barre de menu principale de l'EDI et ouvrez la perspective TEE :

Figure 5. Cet outil MCUXpresso permet à l'utilisateur d'afficher et de modifier la carte mémoire du MCU.

Le tableau sur le côté gauche de l'outil peut changer le niveau de sécurité des régions de mémoire. La carte mémoire sur le côté droit illustre comment la mémoire est partitionnée.

TrustZone offre un composant de sécurité nécessaire

Sur la série LPC5500 MCU avec technologie TrustZone, la mémoire est divisée en un monde sécurisé et un monde non sécurisé - il est possible de permettre aux utilisateurs d'accéder à des parties de la mémoire non sécurisée, et une application sécurisée peut également être écrite pour être utilisée par autres. TrustZone agit comme un gardien entre les deux mondes et gère la transition du noyau entre eux.

Deux nouvelles instructions ont été introduites à cet effet. L'application sécurisée fournit une table de placage qui expose les fonctions pouvant être appelées à partir du contexte non sécurisé. Le matériel du MCU garantit qu'aucune opération d'accès à la mémoire illégale n'est effectuée. Ce matériel peut également être utilisé pour configurer les régions dans la carte mémoire. Pour cela, MCUXpresso propose la perspective TEE. Une meilleure compréhension de la sécurité fournie pour la série de microcontrôleurs LPC5500 permet une meilleure expérience de conception. Vous trouverez plus d'informations sur TrustZone en regardant TrustZone :Calling the Secure World.

Les articles de l'industrie sont une forme de contenu qui permet aux partenaires de l'industrie de partager des nouvelles, des messages et des technologies utiles avec les lecteurs d'All About Circuits d'une manière qui ne convient pas au contenu éditorial. Tous les articles de l'industrie sont soumis à des directives éditoriales strictes dans le but d'offrir aux lecteurs des informations utiles, une expertise technique ou des histoires. Les points de vue et opinions exprimés dans les articles de l'industrie sont ceux du partenaire et pas nécessairement ceux d'All About Circuits ou de ses rédacteurs.