Le jeton d'authentification est crypté mais pas signé - faiblesse?

Question

Au cours des années, j'ai rencontré ce scénario plus d'une fois. Vous avez un tas de données relatives aux utilisateurs que vous souhaitez envoyer d'une application à une autre. La deuxième application devrait "faire confiance" à ce "jeton" et utiliser les données qu'il contient. Un horodatage est inclus dans le jeton pour empêcher une attaque de vol/réutilisation. Pour une raison ou une autre (ne nous en préoccupons pas ici), une solution personnalisée a été choisie plutôt qu'une norme industrielle comme SAML.

Pour moi, il semble que la signature numérique des données est ce que vous voulez ici. Si les données doivent être secrètes, vous pouvez également les crypter. Mais ce que je vois beaucoup, c'est que les développeurs vont utiliser le cryptage symétrique, par exemple. AES. Ils supposent qu'en plus de rendre les données "secrètes", le chiffrement fournit également 1) l'intégrité des messages et 2) la confiance (authentification de la source).

Ai-je raison de soupçonner qu'il y a une faiblesse inhérente ici? À première vue, cela semble fonctionner si la clé symétrique est correctement gérée. En l'absence de cette clé, je ne saurais certainement pas comment modifier un jeton chiffré, ou lancer une sorte d'attaque cryptographique après avoir intercepté plusieurs jetons. Mais un attaquant plus sophistiqué pourrait-il exploiter quelque chose ici?

Answer 1

Une partie dépend du mode de cryptage. Si vous utilisez ECB (honte sur vous!) je pourrais échanger des blocs autour, en modifiant le message. Stackoverflow got hit by this very bug. Moins menaçant - sans aucune vérification d'intégrité, je pourrais effectuer une attaque d'homme au milieu, et échanger toutes sortes de bits, et vous le recevriez et essayer de le décrypter. Vous échoueriez bien sûr, mais la tentative peut être révélatrice. Bernstein (exploitant une combinaison de caractéristiques de cache et de microarchitecture) subit des attaques latérales et Osvik, Shamir et Tromer (exploitant les collisions de cache) s'appuient sur l'obtention de données statistiques basées sur un grand nombre de tests aléatoires. 1 L'article en bas de page est un cryptographe d'une plus grande note que moi, et il conseille réduire la surface d'attaque avec un MAC:

si vous pouvez vous assurer qu'un attaquant qui n'a pas accès à votre MAC la clé ne peut jamais nourrir le mal entrée à un bloc de code, cependant, vous réduire considérablement les chances qu'il sera en mesure d'exploiter les bugs

Answer 2

Une approche de chiffrement symétrique est aussi sûre que la clé. Si les deux systèmes peuvent recevoir la clé et maintenir la clé en toute sécurité, c'est bien. La cryptographie à clé publique est certainement un ajustement plus naturel.

Answer 3

Eh oui. Le cryptage seul ne fournit pas d'authentification. Si vous voulez une authentification, vous devez utiliser un code d'authentification de message tel que HMAC ou des signatures numériques (selon vos besoins).

Il y a un grand nombre d'attaques possibles si les messages sont simplement cryptés, mais pas authentifiés. Voici juste un exemple très simple. Supposons que les messages sont chiffrés à l'aide de CBC. Ce mode utilise une IV pour randomiser le texte chiffré de sorte que chiffrer deux fois le même message ne donne pas le même texte chiffré. Maintenant, regardez ce qui se passe pendant le décryptage si l'attaquant modifie juste la IV mais laisse le reste du texte chiffré tel quel. Seul le premier bloc du message déchiffré va changer. En outre exactement ces bits ont changé dans le changement IV dans le message. Par conséquent, l'attaquant sait exactement ce qui va changer lorsque le destinataire décrypte le message.Si ce premier bloc était par exemple un horodatage, l'attaquant sait quand le message original a été envoyé, alors il peut facilement fixer l'horodatage à tout autre moment, juste en retournant les bons bits.

D'autres blocs du message peuvent également être manipulés, bien que ce soit un peu plus compliqué. Notez également que ce n'est pas seulement une faiblesse de CBC. D'autres modes comme OFB, CFB ont des faiblesses similaires. S'attendre à ce que le cryptage seul fournisse l'authentification est donc une hypothèse très dangereuse.