Décryptage AES dans iOS: PKCS5 rembourrage et de la CBC

Je suis en œuvre pour iOS certains le code de décryptage d'un message d'origine sur un serveur sur lequel je n'ai aucun contrôle. Une précédente mise en œuvre sur une plate-forme de documents le déchiffrement des exigences AES256, spécifie la clé et le vecteur d'initialisation, et dit aussi:

 * Cipher Mode: CBC
 * Padding: PKCS5Padding

Les options pour la création d'un CCCryptor objet inclure uniquement kCCOptionPKCS7Padding et kCCOptionECBMode, notant que la SRC est la valeur par défaut. À partir de ce que je comprends au sujet de rembourrage pour le cryptage, je ne comprends pas comment on peut utiliser les deux; je pensais qu'ils étaient mutuellement exclusives. Dans la création d'un CCCryptor pour le déchiffrement, j'ai essayé d'utiliser à la fois un 0 pour les options et les kCCOptionPKCS7Padding, mais les deux me donner charabia après décryptage.

J'ai comparé le vidage de ce décryptage avec un dump de la décodé octets de la mémoire tampon sur l'autre plate-forme et confirmé qu'ils sont vraiment différents. Donc, il y a quelque chose que je suis en train de faire différentes dans cette mise en œuvre, qui est sensiblement différent, je ne sais pas quoi... Et n'ont pas la moindre idée de comment faire pour obtenir une poignée sur elle. Les plates-formes sont assez différentes qu'il est difficile de déduire beaucoup de la précédente mise en œuvre, car il est basé sur une plate-forme différente. Et bien sûr, l'auteur de la précédente mise en œuvre a depuis quitté.

Toute devine quoi d'autre pourrait être incompatible ou comment résoudre cette chose?

OriginalL'auteur Paul Mailman | 2011-02-09

  1. 6

    PKCS#5 de rembourrage et de remplissage PKCS#7 sont pratiquement les mêmes (ajout d'octets 01, ou 0202, ou 0303 etc jusqu'à la longueur de la taille du bloc de l'algorithme, 16 octets dans ce cas). Officiellement PKCS#5 rembourrage doit être utilisé uniquement pour les blocs de 8 octets, mais dans de nombreux environnements d'exécution, les deux peuvent être échangés sans problème. Rembourrage se produit toujours à la fin du texte chiffré, donc, si vous obtenez juste du charabia ce n'est pas le rembourrage. La BCE est un bloc de mode de fonctionnement (qui ne doit pas être utilisé pour chiffrer les données qui peuvent être distingués à partir de nombres aléatoires) : elle aurait besoin de rembourrage, de sorte que les deux ne sont pas mutuellement exclusives.

    Enfin, si vous venez d'effectuer le décryptage (pas MAC qui pratiquent ou d'autres formes de contrôle d'intégrité), et vous retourner le résultat de la unpadding sur le serveur (le déchiffrement a échoué), vos données en texte brut n'est pas en sécurité à cause de padding oracle attaques.

    PKCS#5 rembourrage est pas le même que le remplissage PKCS#7. Alors que les deux pad jusqu'à la longueur du bloc, PKCS#5 rembourrage est seulement approprié pour les algorithmes de chiffrement avec des blocs de 8 octets, PKCS#7 s'étend jusqu'à l'arbitraire d'un bloc de longueur. Ils peuvent se comporter de la même où il y a moins de 8 octets de remplissage requis et en Java PKCS bibliothèques qu'ils utilisent le remplissage PKCS#7 et il PKCS#5, mais elles sont différentes
    Oui, je sais, mais en Java qui utilise exactement la "PKCS5Padding" chaîne de caractères donnée pour la configuration du serveur - c'est en fait identique à remplissage PKCS#7. C'est le cas pour la plupart des applications qui permettent PKCS#5 rembourrage pour les différents algorithmes de chiffrement par bloc. Précisé dans la réponse...

    OriginalL'auteur Maarten Bodewes

  2. 4

    Tout d'abord, vous pouvez vous soucier de le rembourrage plus tard. Fournir 0 comme vous l'avez fait signifie AES CBC sans rembourrage, et avec cette configuration, vous devriez voir votre message à l'amende juste. Albiet potentiellement avec quelques octets de remplissage sur la fin. De sorte que des feuilles:

    1. Vous n'êtes pas le chargement de la clé correctement.
    2. Vous n'êtes pas le chargement de la IV correctement.
    3. Vous n'êtes pas charger les données correctement.
    4. Le serveur est en train de faire quelque chose que vous n'attendiez pas.

    De débogage, vous devez isoler votre système. Vous pouvez le faire en mettant en œuvre un test de bouclage où vous crypter et décrypter les données assurez-vous que vous êtes en train de charger tout correctement. Mais cela peut être trompeur. Même si vous faites quelque chose de mal (par exemple, le chargement de la clé vers l'arrière), vous pourriez encore être en mesure de déchiffrer ce que vous avez chiffré parce que vous êtes en train de faire exactement la même chose en sens inverse sur les deux côtés.

    Si vous avez besoin de tester contre Known Answer Tests (KATs). Vous pouvez consulter le officiel KATs sur le AES entrée de wikipedia. Mais il se trouve que j'ai posté une autre réponse ici AFIN que nous puissions les utiliser.

    Compte tenu de cette entrée:

    KEY: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
     0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
     0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
     0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f
IV:  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
PLAIN TEXT:   encrypt me
CIPHER TEXT:  338d2a9e28208cad84c457eb9bd91c81

    Vérifier avec un programme tiers que vous pouvez déchiffrer le texte chiffré et obtenir le texte en clair.

    $ echo -n "encrypt me" > to_encrypt
$ openssl enc -in to_encrypt -out encrypted -e -aes-256-cbc \
> -K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
> -iv 0000000000000000
$ hexdump -C encrypted
00000000  33 8d 2a 9e 28 20 8c ad  84 c4 57 eb 9b d9 1c 81  |3.*.( ....W.....|
00000010
$ openssl enc -in encrypted -out plain_text -d -aes-256-cbc \
> -K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
> -iv 0000000000000000
$ hexdump -C plain_text 
00000000  65 6e 63 72 79 70 74 20  6d 65                    |encrypt me|
0000000a

    Donc maintenant essayer de déchiffrer ce-réponse de test dans votre programme. Assurez-vous d'activer le remplissage PKCS7, parce que c'est ce que j'ai utilisé dans cet exemple. Comme un exercice, de les décrypter avec pas de rembourrage et de voir que le résultat est le même, sauf que vous avez des octets de remplissage après la "chiffrer moi" du texte.

    La mise en œuvre de la KAT est un grand pas. Il dit que votre mise en œuvre correcte, mais vos hypothèses sur le comportement du serveur est mal. Et puis il est temps de commencer à interroger ces hypothèses...

    (Et P. S., ces options que vous avez mentionnés ne sont pas mutuellement exclusives. BCE signifie pas de IV, et de la CBC signifie que vous avez une IV. Aucun rapport avec rembourrage.)

    OK, je sais que j'ai dit c'est un exercice, mais je veux prouver que même si vous chiffrer avec rembourrage
    et déchiffrer sans rembourrage, vous n'obtenez pas les ordures. Donc, étant donné la KAT qui a utilisé remplissage PKCS7, nous décrypter avec la pas de rembourrage option et obtenir un message lisible suivie par 06 utilisé comme rembourrage octet.

    $ openssl enc -in encrypted -out plain_text -d -aes-256-cbc \
-K 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f \
-iv 0000000000000000 -nopad
$ hexdump -C plain_text
00000000  65 6e 63 72 79 70 74 20  6d 65 06 06 06 06 06 06  |encrypt me......|
00000010
$

    OriginalL'auteur indiv

  3. 3

    Paul,

    Le PKCS#5 rembourrage est nécessaire pour identifier de rembourrage dans la restitution des données. Pour la CBC, la mémoire tampon d'entrée doit être un multiple de ce chiffre de la taille du bloc (16 pour l'AES). Pour cette raison, la mémoire tampon pour être chiffré est étendu avec des octets supplémentaires. Notez qu'après le cryptage, la taille d'origine de la perte de données. PKCS#5 remplissage permet de récupérer la taille. Cela se fait par le remplissage de l'étendue de la mémoire de données avec la répétition des octets, avec une valeur égale à la marge de la taille. e.g si votre texte clair de la mémoire tampon a été de 12 octets, pour le rendre multiple de 16, vous aurez besoin d'ajouter 4 octets de plus. (Si les données ont été 16, vous allez ajouter des 16 plus pour le faire 32). Ensuite, vous remplissez ces 4 octets avec '0 x 4" pour être conforme avec PKCS#5 rembourrage. Lorsque vous déchiffrer, il suffit de regarder pour le dernier octet de données déchiffrées et de soustraire ce nombre de la longueur de la restitution de la mémoire tampon.

    Ce que vous faites est de rembourrage avec '0'. Bien que vous semblez être heureux de voir les résultats, vous aurez une surprise lors de vos données d'origine se termine dans l'un des plus '0'.

    OriginalL'auteur FractalSpace

  4. 0

    Il s'avère que l'explication de la ce que je vivais était trop simple: j'en ai mal interprété ce que j'ai lu dans la précédente mise en œuvre de laisser entendre que c'était à l'aide d'une clé de 256 bits, mais en fait, c'est à l'aide d'une clé de 128 bits. Le changement et tout d'un coup, ce qui était obscur devient clair. 🙂

    0 pour l'argument options, d'invoquer la CBC, a été tout à fait correct. Ce à quoi la référence à PKCS5 rembourrage dans la précédente mise en œuvre est encore mystérieux, mais qui n'a pas d'importance parce que parce que ce que j'ai fonctionne maintenant.

    Merci pour le coup, indiv.

    OriginalL'auteur Paul Mailman