par Gene Gaunt
De l'usage des blocs élémentaires de la cryptographie pour se protéger contre
l'altération des données sensibles
Supposons un fichier de données sensibles, que les utilisateurs peuvent visualiser
mais non modifier et que les programmes peuvent ouvrir et lire, mais pas mettre
à jour. Supposons que vous vouliez créer des requêtes SQL et des fichiers logiques
sur ces champs de données sans processus de cryptage de données. Comment les programmes
en lecture seule peuvent-ils détecter facilement si un enregistrement du fichier
a été modifié ? Ne serait-il pas intéressant d'avoir un indicateur d'intégrité
des données (du genre *INxx) que l'on testerait après un accès en RPG par le code
opération CHAIN ?
Supposons qu'un de vos partenaires de commerce électronique demande de vérifier
si vous possédez une copie authentique de l'un de ses enregistrements. Pour des
raisons de sécurité, il ne veut pas que vous lui envoyiez l'enregistrement. Quel
type d' " empreinte digitale " pouvez-vous lui envoyer pour vérifier votre copie
?
Supposons une boutique Web acceptant des commandes par carte de crédit. Une fois
la commande traitée, on transmet en toute sécurité le numéro de la carte de crédit
à la banque pour collecter l'argent, après quoi on n'a plus besoin du numéro.
Toutefois, on peut fort bien être appelé ultérieurement pour vérifier si un numéro
de carte donné a payé pour la commande. Comment le faire sans stocker le numéro
dans une base de données, avec tous les risques en cas de divulgation involontaire
ultérieure ?
Précisément, la fonction de hachage unidirectionnel est un moyen pratique et rapide
d'assurer l'intégrité des données au moment de la lecture de l'enregistrement.
Il suffit d'ajouter au fichier critique une colonne qui contiendra une valeur
de hachage unidirectionnel des autres colonnes de l'enregistrement. On calculera
et écrira cette valeur de hachage dans chaque enregistrement au moment de la création
du fichier. Au moment de la lecture de l'enregistrement, on recalculera cette
valeur et on la comparera à la valeur écrite. En cas de différence, le programme
pourra signaler à l'utilisateur que l'enregistrement a été modifié.
Il existe une autre solution moins séduisante au problème de la vérification des
données. Elle consiste à attacher un trigger ou un récepteur de journal au fichier
critique, puis à bâtir une liste de contrôle sécurisée et inaccessible (par les
utilisateurs ordinaires). Toutefois, comme les journaux et les triggers ne se
déclenchent pas quand les enregistrements sont lus par une application, le timing
de cette technique est discutable. La lourdeur des consultations des listes de
contrôle risque de freiner les performances du système. Il faut aussi songer à
protéger la liste de contrôle (" contrôler le contrôle "). En revanche, les fonctions
de hachage unidirectionnel donnent un accès rapide aux enregistrements avec des
blocs élémentaires de cryptographie. Elles peuvent aussi aider à prouver que l'on
possède (ou que l'on a possédé) une information particulière comme un numéro de
carte de crédit.
L’intégrité des données avec les fonctions de hachage unidirectionnel
Une fonction de hachage unidirectionnel est un processus qui comprime une chaîne
d’entrée de longueur variable en une chaîne de sortie de longueur fixe (la purée
de pommes de terre est un excellent exemple de fonction de hachage unidirectionnel
: elle est facile à obtenir mais il est impossible de revenir en arrière pour
reconstituer les pommes de terre.) La sortie d’une fonction de hachage unidirectionnel
porte plusieurs noms en informatique : total de contrôle, valeur de validation,
code de redondance cyclique, empreinte digitale numérique, bits de compression,
mot de détection de manipulation, et digest de message. Dans cet article, on utilisera
simplement le terme digest.
Les fonctions MD5 et SHA-1 sont toutes deux calculables par l’API » _CIPHER
«
Un digest ne dépasse généralement pas 20 octets et authentifie un message si la
fonction de hachage unidirectionnel est sûre. Pour être sûre, cette fonction doit
créer un digest ne permettant absolument pas, par un calcul, de trouver un message
correspondant au digest ou de trouver deux messages différents produisant le même
digest. Autrement dit, un digest sûr doit être facile à calculer mais difficile
à inverser. L’aspect » difficile à inverser » donne à l’utilisateur de la fonction
de hachage, un délai de sécurité contre une attaque visant le message. Par conséquent,
un digest indique si un message candidat a toutes les chances d’être le message
réel ou une contrefaçon.
Le monde de la cryptographie a récemment créé un puissant ensemble de fonctions
de hachage unidirectionnels standard : MD5 et SHA-1. Elles sont toutes deux calculables
par une API AS/400 nommée » _CIPHER « . Cette API est une fonction intégrée ILE
documentée dans Machine Interface Functional Reference (SC41-5810). Ce manuel
n’appartient pas à la bibliothèque en ligne AS/400 d’IBM, mais on peut le commander
sous forme imprimée auprès du Software Solutions Center d’IBM à Boulder, Colorado.
MD5 et SHA-1 peuvent participer aux deux cryptosystèmes : clé privée et clé publique.
La différence entre les deux est la symétrie des clés. Pour le cryptage/décryptage,
un cryptosystème à clé privée utilise une clé partagée unique et un cryptosystème
à clé publique utilise une paire de clés reliées par une fonction de trappe mathématique.
Le format de courrier électronique MIME (Multipurpose Internet Mail Exchange),
par exemple, utilise la cryptographie à clé publique avec une fonction de hachage
unidirectionnel. Lorsqu’un utilisateur MIME (que nous appellerons Alice) envoie
un message électronique, il applique une fonction de hachage unidirectionnel à
son message et crée un digest de message temporaire (figure 1). Ensuite, il crypte
le digest temporaire avec sa clé privée pour créer une signature numérique, ajoute
celle-ci à son message électronique et envoie les deux éléments à son partenaire.
Quand Bob, le partenaire d’Alice, reçoit le message électronique, il décrypte
la portion de signature numérique avec la clé publique d’Alice, extraite de son
trousseau de clés publiques. Si le digest de message résultant est égal au hachage
unidirectionnel de la portion de message électronique originale, Bob sait qu’Alice
a envoyé le message. Les signatures numériques demandent une infrastructure de
clé publique, comportant un tiers de confiance chargé d’authentifier les signatures.
Nous n’entrons pas ici dans le détail des signatures numériques.
Il existe une autre technique d’authentification des signatures numériques dans
laquelle une clé secrète permet de générer un digest du message. Avec un HMAC
(Hash Message Authentication Code), Alice et Bob conviennent de partager une clé
secrète avant d’échanger du courrier électronique. Quand Alice envoie du courrier
électronique à Bob, elle utilise leur clé secrète commune pour générer un HMAC
sur son message, puis elle lui ajoute le HMAC. Quand Bob reçoit le courrier électronique,
il utilise sa clé secrète partagée pour générer un HMAC sur le message, et il
le compare à celui qu’a envoyé Alice. S’ils correspondent, Bob sait que c’est
bien Alice qui a envoyé le message (à condition bien sûr qu’elle n’ait confié
la clé secrète à personne !). La fonction intégrée » _CIPHER » de l’AS/400 possède
une option HMAC.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
