Provisioning sécurisé en usine : PKI pour l'IoT industriel

Chaque appareil connecté a besoin d'une identité unique pour être reconnu par votre cloud. Mais comment donner leur identité à 100 000 appareils sans compromettre la sécurité à l'usine ? Voici le playbook que nous utilisons.

Le problème : de la puce anonyme à l'appareil de confiance

Un microcontrôleur sort de la fonderie sans identité. Il lui faut :

• Une paire de clés cryptographiques unique (clé privée jamais extractible)
• Un certificat signé par votre Autorité de Certification (CA)
• Une configuration initiale (URL serveur, credentials réseau, etc.)

Et tout cela doit se passer à l'usine, souvent chez un sous-traitant fabricant, potentiellement dans un autre pays. Comment faire sans :

• Divulguer votre clé privée de CA
• Permettre à des ouvriers de l'usine de voler des clés
• Permettre à des contrefaçons de se provisionner elles-mêmes

L'approche naïve (à ne pas faire)

Envoyer une clé USB à l'usine avec votre clé privée CA. Demander aux ouvriers de générer des certificats par appareil. Problème : la clé CA se retrouve dans une usine à Shenzhen, accessible à toute personne ayant un accès physique. Toute votre gamme peut être clonée.

L'approche correcte : Hardware Security Modules (HSM)

La clé privée CA ne quitte jamais un HSM — un appareil hardware résistant aux altérations. Deux patterns principaux :

Pattern 1 : HSM à l'usine

Un HSM connecté (Thales, Utimaco, AWS CloudHSM) est déployé physiquement à l'usine. Chaque appareil génère sa propre paire de clés localement (via son secure element), envoie une CSR (Certificate Signing Request) au HSM, reçoit un certificat signé. La clé CA ne quitte jamais le HSM.

Compromis : nécessite la présence physique d'un HSM (coût, logistique), fonctionne hors ligne (bon pour les usines sans bonne connectivité cloud).

Pattern 2 : HSM cloud avec provisioning borné

Le HSM vit dans votre cloud (AWS CloudHSM, Azure Key Vault HSM). La station de provisioning de l'usine a un credential limité dans le temps pour demander des certificats. Chaque requête est authentifiée et rate-limitée.

Compromis : nécessite une bonne connectivité cloud à l'usine, mais plus facile à gérer centralement et auditer.

Secure Elements : l'exigence côté appareil

Même avec une CA solide, chaque appareil doit protéger sa propre clé privée. Cela nécessite un Secure Element (SE) ou une sécurité hardware intégrée :

• SE discret : NXP A1006, Infineon Optiga, ATECC608A. Coût : 0.30-1.50 € par appareil.
• Intégré dans le MCU : Microchip CryptoAuth, NXP MCUXpresso, STM32 avec TrustZone
• Intégré dans le module cellulaire : Quectel, Telit, u-blox avec SE embarqué

Le SE génère la clé privée en interne ; elle n'existe jamais en mémoire logicielle. Compromettre un appareil ne compromet que cet appareil.

Le flux complet de provisioning

1. Le SE génère la clé privée + le CSR sur l'appareil
2. La station d'usine collecte le CSR, l'envoie au HSM (local ou cloud) pour signature
3. Le HSM vérifie l'autorisation de la station, signe le certificat
4. Le certificat est réécrit dans le SE de l'appareil
5. L'appareil est ajouté au système de gestion de flotte, prêt à expédier

Audit et révocation

À prévoir dès le jour 1 :

• Chaque certificat provisionné est logué avec numéro de série, timestamp, lieu d'usine
• Les Certificate Revocation Lists (CRLs) ou OCSP permettent de révoquer les appareils compromis
• Audits trimestriels pour vérifier que les logs de provisioning correspondent aux quantités expédiées