07 — Exigences de sécurité fournisseur (firmware des centrales)

Diffusion : interne / confidentiel. Document destiné à être transmis au fabricant du firmware des centrales (INIS-E16) dans le cadre de la relation fournisseur.

1. Objet

Le firmware des centrales est un produit à éléments numériques distinct, développé par une société tierce qui en est le fabricant au sens du CRA. Ce document formalise les exigences de sécurité que Desautel adresse à ce fournisseur, au titre de sa diligence raisonnable (art. 13.5) sur un composant intégré dans sa chaîne.

2. Constat de l'interface Superviseur ↔ centrale

Le Superviseur est un maître Modbus interrogeant les centrales (esclaves) via Modbus TCP/RTU. État factuel :

• Lien en clair, non authentifié, sans intégrité applicative. Modbus TCP sur socket TCP nue (port 502, aucun TLS), Modbus RTU sur port série. Seule protection : le CRC natif du protocole. Aucun HMAC, aucune signature de trame, aucun secret partagé. C'est la nature du protocole Modbus.
• Aucune identité vérifiable de la centrale. Le numéro de série est déclaratif (saisi par l'opérateur), pas prouvé par le matériel. Aucun champ de version de firmware connu du Superviseur, aucun handshake d'identification.
• Écritures de commande non protégées. Les commandes (reset, silence, mise hors service) sont des écritures FC 16 (adresse 500) exécutables par tout maître présent sur le segment, sans contrôle d'accès au niveau du bus.

Conséquence : sur le segment réseau, un tiers peut lire l'ensemble des registres et commander la centrale. Ce risque ne peut pas être levé par le seul Superviseur : il relève du firmware et de l'architecture réseau.

3. Exigences adressées au fabricant firmware

Priorité haute

1. Contrôle d'accès aux commandes. Les écritures sensibles (reset, silence, mise hors service) doivent être soumises à un contrôle d'accès côté firmware (secret partagé, jeton, liste blanche de maîtres), et non exécutées par tout maître présent sur le bus.
2. Identification authentifiée (handshake). Un mécanisme permettant à la centrale de prouver son identité au-delà d'un numéro de série déclaratif, afin d'écarter l'usurpation d'un esclave.
3. Version exposée et vérifiable. Exposer la version firmware/matériel dans un registre Modbus dédié, lisible par le Superviseur, pour détecter une version obsolète, vulnérable ou inattendue.

Priorité moyenne

4. Firmware signé + démarrage vérifié. Les images de firmware signées par le fabricant ; la centrale vérifie la signature avant d'appliquer une mise à jour (secure boot). Idéalement une attestation d'identité et d'intégrité présentable par la centrale.
5. Robustesse et validation des trames. Le firmware valide ses entrées, borne ses valeurs et refuse les trames invalides.
6. Durcissement réseau et kernel. Aucun service réseau inutile exposé, aucun accès kernel/administrateur non nécessaire, segmentation des interfaces (Modbus / CAN / administration), canal de mise à jour firmware signé.
7. Sécurisation du bus CAN interne (entre cartes), le cas échéant : mesures d'intégrité et de contrôle d'accès pertinentes.

Piste protocolaire (si faisable)

8. Modbus/TCP Security (TLS + certificats client) ou passerelle TLS dédiée. C'est la seule réponse protocolaire à l'absence de chiffrement et d'authentification ; elle exige le support des deux extrémités. À défaut, la sécurité repose sur la segmentation réseau (voir mesures compensatoires Superviseur, §5 ci-dessous).

4. Modalités

• Ces exigences sont à inscrire au cahier des charges / au contrat fournisseur et à suivre dans le temps (versions, correctifs).
• Le fabricant firmware est tenu à ses propres obligations CRA sur ce produit ; ces exigences s'articulent avec elles, elles ne s'y substituent pas.
• La transmission formelle de ce document (et son suivi) constitue une preuve de diligence raisonnable à verser au dossier de conformité.

5. Ce qui relève du Superviseur (renvoi)

Les mesures compensatoires mises en œuvre côté Superviseur (segmentation, cohérence de type, journalisation des commandes, documentation du modèle de confiance) sont planifiées séparément : voir ../project/COMPENSATIONS-MODBUS.md. Le risque résiduel « lien Modbus en clair » est tracé dans 02 — Évaluation des risques §3.6.