Auteur : Giancarlo Parodi, ingénieur principal, Renesas Electronics
La croissance des appareils capables de connectivité implique un besoin accru de sécuriser à la fois les canaux de communication et tout stockage local que l'appareil peut utiliser, afin de protéger la confidentialité et l'intégrité des données des utilisateurs. Par conséquent, un développeur d'appareils embarqués doit réfléchir à la manière d'implémenter la fonctionnalité requise pour les besoins des utilisateurs actuels et de rendre l'implémentation pérenne pour répondre aux exigences futures de manière rentable. Une feuille de route de sécurité doit trouver le juste équilibre entre la prise en compte de l'approche actuelle (et héritée), rendre la mise en œuvre compatible avec le cycle de vie de l'équipement final et être ouverte aux améliorations qui pourraient survenir à l'avenir.
L'un des aspects les plus difficiles est la gestion des clés cryptographiques des utilisateurs, dès la phase de production et plus tard sur le terrain, car ce sont les actifs les plus sensibles à protéger, du point de vue de l'utilisateur final. Cet article décrit comment Renesas peut aider ses clients à relever ces défis de manière simple et rentable.
Les clés doivent être protégées dans divers scénarios de menace : pendant l'installation sur le système, pendant l'utilisation, lorsqu'elles sont stockées sur l'appareil et après la mise au rebut de l'équipement. Pour faciliter toutes ces exigences, il est très avantageux que le microcontrôleur comprenne un sous-système dédié conçu pour prendre en charge de manière autonome tous ces aspects. Heureusement, c'est le cas de la famille de microcontrôleurs RA, qui comprend le Secure Crypto Engine (SCE).
Le sous-système sécurisé défini par SCE (illustré à la figure 1) fournit une fonctionnalité d'élément sécurisé comparable avec des performances bien supérieures en tant que solution intégrée, réduisant le coût de la nomenclature et simplifiant l'intégration à la fois dans la phase de développement et dans la production. Il prend en charge AES, RSA, ECC, le hachage et la génération de nombres aléatoires réels dans un environnement isolé sur puce. En plus de cela, le SCE permet le stockage sécurisé de clés illimitées à l'aide d'une clé matérielle unique (HUK) 256 bits programmée en usine pour dériver des "clés de chiffrement de clé", qui à leur tour peuvent être utilisées pour encapsuler (chiffrer) toute clé client prise en charge. taper. Le sous-système cryptographique Secure Crypto Engine (SCE9) est complètement contenu et isolé dans le MCU, et protégé par un circuit de gestion d'accès qui arrête le fonctionnement du moteur cryptographique lors de la détection de tentatives d'accès illégales. Le SCE effectue toutes les opérations cryptographiques en clair à l'aide de sa propre zone de stockage interne dédiée, à laquelle il n'est pas possible d'accéder via un processeur ou un bus accessible par DMA. Les capacités avancées de stockage et de gestion des clés de SCE9 peuvent garantir que les clés en texte brut ne sont jamais exposées ou stockées dans la RAM accessible au processeur ou dans la mémoire externe non volatile.
La famille de microcontrôleurs RA inclut le SCE dans tous les groupes capables de connectivité, tels que les dérivés RA6 et RA4. Le RA6M4 est le premier MCU de la famille RA de la nouvelle génération de MCU axés sur la sécurité de Renesas. Les fonctionnalités de sécurité de pointe combinées aux meilleurs périphériques IP de leur catégorie et à la compatibilité des broches et des fonctionnalités dans toute la série de microcontrôleurs font des microcontrôleurs de la famille RA le choix optimal pour presque tous les produits embarqués connectés.
Tous les microcontrôleurs Renesas prennent en charge la programmation en usine via des interfaces série et USB en tant que mécanisme de production de masse fiable et peu coûteux. En plus de cela, la fonctionnalité intégrée du RA6M4 et des séries de microcontrôleurs suivantes permet aux utilisateurs de mettre en œuvre un provisionnement de clé sécurisé via la même interface de programmation. Le micrologiciel de démarrage MCU prend en charge un protocole de commande dédié pour transmettre une clé d'installation choisie et une charge utile chiffrée (la clé d'application est injectée) à la limite SCE ; la clé d'application est générée dans un format encapsulé unique au MCU qui peut être stocké en toute sécurité dans une mémoire non volatile.
Étant donné que la clé d'installation de la clé et la clé de l'application utilisateur sont chiffrées, il n'est pas nécessaire d'utiliser un module de sécurité matériel (HSM) ou un service de programmation sécurisé pour l'injection de la clé utilisateur en production . Renesas fournit un service « hors ligne » gratuit à tous ses clients pour générer la charge utile de données clés installée en usine, via une infrastructure dédiée appelée serveur de gestion du cycle de vie des appareils (DLM). Toute la communication entre l'utilisateur et le serveur est sécurisée et cryptée via PGP ; notamment, la clé d'application n'est à aucun moment exposée au serveur DLM lui-même.
L'application utilisateur peut tirer parti de la capacité SCE via des pilotes cryptographiques dédiés, inclus dans le progiciel flexible Renesas (FSP). Le FSP est un progiciel amélioré conçu pour fournir un logiciel de haute qualité, évolutif et facile à utiliser pour les conceptions de systèmes embarqués utilisant des microcontrôleurs RA. Prend en charge Arm® TrustZone®, des fonctionnalités de sécurité avancées, fournit des contrôleurs hautes performances prêts pour la production, à faible mémoire, intègre des piles middleware telles qu'Azure® RTOS, FreeRTOS™, ce qui facilite le déploiement de modules complexes pour la communication et la sécurité.
Quant aux drivers SCE en particulier, ils implémentent deux modes de fonctionnement, appelés "mode compatibilité" et "mode protégé".
Mode de compatibilité
L'une des principales raisons de leur existence est que de nombreux systèmes hérités nécessitent de gérer des clés en texte clair, ou que les implémentations réelles doivent s'intégrer à différentes piles et bibliothèques qui ne gèrent pas nativement les clés encapsulées (parfois appelées "blobs de clés"). . Le SCE est flexible et peut prendre en charge le fonctionnement des touches en texte brut en permettant au logiciel d'application d'importer une clé en texte brut à la limite du SCE. Après cette étape, l'application peut stocker en toute sécurité la version de la clé compressée en mémoire, réduisant ainsi l'exposition de la clé. En ce sens, les fonctions de stockage sécurisé et d'emballage de clé de SCE deviennent transparentes pour l'application de l'utilisateur final et permettent une intégration transparente avec les systèmes hérités ou tout logiciel et solution tiers, tout en offrant ses performances illimitées et ses avantages de stockage de clé sécurisé. Le logiciel d'application peut utiliser le texte brut ou les clés encapsulées via les API PSA Crypto et MbedCrypto.
Le stockage sécurisé des clés est pratiquement illimité, car n'importe quel emplacement de programme ou de flash de données disponible sur les MCU peut être choisi comme emplacement de stockage. Dans le même temps, la clé matérielle unique impliquée dans le processus d'encapsulation empêche le clonage et la copie illicites de clés.
Dans ce mode de fonctionnement, l'utilisateur a également la possibilité de générer des clés encapsulées (aléatoires) sur le MCU lui-même. Cela pourrait être intéressant pour chiffrer les données locales du MCU (par exemple). De plus, la prise en charge des clés en texte brut pourrait faciliter l'intégration aux systèmes de programmation existants.
D'autre part, le développeur doit évaluer la menace de falsification des clés en clair sur le système, en particulier pendant le fonctionnement, car le contenu de la clé sera exposé en dehors des limites du SCE. Ce risque affecte à la fois le fonctionnement du logiciel et toute mise à jour ultérieure des clés, lorsqu'un code malveillant pourrait exploiter les faiblesses des logiciels existants pour obtenir les données clés.
mode protégé
Cela fournit une amélioration significative de la sécurité au niveau du système et de la gestion sécurisée des clés, en mettant en œuvre une approche basée sur les meilleures pratiques. Dans ce mode, seules les clés encapsulées nativement sont autorisées et le système ne prend pas en charge le fonctionnement des clés en texte brut. Cela élimine complètement l'exposition des clés du processeur, du DMA ou d'autres interfaces de bus système et réduit considérablement la surface d'attaque.
Comme en mode de compatibilité, le SCE peut générer des clés encapsulées (locales).
Les clés d'utilisateur connues peuvent être installées en toute sécurité par un programmeur de périphérique interagissant avec le micrologiciel de démarrage sur puce, permettant un provisionnement sécurisé des clés en production. Ces clés sont stockées en toute sécurité dans un format encapsulé et peuvent être utilisées directement dans l'application. La même interface peut être utilisée pour installer en usine des clés de mise à jour de clé, c'est-à-dire des clés que le logiciel d'application peut utiliser pour mettre à jour et mettre à jour en toute sécurité les clés d'application sur le terrain. Cela signifie à son tour qu'il n'y a aucune dépendance vis-à-vis du service du serveur DLM une fois la programmation initiale en usine terminée.
En plus de cela, le mode protégé permet diverses contre-mesures pour protéger le système contre les attaques d'analyse de puissance simples et différentielles (appelées SPA et DPA). De telles attaques impliquent que l'opérateur ait un accès physique au système (une telle menace peut être atténuée par d'autres politiques de sécurité, en fonction de l'environnement d'exploitation), mais elles deviennent moins chères et plus rapides à mettre en œuvre et il est donc important de s'en protéger.
De même, des contre-mesures contre les attaques de synchronisation sont mises en œuvre pour les opérations de chiffrement ECC et RSA, qui sont traitées en temps constant lorsqu'elles traitent de matériel de clé sensible (pour éviter les fuites de canal latéral de synchronisation).
Le mode protégé SCE est accessible à l'aide du module "FSP Crypto" dans un format autonome, dans le cadre du package FSP. Bien que l'intégration avec les systèmes et logiciels existants puisse nécessiter une refonte architecturale, il convient de considérer les avantages offerts par le mode de fonctionnement protégé.
Pour les applications qui souhaitent utiliser l'implémentation Trusted Firmware-M (TF-M) d'un environnement de traitement sécurisé pour les architectures Arm® Cortex®-M33, le mode de compatibilité SCE peut être utilisé en combinaison avec la cryptographie PSA et s'intègre de manière transparente à l'exosystème ARM PSA existant Logiciel. Cette intégration est fournie dans le cadre du package FSP.
De plus, le FSP peut utiliser le mode de compatibilité pour s'intégrer à Amazon FreeRTOS, y compris la prise en charge de MbedTLS, ou la prise en charge d'Azure RTOS et NetX Duo.
D'autres solutions de connectivité, telles que la pile de bibliothèques SSL/TLS intégrée WolfSSL prise en charge commercialement, peuvent tirer parti du fonctionnement en mode protégé et sont actuellement en cours de développement.
En bref, les solutions Renesas peuvent prendre en charge n'importe quelle feuille de route de sécurité des applications, de la prise en charge des systèmes existants et hérités à la fourniture de la base d'un chemin de sécurité amélioré pour une protection optimale des actifs et des applications des utilisateurs.
Le logiciel et la fonctionnalité décrits sont disponibles dans la famille de microcontrôleurs RA, à commencer par le microcontrôleur RA6M4 et les prochains microcontrôleurs basés sur Cortex-M33 des séries RA6 et RA4.
