> Tech > « _CIPHER »

« _CIPHER »

Tech - Par iTPro - Publié le 24 juin 2010
email

L'OS/400 fournit, dans le SLIC (System Licensed Internal Code), une implémentation rapide de SHA-1 et MD5 à  laquelle on peut accéder au moyen de la fonction intégrée ILE " _CIPHER ". La figure 4 présente une procédure " wrapper " écrite en ILE RPG IV autour de la fonction "

« _CIPHER »

_CIPHER « . Le nom de la procédure  » wrapper  » est
HASH.

Pour compiler cette procédure dans un module, utiliser la commande CRTRPGMOD (Create
RPG Module). Après avoir créé un module, utiliser la technique bind-by-reference
(relier par référence) avec la commande CRTSRVPGM (Create Service Program), ou
la technique bind-by-copy (relier par copie) avec la commande CRTPGM (Create Program),
pour mettre la procédure HASH à  la disposition des programmes applicatifs. La
procédure demande quatre paramètres d’entrée. En voici la liste avec leurs types
de paramètres :

· Pointeur vers le message d’entrée – PTR(SPP)
· Longueur du message d’entrée – Binary(4)
· Nom de l’algorithme : ‘MD5’ ou ‘SHA1’ – Char(4)
· Pointeur vers la clé HMAC de 64 octets (facultatif) – PTR(SPP)

La procédure HASH renvoie une valeur de sortie :

· Pointeur vers le digest de hachage, HMAC, ou *NULL – PTR(SPP)

La première fois qu’on appelle HASH, il faut indiquer trois ou quatre paramètres.
Si l’on se contente de trois (pointeur vers le message d’entrée, longueur du message
d’entrée et nom de l’algorithme), HASH crée uniquement un digest de hachage. Si
l’on indique le quatrième paramètre (pointeur vers la clé HMAC de 64 octets),
HASH créera un HMAC.

Cette procédure permet de répartir le message d’entrée sur plusieurs appels adressés
à  HASH. Donc, sur le deuxième appel et les suivants adressés à  HASH, il ne faut
indiquer que deux paramètres (pointeur vers message d’entrée et longueur du message
d’entrée).

HASH maintient une zone de travail dans la mémoire statique du programme entre
des appels discrets. Après avoir haché le dernier morceau du message d’entrée,
appeler à  nouveau HASH sans paramètres. HASH renvoie alors un pointeur vers le
digest de 128 bits ou de 160 bits ou HMAC. HASH se réinitialise lui-même après
que l’on ait reçu un pointeur vers le digest ou HMAC. On peut alors appeler à 
nouveau la procédure avec trois ou quatre paramètres pour démarrer un nouveau
calcul de hash.

La longueur de clé minimale autorisée par  » _CIPHER  » est de 16 octets pour MD5
et de 20 octets pour SHA-1.  » _CIPHER  » n’a pas de longueur de clé maximale ;
cependant, si la longueur de clé dépasse 64 octets,  » _CIPHER  » hachera la clé
avant de l’utiliser dans le HMAC. J’ai choisi une longueur de clé fixe de 64 octets
dans la procédure  » wrapper  » HASH parce que 64 m’a semblé facile à  mémoriser
; on peut choisir une autre longueur plus appropriée.

La figure 5 montre une utilisation de HASH. C’est un programme ILE RPG IV qui
calcule un HMAC sur trois champs : ITEM, TEXT et COST. Notons que HASH est appelé
quatre fois : une fois pour chaque champ, et une fois pour recevoir un pointeur
vers le HMAC. Seul le premier appel indique le type d’algorithme (MD5) et le pointeur
de clé. La clé secrète est transmise dans ce programme au moyen d’un programme
externe. Dans une application réelle, on pourrait demander un mot de passe à  l’utilisateur
et utiliser la réponse pour la clé secrète.

Conclusion
Le résultat de MD5 est un champ de 16 octets. Le résultat de SHA-1 est
un champ de 20 octets. Il faudra choisir entre l’utilisation d’un digest de hachage
et l’utilisation d’un HMAC, si on ajoute un champ dans un fichier physique pour
contenir une valeur de hachage unidirectionnel des autres champs dans chaque enregistrement.
Si l’on choisit HMAC, il faudra intégrer un mot de passe secret dans l’application.

S’il vous semble que le cryptage unidirectionnel n’a pas d’applications concrètes,
lisez donc l’article de Mel Beckman intitulé  » Protocoles de sécurité : Etat des
lieux « . Mel décrit une application parfaite pour les hachages MD5 (à  laquelle
j’ai déjà  fait allusion dans cet article) : crypter des numéros de cartes de crédit
afin qu’on puisse les vérifier mais pas les divulguer par inadvertance.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010