This application is based upon and claims the benefit of priority from prior Japanese Patent Application No. 2007-160421, filed Jun. 18, 2007, the entire contents of which are incorporated herein by reference.
1. Field of the Invention
The invention relates to a communication apparatus which uses an SIP (Session Initiation Protocol) as a call signaling protocol used for IP phones on a network such as the Internet, intranet, and the like.
2. Description of the Related Art
An SIP is a protocol for a session layer which is used for Internet phones and the like and is required to establish a session between two or more terminals (for example, see reference 1: IETF RFC3261, SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002.).
Conventionally, upon reception of information (SIP URI or the like) of a transfer destination from a transfer instruction node, when a connection request source node (transfer instruction reception node) attempts to establish a connection to a transfer destination node based on that information, it is difficult to confirm (authenticate) whether or not that transfer destination node is, in fact, a node intended by the transfer instruction node. This means that node information (address information) indicating the transfer destination received from the transfer instruction node may have changed. Such change is likely to occur irrespective of the presence/absence of ill intent.
For example, the IP address of the transfer destination node changes when an IP address lease time based on the DHCP (Dynamic host configuration protocol) has elapsed or when the valid lifetime of an IPv6 privacy address has expired. Also, the IP address is often forged by hijacking the DNS (Domain name system).
In this manner, irrespective of whether or not the address information of the transfer destination instructed from the transfer instruction node may have changed, conventionally, the transfer instruction reception node cannot confirm whether or not a transfer destination corresponding to the address information notified from the transfer instruction node is the one intended by the transfer instruction node.
A communication system including a first terminal, a second terminal, and a third terminal which are connected to a network.
(1) The First Terminal
stores, in a first secret data memory, secret data shared with the second terminal; and
transmits a first connection request message to the second terminal.
(2) The Second Terminal
stores, in a first encryption key memory, a public key of the third terminal or a shared key shared with the third terminal;
stores, in a second secret data memory, the secret data shared with the first terminal;
receives the connection request message from the first terminal;
encrypts the secret data by using one of the public key and the shared key stored in the first encryption key memory, to generate an encrypted message; and
transmits, to the first terminal, the encrypted message together with a transfer instruction message which includes address information of the third terminal and instructs transfer of a connection request to the third terminal.
(3) The First Terminal
receives the transfer instruction message and the encrypted message; and
transmits the encrypted message together with a second connection request message whose destination is the address information in the transfer instruction message received.
(4) The Third Terminal
stores, in a second encryption key memory, a private key corresponding to the public key or the shared key;
receives the second connection request message and the encrypted message transmitted;
decrypts the encrypted message received by using the private key or the shared key stored in the second encryption key memory; and
transmits, to the first terminal, a response message to the second connection request and a decryption result of the encrypted message.
(5) The First Terminal
receives the response message and the decryption result; and
compares the decryption result with the secret data stored in the first secret data memory, and starts, when the decryption result equals the secret data, a communication with the third terminal.
As shown in
A case will be examined below wherein when SIP terminal A calls SIP terminal B (to issue a connection request), SIP terminal B issues a transfer instruction to SIP terminal A to transfer a call request (connection request) from SIP terminal A to SIP terminal C, as shown in
In this embodiment, when SIP terminal B transfers a connection request from SIP terminal A to SIP terminal C in this way, SIP terminal A as a connection request source (transfer instruction reception node) confirms whether or not a transfer destination is SIP terminal C as a transfer destination node intended by SIP terminal B as a transfer instruction node.
For this purpose, SIP terminal B pre-stores a public key of SIP terminal C. SIP terminals A and B share secret data between themselves.
SIP terminal B includes an encryption key storage unit 105b and encryption unit 106b in addition to a transceiver 101b, controller 102b, SIP processor 103b, and secret data storage unit 104b. The transceiver 101b, controller 102b, SIP processor 103b, and secret data storage unit 104b are the same as the transceiver 101a, controller 102a, SIP processor 103a, and secret data storage unit 104a of SIP terminal A. The encryption key storage unit 105b stores a public key of, e.g., SIP terminal C. The encryption unit 106b encrypts the secret data using an encryption key (the public key of SIP terminal C in this case) stored in the encryption key storage unit 105b, as will be described later.
SIP terminal C includes an encryption key storage unit 105c and decryption unit 107c in addition to a transceiver 101c, controller 102c, and SIP processor 103c. The transceiver 101c, controller 102c, and SIP processor 103c are the same as the transceiver 101a, controller 102a, and SIP processor 103a of SIP terminal A. The encryption key storage unit 105c stores, e.g., a private key of SIP terminal C in this case. The decryption unit 107c decrypts an encrypted message sent from SIP terminal A using an encryption key (the private key of SIP terminal C in this case) stored in the encryption key storage unit 105c.
A schematic sequence for transferring a connection request from SIP terminal A to SIP terminal C will be described below with reference to
In step S1, the SIP processor 103a of SIP terminal A generates a connection request message used to call for SIP terminal B, i.e., an SIP INVITE request. This SIP INVITE request is transmitted from the transceiver 101a.
In step S2, the transceiver 101b of SIP terminal B receives the SIP INVITE request transmitted from SIP terminal A. In response to this request, the SIP processor 103b of SIP terminal B generates a transfer instruction message which includes the address information of SIP terminal C and instructs SIP terminal A to transfer the connection request to SIP terminal C. As this transfer instruction message, an SIP REFER request, 302 Moved Temporarily response, and the like may be used. On the other hand, the encryption unit 106b of SIP terminal B encrypts the secret data (information unknown to SIP terminal C), which is stored in the secret data storage unit 104b and is shared with SIP terminal A, using the public key of SIP terminal C, which is stored in the encryption key storage unit 105b, thereby generating an encrypted message. The controller 102b appends this encrypted message to the transfer instruction message generated by the SIP processor 103b, and transmits that message to SIP terminal A from the transceiver 101b. Note that the secret data may be a time at which SIP terminal A issued the connection request to SIP terminal B (e.g., a time stamp recorded in the connection request message transmitted from SIP terminal A to SIP terminal B in step S1).
In step S3, in SIP terminal A which receives the transfer instruction message by the transceiver 101a, the SIP processor 103a generates a connection request message (SIP INVITE request) to be transmitted to a transfer destination node based on the address information of the transfer destination included in the Contact header in the transfer instruction message. The controller 102a transmits this connection request message together with the encrypted message received from SIP terminal B to the transfer destination node from the transceiver 101a.
In step S4, in SIP terminal C as the transfer destination node, which receives the connection request message from SIP terminal A, the SIP processor 103c generates a response message to the connection request message. The controller 102c calls the decryption unit 107c. The decryption unit 107c decrypts the encrypted message appended to the connection request message using the own private key stored in the encryption key storage unit 105c, and sends the decrypted message to the controller 102c. The controller 102c appends the decrypted message to the connection response message to SIP terminal A generated by the SIP processor 103c, and returns that message to SIP terminal A from the transceiver 101c.
Upon reception of the connection response message from SIP terminal C, the controller 102a of SIP terminal A verifies the decrypted message appended to the connection response message. That is, the controller 102a compares the decrypted message with the secret data shared between SIP terminals B and A (stored in the secret data storage unit 104a). If the decrypted message equals the secret data, the controller 102a determines that SIP terminal C is the transfer destination intended by SIP terminal B. After that, SIP terminal A starts an actual communication with SIP terminal C.
The match between the decryption result sent from SIP terminal C, and the secret data between SIP terminals A and B, means that SIP terminal C has a private key corresponding to the public key of SIP terminal B. That is, the match between the decryption result sent from SIP terminal C, and the secret data, is nothing but the proof that SIP terminal C is the transfer destination intended by SIP terminal B.
In the above description, the secret data is encrypted using the public key method. That is, the encryption key storage unit 105b of SIP terminal B stores the public key of SIP terminal C, and the encryption key storage unit 105c of SIP terminal C stores the private key of SIP terminal C. However, a secret key encryption method may be used in place of the public key method. That is, the secret data is encrypted and decrypted using a shared key (secret key) shared by SIP terminal B as the transfer instruction node and SIP terminal C as the transfer destination node. In this case, the encryption key storage units 105b and 105c of SIP terminals B and C store a shared key shared between SIP terminals B and C. Then, the match between the decryption result sent from SIP terminal C and the secret data between SIP terminals A and B means that SIP terminal C has a shared key shared with SIP terminal B. Hence, as in the aforementioned public key method, the match between the decryption result sent from SIP terminal C and the secret data proves that SIP terminal C is the transfer destination intended by SIP terminal B.
When SIP terminal A as the transfer instruction reception node establishes a connection to SIP terminal C as the transfer destination node, SIP terminal C as the transfer destination node may execute caller authentication of SIP terminal A as the transfer instruction reception node using a “WWW-Authenticate” header in the SIP message (see reference 2: [IETF RFC3261, SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002.]).
A practical example of the transfer sequence shown in
The first practical example of the transfer sequence will be described first with reference to
In SIP terminal B which receives the INVITE request message from SIP terminal A, the SIP processor 103b generates a 302 Moved temporarily response message to transfer that request to SIP terminal C. The Contact header in this message includes the IP address or SIP URI of SIP terminal C. On the other hand, the encryption unit 106b generates an encrypted message by encrypting the secret data (information unknown to SIP terminal C), which is stored in the secret data storage unit 104b and is shared with SIP terminal A, using the public key of SIP terminal C, which is stored in the encryption key storage unit 105b (step S102). The controller 102b appends this encrypted message to the 302 Moved temporarily response message generated by the SIP processor 103b, and transmits that message to SIP terminal A from the transceiver 101b (step S103).
Upon reception of the 302 Moved temporarily response message by the transceiver 101a, the SIP processor 103a of SIP terminal A generates an INVITE request message which includes, as a destination, the transfer destination information included in the Contact header in the received message. The controller 102a transmits this INVITE request message to the transfer destination from the transceiver 101a together with the encrypted message received from SIP terminal B (step S104).
Upon reception of the INVITE request message from SIP terminal A, the SIP processor 103c of SIP terminal C as the transfer destination node generates a response message (e.g., 200 OK message) to the request message. The decryption unit 107c decrypts the encrypted message appended to the request message using the private key stored in the encryption key storage unit 105c. The controller 102c appends the decrypted message to the 200 OK message generated by the SIP processor 103c, and returns that message from transceiver 101c to SIP terminal A (step S106).
Upon reception of the 200 OK message from SIP terminal C, the controller 102a of SIP terminal A verifies the decrypted message appended to that response message. If that message matches the secret data (stored in the secret data storage unit 104a) shared between SIP terminals B and A, the controller 102a determines that SIP terminal C is the transfer destination intended by SIP terminal B (step S107), and the process advances to step S108. If the decryption result is different from the secret information (step S107), the process ends.
In step S108, the SIP processor 103a of SIP terminal A generates an ACK message including SIP terminal C as a destination, and transmits it from the transceiver 101a. After that, an actual communication is continued between SIP terminals A and C.
The second practical example of the transfer sequence will be described below with reference to
Upon reception of the INVITE request message from SIP terminal A, SIP terminal B generates an encrypted message as in step S102 in
Upon reception of the Refer-To request message by the transceiver 101a, the SIP processor 103a of SIP terminal A generates a response message to that request message, i.e., a 202 Accepted message, and the transceiver 101a transmits this response message to SIP terminal B (step S203b).
Furthermore, the SIP processor 103a of SIP terminal A generates an INVITE request message which includes, as a destination, the transfer destination information included in the Refer-to header in the received Refer-to request message. The Referred-By header of this INVITE request message includes the IP address or SIP URI of SIP terminal B. The controller 102a transmits this INVITE request message from the transceiver 101a to the transfer destination together with the encrypted message received from SIP terminal B (step S204).
Upon reception of the INVITE request message from SIP terminal A, the decryption unit 107c of SIP terminal C as the transfer destination node decrypts the encrypted message appended to that request message using the private key stored in the encryption key storage unit 105c (step S205a). At this time, the SIP processor 103c may generate a 180 Ringing message and may transmit it from the transceiver 101c to SIP terminal A (step S205b). Upon completion of the decryption processing of the encrypted message, the SIP processor 103c generates a response message (e.g., 200 OK message) to the INVITE message. The controller 102c appends the decrypted message to the 200 OK message generated by the SIP processor 103c, and returns that message from the transceiver 101c to SIP terminal A (step S206).
Upon reception of the 200 OK message from SIP terminal C, the controller 102a of SIP terminal A verifies the decrypted message appended to the response message. If that message matches the secret data (stored in the secret data storage unit 104a) shared between SIP terminals B and A, the controller 102a determines that SIP terminal C is the transfer destination intended by SIP terminal B (step S207). If the decryption result is different from the secret data (step S207), the process ends.
If the decryption result matches the secret data, the SIP processor 103a of SIP terminal A generates an ACK message including SIP terminal C as a destination, and transmits it from the transceiver 101a (step S208). After that, a communication starts between SIP terminals A and C (step S209).
While SIP terminals A and C are communicating with each other in the processing sequence, SIP terminals A and B exchange a Notify message and its response message (200 OK response message) between them.
As described above, according to the above embodiment, when SIP terminal A transfers a connection request to the transfer destination node upon reception of a transfer request from SIP terminal B, SIP terminal A checks whether or not data of the decryption result sent from the transfer destination node equals the secret data shared between SIP terminals A and B. With this checking process, SIP terminal A can easily confirm without the intervention of a third party that the transfer destination node is a transfer destination intended by SIP terminal B, and that it is a reliable partner for SIP terminal A. That is, the transfer instruction reception node (SIP terminal A) can easily confirm whether or not a transfer destination corresponding to the address information notified by the transfer instruction node (SIP terminal B) is the one intended by the transfer instruction node.
The method of the invention (the processing sequences shown in
Number | Date | Country | Kind |
---|---|---|---|
2007-160421 | Jun 2007 | JP | national |