Sécurisation des systèmes embarqués avec le PSoC 64

Le nombre de produits connectés à Internet continue de croître à un rythme exponentiel. Le problème auquel sont confrontées de nombreuses équipes de produits est que les développeurs de logiciels embarqués n'ont pas une expérience suffisante en matière de sécurité. Le manque d'expérience peut conduire à des exigences de sécurité négligées, à des failles de sécurité et à une mise en œuvre médiocre. Il en résulte des systèmes connectés qui ne sont pas suffisamment protégés et qui constituent une cible facile pour le vol de propriété intellectuelle et de données relatives aux dispositifs et aux utilisateurs.

Les concepteurs de systèmes basés sur microcontrôleurs ont à leur disposition plusieurs solutions qui simplifient les implémentations de sécurité et leur fournissent les outils nécessaires à une mise en œuvre réussie. Par exemple, les microcontrôleurs monocœurs peuvent utiliser Arm TrustZone, qui fait partie de l'architecture Armv8-M (et versions ultérieures). Des solutions avec des microcontrôleurs multicœurs sont également disponibles.

Cet article montre comment les développeurs peuvent utiliser les processeurs multicœurs pour sécuriser leurs solutions embarquées. Plus précisément, il présente le microcontrôleur sécurisé PSoC 64 de Cypress et les outils associés pour mettre en œuvre une solution sécurisée.

Principes fondamentaux de la sécurité embarquée

L'un des principes fondamentaux de la conception d'un produit sécurisé consiste à tirer parti de l'isolation matérielle. Cette isolation peut prendre de nombreuses formes, telles qu'un environnement d'exécution isolé ou une mémoire isolée basée sur une unité de protection de la mémoire (MPU). Au niveau le plus élevé, un microcontrôleur doit être capable de diviser son environnement d'exécution en un environnement de traitement sécurisé (SPE) et un environnement de traitement non sécurisé (NSPE).

Un SPE est un environnement d'exécution isolé dont la mémoire, les composants et le code d'application sont séparés du NSPE. Le SPE peut être considéré comme un processeur de sécurité. Le SPE exécute un code et des opérations sécurisés, tels qu'un système d'exploitation sécurisé et/ou une racine de confiance (RoT). Le SPE exécute également des services de confiance tels que la cryptographie, le stockage sécurisé, l'attestation et la journalisation sécurisée. Un nombre limité d'applications de confiance liées à des opérations sécurisées sera exécuté dans le SPE.

Le NSPE, quant à lui, peut être considéré comme l'environnement d'exécution riche en fonctionnalités qui exécute tout, sauf les opérations sécurisées. Le NSPE est en fait le modèle de programmation familier auquel la plupart des développeurs embarqués sont habitués ; il comporte un RTOS et la plupart des composants de l'application.

L'isolation matérielle est l'un des principes fondamentaux (ou meilleures pratiques), fournis par l'architecture Arm® Platform Security Architecture (PSA) pour construire des systèmes sécurisés. Les différentes couches d'isolation dont nous venons de parler sont illustrées à la Figure 1, avec le PSoC 64 comme exemple. Dans cet exemple, le SPE et le NSPE (1) produisent une isolation matérielle en ayant les environnements d'exécution sur des processeurs séparés. En plus de la séparation des environnements d'exécution, la racine de confiance et les services de confiance sont davantage isolés (2). Enfin, chaque application de confiance dans le SPE est également isolée à l'aide d'outils tels que les partitions de confiance et les unités MPU (3).

Figure 1 : Une application sécurisée utilise l'isolation matérielle pour séparer les environnements d'exécution. 1) Les environnements NSPE et SPE sont isolés 2) La racine de confiance et les services de confiance sont isolés 3) Les applications de confiance sont isolées. (Source de l'image : Arm/Cypress)

Le PSoC 64 est un microcontrôleur à double cœur où le NSPE est exécuté sur un processeur Arm Cortex®-M4, et le SPE sur un processeur Arm Cortex-M0+. Le processeur Arm Cortex-M0+ exécute toutes les fonctions de sécurité et peut communiquer avec le processeur Cortex-M4 par le biais d'un bus de communication interprocesseur (IPC). L'architecture limite l'accès au SPE, qui est isolé matériellement.

Pour commencer à utiliser le PSoC 64, les développeurs peuvent se tourner vers le kit PSoC 64 Secure Boot Pioneer Kit.

PSoC 64 Secure Boot Pioneer Kit

Le PSoC 64 Secure Boot Pioneer Kit (Figure 2) contient tout ce dont les développeurs ont besoin pour commencer à sécuriser leurs applications. Tout d'abord, il comprend un module PSoC 64 qui contient le microcontrôleur PSoC 64, la mémoire externe et tous les circuits de support (indiqués en rouge). La mémoire externe peut être utilisée pour stocker le code d'application ou pour stocker les nouvelles images de micrologiciel pour les mises à jour sécurisées à distance FOTA (Firmware-Over-The-Air).

Figure 2 : Le PSoC 64 Secure Boot Pioneer Kit offre tout ce dont les développeurs ont besoin pour commencer à développer des applications IoT sécurisées. (Source de l'image : Cypress)

Il comprend également un module Wi-Fi qui permet aux développeurs de connecter la carte à un réseau. Le module Wi-Fi est particulièrement utile pour les applications IoT où la carte doit être connectée à des services cloud comme AWS ou Azure. La carte de développement prend en charge Amazon FreeRTOS, dont nous parlerons dans la section suivante.

Enfin, le kit Pioneer prend en charge un large éventail de capacités d'extension telles que des embases mâles, des embases Arduino et une variété de capteurs. Les développeurs peuvent utiliser le curseur tactile intégré et les boutons tactiles, les boutons-poussoirs, le potentiomètre, et bien plus encore. La carte est également configurée de manière à faciliter la personnalisation pour la plupart des applications.

Suite logicielle sécurisée PSoC 64

La conception d'une application embarquée sécurisée peut être longue et difficile. Les développeurs doivent rechercher des solutions qui permettent de réduire les coûts et les délais de mise sur le marché tout en garantissant la sécurité de leur application. À cette fin, le PSoC 64 fournit une large gamme de logiciels permettant aux développeurs de créer rapidement une application sécurisée.

Par exemple, CySecureTools fournit aux développeurs un ensemble d'outils pour créer des clés et des certificats, ainsi que des outils pour signer les applications utilisateur et provisionner les microcontrôleurs Cypress. L'outil permet aux développeurs de transférer la racine de confiance Cypress, puis d'injecter leurs propres actifs de sécurité. Des informations sur la configuration et l'utilisation de CySecureTools sont disponibles dans le fichier README du référentiel github.

Un outil que les développeurs IoT trouveront utile est la prise en charge pour AWS avec FreeRTOS. Le référentiel github contient des exemples utiles pour utiliser FreeRTOS et AWS avec le PSoC 64. Le premier exemple pouvant intéresser les développeurs est l'application « Hello World » qui transmet des messages MQTT du PSoC 64 au cloud AWS. Cet exemple permet au développeur de découvrir le processus de provisionnement, la génération de clés et les phases de déploiement. À la fin de l'exemple, les développeurs ont un dispositif embarqué sécurisé connecté à AWS. Des informations pour démarrer sont disponibles dans le guide Getting Started with CY8CKIT-064S0S204343.

Applications sécurisées avec Trusted Firmware-M (TF-M)

Le PSoC 64 fournit aux développeurs une structure de sécurité immédiate qui peut être facilement personnalisée pour une application. Les développeurs peuvent trouver utile de comprendre ce qui se passe en coulisses du point de vue logiciel. Plus précisément, le micrologiciel PSoC 64 exploite une structure de sécurité de base open-source, connue sous le nom de Trusted Firmware-M, ou TF-M.

TF-M est une implémentation de référence de la structure de sécurité IoT Arm PSA. Elle fournit aux développeurs des outils de sécurité utiles tels que l'attestation des dispositifs, la vérification des micrologiciels, des services cryptographiques, la gestion des secrets des dispositifs et le partitionnement sécurisé, pour n'en citer que quelques-uns. Cypress a tiré parti de TF-M pour créer sa structure de sécurité, que les développeurs peuvent ensuite utiliser dans leurs applications.

Les développeurs peuvent modifier leur structure de sécurité en ajoutant leur propre code, des profils de sécurité, et bien plus encore. Toutefois, il est important de garder à l'esprit que plus le logiciel SPE est modifié, plus la probabilité d'ajouter une faille de sécurité est élevée. Les développeurs doivent soigneusement évaluer les risques associés aux changements, aux ajouts ou aux suppressions apportés au micrologiciel de base.

Conseils et astuces pour sécuriser les applications embarquées

Les développeurs qui cherchent à sécuriser leurs applications embarquées pour la première fois ont beaucoup d'éléments à prendre en compte. Voici quelques conseils et astuces qui peuvent simplifier et accélérer le développement :

• Effectuez une analyse de sécurité et de modèle de risque (TMSA) dès le début du cycle de développement.
• Utilisez une carte de développement pour tester la racine de confiance du dispositif, le chargeur d'amorçage sécurisé, le processus de provisionnement du dispositif et les mises à jour micrologicielles.
• N'implémentez pas la sécurité sans aide ! Tirez parti des piles micrologicielles sécurisées et open-source existantes afin de réduire les efforts de retravail.
• Veillez à bien réfléchir au cycle de vie du dispositif, notamment à la manière dont il sera mis hors service en toute sécurité.
• Explorez des outils tels que CySecureTools ; de tels outils sont accompagnés de modèles de sécurité, de logiciels et d'exemples.
• Lorsque vous clonez le référentiel github FreeRTOS, clonez la dernière version balisée. Le clonage de la ligne principale active permet souvent de découvrir des incompatibilités d'outils et des bogues qui sont toujours en cours.
• Commencez un projet en parcourant le guide de démarrage du kit Cypress CY8CKIT-064S0S2-4343W. Il fournit toutes les informations nécessaires pour le fonctionnement d'une application de base qui peut ensuite être modifiée en fonction des besoins spécifiques du produit.

Les développeurs qui suivent ces « conseils et astuces » constateront qu'ils économisent beaucoup de temps et d'efforts.

Conclusion

La sécurité ne doit pas être un défi complexe. Les développeurs de produits embarqués doivent pouvoir se concentrer sur les éléments différenciateurs de leurs produits, leur sauce secrète. Dans la plupart des cas, il ne s'agit pas de la sécurité. Cet article a exploré comment le PSoC 64 peut aider les développeurs à sécuriser rapidement leurs applications en fournissant non seulement un environnement d'isolation basé sur le matériel, mais également une structure d'outils logiciels. Ensemble, les solutions matérielles et logicielles offrent aux développeurs un cycle de développement de sécurité accéléré.