Identité & authentification device¶

Donner à chaque device IoT une identité cryptographique unique et vérifiable — la fondation de la confiance dans les communications machine-à-machine.

Pourquoi chaque device doit avoir sa propre identité¶

Les systèmes IoT traditionnels utilisent des credentials partagés : un même mot de passe MQTT pour cent devices, ou un certificat de groupe pour toute une flotte. Cette approche crée un point de défaillance catastrophique — la compromission d'un seul device expose tous les autres.

L'identité individuelle par device garantit :

• Isolation : la compromission d'un device ne compromet pas les autres
• Révocation ciblée : désactiver un device spécifique sans impacter le reste de la flotte
• Auditabilité : chaque action est associée à un device précis (non-répudiation)
• Confiance mutuelle : le cloud sait avec certitude à quel device il parle, et vice versa

Certificats X.509 par device¶

Le standard X.509 est la base de l'identité PKI. Chaque device dispose d'un certificat unique contenant :

Certificate:
    Subject: CN=device-a3f9b1c2, O=ACME Industrial, OU=Factory-Lyon-01
    SubjectAltName: URI:urn:iot:device:a3f9b1c2-d4e5-f6a7-b8c9
    Issuer: CN=ACME IoT Device CA, O=ACME Industrial
    Validity: 2026-04-15 → 2031-04-15 (5 ans)
    PublicKey: EC P-256
    Extensions:
        ExtendedKeyUsage: clientAuth
        DeviceType: EXT-SENSOR-V2 (custom OID)
        FirmwareVersion: 2.4.1 (custom OID)

Hiérarchie PKI IoT typique¶

graph TB
    ROOT["CA Racine\nRoot CA\n(hors ligne, HSM dédié)\nValidité : 20 ans"]
    SUBCA_MFG["CA Fabrication\nManufacturing CA\nValidité : 10 ans"]
    SUBCA_OPS["CA Opérations\nOperational CA\nValidité : 5 ans"]
    CERT_DEV["Certificat Device\nCN=device-a3f9b1c2\nValidité : 5 ans"]
    CERT_GW["Certificat Gateway\nCN=gw-lyon-01\nValidité : 3 ans"]
    CERT_SRV["Certificat Serveur\nCN=iot.acme.com\nValidité : 1 an"]

    ROOT -->|"signe"| SUBCA_MFG
    ROOT -->|"signe"| SUBCA_OPS
    SUBCA_MFG -->|"signe à la fabrication"| CERT_DEV
    SUBCA_OPS -->|"signe au déploiement"| CERT_GW
    SUBCA_OPS -->|"signe"| CERT_SRV

    style ROOT fill:#1a237e,color:#fff
    style SUBCA_MFG fill:#283593,color:#fff
    style SUBCA_OPS fill:#303f9f,color:#fff
    style CERT_DEV fill:#3949ab,color:#fff
    style CERT_GW fill:#3f51b5,color:#fff
    style CERT_SRV fill:#5c6bc0,color:#fff

La CA racine est maintenue hors ligne (air-gapped) dans un HSM physique. Elle ne signe que les CA intermédiaires, jamais directement les certificats devices.

Provisioning zero-touch¶

Le provisioning zero-touch permet d'injecter automatiquement des identités cryptographiques dans les devices à la fabrication ou au premier démarrage, sans intervention manuelle.

Flux de provisioning à la fabrication¶

sequenceDiagram
    participant FAB as Ligne de fabrication
    participant HSM as HSM Manufacturing CA
    participant SEC as Secure Element (ATECC608)
    participant DB as Device Registry
    participant CLOUD as IoT Cloud Platform

    FAB->>SEC: Générer paire de clés EC P-256\n(clé privée non extractible)
    SEC-->>FAB: Clé publique device (CSR)
    FAB->>HSM: Signer certificat device\n(CSR + métadonnées)
    HSM-->>FAB: Certificat X.509 signé
    FAB->>SEC: Injecter certificat + CA chain
    FAB->>DB: Enregistrer {device_id, cert_thumbprint, hardware_revision}
    DB->>CLOUD: Pré-provisionner device dans le registre IoT
    CLOUD-->>DB: ACK + configuration initiale

    Note over FAB,CLOUD: Le device quitte la ligne avec\nune identité unique prête à l'emploi

Protocoles de provisioning réseau¶

Quand le provisioning à la fabrication n'est pas possible (devices tiers, remplacemen terrain), des protocoles réseau standardisés prennent le relai :

Provisioning zero-touch industriel (DPS)¶

Les grands cloud IoT proposent des services de provisioning automatique :

mTLS (mutual TLS) device-to-cloud¶

Le mTLS est le standard de connexion sécurisée entre device IoT et cloud. À la différence du TLS classique (seul le serveur s'authentifie), le mTLS authentifie les deux parties.

Handshake mTLS¶

sequenceDiagram
    participant C as Client (Device)
    participant S as Serveur (IoT Platform)
    C->>S: ClientHello (TLS 1.3)
    S->>C: ServerHello + ServerCertificate
    Note right of C: cert serveur vérifié
    C->>S: ClientCertificate
    Note left of S: cert device, signé par Device CA
    S->>C: CertificateVerify + Finished
    C->>S: Finished
    rect rgb(200, 230, 200)
        Note over C,S: Canal chiffré mTLS<br/>MQTT/TLS ou HTTPS authentifié mTLS
    end

Vérifications côté serveur :

1. La chaîne de certification est valide (jusqu'à la CA racine connue)
2. Le certificat n'est pas révoqué (CRL ou OCSP)
3. L'identité dans le certificat (CN ou SAN) correspond au device ID enregistré
4. La date de validité est dans les limites

Rotation des credentials¶

La durée de vie d'un certificat device doit être calculée en fonction du risque et des contraintes opérationnelles :

Renouvellement automatique (auto-renewal)¶

Le device initie lui-même le renouvellement avant expiration (90 jours avant) via EST ou l'API propriétaire cloud. Le processus :

1. Le device détecte que son certificat expire dans < 90 jours
2. Génère une nouvelle paire de clés dans le secure element
3. Construit un CSR signé par le certificat actuel (preuve de possession)
4. Envoie le CSR au serveur EST (authentifié par l'ancien certificat mTLS)
5. Reçoit le nouveau certificat, le stocke dans le secure element
6. Continue avec le nouveau certificat à l'expiration de l'ancien

Révocation des certificats¶

La révocation permet de couper l'accès réseau d'un device compromis ou volé sans attendre l'expiration naturelle du certificat.

CRL (Certificate Revocation List)¶

La CA publie une liste signée des certificats révoqués. Les vérificateurs téléchargent périodiquement la CRL.

• Avantage : simple, fonctionne hors ligne
• Inconvénient : délai de propagation (la CRL est mise à jour toutes les N heures), taille croissante

OCSP (Online Certificate Status Protocol)¶

Le vérificateur interroge un répondeur OCSP en temps réel pour connaître le statut d'un certificat spécifique.

• Avantage : révocation quasi-instantanée, réponse granulaire
• Inconvénient : dépendance réseau, latence supplémentaire, point de défaillance

OCSP Stapling pour IoT¶

Sur les devices avec connectivité intermittente, l'OCSP stapling permet au device de pré-télécharger la réponse OCSP et de la présenter au serveur, évitant que le serveur n'ait besoin de contacter le répondeur OCSP en direct.

Stratégie de révocation recommandée¶

flowchart TD
    INCIDENT["Device compromis\nou volé signalé"]
    REVOKE["Révoquer certificat\ndans la CA"]
    CRL["Publier CRL mise à jour\n(propagation < 1h)"]
    OCSP["Mettre à jour OCSP\n(instantané)"]
    POLICY["Politique broker MQTT :\nRefus de connexion\nsi cert révoqué"]
    AUDIT["Logger l'événement\n+ alerter SOC"]
    REPROV["Décider : re-provisionner\nou décommissionner"]

    INCIDENT --> REVOKE
    REVOKE --> CRL
    REVOKE --> OCSP
    CRL --> POLICY
    OCSP --> POLICY
    POLICY --> AUDIT
    AUDIT --> REPROV

Gestion du cycle de vie complet¶

Ce qu'il faut retenir¶

• Chaque device doit avoir une identité cryptographique unique — jamais de credentials partagés.
• La clé privée doit être générée dans le secure element et ne jamais le quitter.
• Le mTLS est le standard pour les communications device-to-cloud : les deux parties s'authentifient.
• Prévoir la rotation des certificats dès la conception — un certificat qui ne peut pas être renouvelé OTA est un risque opérationnel.
• La révocation doit être instantanée : OCSP + politique de blocage immédiat sur le broker.

Chapitre suivant : Conformité & normes — naviguer dans le paysage réglementaire IoT : IEC 62443, ETSI EN 303 645, NISTIR 8259A et RGPD.