Verfahren zum Authentisieren einer Schlüsselinformation zwischen Endpunkten einer Kommunikationsbeziehung

In Kommunikationsnetzen, insbesondere in Voice over IP Kommunikationsnetzen, wird eine Kommunikationsbeziehung bzw. Verbindung häufig gemäß dem SIP- Protokoll (Session Internet Protocol) gesteuert. Für die übertragung von Datenströmen bzw. Multimediadatenströmen, d.h. der Nutzinformation bzw. der Video- und/oder Sprachinformation, wird meist das RTP- Protokoll (Real Time Protocol) verwendet. Das RTP- Protokoll ist im RFC Standard 1889 bzw. seit 2003 im RFC Standard 3550 definiert. Aufgrund gestiegener Sicherheitsbedürfnisse werden die Datenströme seit geraumer Zeit verschlüsselt übertragen, wobei dieses gesicherte RTP- Protokoll (SRTP) im RFC- Standard 3711 beschrieben ist. Für das SRTP- Protokoll sind gemeinsame geheime Schlüssel erforderlich, die mit einem geeigneten Protokoll ausgetauscht werden, wobei derartige Protokolle der Fachwelt auch als Key Management Protocols bekannt sind.

Ein bekanntes Key Management Protocol ist als MIKEY Protocol bekannt, das im RFC- Standard RFC 3830 definiert ist, wobei dieses Protokoll in das Signalisierungsprotokoll SIP eingebettet ist.

Ein weiteres Key Management Protocol ist das DTLS- SRTP- Protokoll (Data Transport Layer Security - Secure Transport Protocol) . Das DTLS- Protokoll basiert auf dem TLS- Protokoll (Transport Layer Security) und stellt ein Verschlüsselungs- protokoll für Datenübertragungen über das Internet dar. Das DTLS- Protokoll kann auch über unzuverlässigere Protokolle wie UDP- Protokoll (User Datagram Protocol) eingesetzt werden. Das DTLS- SRTP- Protokoll ist innerhalb des Nutzdatenkanals bzw. Mediendatenkanals realisiert, wobei der Schlüssel - austausch durch Zertifikate und den assoziierten privaten Schlüsseln authentisiert wird. Die Zertifikate werden nicht

von einer vertrauenswürdigen PKI- Instanz (Public Key Infrastructure) sondern durch die jeweiligen Endpunkte bzw. Endeinrichtung selbst signiert. Derartige Zertifikate sind nicht geeignet Endpunkte zu authentisieren, die in das Key Management Protocol einbezogen sind, da kein Vertrauensverhältnis zu einem gemeinsamen Sicherheitsanker existiert. Um die Authentisierung mit der Einrichtung zu sichern, mit der eine Kommunikationsbeziehung vorgesehen ist, wird eine oder werden mehrere in der Fachwelt als Fingerprint bezeichnete Sicherungsinformationen gebildet und innerhalb der SIP- Message übertragen. Der Fingerprint ist jeweils auf einen öffentlichen Schlüssel oder ein Zertifikat bezogen und stellt üblicherweise den Hashwert einer auf den öffentlichen Schlüssel oder Zertifikat angewendeten Hashfunktion dar. Der Hash- wert ist eine gegenüber dem öffentlichen Schlüssel bzw. Zeri- tifikat kürzere Zahlenfolge, wobei der Hashwert den öffentlichen Schlüssel jedoch eindeutig identifiziert. Der Fingerprint wird innerhalb der SIP- Nachricht durch eine Signatur - beispielsweise nach dem RFC Standard 4474 gesichert, die allgemein für die Sicherung des Kopfteils bzw. Headers und des SIP- Bodys vorgesehen ist, wobei der SIP- Body den Nutzdatenteil einer SIP- Nachricht darstellt, in dem die zu übermittelnde Information für Nutz- und Mediendaten übertragen wird.

Bezogen auf eine SIP- Nachricht, insbesondere eine INVITE- Nachricht, wird mit Hilfe eines Schlüssel- Management- Protokolls die in einem Medienkanal übertragene Schlüsselinformation durch zumindest ein von den Endpunkten signiertes Zerti- fikat authentisiert und in den Nutzteil einer SIP- Nachricht wird zumindest ein Fingerprint des Zertifikats zur Authentisierung der zu übertragenden Schlüsselinformation eingefügt. In den Header einer SIP- Nachricht wird SIP-gemäß eine Datumsinformation, Zertifikatshinweisinformation und eine die Identitätsinformation des die SIP- Nachricht bildenden Endpunkts eingefügt.

Die Qualität der Ende- zu-Ende-Sicherung der Nutz- und Mediendaten hängt von der Authentisierung des Fingerprints ab. Werden SIP- Nachrichten über Netze mehrerer Carrier bzw. Netz- betreiber übertragen, kommt es vor, dass Inhalte von SIP- Nachrichten geändert werden wie beispielsweise die änderung von Transportadressen in Session Board Controllern der jeweiligen Netzbetreiber. In diesen Fällen ist die SIP- Identity Signatur wie in dem Standard RFC 4474 beschrieben nicht mehr gültig und muss erneut durch jeweiligen Netzbetreiber gebil- det werden. Hierdurch ergibt sich eine Angriffsmöglichkeit auf die Authentizität des Fingerprints in der Art, dass in den zwischengeschalteten Netzen der Netzbetreiber der Fin- gerprint des Zertifikats durch einen Fingerprint desjenigen Zertifikats ersetzt wird, das dem zwischengeschalteten Netz des Netzbetreibers zugeordnet ist.

Die der Erfindung zugrunde liegende Aufgabe besteht darin, die Sicherheit bei übertragung eines von einem Zertifikat abgeleiteten Fingerprints auch über mehrere Netze unterschied- licher Netzbetreiber zu gewährleisten. Die Aufgabe wird ausgehend von den Merkmalen des Patentanspruchs 1 gelöst .

Der wesentliche Aspekt des erfindungsgemäßen Verfahrens ist darin zu sehen, dass mit Hilfe eines Schlüssel-Management- Protokolls die übertragene Schlüsselinformation durch von den

Endpunkten signierte Zertifikate authentisiert werden und in den Nutzteil einer SIP - Nachricht zumindest ein Fingerprint eines von einem Endpunkt signierten Zertifikats eingefügt ist. In den Header einer SIP- Nachricht ist eine Datumsinfor- mation, Zertifikatshinweisinformation und eine die Identitätsinformation des die SIP- Nachricht bildenden Endpunkts eingefügt. Erfindungsgemäß wird die Identitätsinformation in einen Bereich des Headers oder des Nutzteils kopiert und eine Signatur über den Fingerprint, die Datumsinformation und die kopierte Identitätsinformation gebildet und in einen weiteren

Bereich des Headers einer SIP- Nachricht eingefügt. Optional kann die Zertifikationshinweisinformation in die Bildung der Signatur einbezogen werden.

Ein wesentlicher Vorteil des erfindungsgemäßen Verfahrens besteht darin, dass bei einer Kommunikationsbeziehung zwischen zwei Endpunkten bzw. Endgeräten, die über mehrere Netze mehrerer Netzbetreiber geführt ist, auch bei einer änderung der Identitätssignatur durch die Netze unterschiedlicher Netzbetreiber die zusätzliche erfindungsgemäß gebildete und eingefügte Signatur unbeeinflusst bleibt und damit eine eindeutige Authentisierung der übermittelten Schlüsselinformation erreicht wird. Diese eindeutige Authentisierung der Schlüs- selinformation wird auch dann noch erreicht, wenn die Identitätsinformation in den Netzen der unterschiedlichen Betreiber geändert wird. Durch das erfindungsgemäße Verfahren können folglich Angriffe auf die Sicherheit der Authentisierung in den Netzen der unterschiedlichen Netzbetreiber vermieden wer- den.

Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens wird zumindest eine weitere im Zusammenhang mit der Authentisierung stehende Information in der SIP- Nach- rieht in die Signaturbildung einbezogen. Hierdurch können diejenigen Informationen, die die Sicherheit noch weiter erhöhen, einbezogen werden.

Nach einer Weiterbildung des erfindungsgemäßen Verfahrens ist als Schlüssel-Management-Protokoll das DTLS- SRTP- Verfahren (Data Transport Layer Security - Secure Transport Protocol) vorgesehen. Dieses Protokoll ist besonders für die Sicherung von zu übertragenden Multimedia- Verkehr gemäß dem SIP- Protokoll vorgesehen.

Gemäß einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist die Identitätsinformation, die Datumsinformation und die Zertifikatshinweisinformation in vorgegebene Felder des Headers der SIP- Nachricht und der Fingerprint in ein vorgegebenes Feld des Nutzteils der SIP-

Nachricht eingefügt und für die Bildung der Signatur wird zumindest der die Informationen enthaltende Teil der vorgegebenen Felder einbezogen. Dies bedeutet, dass in den vorgegebe-

nen Feldern die Information das jeweilige Feld nicht vollständig belegen muss und in die Signaturbildung entweder nur die in den Feldern enthaltene Information oder auch das vollständige Feld einbezogen wird.

Weitere vorteilhafte Weiterbildungen des erfindungsgemäßen Verfahrens und eine Ausgestaltung einer erfindungsgemäßen A- nalyseeinheit sind weiteren Ansprüchen zu entnehmen.

Im Folgenden wird das erfindungsgemäße Verfahren anhand von zwei zeichnerischen Darstellungen näher erläutert. Dabei zeigen

Figur 1 ein Ablaufdiagramm zur Erläuterung der erfindungs- gemäßen Verfahrens und

Figur 2 den Aufbau der in Figur 1 angedeuteten SIP- Nachrichten.

Figur 1 zeigt in einem Ablaufdiagramm den Aufbau einer Kommu- nikationsbeziehung zwischen einem Endpunkt A und einem Endpunkt B - in Figur 1 durch die Bezeichnungen A und B angedeutet. Nach den beiden Endpunkten A, B ist jeweils in Richtung Netzwerk IPNET ein Proxy A bzw. Proxy B angeordnet, der im Ausführungsbeispiel durch einen SIP- Proxy realisiert ist - in Figur 1 durch die Bezeichnung Proxy A(SIP) , Proxy B (SIP) angedeutet. Zwischen Proxy A und Proxy B sei für das Ausführungsbeispiel zumindest ein Netzwerk IPNET eines Netzbetreibers angenommen, beispielsweise das Internet und ein Betreiber des Internets. Die Endpunkte A, B sowie die Proxy A und Proxy B und das Netzwerk INPET sind in dem Ablaufdiagramm jeweils durch eine vertikale, gestrichelte Linie repräsentiert.

Ein SIP Proxy ist meist in einem SIP Proxy Server realisiert und ist für die Umsetzung eines Namens in eine IP- Adresse in einer SIP- Domain und umgekehrt zuständig. In einem SIP Proxy Server werden zusätzlich Dienste, Leistungsmerkmale und die Skalierbarkeit zu SIP- Netzwerken realisiert. Eine SIP- Domain ist durch die Domain- Angabe in einer URI (Universal Re-

source Identifier) angegeben, wobei der SIP Proxy für diese Domain - im Ausführungsbeispiel Domäne A und B - die Adressumsetzung übernimmt.

Ein Endpunkt A, B bzw. ein SIP- Endpunkt kann durch ein SIP- Endgerät oder durch ein Gateway oder durch einen Leistungs- merkmal- Server, beispielsweise einen Konferenzserver, realisiert sein, wobei als VoIP- Protokoll das SIP- Protokoll SIP vorgesehen ist.

Für das Ausführungsbeispiel sei angenommen, dass im Rahmen des SIP Protokolls SIP für die übertragung der Voice oder Multimediainformation als gesichertes RTP- Protokoll das SRTP- Protokoll SRTP eingesetzt wird, bei dem die Schlüssel bzw. Schlüsselinformation mit einem Key Management Protocols ausgetauscht werden. Weiterhin sei angenommen, dass als Key Management Protocol das DTLS- SRTP- Protokoll (Data Transport Layer Security - Secure Transport Protocol) vorgesehen ist. Das DTLS- Protokoll basiert auf dem TLS- Protokoll (Transport Layer Security) und stellt ein Verschlüsselungsprotokoll für Datenübertragungen über Netzwerke mit Internetprotokoll dar. Das DTLS- SRTP- Protokoll ist innerhalb des Nutzdatenkanals bzw. Mediadatenkanals realisiert, wobei der Schlüsselaustausch durch Zertifikate und den assoziierten privaten Schlüsseln authentisiert wird. Die Zertifikate werden nicht von einer vertrauenswürdigen PKI- Instanz (Public Key Infrastructure) sondern durch die jeweiligen Endpunkte A, B bzw. Endeinrichtung selbst signiert. Um die Authentisierung mit der Einrichtung zu sichern, mit der eine Kommunikations- beziehung vorgesehen ist, wird eine oder mehrere in der Fachwelt als Fingerprint fp bezeichnete Sicherungsinformationen gebildet und innerhalb der SIP- Message gesendet. Der Fingerprint fp ist jeweils auf einen öffentlichen Schlüssel oder ein Zertifikat bezogen und stellt üblicherweise den Hashwert einer auf den öffentlichen Schlüssel bzw. Zertifikat angewendeten Hashfunktion dar. Der Hashwert ist eine gegenüber dem öffentlichen Schlüssel kürzere Zahlenfolge, wobei der Hashwert den öffentlichen Schlüssel jedoch eindeutig identifi-

ziert. Der Fingerprint fp wird innerhalb der SIP- Nachricht durch eine Signatur - beispielsweise nach dem RFC Standard 4474 gesichert, die allgemein für die Sicherung des Kopfteils bzw. Headers und des SIP- Bodys vorgesehen ist. Die Signatur stellt sicher, dass die Schlüsselinformation von dem ursprünglichen Signaturgeber stammt.

Bei einem Aufbau einer Kommunikationsbeziehung gemäß dem SIP- Protokoll SIP mit einem SIP Proxy wird eine INVITE- Nachricht INVITE (1) von Endpunkt A an den Proxy A übermittelt, der der SIP- Domain A zugeordnet ist. In Figur 2 ist der Aufbau einer zwischen Proxy A und dem Netzwerk IPNET übermittelten INVITE- Nachricht INVITE (2) dargestellt, wobei im Weiteren nur die für die Erläuterung des erfindungsgemäßen Verfahrens erfor- derlichen Teile bzw. Felder der INVITE- Nachricht INVITE einschließlich der enthaltenen Information beschrieben werden.

Eine INVITE- Nachricht INVITE (1) weist einen SIP- Header SIPH und einen Body bzw. Nutzteil B auf, wobei im Nutzteil B vom Endpunkt A in einem SDP- Feld (Session Description Proto- col) eingefügte ein oder mehrere von öffentlichen Schlüsseln bzw. Zertifikaten des Endpunkts abgeleitete Fingerprints fp übertragen werden - in Figur 2 durch die Bezeichnung fp (si) angedeutet -, die zur Authentisierung der Schlüsselinformati- on si verwendet wurden. In den SDP- Felder werden generell die Parameter einer Kommunikationsbeziehung übertragen. Im SIP- Header SIPH sind eine Identitätsinformation idi und eine Datumsinformation di eingetragen - in Figur 2 durch die Bezeichnung idi, di angedeutet, wobei die Identitätsinformation idi in ein spezielles Feld - in der Fachwelt als From Header bezeichnet - und die Datumsinformation di in ein Datumsfeld eingetragen wird. Der Fingerprint fp repräsentiert hierbei das Zertifikat des Endpunkts A, das zur Authentisierung der Schlüsselinformation si verwendet wurde.

Durch den Proxy A wird die im SIP- Header SIPH der SIP- Nachricht INVITE (2) enthaltene Identitätsinformation idi kopiert und die Kopie idi' in ein zusätzliches Feld bzw. Element des

SIP- Headers SIPH eingefügt. Dieses Kopieren und Einfügen der Identitätinformation idi kann alternativ auch durch den Endpunkt A erfolgen. Zusätzlich wird ausschließlich durch den Proxy A in ein Zertifikatsfeld eine Hinweisinformation hz für ein Domänenzertifikat eingetragen, wobei die Hinweisinformation hz eine Netzadresse - insbesondere Internetadresse - angibt, in der das Zertifikat der Domäne A gespeichert ist bzw. abrufbar ist. Ein Domänenzertifikat repräsentiert eine signierte öffentliche Schlüsselinformation, mit dem eine über- tragene, mit einer privaten Schlüsselinformation vorgenommene Signatur verifiziert wird.

Um eine eindeutige Authentisierung der Schlüsselinformation si bei einem Nutzer bzw. beim Proxy B oder Endpunkt B zu er- reichen, wird erfindungsgemäß eine Signatur S über die Datumsinformation di, die kopierte Identitätsinformation idi' , den im Nutzteil B enthaltenen Fingerprint fp und optional über die Hinweisinformation hz gebildet und in ein zusätzliches Feld des SIP- Headers SIPH eingefügt - in der Figur 2 durch die Angaben di, idi' , fp, opt (hz) > S angedeutet. Die Signatur S wir mit Hilfe einer von der jeweiligen Proxy A, B verwalteten Signaturinformation bzw. einer privaten Schlüsselinformation und einem aus der Datumsinformation di, der kopierten Identitätsinformation idi' , der Hinweisinformation hz und den im Nutzteil B enthaltenen Fingerprint fp abgeleiteten

Hashwert berechnet. Die so gebildete INVITE- Nachricht INVITE (2) kann anschließend, wie in Figur 1 dargestellt, über ein oder mehrere Netzwerke IPNET mit IP- Protokoll zu dem Proxy B und dem Endpunkt B übermittelt werden - in Figur 1 durch INVITE (3), INVITE (4) angedeutet.

Beispielhaft ist ein Auszug aus einem Header SIPH einer INVITE- Nachricht INVITE gemäß dem SIP- Protokoll angegeben, die vom Proxy A über das Netzwerk IPNET and den Endpunkt B übertragen wird:

INVITE sip: b@domainb.com SIP/2.0 1)

Via: SIP/2.0/TLS pc. domaina. com;branch= zEz67in32Wer4i 2)

To: B <sip:b@domainb. com> 3)

From: A <sip:a@domaina.com>; tag=1234567890 4)

CaIl-ID: 12345678901234 5)

CSeq: 987654 INVITE 6) Max-Forwards: 50 7)

Date: Thu, 03 Jan 2008 15:07:00 GMT 8)

Contact: <sip:a@pc.domaina.com> 9)

Content-Type: application/sdp

10) Content -Length: 123

11) DomainCert-Info: <https://domaina.com/proxya.cer>; 12) alg=rsa-shal

Original-Identity-Info: A <sip:a@domaina. com> 13)

Signature : " j j sRdiOPQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz 14)

6uEo3svJsSH49thβqcefQBbHCO0VMZr2k+t6VmCvPonWJM GvQTBDqghoWeLxJfzB2alpxAr3VgrB0SsjcdVcunyaZucy RlB YQTLqWzJ+KVhPKbfU/pryhVn9Jcqe="

Erläuterung :

1) Nachrichtentyp, Zieladresse (URI) , SIP- Version

2) IP-Adresse, Portnummer und das Transportprotokoll für die Rückantwort der Nachricht

3) Displayname von B und dessen URI

4) Displayname von A und dessen URI (Identifikationsinfor- mation idi)

5) Zufallszeichenkette als eindeutige Nummer für eine Kommunikationsbeziehung

6) Sequenznummer (bezogen auf Nachrichtentyp)

7) maximale Anzahl Proxy Server (wird durch jeden durchlau- fenen Proxy dekrementiert)

8) Datumsinformation di

9) SIP-Adresse des Empfängers für eine direkte Kommunikation

10) Datentyp im Nutzteil B (beispielsweise gemäß SDP- Proto- koll)

11) Länge des Nutzteils

12) Hinweisinformation hz für Domänenzertifikat

13) kopierte Identifikationsinformation idi'

14) Signatur S

Weiterhin ist beispielhaft ein Auszug aus einem SIP- Nutzteil B angegeben :

v=0

15)

O=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 15) s=example2

15) C=IN IP4 192.0.2.1

15) t=0 0

16) m=audio 54113 RTP/SAVP 0

17) a=fingerprint : SHA-I 18)

4A:AD:B9:Bl:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C: AB m=video 54115 RTP/SAVP 0 a=fingerprint : SHA- 1

4A:AD:B9:B1:3F:82:18:3B:54 : 02: 12: DF: 3E : 5D : 49 : 6B : 19 : E5 : 7C: AB

Erläuterung :

15) RTP (Real Time Protocol) - Session - Parameter

16) Zeitbeschreibung 17) Medientyp (beispielsweise Audio) 18) Fingerprint

Hierbei können für die INVITE- Nachricht INVITE durch die die INVITE- Nachricht INVITE übertragenden Netzwerke netzspezifi- sehe Signaturen berechnet und in die INVITE- Nachricht INVITE eingefügt werden, ohne dass die in den SIP- Header SIPH eingefügte Signatur S verändert bzw. beeinflusst wird. Dies bedeutet, dass im Proxy B durch die überprüfung der im weiteren

zusätzlichen Feld enthaltenen Signatur S die in einem Medienkanal übermittelte Schlüsselinformation si eindeutig authen- tisiert werden kann, d.h. der Fingerprint fp ist eindeutig eingefügt durch den Proxy A bzw. die Domäne A. Endpunkt B kann anschließend aus der empfangenen INVITE- Nachricht

INVITE (4) die Identitätsinformation idi und die kopierte I- dentitätsinformation idi' lesen und einem Benutzer von Endpunkt B anzeigen.

Gemäß dem SIP- Protokoll SIP wird im Endpunkt A eine Antwortnachricht 200OK gebildet und über den Proxy B, das Netzwerk IPNET und den Proxy A an den Endpunkt A übermittelt. In die Antwortnachricht 200OK ist das Bilden und Einfügen der Signatur S nicht mehr erforderlich, da der Endpunkt A einschließ- lieh der Schlüsselinformation si durch die eindeutige Identitätsinformation idi und kopierte Identitätsinformation idi' identifiziert bzw. authentisiert ist.

Da mit Hilfe des erfindungsgemäßen Verfahren erfolgt die Au- thentisierung für die Schlüsselinformation des Endpunkts B im Endpunkt A bzw. Proxy A in gleicher Weise wie vorhergehend beschrieben, jedoch ist anstelle eine INVITE- Nachricht INVITE eine UPDATE- Nachricht vorgesehen - in Figur 1 nicht dargestellt.