On peut tester un objet connecté fermé. On peut parfois trouver des failles graves. On peut même évaluer sérieusement son niveau de risque. Mais il faut être froid : on ne “vérifie” jamais complètement la sécurité d’un IoT quand son firmware reste propriétaire et inaccessible. Ce qu’on obtient, ce n’est pas une transparence totale. C’est un niveau d’assurance partiel, plus ou moins solide selon ce que le fabricant accepte de montrer, ce que l’appareil laisse observer, et ce que l’expert peut extraire techniquement.
La vraie question n’est donc pas “code fermé = forcément non sécurisé” ou “code propriétaire = on ne peut rien faire”. La vraie question est : quel type d’audit reste possible sans accès au code, et quelles zones resteront inévitablement opaques ?
1) Firmware fermé ne veut pas dire audit impossible
Un firmware propriétaire bloque l’audit source-level, pas toute l’analyse. Un expert peut encore travailler sur plusieurs couches :
- le comportement réseau,
- les interfaces locales (web, Bluetooth, API, ports de debug),
- le mécanisme de mise à jour,
- le firmware binaire s’il peut être extrait,
- les composants tiers identifiables,
- les journaux, certificats, signatures, métadonnées.
Autrement dit, un audit reste possible, mais il devient indirect. On n’inspecte plus le raisonnement interne du produit ligne par ligne ; on observe ses effets, ses entrées/sorties, ses protections et ses défauts de conception. C’est beaucoup moins confortable, mais ce n’est pas vide.
2) Ce qu’un audit sérieux peut vraiment tester sans le code
Sans accès au code source, on peut quand même auditer des points critiques.
Le premier, c’est la surface d’attaque visible : services exposés, authentification, API, ports ouverts, protocoles faibles, chiffrement mal implémenté. Beaucoup de compromissions IoT viennent de là, pas d’un bug ésotérique enfoui dans un module rare.
Le deuxième, c’est le mécanisme de mise à jour. Si un objet ne valide pas correctement le firmware, accepte un downgrade, télécharge en clair, ou applique une mise à jour sans contrôle d’intégrité, il est déjà dans une zone rouge.
Le troisième, c’est la sécurité opérationnelle : gestion des certificats, secrets embarqués, comportement après reboot, persistance, journalisation, réaction à des erreurs réseau, robustesse en cas d’entrées inattendues. Tout cela se teste sans lire le code.
3) Là où le firmware fermé devient un vrai problème
Le code fermé ne bloque pas seulement la curiosité : il bloque la preuve.
Sans source, un auditeur indépendant ne peut pas confirmer facilement :
- l’absence de fonctions cachées,
- la qualité réelle des contrôles d’accès internes,
- la présence d’un composant vulnérable non visible,
- la logique métier exacte qui déclenche certaines actions,
- le traitement correct de tous les cas limites,
- la présence de portes dérobées “commerciales” ou de raccourcis de debug oubliés.
Même si l’objet “a l’air propre” en surface, le cœur peut rester opaque. Et c’est là le point que beaucoup évitent : l’audit d’un firmware propriétaire ressemble souvent plus à une estimation de risque qu’à une vérification exhaustive.
4) L’extraction et la rétro-ingénierie : possible, mais coûteuse et incomplète
Dans certains cas, des experts peuvent extraire le firmware binaire via :
- mises à jour récupérées chez le constructeur,
- ports UART/JTAG/SWD laissés actifs,
- accès physique à la mémoire flash,
- dump depuis le stockage interne,
- récupération via l’application ou l’infrastructure cloud.
Une fois le binaire obtenu, on peut faire de la rétro-ingénierie, identifier des bibliothèques, chercher des chaînes, des clés, des chemins, des routines de vérification, des mécanismes de signature. Cela peut être très efficace pour trouver des erreurs grossières ou des composants datés.
Mais il faut rester lucide : avoir le binaire n’équivaut pas à avoir le code source. Le reverse est long, partiel, parfois rendu difficile par l’obfuscation, le chiffrement, les secure enclaves, les bootloaders verrouillés ou les protections anti-tamper. On peut démontrer une faille. On peut rarement démontrer proprement l’absence de faille.
5) Ce qui remplace partiellement la transparence : preuves de chaîne d’approvisionnement
Quand le code n’est pas ouvert, il faut exiger autre chose que des promesses.
Le minimum crédible, c’est de la traçabilité technique :
- un SBOM sérieux,
- une politique de correctifs claire,
- une documentation des mises à jour,
- des engagements de support,
- des canaux de divulgation de vulnérabilités,
- des journaux d’intégrité et de signature.
Un SBOM ne “prouve” pas que le produit est sûr, mais il réduit l’angle mort sur ce qu’il contient.
Le firmware propriétaire ne devient pas open source pour autant, mais la question n’est plus seulement “faites-nous confiance”. Elle devient : “quelles preuves minimales fournissez-vous pour que cette confiance ne soit pas aveugle ?”
6) Alors, peut-on vraiment vérifier la sécurité ?
La réponse honnête est : partiellement, oui ; totalement, non.
On peut vérifier si l’objet est manifestement mal conçu.
On peut vérifier s’il expose des services absurdes.
On peut vérifier si le mécanisme de mise à jour est fragile.
On peut vérifier s’il embarque des composants visiblement datés.
On peut vérifier s’il résiste à des scénarios d’attaque réalistes.
Mais on ne peut pas, sans accès profond, certifier sérieusement qu’il n’y a rien derrière. Et plus le fabricant refuse :
- la documentation,
- les interfaces de test,
- la politique de vulnérabilité,
- les composants déclarés,
- la durée de support,
plus le message implicite est mauvais : il ne demande pas de la confiance, il exige de la foi.
Conclusion : un firmware fermé peut être testé, mais jamais “blanchi” proprement
Oui, on peut auditer un IoT à firmware propriétaire. Non, on ne peut pas en déduire une sécurité pleinement vérifiée comme si le code était ouvert, documenté et reproductible. Le meilleur audit possible, dans ce contexte, reste un audit de comportement, de chaîne de mise à jour, d’exposition, et de traçabilité.
La bonne question n’est donc pas “est-ce qu’on peut quand même tester ?”. La bonne question est : combien d’opacité un fabricant vous demande d’accepter avant même de mériter votre confiance ?
