Pourquoi le provisioning sécurisé a sa place en production
Un appareil connecté livré sans identité doit être provisionné sur le terrain. Le provisioning sur site implique une étape manuelle (ou un auto-enrôlement vulnérable) au moment de l'installation. Les deux génèrent de la complexité opérationnelle et une exposition de sécurité.
Le provisioning en production donne à l'appareil une identité cryptographique unique avant son expédition. L'appareil démarre, s'authentifie et s'enrôle sans intervention manuelle.
Secure elements
Microchip ATECC608 et NXP EdgeLock sont des secure elements répandus pour l'IoT. Tous deux prennent en charge :
- La génération de clé privée ECC à l'intérieur de la puce (la clé n'en sort jamais)
- La signature et la vérification de certificat
- La protection contre le rejeu par compteur
- Un comportement à preuve d'effraction
La ligne de production génère une clé dans le secure element, signe un certificat contre la CA racine, écrit le certificat dans l'appareil et enregistre la clé publique associée au numéro de série.
Enrôlement de certificat X.509
X.509 est le format de certificat standard. L'enrôlement côté production suit généralement ce schéma :
- Le secure element génère une paire de clés ECC (la clé privée reste verrouillée dans la puce)
- Le système de production lit la clé publique
- Le système de production signe le certificat avec la CA racine adossée à un HSM
- Le certificat est réécrit dans l'appareil
- La clé publique et l'empreinte du certificat sont enregistrées avec le numéro de série
La clé privée de la CA racine ne touche jamais la ligne de production. Elle vit dans un HSM, dans un environnement contrôlé.
AWS IoT et Azure DPS
AWS IoT prend en charge le Just-in-Time Provisioning (JITP) et le Multi-Account Registration. Azure Device Provisioning Service (DPS) prend en charge l'attestation X.509, l'attestation par Trusted Platform Module (TPM) et l'attestation par clé symétrique.
Les deux permettent à la ligne de production de préenregistrer les appareils pour qu'ils s'enrôlent automatiquement à la première connexion au cloud. Le workflow côté production :
- L'appareil est provisionné avec un certificat X.509
- L'empreinte du certificat de l'appareil est enregistrée auprès du DPS cloud
- L'appareil démarre sur le terrain, présente son certificat, s'enrôle automatiquement
- Le cloud assigne l'appareil au bon groupe et télécharge la configuration
Une PKI privée suit le même schéma avec une infrastructure interne à la place d'AWS ou d'Azure.
Un workflow de production qui fonctionne
- CA racine adossée à un HSM dans un environnement contrôlé, accédée via une API de signature
- Génération de clé unitaire dans le secure element, sur la ligne
- Signature du certificat via un appel d'API (aucun matériel clé exposé)
- Préenregistrement DPS cloud intégré à l'étape de provisioning
- Enregistrement d'enrôlement unitaire consigné dans la base de production
- Gestion optionnelle d'une liste de révocation pour les appareils en fin de vie ou perdus
Erreurs courantes
- Clé privée de la CA racine stockée sur la ligne de production (et non dans un HSM)
- Même clé gravée dans plusieurs appareils (« mode test parti en production »)
- Empreinte de certificat enregistrée mais pas préenregistrée auprès du DPS cloud
- Workflow de provisioning fait à la main sur quelques unités, jamais passé à l'échelle
Sources
- Documentation AWS IoT Just-in-Time Provisioning
- Documentation Microsoft Azure Device Provisioning Service
- Documentation du secure element Microchip ATECC608
- Documentation du secure element NXP EdgeLock