ISO 10202-5:1998

Financial transaction cards - Security architecture of financial transaction systems using integrated circuit cards - Part 5: Use of algorithms

Cartes de transactions financières — Architecture de sécurité des systèmes de transactions financières utilisant des cartes à circuit intégré — Partie 5: Utilisation des algorithmes

La présente partie de l'ISO 10202 s'applique aux échanges de chiffrement dans lesquels au moins un noeud est une ICC ou un SAM. Les échanges entre d'autres noeuds de systèmes ne correspondent pas au domaine d'application de la présente partie de l'ISO 10202.La fourniture de toute fonction de sécurité est optionnelle et dépend des prescriptions relatives au système. Lorsqu'une fonction spécifique est considérée comme nécessaire, elle doit être exécutée de la manière décrite dans le présent document.

General Information

• Status: Withdrawn
• Publication Date: 08-Jul-1998
• Withdrawal Date: 08-Jul-1998
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/TC 68/SC 2 - Financial Services, security
• Drafting Committee: ISO/TC 68/SC 2 - Financial Services, security
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 17-Mar-2006
• Completion Date: 13-Dec-2025

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 10202-5
First edition
1998-07-15
Financial transaction cards — Security
architecture of financial transaction
systems using integrated circuit cards —
Part 5:
Use of algorithms
Cartes de transactions financières — Architecture de sécurité des systèmes
de transactions financières utilisant des cartes à circuit intégré —
Partie 5: Utilisation des algorithmes
A
Reference number
Contents
1 Scope .1
2 Normative references .1
3 Definitions .2
4 Notations .5
4.1 Values and entities .5
4.2 Processes .5
4.3 Optionlist .5
4.4 Functions.6
4.5 Digital signatures.6
4.6 Security message format .6
5 Mapping security functions to process types .7
6 Process specifications.9
6.1 Process 1: Key Exchange (KE).9
6.1.1 KE-symmetric-symmetric.9
6.1.2 KE-symmetric-symmetric-mutual-timeliness.10
6.1.3 KE-symmetric-asymmetric.11
6.1.4 KE-asymmetric-symmetric.12
6.1.5 KE-asymmetric-symmetric-mutual .13
6.1.6 KE-asymmetric-symmetric-mutual-timeliness.14
6.1.7 KE-asymmetric-asymmetric.15
6.2 Process 2: Entity Authentication (EA).16
6.2.1 EA-symmetric-timeliness.17
6.2.2 EA-symmetric-timeliness-mutual.18
©  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 [e-mail]
Printed in Switzerland
ii
©
ISO ISO 10202-5:1998(E)
6.2.3 EA-asymmetric. 21
6.2.4 EA-asymmetric-timeliness. 21
6.2.5 EA-asymmetric-timeliness-mutual. 22
6.3 Process 3: Message Authentication (MA) . 24
6.3.1 MA-symmetric . 24
6.3.2 MA-symmetric-timeliness . 24
6.3.3 MA-asymmetric . 25
6.3.4 MA-asymmetric-timeliness . 26
6.4 Process 4: Message Encipherment (ME). 26
6.4.1 ME-symmetric . 27
6.4.2 ME-symmetric-timeliness . 27
6.4.3 ME-asymmetric . 28
6.4.4 ME-asymmetric-timeliness . 28
6.5 Process 5: Transaction Certification (TC). 29
6.5.1 TC-symmetric. 30
6.5.2 TC-asymmetric. 30
6.5.3 TC-asymmetric-mutual. 31
6.6 Process 6: PIN Verification (PV). 32
6.6.1 PV symmetric . 32
6.6.2 PV-symmetric-timeliness. 33
6.6.3 PV-asymmetric. 34
6.6.4 PV-asymmetric-timeliness. 35
Annex A (informative) Certification of public keys . 37
Annex B (informative) Key and certificate identifiers. 38
Annex C (informative) Threat matrix . 39
Annex D (informative) ISO security services and security mechanisms. 40
Annex E (informative) Timeliness. 41
Annex F (informative) Bibliography. 43
Annex G (informative) Process options and functions . 44
Annex H (informative) Mapping ICC classes to process options. 46
iii
©
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 10202-5 was prepared by Technical Committee ISO/TC 68, Banking, securities and
other financial services, SC 6, Retail financial services.
ISO 10202 consists of the following parts, under the general title Financial transaction cards — Security architecture
of financial transaction systems using integrated circuit cards:
 Part 1: Card life cycle
 Part 2: Transaction process
 Part 3: Cryptographic key relationships
 Part 4: Secure application modules
 Part 5: Use of algorithms
 Part 6: Cardholder verification
 Part 7: Key management
 Part 8: General principles and overview
Annexes A to H of this part of ISO 10202 are for information only.
iv
©
ISO ISO 10202-5:1998(E)
Introduction
The standardisation of the security architecture of financial transaction systems using the Integrated Circuit Card
(ICC) is partitioned into the following:
Part 1: Card life cycle
Part 2: Transaction process
Part 3: Cryptographic key relationships
Part 4: Secure application modules
Part 5: Use of algorithms
Part 6: Cardholder verification
Part 7: Key management
Part 8: General principles and overview
This part of ISO 10202 describes the cryptographic processes available to fulfill those security functions defined in
parts 2, 4, and 6 where cryptographic algorithms are required.
ISO 10202 enables the execution of all security functions with either a symmetric or an asymmetric algorithm type.
ISO 10202 does not cover zero-knowledge techniques, which could be incorporated at a later stage.
The nodes participating in a given cryptographic process shall each be capable of the cryptographic functionality
required.
The cryptographic processes necessary to execute a security function are specified in options. Within each
cryptographic process, a separate option is specified for each algorithm type. Also a separate option is specified for
each variant of a cryptographic process that requires additional communication steps.
Clause 5 maps the security functions into the cryptographic processes available to achieve them.
Clause 6 specifies the details of the cryptographic processes. This part of ISO 10202 is not an implementation
specification, but it does indicate those data elements required at both nodes to ensure that the cryptographic
process is carried out in accordance with the required security procedures.
v
INTERNATIONAL STANDARD  © ISO ISO 10202-5:1998(E)
Financial transaction cards — Security architecture of financial
transaction systems using integrated circuit cards —
Part 5:
Use of algorithms
1 Scope
This part of ISO 10202 applies to cryptographic exchanges where at least one node is an ICC or a SAM.
Exchanges between other system nodes are outside the scope of this part of ISO 10202.
The provision of any security function is optional depending upon requirements of the system. Where a specific
function is identified as being required, it shall be performed in the manner described herein.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO 10202. For dated references, subsequent amendments to, or revisions of, any of these publications
do not apply. However, parties to agreements based on this part of ISO 10202 are encouraged to investigate the
possibility of applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain
registers of currently valid International Standards.
ISO 4909, Bank cards — Magnetic stripe data content for track 3.
ISO 9564-1, Banking — Personal Identification Number management and security — Part 1: PIN protection
principles and techniques.
ISO/IEC 9796, Information technology — Security techniques — Digital signature scheme giving message recovery.
ISO 10202-1, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 1: Card life cycle.
ISO 10202-2,
Financial transaction cards — Security architecture of financial transaction systems using integrated
.
circuit cards — Part 2: Transaction process
ISO 10202-3, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 3: Cryptographic key relationships.
ISO 10202-4, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 4: Secure application modules.
ISO 10202-6, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 6: Cardholder verification.
ISO 10202-7, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 7: Key management.
©
ISO
ISO 10202-8, Financial transaction cards — Security architecture of financial transaction systems using integrated
circuit cards — Part 8: General principles and overview.
3 Definitions
For the purposes of this part of ISO 10202, the following definitions apply.
3.1
asymmetric algorithm
an algorithm in which the encipherment and decipherment keys are different and for which it is computationally
infeasible to deduce one from the other
3.2
certificate
(See public key certificate.)
3.3
certificate identifier
certificate information which enables proper verification of a key certificate
3.4
ciphertext
enciphered plaintext
3.5
collision resistant
a function is called collision resistant if any two different input values produce different output results
3.6
credentials
the set of data items assigned to each entity and used to authenticate that entity
3.7
cryptographic link
two logical entities (nodes) who have previously agreed to exchange data and who have a cryptographic key-
relationship
3.8
cryptographic node
one of the logical entities (nodes) in a cryptographic link
3.9
decipherment
the process of transforming ciphertext into plaintext
3.10
digital signature
the result of a cryptographic transformation, executed by the initiator using his secret key with an asymmetric
algorithm, providing non repudiation of the source and integrity of the signed data
3.11
distinguishing name
a name which uniquely identifies an entity in a process
3.12
encipherment
the process of transforming plaintext into ciphertext
© ISO
3.13
entity authentication
corroboration that the identity of an entity (node) is the one claimed
3.14
explicit key identifier
(See key identifier.)
3.15
hash-function
a function which maps a string of bits to fixed-length strings of bits, satisfying the following two properties:
 it is computationally infeasible to find for a given output an input which maps to this output
 it is computationally infeasible to find for a given input a second input which maps to the same output
NOTE 1 The literature of the subject contains a variety of terms which have the same or similar meaning as hash-function.
Compressed encoding and condensing function are some examples.
NOTE 2 Computational feasibility depends on the user specific security requirements and environment.
3.16
initiator
the node or entity that initiates a process
3.17
key
a parameter used in conjunction with a cryptographic algorithm for executing cryptographic transformations
3.18
key identifier
key information which enables the recipient to determine the appropriate keys(s) associated with a transaction
3.19
message authentication
process providing cryptographic proof that a message has not been altered or destroyed in an unauthorized manner
3.20
message authentication code (MAC)
a data field, the contents of which can be used to verify the integrity of a message, or selected message elements
3.21
non-repudiation
security service providing permanent cryptographic proof of the integrity and origin of data — both in an unforgeable
relationship — which can be verified by any third party at any time
3.21
one-way function
a mathematical function which maps input values into output values in an irreversible way
3.22
plaintext
intelligible data that has a meaning and can be read or acted upon without the application of a transformation
3.23
public key certificate (certificate)
a set consisting of user credentials (including the public key) together with the trusted third party's digital signature
of these credentials
©
ISO
3.24
reflection attack
an attack by a false respondent whereby the initiator is challenged in a separate session with the same random
value it has transmitted in a concurrent session to authenticate that respondent
3.25
respondent
the node or entity that responds to the initiator of a process
3.26
symmetric algorithm
a cryptographic method using the same secret key for encipherment and decipherment
3.27
timeliness
a method to prevent a valid message from being replayed at a later time e.g. by using a probe of information as a
challenge requesting a proper and timely response
3.28
token
a set of data items formed for each data exchange sent by one entity to another
3.29
transaction certification code
result of the transaction certification process producing an electronic signature, which could either be a MAC (based
on a symmetric algorithm) or a digital signature (based on an asymmetric algorithm)
3.30
transaction certification
process providing cryptographic proof of the origin and integrity of transaction data which can be verified by a third
party
3.31
trusted third party
a generally accessible entity being known and trusted by the communicating entities
© ISO
4 Notations
Throughout this part of ISO 10202 the following notations are used.
4.1 Values and entities
Values and entities are in italic print:
A the distinguishing name of entity A.
Cert certificate of entity X.
X
CID certificate identifier of entity X (see annex B).
X
Cred credential of entity X (see annex A).
X
k a key (K , S , P ) associated with entity X.
X X X X
K a secret key associated with entity X to be used with a symmetric algorithm.
X
KID explicit key identifier for key k of entity X (see annex B).
k
X
KID explicit key identifier for key pair S /P of entity X (see annex B).
P X X
X
PBF0 PIN block format 0 according to ISO 9564.
PBF1 PIN block format 1 according to ISO 9564.
R random value issued by entity X.
X
S /P a public/secret key associated with entity X to be used with an asymmetric algorithm.
X X
TP the distinguishing name of the trusted third party.
T validity period for credentials.
val
T time stamp issued by entity X.
X
Z//Z* the concatenation of the bitstrings Z and Z*.
<>|<> separation of fields
4.2 Processes
Process identifiers are in upper case:
EA entity authentication
KE key exchange
MA message authentication
ME message encipherment/decipherment
PV PIN verification
TC transaction certification
4.3 Optionlist
Option identifiers are in lower case:
a asymmetric
s symmetric
m mutual
t timeliness
©
ISO
4.4 Functions
Function identifiers are in lower case italic print:
c compare
d decipher
e encipher
g generate a random
h hash
m authenticate message
o apply a one-way-function
s sign
v verify
The function notation is used in combination with an indication of the key values and entities.
c(Y,Z) the comparison of two bitstrings Y and Z; result is a status code.
dK(Z) the decipherment of data Z by a symmetric algorithm using key K.
dS (Z) the decipherment of data Z by an asymmetric algorithm using the secret key S .
X X
eK(Z) the encipherment of data Z by a symmetric algorithm using key K.
eP (Z) the encipherment of data Z by an asymmetric algorithm using the public key P .
X X.
R=g() the generation of a random value R.
h(Z) the application of a collision-resistent one-way function which maps a data item Z to an output value
of a fixed length using public properties (hashing); the hash result is h(Z).
mK(Z) the generation of a message authentication code (MAC-ing) using a symmetric algorithm as a one-
way function with the secret key K; the result is a Message Authentication Code MAC.
vK(MAC) the verification of a MAC using a symmetric algorithm as a one-way function with the secret key K;
the result is a status code.
oK(Z) the application of a one-way function which maps data Z to an output value of a fixed length using
an algorithm with a secret key K.
sS (Z) the application of a digital signature to data Z using the secret key S (signing); the result is a
X X
signature Sig.
vP (Sig) the verification process of Sig using the public key P ; the result is a status code.
X X
4.5 Digital signatures
The transmission of the unsigned Z (data to be transferred) is mandatory except when a digital signature scheme
with message recovery is used (see ISO/IEC 9796). In this case the data signed is composed as such that its
structural properties can be verified and that Z can be retrieved from it. This requires Z to be sufficiently short and
the asymmetric algorithm to be reversible.
Throughout this part of ISO 10202 the notation sS (Z) is used for both signing with data recovery or signing using a
A
hash function. This means that sS (Z) can either stand for sS (Z) or sS (h(Z))//Z where h(Z) could denote Z.
A A A
4.6 Security message format
Security messages are logical commands for standardised security functions. The information of these security
messages can be transmitted in the ICC related field of an 8583 message or interpreted by a SAM or application to
produce the appropriate commands for ICCs.
A security message is identified as follows:
© ISO
• message indicator logical message identifier; a concatenation of the following elements:
process: process identifier (subclause 4.2)
optionlist: list of option identifiers (subclause 4.3)
number: sequential message number
EXAMPLE KEss1
The security message contains one or more security message subfields. Mandatory subfields are in boldprint. The
subfield appears at least once in every message.
• message subfields | | |
: distinguishing name of source entity
: distinguishing name of destination entity
= | |
: optional datafield
: key identifier
: result of applying the function f to the data Z (subclause 4.4)
EXAMPLE A | B | KID | KID | eK*(KID ) | eK(K*)
K K* K*
5 Mapping security functions to process types
A mapping of the security functions as defined in parts 2, 4 and 6 of ISO 10202 and the set of process types is
shown in table 1.
©
ISO
Table 1 — Mapping of security functions to process types
SECURITY FUNCTION PROCESS TYPE KEY
ICC manufacturing
Manufacturing Initial key loading kMprd
M-P
Embedding and initialisation Initial key loading kEprd
E-P
ICC personalisation
Personalisation Initial key loading kIctl
I-C
Card session initialisation
IC compability check No cryptographic process
CDF parameters update
CDF activation/deactivation/reactivation/termination Key Exchange KE kIctl
I-C
ADF allocation Key Exchange KE kIctl
I-C
CDF specific authentication and verification
Cardholder verification PIN verification PV 1
kIenc
I-C
CDF static authentication Entity Authentication EA kIaut
I
CDF dynamic authentication Entity Authentication EA kIaut
C
Issuer host dynamic authentication Entity Authentication EA kIaut
I-C
CDF transaction handling
Transaction authorisation Message Authentication MA kImac
I-C
Data confidentiality Message Encipherment ME 1
kIenc
I- C
Transaction certification Transaction Certification TC kIcer
I-C
ADF selection
ADF selection No cryptographic process
ADF parameters update
ADF KActl loading Key Exchange KE kIkex
A-C I-A
ADF activation/deactivation/reactivation/termination Key Exchange KE kActl
A-C
ADF specific authentication and verification
Cardholder verification PIN verification PV 2
kAenc
A-C
ADF static authentication Entity Authentication EA kAaut
A
ADF dynamic authentication Entity Authentication EA kAaut
C
SAM authentication Entity Authentication EA kAaut
S-C
Application supplier authentication Entity Authentication EA kAaut
A-C
ADF transaction handling
Transaction authorisation Message Authentication MA kAmac
A-C
Data confidentiality Message Encipherment ME 2
kAenc
A-C
Transaction certification Transaction Certification TC kAcer
A-C
Card session termination
Card session termination No cryptographic process
1 At the issuers discretion these keys can be separately generated or derived.
2 At the providers discretion these keys can be separately generated or derived.
© ISO
6 Process specifications
This clause specifies the processes which are available for the different security functions. Each process may be
used on its own or in combination with other processes as required.
Each process allows several options that protect against different threats like interception, masquerade, replay,
manipulation or repudiation. The selection of options should be based on an analysis of the risk resulting from the
threats in a specific environment. Further guidance on this clause can be taken from Annex H.
Some processes include options that provide for timeliness where it is required to ensure that a message is unique
and/or sent at a specified time. Different ways to obtain timeliness are explained in Annex E.
For Entity Authentication the timeliness is inherent; combination with such a process automatically ensures
timeliness.
If the cryptographic process is based on a symmetric algorithm, the secret key required for the process shall have
been established at both participating nodes. If the secret key is shared between more than two entities belonging
to a group it is cryptographically impossible to distinguish between those entities.
If the cryptographic process is based on an asymmetric algorithm, key information shall be generated at each node.
The secret key shall be stored in a secure manner at the node, and the corresponding public information shall be
certified by a trusted third party that provides certificates (see Annex A).
All data elements in a message have to be known at the destination node in order to be able to execute the next
step in the process. If a data element is generated dynamically during the process, its transmission is mandatory.
If a data element is already known at the destination node, its transmission may be omitted.
Operations and parameters in boldprint are mandatory. All mandatory elements are reflected in the arrows of the
figures. Alternative steps described in the roles may not always correspond directly to the steps described in that
figure.
6.1 Process 1: Key Exchange (KE)
The secure electronic transmission of a secret key K or S to or from an Integrated Circuit Card or a SAM shall be
B
carried out according to one of the options described in this subclause. It is assumed that the initiator and
respondent have established a cryptographic link.
The secret key which is to be exchanged is always sent from A to B, except where the key is mutually developed by
the two communicating parties.
6.1.1 KE-symmetric-symmetric
Exchange of a secret key K* to be used with a symmetric algorithm by means of a symmetric algorithm (figure 1).
KEss1 = A | B | KID | KID | eK*(KID ) | eK(K*)
K K* K*
K common secret key
K* exchanged secret key
KID key identifier for key K
K
KID key identifier for key K*
K*
©
ISO
A B
S1 eK(K*)
S2 eK*(KID )
K*
eK(K*)
S3 KEss1
KID |eK*(KID )
K* S4
K* K*
KID S5
K*
c(KID ) S6
K*
Figure 1 — Key Exchange symmetric symmetric
S1 A calculates eK(K*)
S2 Option 1: A calculates eK*(KID )
K*
S3 A sends KEss1 to B
S4 B calculates dK(eK(K*)) to retrieve K*
S5 Option 1: B calculates dK*(eK*(KID )) to retrieve KID
K* K*
B K* KID
S6 Option 1: verifies the correctness of by comparing
K*
NOTE 1 The decipherment in step 5 could be replaced by a comparison of the enciphered key identifier KID .
K*
S5 Option 1: B calculates eK*(KID )
K*
S6 Option 1: B compares eK*(KID )
K*
NOTE 2 Alternatively a one-way-function can be used in option 1.
S2 Option 1: A calculates oK*(KID )
K*
S5 Option 1: B calculates oK*(KID )
K*
S6 Option 1: B compares oK*(KID )
K*
6.1.2 KE-symmetric-symmetric-mutual-timeliness
K*
Mutual generation of a secret key to be used with a symmetric algorithm by means of a symmetric algorithm
A
(figure 2). Entity Authentication of entity is implicit.
=B A KID R
KEssmt1 | | |
K* B
KEssmt2 =A | B | KID | eK*(KID ) | eK(R )
K K* A
K common secret key
K* mutually generated secret key
KID key identifier for key K
K
KID K*
key identifier for key
K*
© ISO
Figure 2 — Key Exchange symmetric symmetric mutual timeliness
S1 B generates a random R
B
S2 B sends KEssmt1 to A
S3 A generates a random R
A
S4 A calculates eK(R )
A
S5 A calculates eR (R ) to retrieve K*
A B
S6 Option 1: A calculates eK*(KID )
K*
S7 A sends KEssmt2 to B
S8 B calculates dK(eK(R )) to retrieve R
A A
S9 B calculates eR (R ) to retrieve K*
A B
S10 Option 1: B calculates dK*(eK*(KID )) to retrieve KID
K* K*
S11 Option 1: B verifies the correctness of K* by comparing KID
K*
NOTE 1 The decipherment in step 10 could be replaced by a comparison of the enciphered key identifier KID .
K*
S10 Option 1: B calculates eK*(KID )
K*
S11 Option 1: B compares eK*(KID )
K*
NOTE 2 Alternatively a one-way-function can be used in option 1.
S6 Option 1: A calculates oK*(KID )
K*
S10 Option 1: B calculates oK*(KID )
K*
S11 Option 1: B compares oK*(KID )
K*
6.1.3 KE-symmetric-asymmetric
Key exchange of a secret key S to be used with an asymmetric algorithm by means of a symmetric algorithm
B
(figure 3).
The entity using this option for loading a secret key into an Integrated Circuit Card for digital signature purposes
shall be responsible for the authenticity of the corresponding public key. The non-repudiation property will be lost if
knowledge of the secret key is shared.
KEsa1 =A | B | KID | KID | CID | Cert | eK(S )
K P B B B
B
K common secret key
S /P exchanged secret/public key pair for entity B
B B
KID key identifier for key K
K
KID key identifier for key pair S /P
P B B
B
CID certificate identifier for Cert
B B
©
ISO
A B
S1 Cert
B
S2 eK(S )
B
Cert |eK(S )
S3 KEsa1
B B
S S4
B
v(Cert ) S5
B
P
B
v(S /P )
S6
B B
Figure 3 — Key Exchange symmetric asymmetric
S1 A obtains Cert
B
S2 A calculates eK(S )
B
A B
S3 sends KEsa1 to
B dK(eK(S )) S
S4 calculates to retrieve
B B
S5 Option 1: B validates P by verifying Cert
B B
S6 Option 2: B verifies the correctness of the key pair S /P by verifying dS (eP (B))=B
B B B B
6.1.4 KE-asymmetric-symmetric
K
Key exchange of a secret key to be used with a symmetric algorithm by means of an asymmetric algorithm
(figure 4).
K
If signing is performed using a technique with data recovery, the transmission of the key becomes optional.
=B A KID CID Cert
KEas1 | | | |
P B B
B
=A B KID CID Cert KID eK(KID ) eP (sS (K))
KEas2 | | | | | | |
P A A K K B A
A
S /P secret/public key pair of entity A
A A
S /P secret/public key pair of entity B
B B
K exchanged secret key
KID key identifier for key K
K
KID S /P
key identifier for key pair
P A A
A
KID key identifier for key pair S /P
P B B
B
CID certificate identifier for Cert
A A
CID Cert
certificate identifier for
B B
© ISO
A B
KEas1 S1
Cert
S2 v(Cert )
B
B
P
B
S3 eP (sS (K))
B A
S4 eK(KID )
K
S5 KEas2
eP (sS (K))
v(Cert ) S6
B A A
KID |eK(KID )
P
K K A
K
S7
KID
S8
K
c(KID )
S9
K
Figure 4 — Key Exchange asymmetric symmetric
S1 Option 1: B sends KEas1
A P Cert
S2 Option 1: validates by verifying
B B
S3 A calculates eP (sS (K))
B A
S4 Option 2: A calculates eK(KID )
K
A
S5 sends KEas2
S6 Option 3: B validates P by verifying Cert
A A
B vP (dS (eP (sS (K)))) K
S7 calculates to retrieve
A B B A
S8 Option 2: B calculates dK(eK(KID )) to retrieve KID
K K
S9 Option 2: B verifies the correctness of K by comparing KID
K
NOTE 1 The decipherment in step 8 could be replaced by a comparison of the enciphered key identifier KID .
K
S8 Option 2: B calculates eK(KID )
K
B eK(KID )
S9 Option 2: compares
K
NOTE 2 Alternatively a one-way-function can be used in option 2.
S4 Option 2: A calculates oK(KID )
K
S8 Option 2: B calculates oK(KID )
K
S9 Option 2: B compares oK(KID )
K
6.1.5 KE-asymmetric-symmetric-mutual
Mutual generation of a secret key K to be used with a symmetric algorithm by means of an asymmetric algorithm
(figure 5). The algorithm f shall satisfy the following relationships where b is a public base:
P =f(b,S )
x x
f(P ,S )=f(P ,S )
x y y x
Entity authentication shall take place before a key may be established using this technique.
KEasm1=B | A | KID | P
P R
R B
B
=A B KID P KID eK(KID )
KEasm2 | | | | |
P R K K
R A
A
S /P random secret/public key pair of entity A
R R
A A
S /P random secret/public key pair of entity
R R
B B
S /P random secret/public key pair of entity B
R R
B B
K
mutually generated secret key
©
ISO
KID key identifier for key K
K
KID key identifier for key pair S /P
P R R
R A A
A
KID key identifier for key pair S /P
P R R
R B B
B
A B
S =g() S1
RB
P =f(b,S )
S2
RB RB
P
KEasm1 S3
RB
S =g()
S4
RA
P =f(b,S )
S5
RA RA
K
S6
S7 eK(KID )
K
S8 KEasm2
P
RA
KID |eK(KID ) K S9
K K
KID S10
K
c(KID ) S11
K
Figure 5 — Key Exchange asymmetric symmetric mutual
B S =g()
S1 generates
R
B
B P =f(b,S )
S2 calculates
R R
B B
S3 B sends KEasm1
S4 A generates S =g()
R
A
S5 A calculates P =f(b,S )
R R
A A
S6 A calculates f(P ,S ) to retrieve K
R R
B A
S7 Option 1: A calculates eK(KID )
K
S8 A sends KEasm2
S9 B calculates f(P ,S ) to retrieve K
R R
A B
S10 Option 1: B calculates dK(eK(KID )) to retrieve KID
K K
S11 Option 1: B verifies the correctness of K by comparing KID
K
NOTE Alternatively a one-way-function can be used in option 1.
S7 Option 1: A calculates oK(KID )
K
S10 Option 1: B calculates oK(KID )
K
S11 Option 1: B compares oK(KID )
K
6.1.6 KE-asymmetric-symmetric-mutual-timeliness
Mutual generation of a secret key K to be used with a symmetric algorithm by means of an asymmetric algorithm
(figure 6). Entity authentication of entity A is implicit.
R
KEasmt1 =B | A | KID | CID | Cert |
P B B B
B
KEasmt2 =A | B | KID | CID | Cert | KID | eK(KID ) | eP (sS (R ))
P A A K K B A A
A
S /P secret/public key pair of entity A
A A
S /P secret/public key pair of entity B
B B
K mutually generated secret key
© ISO
KID key identifier for key K
K
KID key identifier for key pair S /P
P A A
A
KID key identifier for key pair S /P
P B B
B
CID certificate identifier for Cert
A A
CID certificate identifier for Cert
B B
A B
R =g()
S1
B
R KEasmt1 S2
B
S3 v(Cert )
B
P
B
S4 R =g()
A
S5 eP (sS (R ))
B A A
S6 K
S7 eK(KID )
K
eP (sS (R ))
S8 KEasmt2
B A A
KID |eK(KID ) v(Cert ) S9
K K A
P
A
R S10
A
K S11
KID S12
K
c(KID ) S13
K
Figure 6 — Key Exchange asymmetric symmetric mutual timeliness
S1 B generates a random R
B
S2 B sends KEasmt1
S3 Option 1: A validates P by verifying Cert
B B
A R
S4 generates a random
A
S5 A calculates eP (sS (R ))
B A A
S6 A calculates eR (R ) to retrieve K
A B
S7 Option 2: A calculates eK(KID )
K
S8 A sends KEasmt2
S9 Option 3: B validates P by verifying Cert
A A
S10 B calculates vP (dS (eP (sS (R )))) to retrieve R
A B B A A A
B eR (R ) to retrieve K
S11 calculates
A B
S12 Option 2: B calculates dK(eK(KID )) to retrieve KID
K K
S13 Option 2: B verifies the correctness of K by comparing KID
K
NOTE Alternatively a one-way-function can be used in option 2.
S7 Option 1: A calculates oK(KID )
K
S12 Option 2: B calculates oK(KID )
K
S13 Option 2: B compares oK(KID )
K
6.1.7 KE-asymmetric-asymmetric
Key exchange of a secret key S to be used with an asymmetric algorithm by means of an asymmetric algorithm
B*
(figure 7).
The entity using this option for loading a secret key into an Integrated Circuit Card for digital signature purposes
shall be responsible for the authenticity of the corresponding public key.
©
ISO
KEaa1 =B | A | KID | CID | Cert
P B B
B
KEaa2 =A | B | KID | CID | Cert | KID | CID | Cert | eP (sS (S ))
P A A P B* B* B A B*
A B*
S /P secret/public key pair of entity A
A A
S /P secret/public key pair of entity B
B B
S /P exchanged secret/public key pair of entity B
B* B*
KID key identifier for key pair S /P
P A A
A
KID key identifier for key pair S /P
P B B
B
CID certificate identifier for Cert
A A
CID certificate identifier for Cert
B B
certificate identifier for
CID Cert
B* B*
A B
KEaa1 S1
Cert
S2 v(Cert )
B
B* *
P
B
S3 eP (sS (S ))
B A B*
S4 Cert
B*
S5 KEaa2
Cert |eP (sS (S ))
v(Cert ) S6
B* B A B* A
P
A
S S7
B*
v(Cert ) S8
B*
P
B*
v(S /P ) S9
B* B*
Figure 7 — Key Exchange asymmetric asymmetric
S1 Option 1: sends KEaa1
B
S2 Option 1: validates by verifying
A P Cert
B B
S3 A calculates eP (sS (S ))
B A B*
S4 A calculates Cert
B*
S5 A sends KEaa2
S6 Option 2: B validates P by verifying Cert
A A
S7 B calculates vP (dS (eP (sS (S )))) to retrieve S
A B B A B* B*
S8 Option 3: B validates P by verifying Cert
B* B*
S9 Option 3: B verifies the correctness of the key pair S /P by verifying dS (eP (B))=B
B* B* B* B*
6.2 Process 2: Entity Authentication (EA)
The verification of a cryptographic node shall be performed according to one of the options described in this
subclause. It is assumed that the initiator and respondent have established a cryptographic link. One of the nodes
is an Integrated Circuit Card or a SAM.
The respondent B is authenticated by the initiator A, except where mutual authentication is the objective.
The node to be authenticated proves its identity by showing its knowledge of a secret key.
With the exception of 6.2.3 the entity authentication options include timeliness and a challenge/response scheme.
© ISO
Entity Authentication by itself does not guarantee that subsequent messages are from the same source. It is a
sufficient requirement that the challenge be generated outside the control of the authenticated entity. Depending on
the implementation, the challenge might be a counter value obtained from an intermediate entity trusted by the
challenging entity.
6.2.1 EA-symmetric-timeliness
Authentication of entity B by means of a challenge response scheme using a symmetric algorithm (figure 8).
EAst1 =A | B | KID | R
K A
B
EAst2 =B | A | eK (R )
B A
K secret derivation key
K unique (derived) secret key for entity B
B
KID key identifier for key K
K B
B
A B
S1 R =g()
A
S2 EAst1 R
A
K S3
B
eK (R ) S4
B A
eK (R ) EAst2 S5
B A
S6 K
B
S7 eK (R )
B A
S8 c(eK (R ))
B A
Figure 8 — Entity Authentication symmetric timeliness
S1 A generates a random R
A
S2 A sends EAst1 to B
S3 B obtains K
B
S4 B calculates eK (R )
B A
S5 B sends EAst2 to A
S6 A obtains K or calculates K =eK(B)
B B
S7 A calculates eK (R )
B A
S8 A verifies eK (R )
B A
NOTE 1 Protection against a reflection attack is obtained by using unidirectional keys which are generated by a derivation
process. By using an encipherment technique to derive K key separation on entity B level is achieved.
B
When a common secret key K is used for entity authentication a reflection attack is prevented by concatenating the entity
identifier A to the challenge.
EAst1 =A | B | KID | R
K A
EAst2 =B | A | eK(R //A)
A
S7 A calculates eK (R //A))
B A
S8 A verifies eK (R //A))
B A
NOTE 2 Protection against a chosen plaintext attack can be obtained by encipherment of the challenge with the unique
derived secret key K from entity A.
A
=A | B | KID |
EAst1 eK (R )
K A A
©
ISO
EAst2 =B | A | eK (R )
B A
S1 Option 1: A calculates K =eK(A)
A
S2 A generates a random R
A
S3 A calculates eK (R )
A A
S4 A sends EAst1 to B
S5 B calculates K =eK(A)
A
S6 B calculates dK (eK (R )) to retrieve R
A A A A
S7 B obtains K
B
S8 B calculates eK (R )
B A
S9 B sends EAst2 to A
A K K =eK(B)
S10 obtains or calculates
B B
S11 A calculates eK (R )
B A
S12 A verifies eK (R )
B A
NOTE 3 When a parameter value unique to the message (e.g. a time stamp T ) is considered secure enough as a deterrent
B
against replay, the authentication could be realised by a single message sent from B to A.
EAst1 =B | A | KID | eK (T )
K B B
B
S1 B obtains K
B
S2 B obtains T
B
S3 B calculates eK (T )
B B
S4 B sends EAst1 to A
S5 A obtains K or calculates K =eK(B)
B B
S6 A calculates dK (eK (T )) to retrieve T
B B B B
S7 A verifies T
B
NOTE 4 The comparison of the challenge response received from B with the expected result calculated by the initiator A
could be replaced by the comparison of the deciphered challenge response received from B with the challenge generated by
the initiator A.
S7 A calculates dK (eK (R )) to retrieve R
B B A A
S8 A verifies R
A
NOTE 5 Alternatively a one-way-function can be used.
B oK (R )
S4 calculates
B A
S7 A calculates oK (R )
B A
S8 A verifies oK (R )
B A
6.2.2 EA-symmetric-timeliness-mutual
Mutual authentication of entities A and B by means of a challenge response scheme using a symmetric algorithm
(figure 9).
EAstm1=A | B | KID | R
K A
B
EAstm2=B | A | KID | eK (R ) | R
K B A B
A
EAstm3=A | B | eK (R )
A B
K secret derivation key
K unique (derived) secret key for entity A
A
K unique (derived) secret key for entity B
B
KID key identifier for key K
K A
...

NORME ISO
INTERNATIONALE 10202-5
Première édition
1998-07-15
Cartes de transactions financières —
Architecture de sécurité des systèmes de
transactions financières utilisant des cartes
à circuit intégré —
Partie 5:
Utilisation des algorithmes
Financial transaction cards — Security architecture of financial transaction
systems using integrated circuit cards —
Part 5: Use of algorithms
A
Numéro de référence
Sommaire Page
1 Domaine d'application.1
2 Références normatives .1
3 Termes et définitions.2
4 Notations .4
4.1 Valeurs et entités .4
4.2 Processus.5
4.3 Liste d'option .5
4.4 Fonctions.6
4.5 Signatures numériques.6
4.6 Format de message de sécurité .7
5 Correspondances entre les fonctions de sécurité et les types de processus .7
6 Spécifications de processus .9
6.1 Processus 1: échange de clé (KE - Key Exchange) .9
6.2 Processus 2: authentification de l'entité (EA - Entity Authentication).18
6.3 Processus 3: authentification du message (MA - Message Authentication).26
6.4 Processus 4: chiffrement de messages (ME-Message Encipherment).30
6.5 Processus 5: certification de transaction (TC - Transaction Certification) .33
6.6 Processus 6: vérification du PIN (PV- PIN Verification).36
Annexe A (informative) Certification des clés publiques.42
Annexe B (informative) Identificateurs de clés et de certificats.43
Annexe C (informative) Matrice des menaces de danger.45
Annexe D (informative) Services de sécurité ISO et mécanismes de sécurité .46
Annexe E (informative) Degré d'actualité des données.48
©  ISO 1998
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite 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 l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet [e-mail]
Imprimé en Suisse
ii
© ISO
Annexe F (informative) Bibliographie. 50
Annexe G (informative) Options de processus et fonctions. 51
Annexe H (informative) Correspondance entre les classes ICC et les options de processus. 53
iii
© ISO
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 10202-5 a été élaborée par le comité technique ISO/TC 68, Banque, valeurs
mobilières et autres services financiers, sous-comité SC 6, Services financiers liés à la clientèle.
L'ISO 10202 comprend les parties suivantes, présentées sous le titre général Cartes de transactions financières —
Architecture de sécurité des systèmes de transactions financières utilisant des cartes à circuit intégré:
 Partie 1: Cycle de vie de la carte
 Partie 2: Processus de transaction
 Partie 3: Relations entre les clés de chiffrement
 Partie 4: Modules applicatifs de sécurité
 Partie 5: Utilisation des algorithmes
 Partie 6: Vérification du porteur de carte
 Partie 7: Gestion des clés
 Partie 8: Principes généraux et vue d’ensemble
Les annexes A à H de la présente partie de l'ISO 10202 sont données uniquement à titre d'information.
iv
© ISO
Introduction
La normalisation de l'architecture de sécurité des systèmes de transactions financières utilisant les cartes à circuit
intégré (ICC) est divisée de la manière suivante:
 Partie 1: Cycle de vie de la carte
 Partie 2: Processus de transaction
 Partie 3: Relations entre les clés de chiffrement

Partie 4: Modules applicatifs de sécurité
 Partie 5: Utilisation des algorithmes
 Partie 6: Vérification du porteur de carte
 Partie 7: Gestion des clés
 Partie 8: Principes généraux et vue d’ensemble
La présente partie de l'ISO 10202 décrit les processus de chiffrement disponibles pour remplir les fonctions de
sécurité définies dans les parties 2, 4 et 6 de l'ISO 10202, et pour lesquelles les algorithmes de chiffrement sont
nécessaires.
Elle permet l'exécution de toutes les fonctions de sécurité avec un type d'algorithme symétrique ou asymétrique.
Elle ne comprend pas les techniques d'apport de connaissance nul, qui pourront être incluses ultérieurement.
Chaque nœud participant à un processus de chiffrement donné doit avoir la fonction de chiffrement nécessaire.
Les processus de chiffrement nécessaires à l'exécution d'une fonction de sécurité sont spécifiés dans les options.
Dans chaque processus, une option séparée est définie pour chaque type d'algorithme. De même, une option
particulière est spécifiée pour chaque variante d'un processus de chiffrement nécessitant des étapes de
communication supplémentaires.
L'article 5 présente les fonctions de sécurité des processus de chiffrement disponibles pour les effectuer.
L'article 6 spécifie les détails des processus de chiffrement. La présente partie de l'ISO 10202 n'est pas une
spécification de mise en application, mais indique les éléments de données nécessaires aux deux nœuds pour
garantir que le processus de chiffrement est effectué conformément aux procédures de sécurité exigées.
v
NORME INTERNATIONALE  © ISO ISO 10202-5:1998(F)
Cartes de transactions financières — Architecture de sécurité des
systèmes de transactions financières utilisant des cartes à circuit
intégré —
Partie 5:
Utilisation des algorithmes
1 Domaine d'application
La présente partie de l'ISO 10202 s'applique aux échanges de chiffrement dans lesquels au moins un nœud est
une ICC ou un SAM. Les échanges entre d'autres nœuds de systèmes ne correspondent pas au domaine
d'application de la présente partie de l'ISO 10202.
La fourniture de toute fonction de sécurité est optionnelle et dépend des prescriptions relatives au système.
Lorsqu'une fonction spécifique est considérée comme nécessaire, elle doit être exécutée de la manière décrite
dans le présent document.
2 Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence qui y est faite,
constituent des dispositions valables pour la présente partie de l'ISO 10202. Pour les références datées, les
amendements ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes
aux accords fondés sur la présente partie de l'ISO 10202 sont invitées à rechercher la possibilité d'appliquer les
éditions les plus récentes des documents normatifs indiqués ci-après. Pour les références non datées, la dernière
édition du document normatif en référence s’applique. Les membres de la CEI et de l'ISO possèdent le registre des
Normes internationales en vigueur.
ISO 4909, Cartes bancaires — Zone magnétique — Contenu des données de la piste 3.
ISO 9564-1, Banque — Gestion et sécurité du numéro personnel d'identification — Partie 1: Principes et techniques
de protection du PIN.
ISO/CEI 9796, Technologies de l'information — Techniques de sécurité — Schéma de signature numérique
rétablissant le message.
ISO 10202-1, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 1: Cycle de vie de la carte.
ISO 10202-2, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 2: Processus de transaction.
ISO 10202-3, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 3: Relations entre les clés de chiffrement.
ISO 10202-4, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 4: Modules applicatifs de sécurité.
© ISO
ISO 10202-6,
Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 6: Vérification du porteur de carte.
ISO 10202-7, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 7: Gestion des clés.
ISO 10202-8, Cartes de transactions financières — Architecture de sécurité des systèmes de transactions
financières utilisant des cartes à circuit intégré — Partie 8: Principes généraux et vue d’ensemble.
3 Termes et définitions
Pour les besoins de la présente partie de l'ISO 10202, les termes et définitions suivants s'appliquent.
3.1
algorithme asymétrique
algorithme dans lequel les clés de chiffrement et de déchiffrement sont différentes et pour lequel il est impossible,
par le calcul, de déduire l'une connaissant l'autre
3.2
certificat
(Voir certificat de clé publique.)
3.3
identificateur de certificat
informations relatives au certificat et permettant la vérification correcte d'un certificat de clé
3.4
texte chiffré
texte en clair chiffré
3.5
résistant à la collision
une fonction est dite résistante à la collision si deux valeurs d'entrée produisent des résultats de sortie différents
3.6
justificatifs d'identité
ensemble des éléments de données attribués à chaque entité et utilisés pour authentifier cette entité
3.7
liaison de chiffrement
deux entités logiques (nœuds) ayant préalablement convenu d'un échange de données et ayant une relation de clé
de chiffrement
3.8
nœud de chiffrement
une des deux entités logiques (nœuds) d'une liaison de chiffrement
3.9
déchiffrement
processus de transformation d'un texte chiffré en un texte en clair
3.10
signature numérique
résultat d'une transformation de chiffrement, exécutée par l'initiateur utilisant sa clé secrète avec un algorithme
asymétrique, assurant la non-répudiation de la source et l'intégrité des données signées
3.11
nom distinctif
nom identifiant de façon unique une entité au cours d'un processus
© ISO
3.12
chiffrement
processus de transformation d'un texte en clair en un texte chiffré
3.13
authentification d'entité
confirmation que l'identité d'une entité (nœud) est bien celle déclarée
3.14
identificateur explicite de la clé
voir identificateur de clé
3.15
fonction de tronçonnage
fonction faisant correspondre une chaîne de bits à des chaînes de bits de longueur fixe ayant les deux propriétés
suivantes:
 pour une sortie donnée, il est impossible d'obtenir par le calcul une entrée correspondant à cette sortie
 pour une entrée donnée, il est impossible d'obtenir par le calcul une deuxième entrée correspondant à la même
sortie
NOTE 1 La biblographie en la matière contient divers termes qui ont une signification identique ou analogue à fonction de
contrôle. Codage comprimé et fonction de condensation en sont des exemples.
NOTE 2 La possibilité de calculer dépend des prescriptions de sécurité et de l'environnement spécifiques de l'utilisateur.
3.16
initiateur
le nœud ou l'entité qui engage un processus
3.17
clé
paramètre utilisé conjointement avec un algorithme de chiffrement pour l'exécution de transformations
cryptographiques
3.18
identificateur de clé
information d'une clé permettant au destinataire de déterminer la ou les clés appropriées associées à une
transaction
3.19
authentification du message
processus fournissant la preuve cryptographique qu'un message n'a pas été modifié ou détruit sans autorisation
3.20
code d'authentification du message (MAC)
champ de données, dont le contenu peut être utilisé pour vérifier l'intégrité d'un message ou de certains éléments
de message
3.21
non-répudiation
service de sécurité fournissant une preuve cryptographique permanente de l'intégrité et de l'origine des données –
dans une relation infalsifiable – pouvant être vérifiée à tout moment par une tierce partie
3.22
fonction unidirectionnelle
fonction mathématique qui fait correspondre des valeurs d'entrée à des valeurs de sortie de manière irréversible
© ISO
3.23
certificat de clé publique (certificat)
ensemble constitué des justificatifs d'identité de l'utilisateur (y compris la clé publique) ainsi que de la signature
numérique d'une tierce partie de confiance pour ces justificatifs
3.24
attaque par réflexion
attaque provenant d'un faux répondeur et par laquelle l'initiateur est interrogé dans une session séparée avec la
même valeur aléatoire que celle qu'il a transmise dans une session concurrente pour authentifier ce répondeur
3.25
répondeur
le nœud ou l'entité qui répond à l'initiateur d'un processus
3.26
algorithme symétrique
méthode cryptographique utilisant la même clé secrète pour le chiffrement et le déchiffrement
3.27
degré d'actualité des données
méthode permettant d'empêcher un message valide d'être répété ultérieurement en utilisant, par exemple, des
informations comme une question demandant une réponse correcte et d'actualité
3.28
jeton
ensemble d'éléments de données formé pour chaque échange de données et émis d'une entité vers une autre.
3.29
code de certification de transaction
résultat du processus de certification de transaction produisant une signature électronique, pouvant être un MAC
(basé sur un algorithme symétrique) ou une signature numérique (basée sur un algorithme asymétrique)
3.30
certification de transaction
processus fournissant une preuve cryptographique de l'origine et de l'intégrité des données de transaction pouvant
être vérifiée par une tierce partie
3.31
tierce partie de confiance
entité généralement accessible, connue et ayant la confiance des entités impliquées dans une communication
3.32
texte en clair
données intelligibles ayant une signification et pouvant être lues ou traitées sans l'application d'une transformation
NOTE Le paragraphe 3.32 n’existe pas dans la version anglaise de la présente partie de l'ISO 10202.
4 Notations
La présente partie de l'ISO 10202 utilise les notations suivantes.
4.1 Valeurs et entités
Les valeurs et entités sont imprimées en italique:
A nom distinctif de l'entité A
Cert certificat de l'entité X
X
© ISO
identificateur de certificat de l'entité (voir annexe B)
CID X
X
Cred justificatif d'identité de l'entité X (voir annexe A)
X
k une clé (K , S , P ) associée à une entité X
X X X X
K une clé secrète associée à une entité X devant être utilisée avec un algorithme symétrique
X
KID identificateur de clé explicite pour une clé k d'une entité X (voir annexe B)
k
X
KID identificateur de clé explicite pour une paire de clés S /P de l'entité X (voir annexe B)
p X X
X
PBF0 bloc PIN de format 0 conforme à l'ISO 9564
PBF1 bloc PIN de format 1 conforme à l'ISO 9564
R valeur aléatoire émise par l'entité X
X
S /P clé publique/secrète associée à une entité X devant être utilisée avec un algorithme asymétrique
X X
TP nom distinctif de la tierce partie de confiance
T période de validité des justificatifs d'identité
val
T timbre à date émis par une entité X
X
Z//Z* concaténation des chaînes binaires Z et Z*
<>/<> séparation des champs
4.2 Processus
Les identificateurs de processus sont en lettres majuscules:
EA authentification d'entité
KE échange de clé
MA authentification du message
ME chiffrement/déchiffrement de message
PV vérification du PIN
TC certification de transaction
4.3 Liste d'option
Les identificateurs d'option sont en lettres minuscules:
a asymétrique
s symétrique
réciproque
m
t degré d'actualité des données
© ISO
4.4 Fonctions
Les identificateurs de fonction sont en lettres minuscules et en italique:
c comparer
d déchiffrer
e chiffrer
g générer une valeur aléatoire
h tronçonner
m authentifier un message
o appliquer une fonction unidirectionnelle
s signer
v vérifier
La notation de la fonction est utilisée de paire avec une indication des valeurs de clés et entités.
c(Y,Z) comparaison de deux chaînes binaires Y et Z, le résultat étant un code d'état
dK(Z) déchiffrement des données Z par un algorithme symétrique utilisant la clé K
dS (Z) déchiffrement des données Z par un algorithme asymétrique utilisant la clé secrète S
X
X
eK(Z) chiffrement des données Z par un algorithme symétrique utilisant la clé K
eP (Z) chiffrement des données Z par un algorithme asymétrique utilisant la clé publique P
X
X
R=g() génération d'une valeur aléatoire R
h(Z) application d'une fonction unidirectionnelle résistante à la collision qui fait correspondre un élément
de données Z à une valeur de sortie de longueur fixe utilisant les propriétés publiques
(tronçonnage), le résultat du tronçonnage étant h(Z)
mK(Z) génération d'un code d'authentification du message (MAC-ing) utilisant un algorithme symétrique
comme fonction unidirectionnelle avec la clé secrète K, le résultat étant un code d'authentification
du message MAC (Message Authentication Code)
vK(MAC) vérification d'un MAC utilisant un algorithme symétrique comme fonction unidirectionnelle avec la
clé secrète K, le résultat étant un code d'état
oK(Z) application d'une fonction unidirectionnelle qui fait correspondre les données Z à une valeur de
sortie de longueur fixe utilisant un algorithme avec la clé secrète K
sS (Z) application d'une signature numérique aux données Z utilisant la clé secrète S (signature), le
X X
résultat étant une signature Sig
vP (Sig) processus de vérification de Sig utilisant la clé publique P , le résultat étant un code d'état
X
X
4.5 Signatures numériques
La transmission de Z non signé (données à transférer) est obligatoire sauf lorsqu'un schéma de signature
numérique avec reprise de message est utilisé (voir ISO/CEI 9796). Dans ce cas, les données signées sont
composées de sorte que leurs propriétés structurelles puissent être vérifiées et que Z soit récupéré à partir de ces
données. Pour cela, Z doit être suffisamment court et l'algorithme asymétrique doit être réversible.
© ISO
Dans la présente partie de l'ISO 10202, la notation est utilisée pour la signature avec reprise de données et
sS (Z)
A
la signature utilisant une fonction de tronçonnage. Cela signifie que sS (Z) peut représenter sS (Z) ou sS (h(Z))//Z
A A A
où h(Z) peut indiquer Z.
4.6 Format de message de sécurité
Les messages de sécurité sont des commandes logiques des fonctions de sécurité normalisées. Les informations
contenues dans ces messages peuvent être transmises dans le champ associé d'une ICC d'un message 8583 ou
interprétées par un SAM ou une application afin de générer les commandes appropriées pour les cartes à circuit
intégré (ICC).
Un message de sécurité est identifié de la façon suivante:
• indicateur de message identificateur de message logique; concaténation des éléments suivants:
processus: identificateur de processus (paragraphe 4.2)
liste d'option: liste des identificateurs d'option (paragraphe 4.3)
numéro de message séquentiel
numéro:
EXEMPLE KEss1
Le message de sécurité contient un ou plusieurs sous-champs de message de sécurité. Les sous-champs
obligatoires sont en caractères gras. Le sous-champ < operation > (opération) apparaît au moins une fois dans
chaque message.
• sous-champs de message < initiator >  (initiateur)
< respondent >  (répondeur)
< operation >  (opération)
< operation >
< initiator >: nom distinctif de l'entité source
< respondent >: nom distinctif de l'entité de destination
< operation >= < Z >  < KID >  < f(Z) >
< Z >: champ de données facultatif
< KID >: identificateur de clé
< f(Z) >: résultat de l'application de la fonction f aux données Z (paragraphe 4.4)
EXEMPLE A  B  KID  KID  eK*(KID )  eK(K*)
K K* K*
5 Correspondances entre les fonctions de sécurité et les types de processus
Une correspondance entre les fonctions de sécurité telles que définies dans les parties 2, 4 et 6 de l'ISO 10202 et
l'ensemble des types de processus est illustrée dans le Tableau 1.
© ISO
Tableau 1 — Correspondance entre les fonctions de sécurité et les types de processus
FONCTION DE SÉCURITÉ TYPE DE PROCESSUS CLÉ
Fabrication de l'ICC
Fabrication Chargement de la clé initiale kMprd
M-P
Encartage et initialisation Chargement de la clé initiale kEprd
E-P
Personnalisation de l'ICC
Personnalisation Chargement de la clé initiale kIctl
I-C
Initialisation de la session de la carte
Contrôle de compatibilité IC Aucun processus de chiffrement
Mise à jour des paramètres CDF
Activation/désactivation/réactivation/fin Échange de clé KE kIctl
I-C
CDF
Échange de clé KE kIctl
I-C
Allocation ADF
Authentification et vérification propres au CDF
1)
Vérification du titulaire de la carte Vérification du PIN PV kIenc
I-C
Authentification statique de CDF Authentification de l'entité EA kIaut
I
Authentification dynamique de CDF Authentification de l'entité EA kIaut
C
Authentification dynamique de l'hôte Authentification de l'entité EA kIaut
I-C
émetteur
Traitement de la transaction CDF
Autorisation de transaction Authentification du message MA kImac
I-C
1)
Confidentialité des données Chiffrement de message ME kIenc
I-C
Certification de transaction Certification de transaction TC kIcer
I-C
Sélection ADF
Sélection ADF Aucun processus de chiffrement
Mise à jour des paramètres ADF
Chargement ADF KActl Échange de clé KE kIkex
A-C I-A
Activation/désactivation/réactivation/fin Échange de clé KE kAct
lA-C
ADF
Authentification et vérification propres à l'ADF
2)
Vérification du titulaire de la carte Vérification du PIN PV kAenc
A-C
Authentification statique de l'ADF Authentification de l'entité EA kAaut
A
Authentification dynamique de l'ADF Authentification de l'entité EA kAaut
C
Authentification du SAM Authentification de l'entité EA kAaut
S-C
Authentification du prestataire Authentification de l'entité EA kAaut
A-C
Traitement de la transaction ADF
Autorisation de transaction Authentification du message MA kAmac
A-C
2)
Confidentialité des données Chiffrement de message ME kAenc
A-C
Certification de transaction Certification de transaction TC kAcer
A-C
Fin de session de la carte
Fin de session de la carte Aucun processus de chiffrement
1)
Ces clés peuvent être, au choix des émetteurs, générées séparément ou dérivées.
2)
Ces clés peuvent être, au choix des fournisseurs, générées séparément ou dérivées.
© ISO
6 Spécifications de processus
Le présent article spécifie les processus disponibles pour les différentes fonctions de sécurité. Chaque processus
peut être utilisé seul ou parallèlement à d'autres processus si nécessaire.
Chaque processus permet l'utilisation de plusieurs options offrant une protection contre différentes menaces telles
que l'interception, l'usurpation d'identité, le rejeu, la manipulation ou la répudiation. Il convient de sélectionner les
options en fonction de l'analyse du risque provenant des menaces d'un environnement particulier. L'annexe H
apporte d'autres indications sur cette partie.
Certains processus incluent des options qui fournissent un degré d'actualité des données lorsqu'il est nécessaire de
s'assurer qu'un message est unique et/ou émis à un moment spécifique. L'annexe E explique les différentes façons
d'obtenir un degré d'actualité des données.
Le degré d'actualité des données est essentiel pour l'authentification d'entité; la combinaison avec un tel processus
garantit automatiquement le degré d'actualité des données.
Si le processus de chiffrement est fondé sur un algorithme symétrique, la clé secrète nécessaire au processus doit
avoir été établie au niveau des deux nœuds participants. Si cette clé est partagée entre plus de deux entités
appartenant à un groupe, il est cryptographiquement impossible de faire la distinction entre ces entités.
Si le processus de chiffrement est fondé sur un algorithme asymétrique, les informations concernant la clé doivent
être générées au niveau de chaque nœud. La clé secrète doit être stockée de manière sûre au niveau du nœud, et
les informations publiques correspondantes doivent être certifiées par une tierce partie de confiance fournissant des
certificats (voir annexe A).
Tous les éléments de données d'un message doivent être connus au niveau du nœud de destination afin que
l'étape suivante du processus puisse être exécutée. Si un élément de données est généré dynamiquement au
cours du processus, sa transmission est obligatoire. S'il est déjà connu au niveau du nœud de destination, sa
transmission peut être omise.
Les opérations et les paramètres apparaissant en caractères gras sont obligatoires. Tous les éléments obligatoires
sont repris dans les flèches des figures. D'autres étapes décrites dans les rôles peuvent ne pas toujours
correspondre directement aux étapes décrites dans cette figure.
6.1 Processus 1: échange de clé (KE - Key Exchange)
La transmission électronique sûre d'une clé secrète K ou S vers ou à partir d'une carte à circuit intégré (ICC) ou
B
d'un SAM doit être effectuée conformément à l'une des options décrites dans le présent paragraphe. On suppose
que l'initiateur et le répondeur ont établi une liaison de chiffrement.
La clé secrète qui doit être échangée est toujours émise de A vers B, sauf lorsque la clé est réciproquement
développée par les deux parties impliquées dans la communication.
6.1.1 KE-symétrique-symétrique
Échange d'une clé secrète à utiliser avec un algorithme symétrique au moyen d'un algorithme symétrique
K*
(Figure 1).
KEss1 = A | B | KID | KID | eK*(KID ) | eK(K*)
K K* K*
K clé secrète commune
K* clé secrète échangée
KID identificateur de clé pour la clé K
K
KID identificateur de clé pour la clé K*
K*
© ISO
A B
S1 eK(K*)
S2 eK*(KID )
K*
eK(K*)
S3 KEss1
KID |eK*(KID )
K* S4
K* K*
KID S5
K*
c(KID ) S6
K*
Figure 1 — Échange de clé symétrique symétrique
S1 A calcule eK(K*)
S2 Option 1: A calcule eK*(KID )
K
*
S3 A émet KEss1 vers B
S4 B calcule dK(eK(K*)) pour récupérer K*
S5 Option 1: B calcule dK*(eK*(KID )) pour récupérer KID
K* K*
S6 Option 1: B vérifie l'exactitude de K* en comparant KID
K*
NOTE 1 Le déchiffrement de l'étape 5 pourrait être remplacé par une comparaison de l'identificateur KID de la clé chiffrée.
K*
S5 Option 1: B calcule eK*(KID )
K*
B eK*(KID )
S6 Option 1: compare
K*
NOTE 2 Sinon, une fonction unidirectionnelle peut être utilisée en option 1.
S2 Option 1: A calcule oK*(KID )
K*
S5 Option 1: B calcule oK*(KID )
K*
S6 Option 1: B compare oK*(KID )
K*
6.1.2 KE-symétrique-symétrique-réciproque-degré d'actualité des données
Génération réciproque d'une clé secrète K* à utiliser avec un algorithme symétrique au moyen d'un algorithme
symétrique (Figure 2). L'authentification de l'entité A est implicite.
KEssmt1 = B | A | KID | R
K* B
KEssmt2 = A | B | KID | eK*(KID ) | eK(R )
K K* A
K
clé secrète commune
K*
clé secrète générée réciproquement
KID identificateur de clé pour la clé K
K
KID K*
identificateur de clé pour la clé
K*
© ISO
A B
R R =g()
S1
B
B
KEssmt1 S2
R =g()
S3
A
eK(R )
S4
A
K*
S5
S6 eK*(KID )
K*
eK(R )
S7 KEssmt2
A
KID |eK*(KID ) R
S8
K* K* A
K*
S9
KID S10
K*
c(KID ) S11
K*
Figure 2 — Échange de clé symétrique symétrique réciproque degré d'actualité des données
S1 B génère une valeur aléatoire R
B
B A
S2 émet KEssmt1 vers
S3 A génère une valeur aléatoire R
A
A eK(R )
S4 calcule
A
S5 A calcule eR (R ) pour récupérer K*
A B
S6 Option 1: A calcule eK*(KID )
K*
A B
S7 émet KEssmt2 vers
S8 B calcule dK(eK(R )) pour récupérer R
A A
B eR (R ) pour récupérer K*
S9 calcule
A B
S10 Option 1: B calcule dK*(eK*(KID )) pour récupérer KID
K* K*
S11 Option 1: B vérifie l'exactitude de K* en comparant KID
K*
NOTE 1 Le déchiffrement de l'étape 10 pourrait être remplacé par une comparaison de l'identificateur KID de la clé
K*
chiffrée.
S10 Option 1: B calcule eK*(KID )
K*
S11 Option 1: B compare eK*(KID )
K*
NOTE 2 Sinon, une fonction unidirectionnelle peut être utilisée en option 1.
S6 Option 1: A calcule oK*(KID )
K*
S10 Option 1: B calcule oK*(KID )
K*
S11 Option 1: B compare oK*(KID )
K*
6.1.3 KE-symétrique-asymétrique
Échange d'une clé secrète S à utiliser avec un algorithme asymétrique au moyen d'un algorithme symétrique
B
(Figure 3).
© ISO
L'entité utilisant cette option pour charger une clé secrète dans une carte à circuit intégré pour la signature
numérique doit être responsable de l'authenticité de la clé publique correspondante. La propriété de non-répudiation
sera perdue si la connaissance de la clé secrète est partagée.
KEsa1 = A | B | KID | KID | CID | Cert | eK(S )
K P B B B
B
K clé secrète commune
S /P paire de clés secrète/publique échangée pour l'entité B
B B
KID identificateur de clé pour la clé K
K
KID identificateur de clé pour la paire de clés S /P
P B B
B
CID identificateur de certificat pour Cert
B B
A B
S1 Cert
B
S2 eK(S )
B
S3 KEsa1 Cert |eK(S )
B B
S S4
B
v(Cert ) S5
B
P
B
v(S /P ) S6
B B
Figure 3 — Échange de clé symétrique asymétrique
S1 A obtient Cert
B
S2 A calcule eK(S )
B
S3 A émet KEsa1 vers B
S4 B calcule dK(eK(S )) pour récupérer S
B B
S5 Option 1: B valide P en vérifiant Cert
B B
S6 Option 2: B vérifie l'exactitude de la paire de clés S /P en vérifiant dS (eP (B))=B
B B B B
6.1.4 KE-asymétrique-symétrique
Échange d'une clé secrète K à utiliser avec un algorithme symétrique au moyen d'un algorithme asymétrique
(Figure 4).
Si la signature est effectuée à l'aide d'une technique avec reprise des données, la transmission de la clé K devient
facultative.
KEas1 = B | A | KID | CID | Cert
P B B
B
KEas2 = A | B | KID | CID | Cert | KID | eK(KID ) | eP (sS (K))
P A A K K
B A
A
S /P paire de clés secrète/publique de l'entité A
A A
S /P paire de clés secrète/publique de l'entité B
B B
K clé secrète échangée
© ISO
identificateur de clé pour la clé
KID K
K
KID identificateur de clé pour la paire de clés S /P
P A A
A
KID identificateur de clé pour la paire de clés S /P
P B B
B
CID identificateur de certificat pour Cert
A A
CID identificateur de certificat pour Cert
B B
A B
KEas1 S1
Cert
S2 v(Cert )
B
B
P
B
eP (sS (K))
S3
B A
S4 eK(KID )
K
S5 KEas2
eP (sS (K))
v(Cert ) S6
B A
A
KID |eK(KID )
P
K K A
K
S7
KID S8
K
c(KID ) S9
K
Figure 4 — Échange de clé asymétrique symétrique
S1 Option 1 : B émet KEas1
S2 Option 1: A valide P en vérifiant Cert
B B
S3 A calcule eP (sS (K))
B A
S4 Option 2: A calcule eK(KID )
K
S5 A émet KEas2
S6 Option 3: B valide P en vérifiant Cert
A A
S7 B calcule vP (dS (eP (sS (K)))) pour récupérer K
A B B A
S8 Option 2: B calcule dK(eK(KID )) pour récupérer KID
K K
S9 Option 2: B vérifie l'exactitude de K en comparant KID
K
NOTE 1 Le déchiffrement de l'étape 8 pourrait être remplacé par une comparaison de l'identificateur de clé chiffrée KID .
K
S8 Option 2: B calcule eK(KID )
K
S9 Option 2: B compare eK(KID )
K
NOTE 2 Sinon, une fonction unidirectionnelle peut être utilisée en option 2.
S4 Option 2: A calcule oK(KID )
K
S8 Option 2: B calcule oK(KID )
K
S9 Option 2: B compare oK(KID )
K
© ISO
6.1.5 KE-asymétrique-symétrique-réciproque
Génération réciproque d'une clé secrète K à utiliser avec un algorithme symétrique au moyen d'un algorithme
asymétrique (Figure 5). L'algorithme f doit répondre aux relations suivantes où b est une base publique:
P = f(b,S )
x x
f(P ,S ) = f(P ,S )
x y y x
L'authentification de l'entité doit avoir lieu avant qu'une clé puisse être établie à l'aide de cette technique.
KEasm1 = B | A | KID | P
P R
R B
B
KEasm2 = A | B | KID | P | KID |eK(KID )
P R K K
R A
A
S /P paire de clés secrète/publique aléatoire de l'entité A
R R
A A
S /P paire de clés secrète/publique aléatoire de l'entité B
R R
B B
K clé secrète générée réciproquement
KID identificateur de clé pour la clé K
K
KID identificateur de clé pour la paire de clés S /P
P R R
R A A
A
KID identificateur de clé pour la paire de clés S /P
P R R
R B B
B
A B
S =g() S1
RB
P =f(b,S ) S2
RB RB
P
KEasm1 S3
RB
S4 S =g()
RA
S5 P =f(b,S )
RA RA
S6 K
S7 eK(KID )
K
S8 KEasm2
P
RA
KID |eK(KID ) K S9
K K
KID S10
K
c(KID ) S11
K
Figure 5 — Échange de clé asymétrique symétrique réciproque
S1 B génère S = g()
R
B
S2 B calcule P = f(b, S )
R R
B B
S3 B émet KEasm1
S4 A génère S = g()
R
A
S5 A calcule P = f(b, S )
R R
A A
© ISO
S6 A calcule f(P ,S ) pour récupérer K
R R
B A
S7 Option 1: A calcule eK(KID )
K
S8 A émet KEasm2
S9 B calcule f(P , S ) pour récupérer K
R R
A B
S10 Option 1: B calcule dK(eK(KID )) pour récupérer KID
K K
S11 Option 1: B vérifie l'exactitude de K en comparant KID
K
NOTE Sinon, une fonction unidirectionnelle peut être utilisée en option 1.
S7 Option 1: A calcule oK(KID )
K
S10 Option 1: B calcule oK(KID )
K
S11 Option 1: B compare oK(KID )
K
6.1.6 KE-asymétrique-symétrique-réciproque-degré d'actualité des données
Génération réciproque d'une clé secrète K à utiliser avec un algorithme symétrique au moyen d'un algorithme
asymétrique (Figure 6). L'authentification de l'entité A est implicite.
= | | | | |
KEasmt1 B A KID CID Cert R
P B B
B
B
KEasmt2 = A | B | KID | CID | Cert | KID | eK(KID ) | eP (sS (R ))
P A A K K B A A
A
S /P paire de clés secrète/publique de l'entité A
A A
S /P paire de clés secrète/publique de l'entité B
B B
K clé secrète générée réciproquement
KID identificateur de clé pour la clé K
K
KID identificateur de clé pour la paire de clés S /P
P A A
A
KID identificateur de clé pour la paire de clés S /P
P B B
B
CID identificateur de certificat pour Cert
A A
CID identificateur de certificat pour Cert
B B
© ISO
A B
R =g() S1
B
R
KEasmt1 S2
B
S3 v(Cert )
B
P
B
S4 R =g()
A
S5 eP (sS (R ))
B A A
S6 K
S7 eK(KID )
K
eP (sS (R ))
S8 KEasmt2
B A A
KID |eK(KID ) v(Cert )
S9
K K A
P
A
R
S10
A
K
S11
KID S12
K
c(KID ) S13
K
Figure 6 — Échange de clé asymétrique symétrique réciproque degré d'actualité des données
S1 B génère une valeur aléatoire R
B
B
S2 émet KEasmt1
S3 Option 1: A valide P en vérifiant Cert
B B
A R
S4 génère une valeur aléatoire
A
S5 A calcule eP (sS (R ))
B A A
S6 A calcule eR (R ) pour récupérer K
A B
S7 Option 2: A calcule eK(KID )
K
S8 A émet KEasmt2
B P Cert
S9 Option 3: valide en vérifiant
A A
S10 B calcule vP (dS (eP (sS (R )))) pour récupérer R
A B B A A A
B eR (R ) pour récupérer K
S11 calcule
A B
S12 Option 2: B calcule dK(eK(KID )) pour récupérer KID
K K
S13 Option 2: B vérifie l'exactitude de K en comparant KID
K
NOTE Sinon, une fonction unidirectionnelle peut être utilisée en option 2.
S7 Option 1: A calcule oK(KID )
K
S12 Option 2: B calcule oK(KID )
K
S13 Option 2: B compare oK(KID )
K
6.1.7 KE-asymétrique-asymétrique
Échange d'une clé secrète S à utiliser avec un algorithme asymétrique au moyen d'un algorithme asymétrique
B*
(Figure 7).
© ISO
L'entité utilisant cette option afin de charger une clé secrète dans une carte à circuit intégré pour la signature
numérique doit être responsable de l'authenticité de la clé publique correspondante.
KEaa1 = B | A | KID | CID | Cert
P B B
B
KEaa2 = A | B | KID | CID | Cert | KID | CID | Cert | eP (S (S ))
P A A P B* B* B A B *
A B*
S /P paire de clés secrète/publique de l'entité A
A A
S /P paire de clés secrète/publique de l'entité B
B B
S /P paire de clés secrète/publique échangée de l'entité B
B* B*
KID identificateur de clé pour la paire de clés S /P
P A A
A
KID identificateur de clé pour la paire de clés S /P
P B B
B
identificateur de certificat pour
CID Cert
A A
CID identificateur de certificat pour Cert
B B
CID identificateur de certificat pour Cert
B B*
*
A B
KEaa1 S1
Cert
S2 v(Cert )
B*
B*
P
B
S3 eP (sS (S ))
B A B*
S4 Cert
B
*
S5 KEaa2
Cert |eP (sS (S )) v(Cert ) S6
B* B A B* A
P
A
S
S7
B*
v(Cert ) S8
B*
P
B*
v(S /P ) S9
B* B*
Figure 7 — Échange de clé asymétrique asymétrique
S1 Option 1: B émet KEaa1
S2 Option 1: A valide P en vérifiant Cert
B B
S3 A calcule eP (sS (S ))
B A B*
S4 A obtient Cert
B
*
S5 A émet KEaa2
S6 Option 2: B valide P en vérifiant Cert
A A
S7 B calcule vP (dS (eP (sS (S )))) pour récupérer S
A B B A B* B*
S8 Option 3: B valide P en vérifiant Cert
B* B*
S9 Option 3: B vérifie l'exactitude de la paire de clés S /P en vérifiant dS (eP (B)) = B
B* B* B B*
*
© ISO
6.2 Processus 2: authentification de l'entité (EA - Entity Authentication)
La vérification d'un nœud de chiffrement doit être effectuée conformément à l'une des options décrites dans le
présent paragraphe. On suppose que l'initiateur et le répondeur ont établi une liaison de chiffrement. L'un des
nœuds est une carte à circuit intégré ou un SAM.
Le répondeur B est authentifié par l'initiateur A, sauf lorsque l'objectif est l'authentification réciproque.
Le nœud devant être authentifié prouve son identité en montrant sa connaissance d'une clé secrète.
À l'exception de 6.2.3, le degré d'actualité des données et un schéma question/réponse sont inhérents aux options
d'authentification de l'entité.
L'authentification de l'entité elle-même ne garantit pas que les messages suivants proviennent de la même source.
La prescription suivante est suffisante : la question doit être générée en-dehors du contrôle de l'entité authentifiée.
Selon la mise en application, la question peut être une simple contre valeur obtenue à partir d'une entité
intermédiaire ayant la confiance de l'entité impliquée dans la question.
6.2.1 EA-symétrique-degré d'actualité des données
L'authentification de l'entité B au moyen d'un schéma question/réponse utilisant un algorithme symétrique
(Figure 8).
EAst1 = A | B | KID | R
K A
B
EAst2 = B | A | eK (R )
B A
K clé de dérivation secrète
K clé secrète (dérivée) unique pour l'entité B
B
identificateur de clé pour la clé
KID K
K B
B
A B
S1 R =g()
A
S2 EAst1 R
A
K S3
B
eK (R ) S4
B A
eK (R ) EAst2 S5
B A
S6 K
B
S7 eK (R )
B A
S8 c(eK (R ))
B A
Figure 8 — Authentification d'entité symétrique degré d'actualité des données
S1 A génère une valeur aléatoire R
A
S2 A émet EAst1 vers B
S3 B obtient K
B
S4 B calcule eK (R )
B
A
S5 B émet EAst2 vers A
S6 A obtient K ou calcule K = eK(B)
B B
S7 A calcule eK (R )
B A
S8 A vérifie eK (R )
B A
© ISO
NOTE 1 La protection contre une attaque par réflexion est obtenue en utilisant des clés unidirectionnelles qui sont générées
par un processus de dérivation. L'utilisation d'une technique de chiffrement pour dériver la clé K permet une séparation au
B
niveau de l'entité B.
Lorsqu'une clé secrète commune K est utilisée pour l'authentification d'entité, une attaque par réflexion est empêchée en
concaténant l'identificateur d'entité A à la question.
EAst1 = A | B | KID | R
K A
EAst2 = B | A | eK (R //A)
B A
S7 A calcule eK (R //A)
B A
S8 A vérifie eK (R //A)
B A
NOTE 2 Une protection contre une attaque par texte en clair choisi peut être obtenue par chiffrement de la question avec la
clé secrète dérivée unique K de l'entité A.
A
EAst1 = A | B | KID | eK (R )
K A A
EAst2 = B | A | eK (R )
B A
S1 Option 1: A calcule K = eK(A)
A
S2 A génère une valeur aléatoire R
A
S3 A calcule eK (R )
A A
S4 A émet EAst1 vers B
S5 B calcule K = eK(A)
A
S6 B calcule dK (eK (R )) pour récupérer R
A A A A
S7 B obtient K
B
S8 B calcule eK (R )
B A
S9 B émet EAst2 vers A
S10 A obtient K ou calcule K = eK(B)
B B
S11 A calcule eK (R )
B A
S12 A vérifie eK (R )
B A
NOTE 3 Lorsqu'une valeur de paramètre spécifique au message (par exemple, un timbre à date T ) est considérée comme
B
un agent de dissuasion suffisamment sûr contre le rejeu, l'authentification pourrait être réalisée par un message unique émis
de B vers A.
EAst1 = B | A | KID | eK (T )
K B B
B
S1 B obtient K
B
S2 B obtient T
B
S3 B calcule eK (T )
B B
S4 B émet EAst1 vers A
S5 A obtient K ou calcule K = eK(B)
B B
S6 A calcule dK (eK (T )) pour récupérer T
B B B B
S7 A vérifie T
B
© ISO
NOTE 4 La comparaison de la réponse à la question reçue de B avec le résultat attendu calculé par l'initiateur A pourrait
être remplacée par la comparaison de la réponse à la question déchiffrée reçue de B, la question étant générée par l'initiateur
A.
S7 A calcule dK (eK (R )) pour récupérer R
B B A A
S8 A vérifie R
A
NOTE 5 Sinon, une fonction unidirectionnelle peut être utilisée.
S4 B calcule oK (R )
B A
S7 A calcule oK (R )
B A
S8 A vérifie oK (R )
B A
6.2.2 EA-symétrique-degré d'actualité des données-réciproque
Authentification réciproque des entités et au moyen d'un schéma question/réponse utilisant un algorithme
A B
symétrique (Figure 9).
EAstm1 = A | B | KID | R
K A
B
EAstm2 = B | A | KID | eK (R ) | R
K B A B
A
EAstm3 = A | B | eK (R )
A B
K clé de dérivation secrète
K clé secrète (dérivée) uniq
...