"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"". 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."