ISO 13492:1998
(Main)Banking — Key management related data element (retail)
Banking — Key management related data element (retail)
Banque — Élément de données lié à la gestion des clés (services aux particuliers)
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 13492
First edition
1998-05-15
Banking — Key management related data
element (retail)
Banque — Élément de données lié à la gestion des clés (services aux
particuliers)
A
Reference number
ISO 13492:1998(E)
---------------------- Page: 1 ----------------------
ISO 13492:1998(E)
Contents
1 Scope .1
2 Normative references .1
3 Definitions .2
4 Requirements for key management related data element.2
4.1 Concept of key set identifiers.3
4.2 Assignment of key set identifiers .4
5 Implementation in ISO 8583.4
Annex A (informative) Uses for transmitted key management related data.6
Annex B (informative) Example of usage of key set identifiers.10
© ISO 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet iso@iso.ch
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
© ISO
ISO 13492:1998(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
International Standard ISO 13492 was prepared by Technical Committee ISO/TC 68, Banking, securities and other
financial services, Subcommittee SC 6, Retail financial services.
Annexes A and B of this International Standard are for information only.
iii
---------------------- Page: 3 ----------------------
© ISO
ISO 13492:1998(E)
Introduction
This International Standard describes the structure and contents of a key management related data element that
may be conveyed in electronically transmitted messages within the retail banking environment to support the secure
management of cryptographic keys, where the retail banking environment involves the communications between a
card-accepting device and an acquirer, and between an acquirer and a card issuer. Key management of keys used
in an Integrated Circuit Card (ICC) and the related data elements are not covered in this International Standard.
This International Standard provides compatibility with the existing ISO standard on bank card originated messages
(see ISO 8583).
iv
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD © ISO ISO 13492:1998(E)
Banking — Key management related data element (retail)
1 Scope
This International Standard describes a key management related data element that may be transmitted either in
transaction messages to convey information about cryptographic keys used to secure the current transaction or in
cryptographic service messages to convey information about cryptographic keys to be used to secure future
transactions.
This International Standard addresses the requirements for the use of the key management related data element
within ISO 8583, using the following two ISO 8583 data elements: Security Related Control Information (bit 53) or
Key Management Data (bit 96). However, the transportation of key management related data is not limited to
ISO 8583.
This International Standard is applicable to either symmetric or asymmetric cipher systems.
Key management procedures for the secure management of the cryptographic keys within the retail banking
environment are described in ISO 11568. Security related data, such as PIN data and MACs, are described in
ISO 9564 and ISO 9807, respectively.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
International Standard. At the time of publication, the editions indicated were valid. All standards are subject to
revision, and parties to agreements based upon this International Standard are encouraged to investigate the
possibility of applying the most recent edition of the standards indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.
ISO/IEC 7812-1:1993, Identification cards — Identification of issuers — Part 1: Numbering system.
ISO/IEC 7812-2:1993, Identification cards — Identification of issuers — Part 2: Application and registration
procedures.
ISO 8583:1993, Financial transaction card originated messages — Interchange message specifications.
ISO 8908:1993, Banking and related financial services — Vocabulary and data elements.
ISO 9564-1:1991, Personal Identification Number management and security — Part 1: PIN protection principles and
techniques.
ISO 9807:1991, Banking and related financial services — Requirements for message authentication (retail).
ISO 11568-1:1994, Banking — Key management (retail) — Part 1: Introduction to key management.
ISO 11568-2:1994, Banking — Key management (retail) — Part 2: Key management techniques for symmetric
ciphers.
ISO 11568-3:1994, Banking — Key management (retail) — Part 3: Key life cycle for symmetric ciphers.
1
---------------------- Page: 5 ----------------------
© ISO
ISO 13492:1998(E)
ANSI X3.92:1987, Data Encryption Algorithm.
3 Definitions
For the purposes of this International Standard, the definitions given in ISO 8908 and the following definitions apply.
3.1
asymmetric cipher
a cipher in which the encipherment and decipherment keys are different and it is computationally infeasible to
deduce the decipherment key from the encipherment key
3.2
cipher
a pair of operations that effect transformations between plaintext and ciphertext under the control of a parameter
called a key
NOTE The encipherment operation transforms data (plaintext) into an unintelligible form (ciphertext). The decipherment
operation restores the original text.
3.3
cryptographic algorithm
a set of rules specifying the procedures required to perform encipherment and decipherment of data
NOTE The algorithm is designed so that it is not possible to determine the control parameters (e.g. keys) except by
exhaustive search.
3.4
cryptographic key; key
the control parameter of a cryptographic algorithm that cannot be deduced from the input and output data except by
exhaustive search
3.5
cryptographic service message
a message for transporting keys or related information used to control a keying relationship
3.6
primary key
that key for a transaction from which other keys for the transaction are produced (e.g. by means of variants or
transformations)
3.7
symmetric cipher
a cryptographic method using the same secret cryptographic key both for encipherment and decipherment
3.8
transaction message
a message used to convey information related to a financial transaction
4 Requirements for key management related data element
A key management related data element that conveys information about the associated transaction's key(s) is
normally divided into sub-fields. This data element may be transmitted in a transaction where the nature of the sub-
fields are implicitly known to the communicating parties. In environments where such transactions are exchanged,
the parties may use the key management related data element as a private-use field and define its sub-fields in any
mutually agreeable way. In other environments, transactions are exchanged where the nature of the sub-fields
2
---------------------- Page: 6 ----------------------
© ISO
ISO 13492:1998(E)
are not implicitly known and therefore must be structured using a standardized representation to support
interoperability. However, other environments, both types of transactions may be exchanged.
To distinguish between those transactions where the key management related data element must have a
standardized representation and those transactions where it is used for private use, the first byte of the key
management related data element shall be structured as a "control byte", where the control byte is defined as
follows:
00-9F: The first sub-field of the key management related data element is a variable-length "key set identifier,"
as defined in 4.1 and 4.2.
A0-FF: The key management related data element is a private-use field, where the nature of the sub-fields are
implicitly known to both communicating parties.
The use of key set identifiers provides a standardized way to convey any type of key management related
information associated with a key management system. This approach eliminates the need to recognize specific
key management techniques and to specify specific sub-fields to meet the needs of each such technique.
When the key management related data element begins with a key set identifier, the remainder of the data element
contains whatever type of information is required to determine the key(s) needed to cryptographically process the
transaction. Thus, there is no specified structure to the sub-fields contained in the remainder of the data element.
Any information that may vary on a per transaction basis is conveyed following the key set identifier. This
information normally includes the identity of a particular key(s) within a key set.
Key management related information that does not change from one transaction to the next need not be conveyed
with every transaction. Rather, it may be implicitly known, or it may be installed concurrent with, and stored in
association with, the corresponding key. Examples of information that may be implicitly known include the following:
Key management technique used for the transaction's keys (e.g. static key, unique key per transaction).
Format of enciphered or authenticated data (e.g. PIN block format).
Encipherment algorithm used.
Number of different keys used with the transaction and the purpose of each such key.
In some key management schemes, it may not be necessary to transmit a key management related data element in
transaction messages. The need to transmit such a data element is discussed in annex A.
4.1 Concept of key set identifiers
A key set identifier is a number that uniquely identifies a key set, where a key set is a group of related keys that are
all different but have certain characteristics in common, most notably:
All are managed using the same key management method.
The same high level key is used to encipher (for database storage) or derive all keys of the set.
The remainder of the key management related data element (beyond the key set identifier) is identically
structured for all keys of the set and is interpreted using the same logic.
Associated with any given key set is logic (e.g. computer software) at the acquiring host that may interpret the key
management related data element to determine what key(s) is to be used with that transaction and how each such
key is to be used.
Multiple key sets, with different key set identifiers, may use the exact same logic, differing only, for example, in the
key encipherment key or the derivation key used to decipher or derive the key for the associated transaction.
3
---------------------- Page: 7 ----------------------
© ISO
ISO 13492:1998(E)
The first byte of the key set identifier is the control byte (00-9F). Key set identifiers are assigned as described in 4.2.
Key set identifiers are of variable length and do not have a specified maximum length. The length of the key set
identifier is implicit. Therefore, the key management related data element shall not contain a "length" sub-field
preceding the key set identifier that indicates the length of the key set identifier. Similarly, it is unnecessary for the
key set identifier to be followed by a specified delimiter. (Note that if the key management related data element is
transmitted in a variable length field, the key management related data element itself may be preceded by a length
sub-field indicating the length of the entire data element, as is required in ISO 8583 for data elements Security
Related Control Information and Key Management Data.)
Since key set identifiers are of variable length and the length is implicit, the acquiring host should store in the table
of the key set identifiers that it recognizes the length of each key set identifier. When a host receives a transaction
from, e.g. a POS terminal, the host should attempt to match the key set identifier in each such table entry with as
many leftmost key management related data element digits as are specified for the particular table entry. Such a
match indicates that this table entry holds the key set identifier that applies to the just-received key management
related data element.
4.2 Assignment of key set identifiers
To prevent institutions from assigning duplicate key set identifiers, key set identifiers shall be assigned using either
the six-digit Issuer Identification Numbers (IINs) as defined in ISO 7812 or the six-digit Institution Identification
Codes (IICs) as defined in ISO 8583. The ISO Registration Authority assigns IINs to institutions that issue cards and
IICs to institutions that do not issue cards. Since IINs and IICs are unique to the institution to which they are
assigned and these two sets of numbers do not overlap, this ensures that, if two cryptographic environments are
combined, key set identifiers that were unique in each separate environment will be unique in the combined
environment.
An organization that wishes to obtain a key set identifier but has not been assigned an IIN or IIC may also obtain
such an identifier from an institution that has been assigned an IIN or IIC. Such an institution shall ensure that it
never assigns duplicate key set identifiers.
An institution may use an IIN or IIC directly as a key set identifier provided it will never need more key set identifiers
than the quantity of IINs or IICs it has been assigned. If the institution requires additional key set identifiers, it shall
concatenate one or more hexadecimal digits to the right of an IIN or IIC and in this way obtain multiple key set
identifiers from a single IIN or IIC.
The institution allocating key set identifiers should choose how many digits (if any) to concatenate with its IIN or IIC
to obtain its key set identifiers, prior to allocating any key set identifiers based on the IIN or IIC. For example, if an
institution chooses to use seven-digit key set identifiers by concatenating a single digit with an IIN or IIC, it may not,
after having used all 16 such seven-digit numbers, subsequently add an eighth digit to obtain additional key set
identifiers. Such an eight-digit key set identifier would match, in the first seven digits, a key set identifier already
assigned. For example, if the key set identifier seven-digit "1362047" already exists, the key set identifier eight-digit
"13620475" is not allowed, and vice versa, because the one key set identifier is totally included within the other key
set identifier. For an example of the usage of key set identifiers, see annex B.
5 Implementation in ISO 8583
When the key management related data element described in clause 4 is used with ISO 8583 to convey key
management information for the current transaction message, the contents of the key management related data
element shall be transmitted using ISO 8583 Security Related Control Information, which is a variable-length binary
data element up to 48 bytes.
NOTE 1 Examples of ISO 8583 messages in which Security Related Control Information may b
...
NORME ISO
INTERNATIONALE 13492
Première édition
1998-05-15
Banque — Élément de données lié à la
gestion des clés (services aux particuliers)
Banking — Key management related data element (retail)
A
Numéro de référence
ISO 13492:1998(F)
---------------------- Page: 1 ----------------------
ISO 13492:1998(F)
Sommaire
Page
1 Domaine d’application .1
2 Références normatives .1
3 Définitions .2
4 Exigences pour les données liées à la gestion de clés .3
4.1 Le concept d'identifiants de jeu de clés.3
4.2 Affectation d'identifiants de jeu de clés .4
5 Mise en œuvre dans l'ISO 8583 .5
Annexe A (informative) Utilisations de la donnée transmise liée à la gestion de clés.6
Annexe B (informative) Exemple d'utilisation d'identifiants de jeu de clés .10
© ISO 1998
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun pro-
cédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord
écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet iso@iso.ch
Imprimé en Suisse
ii
---------------------- Page: 2 ----------------------
© ISO
ISO 13492:1998(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'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 l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 13492 a été élaborée par le comité technique ISO/TC 68, Banque et services
financiers liés aux opérations bancaires, sous-comité SC 6, Cartes de transactions financières, supports et
opérations relatifs à celles-ci.
Les annexes A et B de la présente Norme internationale sont données uniquement à titre d’information.
iii
---------------------- Page: 3 ----------------------
©
ISO 13492:1998(F) ISO
Introduction
La présente Norme internationale décrit la structure et le contenu d'un élément de données lié à la gestion de clés
qui peut être transporté dans des messages transmis de manière électronique dans un environnement de services
bancaires aux particuliers, afin de permettre la gestion sûre des clés cryptographiques, cet environnement incluant
les communications entre un dispositif d'acceptation de cartes et un acquéreur, et entre un acquéreur et un
émetteur de cartes. La gestion de clés utilisées dans une carte à circuit intégré et les éléments de données qui y
sont liés ne sont pas couverts par la présente Norme internationale.
La présente Norme internationale offre une compatibilité avec les normes ISO existantes relatives aux messages
émis par cartes bancaires (voir ISO 8583).
iv
---------------------- Page: 4 ----------------------
©
NORME INTERNATIONALE ISO ISO 13492:1998(F)
Banque — Élément de données lié à la gestion des clés (services
aux particuliers)
1 Domaine d’application
La présente Norme internationale décrit un élément de données lié à la gestion de clés qui peut être transporté soit
dans des messages de transactions pour transporter des informations sur les clés cryptographiques utilisées pour
sécuriser la transaction en cours, soit dans des messages de service cryptographique pour transporter des
informations sur les clés cryptographiques à utiliser pour sécuriser des transactions ultérieures.
La présente Norme internationale traite les exigences liées à l'utilisation des éléments de données liés à la gestion
de clés de l'ISO 8583, en utilisant les deux éléments de données suivants de l’ISO 8583: l'Information de Contrôle
Liée à la Sécurité (bit 53) ou la Donnée de Gestion de Clés (bit 96). Néanmoins, le transport de données lié à la
gestion de clés n'est pas limité à l’ISO 8583.
La présente Norme internationale est applicable aux systèmes de relations cryptographiques symétriques ou
asymétriques.
Les procédures de gestion de clés, applicables à une gestion sûre des clés cryptographiques dans le cadre des
services bancaires aux particuliers, sont décrites dans l'ISO 11568. Des données liées à la sécurité, telles que le
numéro d'identification personnel (PIN) et le code d'authentification de messages (MAC), sont respectivement
décrites dans l’ISO 9564 et l’ISO 9807.
2 Références normatives
Les normes suivantes contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des
dispositions valables pour la présente Norme internationale. Au moment de la publication, les éditions indiquées
étaient en vigueur. Toute norme est sujette à révision et les parties prenantes des accords fondés sur la présente
Norme internationale sont invitées à rechercher la possibilité d'appliquer les éditions les plus récentes des normes
indiquées ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur
à un moment donné.
ISO/CEI 7812-1:1993, Cartes d'identification — Identification des émetteurs — Partie 1: Système de numérotation.
ISO/CEI 7812-2:1993,
Cartes d'identification — Identification des émetteurs — Partie 2: Procédures de demande
d’enregistrement.
ISO 8583:1993, Messages initiés par carte de transaction financière — Spécifications d’échange de messages.
ISO 8908:1993, Banque et services financiers connexes — Vocabulaire et éléments de données.
ISO 9564-1:1991, Banque — Gestion et sécurité du numéro personnel d'identification — Partie 1: Principes et
techniques de protection du PIN.
ISO 9807:1991, Banque et services financiers liés aux opérations bancaires — Spécifications liées à
l'authentification des messages (service aux particuliers).
ISO 11568-1:1994, Banque — Gestion de clés (services aux particuliers) — Partie 1: Introduction à la gestion de
clés.
1
---------------------- Page: 5 ----------------------
©
ISO
ISO 13492:1998(F)
ISO 11568-2:1994, Banque — Gestion de clés (services aux particuliers) — Partie 2: Techniques de gestion de
clés pour les algorithmes cryptographiques symétriques.
ISO 11568-3:1994, Banque — Gestion de clés (services aux particuliers) — Partie 3: Cycle de vie des clés pour les
algorithmes cryptographiques symétriques.
ANSI X3.92:1987, Data Encryption Algorithm.
3 Définitions
Pour les besoins de la présente Norme internationale, les définitions données dans l’ISO 8908 et les définitions
suivantes s'appliquent.
3.1
relation cryptographique asymétrique
type de relation cryptographique dans laquelle les clés de chiffrement et de déchiffrement sont différentes, et pour
lesquelles il est impossible par un calcul sur ordinateur de déduire la clé de déchiffrement à partir de la clé de
chiffrement
3.2
relation cryptographique
paire d'opérations qui effectue des transformations entre un texte en clair et un texte chiffré sous le contrôle d'un
paramètre appelé clé
NOTE L'opération de chiffrement transforme les données (texte en clair) sous une forme inintelligible (texte chiffré).
L'opération de déchiffrement rétablit le texte original.
3.3
algorithme cryptographique
ensemble de règles spécifiant les procédures à appliquer pour le chiffrement et pour le déchiffrement des données
NOTE L'algorithme est conçu de sorte qu'il soit impossible de déterminer les paramètres de contrôle (par exemple les clés)
autrement que par une recherche exhaustive.
3.4
clé cryptographique, clé
paramètre de contrôle d'un algorithme cryptographique, ne pouvant être déduit des données en entrée et en sortie
autrement que par une recherche exhaustive
3.5
message de service cryptographique
message destiné au transport des clés ou des informations utilisées pour le contrôle d'une relation mettant en jeu
des clés
3.6
clé primaire
clé de transaction à partir de laquelle les autres clés de la transaction sont produites (par exemple au moyen de
variantes ou de transformations)
3.7
relation cryptographique symétrique
type de relation cryptographique utilisant la même clé secrète pour le chiffrement et le déchiffrement
3.8
message de transaction
message utilisé pour transporter des informations liées à une transaction financière
2
---------------------- Page: 6 ----------------------
©
ISO
ISO 13492:1998(F)
4 Exigences pour les données liées à la gestion de clés
Un élément de données lié à la gestion de clés qui transporte de l'information sur la (les) clé(s) associée(s) à la
transaction est normalement subdivisé en sous champs. Cet élément de données peut être transmis dans une
transaction où la nature des sous champs est implicitement connue des parties en communication. Dans de tels
environnements, les parties peuvent utiliser l'élément de données lié à la gestion de clés comme un champ d'usage
privé et définir ses sous champs de n'importe quelle façon mutuellement admise. Dans d'autres environnements,
des transactions sont échangées où la nature des sous champs n'est pas implicitement connue et pour cela doivent
être structurés en utilisant une représentation normalisée afin de permettre l'interopérabilité. Dans encore d'autres
environnements, les deux types de transactions peuvent être échangées.
Pour faire la distinction entre les transactions où l'élément de données lié à la gestion de clés doit avoir une
représentation normalisée et celles où il est utilisé pour un usage privé, le premier octet de l'élément de données lié
à la gestion de clés doit être structuré comme un « octet de contrôle » défini de la manière suivante:
00-9F: Le premier sous champ de l'élément des données lié à la gestion de clés est un «identifiant de jeu de
clés» de longueur variable, tel que défini en 4.1 et 4.2.
A0-FF: L'élément de données lié à la gestion des clés est un champ d'usage privé, où la nature des sous-
champs est implicitement connue des deux entités en communication.
L'utilisation d'identifiants de jeu de clés fournit un moyen normalisé de transporter n'importe quel type d'information
liée à la sécurité associé à n'importe quel type de système de gestion de clés. Cette approche élimine le besoin
d'identifier des techniques spécifiques de gestion de clés et de définir des sous champs spécifiques afin de
s'adapter aux besoins de chacune de ces techniques.
Lorsque l'élément de données lié à la gestion des clés commence par un identifiant de jeu de clés, la partie non
utilisée de l'élément de données fournit les différents types d'informations nécessaires au jeu de clés associé pour
déterminer la ou les clé(s) nécessaire(s) au traitement cryptographique de cette transaction. En conséquence, il n'y
a pas de structure spécifique pour les sous champs contenus dans le reste de l'élément de données. Toute
information qui peut varier d'une transaction à l'autre est transmise selon le principe des identifiants de jeu de clés.
Cette information inclut normalement l'identité de la clé spécifique à ce jeu de clés.
Les informations liées à la gestion des clés qui ne changent pas d'une transaction à l'autre n'ont pas besoin d'être
transmises dans chaque transaction. Mieux, elles peuvent être implicitement connues, ou installées simultanément
avec les clés correspondantes et enregistrées avec celles-ci. Des exemples d'informations qui peuvent être
implicitement connues sont les suivants.
La technique de gestion de clés utilisée pour les clés de transaction (clé statique, clé unique par transaction).
Le format des données chiffrées ou authentifiées (format de PIN bloc).
L'algorithme de chiffrement utilisé.
Le nombre de clés utilisées avec la transaction et la fonction de chacune.
Dans certains schémas de gestion de clés, il peut être inutile de transmettre l'élément de données lié à la gestion
de clés dans le message de transaction. Le besoin de transmettre un tel élément de données est abordé dans
l'annexe A.
4.1 Le concept d'identifiants de jeu de clés
Un identifiant de jeu de clés est un nombre qui identifie un jeu de clés de façon unique; un jeu de clés est un groupe
de clés liées entre elles; elles sont toutes différentes, mais ont certaines caractéristiques en commun, en particulier
les suivantes.
Elles sont toutes gérées selon la même méthode de gestion de clés.
3
---------------------- Page: 7 ----------------------
©
ISO
ISO 13492:1998(F)
La même clé de haut niveau est utilisée pour chiffrer (pour un enregistrement en base de données) ou pour
dériver toutes les clés du jeu.
La partie non utilisée de l'élément de données lié à la gestion de clés (au delà de l'identifiant du jeu de clés) est
structurée de façon identique pour toutes les clés du jeu et est interprétée selon la même logique.
Un système logique (c'est-à-dire un logiciel) sur l'ordinateur hôte d'acquisition ayant pour but d'interpréter l'élément
de données lié à la gestion des clés doit être associé à tout jeu de clés donné, ceci afin de déterminer quelle clé a
été utilisée par la transaction et comment cette clé doit être traitée.
Des jeux de clés multiples, avec différents identifiants de jeu de clés, peuvent utiliser exactement la même logique,
se différenciant seulement, par exemple, par la clé de chiffrement ou de dérivation de clé utilisée pour déchiffrer ou
dériver la clé de la transaction associée.
Le premier octet de l'identifiant de jeu de clés est l'octet de contrôle (00-9F). Les identifiants de jeu de clés sont
affectés comme décrit en 4.2. Les identifiants de jeu de clés sont de longueur variable et n'ont pas de longueur
maximum spécifiée. La longueur de l'identifiant de jeu de clés est implicite. En conséquence, l'élément de données
lié à la gestion des clés ne doit pas contenir un sous champ de « longueur » précédant l'identifiant de jeu de clés
pour indiquer la longueur de celui-ci. De même, il n'est pas nécessaire de faire suivre l'identifiant de jeu de clés d'un
délimiteur spécifique. (A noter que si l'élément de données lié à la gestion de clés est transmis dans un champ de
longueur variable, il peut être lui-même précédé d'un sous champ de longueur, indiquant la longueur de l'élément
de données complet, comme cela est spécifié dans l'ISO 8583 pour les éléments de données « Information de
Contrôle Liée à la Gestion de la Sécurité » et « Donnée de Gestion de Clés ».)
Comme les identifiants de jeu de clés sont de longueur variable et que cette longueur est implicite, l'ordinateur hôte
d'acquisition devrait stocker, dans la table des identifiants de jeu de clés qu'il gère, la longueur de chacun de ces
identifiants. Lorsqu'un hôte reçoit une transaction, par exemple d'un terminal point de vente, il devrait essayer de
faire correspondre l'identifiant de jeu de clés aux entrées de ces tables en employant autant de chiffres (les plus à
gauche) qu'il en est défini dans l'entrée spécifique de la table pour cet élément de données. Une correspondance
indique que cette entrée de table contient l'identifiant de jeu de clés qui s'applique à l'élément de données lié à la
gestion de clés qu'il vient de recevoir.
4.2 Affectation d'identifiants de jeu de clés
Pour éviter aux institutions d'affecter des identifiants de jeu de clés identiques, ceux-ci doivent être affectés en
utilisant soit leur numéro d'identification d'émetteur à six chiffres (IIN), tel que défini dans l'ISO 7812, soit leur code
d'identification d'institution à six chiffres (IIC), tel que défini dans l'ISO 8583. L'autorité d'enregistrement de l'ISO
affecte les IIN aux institutions qui émettent des cartes, et les IIC aux institutions qui n'en émettent pas. Comme un
IIN ou un IIC est propre à l'institution à laquelle il est attribué, et que ces deux ensembles de nombres ne se
recouvrent pas, cela assure que, si deux environnements cryptographiques se combinent, les identifiants de jeu de
clés, qui étaient uniques dans chacun des environnements, le sont également dans l'environnement combiné.
Une organisation qui souhaite obtenir un jeu d'identifiant de clés et à qui il n'a pas été affecté de IIN ou de IIC peut
également obtenir un tel identifiant d'une institution en ayant reçu. Une telle institution doit s'assurer qu'elle n'affecte
pas d'identifiant de jeu de clés déjà existant.
Une institution peut utiliser directement un IIN ou un IIC comme identifiant de jeu de clés, à condition qu'elle n'ait
jamais besoin de plus d'identifiants de jeu de clés que le nombre de numéros d'identification qui lui ont été affectés.
Si l'institution a besoin d'identifiants supplémentaires, elle peut concaténer un ou plusieurs chiffres hexadécimaux à
la droite d'un IIN ou IIC, et de cette manière obtenir des identifiants de jeu de clés multiples à partir d'un seul IIN ou
IIC.
L'institution allouant des identifiants de jeu de clés devrait décider, préalablement à l'allocation, combien de chiffres
(s'il y en a plusieurs) doivent être concaténés aux IIN ou IIC pour obtenir ses identifiants de jeu de clés, basés sur
ces IIN ou IIC. Par exemple, si une institution décide d'utiliser des identifiants de jeu de clés de sept chiffres, en
concaténant un seul chiffre au IIN ou IIC, elle ne peut plus, après avoir utilisé tous les 16 nombres de sept chiffres,
ajouter un huitième chiffre pour obtenir de nouveaux identifiants de jeu de clés. Un tel identifiant de jeu de clés de
huit chiffres correspondrait, au niveau des sept premiers chiffres, à un identifiant de jeu de clés déjà attribué. Par
exemple, si l'identifiant de jeu de clés « 1362047 » existe déjà, l'identifiant de jeu de clés « 13620475 » ne peut pas
4
---------------------- Page: 8 ----------------------
©
ISO
ISO 13492:1998(F)
être attribué, et vice versa, parce que l'un est complètement inclus dans l'autre. Un exemple d'utilisation des
identifiants de jeu de clés est donné à l'annexe B.
5 Mise en œuvre dans l'ISO 8583
Lorsque l'élément de données lié à la gestion de clés décrit dans l’article 4 est utilisé avec l'ISO 8583 pour
transporter les informations de gestion de clés de la transaction courante, le contenu de cette donnée doit être
transmis en utilisant l'Information de Contrôle Liée à la Sécurité de l'ISO 8583, qui est un élément de données
binaires de longueur variable pouvant aller jusqu'à 48 octets
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.