FIDO Device Onboarding : forces et faiblesses d’un standard IoT

Six étapes pour un déploiement IoT

À l’étape 2, les équipements sont emballés et distribués. À ce moment-là, un fichier texte appelé justificatif de propriété (intitulé Ownership Voucher) est produit. Ce fichier atteste du transfert de propriété entre le fabricant et son client. « Il se présente sous la forme d’une chaîne de clés publiques signées, chaque signature d’une clé publique autorisant le possesseur de la clé privée correspondante à prendre possession du dispositif ou à transmettre la propriété à un autre maillon de la chaîne », peut-on lire dans la documentation.

Dans le principe, il peut enregistrer la trace de passage d’un fabricant, du distributeur, du revendeur, ainsi que du ou des différents propriétaires d’un équipement. La signature dépend des algorithmes RSA ou ECDSA. Les informations de propriété de l’équipement sont chiffrées via les fonctions Hash SHA256 ou SHA384, vérifiées par les HMAC équivalents. En parallèle, ces clés sont envoyées au fournisseur de services cloud ou à un système de device management pendant que le matériel lui-même est acheminé vers l’installateur ou le client.

Puis vient la troisième étape. « Une fois que le fournisseur de cloud ou le gestionnaire de device management a reçu les clés, il enregistre le bien correspondant à la clé dans un service Rendezvous, qui est essentiellement un service de consultation de type DNS », explique David Turner. Ce service Rendezvous dépend d’un serveur.

La quatrième étape coïncide avec le premier démarrage de l’équipement. À ce moment-là, l’objet exécute le code FDO qui émet un appel vers le serveur Rendezvous. Le service Rendezvous fait le lien entre l’appareil et les identifiants de son propriétaire, lui transfère ces informations et lui associe une adresse IP.

Les échanges de clés entre le serveur Rendezvous, les objets connectés et la plateforme sont baptisés « transferts de propriété ». La spécification FDO comprend trois de ces passages de flambeau (TO0, TO1 et TO2), assimilés à des protocoles. Les transferts de propriété, donc le moment où les clés publiques sont ajoutées à la chaîne de confiance, demandent d’adopter les protocoles HTTPS et TLS. « Une fois l’authentification effectuée, ce canal sécurisé est ensuite exploité pour effectuer le provisionnement afin d’établir une connexion sécurisée », précise le directeur.

« Une fois que l’appareil sait où aller, il suit l’étape cinq dans laquelle il communique avec le cloud ou la plateforme IoT sur site. À ce stade, l’équipement et le service de device management partagent leurs clés publiques. C’est une phase d’authentification mutuelle qui permet au service cloud de faire confiance à l’appareil, de s’assurer qu’il s’agit bien de celui que son utilisateur a acheté, mais la machine peut également faire confiance au propriétaire qui essaie de le paramétrer. L’objectif est d’éviter les attaques malveillantes aux deux extrémités du processus », déclare David Turner.

Ce n’est donc que lors de cette cinquième étape que les informations spécifiques et les détails de configuration liés à l’environnement sont fournis. C’est ce que l’Alliance a appelé une liaison tardive (« late binding ») entre les équipements et la plateforme IoT. Une fois provisionnés et authentifiés, les appareils connectés peuvent collecter et envoyer leurs données vers une plateforme cloud. « Les clés initiales utilisées dans les étapes un à cinq sont supprimées à l’étape six et remplacées par un autre jeu de clés fourni par le service cloud », complète le directeur du développement des standards au sein de la FIDO Alliance. À la fin de ce provisionnement, ce sont les services de type KMS ou HSM associés à l’architecture de l’usager qui administrent les certificats et les clés pour protéger les données recueillies.

Avant cela, tous les renseignements concernant l’appareil sont transférés vers le service de device management, désormais uniquement accessible par son propriétaire. Seules les clés OCDeviceInfo et la Hardware Root of Trust ne sont pas changées. Ce qui veut dire que le certificat de naissance de l’équipement est réduit à sa plus simple expression après l’authentification mutuelle avec la plateforme IoT. La FIDO Alliance considère que ces deux éléments fournissent « suffisamment d’informations pour construire un justificatif de propriété avec zéro entrée ».

FDO est plus adapté aux nouveaux projets IoT

Avec cette spécification, tous les équipements doivent être capables de supporter les attestations et les vérifications à l’aide de moyens cryptographiques répondant aux exigences du protocole EAT (Entity Attestation Token). Pour l’attestation des équipements, l’alliance impose l’algorithme ECDSA (Eliptic Curve Digital Signature Algorithm) ou, SDO oblige, le système de signature sous licence apache 2.0, Intel EPID. Les signatures ESCDSA sont basées sur les courbes elliptiques SECP256R1 ou SEC384R1 encodées via COSEX509 ou le plus traditionnel X509. Intel EPID dispose lui aussi de deux variantes algorithmiques.

Cependant, il est à préciser que cette chaîne de confiance n’est valable que si les équipements sont capables de supporter les opérations de chiffrement et que tous les membres de la chaîne se sont entendus sur le choix d’algorithme, pour crypter les attestations des machines IoT et les parafes indiquant le transfert de propriété. En clair, la spécification prévoit plusieurs options de déploiement, mais il ne faut en choisir qu’une pour chaque protocole et service.

Selon Jon Ferguson, Directeur Product Management chez Entrust, cela signifie que ce type de spécification est davantage compatible avec le déploiement d’un nouveau projet IoT. « Il y a la question des déploiements brownfield et greenfield. Les acteurs de ce marché tentent d’abord de résoudre le problème greenfield, parce que c’est plus facile », déclare-t-il. « Entrust associe à son infrastructure PKI un agent à même l’équipement, pour surveiller son comportement tout au long de son cycle de vie ».

FDO ne met pas les architectures PKI au placard

Tout comme Keyfactor, GlobalSign et d’autres éditeurs de solutions mêlant IoT et une infrastructure à clés publiques (PKI), Entrust mise lui sur une identité unique, un certificat de naissance, supposé immuable, placé au sein d’un appareil qu’une technologie de chiffrement peut vérifier quand il se connecte à une passerelle ou à un serveur central. Au lieu d’un justificatif de propriété, les éditeurs de PKI fournissent des certificats basés sur la norme X509.

Avec ce modèle, une autorité centrale signe ou valide les certificats d’origine utilisés tout au long du cycle de vie des équipements. L’autre grande différence avec FDO tient dans le fait que la génération des clés privées et publiques est forcément effectuée depuis un HSM. Les clés privées, ici des certificats d’autorité, sont stockées au sein de ce module matériel renforcé associé à un serveur. Les clés publiques sont embarquées dans une zone sécurisée d’un équipement IoT. Ensuite, un système de type Active Directory (voire AD lui-même) est utilisé pour gérer les politiques d’accès aux clés, de gestions et d’audits. Avec FDO, ce rôle est joué en partie par la plateforme IoT. En clair, une architecture PKI peut jouer également ce rôle d’enrôlement des nouveaux équipements, mais les possibilités sont plus nombreuses. Entrust propose par exemple de vérifier par chiffrement les mises à jour de firmwares IoT. 

Les composants IoT sont encore trop peu robustes

Si la spécification FDO recommande de stocker les clés publiques au sein d’une zone sécurisée de l’appareil et les clés privées au sein d’une zone protégée d’un serveur, ce choix est « laissé à l’utilisateur final ». « Il y a beaucoup de variations possibles. La façon dont vous [stockez les clés] ne fait pas partie de notre spécification », déclare David Turner.

« Il y a beaucoup de variations possibles. La façon dont vous [stockez les clés] ne fait pas partie de notre spécification ».

« Les clés peuvent être stockées n’importe où sur le dispositif, que ce soit dans un élément matériel ou logiciel renforcé (de type Trusted Platform Module – TPM ou Trusted Execution Environnement) ou dans un dossier du système de fichiers, potentiellement le moins sécurisé possible. Ainsi, l’une des considérations lors de l’achat d’un dispositif est de savoir si celui-ci est sécurisé. Alors que le protocole lui-même peut être sécurisé, le dispositif peut ne pas être aussi robuste que vous le souhaitez », reconnaît-il. La documentation de SDO est plus stricte et assure que les clés privées doivent être stockées soit dans un élément TPM, soit dans un HSM séparé.

Pour mitiger ce risque, la FIDO Alliance propose des certifications payantes aux fabricants d’équipements. Ces procédures devraient comprendre plusieurs niveaux attestant de la fiabilité d’un appareil.

D’après Jon Ferguson, la gestion des clés de chiffrement depuis des objets connectés n’aurait rien d’aisé. « Un des enjeux relatifs à l’IoT est que les équipements sont fortement dépendants de systèmes Linux et de microcontrôleurs. Et ces deux éléments ne sont pas très propices à la gestion et à la génération de clés, car les capacités du processeur sont généralement très faibles et ce n’est que récemment que les accélérateurs de cryptographie ont commencé à devenir plus courants dans ces appareils », constate-t-il.

« Si vous regardez les TPM et les éléments sécurisés, ils sont limités à un très petit nombre de clés et deux algorithmes. Actuellement, toute personne dans l’écosystème Iot qui déploie une solution qui s’appuie sur la cryptographie classique ignore la réalité de l’informatique quantique », ajoute-t-il.

«  Actuellement, toute personne dans l’écosystème IoT qui déploie une solution qui s’appuie sur la cryptographie classique ignore la réalité de l’informatique quantique ».

De plus, les distributions Linux embarquées n’auraient pas d’espace de stockage des clés de chiffrement attribué, « contrairement à Windows ou macOS », selon Jon Ferguson. Contre-exemple, Ubuntu tente de son côté de standardiser ces aspects sécuritaires depuis peu.

Une spécification pensée pour faciliter la tâche des fabricants et des distributeurs

Mais la FIDO Alliance veut surtout retirer une épine du pied aux fabricants en proposant une solution de déploiement censée être plus sécurisée et plus rapide que les protocoles existants.

« Lorsqu’un fabricant usine un produit IoT, il n’a pas besoin de savoir à l’avance quel sera l’environnement physique ou virtuel où il sera installé. Souvent, le manufacturier doit fournir des informations caractéristiques dans l’objet connecté au moment de la confection, afin qu’il puisse être employé avec une plateforme IoT et dans un environnement particulier, ce qui peut inclure des exigences de sécurité distinctives et des détails de configuration associés à certains logiciels de gestion IoT », explique David Turner. « Avec notre spécification, cette décision n’intervient pas avant le processus d’embarquement lui-même. Donc les fabricants peuvent maintenant produire beaucoup d’appareils sans avoir à dire que ces dix mille unités sont destinées à cet utilisateur final ».

« La principale raison pour laquelle j’ai rejoint Entrust il y a cinq ans, c’est que je travaillais beaucoup avec des fabricants d’équipements IT/OT dans l’aérospatial, des spécialistes des systèmes SCADA et de réponses à incidents », raconte Jon Ferguson. « À l’époque la notion de sécurité était repoussée au niveau du réseau ou fondée sur des clés prépartagées, groupées, codées en dur, etc. avec beaucoup de choses basées sur l’obfuscation. Ces cinq dernières années, il y a eu une prise de conscience que l’obfuscation n’est efficace que si vos ventes sont mauvaises. Quand vous commencez à déployer beaucoup de matériels IoT sur le terrain, vous devenez une cible de choix ».

« Quand vous commencez à déployer beaucoup de matériels IoT sur le terrain, vous devenez une cible de choix ».

Et d’ajouter : « si ces objets sont connectés, leur capacité rudimentaire les expose à différents risques, d’autant que certains fabricants ont longtemps considéré la configuration de sécurité comme optionnelle ».

En l’état, FDO représente un pas en avant et sûrement une étape complémentaire à une architecture PKI ou tout autre dispositif pour protéger de bout en bout une flotte d’équipements IoT. Mais la FIDO Alliance doit convaincre l’ensemble de l’écosystème IoT. Un exercice loin d’être aisé.