Les comparaisons de temps variables sont-elles toujours un risque de sécurité dans le code de cryptographie?
Je suis tombé sur le cryptage python package, et j'ai remarqué qu'il y avait ce qui suit sur le rapport des failles de sécurité:
Exemples de choses que nous ne considérerions pas comme des problèmes de sécurité: utiliser une comparaison de temps variable quelque part, s'il n'est pas possible d'articuler un programme particulier dans lequel cela entraînerait une divulgation d'informations problématique.
Je pensais que l'absence de comparaisons de temps variables était l'une des choses que les implémentations de cryptographie assuraient d'être sécurisées. Cela devrait-il être un objectif de toutes les bibliothèques de cryptographie sécurisées? Si ce n'est pas le cas, dans quelles conditions cela ne change-t-il pas la sécurité, qu'une comparaison à temps constant soit utilisée ou non?
Non, ils ne sont pas toujours un risque, et en effet, il est impossible de construire une bibliothèque cryptographique pratique où chaque fonction est à temps constant.
Prenons, par exemple, une fonction de décryptage. Dans une bibliothèque cryptographique du monde réel, il sera plus rapide de déchiffrer un message de 10 octets qu'un message de 10 gigaoctets. Vous pourriez théoriquement créer une bibliothèque où le déchiffrement était un temps constant pour tout message de taille prise en charge, mais ce serait absurde, vous avez donc une fonction de temps variable qui divulgue (inutile) des informations sur la taille du message déchiffré. L'une des raisons spécifiques pour lesquelles ce n'est pas un problème est l'hypothèse que l'attaquant peut avoir des informations sur la taille du message sont intégrées dans les preuves de sécurité. Les propriétés de sécurité sont généralement conçues pour n'assumer la sécurité que pour les messages d'une taille spécifique, et puisqu'elles ne s'appliquent pas aux messages de tailles différentes, il n'y a aucun impact sur la sécurité conçue d'un système si la taille des messages affecte le délai d'exécution de la fonction.
Dans d'autres cas, le timing peut être potentiellement sensible, mais une fonction peut être conçue pour éliminer toute information qu'un attaquant pourrait utiliser contre la fonction. Le double MAC'ing en est un exemple. L'évaluation d'un MAC est très certainement une fonction sensible aux attaques temporelles. Dans un schéma (par exemple) de chiffrement puis MAC, vous comparez un MAC envoyé avec un texte chiffré avec un MAC fraîchement calculé par rapport au texte chiffré, une attaque de synchronisation pourrait permettre à un adversaire de soumettre à plusieurs reprises des combinaisons de texte chiffré/MAC modifiées et de calculer itérativement un MAC valide sans connaître la bonne clé secrète. Si, cependant, à chaque comparaison, vous re-MACnez le MAC avec une clé éphémère et comparez à nouveau, peu importe s'il y a des problèmes de timing. La clé éphémère dans le deuxième MAC empêchera un adversaire de pouvoir produire itérativement un MAC correct car la nouvelle clé éphémère produite pour chaque évaluation ultérieure contrecarrera l'effort de découvrir des bits valides.
Des comparaisons de temps variables entraîneront des fuites d'informations. S'il n'y a aucun mal à révéler les données comparées, il n'y a aucun problème à utiliser des comparaisons de temps variables. S'il est crucial qu'elle reste secrète, utilisez la comparaison à temps constant.
Certaines comparaisons de temps variables qui sont exploitables en théorie peuvent être difficiles à exploiter dans la pratique. La qualité des données de synchronisation qu'un pirate informatique peut collecter n'est peut-être pas assez bonne pour qu'une attaque de synchronisation réussisse dans certains contextes du monde réel.
Par exemple, une attaque de synchronisation est plus difficile si le logiciel traitant les informations secrètes s'exécute sur du matériel qui a déjà des durées d'exécution incohérentes et imprévisibles (pour des entrées identiques); même si quelqu'un a accès à des données de synchronisation précises en nanosecondes.
Si les informations secrètes ne sont pas aussi sensibles et ont une courte durée de vie, le risque associé à une telle attaque temporelle pourrait être trop faible pour vous en inquiéter.
Cependant, il existe des moyens de contourner les données de synchronisation bruyantes. Peut-être qu'un pirate utilise d'autres canaux secondaires pour compléter les données de synchronisation. Peut-être qu'il envoie à votre serveur des demandes spécifiques qui rendent le timing plus prévisible. Et bien sûr, il peut effectuer l'attaque plusieurs fois et en quelque sorte faire la moyenne du bruit.
(En tant que développeur, si vous n'êtes pas sûr, alors utilisez des opérations à temps constant. Ne présumez pas que c'est trop difficile à exploiter.)
Choses qui ne devraient certainement pas être comparées à l'aide d'un algorithme à temps variable:
- Clés secrètes (symétriques) ou clés privées (asymétriques)
- balises d'authentification de message
- Messages (ou hachages de messages) contenant des secrets
- Secrets codés en dur (ou configurables par l'utilisateur)
Exemples pour lesquels cela peut ou non être important :
- Clés publiques
- Texte chiffré
- Adresses IP publiques
- Identifiants publics (à l'exclusion des informations personnelles identifiables)
N'oubliez pas que compromettre la confidentialité des utilisateurs peut être un problème de sécurité. (Même si vous ne pensez pas personnellement que vous devez garder certains types d'informations confidentiels.) Par conséquent, les développeurs devraient considérez toujours les attaques par canal latéral, même lorsque vous travaillez avec des données que vous ne pensez peut-être pas sensibles.
Tout d'abord, la cryptographie est un terme large et la bibliothèque Python cryptography n'inclut pas seulement les primitives mais aussi la gestion X.509, etc.
La principale question est de savoir si les problèmes de synchronisation peuvent être utilisés par un attaquant pour obtenir des secrets ou réduire la complexité du problème et donc le temps d'obtenir des secrets à une valeur qui rend les attaques réalistes. Cela signifie pour l'un que l'attaquant peut mesurer le temps avec une granularité suffisante en premier lieu. Ce n'est par exemple généralement pas le cas avec des applications Web complexes où les variations de latence du réseau et du temps d'exécution des requêtes SQL, etc. rendront probablement de petites différences de synchronisation dans les opérations cryptographiques impossibles à mesurer à distance. Notez que l'utilisation précoce de la cryptographie comme dans la négociation TLS pourrait toujours être affectée car à ce stade précoce, tous les autres frais généraux et variations de l'application n'ont pas encore beaucoup d'incidence.
Cela signifie également que l'attaquant peut exécuter suffisamment d'expériences pour enfin extraire les secrets. Les détails dépendent de la quantité d'informations qui sont réellement divulguées à cause des différences de synchronisation, mais elles sont souvent pratiquement irréalisables.
Et puis il pourrait tout simplement y avoir des attaques moins complexes possibles. S'il s'agit d'une application locale, il pourrait être moins coûteux de simplement la rétroconcevoir au lieu de la traiter principalement comme une boîte noire. Bien sûr, si l'application est par exemple incluse dans certains boîtiers inviolables (comme avec les cartes à puce), la synchronisation des attaques ou d'autres canaux latéraux (comme le rayonnement, les variations de puissance utilisée, ...) pourrait en fait être le seul moyen.
En résumé: la résistance aux attaques de synchronisation est pertinente si a) la différence de synchronisation peut être mesurée avec une granularité suffisante et b) suffisamment d'expériences peuvent être effectuées et c) aucune attaque manifestement moins coûteuse n'est possible. Étant donné que a) et b) dépendent en particulier beaucoup du cas d'utilisation réel, il est plus important que les primitives cryptographiques soient résistantes, car elles peuvent être utilisées dans une grande variété de cas d'utilisation.
Le but principal d'éviter la comparaison de temps variable était d'empêcher la divulgation involontaire d'informations conduisant à des attaques basées sur le temps sur l'application.
Par exemple, jetez un œil à Padding Oracle attack and Time based Blind SQL Injection attack . Effacer toutes les comparaisons de temps variables dans le programme a un certain coût que le paquet cryptographie python essaie d'éviter car ils ne voient aucune divulgation d'informations à cause de ces cas.
Il est facile de rater de tels cas d'utilisation pour le code pertinent pour la sécurité, donc je préfère éviter les comparaisons de temps variables.
La chose importante à propos des informations divulguées est d'identifier quelles informations sont divulguées, compte tenu d'un certain ensemble de circonstances, et ce que l'attaquant saurait et/ou contrôle.
Par exemple, prenons la vérification du mot de passe. Les vieux mots de passe en clair dans le mauvais vieux temps étaient souvent comparés un caractère à la fois, par une bibliothèque sans aucun souci de sécurité. Cela signifie que si vous obtenez correctement la première lettre du mot de passe, cela prendra un peu plus de temps que si vous vous trompez la première lettre (car il faudrait du temps pour vérifier la deuxième lettre). Vous pouvez essayer chaque première lettre possible, jusqu'à ce que vous frappiez la bonne, puis cette première lettre plus chaque deuxième lettre possible, et ainsi de suite. De cette façon, vous pouvez réduire le travail nécessaire de 64 ^ 6 à 64 * 6 (en supposant 6 symboles parmi un ensemble de 64 symboles possibles).
Même si vous hachez le mot de passe avant de le vérifier, vous pouvez appliquer la même chose aux tables Rainbow précalculées - trouver un mot de passe avec un hachage commençant par l'octet 00, si cela prend plus de temps à vérifier qu'un mot de passe commençant par 01, alors vous pouvez éliminer tous les mots de passe avec un hachage ne commençant pas par 01.
Dans l'exemple du cryptage, si le message en cours de décryptage est fourni par l'attaquant, alors il sait quelle est sa taille. S'il faut deux fois plus de temps pour lire un message deux fois plus longtemps, ils n'apprennent rien de nouveau de cela.
Si, en revanche, il faut plus de temps pour déchiffrer un message si la CLÉ est différente, alors le temps qu'il a fallu pour déchiffrer un message vous donne des informations sur la clé, des informations inconnues par l'attaquant.