14.4.6. Exploitation : clés, expiration et dépannage

Trois aspects du travail sur les certificats concernent chaque appareil déployé : protéger la clé privée une fois qu’elle se trouve sur la caméra, anticiper le jour où le certificat expirera, et la courte liste des modes d’erreur que l’on rencontre en pratique.

14.4.6.1. Protéger la clé privée

Chaque fois que la caméra présente un certificat – en tant que serveur TLS, ou en tant que client dans le cadre du mTLS – sa clé privée doit résider sur l’appareil, en clair au format DER, dans le système de fichiers ou dans ROMFS. Stockée ainsi, elle est lisible par tout code s’exécutant sur la caméra et par quiconque y a un accès physique : le lecteur de stockage de masse USB, une invite REPL ou la mémoire flash brute. ROMFS et les indicateurs de lecture seule empêchent la modification, pas l”extraction. Considérez toute clé privée livrée sur un appareil comme récupérable par un attaquant déterminé disposant d’un accès physique ou au code.

Cela ne rend pas TLS inutile – cela conditionne la façon dont vous le déployez :

• Utilisez une clé et un certificat uniques par appareil. Ne programmez jamais une seule clé partagée sur l’ensemble du parc : l’extraire d’une seule unité permettrait alors à un attaquant d’usurper l’identité de chaque caméra. Des clés propres à chaque appareil limitent une compromission à cet appareil unique, que vous pouvez révoquer ou désactiver côté serveur.

• Gardez des certificats à courte durée de vie. Une clé volée n’est utile que tant que son certificat est valide ; des durées de vie courtes associées à une rotation régulière limitent les dégâts (voir Expiration et rotation des certificats ci-dessous).

• Évitez autant que possible de placer un secret sur l’appareil. Si vous n’avez besoin de vérifier que le serveur (authentification du serveur, et non mTLS), la caméra agissant comme client ne stocke que le certificat de l’autorité de certification (CA) – qui est public – et ne détient aucune clé privée qui vaille la peine d’être volée.

• Ne livrez jamais une clé dans une image de micrologiciel publique. Une clé intégrée dans ROMFS au sein d’une version de micrologiciel que vous distribuez n’est pas secrète ; quiconque télécharge le micrologiciel la possède. Le provisionnement par appareil consiste à programmer la clé après le micrologiciel générique, et non à l’intérieur de celui-ci.

• Limitez le rayon d’impact. Restreignez la portée de ce que le certificat authentifie (moindre privilège) et assurez-vous qu’une identité d’appareil compromise puisse être révoquée ou désactivée sans affecter les autres.

Si votre modèle de menace inclut des attaquants disposant d’un accès physique, concevez en partant du principe que la clé de l’appareil finira par fuiter et faites en sorte que cela reste viable, plutôt que de supposer qu’elle peut rester secrète sur un matériel qui ne dispose d’aucun moyen pour cela.

14.4.6.2. Expiration et rotation des certificats

Chaque certificat possède une période de validité. Une fois celle-ci dépassée, un pair ssl.CERT_REQUIRED rejette la connexion – l’expiration constitue donc une véritable panne programmée, et non un risque théorique. L’horloge de la caméra doit elle aussi être correcte pour que la vérification de validité soit évaluée de façon fiable.

• Auto-signé. Vous avez choisi la durée de vie avec -days. Lorsqu’elle expire, vous devez régénérer la clé/le certificat et le redéployer : recopier les fichiers DER, ou reconstruire et reprogrammer l’image ROMFS si le certificat y est intégré. Choisissez une valeur -days sur laquelle vous penserez réellement à agir.

• CA publique. Ces certificats sont délibérément à courte durée de vie. Let’s Encrypt émet des certificats de 90 jours et attend un renouvellement automatisé environ tous les 60 jours ; il n’existe pas d’option « installer une fois et oublier ».

La tendance générale est à sens unique : la durée de validité maximale des certificats TLS reconnus publiquement ne cesse de diminuer. Elle était de 825 jours, est actuellement plafonnée à 398 jours, et le CA/Browser Forum a adopté un calendrier qui la réduit progressivement vers environ 47 jours d’ici 2029. La conclusion pour la conception d’un appareil est de supposer que les certificats sont à courte durée de vie et que la rotation doit être automatisée ou au moins routinière – ne livrez pas un produit qui dépend d’un humain remplaçant un certificat de dix ans.

Concrètement, sur la caméra : privilégiez les conceptions où le certificat peut être remplacé sans reprogrammation (un système de fichiers accessible en écriture associé à un chemin de mise à jour à distance, ou l’exécution de la caméra en tant que client faisant confiance à une CA que vous renouvelez de façon centralisée). Si un certificat doit résider dans ROMFS, planifiez les mises à jour du micrologiciel en fonction de sa durée de vie.

14.4.6.3. Dépannage

• L’horloge doit être réglée. Une caméra qui n’a pas réglé son horloge depuis sa mise sous tension échoue à la vérification de validité du certificat – appelez d’abord ntptime.settime().

• Le nom d’hôte doit correspondre. Lorsque le client transmet server_hostname, celui-ci doit correspondre au subjectAltName du certificat (ou au CN sur les piles plus anciennes), faute de quoi la vérification échoue.

• Mauvais format. Un fichier PEM copié sur la caméra ne se chargera pas – convertissez-le d’abord en DER.

• Certificat expiré. Une connexion qui fonctionnait auparavant et qui échoue désormais avec OSError peut simplement avoir un certificat expiré – vérifiez les dates de validité et régénérez/redéployez selon les besoins.

• Les clés Ed25519 échouent. Utilisez ECDSA P-256/P-384 ou RSA, et non Ed25519.

• Les erreurs sont des OSError. MicroPython n’implémente pas ssl.SSLError ; les échecs TLS (certificat invalide, expiré, CA inconnue, erreur de format, échec de la négociation) sont levés sous forme de OSError.