JP2007036953A - Information communication apparatus, information communication method and computer program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To enable to smoothly recover an operation state even if a normal response to a request of content key confirmation cannot be obtained from a Source apparatus. <P>SOLUTION: In a situation where a busy state of a Source apparatus or congestion of a network causes delay in response of CONT_KEY_CONF, a Sink apparatus is brought into a non-confirmation state similarly to a case of receiving the response, and permits retry of a request of confirming a content key for only a predetermined period. If it is confirmed that the content key is correct after that, the Sink apparatus can continue to execute decoding processing of reception content. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an information communication apparatus, an information communication method, and a computer program for receiving and processing transmission content encrypted for copyright protection or other purposes, and particularly to another information device compliant with DTCP. The present invention relates to an information communication apparatus, an information communication method, and a computer program for executing mutual authentication and key exchange (AKE) procedures.

  More specifically, the present invention relates to a DTCP-IP-compliant mutual authentication and key exchange (AKE) procedure with another information device on an IP network, encrypted content transmission using the HTTP protocol, and transmission content The present invention relates to an information communication apparatus and information communication method for executing decryption, reproduction and other content processing, and a computer program, and in particular, encryption using a content key shared via an AKE procedure compliant with DTCP-IP. The present invention relates to an information communication apparatus, an information communication method, and a computer program that perform a content key confirmation procedure when performing content decryption processing.

  Recently, distribution and distribution services for content such as video and music via a network are actively performed. This type of service does not require movement of media such as CDs and DVDs, and can distribute contents between remote terminals via a network. On the other hand, content handled via a network is protected from unauthorized use such as unauthorized duplication or falsification under copyright law as one of the copyrighted works. According to the Copyright Act, Article 30 of the Act allows the user to reproduce personally or for the purpose of use at home, etc., while in Article 49, Paragraph 1 of the Act, private use is permitted. The use of duplicates in other places is prohibited. In addition, since illegal operations such as copying and falsification are relatively easy for digital content, not only legal maintenance but also technical aspects are allowed while using personal or household content. Protection against unauthorized use is necessary.

  For example, DTCP (Digital Transmission Content Protection), which is an industry standard related to protection of digital transmission content, defines a mechanism for transmitting content in a copyright-protected form (for example, see Non-Patent Document 1). ) In DTCP, an authentication protocol between devices at the time of content transmission and a transmission protocol for encrypted content are decided. To summarize, the DTCP-compliant device is required to decrypt compressed content that is easy to handle, such as MPEG (Moving Picture Experts Group), in an unencrypted state and to decrypt encrypted content. To perform key exchange according to a predetermined mutual authentication and key exchange (AKE) algorithm, and to limit the range of devices that perform key exchange using the AKE command.

  A server (DTCP Source) that is a content provider and a client (DTCP Sink) that is a content provider share a key through an authentication procedure by transmitting and receiving an AKE command, and encrypt the transmission path using the key to create a content. Is transmitted. Therefore, an unauthorized client cannot obtain the content because the encryption key cannot be acquired unless the authentication with the server is successful. Also, by limiting the number and range of devices that transmit and receive AKE commands, the range in which content is used can be kept within the personal or home range as defined by the Copyright Act.

  DTCP originally defined the transmission of digital content on a home network using IEEE 1394 or the like as a transmission path. Recently, development of a technology in which the DTCP technology defined on the basis of IEEE 1394 is ported to an IP network has been promoted (hereinafter, this technology is referred to as DTCP-IP). Many home networks are connected to external wide-area networks such as the Internet via routers, etc., so the establishment of DTCP-IP technology enables flexible and efficient use of IP networks while protecting digital content Content can be used.

  DTCP-IP is basically the same technology that is included in the DTCP standard and ported the DTCP technology to the IP network. However, the DTCP-IP uses an IP network as a transmission path, and uses HTTP or the like to transmit encrypted content. It differs from the original DTCP defined in the IEEE1394 base in that the RTP protocol is used. In addition, since various devices such as PCs are connected on the IP network and there is a high risk that data can be easily wiretapped or tampered with, DTCP-IP performs network transmission while protecting the content. Further methods are defined (see, for example, Non-Patent Document 2).

  Here, a content transmission procedure according to DTCP-IP will be described. However, devices conforming to DTCP are classified into two types. One is a server device called DTCP_Source, which accepts a request for content and transmits the content. The other is called DTCP_Sink, which is a client device that requests content, receives content, and reproduces or records it.

  FIG. 6 illustrates a key exchange procedure based on AKE between a DTCP_Source device and a DTCP_Sink device, and a mechanism for performing encrypted content transmission using a key shared by the key exchange. In the example shown in the figure, the HTTP protocol is used for content transmission.

DTCP_Source and DTCP_Sink first establish one TCP / IP connection and authenticate each other. This authentication is called DTCP authentication or AKE (Authentication and Key Exchange). In the DTCP compliant device, a unique device ID and an authentication key K _auth are embedded by an authorized organization called DTLA (Digital Transmission Licensing Administrator). In the DTCP authentication procedure, using such information, after confirming that each other is a legitimate DTCP compliant device, the authentication key K _auth managed by DTCP_Source for encrypting or decrypting the content is exchanged with the DTCP_Sink device. Can be shared.

If the AKE procedure is successful, each of the DTCP_Source device and the DTCP_Sink device performs the same processing inside, and generates a seed key K _x that is a seed of the content key from K _auth . Seed key K _x is used to generate the content key K _c during content transmission (described later).

  Then, after the AKE authentication and key exchange procedure is completed between DTCP-compliant devices, DTCP_Sink requests content on DTCP_Source. The DTCP_Source can transmit in advance a content location indicating an access destination to the content on the DTCP_Source to the DTCP_Sink through a CDS (Contents Directory Service) or the like. When DTCP_Sink requests content, protocols such as HTTP (Hyper Text Transfer Protocol) and RTP (Real Time Protocol) can be used. Alternatively, a transmission protocol such as RSTP (Real Time Streaming Protocol) is also applicable.

  As shown in FIG. 6, when requesting content according to the HTTP procedure, DTCP_Source becomes an HTTP server and DTCP_Sink becomes an HTTP client, and content transmission is started. By the way, when RTP transmission is requested, DTCP_Source becomes RTP Sender and DTCP_Sink becomes RTP Receiver, and transmission of contents starts.

  When performing content transmission by HTTP, a TCP / IP connection for HTTP is created from an HTTP client separately from a TCP / IP connection for DTCP authentication (that is, each of the DTCP_Source device and the DTCP_Sink device is for an AKE procedure) And a separate socket (a combination of IP address and port number) for content transmission). Then, the HTTP client requests content on the HTTP server by the same operation procedure as that of normal HTTP. In contrast, the HTTP server returns the requested content as an HTTP response.

  Here, the data transmitted as the HTTP response is data obtained by encrypting the content using the key shared after the AKE authentication is performed by the HTTP server, that is, the DTCP_Source device.

Specifically, the DTCP_Source device generates a nonce N _c using a random number, and generates a content key K _c based on K _x and N _c . Then, the content requested from the DTCP_Sink device is encrypted using the content key K _c, and a PCP (Protected Content Packet) composed of the encrypted content and the nonce N _c is placed on the TCP stream and transmitted to the DTCP_Sink device. Then, the IP protocol divides the TCP stream into packet sizes as a predetermined unit, further converts the TCP stream into an IP packet with a header portion added, and delivers it to a specified IP address (for example, see Non-Patent Document 3). thing).

When the DTCP_Sink device receives each IP packet from the DTCP_Source device, it assembles it into a TCP stream. When the nonce N _c is extracted from the stream, the content key K _c can be calculated in the same manner using this and the key K _x obtained from the authentication key K _auth , and the encrypted content can be decrypted. Then, processing such as reproduction or recording can be performed on the plaintext content after decryption.

  When the content transmission using the HTTP protocol is completed, the used TCP connection can be appropriately disconnected.

Here, if the same encryption key is continuously used throughout the long TCP stream, the risk of the key being decrypted increases. For this reason, in DTCP-IP, the source device is arranged to update the nonce N _c, that is, the content key K _c for every 128 MB of content. In the byte stream, the range of data encrypted using the content key K _c generated from the same nonce N _c is a decryption unit that can be decrypted using the same key.

  Also, since the decryption key is dynamically changed in the middle of the byte stream in this way, a content key confirmation procedure is required. Therefore, the DTCP_Sink device further establishes a TCP connection for confirming the content key separately from the TCP connection for content transmission, and performs a procedure for confirming the content key for the DTCP_Source device. When the DTCP_Sink device needs to confirm the content key, it establishes this TCP connection as appropriate.

For example, DTCP-IP Volume 1 Supplement Section V1SE. In 8.6, Content Key Configuration is defined. According to this, the sink device uses the CONT_KEY_CONF subfunction to confirm the content key associated with the current nonce _Nc .

In DTCP-IP, content transmission is performed in a packet format called PCP including encrypted content and nonce _Nc . One PCP corresponds to a decryption unit that can be decrypted with the same decryption key. The sink device must confirm the value of the nonce _Nc of the most recently received PCP for each content stream, and must reconfirm subsequent nonces that are dynamically changed at intervals of 2 minutes. However, when the sink device monitors and confirms that the value of the subsequent nonce _Nc is a continuously increasing value after the initial confirmation of the nonce, the periodic content key confirmation procedure is omitted. be able to.

When the sink device acquires an unconfirmed initial nonce, it is given a grace period to retry the content key confirmation for only one minute before it has to finish decrypting the encrypted content with respect to the content stream. When the sink device succeeds in confirming the nonce _Nc during this grace period, the sink device can recover the decryption operation of the encrypted content.

FIG. 7 shows a procedure between the sink device and the source device for content key confirmation. However, although R is a 64-bit value and is initially a random number, it is incremented by 1 mod 2 ⁶⁴ in the subsequent trial and is as follows.

MX = SHA-1 (K _x || K _y )
MAC3A = MAC3B = [SHA-1 (MX + N c T + R)] msb80
MAC4A = MAC4B = [SHA-1 (MX + N c T + R)] lsb80
(In the above equation, “+” is used to mean mod 2 ⁶⁴ addition.)

In the content confirmation procedure shown in the drawing, the sink device sends a nonce N _c T for inspection to the source device in the CONT_KEY_CONF command.

When receiving the CONT_KEY_CONF command, the source device extracts the nonce N _c T for inspection and compares it with the current nonce N _c . When the current nonce N _c is in the range of N _c T and N _c T + 5, it is confirmed that the inspection nonce N _c T is valid. When it is confirmed that the nonce N _c T for inspection is valid, the content key is further confirmed based on whether MAC4A and MAC4B are equal. Then, either an ACCEPTED response indicating that the content key is correct or a REJECTED response indicating that the content key is incorrect is returned to the sink device.

  On the sink device side, when an ACCEPTED response is returned from the source device, the content key is further confirmed based on whether MAC4A and MAC4B are equal. When the sink device itself can confirm that the content key is correct, the sink device is in a confirmed state.

  On the other hand, when the ACCEPTED response is returned from the source device but the content key confirmation fails in the sink device itself, or when the REJECTED response is returned from the source device, the sink device is in a non-configuration state.

  Here, confirmed is a state in which the content key is confirmed to be correct by CONT_KEY_CONF, and non-configuration is a state in which the content key is confirmed to be invalid by CONT_KEY_CONF, both of which are in DTCP Volume 1 Supplement E Section 6 Section E1. It is prescribed.

  In the confirmed state, the sink device can continue to decrypt the received content. On the other hand, in the non-configuration state, the sink device cannot continue the decoding process.

  FIG. 8 shows, in the form of a flowchart, a processing procedure for the source device to perform a content key confirmation procedure with the sink device.

When the source device receives a CONT_KEY_CONF command requesting content confirmation from the sink device that is the content transmission destination (step S1), the source device confirms the content key (step S2). Specifically, the inspection nonce N _c T is extracted from the command and compared with the current nonce N _c . When the current nonce N _c is in the range of N _c T and N _c T + 5, it is confirmed that the inspection nonce N _c T is valid.

  If the source device confirms that the content key is correct, it returns an ACCEPTED response indicating that to the sink device (step S3). Is returned as a REJECTED response (step S4).

  Note that ACCEPTED and REJECTED are responses to commands specified in DTCP Volume 1 Supplement E Section V1SE8.6.

  FIG. 9 is a flowchart showing a processing procedure for the sink device to perform a content key confirmation procedure with the source device.

  The sink device transmits a CONT_KEY_CONF command to the source device as a content request destination (step S11), and then waits for a response from the source device (step S12).

  Here, when an ACCEPTED response is received from the source device (step S13), the content key is confirmed by itself based on whether MAC4A and MAC4B are equal (step S14). At this time, it is confirmed (step S15) when the content key is correct, and non-confirmation when the content key is invalid (step S17). In addition, when the sink device receives a REJECTED response from the source device (step S16), it is non-configuration (step S17).

  In the confirmed state, the sink device can continue the decryption process of the received content. On the other hand, in non-configuration, the sink device cannot continue the decoding process (described above). However, since the sink device can repeat the content key confirmation procedure for one minute after becoming the first non-configuration (step S18), the process returns to step S11 (step S19) and reissues the CONT_KEY_CONF command.

  If the content key confirmation procedure is retried and confirmed within one minute (step S15), the decryption process of the received content can be continued. However, if the non-configuration continues for 1 minute (step S18), the decryption process of the received content must be stopped immediately (step S20).

  As described above, in the DTCP-IP standard, in the content key confirmation procedure, the sink device transmits a CONT_KEY_CONF command, receives a normal response such as ACCEPTED or REJECTED from the source device, and fails to confirm the content key. As a result, it is specified that the device falls into a non-confirmation state, and that when the device enters the non-confirmation state, the sink device is given one minute before stopping the content decrypting process. Therefore, the sink device repeatedly transmits the CONT_KEY_CONF command for one minute after it enters the non-configuration state, and if the command key is successfully confirmed during this grace period, the sink device does not have to stop the content decrypting process.

  However, in the DTCP-IP standard, in the content key confirmation procedure, when the sink device cannot receive a normal response to the CONT_KEY_CONF command such as ACCEPTED or REJECTED from the source device, the content key confirmation is not successful. The processing is not specified. Specifically, when the sink device transmits a CONT_KEY_CONF command, the source device returns a NOT_IMPLEMENTED (non-implemented) response, or when a timeout occurs for a response reception standby, the non-sink device -It is not specified that it will be in the confirmation state.

  In other words, the non-confirmation state does not mean that a grace period is not given to the sink device when the content key confirmation fails. That is, the sink device must immediately stop the content decryption process when it receives a NOT_IMPLEMENTED response from the source device or when the response reception waiting period times out. Then, when it is desired to use the content for which the decryption process has been stopped, the content transmission procedure must be performed again from the beginning. Compared with the case where the content decryption process is restarted using a one-minute grace period, It becomes inefficient.

  The response of CONT_KEY_CONF may be delayed due to the busy state of the source device or network congestion. However, if the sink device receives NOT_IMPLEMENTED, which is not normally possible, or if the response content is timed out, the received content decryption process is immediately stopped, which causes a problem in the operation of the sink device. This is because the sink device cannot decrypt the received content even though it has the correct content key.

DTCP Specification Volume 1 Version 1.3 (Informal Version) http: //www.DTCP Specification Volume 1 Version 1.3 (Informational Version) http: // www. dtcp. com / data / info — 20040107_dtcp_Vol — 1_1p3. pdf DTCP Volume 1 Supplement E Mapping DTCP to IP, Version 1.0 (Informational Version) http: //www.DTCP Volume 1 Supplement E Mapping DTCP to IP, Version 1.0 (Informational Version) http: // www. dtcp. com / data / info — 20031124_dtcp_VISE — 1p0. pdf / RFC (Request For Comment) 791 INTERNET PROTOCOL

  An object of the present invention is to perform mutual authentication and key exchange (AKE) procedures based on DTCP-IP with another information device on an IP network, encrypted content transmission using the HTTP protocol, and decryption of transmission content. It is to provide an excellent information communication apparatus, information communication method, and computer program capable of suitably executing content processing such as reproduction, reproduction and the like.

  A further object of the present invention is to suitably perform a content key confirmation procedure when performing decryption processing of encrypted content using a content key shared via an AKE procedure compliant with DTCP-IP. Another object of the present invention is to provide an excellent information communication apparatus, information communication method, and computer program.

  It is a further object of the present invention to request content key confirmation from a source device as a sink device when content is transmitted in conformity with DTCP-IP, and to obtain content without obtaining a normal response to this. An object of the present invention is to provide an excellent information communication apparatus, information communication method, and computer program capable of smoothly recovering the operating state even when key confirmation fails.

The present invention has been made in consideration of the above problems, and a first aspect thereof is an information communication apparatus for receiving and processing encrypted content transmitted from a source device,
Content receiving means for receiving encrypted content;
Content decrypting means for decrypting the encrypted content using the content key;
Content key confirmation requesting means for requesting confirmation of the content key from the source device;
In response to the response from the source device to the content key confirmation request, the content key confirmation means,
Content decryption processing control means for controlling continuation or stop of the decryption processing operation of the encrypted content by the content decryption means according to the confirmation result by the content key confirmation means;
The content decryption processing control means confirms the content key by the content key confirmation requesting means when a desired response is not obtained from the source device in response to the content key confirmation request or when the response reception waiting period has timed out. Allow requests to be retried for a specified period of time,
This is an information communication device.

  The present invention relates to an information communication system for transmitting information content that requires copyright protection on an IP network, and more specifically, specifically, mutual authentication and communication between information communication devices compliant with DTCP-IP. The present invention relates to an information communication system that transmits and receives an AKE command for key exchange (AKE) and securely transmits encrypted content using a key shared through mutual authentication and key exchange.

  In this type of information communication system, encrypted communication is performed while changing a content key in the middle of a long byte stream such as a TCP stream, and decryption processing of encrypted content and other content processing are performed. The content key confirmation procedure is performed.

  The information communication apparatus according to the present invention operates as a sink device in DTCP-IP. When content is transmitted to and from the source device using the HTTP protocol, the content decrypting unit is configured to use the authentication key shared through the mutual authentication procedure with the source device and the nonce added to the encrypted content. Generate a key and decrypt the encrypted content. Further, the content key confirmation requesting unit transmits a content key confirmation request command including the inspection nonce to the source device. In addition, the content key confirmation unit receives the ACCEPTED response from the source device and checks the content key by itself to determine that it is the correct key, and outputs a confirmed state. When the content key confirmation unit receives the ACCEPTED response from the source device, A non-confirmation state is output when it cannot be determined that the key is correct after confirmation or when a REJECTED response is received from the source device.

  Here, in the DTCP-IP standard, in the content key confirmation procedure, a normal response such as ACCEPTED or REJECTED is received from the source device, and as a result of the failure to confirm the content key, the state falls into a non-configuration state. , It is clearly stated that when the device enters the non-confirmation state, the sink device is given a one-minute grace period before the content decryption process is stopped. Therefore, if the sink device succeeds in confirming the command key during the grace period after the sink device enters the non-configuration state, the sink device does not have to stop the content decryption process.

  On the other hand, the response of CONT_KEY_CONF may be delayed due to the busy state of the source device or the congestion of the network. However, in such a case, it is not specified that the sink device is in a non-confirmation state. In the non-confirmation state, a grace period is not given when the content key confirmation fails, so the sink device must immediately stop the content decryption process.

  Since the sink device cannot decrypt the received content even though it has the correct content key, the decryption processing of the received content is immediately performed when a NOT_IMPLEMENTED is received or when a timeout occurs for the response. If it stops, there is a problem as the operation of the sink device. Also, when it is desired to use content for which decryption processing has been stopped, the content transmission procedure must be performed again from the beginning, which is inefficient compared to the case where content decryption processing is resumed using a grace period. It becomes.

  On the other hand, according to the information communication apparatus of the present invention, the content decryption process control means is timed out when a desired response cannot be obtained from the source device in response to the content key confirmation request or when the response reception waiting period times out. In this case, the content key confirmation requesting means by the content key confirmation requesting unit is allowed to retry only for a predetermined period. Therefore, even if the sink device can confirm that the content key is correct after that even if the response of the CONT_KEY_CONF response is delayed due to the busy state of the source device or network congestion, the decryption processing of the received content can be performed. Can be continued.

  Here, the content key confirmation unit outputs a non-configuration state when a desired response is not obtained from the source device in response to the content key confirmation request or when the response reception waiting period times out. May be.

  In such a case, the operation of the sink device when there is a delay in receiving a response to the content key confirmation request due to the busy state of the source device or the congestion of the network is processed in the non-configuration state defined by DTCP-IP. Can be realized at low cost.

According to a second aspect of the present invention, there is provided a computer program written in a computer-readable format so that reception processing of encrypted content transmitted from a source device is executed on a computer system. For the system,
A content receiving procedure for receiving encrypted content;
A content decryption procedure for decrypting the encrypted content using the content key;
A content key confirmation requesting procedure for requesting confirmation of a content key from the source device;
In response to a response from the source device to the content key confirmation request, a content key confirmation procedure;
Executing a content decryption process control procedure for controlling the continuation or stop of the decryption process operation of the encrypted content according to the content decryption procedure according to the confirmation result in the content key confirmation procedure;
In the content decryption process control procedure, when a desired response is not obtained from the source device in response to the content key confirmation request, or when the response reception waiting period times out, the content key confirmation by the content key confirmation request procedure is performed. Allow requests to be retried for a specified period of time,
This is a computer program characterized by the above.

  The computer program according to the second aspect of the present invention defines a computer program described in a computer-readable format so as to realize predetermined processing on a computer system. In other words, by installing the computer program according to the second aspect of the present invention in the computer system, a cooperative action is exhibited on the computer system, and the information communication according to the first aspect of the present invention. The same effect as the apparatus can be obtained.

  According to the present invention, mutual authentication and key exchange (AKE) procedures compliant with DTCP-IP with another information device on an IP network, encrypted content transmission using the HTTP protocol, and transmission content processing are performed. An excellent information communication apparatus, information communication method, and computer program that can be suitably executed can be provided.

  In addition, according to the present invention, it is possible to suitably perform a content key confirmation procedure when performing decryption processing of encrypted content using a content key shared through an AKE procedure compliant with DTCP-IP. An excellent information communication apparatus, information communication method, and computer program that can be provided can be provided.

  Further, according to the present invention, when content transmission is performed in conformity with DTCP-IP, a content key confirmation is requested to the source device as a sink device, and a normal response cannot be obtained. Even when the content key confirmation fails, it is possible to provide an excellent information communication apparatus, information communication method, and computer program that can smoothly recover the operation state.

  In content transmission conforming to DTCP-IP, when a sink device sends a CONT_KEY_CONF command, the response of CONT_KEY_CONF may be delayed due to the busy state of the source device or network congestion. Should not affect. According to the present invention, when the sink device receives NOT_IMPLEMENTED from the source device or when a timeout occurs for the response, the sink device does not immediately stop the decryption process of the received content (pseudo). By determining the confirmation, the content key confirmation procedure can be repeatedly performed on the source device. Therefore, even if the sink device is able to confirm that the content key is correct afterward even if the response of the CONT_KEY_CONF response is delayed due to the busy state of the source device or network congestion, the decryption processing of the received content can be performed. Can be continued.

  Further, according to the present invention, the operation of the sink device when the response of the CONT_KEY_CONF response is delayed due to the busy state of the source device or the congestion of the network is processed in the non-configuration state defined by DTCP-IP. Can be realized at low cost.

  Other objects, features, and advantages of the present invention will become apparent from more detailed description based on embodiments of the present invention described later and the accompanying drawings.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  The present invention relates to an information communication system that receives and decrypts encrypted data as a byte stream from a network such as TCP / IP or from a file system. In the information communication system according to the present invention, the content key is dynamically changed in the middle of content transmission in a long byte stream such as a TCP stream between the source device and the sink device, and the sink device is connected to the source device. Then, check the content key appropriately. In this information communication system, a TCP connection is established for each procedure of mutual authentication and key exchange (AKE), content transmission, and content key confirmation. A specific example of such a system is content transmission using an HTTP protocol performed between a DTCP_Source device and a DTCP_Sink device.

A. Content transmission according to the system configuration DTCP-IP is performed by a source device as a server that receives a request for content and transmits the content, and a sink device as a client that requests the content, receives the content, and plays or records the content. Composed. FIG. 1 schematically shows a configuration example of an information communication system according to an embodiment of the present invention.

  In the illustrated example, the DTCP-IP AKE system is constructed by the entities of the source devices A to B, the sink devices A to B, and the relay devices A to C.

  A source device A, which is an authentication server compliant with DTCP-IP, and a sink device A, which is an authentication client compliant with DTCP-IP, are connected by a network via relay device A and relay device B.

  Also, the source device B, which is an authentication server compliant with DTCP-IP, and the sink device B, which is an authentication client compliant with DTCP-IP, are connected via an IP network via the relay device A, the relay device B, and the relay device C. Has been.

  2 and 3 schematically show functional configurations of information communication apparatuses that operate as a client (ie, a sink device) and a server (ie, a source device) in the information communication system shown in FIG. . The sink device and the source device can establish a connection on a TCP / IP network (not shown) such as the Internet, and can use this connection to execute an authentication procedure and a content transmission procedure.

  The sink device shown in FIG. 2 conforms to the DTCP-IP standard and operates as DTCP_Sink. The illustrated client device includes a DTCP-IP authentication block, a DTCP-IP content reception block, and a content playback / recording block as functional blocks.

  The DTCP-IP authentication block includes an AKE block, a message digest generation block, and a content decryption block.

  The AKE block is a block that realizes an AKE mechanism (DTCP_Sink side) in DTCP-IP. This AKE block also has a function of passing parameters requested from a message digest generation block described later.

  The message digest generation block is a block for generating a parameter message digest according to a specified algorithm. An algorithm prepared in advance can be designated as the algorithm for generating the message digest. As an algorithm prepared in advance, for example, an algorithm related to a one-way hash function such as MD5 or SHA-1 can be cited (SHA-1 is equivalent to an improvement of MD4, like MD5, but a 160-bit hash) Since the value is generated, the strength exceeds the MD series).

  The message digest generation block is closely arranged with the AKE block so as to generate a message digest of parameters held by the AKE block that should not be disclosed outside the DTCP-IP authentication block, and requests parameters from the AKE block. The message digest of the parameter or the parameter given from the outside can be created.

  The content decryption block is a block for calculating a content decryption key using a key obtained by exchanging encrypted content data received from the server by AKE and decrypting the encrypted content. The decrypted content is passed to the content playback / recording block.

  The content playback / recording block plays back the passed content in the playback mode and saves it in the recording mode.

  The DTCP-IP content reception block is a processing module that executes a content transmission procedure after performing AKE. In the illustrated example, the DTCP-IP content reception block has an HTTP client block, requests the content from the HTTP server as an HTTP client, and receives the responded content from the HTTP server.

  The HTTP client block is divided into an HTTP request management block and an HTTP response management block. Further, the HTTP request management block is divided into an HTTP request transmission block and an HTTP request generation block.

  The HTTP request generation block generates a content transmission request (HTTP request) to be transmitted. The HTTP request generated here is transmitted to the server by the HTTP request transmission block.

  The HTTP response management block is divided into an HTTP response reception block and an HTTP response interpretation block. The HTTP response returned from the server and the encrypted content are received by the HTTP reception block. The HTTP response received here is checked in the HTTP response interpretation block. If the check here is OK, the received encrypted content is sent to the content decryption block in the DTCP authentication block. If this check is NG, processing as an error response is performed.

  The DTCP-IP authentication block and the DTCP-IP content reception block establish an individual TCP / IP connection with the server device, and execute an authentication procedure and a content transmission procedure independently of each other.

  Also, the Source device shown in FIG. 3 is compliant with the DTCP-IP standard and operates as DTCP_Source. The server device includes a DTCP-IP authentication block, a DTCP-IP content transmission block, and a content management block as functional blocks.

  The DTCP-IP authentication block includes an AKE block, a message digest generation block, and a content encryption block.

  The AKE block is a block that realizes an AKE mechanism (DTCP_Source side) in DTCP-IP. This block also has a function of passing parameters requested from a message digest generation block described later. The AKE block holds information about the authenticated DTCP_Sink device by the number of authenticated devices, and uses it to determine whether the client is an authenticated client when content is requested from the client.

  The message digest generation block is a block for generating a parameter message digest according to a specified algorithm. As an algorithm for generating a message digest, an algorithm prepared in advance can be designated. An algorithm prepared in advance includes, for example, an algorithm related to a one-way hash function such as MD5 and SHA-1.

  The message digest generation block is closely arranged with the AKE block so as to generate a message digest of parameters held by the AKE block that should not be disclosed outside the DTCP-IP authentication block, and requests parameters from the AKE block. The message digest of the parameter or the parameter given from the outside can be created.

  The content encryption block is a block that encrypts content data read from the content management block using a content key generated from a key exchanged by AKE in response to a request of the DTCP-IP content transmission block. The decrypted content is passed to the DTCP-IP content transmission block for transmission to the client.

  The content management block is a block for managing content to be protected using a DTCP-IP mechanism. In response to the reading of the content encryption block, the content data is passed.

  The DTCP-IP content transmission block has an HTTP server block, accepts a request from a client as an HTTP server, and executes processing according to the request.

  The HTTP server block is divided into an HTTP request management block and an HTTP response management block. Further, the HTTP request management block is divided into an HTTP request reception block and an HTTP request interpretation block.

  The HTTP request reception block receives an HTTP request from a client. The received HTTP request is sent to the HTTP request interpretation block and checked. If the check in the HTTP request interpretation block is OK, the HTTP request information is notified to the DTCP-IP authentication block.

  The HTTP response management block is divided into an HTTP response generation block and an HTTP response transmission block.

  When the check in the HTTP request interpretation block is OK, the HTTP response generation block creates an HTTP response for returning the encrypted content. On the other hand, if the check in the HTTP request interpretation block is NG, an HTTP response for returning an error is created.

  The HTTP response transmission block transmits the created HTTP response to the requesting client. If the check in the HTTP request interpretation block is OK, the content encrypted by the content encryption block in the DTCP-IP authentication block is transmitted following the HTTP response header.

  The DTCP-IP authentication block and the DTCP-IP content transmission block establish individual TCP / IP connections with the sink device, and execute the authentication procedure and the content transmission procedure independently of each other.

  Note that the message digest generation block that each DTCP-Sink device and DTCP-Source device has in the DTCP-IP authentication block is not a functional module defined by DTCP-IP itself, and is directly related to the gist of the present invention. do not do. For example, Japanese Patent Application No. 2004-113659 already assigned to the present applicant describes this type of message digest generation block.

B. Content transmission using HTTP Content transmission based on DTCP-IP has already been described, but a review will be given with reference to FIG.

  When content transmission using HTTP protocol is performed between source devices and sink devices compliant with DTCP-IP, encrypted communication is performed while changing the content key in the middle of a long byte stream such as a TCP stream. In addition, a content key confirmation procedure is performed when performing decryption processing of encrypted content and other content processing. A TCP connection is established for each procedure of mutual authentication and key exchange (AKE), content transmission, and content key confirmation.

Specifically, if the AKE procedure is successful, the DTCP_Source device and the DTCP_Sink device can share the authentication key K _auth , and perform the same processing inside each to generate a seed key K that becomes the seed of the content key from K _auth. Generate _x . The source device generates a nonce N _c using a random number, generates a content key K _c based on K _x and N _c , and encrypts the content requested by the sink device using the content key K _c The PCP composed of the encrypted content and the nonce _Nc is placed on the TCP stream and transmitted to the sink device. On the other hand, when the nonce N _c is extracted from the TCP stream, the sink device side can similarly calculate the content key K _c using this and the key K _x obtained from the authentication key K _auth to decrypt the encrypted content. it can.

  In this way, DTCP-IP performs authentication between devices that comply with DTCP, shares a key between devices that have completed DTCP authentication, and performs encryption and decryption when transmitting content, thereby transmitting a transmission path. It is possible to provide a safe content transmission method even on an IP network that prevents content interception and tampering in the middle.

Also, if the same encryption key is used throughout the long TCP stream, the risk of the key being decrypted increases. For this reason, the source device updates the nonce N _c, that is, the content key K _c for every 128 MB of content. Since the decryption key is dynamically changed in the middle of the byte stream, a content key confirmation procedure is required, and the sink device performs a content key confirmation procedure for the source device.

C. Content Key Confirmation Procedure In the content key confirmation procedure, the sink device sends a CONT_KEY_CONF command to which a nonce N _c T for inspection is added to the source device. When receiving the CONT_KEY_CONF command, the source device extracts the nonce N _c T for inspection and compares it with the current nonce N _c . When the current nonce N _c is in the range of N _c T and N _c T + 5, it is confirmed that the inspection nonce N _c T is valid.

  When the source device confirms that the content key is correct, the source device returns an ACCEPTED response indicating the fact to the sink device. When the source device confirms that the content key is invalid, the REJECTED response indicating that fact is returned. Is returned (see FIG. 8).

  On the other hand, the sink device transmits a CONT_KEY_CONF command to the source device that is the content request destination, and then waits for a response from the source device. When the ACCEPTED response is received from the source device, the content key is further confirmed by the sink device itself. If the content key is correct, the confirmed state is entered. If the content key is invalid, the non-confirmed state is set. Become. Further, when the sink device receives a REJECTED response from the source device, the non-configuration state is entered (see FIG. 9).

  When the sink device is non-confirmed, the sink device cannot continue the decryption process, but the content key confirmation procedure can be repeated for one minute after the first non-confirmation. If the content is confirmed within one minute, the decryption process of the received content can be continued.

  As the operation on the source device side in response to the content key confirmation request from the sink device, it is assumed that the response of the CONT_KEY_CONF command is delayed or the NOT_IMPLEMENTED response is returned due to the busy state of the source device or network congestion. However, in DTCP-IP, the coping method of the sink device in cases other than ACCEPTED / REJECTED response is not specified.

  When the sink device has the correct content key, the content key confirmation determination on the sink device side is affected by a response delay or a response that cannot normally be received from the source device, and the received content is decrypted. If it cannot be performed, there is a problem in the operation of the sink device.

  Therefore, in the present embodiment, the sink device does not immediately stop the decryption process of the received content when receiving NOT_IMPLEMENTED from the source device or when a timeout occurs with respect to the response (in a pseudo manner). The content key confirmation procedure is repeatedly performed on the source device by determining -confirmation. Therefore, even if the sink device can confirm that the content key is correct after that even if the response of the CONT_KEY_CONF response is delayed due to the busy state of the source device or network congestion, the decryption processing of the received content can be performed. Can be continued.

  FIG. 4 schematically shows a functional configuration for performing a content key confirmation procedure in a sink device.

The command transmission unit 11 transmits a command to the source device. When requesting confirmation of a content key from the source device, a TCP connection for content key confirmation is established and a CONT_KEY_CONF command including a nonce N _c T for inspection is transmitted.

  In addition, since it is allowed to repeat the content key confirmation procedure for one minute after the first non-configuration, the command transmission unit 11 transmits the CONT_KEY_CONF command again to the source device within this grace period.

  After transmitting a command to the source device, the response standby unit 12 performs a reception operation on the TCP connection and waits for a response from the source device.

  The response receiving unit 13 receives a response from the source device for the transmitted command. When the transmission command is a CONT_KEY_CONF command, an ACCEPTED response indicating that the content key is correct, a REJECTED response indicating that the content key is not correct, and a NOT_IMPLEMENTED response that is not normally possible are assumed as responses from the source device. Is done. The response reception unit 13 interprets which response is received, and notifies the content key confirmation determination unit 15 if the response is an ACCEPTED response. In addition, when a REJECTED response is returned from the source device, a non-configuration state is entered.

  In addition, in DTCP-IP, the handling method of the sink device in cases other than ACCEPTED / REJECTED responses is not specified, but in this embodiment, the response receiving unit 13 receives a NOT_IMPLEMENTED response from the source device. It is trying to be in a state.

  The response time-out detection unit 14 detects a time-out from when a command is transmitted from the command transmission unit to the source device until a response is returned from the source device. For example, a timeout is detected when a response is delayed due to a busy state of a source device or network congestion.

  In DTCP-IP, the countermeasure method on the sink device side when the response of the CONT_KEY_CONF command is delayed is not specified. On the other hand, in the present embodiment, the timeout detection unit 14 for a response is set to a non-confirmation state when the response of the CONT_KEY_CONF command is delayed.

  When notified from the response receiving unit 13 that the ACCEPTED response has been returned from the source device, the content key confirmation determining unit 15 confirms the content key based on whether MAC4A and MAC4B are equal. When the sink device itself can confirm that the content key is correct, the sink device is in a confirmed state, but when the sink device itself fails to confirm the content key, the sink device is in a non-confirmation state.

  When the decryption processing stop unit 16 does not enter the confirmed state for one minute after becoming the first non-configuration, the decryption processing stop unit 16 receives the received content in the content decryption block (see FIG. 2) in the DTCP-IP authentication block. Stop the decryption process.

  FIG. 5 is a flowchart showing a processing procedure for performing a content key confirmation procedure in a sink device having the functional configuration shown in FIG.

  After the command transmission unit 11 transmits a CONT_KEY_CONF command to the source device as the content request destination (step S31), the response standby unit 12 waits for reception of a response from the source device (step S32). Then, until the timeout detection unit 14 for the response detects a timeout (step S43), the response standby unit 12 continues the response standby operation.

  Here, when a response is received from the source device, the response receiving unit 13 determines the type of response (step S33). When the ACCEPTED response is received (step S34), the content key confirmation determination unit 15 is notified to start the content key confirmation determination process (step S35). The content key confirmation determination unit 15 confirms the content key based on whether MAC4A and MAC4B are equal. If the content key is correct, it is confirmed (step S36), and if the content key is illegal, it is non-confirmation (step S38).

  Further, when the response receiving unit 13 receives a REJECTED response from the source device (step S37), it becomes non-configuration (step S38). In the present embodiment, when the response receiving unit 13 receives a NOT_IMPLEMENTED response from the source device (step S37), it becomes non-configuration (step S38).

  Further, in the present embodiment, even when the timeout detection unit 14 for a response detects a timeout after transmitting a CONT_KEY_CONF command to the source device (step S43), non-configuration is performed (step S38).

  In the confirmed state (step S36), the content decryption block in the DTCP-IP authentication block can continue to decrypt the received content. On the other hand, in the non-configuration state (step S38), the sink device cannot continue the decoding process (described above). However, since the sink device can repeat the content key confirmation procedure for one minute after becoming the first non-configuration (step S39), the process returns to step S31 (step S40) and reissues the CONT_KEY_CONF command.

  If the content key confirmation procedure is retried and confirmed within one minute (step S36), the decryption process of the received content can be continued. However, if the non-configuration continues for one minute (step S39), the decryption process of the received content must be stopped immediately (step S41).

  Thus, according to the processing procedure shown in FIG. 5, the sink device not only receives the REJECTED response from the source device, but also immediately receives NOT_IMPLEMENTED or when a timeout occurs for the response. Instead of stopping the decryption process of the received content, it is possible to repeat the content key confirmation procedure for the source device by determining (pseudo) non-confirmation. Therefore, even if the sink device can confirm that the content key is correct after that even if the response of the CONT_KEY_CONF response is delayed due to the busy state of the source device or network congestion, the decryption processing of the received content can be performed. Can be continued.

  The present invention has been described in detail above with reference to specific embodiments. However, it is obvious that those skilled in the art can make modifications and substitutions of the embodiment without departing from the gist of the present invention.

  In this specification, an embodiment in which a TCP connection is established for each procedure of mutual authentication and key exchange (AKE), content transmission, and content key confirmation between information communication devices compliant with DTCP-IP will be described as an example. However, the gist of the present invention is not limited to this. The same applies to other types of information communication systems that establish separate TCP connections for encrypted content transmission and encrypted content decryption key confirmation procedures in the content transmission procedure using the IP protocol. The present invention can be applied to.

  In short, the present invention has been disclosed in the form of exemplification, and the description of the present specification should not be interpreted in a limited manner. In order to determine the gist of the present invention, the claims should be taken into consideration.

FIG. 1 is a diagram schematically showing a configuration example of an information communication system according to an embodiment of the present invention. FIG. 2 is a diagram schematically illustrating a functional configuration of an information communication apparatus that operates as a client (that is, a sink device) in the information communication system illustrated in FIG. FIG. 3 is a diagram schematically illustrating a functional configuration of an information communication apparatus that operates as a server (that is, a source device) in the information communication system illustrated in FIG. 1. FIG. 4 is a diagram schematically showing a functional configuration for performing a content key confirmation procedure in a sink device. FIG. 5 is a flowchart showing a processing procedure for performing a content key confirmation procedure in a sink device having the functional configuration shown in FIG. FIG. 6 is a diagram for explaining a mechanism for performing an AKE-based key exchange procedure between the DTCP_Source device and the DTCP_Sink device, and a mechanism for performing encrypted content transmission using a key shared by the key exchange. FIG. 7 is a diagram illustrating a procedure between a sink device and a source device for content key confirmation. FIG. 8 is a flowchart showing a processing procedure for the source device to perform a content key confirmation procedure with the sink device. FIG. 9 is a flowchart showing a processing procedure for the sink device to perform a content key confirmation procedure with the source device.

Explanation of symbols

DESCRIPTION OF SYMBOLS 11 ... Command transmission part 12 ... Response waiting part 13 ... Response reception part 14 ... Timeout detection part with respect to response 15 ... Content key confirmation part 16 ... Decryption process stop part

Claims (7)

An information communication apparatus for receiving and processing encrypted content transmitted from a source device,
Content receiving means for receiving encrypted content;
Content decrypting means for decrypting the encrypted content using the content key;
Content key confirmation requesting means for requesting confirmation of the content key from the source device;
In response to the response from the source device to the content key confirmation request, the content key confirmation means,
Content decryption processing control means for controlling continuation or stop of the decryption processing operation of the encrypted content by the content decryption means according to the confirmation result by the content key confirmation means;
The content decryption processing control means confirms the content key by the content key confirmation requesting means when a desired response is not obtained from the source device in response to the content key confirmation request or when the response reception waiting period has timed out. Allow requests to be retried for a specified period of time,
An information communication device. When operating as a sink device in DTCP-IP and performing content transmission with a source device using the HTTP protocol,
The content decryption means generates a content key from an authentication key shared through a mutual authentication procedure with the source device and a nonce added to the encrypted content, and decrypts the encrypted content.
The content key confirmation requesting means transmits a content key confirmation request command including the inspection nonce to the source device,
When the content key confirmation means receives the ACCEPTED response from the source device and confirms the content key by itself and determines that it is a correct key, the content key confirmation means outputs a confirmed state and receives the ACCEPTED response from the source device, but confirms the content key by itself. If a REJECTED response is received from the source device, the non-configuration state is output.
The information communication apparatus according to claim 1. In DTCP-IP, the decryption operation of the encrypted content by the content decrypting unit is allowed in the configured state, and the content key confirmation requesting unit by the content key confirmation requesting unit can be retried for a predetermined period in the non-confirmation state. And
The content key confirmation unit outputs a non-configuration state when a desired response is not obtained from the source device in response to the content key confirmation request, or when a response reception waiting period times out.
The information communication apparatus according to claim 2. An information communication method for receiving and processing encrypted content transmitted from a source device,
A content receiving step for receiving encrypted content;
A content decrypting step for decrypting the encrypted content using the content key;
A content key confirmation requesting step for requesting the source device to confirm a content key;
In response to a response from the source device to the content key confirmation request, a content key confirmation step;
A content decryption processing control step for controlling continuation or stop of the decryption processing operation of the encrypted content by the content decryption means according to the confirmation result in the content key confirmation step;
In the content decryption process control step, when a desired response is not obtained from the source device in response to the content key confirmation request, or when the response reception waiting period has timed out, the content key confirmation by the content key confirmation request unit is performed. Allow requests to be retried for a specified period of time,
An information communication method characterized by the above. When operating as a sink device in DTCP-IP and performing content transmission with a source device using the HTTP protocol,
In the content decrypting step, a content key is generated from an authentication key shared through a mutual authentication procedure with the source device and a nonce added to the encrypted content, and the encrypted content is decrypted.
In the content key confirmation request step, a content key confirmation request command including the inspection nonce is transmitted to the source device,
In the content key confirmation step, when the ACCEPTED response is received from the source device and the content key is confirmed by itself to determine that it is the correct key, a confirmed state is output, and the ACCEPTED response is received from the source device, but the content key is confirmed by itself. If a REJECTED response is received from the source device, the non-configuration state is output.
The information communication method according to claim 4. 6
In DTCP-IP, in the confirmed state, the decryption operation of the encrypted content by the content decryption step is allowed to continue, and in the non-configuration state, the content key confirmation request by the content key confirmation request step can be retried only for a predetermined period. And
In the content key confirmation step, when a desired response is not obtained from the source device in response to the content key confirmation request, or when a response reception standby period times out, a non-configuration state is output.
The information communication method according to claim 5. A computer program written in a computer-readable format so as to execute reception processing of encrypted content transmitted from a source device on the computer system,
A content receiving procedure for receiving encrypted content;
A content decryption procedure for decrypting the encrypted content using the content key;
A content key confirmation requesting procedure for requesting confirmation of a content key from the source device;
In response to a response from the source device to the content key confirmation request, a content key confirmation procedure;
Executing a content decryption process control procedure for controlling the continuation or stop of the decryption process operation of the encrypted content according to the content decryption procedure according to the confirmation result in the content key confirmation procedure;
In the content decryption process control procedure, when a desired response is not obtained from the source device in response to the content key confirmation request, or when the response reception waiting period times out, the content key confirmation by the content key confirmation request procedure is performed. Allow requests to be retried for a specified period of time,
A computer program characterized by the above.

Images