Des systèmes à l'épreuve du temps grâce à la crypto-agilité

À peine un système technique peut-il se passer de la cryptographie. La confidentialité et l'authenticité des données peuvent être assurées en utilisant des méthodes cryptographiques modernes telles que l'AES [Advanced Encryption Standard]. Les fonctions de hachage cryptographique, qui créent une empreinte digitale d'un enregistrement de données, sont un outil important dans ce processus.

Cependant, la cryptographie est souvent utilisée comme une boîte noire. L'idée est que la cryptographie est toujours sécurisée lorsqu'elle est utilisée correctement. La confiance dans la cryptographie utilisée aujourd'hui vient également du fait que les algorithmes ont été testés et éprouvés pendant des décennies. La méthode asymétrique RSA, par exemple, existe depuis les années 1970 et, avec le paramétrage approprié, elle ne peut pas être brisée aujourd'hui. Le chiffrement par bloc symétrique AES a également été étudié par les esprits les plus brillants de la communauté cryptographique depuis plus de 20 ans sans qu'aucune attaque pratique ne soit trouvée.

Les faiblesses de la cryptographie acutelle

Néanmoins, ce serait une erreur fatale de supposer que la cryptographie moderne est "invulnérable". L'algorithme prédécesseur de l'AES, le Standard de Chiffrement des Données (DES), a été cassé pour la première fois à la fin des années 1990, après environ 20 ans d'utilisation, par le supercalculateur spécialement conçu "Deep Crack" - en quelques jours seulement.

Les fonctions de hachage cryptographique ont été brisées à plusieurs reprises au fil des ans. MD5 et SHA-1 sont considérés comme non sécurisés aujourd'hui, et même s'il n'y a toujours pas d'attaques pratiques sur le successeur SHA-2, l'existence de la norme SHA-3, qui est complètement détachée des principes de conception de ses prédécesseurs, montre qu'il y a de sérieux doutes sur la longévité de SHA-2.

Durée de vie des algorithmes sélectionnés

Cependant, les perspectives sont décourageantes pour la cryptographie asymétrique (c'est-à-dire les algorithmes tels que RSA, Diffie-Hellman ou la cryptographie sur les courbes elliptiques). Comme la sécurité de toutes ces méthodes repose sur des problèmes de calcul mathématiquement liés, le fait de faire tomber une méthode suffit à briser toute la cryptographie asymétrique utilisée aujourd'hui. Cela peut se produire, par exemple, s'il y a une percée mathématique et qu'un algorithme est trouvé pour calculer efficacement une factorisation de nombres premiers sur un matériel conventionnel. Le scénario le plus probable, cependant, est le progrès technique dans le domaine de l'informatique quantique, car elle peut exécuter un tel algorithme pour la factorisation de nombres premiers.

Transition vers la cryptographie post-quantique

La cryptographie asymétrique que nous utilisons aujourd'hui a une date d'expiration. Heureusement, la communauté de recherche a depuis longtemps reconnu le problème et a déjà fourni une alternative sous la forme d'une nouvelle cryptographie post-quantique.

La normalisation de la cryptographie post-quantique par le NIST [National Institute of Standards and Technology] a également ouvert la voie à l'industrie pour convertir ses produits, processus et services en cryptographie résistante aux ordinateurs quantiques. Cependant, c'est précisément là que l'on constate que la cryptographie ne peut pas être considérée comme une boîte noire, et que les nouveaux algorithmes, en raison de nouvelles conditions telles que la contextualité ou des paramètres significativement plus grands, ne sont pas des remplacements instantanés.

En fonction de la complexité du système, la transition vers la cryptographie post-quantique peut devenir une tâche colossale. Et que se passe-t-il lorsque la transition est terminée ? Lorsque tous les systèmes ont été convertis et sont équipés pour l'ère des ordinateurs quantiques ? À ce moment-là, le prochain algorithme sera probablement identifié comme une source de préoccupation - que des conflits aient été trouvés pour la fonction de hachage SHA-2 ou, pendant la transition vers la cryptographie post-quantique, l'accent ait été mis sur les algorithmes basés sur les réseaux, et de nouvelles vulnérabilités aient été trouvées dans ceux-ci. Dans de tels cas, le processus recommence, et la prochaine transition vers une nouvelle cryptographie commence

L'agilité de la cryptographie comme principe de conception

La priorité absolue devrait être, pendant la transition déjà nécessaire loin de la cryptographie asymétrique classique, de créer les conditions et les processus nécessaires pour assurer une interchangeabilité générale de la cryptographie utilisée. Cela concerne particulièrement les produits déjà utilisés sur le terrain.

Ce principe s'appelle l'agilité de la cryptographie. Un système est agile en cryptographie s'il permet l'échange transparent de la cryptographie existante sans avoir besoin de modifier l'infrastructure sous-jacente. Cela signifie qu'une entreprise qui adopte l'agilité de la cryptographie comme principe de conception peut remplacer un algorithme cryptographique compromis par une variante sécurisée en quelques jours seulement, au lieu de devoir subir une transition à grande échelle qui prend des mois à planifier.

Etude de cas : l'industrie automobile

L'objectif de l'agilité de la cryptographie est plus facile à atteindre sur certains systèmes que sur d'autres. En particulier, les systèmes qui fonctionnent entièrement dans le cloud et sont sous le contrôle total de l'opérateur peuvent naturellement atteindre plus facilement l'agilité de la cryptographie. Pour les systèmes distribués qui sont exploités à partir de divers endroits dans le monde réel, il y a plus de défis sur le chemin de l'agilité de la cryptographie.

Supposons qu'un constructeur automobile (OEM - Original Equipment Manufacturer) souhaite rendre la prochaine génération de ses véhicules agile en cryptographie - notamment en tenant compte de la menace posée par les ordinateurs quantiques. Quelles considérations doivent être prises en compte ? Une distinction doit être faite entre les changements locaux qui n'affectent que l'hôte lui-même et les changements dans la communication qui affectent les deux partenaires de communication. Il existe également plusieurs exigences en matière de processus. Dans ce qui suit, nous voulons examiner de plus près quelques points sans être exhaustifs.

Changements locaux

L'ancre de confiance d'une unité de commande est généralement le module de sécurité matériel (HSM) installé sur l'unité de commande ou les clés stockées dans le HSM. Un HSM généralement utilisé dans l'industrie automobile aujourd'hui remplit, entre autres, les objectifs suivants :

• Stockage sécurisé de clés ou de valeurs de hachage, parfois même immuables dans des fusibles électroniques.

• Exécution haute performance de calculs cryptographiques à l'aide d'accélérateurs matériels.

• Génération de nombres aléatoires réels.

• Compteurs monotones pour, par exemple, la protection contre le rétrogradage.

HSM dans l'unité de contrôle

Ici, vous pouvez rapidement voir où le concept d'agilité de la cryptographie atteint ses limites. Si, par exemple, la clé de vérification pour un mécanisme de démarrage sécurisé est stockée de manière inchangeable dans des fusibles électroniques, la procédure utilisée ne peut pas être remplacée sans créer un nouveau concept de démarrage sécurisé.

Les accélérateurs matériels sont utilisés pour répondre à certaines exigences de performance pour la cryptographie en termes de temps de démarrage ou de temps de réponse. Si la cryptographie accélérée avec ces composants matériels doit être remplacée, les exigences ne peuvent plus être satisfaites. Des solutions possibles comprennent l'intégration complète des calculs cryptographiques dans le logiciel - ou le micrologiciel HSM. Cependant, le processeur HSM doit avoir une capacité de calcul suffisante pour cela. Une autre option serait d'externaliser non pas l'ensemble de l'algorithme, mais seulement les opérations les plus coûteuses vers les accélérateurs matériels. Cela pourrait réduire la surface de puce requise par algorithme accéléré et permettre à un plus grand nombre d'algorithmes d'être pris en charge par le matériel. Cependant, il s'agit d'une mesure que le constructeur automobile ne peut initier qu'en étroite coordination avec l'industrie des semi-conducteurs.

Pour un système agile en cryptographie, les mémoires de clés dans le HSM doivent également être dimensionnées de manière à pouvoir stocker des clés plus grandes si l'algorithme cryptographique (ou simplement les paramètres de l'algorithme) est modifié. Il en va de même pour le stockage des certificats, car les certificats peuvent contenir des clés et des signatures plus grandes à l'avenir. Ici aussi, le constructeur automobile doit formuler des exigences correspondantes pour le fournisseur.

Le logiciel qui contrôle les algorithmes cryptographiques (par exemple, la pile crypto AUTOSAR) doit également pouvoir cartographier les conditions-cadres modifiées des nouveaux algorithmes. Par exemple, les méthodes basées sur les hachages ont un nombre maximum de générations de signatures par paire de clés.

Modifications de communication

Fondamentalement, un véhicule moderne dispose de nombreuses interfaces, dont toutes ne sont pas sous le contrôle de l'OEM. Alors que l'OEM peut contrôler le type de communication entre le véhicule et le backend, ou entre le véhicule et sa propre application mobile, l'OEM n'a pas d'influence sur les protocoles de communication normalisés pour V2X ou la communication de charge, par exemple.

Il peut également y avoir des interfaces sur des unités de commande fournies que le fournisseur utilise pour l'analyse de retour, par exemple. L'OEM n'a pas d'influence directe sur ces interfaces, mais peut persuader le fournisseur de mettre à jour le protocole utilisé en présentant une demande de modification correspondante. La condition préalable à cela est que l'OEM ait déjà engagé le fournisseur à l'agilité de la cryptographie dans la phase de développement.

Partenaires de communication sélectionnés d'un véhicule

Avec les protocoles de communication utilisés sous le contrôle de l'OEM, il faut continuer à veiller à ce que les protocoles soient suffisamment flexibles pour que le format des messages supporte des signatures plus grandes et éventuellement des métadonnées supplémentaires. L'algorithme cryptographique utilisé devrait être communiqué comme métadonnée dans le flux de protocole (par exemple, choix de la suite de chiffrement pour TLS).

Exigences en matière de processus

Des processus appropriés doivent être créés pour l'échange fluide de la cryptographie. Tout d'abord, un inventaire de la cryptographie existante doit être réalisé, par exemple sous la forme d'un inventaire cryptographique (CBOM). Si l'on apprend ensuite qu'un certain algorithme présente des faiblesses, une décision doit être prise quant à ce qui doit être utilisé pour remplacer l'algorithme.

Ce choix d'un algorithme "de secours" peut, bien sûr, également être fait à l'avance. Cependant, il faut noter qu'un algorithme "de secours" doit être basé sur un problème mathématique différent afin de minimiser le risque que les deux algorithmes deviennent non sécurisés en même temps.

La cryptographie utilisée doit ensuite être mise à jour pour tous les partenaires de communication (par exemple, l'unité de commande dans le véhicule et le backend). Le partenaire de communication le plus puissant (par exemple, le backend) devrait être mis à jour en premier et idéalement prendre en charge les deux algorithmes pendant une période de transition. Il peut ne pas y avoir suffisamment de ressources disponibles sur le dispositif de commande pour héberger simultanément les deux algorithmes. À partir du moment où le nouvel algorithme a été déployé dans toute la flotte, il peut alors également être configuré dans le backend que désormais la communication n'est autorisée qu'avec le nouvel algorithme.

Si toutes les exigences sont remplies, un processus d'échange cryptographique peut idéalement être intégré dans les processus de gestion des incidents existants.

Conclusion

L'agilité de la cryptographie désigne la capacité d'un système à échanger les algorithmes cryptographiques utilisés sans restrictions significatives pendant l'exploitation. L'effort nécessaire pour rendre un système agile en cryptographie dépend principalement de la complexité du système.

Cependant, surtout pour les systèmes complexes et distribués, une transition vers une nouvelle cryptographie est à peine, voire pas du tout, possible sans agilité en cryptographie. Le fait qu'une telle transition sera nécessaire tôt ou tard est déjà donné en raison de la menace posée par l'informatique quantique. L'agilité de la cryptographie est donc un impératif absolu pour développer des systèmes résistants aux futures évolutions - par exemple, dans les industries automobile, médicale, de l'automatisation du bâtiment, de la fabrication industrielle et aérospatiale.

Votre chemin vers l'agilité en cryptographie

La manière dont l'agilité de la cryptographie peut être intégrée de la manière la plus efficace dans les structures existantes dépend fortement des besoins spécifiques de votre organisation. Alter Solutions peut vous accompagner sur ce chemin et développer des solutions individuelles pour vous. Nous pouvons travailler avec vous dans les domaines suivants :

• Évaluation des technologies de sécurité existantes et analyse des besoins en agilité de la cryptographie.
• Développement d'un concept holistique pour la mise en œuvre de l'agilité en cryptographie pour vos produits. *
• Évaluation de la sécurité du matériel et des logiciels utilisés, par exemple des modules HSM et des bibliothèques cryptographiques.
• Développement de technologies de sécurité agiles en cryptographie, notamment :
  • Protocoles de communication sécurisés.
  • Gestion des clés et des certificats.
  • Démarrage sécurisé.
  • Infrastructure à clé publique (PKI).

• Spécification de l'agilité en cryptographie dans les spécifications.

• Évaluation de la mise en œuvre de l'agilité en cryptographie par les fournisseurs.

• Sélection des algorithmes cryptographiques appropriés en tenant compte des conditions-cadres données.

• Introduction des processus nécessaires, tels que l'inventaire de la cryptographie ou les stratégies de mise à jour.

Vous souhaitez en savoir plus sur l'agilité de la cryptographie ou l'intégrer dans vos systèmes pour les rendre résistants aux futures évolutions ? Contactez-nous dès aujourd'hui, gratuitement et sans engagement.

Planifiez une réunion sans engagement dès maintenant !