Projet de Recherche Doctorale (PRD)

Le nombre de dispositifs connectés déployés dans le monde devrait dépasser 29 milliards d’ici 2027 [1], et chacun doit prouver qui il est pour rejoindre un réseau. Cette preuve repose aujourd’hui sur trois familles de justificatifs normalisées par la RFC 7925 [3] : les clés pré-partagées « Pre-Shared Keys (PSK) », les clés publiques brutes « Raw Public Keys (RPK) » et les certificats X.509 avec authentification mutuelle. Ce dernier modèle, retenu par les grandes plateformes cloud, fait dépendre la confiance d’une autorité de certification : sa compromission invalide la chaîne de confiance dans son ensemble, et la gestion du cycle de vie de ces justificatifs à grande échelle reste un problème ouvert [1, 2]. 

Un second problème tient à ce que l’identité ne dit pas : une identité valide atteste de qui est le dispositif, non de ce qu’il exécute. L’attaque SolarWinds l’a montré en 2020, avec des mises à jour signées par le fabricant légitime qui transportaient du code malveillant injecté dans la chaîne d’approvisionnement [5]. Un dispositif au firmware compromis présente ainsi une identité parfaitement valide, car aucune étape de vérification ne porte sur le code réellement embarqué. Les travaux récents qui lient un identifiant décentralisé du dispositif à une preuve d’intégrité de son firmware [6] reposent encore sur la signature d’un émetteur unique, sans contre-signature du réseau : le point de confiance unique est déplacé, il n’est pas supprimé. 

Le contexte réglementaire rend la question pressante : le règlement européen sur la cyberrésilience [9], pleinement applicable en décembre 2027, impose aux fabricants de documenter les composants logiciels de leurs produits sous forme de nomenclature lisible par machine « Software Bill of Materials (SBOM) » [10] et d’en assurer le suivi pendant toute la durée de support. Rendre cette nomenclature vérifiable par le réseau, plutôt que simplement déclarée par le fabricant, constitue un verrou scientifique autant qu’une attente industrielle. 

Concevoir une réponse décentralisée se heurte enfin aux propriétés de ces dispositifs : aucun mot de passe n’y est saisi d’où dériver une clé privée, et les plus contraints d’entre eux, tels que caractérisés par la RFC 7228 [4], ne peuvent pas héberger un client blockchain. Toute architecture décentralisée pour l’IoT doit donc rendre le registre accessible à des dispositifs qui ne peuvent y accéder directement, sans que l’intermédiaire qui les représente ne redevienne l’autorité centrale que l’on cherchait à supprimer. 

D’où la question qui structure cette thèse : 

Comment doter un dispositif contraint d’une identité décentralisée qu’aucune autorité ne contrôle, et lier cette identité à une preuve vérifiable du code qu’il exécute ? 

Le sujet s’inscrit dans les travaux de l’équipe sur la gestion décentralisée de l’identité et les architectures blockchain substituables à une infrastructure à clés publiques [11, 12], dont il porte les principes vers un terrain non traité : les dispositifs contraints et l’intégrité de leur firmware. Aucune connaissance préalable de ces travaux n’est attendue des candidats. 

La thèse s’organise autour de quatre objectifs, du modèle à la validation expérimentale. 

1. Un modèle d’identité décentralisée pour dispositifs contraints 

• Étudier le provisionnement du secret cryptographique en l’absence d’utilisateur humain : clé pré-installée en usine, élément sécurisé, fonction physique non clonable « Physical Unclonable Function (PUF) », comparés en sécurité, coût et passage à l’échelle. 

• Concevoir un mécanisme de signature à plusieurs parties associant le dispositif et une contre-signature du réseau, de sorte qu’aucun acteur seul ne puisse créer, modifier ou révoquer une identité. 

• Retenir des primitives cryptographiques compatibles avec les budgets mémoire, calcul et énergie des plateformes visées, et valider expérimentalement cette compatibilité. 

2. Un accès au registre sans nouvel ancrage de confiance central 

• Définir le rôle d’une passerelle intermédiaire pour les dispositifs qui ne peuvent pas dialoguer directement avec le registre : délégation, preuves transmises, part de vérification restant exécutable par le dispositif lui-même. 

• Construire un modèle d’attaquant incluant une passerelle compromise ou indisponible, et démontrer que sa compromission ne suffit pas à usurper une identité. 

• Caractériser les conditions dans lesquelles une organisation pourrait déployer sa propre instance de registre pour gérer l’identité de son parc, en substitution d’une autorité de certification. 

3. Le lien entre identité et intégrité du firmware 

• Enrichir l’identité du dispositif pour qu’elle porte, outre sa clé publique et ses attributs, l’empreinte de son firmware et la nomenclature de ses composants logiciels (SBOM). 

• Étendre la signature à plusieurs parties à la validation de ce lien identité-firmware, afin que l’attestation d’intégrité ne repose pas sur la seule parole du fabricant. 

• Tracer les mises à jour à distance « Over-The-Air (OTA) » dans un registre auditable et traiter la révocation d’une version vulnérable : vérifier l’identité d’un dispositif couvrirait alors qui il est et quel code il exécute. 

4. Validation formelle et expérimentale 

• Analyser formellement les protocoles d’authentification et de mise à jour proposés à l’aide d’un vérificateur de protocoles (Scyther, ProVerif ou Tamarin). 

• Implémenter un prototype sur des plateformes réelles représentatives des classes de la RFC 7228 : latence d’authentification, empreinte mémoire, consommation énergétique, passage à l’échelle. 

• Évaluer l’architecture face à des scénarios d’attaque concrets : firmware corrompu dans la chaîne d’approvisionnement, passerelle compromise, rejeu, révocation contournée. 

Le sujet se situe à la rencontre de la cryptographie appliquée, des architectures décentralisées et des systèmes embarqués. Aucun candidat n’est attendu expert des trois. 

• Solides bases en sécurité des réseaux et en cryptographie appliquée : signature numérique, courbes elliptiques, infrastructures à clés publiques. 

• Connaissance des technologies blockchain (consensus, contrats intelligents). Une familiarité avec les identifiants décentralisés et les attestations vérifiables [7, 8] est appréciée. 

• Programmation : C/C++ pour l’embarqué et Python. Solidity, Go ou Rust sont un plus. 

• Goût pour l’expérimentation sur plateformes matérielles contraintes et pour la mesure rigoureuse. 

• Une première exposition à la vérification formelle de protocoles est un atout, sans être exigée. 

• Anglais scientifique : la thèse donnera lieu à des publications dans des conférences et revues internationales. 

• Autonomie, rigueur, honnêteté intellectuelle et goût du travail en équipe. 

Master 2 recherche ou diplôme d’ingénieur (bac+5) en informatique, réseaux, cybersécurité ou systèmes embarqués, obtenu au plus tard à la date de démarrage de la thèse. Les candidatures ne présentant ni diplôme de master ni diplôme d’ingénieur ne peuvent pas être retenues. Un stage de recherche ou un projet de fin d’études en sécurité, cryptographie appliquée, blockchain ou systèmes embarqués constitue un atout. 

Nour EL MADHOUN (Isep) : nour.el-madhoun@isep.fr  

Simon Pierre DEMBELE (Isep) : simon-pierre.dembele@isep.fr  

Haifa TOUATI (Université de Gabès) : haifa.touati@univgb.tn  

Le dossier de candidature comprend : 

• un curriculum vitae détaillé ; 

• une lettre de motivation précisant l’intérêt du candidat pour le sujet ; 

• les relevés de notes du master ou des deux dernières années du cycle ingénieur ; 

• les coordonnées de deux personnes pouvant être contactées comme référents. 

Merci d’adresser le dossier par courriel avec l’objet « Candidature doctorat – Identité et firmware IoT ». Les candidatures sont examinées au fil de l’eau jusqu’à pourvoi du poste.