Utimaco : sécuriser les systèmes d'IA impose de passer à la cryptographie post-quantique

Utimaco estime que, pour l'IA en entreprise, le problème principal n'est plus la qualité des modèles, mais la protection des données sur lesquelles ils sont entraînés et fonctionnent. La société prévient : si l'infrastructure d'IA n'est conçue que pour les menaces d'aujourd'hui, il faudra la refaire dans quelques années pour la sécurité post-quantique.

Le principal obstacle à l'adoption

L'eBook AI Quantum Resilience indique que les entreprises freinent le plus souvent l'adoption de l'IA non par manque de cas d'usage, mais par crainte de la fuite, de la falsification ou de la compromission de leurs propres données. C'est particulièrement sensible pour les organisations qui veulent entraîner des modèles sur des documents internes, des informations financières, de la propriété intellectuelle et d'autres données qui gardent leur valeur longtemps. Plus les données ont de la valeur, plus l'erreur coûte cher : la compromission du pipeline d'entraînement pèse à la fois sur la qualité du modèle et sur les risques juridiques.

Le problème, c'est que les menaces apparaissent sur toute la chaîne de l'IA. Il ne s'agit pas seulement de la phase d'inférence, où l'on évoque généralement la prompt injection et la fuite des résultats. Les dangers surgissent aussi lors du chargement des données, de l'entraînement, du stockage des clés, du déploiement du modèle et de son exploitation ultérieure. Si l'une de ces couches reste sans protection, l'attaquant obtient un point d'entrée dans l'ensemble du système.

Trois zones de risque

Utimaco identifie trois grands domaines où les systèmes d'IA sont déjà vulnérables aujourd'hui, même sans véritable ère des ordinateurs quantiques. Ce ne sont pas des scénarios théoriques, mais des risques concrets pour les entreprises qui collectent des données pendant des années, puis les utilisent dans des modèles, des assistants et des services d'IA internes.

• Empoisonnement des données d'entraînement — un attaquant peut injecter ou modifier des données pour que le modèle se mette à produire des résultats faussés, sans qu'il soit facile d'en repérer la cause.
• Vol ou copie de modèles — si un modèle est extrait ou reproduit, l'entreprise perd sa propriété intellectuelle et son avantage concurrentiel.
• Exposition de données sensibles — les données utilisées pendant l'entraînement ou l'inférence peuvent être interceptées si l'environnement et les clés sont mal protégés.

Un risque distinct tient au principe harvest now, decrypt later : des données chiffrées peuvent être volées aujourd'hui et déchiffrées plus tard, quand des moyens quantiques plus puissants apparaîtront. Il faut donc protéger non seulement les opérations en cours, mais aussi les archives, les jeux de données et tous les actifs qui doivent rester confidentiels pendant des années.

Comment construire la protection

Selon les auteurs, la cryptographie à clé publique actuelle pourrait commencer à perdre sa fiabilité d'ici une décennie. La migration vers des algorithmes post-quantiques ne peut donc pas attendre que le risque devienne massif : refondre les protocoles, les systèmes de gestion de clés, la compatibilité et les performances prend des années. Les auteurs soulignent expressément que cette migration touchera à la fois l'interopérabilité entre systèmes et la vitesse de l'infrastructure.

Comme stratégie de transition, Utimaco propose la crypto-agility — la capacité de changer d'algorithmes cryptographiques sans refondre toute l'architecture, grâce à une approche hybride combinant cryptographie classique et post-quantique, y compris les méthodes proposées par le NIST.

Mais la cryptographie seule ne suffit pas. Le rapport insiste séparément sur le rôle des environnements protégés par du matériel et des enclaves, qui isolent les clés et les opérations sensibles de l'infrastructure ordinaire. Dans ce schéma, les clés servant à chiffrer les données et à signer les modèles peuvent être générées et stockées dans un périmètre de confiance, l'intégrité du modèle peut être vérifiée avant le déploiement et les données traitées pendant l'inférence peuvent être protégées. En outre, les modules matériels permettent l'attestation externe de l'environnement et la tenue de journaux d'accès résistants à la falsification, ce qui aide aussi à respecter des exigences comme celles de l'EU AI Act.

Ce que cela signifie

Pour les entreprises qui bâtissent de l'IA sur leurs propres données, la sécurité cesse d'être une « couche supplémentaire » et devient une partie de l'architecture du produit. Gagneront celles qui intègrent dès maintenant la migration cryptographique, la protection des clés et les périmètres de confiance matériels, plutôt que d'essayer de tout réparer après la première fuite grave ou l'arrivée des menaces post-quantiques.