Utilisation d'une puce de cryptographie pour ajouter un démarrage sécurisé aux conceptions de dispositifs IoT

Malgré tous leurs efforts, les développeurs peuvent laisser les conceptions Internet des objets (IoT) exposées aux attaques par le code pourtant prévu pour maintenir la sécurité. Les pirates attaquent souvent des conceptions apparemment sécurisées en remplaçant le micrologiciel par du code compromis. Les méthodes de démarrage sécurisé peuvent atténuer ces attaques, mais il peut s'avérer difficile de les implémenter correctement.

Les développeurs ont besoin de méthodes plus simples pour implémenter le démarrage sécurisé dans le cadre d'une stratégie globale visant à garantir la sécurité des dispositifs IoT.

Cet article examine très brièvement les surfaces d'attaque fréquentes dans les conceptions de dispositifs IoT, ainsi que le rôle des méthodes de sécurité de base, notamment le stockage sécurisé des clés, le cryptage et l'authentification. L'article présente ensuite une puce de sécurité qui permet aux développeurs d'ajouter un démarrage sécurisé parmi d'autres fonctionnalités nécessaires dans une stratégie globale pour garantir la sécurité des dispositifs IoT.

Vulnérabilités des dispositifs IoT

Pour les pirates, les dispositifs IoT peuvent fournir des points d'entrée permettant de perturber les dispositifs eux-mêmes, les réseaux associés et même les applications finales qui y sont rattachées. Bien que les développeurs puissent utiliser diverses techniques pour renforcer la sécurité des réseaux et des applications, la sécurité des dispositifs IoT reste un défi en raison de la quantité limitée de mémoire et de ressources de traitement disponibles sur ces dispositifs.

Même si les développeurs utilisent des méthodes de cryptage pour protéger les données, de nombreux dispositifs sont conçus sans les fonctionnalités d'authentification sécurisées nécessaires pour empêcher les pirates d'intercepter les communications en se faisant passer pour des serveurs ou passerelles d'autorisation, ou autres dispositifs IoT. Dans certains cas, les dispositifs utilisant des méthodes d'authentification valides mais faibles peuvent être vulnérables aux exploits sophistiqués qui interceptent et réutilisent des clés de sécurité valides utilisées dans des sessions de communication apparemment privées.

Mise à jour des dispositifs IoT

Une faiblesse de sécurité encore plus critique concerne l'utilisation des capacités de mise à jour OTA (sans fil en direct) intégrées dans un nombre croissant de dispositifs IoT. Les mises à jour OTA constituent une fonctionnalité importante sur le marché IoT en évolution rapide. Les développeurs peuvent répondre à l'évolution de la demande des clients concernant de nouvelles fonctionnalités (ou corriger des bogues) en mettant à niveau le micrologiciel des dispositifs déployés. Dans un processus de mise à jour OTA classique, le dispositif IoT recherche régulièrement des mises à jour, télécharge le nouveau code dès qu'il est disponible et effectue une série d'appels système pour terminer le processus de mise à jour.

Par exemple, pour un dispositif IoT basé sur le microcontrôleur SAM D21 de Microchip Technology, le micrologiciel du dispositif inclut le code de mise à jour OTA qui télécharge l'image depuis un point d'extrémité prédéfini, et vérifie la réussite de l'opération, puis passe au nouvel ensemble micrologiciel (Liste 1). Dans cette liste du pack Advanced Software Framework de Microchip, après l'initialisation (m2m_ota_init()) du micrologiciel OTA, une routine de rappel, OtaUpdateCb(), bascule vers le nouvel ensemble micrologiciel (m2m_ota_switch_firmware()) après le téléchargement de l'image du nouveau code et une réinitialisation du système entraînant le redémarrage du microcontrôleur dans le micrologiciel mis à jour.

Copier

static void OtaUpdateCb(uint8 u8OtaUpdateStatusType ,uint8 u8OtaUpdateStatus)

{

if(u8OtaUpdateStatusType == DL_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

//switch to the upgraded firmware

m2m_ota_switch_firmware();

}

}

else if(u8OtaUpdateStatusType == SW_STATUS) {

if(u8OtaUpdateStatus == OTA_STATUS_SUCSESS) {

M2M_INFO("Now OTA successfully done");

//start the host SW upgrade then system reset is required (Reinitialize the driver)

}

}

}

<e> 

void wifi_event_cb(uint8 u8WiFiEvent, void * pvMsg)

{

case M2M_WIFI_REQ_DHCP_CONF:

{

//after successfully connection, start the over air upgrade

m2m_ota_start_update(OTA_URL);

}

break;

default:

break;

}

<e> 

int main (void)

{

tstrWifiInitParam param;

tstr1xAuthCredentials gstrCred1x    = AUTH_CREDENTIALS;

nm_bsp_init();

<e>

m2m_memset((uint8*)&param, 0, sizeof(param));

param.pfAppWifiCb = wifi_event_cb;

<e>

//Initialize the WINC Driver

ret = m2m_wifi_init(&param);

if (M2M_SUCCESS != ret)

{

M2M_ERR("Driver Init Failed <%d>\n",ret);

while(1);

}

//Initialize the OTA module

m2m_ota_init(OtaUpdateCb,NULL);

//connect to AP that provide connection to the OTA server

m2m_wifi_default_connect();

<e> 

while(1)

{

<e>

//Handle the app state machine plus the WINC event handler

while(m2m_wifi_handle_events(NULL) != M2M_SUCCESS) {

<e>

}

<e>

}

}

Liste 1 : Dans cet exemple de code OTA du pack Advanced Software Framework de Microchip, un rappel de gestionnaire d'événements Wi-Fi wifi_event_cb() lance la mise à jour OTA m2m_ota_start_update(OTA_URL) en utilisant l'URL spécifiée et passe au nouveau micrologiciel m2m_ota_switch_firmware() à la fin du processus OtaUpdateCb(). (Source du code : Microchip Technology)

Pour vérifier que le code téléchargé est valide, les développeurs ont longtemps utilisé des certificats de signature de code émis par une autorité de certification reconnue. Malgré tout, les faiblesses du stockage sécurisé des données, de l'implémentation de techniques de validation et de la protection des certificats fournissent aux pirates de multiples possibilités de prendre le contrôle d'un dispositif IoT.

Même avec les techniques de sécurité conventionnelles, le processus de mise à jour du micrologiciel propre à un dispositif peut être détourné pour remplacer son code valide par un code compromis. Au redémarrage, le dispositif devient un outil que le pirate informatique peut utiliser pour s'infiltrer plus profondément dans le réseau IoT, l'application IoT et même les ressources internes de l'entreprise.

Dans ce scénario, la capacité à démarrer le dispositif IoT en toute sécurité sert de ligne de défense stratégique. Pour le développeur, toutefois, l'implémentation d'un démarrage sécurisé comporte plusieurs exigences pour le stockage sécurisé, le cryptage, l'authentification et la validation du code.

L'implémentation d'un démarrage sécurisé dans le logiciel expose le processus de mise à jour à des méthodes d'attaque axées sur la récupération des clés sécurisées dans l'espace de stockage du dispositif, l'interception des données cryptées, le détournement des mécanismes d'authentification et la compromission des algorithmes de validation du code. En pratique, les conceptions IoT ne disposent généralement pas de la mémoire et de la puissance de traitement supplémentaires requises pour une solution logicielle. Cependant, une implémentation matérielle ne peut pas toujours garantir la sécurité.

Pour implémenter un démarrage sécurisé dans le matériel, les dispositifs IoT nécessitaient jusqu'à récemment un certain nombre de dispositifs spécialisés qui augmentaient considérablement la complexité et le coût de la conception. Même si les développeurs intégraient ces dispositifs distincts, des pirates déterminés pouvaient facilement se procurer un échantillon du dispositif IoT cible et attaquer les dispositifs de sécurité individuels via leur bus et leur interconnexion de signaux. En contraste, l'ATECC608A de Microchip Technology est une solution monopuce qui permet aux développeurs d'ajouter un démarrage sécurisé sans exposer les secrets ou mécanismes de sécurité sous-jacents.

Circuit intégré de sécurité

L'ATECC608A est un dispositif de sécurité à 8 broches conçu pour prendre en charge un microcontrôleur hôte doté d'un complément sophistiqué de fonctionnalités de sécurité via une interface série simple (Figure 1).

Figure 1 : L'ATECC608A est un coprocesseur cryptographique à 8 broches avec stockage de clés sécurisé basé sur du matériel. (Source de l'image : Microchip Technology)

Le dispositif fournit une solution de sécurité matérielle complète qui combine ses accélérateurs de cryptographie intégrés avec un stockage sécurisé sur puce pour prendre en charge une variété d'algorithmes de cryptage, notamment SHA-256, AES-128 et des algorithmes de courbes elliptiques robustes, notamment ECDSA (Elliptic Curve Digital Signature), ECDH (Elliptic Curve Diffie-Hellman) et NIST Curve P-256. Au-delà de ces mécanismes de cryptographie, le dispositif prend en charge les protocoles TLS (Transport Layer Security) de niveau supérieur, notamment TLS 1.3. Contrairement aux précédents dispositifs, l'ATECC608A peut générer et stocker des clés de session de manière sécurisée, ce qui permet d'atténuer une source courante de menaces lors de l'utilisation de l'authentification utilisant un protocole TLS.

Ces fonctionnalités jouent un rôle fondamental dans la sécurisation des opérations normales d'un dispositif IoT, mais la prise en charge du démarrage sécurisé par l'ATECC608A étend la couverture de sécurité au processus essentiel de mise à jour du micrologiciel. Ici, l'ATECC608A valide le nouveau code et renvoie un message au microcontrôleur pour lui indiquer la réussite ou l'échec de l'opération. À ce stade, en fonction des stratégies de sécurité existantes, le microcontrôleur peut relancer la mise à jour, envoyer un message d'avertissement à un point d'extrémité du moniteur de sécurité, interrompre ou ignorer la mise à jour et redémarrer dans le code d'origine.

Intégration matérielle

Pour le développeur, l'ATECC608A ajoute relativement peu d'exigences supplémentaires pour l'ajout d'un démarrage sécurisé et d'autres fonctionnalités de sécurité à une conception basée sur un microcontrôleur. Côté matériel, le concepteur doit gérer au plus quatre connexions : V_CC, GND, SCL (entrée d'horloge série) et SDA (données série). Les quatre autres broches ne sont pas connectées. Hormis la connexion de V_CC à une source d'alimentation de 2,0 V à 5,5 V, la seule décision restante concerne la connexion série au microcontrôleur.

Les concepteurs peuvent connecter les broches SCL et SDA du dispositif au microcontrôleur pour avoir une connectivité I²C traditionnelle. Ils peuvent également tirer parti de la prise en charge de l'interface 1-Wire de Microchip. Ici, les développeurs connectent le port SDA du dispositif à une broche GPIO du microcontrôleur et utilisent le protocole de temporisation 1-Wire de Microchip pour transmettre les valeurs logiques 0 et 1 (Figure 2).

Figure 2 : Dans le protocole série 1-Wire de Microchip, une séquence de transitions de forme d'onde d'une durée spécifiée signale une valeur logique 0 ou 1. (Source de l'image : Microchip Technology)

Dans ce protocole, une transmission de valeur logique entre l'ATECC608A et le microcontrôleur commence par une impulsion de démarrage (t_START) d'une durée spécifiée. Après l'impulsion de démarrage, le protocole définit une valeur logique 0 comme cycle d'une impulsion haute à transmission nulle (t_ZHI) suivie d'une impulsion basse à transmission nulle (t_ZLO) d'une durée spécifiée. De même, un niveau élevé soutenu signifie une transmission de valeur logique 1.

Dans les deux cas, le protocole s'attend à ce que le signal diminue dans un délai spécifié (t_BIT). Après une série de transmissions de bits, si la ligne série devient inactive après une durée de temporisation E/S spécifiée, il est possible de programmer le dispositif de manière à le faire basculer automatiquement en mode veille. Toutefois, pour utiliser l'ATECC608A, les développeurs ont rarement besoin de se préoccuper des détails de temporisation de ce protocole : Microchip a défini les paramètres de temporisation clés pour qu'ils soient compatibles avec un UART standard fonctionnant à 230,4 Kbauds.

Configuration du dispositif

Au niveau du dispositif, l'ATECC608A nécessite des paramètres de configuration minimum. En utilisant l'interface série I²C ou 1-Wire, les développeurs peuvent charger des paramètres comme l'adresse I²C ou définir certaines fonctionnalités comme l'auto-test à l'activation ou à la mise sous tension. Le dispositif offre un paramètre de configuration qui peut être particulièrement pertinent pour les conceptions IoT ultrabasse consommation.

Dans ces conceptions, l'ATECC608A ajoute relativement peu au budget global de l'alimentation pour les modes de veille ou d'inactivité, qui sont probablement les états les plus courants dans une conception IoT typique. En mode inactif, le dispositif consomme environ 800 μA. En mode veille, la consommation électrique est inférieure ou égale à 150 nA, selon la configuration. Lorsque le microcontrôleur réactive le dispositif pour exécuter un processus de sécurité, la consommation électrique du dispositif n'atteint toujours que 14 mA en fonctionnement actif. Néanmoins, les conceptions avec des budgets de puissance très serrés peuvent avoir besoin de niveaux de puissance active encore plus bas.

Pour prendre en charge ces conceptions, le dispositif offre une option de configuration qui permet aux développeurs de sélectionner trois modes de fonctionnement différents qui échangent la vitesse d'exécution contre une réduction de la consommation électrique. Ainsi, les développeurs peuvent réduire la consommation électrique en mode actif de 14 mA (à la vitesse d'exécution maximale) à 6 ou 3 mA avec des vitesses d'exécution plus faibles.

Outre divers éléments de configuration de base, un dispositif de sécurité comme l'ATECC608A est plus efficace lorsque les informations sécurisées connexes sont déjà en place bien avant le développement. Les erreurs ou les vulnérabilités de clés sécurisées et de certificats se produisant au cours du développement peuvent anéantir même les meilleurs efforts en termes de sécurité. Pour faire face à cette menace possible, le service de provisionnement sécurisé de Microchip charge les données sécurisées, y compris les clés et les certificats, dans le cadre du processus de fabrication.

Une fois que les informations sécurisées sont chargées dans un environnement sécurisé en usine, elles restent protégées contre toute découverte accidentelle ou intentionnelle, même lorsque le dispositif passe par des processus de manipulation normaux dans la chaîne d'approvisionnement. L'ATECC608A inclut une fonction spéciale de verrouillage de transport qui désactive l'utilisation du dispositif jusqu'à ce qu'il soit activé de manière cryptographique à l'aide d'une clé connue transmise par le microcontrôleur de l'hôte final.

Une fois activé par le microcontrôleur hôte, l'ATECC608A génère aléatoirement une clé secrète appelée clé de protection E/S qu'il partage avec le microcontrôleur. Les communications ultérieures entre l'ATECC608A et le microcontrôleur sont cryptées à l'aide de cette clé de protection E/S. Ce mécanisme fournit une authentification supplémentaire lors du démarrage sécurisé et d'autres processus sécurisés.

Si les pirates informatiques espèrent détourner le processus de validation en coupant la connexion avec l'ATECC608A et en transmettant leur propre signal de « réussite » au microcontrôleur, ce mécanisme de clé de protection E/S fait en sorte que le microcontrôleur ignore le faux signal. Même si un pirate parvenait à compromettre de quelque manière que ce soit un dispositif ATECC608A et essayait de l'utiliser sur un système différent, le mécanisme de clé de protection E/S en empêcherait efficacement l'utilisation.

Intégration logicielle

Malgré ses fonctionnalités et ses mécanismes de protection sophistiqués, l'ATECC608A reste simple à appliquer à une conception basée sur microcontrôleur. Outre l'implémentation de l'interface matérielle simple et des paramètres de configuration mentionnés précédemment, les développeurs utilisent une interface de programmation d'application (API) qui permet d'extraire les détails des opérations de sécurité. La bibliothèque de crypto-authentification CryptoAuthLib de Microchip fournit un pack logiciel complet avec les définitions, les structures et les appels d'API nécessaires pour tirer pleinement parti des fonctionnalités de l'ATECC608A. La bibliothèque sert de couche matérielle indépendante, fonctionnant via l'API de couche d'abstraction matérielle (HAL) et les pilotes pour des cibles matérielles spécifiques (Figure 3).

Figure 3 : La bibliothèque CryptoAuthLib de Microchip fournit une couche de services de cryptographie entre une application et le matériel sous-jacent accessible via une couche d'abstraction matérielle au-dessus des pilotes matériels spécifiques, offrant ainsi une portabilité entre différents ensembles matériels. (Source de l'image : Microchip Technology)

Les développeurs utilisent des routines API CryptoAuthLib comme io_protection_set_key() pour créer une clé de protection E/S et atcab_secureboot() pour exécuter le mécanisme de validation de démarrage sécurisé de l'ATECC608A par rapport au résumé de code ou à la signature inclus dans les paramètres d'appel.

Bien que les commandes de l'API soient simples, les étapes spécifiques de configuration, d'administration et d'exécution requises pour implémenter la sécurité peuvent être complexes. Les mécanismes de sécurité que les développeurs tentent de mettre en place peuvent entraîner des retards si des étapes clés sont manquantes ou exécutées hors séquence.

Grâce au kit de développement ATSAMD21-XPRO basé sur le microcontrôleur SAM D21 de Microchip et à la carte d'extension ATCRYPTOAUTH-XPRO-B équipée du coprocesseur ATECC608A, les développeurs peuvent rapidement acquérir une expérience de travail avec ces mécanismes généraux et avec les capacités spécifiques de l'ATECC608A. Microchip propose un logiciel de démarrage sécurisé étendu, conçu pour fonctionner sur les systèmes ATSAMD21-XPRO et ATCRYPTOAUTH-XPRO-B, avec une carte ATOLED1-XPRO de Microchip pour fournir une interface d'affichage de base pour des applications d'exemple (Figure 4).

Figure 4 : Les développeurs peuvent rapidement évaluer le processus de démarrage sécurisé à l'aide du logiciel de Microchip et du kit de développement ATSAMD21-XPRO basé sur le microcontrôleur SAM D21, combiné à la carte d'extension ATCRYPTOAUTH-XPRO-B équipée de l'ATECC608A et à la carte d'extension d'affichage ATOLED1-XPRO. (Source de l'image : Microchip Technology)

Dans le pack de démonstration SAM D21, une routine de démarrage sécurisé complète illustre les principaux schémas logiciels utilisés pour configurer, exécuter et vérifier le statut d'une opération de démarrage sécurisé (Liste 2). Grâce à cette plateforme matérielle et à ce pack logiciel de démonstration, les développeurs peuvent rapidement évaluer l'utilisation de l'ATECC608A pour le démarrage à distance et modifier le logiciel d'exemple selon leurs besoins.

Copier

/** \brief Handles secure boot functionality through initialization, execution,

*         and de-initialization.

*  \return ATCA_SUCCESS on success, otherwise an error code.

*/

ATCA_STATUS secure_boot_process(void)

{

ATCA_STATUS status;

secure_boot_parameters secure_boot_params;

uint8_t secure_boot_mode;

bool secure_boot_app_valid = false;

<e> 

/*Initialize secure boot */

if ((status = secure_boot_init(&secure_boot_params)) != ATCA_SUCCESS)

{

return status;

}

<e> 

do

{

.

.

.

#if SECURE_BOOT_DIGEST_ENCRYPT_ENABLED

.

.

.

/*Get IO Protection Key*/

if ((status = io_protection_get_key(secure_boot_params.io_protection_key)) != ATCA_SUCCESS)

{

return status;

}

<e> 

if ((status = atcab_secureboot_mac(secure_boot_mode,

(const uint8_t*)&secure_boot_params.app_digest,

(const uint8_t*)&secure_boot_params.memory_params.signature,

(const uint8_t*)secure_boot_params.randomnum,

(const uint8_t*)secure_boot_params.io_protection_key,

&secure_boot_app_valid)) != ATCA_SUCCESS)

{

break;

}

#else

if ((status = atcab_secureboot(secure_boot_mode,

0,

(const uint8_t*)&secure_boot_params.app_digest,

(const uint8_t*)&secure_boot_params.memory_params.signature,

NULL)) != ATCA_SUCCESS)

{

break;

}

secure_boot_app_valid = true;

#endif

<e> 

/*Check whether the secure boot command executed successfully with the correct return mac  */

if (!secure_boot_app_valid)

{

break;

}

.

.

.

}

while (0);

<e> 

/* De-initialize memory interface and release its resources*/

secure_boot_deinit_memory(&secure_boot_params.memory_params);

<e> 

return status;

}

Liste 2 : Cet extrait du pack de démonstration SAM D21 de Microchip présente les principaux schémas de conception pour un démarrage sécurisé, notamment la récupération d'une clé de protection E/S (io_protection_get_key()) et la validation du micrologiciel à l'aide de son résumé, de sa signature et d'autres paramètres (atcab_secureboot_mac() ou atcab_secureboot() en fonction de la configuration sélectionnée). (Source du code : Microchip Technology)

Conclusion

Les dispositifs IoT présentent de multiples possibilités de menace pour les pirates informatiques désireux d'utiliser des dispositifs compromis comme sources d'entrée sur les réseaux, applications et ressources d'entreprise IoT. Parmi les techniques d'atténuation, le démarrage sécurisé apparaît comme un élément essentiel au sein d'une stratégie de sécurité plus large. Cependant, l'implémentation du démarrage sécurisé apporte son propre ensemble d'exigences pouvant exposer le système en cas de mauvaise gestion.

Le circuit intégré de sécurité ATECC608A de Microchip Technology offre une solution complète dans un seul boîtier que les développeurs peuvent facilement ajouter à toute conception basée sur microcontrôleur. Grâce à l'ATECC608A, les développeurs peuvent considérablement améliorer la sécurité et assurer un démarrage sécurisé de leurs conceptions IoT.