EP2082521A1 - Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls - Google Patents

Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls

Info

Publication number
EP2082521A1
EP2082521A1 EP07820477A EP07820477A EP2082521A1 EP 2082521 A1 EP2082521 A1 EP 2082521A1 EP 07820477 A EP07820477 A EP 07820477A EP 07820477 A EP07820477 A EP 07820477A EP 2082521 A1 EP2082521 A1 EP 2082521A1
Authority
EP
European Patent Office
Prior art keywords
cscf
time
symmetric key
uel
nonce
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07820477A
Other languages
English (en)
French (fr)
Inventor
Wolfgang BÜCKER
Günther Horn
Srinath Thiruvengadam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP2082521A1 publication Critical patent/EP2082521A1/de
Withdrawn legal-status Critical Current

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Definitions

  • the invention relates to a method for providing a symmetric key for securing a key management ⁇ ment protocol.
  • the technical field of the present invention relates to securing or encrypting media data between a subscriber device, such as a personal computer, and a provider device, such as a media server of a service provider or provider.
  • RFC 3711 defines a profile for RTP, Secure-RTP (SRTP), to secure the RTP stream.
  • SRTP Secure-RTP
  • SRTP can be used to secure media traffic on an end-to-end connection, ie the complete path between two communicating parties.
  • RTP can also be used for an end-to-middle connection.
  • a security protocol with an appropriate master key to derive Wegungsschlüs ⁇ clauses and cryptographic context must be provided.
  • An example of a cryptographic context is described in Section 3.2 of RFC 3711.
  • the master key and the cryptographic context Prior to the start of communication between the subscriber equipment and the provider equipment, such as a media proxy, the master key and the cryptographic context are not available in the subscriber equipment and the provider equipment. Thus, it is necessary to provide means which provide the main ⁇ key and the cryptographic context.
  • a key management protocol can be a ⁇ set.
  • MIKEY An example of a key management protocol for SRTP is MIKEY. MIKEY is described in
  • the key management protocol is executed between the subscriber equipment and the appropriate server of the network.
  • the appropriate server need not be the Me ⁇ serving proxy. Alternatively, this can coincide with the SIP proxy. However, the key management protocol itself must be backed up.
  • another object of the present invention is to secure a key management protocol for a protocol for the encrypted transmission of media data, such as SRTP, between a subscriber device and a provider device.
  • symmetric key ei ⁇ ner subscriber device and a corresponding provider means to provide means for securing a key management protocol for a protocol for encrypted transmission of media data between the user device and the provider.
  • a method for providing a symmetric key for securing a key management protocol, by means of which cryptographic material is generated for a protocol for the encrypted transmission of media data between a subscriber device and a provider device, the method being as follows Steps:
  • - Compute a second symmetric key for securing the key management protocol by means of a predetermined function as a function of at least the ready ⁇ provided first symmetric key and the provided first time-variable parameter by the provider device; and - calculating the second symmetric key using the predetermined function in dependence of at least the ready made ⁇ first symmetric key and the transmitted first time-varying parameter by the user equipment.
  • a method for encrypting media data between a subscriber device and a provider device comprises the following steps: providing a symmetric key of the subscriber device and the provider device by means of the above-explained method for providing a symmetric key for securing a Key management protocol; - Encrypt the media data in response to the symmetric key by the subscriber device or the provider device;
  • the present invention provides a way, the key management protocol, which cryptographic material means is generated with ⁇ means of a protocol, such as SRTP, to the encrypted media data see be- a subscriber device and a provider, to secure.
  • the backup of the key management protocol is advantageously carried out an easy-to-handle, symmetric encryption method secured with a symmetric key.
  • the protocol for the encrypted transmission of the media data is designed as a Secure Real-Time Transport Protocol (SRTP).
  • SRTP Secure Real-Time Transport Protocol
  • the key management protocol is designed as multimedia internet keying (MIKEY).
  • the securing mechanism as the authentication and / or Integri ⁇ tuschsprotokoll, in particular as HTTP digest protocol, out ⁇ forms.
  • the network protocol for establishing the communication connection is designed as a session initiation protocol (SIP).
  • SIP session initiation protocol
  • the cryptographic material has a master key for deriving session keys and cryptographic context.
  • the key management protocol is used in the control layer and / or in a media layer.
  • the method explained above further comprises the following steps: generating a second time-variable parameter by the subscriber device; - transmitting the generated second time-variable parameter from the subscriber device to the provider device;
  • a third time-variable parameter is derived in each case by the subscriber device and the provider device from the first time-variable parameter, as a function of which the second symmetric key is calculated by the subscriber device and the provider device.
  • the first time-variable parameter is a Number-Used-Once (Nonce) and / or the second time-variant parameter is one
  • Client-Defined-Nonce (CNonce) and / or the third zeitverän ⁇ cal parameters formed as a nonce count of the HTTP digest protocol.
  • the predetermined function is divisible into a first sub-function and a second sub-function, the first sub-function having at least the first symmetric key and the first time-variant parameter as the input parameter and the second sub-function at least a result of the first
  • the subscriber device and the provider device at least partially form an IP multimedia subsystem (IMS).
  • IMS IP multimedia subsystem
  • the provider apparatus of the IP Multimedia Subsystem IMS: a proxy functionality unit which is coupled to the parti ⁇ mer pain, and / or - a Interrogations functionality unit which with the proxy functionality unit coupled, and / or
  • server functionality unit which is coupled to the interrogation functionality unit, and / or
  • a home subscriber server unit which is coupled to the server functionality unit and stores at least the first symmetric key.
  • the HTTP digest protocol is executed between the subscriber device and the server functionality unit.
  • the HTTP digest protocol is executed between the subscriber device and the home subscriber server unit.
  • the first part function of the server functionality unit is ⁇ leads, the result of the first part-function is transmitted from the server functionality unit to the proxy functionality unit, the second zeitver Sli ⁇ che parameter is used by the proxy emp catch -JE Chemie ⁇ and the second part-function is performed by the proxy functionality unit.
  • the first part-function from the home subscriber server unit is ⁇ leads
  • the result of the first part function is provided by the Home Subscriber Server unit to the Proxy-Schein- Interrogations uniform over the functionality unit übertra ⁇ gene
  • the second time-varying parameter is received by the Pro ⁇ xy functionality unit and the second partial function is excluded from the proxy functionality unit performs.
  • the subscriber device has a SIP-based subscription with the provider device.
  • FIG. 1 shows a schematic block diagram of a SIP-based communication architecture to which the method according to the invention can be applied;
  • FIG. 2 shows a schematic flow diagram of a first exemplary embodiment of the method according to the invention
  • FIG. 3 shows a schematic flow diagram of a second embodiment of the method according to the invention.
  • FIG. 5 is a schematic flow diagram of a third embodiment of the method according to the invention, applied to the IMS architecture according to FIG. 4;
  • FIG. 6 shows a schematic flow diagram of a fourth embodiment of the method according to the invention, applied to the IMS architecture according to FIG. 4.
  • the same or functionally identical elements and units - unless otherwise indicated - have been given the same reference numerals.
  • FIG. 1 shows a schematic block diagram of a SIP-based communication architecture SKA to which the method according to the invention can be applied.
  • the SIP-based communication architecture SKA according to FIG. 1 is formed by a first user equipment UE1, a first provider equipment PE1, a second provider equipment PE2 and a second user equipment UE2.
  • the first subscriber device UE1 is coupled to the first provider device PE1.
  • the second subscriber device UE2 is coupled to the second provider device PE2.
  • the first provider device PE1 and the second provider device PE2 are coupled.
  • the Koppe ⁇ ment between the first provider device PEI and the second provider device PE2 can be formed by a network, in particular the Internet.
  • a provider device PE1, PE2 has a database DB1, DB2, a SIP proxy functional unit SP1, SP2 and a media proxy functionality unit MP1, MP2.
  • the Session Initiation Protocol SIP is particularly Zvi ⁇ rule of the subscriber device and the UEL SIP functionalities tucisritt SPl executed. For reasons of clarity, a corresponding representation for the second subscriber device UE2 and the second provider device PE2 is not shown.
  • the secure real-time protocol SRTP is executed between the first user equipment UE1 and the media proxy functionality unit MP1.
  • FIG. 2 is a schematic flow diagram of a first embodiment of the method according to the invention for Semi provide a symmetric key NK for securing a key management protocol, the system with which krytographi- ULTRASONIC material generated for a protocol for encrypted Götra ⁇ gene of media data MD between the subscriber device and the provider device UEL PEI is shown.
  • the method according to the invention will now be described with reference to the block diagram in FIG. 2 with reference to the architecture according to FIG. 1.
  • the first exemplary embodiment of the method according to the invention according to FIG. 2 has the following method steps S1 to S5:
  • a first symmetrical key DK is made available to the subscriber device UE1 and to the provider device PE1.
  • the first symmetric key DK is used in a generic keys based symmet ⁇ Sich ceremoniessmechanimus a network protocol of a control layer for establishing a Kiru ⁇ nikationssitzung between the subscriber device and the provider device UEL PEI.
  • a first time-variant parameter Nonce is provided by the provider device PE1.
  • the provided first time-variable parameter Nonce is transmitted from the provider device PE1 to the user equipment UE1.
  • the method steps S4 and S5 can also be carried out in the reverse order.
  • the provi ⁇ the device PEI is the NK key only calculated when the user equipment is authenticated UEL.
  • FIG. 3 A second embodiment of the procedural ⁇ proceedings according to the invention is shown in Fig. 3.
  • the secondstrasbei ⁇ game according to FIG. 3 the method steps Tl to T7.
  • the method steps Tl to T3 according to FIG. 3 correspond to the method steps S1 to S3 according to FIG.
  • the second embodiment of Figure 3 thus comprises the steps of Tl to T3, which correspond to the Ver ⁇ method steps Sl to S3 of Figure 2, and the following method steps T4 to T7.:
  • a second time-variable parameter CNonce is generated by the subscriber device UE1.
  • the generated second time-variable parameter CNonce is transmitted from the subscriber device UE1 to the provider device PE1.
  • the provi ⁇ the device PEI is the NK key only calculated when the user equipment is authenticated UEL.
  • the inventive method in particular for the embodiments according to FIGS. 2 and 3, follow ⁇ de embodiments are advantageously possible.
  • the protocol for the encrypted transmission of the media data MD can be embodied as a Secure Real-Time Transport Protocol (SRTP).
  • SRTP Secure Real-Time Transport Protocol
  • the key management protocol can be called
  • the locking mechanism may be an authentication and / or tegrticiansprotokoll In ⁇ , in particular a HTTP Digest Be a log.
  • the network protocol for the construction of the communi ⁇ cation compound may be the Session Initiation Protocol (SIP).
  • the cryptographic material may include a master key for deriving session keys and cryptographic context.
  • the key management protocol is used in the control layer and / or in a media layer.
  • a third time-variable parameter Nonce-Count can also be derived by the subscriber device UE1 and the provider device PE1 from the first time-variable parameter Nonce.
  • the second symmetric key NK can be calculated in each case by the subscriber device UE1 and the provider device PE1.
  • the HTTP digest authentication is that according to the invention is preferably used as a Si ⁇ cherungsmechanismus, described in RFC 2618 and RFC 3261st
  • the first time-variable parameter is preferably designed as a number-used-once (nonce).
  • the second time-variant parameter is in particular a client-defined nonce (CNonce).
  • the third time-variable parameter is preferably designed as a nonce count of the HTTP digest protocol.
  • the HTTP Digest protocol is its compliance is ⁇ as a backup mechanism for the Session Initiation Protocol SIP.
  • Examples of HTTP digest authentication are Push-To-Talk-over-Cellular (PoC) [OMA PoC Release 1] or ETSI TISPAN Specification ETSI TS 183033.
  • Another example of using HTTP digest for a IMS architecture is the packet cable specification PKT-SP-33.203.
  • the provider device PE1 of the IP multimedia subsystem IMS according to FIG. 4 has a proxy-functional unit P-CSCF, an interogation functional unit I-CSCF, a server-functional unit S-CSCF and a home-subscriber-server unit HSS ,
  • P-CSCF is coupled to the user equipment UEl.
  • the interrogation functionality unit I-CSCF is coupled to the proxy functional unit P-CSCF, the server functionality unit S-CSCF is coupled to the interrogation functionality unit I-CSCF and the home subscriber server unit HSS is connected to the Server functionality unit S-CSCF coupled.
  • spei ⁇ chert the Home Subscriber Server unit preferably the first symmetric key DK.
  • the user equipment UE1 and the home subscriber server unit HSS are each equipped with the symmetric key DK for authentication by the HTTP digest.
  • the user equipment UEl sends a first unauthorized SIP register message to the P-CSCF, which forwards it to the S-CSCF.
  • the S-CSCF queries a Nationalidenti ⁇ fication or Subscriptionsoire in the HSS. Two alternatives are possible:
  • the S-CSCF receives the key DK from the HSS.
  • the S-CSCF stores the key DK to authenticate ⁇ tion of the subscriber device UEL means of the next re gister message.
  • the S-CSCF terminates the HTTP digest protocol.
  • the S-CSCF generates the second key NK using the first key DK and the first time-variable parameter Nonce and sends the second key NK in the SIP-401 Unauthorized message to the P-CSCF.
  • the subscriber device UEL generated, after receiving this message, also the second Keyring ⁇ sel NK in a similar manner using the first key DK and the time varying parameter nonce.
  • ⁇ all recently has the P-CSCF the NK key corresponds removed from the message, or he would easily eavesdrop on the way from the P-CSCF to the user equipment UEL.
  • the subscriber key UE1 and the P-CSCF are thus aware of the second key NK.
  • the HSS generates the second key NK using the first key DK and the first time-variable parameter Nonce by means of the predetermined function F and sends the generated second key NK in an IMS message to the S-CSCF containing the second key NK in a SIP-401 Unauthorized message to P-CSCF go ⁇ passes.
  • the subscriber device UE1 will also, after having received this message, generate the second key NK in the same way using the nonce and the first key DK.
  • the P-CSCF has removed the key NK from the message, otherwise it would be easy to listen on the way from the P-CSCF to the user equipment UE1.
  • the first user equipment UE1 and the P-CSCF, the second key NK are provided.
  • Alternative 1 The S-CSCF NK generated using DK, Nonce and cnonce as input parameters for the Quilt ⁇ voted function F. But NK can not be 401 message from the S-CSCF to the P-CSCF because CNonce is not available in the S-CSCF at this time. However, it is possible to send NK in the SIP 200 OK message (see message 9 in FIG. 5).
  • the user equipment UE1 can also generate NK by means of the predetermined function F using DK, Nonce and CNonce.
  • the P-CSCF has the NK key from the message ent ⁇ removed, otherwise he would easily eavesdrop on the way from the P-CSCF to the user equipment UEL. Thus, the user equipment UE1 and the P-CSCF have the second key NK.
  • the predetermined function F can be divided into a first part function Fl and a second part function F2.
  • the first partial function F1 has at least the first symmetric key DK and the first time-variable parameter Nonce as the input parameter
  • the second partial function F2 has at least one result of the first partial function F1 (DK, Nonce) and the second time-variant Parameter CNonce as input parameter.
  • HSS performs the first part of function Fl and calculates the result Fl (Nonce, DK) and sends the result ⁇ He Fl (Nonce, DK) in an IMS message to the S-CSCF.
  • the subscriber device UE1 can then also, after having received this message, generate the second key NK using Nonce and DK.
  • the P-CSCF has the NK key is removed from the message, or he would easily eavesdrop on the way from the P-CSCF for part ⁇ taking purely directional UEL.
  • both the user equipment UEl and the P-CSCF have the same second key NK.
  • the result of the first partial function F1 (Nonce, DK) from the S-CSCF to the P-CSCF in the 401
  • the P-CSCF can calculate the second key NK depending on this and the intercepted CNonce.
  • the user equipment UEl sends the initial SIP register request to the address of the P-CSCF, which is preconfigured in the IMS architecture IMS.
  • the request includes an authorization header that has the private user identity IMPI.
  • the P-CSCF forwards the received message to the S-CSCF via the I-CSCF.
  • the I-CSCF is not shown in FIGS. 5 and 6.
  • the S-CSCF transmits authentication data from the HSS
  • the HSS responds with a multimedia Auth reply MAA, which contains the first key DK for the HTTP digest.
  • the S-CSCF generates the second key NK by means of the predetermined function F using DK and Nonce as input parameters.
  • the S-CSCF indexes the P-CSCF via the I-CSCF by means of a SIP 401 Unauthorized message that HTTP digest authentication was requested.
  • the SIP 401 Unauthorized message contains a WWW Authenticate header with the nonce.
  • the second Key NK is transported to the P-CSCF so that the key management protocol can be executed.
  • the P-CSCF may store the second key NK and forwards the SIP 401 Unauthorized message to the subscriber device ⁇ UEL, but without the second key NK.
  • the stored second key NK may not be used by the P-CSCF as long as the registration process is not successfully completed (from step 9 of FIG. 5, NK may be used).
  • the user equipment UEl calculates the digest value Digest using the stored first key DK and the received nonce.
  • the user equipment UEl sends a second SIP register request to the P-CSCF containing an authorization header comprising the IMPI and the calculated digest value Digest.
  • the P-CSCF forwards the received message via the I-CSCF to the S-CSCF.
  • the S-CSCF After the S-CSCF has received this message, be it expects ⁇ again the digest value Digest using the stored key DK, which it has previously received from the HSS, as a digest key and the nonce.
  • the S-CSCF compares the calculated digest value digest with the digest value Digest received from the user equipment UE1. If both match, the registration is successfully completed by sending a SIP 200 OK message to the user equipment UEl. If the 200-OK message passes the P-CSCF, the P-CSCF can also assume a successful com ⁇ pletting of the registration process and can from there on the second key NK, the chi saved in step 6, use ⁇ .
  • the user equipment UE1 If, for example, the user equipment UE1 wishes to have an encrypted session, it can store an encrypted master key enc (MK) in the SIP invitee. Message (see message 10 in FIG. 5) to the P-CSCF. The encryption of the master key MK in the encrypted master key enc (MK) is performed by means of the two ⁇ th symmetric key NK. After the second key NK of the P-CSCF is known, it can decrypt the received, encrypted master key enc (MK).
  • MK master key enc
  • the initiation of the session is confirmed by sending the second SIP OK message back to the user equipment UE1.
  • the session is initiated by the user equipment UE1.
  • the initiation of the session by the provider institution PEI, in particular through the P-CSCF SUC ⁇ gen.
  • FIG. 6 shows a schematic flow diagram of the method according to the invention for example 1 with alternative 2.
  • the fourth exemplary embodiment according to FIG. 6 differs from the third exemplary embodiment according to FIG. 5 in step 4.
  • Step 4 in FIG. 6 is different from step 4 in FIG 5, that the HSS according to Figure 6 only the second key NK and not directly sent the first key DK.
  • the expected digest value Di ⁇ gest is sent to the S-CSCF.

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)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Das Verfahren zum Bereistellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls, mittels welchem kryptographisches Material für ein Protokoll zum verschlüsselten Übertragen von Mediendaten zwischen einer Teilnehmereinrichtung und einer Provider-Einrichtung generiert wird, weist folgende Schritte auf: Bereitstellen eines ersten symmetrischen Schlüssels der Teilnehmereinrichtung und der Provider-Einrichtung, welcher in einem auf symmetrischen Schlüsseln basierenden Sicherungsmechanismus eines Netzprotokolls einer Kontrollschicht zum Aufbau einer Kommunikationssitzung zwischen der Teilnehmereinrichtung und der Provider-Einrichtung eingesetzt wird; Bereitstellen eines ersten zeitveränderlichen Parameters durch die Provider-Einrichtung; Übertragen des bereitgestellten ersten zeitveränderlichen Parameters von der Provider-Einrichtung an die Teilnehmereinrichtung; Berechnen eines zweiten symmetrischen Schlüssels für das Sichern des Schlüssel-Management-Protokolls mittels einer vorbestimmten Funktion in Abhängigkeit zumindest des bereitgestellten ersten symmetrischen Schlüssels und des bereitgestellten ersten zeitveränderlichen Parameters durch die Provider-Einrichtung; und Berechnen des zweiten symmetrischen Schlüssels mittels der vorbestimmten Funktion in Abhängigkeit zumindest des bereitgestellten ersten symmetrischen Schlüssels und des übertragenen ersten zeitveränderlichen Parameters durch die Teilnehmereinrichtung.

Description

Beschreibung
Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
Die Erfindung betrifft ein Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Manage¬ ment-Protokolls .
Das technische Gebiet der vorliegenden Erfindung betrifft das Sichern oder Verschlüsseln von Mediendaten zwischen einer Teilnehmereinrichtung, wie einem Personal-Computer, und einer Provider-Einrichtung, beispielsweise einem Medien-Server eines Dienstleisters oder Providers.
In den heutigen im Einsatz befindlichen SIP/RTP basierten Voice-over-IP Systemen (wie z.B. dem IP Multimedia Subsystem - IMS) werden typischerweise keine Maßnahmen zum Schutz der Mediendaten ergriffen. Dies mag vertretbar sein in Mobilfunk- netzen, die typischerweise eine Layer 2 Verschlüsselung anbieten, wie z.B. das UMTS bzw. GPRS Netz. In Festnetz- Szenarien sind aber solche unterliegenden Layer 2 Verschlüsselungen typischerweise nicht vorhanden, so dass hier eigene Mechanismen eingesetzt werden müssen. Dies ist umso dringli- eher, als beispielsweise das IMS in zunehmendem Maße auch in Festnetz-Szenarien eingesetzt wird und nicht nur im Mobil¬ netz-Umfeld, wofür es ursprünglich entwickelt wurde.
Ein möglicher Ansatz zum Sichern der Mediendaten besteht in einer Ende-zu-Ende Verschlüsselung zwischen den beiden Kommunikationspartnern. Hier trifft man allerdings auf diverse Probleme wie z.B. Schlüssel-Management, Lawful Interception, Transcodierung etc. Eine bessere Variante scheint daher ein Ende-zu-Mitte (end-to-middle) Ansatz zu sein, bei dem die Si- cherung nur zwischen dem Endgerät und einer Providereinrichtung (z.B. einem Medien-Proxy) erfolgt. In einem Ende-zu-Ende-Sicherheitsszenario sind die Signali- sierungsendpunkte und die Mediensicherheitsendpunkte diesel¬ ben, in einem Ende-zu-Mitte-Szenario sind sie verschieden. RFC 3711 definiert ein Profil für RTP, nämlich Secure-RTP (SRTP), um den RTP-Strom zu sichern. SRTP kann genutzt werden, um den Medienverkehr bei einer End-zu-End-Verbindung zu sichern, d.h. den kompletten Pfad zwischen zwei kommunizierenden Teilnehmern. Auch für eine Ende-zu-Mitte-Verbindung ist RTP einsetzbar.
Es ist eine Aufgabe der vorliegenden Erfindung, Mediendaten zwischen einer Teilnehmereinrichtung und einer Provider- Einrichtung hinsichtlich Integrität und Vertraulichkeit unter Verwendung eines geeigneten Sicherheitsprotokolls, wie SRTP, zu schützen.
Allerdings muss ein solches Sicherheitsprotokoll mit einem geeigneten Hauptschlüssel zur Ableitung von Sitzungsschlüs¬ seln und kryptographischem Kontext ausgestattet werden. Ein Beispiel für einen kryptographischen Kontext ist in Abschnitt 3.2 des RFC 3711 beschrieben. Vor dem Start einer Kommunikation zwischen der Teilnehmereinrichtung und der Provider- Einrichtung, wie beispielsweise einem Medien-Proxy, sind der Hauptschlüssel und der kryptographische Kontext nicht in der Teilnehmereinrichtung und der Provider-Einrichtung verfügbar. Somit ist es notwendig, Mittel vorzusehen, welche den Haupt¬ schlüssel und den kryptographischen Kontext bereitstellen. Für diesen Zweck kann ein Schlüssel-Management-Protokoll ein¬ gesetzt werden. Ein Beispiel für ein Schlüssel-Management- Protokoll für SRTP ist MIKEY. MIKEY ist beschrieben in
RRC 3830. Das Schlüssel-Management-Protokoll wird zwischen der Teilnehmereinrichtung und dem geeigneten Server des Netzwerkes ausgeführt. Der geeignete Server muss nicht der Me¬ dien-Proxy sein. Alternativ kann dieser auch mit dem SIP- Proxy zusammenfallen. Allerdings muss das Schlüssel- Management-Protokoll selbst gesichert werden. Somit ist eine weitere Aufgabe der vorliegenden Erfindung, ein Schlüssel-Management-Protokoll für ein Protokoll zum ver¬ schlüsselten Übertragen von Mediendaten, wie SRTP, zwischen einer Teilnehmereinrichtung und einer Provider-Einrichtung zu sichern.
Des Weiteren ist es eine Aufgabe, symmetrische Schlüssel ei¬ ner Teilnehmereinrichtung und einer entsprechenden Provider- Einrichtung zum Sichern eines Schlüssel-Management-Protokolls für ein Protokoll zum verschlüsselten Übertragen von Mediendaten zwischen der Teilnehmereinrichtung und der Provider- Einrichtung bereitzustellen.
Erfindungsgemäß wird zumindest eine dieser gestellten Aufgabe durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 und/oder durch ein Verfahren mit den Merkmalen des Patentanspruchs 15 gelöst.
Demgemäß wird ein Verfahren zum Bereistellen eines symmetri- sehen Schlüssels zum Sichern eines Schlüssel-Management- Protokolls vorgeschlagen, mittels welchem kryptographisches Material für ein Protokoll zum verschlüsselten Übertragen von Mediendaten zwischen einer Teilnehmereinrichtung und einer Provider-Einrichtung generiert wird, wobei das Verfahren fol- gende Schritte aufweist:
- Bereitstellen eines ersten symmetrischen Schlüssels der Teilnehmereinrichtung und der Provider-Einrichtung, welcher in einem auf symmetrischen Schlüsseln basierenden Sicherungsmechanismus eines Netzprotokolls einer Kontrollschicht zum Aufbau einer Kommunikationssitzung zwischen der Teilnehmereinrichtung und der Provider-Einrichtung eingesetzt wird;
- Bereitstellen eines ersten zeitveränderlichen Parameters durch die Provider-Einrichtung;
- Übertragen des bereitgestellten ersten zeitveränderlichen Parameters von der Provider-Einrichtung an die Teilnehmereinrichtung;
- Berechnen eines zweiten symmetrischen Schlüssels für das Sichern des Schlüssel-Management-Protokolls mittels einer vorbestimmten Funktion in Abhängigkeit zumindest des bereit¬ gestellten ersten symmetrischen Schlüssels und des bereitgestellten ersten zeitveränderlichen Parameters durch die Provider-Einrichtung; und - Berechnen des zweiten symmetrischen Schlüssels mittels der vorbestimmten Funktion in Abhängigkeit zumindest des bereit¬ gestellten ersten symmetrischen Schlüssels und des übertragenen ersten zeitveränderlichen Parameters durch die Teilnehmereinrichtung.
Des Weiteren wird ein Verfahren zum Verschlüsseln von Mediendaten zwischen einer Teilnehmereinrichtung und einer Provider-Einrichtung vorgeschlagen, welches folgende Schritte aufweist : - Bereitstellen eines symmetrischen Schlüssels jeweils der Teilnehmereinrichtung und der Provider-Einrichtung mittels des oben erläuterten Verfahrens zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management- Protokolls; - Verschlüsseln der Mediendaten in Abhängigkeit des symmetrischen Schlüssels durch die Teilnehmereinrichtung oder die Provider-Einrichtung;
Senden der verschlüsselten Mediendaten durch die Teilnehmereinrichtung oder die Provider-Einrichtung; - Empfangen der verschlüsselten Mediendaten durch die Provider-Einrichtung oder die Teilnehmereinrichtung; und
Entschlüsseln der empfangenen Mediendaten mittels des bereitgestellten symmetrischen Schlüssels durch die Provider- Einrichtung oder die Teilnehmereinrichtung.
Vorteilhafterweise stellt die vorliegenden Erfindung eine Möglichkeit bereit, das Schlüssel-Management-Protokoll, mit¬ tels welchem kryptographisches Material für ein Protokoll, wie SRTP, zum verschlüsselten Übertragen von Mediendaten zwi- sehen einer Teilnehmereinrichtung und einer Provider- Einrichtung generiert wird, zu sichern. Die Sicherung des Schlüssel-Management-Protokolls wird vorteilhafterweise durch ein einfach handhabbares, symmetrisches Verschlüsselungsverfahren mit einem symmetrischen Schlüssel gesichert.
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfin- düng ergeben sich aus den Unteransprüchen sowie der Beschreibung der Bezugnahme auf die Zeichnungen.
Gemäß einer bevorzugten Ausgestaltung der Erfindung ist das Protokoll zum verschlüsselten Übertragen der Mediendaten als Secure-Real-Time-Transport-Protokoll (SRTP) ausgebildet.
Gemäß einer weiteren bevorzugten Ausgestaltung ist das Schlüssel-Management-Protokoll als Multimedia-Internet-Keying (MIKEY) ausgebildet.
Gemäß einer weiteren bevorzugten Ausgestaltung ist der Sicherungsmechanismus als Authentifizierungs- und/oder Integri¬ tätsprotokoll, insbesondere als HTTP-Digest-Protokoll, ausge¬ bildet.
Gemäß einer weiteren bevorzugten Ausgestaltung ist das Netzprotokoll zum Aufbau der Kommunikationsverbindung als Sessi- on-Initiation-Protokoll (SIP) ausgebildet.
Gemäß einer weiteren bevorzugten Ausgestaltung weist das kryptographische Material einen Hauptschlüssel zur Ableitung von Sitzungsschlüsseln und kryptographischen Kontext auf.
Gemäß einer weiteren bevorzugten Ausgestaltung wird das Schlüssel-Management-Protokoll in der Kontrollschicht und/oder in einer Medienschicht eingesetzt.
Gemäß einer bevorzugten Weiterbildung der Erfindung weist das oben erläuterte Verfahren weiter folgende Schritte auf: - Generieren eins zweiten zeitveränderlichen Parameters durch die Teilnehmereinrichtung; - Übertragen des generierten zweiten zeitveränderlichen Parameters von der Teilnehmereinrichtung an die Provider- Einrichtung;
- Berechnen des zweiten symmetrischen Schlüssels in Abhängig- keit des bereitgestellten ersten symmetrischen Schlüssels, des bereitgestellten ersten zeitveränderlichen Parameters und des von der Teilnehmereinrichtung übertragenen, zweiten zeitveränderlichen Parameters durch die Provider-Einrichtung; und Berechnen des zweiten symmetrischen Schlüssels in Abhän- gigkeit des bereitgestellten ersten symmetrischen Schlüssels, des von der Provider-Einrichtung übertragenen ersten zeitveränderlichen Parameters und des generierten zweiten zeitveränderlichen Parameters durch die Teilnehmereinrichtung.
Gemäß einer weiteren bevorzugten Weiterbildung wird ein dritter zeitveränderlicher Parameter jeweils durch die Teilnehmereinrichtung und die Provider-Einrichtung von dem ersten zeitveränderlichen Parameter abgeleitet, in dessen Abhängigkeit der zweite symmetrische Schlüssel jeweils durch die Teilnehmereinrichtung und die Provider-Einrichtung berechnet wird.
Gemäß einer weiteren bevorzugten Ausgestaltung ist der erste zeitveränderliche Parameter als eine Number-Used-Once (Nonce) und/oder der zweite zeitveränderliche Parameter als eine
Client-Defined-Nonce (CNonce) und/oder der dritte zeitverän¬ derliche Parameter als ein Nonce-Count des HTTP-Digest- Protokolls ausgebildet.
Gemäß einer weiteren bevorzugten Ausgestaltung ist die vorbestimmte Funktion in eine erste Teil-Funktion und in eine zweite Teil-Funktion teilbar, wobei die erste Teil-Funktion zumindest den ersten symmetrischen Schlüssel und den ersten zeitveränderlichen Parameter als Eingangsparameter hat und die zweite Teil-Funktion zumindest ein Ergebnis der ersten
Teil-Funktion und den zweien zeitveränderlichen Parameter als Eingangsparameter hat . Gemäß einer weiteren bevorzugten Ausgestaltung bilden die Teilnehmereinrichtung und die Provider-Einrichtung zumindest teilweise ein IP-Multimedia-Subsystem (IMS) aus.
Gemäß einer weiteren bevorzugten Ausgestaltung weist die Provider-Einrichtung des IP-Multimedia-Subsystems (IMS) auf: eine Proxy-Funktionalitätseinheit, welche mit der Teilneh¬ mereinrichtung gekoppelt ist, und/oder - eine Interrogations-Funktionalitätseinheit , welche mit der Proxy-Funktionalitätseinheit gekoppelt ist, und/oder
- eine Server-Funktionalitätseinheit, welche mit der Interro- gations-Funktionalitätseinheit gekoppelt ist, und/oder
- eine Home-Subscriber-Server-Einheit , welche mit der Ser- ver-Funktionalitätseinheit gekoppelt ist und zumindest den ersten symmetrischen Schlüssel speichert.
Gemäß einer weiteren bevorzugten Ausgestaltung wird das HTTP- Digest-Protokoll zwischen der Teilnehmereinrichtung und der Server-Funktionalitätseinheit ausgeführt.
Gemäß einer weiteren bevorzugten Ausgestaltung wird das HTTP- Digest-Protokoll zwischen der Teilnehmereinrichtung und der Home-Subscriber-Server-Einheit ausgeführt .
Gemäß einer weiteren bevorzugten Ausgestaltung wird die erste Teil-Funktion von der Server-Funktionalitätseinheit ausge¬ führt, das Ergebnis der ersten Teil-Funktion wird von der Server-Funktionalitätseinheit an die Proxy- Funktionalitätseinheit übertragen, der zweite zeitveränderli¬ che Parameter wird von der Proxy-Funktionalitätseinheit emp¬ fangen und die zweite Teil-Funktion wird von der Proxy- Funktionalitätseinheit ausgeführt .
Gemäß einer weiteren bevorzugten Ausgestaltung wird die erste Teil-Funktion von der Home-Subscriber-Server-Einheit ausge¬ führt, das Ergebnis der ersten Teil-Funktion wird von der Home-Subscriber-Server-Einheit an die Proxy-Funktionalitätsein- heit über die Interrogations-Funktionalitätseinheit übertra¬ gen, der zweite zeitveränderliche Parameter wird von der Pro¬ xy-Funktionalitätseinheit empfangen und die zweite Teil- Funktion wird von der Proxy-Funktionalitätseinheit ausge- führt .
Gemäß einer weiteren bevorzugten Ausgestaltung hat die Teilnehmereinrichtung eine SIP-basierte Subskription mit der Provider-Einrichtung.
Die Erfindung wird nachfolgend anhand der in den schemati¬ schen Figuren angegebenen Ausführungsbeispiele näher erläutert. Es zeigen:
Fig. 1 ein schematisches Blockschaltbild einer SIP- basierten Kommunikations-Architektur, auf welches das erfindungsgemäße Verfahren anwendbar ist;
Fig. 2 ein schematisches Ablaufdiagramm eines ersten Aus- führungsbeispiels des erfindungsgemäßen Verfahrens;
Fig. 3 ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels des erfindungsgemäßen Verfahrens;
Fig. 4 ein schematisches Blockschaltbild einer IMS-
Architektur, auf welche das erfindungsgemäße Ver¬ fahren anwendbar ist;
Fig. 5 ein schematisches Ablaufdiagramm eines dritten, auf die IMS-Architektur gemäß Fig. 4 angewendeten Ausführungsbeispiels des erfindungsgemäßen Verfahrens; und
Fig. 6 ein schematisches Ablaufdiagramm eines vierten, auf die IMS-Architektur gemäß Fig. 4 angewendeten Ausführungsbeispiels des erfindungsgemäßen Verfahrens. In allen Figuren sind gleiche bzw. funktionsgleiche Elemente und Einheiten - sofern nichts anderes angegeben ist - mit denselben Bezugszeichen versehen worden.
Fig. 1 zeigt ein schematisches Blockschaltbild einer SIP- basierten Kommunikations-Architektur SKA, auf welche das erfindungsgemäße Verfahren anwendbar ist.
Die SIP-basierte Kommunikations-Architektur SKA gemäß Fig. 1 ist durch eine erste Teilnehmereinrichtung UEl, eine erste Provider-Einrichtung PEl, eine zweite Provider-Einrichtung PE2 und eine zweite Teilnehmereinrichtung UE2 ausgebildet. Dabei ist die erste Teilnehmereinrichtung UEl mit der ersten Provider-Einrichtung PEl gekoppelt. Die zweite Teilnehmerein- richtung UE2 ist mit der zweiten Provider-Einrichtung PE2 gekoppelt. Weiterhin sind die erste Provider-Einrichtung PEl und die zweite Provider-Einrichtung PE2 gekoppelt. Die Koppe¬ lung zwischen der ersten Provider-Einrichtung PEl und der zweiten Provider-Einrichtung PE2 kann durch ein Netzwerk, insbesondere dem Internet, ausgebildet sein.
Eine Provider-Einrichtung PEl, PE2 weist eine Datenbank DBl, DB2, eine SIP-Proxy-Funktionalitätseinheit SPl, SP2 und eine Media-Proxy-Funktionalitätseinheit MPl, MP2 auf.
Das Session-Initiation-Protokoll SIP wird insbesondere zwi¬ schen der Teilnehmereinrichtung UEl und der SIP-Funktionali- tätseinheit SPl ausgeführt. Aus Gründen der Übersichtlichkeit ist eine entsprechende Darstellung für die zweite Teilnehmer- einrichtung UE2 und die zweite Provider-Einrichtung PE2 nicht dargestellt .
Das Secure-Real-Time-Protokoll SRTP wird zwischen der ersten Teilnehmereinrichtung UEl und der Media-Proxy- Funktionalitätseinheit MPl ausgeführt.
In Fig. 2 ist ein schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels des erfindungsgemäßen Verfahrens zum Be- reitstellen eines symmetrischen Schlüssels NK zum Sichern eines Schlüssel-Management-Protokolls, mit welchem krytographi- sches Material für ein Protokoll zum verschlüsselten Übertra¬ gen von Mediendaten MD zwischen der Teilnehmereinrichtung UEl und der Provider-Einrichtung PEl generiert wird, dargestellt. Nachfolgend wird das erfindungsgemäße Verfahren anhand des Blockschaltbildes in Fig. 2 unter Verweis auf die Architektur gemäß Fig. 1 beschrieben. Das erste Ausführungsbeispiel des erfindungsgemäßen Verfahrens gemäß Fig. 2 weist folgende Ver- fahrensschritte Sl bis S5 auf:
Verfahrensschritt Sl:
Ein erster symmetrischer Schlüssel DK wird der Teilnehmerein- richtung UEl und der Provider-Einrichtung PEl bereitgestellt. Der erste symmetrische Schlüssel DK wird in einem auf symmet¬ rischen Schlüsseln basierenden Sicherungsmechanimus eines Netzprotokolls einer Kontrollschicht zum Aufbau einer Kommu¬ nikationssitzung zwischen der Teilnehmereinrichtung UEl und der Provider-Einrichtung PEl eingesetzt.
Verfahrensschritt S2 :
Es wird ein erster zeitveränderlicher Parameter Nonce durch die Provider-Einrichtung PEl bereitgestellt.
Verfahrensschritt S3:
Der bereitgestellte erste zeitveränderliche Parameter Nonce wird von der Provider-Vorrichtung PEl an die Teilnehmereinrichtung UEl übertragen.
Verfahrensschritt S4:
Ein zweiter symmetrischer Schlüssel NK wird für das Sichern des Schlüssel-Management-Protokolls mittels einer vorbestimm¬ ten Funktion F in Abhängigkeit zumindest des bereitgestellten ersten symmetrischen Schlüssels DK und des bereitgestellten ersten zeitveränderlichen Parameters Nonce durch die Provider-Einrichtung PEl berechnet (NK = F(DK, Nonce)).
Verfahrensschritt S5:
Der zweite symmetrische Schlüssel NK wird mittels der vorbe¬ stimmten Funktion F in Abhängigkeit zumindest des bereitge¬ stellten ersten symmetrischen Schlüssel DK und des übertragenen ersten zeitveränderlichen Parameters Nonce durch die Teilnehmereinrichtung UEl berechnet (NK = F (DK, Nonce) ) .
Die Verfahrensschritte S4 und S5 können auch in umgekehrter Reihenfolge durchgeführt werden. Vorzugsweise wird die Provi¬ der-Einrichtung PEl den Schlüssel NK erst berechnen, wenn die Teilnehmereinrichtung UEl authentifiziert ist.
Somit ist sowohl der Provider-Einrichtung PEl als auch der Teilnehmereinrichtung UEl der symmetrische Schlüssel NK bekannt .
Ein zweites Ausführungsbeispiel des erfindungsgemäßen Verfah¬ rens ist in Fig. 3 dargestellt. Das zweite Ausführungsbei¬ spiel gemäß Fig. 3 weist die Verfahrensschritte Tl bis T7 auf. Dabei entsprechen die Verfahrensschritte Tl bis T3 gemäß Fig. 3 den Verfahrensschritten Sl bis S3 gemäß Fig. 2. Aus
Gründen der Übersichtlichkeit wird auf deren erneute Darstel¬ lung verzichtet. Das zweite Ausführungsbeispiel gemäß Fig. 3 weist also die Verfahrensschritte Tl bis T3, welche den Ver¬ fahrensschritten Sl bis S3 gemäß Fig. 2 entsprechen, und die folgenden Verfahrensschritte T4 bis T7 auf:
Verfahrensschritt T4 :
Es wird ein zweiter zeitveränderlicher Parameter CNonce durch die Teilnehmereinrichtung UEl generiert. Der generierte zweite zeitveränderliche Parameter CNonce wird von der Teilnehmereinrichtung UEl an die Provider-Einrichtung PEl übertragen.
Verfahrensschritt T6:
Der zweite symmetrische Schlüssel NK wird in Abhängigkeit des bereitgestellten ersten symmetrischen Schlüssels DK, des bereitgestellten ersten zeitveränderlichen Parameters Nonce und des von der Teilnehmereinrichtung UEl übertragenen, zweiten zeitveränderlichen Parameters CNonce durch die Provider-Einrichtung PEl berechnet (NK = F(DK, Nonce, CNonce)).
Verfahrensschritt T7 :
Der zweite symmetrische Schlüssel NK wird in Abhängigkeit des bereitgestellten ersten symmetrischen Schlüssels DK, des von der Provider-Einrichtung PEl übertragenen, ersten zeitveränderlichen Parameters Nonce und des generierten, zweiten zeitveränderlichen Parameters CNonce durch die Teilnehmereinrichtung UEl berechnet (NK = F (DK, Nonce, CNonce) ) .
Die Verfahrensschritte T6 und T7 können auch in umgekehrter
Reihenfolge durchgeführt werden. Vorzugsweise wird die Provi¬ der-Einrichtung PEl den Schlüssel NK erst berechnen, wenn die Teilnehmereinrichtung UEl authentifiziert ist. Für das erfindungsgemäße Verfahren, dabei insbesondere für die Ausführungsbeispiele gemäß der Fig. 2 und 3, sind folgen¬ de Ausgestaltungen vorteilhafterweise möglich.
Das Protokoll zum verschlüsselten Übertragen der Mediendaten MD kann als Secure-Real-Time-Transport-Protokoll (SRTP) aus- gebildet sein. Das Schlüssel-Management-Protokoll kann als
Multimedia-Internet-Keying (MIKEY) ausgebildet sein. Der Sicherungsmechanismus kann ein Authentifizierungs- und/oder In¬ tegritätsprotokoll, dabei insbesondere ein HTTP-Digest- Protokoll sein. Das Netzwerkprotokoll zum Aufbau der Kommuni¬ kationsverbindung kann das Session-Initiation-Protokoll (SIP) sein. Weiterhin kann das kryptographische Material einen Hauptschlüssel zur Ableitung von Sitzungsschlüsseln und kryp- tographischem Kontext aufweisen.
Vorzugsweise wird das Schlüssel-Management-Protokoll in der Kontrollschicht und/oder in einer Medienschicht eingesetzt. Insbesondere kann auch ein dritter zeitveränderlicher Parame- ter Nonce-Count jeweils durch die Teilnehmereinrichtung UEl und die Provider-Einrichtung PEl von dem ersten zeitveränderlichen Parameter Nonce abgeleitet werden. In Abhängigkeit von diesem dritten zeitveränderlichen Parameter Nonce-Count kann der zweite symmetrische Schlüssel NK jeweils durch die Teil- nehmereinrichtung UEl und die Provider-Einrichtung PEl berechnet werden. Insbesondere ist die HTTP-Digest- Authentification, welche erfindungsgemäß vorzugsweise als Si¬ cherungsmechanismus eingesetzt wird, in RFC 2618 und RFC 3261 beschrieben. Vorzugsweise ist der erste zeitveränderliche Pa- rameter als eine Number-Used-Once (Nonce) ausgebildet. Der zweite zeitveränderliche Parameter ist insbesondere eine Client-Defined-Nonce (CNonce) . Der dritte zeitveränderliche Parameter ist vorzugsweise als Nonce-Count des HTTP-Digest- Protokolls ausgebildet.
Im Folgenden wird der Einsatz der Erfindung in einer IMS- Architektur erläutert. Dazu ist in Figur 4 ein schematisches Blockschaltbild einer solchen IMS-Architektur IMS dargestellt. Das HTTP-Digest-Protokoll wird dabei als Sicherungs- mechanismus für das Session-Initiation-Protokoll SIP einge¬ setzt. Beispiele für HTTP-Digest als Authentifizierungsmecha- nismus finden sich in Push-To-Talk-over-Cellular (PoC) [OMA PoC Release 1] oder in ETSI TISPAN Spezifikation ETSI TS 183033. Ein weiteres Beispiel der Verwendung von HTTP-Digest für eine IMS-Architektur ist die Packet-Cable-Spezifikation PKT-SP-33.203. Die Provider-Einrichtung PEl des IP-Multimedia-Subsystems IMS gemäß Figur 4 weist eine Proxy-Funktionalitätseinheit P-CSCF, eine Interogations-Funktionseinheit I-CSCF, eine Server- Funktionalitätseinheit S-CSCF und eine Home-Subscriber- Server-Einheit HSS auf. Die Proxy-Funktionalitätseinheit
P-CSCF ist mit der Teilnehmereinrichtung UEl gekoppelt. Die Interrogations-Funktionalitätseinheit I-CSCF ist mit der Pro- xy-Funktionaltitätseinheit P-CSCF gekoppelt, die Server- Funktionalitätseinheit S-CSCF ist mit der Interrogations- Funktionalitätseinheit I-CSCF gekoppelt und die Home- Subscriber-Server-Einheit HSS ist mit der Server- Funktionalitätseinheit S-CSCF gekoppelt. Des Weiteren spei¬ chert die Home-Subscriber-Server-Einheit vorzugsweise den ersten symmetrischen Schlüssel DK.
Wenn also HTTP-Digest in der IMS-Architektur IMS verwendet wird, so sind die Teilnehmereinrichtung UEl und die Home- Subscriber-Server-Einheit HSS jeweils mit dem symmetrischen Schlüssel DK für die Authentifizierung durch das HTTP-Digest ausgestattet. Während einer Sitzungs-Initiierung sendet die Teilnehmereinrichtung UEl eine erste unauthorisierte SIP- Register-Nachricht zur P-CSCF, welche diese an die S-CSCF weiterleitet. Die S-CSCF fragt bei der HSS eine Nutzeridenti¬ fizierung oder Subscriptionsdaten ab. Dabei sind zwei Alter- nativen möglich:
Alternative 1: Die S-CSCF erhält den Schlüssel DK von der HSS. Die S-CSCF speichert den Schlüssel DK zur Authentifizie¬ rung der Teilnehmereinrichtung UEl mittels der nächsten Re- gister-Nachricht . Die S-CSCF terminiert das HTTP-Digest- Protokoll .
Alternative 2: Die HSS sendet den Schlüssel DK nicht an die S-CSCF. Die HSS terminiert das HTTP-Digest-Protokoll selbst und berechnet alle für das verwendete Protokoll erforderli¬ chen Nachrichten. Folgende zwei Beispiele zeigen zwei unterschiedliche Ausges¬ taltungen der Erfindung für beide oben erläuterten Alternativen :
Beispiel 1 : Verwendung von Nonce ohne CNonce
Für Alternative 1: Die S-CSCF generiert den zweiten Schlüssel NK unter Verwendung des ersten Schlüssels DK und des ersten zeitveränderlichen Parameters Nonce und sendet den zweiten Schlüssel NK in der SIP-401-Unauthorized-Nachricht zur P- CSCF. Die Teilnehmereinrichtung UEl generiert, nachdem sie diese Nachricht empfangen hat, ebenfalls den zweiten Schlüs¬ sel NK in ähnlicher Weise unter Verwendung des ersten Schlüssels DK und des zeitveränderlichen Parameters Nonce. Aller¬ dings hat die P-CSCF den Schlüssel NK aus der Nachricht ent- fernt, sonst wäre er auf dem Weg von der P-CSCF zur Teilnehmereinrichtung UEl leicht abzuhören. Somit sind der Teilnehmereinrichtung UEl und der P-CSCF der zweite Schlüssel NK bekannt .
Für Alternative 2: Die HSS generiert den zweiten Schlüssel NK unter Verwendung des ersten Schlüssels DK und des ersten zeitveränderlichen Parameters Nonce mittels der vorbestimmten Funktion F und sendet den generierten zweiten Schlüssel NK in einer IMS-Nachricht zur S-CSCF, welche den zweiten Schlüssel NK in einer SIP-401-Unauthorized-Nachricht zur P-CSCF weiter¬ leitet. Die Teilnehmereinrichtung UEl wird ebenfalls, nachdem sie diese Nachricht empfangen hat, den zweiten Schlüssel NK in gleicher Weise unter Verwendung der Nonce und des ersten Schlüssels DK generieren. Allerdings hat die P-CSCF den Schlüssel NK aus der Nachricht entfernt, sonst wäre er auf dem Weg von der P-CSCF zur Teilnehmereinrichtung UEl leicht abzuhören. Somit sind der ersten Teilnehmereinrichtung UEl und der P-CSCF der zweite Schlüssel NK bereitgestellt.
Beispiel 2: Verwendung von Nonce und CNonce
Für Alternative 1: Die S-CSCF generiert NK unter Verwendung von DK, Nonce und CNonce als Eingangsparameter für die vorbe¬ stimmte Funktion F. Aber NK kann nicht in der 401-Nachricht von der S-CSCF an die P-CSCF gesendet werden, da CNonce zu diesem Zeitpunkt in der S-CSCF nicht verfügbar ist. Allerdings ist es möglich, NK in der SIP-200-OK-Nachricht (siehe Nachricht 9 in Figur 5) zu senden. Die Teilnehmereinrichtung UEl kann ebenfalls NK mittels der vorbestimmten Funktion F unter Verwendung von DK, Nonce und CNonce generieren. Allerdings hat die P-CSCF den Schlüssel NK aus der Nachricht ent¬ fernt, sonst wäre er auf dem Weg von der P-CSCF zur Teilnehmereinrichtung UEl leicht abzuhören. Somit besitzen die Teil- nehmereinrichtung UEl und die P-CSCF den zweiten Schlüssel NK.
Vorzugsweise kann die vorbestimmte Funktion F in eine erste Teil-Funktion Fl und eine zweite Teil-Funktion F2 unterteilt werden. Dabei hat die erste Teil-Funktion Fl zumindest den ersten symmetrischen Schlüssel DK und den ersten zeitveränderlichen Parameter Nonce als Eingangsparameter und die zweite Teil-Funktion F2 hat zumindest ein Ergebnis der ersten Teil-Funktion Fl (DK, Nonce) und den zweiten zeitveränderli- chen Parameter CNonce als Eingangsparameter. Dann kann das
Ergebnis der ersten Teil-Funktion (DK, Nonce) von der S-CSCF zu der P-CSCF [in der 401-Nachricht ] gesendet werden und die P-CSCF kann NK in Abhängigkeit von diesem und einem abgefangenen CNonce berechnen. Dies ist dann möglich, wenn die P- CSCF die HTTP-Digest-Header empfängt oder abfängt.
Für Alternative 2: HSS führt die erste Teil-Funktion Fl aus und berechnet deren Ergebnis Fl (Nonce, DK) und sendet das Er¬ gebnis Fl (Nonce, DK) in einer IMS-Nachricht an die S-CSCF. Die S-CSCF kann dann den zweiten Schlüssel NK (NK = F2 (CNonce, Fl (Nonce, DK))) in der SIP-200-OK-Nachricht zur P-CSCF weiterleiten. Die Teilnehmereinrichtung UEl kann dann ebenfalls, nachdem sie diese Nachricht empfangen hat, den zweiten Schlüssel NK unter Verwendung von Nonce und DK generieren. Allerdings hat die P-CSCF den Schlüssel NK aus der Nachricht entfernt, sonst wäre er auf dem Weg von der P-CSCF zur Teil¬ nehmereinrichtung UEl leicht abzuhören. Somit werden sowohl die Teilnehmereinrichtung UEl als auch die P-CSCF denselben zweiten Schlüssel NK besitzen.
Als eine Variante wird das Ergebnis der ersten Teil-Funktion Fl(Nonce,DK) von der S-CSCF zu der P-CSCF in der 401-
Nachricht gesendet und die P-CSCF kann den zweiten Schlüssel NK in Abhängigkeit von diesem und dem abgefangenen CNonce berechnen .
Dazu zeigt Figur 5 ein schematisches Ablaufdiagramm des er¬ findungsgemäßen Verfahrens gemäß Beispiel 1 mit Alternative 1:
1. Die Teilnehmereinrichtung UEl sendet die initiale SIP- Register-Anfrage zur Adresse der P-CSCF, welche in der IMS- Architektur IMS vorkonfiguriert ist. Die Anfrage beinhaltet einen Authorisierungs-Header, der die Private-User-Identity IMPI aufweist.
2. Die P-CSCF leitet die empfangene Nachricht zur S-CSCF über die I-CSCF weiter. Aus Gründen der Übersichtlichkeit ist die I-CSCF in den Figuren 5 und 6 nicht dargestellt.
3. Nachdem die SIP-Register-Anfrage empfangen wurde, über- trägt die S-CSCF Authentifizierungsdaten von der HSS durch
Senden einer Cx-Multimedia-Auth-Request MAR mit der IMPI. Da¬ zu wird auf 3GPP TS 29.229 verwiesen.
4. Die HSS antwortet mit einer Multimedia-Auth-Antwort MAA, welche den ersten Schlüssel DK für das HTTP-Digest.
5. Die S-CSCF generiert den zweiten Schlüssel NK mittels der vorbestimmten Funktion F unter Verwendung von DK und Non- ce als Eingangsparameter. Die S-CSCF indiziert der P-CSCF über die I-CSCF mittels einer SIP-401-Unauthorized-Nachricht , dass die HTTP-Digest-Authentifizierung angefragt wurde. Die SIP-401-Unauthorized-Nachricht enthält einen WWW- Authenticate-Header mit der Nonce . Zusätzlich wird der zweite Schlüssel NK zur P-CSCF transportiert, sodass das Schlüssel- Management-Protokoll ausgeführt werden kann.
6. Die P-CSCF kann den zweiten Schlüssel NK speichern und leitet die SIP-401-Unauthorized-Nachricht zu der Teilnehmer¬ einrichtung UEl, allerdings ohne den zweiten Schlüssel NK. Der gespeicherte zweite Schlüssel NK darf nicht durch die P-CSCF verwendet werden, solange der Registrierungs-Prozess nicht erfolgreich beendet ist (ab Schritt 9 gemäß Figur 5 kann NK verwendet werden) .
7. Die Teilnehmereinrichtung UEl berechnet den Digest-Wert Digest unter Verwendung des gespeicherten ersten Schlüssels DK und der empfangenen Nonce . Die Teilnehmereinrichtung UEl sendet eine zweite SIP-Register-Anfrage zur P-CSCF, welche einen Authorisierungs-Header beinhaltet, der die IMPI und den kalkulierten Digest-Wert Digest aufweist.
8. Die P-CSCF leitet die empfangene Nachricht über die I-CSCF an die S-CSCF weiter.
9. Nachdem die S-CSCF diese Nachricht empfangen hat, be¬ rechnet sie erneut den Digest-Wert Digest unter Verwendung des gespeicherten Schlüssels DK, den sie vorher von der HSS empfangen hat, als Digest-Schlüssel und der Nonce. Die S-CSCF vergleicht den berechneten Digest-Wert Digest mit dem von der Teilnehmereinrichtung UEl empfangenen Digest-Wert Digest. Falls beide übereinstimmen, ist die Registrierung durch Senden einer SIP-200-OK-Nachricht an die Teilnehmereinrichtung UEl erfolgreich beendet. Wenn die 200-OK-Nachricht die P-CSCF passiert, kann die P-CSCF ebenfalls eine erfolgreiche Kom¬ plettierung des Registrierungsprozesses annehmen und kann von da ab den zweiten Schlüssel NK, den sie in Schritt 6 gespei¬ chert hat, verwenden.
10. Falls beispielsweise die Teilnehmereinrichtung UEl eine verschlüsselte Sitzung haben möchte, kann sie einen verschlüsselten Hauptschlüssel enc (MK) in der SIP-Invite- Nachricht (siehe Nachricht 10 gemäß Figur 5) an die P-CSCF übertragen. Die Verschlüsselung des Hauptschlüssels MK in den verschlüsselten Hauptschlüssel enc (MK) wird mittels des zwei¬ ten symmetrischen Schlüssels NK durchgeführt. Nachdem der zweite Schlüssel NK der P-CSCF bekannt ist, kann diese den empfangenen, verschlüsselten Hauptschlüssel enc (MK) entschlüsseln .
11. Die Initiierung der Sitzung wird durch Senden der zwei- ten SIP-OK-Nachricht zurück zur Teilnehmereinrichtung UEl bestätigt .
Ab Schritt 10 in Figur 5 ist eine Initiierung der Sitzung durch die Teilnehmereinrichtung UEl durchgeführt. Alternativ kann die Initiierung der Sitzung auch durch die Provider- Einrichtung PEl, dabei insbesondere durch die P-CSCF erfol¬ gen .
Figur 6 zeigt ein schematisches Ablaufdiagramm des erfin- dungsgemäßen Verfahrens für Beispiel 1 mit Alternative 2. Das vierte Ausführungsbeispiel gemäß Figur 6 unterscheidet sich von dem dritten Ausführungsbeispiel gemäß Figur 5 in Schritt 4. Schritt 4 in Figur 6 ist dahingehend unterschiedlich zu Schritt 4 in Figur 5, dass die HSS gemäß Figur 6 nur den zweiten Schlüssel NK und nicht direkt den ersten Schlüssel DK versendet. Zusätzlich wird noch der erwartete Digest-Wert Di¬ gest zur S-CSCF gesendet.
Obwohl die vorliegende Erfindung vorstehend anhand der bevor- zugten Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Art und Weise modi¬ fizierbar. Beispielsweise ist es denkbar, den Schlüssel NK erst in der 200 OK Nachricht von der S-CSCF zur P-CSCF zu senden. Des Weiteren ist es denkbar, die Erfindung auf eine Nicht-IMS-Architektur anzuwenden. In einer solchen Nicht-IMS- Architektur kann der SIP-Proxy direkt mit dem ersten symmetrischen Schlüssel DK ausgestattet werden, sodass ein Empfan¬ gen des ersten Schlüssels DK von einer Datenbank oder ein Transfer des zweiten Schlüssels NK von S-CSCF/HSS zur P-CSCF nicht notwendig wird.

Claims

Patentansprüche
1. Verfahren zum Bereitstellen eines symmetrischen Schlüssels (NK) zum Sichern eines Schlüssel-Management- Protokolls, mittels welchem kryptographisches Material für ein Protokoll zum verschlüsselten Übertragen von Mediendaten (MD) zwischen einer Teilnehmereinrichtung (UEl) und einer Provider-Einrichtung (PEl) generiert wird, mit den Schritten:
(a) Bereitstellen eines ersten symmetrischen Schlüssels (DK) der Teilnehmereinrichtung (UEl) und der Provider-Einrichtung
(PEl), welcher in einem auf symmetrischen Schlüsseln basierenden Sicherungsmechanismus eines Netzprotokolls einer Kon¬ trollschicht zum Aufbau einer Kommunikationssitzung zwischen der Teilnehmereinrichtung (UEl) und der Provider-Einrichtung (PEl) eingesetzt wird;
(b) Bereitstellen eines ersten zeitveränderlichen Parameters (Nonce) durch die Provider-Einrichtung (PEl);
(c) Übertragen des bereitgestellten ersten zeitveränderlichen Parameters (Nonce) von der Provider-Einrichtung (PEl) an die Teilnehmereinrichtung (UEl);
(d) Berechnen eines zweiten symmetrischen Schlüssels (NK) für das Sichern des Schlüssel-Management-Protokolls mittels einer vorbestimmten Funktion (F) in Abhängigkeit zumindest des bereitgestellten ersten symmetrischen Schlüssels (DK) und des bereitgestellten ersten zeitveränderlichen Parameters (Nonce) durch die Provider-Einrichtung (PEl); und
(e) Berechnen des zweiten symmetrischen Schlüssels (NK) mittels der vorbestimmten Funktion (F) in Abhängigkeit zumindest des bereitgestellten ersten symmetrischen Schlüssels (DK) und des übertragenen ersten zeitveränderlichen Parameters (Nonce) durch die Teilnehmereinrichtung (UEl).
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Protokoll zum verschlüsselten Übertragen der Mediendaten (MD) als Secure-Real-Time-Transport-Protocol (SRTP) und/oder das Schlüssel-Management-Protokoll als Multimedia-Internet- Keying (MIKEY) und/oder der Sicherungsmechanismus als Authentifizierungs- und/oder Integritätsprotokoll, insbesondere als HTTP-Digest-Protokoll, und/oder das Netzprotokoll zum Aufbau der Kommunikationsverbindung als Session-Initiation-Protocol (SIP) ausgebildet sind/ist und/oder das kryptographische Material einen Hauptschüssel zur Ablei- tung von Sitzungsschlüsseln und kryptographischen Kontext aufweist .
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Schlüssel-Management-Protokoll in der Kontroll¬ schicht und/oder in einer Medienschicht eingesetzt wird.
4. Verfahren nach Anspruch 1 oder einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass das Verfahren weiter folgende Schritte aufweist:
Generieren eines zweiten zeitveränderlichen Parameters (CNonce) durch die Teilnehmereinrichtung (UEl);
Übertragen des generierten zweiten zeitveränderlichen Pa- rameters (CNonce) von der Teilnehmereinrichtung (UEl) an die Provider-Einrichtung (PEl)
Berechnen des zweiten symmetrischen Schlüssels (NK) in Abhängigkeit des bereitgestellten ersten symmetrischen Schlüssels (DK) , des bereitgestellten ersten zeitveränderli- chen Parameters (Nonce) und des von der Teilnehmereinrichtung (UEl) übertragenen, zweiten zeitveränderlichen Parameters (CNonce) durch die Provider-Einrichtung (PEl); und
Berechnen des zweiten symmetrischen Schlüssels (NK) in Abhängigkeit des bereitgestellten ersten symmetrischen Schlüssels (DK), des von der Provider-Einrichtung (PEl) übertragenen ersten zeitveränderlichen Parameters (Nonce) und des generierten, zweiten zeitveränderlichen Parameters (CNonce) durch die Teilnehmereinrichtung (UEl) .
5. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-4, dadurch gekennzeichnet, dass ein dritter zeitveränderlicher Parameter (Nonce-Count) jeweils durch die Teilnehmereinrichtung (UEl) und die Provider-Einrichtung (PEl) von dem ersten zeitveränderlichen Parameter (Nonce) abgeleitet wird, in dessen Abhängigkeit der zweite symmetrische Schlüssel (NK) jeweils durch die Teilneh¬ mereinrichtung (UEl) und die Provider-Einrichtung (PEl) be- rechnet wird.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der erste zeitveränderliche Parameter (Nonce) als eine Number-Used-Once (Nonce) und/oder der zweite zeitveränderli¬ che Parameter als eine Client-Defined-Nonce (CNonce) und/oder der dritte zeitveränderliche Parameter als ein Nonce-Count des HTTP-Digest-Protokolls ausgebildet sind/ist.
7. Verfahren nach einem der Ansprüche 4-6, dadurch gekennzeichnet, dass die vorbestimmte Funktion (F) in eine erste Teil- Funktion (Fl) und in eine zweite Teil-Funktion (F2) teilbar ist, wobei die erste Teil-Funktion (Fl) zumindest den ersten symmetrischen Schlüssel (DK) und den ersten zeitveränderlichen Parameter (Nonce) als Eingangsparameter hat und die zweite Teil-Funktion (F2) zumindest ein Ergebnis der ersten Teil-Funktion (Fl (DK, Nonce) ) und den zweiten zeitveränderlichen Parameter (CNonce) als Eingangsparameter hat.
8. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-7, dadurch gekennzeichnet, dass die Teilnehmereinrichtung (UEl) und die Provider- Einrichtung (PEl) zumindest teilweise ein IP-Multimedia- Subsystem (IMS) ausbilden.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Provider-Einrichtung (PEl) des IP-Multimedia- Subsystems (IMS) aufweist: eine Proxy-Funktionalitätseinheit (P-CSCF) , welche mit der Teilnehmereinrichtung (UEl) gekoppelt ist, und/oder eine Interrogations-Funktionalitätseinheit (I-CSCF), wel¬ che mit der Proxy-Funktionalitätseinheit (P-CSCF) gekoppelt ist, und/oder - eine Server-Funktionalitätseinheit (S-CSCF), welche mit der Interrogations-Funktionalitätseinheit (I-CSCF) gekoppelt ist und/oder eine Home-Subscriber-Server-Einheit (HSS), welche mit der Server-Funktionalitätseinheit (S-CSCF) gekoppelt ist und zu¬ mindest den ersten symmetrischen Schlüssel (DK) speichert.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das HTTP-Digest-Protokoll zwischen der Teilnehmerein¬ richtung (UEl) und der Server-Funktionalitätseinheit (S-CSCF) ausgeführt wird.
11. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das HTTP-Digest-Protokoll zwischen der Teilnehmerein¬ richtung (UEl) und der Home-Subscriber-Server-Einheit (HSS) ausgeführt wird.
12. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die erste Teil-Funktion (Fl) von der Server- Funktionalitätseinheit (S-CSCF) ausgeführt wird, das Ergebnis der ersten Teil-Funktion (Fl (DK, Nonce) ) von der Server- Funktionalitätseinheit (S-CSCF) an die Proxy- Funktionalitätseinheit (P-CSCF) übertragen wird, der zweite zeitveränderliche Parameter (CNonce) von der Proxy- Funktionalitätseinheit (P-CSCF) empfangen wird und die zweite Teil-Funktion (F2) von der Proxy-Funktionalitätseinheit (P- CSCF) ausgeführt wird.
13. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die erste Teil-Funktion (Fl) von der Home-Subscriber- Server-Einheit (HSS) ausgeführt wird, das Ergebnis (Fl (DK, Nonce) ) der ersten Teil-Funktion (Fl) von der Home- Subscriber-Server-Einheit (HSS) an die Proxy- Funktionalitätseinheit (P-CSCF) übertragen wird, der zweite zeitveränderliche Parameter (CNonce) von der Proxy- Funktionalitätseinheit (P-CSCF) empfangen wird und die zweite Teil-Funktion (F2) von der Proxy-Funktionalitätseinheit (P- CSCF) ausgeführt wird.
14. Verfahren nach Anspruch 1 oder einem der Ansprüche 2 bis 13, dadurch gekennzeichnet, dass die Teilnehmereinrichtung (UEl) eine SIP-basierte Sub- skription mit der Provider-Einrichtung (PEl) hat.
15. Verfahren zum Verschlüsseln von Mediendaten (MD) zwischen einer Teilnehmereinrichtung (UEl) und einer Provider- Einrichtung (PEl) mit den Schritten: - Bereitstellen eines symmetrischen Schlüssels (NK) jeweils zur Teilnehmereinrichtung (UEl) und der Provider- Einrichtung (PEl) mittels des Verfahrens nach Anspruch 1 oder einem oder mehreren der Ansprüche 2 bis 14;
Verschlüsseln der Mediendaten (MD) in Abhängigkeit des bereitgestellten symmetrischen Schlüssels (NK) durch die
Teilnehmereinrichtung (UEl) oder Provider-Einrichtung (PEl); - Senden der verschlüsselten Mediendaten (MD) ;
Empfangen der verschlüsselten Mediendaten durch die Provider-Einrichtung (PEl) oder Teilnehmereinrichtung (UEl); und - Entschlüsseln der empfangenen Mediendaten (MD) mittels des bereitgestellten symmetrischen Schlüssels (MK) durch die Provider-Einrichtung (PEl) oder durch die Teilnehmereinrichtung (UEl) .
EP07820477A 2006-09-28 2007-09-24 Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls Withdrawn EP2082521A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006046017A DE102006046017B4 (de) 2006-09-28 2006-09-28 Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
PCT/EP2007/060069 WO2008037670A1 (de) 2006-09-28 2007-09-24 Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls

Publications (1)

Publication Number Publication Date
EP2082521A1 true EP2082521A1 (de) 2009-07-29

Family

ID=39052439

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07820477A Withdrawn EP2082521A1 (de) 2006-09-28 2007-09-24 Verfahren zum bereitstellen eines symmetrischen schlüssels zum sichern eines schlüssel-management-protokolls

Country Status (7)

Country Link
US (1) US8488795B2 (de)
EP (1) EP2082521A1 (de)
JP (1) JP2010505313A (de)
KR (1) KR101488167B1 (de)
CN (1) CN101536399A (de)
DE (1) DE102006046017B4 (de)
WO (1) WO2008037670A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006006071A1 (de) * 2006-02-09 2007-08-16 Siemens Ag Verfahren zum Übertragen von Mediendaten, Netzwerkanordnung mit Computerprogrammprodukt
US20120137137A1 (en) * 2010-11-30 2012-05-31 Brickell Ernest F Method and apparatus for key provisioning of hardware devices
WO2015062239A1 (zh) * 2013-11-04 2015-05-07 华为技术有限公司 密钥协商处理方法和装置
CN103560892A (zh) * 2013-11-21 2014-02-05 深圳中兴网信科技有限公司 密钥生成方法和密钥生成装置
CN104683304B (zh) * 2013-11-29 2019-01-01 中国移动通信集团公司 一种保密通信业务的处理方法、设备和系统
CN104901966B (zh) * 2015-06-02 2016-06-08 慧锐通智能科技股份有限公司 一种网络通讯的密钥配置方法及系统
US10545940B2 (en) 2017-02-22 2020-01-28 Red Hat, Inc. Supporting secure layer extensions for communication protocols

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5720034A (en) * 1995-12-07 1998-02-17 Case; Jeffrey D. Method for secure key production
JP2002290391A (ja) 2001-03-26 2002-10-04 Toyo Commun Equip Co Ltd 共通鍵暗号方式におけるセッション鍵生成方式及び暗号化／復号装置。
WO2003049357A2 (en) * 2001-12-07 2003-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Lawful interception of end-to-end encrypted data traffic
SG105005A1 (en) 2002-06-12 2004-07-30 Contraves Ag Device for firearms and firearm
DE10238928B4 (de) * 2002-08-22 2009-04-30 Nokia Siemens Networks Gmbh & Co.Kg Verfahren zur Authentifizierung eines Nutzers eines Kommunikationsendgerätes bei Nutzung eines Dienstnetzes
DE10307403B4 (de) * 2003-02-20 2008-01-24 Siemens Ag Verfahren zum Bilden und Verteilen kryptographischer Schlüssel in einem Mobilfunksystem und Mobilfunksystem
US7908484B2 (en) * 2003-08-22 2011-03-15 Nokia Corporation Method of protecting digest authentication and key agreement (AKA) against man-in-the-middle (MITM) attack
EP1673921B1 (de) * 2003-10-14 2018-11-28 Siemens Aktiengesellschaft Verfahren zur sicherung des datenverkehrs zwischen einem mobilfunknetz und einem ims-netz
DE10355418B4 (de) * 2003-11-27 2008-04-03 Siemens Ag Sicherheitsmodul zum Verschlüsseln eines Telefongesprächs
US7657036B2 (en) * 2004-09-21 2010-02-02 Qualcomm Incorporated Determining a session encryption key during a broadcast/multicast service session using secure real-time transport protocol

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2008037670A1 *

Also Published As

Publication number Publication date
KR20090067194A (ko) 2009-06-24
DE102006046017B4 (de) 2010-01-14
US20100034384A1 (en) 2010-02-11
CN101536399A (zh) 2009-09-16
KR101488167B1 (ko) 2015-01-30
WO2008037670A1 (de) 2008-04-03
WO2008037670B1 (de) 2008-06-12
DE102006046017A1 (de) 2008-04-03
US8488795B2 (en) 2013-07-16
JP2010505313A (ja) 2010-02-18

Similar Documents

Publication Publication Date Title
EP1595420B1 (de) Verfahren zum bilden und verteilen kryptographischer schlüssel in einem mobilfunksystem und entsprechendes mobilfunksystem
DE60209475T2 (de) Datensicherungs-kommunikationsvorrichtung und -verfahren
EP1793525B1 (de) Verfahren zum Ändern eines Gruppenschlüssels in einer Gruppe von Netzelementen in einem Netz
WO1997047109A1 (de) Verfahren zum kryptographischen schlüsselmanagement zwischen einer ersten computereinheit und einer zweiten computereinheit
DE102006046017B4 (de) Verfahren zum Bereitstellen eines symmetrischen Schlüssels zum Sichern eines Schlüssel-Management-Protokolls
EP2014010B1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zum ver- und entschlüsseln von mediendaten
EP1982494A1 (de) Verfahren, vorrichtung und computerprogrammprodukt zum verschlüsselten übertragen von mediendaten zwischen dem medienserver und dem teilnehmergerät
WO2009086845A1 (de) Verfahren zum authentisieren einer schlüsselinformation zwischen endpunkten einer kommunikationsbeziehung
WO2019145207A1 (de) Verfahren und system zur offenlegung mindestens eines kryptographischen schlüssels
DE102020003739A1 (de) Verfahren zur Verteilung und Aushandlung von Schlüsselmaterial
EP3759958B1 (de) Verfahren, vorrichtung und computerprogrammprodukt zur überwachung einer verschlüsselten verbindung in einem netzwerk
DE102006002892A1 (de) Verfahren, System, Computerprogramm, Datenträger und Computerprogramm-Produkt zum Übertragen von Mediendaten eines Multicast-Dienstes
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung
EP3955511B1 (de) Gesicherte datenübertragung innerhalb eines qkd-netzwerkknotens
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
EP3005645B1 (de) Verfahren zur sicherung von telekommunikationsverkehrsdaten
DE102022002973B3 (de) Verfahren zur verschlüsselten Übermittlung von Daten
WO2004064316A1 (de) Telekommunikationsgestützter zeitstempel
EP2101468B1 (de) Einbeziehung von Signalisierungsinformationen in ein Schlüsselmanagementprotokoll für den sicheren Medientransport
DE10325816B4 (de) Infrastruktur für öffentliche Schlüssel für Netzwerk-Management
DE10255618A1 (de) Verfahren zur Datenverkehrssicherung in einer mobilen Netzumgebung
DE10356091A1 (de) Verfahren zur Sicherung des Datenverkehrs zwischen einem Mobilfunknetz und einem IMS-Netz
EP1647108A1 (de) Verfahren und sicherheitssystem zum erkennen einer unverfälschten teilnehmer-identität bei einem empfänger
DE10310735A1 (de) Einrichtung zur kryptographisch gesicherten Übertragung von Daten
CH698115B1 (de) Verfahren und Vorrichtung zur Erbringung von temporal authentifizierten Versand- und Empfangsbestätigungen in einem elektronischen Nachrichtenvermittlungssystem.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090218

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110801

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20170703