ISO 8730:1990

ISO
NORME
INTERNATIONALE
Deuxième édition
1990-05-l 5
- Spécifications liées à
Opérations bancaires
l’authentification des messages
Requirements for message authentication (wholesale)
Banking -
Numéro de référence
ISO 8730: 1990(F)
Sommaire
Page
q
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Reférences normatives
3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Protection
Génération et vérification du code d’authentification de message
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
(MAC)
. . . . . . . . . . . . . . . . 4
6 Procédures d’authentification de message
7 Procédure d’approbation des algorithmes d’authentification . . . 7
Annexes
A. Procédure d’examen d’autres algorithmes d’authentification . . 8
6. Risques associés aux caractéres de contrôle de communica-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .lO
C. Protection contre la répétition et la perte . . . . . . . . . . . . . . . . . 12
D. Exemple de message d’authentification pour jeux de caractères
codés:DEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
E. Exemple d’authentification de message pour jeux de caractères
codés:MAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .lg
F. Cadre pour l’authentification de messages télex normalisés . . 24
G. Un générateur de clé pseudo-aléatoire . . . . . . . . . . . l . . . . . . 26
8 ISO 1990
Droits de reproduction réservés. Aucune partie de cette publication ne peut être repro-
duite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de i’éditeur.
Organisation internationale de normalisation
Case Postale 56 l CH-121 1 Genève 20 l Suisse
Imprimé en Suisse
ii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération
mondiale d’organismes nationaux de normalisation (comités membres
de I’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de I’ISO. Chaque comité membre inté-
ressé par une étude a le droit de faire partie du comité technique créé
à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec I’ISO participent également aux tra-
vaux. L’ISO collabore étroitement avec la Commission électrotechnique
internationale (CEI) en ce qui concerne la normalisation électrotech-
nique.
Les projets de Normes internationales adoptés par les comités techni-
ques sont soumis aux comités membres pour approbation, avant leur
acceptation comme Normes internationales par le Conseil de I’ISO. Les
Normes internationales sont approuvées conformément aux procédures
de I’ISO qui requièrent l’approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 8730 a été élaborée par le comité techni-
que ISO/TC 68, Banque et services financiers liés aux opérations ban-
caires.
Cette deuxième édition annule et remplace la première édition (ISO
8730~1:1986), qui a fait l’objet d’une révision technique afin de clarifier
les améliorations déjà apportées dans cette édition.
Ces améliorations sont déjà apportées dans le document ANSI X9.9 pu-
blié en août 1986 et le nouveau texte reste cohérent avec le texte publié
par I’ANSI.
Les changements spécifiques apportés dans la présente édition sont:
a) les données présentées pour authentification peuvent être formatées
de cinq manières différentes. Le processus de choix permet aux uti-
lisateurs d’authentifier les messages selon l’option de format qui
convient le mieux au processus de transmission utilisé;
Les correspondants doivent maintenant se mettre d’accord sur I’op-
tion de format pour l’authentification de tout message particulier,
ceci ne devenant pas en fait une obligation majeure pour les parties
concernées étant donné que le mode de sélection sera déterminé
par le choix du processus de transmission;
b) introduction d’une nouvelle zone permettant d’identifier la clé
d’authentification utilisée (zone IDA);
plusie lurs définitions o nt aussi été modifiées afin d’assurer la cohé-
Cl
rente avec les autres Normes internationales du TC 68.
. . .
III
Dans le même temps quatre nouvelles annexes ont été ajoutées, toutes
dans l’intention de simplifier la mise en œuvre de la présente Norme
internationale:
a) l’annexe B décrit les risques associés à l’introduction accidentelle
de caractères de contrôle au cours du processus de reformatage et
la manière dont ces risques peuvent être réduits;
b) l’annexe D et l’annexe E fournissent des exemples de calcul
d’authentification au moyen des algorithmes spécifiés dans
I’ISO 8731:1987, Parties 1 et 2;
c) l’annexe F décrit un moyen d’application de la présente Norme
internationa le à u n ordre de paiement par télex formaté conformé-
ment aux presciptions de I’ISO 7746.
L’annexe A fait partie intégrante de la présente Norme internationale.
Les annexes B et C et D et E et F et G sont données uniquement à titre
d’information.
iv
Introduction
Un code d’authentification de message (MAC) est une zone de données
annexée à un ensemble de données (ou message) échangé entre des
institutions financières et transmis avec cet ensemble de données. II
découle du message complet ou de certains éléments spécifies dans le
message devant être protégés contre une altération accidentelle ou
frauduleuse.
Quelle que soit la nature de l’altération, le niveau de protection offert
par un algorithme donné dépend d’une part de la longueur du code
d’authentification de message (MAC) et de la clé d’authentification et,
d’autre part, de la possibilité qu’ont les deux correspondants de pré-
server la confidentialité de leur clé d’authentification. La mise en œuvre
de la présente Norme internationale implique l’adhésion des corres-
pondants à ces principes. La liste des algorithmes approuvés figure
dans I’ISO 8731. Les techniques de gestion de clé sont spécifiées dans
I’ISO 8732. La fiabilité mathématique d’un algorithme normalisé est
calculée en partant du principe que le fraudeur potentiel est confronté
à un nombre arbitrairement grand de messages en clair, contenant
chacun son MAC associé, calculé d’après une même clé d’authentifï-
cation. La fiabilité est alors déterminée par la puissance de calcul né-
cessaire au fraudeur pour déterminer la clé d’authentification et par la
longueur du MAC.
Page blanche
-
NORME INTERNATIONALE ISO 8730:1990(F)
Opérations bancaires - Spécifications liées à
l’authentification des messages
l’intégrité de la présentation des données (voir an-
1 Domaine d’application
nexe B). La présente Norme internationale offre un
moyen de protection contre la répétition et la perte;
une méthode est décrite à l’annexe C.
La présente Norme internationale est concue pour
La présente Norme internationale vise l’utilisation
être utilisée par des institutions échangeant des
d’algorithmes symétriques, l’expéditeur et le desti-
messages financiers. Elle peut servir à authentifier
nataire utilisant la même clé. Des dispositions se-
des messages transmis par un service de télécom-
ront prises en temps utile pour traiter de l’emploi
munication ou tout autre mode de transmission.
d’algorithmes asymétriques. La méthode d’authen-
tification s’applique à des messages formatés et
La présente Norme internationale spécifie les mé-
transmis sous forme de jeux de caractères codés
thodes à utiliser pour protéger l’authenticité de
ou de données binaires.
messages financiers liés à l’activité d’entreprise
échangés par des institutions (entre banques, entre
La présente Norme internationale n’indique pas de
une banque et une société ou un gouvernement), en
méthode de protection contre la lecture et la mani-
recourant à un code d’authentification de messages
pulation non autorisées, telle quelle peut être obte-
(MAC). Elle spécifie la méthode d’approbation des
nue par chiffrement du message comme décrit dans
algorithmes d’authentification en vue de leur inté-
I’ISO 10126’).
gration à I’ISO 8731. L’application de la présente
Norme internationale n’est pas une garantie contre
la fraude interne, qu’elle soit du fait de l’expéditeur
ou du destinataire, par exemple la contrefacon d’un
2 Références normatives
MAC par le destinataire.
Les normes suivantes contiennent des dispositions
La présente Norme internationale spécifie une
qui, par suite de la référence qui en est faite,
technique de protection de message, dans sa tota-
constituent des dispositions valables pour la pré-
lité ou dans certains de ses éléments. Les données
sente Norme internationale. Au moment de la pu-
présentées à l’authentification peuvent être
blication, les éditions indiquées étaient en vigueur.
formatées sous une forme à choisir parmi cinq op-
Toute norme est sujette à révision et les parties
tions. Ces spécifications peuvent être complétées
prenantes des accords fondés sur la présente
par un groupe d’institutions financières présentant
Norme internationale sont invitées à rechercher la
des intérêts communs et qui ont pris des dispo-
possibilité d’appliquer les éditions les plus récentes
sitions fonctionnelles propres (par exemple un
des normes indiquées ci-après. Les membres de la
consortium bancaire, un regroupement géographi-
CEI et de I’ISO possèdent le registre des Normes
que, un réseau d’exploitation, un accord de secteur
internationales en vigueur à un moment donné.
industriel). Le choix de l’option appropriée permet
une authentification des messages compatibles
ISO 646:1983, Traitement de l’information - Jeu /SO
avec le système de transmission utilisé.
de caractères codés à 7 éléments pour l’échange
La protection de l’intégrité s’applique uniquement d’information.
aux éléments d’authentification choisis. Les alté-
rations des autres parties du message ne sont pas ISO 7746:1988, Banque - Messages télex interban-
décelées. II incombe aux utilisateurs de garantir cakes.
1) À publier.
3.7 biais: La situation dans laquelle au cours de la
ISO 7982-l : 1987, Télécommunication bancaire -
Messages de transfert de fonds - Partie 1: Vocabu- création de nombres aléatoires ou pseudo-
laire et éléments de données. aléatoires, certains nombres sortent plus souvent
que d’autres.
ISO 8601:1988, Éléments de données et formats
d’échange - Echange d’information - Représen-
3.8 période de validité: Période de temps définie
tation de la date et de l’heure.
au cours de laquelle une clé de chiffrement spécifi-
que peut être utilisée, ou au cours de laquelle les
ISO 8731-1:1987, Banque - Algorithmes approuvés
clés de chiffrement peuvent rester efficaces dans un
pour l’authentification de messages - Partie 1:
système donné.
DEA.
ISO 8732:1988, Banque - Gestion de clés.
3.9 intégrité des données: Capacité qu’ont des
données de ne pas pouvoir être altérées ou dé-
ISO 10126~1:--J), Banque - Procédures de chif-
truites d’une manière frauduleuse.
frement de message - Partie 1: Principes généraux.
ISO 10126-2:-*), Banque - Procédures de chif-
3.10 date de calcul du MAC (DMC): Date à laquelle
fremenf de message - Partie 2: Algorithmes.
l’expéditeur calcule le code d’authentification de
message. Cette date peut être utilisée pour syn-
chroniser le processus d’authentification en choi-
sissant la clé appropriée.
3.11 authentification de l’origine des données:
Confirmation que la source des données recues est
3 Définitions
I
celle revendiquée.
Pour les besoins de la présente Norme internatio-
nale, les définitions suivantes s’appliquent. Les ter-
3.12 déchiffrement: L’inverse du chiffrement
mes imprimés en italique dans les définitions sont
reversible correspondant.
définis ailleurs dans le présent article.
3.1 algorithme: Processus mathématique propre à 3.13 décryptage: voir déchiffrement.
un calcul; un ensemble de règles dont l’application
donne un résultat d’éterminé.
3.14 délimiteur: Groupe de caractères servant à
marquer le début et la fin d’une ou plusieurs zones
3.2 authentification: Processus appliqué par I’ex-
de données.
péditeur et le destinataire pour garantir l’intégrité
des données et fournir l’authentification de l’origine
des données.
3.15 double contrôle: Intervention d’au moins deux
entités (généralement des personnes), opérant de
concert, pour protéger des fonctions ou des infor-
3.3 algorithme d’authentification: Algorithme utilisé
mations sensibles, aucune entité ne pouvant seule
conjointement à une clé d’authentification et un ou
accéder à des (ou utiliser les) données, par exemple
plusieurs éléments d’authentification, à des fins
clé de chiffrement.
d’authentification.
3.16 chiffrement: Transformation cryptographique
3.4 élément d’authentification: Élément de message
de données en vue de produire un texte chiffré.
que l’on désire protéger par l’authentification.
3.17 cryptage: voir chiffrement.
3.5 clé d’authentification: Clé de chiffrement utili-
sée pour l’authentification.
3.18 chiffre hexadécimal: Caractère unique choisi
dans l’intervalle O-9, A-F (majuscule), représentant
3.6 bénéficiaire(s): Le ou les interlocuteur(s) qui
doit/doivent être crédité(s) ou payé(s) à I’aboutis- une série de quatre éléments binaires, comme suit:
sement d’un transfert.
2) À publier.
Binaire Décimal Héxadécimal
4 Protection
0000 0 0
0001 1 1 4.1 Protection de l’identité de l’expéditeur et
du destinataire
0010 2 2
0011 3 3
Afin d’empêcher l’usurpation d’identité de I’expédi-
0100 4 4
teur, la clé d’authentification doit être protégée et
0101 5 5
son utilisation doit être restreinte à l’expéditeur et
au destinataire (ou leurs représentants attitrés).
0110 6 6
0111 7 7
4.2 Éléments d’authentification
1000 8 8
1001 9 9
4.2.1 Les éléments d’authentification suivants doi-
1010 10 A
vent toujours être inclus dans le calcul du MAC:
1011 11 B
a) date de calcul du MAC (DMC);
1100 12 C
1101 13 D
b) identificateur de message (MID).
1110 14 E
1111 15 F
4.2.2 Les éléments d’authentification suivants doi-
vent toujours être inclus dans le calcul du MAC,
3.19 identificateur de clé d’authentification (IDA):
lorsqu’ils apparaissent dans le message:
Zone qui identifie la clé à utiliser pour authentifier
le message.
a) montant de la transaction;
b) devise;
3.20 code d’authentification de message (MAC):
Code contenu dans un message entre un expéditeur
c) identificateur de clé d’authentification (IDA);
et un destinataire, utilisé pour valider la source et
une partie ou l’ensemble du texte du message. Le
d) identification des entités à créditer et à débiter;
code est le résultat d’un calcul ayant fait l’objet d’un
accord.
e) identification du bénéficiaire;
3.21 élément de message: Groupe de caractères
f) date de valeur.
contigus utilisable dans un but spécifique.
4.3 Protection du message dans son
3.22 identificateur de message (MID): Zone utilisée
ensemble
pour identifier de manière unique un message fi-
nancier ou une transaction (exemple, référence de
Lorsque les correspondants souhaitent protéger le
la transaction de la banque expéditrice).
texte complet du message, le processus d’authenti-
fication doit s’appliquer au texte entier (voir 6.5 et
3.23 texte du message: Informations acheminées
. .
6 7)
ou transmises entre I’expédifeur et le destinataire,
en excluant les informations d’en-tête
et de fin de
transmission, liées à la transmission. 4.4 Protection contre la répétition et la perte
Pour assurer la protection contre la répétition et la
3.24 destinataire: Personne, institution ou autre
perte, une référence unique de transaction (ou
entité dûment autorisée et responsable de la ré-
identificateur de message) doit être utilisée.
ception du message.
L’identificateur de message (MID) est une valeur qui
n’est pas répétée avant (i) le changement de date
3.25 expéditeur: Personne, institution ou autre en-
(c’est-à-dire la date de calcul du MAC), ou (ii) I’ex-
tité dûment autorisée et responsable de l’envoi du
piration de la période de validité de la clé utilisée
message.
pour l’authentification, selon l’événement survenant
le premier, c’est-à-dire qu’il ne doit pas y avoir plus
3.26 date de valeur: Date à laquelle les fonds doi-
d’un message avec la même date et le même
vent être à la disposition du bénéficiaire.
identificateur de message utilisant la même clé.
Cette exigence peut être satisfaite par l’inclusion
3.27 service de télécommunication: Tout service de d’un numéro de référence unique pour la transac-
télécommunication autorisant l’échange de messa- tion de la banque expéditrice dans un message à
ges entre abonnés. format fixe servant d’identificateur de message.
Dans les messages de format libre, la zone du MID puisse être identifié par le destinataire. (Pour les
doit être délimitée conformément à la présente messages de format libre voir 6.3.3.) Le destinataire
Norme internationale (voir 6.3.1). Une méthode de répète le calcul en utilisant la même méthode d’au-
protection est donnée à l’annexe C. thentification que celle décrite dans cette section.
Le message est authentifié si le MAC recu et le MAC
de référence calculé sont identiques. ’
5 Génération et vérification du code
d’authentification de message (MAC)
6.2 Options de format
5.1 Génération
La présente Norme internationale offre cinq options
pour le format des données à authentifier:
L’expéditeur d’un message doit générer un MAC en
traitant (dans l’ordre où ils apparaissent dans le
1) données binaires; (6.4);
message) les éléments d’authentification des mes-
sages transmis qui doivent être protégés dans un
2) caractères codés; (6.5); texte complet du
algorithme d’authentification approuvé (voir
message, pas de mise en page
ISO 8731). L’algorithme doit fonctionner avec une
clé d’authentification échangée préalablement avec
3) caractères codés; (6.6); éléments extraits du
le destinataire et qui n’est connue que des deux
message, pas de mise en page
correspondants. Ce processus donne naissance au
MAC, qui doit être inclus dans le texte du message
ères codés; (6.7); texte complet du
4) caract
original, en tant que zone de données supplémen-
message; mise en page
taires.
caractères cod és; (6. 8); éléments extraits du
5)
5.2 Vérification
m essage; mise en
page
À la réception du message, le destinataire doit cal- e pour authentifier une chaîne
L’option 1 est concu
culer un MAC de référence, en utilisant les éléments
binaire de don nées.
d’authentification, une clé d’authentification identi-
Les options 2 et 3 sont concues pour authentifier les
que et un algorithme identique. L’authenticité des
données sous forme de jeux de caractères codés
éléments d’authentification et la source du message
chaque fois que le moyen de transmission offre une
sont confirmés lorsque le MAC de référence calculé
transparence au jeu de caractères, par exemple
par le destinataire correspond à celui qui accompa-
systèmes et réseaux concus conformément au mo-
gne le message.
dèle des systèmes ouverts interconnectés (OSI).
Un MAC recu ainsi que ses déli miteurs ne doivent
Les options 4 et 5 sont concues pour I’authentifi-
être i nclus dans le calcul de I’algorit hme.
Pas
cation des données sous forme d’un jeu restreint de
Lorsque le MAC recu ne correspond pas au MAC caractères codés utilisé lorsque le moyen de trans-
de référence calculé: le défaut d’authentification doit mission n’est pas transparent au jeu de caractères
être communiqué conformément à 6.9.2. utilisé, par exemple code baudot, telex et services
de commutation tels que ceux offerts par de nom-
Le processus de génération du MAC est sensible à
breux services internationaux de communication.
l’ordre dans lequel les éléments d’authentification
sont transmis, c’est-à-dire qu’un changement inter- at incombe aux corres-
Le choix de l’option d e form
I
venant dans l’ordre des éléments d’authentification
pondants et doit faire l’objet d un accord bilatéral.
après la génération du MAC se traduit par un défaut
d’authentification.
6.3 Jeux de caractères codés (comme ceux
Les clés utilisés dans les options 2 à 5)
d’authentification du message ne doivent
pas être utilisées comme clés de chiffrement.
6.3.1 Formats définis des éléments de message
6 Procédures d’authentification de
Les formats de zone pour la date de calcul du MAC,
message
l’identificateur de clé d’authentification, le code
d’authentification de message et l’identificateur de
6.1 Processus d’authentification
message sont représentés sous la forme spécifiée
dans la présente Norme internationale. Les formats
Les correspondants doivent convenir de I’algo-
pour les autres éléments de message ne sont pas
rithme à appliquer et aussi échanger une clé d’au-
spécifiés.
thentification secrète. L’expéditeur calcule alors un
MAC utilisant ces éléments. Le MAC doir être joint Les fo rmats de zone doivent être vérifiés comme
au texte du message transmis, de telle sorte qu’il partie intégrante rocessus d’authentification. Si
du P
l’option d’authentification avec mise en page est c) Code d’authentification de message (MAC): QM-
choisie, les formats de zone doivent être vérifiés et -MQ exemple: QM-hhhhbhhhh-MQ;
-
avant la mise en page. S’il se produit une erreur de
) Identificateur de message (MID): QX- et -XQ
formatage, le message ne sera pas authentifié. Les
exemple: QX-aaaaaaaaaaaaaaaa-XQ; et
formats de zone suivants apparaissent comme indi-
.
qué .
) Autres éléments de message: QT- et -TQ exem-
a) Date de calcul du MAC (DMC). La date à laquelle ple: QT-texte-TQ
l’institution expéditrice crée le message doit être
Le ((texte,> délimité dans QT-texte-TQ peut avoir
exprimée conformément à I’ISO 8601 sous la
n’importe quelle longueur autorisée par le service
forme année, mois, jour (de préférence sous
de télécommunication.
forme abrégée, à savoir AAMMJJ), par exemple
851101 pour 1 novembre 1985.
6.3.4 Utilisation des délimiteurs
b) Identificateur de clé d’authentification (IDA).
Cette zone est l’identificateur de la clé d’au-
Les délimiteurs explicites de début et de fin, s’ils
thentification qui doit être conforme aux exi-
existent, doivent se présenter par couples complé-
gences relatives aux identificateurs de clés
mentaires, sans délimiteurs explicites intermédiai-
spécifiées dans I’ISO 8732. Permet de laisser un
res.
message dans le texte sans qu’il apparaisse à
l’impression.
NOTE 1 Si cette condition n’est pas remplie, le message
n’est pas authentifié.
c) Code d’authentification de message (MAC). Le
MAC doit être exprimé sous forme de huit chif-
Le message peut contenir un nombre quelconque
fres hexadécimaux répartis en deux groupes de
de zones de 4extejB délimitées, toutefois, les zones
quatre, séparés par un blanc (hhhhbhhhh), par
-
des DMC, MID, IDA et du MAC ne doivent apparaître
exemple 5A6Fb09C3.
-
qu’une fois dans le message.
Le trait d’union (-) doit figurer dans tous les délimi-
d) Identificateur de message (MID). L’identificateur
de message doit être exprimé sous forme de un teurs explicites.
à seize caractères imprimables
(aaaaaaaaaaaaaaaa). Les caractères autorisés
Représentation des caractères
6‘3.5
sont O-9, A-Z (majuscules), l’espace (b), la vir-
gule (,), le point (.), la barre oblique (/), I’astéris-
Tous les caractères des éléments d’authentification
que (*) et le trait d’union (-); par exemple
qui sont introduits dans l’algorithme doivent être
FN-BU2.5.
représentés par des caractères de 8 bits compre-
nant le jeu de caractères codés à 7 éléments de
6.3.2 Délimiteurs implicites de zone I’ISO 646 (à l’exclusion des caractères nationaux)
précédé d’un zéro (par exemple 0, b7, b6, . .bl).
Lorsque cela nécessite une traduction de code, la
Un élément d’authentification est implicitement dé-
limité si sa place dans le message est fixe ou iden- traduction ne doit servir qu’à des fins internes. Si le
message est transformé en un jeu de caractères
tifiée sans ambiguïté par des règles normalisées de
différents, la transformation inverse doit être appli-
format. Les noms de zone, les nombres, ou les éti-
quée avant que ne débute le processus d’authenti-
quettes mnémoniques d’identification doivent être
fication.
pris en compte pour l’authentification, dès lors que
le service de télécommunication les signale comme
délimiteurs implicites.
6.3.6 Information d’en-tête et de fin
L’information d’en-tête et de fin de message ajoutée
6.3.3 Délimiteurs explicites de zone
(par exemple par un réseau) à des fins de trans-
mission doit être omise, c’est-à-dire qu’elle ne doit
Les délimiteurs explicites peuvent être utilisés pour
identifier le début et la fin des éléments de mes- pas faire partie du texte du message et ne doit pas
sage, y compris le MAC. Ils peuvent être utilisés être incluse dans le calcul de l’algorithme.
dans toutes les options de jeux de caractères codés.
Les délimiteurs explicites suivants sont spécifiés:
6.4 Option 1: Données binaires
a) Date de calcul du MAC (DMC): QD- et -DQ,
exemple: QD-AAMMJJ-DQ; L’algorithme d’authentification doit être appliqué au
texte complet du message, ou à des parties du texte
b) Identificateur de clé d’authentification (IDA): QK- du message, selon l’accord bilatéral conclu entre
et -KQ, exemple: QK-1357BANKATOBANKB-KQ; l’expéditeur et le destinataire.

I§O 8730:1990(F)
6.7.2.1 Chaque retour chariot et chaque chan-
6.5 Option 2: Caractères codés; message
gement de ligne doivent être remplacés par un seul
entier; pas de mise
espace.
message entier; pas de mise en page
6.7.2.2 Les caractères alphabétiques minuscules
Lorsque le traitement du message est automatisé
(a-z) doivent être transcrits en majuscules (A-Z).
et que le contenu précis du corps du message ne
change pas entre l’expéditeur et le destinataire,
l’algorithme peut être appliqué au message entier.
6.7.2.3 Tous les caractères autres que les lettres
A-Z, les chiffres O-9, l’espace, la virgule (J, le point
Le MAC est calculé sur le texte entier du message
(.), la barre oblique (/), l’astérisque (*), les paren-
(voir exemple en annexe D ).
thèses de début et de fin et le trait d’union (-) doi-
vent ëtre supprimés. De même la fin de texte et tout
autre caractéres de formatage et de contrôle doi-
6.6 Option 3: Caractères codés; éléments
vent être supprimés.
extraits du message; pas de
éléments extraits du message; pas de mise en
6.7.2.4 Tous les espaces d’en-tête doivent être
page
supprimés.
6.6.1 Utilisation
6.7.2.5 Chaque série d’espaces consécutifs (inter-
nes et de fin) doit être remplacée par un seul es-
Lorsque l’authentification du message entier n’est
pace.
pas possible, l’algorithme d’authentification doit être
appliqué uniquement aux éléments de message
choisis.
6.8 Option 5: Caractères codés; éléments
extraits du message; mise en
Les éléments de message doivent être extraits
éléments extraits du message; mise en page
conformément aux règles décrites en 6.6.2. Un MAC
doit être calculé sur les éléments extraits, pris dans
6.8.1 Utilisation
l’ordre dans lequel ils apparaissent (voir exemple
dans l’annexe D).
Voir 6.6.1.
6.6.2 Extraction des éléments de message
6.8.2 Extraction des éléments de message
Les éléments de message à authentifier doivent être
Les règles d’extraction décrites en 6.6.2 doivent être
extraits selon les règles suivantes:
appliquées.
6.6.2,1 Supprimer tous les caractères autres que
6.8.3 Mise en page
les éléments du message et leurs délimiteurs cor-
respondants.
Les règles de mise en page décrites en 6.7.2 doivent
être appliquées.
6.6.2.2 Insérer un seul espace après chaque élé-
ment de message implicitement délimité.
6.9 Erreurs sur le code d’authentification du
message (MAC)
6.7 Option 4: Caractères codés; message
entier; mise en page
6.9.1 Incapacité à générer un MAC
message entier; mise en page
Quand le MAC est généré automatiquement, c’est-
6.7.1 Utilisation
à-dire par extraction automatique des éléments
d’authentification, le non-respect des règles préci-
Le MAC doit être calculé sur le texte du message à
tées peut faire échouer l’opération (imbrication des
la suite de la mise en page selon les règles décrites
délimiteurs, par exemple). Dans ce cas et lorsque
en 6.7.2 (voir exemple dans l’annexe D).
l’erreur doit, au minimum, pouvoir être constatée de
facon lisible (par exemple, sur papier, écran ou mi-
crofiche, l’échec de l’opération doit être signalé par
6.7.2 Mise en page
huit espaces (si possible) répartis en deux groupes
de quatre, séparés par un caractère autre qu’un
Les règles de mise en page suivantes doivent s’ap-
chiffre hexadécimal, de préférence un astérisque,
pliquer dans l’ordre présenté, à tous les éléments
par exemple, bbbb*bbbb. Lorsque des espaces ne
de message - délimités implicitement ou explici-
sont pas disponibles, ils doivent être remplacés par
tement - avant le traitement par l’algorithme d’au-
thentification: des zéros; (par exemple, OOOO*OOOO).
6.9.2 MAC recu non authentifié l’authentification être protégée contre
doit toute
communication à des personnes non autorisé es.
Lorsqu’un MAC ne correspond pas au MAC de ré-
férence créé au cours du processus d’authentifi-
7 Procédure d’approbation des
cation et lorsque l’erreur doit pouvoir être constatée
algorithmes d’authentification
de facon lisible, l’échec doit être indiqué par I’in-
sertion d’un caractère d’impression non
Avant qu’un algorithme d’authentification puisse
hexadécimal à la place de l’espace dans le MAC
être intégré à I’ISO 8731, il doit répondre aux deux
recu. S’il est disponible dans le jeu de caractères,
exigences suivantes:
utiliser un astérisque; par exemple, 5ABF*09C3.
a) Être concu pour une mission que ne remplit pas
6.10 Clés d’authentification
déjà I’ISO 8731 (par exemple convenir à un en-
vironnement différent ou permettre une réduc-
Les clés d’authentification sont des clés
tion sensible des coûts de mise en œuvre ou de
cryptographiques secrètes qui ont été auparavant
fonctionnement ou, enfin, offrir une protection
échangées entre l’expéditeur et le destinataire et
notablement meilleure);
sont utilisées par l’algorithme d’authentification. De
telles clés sont créées de facon aléatoire ou
b) Être suffisamment sûr pour remplir sa mission.
pseudo-aléatoire (voir annexe G).‘Les clés utilisées
pour l’authentification des messages ne doivent pas
L’annexe A indique le processus qui doit être suivi
être utilisées à d’autres fins. Toute clé utilisée pour
pour réaliser ces objectifs.
Annexe A
(normative)
Procédure d’examen d’autres algorithmes d’authentification
un exemple de calcul pas à pas, illustrant le
A.1 Initiative
calcul du MAC, à l’appui de l’exemple de mes-
sage normalisé (voir annexe D);
Tout algorithme alternatif d’authentification visant à
être incorporé dans I’ISO 8731 doit être soumis par
g) des informations détaillées sur tout essai préa-
un organisme national de normalisation ou avec
lable auquel l’algorithme aurait été soumis,
l’accord de celui-ci au Secrétariat de I’ISO/TC 68.
concernant notamment sa sécurité, sa fiabilité
et sa stabilité. Ces informations doivent com-
A.2 Fondement de la proposition
prendre une description générale des procédu-
res d’essai utilisées, les résultats obtenus et
Le demandeur doit justifier sa proposition en décri-
l’identité de l’organisme ou du groupe effectuant
vant:
les essais et certifiant les résultats (en résumé,
des informations suffisantes devraient permettre
a) le but que la proposition est censée atteindre;
à un organisme indépendant de procéder aux
mêmes essais et de comparer les résultats ob-
b) l’intérêt que présente l’algorithme par rapport à
tenus).
ceux que décrit déjà I’ISO 8731;
A.4 Publicité
c) les avantages autres que ceux déjà décrits par
ailleurs;
Aucun algorithme soumis à l’étude ne doit faire
l’objet d’une classification de sécurité. Si I’algo-
d) l’expérience acquise dans l’utilisation du nouvel
rithme a été breveté, l’évaluation doit avoir lieu
algorithme.
conformément aux procédures CEI/IS03). Toute do-
cumentation et information accompagnant la de-
A.3 Documentation
mande d’étude de l’algorithme doit être considérée
comme étant du domaine public et donc accessible
Une documentation complète doit accompagner
à toute personne physique ou morale souhaitant
l’algorithme soumis à considération. Cette docu-
l’examiner et l’essayer.
mentation doit comprendre:
A.5 Examen des propositions
a) une description complète de l’algorithme pro-
posé;
Toute proposition nouvelle sera examinée par I’ISO
et fera l’objet d’un compte rendu dans les 180 jours
b) une déclaration attestant clairement que I’algo-
suivant la réception (voir article A.6). Ce rapport
rithme répond aux impératifs de la présente
doit établir si la proposition est suffisamment docu-
Norme internationale ou est compatible avec
mentée, si elle a déjà été essayée avec succès et
elle;
certifiée et si l’algorithme proposé répond aux
conditions et spécifications énoncées dans la pré-
c) un organigramme mettant en évidence les éta-
sente Norme internationale. L’examen peut
pes successives aboutissant au calcul du MAC;
également s’accompagner d’une soumission de la
proposition à enquête publique (voir article A.6).
d) une définition, avec commentaires à l’appui, de
tous nouveaux termes, facteurs ou variables;
A.6 Enquête publique
e) les spécifications liées à la clé d’authentification,
à son utilisation et à sa manipulation;
Si le compte rendu (voir article A.5) recommande
une enquête publique, les propositions jugées rece-
vables doivent être transmises (avec l’accord du
3) Actuellement, Directives CEVISO, partie 2, Méthodologie pour /‘élaboration des Normes internationales, 1 ère édition
(1989) annexe A.
vote, afin que les membres P du comité technique
demandeur) à des organismes et institutions sélec-
tionnés jouissant d’une notoriété internationale procèdent à un vote à la majorité simple dont l’issue
dans ce domaine. Ces instances doivent rendre leur marquera le terme de la procédure.
avis dans les 90 jours suivant la réception de la
proposition.
A.8 Incorporation d’un nouvel algorithme
d’authentification
NOTE 2
Cette période d’enquête publique peut s’ajouter
aux 180 jours prévus pour la préparation du compte rendu
de la proposition (voir article A.5 ). Les nouveaux algorithmes d’authentification soumis
à approbation ainsi que les rapports les concernant,
doivent être diffusés pour vote par correspondance
A.7 Procédure d’appel
en tant que propositions de modification de
I’ISO 8731.
Les demandeurs dont les propositions sont rejetées
(voir article A.5), peuvent demander au Secrétariat
de I’ISO/TC 68 que leur proposition soit soumise à A.9 Suivi
la procédure d’enquête publique (voir article A.6)
si cela n’a pas déjà été fait. Si, au terme de cette Tout algorithme approuvé selon la méthode décrite
enquête publique, le rejet est toujours recommandé, par la présente Norme internationale doit faire I’ob-
le demandeur peut solliciter auprès du secrétariat jet d’une révision, par I’ISO/TC 68, au moins tous les
de I’ISO/TC 68 une distribution de sa proposition,
cinq ans.
accompagnée des rapports la concernant, pour

Annexe B
(informative)
Risques associés aux caractères de contrôle de communications
B.l Objet B.2 Insertion et suppression de
caractères dans un texte authentifié
Comme il est indiqué dans le domaine d’application
de la présente Norme internationale, la garantie de
Les règles de la mise en page (voir 6.7.2) indiquent
l’intégrité de la présentation des données incombe
que chaque retour de chariot et chaque changement
à l’utilisateur. Le contrôle de la présentation des
de ligne sont remplacés par un seul espace, et
données (par exemple impression, affichage) n’est
chaque série d’espaces est remplacée par un seul
pas couvert par la présente Norme internationale.
espace. Par conséquent ces caractères peuvent être
Cette annexe a pour objet de mettre en lumière
insérés à la suite d’autres caractères de ce type ou
certains risques associés aux caractères de
supprimés s’ils sont à la suite d’autres caractères
contrale des communications et d’apporter certai-
semblables sans répercussions sur I’authentifï-
nes solutions possibles à ces problèmes.
cation.
Le problème apparaît lorsque le message présenté
Lorsque de telles modifications sont apportées, le
diffère de facon significative des données de mes-
message tel qu’il est présenté peut apparaître très
sage effectiiement transmises à l’algorithme du
différent du message recu. Par exemple, si le CR
MAC. Même lorsque le message est correctement
représente un retour c’hariot alors <(123456>, et
authentifié, la présentation des données donne une
(~123 CR456,) auraient le même MAC. Le premier
impression erronée du message original. Les cas
message apparaîtrait sous la forme ~(123 456,~ alors
peuvent se présenter parce que les messages sont
que le dernier pourrait apparaître sous la forme
présentés avant la mise en page, parce que des
tq456~~ sur certains terminaux.
parties du message présenté peuvent ne pas être
soumis à authentification et que les dispositifs de
B.3 Insertion et suppression de
présentation ne présentent pas les données de
caractères dans un texte non authentifié
facon cohérente.
.
La protection contre les changements présentés
La présente Norme internationale permet uni-
dans l’article B.2 et l’article B.3 ci-dessous peut
quement l’authentification des éléments de mes-
être assurée si le MAC est calculé sur un texte qui
sage. Dans ce cas, il peut être possible d’insérer ou
n’est pas mis en page (voir 6.5 et 6.6) et si aucune
de supprimer des caractères dans un texte qui n’est
nouvelle mise en page n’est faite avant la présen-
pas choisi pour l’authentification (y compris des
tation. Toutefois cette option implique que le réseau
parties des éléments de message). De telle sorte
ne modifie pas les caractères de contrôle et que les
que le texte authentifié apparaisse différent du
appareils soient cohérents aux deux extrémités.
même texte dans le message original. Une sé-
quence de changement de code peut être placée
Le choix d’une option de format en vue d’une pro-
dans un texte authentifié, ce qui aura pour consé-
tection contre l’insertion de caractères de contrôle
quence le recouvrement d’une zone authentifiée,
de présentation est une décision opérationnelle im-
telle que la zone de valeur de la transaction, lorsque
portante. Les choix dépendent de nombreux fac-
le message complet est affiché. Noter que ce pro-
teurs tels que traitement manuel ou automatique,
blème est indépendant des règles de mise en page.
authentification du matériel ou du logiciel, messa-
ges formatés ou non, communications uni- ou bila-
Par exemple, sur certains terminaux, des séquences
térales, disponibilité d’une analyse rétrospective,
de changement de code peuvent être insérées à la
entre autres.
fin du message pour recouvrir le texte à authentifier.
Ces séquences de changement de code réalisent
Chaque utilisateur est seul à décider de la solution
l’adressage de curseur absolu pour remplacer de
finale, en s’appuyant sur les caractéristiques de son
facon sélective le montant en dollars.
environnement.
QD-850327-DQ QK-KEYl -KQ QX-MSGl -XQ
QT-$12000-TQ QM-2EB7 2F98-MQ -[ = “G99999-[ = ”
tous ces caractères avant de passer les données
Le message modifié est authentifié en utilisant l’une
dans l’algorithme. Les données de message qui
des options de format. Quand il est affiché à l’écran,
en résultent seraient alors transmises sans ces
le montant en dollars apparaît sous la forme $99999.
caractères. Cette règle s’applique à toutes les
Dans la mesure où les séquences de changement
données, pas seulement aux éléments d’authen-
de code (-[ =” G) et (-[ =“) ont été insérées dans le
message à l’extérieur des éléments de message, tification;
elles ne sont pas authentifiées et le MAC calculé est
2) si une mise en œuvre quelconque nécessite
identique au MAC calculé pour le message original
la présence de caractères spéciaux, tels qu’un
non modifié.
espacement arrière, dans les données transmi-
ses, le destinataire doit alors exécuter la fonction
l3,4 Incohérences des appareils de
des caractères spéciaux avant de passer les
présentation
données dans l’algorithme d’authentification;
Un message non modifié peut apparaître sous une
3) un jeu de caractères de contrôle prédéter-
forme différente d’un appareil de présentation à un
miné peut être défini. Toute variation par rapport
autre. Par exemple, un message <<123 CR456>> peut
à ce jeu déclencherait un état d’erreur. Si cer-
apparaître sous forme de deux lignes, la première
taines combinaisons de caractères sont requi-
(<123>) et la deuxième ~<456>>, ou le message peut
ses, elles pourraient également être validées.
apparaître sous forme d’une seule ligne ((456~~
Par exemple, si un changement de ligne précéde
toujours un retour chariot, alors un changement
de ligne tout seul pourrait être cause d’erreur.
B.5 Autres solutions de traitement
De même, si un caractère de changement de
code est considéré comme dangereux, il pourrait
Certaines des solutions (parmi un nombre non li-
être exclu du jeu de caractères autorisés;
mité) permettant de pallier les problèmes liés à
l’affichage dépendent des conditions dans les-
4) les éléments authentifiés pourraient être sé-
quelles le traitement est réalisé.
parés des données non authentifiées sur des
écrans ou .supports papier différents;
1) dans les options de format 4 et 5, les carac-
tères autres que ceux autorisés en 6.7.2 ne se-
5) tout caractère de contrôle de format, s’il
ront pas présents dans les données transmises.
existe, pourrait être ignoré. Le destinataire ef-
L’expéditeur devrait effectuer les fonctions de
fectuerait le formatage de facon indépendante.
,
Annexe C
(informative)
Protection contre la répétition et la perte
C.2.2 Lorsque plus de deux intervenants partagent
C.l Objet
une clé commune (exploitation multilatérale), la ré-
pétition peut être détectée si chaque entité utilise
Cette annexe décrit une méthode permettant de dé-
un sous-ensemble exclusif des MID possibles. Les
tecter la répétition et la perte de messages transmis
destinataire s’assure que le MID est compris dans
en utilisant la <(date de calcul du MAC) (DMC) et
l’intervalle correct et n’a pas déjà été recu.
4identificateur de message,, (MID) comme élé- ,
ments d’authentification.
C.2.3 Lorsque les identités de l’expéditeur et du
destinataire figurent dans chaque message en tant
C.2 Protection contre la répétition
qu’éléments d’authentification, il suffit au desti-
nataire de s’assurer que le message lui est bien
C.2.1 La répétition de messages peut être détec-
destiné et que le MID ne figurait pas déjà da
...

ISO
NORME
INTERNATIONALE
Deuxième édition
1990-05-l 5
- Spécifications liées à
Opérations bancaires
l’authentification des messages
Requirements for message authentication (wholesale)
Banking -
Numéro de référence
ISO 8730: 1990(F)
Sommaire
Page
q
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Reférences normatives
3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Protection
Génération et vérification du code d’authentification de message
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
(MAC)
. . . . . . . . . . . . . . . . 4
6 Procédures d’authentification de message
7 Procédure d’approbation des algorithmes d’authentification . . . 7
Annexes
A. Procédure d’examen d’autres algorithmes d’authentification . . 8
6. Risques associés aux caractéres de contrôle de communica-
tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .lO
C. Protection contre la répétition et la perte . . . . . . . . . . . . . . . . . 12
D. Exemple de message d’authentification pour jeux de caractères
codés:DEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
E. Exemple d’authentification de message pour jeux de caractères
codés:MAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .lg
F. Cadre pour l’authentification de messages télex normalisés . . 24
G. Un générateur de clé pseudo-aléatoire . . . . . . . . . . . l . . . . . . 26
8 ISO 1990
Droits de reproduction réservés. Aucune partie de cette publication ne peut être repro-
duite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de i’éditeur.
Organisation internationale de normalisation
Case Postale 56 l CH-121 1 Genève 20 l Suisse
Imprimé en Suisse
ii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération
mondiale d’organismes nationaux de normalisation (comités membres
de I’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de I’ISO. Chaque comité membre inté-
ressé par une étude a le droit de faire partie du comité technique créé
à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec I’ISO participent également aux tra-
vaux. L’ISO collabore étroitement avec la Commission électrotechnique
internationale (CEI) en ce qui concerne la normalisation électrotech-
nique.
Les projets de Normes internationales adoptés par les comités techni-
ques sont soumis aux comités membres pour approbation, avant leur
acceptation comme Normes internationales par le Conseil de I’ISO. Les
Normes internationales sont approuvées conformément aux procédures
de I’ISO qui requièrent l’approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 8730 a été élaborée par le comité techni-
que ISO/TC 68, Banque et services financiers liés aux opérations ban-
caires.
Cette deuxième édition annule et remplace la première édition (ISO
8730~1:1986), qui a fait l’objet d’une révision technique afin de clarifier
les améliorations déjà apportées dans cette édition.
Ces améliorations sont déjà apportées dans le document ANSI X9.9 pu-
blié en août 1986 et le nouveau texte reste cohérent avec le texte publié
par I’ANSI.
Les changements spécifiques apportés dans la présente édition sont:
a) les données présentées pour authentification peuvent être formatées
de cinq manières différentes. Le processus de choix permet aux uti-
lisateurs d’authentifier les messages selon l’option de format qui
convient le mieux au processus de transmission utilisé;
Les correspondants doivent maintenant se mettre d’accord sur I’op-
tion de format pour l’authentification de tout message particulier,
ceci ne devenant pas en fait une obligation majeure pour les parties
concernées étant donné que le mode de sélection sera déterminé
par le choix du processus de transmission;
b) introduction d’une nouvelle zone permettant d’identifier la clé
d’authentification utilisée (zone IDA);
plusie lurs définitions o nt aussi été modifiées afin d’assurer la cohé-
Cl
rente avec les autres Normes internationales du TC 68.
. . .
III
Dans le même temps quatre nouvelles annexes ont été ajoutées, toutes
dans l’intention de simplifier la mise en œuvre de la présente Norme
internationale:
a) l’annexe B décrit les risques associés à l’introduction accidentelle
de caractères de contrôle au cours du processus de reformatage et
la manière dont ces risques peuvent être réduits;
b) l’annexe D et l’annexe E fournissent des exemples de calcul
d’authentification au moyen des algorithmes spécifiés dans
I’ISO 8731:1987, Parties 1 et 2;
c) l’annexe F décrit un moyen d’application de la présente Norme
internationa le à u n ordre de paiement par télex formaté conformé-
ment aux presciptions de I’ISO 7746.
L’annexe A fait partie intégrante de la présente Norme internationale.
Les annexes B et C et D et E et F et G sont données uniquement à titre
d’information.
iv
Introduction
Un code d’authentification de message (MAC) est une zone de données
annexée à un ensemble de données (ou message) échangé entre des
institutions financières et transmis avec cet ensemble de données. II
découle du message complet ou de certains éléments spécifies dans le
message devant être protégés contre une altération accidentelle ou
frauduleuse.
Quelle que soit la nature de l’altération, le niveau de protection offert
par un algorithme donné dépend d’une part de la longueur du code
d’authentification de message (MAC) et de la clé d’authentification et,
d’autre part, de la possibilité qu’ont les deux correspondants de pré-
server la confidentialité de leur clé d’authentification. La mise en œuvre
de la présente Norme internationale implique l’adhésion des corres-
pondants à ces principes. La liste des algorithmes approuvés figure
dans I’ISO 8731. Les techniques de gestion de clé sont spécifiées dans
I’ISO 8732. La fiabilité mathématique d’un algorithme normalisé est
calculée en partant du principe que le fraudeur potentiel est confronté
à un nombre arbitrairement grand de messages en clair, contenant
chacun son MAC associé, calculé d’après une même clé d’authentifï-
cation. La fiabilité est alors déterminée par la puissance de calcul né-
cessaire au fraudeur pour déterminer la clé d’authentification et par la
longueur du MAC.
Page blanche
-
NORME INTERNATIONALE ISO 8730:1990(F)
Opérations bancaires - Spécifications liées à
l’authentification des messages
l’intégrité de la présentation des données (voir an-
1 Domaine d’application
nexe B). La présente Norme internationale offre un
moyen de protection contre la répétition et la perte;
une méthode est décrite à l’annexe C.
La présente Norme internationale est concue pour
La présente Norme internationale vise l’utilisation
être utilisée par des institutions échangeant des
d’algorithmes symétriques, l’expéditeur et le desti-
messages financiers. Elle peut servir à authentifier
nataire utilisant la même clé. Des dispositions se-
des messages transmis par un service de télécom-
ront prises en temps utile pour traiter de l’emploi
munication ou tout autre mode de transmission.
d’algorithmes asymétriques. La méthode d’authen-
tification s’applique à des messages formatés et
La présente Norme internationale spécifie les mé-
transmis sous forme de jeux de caractères codés
thodes à utiliser pour protéger l’authenticité de
ou de données binaires.
messages financiers liés à l’activité d’entreprise
échangés par des institutions (entre banques, entre
La présente Norme internationale n’indique pas de
une banque et une société ou un gouvernement), en
méthode de protection contre la lecture et la mani-
recourant à un code d’authentification de messages
pulation non autorisées, telle quelle peut être obte-
(MAC). Elle spécifie la méthode d’approbation des
nue par chiffrement du message comme décrit dans
algorithmes d’authentification en vue de leur inté-
I’ISO 10126’).
gration à I’ISO 8731. L’application de la présente
Norme internationale n’est pas une garantie contre
la fraude interne, qu’elle soit du fait de l’expéditeur
ou du destinataire, par exemple la contrefacon d’un
2 Références normatives
MAC par le destinataire.
Les normes suivantes contiennent des dispositions
La présente Norme internationale spécifie une
qui, par suite de la référence qui en est faite,
technique de protection de message, dans sa tota-
constituent des dispositions valables pour la pré-
lité ou dans certains de ses éléments. Les données
sente Norme internationale. Au moment de la pu-
présentées à l’authentification peuvent être
blication, les éditions indiquées étaient en vigueur.
formatées sous une forme à choisir parmi cinq op-
Toute norme est sujette à révision et les parties
tions. Ces spécifications peuvent être complétées
prenantes des accords fondés sur la présente
par un groupe d’institutions financières présentant
Norme internationale sont invitées à rechercher la
des intérêts communs et qui ont pris des dispo-
possibilité d’appliquer les éditions les plus récentes
sitions fonctionnelles propres (par exemple un
des normes indiquées ci-après. Les membres de la
consortium bancaire, un regroupement géographi-
CEI et de I’ISO possèdent le registre des Normes
que, un réseau d’exploitation, un accord de secteur
internationales en vigueur à un moment donné.
industriel). Le choix de l’option appropriée permet
une authentification des messages compatibles
ISO 646:1983, Traitement de l’information - Jeu /SO
avec le système de transmission utilisé.
de caractères codés à 7 éléments pour l’échange
La protection de l’intégrité s’applique uniquement d’information.
aux éléments d’authentification choisis. Les alté-
rations des autres parties du message ne sont pas ISO 7746:1988, Banque - Messages télex interban-
décelées. II incombe aux utilisateurs de garantir cakes.
1) À publier.
3.7 biais: La situation dans laquelle au cours de la
ISO 7982-l : 1987, Télécommunication bancaire -
Messages de transfert de fonds - Partie 1: Vocabu- création de nombres aléatoires ou pseudo-
laire et éléments de données. aléatoires, certains nombres sortent plus souvent
que d’autres.
ISO 8601:1988, Éléments de données et formats
d’échange - Echange d’information - Représen-
3.8 période de validité: Période de temps définie
tation de la date et de l’heure.
au cours de laquelle une clé de chiffrement spécifi-
que peut être utilisée, ou au cours de laquelle les
ISO 8731-1:1987, Banque - Algorithmes approuvés
clés de chiffrement peuvent rester efficaces dans un
pour l’authentification de messages - Partie 1:
système donné.
DEA.
ISO 8732:1988, Banque - Gestion de clés.
3.9 intégrité des données: Capacité qu’ont des
données de ne pas pouvoir être altérées ou dé-
ISO 10126~1:--J), Banque - Procédures de chif-
truites d’une manière frauduleuse.
frement de message - Partie 1: Principes généraux.
ISO 10126-2:-*), Banque - Procédures de chif-
3.10 date de calcul du MAC (DMC): Date à laquelle
fremenf de message - Partie 2: Algorithmes.
l’expéditeur calcule le code d’authentification de
message. Cette date peut être utilisée pour syn-
chroniser le processus d’authentification en choi-
sissant la clé appropriée.
3.11 authentification de l’origine des données:
Confirmation que la source des données recues est
3 Définitions
I
celle revendiquée.
Pour les besoins de la présente Norme internatio-
nale, les définitions suivantes s’appliquent. Les ter-
3.12 déchiffrement: L’inverse du chiffrement
mes imprimés en italique dans les définitions sont
reversible correspondant.
définis ailleurs dans le présent article.
3.1 algorithme: Processus mathématique propre à 3.13 décryptage: voir déchiffrement.
un calcul; un ensemble de règles dont l’application
donne un résultat d’éterminé.
3.14 délimiteur: Groupe de caractères servant à
marquer le début et la fin d’une ou plusieurs zones
3.2 authentification: Processus appliqué par I’ex-
de données.
péditeur et le destinataire pour garantir l’intégrité
des données et fournir l’authentification de l’origine
des données.
3.15 double contrôle: Intervention d’au moins deux
entités (généralement des personnes), opérant de
concert, pour protéger des fonctions ou des infor-
3.3 algorithme d’authentification: Algorithme utilisé
mations sensibles, aucune entité ne pouvant seule
conjointement à une clé d’authentification et un ou
accéder à des (ou utiliser les) données, par exemple
plusieurs éléments d’authentification, à des fins
clé de chiffrement.
d’authentification.
3.16 chiffrement: Transformation cryptographique
3.4 élément d’authentification: Élément de message
de données en vue de produire un texte chiffré.
que l’on désire protéger par l’authentification.
3.17 cryptage: voir chiffrement.
3.5 clé d’authentification: Clé de chiffrement utili-
sée pour l’authentification.
3.18 chiffre hexadécimal: Caractère unique choisi
dans l’intervalle O-9, A-F (majuscule), représentant
3.6 bénéficiaire(s): Le ou les interlocuteur(s) qui
doit/doivent être crédité(s) ou payé(s) à I’aboutis- une série de quatre éléments binaires, comme suit:
sement d’un transfert.
2) À publier.
Binaire Décimal Héxadécimal
4 Protection
0000 0 0
0001 1 1 4.1 Protection de l’identité de l’expéditeur et
du destinataire
0010 2 2
0011 3 3
Afin d’empêcher l’usurpation d’identité de I’expédi-
0100 4 4
teur, la clé d’authentification doit être protégée et
0101 5 5
son utilisation doit être restreinte à l’expéditeur et
au destinataire (ou leurs représentants attitrés).
0110 6 6
0111 7 7
4.2 Éléments d’authentification
1000 8 8
1001 9 9
4.2.1 Les éléments d’authentification suivants doi-
1010 10 A
vent toujours être inclus dans le calcul du MAC:
1011 11 B
a) date de calcul du MAC (DMC);
1100 12 C
1101 13 D
b) identificateur de message (MID).
1110 14 E
1111 15 F
4.2.2 Les éléments d’authentification suivants doi-
vent toujours être inclus dans le calcul du MAC,
3.19 identificateur de clé d’authentification (IDA):
lorsqu’ils apparaissent dans le message:
Zone qui identifie la clé à utiliser pour authentifier
le message.
a) montant de la transaction;
b) devise;
3.20 code d’authentification de message (MAC):
Code contenu dans un message entre un expéditeur
c) identificateur de clé d’authentification (IDA);
et un destinataire, utilisé pour valider la source et
une partie ou l’ensemble du texte du message. Le
d) identification des entités à créditer et à débiter;
code est le résultat d’un calcul ayant fait l’objet d’un
accord.
e) identification du bénéficiaire;
3.21 élément de message: Groupe de caractères
f) date de valeur.
contigus utilisable dans un but spécifique.
4.3 Protection du message dans son
3.22 identificateur de message (MID): Zone utilisée
ensemble
pour identifier de manière unique un message fi-
nancier ou une transaction (exemple, référence de
Lorsque les correspondants souhaitent protéger le
la transaction de la banque expéditrice).
texte complet du message, le processus d’authenti-
fication doit s’appliquer au texte entier (voir 6.5 et
3.23 texte du message: Informations acheminées
. .
6 7)
ou transmises entre I’expédifeur et le destinataire,
en excluant les informations d’en-tête
et de fin de
transmission, liées à la transmission. 4.4 Protection contre la répétition et la perte
Pour assurer la protection contre la répétition et la
3.24 destinataire: Personne, institution ou autre
perte, une référence unique de transaction (ou
entité dûment autorisée et responsable de la ré-
identificateur de message) doit être utilisée.
ception du message.
L’identificateur de message (MID) est une valeur qui
n’est pas répétée avant (i) le changement de date
3.25 expéditeur: Personne, institution ou autre en-
(c’est-à-dire la date de calcul du MAC), ou (ii) I’ex-
tité dûment autorisée et responsable de l’envoi du
piration de la période de validité de la clé utilisée
message.
pour l’authentification, selon l’événement survenant
le premier, c’est-à-dire qu’il ne doit pas y avoir plus
3.26 date de valeur: Date à laquelle les fonds doi-
d’un message avec la même date et le même
vent être à la disposition du bénéficiaire.
identificateur de message utilisant la même clé.
Cette exigence peut être satisfaite par l’inclusion
3.27 service de télécommunication: Tout service de d’un numéro de référence unique pour la transac-
télécommunication autorisant l’échange de messa- tion de la banque expéditrice dans un message à
ges entre abonnés. format fixe servant d’identificateur de message.
Dans les messages de format libre, la zone du MID puisse être identifié par le destinataire. (Pour les
doit être délimitée conformément à la présente messages de format libre voir 6.3.3.) Le destinataire
Norme internationale (voir 6.3.1). Une méthode de répète le calcul en utilisant la même méthode d’au-
protection est donnée à l’annexe C. thentification que celle décrite dans cette section.
Le message est authentifié si le MAC recu et le MAC
de référence calculé sont identiques. ’
5 Génération et vérification du code
d’authentification de message (MAC)
6.2 Options de format
5.1 Génération
La présente Norme internationale offre cinq options
pour le format des données à authentifier:
L’expéditeur d’un message doit générer un MAC en
traitant (dans l’ordre où ils apparaissent dans le
1) données binaires; (6.4);
message) les éléments d’authentification des mes-
sages transmis qui doivent être protégés dans un
2) caractères codés; (6.5); texte complet du
algorithme d’authentification approuvé (voir
message, pas de mise en page
ISO 8731). L’algorithme doit fonctionner avec une
clé d’authentification échangée préalablement avec
3) caractères codés; (6.6); éléments extraits du
le destinataire et qui n’est connue que des deux
message, pas de mise en page
correspondants. Ce processus donne naissance au
MAC, qui doit être inclus dans le texte du message
ères codés; (6.7); texte complet du
4) caract
original, en tant que zone de données supplémen-
message; mise en page
taires.
caractères cod és; (6. 8); éléments extraits du
5)
5.2 Vérification
m essage; mise en
page
À la réception du message, le destinataire doit cal- e pour authentifier une chaîne
L’option 1 est concu
culer un MAC de référence, en utilisant les éléments
binaire de don nées.
d’authentification, une clé d’authentification identi-
Les options 2 et 3 sont concues pour authentifier les
que et un algorithme identique. L’authenticité des
données sous forme de jeux de caractères codés
éléments d’authentification et la source du message
chaque fois que le moyen de transmission offre une
sont confirmés lorsque le MAC de référence calculé
transparence au jeu de caractères, par exemple
par le destinataire correspond à celui qui accompa-
systèmes et réseaux concus conformément au mo-
gne le message.
dèle des systèmes ouverts interconnectés (OSI).
Un MAC recu ainsi que ses déli miteurs ne doivent
Les options 4 et 5 sont concues pour I’authentifi-
être i nclus dans le calcul de I’algorit hme.
Pas
cation des données sous forme d’un jeu restreint de
Lorsque le MAC recu ne correspond pas au MAC caractères codés utilisé lorsque le moyen de trans-
de référence calculé: le défaut d’authentification doit mission n’est pas transparent au jeu de caractères
être communiqué conformément à 6.9.2. utilisé, par exemple code baudot, telex et services
de commutation tels que ceux offerts par de nom-
Le processus de génération du MAC est sensible à
breux services internationaux de communication.
l’ordre dans lequel les éléments d’authentification
sont transmis, c’est-à-dire qu’un changement inter- at incombe aux corres-
Le choix de l’option d e form
I
venant dans l’ordre des éléments d’authentification
pondants et doit faire l’objet d un accord bilatéral.
après la génération du MAC se traduit par un défaut
d’authentification.
6.3 Jeux de caractères codés (comme ceux
Les clés utilisés dans les options 2 à 5)
d’authentification du message ne doivent
pas être utilisées comme clés de chiffrement.
6.3.1 Formats définis des éléments de message
6 Procédures d’authentification de
Les formats de zone pour la date de calcul du MAC,
message
l’identificateur de clé d’authentification, le code
d’authentification de message et l’identificateur de
6.1 Processus d’authentification
message sont représentés sous la forme spécifiée
dans la présente Norme internationale. Les formats
Les correspondants doivent convenir de I’algo-
pour les autres éléments de message ne sont pas
rithme à appliquer et aussi échanger une clé d’au-
spécifiés.
thentification secrète. L’expéditeur calcule alors un
MAC utilisant ces éléments. Le MAC doir être joint Les fo rmats de zone doivent être vérifiés comme
au texte du message transmis, de telle sorte qu’il partie intégrante rocessus d’authentification. Si
du P
l’option d’authentification avec mise en page est c) Code d’authentification de message (MAC): QM-
choisie, les formats de zone doivent être vérifiés et -MQ exemple: QM-hhhhbhhhh-MQ;
-
avant la mise en page. S’il se produit une erreur de
) Identificateur de message (MID): QX- et -XQ
formatage, le message ne sera pas authentifié. Les
exemple: QX-aaaaaaaaaaaaaaaa-XQ; et
formats de zone suivants apparaissent comme indi-
.
qué .
) Autres éléments de message: QT- et -TQ exem-
a) Date de calcul du MAC (DMC). La date à laquelle ple: QT-texte-TQ
l’institution expéditrice crée le message doit être
Le ((texte,> délimité dans QT-texte-TQ peut avoir
exprimée conformément à I’ISO 8601 sous la
n’importe quelle longueur autorisée par le service
forme année, mois, jour (de préférence sous
de télécommunication.
forme abrégée, à savoir AAMMJJ), par exemple
851101 pour 1 novembre 1985.
6.3.4 Utilisation des délimiteurs
b) Identificateur de clé d’authentification (IDA).
Cette zone est l’identificateur de la clé d’au-
Les délimiteurs explicites de début et de fin, s’ils
thentification qui doit être conforme aux exi-
existent, doivent se présenter par couples complé-
gences relatives aux identificateurs de clés
mentaires, sans délimiteurs explicites intermédiai-
spécifiées dans I’ISO 8732. Permet de laisser un
res.
message dans le texte sans qu’il apparaisse à
l’impression.
NOTE 1 Si cette condition n’est pas remplie, le message
n’est pas authentifié.
c) Code d’authentification de message (MAC). Le
MAC doit être exprimé sous forme de huit chif-
Le message peut contenir un nombre quelconque
fres hexadécimaux répartis en deux groupes de
de zones de 4extejB délimitées, toutefois, les zones
quatre, séparés par un blanc (hhhhbhhhh), par
-
des DMC, MID, IDA et du MAC ne doivent apparaître
exemple 5A6Fb09C3.
-
qu’une fois dans le message.
Le trait d’union (-) doit figurer dans tous les délimi-
d) Identificateur de message (MID). L’identificateur
de message doit être exprimé sous forme de un teurs explicites.
à seize caractères imprimables
(aaaaaaaaaaaaaaaa). Les caractères autorisés
Représentation des caractères
6‘3.5
sont O-9, A-Z (majuscules), l’espace (b), la vir-
gule (,), le point (.), la barre oblique (/), I’astéris-
Tous les caractères des éléments d’authentification
que (*) et le trait d’union (-); par exemple
qui sont introduits dans l’algorithme doivent être
FN-BU2.5.
représentés par des caractères de 8 bits compre-
nant le jeu de caractères codés à 7 éléments de
6.3.2 Délimiteurs implicites de zone I’ISO 646 (à l’exclusion des caractères nationaux)
précédé d’un zéro (par exemple 0, b7, b6, . .bl).
Lorsque cela nécessite une traduction de code, la
Un élément d’authentification est implicitement dé-
limité si sa place dans le message est fixe ou iden- traduction ne doit servir qu’à des fins internes. Si le
message est transformé en un jeu de caractères
tifiée sans ambiguïté par des règles normalisées de
différents, la transformation inverse doit être appli-
format. Les noms de zone, les nombres, ou les éti-
quée avant que ne débute le processus d’authenti-
quettes mnémoniques d’identification doivent être
fication.
pris en compte pour l’authentification, dès lors que
le service de télécommunication les signale comme
délimiteurs implicites.
6.3.6 Information d’en-tête et de fin
L’information d’en-tête et de fin de message ajoutée
6.3.3 Délimiteurs explicites de zone
(par exemple par un réseau) à des fins de trans-
mission doit être omise, c’est-à-dire qu’elle ne doit
Les délimiteurs explicites peuvent être utilisés pour
identifier le début et la fin des éléments de mes- pas faire partie du texte du message et ne doit pas
sage, y compris le MAC. Ils peuvent être utilisés être incluse dans le calcul de l’algorithme.
dans toutes les options de jeux de caractères codés.
Les délimiteurs explicites suivants sont spécifiés:
6.4 Option 1: Données binaires
a) Date de calcul du MAC (DMC): QD- et -DQ,
exemple: QD-AAMMJJ-DQ; L’algorithme d’authentification doit être appliqué au
texte complet du message, ou à des parties du texte
b) Identificateur de clé d’authentification (IDA): QK- du message, selon l’accord bilatéral conclu entre
et -KQ, exemple: QK-1357BANKATOBANKB-KQ; l’expéditeur et le destinataire.

I§O 8730:1990(F)
6.7.2.1 Chaque retour chariot et chaque chan-
6.5 Option 2: Caractères codés; message
gement de ligne doivent être remplacés par un seul
entier; pas de mise
espace.
message entier; pas de mise en page
6.7.2.2 Les caractères alphabétiques minuscules
Lorsque le traitement du message est automatisé
(a-z) doivent être transcrits en majuscules (A-Z).
et que le contenu précis du corps du message ne
change pas entre l’expéditeur et le destinataire,
l’algorithme peut être appliqué au message entier.
6.7.2.3 Tous les caractères autres que les lettres
A-Z, les chiffres O-9, l’espace, la virgule (J, le point
Le MAC est calculé sur le texte entier du message
(.), la barre oblique (/), l’astérisque (*), les paren-
(voir exemple en annexe D ).
thèses de début et de fin et le trait d’union (-) doi-
vent ëtre supprimés. De même la fin de texte et tout
autre caractéres de formatage et de contrôle doi-
6.6 Option 3: Caractères codés; éléments
vent être supprimés.
extraits du message; pas de
éléments extraits du message; pas de mise en
6.7.2.4 Tous les espaces d’en-tête doivent être
page
supprimés.
6.6.1 Utilisation
6.7.2.5 Chaque série d’espaces consécutifs (inter-
nes et de fin) doit être remplacée par un seul es-
Lorsque l’authentification du message entier n’est
pace.
pas possible, l’algorithme d’authentification doit être
appliqué uniquement aux éléments de message
choisis.
6.8 Option 5: Caractères codés; éléments
extraits du message; mise en
Les éléments de message doivent être extraits
éléments extraits du message; mise en page
conformément aux règles décrites en 6.6.2. Un MAC
doit être calculé sur les éléments extraits, pris dans
6.8.1 Utilisation
l’ordre dans lequel ils apparaissent (voir exemple
dans l’annexe D).
Voir 6.6.1.
6.6.2 Extraction des éléments de message
6.8.2 Extraction des éléments de message
Les éléments de message à authentifier doivent être
Les règles d’extraction décrites en 6.6.2 doivent être
extraits selon les règles suivantes:
appliquées.
6.6.2,1 Supprimer tous les caractères autres que
6.8.3 Mise en page
les éléments du message et leurs délimiteurs cor-
respondants.
Les règles de mise en page décrites en 6.7.2 doivent
être appliquées.
6.6.2.2 Insérer un seul espace après chaque élé-
ment de message implicitement délimité.
6.9 Erreurs sur le code d’authentification du
message (MAC)
6.7 Option 4: Caractères codés; message
entier; mise en page
6.9.1 Incapacité à générer un MAC
message entier; mise en page
Quand le MAC est généré automatiquement, c’est-
6.7.1 Utilisation
à-dire par extraction automatique des éléments
d’authentification, le non-respect des règles préci-
Le MAC doit être calculé sur le texte du message à
tées peut faire échouer l’opération (imbrication des
la suite de la mise en page selon les règles décrites
délimiteurs, par exemple). Dans ce cas et lorsque
en 6.7.2 (voir exemple dans l’annexe D).
l’erreur doit, au minimum, pouvoir être constatée de
facon lisible (par exemple, sur papier, écran ou mi-
crofiche, l’échec de l’opération doit être signalé par
6.7.2 Mise en page
huit espaces (si possible) répartis en deux groupes
de quatre, séparés par un caractère autre qu’un
Les règles de mise en page suivantes doivent s’ap-
chiffre hexadécimal, de préférence un astérisque,
pliquer dans l’ordre présenté, à tous les éléments
par exemple, bbbb*bbbb. Lorsque des espaces ne
de message - délimités implicitement ou explici-
sont pas disponibles, ils doivent être remplacés par
tement - avant le traitement par l’algorithme d’au-
thentification: des zéros; (par exemple, OOOO*OOOO).
6.9.2 MAC recu non authentifié l’authentification être protégée contre
doit toute
communication à des personnes non autorisé es.
Lorsqu’un MAC ne correspond pas au MAC de ré-
férence créé au cours du processus d’authentifi-
7 Procédure d’approbation des
cation et lorsque l’erreur doit pouvoir être constatée
algorithmes d’authentification
de facon lisible, l’échec doit être indiqué par I’in-
sertion d’un caractère d’impression non
Avant qu’un algorithme d’authentification puisse
hexadécimal à la place de l’espace dans le MAC
être intégré à I’ISO 8731, il doit répondre aux deux
recu. S’il est disponible dans le jeu de caractères,
exigences suivantes:
utiliser un astérisque; par exemple, 5ABF*09C3.
a) Être concu pour une mission que ne remplit pas
6.10 Clés d’authentification
déjà I’ISO 8731 (par exemple convenir à un en-
vironnement différent ou permettre une réduc-
Les clés d’authentification sont des clés
tion sensible des coûts de mise en œuvre ou de
cryptographiques secrètes qui ont été auparavant
fonctionnement ou, enfin, offrir une protection
échangées entre l’expéditeur et le destinataire et
notablement meilleure);
sont utilisées par l’algorithme d’authentification. De
telles clés sont créées de facon aléatoire ou
b) Être suffisamment sûr pour remplir sa mission.
pseudo-aléatoire (voir annexe G).‘Les clés utilisées
pour l’authentification des messages ne doivent pas
L’annexe A indique le processus qui doit être suivi
être utilisées à d’autres fins. Toute clé utilisée pour
pour réaliser ces objectifs.
Annexe A
(normative)
Procédure d’examen d’autres algorithmes d’authentification
un exemple de calcul pas à pas, illustrant le
A.1 Initiative
calcul du MAC, à l’appui de l’exemple de mes-
sage normalisé (voir annexe D);
Tout algorithme alternatif d’authentification visant à
être incorporé dans I’ISO 8731 doit être soumis par
g) des informations détaillées sur tout essai préa-
un organisme national de normalisation ou avec
lable auquel l’algorithme aurait été soumis,
l’accord de celui-ci au Secrétariat de I’ISO/TC 68.
concernant notamment sa sécurité, sa fiabilité
et sa stabilité. Ces informations doivent com-
A.2 Fondement de la proposition
prendre une description générale des procédu-
res d’essai utilisées, les résultats obtenus et
Le demandeur doit justifier sa proposition en décri-
l’identité de l’organisme ou du groupe effectuant
vant:
les essais et certifiant les résultats (en résumé,
des informations suffisantes devraient permettre
a) le but que la proposition est censée atteindre;
à un organisme indépendant de procéder aux
mêmes essais et de comparer les résultats ob-
b) l’intérêt que présente l’algorithme par rapport à
tenus).
ceux que décrit déjà I’ISO 8731;
A.4 Publicité
c) les avantages autres que ceux déjà décrits par
ailleurs;
Aucun algorithme soumis à l’étude ne doit faire
l’objet d’une classification de sécurité. Si I’algo-
d) l’expérience acquise dans l’utilisation du nouvel
rithme a été breveté, l’évaluation doit avoir lieu
algorithme.
conformément aux procédures CEI/IS03). Toute do-
cumentation et information accompagnant la de-
A.3 Documentation
mande d’étude de l’algorithme doit être considérée
comme étant du domaine public et donc accessible
Une documentation complète doit accompagner
à toute personne physique ou morale souhaitant
l’algorithme soumis à considération. Cette docu-
l’examiner et l’essayer.
mentation doit comprendre:
A.5 Examen des propositions
a) une description complète de l’algorithme pro-
posé;
Toute proposition nouvelle sera examinée par I’ISO
et fera l’objet d’un compte rendu dans les 180 jours
b) une déclaration attestant clairement que I’algo-
suivant la réception (voir article A.6). Ce rapport
rithme répond aux impératifs de la présente
doit établir si la proposition est suffisamment docu-
Norme internationale ou est compatible avec
mentée, si elle a déjà été essayée avec succès et
elle;
certifiée et si l’algorithme proposé répond aux
conditions et spécifications énoncées dans la pré-
c) un organigramme mettant en évidence les éta-
sente Norme internationale. L’examen peut
pes successives aboutissant au calcul du MAC;
également s’accompagner d’une soumission de la
proposition à enquête publique (voir article A.6).
d) une définition, avec commentaires à l’appui, de
tous nouveaux termes, facteurs ou variables;
A.6 Enquête publique
e) les spécifications liées à la clé d’authentification,
à son utilisation et à sa manipulation;
Si le compte rendu (voir article A.5) recommande
une enquête publique, les propositions jugées rece-
vables doivent être transmises (avec l’accord du
3) Actuellement, Directives CEVISO, partie 2, Méthodologie pour /‘élaboration des Normes internationales, 1 ère édition
(1989) annexe A.
vote, afin que les membres P du comité technique
demandeur) à des organismes et institutions sélec-
tionnés jouissant d’une notoriété internationale procèdent à un vote à la majorité simple dont l’issue
dans ce domaine. Ces instances doivent rendre leur marquera le terme de la procédure.
avis dans les 90 jours suivant la réception de la
proposition.
A.8 Incorporation d’un nouvel algorithme
d’authentification
NOTE 2
Cette période d’enquête publique peut s’ajouter
aux 180 jours prévus pour la préparation du compte rendu
de la proposition (voir article A.5 ). Les nouveaux algorithmes d’authentification soumis
à approbation ainsi que les rapports les concernant,
doivent être diffusés pour vote par correspondance
A.7 Procédure d’appel
en tant que propositions de modification de
I’ISO 8731.
Les demandeurs dont les propositions sont rejetées
(voir article A.5), peuvent demander au Secrétariat
de I’ISO/TC 68 que leur proposition soit soumise à A.9 Suivi
la procédure d’enquête publique (voir article A.6)
si cela n’a pas déjà été fait. Si, au terme de cette Tout algorithme approuvé selon la méthode décrite
enquête publique, le rejet est toujours recommandé, par la présente Norme internationale doit faire I’ob-
le demandeur peut solliciter auprès du secrétariat jet d’une révision, par I’ISO/TC 68, au moins tous les
de I’ISO/TC 68 une distribution de sa proposition,
cinq ans.
accompagnée des rapports la concernant, pour

Annexe B
(informative)
Risques associés aux caractères de contrôle de communications
B.l Objet B.2 Insertion et suppression de
caractères dans un texte authentifié
Comme il est indiqué dans le domaine d’application
de la présente Norme internationale, la garantie de
Les règles de la mise en page (voir 6.7.2) indiquent
l’intégrité de la présentation des données incombe
que chaque retour de chariot et chaque changement
à l’utilisateur. Le contrôle de la présentation des
de ligne sont remplacés par un seul espace, et
données (par exemple impression, affichage) n’est
chaque série d’espaces est remplacée par un seul
pas couvert par la présente Norme internationale.
espace. Par conséquent ces caractères peuvent être
Cette annexe a pour objet de mettre en lumière
insérés à la suite d’autres caractères de ce type ou
certains risques associés aux caractères de
supprimés s’ils sont à la suite d’autres caractères
contrale des communications et d’apporter certai-
semblables sans répercussions sur I’authentifï-
nes solutions possibles à ces problèmes.
cation.
Le problème apparaît lorsque le message présenté
Lorsque de telles modifications sont apportées, le
diffère de facon significative des données de mes-
message tel qu’il est présenté peut apparaître très
sage effectiiement transmises à l’algorithme du
différent du message recu. Par exemple, si le CR
MAC. Même lorsque le message est correctement
représente un retour c’hariot alors <(123456>, et
authentifié, la présentation des données donne une
(~123 CR456,) auraient le même MAC. Le premier
impression erronée du message original. Les cas
message apparaîtrait sous la forme ~(123 456,~ alors
peuvent se présenter parce que les messages sont
que le dernier pourrait apparaître sous la forme
présentés avant la mise en page, parce que des
tq456~~ sur certains terminaux.
parties du message présenté peuvent ne pas être
soumis à authentification et que les dispositifs de
B.3 Insertion et suppression de
présentation ne présentent pas les données de
caractères dans un texte non authentifié
facon cohérente.
.
La protection contre les changements présentés
La présente Norme internationale permet uni-
dans l’article B.2 et l’article B.3 ci-dessous peut
quement l’authentification des éléments de mes-
être assurée si le MAC est calculé sur un texte qui
sage. Dans ce cas, il peut être possible d’insérer ou
n’est pas mis en page (voir 6.5 et 6.6) et si aucune
de supprimer des caractères dans un texte qui n’est
nouvelle mise en page n’est faite avant la présen-
pas choisi pour l’authentification (y compris des
tation. Toutefois cette option implique que le réseau
parties des éléments de message). De telle sorte
ne modifie pas les caractères de contrôle et que les
que le texte authentifié apparaisse différent du
appareils soient cohérents aux deux extrémités.
même texte dans le message original. Une sé-
quence de changement de code peut être placée
Le choix d’une option de format en vue d’une pro-
dans un texte authentifié, ce qui aura pour consé-
tection contre l’insertion de caractères de contrôle
quence le recouvrement d’une zone authentifiée,
de présentation est une décision opérationnelle im-
telle que la zone de valeur de la transaction, lorsque
portante. Les choix dépendent de nombreux fac-
le message complet est affiché. Noter que ce pro-
teurs tels que traitement manuel ou automatique,
blème est indépendant des règles de mise en page.
authentification du matériel ou du logiciel, messa-
ges formatés ou non, communications uni- ou bila-
Par exemple, sur certains terminaux, des séquences
térales, disponibilité d’une analyse rétrospective,
de changement de code peuvent être insérées à la
entre autres.
fin du message pour recouvrir le texte à authentifier.
Ces séquences de changement de code réalisent
Chaque utilisateur est seul à décider de la solution
l’adressage de curseur absolu pour remplacer de
finale, en s’appuyant sur les caractéristiques de son
facon sélective le montant en dollars.
environnement.
QD-850327-DQ QK-KEYl -KQ QX-MSGl -XQ
QT-$12000-TQ QM-2EB7 2F98-MQ -[ = “G99999-[ = ”
tous ces caractères avant de passer les données
Le message modifié est authentifié en utilisant l’une
dans l’algorithme. Les données de message qui
des options de format. Quand il est affiché à l’écran,
en résultent seraient alors transmises sans ces
le montant en dollars apparaît sous la forme $99999.
caractères. Cette règle s’applique à toutes les
Dans la mesure où les séquences de changement
données, pas seulement aux éléments d’authen-
de code (-[ =” G) et (-[ =“) ont été insérées dans le
message à l’extérieur des éléments de message, tification;
elles ne sont pas authentifiées et le MAC calculé est
2) si une mise en œuvre quelconque nécessite
identique au MAC calculé pour le message original
la présence de caractères spéciaux, tels qu’un
non modifié.
espacement arrière, dans les données transmi-
ses, le destinataire doit alors exécuter la fonction
l3,4 Incohérences des appareils de
des caractères spéciaux avant de passer les
présentation
données dans l’algorithme d’authentification;
Un message non modifié peut apparaître sous une
3) un jeu de caractères de contrôle prédéter-
forme différente d’un appareil de présentation à un
miné peut être défini. Toute variation par rapport
autre. Par exemple, un message <<123 CR456>> peut
à ce jeu déclencherait un état d’erreur. Si cer-
apparaître sous forme de deux lignes, la première
taines combinaisons de caractères sont requi-
(<123>) et la deuxième ~<456>>, ou le message peut
ses, elles pourraient également être validées.
apparaître sous forme d’une seule ligne ((456~~
Par exemple, si un changement de ligne précéde
toujours un retour chariot, alors un changement
de ligne tout seul pourrait être cause d’erreur.
B.5 Autres solutions de traitement
De même, si un caractère de changement de
code est considéré comme dangereux, il pourrait
Certaines des solutions (parmi un nombre non li-
être exclu du jeu de caractères autorisés;
mité) permettant de pallier les problèmes liés à
l’affichage dépendent des conditions dans les-
4) les éléments authentifiés pourraient être sé-
quelles le traitement est réalisé.
parés des données non authentifiées sur des
écrans ou .supports papier différents;
1) dans les options de format 4 et 5, les carac-
tères autres que ceux autorisés en 6.7.2 ne se-
5) tout caractère de contrôle de format, s’il
ront pas présents dans les données transmises.
existe, pourrait être ignoré. Le destinataire ef-
L’expéditeur devrait effectuer les fonctions de
fectuerait le formatage de facon indépendante.
,
Annexe C
(informative)
Protection contre la répétition et la perte
C.2.2 Lorsque plus de deux intervenants partagent
C.l Objet
une clé commune (exploitation multilatérale), la ré-
pétition peut être détectée si chaque entité utilise
Cette annexe décrit une méthode permettant de dé-
un sous-ensemble exclusif des MID possibles. Les
tecter la répétition et la perte de messages transmis
destinataire s’assure que le MID est compris dans
en utilisant la <(date de calcul du MAC) (DMC) et
l’intervalle correct et n’a pas déjà été recu.
4identificateur de message,, (MID) comme élé- ,
ments d’authentification.
C.2.3 Lorsque les identités de l’expéditeur et du
destinataire figurent dans chaque message en tant
C.2 Protection contre la répétition
qu’éléments d’authentification, il suffit au desti-
nataire de s’assurer que le message lui est bien
C.2.1 La répétition de messages peut être détec-
destiné et que le MID ne figurait pas déjà da
...