ISO 9735-5:1999
(Main)Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
Échange de données informatisé pour l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (Numéro de version de syntaxe: 4) — Partie 5: Règles de sécurité pour EDI par lots (authenticité, intégrité et non-répudiation de l'origine)
General Information
Relations
Frequently Asked Questions
ISO 9735-5:1999 is a standard published by the International Organization for Standardization (ISO). Its full title is "Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)". This standard covers: Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin)
ISO 9735-5:1999 is classified under the following ICS (International Classification for Standards) categories: 35.240.60 - IT applications in transport; 35.240.63 - IT applications in trade. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 9735-5:1999 has the following relationships with other standards: It is inter standard links to PSIST ISO 9735:1996, OSIST ISO 9735-5:2004, ISO 9735-5:2002, ISO 9735:1988/Amd 1:1992, ISO 9735:1988. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 9735-5:1999 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 9735-5
First edition
1999-04-01
Electronic data interchange for
administration, commerce and transport
(EDIFACT) — Application level syntax rules
(Syntax version number: 4) —
Part 5:
Security rules for batch EDI (authenticity,
integrity and non-repudiation of origin)
Échange de données informatisées pour l’administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe au niveau de l’application
(Numéro de version de syntaxe: 4) —
Partie 5: Règles de sécurité pour EDI par lots (authenticité, intégrité et
non-répudiation de l’origine)
A
Reference number
Page
Contents
1 Scope 1
2 Conformance 1
3 Normative references 1
4 Definitions 2
5 Rules for the use of security header and trailer segment groups
for batch EDI 2
6 Rules for the use of interchange and group security header and
trailer segment groups for batch EDI 9
Annex A: Definitions 12
Annex B: Syntax service directories (segments, composite data
elements and simple data elements) 13
Annex C: EDIFACT security threats and solutions 29
Annex D: How to protect an EDIFACT structure 32
Annex E: Message protection examples 34
Annex F: Filter functions for UN/EDIFACT character set repertoires
A and C 41
Annex G: Service code directory 43
Annex H: Security services and algorithms 44
Annex I: Bibliography 50
© ISO 1999
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
©
ISO ISO 9735-5:1999(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 collabo-
rates 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.
This part of ISO 9735 was prepared by the UN/ECE Trade Division (as
UN/EDIFACT) and was adopted, under a special "fast-track procedure", by
Technical Committee ISO/TC 154, Documents and data elements in
administration, commerce and industry.
Whereas this part supersedes the earlier publications, and shall use a
version number of “4” in the mandatory data element 0002 (Syntax version
number) in the segment UNB (Interchange header), interchanges
continuing to use the syntax defined in the earlier published versions shall
use the following Syntax version numbers, in order to differentiate them
from each other and from this part:
ISO 9735:1988 — Syntax version number: 1
ISO 9735:1988 (amended and reprinted in 1990) — Syntax version
number: 2
ISO 9735:1988 (amended and reprinted in 1990) plus
Amendment 1:1992 — Syntax version number: 3
ISO 9735 consists of the following parts, under the general title Electronic
data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number: 4) :
— Part 1: Syntax rules common to all parts, together with the syntax
service directories for each of the parts
— Part 2: Syntax rules specific to batch EDI
— Part 3: Syntax rules specific to interactive EDI
— Part 4: Syntax and service report message for batch EDI (message
type - CONTRL)
— Part 5: Security rules for batch EDI (authenticity, integrity and non-
repudiation of origin)
iii
©
— Part 6: Secure authentication and acknowledgement message
(message type - AUTACK)
— Part 7: Security rules for batch EDI (confidentiality)
— Part 8: Associated data in EDI
— Part 9: Security key and certificate management message (message
type - KEYMAN)
Further parts may be added in the future.
Annexes A and B form an integral part of this part of 9735. Annexes C to I
are for information only.
iv
©
ISO ISO 9735-5:1999(E)
Introduction
This part of ISO 9735 includes the rules at the application level for the
structuring of data in the interchange of electronic messages in an open
environment, based on the requirements of either batch or interactive
processing. These rules have been agreed by the United Nations
Economic Commission for Europe (UN/ECE) as syntax rules for Electronic
Data Interchange for Administration, Commerce and Transport (EDIFACT)
and are part of the United Nations Trade Data Interchange Directory
(UNTDID) which also includes both batch and interactive Message Design
Guidelines.
Communications specifications and protocols are outside the scope of this
part of ISO 9735.
This is a new part, which has been added to ISO 9735. It provides an
optional capability of securing batch EDIFACT structures i.e. messages,
packages, groups or interchange.
v
©
INTERNATIONAL STANDARD ISO ISO 9735-5:1999(E)
Electronic data interchange for administration, commerce and
transport (EDIFACT) — Application level syntax rules — (Syntax
version number: 4)
Part 5:
Security rules for batch EDI (authenticity, integrity and non-repudiation
of origin)
1 Scope
This part of ISO 9735 specifies syntax rules for EDIFACT security. It provides a method to address
message/package level, group level and interchange level security for authenticity, integrity and non-repudiation of
origin, in accordance with established security mechanisms.
2 Conformance
Conformance to a standard means that all of its requirements, including all options, are supported. If all options are
not supported, any claim of conformance shall include a statement which identifies those options to which
conformance is claimed.
Data that is interchanged is in conformance if the structure and representation of the data conform to the syntax
rules specified in this part of ISO 9735.
Devices supporting this part of ISO 9735 are in conformance when they are capable of creating and/or interpreting
the data structured and represented in conformance with this part of ISO 9735.
Conformance to part of ISO 9735 shall include conformance to Part 1, Part 2 and Part 8 of ISO 9735.
When identified in this part of ISO 9735, provisions defined in related standards shall form part of the conformance
criteria.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of
ISO 9735. At the time of publication, the editions indicated were valid. All standards are subject to revision, and
parties to agreements based on this part of ISO 9735 are encouraged to investigate the possibility of applying the
most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently
valid International Standards.
Information processing systems — Open Systems Interconnection — Basic Reference Model —
ISO 7498-2:1989,
Part 2: Security architecture.
ISO/IEC 9594-8:1995, Information technology — Open Systems Interconnection — The Directory: Authentication
framework.
©
ISO
ISO 9735-1:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 1: Syntax rules common to all parts, together with syntax
directories for each of the parts.
ISO 9735-2:1998, Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 2: Syntax rules specific to batch EDI.
Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
ISO 9735-6:1998,
level syntax rules (Syntax version number: 4) — Part 6: Secure authentication and acknowledgement message
(message type — AUTACK).
1)
ISO 9735-7:— , Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
level syntax rules (Syntax version number: 4) — Part 7: Security rules for batch EDI (confidentiality).
Electronic data interchange for administration, commerce and transport (EDIFACT) — Application
ISO 9735-8:1998,
level syntax rules (Syntax version number: 4) — Part 8: Associated data in EDI.
Information technology — Open Systems Interconnection — Security frameworks for open
ISO/IEC 10181-2:1996,
systems: Authentication framework.
ISO/IEC 10181-4:1997, Information technology — Open Systems Interconnection — Security frameworks for open
systems: Non-repudiation framework.
Information technology — Open Systems Interconnection — Security frameworks for open
ISO/IEC 10181-6:1996,
systems: Integrity framework.
4 Definitions
For the purposes of this part of ISO 9735, the definitions in ISO 9735-1:1998, annex A apply.
5 Rules for the use of security header and trailer segment groups for batch EDI
5.1 Message/package level security - integrated message/package security
The security threats relevant to message/package transmission and the security services which address them are
described in annexes C and D.
This section describes the structure of EDIFACT message/package level security.
Security services addressed in this part of ISO 9735 shall be provided by the inclusion of security header and trailer
segment groups after the UNH and before the UNT, in a way which shall be applied to any existing message, or
after the UNO and before the UNP, for any existing package.
________________
1) To be published.
©
ISO
5.1.1 Security header and trailer segment groups
Figure 1 describes an interchange showing security at message level.
INTERCHANGE
Either : Only Or : Only
UN A UN B UNZ
GR OU P(S) M ESS AG E(S)/
PA CK AG E(S)
M essage M essage
UNG MESSAGE UNE
Security Security
header tra iler
UN H M ESS AG E BO DY UN T
seg m ent seg m ent
group (s) group (s)
Figure 1 - Interchange showing security at message level (schematic)
Figure 2 describes an interchange showing security at package level.
INTERCHANGE
Either : Only Or : Only
UNA UNB UNZ
G R O U P(S) M ESS A G E(S)/
PACKA G E(S)
PACKAGE Package
UNG Package UNE
Security Security
header trailer
UNO OBJECT UNP
segm ent segm ent
group(s) group(s)
Figure 2 - Interchange showing security at package level (schematic)
©
ISO
5.1.2 Security header and trailer segment groups structure
TAG Name S R
UNH Message Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+ I
USC Certificate M 1 I I
USA Security Algorithm C 3 I I
USR Security Result C 1 --------+
Message body
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1 I
USR Security Result C 1 ----+
UNT Message Trailer M 1
Table 1 - Security header and security trailer segment groups segment table (message level security)
TAG Name S R
UNO Object Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+ I
USC Certificate M 1 I I
USA Security Algorithm C 3 I I
USR Security Result C 1 --------+
Object
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1 I
USR Security Result C 1 ----+
UNP Object Trailer M 1
Table 2 - Security header and security trailer segment groups segment table (package level security)
Note: UNH message header, UNT message trailer, UNO object header and UNP object trailer are specified in
Part 1 of ISO 9735. They are not described further in this Part.
The complete directory specification of the segments and data elements may be found in annex B.
5.1.3 Data segment clarification
Segment Group 1: USH-USA-SG2 (security header group)
A group of segments identifying the security service and security mechanisms applied and containing the data
necessary to carry out the validation calculations.
There may be several different security header segment groups within the same message/package, if different
security services are applied to the message/package (e. g. integrity and non-repudiation of origin) or if the same
security service is applied by several parties.
USH, Security header
A segment specifying a security service applied to the message/package in which the segment is included.
The parties involved in the security service (security elements originator and security elements recipient), may be
identified in this segment, unless they are unambiguously identified by means of certificates (USC segment) when
asymmetric algorithms are used.
©
ISO
Security identification details composite data element (S500) shall be used in USH segment either:
- if symmetric algorithms are used, or
- if asymmetric algorithms are used and when two certificates are present, in order to distinguish between the
originator and the recipient certificates
In this latter case, the identification of the party in S500 (any of the data elements S500/0511, S500/0513,
S500/0515, S500/0586) shall be the same as the identification of the party, qualified as "certificate owner" in one
of the S500 present in the USC segment in segment group 2, and data element S500/0577 shall identify the
function (originator or recipient) of the party involved.
Data element key name in security identification details composite data element (S500/0538) may be used to
establish the key relationship between the sending and receiving parties.
This key relationship may also be established by using the data element identification of the key of the algorithm
parameter composite data element (S503/0554) in the USA segment of segment group 1.
S500/0538 in USH segment may be used if there is no need to convey a USA segment in segment group 1
(because the cryptographic mechanisms have been agreed previously between the partners).
Nevertheless, it is strongly recommended to use either S500/0538 in the USH segment, or S503/0554 with the
appropriate qualifier in the USA segment, but not both of them, within the same security header group.
USH segment may specify the filter function used for the binary fields of USA segment within segment group 1
and of the USR segment of the corresponding security trailer group.
USH segment may include a security sequence number, to provide sequence integrity, and the date of creation of
the security elements.
USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required. This shall be the algorithm applied directly on the message/package. This algorithm may be
either symmetric, a hash function or a compression algorithm. For example, for a digital signature, it indicates the
message-dependent hash function to be used.
Asymmetric algorithms shall not be referred to directly in this USA segment within segment group 1 but may
appear only within segment group 2, triggered by a USC segment.
Three occurrences of the USA segment are allowed. One occurrence shall be used for the symmetric algorithm or
the hash function required to provide the security service specified in the USH segment. The other two
occurrences are described in Part 7 of ISO 9735.
Indication of padding mechanism may be used when appropriate.
Segment Group 2: USC-USA-USR (certificate group)
A group of segments containing the data necessary to validate the security methods applied to the
message/package, when asymmetric algorithms are used. Certificate segment group shall be used when
asymmetric algorithms are used to identify the asymmetric key pair used, even if certificates are not used.
Either the full certificate segment group (including the USR segment), or the only data elements necessary to
identify unambiguously the asymmetric key pair used, shall be present in the USC segment. The presence of a full
certificate may be avoided if the certificate has already been exchanged by the two parties, or if it may be retrieved
from a database.
Where it is decided to refer to a non-EDIFACT certificate (such as X.509), the certificate syntax and version shall be
identified in data element 0545 of the USC segment. Such certificates may be conveyed in an EDIFACT package.
Two occurrences of this segment group are allowed, one being the message/package sender certificate (that the
message/package receiver will use to verify the sender's signature), the other being the message/package receiver
certificate (only referred to by certificate reference) in the case where the receiver public key is used by the sender
for confidentiality of symmetric keys.
If both are present within one security header segment group, the security identification details composite data
element (S500) together with the certificate reference data element (0536) allow them to be differentiated.
This segment group shall be omitted if no asymmetric algorithm is used.
©
ISO
USC, Certificate
A segment containing the credentials of the certificate owner and identifying the certification authority which has
generated the certificate. The data element filter function, coded (0505) shall identify the filter function used for the
binary fields of USA segments and USR segment within segment group 2.
USC certificate may contain two occurrences of S500: one for the certificate owner (identifying the party which
signs with the private key associated to the public key contained in this certificate), one for the certificate issuer
(certification authority or CA).
USA, Security algorithm
A segment identifying a security algorithm, the technical usage made of it, and containing the technical
parameters required. The three different occurrences of this USA segment in segment group 2 are identifying:
1 the algorithm used by the certificate issuer to compute the hash value of the certificate (hashing function)
2 the algorithm used by the certificate issuer to generate the certificate (i.e. to sign the result of the hash
function computed on the certificate content) (asymmetric algorithm)
3a - either the algorithm used by the sender to sign the message/package (i.e. to sign the result of the hash
function described in the USH segment, computed on the message/package content) (asymmetric
algorithm),
3b - or the receiver's asymmetric algorithm used by the sender to encrypt the key required by a symmetric
algorithm applied to the message/package content and referred to by the segment group 1 triggered by the
USH segment (asymmetric algorithm)
Indication of padding mechanism may be used when appropriate.
USR, Security result
A segment containing the result of the security functions applied to the certificate by the certification authority. This
result shall be the signature of the certificate computed by the certification authority by signing the hash result
computed on the data of the credentials.
For the certificate, the signature computation starts with the first character of the USC segment (namely the "U")
and ends with the last character of the last USA segment (including the separator following this USA segment).
Segment Group n: UST-USR (security trailer group)
A group of segments containing a link with security header segment group and the result of the security functions
applied to the message/package.
UST, Security trailer
A segment establishing a link between security header and security trailer segment groups, and stating the
number of security segments containedin these groups.
USR, Security result
A segment containing the result of the security functions applied to the message/package as specified in the
linked security header group. Depending on the security mechanisms specified in the linked security header
group, this result shall be either:
- computed directly on the message/package by the algorithm specified in the USA segment within segment
group 1 of the security header group, or
- computed by signing with an asymmetric algorithm specified in USA segment within segment group 2 of the
security header segment group a hash result computed on the message/package by the algorithm specified in
the USA segment within segment group 1 of the security header segment group
5.1.4 Scope of security application
There are two possibilities for the scope of security application:
1. The computation of each of the integrity and authentication values and of the digital signatures starts with and
includes the current security header segment group and the message body, or object, itself. In this case no
other security header or security trailer segment groups shall be encompassed within this scope.
The security header segment group shall be counted from the first character, namely a "U", to the separator
ending this security header segment group, both included, and the message body, or object, from the first
character following the separator ending the last security header segment group to the separator preceding
the first character of the first security trailer segment group, both included.
©
ISO
Thus the order in which security services integrated in this manner are performed, is not prescribed. They are
completely independent of each other.
Figure 3 illustrates this case (the scope of application of the security service defined in the security header 2
is represented by shaded boxes):
Security Security Security Security Security Security
UNH/ header header header MESSAGE BODY/ trailer trailer trailer UNT/
UNO segment segment segment OBJECT segment segment segment UNP
group 3 group 2 group 1 group 1 group 2 group 3
Figure 3 - Scope of application: security header segment group and message body/object only (schematic)
2. The computation starts with and includes the current security header segment group to the associated
security trailer segment group. In this case the current security header segment group, the message body, or
object, and all the other embedded security header and trailer segment groups shall be encompassed within
this scope.
The scope shall include every character from the first character, namely a "U", of the current security header
segment group, to the separator preceding the first character of the associated security trailer segment
group, both included.
Figure 4 illustrates this case (the scope of application of the security service defined in the security header 2
is represented by shaded boxes):
Security Security Security Security Security Security
UNH/ header header header MESSAGE BODY/ trailer trailer trailer UNT/
UNO segment segment segment OBJECT segment segment segment UNP
group 3 group 2 group 1 group 1 group 2 group 3
Figure 4 - Scope of application: from security header segment group to security trailer segment group
(schematic)
For each added security service, either of the two approaches may be chosen.
In both cases, the relation between the security header segment group and associated security trailer segment
group shall be provided by the data elements security reference number of the USH and of the UST segments.
5.2 Principles of usage
5.2.1 Choice of service
The security header segment group may include the following general information:
- Security service applied
- Identification of the parties involved
- Security mechanism used
- "Unique" value (sequence number and/or timestamp)
- Non-repudiation of receipt request
If more than one security service is required for the same EDIFACT structure, then the security header segment
group may be present several times. This shall be the case when several pairs of parties are involved. However, if
several services are required between the same two parties they may be included in a single pair of security header
and trailer segment groups, as certain services include others implicitly.
5.2.2 Authenticity
If origin authentication of a EDIFACT structure is required, it shall be provided in accordance to the principles
defined in ISO 10181-2, using an appropriate pair of security header and security trailer segment groups.
The security service of origin authentication shall be specified in the USH segment and the algorithm shall be
identified in the USA segment in segment group 1. It shall be a symmetric algorithm.
©
ISO
The party acting as security originator shall compute an authenticity value that shall be conveyed in the USR
segment of the security trailer segment group. The party acting as security recipient shall check the authenticity
value.
This service may include integrity service and may be obtained as a sub-product of non-repudiation of origin
service.
If an appropriate implementation of this "origin authentication" service, based on tamper resistant hardware or
trusted third parties, is used, it may be considered as an instance of "non repudiation of origin" service. Such a
practice shall be defined in the interchange agreement.
5.2.3 Integrity
If content integrity of a EDIFACT structure is required, it shall be provided in accordance to the principles defined in
ISO 10181-6, using an appropriate pair of security header and security trailer segment groups.
The security service of integrity shall be specified in the USH segment and the algorithm shall be identified in the
USA segment in segment group 1. It shall be hash function or a symmetric algorithm.
The party acting as security originator shall compute an integrity value that shall be conveyed in the USR segment
of the security trailer segment group. The party acting as security recipient shall check the integrity value.
This service may be obtained as a sub-product of origin authentication service or of non-repudiation of origin
service.
If sequence integrity is required, either a security sequence number or a security timestamp, or both, shall be
contained by the security header segment group and either content integrity service or origin authentication service
or non-repudiation of origin service shall be used.
5.2.4 Non-repudiation of origin
If non-repudiation of origin of a EDIFACT structure is required, it shall be provided in accordance to the principles
defined in ISO 10181-4, using an appropriate pair of security header and security trailer segment groups.
The security service of non-repudiation of origin shall be specified in the USH segment and the hashing algorithm
shall be identified in the USA segment in segment group 1, and the asymmetric algorithm used for signature in the
USA segments of segment group 2, if certificates are used.
If the certificate is not conveyed in the message/package, the asymmetric algorithm shall be implicitly known by the
receiving party. In this case the asymmetric algorithm shall be defined in the interchange agreement.
The party acting as security originator shall compute a digital signature that shall be conveyed in the USR segment
of the security trailer segment group. The party acting as security recipient shall verify the digital signature value.
This service provides also content integrity and origin authentication services.
5.3 Internal representation and filters for compliance with EDIFACT syntax
The use of mathematical algorithms to compute integrity values and digital signatures introduces two problems.
The first problem is that the result of the calculation depends on the internal representation of the character set.
Thus the computation of the digital signature by the sender and its verification by the recipient shall be executed
using the same character set encoding. Therefore the sender may indicate the representation used to produce the
original security validation result.
The second problem is that the result of the calculation is a seemingly random bit pattern. This may cause problems
during transmission and with interpretation software. To avoid these problems the bit pattern may be reversibly
mapped on to a particular representation of the character set used by means of a filtering function. For simplicity,
only one filtering function shall be used for each security service. Any appearance of an anomalous terminator in the
output of this mapping is dealt with by including an escape sequence.
©
ISO
6 Rules for the use of interchange and group security header and trailer segment
groups for batch EDI
6.1 Group and interchange level security - integrated message security
The security threats relevant to message/package transmission and the security services which address them, as
described in annexes C and D, are also valid at group and interchange level.
The techniques described in the previous section for applying security to messages/packages may also be applied
to interchanges and groups.
For group and interchange level security, the same header and trailer segment groups as those described at
message/package level, shall be used, and header-trailer cross referencing shall always apply at the same level,
even when security is applied separately at more than one level.
When security is applied at message/package level, the protected structure is the message body or object. At group
level it is the set of messages/packages in the group including all message/package headers and trailers. At
interchange level, it is the set of messages/packages or groups in the interchange, including all message/package
or group headers and trailers.
6.1.1 Security header and trailer segment groups
Figure 5 describes an interchange showing security at both interchange and group levels.
INTERCHANGE
Security Security
Either : Only Or : Only
header trailer
G R O U P(S) M ESS A G E(S)/
UNA UNB UNZ
segm ent PACKA G E(S) segm ent
group(s) group(s)
Security Security
header trailer
UNG MESSAGE(S)/PACKAGE(S) UNE
segm ent segm ent
group(s) group(s)
Figure 5 - Interchange showing security at both interchange and group levels (schematic)
6.1.2 Security header and trailer segment groups structure
TAG Name S R
UNB Interchange Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+ I
USC Certificate M 1 I I
USA Security Algorithm C 3 I I
USR Security Result C 1 --------+
©
ISO
Group(s) or Message(s)/Package(s)
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1 I
USR Security Result C 1 ----+
UNZ Interchange Trailer M 1
Table 3 - Security header and security trailer segment groups segment table (interchange level
security only)
TAG Name S R
UNG Group Header M 1
----- Segment Group 1 ---------------- C 99 --------+
USH Security Header M 1 I
USA Security Algorithm C 3 I
----- Segment Group 2 ---------------- C 2 ----+ I
USC Certificate M 1 I I
USA Security Algorithm C 3 I I
USR Security Result C 1 --------+
Message(s)/Package(s)
----- Segment Group n ---------------- C 99 ----+
UST Security Trailer M 1 I
USR Security Result C 1 ----+
UNE Group Trailer M 1
Table 4 - Security header and security trailer segment groups segment table (group level security only)
Note: UNB interchange header, UNZ interchange trailer, UNG group header and UNE group trailer are specified in
Part 1 of ISO 9735. They are not described further in this Part.
The complete directory specification of the segments and data elements may be found in annex B.
6.1.3 Scope of security application
There are two possibilities for the scope of security application:
1. The computation of each of the integrity and authentication values and of the digital signatures starts with and
includes the current security header segment group and the group(s) or message(s)/package(s), themselves.
In this case no other security header or security trailer segment groups shall be encompassed within this
scope.
The security header segment group shall be counted from the first character, namely a "U", to the separator
ending this security header segment group, both included, and the group(s) or message(s)/package(s), from
the first character following the separator ending the last security header segment group to the separator
preceding the first character of the first security trailer segment group, both included.
Thus the order in which security services integrated in this manner are performed, is not prescribed. They are
completely independent of each other.
Figures 6 and 7 illustrate this case (the scope of application of the security service defined in the security
header 2 is represented by shaded boxes):
Security Security Security GROUP(S) Security Security Security
UNB header header header OR trailer trailer trailer UNZ
segment segment segment MESSAGE(S)/PACKAGE(S) segment segment segment
group 3 group 2 group 1 group 1 group 2 group 3
Figure 6 - Scope of application: security header segment group and group(s) or message(s)/package(s)
only (schematic)
©
ISO
Security Security Security Security Security Security
UNG header header header MESSAGE(S)/PACKAGE(S) trailer trailer trailer UNE
segment segment segment segment segment segment
group 3 group 2 group 1 group 1 group 2 group 3
Figure 7 - Scope of application: security header segment group and message(s)/package(s) only
(schematic)
2. The computation starts with and includes the current security header segment group to the associated
security trailer segment group. In this case the current security header segment group, the group(s) or
message(s)/package(s), and all the other embedded security header and trailer segment groups shall be
encompassed within this scope.
The scope shall include every character from the first character, namely a "U", of the current security header
segment group, to the separator preceding the first character of the associated security trailer segment
group, both included.
Figures 8 and 9 illustrate this case (the scope of application of the security service defined in the security
header 2 is represented by shaded boxes):
Security Security Security GROUP(S) Security Security Security
UNB header header header OR trailer trailer trailer UNZ
segment segment segment MESSAGE(S)/PACKAGE(S) segment segment segment
group 3 group 2 group 1 group 1 group 2 group 3
Figure 8 - Scope of application: from security header segment group to security trailer segment group
(schematic)
Security Security Security Security Security Security
UNG header header header MESSAGE(S)/PACKAGE(S) trailer trailer trailer UNE
segment segment segment segment segment segment
group 3 group 2 group 1 group 1 group 2 group 3
Figure 9 - Scope of application: from security header segment group to security trailer segment group
(schematic)
For each added security service, either of the two approaches may be chosen.
In both cases, the relation between the security header segment group and associated security trailer segment
group shall be provided by the data elements security reference number of the USH and of the UST segments.
©
ISO
Annex A
(normative)
Addendum — to be added to Part 1 annex A when approved
Definitions
A.1 asymmetric algorithm: A cryptographic algorithm employing a public key and a private key. Together
these form an asymmetric key set. [1]
A.2 authentication: See ‘data origin authentication’. [2]
: The public key of a user, together with some other information, rendered unforgeable by a
A.3 certificate
signature with the private key of the certification authority which issued it. (ISO/IEC 9594-8) [3]
A.4 certification authority: An authority trusted by one or more users to create and assign certificates.
(ISO/IEC 9594-8) [4]
A.5 confidentiality: The property that information is not made available or disclosed to unauthorized
individuals, entities or processes. (ISO 7498-2) [5]
A.6 credential: Data that serves to establish the claimed identity of an entity. (ISO 7498-2) [6]
A.7 cryptography: The discipline which embodies principles, means, and methods for the transformation of
data in order to hide its information content, prevent its undetected modification and/or prevent its
unauthorized use. (ISO 7498-2) [7]
A.8 data integrity: The property that data has not been altered or destroyed in an unauthorised manner.
(ISO 7498-2) [8]
A.9 data origin authentication: The corroboration that the source of data received is as claimed.
(ISO 7498-2) [9]
A.10 decryption: See decipherment. (ISO 7498-2) [10]
A.11 decipherment: The reversal of a corresponding reversible encipherment. (ISO 7498-2) [11]
A.12 digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit
that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against
forgery e.g. by the recipient. (ISO 7498-2) [12]
A.13 encipherment: The cryptographic transformation of data (see cryptography) to produce ciphertext.
(ISO 7498-2) [13]
A.14 encryption: See encipherment. (ISO 7498-2) [14]
A.15 filtering: The process by which octets containing arbitrary bit patterns are converted to octets belonging to
the character set which the underlying syntax is capable of supporting. [15]
A.16 hash function: A (mathematical) function which maps values from a large (possibly very large) domain
into a smaller range. A 'good' hash function is such that the results of applying the function to a (large) set
of values in the domain will be evenly distributed (and apparently at random) over the range.
(ISO/IEC 9594-8) [16]
A.17 integrity: See ‘data integrity’. [17]
A.18 key: A sequence of symbols that controls the operations of encipherment and decipherment.
(ISO 7498-2) [18]
A.19 non-repudiation: Denial by one of the entities involved in a communication of having participated in all or
part of the communication. (ISO 7498-2) [19]
A.20 private key: (In a public key cryptosystem) that key of a user's key pair which is known only by that user.
(ISO/IEC 9594-8) [20]
A.21 public key: (In a public key cryptosystem) that key of a user's key pair which is publicly known.
(ISO/IEC 9594-8) [21]
A.22 secret key: a key used with symmetric cryptographic techniques and usable only by a set of specified
entities. (ISO/IEC 11770-1) [22]
: A cryptographic algorithm employing the same value of key for both enciphering
A.23 symmetric algorithm
and deciphering or for both authentication and validation.
A.24 threat: A potential violation of security. (ISO 7498-2) [23]
©
ISO
Annex B
(normative)
Addendum — to be added to Part 1 annex C when approved
Syntax service directories
(segments, composite data elements and simple data elements)
B.1 Segment directory
B.1.1 Segment specification legend:
Function The function of the segment
POS The sequential position number of the stand-alone data element or composite data element in the
segment table
TAG The tags for all service segments contained in the segment directory start with the letter “U”. The tags
of all service composite data elements start with the letter "S", and the tags of all service simple data
elements start with the figure "0"
Name Name of a COMPOSITE DATA ELEMENT in capital letters
Name of a STAND-ALONE DATA ELEMENT in capital letters
Name of a component data element in small letters
S The status of the stand-alone data element or composite data element in the segment, or of the
components in the composite (where M = Mandatory and C = Conditional)
R The maximum number of occurrences of a stand-alone data element or composite data element in the
segment
Repr. Data value representation of the stand-alone data element or component data elements in the
composite.
a alphabetic characters
n numeric characters
an alphanumeric characters
a3 3 alphabetic characters, fixed length
n3 3 numeric characters, fixed length
an3 3 alphanumeric characters, fixed length
a.3 up to 3 alphabetic characters
n.3 up to 3 numeric characters
an.3 up to 3 alphanumeric characters
B.1.2 Dependency note identifiers
Code Name
D1 One and only one
D2 All or none
D3 One or more
D4 One or none
D5 If first , then all
D6 If first, then at least one more
D7 If first, then none of the others
See clause 11.5 in Part 1 for the definition of the dependency note identifiers
©
ISO
B.1.3 Index of segments by tag
TAG Name
USA Security algorithm
USC Certificate
USH Security header
USR Security result
UST Security trailer
B.1.4 Index of segments by name
TAG Name
USC Certificate
USA Security algorithm
USH Security header
USR Security result
UST Security trailer
B.1.5 Segment specifications
---------------------------------------------------------------------------
USA SECURITY ALGORITHM
Function: To identify a security algorithm, the technical usage made
of it, and to contain the technical parameters required.
POS TAG Name S R Repr. Notes
010 S502 SECURITY ALGORITHM M 1
0523 Use of algorithm, coded M an.3
0525 Cryptographic mode of operation, coded C an.3
0533 Mode of operation code list identifier C an.3
0527 Algorithm, coded C an.3
0529 Algorithm code list identifier C an.3
0591 Padding mechanism, coded C an.3
0601 Padding mechanism code list identifier C an.3
020 S503 ALGORITHM PARAMETER C 9 1
0531 Algorithm parameter qualifier M an.3
0554 Algorithm parameter value M an.512
NOTES:
1. S503, provides space for one parameter. The number of repetitions of
S503 actually used will depend on the algorithm used. The order of the
parameters is arbitrary but, in each case, the actual value is preceded
by a coded algorithm parameter qualifier.
---------------------------------------------------------------------------
©
ISO
---------------------------------------------------------------------------
USC CERTIFICATE
Function: To convey the public key and the credentials of its owner.
POS TAG Name S R Repr. Notes
010 0536 CERTIFICATE REFERENCE C 1 an.35 2
020 S500 SECURITY IDENTIFICATION DETAILS C 2 3
0577 Security party qualifier M an.3
0538 Key name C an.35
0511 Security party identification C an.512
0513 Security party code list qualifier C an.3
0515 Security party code list responsible
agency, coded C an.3
0586 Security party name C an.35
0586 Security party name C an.35
0586 Security party name C an.35
030 0545 CERTIFICATE SYNTAX AND VERSION, CODED C 1 an.3 2
040 0505 FILTER FUNCTION, CODED C 1 an.3
050 0507 ORIGINAL CHARACTER SET ENCODING, CODED C 1 an.3 4
060 0543 CERTIFICATE ORIGINAL CHARACTER SET
REPERTOIRE, CODED C 1 an.3 5
070 0546 USER AUTHORISATION LEVEL C 1 an.35
080 S505 SERVICE CHARACTER FOR SIGNATURE
...
NORME ISO
INTERNATIONALE 9735-5
Première édition
1999-04-01
Échange de données informatisé pour
l'administration, le commerce et le
transport (EDIFACT) — Règles de syntaxe
au niveau de l'application (numéro de
version de syntaxe: 4) —
Partie 5:
Règles de sécurité pour l'EDI par lots
(authentification, intégrité et
non-répudiation de l'origine)
Electronic data interchange for administration, commerce and transport
(EDIFACT) — Application level syntax rules (Syntax version number: 4) —
Part 5: Security rules for batch EDI (authenticity, integrity and
non-repudiation of origin)
Numéro de référence
©
ISO 1999
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifiéà moins que l'ordinateur employéà cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la créationduprésent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO 1999
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’ISO à
l’adresse ci-aprèsouducomité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Version française parue en 2000
Imprimé en Suisse
ii © ISO 1999 – Tous droits réservés
Sommaire Page
1 Domaine d'application.1
2 Conformité.1
3Références normatives .1
4Définitions .2
5Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité pour l’EDI par lots.2
6Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité au niveau de
l’échange et des groupes pour l’EDI par lots .10
Annexe A Addendum -—à ajouter à l’annexe A de la Partie 1 lorsqu’elle sera approuvée —
Définitions .14
Annexe B Addendum—à ajouter à l’annexeCdelaPartie1 lorsqu’elle sera approuvée —
Répertoires syntaxiques de service (segments, éléments de données composites et éléments
de données simples) .16
Annexe C Menaces à l’encontre de la sécurité EDIFACT et solutions pour s’en prémunir.34
Annexe D Façon de protéger une structure EDIFACT.38
Annexe E Exemples de protection d’un message.41
Annexe F Fonctions du filtre pour les répertoires des jeux de caractères A et C EDIFACT/ONU .51
Annexe G Addendum —à ajouter à l’annexe D le la Partie 1 une fois approuvée — Répertoire des
codes de service.54
Annexe H Services et algorithmes de sécurité.55
Annexe I Bibliographie.63
© ISO 1999 – Tous droits réservés iii
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éeaux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude aledroit de faire partie ducomité
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 9735-5 a étéélaborée par la Division du commerce de la Commission Économique
pour l’Europe des Nations Unies (en tant qu’EDIFACT/ONU) et a été adoptée, selon une procédure spéciale par
«voie express»,par le comité technique ISO/TC 154, Documents et éléments de données dans l'administration, le
commerce et l'industrie.
Alors que la présente partie remplace les publications antérieures et qu’un numéro de version «4» doit être attribué
à l’élément de données obligatoire 0002 (numéro de version de la syntaxe) du segment UNB (en-tête de
l’échange), les échanges continuant à utiliser la syntaxe définie dans les versions publiées antérieurement doivent
reprendre les numéros suivants de version de syntaxe afin de se différencier tant les uns des autres que de la
présente partie:
ISO 9735:1988 — Numéro de version de syntaxe: 1
ISO 9735:1988 (modifiéeetréimprimée en 1990) — Numéro de version de syntaxe: 2
ISO 9735:1988 (modifiéeetréimprimée en 1990) plus Amendement 1:1992 — Numéro de version de
syntaxe: 3
L'ISO 9735 comprend les parties suivantes, présentées sous le titre général Échange de données informatisé pour
l'administration, le commerce et le transport (EDIFACT) — Règles de syntaxe au niveau de l'application (numéro
de version de syntaxe: 4):
� Partie 1: Règles de syntaxe communes à l’ensemble des parties, accompagnées des répertoires de service
syntaxiques associés à chacune d'elles
� Partie 2: Règles de syntaxe spécifiques à l'EDI par lots
� Partie 3: Règles de syntaxe spécifiques à l'EDI interactif
� Partie 4: Message Compte rendu syntaxique et de service pour l'EDI par lots (type de message CONTRL)
� Partie 5: Règles de sécurité pour l'EDI par lots (authentification, intégrité et non-répudiation de l'origine)
� Partie 6: Message sécurisé Authentification et accusé de réception (type de message AUTACK)
� Partie 7: Règles de sécurité pour le lot EDI (confidentialité)
� Partie 8: Données associées en EDI
� Partie 9: Message Gestion de clés et de certificats de sécurité(typedemessage KEYMAN)
� Partie 10: Règles de sécurité pour l'EDI interactif
iv © ISO 1999 – Tous droits réservés
D'autres parties pourront être ajoutées ultérieurement.
Les annexes A et B constituent des éléments normatifs de la présente partie de l’ISO 9735. Les annexes C à Ine
sont données qu’à titre d’information.
© ISO 1999 – Tous droits réservés v
Introduction
La présente partie de l’ISO 9735 comprend les règles qui se situent au niveau de l'application pour la structuration
des données associées à l'échange de messages électroniques dans un environnement ouvert, fondées sur les
prescriptions du traitement ou par lots, ou interactif. Ces règles ont été adoptées par la Commission Économique
pour l'Europe des Nations Unies (CEE/ONU) comme règles de syntaxe pour l'échange de données informatisé
pour l'administration, le commerce et le transport (EDIFACT). Elles font partie du Répertoire d'Échange de
données commerciales des Nations Unies (UNTDID) qui comporte également les Directives pour la conception de
messages, tant par transmission par lots qu'en mode interactif.
Les spécifications des communications et les protocoles n'entrent pas dans le cadre de la présentepartiede
l’ISO 9735.
La présente partie est nouvelle. Elle a été ajoutée à l'ISO 9735. Elle offre la possibilité de sécuriser des structures
EDIFACT par lots, c’est à dire des messages, des paquets, des groupes ou un échange.
vi © ISO 1999 – Tous droits réservés
NORME INTERNATIONALE ISO 9735-5:1999(F)
Échange de données informatisé pour l'administration, le
commerce et l'industrie (EDIFACT) — Règles de syntaxe au niveau
de l'application (numéro de version de syntaxe: 4) —
Partie 5:
Règles de sécurité pour l'EDI par lots (authentification, intégrité et
non-répudiation de l'origine)
1 Domaine d'application
La présente partie de l'ISO 9735 définit les règles de syntaxe régissant la sécurité EDIFACT. Elle décrit une
méthode traitant de la sécurité au niveau d’un message/paquet, d’un groupe et d’un échange permettant d’assurer
l’authenticité,l’intégrité et la non-répudiation de l’origine, conformément aux mécanismes reconnus de sécurité.
2 Conformité
La conformitéà une norme signifie que la totalité de ses prescriptions, y compris tous ses aspects, sont pris en
compte. Si tel n’est pas le cas, toute demande de conformité doit comporter une déclaration identifiant chacun des
aspects qui en fait l'objet.
Les données échangées sont en conformité si la structure et la représentation des données respectent les règles
de syntaxe définies dans la présente partie de l'ISO 9735.
Les dispositifs qui s'appuient sur la présente partie de l'ISO 9735 sont en conformité s'ils sont en mesure de créer
et/ou d'interpréter les données structurées et représentées conformément à la présente partie de l’ISO 9735.
La conformitéà la présentepartiel’ISO 9735 doit prendre en compte la conformité aux Parties 1, 2 et 8 de
l’ISO 9735.
Une fois identifiées dans la présente partie de l’ISO 9735, les dispositions définies dans les normes associées
doivent faire partie intégrante des critères de conformité.
3Ré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 9735. 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 9735 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 l'ISO et de la CEI possèdent le registre des
Normes internationales en vigueur.
ISO 7498-2:1989, Systèmes de traitement de l’information — Interconnexion de systèmes ouverts — Modèle de
référence de base — Partie 2: Architecture de sécurité.
© ISO 1999 – Tous droits réservés 1
ISO/CEI 9594-8:1995, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — L’Annuaire:
Cadre d’authentification.
ISO 9735-1:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 1: Règles
de syntaxe communes à l'ensemble des parties, accompagnées des répertoires de service syntaxiques associés à
chacune d'elles.
ISO 9735-2:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 2: Règles
de syntaxe spécifiques à l'EDI par lots.
ISO 9735-6:1999, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 6:
Message sécurisé Authentification et accusé de réception (type de message AUTACK).
1)
ISO 9735-7:— , Échange de données informatisé pour l’administration, le commerce et le transport (EDIFACT) —
Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 7: Règles de sécurité
pour le lot EDI (confidentialité).
ISO 9735-8:1998, Échange de données informatisé pour l’administration, le commerce et le transport
(EDIFACT) — Règles de syntaxe au niveau de l’application (numéro de version de syntaxe: 4) — Partie 8:
Données associées en EDI.
ISO/CEI 10181-2:1996, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre d’authentification.
ISO/CEI 10181-4:1997, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre de non-répudiation.
ISO/CEI 10181-6:1996, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) — Cadres de
sécurité pour les systèmes ouverts: Cadre d’intégrité.
4Définitions
Pour les besoins de la présente partie de l’ISO 9735, les définitions données dans l'annexe A de l’ISO 9738-1:1998
s’appliquent.
5Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité pour
l’EDI par lots
5.1 Sécurité au niveau d’un message/paquet - sécurité intégrée à un message/paquet
Les risques pouvant menacer la sécurité de la transmission d’un message/paquet et les services de sécurité qui en
traitent sont décrits dans les annexes C et D.
Cette section décrit la structure de la sécurité au niveau d’un message/paquet EDIFACT.
Les services de sécurité traités dans la présente partie de l’ISO 9735 doivent être assuréspar l’inclusion de
groupes de segments d’en-tête et de findesécurité après le segment UNH et avant le segment UNT de façon à
s’appliquer à tout message existant, ou après le segment UNO et avant le segment UNP, pour tout paquet
existant.
1) À publier.
2 © ISO 1999 – Tous droits réservés
5.1.1 Groupes de segments d’en-tête et de fin de sécurité
La Figure 1 décrit un échange illustrant l’application de la sécurité au niveau d’un message.
ECHANGE
Soit : Seulement
Soit : Seulement
UNA UNB
UNZ
GROUPE(S) PAQUET(S)
Message UNE
UNG MESSAGE Message
Groupe(s) Groupe(s)
de segments
de segments
UNH CORPS DU MESSAGE UNT
de fin de
d'en-tête de
sécurité
sécurité
Figure 1—Échange illustrant l’application de la sécurité au niveau d’un message (schéma simplifié)
La Figure 2 décrit un échange illustrant l’application de la sécurité au niveau d’un paquet.
ECHANGE
Soit : Seulement
Soit : Seulement
UNA UNB
UNZ
GROUPE(S) PAQUET(S)
UNG Paquet PAQUET Paquet UNE
Groupe(s)
Groupe(s)
de segments
de segments
UNO OBJET UNP
de fin de
d'en-tête de
sécurité
sécurité
Figure 2—Échange illustrant l’application de la sécurité au niveau d’un paquet (schéma simplifié)
© ISO 1999 – Tous droits réservés 3
5.1.2 Structure de groupes de segments d’en-tête et de fin de sécurité
Tableau 1 — Table des segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau du message)
Etiquette Nom S R
UNH En-tête de message M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M 1 I
USA Algorithme de sécurité C 3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C 3 I I
USR Résultat de sécurité C 1 --------+
Corps du message
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M 1 I
USR Résultat de la sécurité C 1 ----+
UNT Fin de message M 1
Tableau 2 — Table des segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau du paquet)
Etiquette Nom S R
UNO En-tête d’objet M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M 1 I
USA Algorithme de sécurité C 3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C 3 I I
USR Résultat de la sécurité C 1 --------+
Objet
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M 1 I
USR Résultat de la sécurité C 1 ----+
UNP Fin d’objet M 1
NOTE L’en-tête UNH du message, la fin UNT du message, l’en-tête UNO d’objet et la fin UNP d’objet sont décrits dans la
Partie 1 de l’ISO 9735. Ils ne sont pas décritsplusloindanslaprésente partie.
Toutes les spécifications des segments et des éléments de données peuvent être consultées dans l’annexe B qui
contient les répertoires correspondants.
5.1.3 Précisions sur les segments de données
Groupe de segments 1: USH-USA-SG2 (groupe d’en-tête de sécurité)
Groupe de segments identifiant le service et les mécanismes de sécurité qui s’appliquent et contenant les données
nécessaires à l’exécution des calculs de validation.
Il peut y avoir plusieurs groupes de segments d’en-tête de sécurité dans le même message/paquet, si différents
services de sécurité s’appliquent au message/paquet (par exemple, intégrité et non-répudiation de l’origine) ou si le
mêmeservicedesécurité s’applique à plusieurs intervenants.
4 © ISO 1999 – Tous droits réservés
USH, En-tête de sécurité
Segment définissant un service de sécurité s’appliquant au message/paquet dans lequel ce segment est intégré.
Les intervenants impliquésdans le servicedesécurité (initiateur des éléments de sécurité et destinataire des
éléments de sécurité) peuvent être identifiés dans ce segment, à moins qu’ils soient identifiés sans ambiguïté par
des certificats (segment USC) lorsque des algorithmes asymétriques sont utilisés.
L’élément de données composite (S500) «Précisions concernant les informations détaillées sur l’identification» doit
être utilisé dans le segment USH, dans les cas suivants :
� si des algorithmes symétriques sont utilisés, ou
� si des algorithmes asymétriques sont utilisés et que deux certificats sont présents, afin d’opérer la distinction
entre les certificats de l’initiateur et du destinataire.
Dans ce dernier cas, «l’identification de l’intervenant» contenue dans l’élément de données composite S500 (l’un
ou l’autre des éléments de données S500/0511, S500/0513, S500/0515, S500/0586) doit êtrelamême que
l’identification de l’intervenant, qualifié de «propriétairedecertificat», contenue dans l’une des données de S500
présente dans le segment USC du groupe de segments 2 et l’élément de données S500/0577 doit identifier la
fonction (initiateur ou destinataire) de l’intervenant impliqué.
L’élément de données «Nom de la clé» contenu dans l’élément de données composite, «Informations détaillées
sur l’identification de l’intervenant» (S500/0538), peut servir àétablir la relation des clés entre l’émetteur et le
récepteur.
Cette relation peut également être établie en utilisant l’élément de données «Identification de la clé» contenu dans
l’élément de données composite «Paramètredel’algorithme» (S503/0554) contenu dans le segment USA du
groupe de segments 1.
L’élément de données composite S500/0538 contenu dans le segment USH peut être utilisé s’il n’est pas
nécessaire de véhiculer un segment USA dans le groupe de segments 1 (les mécanismes cryptographiques ayant
été convenus au préalable entre les partenaires).
Néanmoins, il est vivement recommandé d’utiliser soit S500/0538 du segment USH, ou S503/0554 avec le
qualifiant approprié du segment USA, mais non les deux, au sein du même groupe d’en-tête de sécurité.
Le segment USH peut indiquer la fonction du filtre utilisé pour les champs binaires du segment USA au sein du
groupe de segments 1 et du segment USR du groupe correspondant de fin de sécurité.
Le segment USH peut comprendre un numéro de séquence de sécurité pour indiquer l’intégrité d’une séquence et
la date de création des éléments de sécurité.
USA, Algorithme de sécurité
Segment identifiant un algorithme de sécurité,l’utilisation technique qui en est faite et contenant les paramètres
techniques requis. Il s’agiradel’algorithme s’appliquant directement au message/paquet. Cet algorithme peut être
soit symétrique, soit une fonction de hachage, soit un algorithme de compression. Il indique la fonction à utiliser par
exemple, pour une signature numérique. Il ne doit pas être fait référence aux algorithmes asymétriques
directement dans ce segment USA contenu dans le groupe de segments 1 car ces algorithmes ne peuvent
apparaître que dans le groupe de segments 2, déclenché par un segment USC.
Trois occurrences du segment USA sont autorisées. Une occurrence doit être utilisée pour l’algorithme ou la
fonction de hachage nécessaire à la fourniture du service de sécurité défini dans le segment USH segment. Les
deux autres occurrences sont décrites dans la Partie 7 de l’ISO 9735.
Un mécanisme de remplissage peut être indiqué aux endroits appropriés.
© ISO 1999 – Tous droits réservés 5
Groupe de segments 2: USC-USA-USR (certificat)
Groupe de segments contenant les données nécessaires à la validation des méthodes de sécurité s’appliquant au
message/paquet, lorsque des algorithmes asymétriques sont utilisés. Le groupe de segments du certificat doit être
utilisé lorsque des algorithmes asymétriques sont utilisés pour identifier la paire de clésasymétriques utilisée,
même si des certificats ne sont pas utilisés.
Soit l’ensemble du groupe de segments (comprenant le segment USR), soit les seuls éléments de données
nécessaires à l’identification non ambiguë de la paire de clésasymétriques utilisée, doivent être présents dans le
segment USC. La présence d’un certificat complet peut être évitéesi lecertificatadéjàétééchangé entre les deux
partenaires ou s’il peut être extrait d’une base de données.
S’il est décidé de faire référence à un certificat non EDIFACT (tel qu’à un X.509), la syntaxe et la version de ce
certificat doivent être identifiés dans l’élément de données 0545 du segment USC. Ces certificats peuvent être
véhiculés dans un paquet EDIFACT.
Deux occurrences de ce groupe de segments sont autorisées, l’une correspondant au certificat de l’émetteur du
message/paquet (qui servira au récepteur du message/paquet à vérifier la signature de l’émetteur), l’autre
correspondant au certificat du récepteur de ce message/paquet (auquel il n’est fait référence que par la référence
du certificat) au cas où la clé publique du récepteur est utilisée par l’émetteur pour des raisons de confidentialité de
cléssymétriques.
SI les deux sont présentes au sein d’un groupe de segments d’en-tête de sécurité,l’élément de données
composite «Informations détaillées sur l’identification de la sécurité» (S500) ainsi que l’élément de données
«Référence du certificat» (0536) permettront de les différencier.
Ce groupe de segments doit être omis si aucun algorithme asymétrique n’est utilisé.
USC, Certificat
Segment contenant les justificatifs d’identité du propriétaire du certificat et identifiant l’autorité de certification qui a
généré le certificat. L’élément de données «Fonction du filtre, en code», (0505) doit identifier la fonction du filtre
utilisé pour les champs binaires des segments USA et du segment USR au sein du groupe de segments 2.
Le certificat USC peut contenir deux occurrences de l’élément de données S500: l’une pour le propriétaire du
certificat (identifiant l’intervenant qui signe avec la clé privée associée à la clé publique contenue dans ce
certificat), l’autre pour l’émetteur du certificat (autorité de certification ou «CA»).
USA, Algorithme de sécurité
Segment identifiant un algorithme de sécurité,l’utilisation technique qui en est faite et contenant les paramètres
techniques requis. Les trois occurrences différentes de ce segment USA dans le groupe de segments 2 identifient
1l’algorithme utilisé pour l’émetteur pour calculer la valeur de hachage du certificat (fonction de hachage);
2l’algorithme utilisé par l’émetteur du certificat pour produire le certificat (c’est-à-direlerésultat de la fonction de
hachage calculéà partir du contenu du certificat) (algorithme asymétrique);
3a soit l’algorithme utilisé par l’émetteur pour signer le message/paquet (c’est-à-dire, pour signer le résultat de la
fonction de hachage décrite dans le segment USH, calculéà partir du contenu du message/paquet)
(algorithme asymétrique);
3b soit l’algorithme asymétrique du récepteur, utilisé par l’émetteur pour chiffrer la clé requise, par un algorithme
symétrique appliqué au contenu du message/paquet et auquel fait référence le groupe de segments 1
déclenché par le segment USH) (algorithme asymétrique).
L’indication du mécanisme de remplissage peut être utilisée.
6 © ISO 1999 – Tous droits réservés
USR, Résultat de sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au certificat par l’autorité de certification. Ce
résultat doit être constitué par la signature du certificat calculée par l’autorité de certification en signant le résultat
de hachage calculéà partir des données du justificatif d’identité.
Pour le certificat, le calcul de la signature commence au premier caractère du segment USC (à savoir le «U»)et se
termine au dernier caractère du dernier segment USA (qui comprend le séparateur qui suit ce segment USA).
Groupe de segments n: UST-USR (groupe de fin de sécurité)
Groupe de segments contenant un lien avec le groupe de segments d’en-tête de sécurité et le résultat des
fonctions de sécurité appliquées au message/paquet.
UST, Fin de sécurité
Segment établissant un lien entre le groupe de segments d’en-tête de sécurité et de fin de sécurité et indiquant le
nombre de segments de sécurité contenu dans ces groupes.
USR, Résultat de sécurité
Segment contenant le résultat des fonctions de sécurité appliquées au message/paquet comme précisé dans le
groupe d’en-tête de sécurité subordonné. En fonction des mécanismes de sécurité définis dans le groupe d’en-tête
de sécurité subordonné,cerésultat doit être, soit
� directement calculéà partir du message/paquet par l’algorithme défini dans le segment USA au sein du
groupe de segments 1 du groupe d’en-tête de sécurité ou
� calculé en signant, avec un algorithme asymétrique défini dans le segment USA au sein du groupe de
segments 2 du groupe de segments d’en-tête de sécurité,un résultat de hachage calculéà partir du
message/paquet par l’algorithme défini dans le segment USA au sein du groupe de segments 1 du groupe de
segments d’en-tête de sécurité.
5.1.4 Domaine d’application de la sécurité
La sécurité peut s’appliquer dans deux domaines :
1. Le calcul de chacune des valeurs d’intégrité et d’authentification et des signatures numériques commence
par, et comprend, le groupe de segments d’en-tête de sécurité courant et le corps du message ou l’objet, lui-
même. Dans ce cas, aucun autre groupe de segments d’en-tête ou de fin de sécurité ne doit entrer dans ce
domaine.
Le décompte du groupe de segments d’en-tête de sécurité doit être effectuéà partir du premier caractère, à
savoir «U», jusqu’au séparateur terminant le groupe de segments d’en-tête de sécurité, les deux compris et
le corps du message, ou l’objet, à partir du premier caractère suivant le séparateur terminant le dernier
groupe de segments d’en-tête de sécurité jusqu’au séparateur précédant le premier caractère du premier
groupe de segments de fin de sécurité, les deux compris.
Ainsi l’ordre dans lequel les services de sécurité intégrés de cette façon sont exécutés, n’est pas imposé.Ils
sont totalement indépendants les uns des autres.
La Figure 3 illustre ce cas (le domaine d’application du service de sécurité défini dans l’en-tête 2 est
représenté par des cases en grisé).
© ISO 1999 – Tous droits réservés 7
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments CORPS DU
UNH/ segments segments segments de UNT/
d’en-tête d’en-tête d’en-tête MESSAGE/
UNO de fin de de fin de fin de UNP
de de de OBJET
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 3 — Domaine d’application: groupe de segments d’en-tête de sécurité et corps
du message/objet seulement (schéma simplifié)
2. Le calcul commence par, et comprend, le groupe courant de segments d’en-tête de sécurité jusqu’au groupe
de segments de fin de sécurité associé. Dans ce cas, le groupe courant de segments d’en-tête de sécurité,
le corps du message, ou l’objet, et tous les autres groupes de segments d’en-tête de sécurité et de fin de
sécurité imbriqués, doivent entrer dans ce domaine.
Le domaine d’application doit comprendre tous les caractères à partir du premier caractère, à savoir «U» du
groupe courant de segments d’en-tête de sécurité, jusqu’au séparateur précédant le premier caractère du
groupe de segments de fin de sécurité associé, les deux compris.
La Figure 4 illustre ce cas (le domaine d’application du service de sécurité défini dans l’en-tête de sécurité 2
est représenté dans les cases en grisé).
Groupe de Groupe de Groupe de Groupe Groupe Groupe
segments segments segments CORPS DU de de de
UNH/ UNT/
d’en-tête d’en-tête d’en-tête MESSAGE/ segments segments segments
UNO UNP
de de de OBJET de fin de de fin de de fin de
sécurité 3 sécurité 2 sécurité 1 sécurité 1 sécurité 2 sécurité 3
Figure 4 — Domaine d’application: du groupe de segments d’en-tête de sécurité au groupe de segments
de fin de sécurité (schéma simplifié)
Pour chaque service de sécurité ajouté,l’une des deux démarches peut être retenue.
Dans les deux cas, la relation entre le groupe de segments d’en-tête de sécurité et le groupe de segments de fin
de sécurité associé doit être fournie par les éléments de données «Numéro de la référencedela sécurité» des
segments USH et UST.
5.2 Principes d’utilisation
5.2.1 Choix du service
Le groupe de segments d’en-tête de sécurité peut comporter les informations générales qui suivent :
� servicedesécurité appliqué
� identification des intervenants impliqués
� mécanismedesécurité utilisé
� valeur «Unique» (numéro de séquence et/ou horodatage)
� non-répudiation de demande de réception
Si plus d’un servicedesécurité est requis pour la même structure EDIFACT, le groupe de segments d’en-tête de
sécurité peut alors être présent plusieurs fois. Ce sera le cas lorsque plusieurs couples d’intervenants seront
impliqués. Cependant si plusieurs services sont requis entre le même couple d’intervenants, ils peuvent être
incorporés dans une seule paire de groupes de segments d’en-tête et de findesécurité, puisque certains services
en comportent implicitement d’autres.
8 © ISO 1999 – Tous droits réservés
5.2.2 Authenticité
Si l’authentification de l’origine d’une structure EDIFACT est requise, elle doit être fournie conformément aux
principes définis dans l’ISO 10181-2, par l’utilisation d’une paire appropriée de groupes de segments d’en-tête et
defindesécurité.
Le servicedesécurité de l’authentification de l’origine doit être défini dans le segment USH et l’algorithme, être
identifié dans le segment USA du groupe de segments 1. Cet algorithme doit être symétrique.
L’intervenant jouant le rôle d’initiateur de sécurité doit calculer une valeur de l’authenticité qui doit être véhiculée
dans le segment USR du groupe de segments de fin de sécurité.L’intervenant jouant le rôle de destinataire doit
vérifier la valeur de l’authenticité.
Ce service pouvant comporter un service d’intégrité peut être obtenu en tant que sous-produit de service de non-
répudiation de l’origine.
Si la mise en œuvre appropriéedeceservice «d’authentification de l’origine», fondée sur un matériel infalsifiable
ou sur des tiers certificateurs, est assurée, elle peut être considérée comme une instance de service de «non-
répudiation de l’origine». Cette pratique doit être définie dans l’accord d’échange.
5.2.3 Intégrité
Si l’intégrité du contenu d’une structure EDIFACT est requise, elle doit être fournie conformément aux principes
définis dans l’ISO 10181-6, par l’utilisation d’une paire appropriée de groupes de segments d’en-tête et de fin de
sécurité.
Le service sécurisé de l’intégrité doit être défini dans le segment USH et l’algorithme, identifié dans le segment
USA du groupe de segments 1. Il doit s’agir d’une fonction de hachage ou d’un algorithme symétrique.
L’intervenant jouant le rôle d’initiateur de la sécurité doit calculer une valeur d’intégrité qui doit être véhiculée dans
le segment USR du groupe de segments de fin de sécurité.L’intervenant jouant le rôle de destinataire de la
sécurité doit vérifier la valeur de l’intégrité.
Ce service peut être obtenu en tant que sous-produit du service de l’authentification de l’origine ou de non-
répudiation de l’origine.
Si l’intégrité d’une séquence est requise, le groupe de segments d’en-tête doit contenir, soit, un numéro de
séquence de sécurité, soit, un horodatage de sécurité, ou bien les deux, et il conviendra d’utiliser les services
d’intégrité du contenu ou d’authentification de l’origine ou de non-répudiation de l’origine.
5.2.4 Non-répudiation de l’origine
Si la non-répudiation de l’origine d’une structure EDIFACT est requise, elle doit être fournie conformément aux
principes définis dans l’ISO 10181-4, par l’utilisation d’une paire appropriée de groupes de segments d’en-tête et
defindesécurité.
Le service sécurisé de non-répudiation de l’origine doit être défini dans le segment USH et l’algorithme de
hachage, identifié dans le segment USA du groupe de segments 1 et l’algorithme asymétrique utilisé pour la
signature, dans les segments USA du groupe de segments 2, si des certificats sont utilisés.
Si le certificat n’est pas véhiculé dans le message/paquet, l’algorithme asymétrique doit être implicitement connu
de l’intervenant récepteur. Dans ce cas, l’algorithme asymétrique doit être défini dans l’accord d’échange.
L’acteur jouant le rôle d’initiateur de la sécurité doit calculer une valeur numérique qui doit être véhiculée dans le
segment USR du groupe de segments de fin de sécurité.L’acteur jouant le rôle de destinataire doit vérifier la
valeur de la signature numérique.
Ce service comprend également les services d’intégrité et d’authentification de l’origine.
© ISO 1999 – Tous droits réservés 9
5.3 Représentation interne et filtres assurant la conformitéà la syntaxe EDIFACT
L’utilisation d’algorithmes mathématiques permettant de calculer les valeurs d’intégrité et les signatures
numériques pose deux difficultés.
La première difficulté réside dans le fait que le résultat du calcul dépend de la représentation interne du jeu de
caractères. Ainsi, le calcul de la signature numérique par l’émetteur et sa vérification par le destinataire doivent
être exécutés en utilisant la même codification du jeu de caractères. En conséquence, l’expéditeur peut indiquer la
représentation utilisée pour donner le résultat initial de la validation de la sécurité.
La seconde difficulté réside dans le fait que le résultat du calcul constitue apparemment un profil binaire aléatoire.
Cette situation pose des problèmes en cours de transmission et au niveau du logiciel d’interprétation. Pour pallier
ces difficultés, le profil binaire peut être appliqué de façon réversible à une représentation particulière de jeu de
caractères utilisé au moyen d’une fonction de filtre. Pour simplifier, une seule fonction de filtre doit être utiliséepour
chaque service de sécurité. Toute apparition d’un caractère d’anomalie de terminaison importé par cette
application est traité en intégrant une séquence d’échappement.
6Règles d’utilisation des groupes de segments d’en-tête et de fin de sécurité au niveau
de l’échange et des groupes pour l’EDI par lots.
6.1 Sécurité au niveau des groupes et de l’échange - Sécurité intégrée aux messages
Les risques pouvant menacer la sécurité de la transmission d’un message/paquet et les services de sécurité qui en
traitent, décrits dans les annexes C et D, valent également au niveau des groupes et de l’échange.
Les techniques décrites dans la précédente section qui s’appliquent à la sécurité des messages/paquets peuvent
également s’appliquer à l’échange et aux groupes.
Lorsque la sécurité est appliquée au niveau du groupe ou de l’échange, les mêmes groupes d’en-tête et de fin de
sécurité que ceux décrits au niveau d’un message/paquet, doivent être utiliséset unsystème de références
croisées doit toujours s’appliquer au même niveau, même si la sécurité vise séparément plus d’un niveau.
Lorsque la sécurité s’applique au niveau d’un message/paquet, la structure protégée est le corps du message ou
l’objet. Au niveau du groupe, c’est l’ensemble des messages/paquets du groupe dont tous les en-têtes et les fins
des messages/paquets. Au niveau de l’échange, c’est l’ensemble des messages/paquets ou des groupes de
l’échange, dont tous les en-têtes et les fins des messages/paquets ou des groupes.
10 © ISO 1999 – Tous droits réservés
6.1.1 Groupe de segments d’en-tête et de fin de sécurité
La Figure 5 décrit un échange illustrant l’application de la sécurité aux niveaux d’un échange et d’un groupe.
ECHANGE
Groupe(s) Groupe(s)
de segments
de segments
: Soit : Seulement
Soit Seulement
UNZ
UNB
UNA
d'en-tête de
de fin de
GROUPE(S)
PAQUET(S)
sécurité
sécurité
Groupe(s)
Groupe(s)
de segments
de segments
UNG
MESSAGE(S)/PAQUET(S) UNE
d'en-tête de
de fin de
sécurité
sécurité
Figure 5—Échange illustrant l’application de la sécurité aux niveaux de l’échange
et des groupes (schéma simplifié)
6.1.2 Structure des groupes de segments d’en-tête et de fin de sécurité
Tableau 3 — Table de segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau de l’échange uniquement)
Etiquette Nom S R
UNB En-tête d’échange M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M1 I
USA Algorithme de sécurité C3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C3 I I
USR Résultat de la sécurité C 1 --------+
Groupe(s)ou Message(s)/Paquet(s)
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M1 I
USR Résultat de la sécurité C 1 ----+
UNZ Fin d’échange M 1
© ISO 1999 – Tous droits réservés 11
Tableau 4 — Table de segments des groupes de segments d’en-tête et de fin de sécurité
(sécurité au niveau des groupes uniquement)
Etiquette Nom S R
UNG En-tête de groupe M 1
----- Groupe de segments 1------------ C 99 --------+
USH En-tête de sécurité M1 I
USA Algorithme de sécurité C3 I
----- Groupe de segments 2------------ C 2 ----+ I
USC Certificat M 1 I I
USA Algorithme de sécurité C3 I I
USR Résultat de la sécurité C 1 --------+
Message(s)/Paquet(s)
----- Groupe de segments n------------ C 99 ----+
UST Fin de sécurité M1 I
USR Résultat de la sécurité C 1 ----+
UNE Fin de groupe M 1
NOTE L’en-tête d’échange UNB, la fin de l’échange UNZ, l’en-tête de groupe UNG et la fin de groupe UNE sont décrits
dans la Partie 1 de l’ISO 9735. Ils ne sont pas décrits plus loin dans la présente partie.
Toutes les spécifications des segments et des éléments de données peuvent être consultées dans l’annexe B.
6.1.3 Domaine d’application de la sécurité
La sécurité peut s’appliquer dans deux domaines :
1. Le calcul de chacune des valeurs d’intégrité et d’authentification et des signatures numériques commence
par, et comprend, le groupe de segments d’en-tête de sécurité et le(s) groupe(s) ou message(s)/paquet(s),
eux-mêmes. Dans ce cas, aucun autre groupe de segments d’en-tête ou de fin de sécurité ne doit entrer
dans ce domaine.
Le décompte du groupe de segments d’en-tête de sécurité doit être effectuéà partir du premier caractère, à
savoir «U», jusqu’au séparateur terminant le groupe de segments d’en-tête de sécurité, les deux compris et
le(s) groupe(s) ou message(s)/paquet(s), à partir du premier caractère suivant le séparateur terminant le
dernier groupe de segments d’en-tête de sécurité jusqu’au séparateur précédant le premier caractère du
premier groupe de segments de fin de sécurité, les deux compris.
Ainsi l’ordre dans lequel les services de sécurité intégrés de cette façon sont exécutés, n’est pas imposé.Ils
sont totalement indépendants les uns des autres.
Les Figures 6 et 7 illustrent ce cas (le domaine d’application du service de sécurité défini dans l’en-tête 2 est
représenté par des cases en grisé).
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments GROUPE (S) OU
segments segments segments
UNB d’en-tête d’en-tête d’en-tête MESSAGE(S) UNZ
de fin de de fin de de fin de
de de de /PAQUET(S)
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 6 — Domaine d’application: groupe de segments d’en-tête de sécurité et groupe(s)
ou message(s)/paquet(s) uniquement (schéma simplifié)
12 © ISO 1999 – Tous droits réservés
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments
MESSAGE(S) segments segments segments
UNG d’en-tête d’en-tête d’en-tête UNE
/PAQUET(S) de fin de de fin de de fin de
de de de
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 7 — Domaine d’application: groupe de segments d’en-tête de sécurité
et message(s)/paquet(s) uniquement (schéma simplifié)
2. Le calcul commence par, et comprend, le groupe courant de segments d’en-tête de sécurité jusqu’au groupe
de segments de fin de sécurité associé. Dans ce cas, le groupe courant de segments d’en-tête de sécurité,
le(s) groupe(s) ou message(s)/paquet(s) et tous les autres groupes de segments d’en-tête de sécurité et de
findesécurité imbriqués, doivent entrer dans ce domaine.
Le domaine d’application doit comprendre tous les caractères à partir du premier caractère, à savoir «U» du
groupe courant de segments d’en-tête de sécurité, jusqu’au séparateur précédant le premier caractère du
groupe de segments de fin de sécurité associé, les deux compris.
Les Figures 8 et 9 illustrent ce cas (le domaine d’application du service de sécurité défini dans l’en-tête de
sécurité 2 est représenté dans les cases en grisé).
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments GROUPE(S) OU
segments segments segments
UNB d’en-tête d’en-tête d’en-tête MESSAGE(S) UNZ
de fin de de fin de de fin de
de de de /PAQUET(S)
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 8 — Domaine d’application: du groupe de segments d’en-tête de sécurité au groupe de segments
de fin de sécurité (schéma simplifié)
Groupe de Groupe de Groupe de
Groupe de Groupe de Groupe de
segments segments segments
MESSAGE(S) segments segments segments
UNG d’en-tête d’en-tête d’en-tête UNE
/PAQUET(S) de fin de de fin de de fin de
de de de
sécurité 1 sécurité 2 sécurité 3
sécurité 3 sécurité 2 sécurité 1
Figure 9 — Domaine d’application: du groupe de segments d’en-tête de sécurité au groupe de segments
de fin de sécurité (schéma simplifié)
Pour chaque service de sécurité ajouté,l’une des deux démarches peut être retenue :
Dans les deux cas, la relation entre le groupe de segments d’en-tête de sécurité et le groupe de segme
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...