Beschreibung

SPIT-ABWEHR DURCH MIT KRYPTOGRAFISCHEN SCHLüSSELN ABGESICHERTE POSITIVLISTEN

Der Anmeldungsgegenstand betrifft ein Verfahren zur SPIT- Abwehr .

Ahnlich dem Spam-Problem bei E-Mail ist zu erwarten, dass in zukunftigen offeneren SIP-basierten IP-Telefonnetzen SPIT- Anrufe (spam over ip telephony) ein erhebliches

Storungspotenzial für die Telefonteilnehmer bergen. Dagegen werden unter anderem Positivlisten (white lists) eingesetzt - Listen bekannter Teilnehmer, von denen Gespräche bzw. andere Rufe (Multimedia-Verbindungen, instant messages, Multimedia- Nachrichten, Mails) immer angenommen werden sollen. Rufe von Teilnehmern, die nicht Mitglieder dieser Positivliste eines gerufenen Teilnehmers sind, werden abgewiesen oder an eine Ansageeinrichtung oder Sprachspeichereinrichtung verwiesen. Bei der der unter dem Produktname Surpass hiQ vertriebenen Serie der Anmelderin ist dies als „selective call acceptance (SCA)" implementiert, aber auch Endgerate können solche Einrichtungen enthalten, z.B. indem sie Rufe von Teilnehmern auf der Positivliste mit einem besonderen Klingelton signalisieren .

Will ein Spitter M nun einen Teilnehmer B anrufen, der sich durch eine Positivliste abschirmt, so kann er - z.B. durch Nachschlagen in einem Telefonbuch oder einem ahnlichen Adressverzeichnis - vermutliche Mitglieder der Positivliste des Teilnehmers B identifizieren und versuchen, durch

Falschen seiner eigenen Absenderadresse beim Rufaufbau (SIP Invite Nachricht) den Teilnehmer B zu erreichen, obwohl dieser dies nicht wünscht. Gesucht ist hier ein Verfahren, das es dem gerufenen Teilnehmer B erlaubt, einen rufenden Teilnehmer A eindeutig zu identifizieren, auch wenn zwischen den beiden Teilnehmern Netzbetreiber liegen, die u.U. nicht vertrauenswürdig sind, so dass der gerufene Teilnehmer B der

im Rufaufbaupaket als Absenderadresse angegebenen Teilnehmeridentifikation nicht trauen kann. Eine entsprechende Verifikation muss geschehen, bevor das Endgerät von B den eingehenden Ruf beispielsweise durch Klingeln signalisiert und damit den Teilnehmer B stört. Somit steht im Protokoll SIP für eine Entscheidung nur diejenige Information zur Verfügung, die in der SIP INVITE Nachricht (dem ersten Paket des Rufaufbaus) enthalten ist.

Positivlisten (white list, selective call acceptance SCA) sind heute als Produkt verfügbar.

In J. Peterson, C. Jennings, „Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" IETF Draft draft-ietf-sip-identity-06, Oct . 2005 wird ein Verfahren zur Header-Signierung beschrieben, mit dem der

Empfänger einer Rufaufbau-Nachricht überprüfen kann, ob eine SIP INVITE Nachricht in den wesentlichen Feldern unverfälscht übertragen wurde. Dieses Verfahren benötigt eine Infrastruktur von Zertifizierungsinstanzen, die den Absender- IDs zugeordnet sind. Außerdem muss bei jeder empfangenen

INVITE-Nachricht der public key der entsprechenden Instanz geholt werden, damit die Header-Felder überprüft werden können. Netzelemente wie Session Border Controller (SBC) oder back to back user agents (B2BUA, z.B. der unter dem Produktname Surpass hiQ vertriebene Einrichtung der

Anmelderin) zerstören jedoch einen Teil dieser Header-Felder bzw. schreiben sie neu, so dass das Verfahren entsprechend der Beschreibung in einem öffentlichen Netz nach Stand der Technik nicht funktioniert. Außerdem muss dabei dem Betreiber des Ursprungs-Netzes vertraut werden, was nur eine

Absicherung gegen Angriffe aus anderen Ursprungsnetzen darstellt .

In der Patentanmeldung DE-10 2005 046 965.5 „Verfahren und Anordnung zur Verifikation einer im Zuge einer Verbindungsanfrage zum Zweck des Aufbaus einer Kommunikationsverbindung übermittelten Absenderadresse in

einem IP-Kommunikationsnetzwerk" der Anmelderin vom 30. 09. 2005 ist bereits ein Verfahren vorgeschlagen worden, mit dem ohne Beteiligung der Netz-Elemente durch einen automatischen Ruckruf die Erreichbarkeit des Absenders unter der von ihm angegebenen Adresse überprüft werden kann. Dieses Verfahren soll keine Unterstützung durch Netz-Elemente benotigen, lasst sich aber potenziell für distributed denial of Service (DDoS) Angriffe missbrauchen: Wenn ein Angreifer M unter Angabe der Absenderadresse A Rufaufbau-Nachrichten an sehr viele Teilnehmer B_i sendet und alle diese Teilnehmer eine Ruckruf- Validierung der Adresse von A durchfuhren, kann dies zu einer überlastung der Signalisierungseinrichtungen von A fuhren. Abwehrmaßnahmen dafür mussten im Netz stattfinden, weil nur dort die gleichzeitige Ansammlung von Ruckruf-Nachrichten erkannt und gebremst werden kann. Daher verliert dieser Ansatz nach dem momentanen Stand der Erkenntnisse seine Unabhängigkeit von Netzelementen und Betreibern, sobald DDoS- Abwehrmechanismen eingebaut werden.

Das ssh-Protokoll (secure shell) setzt ein völlig verteiltes public-Key-Verfahren ohne zentralisierte certificate Stores zur Identifikation eines Partnerrechners in einer Verbindung ein. Dabei wird bei einem ersten Kontakt zwischen einem Rechner Rl und einem Rechner R2 der public key von R2 an Rl übermittelt und bei diesem in einer „known hosts" Liste abgespeichert. Bei jedem weiteren Kontakt wird dann der Schlüssel überprüft und die Verbindung wird nur aufgebaut, wenn sich R2 gegenüber Rl mit demselben Schlüssel authentifizieren kann wie beim ersten Kontakt. Zur Sicherstellung der Identifikation für den Erstkontakt ist bei ssh vorgesehen, dass Rl über einen separaten Kanal einen „fingerprint" von R2 erhalten hat, den er überprüft.

Dem Anmeldungsgegenstand liegt das Problem zugrunde, ein Verfahren anzugeben, das ein Unterlaufen des auf einer White List basierenden Schutz' vor unerwünschten Anrufen mittels gefälschter Absenderadressen verhindert.

Das Problem wird durch die Merkmale des Anspruchs 1 gelöst.

Da die Positivlisten-Einträge durch kryptografische Schlüssel zwischen Endteilnehmern abgesichert sind, wird das Schlupfloch der auf vermutete Mitglieder einer Positivliste gefälschten Absenderadressen geschlossen. Gleichzeitig sind Vorkehrungen getroffen, um replay-Angriffe auszuschließen und um Man-in-the-middle-Angriffe deutlich zu erschweren. Durch die Forderung nach Verwendung des Zeitstempels in KT bei jedem Anruf wird sichergestellt, dass Dritte einen im Netz beobachteten KT nicht einfach wieder verwenden können, um sich Zugang zu Teilnehmer B zu verschaffen (replay protection) .

Vorteilhafte Weiterbildungen des Anmeldungsgegenstandes sind in den Unteransprüchen angegeben.

In einer Weiterbildung des Anmeldungsgegenstandes sendet ein Endsystem eines Teilnehmers, z. B. B, der angerufen wird, in einer Antwortnachricht an das Endsystem des anrufenden

Teilnehmers, z. B. A, seinen public key. So kann die WL auch bei ausgehenden Rufen gepflegt werden.

Wenn Teilnehmer B selbst Teilnehmer A anruft, kann die Zustandsinformation abermals geändert werden. Sinnvoll ist dabei die Erhöhung der Vertrauenswürdigkeit, weil es wahrscheinlicher ist, dass A eine falsche Identität in einer Signalisierungsnachricht vorspiegeln kann, als dass das Routing im Telefonnetz darüber hinaus einen Ruf zum falschen Teilnehmer führt.

Trifft ein Rufaufbauwunsch mit einem public key bei einem Endsystem ein, bei dem zu dieser Identität ein anderer PK gespeichert ist, so wird dies als Fälschung der ID erkannt, und der Ruf wird abgelehnt, oder er wird dem Verfahren für Erstkontakte zugeleitet.

Es wird zusatzlich gefordert, dass bei kurz aufeinander abgesetzten Verbindungsaufbauwunschen jeweils ein neuer Zeitstempel TS verwendet wird, selbst wenn dies aufgrund des vorgegebenen Intervalls (der Toleranz) von B nicht notig wäre. Dadurch werden auch in kurzen Zeitintervallen replay attacks verhindert.

Der Anmeldungsgegenstand wird im Folgenden als Ausfuhrungsbeispiel in einem zum Verständnis erforderlichen Umfang anhand von Figuren naher erläutert. Dabei zeigen:

Fig 1 zwei Netze Nl und N2 mit SIP Proxies SPl und SP2 und Session Border Controller SBC, Signalisier- und Mediendatenverkehr zwischen Teilnehmerendgeraten A und B, Fig 2 eine Teilnehmerendeinrichtung B mit Positivliste WL und darin enthaltenen Eintragen für Teilnehmer ID, public key PK, Zeitstempel TS (optional) und Zustandsinformation Z (optional) ,

Fig 3 den Ablauf des Protokolls zwischen A (Alice) und B (Bob),

Fig 4 Zustande des Schlüssels A auf der WL von B,

Verbindungsaufbau jeweils nur symbolisch dargestellt, Fig 5 Zustands-Ubergangsdiagramm für den public key von A auf der Positivliste (WL) von B. WS = „willingness to störe", d.h. die Bereitschaft, A auf die WL aufzunehmen. Zustande: 0 = unknown, 1 = VALIDATED, 2 = VALIDATED ID (Referenz zu den folgenden Abbildungen) , Fig 6 Verarbeitung der Schlüssel bei ankommenden und abgehenden Anrufen, Fig 7 Subroutine After Key CaIl Processing (x) zu Fig 6, Fig 8 Subroutine Process new public key zu Fig 7, Fig 9 Subroutine Process known public key zu Fig 6, Fig 10 Subroutine Process known public key in VALIDATED State zu Fig 9 und Fig 11 Subroutine Process known public key in VALIDATED_ID State zu Fig 9.

In Figur 1 ist ein Szenario dargestellt, in dem zwei Endgeräte A und B über zwei Kommunikationsnetze Nl und N2 kommunizieren. In Nl ist SPl und in N2 SP2 als SIP Proxy / SIP Server eingesetzt, und dazwischen filtert ein Session Border Controller SBC den Signalisierungsverkehr .

Ein Teilnehmer A, der einen Ruf zu Teilnehmer B aufbauen möchte, sendet in der initialen Rufaufbaunachricht (bei SIP: INVITE) in einem Feld seinen öffentlichen Schlüssel PK A und in einem (möglicherweise anderen) Feld ein mit seinem dazugehörigen privaten Schlüssel verschlüsselten oder signierten Kryptotext KT. Dieser Kryptotext KT enthält einen Zeitstempel TS.

Beim ersten Anruf eines bis dahin unbekannten Teilnehmers wird - wie bei jedem auf Positivlisten basierenden System - der Anruf zunächst nicht direkt zum gerufenen Teilnehmer signalisiert, sondern einer gesonderten Behandlung zugeleitet. Dabei kann der Ruf beispielsweise auf einen Anrufbeantworter oder ein Ansagesystem geleitet werden, oder er kann dem gerufenen Teilnehmer gesondert signalisiert werden (einmaliges Klingeln, gesonderter Klingelton) . Zusätzlich speichert das Endgerät B bei diesem ersten Anruf von A den in der Rufaufbaunachricht übermittelten öffentlichen Schlüssel PK A und den mit Hilfe von PK A aus dem KT extrahierten Zeitstempel TS_A mit einem Initialzustand. Dabei wird geprüft, ob der mit PK A aus dem KT extrahierte Zeitstempel TS innerhalb eines gewissen Intervalls zur momentanen Uhrzeit liegt. Wenn dies nicht der Fall ist, wird die Anfrage auf jeden Fall abgelehnt (bei SIP: 403 forbidden) .

Nach dem Annehmen (zB Abhören von der Voicebox) des Anrufes kann Teilnehmer B entscheiden, A auf die WL aufzunehmen. Dabei wird die Zustandsinformation des Eintrages für A entsprechend geändert. Wenn Teilnehmer B selbst Teilnehmer A

anruft, kann die Zustandsinformation abermals geändert werden. Sinnvoll ist dabei die Erhöhung der

Vertrauenswürdigkeit, weil es wahrscheinlicher ist, dass A eine falsche Identität in einer Signalisierungsnachricht vorspiegeln kann, als dass das Routing im Telefonnetz zusätzlich einen Ruf zum falschen Teilnehmer führt. Dazu sendet ein Teilnehmer seinen public key nicht nur in der initialen Rufaufbaunachricht, sondern auch, wenn er angerufen wird, in einer der Antwortnachrichten an das Endsystem des Gesprächspartners. So kann die WL auch bei ausgehenden Rufen gepflegt werden.

Trifft ein Rufaufbauwunsch mit einem public key bei einem Endgerät ein, bei dem zu dieser Identität ein anderer PK gespeichert ist, so wird dies als Fälschung der ID erkannt, und der Ruf wird abgelehnt, oder er wird dem Verfahren für Erstkontakte zugeleitet.

Durch die Forderung nach Verwendung des Zeitstempels in KT bei jedem Anruf wird sichergestellt, dass Dritte einen im Netz beobachteten KT nicht einfach wieder verwenden können, um sich Zugang zu Teilnehmer B zu verschaffen (replay protection) . Es wird zusätzlich gefordert, dass bei kurz aufeinander abgesetzten Verbindungsaufbauwünschen jeweils ein neuer Zeitstempel TS verwendet wird, selbst wenn dies aufgrund der Toleranz von B nicht nötig wäre. Dadurch werden auch in kurzen Zeitintervallen replay attacks verhindert.

Im Gegensatz zu dem bei ssh eingesetzten Verfahren ist das hier beschriebene einfacher (kein zusätzlicher Austausch von Paketen) und dadurch schneller. Die Sicherheit ist durch die Verwendung von Zeitstempeln anstelle von Challenges unwesentlich verringert, aber replay attacks sind ausgeschlossen. Im Gegensatz zu ssh findet die Authentifizierung beim Erstkontakt nicht durch einen über einen zweiten Kanal übertragenen Fingerprint des Schlüssels, sondern über den Sprachkanal (Mediendatenaustausch zwischen A und B) statt.

Optionen und Erweiterungen

Die Positivliste kann im Endgerät von Teilnehmer B oder im zugehörigen SIP Proxy / Vermittlungsknoten geführt werden. Anstelle des Führens von Zustandsinformationen in

Positivlisten können auch mehrere Positivlisten gepflegt werden, z.B. eine für temporäre Informationen, eine für WL- Einträge und eine für durch Rückruf bestätigte WL-Einträge. PK A und KT können im Falle der Verwendung von SIP zur Signalisierung in den folgenden Protokoll-Datenfeldern übertragen werden:

- ein oder mehrere zusätzliche Header-Felder

- Verstecken im SDP-Teil der Nachrichten, z.B. in einem zusätzlichen Attribut-Eintrag (a=...) Ein Endgerät kann die public-Key-Information in mehreren dieser Felder redundant versenden für den Fall, dass Systeme im Netz den einen oder anderen Eintrag löschen. Die Positivliste WL kann um einen Eintrag erweitert werden, der angibt, in welchem Feld die public-Key-Information zum jeweiligen Kommunikationspartner am besten durch das Netz übertragen werden kann.

Die Zeitstempel werden in GMT angegeben KT kann einen verschlüsselten Zeitstempel oder einen Zeitstempel in Klartext zuzüglich einer digitalen Unterschrift (Signatur) beinhalten.

KT kann zusätzlich zu Option E auch Informationen über die Identität des Absenders und/oder des Empfängers der Nachricht enthalten . Anstelle der Ablehnung bei nicht passendem Zeitstempel bzw. Schlüssel kann ein Rufaufbau auf eine Ansageeinheit oder einen Anrufbeantworter umgelenkt werden, oder der Ruf kann mit einem besonderen Klingelton („distinctive ringing") signalisiert werden. Zusätzlich zur beschriebenen Whitelist kann ein Endsystem eine herkömmliche Whitelist führen. Dies kann als eine

separate Liste oder als ein zusatzlicher Zustand in einer gemeinsamen WL ausgestaltet sein.

Falls bei einem Verbindungsaufbauwunsch der Zeitstempel nicht im Toleranzintervall des Adressaten B liegt, kann dieser ein challenge-response-Verfahren initiieren, bei dem der ursprungliche Absender A der Anfrage anstelle eines von A gewählten Zeitstempels eine von B gewählte Zeichenkette verschlüsselt oder signiert. Um im Falle von Man-in-the-middle-Angriffen zusatzliche Stabilität zu erhalten, kann das Zustands-Ubergangs-Verhalten der Schlüssel in der WL so ausgestaltet sein, dass ein Schlüssel, der schon lange bzw. bei vielen Anrufen immer wieder bestätigt wurde, eher in seinem Zustand verbleibt, wohingegen ein Schlüssel, der neu aufgenommen wurde schneller wieder geloscht und der Anrufer somit wieder auf die Prozedur für den Erstkontakt verwiesen wird.

Optionen und Erweiterungen

A. Die Positivliste kann im Endgerät von Teilnehmer B oder im zugehörigen SIP Proxy / Vermittlungsknoten geführt werden.

B. Anstelle des Führens von Zustandsinformationen in Positivlisten können auch mehrere Positivlisten gepflegt werden, z.B. eine für temporäre Informationen, eine für WL-Einträge und eine für durch Rückruf bestätigte WL-Einträge. C. PK_A und KT können im Falle der Verwendung von SIP zur Signalisierung in den folgenden Protokoll-Datenfeldern übertragen werden:

- ein oder mehrere zusätzliche Header-Felder

- Verstecken im SDP-Teil der Nachrichten, z.B. in einem zusätzlichen Attribut-Eintrag (a=...) D. Ein Endgerät kann die public-Key-Information in mehreren dieser Felder redundant versenden für den Fall, dass Systeme im Netz den einen oder anderen Eintrag löschen.

E. Die Positivliste WL kann um einen Eintrag erweitert werden, der angibt, in welchem Feld die public-Key-Information zum jeweiligen Kommunikationspartner am besten durch das Netz übertragen werden kann.

F. Die Zeitstempel werden in GMT angegeben

G. KT kann einen verschlüsselten Zeitstempel oder einen Zeitstempel in Klartext zuzüglich einer digitalen Unterschrift (Signatur) beinhalten. H. KT kann zusätzlich zu Option E auch Informationen über die Identität des

Absenders und/oder des Empfängers der Nachricht enthalten. I. Anstelle der Ablehnung bei nicht passendem Zeitstempel bzw. Schlüssel kann ein Rufaufbau auf eine Ansageeinheit oder einen Anrufbeantworter

umgelenkt werden, oder der Ruf kann mit einem besonderen Klingelton („distinctive ringing") signalisiert werden.

J. Zusätzlich zur beschriebenen Whitelist kann ein Endsystem eine herkömmliche Whitelist führen. Dies kann als eine separate Liste oder als ein zusätzlicher Zustand in einer gemeinsamen WL ausgestaltet sein.

K. Falls bei einem Verbindungsaufbauwunsch der Zeitstempel nicht im Toleranzintervall des Adressaten B liegt, kann dieser ein challenge- response-Verfahren initiieren, bei dem der ursprüngliche Absender A der Anfrage anstelle eines von A gewählten Zeitstempels eine von B gewählte Zeichenkette verschlüsselt oder signiert.

L. Um im Falle von Man-in-the-middle-Angriffen zusätzliche Stabilität zu erhalten, kann das Zustands-übergangs-Verhalten der Schlüssel in der WL so ausgestaltet sein, dass ein Schlüssel, der schon lange bzw. bei vielen Anrufen immer wieder bestätigt wurde, eher in seinem Zustand verbleibt, wohingegen ein Schlüssel, der neu aufgenommen wurde schneller wieder gelöscht und der Anrufer somit wieder auf die Prozedur für den Erstkontakt verwiesen wird.

Zu Option C: Header-Felder:

In an INVITE request:

p3k2006-Authentication:

Timestamp = "*the sender's UTC timestamp*",

Signature = "*the sender' s signature*",

Public-Key = "*the sender' s public key*", Signing-Algorithm = "*the applied signing algorithm*"

In a 200 OK response (in case the sender was successfully authenticated) : p3k2006-PubKey : *the receiver' s public key*

In a 401 Unauthorized (in case the sender was not successfully authenticated) :

p3k2006-Challenge:

Challenge = "*the receiver' s challenge*",

List-Signing-Algorithms = "algorithml, algorithm2, ..."

In an reINVITE request upon a 401 Unauthorized response:

p3k2006-Authentication:

Challenge ^r the receiver' s challenge*",

Signature ^r the sender' s signature*",

Public-Key ^r the sender' s public key*",

Signing-Algorithm ^r the applied signing algorithm*"

Ausfuhrungsbeispiele

- Endgerat, das Positivlisten verwaltet (Festnetz- oder Mobiltelefon, Anrufbeantworter, soft client)

- System im Netz, das Positivlisten (white lists) für Teilnehmer verwaltet

- Softswitch, der Positivlisten verwaltet

- Softswitch oder Session Border Controller SBC, der Positivlisten unterstutzt und weitergibt

Mögliche Patentansprüche

— client mit pub/private key Paar

— Mitsenden public key in Rufaufbaunachricht

— Mitsenden public key in Antwortnachricht

— Mitsenden Zeitstempel, in Rufaufbau- und/oder Antwortnachricht, verschlüsselt oder signiert

— überprüfung public key auf übereinstimmung bei Empfang eines Rufaufbauwunsches

— Ablehnung des Rufaufbauwunsches oder Ruckfall auf Initialkontakt-Verhalten, wenn public key nicht mit dem gespeicherten übereinstimmt

— Ablehnung des Rufaufbauwunsches oder Rückfall auf Initialkontakt-Verhalten oder Rückfall auf challenge- response-Prozedur, wenn der Zeitstempel nicht zur momentanen Uhrzeit passt oder schon einmal verwendet wurde

- Zustandsverwaltung im Endgerät, wobei ein bei einem ausgehenden Anruf empfangener public key vertrauenswürdiger eingestuft wird als ein bei einem eingehenden Anruf empfangener. - Teilnehmer kann auswählen, ob er den Gesprächspartner auf die WL aufnehmen will