-
Der
Anmeldungsgegenstand betrifft ein Verfahren zur SPIT-Abwehr.
-
Ähnlich dem
Spam-Problem bei E-Mail ist zu erwarten, dass in zukünftigen
offeneren SIP-basierten IP-Telefonnetzen SPIT-Anrufe (spam over ip telephony) ein
erhebliches Störungspotenzial
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 Endgeräte
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 ähnlichen
Adressverzeichnis – vermutliche
Mitglieder der Positivliste des Teilnehmers B identifizieren und
versuchen, durch Fälschen
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 (BZBUA, 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 Rückruf die Erreichbarkeit des Absenders
unter der von ihm angegebenen Adresse überprüft werden kann. Dieses Verfahren
soll keine Unterstützung
durch Netz-Elemente benötigen,
lässt 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
Rückruf-Validierung der Adresse
von A durchführen,
kann dies zu einer Überlastung
der Signalisierungseinrichtungen von A führen. Abwehrmaßnahmen
dafür müssten im
Netz stattfinden, weil nur dort die gleichzeitige Ansammlung von
Rückruf-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 R1 und einem Rechner R2 der public
key von R2 an R1 ü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 R1 mit demselben Schlüssel authentifizieren
kann wie beim ersten Kontakt. Zur Sicherstellung der Identifikation
für den Erstkontakt
ist bei ssh vorgesehen, dass R1 ü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 Schutzes
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 zusätzlich
gefordert, dass bei kurz aufeinander abgesetzten Verbindungsaufbauwünschen jeweils
ein neuer Zeitstempel TS verwendet wird, selbst wenn dies aufgrund
des vorgegebenen Intervalls (der Toleranz) von B nicht nötig wäre. Dadurch
werden auch in kurzen Zeitintervallen replay attacks verhindert.
-
Der
Anmeldungsgegenstand wird im Folgenden als Ausführungsbeispiel in einem zum
Verständnis
erforderlichen Umfang anhand von Figuren näher erläutert. Dabei zeigen:
-
1 zwei
Netze N1 und N2 mit SIP Proxies SP1 und SP2 und Session Border Controller
SBC, Signalisier- und Mediendatenverkehr zwischen Teilnehmerendgeräten A und
B,
-
2 eine
Teilnehmerendeinrichtung B mit Positivliste WL und darin enthaltenen
Einträgen
für Teilnehmer
ID, public key PK, Zeitstempel TS (optional) und Zustandsinformation
Z (optional),
-
3 den
Ablauf des Protokolls zwischen A (Alice) und B (Bob),
-
4 Zustände des
Schlüssels
A auf der WL von B, Verbindungsaufbau jeweils nur symbolisch dargestellt,
-
5 Zustands-Übergangsdiagramm
für den
public key von A auf der Positivliste (WL) von B. WS = „willingness
to store", d.h.
die Bereitschaft, A auf die WL aufzunehmen. Zustände: 0 = unknown, 1 = VALIDATED,
2 = VALIDATED-ID (Referenz zu den folgenden Abbildungen),
-
6 Verarbeitung
der Schlüssel
bei ankommenden und abgehenden Anrufen,
-
7 Subroutine
After Key Call Processing (x) zu 6,
-
8 Subroutine
Process new public key zu 7,
-
9 Subroutine
Process known public key zu 6,
-
10 Subroutine
Process known public key in VALIDATED state zu 9 und
-
11 Subroutine
Process known public key in VALIDATED_ID state zu 9.
-
In 1 ist
ein Szenario dargestellt, in dem zwei Endgeräte A und B über zwei Kommunikationsnetze
N1 und N2 kommunizieren. In N1 ist SP1 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 zusätzlicher 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 ursprüngliche
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 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.
-
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
= "algorithm1, algorithm2,
..."
- In an reINVITE request upon a 401 Unauthorized response:
p3k2006-Authentication:
Challenge
= "*the receiver's challenge*",
Signature
= "*the sender's signature*",
Public-Key
= "*the sender's public key*",
Signing-Algorithm
= "*the applied
signing algorithm*"
-
Ausführungsbeispiele
-
- – Endgerät, 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 unterstützt und
weitergibt