Confidentialité : quelles clés pour mes utilisateurs ?

Cette clé ne doit pas être stockée sur un support physique, à moins qu’elle ne soit elle-même protégée par une autre clé, qui doit donc être également secrète. On finit par remonter jusqu’à l’utilisateur qui sera incapable de mémoriser une clé AES de 256 bits, c’est-à-dire un mot de passe de plusieurs dizaines de caractères. Quelles sont les solutions à notre disposition pour chiffrer la clé symétrique par un secret que l’utilisateur serait capable de fournir ?

Protéger le secret de l’utilisateur

L’enceinte la plus répandue pour stocker cette clé secrète reste encore de nos jours le cerveau de notre utilisateur. Bien que sa fiabilité soit assez décriée, le mot de passe est un moyen fiable pour protéger la clé de chiffrement finale s’il est d’une complexité suffisante. Associé à des opérations lourdes de diversification, il peut résister complètement à des attaques classiques par dictionnaire, et porte le niveau des attaques à une attaque par force brute sur la clé finale elle-même.

Malheureusement, un mot de passe complexe ne sera pas retenu. Si on ajoute à cela, la nécessité de conserver plusieurs mots de passe pour des systèmes différents, on arrive rapidement aux limites de notre utilisateur. Cependant celui-ci peut utiliser un mot de passe maître dans des systèmes Single Sign On ou des carnets de mots de passe. L’utilisateur n’a plus qu’à mémoriser un seul secret, qui protège lui-même les autres secrets.

L’autre inconvénient du mot de passe est qu’il est un secret symétrique : il faut que le correspondant dispose du mot de passe pour chiffrer des données avec celui-ci. Le correspondant doit donc vous attribuer un nouveau mot de passe, qu’il faudra que vous reteniez. Les mécanismes de chiffrement asymétriques (clé publique / clé privée) offrent depuis longtemps une solution à ce problème. Le correspondant utilise cette clé publique pour chiffrer des informations que seul le détenteur de la clé privée pourra récupérer. Ces mécanismes ont en commun de nécessiter des clés très longues, difficilement mémorisables dans le cerveau de l’utilisateur ! Il existe heureusement de nombreuses solutions plus fiables.

La clé privée peut être stockée dans un fichier de clé, en utilisant par exemple la norme PKCS#12 : le secret est enregistré dans un fichier .pfx ou .p12. Bien entendu, la possession de ce fichier ne doit pas suffire pour accéder aux données chiffrées : le fichier de clés sera donc protégé par un code d’accès. On retombe sur les inconvénients déjà cités du mot de passe, avec les avantages du chiffrement asymétrique (je n’ai pas besoin de retenir le mot de passe que m’aurait attribué mon correspondant). Avec le fichier de clés, un attaquant doit non seulement disposer du code d’accès, mais également subtiliser le fichier de clés.

On reste cependant sur une protection logicielle : si l’attaquant réussit à disposer du fichier de clés, il peut l’attaquer à loisir. Le fichier n’a pas et ne peut pas disposer d’une protection avec un nombre d’essais maximum. C’est la faiblesse d’un stockage logique, qu’un stockage matériel n’aura pas. Les tokens cryptographiques (cartes à puces, clés USB cryptographiques) stockent et gardent captives la clé privée. Celle-ci, une fois enregistrée, ne peut ni en sortir ni être exportée. Seul le crypto-processeur du token y a accès. Le système d’authentification va ainsi demander au token d’effectuer une opération cryptographique utilisant la clé privée, par exemple un déchiffrement d’une clé AES. La sécurité repose sur la nécessité de déverrouiller le token avec un code pour être autorisé à effectuer ces opérations cryptographiques. Ce code, contrairement au stockage logiciel d’un fichier de clés, ne pourra être soumis au token qu’un certain nombre de fois. Au-delà, le dispositif physique se bloque, et nécessite un formatage complet. Le niveau d’attaque nécessaire devient alors très élevé.

Toutefois le coût et la complexité du déploiement des tokens peuvent être un frein à leur adoption. De plus, comment les utiliser sur les terminaux mobiles : Smartphones et tablettes ? Il n’y a pas toujours de port USB ou de lecteur de carte intégré !

Les solutions arrivent : lecteur de carte sous forme de coque pour Smartphone, technologie sans contact NFC… Mais il est encore un peu tôt.

Et pour conclure …

La possession et/ou la connaissance par l’utilisateur d’une clé secrète est le prérequis indispensable à toute véritable solution de confidentialité des données. Les formes que prend cette clé sont multiples et vont du simple mot de passe au token matériel cryptographique, chaque solution présentant des avantages et des inconvénients. Au final, le choix du support de la clé secrète de l’utilisateur dépend également de critères en dehors du champ de la sécurité : coût, déploiement, organisation du système d’information, présence ou non d’une IGC… C’est à la solution de chiffrement des données de s’adapter aux clés choisies par l’entreprise, et non l’inverse. Son déploiement doit être simple et épouser le schéma de gestion des clés défini par l’entreprise, que cela soit des mots de passe ou des bi-clés RSA. Les schémas de sécurité évoluent, et la solution doit être de ce point de vue agile : aucun surcoût ne doit être généré par le produit de chiffrement si la forme de la clé secrète évolue, par exemple lorsqu’une entreprise s’équipe d’une IGC et souhaite passer d’un mot de passe à une bi-clé. La serrure cryptographique doit savoir s’adapter à la forme de clé désignée par l’entreprise.