La chronique du Cesin : mais où sont passées les clés ?

Le téléphone sonne :

– … Allo, ici Thierry [le RSSI].

– Bonjour Thierry, dis-moi on aurait besoin de toi à la DSI pour une mise à la clé ?

– OK, mais c’est pour ouvrir quelle porte ?

Ce RSSI n’a pas eu la bonne réponse car la mise à la clé est en réalité une génération de clé cryptographique pour un système du même nom, opération qui nécessite généralement la présence de plusieurs porteurs de secrets. Mais la question sous-jacente est : Quel niveau de connaissance doit avoir un RSSI en matière de cryptographie pour bien réaliser ses missions opérationnelles ?

Il n’a certainement pas besoin d’être un expert en mathématiques mais il doit néanmoins en connaître suffisamment pour faire les bons choix de cryptosystèmes en fonction des besoins requis par les métiers. Car le constat est très clair, la cryptographie fait aujourd’hui partie des outils incontournables pour sécuriser les SI, et le RSSI doit en maîtriser les principes et les risques.

Un petit rappel sur l’usage de la cryptographie dans le monde civil est nécessaire pour ceux qui s’y intéressent aujourd’hui. Il faut se rappeler qu’avant 1999, les dispositifs cryptographiques étaient classifiés en tant qu’« arme de guerre de 2^ème catégorie[1] » selon la classification en vigueur à l’époque. Cela veut dire par exemple que pour utiliser le chiffrement dans le but de protéger en ligne le transport d’un code confidentiel de carte bancaire, il fallait présenter un dossier d’autorisation au service central de la sécurité des systèmes d’information (SCSSI) lorsque l’ANSSI n’était encore qu’un service. Les refus étaient fréquents et sans explication de la raison.

Le 19 janvier 1999, Lionel Jospin, le premier ministre de l’époque, a levé cette mesure en libéralisant l’usage de la cryptographie pour un usage commercial, la conception et l’export restant néanmoins réglementés. Le début des années 2000 correspond en effet au début du e-commerce au niveau international. En France il sera concrétisé en juin 2004 par la loi dite LCEN[2] et son TITRE III : DE LA SECURITE DANS L’ECONOMIE NUMERIQUE, article 30, alinéa I. – L’utilisation des moyens de cryptologie est libre. En décembre de cette même année, le groupe PCI-DSS produit une norme pour la protection des données de cartes bancaires qui nécessite l’usage de la cryptographie. Les protocoles SSL/TLS, les connexions en https se généralisent, au point qu’en janvier 2017 Google Chrome et Mozilla Firefox ont commencé à identifier et signaler les sites Web qui recueillent des informations sensibles sans utiliser ce protocole de sécurité.

Dans son travail au quotidien, en particulier avec la DSI, le RSSI doit connaitre le cycle de vie des certificats de clés cryptographique (certifiant la clé publique asymétrique) sachant que la plupart des équipement réseaux, FW, hub, serveurs en sont dotés. Peut-être a-t-il mis en place un système d’authentification forte utilisant lui aussi des certificats d’authentification ? Même si sa société ne dispose pas elle-même d’une infrastructure à clés publique (IGG/PKI), il doit savoir auprès de quel opérateur de confiance s’en procurer.

La première chose à maîtriser est le choix des bons algorithmes en fonction du besoin recherché. Pour le chiffrement de flux ou d’une masse importante de données, la cryptographie symétrique est plus performante. En revanche pour l’authentification ou la signature, il faut utiliser des algorithmes asymétriques. Souvent la combinaison des deux techniques est utilisée par exemple dans l’établissement d’une liaison en https ou TLS.

La question temporelle est très importante pour la gestion des clés :

• Pour un besoin de chiffrement de flux, donc dans l’instant de l’échange, un chiffrement avec une clé à usage unique peut être utilisée (ex : DUKPT[3]) ;
• Pour une authentification (on the air – à la volée), il en est de même avec l’utilisation d’un aléa par une signature asymétrique, seule la trace horodatée de l’authentification devant être gardée ;
• En revanche pour le stockage ou pire l’archivage de données de masse, il faut être sûr de pouvoir conserver les clés cryptographiques qui ont été utilisées au moment de l’action. Si les données sont extraites plusieurs années après le chiffrement initial, il faut s’assurer qu’il sera encore possible de déchiffrer les données archivées avec la bonne clé ;
• Cela est encore plus complexe pour des données signées dans un but légal car dans certains cas les signatures devront pouvoir être vérifiées 30 ans après, voire indéfiniment s’il s’agit d’actes notariés.

Le RSSI doit donc, au-delà du choix des bons algorithmes, se préoccuper de façon très précise de la gestion des clés cryptographiques des différents systèmes utilisés. Tout RSSI sait que chaque outil ou système de sécurité génère lui-même ses propres risques. Ainsi, les attaques réussies sur les systèmes cryptographiques sont généralement dues à une mauvaise implémentation du système en question. Les attaques par écoutes de canaux auxiliaires, par la consommation électrique des cryptoprocesseurs ou autres ont fait leurs preuves. Les conseils de l’ANSSI sur les équipements sont dans ce cas très utiles (voir liens utiles).

Mais cela ne s’arrête pas là, car le RSSI doit à la fois gérer la sécurité des données échangées mais dans le même temps veiller à l’innocuité du SI en matière de virus. Ainsi comment contrôler l’absence de virus dans des flux chiffrés https entre le poste utilisateur et un site web distant ? Le seul moyen est de mettre un équipement réseau intermédiaire dont le but sera de déchiffrer / rechiffrer les flux sortants et surtout entrants, et de les analyser avant de les délivrer au destinataire[4].

Face aux tendances d’externalisation des données dans des systèmes cloud publics, face aux nouvelles exigences de la loi sur la protection des données personnelles (RGPD), le RSSI aura de nombreuses occasions de préconiser l’usage de moyens cryptographiques, tout en gardant continuellement en tête « qui est le maître des clés ? ». La réponse à cette question ne sera pas si simple dès lors que les « maîtres des clés » seront les fournisseurs eux-mêmes de services cloud !

Pour terminer cette chronique, quelle importance doit donner le RSSI aux avancées en matière de cryptographie, tailles de clés, courbes elliptiques ou cryptographie quantique ? Il doit s’en remettre aux spécialistes qui veillent pour lui, en restant prudent. L’ANSSI donne des conseils en matière de taille de clés selon les algorithmes (voir ci-dessous les liens utiles). La cryptographie quantique pour sa part est une technologie à double tranchant, elle apporte des solutions incassables pour l’échange de données chiffrées, mais dans un avenir difficile à déterminer l’ordinateur quantique sera le pire ennemi des algorithmes cryptographiques asymétriques. Laissons donc faire les experts.

Et dans tout ça le RSSI ne doit pas oublier qu’une authentification forte utilisant une clé asymétrique de 1024 bits restera soumise à l’entrée par l’utilisateur d’un code à 4 chiffres sur un clavier !

[1] Selon la loi française sur les armes en vigueur à cette époque les armes de 2e catégorie sont des « matériels destinés à porter ou à utiliser au combat les armes à feu ».

[2] Loi n° 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique, NOR: ECOX0200175L

[3] DUKPT : Derived Unique Key per Transaction. Chaque échange utilise une clé dérivée d’une clé maître. Cette clé est fugitive et ne sert que pour un échange donné.

[4] Tout cela avec une bonne information préalable des utilisateurs, voir ma chronique précédente.

Liens utiles :

• ANSSI : Liste de produits certifiés CSPN
• ANSSI : Liste de produits certifiés critères communs
• ANSSI : Le web doc sur la cryptographie
• ANSSI : Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques