web-dev-qa-db-fra.com

Quand utiliser HMAC avec AES?

Un de mes clients souhaite fournir une URL à chacun de ses clients pour s'inscrire dans un système. Cette URL contiendrait un paramètre de chaîne de requête avec certaines données (par exemple, le code, l'e-mail et le nom) de ses clients cryptés à l'aide d'AES avec CBC, similaire à ceci (IV est en gras):

www.website.com/register?key=44a74fb9fad889496e970c604e54fdab a367c6e5802252822ce071c35d7f108aea43e6de925cf93dd3d4772974621927a12702428b1d22d8274706f

Lorsqu'un utilisateur entre dans cette page, il la décrypte et vérifie si les données sont valides (par exemple si le code du client est valide dans une base de données externe et s'il n'est pas déjà enregistré) afin de lui montrer le formulaire d'inscription.

J'ai vu des gens utiliser HMAC avec AES pour crypter des données, mais je ne sais pas si cela est nécessaire dans un cas comme celui-ci. Ma question est: est-ce suffisamment sécurisé? Dois-je utiliser quelque chose comme HMAC avec le texte en clair avant de le chiffrer avec AES pour authentifier les données?

23
Guilherme Sehn

AES est le cryptage ; il est destiné à maintenir la confidentialité. Le chiffrement ne maintient pas l'intégrité par lui-même: un attaquant qui peut accéder aux données chiffrées peut modifier les octets, impactant ainsi les données en texte clair (bien que le chiffrement rend la tâche un peu plus difficile pour l'attaquant, c'est pas aussi irréalisable qu'on le suppose souvent).

Pour obtenir l'intégrité , vous avez besoin d'un MAC , et HMAC est un joli MAC algorithme.

Dans de nombreuses situations où le chiffrement est obligatoire, l'intégrité doit également être maintenue, donc, en règle générale, l'AES "seul" n'est pas suffisant. Dans votre cas, les attaquants potentiels sont les clients eux-mêmes; chaque client peut essayer de modifier l'URL afin d'accéder aux données de quelqu'un d'autre, ou pour pouvoir s'inscrire sous un autre nom, ou autre. Si je comprends bien, votre "client" veut rester maître de l'enregistrement; il veut décider quel client peut s'inscrire et sous quel nom. L'intégrité vérifiée est donc nécessaire.


Il existe plusieurs façons de combiner le chiffrement basé sur AES avec HMAC; la plupart d'entre eux sont mauvais. Voir cette question pour une discussion sur le sujet. Pour faire l'histoire courte:

  • Si vous le pouvez, utilisez GCM ou un autre mode qui fait tout le travail difficile de combiner le chiffrement et MAC en toute sécurité.

  • Si vous ne pouvez pas utiliser GCM (par manque de support dans votre infrastructure de programmation côté serveur), alors vous devez faire les choses à l'ancienne:

    • Hachage de la clé [~ # ~] k [~ # ~] avec SHA-256 pour obtenir 256 bits de "matériau clé". Divisez cela en deux moitiés: 128 bits pour le chiffrement ( Ke), 128 bits pour MAC ( Km).
    • Générez un [~ # ~] iv [~ # ~] aléatoire de 128 bits. Vous en avez besoin d'un nouveau chaque fois que vous cryptez et vous souhaitez le générer avec un fort PRNG (/dev/urandom).
    • Remplissez les données (remplissage PKCS # 5 habituel) de sorte que leur longueur soit un multiple de la taille du bloc AES (16 octets).
    • Chiffrez les données avec AES en mode CBC, en utilisant l'IV généré juste au-dessus, et Ke comme clé. Appelons [~ # ~] c [~ # ~] le texte chiffré résultant.
    • Calculez HMAC/SHA-256 avec la clé Km sur la concaténation de [~ # ~] iv [~ # ~] et [~ # ~] c [~ # ~] , dans cet ordre. Appelez [~ # ~] m [~ # ~] la valeur résultante. Il est crucial que le [~ # ~] iv [~ # ~] fasse partie de l'entrée de HMAC.
    • Concaténer [~ # ~] iv [~ # ~], [~ # ~] c [~ # ~] et [~ # ~] m [~ # ~], dans cet ordre. Il s'agit de votre "clé d'enregistrement".
    • Lors de la réception d'une demande d'enregistrement, vérifiez d'abord le HMAC (en le recalculant), puis (et alors seulement) passez à l'étape de décryptage.

Bien sûr, tout cela suppose qu'il existe une clé [~ # ~] k [~ # ~], que votre client peut utiliser pour générer les clés d'enregistrement pour les clients, et que votre le serveur sait également afin de vérifier et de décrypter les demandes d'enregistrement entrantes. Comme pour toutes les clés, faites attention où vous les stockez.

38
Thomas Pornin