Au fil des ans que j'ai rencontré ce scénario plus d'une fois. Vous avez un tas de données associées à l'utilisateur que vous souhaitez envoyer d'une application à une autre. La deuxième application devrait «faire confiance à» ce «jeton» et utiliser les données en elle. Un horodatage est inclus dans le jeton pour empêcher une attaque de vol / réutilisation. Pour une raison quelconque (ne vous inquiétons pas ici) une solution personnalisée a été choisie plutôt que d'une norme de l'industrie 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 le crypter.
Mais ce que je vois beaucoup, c'est que les développeurs utiliseront un cryptage symétrique, par ex. AES. Ils supposent que, en plus de rendre les données "Secret", le cryptage fournit également 1) Intégrité des messages et 2) Trust (authentification de la source).
ai-je raison de soupçonner qu'il existe une faiblesse inhérente ici? à la valeur de visage, il semble fonctionner si la clé symétrique est gérée correctement. Manque de cette clé, je ne saurais certainement pas comment modifier un jeton crypté ou lancer une sorte d'attaque cryptographique après avoir intercepté plusieurs jetons. Mais un attaquant plus sophistiqué serait-il capable d'exploiter quelque chose ici?
3 Réponses :
Une approche de cryptage symétrique est aussi sécurisée que la clé. Si les deux systèmes peuvent recevoir la clé et maintenir la clé de manière sécurisée, c'est bien. La cryptographie publique publique est certainement un ajustement plus naturel.
Son cryptage symétrique true et symétrique est aussi sécurisé que sa clé - mais la question que vous devriez demander est "en sécurité pour quoi?" Comme l'a souligné l'OP, le cryptage symétrique est idéal pour la confidentialité, mais ne vous aide pas du tout avec intégrité.
Bien sûr que ça fait. Vous ne pouvez pas construire un faux message à partir de l'expéditeur sans la clé symétrique, comme dans la cryptographie de clé publique, vous ne pouvez pas simuler un message de l'expéditeur sans leur clé privée.
Je pense que vous vouliez dire que cela n'aide pas l'authentification, ce qui ne le fait pas, mais depuis que l'OP a parlé de deux applications communiquant, je ne suis pas sûr de la pertinence.
L'authentification est importante car le canal de communication est public, c'est-à-dire que le jeton fait partie d'une demande HTTP. Toute personne sur Internet peut tenter de construire un faux jeton et de le soumettre à la composante de traitement de jeton de l'application. En plus du cryptage AES, nous avons utilisé un HMAC pour authentifier le jeton et vous assurer une intégrité des messages. (Comme suggéré par Avid, Accipitridae et Tom)
@Michael je pense que tu m'as mal compris. S'il existe un certain nombre d'applications / machines autorisées à communiquer à l'aide de ce canal, le cryptage symétrique ne fournit aucun moyen de distinguer leur identité. Le fait même qu'ils peuvent construire un jeton valide suffit à garantir une autorisation sécurisée. Bien que je ne puisse pas passer à 100% de votre commentaire si c'est ce que vous conduisez.
Une partie de celle-ci dépend du mode de cryptage. Si vous utilisez ECB ( honte sur vous! ) Je pourrais échanger des blocs autour, modifier le message. Stackoverflow a été touché par ce bogue très bogue .
moins menaçant - sans aucune vérification d'intégrité, je pourrais effectuer une attaque homme-intermédiaire et échanger toutes sortes de bits autour, et vous le recevriez et essayez de le déchiffrer. Vous échoueriez bien sûr, mais la tentative peut être révélatrice. Il existe des attaques de canal latéral par "Bernstein (exploitant une combinaison de cache et de caractéristiques de cache et de microarchitecturales) et d'Osvik, Shamir et TROMER (exploitant des collisions de cache) s'appuient sur la prise de données statistiques basées sur un grand nombre de tests aléatoires". 1 L'article noté de bas de page est par un cryptographe de plus grande note que moi, et il conseille de 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 mauvais apport à un
bloc de code, cependant, vous
réduire considérablement la chance qu'il
sera capable d'exploiter tous les bugs
Bien placé! De plus, le point d'utiliser un Mac au lieu de la signature numérique (protection de l'intégrité via un cryptage symétrique au lieu de la cigraphie clé publique) est un excellent point - aucun point de tous ces frais généraux pour RSA / DSA et similaires, car votre système est le seul celui qui doit le vérifier.
yup. Le cryptage seul ne fournit pas d'authentification. Si vous souhaitez authentification, vous devez utiliser un code d'authentification de message tel que HMAC ou Signatures numériques (selon vos besoins).
Il existe un grand nombre d'attaques possibles si les messages ne sont que cryptés, mais pas authentifiés. Voici juste un exemple très simple. Supposons que les messages sont cryptés avec CBC . Ce mode utilise un IV pour randomiser le CIPHERText afin de crypter le même message deux fois ne résulte pas du même chiffres. Maintenant, regardez ce qui se passe lors du déchiffrement si l'attaquant modifie simplement le IV mais laisse le reste du CIPHERText tel quel. Seul le premier bloc du message déchiffré changera. De plus, 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 récepteur décrypte le message. Si ce premier bloc Était par exemple un horodatage A l'attaquant le sait lorsque le message d'origine a été envoyé, il peut facilement réparer l'horodatage à tout moment, juste en retournant les bits de droite.
D'autres blocs du message peuvent également être manipulés, même si c'est un peu plus délicieux. Notez également que ce n'est pas simplement une faiblesse de CBC. D'autres modes tels que OFB, BFC ont des faiblesses similiaires. Ainsi, attendez-vous que le cryptage seul fournit une authentification n'est qu'une hypothèse très dangereuse