Exploiter la sécurité Arm TrustZone dans les microcontrôleurs LPC5500

Découvrez comment Arm TrustZone renforce la sécurité dans les microcontrôleurs LPC5500 de NXP et comment implémenter des applications sécurisées et non-sécurisées.

Avec la prolifération des objets connectés, les menaces sophistiquées se multiplient. NXP y répond en intégrant des primitives de sécurité robustes dans la famille de MCU LPC5500, notamment un générateur de nombres aléatoires conforme FIPS, le moteur de chiffrement « Prince » pour l'exécution de code chiffré, et une clé sur puce de 4096 bits générée via la technologie PUF. Associés à l'accélérateur cryptographique sur puce « CASPER », ces MCU sont idéaux pour les déploiements IoT en périphérie de réseau exigeant un provisionnement de clés de bout en bout et une cybersécurité résiliente.

Au cœur de cette capacité se trouve Arm TrustZone pour Cortex-M. Les sections suivantes en expliquent les fondamentaux et montrent comment les exploiter dans vos projets.

Arm TrustZone pour Cortex-M

TrustZone crée deux contextes d'exécution isolés : un monde sécurisé hébergeant du code propriétaire ou sensible, et un monde non-sécurisé pour les applications utilisateur. Les bibliothèques propriétaires du fabricant peuvent résider en ROM, protégées de l'ingénierie inverse, tout en restant appelables par le code applicatif via une interface contrôlée.

La figure 1 illustre la coexistence de ROM sécurisée et de code utilisateur non-sécurisé sur la même puce.

Les transitions entre les deux mondes sont régies par l'extension de sécurité TrustZone, garantissant qu'une application non-sécurisée ne peut invoquer que des fonctions sécurisées exposées, sans jamais accéder directement à la mémoire sécurisée.

Modes processeur avec TrustZone

Alors que les cœurs Cortex-M3 et M4 offrent les modes thread et handler avec niveaux privilégié/non-privilégié, le Cortex-M33 ajoute TrustZone, ce qui donne quatre modes : thread non-sécurisé, thread sécurisé, handler non-sécurisé et handler sécurisé. Cette séparation introduit également des minuteurs SysTick distincts pour chaque domaine.

Partitionnement mémoire

TrustZone attribue des attributs de sécurité aux plages d'adresses : Sécurisé (S), Non-Sécurisé (NS) et Non-Sécurisé Appelable (NSC). L'accès à chaque zone dépend de l'état actuel du cœur. Le LPC55S69, par exemple, considère les adresses avec le bit 28 à 0 comme non-sécurisées et le reste comme sécurisé, sauf pour la mémoire programme configurable via l'unité d'attribution de sécurité (SAU).

Construction d'une application sécurisée

Le code sécurisé n'expose pas directement ses entrailles. Il publie plutôt une table de veneers — une fine couche de fonctions appelables depuis le non-sécurisé qui transfèrent les appels vers le monde sécurisé. La table de veneers réside en mémoire NSC, tandis que les vraies implémentations restent en mémoire sécurisée.

Les projets sécurisés typiques sont compilés en une bibliothèque d'objets et un fichier d'en-tête déclarant les fonctions veneers. L'application non-sécurisée n'inclut que l'en-tête ; à l'exécution, la table de veneers médiatise les appels vers les services sécurisés.

Transition entre les mondes

Deux instructions spéciales gèrent le changement d'état :

• SG — bascule le cœur en mode sécurisé.
• BXNS — retourne le contrôle au mode non-sécurisé.

Une séquence d'appel non-sécurisé ressemble à ceci :

 // Code non-sécurisé
SG(); // Entrée dans le monde sécurisé
SecureFunc(); // Appel du service sécurisé via veneer
BXNS(); // Retour au non-sécurisé

Tout accès illégal déclenche une exception Secure Fault, préservant l'intégrité du système.

Exemple « Hello World » sécurisé

Le SDK LPCXpresso55S69 inclut des démonstrations TrustZone qui divisent la compilation en projets sécurisé et non-sécurisé. Le projet sécurisé commence par un appel d'initialisation précoce :

__attribute__((cmse_nonsecure_entry)) void BOARD_InitTrustZone(void);

Cette fonction configure la SAU, l'IDAU et le partitionnement mémoire. La fonction main non-sécurisée reste concise car toute la configuration est gérée dans le domaine sécurisé :

int main(void) {
// Code non-sécurisé minimal
return 0;
}

Lorsque le côté non-sécurisé a besoin d'un service sécurisé, il invoque une fonction veneer, par exemple PRINTF_NSE() :

void PRINTF_NSE(const char *format, ...) __attribute__((cmse_nonsecure_entry));

L'implémentation sécurisée correspondante réside dans le projet sécurisé et est exportée vers la table de veneers.

Outils de partitionnement mémoire

Dans MCUXpresso, la perspective TEE offre un éditeur visuel pour la configuration SAU et IDAU :

Utilisez le tableau de gauche pour définir le niveau de sécurité de chaque région, et la carte de droite reflétera le partitionnement résultant.

Pourquoi TrustZone est important pour LPC5500

TrustZone donne au LPC5500 une séparation nette des responsabilités : le monde sécurisé protège le code propriétaire et les clés cryptographiques, tandis que le monde non-sécurisé héberge les applications utilisateur. Le matériel garantit que les accès mémoire illégaux sont bloqués, et l'infrastructure logicielle (tables de veneers, instructions SG/BXNS, outils TEE) simplifie le développement d'applications sécurisées.

Pour approfondir, regardez le webinaire NXP TrustZone : Calling the Secure World ou consultez la documentation officielle.

Les articles industriels sont une forme de contenu permettant aux partenaires industriels de partager actualités, messages et technologies avec les lecteurs d'All About Circuits d'une manière que le contenu éditorial ne permet pas. Tous les articles industriels sont soumis à des directives éditoriales strictes dans l'intention d'offrir aux lecteurs des actualités utiles, une expertise technique ou des récits. Les points de vue et opinions exprimés dans les articles industriels sont ceux du partenaire et non nécessairement ceux d'All About Circuits ou de ses rédacteurs.