La chaîne de confiance commence avant la première image

01

Le fonctionnement apparent ne prouve pas l’intégrité

Lorsqu’on évalue une caméra, les premiers critères sont souvent la qualité de l’image, la vision nocturne, le stockage ou la disponibilité du flux vidéo. Ces critères sont nécessaires. Mais un appareil qui fournit le service attendu n’apporte pas, par ce seul fonctionnement, la preuve que son logiciel est intact.

Imaginons un logiciel modifié qui conserve les fonctions visibles tout en ajoutant un comportement indésirable. L’image continue à arriver au poste de supervision ; le problème se situe dans ce que l’équipement fait en parallèle. Ce scénario invite à distinguer deux observations : constater qu’un appareil fonctionne et vérifier qu’il exécute un logiciel autorisé.

Un écran d’administration affichant « système sécurisé » ne suffit donc pas. Il faut comprendre quel mécanisme produit cette information, ce qu’il contrôle et pourquoi ses résultats méritent confiance. La question remonte progressivement vers les premières instructions exécutées par l’équipement.

Cette distinction vaut aussi pour les protections réseau. Chiffrer une liaison protège les échanges sur leur trajet ; cela ne permet pas, à lui seul, de conclure que le logiciel à l’une des extrémités est sain. De même, reconnaître l’identité d’un équipement ne suffit pas à établir l’intégrité de tout ce qu’il exécute. Dans l’analyse qui suit, l’objet précis de la confiance est donc le démarrage du logiciel, avant d’examiner ses relations avec les autres protections.

02

La racine de confiance et le premier vérificateur

La chaîne de confiance repose sur une succession de vérifications : un composant vérifie le suivant avant de lui transmettre l’exécution. Mais cette logique exige un point de départ. Si le premier vérificateur peut être remplacé librement, il peut accepter n’importe quoi et rendre les contrôles suivants sans valeur.

La racine de confiance désigne ce socle initial auquel l’architecture accorde sa confiance. Selon la plateforme, elle associe du matériel, du code protégé et des paramètres de sécurité. Un exemple est un petit programme en mémoire de démarrage non modifiable, associé à une référence cryptographique protégée. Le NIST souligne que la fiabilité de ces racines conditionne celle des mécanismes qui en dépendent. [1]

Pourquoi le premier vérificateur mérite une protection particulière

La question « qui vérifie le vérificateur ? » ne peut pas être repoussée indéfiniment vers un autre programme. L’architecture choisit donc une base de confiance dont les propriétés doivent être établies autrement : conception matérielle, isolation, restrictions d’écriture, contrôle des mises à jour lorsqu’elles sont possibles et évaluation de la résistance aux attaques. Une racine de confiance est une hypothèse de sécurité à justifier, pas une déclaration d’infaillibilité. [1]

Dans Trusted Firmware-A, par exemple, le démarrage de confiance peut s’appuyer sur un premier code supposé résider en ROM et sur une référence protégée à la clé publique racine. Sur les plateformes décrites, une empreinte de cette clé peut être conservée dans des registres dédiés. Cela montre qu’il faut distinguer le code qui vérifie, la clé utilisée et le mécanisme qui protège cette clé. Cet exemple Arm explique le principe ; il ne décrit pas la réalisation interne d’une caméra Axis particulière. [10]

Dans un démarrage fondé sur des signatures, le fabricant conserve la clé privée de signature et l’équipement utilise une clé publique de vérification, ou une référence protégée permettant de l’authentifier. Cette clé publique n’a pas besoin d’être secrète : elle doit surtout résister à un remplacement non autorisé. Sinon, un attaquant pourrait substituer sa propre clé et faire accepter ses propres logiciels. [3]

Ce que la signature apporte réellement

Le logiciel est signé avec une clé privée ; sa signature est contrôlée à l’aide de la clé publique correspondante. Dans le cadre de cette vérification, l’empreinte cryptographique sert à représenter le contenu couvert. Une simple empreinte conservée à côté du fichier ne suffit pas si un attaquant peut remplacer les deux. La signature rattache le contenu à une autorité admise, à condition de protéger la référence de confiance et la politique d’autorisation. [3]

Signer ne signifie pas chiffrer. Le code peut rester lisible tout en étant authentifié. Inversement, cacher le contenu d’un fichier ne prouve pas qu’il provient d’une source autorisée. Cette différence est essentielle pour comprendre la fonction recherchée : empêcher l’exécution d’un logiciel non admis, sans confondre ce contrôle avec la confidentialité du logiciel.

03

Le démarrage d’une caméra IP

La documentation Axis Edge Vault décrit une chaîne qui part de la Boot ROM du système sur puce, puis vérifie le chargeur de démarrage, le noyau Linux et le système de fichiers racine. Chaque étape établit les conditions de confiance nécessaires à la suivante. Le chargeur, ou bootloader, est le programme chargé de préparer le lancement du système. [2]

Pour suivre cette séquence, il faut séparer trois objets. Le système sur puce, ou SoC, est le composant matériel qui regroupe notamment le processeur et plusieurs fonctions de la plateforme. La Boot ROM désigne une mémoire de démarrage contenant du code initial. La mémoire flash conserve des contenus persistants qui peuvent, selon les zones et les autorisations, être mis à jour. Il serait donc trompeur de présenter « la puce », « le firmware » et « le système » comme un seul élément interchangeable.

Du premier code au système en fonctionnement

Cette séquence peut se lire ainsi :

Le constructeur distingue aussi le contrôle d’une mise à jour avant son installation et les vérifications effectuées au démarrage. Ces contrôles interviennent à des moments différents du cycle de vie. La séquence ci-dessus décrit le principe publié ; elle ne constitue pas une cartographie exhaustive de tous les modèles. [2]

Le chargeur ne se limite pas à une décision de sécurité : il prépare aussi le lancement du système, notamment en organisant le chargement des éléments nécessaires. Le noyau prend ensuite en charge les ressources matérielles et l’exécution des processus. Le système de fichiers racine contient les éléments logiciels de base dont les services ont besoin. La vérification relie ces fonctions successives au lieu de supposer que tout contenu lu sur le stockage est digne de confiance.

Vérifier le stockage sans tout relire au même instant

La présentation en étapes ne signifie pas nécessairement que l’intégralité d’un système de fichiers est lue et vérifiée avant le lancement du premier service. Dans Linux, dm-verity illustre une autre possibilité : vérifier les blocs d’un volume en lecture seule à mesure qu’ils sont lus, au moyen d’une structure d’empreintes dont la valeur racine doit être digne de confiance. La protection combine alors une référence authentifiée et des contrôles au moment des accès. Il s’agit ici d’un exemple de mécanisme, sans affirmer son emploi dans un modèle Axis précis. [11]

Cette nuance aide à lire les fiches techniques : « système de fichiers vérifié » décrit une propriété recherchée, mais il faut encore préciser les volumes couverts, les références protégées et le comportement en cas d’erreur. Les paramètres modifiables et les enregistrements vidéo peuvent relever de protections distinctes de celles appliquées aux composants logiciels.

04

Une tentative de remplacement du logiciel

Prenons une caméra installée à l’entrée d’un site. Dans ce scénario pédagogique, une personne cherche à remplacer une partie de son logiciel pour ajouter une transmission vidéo vers une destination non autorisée. Supposons qu’elle dispose effectivement d’un moyen d’écriture sur le stockage : cette hypothèse ne décrit pas une capacité acquise sur un produit particulier.

Sur une architecture qui chargerait aveuglément ce stockage, le logiciel remplacé pourrait être exécuté au redémarrage. Avec une chaîne de vérification correctement appliquée, modifier les octets d’un composant signé invalide sa signature. Sans une signature acceptable par la politique de l’équipement, ce composant doit être refusé. Cela suppose notamment que le vérificateur et sa référence de confiance n’aient pas eux-mêmes été contournés. [3]

Le résultat attendu n’est donc pas « la caméra détecte toutes les intentions malveillantes ». Il est plus précis : elle refuse d’exécuter le composant altéré parce qu’il ne satisfait plus au contrôle d’authenticité et d’intégrité. Selon sa conception, elle peut interrompre le démarrage ou engager une procédure de récupération prévue à cet effet.

Dans notre scénario, le point de refus dépend du composant altéré. Une modification du chargeur doit être détectée avant son exécution ; une modification d’un élément situé plus loin doit être traitée par le mécanisme chargé de cet élément. Une étape validée ne donne pas automatiquement une autorisation à tout ce qui suit : la couverture doit se prolonger jusqu’aux composants que l’on entend protéger.

Il faut également distinguer ce remplacement de logiciel d’un changement de configuration. Si une personne utilise un compte administrateur compromis pour modifier une destination vidéo autorisée par l’application, le démarrage sécurisé peut rester parfaitement valide. Le problème se situe alors dans les droits d’accès et la configuration. La chaîne de démarrage répond à un modèle de menace précis ; elle ne remplace pas le contrôle des usages.

Pour l’exploitant, ce refus peut provoquer une indisponibilité visible. Il faut la traiter comme un événement de sécurité et de continuité de service : préserver les éléments utiles au diagnostic, organiser une couverture de remplacement et restaurer une version autorisée selon la procédure du fabricant. Désactiver le contrôle pour retrouver rapidement une image ferait perdre la garantie recherchée.

05

Firmware BIOS UEFI et démarrage embarqué

Ces termes sont souvent présentés ensemble parce qu’ils peuvent intervenir avant le lancement du système. Ils ne désignent pourtant ni la même chose, ni le même niveau de l’architecture. Pour éviter la confusion, il faut partir du rôle de chacun et revenir ensuite au cas de la caméra.

Le firmware désigne du logiciel embarqué

Le firmware est un terme général pour des logiciels étroitement associés au fonctionnement d’un matériel. Un ordinateur peut en contenir plusieurs : firmware de plateforme, de contrôleur de stockage ou de carte réseau, par exemple. Certains restent actifs après le lancement du système principal. [1]

Dans le vocabulaire commercial des équipements connectés, une « mise à jour du firmware » peut aussi désigner un paquet regroupant plusieurs couches logicielles. Il faut donc examiner son contenu réel : met-il à jour le chargeur, le noyau, les applications, ou seulement certains de ces éléments ? Le mot firmware ne permet pas, à lui seul, de déterminer le périmètre de la mise à jour ou de sa signature.

Le BIOS historique correspond à un modèle de démarrage de PC

Le BIOS, Basic Input/Output System, est associé au modèle historique des ordinateurs compatibles PC. Son implémentation initialise le matériel, effectue des vérifications de démarrage et transmet le contrôle à un code d’amorçage. Cette fonction le place dans la famille des firmwares, mais elle ne fait pas de BIOS un synonyme de tous les firmwares existants. [4]

Le terme reste parfois utilisé, par habitude, pour parler de l’écran de configuration d’un ordinateur moderne. Cela ne suffit pas à identifier l’architecture réellement utilisée. De la même manière, qualifier de « BIOS » le premier programme d’une caméra masque des différences que l’on cherche précisément à comprendre.

UEFI définit une interface mise en œuvre par un firmware

UEFI, Unified Extensible Firmware Interface, est une spécification qui décrit les échanges entre le firmware de la plateforme, le chargeur du système et le système d’exploitation. Elle définit notamment des structures de données et des services. Le constructeur fournit une implémentation de ces interfaces dans son firmware : il faut distinguer la spécification du code qui la réalise. [9]

Dire qu’UEFI a succédé au BIOS historique sur de nombreux PC constitue un repère utile. Dire qu’UEFI est simplement un BIOS avec une interface graphique serait insuffisant : l’évolution concerne l’architecture et les interfaces de démarrage. UEFI n’est pas non plus réservé aux PC x86 ; la spécification couvre plusieurs architectures et peut être utilisée dans des serveurs ou des systèmes embarqués. [4, 9]

UEFI Secure Boot est une fonction de contrôle

Dans cet environnement, UEFI Secure Boot contrôle l’admissibilité des images exécutables concernées, notamment des applications et des pilotes UEFI ainsi que le chargeur du système. Le firmware applique une politique fondée sur des éléments de confiance et des exclusions. La présence d’UEFI ne prouve donc pas, à elle seule, que Secure Boot est actif ni correctement configuré. [5]

Le contrôle du chargeur ne décrit pas non plus toute la protection de la plateforme. La protection du firmware UEFI lui-même et la poursuite des vérifications dans le système d’exploitation doivent être examinées séparément. Dans Windows, par exemple, Trusted Boot prolonge les contrôles vers le noyau et les composants de démarrage. Ce nom désigne un mécanisme Windows ; il ne faut pas l’appliquer automatiquement à une caméra Linux. [6]

Le cas embarqué repose sur sa propre architecture

La caméra étudiée se comprend à partir de la chaîne publiée par son fabricant : Boot ROM, chargeur, noyau et système de fichiers. Il n’est pas nécessaire d’y introduire une étape « BIOS » ou « UEFI » pour expliquer son fonctionnement. Ce serait ajouter un composant que la description retenue n’établit pas.

Inversement, un système embarqué peut utiliser UEFI. L’opposition « ordinateur égale UEFI, caméra égale absence d’UEFI » serait donc fausse. La distinction pertinente porte sur l’implémentation réelle. Le démarrage sécurisé est un principe de contrôle de l’exécution ; UEFI Secure Boot en est une réalisation dans un environnement défini. D’autres plateformes construisent leurs vérifications avec d’autres mécanismes. [9, 10]

Le TPM apporte des services cryptographiques complémentaires

Le TPM, Trusted Platform Module, fournit des fonctions protégées pour les clés, les opérations cryptographiques et les mesures de plateforme. Il peut être réalisé par un composant distinct ou par une implémentation intégrée adaptée. Il ne remplace ni le processeur, ni le firmware de démarrage, ni le chargeur du système. Le fait d’en posséder un ne démontre pas que ses capacités sont exploitées par la plateforme. [7, 12]

UEFI Secure Boot n’a pas besoin, par principe, d’un TPM pour vérifier ses signatures. Un TPM ne décide pas non plus spontanément quel système doit démarrer : les logiciels et la politique de la plateforme utilisent ses services. Il peut contribuer à une architecture de confiance, notamment pour les mesures et leur attestation, sans être à lui seul toute la racine de confiance. [5, 12]

Dans le cas de la caméra, il faut ainsi poser deux questions distinctes : quel mécanisme autorise le code à s’exécuter, et quel mécanisme protège les secrets ou les preuves de l’équipement ? Un élément sécurisé, un TPM ou un environnement d’exécution isolé peut participer à la seconde fonction. Sa présence ne permet pas de déduire automatiquement la réponse à la première.

Les rôles à distinguer

06

Vérifier mesurer et attester

Le vocabulaire de la confiance recouvre trois opérations complémentaires. Les distinguer permet de comprendre à la fois la protection apportée par le démarrage et les preuves que l’on peut en tirer.

Vérifier avant de transmettre le contrôle

Le démarrage sécurisé applique une décision d’autorisation : le composant satisfait-il aux règles nécessaires pour être exécuté ? Le refus doit intervenir avant que ce composant puisse prendre le contrôle dans le chemin protégé. L’efficacité dépend donc de la couverture de la chaîne, mais aussi de l’absence d’un chemin alternatif permettant de lancer le même code sans contrôle.

Mesurer pour conserver une représentation du démarrage

Measured Boot consiste à produire des mesures cryptographiques de composants ou de paramètres. Avec un TPM, elles peuvent alimenter les Platform Configuration Registers, ou PCR. Ceux-ci conservent des valeurs cumulatives ; ils ne contiennent pas une copie du logiciel. Un journal d’événements décrit les mesures associées. Dans les chemins pris en charge par U-Boot, le périmètre mesuré dépend notamment des fonctions activées et du type de démarrage. [13]

Le code de démarrage produit les mesures et sollicite le TPM ; le TPM ne parcourt pas de manière autonome toute la mémoire pour découvrir ce qui s’exécute. La confiance dépend donc aussi de la fiabilité du mécanisme de mesure. Une plateforme peut enregistrer un état différent sans l’interdire : le démarrage mesuré n’est pas, à lui seul, une politique de blocage. [12, 13]

Attester pour permettre une décision extérieure

L’attestation présente des éléments vérifiables à un tiers chargé de les évaluer. Celui-ci examine leur provenance, leur contenu et leur conformité à une politique. Dans une solution fondée sur un TPM, des éléments signés liés aux PCR peuvent être rapprochés du journal et des références attendues. Une preuve cryptographique doit être interprétée ; elle ne signifie pas automatiquement « appareil totalement sain ». [6, 14]

La fraîcheur compte également. Un défi imprévisible, ou nonce, peut lier une réponse signée à une demande récente et limiter le rejeu d’une ancienne réponse. Mais une réponse nouvellement signée peut contenir des mesures produites au démarrage, donc plus anciennes. Elle ne démontre pas à elle seule l’absence de compromission survenue depuis. Le périmètre et la période couverts doivent rester explicites. [14]

Prenons une conséquence pratique : après une mise à jour autorisée, une mesure change. Le service d’évaluation doit reconnaître les versions admises ou disposer d’une procédure pour actualiser ses références ; sinon, il risque de traiter une évolution légitime comme une anomalie. À l’inverse, accepter sans examen toute nouvelle mesure supprimerait l’intérêt du contrôle.

Dans le cas de la caméra présenté ici, la documentation de démarrage sécurisé ne suffit pas à présumer un service d’attestation distante du démarrage déjà intégré à la supervision. Une identité certifiée, une clé protégée et une preuve de démarrage répondent à des questions différentes. Le cahier des charges doit préciser la propriété recherchée et la manière dont elle sera vérifiée.

07

Les limites de la confiance au démarrage

Un logiciel signé peut contenir une vulnérabilité. La signature atteste une autorisation et protège l’intégrité du contenu couvert ; elle ne constitue pas un audit de sécurité du code. Il serait donc incorrect de conclure qu’une caméra devient invulnérable une fois sa chaîne de démarrage vérifiée.

La clé de signature et la chaîne de production du fournisseur deviennent donc des dépendances importantes. Si un code dangereux est signé par une autorité encore admise, la signature peut être mathématiquement valide. La question se déplace alors vers la protection des clés, la validation des versions, la révocation et la capacité du parc à recevoir les changements de politique nécessaires. C’est une raison de traiter le démarrage sécurisé comme une composante de la sécurité du cycle de vie, plutôt que comme une garantie isolée.

Une ancienne version officiellement signée peut également rester dangereuse. La protection contre le retour à une version antérieure, ou anti-rollback, traite ce risque distinct. Android Verified Boot fournit un exemple documenté d’association entre chaîne de vérification et protection contre la rétrogradation. Cette propriété doit être vérifiée pour l’équipement retenu, sans la déduire de la seule mention Secure Boot. [8]

La couverture exacte du contrôle compte tout autant. Vérifier les composants du démarrage ne démontre pas que chaque paramètre modifiable, chaque compte ou chaque application ajoutée est correctement protégé. Une caméra qui démarre avec le logiciel attendu peut encore être mal configurée ou administrée avec des identifiants compromis. La protection doit donc continuer pendant son fonctionnement.

Une autre limite tient à la différence entre le contenu stocké et le comportement en cours d’exécution. Un logiciel conforme au démarrage peut ensuite être affecté par l’exploitation d’une vulnérabilité. L’authentification de son origine ne remplace donc pas les mises à jour, la réduction des services exposés, la segmentation réseau et la surveillance des comportements. De même, la résistance à un adversaire disposant d’un accès physique dépend des protections concrètes du matériel et des interfaces de maintenance.

Enfin, le démarrage vérifié et l’authenticité d’une vidéo sont deux sujets distincts. Une preuve portant sur le logiciel chargé ne prouve pas, à elle seule, qu’un fichier vidéo exporté n’a jamais été retouché. Chaque garantie doit être rattachée à son objet exact : logiciel, identité, configuration, donnée ou opération.

08

Les exigences à poser avant un déploiement

Pour un exploitant, un intégrateur ou un responsable de la sécurité, cette analyse peut se traduire en questions vérifiables avant l’achat et lors de la réception. Une mention commerciale doit conduire à demander une description de l’architecture, de son périmètre et de ses limites. Je retiendrais les exigences suivantes :

• Identifier le point de départ de la confiance : quels composants et quelles références sont protégés, et par quels moyens ?
• Décrire les éléments effectivement vérifiés : chargeur, noyau, système de fichiers, logiciels additionnels et paramètres critiques.
• Documenter les mises à jour : contrôle de signature, versions admises, traitement des clés compromises et éventuelle protection anti-rollback.
• Préciser les possibilités de désactivation : qui peut modifier la politique de démarrage et comment ces changements sont-ils autorisés et tracés ?
• Préparer le traitement des échecs : signalement, accès au diagnostic, restauration authentifiée et maintien du service de surveillance.
• Évaluer le support dans la durée : correctifs, fin de maintenance, documentation accessible et conditions de remplacement du matériel.

La réception devrait aussi prévoir des vérifications encadrées, compatibles avec les procédures du fabricant et la disponibilité attendue. L’objectif est de confirmer les propriétés annoncées sur la version réellement déployée. Un équipement de laboratoire ou de préproduction permet d’évaluer le comportement face à un paquet de mise à jour refusé sans exposer un service essentiel.

La réponse à un échec doit être conçue avec la protection elle-même. Le NIST organise la résilience du firmware autour de la protection, de la détection et de la récupération. Pour une caméra, cette approche oblige à penser simultanément l’intégrité de l’équipement et la continuité de la surveillance. [1]

J’ajouterais une exigence d’exploitation : identifier qui prend la décision lorsqu’une caméra échoue à une vérification ou ne fournit plus les preuves attendues. L’équipe qui gère les images, celle qui administre le réseau et celle qui traite les incidents doivent disposer d’une procédure commune. Sans cette préparation, un mécanisme techniquement pertinent peut être désactivé sous la pression du retour au service.

09

Ce que je retiens

Ce sujet change la manière de regarder les équipements connectés. Une caméra est souvent jugée à travers ce qu’elle montre. Pourtant, une partie de la confiance qu’on lui accorde dépend d’opérations invisibles, réalisées avant l’apparition de la première image.

La racine de confiance fournit le point d’ancrage de fonctions de sécurité déterminées. La chaîne de confiance prolonge ces fonctions vers d’autres composants. Dans le démarrage examiné ici, elle doit empêcher que du code non autorisé prenne le contrôle par le chemin protégé. Son intérêt tient à cette propriété précise et vérifiable, pas à une promesse générale d’invulnérabilité.

À mes yeux, la bonne question n’est pas seulement de savoir si un équipement possède une puce de sécurité ou une fonction Secure Boot. Il faut demander ce que ces mécanismes protègent réellement, quelles hypothèses ils supposent et ce que l’organisation pourra faire lorsqu’une vérification échouera.

Cette lecture relie la conception du matériel aux décisions d’exploitation : choix du fournisseur, maîtrise des versions, maintenance, supervision et récupération. La confiance technique devient utile lorsqu’elle peut être conservée, évaluée et rétablie pendant toute la vie de l’équipement.

Avant de faire confiance à ce qu’un appareil nous montre, il faut comprendre sur quoi repose la confiance accordée au logiciel qui le fait fonctionner.

10

Références et méthode

Cet article est une analyse technique et pédagogique fondée sur des documents publics de référence. La chaîne de caméra est issue de la documentation Axis ; les exemples UEFI, Windows, Trusted Firmware-A, U-Boot, Linux et Android éclairent des mécanismes distincts, sans être attribués à ce produit. Le scénario d’altération et les recommandations d’exploitation sont des développements explicatifs de l’auteur. Il ne s’agit ni d’une expérimentation personnelle, ni d’une vulnérabilité nouvelle, ni d’une évaluation indépendante d’un produit Axis. Les capacités exactes doivent être confirmées pour chaque modèle, version et configuration.

[1] NIST — SP 800-193, Platform Firmware Resiliency Guidelines, mai 2018.

[2] Axis Communications — Axis Edge Vault, livre blanc, mars 2026.

[3] U-Boot — U-Boot Verified Boot, documentation technique.

[4] UEFI Forum — UEFI FAQs.

[5] Microsoft Learn — Secure boot, documentation constructeur.

[6] Microsoft Learn — Secure the Windows boot process.

[7] Trusted Computing Group — Trusted Platform Module.

[8] Android Open Source Project — Verified Boot.

[9] UEFI Forum — UEFI Specification 2.11, Introduction et architecture.

[10] Trusted Firmware-A — Trusted Board Boot, principes et chaîne de vérification.

[11] Linux Kernel — dm-verity, vérification des volumes par blocs.

[12] Microsoft Learn — Trusted Platform Module Technology Overview.

[13] U-Boot — Measured Boot, périmètre et configuration.

[14] IETF — RFC 9334, Remote ATtestation procedureS Architecture, 2023.