WO2007125025A1

WO2007125025A1 - Spit defence by positive lists protected by cryptographic keys

Info

Publication number: WO2007125025A1
Application number: PCT/EP2007/053656
Authority: WO
Inventors: Joachim Charzinski; Maurice Uhlmann
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg
Priority date: 2006-04-27
Filing date: 2007-04-13
Publication date: 2007-11-08
Also published as: EP2014075A1; DE102006020244B3

Abstract

The invention relates to a method for SPIT (spam over ip telephony) – defence as a consequence of which an A subscriber who wishes to set up a call to a B subscriber sends his public key in the initial call setting-up message and a crypto text KT, which is signed with his associated private key, and contains a time stamp TS, with a request in the terminal of the B subscriber being checked to determined whether the extracted time stamp TS is within a predetermined interval of the current time and, if this is not the case, the request is rejected. Since the positive-list entries are protected by cryptographic keys between end subscribers, the slip hole of the sender addresses which have been corrupted with supposed members of a positive list is closed. The use of the time stamp in the KT ensures for each call that third parties cannot simply use a KT observed in the network again in order to gain access to the subscriber B (replay protection).

Description

description

SPIT DEFENSE THROUGH CRYPTOGRAPHIC KEYS SECURED POSITIVE LISTS

The subject of the application relates to a method for SPIT defense.

Similar to the spam problem in e-mail, it is to be expected that in future opener SIP-based IP telephone networks, spam over ip telephony (SPIT) calls will have a significant impact

Potential for telephone subscribers. On the other hand, among other things, white lists are used - lists of known participants from whom calls or other calls (multimedia connections, instant messages, multimedia messages, e-mails) should always be accepted. Calls from subscribers who are not members of a called party positive list will be rejected or referred to an announcer or voice mail facility. In Applicant's series marketed under the product name Surpass hiQ, this is implemented as a "selective call acceptance (SCA)", but terminals may also include such devices, for example by signaling calls from subscribers to the positive list with a particular ringing tone.

If a spitter M now wants to call a subscriber B who shields himself from a positive list, he can - e.g. by looking up in a phone book or similar directory - identify suspected members of participant B's positive list and try by

Wrong his own sender address when establishing a call (SIP Invite message) to reach the subscriber B, although he does not want this. What is sought here is a method that allows the called party B to uniquely identify a calling party A, even if there are network operators between the two parties who may not be trusted, so that the called party B of the in the call setup package as the sender address specified subscriber identification can not trust. A corresponding verification must be done before the terminal of B signals the incoming call, for example by ringing and thus disturbs the subscriber B. Thus, only the information contained in the SIP INVITE message (the first packet of the call setup) is available in the SIP protocol for a decision.

White list, selective call acceptance (SCA) are now available as a product.

In J. Peterson, C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" IETF draft-ietf-sip-identity-06, Oct. 2005 describes a method of header signing with which of the

Receiver of a call setup message can check whether a SIP INVITE message has been transmitted in the essential fields unadulterated. This procedure requires an infrastructure of CAs associated with the sender IDs. It also has to be received at every

INVITE message the public key of the appropriate instance are fetched so that the header fields can be checked. Network elements such as Session Border Controller (SBC) or back to back user agents (B2BUA, for example the device distributed under the product name Surpass hiQ)

Applicant), however, destroys or rewrites a portion of these header fields so that the method as described in a prior art public network will not work. In addition, the operator of the source network must be trusted, which is only one

Protection against attacks from other source networks.

In patent application DE-10 2005 046 965.5 "Method and arrangement for verifying a sender address transmitted in the course of a connection request for the purpose of setting up a communication connection An IP communication network "of the applicant dated 30.09.2005 has already been proposed a method by which the reachability of the sender can be checked at the address specified by him without participation of the network elements by an automatic recall Need support for network elements, but can potentially be misused for distributed denial of service (DDoS) attacks: If an attacker M, sending the sender address A, transmits call setup messages to many subscribers B_i, and all of these subscribers provide a callback validation of the address A, this can lead to an overload of the signaling devices of A. Actions had to take place in the network, because only there the simultaneous accumulation of recall messages can be detected and slowed down.Therefore, this approach loses its independence according to the current state of knowledge of network elements and Be drivers as soon as DDoS defense mechanisms are installed.

The secure shell (ssh) protocol uses a fully distributed public key method with no centralized certificate stores to identify a partner computer in a connection. In this case, in the case of a first contact between a computer R 1 and a computer R 2, the public key is transmitted from R 2 to R 1 and stored in this in a "known hosts" list With each further contact, the key is then checked and the connection is only established if R2 can authenticate to Rl with the same key as the first contact In order to ensure the identification for the initial contact, ssh foresees that Rl has received a "fingerprint" of R2 over a separate channel, which he checks.

The subject of the application is based on the problem of specifying a method which prevents an underrunning of the whitelist-based protection against unwanted calls by means of forged sender addresses. The problem is solved by the features of claim 1.

Since the positive list entries are secured by cryptographic keys between end users, the loophole of the sender addresses forged on suspected members of a positive list is closed. At the same time, precautions have been taken to rule out replay attacks and to significantly complicate man-in-the-middle attacks. The requirement to use the time stamp in KT on each call ensures that third parties can not easily reuse a KT observed in the network to gain access to subscriber B (replay protection).

Advantageous developments of the subject of the application are specified in the dependent claims.

In a development of the subject of the application sends an end system of a subscriber, z. B. B being called, in a response message to the end system of the calling one

Participant, z. B. A, his public key. Thus, the WL can also be maintained for outgoing calls.

If subscriber B himself calls subscriber A, the status information can be changed again. It makes sense to increase the trustworthiness, because it is more likely that A can falsify a false identity in a signaling message, than that the routing in the telephone network also leads to a call to the wrong party.

If a call setup request with a public key arrives at an end system in which another PK is stored for this identity, this is recognized as a forgery of the ID, and the call is rejected, or it is forwarded to the method for first contacts. It is additionally demanded that in each case a new time stamp TS is used in the case of a short successive connection setup request, even if this would not be necessary due to the predetermined interval (the tolerance) of B. This prevents replay attacks even in short time intervals.

The subject of the application is explained in more detail below as an exemplary embodiment in a scope necessary for understanding with reference to figures. Showing:

1 shows two networks N1 and N2 with SIP proxies SP1 and SP2 and session border controller SBC, signaling and media data traffic between subscriber terminals A and B. FIG. 2 shows a subscriber terminal B with positive list WL and entries for subscriber ID, public key PK, timestamp contained therein TS (optional) and status information Z (optional),

3 shows the sequence of the protocol between A (Alice) and B (Bob),

Fig 4 states of the key A on the WL of B,

Connection setup only shown symbolically, Fig. 5 State transition diagram for the public key of A on the positive list (WL) of B. WS = "willingness to disturb", ie the willingness to include A on the WL states: 0 = unknown, 1 = VALIDATED, 2 = VALIDATED ID (reference to the following figures), FIG. 6 Processing of the keys for incoming and outgoing calls, FIG. 7 Subroutine After Key Call Processing (x) to FIG. 6, FIG. 8 Subroutine Process new public key to FIG 7, FIG. 9 Subroutine Process known public key to FIG. 6, FIG. 10 Subroutine Process known public key in VALIDATED State to FIG. 9 and FIG. 11 Subroutine Process known public key in VALIDATED_ID State to FIG. FIG. 1 shows a scenario in which two terminals A and B communicate via two communication networks N1 and N2. In N1 SPl and in N2 SP2 is used as SIP proxy / SIP server, and between them a session border controller SBC filters the signaling traffic.

A subscriber A who wishes to establish a call to subscriber B sends in the initial call setup message (in case of SIP: INVITE) his public key PK A in a field and in a (possibly other) field a cryptotext encrypted or signed with his associated private key KT. This Kryptotext KT contains a timestamp TS.

On the first call of a hitherto unknown subscriber - as with any system based on positive lists - the call is not initially signaled directly to the called party, but forwarded to a separate treatment. In this case, the call can be routed to an answering machine or an announcement system, for example, or it can be signaled to the called subscriber separately (one-time ringing, separate ringing tone). In addition, the terminal B stores in this first call from A the public key PK A transmitted in the call setup message and the time stamp TS_A extracted from the KT with the aid of PK A with an initial state. It is checked whether the extracted with PK A from the KT timestamp TS within a certain interval at the current time. If this is not the case, the request is rejected in any case (with SIP: 403 forbidden).

After accepting (eg, listening to the voicebox) of the call, subscriber B may decide to record A on the WL. The status information of the entry for A is changed accordingly. If participant B himself is participant A calls, the state information can be changed again. It makes sense to increase the

Trustworthiness because A is more likely to foresee a false identity in a signaling message than that the routing in the telephone network additionally results in a call to the wrong party. For this purpose, a subscriber sends his public key not only in the initial call setup message, but also when called, in one of the reply messages to the end system of the call partner. Thus, the WL can also be maintained for outgoing calls.

If a call setup request with a public key arrives at a terminal in which another PK is stored for this identity, this is recognized as a forgery of the ID, and the call is rejected, or it is forwarded to the procedure for initial contacts.

The requirement to use the time stamp in KT on each call ensures that third parties can not easily reuse a KT observed in the network to gain access to subscriber B (replay protection). It is additionally required that in each case a new time stamp TS is used in the case of connection requests that are placed on each other for a short time, even if this is not necessary due to the tolerance of B. This prevents replay attacks even in short time intervals.

In contrast to the method used in ssh, the one described here is simpler (no additional exchange of packets) and thus faster. Security is marginally reduced by using timestamps instead of challenges, but replay attacks are excluded. In contrast to ssh, authentication at first contact does not take place via a fingerprint of the key transmitted via a second channel, but via the voice channel (media data exchange between A and B). Options and extensions

The positive list can be maintained in the terminal of subscriber B or in the associated SIP proxy / switching node. Instead of passing state information in

Positive lists can also be maintained for multiple positive lists, e.g. one for temporary information, one for WL entries and one for recalled WL entries. PK A and KT can be transmitted in case of using SIP for signaling in the following protocol data fields:

- one or more additional header fields

Hiding in the SDP part of the messages, e.g. in an additional attribute entry (a = ...) A terminal can send the public key information redundantly in several of these fields in the event that systems in the network delete one or the other entry. The positive list WL can be extended by an entry that specifies in which field the public key information for the respective communication partner can best be transmitted by the network.

The timestamps are specified in GMT. KT may include an encrypted timestamp or a timestamp in plain text plus a digital signature.

In addition to Option E, KT may also contain information about the identity of the sender and / or the recipient of the message. Instead of rejecting a timestamp or key that does not match, a call setup can be redirected to an announcement unit or an answering machine, or the call can be signaled with a distinctive ringing ring In addition to the described whitelist, an end system can carry a conventional whitelist This can be considered one separate list or as an additional state in a common WL.

If the timestamp is not within the tolerance interval of the addressee B in the case of a connection setup request, the latter can initiate a challenge-response method in which the original sender A of the request encrypts or signs a character string selected by B instead of a timestamp selected by A. In order to obtain additional stability in the case of man-in-the-middle attacks, the state-transition behavior of the keys in the WL can be designed such that a key that has been confirmed for a long time or repeatedly for many calls is more likely to remain in its state, whereas a key that has been newly recorded will be deleted more quickly and the caller will be referred back to the first contact procedure.

Options and extensions

A. The positive list can be maintained in the terminal of subscriber B or in the associated SIP proxy / switching node.

B. Instead of maintaining state information in positive lists, several positive lists can be maintained, e.g. one for temporary information, one for WL entries and one for recalled WL entries. C. PK_A and KT, in the case of using SIP, can be transmitted for signaling in the following protocol data fields:

- one or more additional header fields

Hiding in the SDP part of the messages, e.g. in an additional attribute entry (a = ...) D. A terminal can send the public key information redundantly in several of these fields in the event that systems in the network delete one or the other entry.

E. The positive list WL can be extended by an entry indicating in which field the public key information can be best transmitted to the respective communication partner through the network.

F. The timestamps are in GMT

G. KT may include an encrypted timestamp or a timestamp in plain text plus a digital signature. In addition to Option E, H. KT may also provide information about the identity of the person

Sender and / or the recipient of the message. I. Instead of rejecting a wrong time stamp or key can be a call setup on an announcement unit or an answering machine be redirected, or the call can be signaled with a special ringing tone ("distinctive ringing").

J. In addition to the whitelist described, an end system may carry a conventional whitelist. This may be configured as a separate list or as an additional state in a common WL.

K. If the time stamp is not within the tolerance interval of the addressee B in the case of a connection setup request, this can initiate a challenge-response method in which the original sender A of the request encrypts or signs a string selected by B instead of a time stamp selected by A.

L. In order to gain additional stability in the case of man-in-the-middle attacks, the state-transition behavior of the keys in the WL can be designed to be a key that has been repeated for a long time or for many calls has been confirmed, rather remains in its state, whereas a key that has been newly recorded is deleted more quickly and the caller is thus referred back to the procedure for initial contact.

To option C: header fields:

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 = "algorithm, algorithm2, ..."

In to reinvest 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 * "

Exemplary embodiments

- Terminal that manages positive lists (landline or mobile phone, answering machine, soft client)

- System in the network that manages white lists for subscribers

- Softswitch managing positive lists

- Softswitch or Session Border Controller SBC, which supports and distributes positive lists

Possible claims

- client with pub / private key pair

- Send public key in call setup message

- Send public key in response message

- Sent time stamp, in call setup and / or response message, encrypted or signed

- Checking public key for compliance upon receipt of a call setup request

- rejection of the call setup request or relapse to initial contact behavior if public key does not match the saved one - Rejection of call setup request or fallback to initial contact behavior or fallback to challenge-response procedure if the time stamp does not match the current time or has already been used

State management in the terminal, whereby a public key received on an outgoing call is classified more trustworthy than a received one of an incoming call. - Participant can choose whether he wants to record the call partner on the WL

Claims

claims

1. A method for SPIT defense accordingly - a subscriber A who wants to set up a call to subscriber B, in the initial call setup message his public key PK A and encrypted with its associated private key or cryptotext KT containing a time stamp TS, sends,

In the first call of the subscriber A, the end system of the subscriber B stores the public key PK A transmitted in the call setup message and the time stamp TS_A extracted with the aid of PK A from the KT with an initial state,

a check is made as to whether the time stamp TS extracted from the KT with PK_A lies within a specified interval at the current time and, if this is not the case, the request is rejected.

2. The method of claim 1, wherein after accepting, e.g. Listening to the voicebox, the call is an entry with positive status information for the subscriber A in the whitelist WL of the subscriber B is receivable.

3. The method according to any one of the preceding claims, characterized in that an end system of a subscriber, z. B. B, which is called, in a response message to the end system of the calling party, eg. A, sends his public key.

4. The method according to any one of the preceding claims, characterized in that successive calls for acceptance of the subscriber B have to have different time stamp.