WO2007059944A1 - Sichere voice-over-ip-telefonie - Google Patents

Sichere voice-over-ip-telefonie Download PDF

Info

Publication number
WO2007059944A1
WO2007059944A1 PCT/EP2006/011200 EP2006011200W WO2007059944A1 WO 2007059944 A1 WO2007059944 A1 WO 2007059944A1 EP 2006011200 W EP2006011200 W EP 2006011200W WO 2007059944 A1 WO2007059944 A1 WO 2007059944A1
Authority
WO
WIPO (PCT)
Prior art keywords
connection
telecommunication terminal
voip
separate data
ssl
Prior art date
Application number
PCT/EP2006/011200
Other languages
English (en)
French (fr)
Inventor
Stephan Spitz
Kolja Vogel
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2007059944A1 publication Critical patent/WO2007059944A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment

Definitions

  • the present invention relates to a method for establishing a secure "Voice over IP" communication connection between telecommunication terminals and such telecommunication terminals.
  • IP Internet Protocol
  • IP Internet Protocol
  • LAN Local Area Network
  • WLAN Wireless LAN
  • IP internet protocol
  • video data can be transmitted over the Internet Protocol (IP) based connections, for example, and further data, e.g. Documents for the participants in the multimedia session.
  • VoIP connection refers to any type of IP-based session, in particular multimedia session, using VoIP protocols.
  • Special cases of VoIP connections are Internet telephony connections (IP-based telephony connections).
  • IP-based telephony connections IP-based telephony connections.
  • BBI Federal Office for Information Security
  • VoIP Voice over Internet Protocol
  • NIST National Institute of Standards and Technology
  • VoIP-specific protocols include the H.323 protocol and the H.323 Real-Time Transport Protocol (RTP) transport protocols for real-time transmission of voice and video data over packet-switched networks and SRTP (Secured RTP) for the encrypted real-time Transmission of voice and video data; SIP (Session Initiation Protocol) or H.323, the latter with one of the sub-protocols H.225 or H.245, for the signaling, in particular the connection establishment; the key management protocol MIKEY (Multimedia Internet Keying) based on the signaling protocol (eg SIP, H.225, H.245) or the key management protocol ZRTP based on the transport protocol RTP for authentication between subscribers on a VoIP connection, the generation of keys and key exchange for a subsequent encrypted connection to SRTP.
  • RTP Real-Time Transport Protocol
  • MIKEY is a key exchange process designed for multimedia applications and very efficient in terms of the number of round robin trips is.
  • MIKEY provides three modes: PSK - pre-shared keys, PKE public key and DH - Diffie-Helmann. The authentication is thus as strong as with SSL.
  • MIKEY unlike SSL, is still very young. There are so far only a few implementations, which is why MIKEY could not yet establish itself as safe.
  • VoIP Voice over IP
  • Internet telephony There are a number of open security issues in the technology called Voice over IP (VoIP) or Internet telephony, such as: As the assurance of mutual authentication of the parties and the confidentiality and integrity of the transmitted voice data.
  • VoIP Voice over IP
  • Internet telephony As the assurance of mutual authentication of the parties and the confidentiality and integrity of the transmitted voice data.
  • IP Internet Protocol
  • subscribers e.g. Caller and called, identified by their respective IP address, which may vary.
  • the voice data transmission takes place packet-oriented and the connection is not assigned a fixed transmission channel.
  • Data to be transmitted is divided into packets, each packet is provided with the called party's IP address, and the packets are sent to the called party's IP address, whereby the transmission paths of the individual packets are generally different.
  • Every VoIP connection begins with the signaling, in which a caller determines the IP address of a desired caller and notifies his own IP address.
  • the connection between the terminals of the caller and the caller is made via one or more connection servers, for example in the case of SIP via so-called proxy servers, in H.323 via so-called gatekeepers.
  • connection servers for example in the case of SIP via so-called proxy servers, in H.323 via so-called gatekeepers.
  • the transmission of the voice data and possibly further data takes place, which can now take place directly, without the interposition of connection servers.
  • the data is transmitted unencrypted (eg with RTP) or encrypted (eg with SRTP).
  • a mutual authentication of the subscribers is actually carried out for a VoIP connection, this happens during the signaling phase.
  • subscribers to a VoIP connection authenticate each other via the exchange of certificates, checksums and / or signatures that are created by cryptographic calculations with personal authentication data of the subscribers.
  • the signaling is carried out according to a signaling protocol, for example SIP or H.323, the latter with H.225 or H.245.
  • the cryptographic calculations for the authentication and / or for the generation and / or exchange of transport keys are performed according to a key management protocol, for example MIKEY or ZRTP.
  • a protocol used for VoIP telephony can use the IP protocol ("Internet Protocol") with the optional IPsec security protocol (“secure IP”). as the network layer (OSI layer 4) and the UDP protocol ("User Datagram Protocol”) as well as the RTP protocol ("Real-Time Transport Protocol”) as a transport layer (OSI layer 5), whereby the IP protocol ensures The first layer independent of the transmission medium for the forwarding of the individual voice data packets
  • IP protocol which corresponds approximately to the TCP layer in the TCP / IP data transmission model, is particularly suitable for VoIP telephony and offers a simple interface to the IP Network layer while the RTP Protocol that regulates the continuous transmission (“streaming") of audio-visual data over IP-based networks.
  • the higher-level application layer (OSI layers 5-7) is usually the SIP protocol used, which provides the telephone subscriber with the actual telephone service.
  • IPsec enables the encryption of IP data packets, it leads to delays in the data traffic as well as to the quality reduction of the voice data, especially in connection with the real-time transmission of voice data in the context of Internet telephony.
  • the RTP protocol uses a cryptoalgorithm that is easily surmounted today.
  • mutual authentication of the call partners in RTP is not provided. For this reason, RTP is not sufficient for secure Internet telephony alone, so that at least IPsec with the mentioned disadvantages is to use.
  • SSL Secure HTTP Data Connections
  • TCP Transmission Control Protocol
  • HTTP Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • TCP Transmission Control Protocol
  • HTTP Hypertext Transfer Protocol
  • the SSL protocol can not be used directly to secure VoIP connections because they require RTP / UDP, while SSL at the transport layer requires the TCP protocol. It is therefore the object of the present invention to propose a sufficiently secure and efficiently usable cryptographic functionality for VoIP connections.
  • a secure communication connection between a first telecommunication terminal and a second telecommunication terminal is set up by establishing an additional separate data connection between the telecommunication terminals in addition to a VoIP connection.
  • the separate data connection serves to provide security functionalities for the VoIP connection.
  • a symmetric cryptographic key is negotiated between the first and second telecommunication terminals used to encrypt VoIP voice data packets to be transmitted over the VoIP connection and / or encrypted VoIP voice data packets received via the VoIP connection to decode.
  • a telecommunication terminal comprises a VoIP device, which establishes a VoIP connection with a second telecommunication terminal when initiating a telephone call of a user of the telecommunication terminal in order to send and receive VoIP voice data packets via this connection.
  • the telecommunication terminal comprises a connection device in order to set up the separate data connection to another telecommunication terminal device.
  • a security device of the telecommunication terminal agrees a symmetric key with the called telecommunication terminal or with its corresponding security device.
  • a telecommunication terminal comprises a control device which makes available the symmetrical key of the VoIP device agreed by the security device for the cryptographic securing of the VoIP connection.
  • both connections are at least partially contemporaneous and typically logical over the same physical connection operated separate, protocol-based connections.
  • the connection device establishes an SSL connection as a separate data connection, so that the symmetric key can be used in the context of the SSL protocol by means of a "handshake" method a second, also supporting the SSL protocol telecommunication terminal can be agreed.
  • the SSL handshake is a sequence of data transmissions between the two telecommunications terminals, in which secrets, such as random numbers, are exchanged and combined in such a way that a symmetrical key that is not reproducible for outsiders is agreed upon.
  • the SSL protocol with the SSL handshake is implemented by a special SSL module as a security device of the telecommunication terminal.
  • the connection device is preferably a conventional web server, which establishes as a separate data connection an HTTPS connection, within the framework of which the SSL connection is operated as a security layer underneath the HTTP application layer.
  • HTTP-SSL-TCP-IP HTTP-SSL-TCP-IP
  • VoIP protocol stack eg SIP-RTP-UDP-IP
  • the security device In addition to the cryptographic protection of the voice data during their transmission via the VoIP connection, the security device also provides an authentication option for both the calling and the called call subscriber and / or his telecommunication terminal. This authentication can be done, for example with the SSL handshake, by mutual transfer and cryptographic verification of certificates.
  • a known to the telecommunication terminal of the caller secret is encrypted with a private signature key and transmitted to the second telecommunication terminal.
  • the telecommunications terminal can then verify the authentication of the calling telecommunication terminal (or of the caller) by correctly decrypting the secret with a corresponding corresponding public signature key (challenge-response method).
  • the private signature key can be present in a correspondingly secure memory of the calling telecommunication terminal or, preferably, on a personalized portable data carrier of the caller, which can be connected to the telecommunication terminal via a corresponding read / write interface.
  • a secret is provided by the security device and transmitted via the read / write interface to the portable data carrier and signed by him with the private signature key.
  • the reverse case is also possible in that the control device of the telecommunication terminal reads out the private signature key and the secret is signed by the telecommunication terminal.
  • the portable data carrier can in this case be any data carrier, in particular a chip card, a secure multimedia card, a mobile communication card, a USB storage medium or the like.
  • Chip cards lend themselves here as portable data carriers in particular because they can be clearly assigned by further security measures and individualization / personalization of a specific person. In this context, it makes sense that the user must prove to be authorized in the portable volume before signing the secret, e.g. by entering a PIN or the like.
  • the control device After the authentication of the caller and / or his telecommunication terminal in the initialization phase of a call, the actual conversation with the transmission of encrypted VoIP voice data packets. Likewise, the symmetric cryptographic key is agreed upon in the initialization phase of the VoIP connection, so that the control device facilitates the establishment of the separate data connection by the connection device during the establishment of the VoIP connection.
  • the agreed symmetric Kryptographie Bachl can be used in the context of the transmission of VoIP data packets in the RTP protocol for encrypting / decrypting the VoIP data packets. It is also possible to use the agreed symmetric key for encrypting data packets in the optional IPsec protocol.
  • the control device of the telecommunication terminal typically directs a request with an identifier of the second telecommunication terminal and / or the call partner to be called to a central server.
  • the identifier can be a conventional telephone number, the name of the conversation partner, an HTTP address (domain name) or a VoIP-specific address, such as a SIP address, depending on the central server's routing tables.
  • the central server determines the IP address of the telecommunication terminal to be dialed and transmits it to the telecommunication terminal of the caller. With the IP address obtained, the telecommunication terminal of the caller can then establish both the VoIP connection and the separate data connection, eg in the form of an HTTPS connection.
  • the telecommunication terminal comprises in addition to the addressed components in addition to telephoning required audio functionalities, such as a microphone and a speaker, and an internal voice converter for converting the analog to digital voice signals.
  • audio functionalities such as a microphone and a speaker
  • voice converter for converting the analog to digital voice signals.
  • various other components and functionalities may be provided, which depend on the type of telecommunication terminal used. For example, it is possible to use a conventional internet-enabled computer equipped with a corresponding VoIP software as a VoIP telephone, which provides the user with a graphical user interface, for example a web browser, for operating the telephone functionalities.
  • FIG. 2 shows a schematic process sequence for establishing a secure communication connection between two telecommunication terminals
  • 3 shows a communication arrangement consisting of two telecommunication terminals, a portable data carrier and a central server; and 4 shows a diagram of the generation and use of a cryptographic key.
  • OSI reference model defines seven communication layers, of which layers 1 to 4 are transport-oriented and layers 5 to 7 are application-oriented.
  • the lowest physical layer corresponds to the OSI layers 1 and 2
  • the network layer above (network) corresponds to the OSI layer 3
  • the transport layer (transport) corresponds to the OSI layer 4
  • the uppermost application layer (application) corresponds to the OSI layers 5 to 7 (FIG. 1, column 1).
  • IP protocol Internet Protocol
  • TCP Transmission Control Protocol
  • HTTP protocol Hypertext Transmission Protocol
  • SSL is a security protocol for data transmission over the Internet, which works largely transparently and insofar as protocols can provide secure connections without their own security mechanisms.
  • SSL includes as a sub-protocol the so-called SSL handshake, which enables mutual authentication of the communication partners by means of certificates and the negotiation of a symmetric key for the cryptographic protection of the respective data traffic.
  • VoIP Voice over IP
  • individual protocols tailored to the specific requirements of continuous voice data transmission are used as of the transport layer (FIG. 1, column 3)
  • UDP essentially expands the end-system connections made by the underlying IP layer with an application interface, while RTP relies on UDP for the continuous transmission of audiovisual data (“UDP") and "RTP" (Real-Time Transport Protocol).
  • SIP Session Initiation Protocol
  • H.323 is often used as the application layer
  • the IPsec protocol can be used as the security layer. extension of the IP protocol and, thus, is established in the network layer.
  • FIG. 2 illustrates the establishment of a secure VoIP connection from a first Internet telephone 10 (Terminal 1) to a second Internet telephone 30 (Terminal 2) using a central server 40 and a smart card 22.
  • the security functionality of SSL for the Transmission of voice data packets used in the context of a VoIP connection In the following the method outlined in FIG. 2 will be explained in connection with FIGS. 3 and 4.
  • Fig. 3 shows the interaction of a calling Internet telephone 10 with a called Internet telephone 30, a central server 40 and an associated smart card 22.
  • the structure of the calling Internet telephone 10 is further elaborated in Fig. 4 in terms of security functionality.
  • An Internet telephone 10, 30 includes, among other things, a processor 14 (CPU), a memory device, a VoIP device 12, 32 for establishing a VoIP connection 51 and an HTTPS server 13, 33 for establishing an HTTPS connection 52 to the Internet telephone 30 via the Internet 50 and a controller 11, 31 for coordinating the interaction between the VoIP device 12, 32 and the HTTPS server 13, 33.
  • the devices 11, 12, 13, 31, 32, 33 be present as software components in a memory of the software telephone 10, 30 and be executed by the processor 14 or be implemented on a separate telephony card of the Internet telephone 10, 30.
  • the connections 51, 52 are constructed via the interfaces 17 and 37 and corresponding dial-in devices of the Internet telephones 10, 30 with the Internet 50, eg via modems, LAN cards or the like.
  • an Internet telephone 10, 30 comprises an audio device 15, 35, comprising at least one loudspeaker and a microphone, as well as a suitable user interface, such as indicated in Fig. 4 web browser 18.
  • Internet phones are preferably VoIP software phones (eg SIP TeI efone) in question, as well as small devices such as PDAs, handhelds and The like, which have an Internet connection, eg via Ethernet or WLAN (wireless LAN).
  • the basic principle of the secure voice communication connection is to establish an HTTPS data connection 52 between the HTTPS servers 13, 33 in the initialization phase of a VoIP connection 51 initiated by the Internet telephone 10.
  • the HTTPS server 13 can fall back on an SSL security module 19 (SSL engine). Since the HTTPS data connection 52 is operated at least partially in parallel with the VoIP voice connection 51, the security functionalities provided by the SSL module 19 during the establishment of the HTTPS connection 52 can be used to secure the voice communication via the VoIP connection 51 ,
  • a software controlled Internet telephone 10 provides a graphical user interface (GUI), e.g. a web browser 18, as a front-end for operating the Internet phone 10 at.
  • GUI graphical user interface
  • the user can select the desired interlocutor or a unique identifier of this interlocutor and cause the establishment of a VoIP connection by a VoIP device 12.
  • the VoIP device 12 if used in the application layer SIP, can be configured as a SIP module.
  • the establishment of a secure VoIP connection 51 begins in step S 1 with a request from the Internet telephone 10 to the subscriber Central server 40.
  • the central server 40, the desired call partner and / or an identifier of the call partner or his Internet phone 30 via a data connection 53 is called.
  • This request can optionally be made dependent on an authentication of the user with respect to the Internet telephone 10, eg by a password, a PIN or the like.
  • step S2 the central server 40 determines whether the desired contact can be reached via a VoIP connection. If this is the case, the Internet telephone 10 via the data connection 53, the IP address of the Internet phone 30 is transmitted. At the same time, the central server 40 can notify the internet phone 30 of the calling intention of the internet telephone 10. With the IP address, the VoIP device 12 of the Internet telephone 10 initiates a voice data connection 51 to the Internet telephone 30 according to a suitable VoIP protocol.
  • the HTTPS connection 52 is established by the HTTPS server 13 to the HTTPS server 33 of the Internet telephone 30, wherein the SSL security layer is realized by the SSL module 19 .
  • the SSL module 19 in interaction with a corresponding SSL module of the software telephone 30, a security routine (steps S4a, S4b, S4c) in the form of the SSL handshake method carried out.
  • this comprises an (optional) authentication of the software telephone 30 with respect to the software telephone 10 (auth terminal 2) by transmission of a certificate which the SSL module 19 checks and thereby verify the authenticity of the software telephone 30 can.
  • step S4b an authentication of the software telephone 10 to the software telephone 30 (auth terminal 1) is performed.
  • the SSL module 19 signs a secret, eg a random number (challenge) with a private signature key of the software telephone 10 or its user.
  • the private signature key is in the illustrated embodiment on a personalized and access protected smart card 22 of the user, which is connected via a corresponding read / write interface 16 of the Internet phone 10 to the Internet phone 10 in combination.
  • the secret is provided to the chip card 22 by the control device 11, where it is signed by a corresponding signature device of the chip card 22 with the signature key and transferred to the SSL module 19 for transmission to the Internet telephone 30 via the HTTPS connection 52.
  • the signature can be verified by an SSL module of the software telephone 30 by means of a corresponding public key present there.
  • step S4c a symmetric key 21 is negotiated between the SSL module 19 and a corresponding SSL module of the Internet telephone 30 as part of the SSL handshake.
  • the negotiated key 21 is finally made available in step S5 by the controller 11 of the VoIP device 12 in order subsequently to be able to use a cryptographically secured Internet voice data connection 51 in step S6, by transmitting VoIP voice data packets to the software telephone 30 encrypted and received VoIP voice data packets are decrypted.
  • FIG. 4 illustrates once again step S5.
  • the HTTPS connection 52 established by the HTTPS server 13 using the SSL module 19 via the protocols HTTP, SSL, TCP, IP
  • the VoIP connection 51 established by the SIP module 12 via the protocols SIP, RTP, UDP, IP
  • the hardware layer network access protocols used in the IP protocol are the same for the VoIP connection 51 and the HTTPS connection 52 and are combined in the IP stack 20 (IP stack).
  • the negotiated in the handshake step S5 key 21 is passed to the supported by the SIP module 12 RTP layer and used by this for the encryption / decryption of VoIP data packets.
  • the negotiated key may also be used in an optional IPsec layer by the VoIP device 12.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Es wird vorgeschlagen, eine sichere Kommunikationsverbindung zwischen einem ersten und einem zweiten Telekommunikationsendgerät (10, 30) über das Internet zu schaffen, indem einerseits eine VoIP- Verbindung (51) zwischen den Telekommunikationsendgeräten (10, 30) zum Übertragen von VoIP-Sprachdatenpaketen aufgebaut (Sl, S2, S3) wird und andererseits eine separate Datenverbindung (52), z.B. einen HTTPS- Verbindung, zwischen den Telekommunikationsendgeräten (10, 30) zeitlich überlappend aufgebaut (S4) wird. Die im Rahmen der separaten Datenverbindung (52) bereitgestellten Sicherheitsfunktionalitäten, wie z.B. einen durch ein Schlüsselaustauschverfahren effizient vereinbarten symmetrischen Kryptographieschlüssel (21) und/ oder eine wechselseitige Authentisierung der Telekommunikations- endgeräte (10, 30), können dann ohne größere Anpassungen der VoIP- Protokolle zum sicheren Betrieb der VoIP- Verbindung (51) eingesetzt werden, z.B. zum Ver-/ Entschlüsseln von VoIP-Sprachdatenpaketen.

Description

Sichere Voice-over-IP-Telef onie
Die vorliegende Erfindung betrifft ein Verfahren zum Aufbauen einer sicheren „Voice over IP" -Kommunikations Verbindung zwischen Telekommunikationsendgeräten sowie derartige Telekommunikationsendgeräte.
Mit dem Ausbau der weltweiten digitalen Datennetze, insbesondere des In- ternets, rückt die Möglichkeit in den Vordergrund, auf Basis der zur Datenübertragung verwendeten Kommunikationsprotokolle eine paketorientierte Telefonie zu etablieren, die die herkömmliche leitungsvermittelte Telefonie ergänzen und langfristig sogar ersetzen kann.
Zunehmend etabliert sich dabei die Internet-Protokoll(IP)-basierte Telefonie. Hierbei werden Sprachdaten über eine Internet-Protokoll (IP)-basierte Verbindung übertragen, z.B. über das Internet, oder über eine LAN- Verbindung (LAN= Local Area Network) oder über eine WLAN- Verbindung (WLAN = Wireless LAN). Jedoch auch für Multimediasitzungen im allgemeinen, wie beispielsweise Videokonferenzen, bieten sich Internet-Protokoll (IP)-basierte Verbindungen an. Neben Sprachdaten können über die Internet- Protokoll(IP)-basierte Verbindungen beispielsweise Videodaten übertragen werden, und je nach Bedarf weitere Daten, z.B. Unterlagen für die Teilnehmer an der Multimediasitzung.
Mit dem Begriff VoIP- Verbindung wird jede Art von IP-basierter Sitzung insbesondere Multimediasitzung unter Verwendung von VoIP-Protokollen bezeichnet. Spezialfälle von VoIP- Verbindungen sind Internettelefonie- Verbindungen (IP-basierte Telefonie- Verbindungen). Die grundlegende Funktionsweise von VoIP ist beispielsweise in einer Studie des Bundesamts für Sicherheit in der Informationstechnik (BSI) eingegangen, „ VoIPSEC, Studie zur Sicherheit von Voice over Internet Protocol", Bundesamt für Sicherheit in der Informationstechnik, Oktober 2005, http:/ /www.bsi.bund.de (BSI-Studie), oder in einer Studie des National Institute of Standards and Technology (NIST), „Security Considerations for Voice Over IP Systems", D.R. Kuhn, TJ. Walsh, S. Fries, Januar 2005 (NIST- Studie), beschrieben.
Im Bild eines mehrschichtigen Protokollmodells (wie z.B. OSI) baut eine
VoIP- Verbindung auf dem Internet-Protokoll IP als einer unteren Protokollschicht auf, auf der mehrere VoIP-spezifische Protokolle aufsetzen. Beispiele für VoIP-spezifische Protokolle sind das Protokoll H.323 und die H.323 untergeordneten Transportprotokolle RTP (Real-Time Transport Protocol) für die Echtzeit-Übertragung von Sprach- und Videodaten über paketorientierte Netze und SRTP (Secured RTP) für die verschlüsselte Echtzeit-Übertragung von Sprach- und Videodaten; SIP (Session Initiation Protocol) oder H.323, das letztere mit einem der Unterprotokolle H.225 oder H.245, für die Signalisierung, insbesondere den Verbindungsaufbau; das auf das Signalisierungs- protokoll (z.B. SIP, H.225, H.245) aufsetzende Schlüsselverwaltungsprotokoll MIKEY (Multimedia Internet Keying) oder das auf das Transportprotokoll RTP aufsetzende Schlüsselverwaltungsprotokoll ZRTP für eine Authentisie- rung zwischen Teilnehmern an einer VoIP- Verbindung, die Erzeugung von Schlüsseln und den Schlüsselaustausch für eine nachfolgende verschlüsselte Verbindung nach SRTP.
Von besonderem Interesse für VoIP ist die MIKEY-Spezifikation rfc3830. MIKEY ist ein Schlüsselaustauschverfahren, das für Mutlimediaanwendun- gen konzipiert wurde und sehr effizient in Bezug auf die Zahl der Round- trips ist. MIKEY sieht drei Modi vor: PSK — pre-shared keys, PKE- public- key und DH — Diffie-Helmann. Die Authentisierung ist mithin so stark wie bei SSL. MIKEY ist anders als SSL allerdings noch sehr jung. Es existieren dehalb bisher nur wenige Implementierungen, weshalb sich MIKEY noch nicht als sicher etablieren konnte.
Bei der "Voice over IP" (VoIP) oder Internet-Telefonie bezeichneten Technologie besteht eine Reihe von offenen Sicherheitsfragen, wie z. B. die Sicherstellung der gegenseitigen Authentisierung der Gesprächspartner und der Vertraulichkeit und Integrität der übertragenen Sprachdaten.
Bei einer Internet-Protokoll(IP)-basierten Verbindung sind die Teilnehmer, z.B. Anrufer und Angerufener, durch ihre jeweilige IP- Adresse identifiziert, die variieren kann. Die Sprachdatenübermittlung erfolgt paketorientiert und der Verbindung ist kein fester Übertragungskanal zugewiesen. Zu übertragende Daten werden in Pakete aufgeteilt, jedes Paket mit der IP- Adresse des Angerufenen versehen, und die Pakete an die IP- Adresse des Angerufenen versandt, wobei die Übertragungswege der einzelnen Pakete in der Regel unterschiedlich sind.
Jede VoIP- Verbindung beginnt mit der Signalisierung, bei der ein Anrufer die IP- Adresse eines gewünschten Anzurufenden ermittelt und seine eigene IP- Adresse mitteilt. Die Verbindung zwischen den Endgeräten von Anrufer und Anzurufendem erfolgt über ein oder mehrere Verbindungs-Server, bei- spielsweise bei SIP über sogenannte Proxy-Server, bei H.323 über sogenannte Gatekeeper. Nach erfolgreicher Signalisierung erfolgt die Übertragung der Sprachdaten und ggf. weiterer Daten, die nun direkt, ohne die Zwischenschaltung von Verbindungs-Servern, erfolgen kann. Je nach Transportproto- koll werden die Daten unverschlüsselt (z.B. bei RTP) oder verschlüsselt übertragen (z.B. bei SRTP).
Falls bei einer VoIP- Verbindung überhaupt eine gegenseitige Authentisie- rung der Teilnehmer durchgeführt wird, geschieht dies während der Signali- sierungsphase. Beispielsweise authentisieren sich die Teilnehmer an einer VoIP- Verbindung gegenseitig über den Austausch von Zertifikaten, Prüfsummen und/ oder Signaturen, die durch kryptographische Berechnungen mit persönlichen Authentisierungsdaten der Teilnehmer erstellt werden.
Die Signalisierung wird gemäß einem Signalisierungsprotokoll durchgeführt, beispielsweise SIP oder H.323, das letztere mit H.225 oder H.245. Die kryptographischen Berechnungen für die Authentisierung und/ oder für die Erzeugung und/ oder den Austausch von Transportschlüsseln werden ge- maß einem Schlüssel Verwaltungsprotokoll durchgeführt, beispielsweise MIKEY oder ZRTP.
Im Hinblick auf das siebenschichtige Kommunikationsprotokoll des OSI- Referenzmodells für die Kommunikation zwischen informationsverarbeiten- den Systemen kann ein zur VoIP-Telefonie verwendetes Protokoll das IP- Protokoll („Internet Protocol") mit dem optionalen IPsec-Sicherheits- protokoll („secure IP") als Netzwerkschicht (OSI-Schicht 4) und das UDP- Protokoll ("User Datagram Protocol") sowie das RTP-Protokoll („Real-Time Transport Protocol") als Transportschicht (OSI-Schicht 5) einsetzen. Hierbei sorgt das IP-Protokoll als erste vom Übertragungsmedium unabhängige Schicht für die Weitervermittlung der einzelnen Sprachdatenpakete. Das UDP-Protokoll, das etwa der TCP-Schicht bei dem TCP/IP-Datenüber- tragungsmodell entspricht, eignet sich speziell für die VoIP-Telefonie und bietet eine einfache Schnittstelle zur IP-Netzwerkschicht, während das RTP- Protokoll die kontinuierliche Übertragung („Streaming") von audiovisuellen Daten über IP-basierte Netzwerke regelt. Als darüberliegende Anwendungsschicht (OSI-Schichten 5-7) wird meist das SIP-Protokoll verwendet, das dem Telefonteilnehmer die eigentliche Telefondienstleistung bereitstellt.
In diesem Protokollstapel sind Sicherheitsfunktionen jeweils in IPsec und RTP vorgesehen. IPsec ermöglicht zwar die Verschlüsselung von IP- Datenpaketen, führt jedoch speziell im Zusammenhang mit der Echtzeitübertragung von Sprachdaten im Rahmen der Internet-Telefonie zu Verzögerun- gen im Datenverkehr sowie zur Qualitätsreduktion der Sprachdaten. Das RTP-Protokoll wiederum verwendet standardmäßig einen heutzutage leicht überwindbaren Kryptoalgorithmus. Des weiteren ist eine gegenseitige Authentifizierung der Gesprächspartner bei RTP nicht vorgesehen. Aus diesem Grund ist RTP zur sicheren Internet-Telefonie alleine nicht ausreichend, so dass zumindest auch IPsec mit den genannten Nachteilen einzusetzen ist.
Für sichere HTTP-Datenverbindungen (HTTPS) über das Internet existiert mit SSL ("Secure Socket Layer") ein Sicherheitsprotokoll zwischen der TCP- Transportschicht („Transmission Control Protocol") und der HTTP- Anwendungsschicht („Hypertext Transfer Protocol"), mit dem eine gegenseitige Authentisierung möglich ist und mit dem die Kommunikationspartner auf effiziente Weise einen symmetrischen Kryptographieschlüssel zur kryp- tographischen Absicherung der HTTP-Datenkommunikation vereinbaren können. Jedoch kann das SSL-Protokoll nicht direkt zur Absicherung von VoIP- Verbindungen eingesetzt werden, da diese RTP/ UDP erfordern, während SSL auf der Transportschicht das TCP-Protokoll erfordert. Es ist demzufolge die Aufgabe der vorliegenden Erfindung, eine ausreichend sichere und effizient einsetzbare Kryptographiefunktionalität für VoIP- Verbindungen vorzuschlagen.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zum Aufbauen einer sicheren Kommunikationsverbindung zwischen zwei Telekommunikationsendgeräten sowie durch ein Telekommunikationsendgerät mit den Merkmalen der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche betreffen vorteilhafte Ausgestaltung und Weiterbildungen der Erfindung.
Erfindungsgemäß wird eine sichere Kommunikationsverbindung zwischen einem ersten Telekommunikationsendgerät und einem zweiten Telekommunikationsendgerät eingerichtet, indem neben einer VoIP- Verbindung eine zusätzliche separate Datenverbindung zwischen den Telekommunikations- endgeräten aufgebaut wird. Die separate Datenverbindung dient hierbei der Bereitstellung von Sicherheitsfunktionalitäten für die VoIP- Verbindung. Beim Schritt des Aufbauens der separaten Datenverbindung wird ein symmetrischer Kryptographieschlüssel zwischen dem ersten und zweiten Telekommunikationsendgerät vereinbart, der verwendet wird, um über die VoIP- Verbindung zu übertragene VoIP-Sprachdatenpakete zu verschlüsseln und/ oder über die VoIP- Verbindung empfangene, verschlüsselte VoIP- Sprachdatenpakete zu entschlüsseln.
Durch das Vereinbaren eines symmetrischen Schlüssels über die separate Datenverbindung kann eine effizientere Schlüsselvereinbarung vorgenommen werden, als es im Rahmen der für VoIP- Verbindungen zur Verfügung stehenden Kommunikationsprotokolle möglich ist. Dadurch wird ein effizienter und sicherer Aufbau einer kryptographisch gesicherten VoIP- Verbindung erreicht, ohne dass der bekannte VoIP-Protokollstapel dazu wesentlich geändert werden muss.
Ein erfindungsgemäßes Telekommunikationsendgerät umfasst eine VoIP- Einrichtung, die beim Initiieren eines Telefonats eines Benutzers des Telekommunikationsendgeräts eine VoIP- Verbindung mit einem zweiten Telekommunikationsendgerät aufbaut, um über diese Verbindung VoIP- Sprachdatenpakete zu senden und zu empfangen. Darüber hinaus umfasst das Telekommunikationsendgerät eine Verbindungseinrichtung, um die se- parate Datenverbindung zu einem anderen Telekommunikationsend gerät aufzubauen. Beim Aufbauen der separaten Datenverbindung vereinbart eine Sicherheitseinrichtung des Telekommunikationsendgeräts einen symmetrischen Schlüssel mit dem angerufenen Telekommunikationsendgerät bzw. mit dessen entsprechender Sicherheitseinrichtung. Schließlich umfasst ein Telekommunikationsendgerät eine Steuereinrichtung, die den von der Sicherheitseinrichtung vereinbarten symmetrischen Schlüssel der VoIP- Einrichtung zur kryptographischen Sicherung der VoIP- Verbindung zur Verfügung stellt.
Da die VoIP- Verbindung zum Austauschen von VoIP-Sprachdatenpaketen und die separaten Datenverbindungen zur Schlüsselvereinbarung zumindest in Bezug auf das Aushandeln und Verwenden des symmetrischen Schlüssels interagieren, bestehen beide Verbindungen zumindest teilweise zeitgleich und werden in der Regel über die gleiche physikalische Verbindung als lo- gisch getrennte, protokollgestützte Verbindungen betrieben.
Vorzugsweise wird von der Verbindungseinrichtung als separate Datenverbindung eine SSL- Verbindung aufgebaut, so dass der symmetrische Schlüssel im Rahmen des SSL-Protokolls durch ein „Handshake" -Verfahren mit einem zweiten, ebenfalls das SSL-Protokoll unterstützenden Telekommunikationsendgerät vereinbart werden kann. Der SSL-Handshake ist eine Folge von Datenübertragungen zwischen den beiden Telekommunikationsendgeräten, in deren Rahmen Geheimnisse, wie z.B. Zufallszahlen, derart ausge- tauscht und kombiniert werden, dass ein für Außenstehende nicht reproduzierbarer symmetrischer Schlüssel vereinbart wird. Das SSL-Protokoll mit dem SSL-Handshake wird von einem speziellen SSL-Modul als Sicherheitseinrichtung des Telekommunikationsendgeräts realisiert.
Die Verbindungseinrichtung ist vorzugsweise ein herkömmlicher Web- Server, der als separate Datenverbindung eine HTTPS- Verbindung aufbaut, in deren Rahmen die SSL- Verbindung als Sicherheitsschicht unterhalb der HTTP- Anwendungsschicht betrieben wird. Zur Realisierung der SSL- Verbindung wird also eine separate Datenverbindung gemäß dem HTTPS- Protokollstapel (HTTP - SSL - TCP - IP) betrieben, während die sprachda- tenübertragende VoIP- Verbindung gemäß einem VoIP-Protokollstapel (z.B. SIP - RTP - UDP - IP) aufgebaut und betrieben wird.
Neben dem kryptographischen Schutz der Sprachdaten bei ihrer Übertra- gung über die VoIP- Verbindung stellt die Sicherheitseinrichtung auch eine Authentisierungsmöglichkeit sowohl des anrufenden als auch des angerufenen Gesprächsteilnehmers und/ oder seines Telekommunikationsendgeräts bereit. Diese Authentisierung kann, wie z.B. bei dem SSL-Handshake, durch wechselseitiges Übertragen und kryptographisches Verifizieren von Zertifi- katen geschehen. Bei einer Authentisierung des anrufenden Telekommunikationsendgeräts (oder des Anrufers) gegenüber einem angerufenen Telekommunikationsendgerät wird ein dem Telekommunikationsendgerät des Anrufers bekanntes Geheimnis mit einem privaten Signaturschlüssel verschlüsselt und an das zweite Telekommunikationsendgerät übertragen. Das zweite Te- lekommunikationsendgerät kann die Authentisierung des anrufenden Telekommunikationsendgeräts (oder des Anrufers) dann verifizieren, indem das Geheimnis mit einem vorliegenden korrespondierenden öffentlichen Signaturschlüssel korrekt entschlüsselt wird (Challenge-Response- Verfahren).
Der private Signaturschlüssel kann in einem entsprechend gesicherten Speicher des anrufenden Telekommunikationsendgeräts oder, vorzugsweise, auf einem personalisierten portablen Datenträger des Anrufers vorliegen, der über eine entsprechende Schreib-/ Leseschnittstelle mit dem Telekommuni- kationsendgerät verbunden sein kann. Bei einer Authentisierung des Anrufers wird von der Sicherheitseinrichtung ein Geheimnis bereitgestellt und über die Schreib-/ Leseschnittstelle an den portablen Datenträger übertragen und von diesem mit dem privaten Signaturschlüssel signiert. Prinzipiell möglich ist auch der umgekehrte Fall, dass die Steuereinrichtung des TeIe- kommunikationsendgeräts den privaten Signaturschlüssel ausliest und das Geheimnis von dem Telekommunikationsendgerät signiert wird.
Der portable Datenträger kann hierbei ein beliebiger Datenträger sein, insbesondere eine Chipkarte, eine sichere Multimediakarte, eine Mobilfunkkarte, ein USB-Speichermedium oder dergleichen. Chipkarten bieten sich hier als portable Datenträger insbesondere deswegen an, da sie durch weitere Sicherheitsmaßnahmen und eine Individualisierung/ Personalisierung einer bestimmten Person eindeutig zugeordnet werden können. In diesem Zusammenhang ist es sinnvoll, dass sich der Benutzer vor dem Signieren des Geheimnisses bei dem portablen Datenträger als berechtigt ausweisen muss, z.B. durch Eingeben einer PIN oder dergleichen.
Nach der Authentisierung des Anrufers und/ oder seines Telekommunikationsendgeräts in der Initialisierungsphase eines Gesprächs kann das eigentli- che Gespräch mit dem Übertragen von verschlüsselten VoIP-Sprachdaten- paketen erfolgen. Ebenso erfolgt das Vereinbaren des symmetrischen Kryp- tographieschlüssels in der Initialisierungsphase der VoIP- Verbindung, so dass die Steuereinrichtung den Aufbau der separaten Datenverbindung durch die Verbindungseinrichtung während des Aufbaus der VoIP-
Verbindung durch die VoIP-Einrichtung veranlassen kann. Prinzipiell ist es aber auch möglich, dass eine der beiden Verbindungen zuerst aufgebaut wird und die andere anschließend.
Der vereinbarte symmetrische Kryptographieschlüssel kann im Rahmen der Übertragung von VoIP-Datenpaketen in dem RTP-Protokoll zum Ver-/ Entschlüsseln der VoIP-Datenpakete eingesetzt werden. Ebenso ist es möglich, den vereinbarten symmetrischen Schlüssel zur Verschlüsselung von Datenpaketen in dem optionalen IPsec-Protokoll einzusetzen.
Zum Aufbau einer VoIP- Verbindung richtet die Steuereinrichtung des Telekommunikationsendgeräts typischerweise eine Anfrage mit einer Kennung des zweiten Telekommunikationsendgeräts und/ oder des anzurufenden Gesprächspartners an einen Zentralserver. Die Kennung kann hierbei abhängig von Vermittlungstabellen des Zentralservers eine herkömmliche Telefonnummer, der Name des Gesprächspartners, eine HTTP- Adresse (Domain Name) oder eine VoIP-spezifische Adresse, wie z.B. eine SIP- Adresse, sein. Der Zentralserver ermittelt die IP- Adresse des anzuwählenden Telekommunikationsendgeräts und übermittelt diese dem Telekommunikationsendgerät des Anrufers. Mit der erhaltenen IP- Adresse kann das Telekommunikationsendgerät des Anrufers dann sowohl die VoIP- Verbindung als auch die separate Datenverbindung, z.B. in Form einer HTTPS- Verbindung, herstellen. Ist die Kennung in der Steuereinrichtung bereits bekannt, kann die Anfrage an den Zentralserver entfallen. Das Telekommunikationsendgerät umfasst neben den angesprochenen Komponenten zusätzlich zum Telefonieren benötigte Audiofunktionalitäten, z.B. ein Mikrofon und einen Lautsprecher, sowie einen internen Sprach- wandler zum Umsetzen der analogen in digitale Sprachsignale. Darüber hinaus können verschiedene weitere Komponenten und Funktionalitäten vorgesehen sein, die von der Art des eingesetzten Telekommunikationsendgeräts abhängen. So ist es beispielsweise möglich, einen mit einer entsprechenden VoIP-Software ausgestatteten herkömmlichen internetfähigen Computer als VoIP-Telefon einzusetzen, der dem Benutzer eine grafische Benutzerschnittstelle, z.B. einen Web-Browser, zur Bedienung der Telefonfunktionalitäten bereitstellt.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgen- den Beschreibung verschiedener erfindungsgemäßer Ausführungsbeispiele und Ausführungsalternativen im Zusammenhang mit den begleitenden Zeichnungen. Darin zeigen:
Fig. 1 eine Gegenüberstellung der für eine HTTPS- und eine VoIP- Verbindung verwendeten Protokolle im Rahmen des OSI-
Referenzmodells;
Fig. 2 einen schematischen Verfahrensablaufs beim Aufbau einer sicheren Kommunikationsverbindung zwischen zwei Telekom- munikationsendgeräten;
Fig. 3 eine Kommunikationsanordnung bestehend aus zwei Telekommunikationsendgeräten, einem portablen Datenträger und einem Zentralserver; und Fig. 4 ein Schema der Erzeugung und Verwendung eines krypto- graphischen Schlüssels.
Bei der elektronischen Kommunikation zwischen zwei elektronischen Geräten wird der Aufbau der Kommunikationsverbindung und der anschließende Datenverkehr gemäß vorgegebener, standardisierter Kommunikationsprotokolle abgewickelt. Diese Protokolle regeln sämtliche Probleme und Aufgaben der elektronischen Übertragung von der konkreten physikalischen Signalübertragung bis zur abstrakten Awendungsebene der eigentlichen Kommunikationsapplikation. Aufgrund der Vielzahl der zu regelnden Aufgaben werden verschiedene Protokollschichten definiert, deren Aufgaben jeweils transparent für die übergeordneten Schichten geregelt werden.
Ein verbreitetes Modell zur elektronischen Kommunikation bietet das OSI- Referenzmodell, das sieben Kommunikationsschichten definiert, von welchen die Schichten 1 bis 4 transportorientiert und die Schichten 5 bis 7 an- wendungsorientiert sind. Bei dem bekannten vierschichtigen TCP/ IP- Protokoll zur Datenkommunikation über das Internet entspricht die unterste physikalische Schicht den OSI-Schichten 1 und 2, die darüberliegende Netzwerkschicht (Network) entspricht der OSI-Schicht 3, die Transportschicht (Transport) entspricht der OSI-Schicht 4 und die oberste Anwendungsschicht (Application) entspricht den OSI-Schichten 5 bis 7 (Fig. 1, Spalte 1).
Bei einer gesicherten Datenkommunikation über das Internet mittels einer HTTPS- Anwendung (Fig. 1, Spalte 2) wird die Netzwerkschicht von dem IP- Protokoll (Internet Protocol), die Transportebene von dem TCP-Protokoll (Transmission Control Protocol) und die Anwendungsschicht von dem HTTP-Protokoll (Hypertext Transmission Protocol) geregelt. Hierbei über- nimmt das IP-Protokoll einen ungesicherten paketorientierten Datenverkehr, während das verbindungsorientierte TCP-Protokoll eine Ende-zu Ende- Verbindung zwischen den Kommunikationspartnern herstellt, auf deren Basis das HTTP-Protokoll schließlich eine einheitliche Datenkommunikation ermöglicht. Die Absicherung von HTTP kann hierbei durch SSL (Secure Sok- ket Layer) geschehen, das sich zwischen der Transport- und der Anwendungsschicht einordnen lässt.
SSL ist ein Sicherheitsprotokoll für die Datenübertragung im Internet, das weitgehend transparent arbeitet und insofern Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung stellen kann. SSL umfasst als Unterprotokoll den sogenannten SSL-Handshake, der eine gegenseitige Authentifizierung der Kommunikationspartner mittels Zertifikaten und das Aushandeln eines symmetrischen Schlüssels für die kryptograpische Sicherung des jeweiligen Datenverkehrs ermöglicht.
Bei der VoIP-Kommunikation („Voice over IP") zur kontinuierlichen und/ oder Echtzeitsprachübertragung von Sprachdaten werden ab der Transportschicht individuelle, auf die speziellen Anforderungen der konti- nuierlichen Sprachdatenübertragung abgestimmte Protokolle eingesetzt (Fig. 1, Spalte 3). Hierbei werden als Transportschicht UDP (User Datagramm Protocol) und RTP (Real-Time Transport Protocol) eingesetzt. UDP erweitert im wesentlichen die von der darunter liegenden IP-Schicht hergestellte Endsystemverbindungen um eine Anwendungsschnittstelle, während RTP unter Rückgriff auf UDP die kontinuierliche Übertragung von audiovisuellen Daten ("Streaming") ermöglicht. Als Anwendungsschicht wird häufig SIP (Session Initiation Protocol) oder H.323 eingesetzt. Zusätzlich kann als Sicherheitsschicht das IPsec-Protokoll dienen, das als eine Er- weiterung des IP-Protokolls angesehen werden kann und insofern in der Netzwerkschicht eingerichtet wird.
Figur 2 illustriert den Aufbau einer sicheren VoIP- Verbindung von einem ersten Internet-Telefon 10 (Terminal 1) zu einem zweiten Internet-Telefon 30 (Terminal 2) unter Verwendung eines Zentralservers 40 und einer Chipkarte 22. Hierbei wird die Sicherheitsfunktionalität von SSL für die Übertragung von Sprachdatenpaketen im Rahmen einer VoIP- Verbindung eingesetzt. Im folgenden wird das in Fig. 2 skizzierte Verfahren im Zusammenhang mit den Figuren 3 und 4 erläutert. Fig. 3 zeigt die Interaktion eines anrufenden Internet-Telefons 10 mit einem angerufenen Internet-Telefon 30, einem Zentralserver 40 und einer zugehörigen Chipkarte 22. Der Aufbau des anrufenden Internet-Telefons 10 ist in Fig. 4 im Hinblick auf die Sicherheitsfunktionalität weiter ausgeführt.
Ein Internet-Telefon 10, 30 umfasst u.a. einen Prozessor 14 (CPU), eine Speichereinrichtung, eine VoIP-Einrichtung 12, 32 zum Aufbauen einer VoIP- Verbindung 51 und einen HTTPS-Server 13, 33 zum Aufbauen einer HTTPS- Verbindung 52 zu dem Internet-Telefon 30 über das Internet 50 sowie eine Steuereinrichtung 11, 31 zur Koordination der Interaktion zwischen der VoIP-Einrichtung 12, 32 und dem HTTPS-Server 13, 33. Hierbei können die Einrichtungen 11, 12, 13, 31, 32, 33 als Software-Komponenten in einem Speicher des Software-Telefons 10, 30 vorliegen und von dem Prozessor 14 ausgeführt werden oder auf einer separaten Telefonie-Karte des Internet- Telefons 10, 30 implementiert sein. Die Verbindungen 51, 52 werden über die Schnittstellen 17 und 37 und entsprechende Einwahl Vorrichtungen der Internet-Telefone 10, 30 mit dem Internet 50 aufgebaut, z.B. über Modems, LAN- Karten oder dergleichen. Des weitern umfasst ein Internet-Telefon 10, 30 eine Audioeinrichtung 15, 35, bestehend zumindest aus einen Lautsprecher und einen Mikrophon, sowie eine geeignete Benutzerschnittstelle, wie z.B. den in Fig. 4 angedeuteten Web-Browser 18. Als Internet-Telefone kommen vorzugsweise VoIP-Software-Telefone (z.B. SIP-TeI efone) in Frage, sowie Kleingeräte wie z.B. PDAs, Handhelds und dergleichen, die über eine Internet- Anbindung verfügen, z.B. über Ethernet oder WLAN (Wireless LAN).
Das Grundprinzip der sicheren Sprachkommunikationsverbindung ist, in der Initialisierungsphase einer von dem Internet-Telefon 10 eingeleiteten VoIP- Verbindung 51 eine HTTPS-Datenverbindung 52 zwischen den HTTPS- Servern 13, 33 aufzubauen. Der HTTPS-Server 13 kann dabei auf ein SSL- Sicherheitsmodul 19 (SSL engine) zurückgreifen. Da die HTTPS-Datenverbindung 52 zumindest teilweise parallel mit der VoIP-Sprachverbindung 51 betrieben wird, können die von dem SSL-Modul 19 beim Aufbau der HTTPS- Verbindung 52 bereitgestellten Sicherheitsfunktionalitäten für die Absiche- rung der Sprachkommunikation über die VoIP- Verbindung 51 verwendet werden.
Bei einem Software-gesteuerten Internet-Telefon 10 bietet sich eine grafische Benutzeroberfläche (GUI), z.B. ein Web-Browser 18, als Front-End zur Bedie- nung des Internet-Telefons 10 an. In dem Browser 18 kann der Benutzer den gewünschten Gesprächspartner bzw. eine eindeutige Kennung dieses Gesprächspartners auswählen und das Aufbauen einer VoIP-Verbindung durch eine VoIP-Einrichtung 12 veranlassen. Die VoIP-Einrichtung 12 kann, falls sie in der Anwendungsschicht SIP verwendet wird, als SIP-Modul (SIP engine) ausgestaltet sein.
Gemäß des Ablaufplans der Figur 2 beginnt nach dem Auswählen eines gewünschten Gesprächspartners der Aufbau einer sicheren VoIP-Verbindung 51 in Schritt Sl mit einer Anfrage (request) des Internet-Telefons 10 an den Zentralserver 40. Darin wird dem Zentralserver 40 der gewünschte Gesprächspartner und/ oder eine Kennung des Gesprächspartners oder seines Internet-Telefons 30 über eine Datenverbindung 53 genannt. Diese Anfrage kann optional von einer Authentisierung des Nutzers gegenüber dem Inter- net-Telefons 10 abhängig gemacht werden, z.B. durch ein Passwort, eine PIN oder dergleichen.
In Schritt S2 stellt der Zentralserver 40 fest, ob der gewünschte Ansprechpartner über eine VoIP-Verbindung erreichbar ist. Falls dies der Falls ist, wird dem Internet-Telefon 10 über die Datenverbindung 53 die IP- Adresse des Internet-Telefons 30 übermittelt. Gleichzeitig kann der Zentralserver 40 dem Internet-Telefon 30 die Anrufabsicht des Internet-Telefons 10 mitteilen. Mit der IP-Adresse initiiert die VoIP-Einrichtung 12 des Internet-Telefons 10 eine Sprachdatenverbindung 51 zu dem Internet-Telefon 30 gemäß einem geeigneten VoIP-Protokoll.
In der Initialisierungsphase der VoIP-Verbindung 51 (init call) wird die HTTPS- Verbindung 52 durch den HTTPS-Server 13 zu dem HTTPS-Server 33 des Internet-Telefons 30 hergestellt, wobei die SSL-Sicherheitsschicht durch das SSL-Modul 19 realisiert wird. Anschließend wird im Rahmen des Aufbaus der HTTPS-Verbindung 52 in Schritt S4 das SSL-Modul 19 in Interaktion mit einem entsprechenden SSL-Modul des Software-Telefons 30 eine Sicherheitsroutine (Schritte S4a, S4b, S4c) in Form des SSL-Handshake- Verfahrens durchgeführt. Dies umfasst in Schritt S4a eine (optionale) Au- thentisierung des Software-Telefons 30 gegenüber dem Software-Telefon 10 (auth terminal 2) durch Übermittlung eines Zertifikats, welches das SSL- Modul 19 überprüfen und dadurch die Authentizität des Software-Telefons 30 verifizieren kann. In Schritt S4b wird eine Authentisierung des Software-Telefons 10 gegenüber dem Software-Telefon 30 (auth terminal 1) durchgeführt. Hierzu signiert das SSL-Modul 19 ein Geheimnis, z.B. eine Zufallszahl (challenge) mit einem privaten Signaturschlüssel des Software-Telefons 10 bzw. seines Benutzers. Der private Signaturschlüssel liegt in der dargestellten Ausführungsform auf einer personalisierten und zugangsgeschützten Chipkarte 22 des Benutzers vor, die über eine entsprechende Schreib-/ Leseschnittstelle 16 des Internet- Telefons 10 mit dem Internet-Telefon 10 in Verbindung steht. Das Geheimnis wird der Chipkarte 22 von der Steuereinrichtung 11 bereitgestellt, dort von einer entsprechenden Signatureinrichtung der Chipkarte 22 mit dem Signaturschlüssel signiert und an das SSL-Modul 19 zur Übertragung an das Internet-Telefon 30 über die HTTPS- Verbindung 52 übergeben. Dort kann die Signatur von einem SSL-Modul des Software-Telefons 30 mittels eines dort vorliegenden korrespondierenden öffentlichen Schlüssels verifiziert werden.
In Schritt S4c wird zwischen dem SSL-Modul 19 und einem entsprechenden SSL-Modul des Internet-Telefons 30 ein symmetrischer Schlüssel 21 im Rahmen des SSL-Handshake ausgehandelt. Der ausgehandelte Schlüssel 21 wird schließlich in Schritt S5 von der Steuereinrichtung 11 der VoIP-Einrichtung 12 zur Verfügung gestellt, um nachfolgend in Schritt S6 eine kryptographisch gesicherte Internet-Sprachdatenverbindung 51 nutzen zu können, indem an das Software-Telefon 30 zu übertragende VoIP-Sprachdatenpakete verschlüsselt und empfangene VoIP-Sprachdatenpakete entschlüsselt werden.
Figur 4 illustriert noch einmal den Schritt S5. Hierbei werden die von dem HTTPS-Server 13 unter Verwendung des SSL-Moduls 19 aufgebaute HTTPS- Verbindung 52 (über die Protokolle HTTP, SSL, TCP, IP) und die von dem SIP-Modul 12 aufgebaute VoIP- Verbindung 51 (über die Protokolle SIP, RTP, UDP, IP) zumindest teilweise parallel betrieben. Die unterhalb der Netz- werkschicht des IP-Protokolls verwendeten hardwarenahen Netzzugangsprotokolle sind bei der VoIP- Verbindung 51 und der HTTPS- Verbindung 52 gleich und werden in dem IP-Stapel 20 (IP Stack) zusammengefasst.
Der in dem Handshake-Schritt S5 ausgehandelte Schlüssel 21 wird an die von dem SIP-Modul 12 unterstützte RTP-Schicht übergeben und von dieser zur Ver-/ Entschlüsselung von VoIP-Datenpaketen eingesetzt. Alternativ kann der ausgehandelte Schlüssel auch in einer optionalen IPsec-Schicht von der VoIP-Einrichtung 12 eingesetzt werden.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Aufbauen einer sicheren Kommunikationsverbindung zwischen einem ersten und einem zweiten Telekommunikationsendgerät (10, 30), umfassend den Schritt des Aufbauens (Sl, S2, S3) einer VoIP- Verbindung (51) zwischen dem ersten und dem zweiten Telekommunikationsendgerät (10, 30) auf Veranlassung des ersten Telekommunikationsendgeräts (10) zum Übertragen von VoIP-Datenpaketen, gekennzeichnet durch die weiteren Schritte:
Aufbauen (S4) einer separaten Datenverbindung (52) zwischen dem ersten und dem zweiten Telekommunikationsendgerät (10, 30); Vereinbaren (S4c) eines symmetrischen Schlüssels (21) durch ein Schlüsselaustauschverfahren beim Schritt des Aufbauens (S4) der sepa- raten Datenverbindung (52);
Verwenden (S5, S6) des vereinbarten symmetrischen Schlüssels (21) zum Verschlüsseln von über die VoIP- Verbindung (51) zu übertragenden und/ oder zum Entschlüsseln von über die VoIP- Verbindung (51) empfangenen VoIP-Datenpaketen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als separate Datenverbindung (52) eine SSL- Verbindung aufgebaut wird und der symmetrische Schlüssel (21) durch einen SSL-Handshake (S4c) vereinbart wird.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass als separate Datenverbindung (52) eine HTTPS- Verbindung aufgebaut wird, die eine SSL- Verbindung umfasst.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass bei dem Aufbauen (S4) der separaten Datenverbindung (52) eine Au- thentisierung (S4b, S4a) des ersten Telekommunikationsendgeräts (10) gegenüber dem zweiten Telekommunikationsendgerät (30) und/ oder des zweiten Telekommunikationsendgeräts (30) gegenüber dem ersten Telekommunikationsendgerät (10) durchgeführt wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass zur Au- thentisierung (S4b) des ersten Telekommunikationsend geräts (10) gegenüber dem zweiten Telekommunikationsendgerät (30) ein Geheimnis signiert wird und die Signatur durch das zweite Telekommunikationsendgerät (30) verifiziert wird.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Ge- heimnis auf einem mit dem ersten Telekommunikationsendgerät (10) verbundenen portablen Datenträger (22), vorzugsweise einer Chipkarte, mit einem auf dem Datenträger (22) vorliegenden privaten Signaturschlüssel signiert wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die separate Datenverbindung (52) während des Aufbaus der VoIP- Verbindung (51) aufgebaut wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass der vereinbarte symmetrische Schlüssel (21) in einem zum Betrieb der VoIP- Verbindung (51) eingesetzten RTP-Protokoll und/ oder IPsec-Protokoll zur Verschlüsselung und Entschlüsselung von VoIP-Datenpaketen verwendet wird.
9. Verfahren nach Anspruch 1 bis 8, dadurch gekennzeichnet, dass zum Aufbauen (Sl, S2, S3) der VoIP- Verbindung (51) folgende Schritte durchgeführt werden:
Richten einer Anfrage (Sl) mit einer Kennung des zweiten Telekommu- nikationsendgeräts (30) an einen Zentralserver (40) durch das erste Telekommunikationsendgerät (10);
Ermitteln einer IP- Adresse des zweiten Telekommunikationsendgeräts (30) und Übertragen (S2) der IP- Adresse an das erste Telekommunikationsendgerät (10) durch den Zentralserver (40), und - Kontaktieren (S3) des zweiten Telekommunikationsendgeräts (30) über dessen IP- Adresse durch das erste Telekommunikationsendgerät (10).
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die von dem Zentralserver (40) ermittelte IP- Adresse zum Aufbauen (S4) der separa- ten Datenverbindung (52) verwendet wird.
11. Telekommunikationsendgerät (10), umfassend eine VoIP-Einrichtung (12), die eingerichtet ist, eine VoIP- Verbindung (52) zu einem zweiten Telekommunikationsendgerät (30) aufzubauen und über die VoIP- Verbindung (51) VoIP-Datenpakete zu übertragen und/ oder zu empfangen, gekennzeichnet durch eine Verbindungseinrichtung (13), die eingerichtet ist, eine separate Datenverbindung (52) zu dem zweiten Telekommunikationsendgerät (30) aufzubauen, - eine Sicherheitseinrichtung (19), die eingerichtet ist, beim Aufbauen der separaten Datenverbindung (52) einen symmetrischen Schlüssel (21) mit dem zweiten Telekommunikationsendgerät (30) zu vereinbaren, und eine Steuereinrichtung (11), die eingerichtet ist, den vereinbarten symmetrischen Schlüssel (21) der VoIP-Einrichtung (12) zum Verschlüsseln von zu übertragenden und/ oder zum Entschlüsseln von empfangenen VoIP-Datenpaketen bereitzustellen.
12. Telekommunikationsendgerät (10) gemäß Anspruch 11, dadurch gekennzeichnet, dass die Verbindungseinrichtung (13) eingerichtet ist, als separate Datenverbindung (52) eine SSL- Verbindung aufzubauen, und die Sicherheitseinrichtung (19) ein SSL-Modul ist, das eingerichtet ist, den symme- trischen Schlüssel (21) durch einen SSL-Handshake mit dem zweiten Telekommunikationsendgerät (30) zu vereinbaren.
13. Telekommunikationsendgerät (10) gemäß Anspruch 12, dadurch gekennzeichnet, dass die Verbindungseinrichtung (13) ein Web-Server ist, der eingerichtet ist, als separate Datenverbindung (52) eine die SSL- Verbindung umfassende HTTPS- Verbindung aufzubauen.
14. Telekommunikationsendgerät (10) nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass die Sicherheitseinrichtung (19) beim Aufbau der separaten Datenverbindung (52) eine Authentisierung gegenüber dem zweiten Telekommunikationsend gerät (30) durchführt und/ oder eine Authentisierung des zweiten Telekommunikationsendgeräts (30) verifiziert.
15. Telekommunikationsendgerät (10) nach Anspruch 14, dadurch ge- kennzeichnet, dass die Sicherheitseinrichtung (19) eingerichtet ist, eine Authentisierung gegenüber dem zweiten Telekommunikationsendgerät (30) durch Übertragen eines mit einem Signaturschlüssel signierten Geheimnisses an das zweite Telekommunikationsendgerät (30) einzuleiten.
16. Telekommunikationsendgerät (10) nach Anspruch 15, dadurch gekennzeichnet, dass das Telekommunikationsendgerät (10) eine Leseeinrichtung (16) für einen portablen Datenträger (22) umfasst und die Steuereinrichtung (11) eingerichtet ist, das signierte Geheimnis von einem über die Lese- einrichtung (16) mit dem Telekommunikationsendgerät (10) verbundenen portablen Datenträger (22) zu erhalten und der Sicherheitseinrichtung (19) zur Authentisierung bereitzustellen.
17. Telekommunikationsendgerät (10) nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, dass die Steuereinrichtung (11) eingerichtet ist, die
VoIP-Einrichtung (12) zum Aufbau der VoIP- Verbindung (51) und die Verbindungseinrichtung (13) zum Aufbau der separaten Datenverbindung (52) derart zu aktivieren, dass der Aufbau der separaten Datenverbindung (52) während des Aufbaus der VoIP- Verbindung (51) erfolgt.
18. Telekommunikationsendgerät (10) nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass die VoIP-Einrichtung (12) eingerichtet ist, den vereinbarten symmetrischen Schlüssel (21) in einem zum Betrieb der VoIP- Verbindung (51) eingesetzten RTP-Protokoll und/ oder IPsec-Protokoll zur Verschlüsselung und Entschlüsselung von VoIP-Datenpaketen zu verwenden.
19. Telekommunikationsendgerät (10) nach Anspruch 11 bis 18, dadurch gekennzeichnet, dass die Steuereinrichtung (11) eingerichtet ist, zum Auf- bau einer VoIP- Verbindung (51) mit dem zweiten Telekommunikationsendgerät (30) ein Anfragesignal mit einer Kennung des zweiten Telekommunikationsendgeräts (30) an einen Zentralserver (40) zu senden und eine IP- Adresse des zweiten Telekommunikationsendgeräts (30) von dem Zentralserver (40) zu empfangen.
20. Telekommunikationsendgerät (10) nach Anspruch 19, dadurch gekennzeichnet, dass die Verbindungseinrichtung (13) eingerichtet ist, die separate Datenverbindung (52) mit der empfangenen IP- Adresse aufzubauen.
21. Telekommunikationsendgerät (10) nach einem der Ansprüche 11 bis 20, dadurch gekennzeichnet, dass das Telekommunikationsend gerät (10) ein mit einer Telephonie-Software ausgestatteter Computer, IP-Telefon oder WLAN-Telefon ist.
22. Telekommunikationsendgerät (10) nach Anspruch 16, dadurch gekennzeichnet, dass die Leseeinrichtung (16) ausgestaltet ist, eine Chipkarte, eine sichere Multimediakarte oder einen USB-Datenträger aufzunehmen.
PCT/EP2006/011200 2005-11-23 2006-11-22 Sichere voice-over-ip-telefonie WO2007059944A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005056112A DE102005056112A1 (de) 2005-11-23 2005-11-23 Sichere Voice-over-IP-Telefonie
DE102005056112.8 2005-11-23

Publications (1)

Publication Number Publication Date
WO2007059944A1 true WO2007059944A1 (de) 2007-05-31

Family

ID=37890777

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/011200 WO2007059944A1 (de) 2005-11-23 2006-11-22 Sichere voice-over-ip-telefonie

Country Status (2)

Country Link
DE (1) DE102005056112A1 (de)
WO (1) WO2007059944A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008004384A1 (de) * 2008-01-15 2009-07-16 Giesecke & Devrient Gmbh Sichere Datenkommunikation
DE102008051578A1 (de) * 2008-10-14 2010-04-15 Giesecke & Devrient Gmbh Datenkommunikation mit portablem Endgerät
CH709506A2 (it) * 2014-04-14 2015-10-15 Quantec Sa Dispositivo portatile di ricetrasmissione di flussi audio crittografati e metodo associato.

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002041564A2 (en) * 2000-11-16 2002-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Securing voice over ip traffic
DE10108825A1 (de) * 2001-02-23 2002-09-05 Siemens Ag Gesplittete Sicherheitsarchitektur für Voice over Internetprotocol
WO2005053290A1 (de) * 2003-11-27 2005-06-09 Siemens Aktiengesellschaft Sicherheitsmodul zum verschlüsseln eines telefongesprächs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002041564A2 (en) * 2000-11-16 2002-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Securing voice over ip traffic
DE10108825A1 (de) * 2001-02-23 2002-09-05 Siemens Ag Gesplittete Sicherheitsarchitektur für Voice over Internetprotocol
WO2005053290A1 (de) * 2003-11-27 2005-06-09 Siemens Aktiengesellschaft Sicherheitsmodul zum verschlüsseln eines telefongesprächs

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LO IACONO L ET AL: "Confidential Multimedia Communication in IP Networks", COMMUNICATION SYSTTEMS, 2002. ICCS 2002. THE 8TH INTERNATIONAL CONFERENCE ON NOV. 25-28, 2002, PISCATAWAY, NJ, USA,IEEE, vol. 1, 25 November 2002 (2002-11-25), pages 516 - 523, XP010629272, ISBN: 0-7803-7510-6 *

Also Published As

Publication number Publication date
DE102005056112A1 (de) 2007-05-31

Similar Documents

Publication Publication Date Title
DE102009043276B4 (de) Multimedia-Kommunikationssitzungskoordination über heterogene Transportnetze hinweg
EP1982494B1 (de) Verfahren, vorrichtung und computerprogrammprodukt zum verschlüsselten übertragen von mediendaten zwischen dem medienserver und dem teilnehmergerät
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
US7900249B2 (en) Method, system and software for maintaining network access and security
EP2014010B1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zum ver- und entschlüsseln von mediendaten
WO2009086845A1 (de) Verfahren zum authentisieren einer schlüsselinformation zwischen endpunkten einer kommunikationsbeziehung
CN1615626A (zh) 在通信网中利用已验证的业务质量传输信息
DE60036848T2 (de) Verfahren und Vorrichtungen zur Überwachung eines Internetprotokollnetzwerkes
EP2815565B1 (de) Verfahren zum handhaben einer telekommunikationsverbindung, telekommunikationsanordnung, vermittlungseinrichtung und netzkopplungseinrichtung
CN103546442B (zh) 浏览器的通讯监听方法及装置
WO2007059944A1 (de) Sichere voice-over-ip-telefonie
EP1847092A1 (de) Verfahren zur aufschaltung auf verschlüsselte kommunikationsverbindungen in einem paketorientierten netzwerk
DE102006002892A1 (de) Verfahren, System, Computerprogramm, Datenträger und Computerprogramm-Produkt zum Übertragen von Mediendaten eines Multicast-Dienstes
CN113114644B (zh) 一种基于sip架构的多级跨域对称密钥管理系统
EP1912406A2 (de) Kryptographische Berechnungen für VoIP-Verbindungen
Cycon et al. Connecting the worlds: multipoint videoconferencing integrating H. 323 and IPv4, SIP and IPv6 with autonomous sender authentication
EP1912405A1 (de) Initialisierung einer VoIP-Verbindung
EP1912419A1 (de) Personalisierung eines VoIP-Endgeräts
KR100418398B1 (ko) 맥어드레스를 이용한 가입자 인증 방법
DE202020002785U1 (de) Kryptografisches Headset
Perkins Reflections on security options for the real-time transport protocol framework
EP2101468B1 (de) Einbeziehung von Signalisierungsinformationen in ein Schlüsselmanagementprotokoll für den sicheren Medientransport
Kamble et al. Interoperability and Vulnerabilities in VoIP protocol (SIP, H. 323)
Lucenius Ad hoc conferencing in the IMS
Parnes Secure inclusion of phones into online e-meetings

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06829096

Country of ref document: EP

Kind code of ref document: A1