ETSI ETS 300 841 ed.1 (1998-01)

Telecommunications security; Integrated Services Digital Network (ISDN); Encryption key management and authentication system for audiovisual services

DE/SEC-002309

Telekomunikacijska varnost – Digitalno omrežje z integriranimi storitvami (ISDN) – Sistem za upravljanje in avtentikacijo s ključem za šifriranje pri avdiovizualnih storitvah

General Information

• Status: Published
• Publication Date: 06-Jan-1998
• Technical Committee: SEC - Security
• Current Stage: 12 - Completion
• Due Date: 27-Jan-1998
• Completion Date: 07-Jan-1998
• Ref Project: SIST ETS 300 841 E1:2003 - Telecommunications security; Integrated Services Digital Network (ISDN); Encryption key management and authentication system for audiovisual services

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 841 E1:2003
01-december-2003
7HOHNRPXQLNDFLMVNDYDUQRVW±'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1±
6LVWHP]DXSUDYOMDQMHLQDYWHQWLNDFLMRVNOMXþHP]DãLIULUDQMHSULDYGLRYL]XDOQLK
VWRULWYDK
Telecommunications security; Integrated Services Digital Network (ISDN); Encryption
key management and authentication system for audiovisual services
Ta slovenski standard je istoveten z: ETS 300 841 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
33.160.01 Avdio, video in avdiovizualni Audio, video and audiovisual
sistemi na splošno systems in general
SIST ETS 300 841 E1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ETS 300 841 E1:2003

---------------------- Page: 2 ----------------------

SIST ETS 300 841 E1:2003
EUROPEAN ETS 300 841
TELECOMMUNICATION January 1998
STANDARD
Source: Security Reference: DE/SEC-002309
ICS: 33.020
Key words: ISDN, multimedia, security
Telecommunications Security;
Integrated Services Digital Network (ISDN);
Encryption key management and authentication system
for audiovisual services
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1998. All rights reserved.

---------------------- Page: 3 ----------------------

SIST ETS 300 841 E1:2003
Page 2
ETS 300 841: January 1998
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

---------------------- Page: 4 ----------------------

SIST ETS 300 841 E1:2003
Page 3
ETS 300 841: January 1998
Contents
Foreword .5
1 Scope .7
2 Normative references.8
3 Definition .9
4 Abbreviations.9
5 Message system and key exchange .9
5.1 Message channel.9
5.2 Message formats .9
5.2.1 Identifier.10
5.2.2 Length .10
5.2.3 Bit string .10
5.3 Starting the privacy system.11
5.3.1 Starting messages.11
5.3.2 Session key exchange .12
6 ISO 8732 key management .13
6.1 Introduction .13
6.2 Key management architecture.13
6.3 Key management environments .14
6.4 Cryptographic service message exchanges.14
6.5 Example of ISO 8732 message exchange .15
7 Extended Diffie-Hellman key distribution.16
7.1 Introduction .16
7.2 The basic protocol .16
7.2.1 *key* exchange method .16
7.2.2 Derivation of the *key*.17
7.3 Diffie-Hellman messages.18
7.3.1 *key* exchange information.18
7.3.2 Intermediate *key* exchange information .18
7.3.3 Check code information from MCU.18
7.4 Extension for line checks.19
8 RSA based operation .19
8.1 Introduction .19
8.1.1 General.19
8.1.2 Notation .20
8.2 System set up .20
8.3 Authentication key generation and distribution .21
8.4 Certification.21
8.5 Alternative solution for certification without a GCA.22
8.6 Authentication of entities.23
8.6.1 Simultaneous transmission of RSA.P1 messages.24
8.7 Generation of key for encryption of session keys .25
8.8 RSA messages .26
8.8.1 Authentication initiation.26
8.8.2 Authentication response.27
8.8.3 Authentication complete.28
8.8.4 Authentication failed .28

---------------------- Page: 5 ----------------------

SIST ETS 300 841 E1:2003
Page 4
ETS 300 841: January 1998
9 MCU operation. 28
Annex A (informative): Bibliography . 29
History. 30

---------------------- Page: 6 ----------------------

SIST ETS 300 841 E1:2003
Page 5
ETS 300 841: January 1998
Foreword
This European Telecommunication Standard (ETS) has been produced by the Security (SEC) Technical
Committee of the European Telecommunications Standards Institute (ETSI).
Transposition dates
Date of adoption of this ETS: 24 October 1997
Date of latest announcement of this ETS (doa): 30 April 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 October 1998
Date of withdrawal of any conflicting National Standard (dow): 31 October 1998

---------------------- Page: 7 ----------------------

SIST ETS 300 841 E1:2003
Page 6
ETS 300 841: January 1998
Blank page

---------------------- Page: 8 ----------------------

SIST ETS 300 841 E1:2003
Page 7
ETS 300 841: January 1998
1 Scope
A privacy system consists of two parts, the confidentiality mechanism or encryption process for the data,
and a key management subsystem. This European Telecommunication Standard (ETS) is based on
ITU-T Recommendation H.234 [1] and describes authentication and key management methods for a
privacy system suitable for use in narrowband audiovisual services conforming to ITU-T
Recommendations H.221 [5], H.230 [6] and H.242 [8]. The confidentiality specification is independent, and
is contained in the separate ITU-T Recommendation H.233 [7].
Privacy is achieved by the use of secret keys. The keys are loaded into the confidentiality part of the
privacy system and control the way in which the transmitted data is encrypted and decrypted. If a third
party gains access to the keys being used then the privacy system is no longer secure.
The maintenance of keys by users is thus an important part of any privacy system. Three alternative
practical methods of key management are specified in this ETS. For cases where automated key
management is not feasible, an unspecified alternative such as manual key management can be used.
The first is identified as ISO 8732 [2]. It is based on manually installed keys in systems that physically
afford those keys a high measure of protection, and then an automated exchange of keys encrypted under
the manually distributed keys. The algorithm used for encrypting these automatically distributed keys is
normally the same as that used for encrypting the communication itself. The security of automatically
distributed keys depends on the security of the manually distributed keys.
Automatically distributed keys may be used for a single session, or may be used for multiple sessions in a
given period of time (e.g., a month). ISO 8732 [2] contains protocols not only for the automated exchange
of information between the two terminals, but also physical protocols for ensuring the security of the
manual distribution of keys as well.
There are two distinct environments: direct point-to-point (two layer), where the two terminals share a
common key, and, a three-layer environment, where the two terminals who wish to communicate do not
share a common key, but use the facilities of a mutual third party, with whom each of them do share a
common key. The interfaces to the third party are outside this ETS, although it is required to distinguish
between the two environments.
NOTE 1: Session key exchange specified in subclause 5.3.2 is functionally duplicated in
ANSI X.9.17 [3], in that the keys automatically distributed in ANSI X.9.17 [3] are strong
enough to be used as session keys. However, to follow the form of this
recommendation, these keys are referred to as *key* in subclause 5.3.2.
The second is a simple yet secure method known as "extended Diffie-Hellman", which generates and
exchanges keys automatically via the system itself (this key exchange is itself encrypted). It requires no
action from users until keys have been exchanged; they are then advised to confirm verbally that the
same check sequence is available at each terminal. The method is quite adequate to prevent outsiders
listening in on an audiovisual call carried over a satellite channel, for example. To defeat the system, it
would be necessary for the interloper to intercept totally the bi-directional communication before
encryption had been activated, and to exchange keys with both parties, pretending to each that it is the
other legitimate party. The method does not provide authentication.
The third method is again more complex and provides a higher degree of privacy and also provides
authentication of audiovisual service entities (terminals, Multi-point Control Units (MCUs), etc.). The public
key cryptosystem invented by Rivest, Shamir and Adleman ("the RSA method") is very similar to the public
key method specified in ITU-T Recommendation X.509 [9] and uses the RSA algorithm. The method
requires the establishment of a security agency, available to the whole population of entities which require
interconnectability: certification is effectively "off-line", and relies on the integrity of the agency. This
authentication mechanism allows the parties involved in a conference call to be identified to others in an
assured manner, and can be operated in multipoint as well as point-to-point calls.
All methods require the use of an associated error-free clear channel.
NOTE 2: Access control, integrity and non-repudiation are not provided by any of these
methods.
A fourth method is referred to in this ETS as "manual key exchange".

---------------------- Page: 9 ----------------------

SIST ETS 300 841 E1:2003
Page 8
ETS 300 841: January 1998
Manual key exchange is defined as the users entering key encryption keys directly into terminals, without
H.KEY message exchanges. The same key is entered at both locations. The length of the keys is
dependent on the encryption algorithm. The bit order for the keys is Most Significant Bit (MSB) entered
first and Least Significant Bit (LSB) entered last. The actual mechanism for entering the keys into the
terminal is terminal dependent and beyond the scope of this ETS.
Examples are given below:
- use a telephone keypad to enter: (MSB) 00111010.01110100 (LSB);
- download the same from a computer;
- use a keyboard to enter the same as hexadecimal characters: (MSB) 3A.74 (LSB).
Manual entry may occur prior to initiating the call, or while in a call. In the latter case, the parties may
decide to invoke encryption while in a conference, enter a key using the interface provided by the terminal,
and then initiate encryption through the terminal's user interface. It is when encryption is requested
through the user interface that the Bit-rate Allocation Signal (BAS) code "Encrypt-On" is sent, the
Encryption Control Signal (ECS) channel is opened, encryption algorithms are selected, manual mode of
key management is agreed to, and session keys are exchanged.
For an encryption system to be regarded as private all conferees should be aware of who/what has
access to unencrypted data, whether other conferees or equipments such as MCUs or conversion
facilities. This requires an initial set-up period before a conference starts so that entities can authenticate
each other. Thus all entities that have access to unencrypted data are identified in an assured manner to
all other entities before the conference commences. The authentication framework also provides
information to any network provider, for example billing information for an MCU call.
If unencrypted data is available at the MCU (a so-called "trusted MCU") the equipment should be part of
any authentication framework. Users should also be made aware that there is a trusted MCU in the
network.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1] ITU-T Recommendation H.234: "Key Management Procedures".
[2] ISO 8732: "Banking Key Management".
[3] ANSI X.9.17: "Financial Institution Key Management".
[4] ITU-T Recommendation X.209: "Specification of basic encoding rules for
Abstract Syntax Notation One (ASN.1)".
[5] ITU-T Recommendation H.221: "Frame structure for a 64 to 1 920 kbit/s
channel in audiovisual teleservices".
[6] ITU-T Recommendation H.230: "Frame-synchronous control and indication
signals for audiovisual signals".
[7] ITU-T Recommendation H.233: "Confidentiality system for audiovisual services".
NOTE: ITU-T Recommendation H.233 forms the basis of ETS 300 840 [10].
[8] ITU-T Recommendation H.242: "System for establishing communication
between audiovisual terminals using digital channels up to 2 Mbit/s".
[9] ITU-T Recommendation X.509: "The directory-authentication framework".

---------------------- Page: 10 ----------------------

SIST ETS 300 841 E1:2003
Page 9
ETS 300 841: January 1998
[10] ETS 300 840: "Telecommunications Security; Integrated Services Digital
Network (ISDN); Confidentiality system for audiovisual services".
[11] ITU-T Recommendation T.120: "Data protocols for multimedia conferencing".
[12] ISO/IEC 9979 Registration No. 0001 (B-CRYPT).
3 Definition
For the purposes of this ETS, the following definition applies:
*key*: key-encrypting key
4 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
ANSI American National Standards Institute
ASN.1 Abstract Syntax Notation 1 (see ITU-T Recommendation X.209 [4])
AVSE AudioVisual Service Entity (terminals, MCUs, etc.)
BAS Bit-rate Allocation Signal
CA Certification Authority
CCA Country Certification Authority
CKD Key Distribution Centre
CKT Key Translation Centre
CSM Cryptographic Service Message
DES Data Encryption Standard
DSM Disconnected Service Message
ECS Encryption Control Signal
ExOR Exclusive-OR (logical operator)
GCA General Certification Authority
ILC Identifier, Length, Content
KSM Key Service Message
LSB Least Significant Bit
MCU Multi-point Control Unit
MLP Multi-Layer Protocol
MSB Most Significant Bit
RSA public key cryptosystem invented by Rivest, Shamir and Adleman
RSM Response Service Message
SE Session Exchange
5 Message system and key exchange
5.1 Message channel
The system described below consists of a number of defined messages conveyed in sequence between
the two ends of the link. The error-free channel required for this purpose is described in ITU-T
Recommendation H.233 [7], where reference is made to Session Exchange (SE) blocks.
5.2 Message formats
The messages used by the encryption system for key distribution and authentication are formatted in a
nested Identifier, Length, Content (ILC) form as described in ITU-T Recommendation X.209 [4]. The
length may be encoded in short form or long form. The indefinite form as defined in ITU-T
Recommendation X.209 [4] will not be used.
The messages described in this ETS allow the various messages to be identified by the encryption
system. The messages used by the encryption system shall also be identified by the message system as
belonging to the encryption system. The descriptions of the identifiers used by the messaging system for
that purpose are beyond the scope of this ETS.

---------------------- Page: 11 ----------------------

SIST ETS 300 841 E1:2003
Page 10
ETS 300 841: January 1998
A short description of some of the ITU-T Recommendation X.209 [4] definitions used within this ETS is
given in subclauses 5.2.1 to 5.2.3.
5.2.1 Identifier
An identifier is an octet with the structure shown in figure 1.
MSB LSB
CtCP tttt
Figure 1
The two bits CC, "Tag Class", define the type of identifier: this is 10 (context specific) for the identifiers
defined within this ETS.
The Primitive/Constructor (P) bit indicates whether the content is primitive or whether it is composed of
nested elements.
The 5-bit tag (ttttt) uniquely defines the identifier (according to its class).
Therefore, all identifiers in this ETS have the octet form: 1 0 P t t t t t .
1 2 3 4 5

5.2.2 Length
The length specifies the length in octets of the contents and is itself variable in length.
The short form is one octet long and shall be used in preference to the long form when L is less than 128.
Bit 8 has the value zero and bits 7-1 encode L as an unsigned binary number whose MSB and LSB are
bit 7 and bit 1, respectively.
The long form is from 2 to 127 octets long and is used when L is greater than or equal to 128 and less
1 008
than 2 . Bit 8 of the first octet has the value one. Bits 7-1 of the first octet encode a number one less
than the size of the length in octets as an unsigned binary number whose MSB and LSB are bit 7 and bit 1
respectively. L itself is encoded as an unsigned binary number whose MSB and LSB are bit 8 of the
second octet and bit 1 of the last octet, respectively. This binary number shall be encoded in the fewest
possible octets, with no leading octets containing the value 0.
5.2.3 Bit string
A bit string in primitive form has the bits packed eight to an octet and preceded by an octet that encodes
the number of unused bits in the final octet of the contents - from zero to seven - as an unsigned binary
number those MSB and LSB are bit 8 and bit 1 respectively.

---------------------- Page: 12 ----------------------

SIST ETS 300 841 E1:2003
Page 11
ETS 300 841: January 1998
5.3 Starting the privacy system
To start the system involves three messages, P0, P1, P2 which are detailed below. The privacy system is
invoked by sending a message (by either end) of type (P0). The message (P0) includes bits that describe
the mechanisms, ISO 8732 [2] and/or Diffie-Hellman and/or RSA, that the sender can handle. The
recipient of such a message determines the mechanism to use and responds with a message of type (P0)
or of type (P1) depending on the result.
If both send the (P0) message at the same time, the choice can still be made by comparison of the bit
fields exchanged:
- if both ends support the same mechanism, that is the one used; if more than one mechanism
is supported, then the order of preference is:
1) ISO 8732 [2]; then
2) Diffie-Hellman; then
3) RSA or ITU-T Recommendation X.509 [9]; and finally,
4) the unspecified option referred to in this ETS as "manual";
- if there is no common capability, the link cannot be encrypted.
5.3.1 Starting messages
Message name: Request privacy system (P0).
1 0 P t t t t t = 10000000
Message identifier:
1 2 3 4 5
Meaning: The sender of this message wishes to use an encryption system. This
message may be used to attempt to initiate encryption or in reply to another
P0 message.
Content: A primitive octet as shown below. The bit field within the content shows which
type of mechanism can be used. (MSB) 0000XDRM (LSB)
X is set to '1' if ISO 8732 is supported, or '0' if not.
D is set to '1' if Diffie-Hellman is supported, or '0' if Diffie-Hellman is not
supported.
R is set to '1' if RSA is supported, or '0' if RSA is not supported.
M is set to '1' if there is an unspecified key management system such as a
manual key entry, or '0' if not.
RequestEncryptionSystem ::= [0] IMPLICIT OCTET STRING
In the Abstract Syntax
Notation 1 (ASN.1):
In this message the content is always one octet long.
Cannot Encrypt (P1).
Message name:
Message identifier: 1 0 P t t t t t = 10000001
1 2 3 4 5
Meaning: Sent in reply to (P0). The sender of this message will not use an encryption
system.
This message has no content.
Content:
Message name: Failure to start encryption system (P2).
Message identifier: 1 0 P t t t t t = 10000010
1 2 3 4 5
The sender of this message has failed to start its encryption system. This
Meaning:
could be due to a key exchange failure, but for security reasons, no indication
of the cause of failure is given in the message.
This message has no content.
Content:

---------------------- Page: 13 ----------------------

SIST ETS 300 841 E1:2003
Page 12
ETS 300 841: January 1998
5.3.2 Session key exchange
The session keys used to encrypt the information are derived from the session key exchange. The
message containing the session keys is formatted as described herein, and encrypted using a key-
encrypting key (abbreviated to *key* in this ETS) derived from the authentication or *key* distribution
protocol. The distinction between these two types of key should be noted: the session keys are used in the
encryption/decryption of the audiovisual signal in its ITU-T Recommendations H.221 [5] frame, while the
*key* is only used in the encryption and decryption of the session key exchange.
The encryption mechanism involves keys of length N bits. A common *key* is established by the two
parties involved, and this also has a length of N bits; in the case of RSA there is a further authentication
#key# used to derive *key*.
The common *key* is used to encrypt four N-bit keys as described in this subclause (see figure 2). The
encryption method used shall be the same as that selected for encryption of the audiovisual signal, this
being indicated by transmission of the message P9 defined for the purpose in ITU-T Recommendation
H.233 [7].
The session key exchange message consists of an 8 bit message identifier, an initialization vector with
error correction, and a 4N-bit random value. Each end sends such a value, and derives therefrom the set
of 4 session keys. Each key is of length N bits, the value of N depending on the encryption algorithm to be
used (for example, in the case of B-CRYPT, N = 56) (see ISO/IEC 9979 Registration No. 0001 [12]).
The transmitted and received random numbers are processed as four N-bit blocks, as shown in figure 2.
first key bit last key bit
sent sent
T1 (N bits) T2 (N bits) T3 (N bits) T4 (N bits)
3N 4N
1 N 2N
first key bit last key bit
received received
R1 (N bits) R2 (N bits) R3 (N bits) R4 (N bits)
3N 4N
1 N 2N
Figure 2: Session key exchange bit ordering
Each of the four keys is formed by a bit-wise EXCLUSIVE-OR of one transmitted block and one received
block, maintaining bit ordering: that is, the most significant bit of the key (i.e. most significant bit of the first
byte or word of key data loaded into the encryption device) is formed by the bit-wise EXCLUSIVE-OR the
first two bits of the blocks. Using the bit ordering of figure 2, the four keys are derived as follows:
"Send encryption key #1" formed by block T1 EXCLUSIVE-OR block R3;
"Send encryption key #2" formed by block T2 EXCLUSIVE-OR block R4;
"Receive encryption key #1" formed by block T3 EXCLUSIVE-OR block R1;
"Receive encryption key #2" formed by block T4 EXCLUSIVE-OR block R2.
Encryption key #1 shall be used for encryption of the content of the ITU-T Recommendations H.221 [5]
framed signal as specified in clause A.3 of ITU-T Recommendations H.221 [5], "Encrypt-on". When Multi-
Layer Protocol (MLP) is ON under a BAS command in tables A.1 or A.2 of ITU-T Recommendations
H.221 [5], encryption of the MLP channel is as specified in ITU-T Recommendation T.120 [11] series,
using either the same key #1 or the alternative key #2.
The chosen algorithm may need parity on the keys - this is a local matter and does not form part of the
transmission.

---------------------- Page: 14 ----------------------

SIST ETS 300 841 E1:2003
Page 13
ETS 300 841: January 1998
The only check performed is on the overall 4N bits. If the complete 4N bit result of the "EXCLUSIVE-OR"
operation is zero (i.e. all four N-bit keys are zero), the keys are not loaded and the privacy system is not
invoked.
Session key exchange message (P6).
The message consists of the message identifier, a 96-bit initialization vector in default including error
correction bits, and a 4N-bit random number.
Message name: Here is Session Key Information (P6)
1 0 P t t t t t = 10100110
Message identifier:
1 2 3 4 5
Meaning: The sender of this message is exchanging session key information.
Content: A constructor containing the (unencrypted) initialization vector used for the
encryption of the session key data, and the encrypted session key information
in the format shown.
SessionKeyInformation ::= [6] IMPLICIT SEQUENCE{
In ASN.1:
initialization-vector [0] IMPLICIT BIT STRING,
session-key-information [1] IMPLICIT BIT STRING}
6 ISO 8732 key management
6.1 Introduction
ISO 8732 [2] provides a uniform process for the protection and exchange of cryptographic keys for
authentication and encryption. ISO 8732 [2] defines both manual and automated management of keying
material, including:
- control during the life of the keying material to prevent unauthorized disclosure, modification or
substitution;
- distribution of keying material to permit interoperability between cryptographic equipment or
facilities;
- ensuring the integrity of keying material during all phases of its life, including its generation,
distribution, storage, entry, use, and destruction;
- recovery in the event of failure of the key management process or when the integrity of the keying
material is questioned.
The algorithm used for encrypting the automatically distributed keys is normally
...