Le chiffrement asymétrique permet d’assurer le chiffrement et/ou la signature d’objets numériques. Il est même indispensable pour permettre les échanges publiques avec sa partie publique (justement) et sa partie privée.
Mais, comme le chiffrement symétrique, la sécurité qu’il procure n’est pas garantie à long terme.
Un point spécifique au chiffrement asymétrique, il n’existe pas de preuve mathématique de sa solidité. En effet, celui-ci repose sur un calcul mathématique facile dans un sens mais très très difficile dans l’autre. En clair, il est possible, même si peu probable, que l’on découvre un jour une méthode mathématique pour résoudre dans un temps raisonnable le calcul mathématique dans son sens difficile. Là , c’est tout le système qui s’écroule…
Nous ne sommes pas non plus à l’abri de la découverte d’une attaque sur le chiffrement lui-même. Cela concerne surtout le chiffrement symétrique, mais le chiffrement asymétrique n’est jamais directement utilisé pour chiffrer un objet. On le chiffre (symétrique) d’abord avec une clé aléatoire, puis on chiffre la clé avec la clé publique (asymétrique), ceci pour des raisons de performance. Donc dans le temps la solidité du chiffrement baisse (puissance de calcul nécessaire à le casser) en même temps que la puissance de calcul des machines augmente.
Un autre problème, commun au chiffrement symétrique (même si celui-ci semble avoir plus de marge aujourd’hui), c’est la taille de la clé qui détermine directement la solidité du chiffrement. La puissance des ordinateurs étant en constante progression, le temps nécessaire pour casser une clé d’un taille donnée se réduit. Donc, quand on choisi la taille d’une clé, elle doit être suffisante pour couvrir le temps de vie des données, c’est à dire jusqu’à ce que la donnée chiffrée n’ai plus de valeur. Or, augmenter la taille de la clé augmente aussi le temps de calcul pour chaque chiffrement ou signature.
Comment faire pour une entité qui nécessitera une clé sécurisée sur du long terme?
Il faut prévoir un système équivalent à la liste de révocation. Mais là ou la centralisation des certificats SSL permet de mettre en place une liste de révocation publique, un système qui n’a pas de point convergeant doit trouver un système adapté.
L’utilisateur peut avoir à utiliser directement la clé privé, il peut aussi ne pas y avoir accès et gérer un module (qui lui est propre) qui s’occupe de la clé privé. Comment alors faire en cas de vol? Vol avec violence?
La clé privé est ce qui détermine l’identité de l’individu visa-vis de autres. Lui voler sa clé c’est usurper son identité. Comme si quelqu’un se faisait refaire le visage pour vous ressembler.
Une autre chose détermine l’identité d’un individu, c’est sa « mémoire ». D’un point de vu numérique, cela correspond à tout ce qu’il possède sur ses disques durs. Mais comment protéger les données alors que l’usurpateur dispose des clés pour les lire?