Internet des objets et sécurité : toutes les réponses...
Comment identifier les appareils et comment les appareils s’authentifient-ils auprès des services ? Plusieurs approches sont possibles. Mais au final, c’est au niveau supérieur de l’entreprise que seront définies les stratégies et les approches qui impulseront, ou devraient impulser, les mécanismes choisis par votre organisation.
La stratégie de l’Internet des Objets (IoT) s’articule autour de deux facteurs clés. Une organisation choisira rarement de mettre en œuvre un produit IoT au nom de la technologie. Les organisations doivent avant tout exposer clairement leurs idées maîtresses sur la manière, le lieu et les raisons qui les poussent à considérer l’IoT comme un levier de valorisation de leur activité. Les réponses à ces questions orienteront alors les fonctionnalités, la connectivité et les intégrations requises pour que le produit soit conforme à leur vision stratégique. L’évaluation des risques et la sélection des technologies d’atténuation des risques pour la solution IoT requièrent une analyse qui intervient souvent trop tardivement dans le cycle de développement. L’établissement d’un tel profil de risques permet d’étudier toutes les menaces potentielles pour la sûreté, la confidentialité, la fraude et d’autres points potentiellement négatifs. L’ampleur du risque ou des problèmes associés à chacun de ces points dépend de plusieurs facteurs comme le seuil de risque global de l’entreprise, son secteur d’activité, ses contraintes législatives, etc. Après décryptage du profil de l’écosystème IoT, les organisations devront envisager plusieurs aspects d’ordre général pour espérer réduire convenablement les risques associés à leur solution IoT.
Définition et évaluation des risques et des vecteurs d’attaques
Prenons tout d’abord quelques exemples représentatifs des risques et vecteurs d’attaques potentiels contre un écosystème IoT. Une grande partie des attaques qui ciblent l’IoT ressemblent aux attaques en ligne classiques, du type Thing in the Middle, déni de sommeil (Denial of Sleep), écoutes indiscrètes (Eavesdropping) ou violations d’accès à des données privées (Snooping). L’impact de chacune de ces attaques varie en fonction de l’écosystème et de l’environnement des périphériques, mais aussi en fonction des risques évoqués plus haut qui préoccupent l’entreprise. Pour approfondir l’étude de ces risques et la manière de les atténuer, nous tenterons d’élargir notre propos. Prenons le concept de Thing in the Middle. Imaginons le scénario suivant : un tiers malveillant souhaite fausser les données thermiques d’un appareil de contrôle afin de provoquer la surchauffe d’une pièce de machinerie et provoquer des dommages physiques et financiers pour l’exploitant. Plusieurs composants techniques permettraient de réduire ce risque. Mais en définitive, on cherche à savoir comment le service de vérification peut faire confiance aux données envoyées par cet appareil. Dans les écosystèmes IoT, la confiance est un concept intéressant, pas uniquement sur le plan rhétorique, mais également en termes de besoins de garanties pour les parties utilisatrices et de capacités techniques des points de terminaison dans l’écosystème. Le concept d’identité est étroitement lié à la confiance. Comment le service récepteur qui prend les décisions à partir des données du capteur sur l’appareil peut-il à la fois faire confiance à l’expéditeur des données et aux données reçues ? Le service doit tout d’abord établir une relation de confiance avec la source des données – ce que l’on appelle l’authentification. Ensuite, il doit avoir l’assurance que les données n’ont pas été modifiées depuis leur envoi sur le réseau – ce que l’on appelle l’intégrité.
Nous consacrerons une grande partie de cet article au volet « authentification ». Cette question soulève plusieurs points, mais nous devons tout d’abord étudier la manière dont l’appareil s’authentifie et prouve aux services qu’il est digne de confiance. L’authentification peut s’effectuer de plusieurs façons : avec le nom de l’appareil et le mot de passe, par secret partagé, à l’aide de clés API, de clés symétriques ou via un certificat basé sur une infrastructure PKI (Public Key Infrastructure). Chacune de ces solutions exige un compromis entre sécurité, garanties de fiabilité, facilité d’utilisation, évolutivité, faisabilité et coût de mise en œuvre. Pour ce qui est des garanties de fiabilité, on pourrait chercher à répondre à la question : « comment garantir aux services utilisateurs que l’appareil correspond bien à ce qu’il affirme être ? »
Évaluation des garanties de fiabilité
Si l’on compare le scénario d’identification à l’aide du nom de l’appareil et du mot de passe avec un scénario fondé sur des certificats numériques et une infrastructure PKI, l’évaluation des garanties de fiabilité portera sur les questions suivantes :
- Comment les identifiants ont-ils été générés ?
- Comment ont-ils été configurés sur l’appareil ?
- Comment sont-ils stockés sur l’appareil ?
- Les identifiants ont-ils à un moment donné été envoyés en clair avec le risque d’être interceptés par une tierce partie ?
- Les identifiants ont-ils été mis à jour après leur configuration et si tel est le cas, la mise à jour était-elle sécurisée ?
Mécanismes d’identification et d’authentification fortes
Dans ce contexte, je m’exprimerai sur une mise en œuvre PKI respectueuse des bonnes pratiques que je comparerai avec un scénario plus classique de type « nom de l’appareil/mot passe ». Je démontrerai alors comment instaurer un modèle plus fiable qui permette, en prime, de réduire davantage les risques et la probabilité d’être victime d’une attaque thing in the middle. Je m’efforcerai également de répondre à quelques-unes des questions précédemment soulevées.
L’un des avantages d’une infrastructure PKI dans notre contexte « d’équipement physique » réside dans ses possibilités de mise en œuvre sans que le service utilisateur ait connaissance du secret de l’équipement. L’infrastructure PKI s’appuie sur deux éléments : une clé publique – souvent associée à un certificat d’identification – qui peut être exposée publiquement, et des clés privées… qui doivent le rester. Dans un environnement « physique », les bonnes pratiques recommandent l’utilisation d’équipements sécurisés, tels qu’un module de plate-forme de confiance (TPM, Trusted Platform Module) ou l’équivalent, pour générer et stocker les clés privées. Ces équipements offrent d’excellentes garanties sur l’impossibilité pour les clés privées d’avoir été, et d’être, compromises. Commencez par sécuriser vos clés à l’aide de ces composants matériels sécurisés pour établir le socle de confiance de vos identités. Pour profiter de la fiabilité du stockage des clés propre aux certificats PKI, vous émettrez un certificat électronique qui associe une forme d’information d’identité à la clé publique correspondant à la clé privée. Ce processus s’effectue sur les appareils en usine, au niveau de la chaîne de fabrication. Le certificat numérique peut désormais être utilisé dans plusieurs scénarios : pour authentifier l’appareil de manière sécurisée et ouvrir la négociation visant à garantir la confidentialité de la communication avec les services utilisateurs – sans risque de compromission des clés privées. Dans une approche classique du type « nom d’utilisateur et mot de passe », la fiabilité commence alors à décliner sur plusieurs points. Le nom d’utilisateur et le mot de passe doivent être générés quelque part. Si l’opération s’effectue parfois sur l’équipement, elle passe souvent par un autre service avant que les identifiants ne soient envoyés sur l’appareil pendant leur attribution. Dans cet exemple d’authentification avec « nom de l’appareil/mot de passe », les identifiants risquent d’être divulgués ou interceptés à plusieurs endroits.
Abordons maintenant l’utilisation de ces identifiants pour l’authentification sur des services. Le mécanisme de transport pour l’échange des identifiants s’effectue idéalement via un canal crypté pour empêcher tout risque d’interception. L’interception des identifiants de type « nom de l’appareil/mot de passe » représente un risque considérable, alors que dans le scénario PKI, l’interception des identifiants n’est qu’un aspect mineur. L’échange ne porte que sur la clé publique et le certificat. Or, ces derniers ne sont d’aucune utilité si l’on ne possède pas les clés privées correspondantes (les clés étant protégées dans le système de stockage de l’appareil). Le scénario PKI présente également plusieurs avantages : lorsque l’on procède à une authentification mutuelle par TLS (qui authentifie chaque partie), on obtient, à la fin de la procédure de handshakes, l’établissement d’un canal sécurisé entre les points. Dans un scénario « nom d’appareil/mot de passe », l’établissement du canal sécurisé a de fortes chances de s’effectuer à part.
Enfin, si l’on tient compte du cycle de vie des appareils, nous devons souvent considérer les mécanismes utilisés pour mettre à jour les appareils dans la pratique. À l’évidence, la tâche n’est pas simple. Il faut cependant qu’elle soit réalisable dans chaque cas. Avec une infrastructure PKI, l’appareil doté d’un hardware sécurisé doit être capable de générer de nouvelles clés au besoin, et d’envoyer aux services des demandes de signature de certificat réactualisées. De nouveau, dans ce scénario, les composants privés... restent privés. En revanche, dans un scénario « nom d’appareil/mot de passe », la mise à jour et le partage de nouveaux identifiants posent à nouveau plusieurs questions sur la sécurité des mécanismes utilisés sur l’appareil pour générer de nouveaux identifiants, sur le stockage de ces identifiants et leur transport jusqu’au service.
Juste la partie émergée de l’iceberg...
Nous voyons bien que la discussion peut aller plus loin dans l’analyse des risques et l’utilisation de technologies de mitigation des risques spécifiques. Le concept d’identité représente un énorme enjeu qui, envisagé dans sa globalité, peut vous aider à bâtir votre écosystème en toute sécurité. Pour la création de solutions IoT, les exploitants et fabricants d’appareils ont tout intérêt à faire appel à des partenaires expérimentés et compétents pour sécuriser leurs communications, plutôt que d’essayer de mettre en place des solutions maison ou sur mesure. La sécurité ne saurait être une fonction optionnelle. Elle exige de la part des organisations une analyse approfondie des objectifs et des profils de risques qu’elles sont prêtes à accepter. Vous avez un cas d’utilisation ou un scénario spécifique, et êtes confronté à ces problèmes ? Nous serions ravis de réfléchir avec vous à la création d’une solution pratique et rentable pour sécuriser votre vision de l’IoT.
