Résumé

  • RFC 9019 qualifie la mise à jour de micrologiciel d’exécution de code à distance autorisée. La signature authentifie l’auteur et protège le manifeste, mais la permission d’effectuer l’action demandée relève d’une politique distincte.
  • L’auteur, l’opérateur de l’équipement, l’opérateur de réseau, l’utilisateur et l’autorité de provisionnement de confiance n’ont pas nécessairement les mêmes droits. RFC 9124 prévoit plusieurs signatures pour représenter ces autorisations différentes.
  • Un reçu local d’autorisation de changement peut relier le manifeste à la politique, à la fenêtre de déploiement, au démarrage observé et au rétablissement. C’est une proposition éditoriale de Daniel Kade, pas une exigence de l’IETF.

La signature verte ne doit pas être diminuée. Elle établit qu’une clé admise a protégé le manifeste et que les octets couverts n’ont pas été modifiés. Le condensat de la charge utile rattache en outre l’image reçue aux instructions authentifiées. Sans ces preuves, un mécanisme de mise à jour offre à l’attaquant un chemin direct vers l’exécution.

Mais la preuve de provenance n’est pas encore la décision d’exécuter. RFC 9019, publié comme RFC informationnelle de l’IETF en avril 2021, dit qu’une mise à jour est une « exécution de code à distance autorisée ». Il ajoute que les identités authentifiées servent d’entrée au processus d’autorisation, que tous les auteurs n’ont pas les mêmes permissions et que l’équipement doit vérifier si l’action demandée entre dans les droits du signataire.

Cette phrase empêche une confusion fréquente : « clé de confiance » ne veut pas dire « pouvoir illimité ». Une clé peut être reconnue pour un composant, une classe d’appareils, une opération d’urgence ou une période donnée. La même clé peut être légitime dans ce périmètre et dépourvue d’autorité ailleurs.

L’auteur n’est pas automatiquement l’opérateur

L’architecture distingue plusieurs acteurs. L’auteur produit l’image. L’opérateur de l’équipement gère le parc au quotidien. L’opérateur de réseau maîtrise la connectivité. L’utilisateur possède ou utilise parfois le produit. L’autorité de provisionnement de confiance, ou TPA, distribue les ancres de confiance et les politiques d’autorisation, et peut déléguer des droits.

Dans un produit simple, une seule organisation peut cumuler ces fonctions. Une signature peut alors suffire si la politique locale lui attribue effectivement toutes les permissions nécessaires. RFC 9019 n’impose pas une seconde cérémonie pour le plaisir de multiplier les validations.

La situation change dans une chaîne de production complexe. Le fournisseur d’un module radio peut signer son composant, alors que l’exploitant industriel décide quand interrompre la machine. Un constructeur peut corriger le noyau sans disposer du droit de modifier les paramètres de sécurité du site. Un service de distribution peut livrer le fichier sans être autorisé à le créer. La pluralité n’est pas théorique : elle naît de la répartition réelle des responsabilités.

La politique fournie par la TPA devient donc la constitution du chemin de mise à jour. Elle doit relier des clés à des rôles, des rôles à des composants et des opérations, et préciser les délégations. Si elle reste implicite ou périmée, le contrôle cryptographique peut réussir alors que l’allocation de pouvoir est devenue fausse.

Une ancre de confiance indique quelle clé peut présenter une preuve. Elle ne répond pas forcément à quatre questions décisives : cette clé peut-elle remplacer le chargeur de démarrage ? Peut-elle agir sur ce parc ? Peut-elle opérer seule ? Son droit est-il encore valable ? La décision d’installation exige ces réponses.

L’autorisation précède le téléchargement

RFC 9019 décrit une préautorisation pendant laquelle le consommateur de micrologiciel vérifie si l’entité qui signe le manifeste est autorisée à effectuer la mise à jour. Ce contrôle peut intervenir avant le transfert d’une image volumineuse, ce qui protège la bande passante, l’énergie et la mémoire flash des appareils contraints.

L’action demandée doit être lue dans son contexte. Une autorisation de corriger une application ne s’étend pas nécessairement au micrologiciel de démarrage. Un signataire accepté pour une famille de capteurs n’obtient pas de ce fait accès à un contrôleur industriel. Un mandat d’urgence ne justifie pas l’ajout durable d’une fonction commerciale.

L’exemple de l’infrastructure critique est éclairant. L’image peut être authentique et pourtant nécessiter la signature de l’opérateur en plus de celle de l’auteur. L’opérateur ne réécrit pas l’identité de l’auteur ; il confirme qu’il accepte l’exécution de cette modification dans son environnement.

RFC 9124 transforme ce besoin en capacité du modèle d’information : un format de manifeste doit pouvoir porter plusieurs signatures afin que des parties dotées de permissions différentes autorisent ensemble l’installation. Son cas d’usage donne à l’opérateur le droit d’exiger son approbation expresse et de protéger l’interopérabilité de sa famille de produits.

Il ne suffit donc pas de compter les signatures. Deux clés toutes deux classées « auteur » ne satisfont pas une règle exigeant auteur et opérateur. Une signature supplémentaire ne compense pas l’absence de l’autorité chargée de la sûreté. Il faut vérifier le rôle de chaque signataire, la version de politique appliquée et la portée exacte de l’accord.

Déclencher n’est pas autoriser

Le suivi d’état peut annoncer une version, recevoir des caractéristiques de l’appareil et déclencher à distance le processus. Il peut être exploité par différents acteurs. Cette souplesse facilite les déploiements, mais la capacité technique de déclencher ne confère ni le droit d’écrire le code ni celui d’en approuver l’installation.

Un opérateur de réseau peut programmer un téléchargement pour limiter la charge. Un serveur peut stocker un manifeste détaché. Une passerelle peut relayer l’image vers un appareil hors ligne. Aucune de ces fonctions ne doit pouvoir modifier les octets authentifiés ou élargir les permissions du signataire.

Inversement, l’auteur ne connaît pas forcément le moment sûr. Une correction urgente peut arriver pendant une opération physique impossible à interrompre. Un micrologiciel parfaitement signé peut être incompatible avec une certification locale, une dépendance non encore déployée ou l’absence d’image de secours.

« Disponible », « téléchargé », « stocké », « autorisé », « installé » et « en exécution » sont ainsi six états. Les confondre sous un seul voyant vert rend invisible le passage exact où le pouvoir change de main.

Le numéro de séquence n’est pas la version du logiciel

RFC 9124 exige un numéro de séquence croissant pour empêcher la réutilisation d’un ancien manifeste valide. Pourtant, il précise que ce numéro n’est pas la version du micrologiciel. Une autorité peut émettre un manifeste de séquence plus élevée qui réinstalle intentionnellement une version logicielle plus ancienne.

Cette possibilité permet un rétablissement contrôlé. Si une nouvelle version échoue, une décision récente peut autoriser le retour à une image connue. L’objet d’autorisation est nouveau même si le numéro de la charge utile diminue.

Il serait donc erroné de qualifier automatiquement toute baisse de version d’attaque par retour arrière. Il faut examiner la séquence du manifeste, les droits du signataire, l’état précurseur et la raison opérationnelle. À l’inverse, une version logicielle plus élevée ne rend pas l’action légitime : un signataire trop puissant peut livrer un code « plus récent » hors de son mandat.

Un manifeste valide peut ne pas s’appliquer ici

Un appareil IoT peut contenir plusieurs microcontrôleurs. Sa mise à jour peut nécessiter plusieurs images, des dépendances, un état précurseur précis, une destination de stockage et une activation coordonnée. RFC 9124 prévoit des identifiants de fabricant, de classe, de composant, des condensats précurseurs et des instructions de traitement parce que l’authenticité ne garantit pas l’applicabilité.

Une mise à jour différentielle échoue si l’image de départ n’est pas celle attendue. Deux composants signés peuvent être incompatibles entre eux. Une image destinée à un matériel voisin peut conserver une signature parfaite. L’échec ne se situe pas dans la cryptographie, mais dans le rattachement de l’instruction à l’état réel.

Certaines conditions restent locales : équipement contrôlé à l’arrêt, alimentation de secours disponible, technicien présent, cohorte témoin concluante, service dépendant déjà migré. Le manifeste commun peut annoncer ses exigences ; l’opérateur doit encore prouver que le site satisfait les siennes.

« Mise à jour terminée » peut précéder le redémarrage

RFC 9019 sépare le consommateur, qui traite le manifeste et stocke l’image, du vérificateur, souvent le chargeur de démarrage, qui contrôle l’image avant de l’exécuter. Si l’image est invalide, l’appareil doit pouvoir sélectionner une autre image valide ou en obtenir une nouvelle.

Le diagramme d’exemple envoie un message de fin de mise à jour avant le redémarrage, la vérification au démarrage et l’activation. Ce message n’est pas mensonger : il clôt l’étape qu’il décrit. Il ne peut simplement pas prouver un événement futur.

Après le redémarrage, l’image peut être rejetée, démarrer sans restaurer le service, activer seulement certains composants ou retomber sur l’ancienne version. L’appareil peut aussi perdre le réseau avant de signaler son état. Le serveur ayant reçu le premier message ignore encore quel état est devenu durable.

Il faut donc une observation bornée après démarrage : image sélectionnée, ensemble de composants, résultat du démarrage, état de récupération et santé des fonctions essentielles. Une mesure d’attestation peut aider à dire ce qui fonctionne ; elle ne prouve pas à elle seule que l’installation avait été autorisée ni que le processus physique produit le résultat attendu.

Un reçu d’autorisation de changement

La réparation pratique est un reçu local et minimal qui accompagne une proposition authentifiée jusqu’au résultat observé. Il ne remplace pas le manifeste et ne crée pas d’inventaire public des appareils.

Le reçu lie le condensat du manifeste, celui de la charge utile, la séquence, la version déclarée, la classe d’appareil, le composant et l’état précurseur. Il mentionne la version de politique, le rôle de chaque signataire et l’ensemble d’approbations requis. Une personne chargée du contrôle doit pouvoir expliquer pourquoi ces signatures autorisaient cette action précise.

Il enregistre ensuite l’admission : cohorte, fenêtre de maintenance, conditions locales, résultat du test témoin, solution de secours et responsable de la décision. Les clés, identifiants détaillés, topologies et vulnérabilités ne doivent pas être exposés inutilement ; des références protégées et des condensats suffisent souvent.

Enfin, il sépare téléchargement, stockage, installation, acceptation par le vérificateur, activation après redémarrage, contrôle de santé et rétablissement. Si une version ancienne est restaurée, le reçu indique le manifeste de séquence supérieure qui l’a autorisée et l’état final conservé.

Ce reçu est une proposition éditoriale de Daniel Kade. Ce n’est ni un élément SUIT, ni une exigence de l’IETF, ni une nouvelle signature, ni un produit de TPA. Il empêche seulement qu’une preuve cryptographique exacte soit utilisée comme réponse universelle.

La doctrine de Heng Lu aide à maintenir la frontière : la spécification donne un langage commun minimal ; la décision demeure locale ; le code exécute une interprétation ; le résultat observé nourrit la décision suivante. RFC 9019 et RFC 9124 rendent le manifeste intelligible entre systèmes. Elles ne retirent pas à l’opérateur la responsabilité d’autoriser, d’observer et de rétablir.

La signature peut rester verte. L’autorisation d’installer doit avoir son propre état.

Sources