Ajout d'un élément de sécurité afin d'établir une sécurité périphérie-à-cloud dans une conception IoT

La cybersécurité demeure un problème universel lors de la conception et du déploiement de tout système connecté au réseau Internet public. Dans le domaine de l'Internet des objets (IoT), les problèmes de sécurité sont particulièrement sérieux, car les utilisateurs commencent à douter de la capacité des dispositifs connectés à prendre en charge de façon sécurisée les applications présentes dans les maisons, les usines ou les villes intelligentes. Pourtant, face à des calendriers de livraison plus serrés, les développeurs de dispositifs IoT ont souvent le sentiment qu'ils ne peuvent pas se permettre les ressources de dispositif, et encore moins le temps supplémentaire nécessaire par le passé pour implémenter l'ensemble complet de capacités requises pour une solution de sécurité efficace.

Les fournisseurs de semi-conducteurs participent à la recherche d'un équilibre en proposant des solutions de sécurité plus simples à déployer. Cet article traite du problème de la sécurité avant de présenter une telle solution proposée par NXP Semiconductors, à savoir l'élément de sécurité (Secure Element, SE) EdgeLock SE050. Il présente ensuite aux développeurs la manière d'utiliser ce dispositif monopuce afin de rapidement implémenter une sécurité périphérie-à-cloud dans leurs dispositifs IoT.

Le problème de la sécurité IoT

Les dispositifs IoT mal sécurisés se sont malheureusement révélés être des cibles privilégiées pour les cyberattaques. Une fois compromis, les dispositifs peuvent divulguer des données utilisateur confidentielles ainsi que fournir de précieuses informations nécessaires à la génération de copies contrefaites des dispositifs. Les pirates informatiques peuvent également utiliser ces dispositifs vulnérables pour faire des ravages plus importants, en s'enfonçant encore plus profondément dans les réseaux afin d'atteindre d'autres dispositifs, systèmes et ressources d'entreprise connectés. Ainsi, les effets des dispositifs IoT compromis se répercutent sur les différents niveaux de la hiérarchie IoT, menaçant jusqu'à la sécurité publique dans les applications IoT émergentes telles que l'immotique, les systèmes industriels, les transports et les dispositifs médicaux.

Pour les développeurs devant offrir des conceptions IoT plus efficaces, la sécurité peut prendre la forme d'un ajout inopportun sur une liste croissante d'exigences déjà dominée par des demandes de performances supérieures et de consommation énergétique réduite. En réalité, une sécurité efficace est basée sur une liste croissante d'exigences nécessaires afin de réduire les menaces depuis la périphérie jusqu'au cloud.

Appliquées individuellement, même des techniques familières telles que le cryptage et l'authentification sont insuffisantes en elles-mêmes. La sécurité IoT doit reposer sur une base sécurisée conçue pour garantir que les mécanismes et protocoles de sécurité sont protégés des pirates informatiques. En même temps, les méthodes de sécurité doivent être de plus en plus appliquées selon une granularité plus fine afin de protéger non seulement les connexions entre dispositifs IoT, mais également celles entre les composants d'une conception IoT individuelle.

L'élément de sécurité EdgeLock SE050 de NXP est spécialement conçu pour offrir l'éventail de mécanismes et protocoles de sécurité nécessaire pour établir une sécurité périphérie-à-cloud dans des dispositifs IoT.

Une solide solution de sécurité

Conçu comme une solution prête à l'emploi pour la sécurité des dispositifs IoT, le SE050 de NXP s'appuie sur la vaste expérience de NXP dans le domaine de la sécurité des cartes à puce pour offrir une base matérielle fiable aux conceptions IoT. Le dispositif associe un microcontrôleur dédié et un dispositif de stockage d'identifiants sécurisé à une pile logicielle basée sur le système d'exploitation de cartes à puce JCOP (Java Card OpenPlatform). Certifiée de manière indépendante jusqu'au niveau du système d'exploitation selon les critères communs (CC) de niveau 6 renforcé (EAL 6+) du système d'évaluation Evaluation Assurance Level (EAL), la plateforme opérationnelle du SE050 propose un niveau rare de garantie pour un fonctionnement dans des environnements très risqués (Figure 1).

Figure 1 : Parmi les produits certifiés, la plateforme SE050 offre un niveau rare de garantie avec sa certification jusqu'au niveau du système d'exploitation selon les critères communs EAL 6+. (Source des données : Critères communs)

Optimisé pour fonctionner sur cette solide plateforme de sécurité, un applet de sécurité IoT NXP dédié utilise une bibliothèque cryptographique intégrée pour prendre en charge un ensemble complet d'algorithmes cryptographiques, notamment :

• La cryptographie symétrique à l'aide des algorithmes AES (Advanced Encryption Standard) et DES (Data Encryption Standard)
• La cryptographie asymétrique à l'aide des algorithmes RSA (Rivest–Shamir–Adleman) et ECC (Elliptic-Curve Cryptography), avec la prise en charge d'un certain nombre de courbes ECC, notamment les courbes standard précisées par le NIST (National Institute of Standards and Technology)
• De nombreuses fonctions de hachage utilisées dans l'élaboration de codes MAC (code d'authentification de message)
• De nombreux algorithmes KDF (fonction de dérivation de clés) utilisés pour le hachage de mots de passe, l'accord de clé et le renforcement de clé, entre autres méthodes

Pour accélérer les performances, le dispositif SE050 intègre des accélérateurs matériels destinés à la cryptographie AES (Advanced Encryption Standard), DES (Data Encryption Standard) et FAME (Fast Attribute-based Message Encryption).

Afin de protéger les identifiants utilisés lors des opérations cryptographiques, le dispositif propose jusqu'à 50 Ko de mémoire Flash utilisateur sécurisée et il contient déjà des clés racine conçues pour prendre en charge les transactions IoT typiques. Les développeurs à l'origine d'une grande quantité de conceptions peuvent également tirer parti de clés personnalisées et d'identifiants fournis de manière sécurisée par NXP ou des fournisseurs tiers autorisés.

En plus de sa mémoire Flash embarquée, le dispositif permet d'accéder à une mémoire vive (RAM) afin de stocker des certificats publics, par exemple, tandis que les clés privées associées restent dans la mémoire Flash sécurisée. En outre, l'applet IoT SE050 inclut une capacité sécurisée d'importation/exportation qui permet aux développeurs de stocker en toute sécurité des clés ou des données arbitraires sur une mémoire externe. Toutefois, le dispositif utilise une unité de gestion de la mémoire qui autorise l'accès à différentes parties de la mémoire uniquement à l'applet IoT, évitant ainsi tout accès non autorisé par l'intermédiaire du microcontrôleur. Pour une protection supplémentaire contre les effractions et les attaques sophistiquées par canaux auxiliaires, le dispositif intègre également de nombreuses barrières logiques et physiques visant à empêcher tout accès non autorisé.

Cependant, la sécurité concerne aussi bien l'accès des dispositifs autorisés que la mise en place d'obstacles destinés à éviter tout accès non autorisé.

Authentification du dispositif

En servant de base sécurisée aux dispositifs IoT, les mécanismes cryptographiques et les capacités de stockage sécurisé du SE050 prennent directement en charge les connexions sécurisées destinées aux communications, par l'intermédiaire d'hôtes distants autorisés tels que des serveurs cloud. En effet, ces mêmes capacités permettent aux développeurs de garantir l'authenticité des connexions aux niveaux les plus bas de la hiérarchie IoT entre des dispositifs IoT distincts basés sur des éléments de sécurité SE050.

L'utilisation d'une méthode semblable à l'authentification Internet conventionnelle permet à un capteur IoT intelligent de s'authentifier lui-même sur un dispositif de contrôle IoT, par exemple. Ce processus commence par l'envoi du certificat stocké dans l'espace sécurisé du SE050, du dispositif de détection vers le dispositif de contrôle. Le dispositif de contrôle valide à son tour le certificat reçu à l'aide des fonctionnalités cryptographiques du SE050. Après la validation, le dispositif de contrôle renvoie au dispositif de détection une valeur aléatoire, appelée une demande d'accès. À son tour, le dispositif de détection utilise son élément de sécurité SE050 pour valider la demande d'accès à l'aide de la clé privée associée au certificat précédemment envoyé au dispositif de contrôle. Cette demande d'accès ne pouvant être validée qu'à l'aide de la clé publique associée, le dispositif de contrôle est assuré que le dispositif de détection à l'origine de l'envoi initial du certificat est véritablement le propriétaire de ce dernier. Ainsi, le dispositif de contrôle peut authentifier de manière fiable le dispositif de détection.

En inversant les rôles dans le même processus, le dispositif de contrôle peut à l'inverse s'authentifier sur le capteur.

Ce type de processus d'authentification mutuelle est essentiel à la construction de réseaux IoT de confiance, en particulier avec l'apparition de couches intermédiaires supplémentaires comprenant des dispositifs d'edge computing. Bien que le processus d'authentification mutuelle soit simple, même de petites erreurs d'implémentation ou des interprétations différentes du protocole peuvent entraîner de graves défauts de sécurité. Dans les conceptions IoT aux ressources limitées, notamment, la nécessité d'un stockage sécurisé et d'une exécution rapide des algorithmes cryptographiques complexes peut compliquer davantage l'obtention d'une implémentation fiable. En ajoutant le SE050 à une conception IoT, les développeurs peuvent implémenter des fonctionnalités de sécurité essentielles, telles que l'authentification mutuelle, sans compromettre les performances ou la sécurité de la conception générale.

Intégration simple et sécurisée

Il est possible de compléter les capacités avancées du SE050, tout en conservant la simplicité de conception. Les développeurs peuvent facilement intégrer le dispositif à leurs conceptions matérielles IoT avec une incidence minimale sur la complexité ou l'empreinte de la conception. Conçu pour servir de dispositif complémentaire, le dispositif de 3 mm x 3 mm offre un ensemble simple d'interfaces série (Figure 2).

Figure 2 : L'élément de sécurité SE050 de NXP offre plusieurs interfaces, permettant son utilisation en tant qu'esclave I²C pour des connexions à des microcontrôleurs hôtes, en tant que maître I²C pour des connexions à des capteurs numériques basées sur la norme ISO 7816 et en tant qu'interface sans contact NFC (communication en champ proche) conforme à la norme ISO 14443. (Source de l'image : NXP)

Pour communiquer avec le microcontrôleur hôte, le dispositif agit en tant qu'esclave I²C. Le SE050 peut également agir en tant que maître I²C pour des connexions basées sur la norme ISO 7816 vers un autre périphérique série, tel qu'un capteur numérique. Le dispositif prend également en charge une troisième interface pour une connectivité sans contact NFC conforme à la norme ISO 14443.

Pour ses différentes connexions, l'applet IoT du SE050 orchestre des clés sécurisées et des règles de contrôle d'accès afin de définir et gérer des sessions pour chaque connexion.

Pour communiquer avec l'hôte, le SE050 offre une authentification basée sur une session conçue pour éviter toute interception des commandes et données I²C et l'utilisation d'attaques de l'intercepteur. Pour initier une session de connexion série, les développeurs peuvent s'authentifier à l'aide d'un identifiant utilisateur, qui fonctionne comme un mot de passe ou un numéro d'identification personnel (PIN).

Une authentification élémentaire basée sur mot de passe entre le microcontrôleur et le SE050 n'est pas toujours suffisante pour certaines applications. Pour les applications cruciales, les développeurs peuvent vouloir s'assurer que les communications entre le microcontrôleur hôte et l'élément de sécurité SE050 restent confidentielles afin d'éviter les attaques qui reproduisent des sessions, envoient des fragments de session hors service ou remplacent des algorithmes cryptographiques par des versions piratées destinées à récolter des données confidentielles.

Transactions de bus sécurisées

Grâce à l'élément de sécurité SE050, les développeurs peuvent utiliser des méthodes d'authentification afin de créer un canal de communication sécurisé entre le SE050 et le microcontrôleur hôte. Les développeurs peuvent alors utiliser le support de circuit intégré du SE050 conformément à la norme SCP (Secure Channel Protocol) SCP03 largement utilisée pour sécuriser les communications bidirectionnelles entre un périphérique Java Card et un hôte.

Pour les conceptions basées sur microcontrôleur intégrant l'élément de sécurité SE050, l'utilisation du protocole SCP03 permet essentiellement de lier l'élément de sécurité SE050 au microcontrôleur hôte durant l'authentification de la session de bus I²C, permettant ainsi également l'utilisation de messages cryptés lors de la session. Pour le cryptage de messages au sein du protocole SCP03, le message en texte brut est d'abord crypté à l'aide de l'algorithme AES, puis un code d'authentification de message (MAC) est généré pour le message crypté. En envoyant le message crypté et le code d'authentification de message associé, cette méthode appelée « encrypt-then-MAC » protège le message crypté et permet au destinataire de détecter les modifications apportées au message.

Le SE050 étend également une forme de protection jusqu'aux données du capteur. Les développeurs peuvent alors demander au SE050 d'intensifier les réponses aux commandes de l'hôte à l'aide de métadonnées de certification, notamment un identifiant unique, des données d'actualisation sous la forme d'une valeur aléatoire pour chaque instance, un horodatage et une signature. Au sein de l'hôte, le logiciel peut examiner les données de certification envoyées par le SE050 afin de valider la source et l'exactitude des données provenant des capteurs connectés à l'interface maître I²C du SE050.

Comme les données de capteurs individuels et combinées en flux escaladant la hiérarchie IoT, les applications peuvent utiliser ces données de certification pour identifier la source des séquences de données inhabituelles pouvant signaler des capteurs altérés, défaillants ou compromis. Grâce aux sessions hôtes SCP03 et à la certification des données de capteurs, les développeurs peuvent collecter de manière fiable et sûre les données de capteurs essentielles pour les applications stratégiques.

Interface fonctionnelle

Les demandes et réponses liées à la certification, ainsi que toutes les interactions entre le microcontrôleur hôte et l'élément de sécurité SE050, circulent dans une pile de communication définie par les normes d'interface fonctionnelle ISO 7816 relatives aux dispositifs de cartes à puce (Figure 3). Cette norme APDU (Application Protocol Data Unit) définit le format, le contenu et le protocole pour un échange de messages entre un périphérique hôte (HD) et un élément de sécurité (SE).

Figure 3 : Communications entre un élément de sécurité SE050 de NXP et un périphérique hôte par l'intermédiaire d'une pile de cartes à puce conforme à la norme ISO 7816, et comprenant des demandes et réponses au niveau de l'application à l'aide de la norme APDU ISO 7816, transmises par une couche liaison de données grâce au protocole semi-duplex T=1 ISO 7816-3 via I²C. (Source de l'image : NXP)

Basée sur la couche physique I²C, la couche liaison de données décompose les demandes et les réponses de la couche d'application en une séquence de transactions suivant le protocole T=1 ISO 7816-3 via I²C pour une communication semi-duplex. Dans ce protocole, la couche liaison de données sur le périphérique hôte et sur l'élément de sécurité attend une confirmation après chaque transmission dans une séquence de transaction.

À titre d'exemple, pour une demande de lecture émise par l'application hôte, la couche liaison de données de l'hôte commence par interroger l'élément de sécurité puis attend une réponse de confirmation (ACK), indiquant que l'élément de sécurité est prêt à transmettre (Figure 4).

Figure 4 : La couche liaison de données traite les demandes du périphérique hôte, notamment la demande de lecture illustrée ici sous la forme d'une série de transactions conforme au protocole T=1 via I²C, en commençant par une boucle d'interrogation qui répète la demande jusqu'à recevoir une réponse de confirmation (ACK) indiquant que l'élément de sécurité est prêt à transmettre des données. (Source de l'image : NXP)

Suite à la réponse ACK indiquant que l'élément est prêt, la couche liaison de données dans l'élément de sécurité envoie des données à l'hôte sous la forme d'une séquence de transferts de blocs de données, puis attend une confirmation de la part de la couche liaison de données de l'hôte pour chaque transfert de bloc (Figure 5). Enfin, la réponse complète est fournie à l'application hôte.

Figure 5 : Après avoir indiqué être prêt à envoyer des données, l'élément de sécurité envoie une réponse de données sous la forme d'une séquence de blocs de données, puis attend une confirmation de la part du périphérique hôte avant d'envoyer le bloc suivant dans la séquence. (Source de l'image : NXP)

Implémentation logicielle

Au niveau de l'application, les échanges entre le microcontrôleur hôte et l'élément de sécurité SE050 se déroulent selon la norme APDU ISO 7816. Pour le SE050, les APDU relatifs aux commandes et réponses sont basés sur le format TLV (Tag, Length, Value) défini par la norme ISO 7816-4. Chaque APDU se compose au minimum d'un octet CLA (classe) (une valeur fixe pour toutes les opérations SE050), d'un octet INS (instruction) et de deux octets de paramètre (P1, P2). Les demandes de données et les réponses peuvent également inclure des champs supplémentaires pour le nombre d'octets à lire (Le), la longueur du champ de données (Lc) et le champ de données.

À titre d'exemple, une demande de lecture par l'application hôte utiliserait une paire de TLV pour configurer l'interface I²C du SE050 et réaliser la demande de lecture (Liste 1). Comme indiqué précédemment, la couche liaison de données hôte décomposerait cette demande en une série de transactions de bus I²C conformément au protocole T=1.

Copier static smStatus_t i2cm_Read( ex_sss_boot_ctx_t *pCtx, uint8_t *readbuf, uint32_t readLength) { smStatus_t status; TLV[0].type = kSE05x_I2CM_Configure; TLV[0].cmd.cfg.I2C_addr = I2C_SENSOR_BUS_ADDRESS; TLV[0].cmd.cfg.I2C_baudRate = kSE05x_I2CM_Baud_Rate_400Khz; TLV[1].type = kSE05x_I2CM_Read; TLV[1].cmd.rd.readLength = readLength; TLV[1].cmd.rd.rdBuf = readbuf; status = Se05x_i2c_master_txn(&pCtx->session, &TLV[0], 3); return status; } 

Liste 1 : L'intergiciel Plug & Trust de NXP inclut un code source démontrant l'utilisation du format TLV ISO 7816-4 dans des commandes hôte telles que cette commande de lecture basique envoyée à l'élément de sécurité SE050 de NXP. (Source du code : NXP)

Comme l'illustre la Liste 1, le code utilise une structure C simple afin de coder les TLV pour la configuration et les demandes de lecture. Ici, chaque TLV est instancié à l'aide d'une structure SE05x_I2CM_cmd_t (Liste 2).

Copier typedef struct _SE05x_I2CM_cmd { SE05x_I2CM_TLV_type_t type; SE05x_I2CM_INS_type_t cmd; } SE05x_I2CM_cmd_t; typedef enum _SE05x_I2CM_TLV_type { kSE05x_I2CM_None = 0, kSE05x_I2CM_Configure, //kSE05x_I2CM_Security, kSE05x_I2CM_Write = 3, kSE05x_I2CM_Read, kSE05x_I2CM_StructuralIssue = 0xFF } SE05x_I2CM_TLV_type_t; typedef union _SE05x_I2CM_INS_type { SE05x_I2CM_configData_t cfg; SE05x_I2CM_securityData_t sec; SE05x_I2CM_writeData_t w; SE05x_I2CM_readData_t rd; SE05x_I2CM_structuralIssue_t issue; } SE05x_I2CM_INS_type_t; typedef struct _SE05x_I2CM_readData { uint16_t readLength; SE05x_I2CM_status_t rdStatus; /* Output. rdBuf will point to Host buffer */ uint8_t *rdBuf; } SE05x_I2CM_readData_t; 

Liste 2 : La distribution du logiciel Plug & Trust de NXP fournit des structures afin de définir le type de demande (en vert) et les paramètres de commande associés (en bleu). (Source du code : NXP)

Au sein de cette structure SE05x_I2CM_cmd_t, le membre type est défini par une enum C, SE05x_I2CM_TLV_type_t, qui énumère les valeurs possibles, notamment la valeur standard 4 pour un APDU de demande de lecture (kSE05x_I2CM_Read). Le membre cmd de la structure SE05x_I2CM_cmd_t se définit comme une union de structures. Dans le cas présent, le membre cmd est une structure rd, qui à son tour est composée de membres précisant la longueur des données demandées (readLength) et le pointeur de tampon cible (rdBuf).

Cet ensemble de définitions se résume en quelques lignes de code afin de définir le membre de type TLV[1] dans la Liste 1 pour qu'il indique une demande de lecture (kSE05x_I2CM_Read) et définir le membre cmd sur la valeur readLength et le pointeur de tampon readBuf désirés.

Support de développement

Pour simplifier le développement logiciel, NXP résume les interactions de l'hôte avec l'élément de sécurité SE050 par l'intermédiaire de son intergiciel Plug & Trust et des interfaces de programmation (API) de bibliothèques associées (Figure 6). Le service de distribution de l'intergiciel Plug & Trust de NXP associe un intergiciel à des API grâce à un ensemble d'applications d'exemple reposant sur des paquets mbed TLS, OpenSSL et autres. En outre, une interface de ligne de commande (CLI) basée sur Python permet aux développeurs d'utiliser les fonctionnalités SE050 dans un mode interactif.

Figure 6 : En plus du logiciel d'exemple, le progiciel Plug & Trust de NXP inclut un intergiciel et des API associées qui résument les détails des interactions avec le SE050 par l'intermédiaire de la pile basée sur la norme ISO 7816, qui se compose de la couche d'application APDU, T=1 sur la couche liaison de données I²C, et la couche physique I²C. (Source de l'image : NXP)

Outre le logiciel Plug & Trust de NXP, les développeurs peuvent rapidement évaluer le SE050 à l'aide du kit de développement OM-SE050ARD, qui associe un élément de sécurité SE050 et un circuit de support simple à plusieurs embases. En plus des connecteurs pour une interface I²C externe et un accès direct aux broches du SE050, la carte OM-SE050ARD inclut une embase Arduino-R3. Grâce à l'embase Arduino-R3, les développeurs peuvent facilement connecter la carte OM-SE050ARD à un certain nombre de cartes de développement, notamment les cartes d'évaluation I.MX 6ULTRALITE et FRDM-K64F de NXP.

L'utilisation des cartes d'évaluation prises en charge permet aux développeurs d'explorer rapidement des cas d'utilisation spécifiques liés à la sécurité, du point de vue du programme par l'intermédiaire des exemples de logiciel Plug & Trust, ou de façon interactive par l'intermédiaire de la CLI basée sur Python. Parmi les applications d'exemple dans la distribution du logiciel Plug & Trust, le logiciel d'exemple illustre l'ensemble du processus de lecture de données de capteur par l'intermédiaire de l'interface maître I²C du SE050. Les développeurs peuvent rapidement restaurer cette application d'exemple afin de remplacer les lectures I²C conventionnelles par des lectures d'attestation. L'utilisation de lectures d'attestation ne nécessite aucune modification de la configuration TLV indiquée dans la Liste 1. En effet, les modifications consistent essentiellement à remplacer la fonction de lecture I2C, Se05x_i2c_master_txn(), indiquée dans la Liste 1, par la version de lecture confirmée, Se05x_i2c_master_attst_txn(), ainsi que ses paramètres de fonctionnement associés.

D'autres applications d'exemple présentent l'étape ultime dans la sécurité périphérie-à-cloud – authentification et communications sécurisées grâce à des services cloud. Parmi les exemples du logiciel Plug & Trust, les développeurs peuvent trouver des instructions étape par étape relatives à l'utilisation du SE050 dans le but de fournir une authentification et des connexions sécurisées à des services cloud publics tels que Microsoft Azure, IBM Watson, AWS (Amazon Web Services) et GCP (Google Cloud Platform). La majorité des efforts impliqués dans ces exemples de connexion au cloud réside dans la création d'un compte auprès du service cloud concerné et le téléchargement de clés et de certificats (également fournis dans les routines d'exemple). L'élément de sécurité SE050 prend en charge les tâches lourdes que les développeurs doivent généralement mettre en œuvre pour garantir une connectivité cloud sécurisée.

En utilisant la pile logicielle Plug & Trust de NXP associée aux cartes de développement de NXP, les développeurs peuvent rapidement tirer pleinement parti du support complet de l'élément de sécurité SE050 destiné à la sécurité périphérie-à-cloud des dispositifs IoT.

Conclusion

Les dispositifs IoT peu sécurisés menacent d'exposer d'importants volumes de données confidentielles et peuvent se révéler des points d'accès à d'autres ressources liées. Les développeurs doivent construire leurs conceptions IoT sur une base sûre s'étendant du dispositif jusqu'au cloud et prenant en charge l'ensemble du cycle de vie du dispositif IoT. Comme indiqué, cet objectif peut être atteint en améliorant les conceptions à l'aide du SE050 de NXP. Grâce à cet élément de sécurité, les développeurs peuvent répondre aux exigences émergentes quant à une sécurité plus efficace s'étendant de la périphérie au cloud.