Communication device and communication system

The present invention relates to a method of encrypting a moving image and transmitting it over a network within a required real time.

In recent years, moving image communication using the Internet such as IP videophones has rapidly become widespread with the increase in network speed and computer performance. In such communication, the communication method (video coding method, IP address, port number, etc.) is first negotiated between terminals, and then the compressed coded video and audio data are divided into packets and transmitted. ..

SIP (Session Initiation Protocol: see Non-Patent Document 1), which has a function of establishing / disconnecting a communication session, is used for negotiation of a communication method. In a typical communication start sequence, the communication terminal calls the communication partner and negotiates the communication method through a 3-way handshake of SIP INVITE, 200 OK, and ACK. Contains session information described in SDP (Session Description Protocol: see Non-Patent Document 2). INVITE and 200 OK SDP correspond to the proposal (Offer) and selection (Answer) of the communication method, respectively, and the terminal determines the communication method of the moving image based on this information (see Non-Patent Document 3). ).

On the other hand, moving image compression coding technology such as MPEG (MPEG-2, MPEG-4) is used for coding moving images. MPEG-2 is described in detail in Non-Patent Document 4, and MPEG-4 is described in detail in Non-Patent Document 5. In addition, RTP (Real-time Transport Protocol) of Non-Patent Document 6 is used for transferring moving images. Non-Patent Document 7 and Non-Patent Document 8 describe methods for storing a moving image coded sequence encoded in MPEG-2 or MPEG-4 in an RTP packet, respectively.

By the way, in recent years, there has been increasing interest in communication security on the Internet, and there is a need for corporate users to encrypt and transfer moving images when they hold a video conference with a customer. When performing encrypted communication, first, when a session is established by SIP / SDP, the encryption method and encryption key are negotiated between terminals (key exchange processing), and then encryption of RTP communication is started. Methods for performing key exchange processing with SDP are described in Non-Patent Documents 9 to 11. A method for encrypting RTP communication is described in Non-Patent Document 12 as an SRTP (Secure RTP) protocol.

<nplcit num="1"><text>IETF RFC3261 SIP: Session Initiation Protocol, June 2002</text></nplcit>

<nplcit num="2"><text>IETF RFC2327 SDP: Session Description Protocol, April 1998</text></nplcit><nplcit num="3"><text>IETF RFC3264 An Offer / Answer Model with the Session Description Protocol (SDP), June 2002</text></nplcit><nplcit num="4"><text>"Point Illustrated Latest MPEG Textbook" Supervised by Hiroshi Fujiwara / Edited by Multimedia Communication Study Group, ASCII Publishing Bureau</text></nplcit><nplcit num="5"><text>"H.323 / MPEG-4 Textbook", supervised by Ei Okubo / Masahisa Kawashima, IE Institute</text></nplcit><nplcit num="6"><text>IETF RFC3550 RTP: A Transport Protocol for Real-Time Applications, July 2003</text></nplcit><nplcit num="7"><text>IETF RFC2250 RTP Payload Format for MPEG1 / MPEG2 Video, January 1998</text></nplcit><nplcit num="8"><text>IETF RFC3016 RTP Payload Format for MPEG-4 Audio / Visual Streams, November 2000</text></nplcit><nplcit num="9"><text>IETF Draft Session Description Protocol Security Descriptions for Media Streams, February 2004, http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-03.txt</text></nplcit><nplcit num="10"><text>IETF Draft MIKEY: Multimedia Internet KEYing, December 2003 http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-08.txt</text></nplcit><nplcit num="11"><text>IETF Draft Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP), February 2004, http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt- ext-10.txt,</text></nplcit><nplcit num="12"><text>IETF RFC3771 The Secure Real-time Transport Protocol, March 2004</text></nplcit>

<p> However, when data with a large bit rate such as a moving image is encrypted and transmitted / received in real time, the processing capacity of the communication device becomes overloaded, causing delays and packet loss, and on the communication device. There was a problem that it affected other running applications.</p><p> For example, the encryption processing speed of a PC equipped with Mobile Celeron 1GHz and 256MB of memory is about 30Mb / s for AES and about 5Mb / s for 3DES. Therefore, in moving image communication, which generally requires a processing speed of several Mb / s or more, the load of encryption processing becomes a significant overhead. Therefore, in view of the above-mentioned problems of the prior art, it is an object of the present invention that a communication device that transfers data having a large bit rate such as a moving image in real time selectively performs encryption processing to reduce the calculation cost. ..</p>

<p> In order to achieve the above object, the present invention provides a moving image communication device capable of selectively performing encryption processing based on the frame type of moving images and the contents of headers added to moving image data. provide. More specifically, when the moving image is encoded by MPEG-2, only the packet including the I frame is selected and encrypted.</p>

<p> According to the above invention, even when encryption processing is performed on data having a large bit rate such as a moving image, it is possible to reduce the amount of calculation while ensuring the confidentiality of the information.</p>

Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 3 shows a system configuration when the moving image transmitting device and the moving image receiving device in this embodiment communicate with each other. The moving image transmitting terminal 3, the moving image receiving terminal 4, and the SIP server 2 are connected to the data communication network 1 and can perform data communication with each other. Further, the moving image transmitting terminal 3 and the moving image receiving terminal 4 are housed in the SIP server 2, and SIP / SDP packets for session control are exchanged via the SIP server 2. On the other hand, the RTP packet that transfers the moving image directly communicates between the moving image transmitting terminal 3 and the moving image receiving terminal 4.

FIG. 4 shows an example of a sequence when the moving image transmitting terminal 3 and the moving image receiving terminal 4 perform encrypted communication. Prior to the moving image communication, the moving image transmitting terminal 3 and the moving image receiving terminal 4 exchange SIP INVITE (51), 200 OK (52), and ACK (53) to call the communication partner and negotiate the communication method. The SDP included in the message body part of INVITE (51) includes the content of the encryption process applied to a specific RTP stream (encryption algorithm, message authentication algorithm, encryption key, message authentication key, etc.), as well as a video. The proposal of the "security level" desired by the image transmission terminal 3 is described. In addition, the SDP of 200 OK (52) includes the content and security level of the encryption process selected by the moving image transmitter 4. The "security level" is a concept introduced by the present invention, and specifically specifies an algorithm for determining whether or not to perform encryption processing on a specific RTP packet.

The moving image transmitting terminal 3 and the moving image receiving terminal 4 are based on the SDP of INVITE (51) and 200 OK (52), and the moving image communication method (moving image coding method, IP address, port number, encryption processing). The content, security level, etc.) are determined. Next, the moving image transmitting device 3 starts transmitting the moving image according to the determined communication method (54). Video communication by RTP is protected by using SRTP or the like described above, but the video transmitting device 3 selectively encrypts packets based on the security level negotiated in advance with the video receiving device 4. In addition, whether or not the packet has been encrypted is added to the packet as an encryption flag and transmitted. On the other hand, the moving image receiving device 4 determines whether or not to perform the decryption processing of the received moving image packet by using the encryption flag set in the packet. Note that the moving image transmitting terminal 3 and the moving image receiving terminal 4 may change the security level by exchanging INVITE, 200 OK, and ACK again during communication as shown in 55 to 57.

FIG. 5A shows the format of the SIP packet exchanged between the moving image transmitting terminal 3 and the moving image receiving terminal 4. The SIP packet is composed of an IP header part (81), a UDP header part (82), and a SIP message part (83), and the SIP message part (83) is further composed of a SIP start line (84), a SIP message header (85), and so on. It is decomposed into blank lines (86) and SIP message body part 87). Blank lines and SIP message body parts may not exist, or multiple lines may be consecutive.

Figure 5 (b) shows an example SIP INVITE message. INVITE is a method that requests the establishment of a session. The start line contains the method name (INVITE), the target of the request (sip: t2), and the SIP version information (SIP / 2.0). In the SIP message header, the message destination (To: t2 &lt;sip: t2&gt;), source (From: t1 &lt;sip: t1&gt;), and data type of the message body part (Content-Type: application / sdp) , Data length of message body part (Content-Length: 290) etc. are included. In the example of Fig. 5 (b), the message body part is followed by a blank line, and the session information described in SDP is stored. This SDP proposes the communication method desired by the sender of the message, the moving image coding method (the fourth parameter on the m line), and the IP address used for communication (the third parameter on the c line). , Receive port number (second parameter of m line), content of encryption processing (a = crypto ... line), etc., as well as the security level specified by the present invention (91: a = security-level) Line) is included.

Figure 5 (c) shows an example SIP 200 OK message. 200 OK is a successful response to a particular request (INVITE in this case). The starting line includes the SIP version (SIP / 2.0), status code (200), and a textual status code description (OK). In addition, the SIP message header contains the message destination (To: t2 &lt;sip: t2&gt;), source (From: t1 &lt;sip: t1&gt;), and message body, as in INVITE in Fig. 5 (b). Data type (Content-Type: application / sdp), data length of message body (Content-Length:) 300) etc. are included (message destinations and sources are copied from the corresponding request message). The SDP in the body of the SIP message indicates the session information selected by the sender of the message, the video coding method (4th parameter on line m), and the IP address used for communication (3rd on line c). (Parameter), receiving port number (second parameter in line m), content of encryption processing (a = crypto ... line), etc., as well as the security level (92: a =) specified by the present invention. The security-level line) is included. Here, the values of the IP address and port number are newly selected according to the conditions of the terminal that sends 200 OK, but the contents of the moving image coding method and encryption processing are the parameters included in the SDP of INVITE. Select and set the appropriate one from the list.

Fig. 5 (b) INIVTE, Fig. 5 (c) 200 When determining the video communication method from the OK SDP, the following processing is performed. First, regarding the IP address and port number used for communication, the values specified by each terminal are adopted as they are (the port number only indicates the port for receiving the moving image, and the port number for transmitting the moving image is , The sending terminal can be freely selected). Then, for parameters that require mutual agreement, such as the moving image coding method and the content of encryption processing, INVITE proposes and selects the one selected from 200 OK.

The RTP / SRTP packet format will be described with reference to FIG. As shown in FIG. 6A, the RTP / SRTP packet (103) follows the IP header section (101) and the UDP header section (102). Figure 6 (b) shows an example of the RTP packet format. The RTP packet is divided into an RTP header part and a payload part. The RTP header part depends on the RTP version (v), the flag indicating the presence or absence of padding (P), the flag indicating the presence or absence of the extension header (x), the number of contribution information source identifiers (CSRC) (M), and the payload type. Includes marker bits (M), payload type (PT), sequence number (Sequence Number), time stamp (Time Stamp), stream identifier (SSRC), etc. Audio and moving image data are stored in the payload section according to the format defined for each payload type. For example, the format when MPEG-2 or MPEG-4 is used for encoding a moving image is described in Non-Patent Document 7 and Non-Patent Document 8 described above, respectively.

FIG. 6 (c) shows an example of the SRTP packet format. The SRTP packet format is almost the same as the RTP packet format, but in the example shown in the figure, SRTP MKI (Master Key Index: an identifier that specifies the key used for encryption processing) and Authentication Tag (data for message authentication. Specifically. Is the hash value of the RTP packet) has been added. In addition, the SRTP payload section contains an encrypted version of the RTP payload section (SRTP encryption function and message authentication function, addition of SRTP MKI is optional, and the actual packet is in the format described here. May be different).

7 (a) and 7 (b) show examples of RTP / SRTP packets to which the "encryption flag" specified by the present invention is added. In this example, the encryption flag is added between the RTP / SRTP header part and the payload part, but it may actually be added anywhere in the packet. Although it has been explained above that the encryption flag indicates whether or not the packet has been encrypted, it may be configured as shown in FIG. 7 (c) if necessary. The encryption flag (E-flag) in FIG. 7 (c) consists of an encryption bit (112: E-bit) and a message authentication bit (113: A-bit). These indicate whether or not SRTP encryption processing and message authentication processing have been performed on the packet, respectively.

FIG. 1 shows a functional block of the moving image transmitting device (3) in the first embodiment. The moving image transmitter (3) includes a communication processing unit (21) that performs communication processing with the outside, a communication control unit (13) that performs session control processing, an SDP processing unit (11) that functions as an SDP parser, and a SIP protocol. Based on the security level notified from the SIP processing unit (15) that performs processing, the moving image coding unit (16) that compresses and encodes the moving image, the RTP sending unit (17) that performs RTP protocol processing, and the communication control unit. For the encryption determination unit (18) that determines whether or not to perform encryption processing, the flag addition unit (19) that adds the content determined by the encryption determination unit (18) to the packet as an encryption flag, and the RTP packet. It includes an SRTP transmission unit (20) that performs encryption processing. Here, the encryption determination unit (18) and the flag addition unit (19) are functional blocks newly introduced by this patent. Further, the moving image communication device of the present invention includes a means (14) for determining the security level at the time of session establishment in the communication control unit (13) and a means (12) for describing the security level in the SDP processing unit (11).

As described above, the encryption determination unit (18) is a functional block that determines whether or not to perform encryption processing on a specific RTP packet. However, the method of selecting the packet to be encrypted is at least as follows. There are two possibilities (Method 1) Packets are selected at a fixed rate based on the sequence number in the RTP header (only packets with an even sequence number are encrypted, etc.) (Method 2) Video compression When MPEG-2 is used as the encryption method, packets are selected based on the frame type (I / P / B) included in the RTP payload. Here, what are I frame, P frame, and B frame in MPEG? , Intra-Picture (intra-encrypted image), Predictive-Picture (inter-frame forward-predicted coded image), Bidirectionally predictive-Picture (bidirectional predictive-encrypted image), respectively. By encrypting only the frame, much of the image information can be hidden.

FIG. 2 shows a functional block of the moving image receiving device 4 in the first embodiment. The moving image transmitter (3) includes a communication processing unit (21) that performs communication processing with an external device, a communication control unit (13) that performs session control processing, an SDP processing unit (11) that functions as an SDP parser, and a SIP. SIP processing unit (15) that performs protocol processing, decoding judgment unit (35) that determines whether to decrypt the packet using the encryption flag, SRTP receiving unit that performs decryption processing of RTP packets ( 34), the encryption flag deleter (33) that deletes the encryption flag from the RTP packet, the RTP receiver (32) that performs RTP protocol processing and outputs the moving image coded string, and decodes the moving image coded string. It includes a moving image decoding unit (31) that outputs as a video signal. The decryption determination unit (31) and the flag deletion unit (33) are functional blocks newly introduced by this patent.

<figref num="1">The functional block diagram of the moving image transmission terminal in the 1st Example.</figref><figref num="2">The functional block diagram of the moving image receiving terminal in the 2nd Example.</figref><figref num="3">The network configuration diagram in the first embodiment.</figref><figref num="4">The communication sequence diagram in the first embodiment.</figref><figref num="5">SIP packet format.</figref><figref num="6">RTP packet format.</figref><figref num="7">Extended RTP packet format.</figref>

Code description

3 video transmitter, 4 video receiver, 11 SDP processing unit, 12 security level description means, 13 communication control unit, 14 security level determination means, 15 SIP processing unit, 16 video coding unit, 17 RTP transmission unit , 18 Encryption judgment unit, 19 Flag addition unit, 20 SRTP transmission unit, 21 Communication processing unit, 31 Video decoding unit, 32 RTP reception unit, 33 Flag deletion unit, 34 SRTP reception unit, 35 Decryption judgment unit, 91 Encryption level (suggested), 92 Encryption level (selected), 111 Encryption flag.