DE10108825A1 - Provision of a secure architecture for voice over Internet protocol by splitting authentication, key management and data encryption between different OSI layers - Google Patents

Abstract

Secure architecture for voice over Internet protocol in which the security components, especially SSL/TLS or ISPEC and a VoIP application using the ITU recommendation H.235 are provided and in which key management and the authentication protocol are separated from the data protection protocol. Optimally authentication, key management and data encryption operate on different layers.

Description

The subject of the application relates to a security architecture for Voice over Internetprotocol.

Current security architectures for Voice over Internet protocol (VoIP) are monolithic and either work

• a) completely in the application layer (H.235 [2] with key management and RTP data encryption as data backup), see Fig. 1 or
• b) use existing security components such as SSL / TLS (see [1], [7]) or IPSec (see [7]) on OSI layers 4 or 3 below the VoIP application, see Fig. 2.

In case a) the key management and the data locks processing completely within the application; in the case b) the "black box" security component performs the key management ment and data encryption.

Both process architectures are known to have their and disadvantages. In a) can be based on the real-time critical VoIP application and its specific security needs design a tailored security concept and apply. There can be certain assumptions or pre exposures of the overall scenario are used to advantage the. This allows protocol steps for key management with the signaling and mutual syn energy effects can be achieved. This enables z. B. a so-called called secure 2-way Fastconnect. However, the Implementation effort in the application regarding security clearly because the security protocols are completely imple have to be mented. The integration effort of Si Security functions "in the application" can be quite considerable  be because there are hardly any standardized within the application Interfaces for the security are defined and the Si security functions proprietary in the respective application need to be integrated. This fact is reflected in it high implementation costs and costs.

In b) all security procedures are carried out by a proto generic security layer for the application provided; there is a reference to the application However not; so that no real performance advantages can be settled. In fact, there are additional ones here Protocol steps and more complex security mechanisms are required to become one under weak conditions secure connection to come; the real-time aspect had in Design of such security components played no role. As a result, however, there is no longer a fastconnect pass. In return, the implementation effort is reduced by the Reuse of generic and existing platforms those, tested safety components. Because only about standar Accessed interfaces, there is almost no Integration effort towards application; with existing Safety components can reduce the integration effort and costs can be saved. However, these compos offer have an abundance of algorithms and procedures that are described in are not used so often in practice. Thereby these security components are quite extensive and carry not exactly compact overall implementations.

The standard H.235 [2] offers various security features le on to protect the H.225.0 RAS and H.225.0 call Signaling and to secure the RTP media data. Kei The process and techniques satisfy all aspects of the above problem, a standardized, interoperable A solution is therefore currently not possible.

• - With Annexes D, E and F of H.235, procedures according to a) are implemented at the application level. It is about the authentication of the involved instances, integrity protection of the signaling data, key agreement or key management as well as the security of the media data by encryption z. B. Various crypto-algorithms (symmetrical, asymmetrical), security mechanisms are used. By assuming that the communicating entities such as multimedia terminal and gatekeeper (GK) are time-synchronized, passwords or public / private keys out-of-band already exist, key management can be significantly optimized and simplified and who can be piggybacked with use the signaling so that a secure fast connect is possible and no additional handshakes are required, see Fig. 3.
• - With SSL / TLS (see [1], [7]) there is a standard component for securing TCP transport connections on the OSI layer 4. This component is e.g. B. in web browsers and operating systems (Windows) available. Before an application can securely communicate peer-to-peer, the SSL / TLS component must process a complex security handshake in order to carry out authentication and key management; in the worst case, up to 4 additional handshakes. The elaborate handshake is necessary because no special assumptions have been made about the systems and a high degree of flexibility is to be achieved. Only after this partial functionality has been brought in can the application data be saved, see FIG. 4.
• - IPSEC (see [7]) for the protection of IP data on OSI layer 3 and the generic key management protocol IKE pursues a similar goal as SSL / TLS. Here too, complex security handshakes (in the worst case, up to 6 additional handshakes) are required to establish a security association and then secure the IP data, see Fig. 5. IPSEC is also available in some operating systems (Windows).
• - H.235 also allows the use of SSL / TLS or IPSEC, but the prefabricated security components are naively combined with the application so that no secure fastconnect can be reached; see Figs. 4, 5.

The subject of the registration is based on the problem, one To find a middle ground between the extremes mentioned at the beginning a) and b) in such a way that as many advantages as possible probably from a) and b) and at the same time the Disadvantages of the individual solutions are as small as possible.

The problem is solved by an object with the characteristics of Claim 1 solved.

A conscious decomposition takes place on the subject of the application tion of security components along new borders and the Recombination of the parts to a new composite Whole.

The solution to the problem is that in a Ge overall security architecture of existing security compo nents such as SSL / TLS or IPSEC and a VoIP application H.235 the key management and authentication protocol from Backup protocol is disconnected. The subtasks (Au authentication + key management and data encryption) lau and advantageously on different layers complement one another.

On the one hand, the key management protocol is integrated into the VoIP application via H.235 and at the same time eliminated or bypassed in the lower layer. On the other hand, the data backup function remains on the lower layer and can therefore be omitted in the application, see Fig. 6.

In the case of SSL / TLS, the SSL / TLS key management protocols such as "handshake layer protocol", "change cipher spec protocol", "alert protocol" and "application data protocol" can be omitted and saved. Instead, this functionality is implemented within the VoIP application using the security and key management protocols there, see FIGS . 7 and 9; this would only be communicated via the interface C in FIG. 9. Different key management protocols are possible (symmetrical with administered keys, asymmetrical with certificates).

In the case of IPSEC, the IPSEC key management protocol IKE can be omitted. Here, too, the VoIP application realizes the required functionality, see Fig. 8.

A split security architecture as indicated gives the following advantages:

• - Because the authentication and key management in the application runs simplified and no longer in the generic security component itself, arise Performance advantages for realtime-critical applications. With the permissible assumptions for VoIP (time synchronization) can the protocol steps for key management with the Signaling are linked; VoIP is a secure 2-way fast connect possible. By eliminating the SSL / TLS Handshake protocol results in a fast connection establ.
• - Proven security components are largely restored functions are eliminated without this leads to special implementation effort because standard interfaces are used. By reusing There are a number of advantages as well tested security, low costs etc.
• - The VoIP application is partially relieved by the Data encryption function no longer application-specific must be realized. This reduces the reali sierungsaufwand. The generic security components can also  be streamlined by the key management ment functionality is removed. This creates overall more compact systems.
• - Since generic subcomponents are used, you can use This security architecture also has similar applications be secured. One example is the SIP protocol, where an analog approach is conceivable.
• - Security is increased by a more extensive Protection of data packets at a lower protocol level takes place in comparison to the protection of data on applica tion level.
• - It is also conceivable that the signaling messages (except for the initial handshake) also backed up as data become. That increases security.
• - If an existing security channel is also available for the application-specific key management (with symmetric administered keys) is used Media key distribution with SSL / TLS almost without opening wall; costly Diffie-Hellman operations become one saved.
• - Provided that the SSL / TLS data protection protocol also on UDP is available, the signaling above it can also be protected accordingly. That extends the one security procedure and increases security.

The idea as described for H.323 can be analogous also apply to the SIP protocol [5]. This creates conceptual interoperability.

The subject of registration is shown below using the example of H.323 / H.235 to the extent necessary for understanding explained in more detail with reference to figures. Show:  

Fig. 1 is a security architecture with security functions in the application,

Fig. 2 component a security architecture with standard security,

Fig. 3 H.323 / H.235 stack with security in the application,

Fig. 4 H.323 / H.235 stack with SSL / TLS,

Fig. 5 H.323 / H.235 stack with IPSEC and IKE,

Fig. 6 security architecture with key management in the Appli cation and simplified Sicherheitskomponete with stan dard backup,

Fig. 7 H.323 / H.235 stack with SSL / TLS record layer and H.235 key management in the application and

Fig. 8 H.323 / H.235 stack with IPSEC, and H.235 key management in the application

Fig. 9 SSL / TLS layer structure and interfaces and

Fig. 10 H.323 protocol sequence of Fig. 6.

In the figures, the same designations denote the same elements, interfaces being designated as follows:
A, B, H: standard socket interface
C: new TLS internal TLS interface (with empty TLS hands hake protocol)
D, E, F, G: TLS record layer interface.

Legend

K _AB

: Diffie-Hellman shared secret between A and B, from which an SSL / TLS session key is generated.
K _BC

: Diffie-Hellman shared secret between B and C, from which an SSL / TLS session key is generated.
K _AC

: Media session key between A and C.
{X} K: Encryption of X with key K, or application of key K on date X.

credentials

[1] RFC 2246: "The TLS Protocol Version 1.0", T. Dierks, C. Allen., IETF, January 1999.
[2] ITU-T Recommendation H.235v2: "Security and encryption for H-Series (H.323 and other H.245-based) multimedia terms), ITU-T Recommendation, 2000.
[3] ITU-T Recommendation H.225.0, Media Stream Packetization and Synchronization on Non-Guaranteed QoS LANs, 2000
[4] ITU-T Recommendation H.245, Control Protocol for Multimedia Communication, 2000.
[5] RFC 2453bis: "SIP: Session Initiation Protocol"; draft ietf-sip-rfc2453bis-02.txt, IETF, September 2000.
[6] E. Rescorla: "SSL and TLS", Addison-Wesley, 2001.
[7] N. Doraswamy, D. Harkins: "IPSec", Prentice Hall, 1999.

Claims (2)

1. Security architecture for Voice over Internet protocol in the security components, in particular SSL / TLS or IPSEC, and a VoIP application using ITU recommendation H.235 are characterized in that the key management and the authentication protocol are separated from the data security protocol. 2. Security architecture according to claim 1, characterized in that the subtasks (authentication + key management and data encryption) run on different layers.