JP2017130935A - Content provision system and content provision method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To safely transmit content through a remote access (RA) via an external network such as a Wide Area Network (WAN) while exceeding a limit of Round Trip Time (RTT) or Time To Live (TTL).SOLUTION: In Remote Access Authentication and Key Exchange (RA-AKE), limitations on RTT and TTL are removed to realize sharing of a key for remote access between an RA-Source and an RA-Sink. Advance registration of the RA-Sink, restrictions on the number of use and restrictions on the number of the keys to be supplied are imposed to restrict the remote access from an unspecified number of users. In the RA-Source, remote access output is prohibited unless content contains information that the remote access output is available.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a communication system, a communication apparatus, a communication method, and a computer program for preventing unauthorized use in content transmission, and in particular, transmits encrypted content and uses a predetermined mutual authentication key for decrypting encrypted content. And a communication system, a communication apparatus and a communication method, and a computer program that exchange according to a key exchange (AKE) algorithm.

  More specifically, the present invention relates to a communication system for safely transmitting content through remote access (RA) via an external network such as a WAN, restrictions on round-trip delay time (RTT), hop count of IP router (TTL), etc. In particular, the present invention relates to a communication apparatus and a communication method and a computer program for safely transmitting content through remote access, and more particularly to a communication system, a communication apparatus and a communication method, and a computer program.

  Conventionally, broadcast content and content in packaged media are used in places where receiving devices and playback devices are installed, or devices connected to these devices via a home network (hereinafter referred to as “local access ( LA) ") was also basic. For example, a mobile device connected to the above-mentioned receiving device or playback device from outside and using the content with transmission via an external network such as a WAN (Wide Area Network) (hereinafter referred to as “remote access (RA)”) It was difficult from a technical point of view such as a communication channel and a codec. However, in the future, data communication technologies such as LTE (Long Term Evolution) and WiMAX (World Interoperability for Microwave Access), High compression codecs such as H.264 are expected to become widespread, and by using these, the feasibility of remote access can be seen. For example, the user can remotely access the home server from the destination and play the content.

  On the other hand, the digitized content is relatively easy to perform illegal operations such as copying and falsification. In particular, in remote access, there is a need for a mechanism for preventing unauthorized use involved in content transmission, that is, copyright protection, while allowing the use of personal or home content.

  As an industry standard technique regarding transmission protection of digital contents, there is DTCP (Digital Transmission Content Protection) developed by DTLA (Digital Transmission Licensing Administrator). 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 does not send out compressed content that is easy to handle in an unencrypted state outside the device, and the key exchange required to decrypt the encrypted content is a predetermined mutual authentication. And the key exchange (Authentication and Key Exchange: AKE) algorithm, and limiting 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 was originally defined for content transmission on a home network using IEEE 1394 or the like as a transmission path. Recently, as represented by DLNA (Digital Living Network Alliance), a movement to distribute digitized AV contents via an IP network has become serious in the home. Therefore, DTCP technology corresponding to the IP network, that is, DTCP-IP (DTCP mapping to IP) is being developed with the intention of distributing digital contents through the IP network even in the home.

  DTCP-IP is a similar technology in which DTCP technology is ported to an IP network, using an IP network for a transmission path, HTTP (Hyper Text Transfer Protocol) or RTP (Real-Time) for transmission of encrypted content. A content transmission protocol implemented on an IP network, such as Transfer Protocol), is used. 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 (however, When upload transmission is performed, Source becomes an HTTP client and Sink becomes an HTTP server).

  The current DTCP-IP (DTCP Volume 1 Specification Supplementation E Revision 1.2) is mainly intended to ensure the use of content only in the home. For this reason, the round trip time (RTT) is limited to a maximum of 7 milliseconds for the AKE command, and the upper limit of the hop count (TTL: Time To Live) of the IP router is set to 3.

  For example, the source continues to monitor each AKE command received from the start of DTCP-IP authentication to immediately before it ends, updates the maximum value of the TTL value, and sets the TTL value immediately before the authentication procedure ends. The maximum value is checked, and if this maximum value is 3 or less, the key exchange is completed to complete the authentication procedure. If the maximum value is exceeded, a proposal has been made for an information communication system that terminates the authentication procedure without performing the final step. (For example, see Patent Document 1).

  However, if RTT or TTL restrictions are imposed, it is not possible to access copyright-protected content on a home network server in a home from a remote location outside the home.

  Considering the convenience of the user, it would conflict with the content owner's interest to allow remote access to the content but protect the copyright.

JP 2007-36351 A

  An object of the present invention is to provide an excellent communication system and communication capable of suitably preventing unauthorized use in content transmission by exchanging a decryption key of encrypted content in accordance with a predetermined mutual authentication and key exchange (AKE) algorithm. An apparatus, a communication method, and a computer program are provided.

  A further object of the present invention is to allow content to be safely transmitted through remote access via an external network such as a WAN while exceeding limitations such as round trip delay time (RTT) and IP router hop count (TTL). An excellent communication system, communication apparatus and communication method, and computer program are provided.

The present application has been made in consideration of the above-described problems, and the invention according to the first aspect thereof is a communication for content transmission between a content providing device that provides content and one or more content using devices that use content. A communication system for performing
Registration means for registering a content using device that requests content through the first mutual authentication procedure that imposes a restriction on the round-trip delay time of the command in the content providing device;
A transmission means for transmitting the requested content from the content providing apparatus to the content using apparatus registered by the registration means through a second mutual authentication procedure that imposes no restrictions on the round-trip delay time of the command;
A communication system comprising:

  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.

The invention according to the second aspect of the present application is
A registration means for registering a content use device that requests content through a first mutual authentication procedure that imposes a restriction on a round-trip delay time of a command;
A transmission means for transmitting the requested content to the content use device registered by the registration means through a second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command;
It is a communication apparatus which comprises.

  According to the invention of the third aspect of the present application, the registration means of the communication device according to the second aspect further imposes a limit on the number of hops of the IP router during the first mutual authentication procedure, The means is configured not to impose a limit on the number of hops of the IP router in the second mutual authentication procedure.

  According to the fourth aspect of the present invention, the registration unit of the communication apparatus according to the second aspect is configured to limit the number of content use apparatuses to be registered.

  According to the fifth aspect of the present invention, the transmission means of the communication device according to any of the second and fourth aspects allows content transmission among legitimate content utilization devices registered in the registration means. It is configured to set the upper limit of the number of units to be performed.

  According to the sixth aspect of the present application, the transmission means of the communication device according to the fifth aspect is an encryption generated from an exchange key shared between the content using devices through a second mutual authentication procedure. The exchange key that encrypts and transmits the content using the key, and then destroys the corresponding exchange key in response to the discard request issued when the content using device terminates access, and discards the upper limit count of the number of units. It is configured to be reduced according to the number of.

  According to the seventh aspect of the present invention, when the communication apparatus according to the second aspect adds predetermined transmittable information to the content that can be transmitted through the second mutual authentication procedure. The transmission means prohibits transmission of the content to which the transmittable information is not added, but transmits the content to which the transmittable information is added without the transmittable information. .

  According to the invention of the eighth aspect of the present application, the communication device according to the seventh aspect of the present invention is subjected to the first mutual authentication procedure that imposes restrictions on the round-trip delay time of the command, and the transmittable information is added. Second transmission means for transmitting content is further provided.

  According to the ninth aspect of the present invention, the second transmission means of the communication device according to the eighth aspect is a proxy shared between only one content using device through the first mutual authentication procedure. The content is encrypted and transmitted with the transferable information added using the encryption key generated from the exchange key for use, and the substitute use exchange key is issued in response to the destruction request issued by the content use device when the substitution ends. It is configured to be discarded, and two or more proxy exchange keys are generated at the same time, and two or more content utilization devices do not act as a proxy.

  According to the tenth aspect of the present application, the transmission means of the communication device according to the first aspect is configured not to simultaneously transmit the same content to a predetermined number of content utilization devices.

  According to the invention according to the eleventh aspect of the present application, the transmission means of the communication device according to the first aspect uses an exchange key used to generate an encryption key for encrypting content to be transmitted through the second mutual authentication procedure. The content is changed for each content use device as a transmission destination of the content, and the content to be encrypted and transmitted is managed for each content use device so that the same content is not simultaneously transmitted to a predetermined number or more of content use devices. Yes.

  According to the invention of the twelfth aspect of the present application, the communication device according to the first aspect includes a storage unit that records the provided content, and the transmission unit has a predetermined time elapsed after recording in the storage unit. It is configured to allow the transmission of the content after being performed.

The invention according to the thirteenth aspect of the present application is
A registration step of registering a content utilization device that requests content through a first mutual authentication procedure that imposes restrictions on round-trip delay time of the command;
A transmission step of transmitting the requested content to the content utilization device registered by the registration means through a second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command;
Is a communication method.

The invention according to the fourteenth aspect of the present application is
A registration procedure means for performing a registration procedure through a first mutual authentication procedure that imposes a restriction on a round-trip delay time of a command with respect to a content providing apparatus serving as a content request destination;
Content requesting means for requesting content from the content providing apparatus after registration through the second mutual authentication procedure without imposing restrictions on the round trip delay time of the command;
It is a communication apparatus which comprises.

  According to the fifteenth aspect of the present invention, in the communication device according to the fourteenth aspect, the registration procedure by the registration procedure means further imposes restrictions on the number of hops of the IP router during the first mutual authentication procedure. However, when the content request is made by the content requesting means, there is no restriction on the number of hops of the IP router in the second mutual authentication procedure.

According to the sixteenth aspect of the present application, the content requesting means of the communication device according to the fourteenth aspect is
The content encrypted using the encryption key generated from the exchange key shared with the content providing apparatus through the second mutual authentication procedure is received, and when the access to the content providing apparatus ends, the exchange key It is configured to issue a discard request.

  According to the invention according to the seventeenth aspect of the present application, predetermined transmittable information is added to the content that can be transmitted through the second mutual authentication procedure, and the communication device according to the fourteenth aspect is It further includes second content requesting means for requesting the content with the transmittable information added through a first mutual authentication procedure that imposes restrictions on the round-trip delay time of the command.

  According to the invention according to the eighteenth aspect of the present application, the second content requesting means of the communication device according to the seventeenth aspect is a proxy for sharing with the content providing apparatus through the first mutual authentication procedure. Receiving content encrypted with an encryption key generated from an exchange key, to which the transmittable information is added, acting on behalf of the content providing device, and at the end of acting on the content providing device It is configured to issue an exchange key destruction request.

The invention according to the nineteenth aspect of the present application is
A registration procedure step of performing a registration procedure through a first mutual authentication procedure that imposes a restriction on a round-trip delay time of a command for a content providing apparatus serving as a content request destination;
A content requesting step for requesting content from the content providing apparatus after registration through a second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command;
Is a communication method.

The invention according to the twentieth aspect of the present application is a computer program written in a computer-readable format so that processing for providing content via a network is executed on a computer, the computer comprising:
Registration means for registering a content use device that requests content through a first mutual authentication procedure that imposes restrictions on round-trip delay time of the command;
A transmission means for transmitting the requested content to the content use device registered by the registration means through a second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command;
It is a computer program to function as.

The invention according to the twenty-first aspect of the present application is a computer program described in a computer-readable format so that processing for requesting content via a network is executed on a computer, the computer comprising:
A registration procedure means for performing a registration procedure through a first mutual authentication procedure that imposes a restriction on a round-trip delay time of a command with respect to a content providing apparatus serving as a content request destination;
Content requesting means for requesting content from the content providing apparatus after registration through the second mutual authentication procedure without imposing restrictions on the round trip delay time of the command;
It is a computer program to function as.

  Each computer program according to the twentieth and twenty-first aspects of the present application defines a computer program described in a computer-readable format so as to realize predetermined processing on a computer. In other words, by installing each computer program according to the twentieth and twenty-first aspects of the present application on a computer, a cooperative action is exhibited on the computer, and the communication apparatus according to the second and fourteenth aspects of the present application. The same operational effects can be obtained.

The invention according to the twenty-second aspect of the present application is
A first program that describes a first mutual authentication procedure that imposes a restriction on the round-trip delay time of the command, and a second program that describes a second mutual authentication procedure that imposes no restriction on the round-trip delay time of the command A program storage unit for storing;
A program execution unit for executing a program read from the program storage unit;
A content use device storage unit that stores content use device identification information indicating a content use device that requests content after the program execution unit has executed the first program;
A transmission unit that transmits the requested content to a content use device in which content use device identification information is stored in the content use device storage unit after the program execution unit has executed the second program;
It is a communication apparatus which comprises.

  According to the twenty-third aspect of the present invention, the communication device according to the twenty-second aspect further includes a moving image processing auxiliary arithmetic device that compresses or decodes the moving image.

  According to the twenty-fourth aspect of the present application, the moving image processed by the image processing auxiliary arithmetic device of the communication apparatus according to the twenty-third aspect includes the MPEG2, H264, or VC1 algorithm.

  According to the invention of the twenty-fifth aspect of the present application, in the communication device of the twenty-second aspect, the first mutual authentication procedure described by the first program further imposes a limit on the number of hops of the IP router. The second mutual authentication procedure described in the second program may not impose restrictions on the hop count of the IP router.

  According to the invention of the twenty-sixth aspect of the present application, the content utilization device storage unit of the communication device according to the twenty-second aspect is configured to limit the number of content utilization devices that store the content utilization device identification information. Yes.

  According to the twenty-seventh aspect of the present application, the transmission unit of the communication device according to any one of the twenty-second or twenty-sixth aspects is a content use device in which the content use device storage unit stores content use device identification information. Of these, the upper limit of the number of units allowed for content transmission is set.

  According to the invention of the twenty-eighth aspect of the present application, the transmission unit of the communication apparatus according to the twenty-seventh aspect is generated from an exchange key shared between the content using devices through the second mutual authentication procedure. The content is encrypted and transmitted using an encryption key, the corresponding exchange key is discarded in response to a discard request issued by the content utilization device at the end of access, and the upper limit count of the number is discarded. It is configured to decrease accordingly.

  According to the twenty-ninth aspect of the present invention, in the communication device according to the twenty-second aspect, predetermined transmittable information is added to the content that can be transmitted through the second mutual authentication procedure. The transmission unit is configured to prohibit transmission of content to which the transmittable information is not added and transmit the content to which the transmittable information is added without the transmittable information.

  According to the invention of the thirtieth aspect of the present application, the communication apparatus according to the twenty-second aspect is added with the transmittable information through the first mutual authentication procedure that imposes a restriction on the round-trip delay time of the command. A second transmission unit that transmits the content as it is is further provided.

  According to the invention of the thirty-first aspect of the present application, the second transmission unit of the communication apparatus according to the thirty-third aspect is shared among only one content using apparatus through the first mutual authentication procedure. The content is encrypted and transmitted with the transferable information added using an encryption key generated from an exchange key for substitution, and in response to a discard request issued by the one content utilization device at the end of substitution, The proxy exchange key is configured to be discarded.

  According to the thirty-second aspect of the present application, the transmission unit of the communication device according to the twenty-second aspect is configured not to transmit the same content to a predetermined number of content utilization devices at the same time.

  According to the thirty-third aspect of the present invention, the transmission unit of the communication device according to the twenty-second aspect provides an exchange key used for generating an encryption key for encrypting content to be transmitted through the second mutual authentication procedure. Is changed for each content using device that is a content transmission destination, and the content to be encrypted and transmitted is managed for each content using device, so that the same content is not simultaneously transmitted to a predetermined number or more of content using devices. ing.

  According to the thirty-fourth aspect of the present application, the communication device according to the twenty-second aspect includes a content storage unit that records the content to be provided, and the recording unit stores the predetermined content after recording in the content storage unit. It is configured to allow transmission of content after a lapse of time.

  According to the present invention, content can be safely transmitted through remote access via an external network such as a WAN while exceeding limits such as a round trip delay time (RTT) and the number of hops of an IP router (TTL). An excellent communication system, communication apparatus and communication method, and computer program can be provided.

  In the current DTCP-IP and the like, RTT and TTL are restricted in mutual authentication and key exchange procedures, and thus cannot be applied to remote access. On the other hand, according to the first, second, third, thirteenth, fourteenth, fifteenth, thirteenth to twenty-first, and twenty-first to twenty-fifth aspects of the present application, the transmission means does not impose restrictions on RTT or TTL. The content can be transmitted to a content utilization device that remotely accesses the content. In addition, according to the first, second, third, thirteenth, fourteenth, fifteenth, thirteenth to twenty-first and twenty-first to twenty-fifth aspects of the present application, according to the mutual authentication and key exchange procedures in which RTT and TTL are restricted by the registration means. Register the content use device, and the transmission means transmits the content only to the pre-registered content use device, so that remote access from an unspecified number of users is restricted to ensure the copyright protection of the content Can do.

  According to the fourth to sixth, sixteenth and sixteenth to twenty-sixth aspects of the present application, the number of content use devices to be registered is limited, or an exchange key for remote access is registered among the registered content use devices. By limiting the number of handed over, the scale of unauthorized use can be limited. In addition, according to the fourth to sixth, sixteenth, twenty-sixth to twenty-eighth aspects of the present application, in addition to restricting the number of registered items, the number of content use devices that can be registered by restricting the number of content transmissions allowed. Can be set larger than the number of content that can actually be used, and as a result, it is possible to save the trouble of erasing the old registered contents when registering a new content using apparatus.

  Depending on the device specifications, the content using device as the sink may have the function of the content providing device as the source. If the connection relationship between devices having two functions is repeated in a daisy chain format, the range in which content can be transmitted, that is, the scale of unauthorized use, can be expanded infinitely by sequentially registering content utilization devices. Absent. On the other hand, according to the inventions according to the seventh and 29th aspects of the present application, even if the requesting content utilization device is valid and registered in advance, the content to which no transmittable information is added, It is possible to prohibit the transmission by only the second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command so that the content is not provided to the extent that the content provider does not intend.

  According to the seventh and 29th aspects of the present application, when the content providing apparatus does not support content transmission that has undergone the second mutual authentication procedure that does not impose a restriction on the round-trip delay time of the command, the transmission possible information Even if content is added, content transmission through the second mutual authentication procedure that never imposes a restriction on the round-trip delay time of the command will not be performed, and the range in which content can be provided is unduly limited It will be done. On the other hand, according to the eighth, ninth, seventeenth, eighteenth, thirteenth, thirty-first, and thirty-first aspects of the present application, the transmittable information is obtained through the first mutual authentication procedure that imposes restrictions on the round-trip delay time of commands. Since the content can be transmitted as it is added, the content utilization device as the content transmission destination performs the second mutual authentication procedure on behalf of the content provider within the range where the first mutual authentication procedure is possible. It is possible to transmit the content that has passed, and to secure an appropriate range in which the content can be provided. Further, according to the ninth aspect of the present application, the content use device acting as a proxy for content transmission can be limited to only one.

  According to the tenth, eleventh, thirty-second, and thirty-third aspects of the present application, it is possible to reduce fraudulent threats by limiting the number of contents that can be used for remote access at the same time.

  According to the seventh and 29th aspects of the present application, only the content to which the transmittable information is added is permitted to be provided to the content using device by the transmission means. However, if the content is recordable, it can be provided to the content utilization device by writing it on a recording medium and taking it out even if no transmittable information is added. Therefore, as in the invention according to the twelfth and thirty-fourth aspects of the present application, the content after a predetermined time has elapsed since recording in the storage unit can be provided to the content utilization device regardless of the presence or absence of transmittable information. You may do it.

  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 a communication system according to the present invention. FIG. 2 is a diagram schematically showing another configuration example of the communication system according to the present invention. FIG. 3 is a diagram schematically illustrating a functional configuration of the content providing apparatus 10. FIG. 4 is a diagram schematically illustrating a functional configuration of the content use apparatus 20. FIG. 5 is a diagram for explaining a mechanism for performing encrypted content transmission between a source and a sink by DTCP-IP. FIG. 6 is a diagram showing an operation sequence of mutual authentication and key exchange using an AKE command performed between the source and the sink according to the current DTCP-IP. FIG. 7 is a diagram illustrating an example of an authentication sequence when registering an RA-Sink with an RA-Source. FIG. 8 is a flowchart showing the procedure of “RA-Sink Registrain” processing for RA-Source to register RA-Sink. FIG. 9 is a diagram showing an example of an authentication sequence when the RA-Source supplies an exchange key for remote access to the RA-Sink. FIG. 10 is a flowchart showing the procedure of “RA-Sink ID confirmation” processing for the RA-Source to confirm the registration of the RA-Sink and the number of exchange keys supplied for remote access. FIG. 11 is a diagram schematically illustrating an example of a system configuration in which RA-Source and RA-Sink are daisy chain-connected to another device and there is a possibility that the received content is further output. FIG. 12 is a diagram schematically illustrating an example of a system configuration in which RA-Source and RA-Sink are daisy chain connected to another device, and the received content may be further output. FIG. 13 is a diagram schematically illustrating an example of a system configuration in which RA-Source and RA-Sink are daisy chain connected to another device and there is a possibility that the received content may be further output. FIG. 14 is a diagram showing an example of an authentication sequence when DEP-RA-AKE is performed and Source # 0 shares a key only with Sink # 1. FIG. 15 is a flowchart showing a procedure of a “DEP_RA-Sink Configuration” process in which the Source authenticates the proxy for content remote access output to the Sink. FIG. 16 is a diagram illustrating an operation sequence when the RA-Sink requests content from the RA-Source when the number of RA-Sinks that simultaneously transmit the same content is limited. FIG. 17 is a flowchart showing a processing procedure for managing the number of outputs of the same content, which A-Source executes in response to a request for content data. FIG. 18 is a flowchart illustrating a processing procedure for a device operating as an RA-Source to record content or capture the content using the MOVE function. FIG. 19 is a diagram illustrating an operation sequence when the RA-Sink requests content from the RA-Source. FIG. 20 is a flowchart showing the processing procedure of content remote access (RA) output number management 1. FIG. 21 is a diagram showing an operation sequence when the sink requests content for proxying remote access to the source. FIG. 22 is a flowchart showing a processing procedure of content remote access output proxy management. FIG. 23 is a diagram for explaining an example of a method for preventing falsification of the RA-flag. Specifically, the RA-flag value is input to a function for calculating an encryption key, and the encryption key K _c is input. It is the figure which showed the method of reflecting in the value of. FIG. 24 is a diagram for explaining an example of a method for preventing falsification of the RA-flag. Specifically, information transmitted in plain text including the RA-flag is represented by a hash function using the information and the encryption key. It is the figure which showed the method of calculating | requiring and obtaining signature data. FIG. 25 is a diagram for explaining an example of a method for preventing RA-flag tampering. Specifically, FIG. 25 is a diagram illustrating a storage destination when an RA-flag is encrypted together with content data. FIG. 26 is a diagram for explaining an example of a method of preventing RA-flag tampering. Specifically, FIG. 26 is a diagram illustrating a storage destination when the RA-flag is encrypted together with content data. FIG. 27 is a flowchart showing a processing procedure for the RA-Source to update the RA-flag and T set in the content. FIG. 28 is a diagram illustrating a configuration example of an AKE control command for remote access. FIG. 29 is a diagram illustrating a configuration example of a personal computer applied to the content providing apparatus. FIG. 30 is a diagram illustrating a configuration example of a recorder applied to the content providing apparatus.

  The present invention relates to a communication system for securely transmitting content through remote access (RA) via an external network such as a WAN. The communication system basically includes a server (RA-Source) that provides content by remote access and a client (RA-Sink) that requests content by remote access. In this specification, the AKE procedure performed at the time of remote access is referred to as “RA-AKE”. Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 schematically shows a configuration example of a communication system according to the present invention. In the illustrated communication system, a content providing device 10 corresponding to RA-Source is installed in a home, and a content using device 20 corresponding to RA-Sink is outdoors. Then, the content use device 20 remotely accesses the content providing device 10 by a communication function such as a mobile phone.

  The content providing apparatus 10 is generally connected to an external network such as the WAN 50 via the router 30 and the modem 40. The WAN 50 is, for example, the Internet. An IP address on the WAN 50 side is assigned to the router 30 from an Internet Access Service (IAS) provider 60 to which a user subscribes. Also, the content utilization device 20 basically accesses this IP address. The router 30 assigns a private IP address to the content providing apparatus 10, and relays communication by port forwarding for access from the WAN 50. Note that the IP address assigned to the router 30 may be updated by the IAS provider 60. In such a case, the DDNS service 70 is used, and the DNS 30 (Dynamic DNS (Domain Name System) of the router 30 to the content providing apparatus 10 is used. )) Can be supported by using the function.

  FIG. 2 schematically shows another configuration example of the communication system according to the present invention. In the illustrated communication system, a content utilization device 20 corresponding to RA-Sink is also installed in the home and connected to the WAN 50 via a router 31 and a modem 41. The TCP / IP (Transmission Control Protocol / Internet Protocol) communication transmitted from the content use device 20 is address-converted by the NAT (Network Address Translation) function of the router 31, but the rest is the same as in FIG. .

  FIG. 3 schematically shows a functional configuration of the content providing apparatus 10. The content providing apparatus 10 includes a CPU (Central Processing Unit) 11, a content reception / playback unit 12, a communication unit 13, a storage unit 14, and a timer 15, but functions as an RA-Source for remote access. Send content with.

  The content reception / playback unit 12 has a broadcast reception function and a package media playback function. The CPU 11 appropriately protects the content obtained by the content receiving / reproducing unit 12 that can be remotely accessed, and then performs mutual authentication and key exchange by RA-AKE through the communication unit 13. (Content use device 20).

  In the storage unit 14, the RA-Sink identification information that is to be stored by the registration process described later, the remote access exchange key shared with the RA-Sink through the RA-AKE, the identification information of the exchange key, and the like Is memorized. The storage unit 14 can also be used for storing contents obtained by the content receiving / reproducing unit 12.

  The timer 15 is used when time management is required when handling remotely accessible content (for example, when managing a remote access ineffective period from a reference point time as described later).

  FIG. 4 schematically shows a functional configuration of the content use apparatus 20. The content use device 20 includes a CPU 21, a communication unit 22, a content output unit 23, and a storage unit 24, but functions as an RA-Sink and receives content by remote access.

  The content utilization device 20 as an RA-Sink performs device registration processing to be described later for the RA-Source (content providing device 10) through the communication unit 22, and performs RA-AKE to obtain an exchange key from the RA-Source. Then, the encrypted content obtained from the RA-Source is decrypted with the encryption key calculated based on the key, and the content is output from the content output unit 23. The storage unit 24 is used for storing an exchange key and content received from the RA-Source.

  In the following description, the method for calculating the encryption key from the exchange key is based on DTCP-IP (however, the gist of the present invention is not necessarily limited to this method).

  Here, a mechanism for performing encrypted content transmission by DTCP-IP between the source and the sink will be described with reference to FIG. 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 (well-known). The explanation is based on the method.

The Source and Sink first establish one TCP / IP connection and perform authentication (AKE procedure) between devices. A device certificate issued by DTLA (described above) is embedded in the DTCP-compliant device. In the AKE 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, it is possible to generate a content key K _c which is used to encrypt content when the content transmission.

  Then, after an authentication and key exchange procedure by AKE is completed between DTCP-compliant devices, content transmission is started using a protocol such as HTTP or RTP. In the illustrated example, content transmission is performed according to the HTTP procedure. At this time, a TCP / IP connection for HTTP is created separately from the TCP / IP connection for the AKE procedure (that is, Source and Sink have separate socket information (for the AKE procedure and content transmission, respectively) IP address and port number combination)).

  There are two ways to perform content transmission according to the HTTP protocol: a download format in which Sink requests content from the source, and an upload format in which content is pushed from the source side to the sink. In the former case, the sink as the HTTP client requests content from the source as the HTTP server by, for example, an HTTP request using the HTTP GET method, and the requested content is transmitted as an HTTP response from the source. The In the latter case, the Source as the HTTP client starts transmission with the Sink as the HTTP server, for example, by an HTTP request using the HTTP POST method.

The data transmitted from the source is data obtained by encrypting the content using a key shared after the source performs AKE authentication. Specifically, the source generates a nonce N _c using a random number, and generates a content key K _c corresponding to the exchange key K _x , the nonce N _c, and the encryption mode. Then, the content requested by the Sink, encrypted using the content key K _c, the packet comprising a header including the information of payload and nonce N _c and the encryption mode consisting encrypted content placed on TCP stream Send. In the IP protocol, a TCP stream is divided into packet sizes as a predetermined unit, further converted into an IP packet with a header added, and delivered to a designated IP address.

On the sink side, when each IP packet is received from the source, it is assembled into a TCP stream. When the nonce N _c and E-EMI are extracted from this stream, the content key K _c can be calculated using these and the exchange key K _x , and the encrypted content can be decrypted. Then, the reproduction processing can be performed on the plaintext content after decryption. Alternatively, the sink stores the content in the storage unit 24 or passes it to another device without decrypting the encrypted content. 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. (In DTCP-IP, transmission of copy control information associated with content is realized by two mechanisms, E-EMI (Extended Encryption Mode Indicator) and Embedded CCI (Copy Control Information) described in the header of the packet. .)

Note that DTCP-IP stipulates that the continuous non-use time is discarded before a predetermined period (for example, 2 hours) is exceeded. Sink is to be able to get the latest exchange key K _x from the Source, it becomes unavailable the encrypted content. In addition, the method of operation of the exchange key K _x, there is a method to use and how to prepare a one-by-one key for each Sink, one of the key regardless of the Sink.

  FIG. 6 shows an operation sequence (RTT-AKE) of mutual authentication and key exchange using the AKE command performed between the source and the sink according to the current DTCP-IP.

  In the challenge-response portion of AKE procedure, an Rx challenge including an Rx random number and an Rx certificate is first transmitted from a sink requesting content. In response to this, a Tx challenge including a Tx random number and a Tx certificate is returned from the source. Thereafter, the Rx response including the Rx random number, the Tx message, and the Tx signature is transmitted from the source, and the Tx response including the Tx random number, the Rx message, and the Rx signature is transmitted from the sink. The procedure continues. In the command transmitted in the challenge / response portion, each challenge command includes a Device ID that is identification information unique to the device.

  In the above challenge / response response procedure, TTL (IP router hop count) is restricted. That is, in the current DTCP-IP, in the TCP / IP communication in which the sending device sends a command used in AKE, the TTL is set to 3 or less, and when the TTL is larger than 3, the receiving device must invalidate the received data. .

  Thereafter, an EXCHANGE_KEY command is transmitted from the source to the sink through the RTT protection protocol (protected RTT protocol), and a response (not shown) is returned from the sink.

  In the RTT-AKE according to the current DTCP-IP shown in FIG. 6, the round-trip delay time (RTT) and the number of hops (TTL) of the IP router are limited for the AKE command. It cannot be applied (mentioned above). However, considering the convenience of the user, it is desired that the user remotely access the home server from the destination and play the content. Of course, it is necessary to secure the interest of the content owner who wants to protect the copyright. Therefore, remote access should be limited to the range of content allowed by the content owner, and the content accessed remotely must also be protected.

  On the other hand, in the AKE procedure at the time of remote access proposed as the present invention, that is, RA-AKE, the “Protected RTT Protocol” performed in the RTT-AKE procedure shown in FIG. 6 is not performed. That is, even if the RTT between the source and the sink exceeds 7 milliseconds, the AKE procedure is not canceled. In RA-AKE, the above TTL upper limit is not provided. In other words, in RA-AKE, the RTT and TTL restrictions are not provided, so that the source (content providing apparatus 10) corresponding to remote access and the sink (content using apparatus 20) corresponding to remote access are delayed in response. Even if the time exceeds 7 milliseconds or is separated by more than 3 hops, the AKE procedure can be successfully executed between both devices to share the exchange key for remote access. it can.

  However, in a communication system in which the restrictions on RTT and TTL are removed, content can be transmitted between arbitrary devices, and thus a mechanism for preventing unauthorized use from the viewpoint of copyright protection of content is required. .

  One of the unfair use methods associated with the absence of restrictions on RTT and TTL in the RA-AKE procedure is the unspecified number of users (in other words, beyond the scope of private use permitted by copyright law). It is conceivable that each user's RA-Sink is connected to a specific user's RA-Source and the content is used remotely. Therefore, it is necessary to restrict connections from an unspecified number of users.

  In order to limit connections from an unspecified number of users, a method of performing RA-AKE procedures only with RA-Sinks in which RA-Source has been registered in advance, and the number of RA-Sinks that pass keys in RA-AKE procedures A method of limiting the above is conceivable. Regarding the former pre-registration, the RA-Source stores the device-specific ID of the RA-Sink only when the AKE procedure with the RTT or TTL restriction is successful like the current DTCP-IP RTT-AKE. This prevents an unspecified number of users from succeeding in the RA-AKE procedure.

  Moreover, the scale of unauthorized use can be limited by limiting the number of RA-Sinks registered in the RA-Source. In the following, it is assumed that the RA-Source includes an “RA registry” (in the storage unit 14) for registering the IDs of RA-Sinks up to a predetermined number. Here, even if the device-specific ID of the RA-Sink can be registered in the RA-Source, the number of RA-Sinks that supply an exchange key for remote access at the time of content transmission, as will be described later By limiting, the scale of unauthorized use can be limited.

  The RA-Sink registration procedure is performed in advance in a home that falls within the limits of RTT and TTL, for example. At that time, RA-Source may register a large number of ten RA-Sinks. Even if ten RA-Sinks are pre-registered with the RA-Source, only up to five of these RA-Sources will be given a remote access exchange key.

  FIG. 7 shows an example of an authentication sequence when registering an RA-Sink with an RA-Source.

  This authentication sequence starts when the RA-Sink sends a registration request command “RA_REGI_INIT” to the RA-Source. In the challenge-response portion of AKE of the RA-AKE procedure, first, an Rx challenge including an Rx random number and an Rx certificate is transmitted from the RA-Sink. On the other hand, a Tx challenge including a Tx random number and a Tx certificate is returned from the RA-Source. Thereafter, the Rx response including the Rx random number, the Tx message, and the Tx signature is transmitted from the RA-Source, and the Tx response including the Tx random number, the Rx message, and the Rx signature is transmitted from the RA-Sink. Note that instead of transmitting “RA_REGI_INIT”, information corresponding to transmission of “RA_REGI_INIT”, for example, “RA_REGI_INIT_flag” may be included in the information transmitted as the Rx challenge.

  Each challenge command includes a Device ID that is identification information unique to the device. However, in the challenge / response portion, “RESPONSE2” may be sent as a response from the sink to the source. This is a case where the device ID is not unique to the device by mounting the common device key and the common device certificate. When RESPONSE2 is sent, IDu, which is device-specific information included in RESPONSE2, is used as device-specific identification information, instead of Device ID.

  The challenge / response part of the RA-AKE procedure in the registration procedure is the same as the RTT-AKE procedure in the current DTCP-IP, and TTL restrictions are imposed. Thereafter, the RTT protection protocol (Protected RTT Protocol) continues, and when the RTT between the RA-Source and the RA-Sink exceeds 7 milliseconds, the RA-AKE procedure is stopped.

  The RA-Source executes an “RA-Sink Register” process for registering an RA-Sink that has succeeded in the procedure so far. The RA-Source additionally registers the RA-Sink ID in the RA registry in the storage unit 14 if there is room to register the RA-Sink, and notifies the RA-Sink of the result using a command “RA_REGI_END” that sends a result code. .

  Note that “RA_REGI_INIT” and “RA_REGI_END” in FIG. 7 are added to the DTCP-IP AKE control command as remote access commands. FIG. 28 shows a configuration example of an AKE control command for remote access. In the illustrated example, a new value is assigned to the subfunction field, and information can be carried by AKE_Info.

  FIG. 8 shows the procedure of “RA-Sink Registrain” processing for RA-Source to register RA-Sink in the form of a flowchart.

  The RA-Source first checks whether or not the processing (Challenge-Response port of AKE and Protected RTT Protocol) prior to the start of the processing routine has ended abnormally (step S1).

  Here, if the previous process has ended abnormally (No in step S1), the RA-Source notifies the request source RA-Sink of a result code indicating that the registration process has failed. (Step S9), and this processing routine is terminated.

  If the previous process has been completed normally (Yes in step S1), the RA-Source checks whether RESPONSE2 (described above) has been received (step S2). When RESPONSE2 is received (Yes in Step S2), the RA-Source sets the ID of the requesting RA-Sink as IDu (Step S3). When RESPONSE2 has not been received (No in step S2), the RA-Source uses the device ID of the requesting RA-Sink as an ID (step S4).

  Next, the RA-Source checks whether or not the ID of the requesting RA-Sink has already been registered in the RA registry (step S5).

  If the requesting RA-Sink ID has already been registered in the RA registry (Yes in step S5), the RA-Source performs “success” in the registration process for the requesting RA-Sink. The result code indicating that it has been sent is notified (step S8), and this processing routine is terminated.

  On the other hand, when the requesting RA-Sink ID has not yet been registered in the RA registry (No in step S5), the RA-Source subsequently determines whether or not there is a free space in the RA registry in the storage unit 14. Check (step S6).

  Here, if there is no free space in the RA registry (No in step S6), the RA-Source notifies the request source RA-Sink of a result code indicating that the registration process has failed (step S6). S9) This processing routine ends.

  If there is a free space in the RA registry (Yes in step S6), the RA-Source additionally registers the RA-Sink ID in the RA registry (step S7). Then, the RA-Source notifies the request source RA-Sink of a result code indicating “success” in the registration process (step S8), and ends this processing routine.

  As described with reference to FIG. 7 and FIG. 8, if the RA-Source succeeds in the same authentication procedure as RTT-AKE, it additionally registers if there is room to register the RA-Sink ID in the RA registry. In order to remotely access the RA-Source, the RA-Sink needs to register its own ID in the RA registry of the RA-Source through the above authentication procedure. Therefore, RA-Source can limit the scale of unauthorized use of content by limiting the number of RA-Sinks that can use RA-Source depending on the number of RA registries that can be registered.

  FIG. 9 shows an example of an authentication sequence when the RA-Source supplies an exchange key for remote access to the RA-Sink. The sequence shown in the figure has a mechanism for limiting the number of RA-Sinks that supply an exchange key for remote access.

  This authentication sequence starts when the RA-Sink sends a key supply request command “RA_AKE_INIT” to the RA-Source. In the challenge-response portion of AKE of the RA-AKE procedure, first, an Rx challenge including an Rx random number and an Rx certificate is transmitted from the RA-Sink. In contrast, RA-Source returns a Tx challenge including a Tx random number and a Tx certificate. Thereafter, the Rx response including the Rx random number, the Tx message, and the Tx signature is transmitted from the RA-Source, and the Tx response including the Tx random number, the Rx message, and the Rx signature is transmitted from the RA-Sink. Note that instead of transmitting “RA_AKE_INIT”, information corresponding to transmission of “RA_AKE_INIT”, for example, “RA_AKE_INIT_flag” may be included in the information transmitted as the Rx challenge.

  Each challenge command includes a Device ID that is identification information unique to the device. However, in the challenge / response portion, “RESPONSE2” may be sent as a response from the sink to the source. In this case, IDu included in the RESPONSE2 instead of the device ID is used as the device-specific identification information. Will be used (same as above).

  The TTL restriction is necessary when registering with the RA-Source, but is omitted in the RA-AKE procedure for supplying the exchange key for remote access. The RTT protection protocol (Protected RTT Protocol) is also omitted in the RA-AKE procedure for key supply. As a result, the RA-Sink can request an exchange key for remote access even in a remote environment, that is, the content can be used by remote access.

When the above authentication procedure is successful, the RA-Source executes the “RA-Sink ID confirmation” process. In this process, the RA-Source confirms that the requesting RA-Sink ID has been registered in the RA registry, and the number of remote access exchange keys supplied (KC) does not exceed the upper limit. To check. Then, RA-Source is, RA if could these checks, the exchange key for remote access (RA_K _x), the ID (RA_K _x _label) and result code of the exchange key, the command "RA_EXCHANGE_KEY" -Pass to Sink.

  Note that the upper limit of the number KC of remote access exchange key supplies is set equal to or less than the number of IDs that can be registered in the RA registry in the storage unit 14. That is, in addition to limiting the scale of unauthorized use of content by limiting the number of pre-registered items, it is possible to further limit the scale of unauthorized use by limiting the number of RA-Sinks that can be used by the upper limit of KC. . In addition to limiting the number of registrations in the RA registry, by setting an upper limit for KC, the number of RA-Sinks that can be registered in RA-Source is set larger than the number of RA-Sinks that can use content. As a result, it is possible to save the trouble of deleting the old registration contents when registering a new RA-Sink.

  The exchange key supply number KC for remote access is the number of valid exchange keys delivered from the RA-Source to the RA-Sink. Therefore, KC is zero in an initial state where no exchange key is passed to any RA-Sink, and when the passed exchange key is discarded by the RA-Source, the amount can be reduced.

  Here, when the upper limit of KC is 2 or more, there are two methods for operating the exchange key for remote access: a method of preparing one key for each RA-Sink, and one key regardless of RA-Sink. There is a method to use. In the former case, if one exchange key is discarded, KC is reduced by one. In the latter case, if the exchange key is discarded, KC is reset to zero.

Regarding the destruction of (RA_K _x ) of the exchange key for remote access, it is conceivable to operate according to the rule of discarding before the continuous non-use period exceeds a predetermined period, as in DTCP-IP. In addition, an operation mode in which the RA-Sink sends a command (RA_FINISH) for requesting the destruction of the exchange key together with the exchange key ID (RA_K _x _label) at the end of the remote access is also conceivable. The discard request command RA_FINISH is added as a remote access command to the DTCP-IP AKE control command together with “RA-AKE_INIT” and “RA_EXCHANGE_KEY” in FIG.

  FIG. 10 shows the procedure of “RA-Sink ID confirmation” processing in the form of a flowchart for the RA-Source to confirm the registration of the RA-Sink and the number of exchange keys supplied for remote access.

  First, the RA-Source checks whether or not the processing (Challenge-Response port of AKE, Protected RTT Protocol) prior to starting the processing routine has ended abnormally (step S11).

  Here, if the previous process has ended abnormally (No in step S11), the RA-Source interrupts the RA-AKE procedure for the requesting RA-Sink (step S20), The processing routine ends.

  If the previous processing has been completed normally (Yes in step S11), the RA-Source checks whether RESPONSE2 has been received (step S12). When RESPONSE2 is received (Yes in step S12), the RA-Source sets the ID of the requesting RA-Sink as IDu (step S13). When RESPONSE2 has not been received (No in step S12), the RA-Source uses the device ID of the requesting RA-Sink as an ID (step S14).

  Next, the RA-Source checks whether the requesting RA-Sink ID has already been registered in the RA registry in the storage unit 14 (step S15).

  Here, when it cannot be confirmed that the requesting RA-Sink ID is registered in the RA registry (No in step S15), the RA-Source performs an RA-AKE procedure on the requesting RA-Sink. The process is interrupted (step S20) and this processing routine is terminated.

  On the other hand, when it is confirmed that the ID of the requesting RA-Sink has been registered in the RA registry (Yes in step S15), the RA-Source subsequently supplies the number KC of exchange keys for remote access. Is less than the upper limit value (step S16).

When it is confirmed that the number of supplied remote access key KC is less than the upper limit (Yes in step S16), the RA-Source increments KC by 1 (step S17) and confirms. The result code indicating “success” in the process is notified to the RA-Sink of the request source together with the remote access exchange key (RA_K _x ) and its ID (RA_K _x _label) (step S19). End the routine.

  When the key supply number KC has reached the upper limit (No in Step S16), the RA-Source notifies the request source RA-Sink of a result code indicating “busy” (Step S16). S18) This processing routine is terminated.

  When an exchange key for remote access is shared between the RA-Source and RA-Sink, content transmission by remote access is possible. FIG. 19 shows an operation sequence when the RA-Sink requests content from the RA-Source. However, in the figure, it is assumed that the content is requested from the RA-Sink to the RA-Source according to the HTTP protocol, and the content is transmitted in the download format.

The RA-Sink acquires the remote access exchange key (RA_K _x ) and its ID (RA_K _x _label) by the RA-AKE procedure shown in FIG. 9, and then uses the HTTP GET method to make an HTTP request (HTTP GET). request) to request content data from the RA-Source. At the time of the request, along with the URL of the content, and sends the exchange key ID for remote access output (RA_K _x _label). We define a header field for sending RA-Sink from the exchange key to the _{RA-Source ID (RA_K x _label} ).

  When the RA-Source receives a request for content data, the RA-Source executes “content remote access (RA) output management 1” processing for checking the number of remote access outputs of the requested content. If it is confirmed that the content of the URL specified by the request can be output by remote access, the RA-Source uses the remote access exchange key specified by the exchange key ID to obtain the encryption key. The content calculated and encrypted using this encryption key is returned as an HTTP response (HTTP GET response).

  FIG. 20 shows a processing procedure of content remote access (RA) output management 1 performed by RA-Source in the form of a flowchart.

  First, the RA-Source checks whether or not the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (step S51).

  Here, when the exchange key indicated by the exchange key ID included in the HTTP request is not for DTCP-IP (No in step S51), RA-Source subsequently determines whether the exchange key is for remote access. Is checked (step S52).

  If the exchange key is for remote access (Yes in step S52), the RA-Source checks whether the content specified by the URL included in the HTTP request is accessible remotely (step S53). ). Whether or not the content can be accessed remotely can be managed using, for example, RA-flag (described later).

  Then, when the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (Yes in step S51), it has been found that the content specified in the HTTP request can be accessed remotely. In such a case (Yes in step S53), the RA-Source determines that the response to the HTTP request (HTTP GET request) from the RA-Sink is OK (step S54), and ends this processing routine.

  On the other hand, when the exchange key indicated by the exchange key ID included in the HTTP request is not for remote access (No in step S52), or when the content specified in the HTTP request is not remotely accessible (step S53). No), RA-Source sets the response to the HTTP request (HTTP GET request) from RA-Sink as an error (step S55), and ends this processing routine.

  In the description so far, it has been assumed that the communication system includes only a pair of RA-Source and RA-Sink. However, RA-Source and RA-Sink are each connected to another device in a daisy chain format and may transmit content. The transmission range of copyright-protected content should be originally kept in the home, and it is not preferable that the content is repeatedly received and retransmitted in many steps. For this reason, it is necessary to technically prevent the reception and retransmission of content. In the present embodiment, some rules are further provided in order to make restrictions on RTT and TTL at the time of registration and restrictions on the number of keys supplied more strictly.

  In the system configuration example shown in FIG. 11, RA-Sink # 1 connected to RA-Source # 0 further has a function as RA-Source # 1 and is connected to another device RA-Sink # 2. In such a case, the content provider can prohibit the remote access output from RA-Sink # 1 to the RA-Sink # 2 again as the content received by remote access as RA-Sink # 1. It operates so as to prevent remote access where it is not possible to manage certain RA-Source # 0.

  In the system configuration example shown in FIG. 12, RA-Sink # 1 is connected to RA-Source # 0 by remote access, and also has a function as Source # 1, and another device Sink # 2 by DTCP-IP. Furthermore, Sink # 2 has a function as RA-Source # 2 and is connected to another device RA-Sink # 3. The RA-Sink # 1 can locally transmit the content received by remote access to another device Sink # 2 through DTCP-IP. The local transmission by DTCP-IP is in accordance with the copyright protection mechanism, and there is no problem. Further, by prohibiting the content received by Sink # 2 from being remotely accessed and output again to RA-Sink # 3 as RA-Source # 2, the management of RA-Source # 0, which is the content provider, is extended. Operate to prevent remote access in the absence.

  The system operation described with reference to FIGS. 11 and 12 basically means that the device prohibits remote access output of content received by remote access or local transmission by DTCP-IP, and the content provider does not intend. It is to prevent remote access. One method for realizing such operation is to provide the following provisions (1) and (2) at the time of remote access output of content and local transmission.

(1) RA-Source does not perform remote access output unless the content is accompanied by information indicating that “remote access output is possible”.
(2) RA-Source and Source do not send information indicating whether or not remote access output is possible during remote access or local transmission by DTCP-IP.

  In the system configuration example shown in FIG. 13, Sink # 1 connected to Source # 0 by DTCP-IP also has a function as RA-Source # 1, and is connected to another device RA-Sink # 2. Source # 0 can locally transmit content to Sink # 1 only through DTCP-IP. The local transmission by DTCP-IP is in accordance with the copyright protection mechanism, and there is no problem. Here, when the restrictions (1) and (2) are imposed, Sink # 1 can again output the received content as RA-Source # 1 to RA-Sink # 3 again. Disappear.

  In this case, it is possible to prevent remote access output where the content provider cannot manage. However, even if the content is accompanied by information indicating that “remote access output is possible”, remote access is never possible. It will not be output. On the other hand, the inventors of the present invention have found that RA-Source # 1 receives the content received from Source # 0 by local transmission through DTCP-IP as Sink # 1, and uses another device RA-Sink instead of Source # 0. I think that it is not necessary to prohibit the operation of outputting remote access to # 2 (that is, substituting the remote access output). The operation of acting as a remote access output performs DEP-RA-AKE, Source # 0 shares the key only with Sink # 1, and Sink # 1 encrypts and transmits the content using the key, This can be realized by remote access output from RA-Source1.

  FIG. 14 shows an example of an authentication sequence when DEP-RA-AKE is performed and Source # 0 shares the key only with Sink # 1.

  This authentication sequence starts when Sink # 1 transmits a key supply request command “DEP_RA_INIT” to Source # 0. In the challenge-response portion of AKE procedure, first, an Rx challenge including an Rx random number and an Rx certificate is transmitted from Sink # 1. On the other hand, a Tx challenge including a Tx random number and a Tx certificate is returned from Source # 0. Thereafter, an Rx response including an Rx random number, a Tx message, and a Tx signature is transmitted from Source # 0, and a Tx response including a Tx random number, an Rx message, and an Rx signature is transmitted from Sink # 1. Note that instead of transmitting “DEP_RA_AKE”, information corresponding to transmission of “DEP_RA_AKE”, for example, “DEP_RA_AKE_flag” may be included in the information transmitted as the Rx challenge.

  Each challenge command includes a Device ID that is identification information unique to the device. However, in the challenge / response portion, “RESPONSE2” may be sent as a response from the sink to the source. In this case, IDu included in the RESPONSE2 instead of the device ID is used as the device-specific identification information. Will be used (same as above).

  Since the AKE procedure is implemented through DTCP-IP, TTL restrictions are imposed. Moreover, the RTT protection protocol (Protected RTT Protocol) is further continued. The remote access output proxy procedure DEP-RA-AKE should be performed only in the local environment, and RTT and TTL are imposed in the same way as RTT-AKE in the current DTCP-IP.

Then, when the above authentication procedure is successful, Source # 0 executes a “DEP_RA-Sink Configuration” process. In this process, the Source # 0 shares the key only with the Sink # 1, and prevents the DEP-RA-AKE from being executed with other devices. Then, Source # 0, when it was confirmed that share key only with Sink # 1, exchange key for remote access output proxy (D-RA_K _x) and its ID (D-RA_K _x _label) results The code is passed to Sink # 1 with the command “DEP-RA_EXCHANGE_KEY”.

  Source # 0 prevents this DEP-RA-AKE from being executed with another device until the key shared by AKE is subsequently discarded. On the sink # 1 side, the content is encrypted and transmitted with the information “remote access output is possible” using the remote access output proxy exchange key that can be shared through the processing procedure. Then, Sink # 1 can remotely access and output the content to RA-Sink # 2 as RA-Source # 1.

  FIG. 15 shows the procedure of the “DEP_RA-Sink Configuration” process in which the Source authenticates the proxy for the remote access output of the content to the Sink in the form of a flowchart.

  First, the source checks whether or not the processing (Challenge-Response port of AKE, Protected RTT Protocol) before starting the processing routine has ended abnormally (step S21).

  Here, if the previous processing has ended abnormally (No in step S21), the Source interrupts the DEP_RA-Sink procedure for the requesting sink (step S30), and ends this processing routine. To do.

  If the previous processing has been completed normally (Yes in step S21), the source checks whether or not RESPONSE2 has been received (step S22). When RESPONSE2 is received (Yes in step S22), the source sets ID of the requesting sink as IDu (step S23). When RESPONSE2 is not received (No in step S22), the Source uses the device ID of the requesting sink as an ID (step S24).

  Next, the source checks whether or not its DEP_RA registry is empty (step S25). The DEP_RA registry is a registry prepared in the storage unit 14 in order to hold the ID of a single device that permits remote access output of content.

Here, when it is confirmed that the DEP_RA registry is empty (Yes in step S25), the source substitutes the ID of the requesting sink into the DEP_RA registry (step S26). Then, the source passes the exchange key (D-RA_K _x ) for the remote access output proxy, its ID (D-RA_K _x _label), and the result code to the sink # 1 with the command “DEP-RA_EXCHANGE_KEY” (step S1). S29) This processing routine is terminated.

  If the DEP_RA registry is not empty (No in step S25), the source further checks whether the ID held in the DEP_RA registry matches the ID of the requesting sink (step S27).

When the ID held in the DEP_RA registry matches the ID of the requesting sink, that is, when the requesting sink is already registered as a device acting as a remote access output of content (Yes in step S27) , Source passes the exchange key for remote access output proxy (D-RA_K _x) and its ID (D-RA_K _x _label) result codes, in Sink # 1 on the command "DEP-RA_EXCHANGE_KEY" (step S29 ), This processing routine is terminated.

  On the other hand, when the ID held in the DEP_RA registry does not match the ID of the requesting sink (No in step S27), the source notifies the requesting sink of a result code indicating “busy” ( Step S28), this processing routine is terminated.

After executing the processing procedure shown in FIG. 15, the Source cannot perform this DEP-RA-AKE with another device in an overlapping manner. Further, Source, upon discarding the exchange key for remote access proxy covalently with DEP-RA-AKE (D- RA_K x), by the DEP_RA registry emptied, the DEP-RA and other equipment -Be able to implement AKE.

Regarding the destruction of the exchange key (D_RA_K _x ) for the remote access proxy, for example, when the sink ends the remote access proxy, a command (DEP_RA_FINISH) requesting the destruction of the exchange key is used as the exchange key ID (D_RA_K _x). _Label) is considered as a mode of operation. The discard request command DEP_RA_FINISH is added as a remote access command to the DTCP-IP AKE control command together with “DEP_RA_INIT” and “DEP_RA_EXCHANGE_KEY” in FIG.

  FIG. 21 shows an operation sequence when a sink (having an RA-Source function) requests content for proxying remote access to the source. However, in the figure, it is assumed that the content is requested from the sink to the source according to the HTTP protocol, and the content is transmitted in the download format.

The Sink obtains the remote access exchange key (D_RA_K _x ) and its ID (D_RA_K _x _label) by the DEP_RA-AKE procedure shown in FIG. 14, and then uses the HTTP GET method to make an HTTP request (HTTP GET request). To request content data from the source. At the time of the request, along with the URL of the content, and sends the exchange key ID for remote access agency (D_RA_K _x _label). We define a header field for sending ID (D_RA_K _x _label) of the exchange key to the Source from Sink.

  When the source receives a request for content remote access output proxy, the “content remote access proxy (DEP-RA) output management 1 for checking whether or not the requested content can be remote access output proxy” is checked. ”Is executed. If it is confirmed that the content of the URL specified in the request is capable of remote access output proxy, the Source uses the remote access proxy exchange key specified by the exchange key ID to obtain the encryption key. The content calculated and encrypted using the encryption key is returned as an HTTP response (HTTP GET response) with the information “remote access output possible”.

  FIG. 22 shows, in the form of a flowchart, a processing procedure of content remote access output proxy management performed by the source requested to perform remote access output proxy.

  First, the source checks whether or not the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (step S61).

  Here, if the exchange key indicated by the exchange key ID included in the HTTP request is not for DTCP-IP (No in step S61), RA-Source continues to check whether the exchange key is for remote access proxy use. It is checked whether or not (step S62).

  When the exchange key is for remote access proxy (Yes in step S62), the source checks whether or not the content specified by the URL included in the HTTP request can be accessed remotely (step S63). . Whether or not the content can be accessed remotely can be managed using, for example, RA-flag (described later).

  Then, when the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (Yes in step S61), it has been found that the content specified in the HTTP request can be accessed remotely. In such a case (Yes in step S63), the source sets OK as a response to the HTTP request (HTTP GET request) from the sink (step S64).

  On the other hand, if the exchange key indicated by the exchange key ID included in the HTTP request is not for remote access proxy (No in step S62), or if the content specified in the HTTP request is not remotely accessible (step (No in S63), the source sets an error as a response to the HTTP request (HTTP GET request) from the sink (step S55).

In the system configuration shown in FIG. 13, when it is desired to transmit content that cannot be accessed remotely from Source # 0 to Sink # 1, it may be performed in accordance with the current DTCP-IP. Thus, it is possible to handle both contents that can be accessed remotely and those that cannot be accessed by transmission using an exchange key (D_RA_K _x ) for remote access proxy.

  Source # 0 is accompanied by remote access permission / rejection information (RA-flag) during content transmission using an exchange key shared by DEP-RA-AKE, so that RA-Source # 1 receives received content. To determine whether remote access output is possible.

Incidentally, RA-flag is to encrypt with the content data, and a value of RA-flag on the input to the function of the calculation of the encryption key, the method and (FIG. 23 or to reflect the value of the encryption key K _c By sending information including RA-flag to be transmitted in plain text together with signature data (signature) obtained by processing the information and encryption key with a hash function (see FIG. 24), Tampering can be prevented.

  Further, when the RA-flag is encrypted together with the content data, the storage destination is a DTCP_descriptor operated by DTCP-IP or a reserved bit of PCP-UR (see FIGS. 25 and 26). It is conceivable to provide a container for new content-related information and place it there.

  In the above description, in the system configuration shown in FIG. 13, it is assumed that Sink # 1 does not record content from Source # 0, but performs remote access output via RA-Source # 1. Yes. As a modification, even when the content is moved from Source # 0 to Sink # 1, the remote access permission / rejection information (RA-flag) is accompanied when the content is transmitted using the key shared by DP-RA-AKE. RA-Source # 1 can determine whether or not the received content can be output by remote access. Here, the MOVE function in DTCP-IP is based on the condition that the Sink encodes and records the received content as NoMore Copies, and the source side deletes or disables the content after transmission. , Which means that the encrypted content is transmitted from the source to the sink.

  Up to this point, the method of limiting the number of RA-Sinks that can use RA-Source has been described. On the other hand, some content owners may want to reduce fraudulent threats by limiting the number of remote contents that can be used at the same time. For example, when a receiver prohibits a recordable pay program from being immediately accessed by remote access.

  As a method of limiting the number of remote access usages of content, there is a method of changing the key shared by RA-AKE for each RA-Sink and managing which content is remotely accessed to each RA-Sink. . And RA-Source should just be made not to transmit the same content simultaneously to a predetermined number or more RA-Sink.

  RA-Source uses a management table as shown below, for example, to limit the number of contents that can be used for remote access at the same time.

In the above management table, the combination of RA-Sink URL of the content being transmitted to the RA-Sink and exchange key ID corresponding to the one-to-1 (RA_K _x _label) is managed in each entry. In this management table, entries having only matching URLs and different exchange key IDs indicate that one RA is using one content.

  The RA-Source refers to this management table before starting a new content transmission, and controls so that the same content is not sent to more than a predetermined number of RA-Sinks. When the start of content transmission is permitted, RA-Source adds an entry made up of a combination of a URL and an exchange key ID to the management table.

  FIG. 16 shows an operation sequence when the RA-Sink requests content from the RA-Source when the number of RA-Sinks that simultaneously transmit the same content is limited.

The RA-Sink acquires the remote access exchange key (RA_K _x ) and its ID (RA_K _x _label) by the RA-AKE procedure shown in FIG. 9, and then uses the HTTP GET method to make an HTTP request (HTTP GET). request) to request content data from the RA-Source. At the time of the request, along with the URL of the content, and sends the exchange key ID for remote access output (RA_K _x _label). We define a header field for sending RA-Sink from the exchange key to the _{RA-Source ID (RA_K x _label} ).

  When the RA-Source receives a request for content data, the “Remote Access (RA) Output Management 2 for the same content” for checking the number of RA-Sinks that simultaneously output the requested content by remote access. Execute the process. If the number of RA-Sinks that simultaneously transmit the content of the designated URL has not reached the limit, the RA-Source uses the remote access exchange key designated by the exchange key ID. The encryption key is calculated, and the content encrypted using this encryption key is returned as an HTTP response (HTTP GET response). In addition, RA-Source adds an entry to the management table.

When the RA-Source discards the remote access key, the entry corresponding to the discarded key is deleted from the table. When RA-Sink ends remote access, a command (RA_FINISH) for deleting an entry from the above management table is sent together with the ID (RA_K _x _label) of the exchange key for remote access. (Same as above)

  FIG. 17 shows, in the form of a flowchart, a processing procedure for managing the number of outputs of the same content executed by the RA-Source in response to a request for content data in the operation sequence shown in FIG.

  First, the RA-Source checks whether or not the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (step S31).

  Here, when the exchange key indicated by the exchange key ID included in the HTTP request is for DTCP-IP (Yes in step S31), the RA-Source is an HTTP request (HTTP GET request) from the RA-Sink. The response to is OK (step S38), and this processing routine is terminated.

  If the exchange key indicated by the exchange key ID included in the HTTP request is not for DTCP-IP (No in step S31), RA-Source continues to check whether the exchange key is for remote access. Is checked (step S32).

  If the exchange key is for remote access (Yes in step S32), the RA-Source checks whether the content specified by the URL included in the HTTP request is remotely accessible (step S33). ). Whether or not the content can be accessed remotely can be managed using, for example, RA-flag (described later).

  If the exchange key indicated by the exchange key ID included in the HTTP request is not for remote access (No in step S32), or if the content specified in the HTTP request is not remotely accessible (No in step S33) ), RA-Source sets a response to the HTTP request (HTTP GET request) from RA-Sink as an error (step S39), and ends this processing routine.

If the content specified in the HTTP request is found to be remotely accessible (Yes in step S33), the RA-Source sends the URL and exchange key ID (in the content data request). It is checked whether or not the same entry as the combination of (RA_K _x _label) exists in the management table (step S34).

Here, when the same entry as the combination of the URL and the exchange key ID (RA_K _x _label) included in the content data request is present in the management table (Yes in step S34), the content is the request source RA-Sink. Even if it is used, the limit on the number of uses will not be exceeded. Therefore, the RA-Source sets “OK” as the response to the GET request from the requesting RA-Sink (step S38), and ends this processing routine.

On the other hand, when the same entry as the combination of the URL and the exchange key ID (RA_K _x _label) included in the request for content data is not in the management table, the RA-Source continues to have an entry with the same URL in the management table Is checked (step S35).

If there is no entry in the management table with the same URL included in the request for content data (No in step S35), the content number exceeds the limit on the number of uses even if the content is used for the requesting RA-Sink. There is no. Thus, RA-Source is, add an entry consisting of a combination of content data URL specified in the request and the exchange key ID (RA_K _x _label) in the management table (step S37). Then, the RA-Source sets “OK” as the response to the GET request from the RA-Sink of the request source (Step S38), and ends this processing routine.

  Further, when there is an entry in the management table that is the same as the URL included in the content data request (Yes in step S35), if the content is provided to the requesting RA-Sink in response to the request, the number of uses May exceed the limit. Therefore, the RA-Source further checks whether or not the number of entries that are the same as the URL included in the content data request is less than the upper limit value in the management table (step S36).

If the number of entries that are the same as the URL included in the request for content data in the management table is less than the upper limit (Yes in step S36), even if the content is used for the RA-Sink of the request source Never exceed the usage limit. Therefore, the RA-Source adds an entry consisting of a combination of the URL specified in the content data request and the exchange key ID (RA_K _x _label) to the management table (step S37), and the RA-Sink from the request source RA-Sink. The response to the GET request is “OK” (step S38), and this processing routine is terminated.

  In the management table, when the number of entries that are the same as the URL included in the content data request has reached the upper limit (No in step S36), the content is used for the RA-Sink of the request source. Will exceed the limit of usage. Therefore, the RA-Source sets the response to the GET request from the requesting RA-Sink as “ERROR” (step S39), and ends this processing routine.

  In the description so far, it has been assumed that content without the information “remote access output is possible” cannot be accessed remotely. However, in reality, if the content can be recorded, it can be taken out of the home by using a removable recording medium such as a DVD or a memory card, and used on another device. Can do. Therefore, for the recordable content, it is conceivable to perform the remote access after recording even without the information that “remote access output is possible”.

  However, when the destination of the content received by the RA-Sink is a portable recording medium, the content can be taken out after being written to the end. Suppressing remote access may be required until time passes.

  FIG. 18 is a flowchart showing a processing procedure for a device operating as an RA-Source to record content or capture it with the MOVE function.

  The RA-Source first checks whether or not the captured content is accompanied by information regarding “remote access output availability” (step S41).

  Here, when the content to be captured is accompanied by information relating to “remote access output availability” (Yes in step S41), whether or not the specified content of the information is “remote access output possible” It is checked whether or not (step S42).

  Here, when the specified content of the information relating to “remote access output enabled / disabled” is not “remote access output enabled” (No in step S42), the RA-Source sets the remote access disabled time limit according to the information. “Infinite” is set (step S43).

  Next, the RA-Source sets an RA-flag indicating whether or not the remote access output of the captured content is possible (step S44), and ends this processing routine.

  On the other hand, when the content does not include the information that “remote access output is possible” (No in step S45), the RA-Source obtains a value T as a result of adding a predetermined period to the time at the reference ( In step S46), T is set as the remote access impossible time limit of the content (step S47), and the RA-flag is initialized to “impossible” with setting to prohibit remote access output of the content until the time limit (step S46). S48), this processing routine is terminated.

  Here, the reference point time is, for example, the time at which the head of the program was broadcast in the case of broadcast content, and the predetermined time to be added may be the time length of the program sent together with the content as program information. . For contents that are unknown when they are recorded, such as contents in a recording medium, it is conceivable that T is a value obtained by adding the reproduction length of the contents to the time when the contents are to be taken in by the MOVE function.

  Although omitted in FIG. 18, when the content is accompanied by the information “remote access cannot be output” (when it is found in step S42), RA-Source disables RA-flag and sets T to Set to “infinity”.

  Through the processing procedure shown in FIG. 18, content for which the RA-flag is set to “impossible” and T is not set to “infinite” is handled as being remotely accessible after the specified timing. be able to.

  FIG. 27 shows a processing procedure for RA-Source to update RA-flag and T set in the content in the form of a flowchart.

  The RA-Source first checks whether or not the RA-flag of the content is set to “permitted” (step S71). Here, when the RA-flag of the content has already been set to “permitted” (Yes in step S71), all subsequent processes are skipped and this processing routine is ended.

  When the RA-flag of the content is not set to “permitted” (No in step S71), the RA-Source next checks whether or not the remote access impossibility period of the content is set to “infinite”. (Step S72). Here, when the remote access impossibility period of the content is set to “infinite” (Yes in step S72), all subsequent processes are skipped, and this processing routine is ended.

  When the content remote access disabled period is not set to “infinite” (No in step S72), the RA-Source then checks whether the content remote access disabled period is in the future from the present time (step). S73).

  If the remote access impossibility period of the content is in the future from the present time (Yes in step S73), this processing routine is terminated as it is. Further, when the remote access disabled time limit of the content is not in the future from the present time, that is, when the remote access disabled time limit has already been reached (No in step S73), the RA-Source sets the content RA-flag to “permitted”. It updates (step S74) and this processing routine is complete | finished.

  By regularly executing the processing procedure shown in FIG. 27 by the RA-Source, the RA-flag of the content can be updated to “OK”. Specific implementation timing of the processing procedure includes, for example, when a content list (not shown) is presented to the outside.

  In DTCP-IP, content can only be used on a home network. On the other hand, in the communication system according to the present embodiment, it is possible to use content from outside the home, that is, by remote access by narrowing down the possibility of unauthorized use.

  In the communication system according to the present embodiment, the system is adjusted by adjusting a plurality of limit values that limit remote access, such as RTT, TTL, the number of RA-Sinks that use content, and the number of exchange keys supplied. It can be constructed flexibly.

  In addition, according to the communication system according to the present embodiment, it is possible to realize the use of content by remote access by removing the restrictions of RTT and TTL while constructing based on the DTCP-IP communication protocol.

  The functional configuration of the content providing apparatus corresponding to the RA-Source in the communication system according to the present invention has already been described with reference to FIG. For example, a personal computer, a recorder, and other various information devices can function as a content providing apparatus.

  FIG. 29 shows a configuration example of a personal computer 80 applied to the content providing apparatus. The illustrated personal computer 80 includes a CPU 81, a RAM (Random Access Memory) 82, an EEPROM (Electrically Erasable and Programmable ROM) 83, a display 84, a speaker 85, for example, an HDD (Hard Disc Drive) or an SDD (Super Dist). Circuit components such as a mass storage device 86 and an I / O interface 87 are provided, and these circuit components are interconnected via a bus 88.

  The CPU 81 reads and executes a program loaded in the RAM 82 as the main memory.

  The RAM 82 is loaded with functions related to content encryption and decryption. For example, a program for executing the DTCP-IP function and a program for executing the RA-AKE process are loaded into the RAM 82. In addition, a program for executing an authentication sequence (see FIG. 7) when registering an RA-Sink in the RA-Source is stored in the RAM 82 as a part of a program for executing the RA-AKE process. Loaded and executed by the CPU 81.

  The EEPROM 83 is a rewritable nonvolatile storage device and stores setting information and the like. When the personal computer 80 operates as an RA-Source, that is, as a content providing device, a terminal ID serving as an RA-sink is stored in the EEPROM 83.

  When the personal computer 80 receives a request from an RA-sink (for example, a mobile terminal) to register the RA-sink as a terminal capable of the RA-AKE procedure, the CPU 81 receives the DTCP-IP AKE from the RAM 82. A program in which processing is described is read, and an AKE procedure is executed with the RA-sink.

  If this procedure is successful, the CPU 81 stores the RA-sink terminal ID in the EEPROM 83 in accordance with the program stored in the RAM 82.

  Thereafter, on the personal computer 80, when the CPU 81 receives a request for RA-AKE processing, it compares the ID of the terminal making the request with the terminal ID of the RA-sink stored in the EEPROM 83. , A process for determining whether or not to complete the RA-AKE process is executed.

  When the RA-AKE process is completed, a common content key is generated between the personal computer 80 and the terminal that has requested the RA-AKE process. On the personal computer 80 side, the generated content key is temporarily stored, and when the content is read from the large-capacity information storage device 86, this content is encrypted with the temporarily stored content key. The encrypted content is output to the outside via the I / O interface 88. When the I / O interface 88 has a wireless LAN function, the encrypted content is transmitted to the terminal that has requested the RA-AKE process via the wireless LAN.

  FIG. 30 shows a configuration example of a recorder 90 applied to the content providing apparatus. The illustrated recorder 90 includes a system chip 91, a mass storage device 92, a RAM 93, an EEPROM 94, and a wireless LAN chip 95.

  The system chip 91 includes circuit modules such as a CPU 91a, a coprocessor 91b, and an interface function unit 91c, and these circuit modules are interconnected by a bus 91d in the chip.

  The CPU 91a can execute a program stored in a storage device connected via the interface function unit 91c.

  The coprocessor 91b is an auxiliary arithmetic device, and mainly executes moving image compression or decoding processing. For example, an algorithm such as H264, VC1, MPEG2, or JPEG is executed.

  The mass storage device 92 is, for example, an HDD or an SDD, and stores content to be provided to the content use device.

  A program executed by the CPU 91a is loaded into the RAM 93 as the main memory. The main program loaded in the RAM 93 is a program that realizes functions related to content encryption and decryption. For example, a program for executing the DTCP-IP function and a program for executing the RA-AKE process are provided. It is loaded into the RAM 82.

  The EEPROM 94 is a rewritable nonvolatile storage device and stores setting information and the like. When the recorder 90 operates as an RA-Source, that is, a content providing apparatus, a terminal ID that becomes an RA-sink is stored in the EEPROM 94.

  When the recorder 90 receives a request from the RA-sink (for example, a mobile terminal) to register the RA-sink as a terminal capable of the RA-AKE procedure, the CPU 91a performs the DTCP-IP AKE process from the RAM 93. The described program is read and the AKE procedure is executed with the RA-sink.

  If this procedure is successful, the CPU 91 a stores the RA-sink terminal ID in the EEPROM 94 in accordance with the program stored in the RAM 93.

  Thereafter, on the recorder 90, when the CPU 91a receives a request for the RA-AKE process, the CPU 91a compares the ID of the terminal making this request with the terminal ID of the RA-sink stored in the EEPROM 94, and the RA 91 -A process for determining whether or not to complete the AKE process is executed.

  When the RA-AKE process is completed, a common content key is generated between the recorder 90 and the terminal that has requested the RA-AKE process. On the recorder 90 side, the generated content key is temporarily stored, and when the content is read from the mass information storage device 92, the content is encrypted with the temporarily stored content key. The encrypted content is transmitted via the interface function unit 91c and the wireless LAN chip 95 to the terminal that has requested the RA-AKE process.

  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, a communication system that uses a content by remotely accessing a server on a home network to which DTCP-IP is applied from a client outside the home can be cited. It is not limited to. Content that needs to be protected for copyright or other purposes through remote access via an external network such as a WAN while exceeding the limits such as round-trip delay time (RTT) and IP router hop count (TTL) Similarly, the present invention can be applied to any other content transmission system that transmits the content.

  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.

10. Content providing device (RA-source)
11 ... CPU
DESCRIPTION OF SYMBOLS 12 ... Content receiving / reproducing part 13 ... Communication part 14 ... Memory | storage part 15 ... Timer 20 ... Content utilization apparatus (RA-sink)
21 ... CPU
22 ... Communication unit 23 ... Content output unit 24 ... Storage unit 30, 31 ... Router 40, 41 ... Modem 50 ... WAN
60 ... IAS service 70 ... DDNS service 80 ... Personal computer 81 ... CPU
82 ... RAM
83… EEPROM
84 ... Display 85 ... Speaker 86 ... Mass storage device 87 ... I / O interface 88 ... Bus 90 ... Recorder 91 ... System chip 91a ... CPU, 91b ... Coprocessor 91c ... Interface function part, 91d ... Bus 92 ... Large Capacity storage device 92 ... RAM
94… EEPROM
95 ... Wireless LAN chip

Claims (4)

A content providing system that enables use of broadcast content by remote access via the Internet, the system including a content using device and a content providing device,
The content providing apparatus includes:
Means for receiving broadcast content;
Means for registering up to a first predetermined number of content use devices as devices to use content by remote access through a first mutual authentication procedure that imposes restrictions on round-trip delay time of commands indoors in advance;
When the registered content using device uses the content by remote access, the second of the registered content using devices through the second mutual authentication procedure that does not impose a restriction on the round trip delay time of the command. An exchange key for using the content is transmitted to a predetermined number of content utilization devices, and the content encrypted using the content key generated from the exchange key is transmitted to the content utilization device that has transmitted the exchange key. Means for transmitting;
Have
The content using device is:
Means for indoor device registration in advance with the content providing device;
Means for receiving broadcast content from the content providing apparatus via the Internet from outside;
Means for outputting the received broadcast content for use;
Have
The first predetermined number is 2 or more, and the second predetermined number is less than the first predetermined number;
Content provision system.   The content providing system according to claim 1, wherein the second predetermined number is one. In a content providing method for providing broadcast content requested by remote access via the Internet from a content providing device to a content using device,
The content providing apparatus includes:
Receive broadcast content,
Register the content using devices up to a first predetermined number of devices as devices using remote access indoors through a first mutual authentication procedure that imposes restrictions on the round-trip delay time of commands indoors in advance.
When the registered content using device uses content by remote access,
An exchange key for using the content to a second predetermined number of content usage devices among the registered content usage devices via a second mutual authentication procedure that does not impose restrictions on the round trip delay time of commands. Send
Sending the content encrypted using the content key generated from the exchange key to the content using device that sent the exchange key;
The content using device is:
Register the device indoors beforehand with the content providing device,
Receiving broadcast content from the content providing device from the outside via the Internet,
Means for outputting the received broadcast content for use;
Have
The first predetermined number is 2 or more, and the second predetermined number is less than the first predetermined number;
Content provision method.   The content providing method according to claim 1, wherein the second predetermined number is one.

Images