JP4883199B2 - Content transmission system, content transmission device, content transmission method, and computer program - Google Patents

Description

  The present invention relates to a content transmission system, a content transmission apparatus, a content transmission method, and a computer program for transmitting content such as digitized AV data between devices, and in particular, copying for copyright protection and other purposes. The present invention relates to a content transmission system, a content transmission apparatus, a content transmission method, and a computer program for encrypting and transmitting restricted content between devices.

  More particularly, the present invention relates to a content transmission system, a content transmission apparatus and a content transmission method, and a computer program that execute a transmission procedure of encrypted content between information devices compliant with DTCP, and in particular, a DTCP MOVE function. The present invention relates to a content transmission system, a content transmission apparatus, a content transmission method, and a computer program, which are used to move content from a source to a sink.

  With the spread of information technology, most of AV contents are digitized, and media for recording / reproducing digital contents such as CDs and DVDs are widely used. In recent years, devices that digitally record content such as HDD recorders and HDD-equipped DVD recorders have become popular in the home. Furthermore, content distribution / distribution services such as video and music via the network have become popular, and content distribution is performed between remote terminals via the network without moving media such as CDs and DVDs.

  However, since digitized content is relatively easy to perform illegal operations such as copying and falsification, it is necessary to protect against unauthorized use while allowing the use of personal or household content. In particular, the replacement of analog broadcast receivers with digital broadcast receivers is rapidly progressing toward the terrestrial analog broadcast stoppage in 2011, and technology to protect content against the digitization of AV content in the home. Realization is considered essential.

  In Japan, ARIB (Association of Radio Industries and Businesses) is standardizing digital broadcasting, and MPEG2 systems (for example, non-patented) are used in digital satellite broadcasting, digital terrestrial broadcasting, and digital CATV. (See Document 1) and requires the introduction of a copy control function such as “Copying only one generation” (copy once), and provides strict content protection regulations (for example, Non-Patent Document 2, Non-Patent Document) 3).

  In addition, DTCP (Digital Transmission Content Protection) developed by DTLA (Digital Transmission Licensing Administrator) is an industry standard technology for protecting digital transmission content, and content is protected in the form of copyright protection including copy control. A mechanism for transmission is defined (for example, see Non-Patent Document 4).

  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.

  The server (Source) that is the content provider and the client (Sink) that is the content provider share the key through the authentication procedure by transmitting and receiving the AKE command, encrypt the transmission path using the key, and transmit the content To do. Therefore, an unauthorized client cannot obtain the content because the encryption key cannot be acquired unless the authentication with the server is successful.

  DTCP originally specified transmission of digital contents on a home network using IEEE 1394 or the like as a transmission path. Recently, as represented by DLNA (Digital Living Network Alliance), the movement to distribute digitized AV content via the IP network has become serious in the home. Development of DTCP technology corresponding to the above, ie, DTCP-IP (DTCP mapping to IP) is underway.

  DTCP-IP is a similar technology in which the DTCP technology is transplanted to an IP network. However, the IP network is used as a transmission path, and HTTP (Hyper Text Transfer Protocol) or RTP (Real--) is used for transmission of encrypted content. It differs from the original DTCP defined on the basis of IEEE 1394 in that it uses a content transmission protocol implemented on an IP network, such as Time Transfer Protocol. For example, when content is transmitted according to the HTTP procedure, Source is an HTTP server, Sink is an HTTP client, a TCP / IP connection for HTTP is created, and encrypted content is downloaded and transmitted (upload transmission). When performing the process, the source becomes an HTTP client and the sink becomes an HTTP server).

  If the home network is connected to an external IP network such as the Internet via a router, there is a risk of data eavesdropping, falsification, and unauthorized copying of content. In addition, unauthorized use of content can be easily performed by installing an unauthorized proxy composed of a personal computer or the like on the transmission path between the source and sink. For this reason, in DTCP-IP, by setting an upper limit on the TTL (Time To Live) of the AKE command, that is, the number of hops of the IP router, the content usage range is limited to a personal range or a home range. However, a further method for network transmission is defined (for example, see Non-Patent Document 5).

  When performing content transmission corresponding to copyright protection, it is necessary to specify content attributes relating to content protection. In DTCP-IP, copy control information associated with content is provided by two mechanisms: E-EMI (Extended Encryption Mode Indicator) and Embedded CCI (Copy Control Information) described in the header of a packet (PCP) for content transmission. Has been realized.

  The Embedded CCI is copy control information that is transmitted as a part of a content stream to be encrypted (that is, embedded in a packet payload). When the content stream is tampered, erroneous decryption is performed, so that the integrity of the Embedded CCI can be guaranteed. One E-EMI is described in the plaintext header, and indicates copy control information related to the content stream in the packet header, thereby enabling easy access and security. The E-EMI is composed of a 4-bit field describing the encryption mode, and its value corresponds to seven types of copy control information. The bit value definition is shown in the table below. However, the nine unused E-EMI values in the table are reserved for future expansion.

  The device operating as the source selects the correct encryption mode according to the characteristics of the content stream, and sets E-EMI based on this. On the other hand, a device operating as a sink selects a correct decryption mode specified by E-EMI in a header of a packet transmitting content. Also, a device operating as a sink encodes received content and temporarily stores it, as specified by E-EMI or Embedded CCI, and subsequently performs secondary content transmission according to copy control information when operating as a source. Control the behavior. The types of copy control include the following.

Copy Free: The copyright itself is reserved, but copy control using DTCP is not performed.
Copy Never: Never copy content.
Copy One Generation: Copying is allowed only once (One Generation).
No More Copies: No longer allowed to copy.

  Among the above, No More Copies is a state in which copying is no longer permitted because the content originally set in Copy One Generation is copied only once (first generation). In DTCP-IP, a MOVE function is prepared as means for transmitting content encoded as No More Copies (see, for example, Non-Patent Document 5 and Non-Patent Document 6). MOVE in network communication corresponds to moving data between devices, and basically does not leave data at the source. The MOVE function in DTCP-IP is encrypted under the condition that the Sink encodes the received content as No More Copies, and the source side erases or disables the content after transmission. This means that the content is transmitted from the source to the sink. For example, when the content of Copy One Generation is encoded and recorded as No More Copies in a source such as a personal video recording device (PVR), Copy One Generation is satisfied while satisfying the above conditions by using the MOVE function. Can be encoded and transmitted to a single sink. Also, MOVE is allowed only between a single source and a single sink.

  According to the current regulations, MOVE transmission can be performed using either the C1 mode or the B1 mode by E-EMI. On the sink side, the content received in these modes can be decrypted and recorded using the key acquired in the AKE procedure. On the source side, it is necessary to invalidate data at the moment of transmission.

  According to the MOVE function, the number of moved content entities does not increase as in the case of moving a tangible object from one place to another. In other words, it is necessary to ensure that the content to be transmitted does not exist (or cannot be used) at the same time in the source and the sink. Therefore, when the content from the source to the sink is composed of a plurality of message transfer procedures, the condition that the content is erased or made unavailable on the source side as described above is consistently observed throughout all the message transfer procedures. There must be. For this reason, as a content transmission method, it is necessary to perform “INCREMENTAL MOVE” in which data after transmission is sequentially disabled on the source side and reception data is sequentially enabled on the sink side. .

  For example, the content is divided into a plurality of areas, each is encrypted with a different title key, a time-varying key used for content decryption is extracted, and the original title key in the title key area is extracted There has been proposed a content management apparatus that deletes the original content that has been subjected to the move process by overwriting sequentially with a time-varying key to make it impossible to decrypt the previous content (for example, Patent Documents). 1).

  Here, when the INCREMENTAL MOVE sequence performed between the source and the sink is interrupted due to a failure or the like during content transmission, there is a problem that the content is divided into the source and the sink. If the entire content is successfully transmitted, the content right can be safely transferred between the source and the sink. However, if a failure occurs during the transmission process, the data portion that has been transmitted exists on the sink side. However, since the data part before transmission remains in the source, the content is divided. As a failure that may occur during processing of INCREMENTAL MOVE, for example, a connection error occurs, the power of one device is shut off, the content storage medium is removed (or the storage fails), the content on the Sink side For example, it is not rare that the content is divided.

  When movement of one content is performed by a plurality of message transfer procedures, each time the source performs message transfer, if the data portion that has moved to the sink side is sequentially deleted, when content transmission is interrupted, The content cannot be recovered by any of the sinks. If content on the source side is erased or made unavailable after the content transmission from the source to the sink is completed, the user does not have to worry about losing the content. However, it does not consistently comply with the preconditions (mentioned above) for executing MOVE defined in DTCP-IP, which may endanger the copyright protection of the content.

  For example, a content movement controller is provided between a source and a sink that perform content transmission via a general-purpose bus, and the amount of reproducible content existing in both the source and the sink during the move transmission is 1 as the normal playback time. Based on the DTCP standard that must not exceed minutes, if the content movement controller detects a failure in either the source or the sink, the move is interrupted within one minute, and the movement operation is performed in the portion that remains in the source reproducible state. A content moving system that avoids loss of content by resuming is proposed (for example, see Patent Document 2). However, in this case, since the content movement controller must be interposed, the apparatus cost increases. In addition, when any DTCP-IP device operates as a source and a sink on a wireless LAN, and a content move process is activated ad hoc between these sources and sinks, it becomes difficult to arrange the content movement controller, or The intervention of the content movement controller becomes a bottleneck of the transmission sequence.

  In addition, by erasing the content that has already been sent based on the recording status information of the content returned from the sink that has received the content, the loss on the source side when the sink cannot record the content normally is prevented. Proposals have been made on content recording systems (see, for example, Patent Document 3). However, in this system, no consideration is given to the situation where the content is divided between the source and the sink due to the interruption of content transmission.

  In addition, when moving copyright-protected data to another recording device, the copy data is encrypted and held with a unique copy encryption key. In this case, the data after moving is invalidated, and the device proposes a device that handles content data that protects the copyright while protecting the copyright by restoring the original data from the copied data. (For example, refer to Patent Document 4). However, in the same device, the original data is erased after the data is recorded at the destination, or the original data is erased in parallel with the recording of the data at the destination. The situation where the content is divided between the source and the sink is not fully considered.

JP 2003-101529 A Japanese Patent Laid-Open No. 2005-158056 JP 2005-293731 A JP 2005-250567 A

ISO / IEC 13818-1 GENERIC CODING OF MOVING PICTURESAND ASSOCIATED AUDIO: SYSTEMS RECOMMENDATION H. 222.0 ARIB TR-B14 Digital Terrestrial Television Broadcasting Operation Regulations ARIB TR-B15 BS / broadband CS digital broadcasting operation rules DTCP Specification Volume 1 (Informational Version) Revision 1.4 (http://www.dcp.com/) DTCP Volume 1 Supplement E (V1SE) Mapping DTCP to IP (Information Version) Revision 1.1 (http://www.dcp.com/) DIGITAL TRANSMISSION PROTECTION LICENSE AGREEMENT, Adapter Agreement-May 2005

  An object of the present invention is to provide an excellent content transmission system, content transmission apparatus and content transmission method, and computer program capable of suitably executing an encrypted content transmission procedure between information devices compliant with DTCP. There is.

  A further object of the present invention is to provide an excellent content transmission system, content transmission device and content transmission method, and computer program capable of suitably moving content from a source to a sink using the MOVE function. .

  A further object of the present invention is to prevent the content from being divided or missing even if a failure occurs in the transmission path during content transmission, so that the MOVE processing of the content can be performed reliably. Another object of the present invention is to provide a content transmission system, a content transmission apparatus, a content transmission method, and a computer program.

The present invention has been made in consideration of the above problems, and a first aspect thereof is a content transmission system for transmitting content between a source that transmits content and a sink that receives content,
Content specifying means for specifying content to be transmitted between the source and the sink;
An authentication means for performing mutual authentication and key exchange between the source and the sink;
Content transmission means for encrypting and transmitting the content designated by the content designation means from the source to the sink using the key exchanged by the authentication means;
In response to the completion of the transmission processing by the content transmission means, the content transmission end processing means for validating the content on the sink side and invalidating the original content on the source side,
A content transmission system that moves content from a source to a sink.

  However, “system” here refers to a logical collection of a plurality of devices (or functional modules that realize specific functions), and each device or functional module is in a single housing. It does not matter whether or not (hereinafter the same).

  The present invention relates to a content transmission system for transmitting information content that requires copyright protection on an IP network. Specifically, mutual authentication and a key are performed between information communication devices compliant with DTCP-IP. The present invention relates to a content transmission system that securely transmits encrypted content using a key shared through exchange.

  In DTCP, a mechanism for transmitting content in a form in which copyright is protected including copy control is defined. As a form of content transmission, there are a method of copying the content on the source to the sink, and a method of moving the content from the source to the sink and leaving no content on the source, that is, move. In DTCP, Sink is encoded as No More Copy on the condition that the received content is encoded and handled as No More Copies, and the transmitted content is erased or made unusable on the Source side. A move function for transmitting the contents is provided.

  According to the MOVE function, the user can enjoy contents that cannot be copied by moving them to another device. Similarly to moving a tangible object from one place to another, there is no problem in content protection because the number of moved content entities does not increase.

  On the MOVE transmission sequence, the condition that the content is erased or made unavailable on the source side must be consistently observed. For this reason, it is necessary to perform “INCREMENTAL MOVE” in which data after transmission is sequentially disabled on the source side and reception data is sequentially enabled on the sink side. However, if the MOVE sequence is interrupted due to a failure in the transmission path or other causes, the content is divided between the source and sink or missing, and the user loses the originally acquired content. Will end up.

  On the other hand, in the content transmission system according to the present invention, the Sink sequentially records the contents being moved in the recording medium on the recording medium, but the recorded contents are not usable until the completion of the move transmission. Thereafter, when confirmation of content transmission end processing, that is, commitment, is performed, the recorded content on the sink side is made available and usable, and at the same time, the original content is erased or made unavailable on the source side. As a result, No More Copies content does not exist in the source and sink during the MOVE transmission, and even if the MOVE transmission is interrupted due to a failure in the transmission path, the content is not divided. , Content transmission can be restarted from the source.

  MOVE transmission by such a content transmission method is equivalent to moving the entire content between the source and sink in a batch. Unlike INCREMENTEL MOVE, in which data after transmission is sequentially disabled on the source side and received data is sequentially enabled on the sink side, it can also be referred to as “BLOCK MOVE”. BLOCK MOVE is also a MOVE process for content that satisfies the conditions defined by DTCP, because the same content does not exist twice in Source and Sink on the transmission sequence.

  In addition, the sink cannot reproduce the recorded content until the move finish process is successful, but the received content is reproduced and output (rendered) in parallel with the operation of recording with the received content invalidated. It is also possible to configure so as to. This is because, if BLOCK MOVE is a MOVE process that satisfies the conditions defined by DTCP, decoding and outputting content in parallel with BLOCK MOVE is equivalent to streaming content. That is, since data is lost with the output of the decrypted content, it does not correspond to a copy of the content, and it does not conflict with the DTCP standard that there should be no reproducible content existing in both the source and sink.

  In this case, on the sink side, once the received content is decoded, the specified encoding processing is performed as No More Copies, and this decoded content is stored in parallel with being stored on a hard disk or other recording medium. The video and audio signals are converted (rendered) as they are, and video and audio are output from an AV output unit such as a display. The user can check the content during the MOVE transmission and enjoy viewing the content in real time.

  Also, during the MOVE processing procedure, the source locks the content to be moved so that it cannot make a MOVE request from another sink. This is because, if the same content is multiplexed and moved to a plurality of sinks, the number of content entities increases, that is, the copy is effectively made, and the copy control information of No More Copies is broken. .

  INCREMENTAL MOVE can be implemented by MOVE transmission negotiated by DTCP-IP. On the other hand, BLOCK MOVE is not included in the DTCP specification at the time of application (January 11, 2006) of Japanese Patent Application No. 2006-4129, which is the basic application of the present application. Therefore, when performing the BLOCK MOVE, the authentication means also prevents the spoofing of the MOVE transmission, whether or not each device is compatible with the BLOCK MOVE, together with performing the authentication process between the Source and the Sink. It is preferable. Further, if either one of the devices does not support BLOCK MOVE, the mode may be switched to the conventional INCREMENT MOVE to perform the content move process.

  In the content transmission system according to the present invention, it is possible to use a CDS (Content Directory Service) defined by UPnP (registered trademark) in order to designate content to be moved. Further, the authentication procedure between the source and sink, the content transmission procedure, and the content transmission end processing procedure performed thereafter can be performed in accordance with DTCP-IP.

  For example, the user can operate the sink and move the content in a format in which the content is downloaded from a source that operates as a server that provides the content.

  In this case, in the sink, based on the information included in the CDS :: Browse response from the Source for the CDS :: Browse request, the socket information for authentication and key exchange of the content to be moved is acquired and the content is moved from the Source. It can be confirmed whether or not it is possible.

  Then, the sink can acquire the encrypted content from the source using the HTTP GET method including the header information indicating that the content is moved in the header.

  Alternatively, the user can operate the source and move the content in a form of uploading the content to the sink that operates as a server that provides the content.

  In this case, the Source can request the sink to create a moving location of the content using CDS :: CreateObject request.

  At this time, because the authentication process is started from the sink, the source needs to notify the sink of socket information in order to establish a TCP connection for authentication and key exchange from the sink side. For example, by including a property with socket information in the CDS :: CreateObject request, the socket information for authentication and key exchange may be notified to the sink. Alternatively, the source may notify socket information for authentication and key exchange to the sink using header information included in the HTTP POST method (not including content).

  Then, the source can include the header information indicating that the content is moved in the header, and upload and transmit the encrypted content to the sink using the HTTP POST method.

  In addition, between the source and the sink, it is assumed that a key dedicated to content movement is exchanged for each content to be moved by an AKE procedure. When the source receives a GET request from the sink that will transmit the content to be moved multiple times, the source rejects the request and completes the move transmission process and at the same time promptly invalidates the content that has been transferred. This prevents the same content from being moved (ie, substantially copied) multiple times.

  In addition, while moving a content to a certain sink, the source moves (that is, substantially copies) the same content to a plurality of sinks by refusing a request to move the content from another sink. So that there is no.

  Also, in response to the completion of the content move transmission and the completion of the content transmission end processing, the exchange key dedicated to content movement in the source and sink is extinguished. In other words, the TCP connection established for the AKE procedure is maintained until the content transmission end processing ends.

  In such a case, the content transmission process can be canceled using the TCP connection established for the AKE procedure until the content transmission process is completed. The content transmission cancellation process is activated in response to a request from at least one of Sink and Source. When canceling the content transmission process, the content transmitted to the sink is invalidated.

  In addition, when the communication between the sink and the source is interrupted until the content transmission process ends, the content transmission process can be stopped by a request from at least one of the sink and the source. The behavior of Source and Sink when canceling is the same as when canceling content transmission.

  In the content transmission system according to the present invention, the content transmission end process for confirming that the content transmission has been successfully completed between the sink and the source, that is, taking the commitment, is performed, the content on the sink side is validated, and the source The content movement is completed by invalidating the original content on the side. In the content transmission end process, first, a first command indicating the end of content reception is transmitted from the sink, and in response to this command, the source sets the original content on the source side to an intermediate invalid state. Subsequently, when a first response to the first command is returned from the source, the sink validates the content transmitted to the sink side in response to this response and is dedicated to the content movement held on the sink side. Make the key disappear. When the second command indicating content validation is sent from the sink, the source responds to this command by invalidating the original content on the source side and dedicated to content movement held on the source side. Make the key disappear.

  In addition, the content transmission end processing means is interrupted due to the power-off of one of the devices despite the successful content transmission from the source to the sink by the content transmission means. The transmission system may further include a content transmission end process restarting unit for restarting the interrupted content transmission end process. By this restarting means, the content transmission procedure is not wasted, and it is possible to avoid invalidating the content in both the sink and the source.

  This content transmission end process resuming means still holds the information sent by the source using the exchange key dedicated to content movement or the first response when the source receives the first command indicating the end of content reception from the sink. In this case, the content transmission end procedure can be restarted by setting the original content on the source side to an intermediate invalid state and causing the sink to return a first response to the first command from the source.

  Alternatively, the content transmission end process resumption means still holds information sent by the source using the exchange key dedicated to content movement or the first response when the source receives the second command indicating the end of content reception from the sink. If there is, the original content on the source side is invalidated, the content transfer key held on the source side or the information sent in the first response disappears, and the second command for the second command is sent from the source to the sink. The content transmission end procedure can be resumed by returning the response of.

  Alternatively, the content transmission end process resuming means establishes a connection with the source that is the content transfer source if the sink still holds the information to be sent by the exchange key dedicated to the content transfer or the first command. If the content to be processed is invalid on the sink side, the first command is sent to the source, and if the corresponding content has already been validated on the sink side, the second command is sent to end content transmission. Processing can be resumed.

  At this time, in order to establish a TCP connection for authentication and key exchange from the sink side, the source needs to notify the sink of socket information. When the content transmission is performed in the download format, the sink sends a CDS :: Browse request to the source, acquires socket information based on the information included in the CDS :: Browse response from the source. A TCP connection for resuming the content transmission end process can be established. When the content transmission is performed in the upload format, the socket information is notified to the sink using the header information of the HTTP POST method (not including the content) in the source, and the sink is based on the socket information. A TCP connection for resuming the transmission end process can be established.

  In addition, in DTCP-IP, tampering of communication contents is easily performed by installing an unauthorized proxy composed of a personal computer or the like on a transmission path between a source and a sink. In particular, in a system in which BLOCK MOVE is started after confirming the capability related to the MOVE method between the source and the sink by the authentication means, even though the source corresponds to the BLOCK MOVE, the proxy is the BLOCK MOVE. If it is not compatible with MOVE, Sink can be false and Sink can perform INCREMENTAL MOVE. In this case, the sink side sequentially activates the data every time it receives data from the source, and the proxy cancels the content transmission process for the source when the content transmission process is completed, so that the source and sink There is a situation that conflicts with the DTCP-IP regulations that valid contents exist in both.

  Therefore, the content transmission system according to the present invention further includes a spoofing prevention unit that prevents the capability confirmed between the source and the sink from being misrepresented, or preventing the sink-side move mode from being spoofed by other means. It is preferable to keep it.

  For example, the spoofing prevention means changes the method for generating the content encryption key from the key exchanged by the authentication means for each content transmission method, that is, between INCREMENTAL MOVE and BLOCK MOVE. In such a case, the sink that performs INCREMENTAL MOVE by misrepresentation cannot share the content encryption key with the source that performs BLOCK MOVE, and the content is not validated. Therefore, there is no double content between the source and the sink.

  Alternatively, the spoofing prevention means may change the method of scrambling the key exchanged by the authentication means for each content transmission method, that is, between INCREMENTAL MOVE and BLOCK MOVE. In such a case, the sink that performs INCREMENTAL MOVE by misrepresentation cannot descramble the key exchanged by the authentication means and cannot obtain the correct content encryption key. Therefore, there is no double content between the source and the sink.

  Alternatively, the spoofing prevention means may include information on the content transmission method in a communication message protected by an electronic signature from Sink to Source in a challenge / response procedure for mutual authentication and key exchange. When Sink starts to perform INCREMENTAL MOVE due to misrepresentation, even if the source tries to perform BLOCK MOVE according to the capability confirmation, it is possible to detect that it has been misrepresented in the challenge-response procedure. The Source can take measures such as stopping the MOVE transmission itself or switching to INCREMENTAL MOVE according to the sink side.

According to a second aspect of the present invention, there is provided a computer program written in a computer-readable format so that a process for transmitting content as a DTCP Source is executed on a computer system. In contrast,
A content specification procedure for specifying content to be transmitted to and from the sink;
An authentication procedure for mutual authentication and key exchange with Sink by the AKE procedure;
A content transmission procedure for encrypting and transmitting the content designated in the content designation procedure to the sink using the key exchanged in the authentication procedure;
In response to the end of the content transmission process in the content transmission procedure, the content transmission end processing procedure for invalidating the original content is executed,
A computer program characterized by moving content to a sink.

According to a third aspect of the present invention, there is provided a computer program written in a computer-readable format so as to execute a process for receiving content as a DTCP Sink on the computer system. In contrast,
A content specifying procedure for specifying content to be transmitted to and from the source;
An authentication procedure for mutual authentication and key exchange with the Source by the AKE procedure;
A content transmission procedure for encrypting and transmitting the content designated in the content designation procedure from the source using the key exchanged in the authentication procedure;
In response to the end of the content transmission process in the content transmission procedure, a content transmission end processing step for validating the received content is executed.
A computer program characterized in that content is moved from a source.

  The computer program according to each of the second to third aspects of the present invention defines a computer program written 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 each of the second to third aspects of the present invention in the computer system, a cooperative action is exhibited on the computer system, and each of the first aspects of the present invention. It operates as Source and Sink in the content transmission system according to the above. By activating such a content transmission apparatus and constructing a network based on DTCP, it is possible to obtain the same operational effects as those of the content transmission system according to the first aspect of the present invention.

  According to the present invention, there are provided an excellent content transmission system, content transmission apparatus and content transmission method, and computer program capable of suitably executing a transmission procedure of encrypted content between information devices compliant with DTCP. be able to.

  Furthermore, according to the present invention, it is possible to provide an excellent content transmission system, content transmission apparatus and content transmission method, and computer program capable of suitably moving content from a source to a sink using the MOVE function. it can.

  Further, according to the present invention, even if a failure occurs in the transmission path during content transmission, the content is prevented from being divided or lost, and the content MOVE processing can be performed reliably. An excellent content transmission system, content transmission device, content transmission method, and computer program can be provided.

  The content transmission system according to the present invention is capable of BLOCK MOVE, which is equivalent to moving the entire content between the source and the sink collectively in accordance with the conditions defined by DTCP.

  BLOCK MOVE is realized by a content transmission end process that validates the content on the sink side and invalidates the original content on the source side in response to the end of the content transmission process. Although there is a risk that the content transmission end process is interrupted due to the power of one of the devices being cut off or the like, according to the content transmission system of the present invention, the content transmission end process is resumed and the MOVE process is performed. It can be terminated correctly.

  Also, when BLOCK MOVE is performed, an illegal proxy is interposed between the source and the sink, and for example, the transmission on the side of the sink is spoofed or the MOVE transmission is impersonated by other methods, and the copy transmission is performed. There is a risk that there is a double. On the other hand, according to the content transmission system of the present invention, the spoofing prevention means can prevent the Sink-side MOVE mode from being spoofed by spoofing the capabilities confirmed between the source and the sink.

  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.

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 illustrating a functional configuration of an information communication apparatus that operates as a client (that is, a sink) in the information communication system illustrated in FIG. FIG. 3 is a diagram illustrating a functional configuration of an information communication apparatus that operates as a server (that is, a source) in the information communication system illustrated in FIG. 1. FIG. 4 is a diagram for explaining a mechanism for performing an AKE-based key exchange procedure between a source and a sink and an encrypted content transmission using a key shared by the key exchange. FIG. 5 is a diagram schematically showing the data structure of PCP. FIG. 6 is a diagram illustrating a state where padding is performed on the PCP payload. FIG. 7 is a diagram showing a configuration example of a sink for performing a content move process and a received content reproduction process in parallel. FIG. 8 is a diagram showing an operation sequence in the case of performing MOVE transmission between Source and Sink in a download format. FIG. 9 shows an operation sequence for selecting a content to be moved between Sink and Source using CDS based on UPnP (registered trademark) when performing MOVE transmission between Source and Sink in a download format. FIG. FIG. 10 is a diagram showing an operation sequence of the move AKE procedure. FIG. 11 is a diagram illustrating an operation sequence for executing the move end processing procedure between the source and the sink. FIG. 12 is a diagram showing an operation sequence when performing a MOVE transmission between the source and the sink in the upload format. FIG. 13 is a diagram showing an operation sequence for notifying the upload of content from the source to the sink using CDS on the basis of UPnP (registered trademark) when performing the MOVE transmission between the source and the sink in the upload format. It is. FIG. 14A is a flowchart showing processing operations executed by the source and sink when moving content from the source to the sink in the download format. FIG. 14B is a flowchart illustrating processing operations executed by the source and sink when the content is downloaded and transferred from the source serving as the HTTP server to the sink serving as the HTTP client. FIG. 15A is a flowchart showing processing operations executed by the source and sink when moving content from the source to the sink in the upload format. FIG. 15B is a flowchart illustrating processing operations executed by the source and sink when moving content from the source to the sink in the upload format. FIG. 16 is a diagram illustrating an example of an operation sequence of the move AKE procedure including a capability confirmation sequence. FIG. 17 is a diagram showing in detail the part of the capability exchange procedure in FIG. FIG. 18 is a diagram specifically showing the contents of processing performed by Sink and Source on the download move transmission end sequence shown in FIG. FIG. 19 is a flowchart showing a processing procedure for resuming the interrupted download move transmission end process in the source operating as the HTTP server. FIG. 20 is a flowchart showing a processing procedure for resuming the interrupted download move transmission end process in the source operating as the HTTP server. FIG. 21 is a flowchart showing a processing procedure for resuming an interrupted download MOVE transmission process in a sink operating as an HTTP client. FIG. 22 is a diagram illustrating an example of an operation sequence in which a move mode spoofing attack is applied to a sink. FIG. 23 is a diagram illustrating an example of an operation sequence in which a countermeasure is taken against the move mode spoofing attack. FIG. 24 is a diagram showing an example of an operation sequence in which a countermeasure is taken against the move mode spoofing attack. FIG. 25 is a diagram showing an example of an operation sequence in which a countermeasure is taken against the move mode spoofing attack. FIG. 26 is a diagram illustrating an example of an operation sequence in which a countermeasure is taken against the move mode spoofing attack. FIG. 27 is a diagram illustrating another example of an operation sequence of the move AKE procedure. FIG. 28 is a diagram illustrating an example of an operation sequence in which Sink requests content using an HTTP GET request, and Source performs content transmission using an HTTP GET response. FIG. 29 is a flowchart showing a processing procedure for establishing a TCP connection between a sink and a source when resuming an interrupted move transmission end process in a download-type move sequence. FIG. 30 is a diagram showing an operation sequence for performing upload move transmission between the source and the sink (however, when the source uses the POST request to notify the socket information). FIG. 31 is a diagram showing an operation sequence for performing an upload move transmission between a source and a sink (however, in response to a POST request with socket information transmitted from the source, the sink sends a POST response after the AKE procedure is completed. And then the content is transmitted as a message body for the POST request). FIG. 32A is a flowchart illustrating processing operations executed by the source and sink when uploading and moving content from the source to the sink, respectively. FIG. 32B is a flowchart illustrating processing operations executed by the source and sink when uploading and moving content from the source to the sink, respectively. FIG. 33 is a flowchart showing a processing procedure for establishing a TCP connection between a sink and a source when resuming an interrupted move transmission end process in the upload-type move sequence.

  The present invention relates to a content transmission system that encrypts and transmits information content that needs to be protected for copyright and other purposes in accordance with predetermined copy control information. A specific example of such a system is content transmission using an HTTP protocol performed between DTCP-IP devices. Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

A. System configuration Content transmission according to DTCP-IP is composed of a source for transmitting content and a sink for receiving and reproducing or recording the content. As a content transmission method, a source that operates as a server transmits content in response to a request from a sink that operates as a client, and transmits content to a sink that operates as a server in response to a request from a sink that operates as a client. Upload transfer to be considered.

  FIG. 1 schematically shows a configuration example of an information communication system according to an embodiment of the present invention. In the example shown in the figure, a DTCP-IP AKE system is constructed by each device of Source and Sink. A source, which is an authentication server compliant with DTCP-IP, and a sink, an authentication client compliant with DTCP-IP, are connected via a network. The network referred to here includes Ethernet (registered trademark), the Internet, and other IP networks.

  2 and 3 schematically show functional configurations of the content transmission system operating as a sink and a source in the content transmission system shown in FIG. 1, particularly focusing on authentication and content transmission. However, FIGS. 2 and 3 show a functional configuration when a source operating as a server downloads and transfers content in response to a request from a sink operating as a client. Description is omitted. Sink and Source can establish a connection on a TCP / IP network such as the Internet, and can use this connection to execute an authentication procedure and a content transmission procedure.

  The sink shown in FIG. 2 includes a DTCP-IP authentication block 10, a DTCP-IP content reception block 20, and a content playback / recording block 30, which operates as an HTTP client and is downloaded and transferred from a source operating as an HTTP server. Receive content.

  The DTCP-IP authentication block 10 includes an AKE block 11, a message digest generation block 12, and a content decryption block 13. The DTCP-IP authentication block 10 more preferably has tamper resistance.

  The AKE block 11 is a block that realizes an AKE mechanism (Sink side) in DTCP-IP. The AKE block 11 also has a function of passing parameters requested from a message digest generation block described later. The AKE block 11 may define a move-specific AKE procedure separately from the AKE when performing a normal content transmission procedure such as copying, and may prevent the spoofing of the move mode by changing the scramble method or the like. .

  The message digest generation block 12 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 12 is closely arranged with the AKE block 11 so as to generate a message digest of parameters held by the AKE block 11 that should not be disclosed outside the DTCP-IP authentication block 10. It is possible to request and obtain parameters, and a message digest of the parameters or parameters given from the outside can be created.

Content decrypting block 13 calculates a decryption key K _c of content using the key K _x was replaced with AKE, a block to be decoded by the decryption key K _c the encrypted content received from the Source. The decrypted content is passed to the content playback / recording block. The same applies when the AKE procedure dedicated to MOVE is defined.

  The content playback / recording block 30 plays back the content passed from the content decryption block 13 in the playback mode, and stores it in a hard disk or other recording medium (not shown) in the recording mode. However, the content recording operation conforms to the rules of the copy control information inserted in the content transmission packet PCP.

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

  The HTTP client block 21 is divided into an HTTP request management block 22 and an HTTP response management block 23. Further, the HTTP request management block is divided into an HTTP request transmission block 22A and an HTTP request generation block 22B.

  The HTTP request generation block 22B generates a content transmission request (HTTP request) to be transmitted. The HTTP request generated here (for example, HTTP GET request) is transmitted to the HTTP server (that is, Source) by the HTTP request transmission block 22A.

  The HTTP response management block 23 is divided into an HTTP response reception block 23A and an HTTP response interpretation block 23B. The HTTP response returned from the server and the encrypted content are received by the HTTP response reception block 23A. The HTTP response received here is checked by the HTTP response interpretation block 23B. If the check here is OK, the received encrypted content is sent to the content decryption block 13 in the DTCP-IP authentication block 10. If this check is NG, processing as an error response is performed. The HTTP response from the source consists of one or more PCPs.

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

  3 includes a DTCP-IP authentication block 40, a DTCP-IP content transmission block 50, and a content management block 60. The source operates as an HTTP server and sends content to a sink operating as an HTTP client. Download transfer.

  The DTCP-IP authentication block 40 includes an AKE block 41, a message digest generation block 42, and a content encryption block 43. The DTCP-IP authentication block 40 preferably has tamper resistance.

  The AKE block 41 is a block that realizes an AKE mechanism (source side) in DTCP-IP. This block also has a function of passing parameters (described later) requested from the message digest generation block 42. The AKE block 41 holds information about the authenticated sink by the number of devices that have been AKE-authenticated, and uses it to determine whether the client is an authenticated client when content is requested from the client. The AKE block 41 may define an AKE procedure dedicated to the MOVE separately from the AKE when performing a normal content transmission procedure such as copying, and may prevent the masquerade of the MOVE mode by changing the scramble method or the like. .

  The message digest generation block 42 generates 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 42 is closely arranged with the AKE block 41 so as to generate a message digest of parameters held by the AKE block 41 that should not be disclosed outside the DTCP-IP authentication block 40. It is possible to request and obtain a parameter, and a message digest of the parameter or a parameter given from the outside can be created.

Content encryption block 43, encrypted using the DTCP-IP content data read out from the content management block 60 in response to a request of the content transmission block 50, the content key K _c generated from the key K _x was replaced with AKE It is a block to do. The content encrypted here is passed to the DTCP-IP content transmission block 50 for transmission to the client.

  The content management block 60 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 50 has an HTTP server block 51, receives a request (for example, an HTTP GET request) from a client (that is, a sink) as an HTTP server, and executes processing according to the request.

  The HTTP server block 51 is divided into an HTTP request management block 52 and an HTTP response management block 53.

  The HTTP request management block 52 is further divided into an HTTP request reception block 52A and an HTTP request interpretation block 52B. The HTTP request reception block 52A receives an HTTP request from a client. The received HTTP request is sent to the HTTP request interpretation block 52B and checked. When the check in the HTTP request interpretation block 52B is OK, the HTTP request information is notified to the DTCP-IP authentication block 40.

  The HTTP response management block 53 is further divided into an HTTP response generation block 53B and an HTTP response transmission block 53A.

  When the check in the HTTP request interpretation block 52B is OK, the HTTP response generation block 53B creates an HTTP response for returning the encrypted content. The HTTP response consists of one or more PCPs. On the other hand, when the check in the HTTP request interpretation block 52B is NG, an HTTP response for returning an error is created.

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

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

  Note that the message digest generation block that both DTCP-Sink and DTCP-Source have 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.

B. Content Transmission Using HTTP Next, a content transmission procedure according to DTCP-IP will be described. FIG. 4 illustrates a key exchange procedure based on AKE between Source and Sink, and a mechanism for performing encrypted content transmission using a key shared by key exchange. There are two types of content transmission: a method of copying content on the source to the sink, and a method of moving the content from the source to the sink and leaving no content on the source. In this section, description will be made on the assumption that the former content transmission method is based on copying. The latter content transmission method is realized by the MOVE function, but details of the AKE procedure when performing the MOVE transmission will be described later.

The source and sink first establish one TCP / IP connection and authenticate each other. This authentication is called DTCP authentication or AKE (Authentication and Key Exchange). A device certificate issued by DTLA (described above) is embedded in the DTCP-compliant device. In the DTCP authentication procedure, it is possible to share the authentication key K _auth between the Source and the Sink after confirming that they are regular DTCP compliant devices.

When the AKE procedure is successful, Source generates an exchange key K _x as a seed of the content key K _c, and sends it to the Sink encrypted authentication key K _auth. In each Source and Sink, by applying a predetermined arithmetic processing on the exchange key K _x, the content key K _c which is used to encrypt content when the content transmission is generated. It may be changed calculation formula for generating the content key K _c from the exchange key K _x in accordance with the content transmission ways (e.g., may be switched formula copy transmission and MOVE content transmission The details of this point will be described later.

  Then, after the AKE authentication and key exchange procedure is completed between DTCP-compliant devices, Sink requests content on the source. The Source can in advance tell the sink the content location indicating the access destination of the content on the Source through CDS (Content Directory Service) defined by UPnP (registered trademark). When Sink requests content, protocols such as HTTP and RTP can be used.

  In the example shown in FIG. 4, in the case of content transmission in which the sink as an HTTP client requests a content from the source as an HTTP server in accordance with the HTTP procedure, the content transmission is started using, for example, the HTTP GET method. To do. Although not shown, in the case of content transmission in which the source as an HTTP client pushes content to the sink as an HTTP server according to the HTTP procedure, the content transmission is started using, for example, the HTTP POST method. . Alternatively, when transmission by RTP is requested, the source becomes the RTP sender and the sink becomes the RTP receiver to start content transmission.

  When performing content transmission by HTTP, a TCP / IP connection for HTTP is created from an HTTP client separately from an AKE procedure, that is, a TCP / IP connection for DTCP authentication (that is, Source and Sink are respectively AKE procedures). Separate socket information (combination of IP address and port number) for communication and content transmission). Then, the sink as the HTTP client requests the content on the HTTP server by the HTTP request using the GET method in the same operation procedure as the normal HTTP. In contrast, the HTTP server returns the requested content as an HTTP response.

The data transmitted as the HTTP response is data obtained by encrypting the content using the key shared after the AKE authentication by the HTTP server, that is, the source. Specifically, the source generates a nonce N _c using a random number, and generates a content key K _c based on the exchange key K _x , the nonce N _c, and E-EMI indicating the encryption mode. Then, the content requested from the sink is encrypted using the content key K _c , and a PCP (Protected Content Packet) which is a packet including a payload including the encrypted content, a header including the nonce N _c and E-EMI. Is transmitted on the TCP stream. The IP protocol then divides the TCP stream into packet sizes as a predetermined unit, further converts the TCP stream into an IP packet with a header added, and delivers it to a specified IP address.

On the sink side, when each IP packet is received from the source, it is assembled into a TCP stream and the transmitted PCP is taken out. When the nonce N _c and E-EMI are extracted from the stream, the content key K _c is calculated using these and the exchange key K _x , and the encrypted content can be decrypted. Then, processing such as reproduction or recording can be performed on the plaintext content after decryption. When content transmission using the HTTP protocol is completed in this way, the TCP connection used for content transmission is appropriately disconnected from the sink side, for example.

FIG. 5 schematically shows the data structure of a packet PCP used for content transmission in DTCP-IP. As shown in the figure, the PCP is a packet composed of a header including a nonce _Nc and a payload made up of encrypted content. Incidentally, the HTTP response is composed of one or more PCPs, and the RTP payload is composed of one PCP.

The PCP header is plain text and includes a nonce _Nc . The PCP payload is composed of content encrypted with a content key K _c determined by nonce N _c (however, content for which “copy-free” is specified as copy control information is not required for encryption).

  The PCP payload is defined such that the data length, that is, the value of protected_content_length is always a multiple of 16 bytes. When the value of protected_content_length is not an integer multiple of 16, padding is performed before encryption as necessary, and 1 to 15 bytes of padding is added to the content. FIG. 6 shows how PCP is padded.

Here, if the same encryption key is continuously used throughout the long TCP stream, the risk of the key being decrypted increases. Therefore, in DTCP-IP, Source is negotiated nonce N _c ie updates the content key K _c (incremented by 1) as per 128MB, safety of the contents is achieved. Even when the nonce N _c is periodically updated, the PCP is padded (it is possible to pad to a plurality of PCPs without updating the content key K _c ).

Also, in DTCP-IP, a content key confirmation procedure is started with the update of nonce _Nc . In the content key confirmation procedure, the sink further establishes a TCP connection for content key confirmation separately from the TCP connection for content transmission, and performs a procedure for content key confirmation for the source. When the Sink needs to confirm the content key, it establishes this TCP connection as appropriate. For example, DTCP-IP Volume 1 Supplement E.I. In 8.6, “Content Key Configuration” is defined as a content key confirmation procedure. According to this, Sink confirms the content key associated with the current nonce _Nc using CONT_KEY_CONF subfunction.

C. MOVE transmission of content In DTCP-IP, a MOVE function is prepared as a means for enabling content encoded as No More Copies on the Source side to be used in Sink.

  MOVE in network communication is equivalent to moving data between devices, and basically after the data is moved to the destination device, no data is left in the source device. The MOVE function in DTCP-IP is encrypted under the condition that the Sink encodes the received content as No More Copies, and the source side erases or disables the content after transmission. This means that the content is transmitted from the source to the sink, and the move is allowed only between the single source and the single sink.

  Below, the MOVE sequence for implement | achieving the interoperation of the apparatuses based on DTCP-IP is demonstrated. To ensure minimum interoperability, MOVE transmission using a single HTTP GET method or POST method is recommended, but of course, implementation using other sequences is not prohibited.

  In the MOVE sequence in DTCP-IP, it is required to consistently observe the condition that the content is erased or made unavailable on the source side. For this reason, it is necessary to perform “INCREMENTAL MOVE” in which data after transmission is sequentially disabled on the source side and reception data is sequentially enabled on the sink side. However, if the MOVE sequence is interrupted due to the occurrence of a failure in the transmission path or other reasons, the content is divided between the source and the sink or missing. Then, as a result of the interruption of the MOVE sequence, the user will lose the appropriately acquired content in the first place.

  Therefore, in the content transmission system according to the present embodiment, the sink sequentially records the content being transferred in the move medium on the recording medium, but keeps the sequentially recorded content in an unusable state until the move finish process is successful. did. When confirmation of MOVE transmission end processing, that is, commitment, is performed, the recorded content on the sink side is made valid and usable, and at the same time, the original content is erased or made unusable on the source side. According to such a transmission procedure, No More Copy content does not exist twice in Source and Sink during MOVE transmission. In addition, even if the MOVE transmission process is interrupted due to a failure in the transmission path, the content is not divided and the content transmission can be resumed from the sink side.

  Such MOVE transmission of content is equivalent to moving the entire content between the source and sink at once. Unlike INCREMENTEL MOVE, in which data after transmission is sequentially disabled on the source side and received data is sequentially enabled on the sink side, it can also be referred to as “BLOCK MOVE”. BLOCK MOVE is also a MOVE process for content that satisfies the conditions defined by DTCP, because the same content does not exist twice in Source and Sink.

  Sink cannot play back the recorded content until the end of the MOVE transmission process, but it plays back and outputs the received content in parallel with the operation of recording with the received content invalidated (rendering). ). This is because if the BLOCK MOVE is a MOVE process that satisfies the conditions specified by DTCP, the rendering process in parallel with this is a TCP connection for content streaming transmission in parallel with the TCP connection for MOVE transmission. This is equivalent to establishing and reproducing and outputting streaming data. When rendering processing is performed in parallel with BLOCK MOVE, the communication path can be saved because only one TCP connection is required. In addition, for a source device such as a source or sink, both the move transmission process and the rendering process can be performed by a single content transmission process, thereby reducing the load.

  In order to perform the content move process and the received content playback process in parallel, the content playback / recording block 30 in the sink shown in FIG. 2 is divided into two independent modules, a content playback block 31 and a content recording block 32. What is necessary is just to comprise. FIG. 7 shows a functional block diagram in this case.

In the content decryption block 13, using the decryption key K _c of content calculated from the exchange key K _x was replaced with AKE, when decrypting the encrypted content received from the Source, which the content reproducing block 31 and the content recording block 32 Supply to each of the.

  In the content recording block 32, the content is subjected to a specified encoding process as No More Copies, and is first stored in a disabled state on a hard disk or other recording medium (not shown). Since the encoded content stored by the content recording block 32 is not validated until the entire MOVE transmission is completed, it cannot be read from the recording medium, decoded, and used (for example, reproduced in the content reproduction block). Similarly to the content decryption block 13, the content recording block 32 is arranged in the tamper-resistant DTCP-IP authentication block 10, so that decrypted content leaks between the content decryption block 13 and the content recording block 32. The problem disappears.

  On the other hand, the content playback block 31 converts (renders) the content supplied from the content decoding block 13 into video and audio signals as they are, and outputs video and audio from an AV output unit such as a display. The output of such decrypted content does not correspond to a copy of the content because data is lost along with the output, and conflicts with the DTCP standard that there should be no reproducible content existing in both the source and sink. do not do.

  Thus, by executing the reproduction process of the received content in parallel with the MOVE process, the user can confirm the content of the content during the MOVE transmission and enjoy the content viewing in real time.

  Here, when the content transmission between the source and the sink is performed at a speed higher than the actual playback time in the content playback block, the content playback block 31 may include the AV output buffer 33 locally. When the parallel processing as described above is performed, if the content directly supplied from the content decoding block 13 is stored in the AV output buffer 33 and reproduced and output in the FIFO format, the content of the content through the content reproduction block 31 is stored. Real-time playback can be performed. As a mounting method of the AV output buffer 33, in addition to providing a buffer memory dedicated to the content reproduction block 31, a recording medium (not shown) such as a hard disk possessed by the content recording block 32 and the AV output buffer 33 are provided. It is conceivable to integrate the AV output content and the recording content.

  The inventors of the present invention broadly divide MOVE transmission between Source and Sink into download and upload. Downloading here means that the user operating the sink pulls content from the source. For example, the source operates as an HTTP server and the sink operates as an HTTP client, and a move sequence using the HTTP GET method. Can be implemented. Upload means that the user operating the source pushes the content to the sink. For example, the source operates as an HTTP client and the sink operates as an HTTP server, and the move is performed using the HTTP POST method. A sequence can be implemented. To ensure minimum interoperability, MOVE transmission using a single HTTP GET method or POST method is recommended, but of course, implementation using other sequences is not prohibited.

  In conventional DTCP-IP, copy transmission is generally performed in a download format in which a trigger of content transmission is generated from a sink (see, for example, FIG. 4). The BLOCK MOVE transmission sequence for the case will be described.

C-1. Download format BLOCK MOVE
FIG. 8 shows an operation sequence when BLOCK MOVE transmission is performed between the source and the sink in the download format. As shown in the figure, the MOVE transmission in this case is composed of four phases: Source and content selection, MAKE AKE procedure, content move (MOVE) procedure, and MOVE end processing procedure. Among these, the AKE procedure for MOVE, the content transfer (MOVE) procedure, and the MOVE end processing procedure are executed in accordance with procedures defined on DTCP.

  The source and content selection phases can be performed, for example, on the basis of UPnP (registered trademark). In this case, the sink can acquire content information by using CDS (Content Directory Service). CDS is one of the main services of UPnP® media server. Usually, the sink uses the CDS to browse and search content, edit content metadata, and the like. FIG. 9 shows an operation sequence between the source and the sink in this case.

  First, Sink issues CDS :: Browse request, and can retrieve content list information by CDS :: Browse response from Source. As shown in the figure, in this response, the content is identified by an item ID and a parent ID, and for each content, the content title, the UPnP (registered trademark) class of the content, and response information for CDS :: Browse request are described. ing. Then, the socket information (DTCP Socket Info) for each content is described in the third field of the response attribute information (res protocolInfo property), and whether or not the content can be transferred with another response attribute information (res @ allusedUse). Mobile information to be indicated is described, and subsequently, a URL indicating a storage location of the content is included. In addition, the description means of Mobile information is not limited to this, For example, defining response attribute information by DTCP and using this is also considered. It is also conceivable to separately express BLOCK MOVE and INCREMENTAL MOVE as possible move methods.

  In the example illustrated in FIG. 9, the source describes the character string “DTCP1HOST = (host); DTCP1PORT = (port)” as socket information in the third field of the protocolInfo attribute of res, and the allowedUse attribute includes the content. Describes a character string “MOVE: 1” indicating that MOVE is possible by DTCP-IP. Therefore, Sink reads out the value of each attribute of protocolInfo and allowedUse in the res tag related to the content selected by the user from the response shown in the figure, and obtains the socket information for each content and whether the content can be transferred by MOVE. can do.

  Note that res @ allowedUse is not defined in the DTCP standard, and the operation method of “MOVE: 1” is not defined in detail, which may be inappropriate for future definition contents. Therefore, instead of res @ allowedUse, a parameter “DTCP.COM_FLAGS param” may be provided in the fourth field of res @ protocolInfo to indicate whether the content can be transferred. DTCP. COM_FLAGS param is a 32-bit length field, and the bit definition is as follows. When 1 is written in bit 30, 1 is also written in bit 31. Sink ignores the spare bit field.

Bit 31: MOVE transmission based on DTCP is possible.
Bit 30: Supports the BLOCK MOVE protocol that satisfies the conditions specified in the DTCP specification.
Bits 29-0: Reserved

  DTCP. COM_FLAGS param is provided in the fourth field of res @ protocolInfo, and a 32-bit value is expressed in hexadecimal. Also, DTCP. A description example of the res @ protocolInfo attribute when COM_FLAGS param is used is as follows.

  When the Sink takes a CDS :: Browse response from one or more sources, it selects the source (Select Source), selects the content to be moved from the selected Source (Select Content), and selects the destination (Select Destination). Do. Then, following the selection of content on the sink side, the MOVE transmission process of the selected content is started.

Prior to the move transmission, the move AKE procedure is first executed in order to perform mutual authentication between the source and the sink and the key sharing for the move. Here, before the AKE trigger information is passed from the sink to the source, it is assumed that the source is ready to accept the AKE from the sink. In the present embodiment, in order to share the mutual authentication between the source and sink and the seed key that is the source of the content decryption key according to the same procedure as the AKE procedure in the normal DTCP-IP (see FIG. 4 and FIG. 4). Execute the process. However, when MOVE is executed, an exchange key K _xM that is different from that during normal content transmission is generated, and the exchange key is _deleted for each MOVE transmission. This makes it more difficult to perform a content copy operation by impersonating MOVE transmission as copy transmission.

FIG. 10 shows an operation sequence of the move AKE procedure. As shown, the procedure is performed using a challenge / response authentication procedure. In response to a challenge request (MV-CHALLENGE) for move from Sink, the source generates an exchange key K _XM for move for each move AKE procedure, and passes through the subsequent response to source and sink. shared key K _XM and K _XM _label is realized between. However, in the EXCHANGE KEY command, a scramble method different from that in the normal AKE procedure is applied to prevent the MOVE transmission from being fake as a copy transmission.

Since the generation method of the keys K _XM and K _XM _label is the same as that during normal content transmission (see FIG. 4 and FIG. 4), detailed description is omitted here. Further, since the rules to eliminate the key K _XM and K _XM _label also similar to the case of the key K _X and K _X _label, omitted.

Source and Sink are both, each time one of the MOVE procedure is completed, to extinguish the key K _XM and K _XM _label for the MOVE procedure.

  FIG. 27 shows another operation sequence example of the move AKE procedure. In the illustrated example, Sink uses the MOVE protocol to send an MV-INITIATE command, initializes the MOVE transmission, and activates the MOVE RTT-AKE process. In the RTT-AKE process, mutual authentication is performed by a challenge-response procedure following the same procedure as that of normal AKE. RTT performs Sink and Source Localization checks, but is not directly related to the gist of the present invention. Then, the exchange key is shared by the MV_EXCHANGE_KEY command.

  As described above, the content transmission system according to the present embodiment includes two types of content move modes, INCREMENTAL MOVE and BLOCK MOVE. INCREMENTAL MOVE can be implemented by MOVE transmission negotiated by DTCP-IP. In contrast, BLOCK MOVE is not included in the current specification. Therefore, for example, when performing the AKE procedure for MOVE, it is preferable to confirm whether each other device is compatible with BLOCK MOVE, that is, the capability.

  FIG. 16 shows an example of an operation sequence of the move AKE procedure including a capability confirmation sequence. In the example shown in the figure, a procedure (CAPABILITY_EXCHANGE) for exchanging capabilities between Sink and Source is executed before the challenge / response authentication procedure for MOVE is performed.

  FIG. 17 shows the capability exchange procedure in FIG. 16 in more detail. The message used for this command / response is composed of a CAPABILITY field describing the capabilities of each device and an electronic signature for the CAPABILITY field.

  The first 1 bit of the message is used to identify Sink or Source. When the device sends a capability as a sink, 1 is described, and when the device sends a capability as a source, 0 is described. As a result, the capability as a sink is sent like the capability as a source (or the reverse behavior is performed) to prevent the capability from being spoofed. The field at the end of the CAPABILITY field is used to describe whether the device supports MOVE (or BLOCK MOVE).

  The electronic signature is composed of an electronic signature obtained with the secret key of each device for the Sink / Source bit and the CAPABILITY field at the beginning of the message. The Source that has received the CAPABILITY_EXCHANGE command can verify the signature by using the public key of the sink, and the sink that has received the CAPABILITY_EXCHANGE response can verify the signature by using the public key of the source.

  For example, when a sink requests a move of content in the BLOCK MOVE mode, a CAPABILITY_EXCHANGE command is first issued from the sink side, and a CAPABILITY_EXCHANGE response is returned from the source. If either one of the devices does not support BLOCK MOVE, the mode may be switched to the conventional INCREMENT MOVE and the content move process may be performed.

  The CAPABILITY_EXCHANGE sequence is sufficient as a countermeasure against the move transmission mode spoofing attack. However, when other measures against this type of fraud attack are taken, a secure information exchange procedure through the CAPABILITY_EXCHANGE sequence is not required.

  When the AKE procedure for MOVE transmission is successfully completed, a content transfer (MOVE transmission) procedure is subsequently started. When the content is moved from the source by the user operation on the sink side, the source operates as an HTTP server and the sink operates as an HTTP client, and download MOVE transmission may be performed using the HTTP protocol. For the transmission of the content data entity itself, INCREMENTAL MOVE and BLOCK MOVE can be performed in the same manner, but in either case, the HTTP protocol can be used. That is, a sink as an HTTP client requests content using an HTTP GET request, whereas a source as an HTTP server can perform a MOVE transmission of content selected in the content selection phase using an HTTP GET response. it can. GET is an HTTP method that is transmitted as a request when information is acquired from a specific URI (well-known).

  FIG. 28 exemplifies an operation sequence in the case of download MOVE transmission of contents using the HTTP protocol. For example, when the MOVE RTT-AKE procedure shown in FIG. 27 is successfully completed, the Sink operating as an HTTP client initializes the MOVE transmission process by transmitting an HTTP GET request.

  When the content is downloaded and transferred using the HTTP protocol, the Source sets the E-EMI mode to C1 (that is, the MOVE mode (see Table 1)). When the sink receives an E-EMI mode other than C1, the sink does not handle the received content as a move target.

Sink is an HTTP GET request in which the header information of “MOVE.dtcp.com: <KxM_label>” (or “BLKMOVE.dtcp.com” instead of “MOVE.dtcp.com”) is set in the header of the HTTP GET request. To start download MOVE transmission. Source, this Upon detecting the header information, encrypted with the encryption key K _c obtained from the key K _XM for MOVE corresponding to K _xM _label the key ID of the requested content, set the E-EMI to C1 And transmitted as a GET response.

  In FIG. 14A and FIG. 14B, processing operations executed by the source and sink when the content is downloaded and transferred from the source as the HTTP server to the sink as the HTTP client are summarized in the form of a flowchart.

  When the sink finds a source that operates as an HTTP server and chooses to move the content from the source (step S21), it sends a CDS :: Browse request to the source (step S22), and a response from the source. (Step S23).

  The source side waits for reception of CDS :: Browse request or other request from the sink (step S1), and when receiving the request, returns CDS :: Browse response to the sink (step S2). And waits until an AKE request for MOVE is received (step S3).

  When the sink retrieves the content list by CDS :: Browse response from the source, the sink determines the content to be moved (step S24), and requests the AKE processing for the move from the source (step S25).

  Then, the AKE procedure for MOVE is started between the sink and the source, and the AKE process for the move is mutually executed (steps S4 and S26). When the AKE authentication for the move is successful (steps S5 and S27), the source generates a move key and key ID and sends it to the sink (step S6), and the sink receives the move key and key ID from the source. Receive (step S28). However, when the AKE authentication for the move fails between the source and the sink, both the source and the sink skip all subsequent processes and end the entire processing routine.

  When Sink has successfully completed the AKE procedure for MOVE, Sink is accompanied by header information “MOVE.dcp.com: <KxM_label>” (or “BLKMOVE.dcp.com” instead of “MOVE.dcp.com”). In addition, an HTTP GET request is transmitted (step S29).

  When the source receives an HTTP GET request with a move header from the sink (step S7), the source checks whether the content requested by the request is being moved to another sink (step S8). ). If MOVE transmission is in progress, an error response is returned to the sink (step S15).

  The sink side waits for reception of an HTTP GET response from the source (step S30). If an error response indicating that the requested content cannot be moved is received from the source during the reception standby (step S31), the entire processing routine is terminated here.

  In addition, when the content requested to be moved from the sink is not being moved to another sink, and the source can be moved to the sink, the “move transmission” flag is set for the content. Is set (step S9), the content is encrypted using the key for MOVE, and transmitted to the request source Sink (step S10). When the “MOVE transmission in progress” flag is set, the content is locked. When the encrypted content transmission process is completed, the mobile terminal waits to receive a move completion process request from the sink (step S11).

  If the sink is able to successfully download the encrypted content from the source (step S32), the sink sends a move end processing request to the source (step S33). Then, the source and the sink respectively execute the move end processing procedure (steps S12 and S34), validate the content on the sink side, and delete the original content on the source side. Details of the operation sequence of the MOVE transmission end processing procedure between the source and sink will be described later.

  Then, when the source and sink complete the move end processing procedure (steps S13 and S35), both discard the move key and key ID (steps S14 and S36) and end the entire processing routine.

  During the download MOVE processing procedure shown in FIGS. 14A and 14B, the content to be moved is locked so that a move cannot be requested from another sink, thereby preventing the occurrence of multiple moves. When MOVE is performed by downloading, Source corresponds to a server, but manages whether or not each content to be held is being subjected to MOVE transmission using, for example, a table as shown in Table 2 below. In the table, the URI of the content can be associated with the flag indicating whether the move is being transmitted, and the state of the content can be confirmed. In addition, the source can prevent confusion by not indicating the existence of the content that is being moved in the CDS :: Browse response to other sinks that request the move of the content by downloading. Transmission interruption due to MOVE completion at the time).

  In addition, since the content is not yet valid during the period in which the download MOVE transmission process is performed in the BLOCK MOVE mode, the sink cannot use the content received for the purpose other than rendering in real time. Since the real-time rendering mechanism has already been described with reference to FIG. 7, the description thereof is omitted here.

  Note that during the period of the AKE procedure for MOVE and the content transfer (MOVE) procedure, an interruption process such as Cancel or Abort that cancels the MOVE transmission may be activated. Details of this point will be described later.

  If Sink can successfully download the desired content from the selected source using the HTTP protocol GET request, it confirms that the content transmission between Sink and Source has been completed successfully, that is, to execute a commitment. The MOVE end processing procedure is executed. In this termination process, the downloaded content is validated on the sink side and the original content is deleted on the source side. In addition, each of the sink and source deletes the exchange key used for content transmission. In the BLOCK MOVE mode, by executing such a commitment, a move process equivalent to moving the entire contents between the source and the sink can be realized. BLOCK MOVE is also a MOVE process for content that satisfies the conditions defined by DTCP, because the same content does not exist twice in Source and Sink.

  FIG. 11 shows an operation sequence for executing the move end processing procedure between the source and the sink. The illustrated operation sequence is performed in steps S12 and S34 of the flowchart shown in FIG. 14B.

  When the sink has successfully received the content to be moved, it continues to transmit the move end processing command CMD1 (or MV_FINALIZE command) until a response is received from the source.

  On the other hand, when the source receives the move end processing command CMD1, the source returns a move end processing response RSP1. In addition, the Source transitions the original content that has been in the valid state (Valid) to an intermediate invalid state (Invalid).

  If the sink is described in the received RSP1 that the source has already finished the move processing procedure, the sink similarly ends the move processing procedure. Along with this, the content moved from the source is transitioned from the invalid state to the valid state.

  Subsequently, the sink continues to transmit the next move end processing command CMD2 (or MV_COMPLETE command) until a response is received from the source. On the other hand, the source changes the original content from the intermediate invalid state to the complete invalid state, and then returns a response RSP2 for move end processing.

  FIG. 18 specifically shows, in the form of a flowchart, the contents of processing performed by Sink and Source on the download move transmission end sequence shown in FIG.

On the sink side, first, a random number R is generated (step S81), and predetermined arithmetic processing is applied to the random number R to calculate the message digests MAC5A and MAC6A. MAC5A is a value passed to the source, and MAC6A is a value expected to be returned from the source. The calculation formulas of MAC5A and MAC6A are, for example, as follows. For this calculation, K _xM corresponding to K _{xM _label} is used.

Subsequently, Sink is a key ID K _xM _label and the random number R, MAC5A, MAC6A, MOVE the ID of the content, a nonvolatile manner stores an ID Source (step S82). By storing these data in a non-volatile manner, even if the content transmission end processing is interrupted due to power interruption or the like, the restart processing can be performed, and it can be avoided that the content becomes invalid in both the sink and the source. .

Then, Sink transmits K _xM _label and the random number R, MOVE termination command CMD1 containing MAC5A (or, MV_FINALIZE command) to the Source. Sink continues to send CMD1 every time a reception timeout occurs until a response is received from the Source (step S83).

  On the other hand, when the source receives the move command CMD1, the source applies a predetermined arithmetic process (same as above) to the random number R included therein to calculate the message digests MAC5B and MAC6B. MAC6B is a value passed to the sink, and MAC5B is a value expected to be obtained from the sink. Then, the source checks the authenticity of the command by collating the MAC 5A included in the CMD1 with the MAC 5B obtained by itself (step S91). If this check fails, the content transmission end process is aborted (Abort). However, the source may continue to wait for CMD1 without stopping the process if there is a possibility that the sink has misdirected the destination of CMD1 due to the change of its socket information in the middle.

Further, when the authenticity check is successful, the source stores the key ID _{KxM_label, the} MAC 6B, and the ID of the moved content in a nonvolatile manner (step S92). By storing these data in a non-volatile manner, even if the content transmission end processing is interrupted due to power interruption or the like, the restart processing can be performed, and it can be avoided that the content becomes invalid in both the sink and the source. (Id.)

  Then, after transitioning the original content that was in the valid state to an intermediate invalid state (step S93), the Source returns a MOVE end process response RSP1 indicating that CMD1 has been accepted (Accepted).

  When the sink receives the move completion processing response RSP1 from the source, the sink checks whether the CMD1 has been rejected (step S84). When RSP1 indicates Accepted, it is further checked whether or not the MAC 6B included in the RSP 1 matches the MAC 6A held by itself (step S85). If these checks are successful, the content moved from the source is transitioned from the invalid state to the valid state (step S86).

Subsequently, Sink transmits containing K _xM _label the key ID MOVE termination command CMD2 (or, MV_COMPLETE command) to the Source. Sink continues to send CMD2 every time a reception timeout occurs until a response is received from the Source (step S87).

Source receives the MOVE finalizing command CMD2, deletes the data corresponding to the K _xM _label contained therein (step S94). Here, the term data refers to a non-volatile manner store and keep the K _xM _label and MAC6B, ID of content that MOVE in step S92. Then, the Source returns a MOVE end process response RSP2.

Sink receives the MOVE finalizing response RSP2, deletes the data corresponding to the K _xM _label contained therein (step S88). The data here is that of a non-volatile manner store and keep the K _xM _label and the random number R, MAC5A, MAC6A, ID of the content, Source of ID at step S82.

  The method for validating the content on the sink side after the download move transmission is completed is not particularly limited. When enabled, it is possible to use the content recorded by encoding as No More Copies in the content recording block in the sink (for example, the encryption applied at the time of recording can be released). As a result, the encoded content can be supplied to the content reproduction block 31 and rendered into video and audio signals, and video and audio can be output from an AV output unit such as a display. In addition, the sink can move the No More Copies content in the download format as described above or the upload format described later to another sink as a source.

  Also, there is no particular limitation on the method of deleting the original content on the source side after the download move transmission is completed. In addition to deleting the content data entity itself from the recording medium such as a hard disk storing the content, the content entity recorded by encoding (encrypting) remains but the decryption key cannot be used again. You may do.

  Here, there is a possibility that the end processing sequence of the download move transmission shown in FIG. 11 may be interrupted due to the power-off of one device even though the content entity is successfully downloaded move transmitted from the source to the sink. There is. In such a case, there is a possibility that the content moved in both the Source and the Sink cannot be used due to the interruption of the termination process of the download MOVE transmission (interrupted). Therefore, in the content transmission system according to the present embodiment, in preparation for such a situation, a processing procedure for resuming the content transmission end process is provided so that the commitment can be ended safely. By this restart procedure, the content transmission procedure is not wasted, and it is possible to prevent the content from becoming invalid in both the sink and the source.

In order to enable resumption of the end process of download MOVE transmission, each of Sink and Source is required for the resumption process using a nonvolatile memory such as NVRAM when starting the end process of download MOVE transmission. The data is saved. In Sink side, when issuing CMD1 That MV_FINALIZE command, K _XM _lable to be transmitted in the command, the random number R, MAC5A, further MAC6A, (corresponding to CDS object ID) downloaded MOVE the ID of the content, Source of ID ( UPnP (registered trademark) UUID) is stored in a nonvolatile manner (see step S82 in FIG. 18). Meanwhile, the Source side stores K _xM _label and MAC5B the key ID, and MAC6B in a nonvolatile manner (see step S92 in FIG. 18). The resumption process is basically started on the sink side.

  By storing the UUID specified in UPnP Device Architecture, Sink can discover the source that is the quest destination of the CDS process, and the Object ID specified in UPnP AV CDS2 By storing the contents, it is possible to specify the contents to be moved. Then, when resuming the interrupted MOVE processing, the sink can obtain socket information for the content to be moved by performing UPnP (registered trademark) CDS processing in the same manner as when content is first selected. it can. For example, there is no problem even if the source is shut down and the IP address is changed at the time of restart.

  When the sink obtains the socket information of the content to be moved, it subsequently establishes a TCP connection with the corresponding source. FIG. 29 shows, in the form of a flowchart, a processing procedure for establishing a TCP connection between a sink and a source when resuming the move transmission end process.

  When the sink selects one source ID (UUID) stored in a nonvolatile manner (step S131), the sink checks whether there is a device having the same UUID using the UPnP device discovery protocol (SSDP) (step S132). ). Here, if there is no device having the same UUID, all subsequent processing is skipped, and the entire processing routine is terminated.

  On the other hand, if a device having the same UUID exists (Yes in step S132), a CDS :: Browse request is transmitted to the device with an Object ID specified (step S133).

  When the source receives the CDS :: Browse request from the sink (step S141), the source returns a CDS :: Browse response including information indicating that the content transmission end processing has not been completed for the corresponding content (step S142).

  Note that content transmission end processing is not completed means that, for example, attribute information indicating that the content is movable is not included, or URL information to which an HTTP GET request is not included is included, and attribute information indicating that the move processing is being executed It can be shown by the method of including.

  When the sink receives the CDS :: Browse response (step S134), it refers to the socket information included in the message and establishes a TCP connection for AKE commands such as CMD1 and CMD2 (step S135).

Sink, when establishing a TCP connection for this way AKE command, a key ID that has been stored in a nonvolatile manner K _xM _label and the random number R, with reference to MAC5A, CMD1 (MV_FINALIZE command) or CMD2 ( MV_COMPLETE command) is sent to the source. In contrast, Source returns a response RSP2 for response RSP1 or CMD2 for CMD1 similarly using K _xM _label and MAC6B that has been stored in a nonvolatile manner. As a result, the end processing of the download move transmission between the sink and the source can be completed.

  FIG. 19 is a flowchart showing a processing procedure when the source receives the move end processing command CMD1 from the sink after the download move transmission end processing sequence shown in FIG. 11 and FIG. 18 is interrupted for some reason. It is shown in the form of

The source checks whether or not it stores K _{xM_label} included in the move end processing command CMD1 in a nonvolatile manner (step S101).

Here, when K _xM _label is not held, it is assumed that the Source has already completed the corresponding content transmission end processing, or CMD1 is irrelevant to itself, and therefore rejects the command. A MOVE end process response RSP1 indicating (Rejected) is returned (step S104).

On the other hand, when K _xM _label is held, the corresponding content transmission end process has been interrupted, so the Source transitions the original content indicated by the content ID in CMD1 to an intermediate invalid state. Then (step S102), a response RSP1 for MOVE end processing indicating that CMD1 has been accepted (Accepted) is returned (step S103). In this way, the interrupted MOVE end process can be resumed at the source operating as the HTTP server.

  Also, FIG. 20 shows a processing procedure when the Source receives the MOVE end processing command CMD2 from the Sink after the download MOVE transmission end processing sequence shown in FIGS. 11 and 18 is interrupted for some reason. Is shown in the form of a flowchart.

The source checks whether or not it stores K _xM _label, which is a key ID included in the move end processing command CMD2, in a nonvolatile manner (step S111).

Here, when K _xM _label is held, the corresponding content transmission end processing has been interrupted, so that the Source is stored in association with K _xM _label (ie, MAC 6B, MOVE). (Step S112), and returns a MOVE end process response RSP2 indicating that CMD2 has been accepted (Accepted) (Step S113).

On the other hand, when K _xM _label is not held, it is assumed that the source has already completed the corresponding content transmission end processing or CMD2 is irrelevant to itself, so step S112 is skipped, and CMD2 A response RSP2 for MOVE end processing indicating that it has been accepted (Accepted) is returned (step S113). In this way, the interrupted MOVE end process can be resumed at the source operating as the HTTP server.

  Further, FIG. 21 shows, in the form of a flowchart, a processing procedure for allowing Sink to resume the MOVE end process after the download MOVE transmission end process sequence shown in FIGS. 11 and 18 is interrupted for some reason. Show.

Sink is nonvolatile manner the data stored in the step S82, the i.e. the key ID K _xM _label and the random number R, MAC5A, MAC6A, a content ID, when it is detected that the SourceID is present (step S121), this content It can be seen that the transmission end process is interrupted, the commitment with the source is not completed, and these data remain without being erased.

  In this case, in order to resume the content transmission end process, a TCP connection with the corresponding source is established (step S122).

  Then, it is checked whether or not the content indicated by the content ID is in an invalid state (step S123).

  If the content remains in an invalid state (Yes in step S123), the content transmission end processing is interrupted before receiving the MOVE end processing response RSP1 from the source. Therefore, the process proceeds to # 1 of the flowchart shown in FIG. Jump (step S124) and start a commitment with the source.

  If the content is already in a valid state (No in step S123), the content transmission end processing is interrupted before the MOVE end processing response RSP2 is received after obtaining the commitment from the source. The process jumps to # 2 of the flowchart shown (step S125), and the move end processing command CMD2 is transmitted to the source. In this way, the interrupted MOVE end process can be resumed in the sink operating as an HTTP client.

  By restarting the MOVE transmission sequence as shown in FIGS. 19 to 21, the content transmission procedure is not wasted, and it is possible to avoid invalidating the content in both the sink and the source.

  In response to the user's instruction input that the Source should return the MOVE end process response RSP2, the source transitions the original content from the intermediate invalid state to the completely invalid state.

C-2. Upload form of BLOCK MOVE
FIG. 12 shows an operation sequence when BLOCK MOVE transmission is performed between the source and the sink in the upload format. In this case, the MOVE transmission is composed of four phases such as a sink and content selection, a move AKE procedure, a content transfer (MOVE) procedure, and a move end processing procedure in the same manner as download. Among these, the AKE procedure for MOVE, the content transfer (MOVE) procedure, and the MOVE end processing procedure are executed in accordance with procedures defined on DTCP.

  In the Sink and content selection phase, the user performs selection of the content to be moved (Select Content) and selection of the Sink as the transmission destination of the content (Select Sink & Destination) on the Source side, and then the corresponding Sink. On the other hand, the socket information for authentication and key exchange related to the content transmitted as DTCP MOVE is notified. Subsequently, the MOVE process for the selected content starts.

  Notification from the source to the sink can be performed using CDS on a UPnP (registered trademark) basis. FIG. 13 shows an operation sequence between the source and sink in this case.

  First, when the source requests upload move transmission to the sink, the source issues a CDS :: CreateObject request so as to create a storage location for the content to be transmitted. For each content to be moved in the CDS :: CreateObject request, the source is the content by the content title, the UPnP (registered trademark) class of the content, the socket information for authentication and key exchange, and the DTCP-IP MOVE procedure. The transmission is described. It should be noted that the item ID, parentID, and content URI for content identification are undefined in the request, and the HTTP server Sink is determined and notified to the HTTP client Source by the CDS :: CreateObject response. In the example shown in FIG. 13, the source describes the character string “DTCP1HOST = (host); DTCP1PORT = (port)” as socket information in the third field of the protocolInfo attribute of res, and the content is described in DTCP-IP. A character string “DTCPOP = MOVE” indicating transmission by a MOVE transmission sequence is described.

  In addition, if attribute information that is temporarily used at the time of upload such as DTCPOP is included in res @ protoInfo, Sink will send the attribute when sending res @ protoInfo in response to a CDS :: Browse request as an HTTP server. It is necessary to remove information, and the processing becomes complicated. Therefore, a method of sending attribute information with a new attribute independently of protocolInfo is also conceivable. Specifically, it is conceivable that a res @ dcp: uploadInfo attribute is provided to indicate whether the content can be transferred. The res @ dtcp: uploadInfo attribute is a 32-bit length field, and the bit definition is as follows. When 1 is written in bit 30, 1 is also written in bit 31. Sink ignores the spare bit field.

Bit 31: Transmit as MOVE based on DTCP.
Bit 30: Use the BLOCK MOVE protocol that satisfies the conditions specified in the DTCP specification.
Bits 29-0: Reserved

  res @ dtcp: 32 bits of the uploadInfo attribute are expressed in hexadecimal. A description example of the res @ dcp: uploadInfo attribute in the CDS :: CreateObject request is as follows.

  When the sink receives the CDS :: CreateObject request, the sink can identify the socket information for authentication and key exchange on the source side that is the content transmission source, and whether the content is transmitted as a move. When the sink accepts the upload move transmission request from the source, the sink creates a storage location (that is, an import destination) of the content in the local storage area, and sends a CDS :: CreateObject response including the storage location information. Return to the requesting source. In the example shown in FIG. 13, Sink is a character string “http://1.2.3.4:50000/import?id=6 indicating the import destination of the content to be moved in the importUri attribute in the res @ protoInfo attribute. "Is described. Alternatively, when the res @ dtcp: uploadInfo attribute is used to indicate whether or not the move transmission is possible, a description example of the CDS :: CreateObject response is as follows.

  In this way, the source receives a non-error CDS :: CreateObject response from the sink, confirms that the content can be moved to the sink, secures a storage location for the content, and subsequently selects the content. The content upload MOVE transmission process is started.

  Prior to the move transmission, the move AKE procedure is first executed in order to perform mutual authentication between the source and the sink and the key sharing for the move. The operation sequence of the move AKE procedure is as already described with reference to FIG. 10 and FIGS. However, in the MV-CHALLENGE command, a scramble method different from that in the normal AKE procedure is applied to prevent the MOVE transmission from being fake as the copy transmission (same as above).

  Alternatively, an operation sequence as shown in FIG. 27 can be used for the move AKE procedure. In this case, Sink uses the MOVE protocol to send an MV-INITIATE command, initializes the download MOVE transmission, and activates the MOVE RTT-AKE process. In the RTT-AKE process, mutual authentication is performed by a challenge-response procedure following the same procedure as that of normal AKE. The shared key is exchanged by the MV_EXCHANGE_KEY command (same as above).

  When the AKE procedure for MOVE transmission is successfully completed, a content transfer (MOVE) procedure is subsequently started. When the content is moved to the sink by a user operation on the source side, the source operates as an HTTP client, the sink operates as an HTTP server, and upload MOVE transmission may be performed using the HTTP protocol. That is, a source as an HTTP client sends an HTTP POST request, and a sink as an HTTP server returns an HTTP POST response to upload the content selected in the content selection phase from the source to the sink. To do. POST is an HTTP method that is transmitted as a request for transmitting information to a specific URI (known).

  When uploading and moving content using the HTTP protocol, the Source sets the E-EMI mode to C1 (that is, the MOVE mode (see Table 1)). When the sink receives an E-EMI mode other than C1, the sink does not treat the received content as a move target (same as above).

Source is an HTTP POST request in which the header information of “MOVE.dtcp.com: <KxM_label>” (or “BLKMOVE.dtcp.com” instead of “MOVE.dtcp.com”) is set in the header of the HTTP POST request. To start upload MOVE transmission. Then, Source encrypts the content requested by the K _xM _label encryption key obtained from the key K _XM for MOVE corresponding to K _c, transmitted as subsequent POST request by setting the E-EMI to C1.

  FIG. 15A and FIG. 15B summarize the processing operations executed by the source and sink in the form of a flowchart when the content is uploaded and transferred from the source as the HTTP client to the sink as the HTTP server.

  When the source finds a sink that operates as a content upload destination server (step S41), the source sends a CDS :: CreateObject request to request the sink to create a content storage location (step S42). Waiting for reception of the response (step S43).

  When the sink receives the CDS :: CreateObject request from the source (step S61), it returns a response to this (step S62).

  When the source receives the CDS :: CreateObject response from the sink, the source subsequently determines the content to be moved (step S44), and waits until it receives the AKE request for the move (step S45).

  After sending CDS :: CreateObject response, the Sink requests the AKE process for MOVE from the Source (step S63).

  Then, the AKE procedure for MOVE is started between the sink and the source, and the AKE process for the move is mutually executed (steps S46 and S64). When the AKE authentication for the move is successful (steps S47 and S65), the source generates a move key and key ID and sends it to the sink (step S48), and the sink receives the move key and key ID from the source. Receive (step S66). However, when the AKE authentication for the move fails between the source and the sink, both the source and the sink skip all subsequent processes and end the entire processing routine.

  Subsequently, the source sets a “move transmission” flag for the content to be uploaded to the sink by the move (step S49), and then encrypts the content using the move key. The encrypted content is transmitted by the HTTP POST request with the header information of “MOVE.dcp.com: <KxM_label>” (step S50). When the “MOVE transmission in progress” flag is set, the content is locked. And it waits for reception of the HTTP POST response from Sink (step S51).

  On the sink side, after completing the AKE procedure for the move, the sink side waits to receive an HTTP POST request from the source (step S67). When the request is received and all the encrypted contents are received, an HTTP POST response is returned (step S68).

  If the encrypted content can be successfully uploaded from the source to the sink in this way, the source waits for reception of the move end process (step S52). Also, the sink sends a move end processing request to the source (step S69). Then, the source and the sink respectively execute a move end processing procedure (steps S53 and S70), validate the contents on the sink side, and delete the original contents on the source side. Since the operation sequence of the MOVE end processing procedure between the source and sink has already been described with reference to FIGS. 11 and 18, the description thereof is omitted here.

  Then, when the source and sink complete the move end processing procedure (steps S54 and S71), both discard the move key and key ID (steps S55 and S72), and end the entire processing routine.

  During the upload MOVE processing procedure shown in FIG. 15A and FIG. 15B, the content to be moved is locked so that a move cannot be requested from another sink, thereby preventing the occurrence of multiple MOVEs. When performing content move in the upload format, Sink is equivalent to a server, but manages whether or not each content to be held is being transferred using, for example, a table as shown in Table 2 (described above). (Same as above)

  In addition, since the content is not yet valid during the upload MOVE transmission process in the BLOCK MOVE mode, the sink cannot use the content received for the purpose other than rendering in real time. Since the real-time rendering mechanism has already been described with reference to FIG. 7, the description thereof is omitted here.

  It should be noted that during the period of the AKE procedure for MOVE and the content transfer (MOVE) procedure, an interruption process such as cancel or cancel that aborts the MOVE transmission may be activated. Will be described later.

  If the source can successfully upload the desired content to the predetermined sink operating as the HTTP server by the POST request of the HTTP protocol, the upload MOVE transmission end processing procedure is executed, On the sink side, the uploaded content is validated, and at the same time, the original content is deleted on the source side. The MOVE end processing procedure is executed according to an operation sequence similar to that shown in FIGS. 11 and 18 (same as above).

  The method for validating the content on the sink side after the upload move transmission is completed is not particularly limited. When enabled, the content recorded as No More Copies in the content recording block in the sink can be used (for example, the encryption applied at the time of recording can be released). As a result, the encoded content can be supplied to the content reproduction block, rendered into a video and audio signal, and output from the AV output unit such as a display. Alternatively, this time, as a source, it is possible to move to another sink in the same manner as described above in the download or upload format.

  Also, there is no particular limitation on the method for deleting the original content on the source side after the upload move transmission is completed. In addition to deleting the content data entity itself from the recording medium such as a hard disk storing the content, the content entity recorded by encoding (encrypting) remains but the decryption key cannot be used again. You may do.

  In addition, Sink deletes DTCPOP = MOVE in the res tag (or deletes res @ dcp: uploadInfo attribute) if it intends to provide the content as a source after uploading the content from the source. ) And the host name and port of the socket information need to be changed to their own. Also, when allowing the content to be taken out (MOVE out) to another Sink, an allowedUse attribute describing the character string “MOVE: 1” indicating that the MOVE is possible is added in the res tag (or Add the above DTCP.COM_FLAGS param to the fourth field of the res @ protocolInfo attribute).

  In the operation sequence shown in FIG. 13, the source notifies the socket information (DTCP socket Info) necessary for establishing the TCP connection for the move AKE procedure on the sink side by the CDS :: CreateObject request. . However, in this notification method, when resuming the interrupted MOVE transmission end procedure, a CDS :: CreateObject request that requests upload MOVE transmission of the same content must be issued again in order to notify the socket information. There is a risk of violating the DTCP standard of allowing MOVE transmission only once.

  Therefore, in addition to the notification method based on the operation sequence shown in FIG. 13, the present inventors perform socket information (DTCP socket) in the header of the HTTP POST request before performing the AKE procedure for MOVE after processing CDS :: CreateObject. (Info) and a method for notifying socket information from the source to the sink is proposed. For example, it is described as follows using a Content-Type header.

  Since Sink cannot decrypt the content until the AKE procedure is completed, it can be considered that the source does not transmit the content yet with this POST request but transmits it after the AKE procedure is completed. That is, the HTTP POST request for notifying socket information may not be accompanied by content, and unlike FIG. 13, it is not necessary to send socket information with CDS :: CreateObject.

  FIG. 30 shows an operation sequence for performing upload MOVE transmission between the source and the sink when the source uses a method of notifying socket information using a POST request.

  First, the Source uses a CDS :: CreateObject request to request the sink to create an object that is a content transfer destination. At this time, the Source requests a transaction based on the MOVE transmission in the res @ uploadInfo attribute. On the other hand, Sink returns a URI for HTTP POST in the res @ importUri attribute of the CDS :: CreateObject response.

  Subsequently, the Source transmits an HTTP POST request for the URI acquired from the description content of the CDS :: CreateObject response, and notifies the sink of socket information for authentication and key exchange. As described above, the socket information is sent as ContentType. However, the HTTP POST request used for notification of socket information does not include content.

  When the sink acquires socket information, the sink establishes a TCP connection for authentication and key exchange. Sink then initializes the upload MOVE transmission by sending a MV-INITIATE command to start the MOVE RTT-AKE process.

  When the MOVE RTT-AKE process is completed, BLKMOVE. dtcp. The source transmits the encrypted content by transmitting an HTTP POST request including the com header information.

  After receiving all the contents to be moved, the sink starts a move transmission end process by transmitting an MV_FINALIZE command. The move end processing procedure is performed according to the operation sequence shown in FIG.

As shown in FIG. 31, the socket information is sent from the source in the header of the POST request not accompanied by the content, and after the sink establishes the TCP connection for authentication and key exchange and finishes the AKE procedure, the POST response is sent. May be returned. For such an operation sequence, MOVE the K _XM _label covalently with AKE procedure. dtcp. com (or BLKMOVE.dtcp.com) header and send it as a POST response from Sink as “MOVE.dcp.com:<K _XM _label>”. Even when it is performed, the exchange key K _XM to be applied to the content encryption can be reliably grasped.

Further, as another method for obtaining the same effect as the operation sequence shown in FIG. 31, by making the socket information notified to the Sink unique when performing a plurality of MOVE processes, the association between the Sink and K _XM is ensured. Can be done. In this case, Sink will receive a MOVE. dtcp. com (or BLKMOVE.com) header response without a header can also be sent. Note that the subsequent content transmission is not sent as a new POST request, but as a POST request procedure before the AKE procedure.

  The socket information notification method described here can be applied not only to upload move transmission but also to upload-type COPY transmission.

  32A and 32B are flowcharts showing processing operations executed by the Source and the Sink when uploading and moving the content from the Source as the HTTP client to the Sink as the HTTP server according to the operation sequence shown in FIG. It is summarized.

  When the source finds a sink that operates as a server to which the content is uploaded (step S151), it sends CDS :: CreateObject request to request the sink to create a content storage location (step S152). Waiting for reception of the response (step S153).

  When the sink receives the CDS :: CreateObject request from the source (step S171), it returns a response to this (step S172).

  When the source receives the CDS :: CreateObject response from the sink, the source subsequently determines the content to be moved (step S154). Then, after transmitting socket information to the sink using an HTTP POST request accompanied by a Content-Type header (step S155), the process waits until an AKE request for MOVE is received (step S156).

  When the sink receives an HTTP POST request with socket information from the source (step S173), the sink establishes a TCP connection to the socket obtained from the request (step A174), and requests the AKE processing for the move from the source. (Step S175).

  Then, the AKE procedure for MOVE is started between Sink and Source, and the AKE process for MOVE is mutually executed (steps S157 and S176). Here, when the AKE authentication for the move is successful (steps S158 and S177), the source generates a move key and a key ID and transmits them to the sink (step S159). However, when the AKE authentication for the move fails between the source and the sink, both the source and the sink skip all subsequent processes and end the entire processing routine.

  When the sink receives the move key and key ID from the source (Yes in step S178), the sink receives BLKMOVE. dtcp. The key ID is transmitted by an HTTP POST response with a com header (step S179).

  When the source receives an HTTP POST response with a key ID from the sink (Yes in step S160), the source selects a move transmission key corresponding to the key ID for subsequent processing (step S161).

  Subsequently, the source sets a “move transmission” flag for the content to be uploaded to the sink (step S162), and then encrypts the content using the move transmission key. The message body of the HTTP POST request with socket information is transmitted (step S163). When the “MOVE transmission in progress” flag is set, the content is locked. And it waits for reception of the HTTP POST response from Sink (step S164).

  When the sink side finishes the move AKE procedure, the sink side waits to receive encrypted content as the message body of the HTTP POST request from the source (step S181). When the request is received and the encrypted content is received, an HTTP POST response is returned (step S182).

  In this way, if the encrypted content can be successfully uploaded from the source to the sink, the source waits for reception of the move end process (step S165). Also, the sink sends a move end processing request to the source (step S183). Then, the source and the sink respectively execute the move end processing procedure (steps S166 and S184), and the contents are validated on the sink side and the original contents on the source side are deleted or invalidated. Since the operation sequence of the MOVE end processing procedure between the source and sink has already been described with reference to FIGS. 11 and 18, the description thereof is omitted here.

  Then, when the source and sink complete the move end processing procedure (steps S167 and S185), both discard the move transmission key and key ID (steps S168 and S186) and end the entire processing routine.

  Here, although the content entity has been successfully uploaded and moved from the source to the sink, there is a possibility that the end processing sequence of the move transmission may be interrupted due to power-off of one device. There is a possibility that the content moved in both the Source and the Sink cannot be used due to the interruption of the end process of the MOVE transmission (interrupted). In this way, when the MOVE end processing procedure is interrupted, it can be resumed according to the processing procedure shown in FIGS. 19 to 21 to prevent the contents from becoming invalid in both the sink and the source.

In order to enable the upload MOVE transmission end process to be restarted, each of the sink and source is required for the restart process using a nonvolatile memory such as NVRAM when starting the upload MOVE transmission end process. The data is saved. In Sink side, a parameter (K _xM _label) used in the CMD1 That MV_FINALIZE command, stores MAC6A nonvolatile manner.

Further, when the source has the interrupted commitment information, it is necessary to notify the corresponding sink to the socket information and prompt the processing to be resumed. For this purpose, in the commit process, the source is required to discover the UUID necessary for sink discovery, the object ID necessary to discover the destination URI of the POST, and the key IDs K _xM _label and MAC5B. , MAC6B is stored in a nonvolatile manner. The resumption process is basically started on the sink side.

  According to the above method in which socket information (DTCP socket Info) is described in the header of the HTTP POST request and the socket information is notified from the source to the sink, the method of notifying the socket information using CDS :: CreateObject is In contrast, even when the interrupted move process is resumed, the sink can obtain socket information related to the contents to be moved without any problem.

  FIG. 33 shows, in the form of a flowchart, a processing procedure for establishing a TCP connection between a sink and a source when resuming the move transmission end process.

  The source selects one UUID stored in a nonvolatile manner (step S191), and a device (sink) that matches the UUID stored in a nonvolatile manner is found by the UPnP device discovery protocol. It is checked whether or not (step S192). When the source finds a sink having the same UUID as that stored in a nonvolatile manner, the source transmits a CDS :: Browse request to the device with the object ID specified (step S193).

  On the other hand, when the sink receives a CDS :: Browse request from the source (step S201), it returns a CDS :: Browse response (step S202).

  When the source receives the CDS :: Browse response from the sink (Yes in step S194), the source obtains res @ importUri that is the transmission destination of the socket information from the description content of the response (step S195). Then, an HTTP POST request including the socket information in the Content-Type header is transmitted to the sink (step S196).

  When the sink receives an HTTP POST request with socket information from the source (step S203), the sink refers to the socket information included in the request and establishes a TCP connection for AKE command communication with the source (step S203). S204). Then, using this TCP connection, the suspended MOVE transmission end process can be resumed according to the processing procedure shown in FIGS.

C-3. BLOCK MOVE CANCEL and Abort
Even if the content is moved in any of the download and upload formats as described above, the sink cancels the move process before sending the move end processing command CMD1 to the source. Or it can be aborted.

  Both the Source and the Sink can cancel the MOVE processing procedure (CANCEL) by transmitting the MV-CANCEL subfunction to the other party.

  In the present embodiment, the CANCEL of the MOVE processing procedure is implemented as a part of the AKE procedure. The TCP connection for the AKE procedure is usually established by a trigger from Sink. In a normal content transmission procedure for streaming or copying content, the AKE TCP connection is disconnected when a key is shared by AKE. However, in this case, it is necessary to hold the TCP connection for AKE so that the MV-CANCEL subfunction can be transmitted from the Source side during the MOVE processing procedure.

When the Source sends or receives the MV-CANCEL subfunction before starting the MOVE end processing procedure, the Source ends the MOVE processing procedure and releases the locked state of the content that is the target of the move (specifically, In Table 2, the state of the corresponding content is returned to MOVE enabled), and released for another MOVE request for the content. In addition, at the end of the MOVE processing procedure, the Source deletes the exchange key K _XM . Thereafter, a request regarding the completed move processing procedure from the sink is rejected.

Further, when the sink sends or receives the MV-CANCEL subfunction before starting the move end processing procedure, the sink ends the move processing procedure and deletes the content moved to itself. At the end of the move processing procedure, Sink deletes the exchange key K _XM .

  Also, both the source and sink can abort the move processing procedure if communication between the source and sink is interrupted before the move end processing starts. Source and sink in this case perform the same behavior as when MV-CANCEL is transmitted or received.

D. Countermeasures for MOVE mode spoofing attack In DTCP-IP, communication contents can be easily tampered with by installing an unauthorized proxy composed of a personal computer or the like on the transmission path between the source and sink. In particular, in a system in which BLOCK MOVE is started through a capability confirmation procedure (see FIGS. 16 to 17) between the source and the sink, if the implementation of the confirmation procedure is not essential, the source corresponds to the BLOCK MOVE. In spite of this, the proxy can pretend to Sink that the Source is not compatible with BLOCK MOVE, and can cause Sink to perform INCREMENTAL MOVE. In the example of the operation sequence shown in FIG. 22, the proxy directly transmits a CAPABILITY_EXCHANGE message describing that it is compatible with BLOCK MOVE from the sink to the source, but has altered the CAPABILITY_EXCHANGE message describing that it is compatible with the BLOCK move from the source. Then, the request for BLOCK MOVE is rejected (Rejected), and it is false that the Source is not compatible with BLOCK MOVE. In this case, the source side performs content transmission processing in the BLOCK MOVE mode in accordance with a request from the sink, but the sink switches to the INCREMENTAL MOVE mode and performs content reception processing.

  When such a move mode spoofing attack is launched, the sink side sequentially activates each time data is received from the source, and when the content transmission processing is completed, the proxy performs the content transmission processing on the source. By performing the cancellation, a situation that conflicts with the DTCP-IP rule that valid content exists in both the source and the sink occurs.

  Therefore, the content transmission system according to the present embodiment spoofs the capability confirmed between the source and the sink and the MOVE mode on the sink side is impersonated, or the content transmission system pretends to be a MOVE transmission by some means. Several methods for preventing copy transmission are applied.

  For example, even if the proxy tampers with the CAPABILITY_EXCHANGE message from the source device and rejects the request for BLOCK MOVE (Rejected), and the source is falsely incompatible with the BLOCK MOVE, then the sink is the source in the AKE procedure. The source MOVE mode is notified to the source, and the source can check whether or not the misrepresentation is being performed by checking with the own MOVE mode determined through the capability confirmation procedure. Alternatively, in the source and content selection procedure in FIG. 8 and the sink and content selection procedure in FIG. 12, the sink correctly understands that content transmission by MOVE is performed, so that COPY transmission is not performed excessively. To.

In the example of the operation sequence shown in FIG. 23, the sink uses the challenge / response performed in the AKE authentication procedure to include information on its own operation mode in the response sent to the source. At this time, it is desirable to include MOVE mode information in the information protected by the signature. The source that received this response is different from the BLOCK MOVE mode that it has set, so that the MOVE mode is misrepresented and the transmission path between the source and sink is exposed to danger. Can do. Then, Source may not send the exchange key K _x to Sink, without initiating the content transmission in such a dangerous transmission path, and ends the MOVE process.

FIG. 24 shows a modification of the operation sequence shown in FIG. In the illustrated sequence example, the sink includes the information of the move mode in the information protected by the signature in the response sent to the source in the AKE authentication procedure. The source receiving this response is different from the BLOCK MOVE mode that it has set, so if it notices that the MOVE mode has been misrepresented, it switches from the BLOCK MOVE mode to the INCREMENTAL MOVE mode, and the exchange key Send K _x to Sink. Then, each of the Source and Sink, create a content encryption key K _c by applying a predetermined arithmetic operation to exchange key K _x, to start encrypting transmission of the content to be MOVE target.

As another method of preventing spoofing MOVE mode, and a method of switching a method of scrambling the exchange key K _x per MOVE mode. FIG. 25 shows an operation sequence example in this case. In the Source side, when performing BLOCK MOVE, use a one-time key used to scramble in the exchange key K _x is treated with a hash function. Then, the sink under the INCREMENTAL MOVE mode cannot share the exchange key K _xM for BLOCK MOVE by the descrambling method for the exchange key K _x . That, Sink, the outside BLOCK MOVE mode is prohibited descrambling for exchange key K _x, can not create the correct content encryption key K _c, it can not decode the MOVE content.

As still another method of preventing spoofing MOVE mode, the method of switching every MOVE mode calculation formula for generating a content encryption key K _c from the exchange key K _x and the like. FIG. 26 shows an operation sequence example in this case. On the Source side, when BLOCK MOVE is performed, the constant included in the calculation formula for generating the content encryption key K _c from the exchange key K _xM is changed to a special value. Then, INCREMENTAL the Sink side under MOVE mode, be calculated from the exchange key K _x according to the normal formula, in other words can not create the correct content encryption key K _c (, exchange key K _xM content encryption key from K _Since it is forbidden to calculate _c ), the moved content cannot be decrypted.

  Therefore, by taking any of the measures described above, even if an illegal proxy is present in the transmission path, a situation that violates the DTCP-IP regulations that valid content exists in both the source and the sink Can be avoided.

  FIG. 16 describes the CAPABILITY_EXCHANGE sequence as a countermeasure against the MOVE transmission mode spoofing attack. However, the countermeasures shown in FIGS. 23 to 26 can sufficiently prevent the MOVE transmission mode spoofing attack. In these cases, the CAPABILITY_EXCHANGE A secure information exchange procedure through a sequence becomes unnecessary.

  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.

  As an application example of the present invention, content transmission using an HTTP protocol performed between a source and a sink can be cited, but the gist of the present invention is not limited to this. Even in any other content transmission system that encrypts and transmits information content that needs to be protected for copyright or other purposes in accordance with the specified copy control information, or a system that does not perform copy control or content encryption The present invention can be similarly applied when moving data between devices without leaving the original data.

  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.

DESCRIPTION OF SYMBOLS 10 ... DTCP-IP authentication block 11 ... AKE block 12 ... Message digest production | generation block 13 ... Content decoding block 20 ... DTCP-IP content reception block 21 ... HTTP client block 22 ... HTTP request management block 23 ... HTTP response management block 30 ... content reproduction / recording block 40 ... DTCP-IP authentication block 41 ... AKE block 42 ... message digest generation block 43 ... content encryption unit lock 50 ... DTCP-IP content transmission block 51 ... HTTP server block 52 ... HTTP request management Block 53 ... HTTP response management block 60 ... Content management block

Claims (72)

A content transmission system for transmitting content between a source for transmitting content and a sink for receiving content,
Content specifying means for specifying content to be transmitted between the source and the sink;
An authentication means for performing mutual authentication and key exchange between the source and the sink;
Content transmission means for encrypting and transmitting the content designated by the content designation means from the source to the sink using the key exchanged by the authentication means;
The content on the sink side is kept in an invalidated state until the content transmission processing is completed, and the content on the sink side is validated in response to the completion of the content transmission processing by the content transmission means. Content transmission end processing means for invalidating the content,
Content transmission processing canceling means for canceling the content transmission processing in response to a request from at least one of Sink and Source until the content transmission processing by the content transmission means is completed;
With
The authentication unit holds a TCP connection for authentication and key exchange until the content transmission end processing by the content transmission end processing unit ends.
The content transmission processing cancellation means cancels the content transmission processing using the TCP connection for authentication and key exchange.
Content transmission system. The content transmission processing cancellation means deletes the content transmitted to the sink when canceling the content transmission processing.
The content transmission system according to claim 1. The authentication means confirms the capability to determine whether both the source and sink are compatible with the processing by the content transmission end processing means in addition to mutual authentication and key exchange.
The content transmission system according to claim 1. The content specifying means is performed using a CDS (Content Directory Service) defined by UPnP,
The authentication unit, the content transmission unit, and the content transmission end processing unit perform each process on a DTCP-IP (Digital Transmission Content Protection-Internet Protocol).
The content transmission system according to claim 1. The sink operated by the user moves the content in the form of downloading the content from the source that operates as a server that provides the content.
The content transmission system according to claim 4. The content designating unit acquires socket information for authentication and key exchange of the content to be moved based on information included in the CDS :: Browse response from the Source for the CDS :: Browse request in the sink and Check if it is possible to move from the source,
The content transmission system according to claim 5. In the sink, the content transmission means includes header information indicating that the content is moved in the header, and acquires encrypted content from the source using an HTTP (Hyper Text Transfer Protocol) GET method.
The content transmission system according to claim 5. The source operated by the user moves the content in the form of uploading the content to the sink operating as the server that provides the content.
The content transmission system according to claim 1. The content designating unit requests creation of a moving location of the content by using CDS :: CreateObject request in the Source, and receives a URI (Uniform Resource Identifier) of the moving location of the content in response to the request. ,
The content transmission means transmits the encrypted content from the source using an HTTP POST method to the URI of the moving location of the received content.
The content transmission system according to claim 8. The content designation means notifies the socket information for authentication and key exchange to the sink using CDS :: CreateObject request in the source,
The authentication means establishes a TCP connection for authentication and key exchange from the sink side based on the socket information.
The content transmission system according to claim 9. The content specifying means performs authentication and key exchange for the sink using the header information of the HTTP POST method (not including the content) for the content destination URI received in response to the CDS :: Create Object request in the source. For socket information for
The authentication means establishes a TCP connection for authentication and key exchange from the sink side based on the socket information.
The content transmission system according to claim 9. In the source, the content transmission means includes the header information indicating that the content is moved in the header, and transmits the encrypted content to the sink using the HTTP POST method.
The content transmission system according to claim 8. The authentication means exchanges a key dedicated to content movement by an AKE procedure for each content to be moved.
The content transmission system according to claim 3. In response to the completion of the content transmission end processing by the content transmission end processing unit, the authentication unit extinguishes the exchange key dedicated to content transfer in the source and sink.
The content transmission system according to claim 13. While the source is moving the content to the sink, the source rejects the transfer request for the content from another sink.
The content transmission system according to claim 1. Sink comprises means for playing content that has been moved from Source and has not yet been activated,
The content transmission system according to claim 1. Content transmission processing stop means for stopping the content transmission processing in response to a request from at least one of the sink and the source when communication between the sink and the source is interrupted until the content transmission processing by the content transmission means ends. Prepare
The content transmission system according to claim 1. The content transmission end processing means is
In response to the transmission of the first command indicating the end of content reception from the sink to the source, the original content on the source side is set to an intermediate invalid state,
The content transmission-only key or first command held on the Sink side is validated while the content transmitted to the Sink side is validated in response to the first response to the first command being returned from the Source to the Sink Erasing the information sent by
In response to the transmission of the second command indicating content validation from the sink to the source, the original content on the source side is invalidated, and the content move-only key held on the source side to the first Erasing the information sent in response 1
The content transmission system according to claim 1. Content transmission for resuming content transmission end processing when processing by the content transmission end processing means is interrupted despite successful completion of content transmission from the source to the sink by the content transmission means An end process restarting unit;
The content transmission system according to claim 18. The content transmission end processing resumption means still holds information sent by the source using the exchange key dedicated to content movement or the first response when the source receives the first command indicating the end of content reception from the sink. In such a case, the original content on the source side is set to an intermediate invalid state, and the first response to the first command is returned from the source to the sink.
The content transmission system according to claim 19. The content transmission end processing resumption means still holds information sent by the source using the exchange key dedicated to content movement or the first response when the source receives the second command indicating the end of content reception from the sink. In this case, the original content on the Source side is invalidated, the content transfer key held on the Source side or the information sent in the first response disappears, and the second command for the second command is sent from the Source to the Sink. Make a response return,
The content transmission system according to claim 19. The content transmission end process resuming means establishes a connection with the source of the content transfer, if the sink still holds the exchange key dedicated to the content transfer or the information sent by the first command, and applies If the content is in an invalid state on the sink side, the source sends the first command, and if the corresponding content is already enabled on the sink side, the second command is sent.
The content transmission system according to claim 19. The content transmission end process restarting means includes means for establishing a connection between a sink and a source for performing the restart process.
The content transmission system according to claim 19. The content transmission end process resuming unit, when resuming the content transmission end process performed in the download format, is based on information included in the CDS :: Browse response from the Source for the CDS :: Browse request in the sink. Obtain socket information for authentication and key exchange, and establish a connection with Source.
The content transmission system according to claim 23. The content transmission end process resuming means uses an HTTP POST method (not including contents) in the source to authenticate and exchange a key exchange socket when resuming the content transmission end process performed in the upload format. Information, and Sink establishes a connection with the Source based on the socket information.
The content transmission system according to claim 23. A spoofing prevention unit for preventing the spoofing of the MOVE transmission confirmed between the source and the sink by the authentication unit;
The content transmission system according to claim 1. The spoofing prevention means changes a method for generating a content encryption key from a key exchanged by the authentication means for each content transmission method.
The content transmission system according to claim 26. The spoofing prevention means changes a method of scrambling the key exchanged by the authentication means for each content transmission method.
The content transmission system according to claim 26. The spoofing prevention means includes information on a content transmission method in a communication message from a sink to a source in a challenge / response procedure for mutual authentication and key exchange.
The content transmission system according to claim 26. A content transmission device that operates as a source that transmits content according to DTCP,
Content specifying means for specifying content to be transmitted to and from the sink;
An authentication means for performing mutual authentication and key exchange with Sink by an AKE procedure;
Content transmission means for encrypting and transmitting the content designated by the content designation means to the sink using the key exchanged by the authentication means;
Content transmission end processing means for invalidating the original content in response to completion of the content transmission processing by the content transmission means, keeping the content on the sink side invalid until the content transmission processing is completed;
Content transmission processing canceling means for canceling the content transmission processing until the content transmission processing by the content transmission means ends;
With
The authentication unit holds a TCP connection for authentication and key exchange until the content transmission end processing by the content transmission end processing unit ends.
The content transmission processing cancellation means cancels the content transmission processing using the TCP connection for authentication and key exchange.
Content transmission device. The content transmission processing cancellation means deletes the content transmitted to the sink when canceling the content transmission processing.
The content transmission apparatus according to claim 30. The authentication means confirms the capability whether or not the sink is compatible with the content transmission end processing means in conjunction with mutual authentication and key exchange.
The content transmission apparatus according to claim 30. When operating as a server that provides content and downloading content to a sink in response to a user operation from the sink side,
In response to the CDS :: Browse request from the sink, the content designating means sets a socket information for authentication and key exchange of each content and a CDS :: Browse response describing whether the content can be moved from the source. Reply,
The content transmission means transmits encrypted content in accordance with an HTTP GET method including header information indicating that the content is moved in the header from the sink.
The content transmission apparatus according to claim 30. When uploading content in response to a user's operation for a sink that operates as a server that provides content,
The content specifying means requests the sink to create the moving location of the content using CDS :: CreateObject request, and receives the URI of the moving location of the content in response to the request from the sink.
The content transmission means includes header information indicating that the content is moved in the header, and transmits the encrypted content to the sink using the HTTP POST method with respect to the URI of the movement location of the received content.
The content transmission apparatus according to claim 30. The content specifying means notifies the socket information for authentication and key exchange to the sink using CDS :: CreateObject request.
The authentication means establishes a TCP connection for authentication and key exchange from the sink side based on the socket information.
The content transmission device according to claim 34. The content designating means uses the header information of the HTTP POST method (not including the content) for the content transfer destination URI received in response to CDS :: Create Object request to the sink for authentication and key exchange. Notify socket information
The authentication means establishes a TCP connection for authentication and key exchange from the sink side from the sink side based on the socket information.
The content transmission device according to claim 34. The authentication means exchanges a key dedicated to moving content by AKE procedure for each content moving to the sink.
The content transmission apparatus according to claim 30. In response to the completion of content transmission by the content transmission means, the authentication means extinguishes a key dedicated to content movement.
The content transmission apparatus according to claim 30. The content transmission means rejects a request to move the content from another sink while moving the content to the sink.
The content transmission apparatus according to claim 30. The authentication unit holds a TCP connection for authentication and key exchange until the content transmission process by the content transmission unit is completed,
A content transmission process canceling unit that cancels the content transmission process using a TCP connection for authentication and key exchange until the content transmission process by the content transmission unit ends;
The content transmission apparatus according to claim 30. A content transmission process stopping unit that stops the content transmission process when communication with the sink is interrupted until the content transmission process by the content transmission unit is terminated;
The content transmission apparatus according to claim 30. The content transmission end processing means is
In response to the reception of the first command indicating the end of content reception from the sink, the original content is set to an intermediate invalid state and a first response to the first command is returned.
In response to receiving the second command indicating content validation from the sink, the original content on the source side is disabled.
The content transmission apparatus according to claim 30. Content transmission end processing for resuming content transmission end processing when processing by the content transmission end processing means is interrupted despite successful completion of content transmission to the sink by the content transmission means Further comprising resumption means,
The content transmission device according to claim 42. The content transmission end process resuming means still holds the information sent by the authentication means using the exchange key dedicated to content movement or the first response when receiving the first command indicating the end of content reception from the sink. In this case, the original content is set to an intermediate invalid state, and a first response to the first command is returned to the sink.
44. The content transmission device according to claim 43. The content transmission end process resuming means still holds the information sent by the authentication means using the exchange key dedicated to content movement or the first response when receiving the second command indicating the end of content reception from the sink. In this case, the original content is invalidated, the content transfer-dedicated key held by the authentication unit is extinguished, and a second response to the second command is returned to the sink.
44. The content transmission device according to claim 43. The content transmission end process restarting means includes means for establishing a connection with the sink for performing the restart process.
44. The content transmission device according to claim 43. When the content transmission end process resuming means restarts the content transmission end process performed in the download format, the CDS: including socket information for authentication and key exchange with respect to the CDS :: Browse request from the sink. : Return a Browse response to establish a connection with the sink.
The content transmission device according to claim 46. The content transmission end process restarting means notifies the sink of authentication and key exchange socket information using the HTTP POST method when restarting the content transmission end process performed in the upload format. Establish a connection,
The content transmission device according to claim 46. Further comprising a spoofing prevention means for preventing a spoofing of MOVE transmission confirmed with the sink by the authentication means;
The content transmission apparatus according to claim 30. The spoofing prevention means changes a method for generating a content encryption key from a key exchanged by the authentication means for each content transmission method corresponding to capability.
50. The content transmission device according to claim 49. The spoofing prevention means changes a method of scrambling the key exchanged by the authentication means for each content transmission method.
50. The content transmission device according to claim 49. A content transmission device that operates as a sink that receives content according to DTCP,
Content specifying means for specifying content to be transmitted to and from the source;
An authentication means for performing mutual authentication and key exchange with the Source by the AKE procedure;
Content transmission means for encrypting and transmitting the content designated by the content designation means from the source using the key exchanged by the authentication means;
Content transmission end processing means that keeps the content invalid until the content transmission processing is finished, and validates the received content in response to the content transmission processing being finished by the content transmission means;
A content transmission process canceling unit for canceling the approved content transmission process until the content transmission process by the content transmission unit is completed;
With
The authentication unit holds a TCP connection for authentication and key exchange until the content transmission end processing by the content transmission end processing unit ends.
The content transmission processing cancellation means cancels the content transmission processing using the TCP connection for authentication and key exchange.
Content transmission device. The authentication means confirms the capability whether or not the sink is compatible with the content transmission end processing means in conjunction with mutual authentication and key exchange.
53. The content transmission device according to claim 52. When downloading content in response to a user operation from a source that operates as a server that provides content,
The content specifying means transmits CDS :: Browse request, acquires socket information for authentication and key exchange of the content to be moved based on information included in the CDS :: Browse response from the Source, and the content is Check if you can move from the source,
The content transmission means includes the header information indicating that the content is moved in the header, and acquires the encrypted content from the source using the HTTP GET method.
53. The content transmission device according to claim 52. When operating as a server that provides content and uploading content in response to user operations from the Source side,
The content specifying means creates a moving location of the content based on the CDS :: CreateObject request received from the source,
The content transmission means receives encrypted content from an Source by an HTTP POST method including header information indicating that the content is moved in the header.
53. The content transmission device according to claim 52. In response to completion of content transmission by the content transmission unit, the authentication unit extinguishes the exchange of keys dedicated to content movement.
53. The content transmission device according to claim 52. Further comprising means for playing content that has been moved from the source and has not yet been activated;
53. The content transmission device according to claim 52. A content transmission process canceling unit that cancels the content transmission process using a TCP connection for authentication and key exchange until the content transmission process by the content transmission unit ends;
53. The content transmission device according to claim 52. The content transmission processing cancellation means invalidates the content transmitted from the source when canceling the content transmission processing.
59. The content transmission device according to claim 58. A content transmission process stopping unit that stops the content transmission process when communication with the source is interrupted until the content transmission process by the content transmission unit ends;
53. The content transmission device according to claim 52. The content transmission end processing means transmits a first command indicating the end of content reception to the source, and is transmitted in response to the first response to the first command being returned from the source to the sink. Validating the content, and extinguishing the information sent by the authentication command with the content movement key or the first command,
53. The content transmission device according to claim 52. Content transmission end processing for resuming content transmission end processing when processing by the content transmission end processing means is interrupted despite successful completion of content transmission with the source by the content transmission means Further comprising resumption means,
The content transmission apparatus according to claim 61. The content transmission end process resuming means establishes a connection with the source if the authentication means still holds the exchange key dedicated to content movement or the information sent by the first command, and the corresponding content is invalidated. If it is in a state, the first command is sent to the source, and if the corresponding content is already activated on the sink side, the second command is sent.
The content transmission device according to claim 62. The content transmission end process resuming means includes means for establishing a connection with a source for performing resumption processing.
The content transmission device according to claim 62. The content transmission end process resuming means, when resuming the content transmission end process performed in the download format, authenticates and keys based on information included in the CDS :: Browse response from the Source for the CDS :: Browse request. Get socket information for exchange and establish connection with Source.
The content transmission apparatus according to claim 64. The content transmission end process resuming means is used for authentication and key exchange notified by using the HTTP POST method (not including the content) from the Source when resuming the end process of the content transmission performed in the upload format. Establish a connection with the Source based on the socket information.
The content transmission apparatus according to claim 64. Further comprising a spoofing prevention unit for preventing the spoofing of the MOVE transmission confirmed with the source by the authentication unit;
53. The content transmission device according to claim 52. The spoofing prevention means includes information on a content transmission method in a communication message to a source in a challenge / response procedure for mutual authentication and key exchange.
68. The content transmission device according to claim 67. A content transmission method for transmitting content as a DTCP Source,
A content designating step for designating content to be transmitted to and from the sink;
An authentication step of performing mutual authentication and key exchange with Sink by an AKE procedure;
A content transmission step of encrypting and transmitting the content designated in the content designation step to the sink using the key exchanged in the authentication step;
A content transmission end processing step for keeping the content on the sink side invalidated until the content transmission processing is completed, and invalidating the original content in response to the completion of the content transmission processing in the content transmission step;
A content transmission process canceling step for canceling the content transmission process until the content transmission process in the content transmission step ends;
Have
In the authentication step, the TCP connection for authentication and key exchange is held until the content transmission end processing in the content transmission end processing step ends.
In the content transmission processing cancellation step, the content transmission processing is canceled using the TCP connection for authentication and key exchange.
Content transmission method. A content transmission method for receiving content as a DTCP Sink,
A content designating step for designating content to be transmitted to and from the source;
An authentication step for performing mutual authentication and key exchange with the source by an AKE procedure;
A content transmission step of encrypting and transmitting the content designated in the content designation step from the source using the key exchanged in the authentication step;
A content transmission end processing step for maintaining the content in a disabled state until the content transmission processing is ended, and enabling the received content in response to completion of the content transmission processing in the content transmission step;
A content transmission process canceling step for canceling the content transmission process until the content transmission process in the content transmission step ends;
Have
In the authentication step, the TCP connection for authentication and key exchange is held until the content transmission end processing in the content transmission end processing step ends.
In the content transmission processing cancellation step, the content transmission processing is canceled using the TCP connection for authentication and key exchange.
Content transmission method. A computer program written in a computer-readable format so as to execute a process for transmitting content as a DTCP Source on a computer, the computer comprising:
Content designating means for designating content to be transmitted to and from the sink;
Authentication means for mutual authentication and key exchange with Sink by AKE procedure,
Content transmission means for encrypting and transmitting the content designated by the content designation means to the sink using the key exchanged by the authentication means;
Until the content transmission process is finished, the content on the sink side is kept invalidated, and content transmission end processing means for invalidating the original content in response to the completion of the content transmission process by the content transmission means,
Content transmission processing canceling means for canceling the content transmission processing until the content transmission processing by the content transmission means ends;
Function as
The authentication unit holds a TCP connection for authentication and key exchange until the content transmission end processing by the content transmission end processing unit ends.
The content transmission processing cancellation means cancels the content transmission processing using the TCP connection for authentication and key exchange.
Computer program. A computer program written in a computer-readable format so as to execute processing for receiving content as a DTCP Sink on a computer, the computer comprising:
Content designating means for designating content to be transmitted to and from the source;
Authentication means for performing mutual authentication and key exchange with the Source by the AKE procedure,
Content transmission means for encrypting and transmitting the content designated by the content designation means from the source using the key exchanged by the authentication means;
Content transmission end processing means that keeps the content invalid until the content transmission processing ends and validates the received content in response to the content transmission processing being completed by the content transmission means,
Content transmission processing canceling means for canceling the content transmission processing until the content transmission processing by the content transmission means ends;
Function as
The authentication unit holds a TCP connection for authentication and key exchange until the content transmission end processing by the content transmission end processing unit ends.
The content transmission processing cancellation means cancels the content transmission processing using the TCP connection for authentication and key exchange.
Computer program.