WO2012014566A1 - 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム - Google Patents

通信システム、通信装置及び通信方法、並びにコンピューター・プログラム Download PDF

Info

Publication number
WO2012014566A1
WO2012014566A1 PCT/JP2011/062739 JP2011062739W WO2012014566A1 WO 2012014566 A1 WO2012014566 A1 WO 2012014566A1 JP 2011062739 W JP2011062739 W JP 2011062739W WO 2012014566 A1 WO2012014566 A1 WO 2012014566A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
content
mutual authentication
exchange
communication
Prior art date
Application number
PCT/JP2011/062739
Other languages
English (en)
French (fr)
Inventor
中野　雄彦
Original Assignee
ソニー株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to BR112013001615A priority Critical patent/BR112013001615A2/pt
Priority to MX2013000830A priority patent/MX2013000830A/es
Priority to EP11812159.9A priority patent/EP2600562A4/en
Priority to US13/810,792 priority patent/US8949605B2/en
Priority to CA2804123A priority patent/CA2804123A1/en
Priority to KR1020137001051A priority patent/KR20130044298A/ko
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to RU2013102867/08A priority patent/RU2574356C2/ru
Priority to CN2011800358891A priority patent/CN103026683A/zh
Priority to AU2011284062A priority patent/AU2011284062A1/en
Publication of WO2012014566A1 publication Critical patent/WO2012014566A1/ja
Priority to US14/587,678 priority patent/US9553857B2/en
Priority to US15/266,730 priority patent/US9813397B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Definitions

  • 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.
  • the present invention relates to a decryption key for encrypted content in accordance with a predetermined mutual authentication and key exchange (AKE) algorithm.
  • the present invention relates to a communication system, a communication device, a communication method, and a computer program for exchanging encrypted content.
  • LA local access
  • WAN Wide Area Network
  • RA Remote Access
  • Digitized content is relatively easy to perform illegal operations such as copying and falsification. In particular, in remote access, it is necessary to prevent unauthorized use involved in content transmission and protect the copyright of the content while permitting the use of personal or home content.
  • DTCP Digital Transmission Content Protection
  • DTLA Digital Transmission Licensing Administrator
  • DTCP an authentication protocol between devices at the time of content transmission and a transmission protocol for encrypted content are decided.
  • 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.
  • the key exchange Authentication and Key Exchange: AKE
  • AKE Authentication and Key Exchange
  • DTCP-IP DTCP mapping to IP
  • RTT Round Trip Time
  • TTL Time To Live
  • 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).
  • the content owner may prohibit one content providing device (Source) from simultaneously transmitting content to a number of content using devices (Sinks) in order to limit unauthorized use of the content.
  • Source content providing device
  • Sinks devices
  • a user who uses content may use a plurality of content use devices depending on the situation, or may share one content providing device installed in the home with a family.
  • content transmission from one content providing device in a home to a plurality of content using devices is within the range of legitimate use of content, and the number of content owners is limited as described above. Setting content to prohibit content transmission unduly restricts the user's use of content.
  • An object of the present invention is to provide an excellent communication system, communication apparatus and communication method, and computer capable of suitably transmitting encrypted content by exchanging a decryption key of the encrypted content according to a predetermined mutual authentication and key exchange algorithm. ⁇ To provide a program.
  • a further object of the present invention is to allow the transmission of content within the range of legitimate use by the user, while limiting the number of devices that simultaneously transmit content that requires protection for copyright and other purposes. It is an object to provide an excellent communication system, communication apparatus and communication method, and computer program.
  • a key recording unit that records a key provided by the content providing device to each content using device in combination with a key ID that identifies the key and a device ID that identifies the content using device;
  • Key management means for maintaining the information of the key ID in the key recording means only while the content use device periodically transmits a key life management command including the key ID to the content providing device;
  • a communication system comprising:
  • 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 claim 2 of the present application is Mutual authentication and key exchanging means for exchanging keys for mutual authentication and content encryption with one or more content use devices that are content providing destinations;
  • a key recording means for recording a key passed to each content use device in combination with a key ID for specifying the key and a device ID for specifying the content use device;
  • Key management means for maintaining information corresponding to the key ID in the key recording means only while receiving a key life management command including the key ID from the content use device at a predetermined reception cycle; It is a communication apparatus which comprises.
  • the key management means of the communication device stores information corresponding to the key ID for which the key life management command could not be received at a predetermined reception cycle. It is comprised so that it may discard from a recording means.
  • the key management means of the communication device of claim 2 receives the key life management command received in response to receiving the key life management command from the content utilization device.
  • a response indicating that the key is valid is returned when the information corresponding to the key ID included in the key recording means is maintained, and if the corresponding information is discarded from the key recording means, the key is A response indicating invalidity is returned.
  • the key management means of the communication device responds to the reception of the key life management command in which information for instructing the key destruction is set. The corresponding key information is discarded from the key management means.
  • the communication device described in claim 2 further includes registration means for performing pre-registration of the content using device for key exchange. Then, the key management means is configured to send back a response indicating that it has not been registered in response to receiving a key life command from a content utilization apparatus not pre-registered in the registration means.
  • the invention according to claim 7 of the present application is Mutual authentication and key exchange means for exchanging a key for mutual authentication and content encryption with a content providing apparatus as a content provider;
  • a key life management means for transmitting a key life management command including a key ID for identifying a key passed from the content providing device by the mutual authentication and key exchange means;
  • It is a communication apparatus which comprises.
  • the key life management means of the communication device is a key life management in which information for instructing key destruction is set when the key becomes unnecessary. It is configured to send commands.
  • the invention according to claim 9 of the present application is A mutual authentication and key exchange step of exchanging keys for mutual authentication and content encryption with one or more content utilization devices that are content providers;
  • a key recording step for recording a key passed to each content use device in combination with a key ID for specifying the key and a device ID for specifying the content use device;
  • a key management step of maintaining information corresponding to the key ID in the key recording means only while receiving a key life management command including the key ID from the content use device at a predetermined reception cycle; Is a communication method.
  • the invention according to claim 10 of the present application is A mutual authentication and key exchange step of exchanging keys for mutual authentication and content encryption with a content providing device as a content provider; A key life management step of transmitting a key life management command including a key ID for identifying the key passed from the content providing device in the mutual authentication and key exchange step; Is a communication method.
  • the invention according to claim 11 of the present application is a content providing apparatus in a communication system that performs communication for content transmission between a content providing apparatus that provides content and one or more content using apparatuses that use the content.
  • Key recording means for recording a key passed to each content using device in combination with a key ID for specifying the key and a device ID for specifying the content using device;
  • Key management means for maintaining information corresponding to the key ID in the key recording means only while receiving a key life management command including the key ID from the content utilization device at a predetermined reception cycle; It is a computer program to function as.
  • a computer program written in a computer-readable format to execute a process for operation on a computer Mutual authentication and key exchange means for exchanging keys for mutual authentication and content encryption with a content providing device as a content provider;
  • Key life management means for transmitting a key life management command including a key ID for identifying a key passed from the content providing device by the mutual authentication and key exchange means; It is a computer program to function as.
  • Each computer program according to claims 11 and 12 of the present application defines a computer program described in a computer-readable format so as to realize predetermined processing on a computer.
  • a cooperative action is exhibited on the computer, which is the same as the communication device according to claims 2 and 7 of the present application, respectively. An effect can be obtained.
  • the content using device transmits a key life management command including a key ID to the content providing device every predetermined transmission cycle.
  • the content providing apparatus maintains the corresponding key only for a period during which the key life management command can be received at a predetermined reception cycle. Therefore, the content providing apparatus can determine the number of content using apparatuses that can simultaneously transmit the content. The following can be limited.
  • the content providing apparatus in response to receiving the key life management command, responds that the key is valid when maintaining the corresponding key. Reply. Further, when a command is received after the corresponding key is discarded because the key life management command cannot be received at a predetermined reception cycle, a response indicating that the key is invalid is returned. Therefore, the content using apparatus can confirm the current status of the key held by the content using apparatus.
  • the content use device sets information indicating that it is not necessary in the key life management command corresponding to the unnecessary key, and the content providing device does not require the key.
  • the corresponding key is discarded, so that it is possible to newly exchange keys with other content using devices within the upper limit of the number of devices. become.
  • the content providing apparatus can perform pre-registration of the content use apparatus for key exchange in response to a request from the content owner.
  • the content providing device returns a response indicating that it has not been registered in response to receiving the key life command from the content using device that has not been pre-registered. Can be recognized.
  • 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 the AKE command performed between the source and the sink according to the current DTCP-IP.
  • FIG. 7 shows an operation sequence of mutual authentication and key exchange including a restriction on the number of content use devices that can simultaneously perform content transmission between the source corresponding to the content providing device and the sink corresponding to the content use device.
  • FIG. FIG. 8 is a diagram illustrating an example of connection table update processing.
  • FIG. 9 is a diagram showing a format example of the KEEP_ALIVE command.
  • FIG. 10 is a diagram showing an example of an operation sequence for updating the lifetime of the exchange key Kr performed between the source and the sink.
  • FIG. 11 is a diagram showing another example of an operation sequence for updating the lifetime of the exchange key Kr performed between the source and the sink.
  • the present invention relates to a communication system for safely 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.
  • RA-AKE the AKE procedure performed at the time of remote access.
  • FIG. 1 schematically shows a configuration example of a communication system according to the present invention.
  • 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.
  • 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.
  • the IP address assigned to the router 30 may be updated by the IAS provider 60.
  • the DDNS service 70 is used, and the DDNS (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.
  • a content use 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. .
  • NAT Network Address Translation
  • 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.
  • CPU Central Processing Unit
  • 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.
  • CPU Central Processing Unit
  • 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).
  • the storage unit 14 stores the RA-Sink identification information to be stored by the registration process described later, the remote access exchange key shared with the RA-Sink through RA-AKE and the identification information of the exchange key ( Hereinafter, it is also referred to as “key ID”).
  • key ID the number of exchange keys and key IDs that can be registered simultaneously is limited to n (where n is a positive integer).
  • a connection table and a receiving device table described later are also stored in the storage unit 14.
  • 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 the reception period of the key ID from the RA-Sink as described later).
  • FIG. 4 schematically shows a functional configuration of the content use device 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 an RA-AKE registration process for the RA-Source (content providing device 10), which will be described later, through the communication unit 22, and performs RA-AKE to perform RA-Source.
  • the exchange key is obtained and stored in the storage unit 24, 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.
  • the timer 25 is used when time management is required when handling remotely accessible content (for example, when managing the transmission cycle of the key ID from the RA-Source as will be described later).
  • a mechanism for performing encrypted content transmission by DTCP-IP between a source corresponding to a content providing apparatus and a sink corresponding to a content using apparatus will be described with reference to FIG. 5 (RA-Source and RA).
  • RA-Source and RA the mechanism between the sinks is the same).
  • 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.
  • 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.
  • Source 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.
  • sink In each Source and Sink, by applying a predetermined arithmetic processing on the exchange key K x, can generate a content key K c which is used to encrypt content when the content transmission.
  • HTTP Hyper Text Transfer Protocol
  • RTP Real Time Protocol
  • content transmission is performed according to the HTTP procedure.
  • 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)).
  • the sink as the HTTP client requests the 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 Source as the HTTP client starts transmission with the Sink as the HTTP server by an HTTP request using the HTTP POST method, for example.
  • the data transmitted from the source is data obtained by encrypting the content using a key shared after the source performs AKE authentication.
  • 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.
  • the content requested by the sink is encrypted using the content key K c, and a packet including a payload including the encrypted content, a nonce N c and a header including encryption mode information is placed on the 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 specified IP address.
  • each IP packet is received from the source, it is assembled into a TCP stream.
  • the content key K c can be calculated using these and the exchange key K x , and the encrypted content can be decrypted using the content key K c .
  • the reproduction processing can be performed on the plaintext content after decryption.
  • the sink stores the content in the storage unit 24 or passes it to another device without decrypting the encrypted content.
  • the TCP connection used for content transmission is appropriately disconnected from the sink side, for example.
  • E-EMI Extended Encryption Mode Indicator
  • Embedded CCI Copy Control Information
  • FIG. 6 shows the mutual authentication and key exchange operation sequence (RTT-AKE) using the AKE command performed between the source corresponding to the content providing apparatus and the sink corresponding to the content using apparatus in accordance with the current DTCP-IP. Show.
  • each challenge command includes a Device ID that is identification information unique to the device.
  • a TTL IP router hop count
  • the TTL is set to 3 or less in the TCP / IP communication for sending the command used in AKE, and the receiving device must invalidate the received data when the TTL is larger than 3. .
  • 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.
  • RTT protection protocol Protected RTT protocol
  • contents can be transmitted via the IP network by setting an upper limit on the round-trip delay time (RTT) and the IP router hop count (TTL) for the AKE command.
  • RTT round-trip delay time
  • TTL IP router hop count
  • Some content owners set an upper limit on the number of content utilization devices (RA-Sinks) that simultaneously transmit content from a single content provision device (RA-Source) in order to limit unauthorized use of content. There is.
  • RA-Sinks content usage devices
  • RA-Source content provision device
  • the upper limit of the number of content use devices that simultaneously transmit content from one content providing device is set to n (where n is a positive integer), and a special by the user. Introduced a mechanism to ensure the legitimate use of content by users while responding to content protection requests from content owners by appropriately replacing the content usage devices included in the upper limit of n devices without switching Yes.
  • the content using device sends a key ID corresponding to the exchange key to the content providing device every predetermined transmission cycle. Send by command. Then, the content providing apparatus holds the corresponding exchange key only during a period in which the key ID can be received every predetermined reception cycle. On the other hand, when the command including the key ID cannot be received at a predetermined reception cycle, the corresponding exchange key is discarded.
  • DTCP-IP stipulates that the exchange key be discarded before the continuous non-use time exceeds a predetermined period (described above), but in this embodiment, the key ID is included even within 2 hours. If the command cannot be received periodically, the content providing apparatus discards the corresponding exchange key.
  • the content providing apparatus When the content providing apparatus receives the command including the key ID, it confirms whether or not the corresponding exchange key is maintained. When a corresponding command is received while the exchange key is maintained, a response including information indicating that the exchange key is valid is returned to the content use apparatus that is the transmission source. On the other hand, when the content providing apparatus cannot receive the command including the key ID at a predetermined reception cycle, and when receiving the command after discarding the corresponding exchange key, information indicating that the exchange key is invalid Is sent back to the content-use device as the transmission source.
  • the content providing apparatus when the content providing apparatus cannot receive the command including the key ID periodically, the content providing apparatus receives the command including the key ID corresponding to the exchange key after discarding the exchange key. A response including information that the exchange key (or the content key generated from the exchange key) is invalid is returned to the using device.
  • the content using device sets information indicating that in a command to be transmitted periodically.
  • the content providing apparatus receives a command in which information indicating that the exchange key is no longer necessary is received, the content providing apparatus discards the corresponding exchange key.
  • the content providing apparatus may perform key life management only with a content use apparatus registered in advance.
  • the content utilization device includes a device ID that identifies itself in a command that is periodically transmitted.
  • the content providing device that has received the command receives the content utilization device corresponding to the device ID included in the received command. Check if is registered. If the content transmission device that is the source of the command transmission is not registered, the content provision device confirms that the content usage device has not been registered before checking the validity of the exchange key corresponding to the key ID included in the command. Is sent back to the content utilization apparatus as the transmission source.
  • FIG. 7 shows an operation sequence of mutual authentication and key exchange including a restriction on the number of content use devices capable of simultaneously transmitting content, performed between a source corresponding to the content providing device and a sink corresponding to the content use device.
  • the illustrated sequence is based on the DTCP Full Authentication process.
  • operations that are not set in remote access are common, as in the operation sequence shown in FIG. It may be set.
  • illustration is omitted.
  • the sink When the sink needs content, it sends a CHALLENGE command to the source. At this time, in order to indicate that the mutual authentication and key exchange procedure is intended to share the key (Kr) for remote access to the source, the sink uses the Kr-bit in the CHALLENGE command. Set. Also, the Device ID which is the specific information of the sink is also transmitted by the CHALLENGE command.
  • a CHALLENGE command from the source a RESPONSE command from the sink, a RESPONSE command or a RESPONSE2 command from the source are transmitted in order.
  • “RESPONSE2” may be sent as a response from the sink to the source. This is a case in which the device does not become the specific information of the sink by mounting the common device key and the common device certificate, and the IDu sent by the RESPONSE2 command is used as the specific information of the sink.
  • Source determines a device ID for identifying the sink (step S71).
  • the Source uses IDu, and when the RESPONSE2 command is not received, the Device ID is used as the device ID.
  • the source passes the exchange key Kr for remote access to the sink as a result of the mutual authentication and key exchange procedure with the sink, the source is a key ID for specifying the exchange key Kr, and the sink device.
  • an entry consisting of a set of IDs is stored in the connection table.
  • the connection table it is assumed that entries corresponding to the limited number of sinks capable of simultaneously transmitting content can be stored.
  • the number of entries is two, but the gist of the present invention is not limited to two.
  • the source manages a receiving device table for remote access as shown in the table below, and simultaneously stores the device ID of the sink that performs content transmission in the table.
  • the device ID of the sink is registered in advance in the receiving device table.
  • an upper limit may be set for the number of sinks that can be pre-registered in the receiving device table, the gist of the present invention is not limited to a specific upper limit number.
  • a method for registering the sink device ID in the receiving device table there is a method in which the source registers the sink when performing RTT-AKE in DTCP.
  • the source determines the device ID of the sink in the mutual authentication and key exchange procedure with the sink (step S71)
  • the source confirms whether or not it has been registered in the receiving device table (step S72). This is a process for confirming that the content owner may request that the sink for remote access be registered in advance in the source.
  • the source sends an AKE_CANCEL command notifying the interruption of the mutual authentication and key exchange procedure to the sink and ends the process.
  • Source may describe information indicating that the sink is not registered in the receiving device table in the AKE_CANCEL command.
  • the sink may be registered in the receiving device table before key exchange.
  • step S73 the source checks whether the sink device ID is recorded in the connection table (step S73).
  • the source further checks whether there is room to newly record the device ID in the connection table (step S75).
  • the source manages the number of key IDs that can be recorded in the connection table using a key counter, and can record if the value of the key counter is less than the upper limit value n.
  • Source manages the value of the key counter to be the same as the number of key IDs recorded in the connection table.
  • the Source sends an AKE_CANCEL command notifying the interruption of the mutual authentication and key exchange procedure to the Sink and ends the process.
  • the Source may describe information indicating that the number of entries registered in the connection table has reached the upper limit n in the AKE_CANCEL command.
  • step S75 If the value of the key counter is less than n (Yes in step S75), the source adds 1 to the key counter (step S76), and then the remote access exchange key Kr and the key ID for specifying Kr. (Step S77), and an entry including the exchange key Kr, the key ID and the device ID of the sink is added to the connection table (step S78).
  • step S73 If the sink device ID is already recorded in the connection table (Yes in step S73), the entry corresponding to the device ID is deleted from the connection table (step S74), and then the remote access exchange is performed. A key Kr and a key ID for specifying Kr are newly generated (step S77), and an entry made up of the exchange key Kr and the key ID and sink device ID is added to the connection table (step S78).
  • the exchange key Kr and the key ID corresponding to the device ID are extracted from the connection table and the information is not added to the connection table again. Processing is also conceivable. However, this pattern is not shown.
  • the source encrypts the remote access exchange key Kr generated in step S77 in accordance with the method defined in the DTCP specification, and transmits it to the sink together with the key ID using the EXCHANGE_KEY command.
  • the life management of the exchange key Kr is started by a timer (step S79). Specifically, the Source prepares a timer corresponding to the key ID (that is, prepares a timer for each key ID stored in the connection table), and sets a predetermined value (for example, a value corresponding to 1 minute). To start down-counting.
  • Source will automatically reduce the timer to zero with a fixed clock.
  • the Source starts a connection table update process.
  • FIG. 8 shows an example of connection table update processing.
  • the entry including the key ID that could not be periodically received by the key life management command (AKE_ALIVE.CMD) is deleted from the connection table.
  • the source checks whether or not an entry including the key ID corresponding to the timer that has become zero exists in the connection table (step S81). If the corresponding entry does not exist in the connection table (No in step S81), the process ends.
  • the source deletes the entry including the key ID corresponding to the timer that has become zero from the connection table (step S82), and subtracts 1 from the key counter. (Step S83).
  • the Source can exchange a key with another Sink (or the same Sink) anew.
  • the sink can request the lifetime update of the exchange key Kr in use.
  • the sink requests the lifetime update of the exchange key Kr by transmitting a KEEP_ALIVE command at a predetermined transmission cycle. Further, the source maintains the corresponding key by receiving the KEEP_ALIVE command at a predetermined reception cycle.
  • FIG. 9 shows a format example of the KEEP_ALIVE command.
  • the KEEP_ALIVE command describes, in the payload, a field that describes a device ID that is information for identifying a sink that is a transmission source, and a key ID that is information for identifying an exchange key Kr that requires lifetime update. The last 1 bit including the field is used as a discard flag for instructing discard of the exchange key Kr.
  • the source When the source receives the KEEP_ALIVE command, it performs a lifetime update process and then returns a KEEP_ALIVE response. Although not shown in the figure, it is conceivable to use the status field defined in the AKE Control Command Format of DTCP for the response information of the KEEP_ALIVE response.
  • the source sets a value indicating a predetermined time in a timer corresponding to the key ID included in the KEEP_ALIVE command received from the sink, and renews the lifetime by performing control so that the downcount is performed again from that value. It should be noted that this lifetime update processing is performed even if the corresponding key has not yet been discarded even after the timer becomes zero.
  • FIG. 10 shows an example of an operation sequence for updating the lifetime of the exchange key Kr performed between the source and the sink.
  • the sink receives the exchange key Kr and its key ID from the source, the sink transmits a KEEP_ALIVE command at a predetermined transmission cycle.
  • the source When the source receives the KEEP_ALIVE command from the sink, it checks whether the device ID included in the command has been registered in the receiving device table (step S101).
  • the source sets the response information as “device not registered” (step S105), and sends a KEEP_ALIVE response including this response information.
  • the request is sent to the sink of the request source, and the process ends.
  • step S101 the source subsequently checks whether the key ID in the KEEP_ALIVE command exists in the connection table (step S102). ).
  • the source sets the response information as “key invalid” (step S106), and sends a KEEP_ALIVE response including this response information to the request source. To the sink and finish the process.
  • step S102 If the key ID in the KEEP_ALIVE command is present in the connection table (Yes in step S102), the source initializes the timer corresponding to this key ID with a value indicating a predetermined time, and then downloads it again. Counting is started (step S103). Then, the source sets the response information to “key is valid” (step S104), transmits a KEEP_ALIVE response including this response information to the requesting sink, and ends the processing.
  • the sink When the mutual authentication and key exchange procedure with the source is completed, the sink repeatedly transmits the KEEP_ALIVE command at a transmission cycle within a predetermined period as long as the acquired exchange key Kr is desired to be maintained.
  • the sink may request the source to discard the exchange key Kr when the exchange key Kr is no longer needed after the communication with the source (content reception) is completed.
  • the source can perform communication (content transmission) by connecting another new sink to the source within the upper limit number n.
  • the sink can request the source to destroy the exchange key Kr by including information for requesting the destruction of the exchange key Kr in a KEEP_ALIVE command transmitted at a predetermined transmission cycle.
  • the payload includes a discard flag, and by setting this discard flag, the exchange key Kr can be instructed to be discarded.
  • FIG. 11 shows another operation sequence example for updating the lifetime of the exchange key Kr performed between the source and the sink.
  • the operation sequence shown is different from the operation sequence shown in FIG. 10 in that it includes a process of discarding the exchange key Kr that is no longer needed.
  • the source When the source receives the KEEP_ALIVE command from the sink, it checks whether the device ID included in the command has been registered in the receiving device table (step S111).
  • the source sets the response information as “device not registered” (step S116), and sends a KEEP_ALIVE response including this response information.
  • the request is sent to the sink of the request source, and the process ends.
  • the source subsequently checks whether the key ID in the KEEP_ALIVE command exists in the connection table (step S112). ).
  • the source sets the response information as “key invalid” (step S120), and sends a KEEP_ALIVE response including this response information to the request source. To the sink and finish the process.
  • the source further checks whether the discard flag in the KEEP_ALIVE command is set (step S113).
  • the source discards the key ID in the command and the exchange key corresponding to the key ID (step S117) and the key in the command.
  • the entry of the exchange key and device ID corresponding to the ID is deleted from the connection table (step S118), and the key counter is decremented by 1 (step S119).
  • the source sets the response information as “key invalid” (step S120), transmits a KEEP_ALIVE response including the response information to the sink of the request source, and ends the process.
  • the source initializes a timer corresponding to this key ID with a value indicating a predetermined time, and starts down-counting again (Ste S114). Then, the source sets the response information to “key is valid” (step S115), transmits a KEEP_ALIVE response including this response information to the requesting sink, and ends the processing.
  • the content using device (Sink) that simultaneously uses the content.
  • the content providing apparatus maintains the content providing apparatus because the content using apparatuses that have performed mutual authentication and key exchange procedures with the content providing apparatus transmit the KEEP_ALIVE command at a predetermined transmission cycle. It is possible to accurately grasp the exchange key to be used, and it is possible to newly communicate with another content using apparatus by discarding the unnecessary exchange key.
  • the content providing apparatus manages the exchange key to be maintained based on the key ID, even if the address changes during the mobile communication by the content using apparatus, it can be processed without being affected by the change.
  • a communication system that remotely accesses a server on a home network to which DTCP-IP is applied from a client outside the home and uses contents can be cited.
  • the communication system is not limited to a communication system using DTCP-IP or a communication system that remotely accesses content.
  • the present invention is similarly applied to a communication system that transmits content within the range of legitimate use by a user while limiting the number of devices that simultaneously transmit content that needs to be protected for copyright and other purposes. be able to.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　コンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう。　コンテンツ利用装置は、交換鍵と対応する鍵ＩＤを定期的にコマンドで送信し、コンテンツ提供装置は、鍵ＩＤを所定の受信周期毎に受信できている期間だけ対応する交換鍵を保持する。コンテンツ提供装置は、定期的に鍵ＩＤを受信できなくなると、対応する交換鍵を破棄し、その後、当該鍵ＩＤを含んだコマンドを受信すると、交換鍵は無効になったことを示す情報を含んだレスポンスを返す。

Description

通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
　本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って交換して暗号化コンテンツを伝送する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。
　従来、放送コンテンツやパッケージ・メディア中のコンテンツは、コンテンツ利用装置や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること（以下、「ローカル・アクセス（ＬＡ）」とも呼ぶ）が基本であった。例えば、屋外から携帯機器で上記のコンテンツ利用装置や再生機器と接続し、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること（以下、「リモート・アクセス（ＲＡ）」とも呼ぶ）は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）やＷｉＭＡＸ（Ｗｏｒｌｄ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）といったデータ通信技術、並びに、Ｈ．２６４などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。
　ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用を防止し、コンテンツの著作権を保護する必要がある。
　ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｌｉｃｅｎｓｉｎｇ　Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ　Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｅｎｔ　Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ａｎｄ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
　また、ＩＰネットワークに移植したＤＴＣＰ技術、すなわちＤＴＣＰ－ＩＰ（ＤＴＣＰ　ｍａｐｐｉｎｇ　ｔｏ　ＩＰ）によれば、家庭内においてもディジタル・コンテンツをＩＰネットワーク経由で流通させることができる。現在のＤＴＣＰ－ＩＰ（ＤＴＣＰ　Ｖｏｌｕｍｅ　１　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｓｕｐｐｌｅｍｅｎｔ　Ｅ　Ｒｅｖｉｓｉｏｎ　１．２）は、主にコンテンツの家庭内のみの利用を確保することを意図し、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ　Ｔｒｉｐ　Ｔｉｍｅ）や、ＩＰルーターのホップ回数（ＴＴＬ：Ｔｉｍｅ　Ｔｏ　Ｌｉｖｅ）に制限を設定している。
　例えば、ＳｏｕｒｃｅがＤＴＣＰ－ＩＰ認証を開始してから終了する直前までの間、受信した各ＡＫＥコマンドを監視し続け、ＴＴＬ値の最大値を更新し続け、認証手続きが終了する直前にＴＴＬ値の最大値をチェックし、この最大値が３以下であれば鍵交換して認証手続きを完了するが、３を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている（例えば、特許文献１を参照のこと）。
　また、コンテンツのオーナーは、コンテンツの不正利用を制限するために、１つのコンテンツ提供装置（Ｓｏｕｒｃｅ）が同時に多数のコンテンツ利用装置（Ｓｉｎｋ）にコンテンツ伝送を行なうことを禁止する可能性がある。
　これに対し、コンテンツを利用するユーザーは、複数のコンテンツ利用装置を状況に応じて使い分けたり、家庭内に設置された１台のコンテンツ提供装置を家族で共用したりすることもあり得る。このような利用形態において、家庭内の１台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
特開２００７－３６３５１号公報
　本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換アルゴリズムに従って交換して暗号化コンテンツを好適に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
　本発明のさらなる目的は、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。
　本願は、上記課題を参酌してなされたものであり、請求項１に記載の発明は、
　コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
　コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
　コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
　コンテンツ利用装置がコンテンツ提供装置に鍵ＩＤを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵ＩＤの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システムである。
　但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
　また、本願の請求項２に記載の発明は、
　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置である。
　本願の請求項３に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵ＩＤに対応する情報を前記鍵記録手段から破棄するように構成されている。
　本願の請求項４に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵ＩＤに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信するように構成されている。
　本願の請求項５に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄するように構成されている。
　本願の請求項６に記載の発明によれば、請求項２に記載の通信装置は、鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備えている。そして、鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するように構成されている。
　また、本願の請求項７に記載の発明は、
　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
　前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置である。
　本願の請求項８に記載の発明によれば、請求項７に記載の通信装置の鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信するように構成されている。
　また、本願の請求項９に記載の発明は、
　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録ステップと、
　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法である。
　また、本願の請求項１０に記載の発明は、
　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
　前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法である。
　また、本願の請求項１１に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段、
　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラムである。
　また、本願の請求項１２に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
　前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラムである。
　本願の請求項１１、１２に係る各コンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項１１、１２に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、それぞれ本願の請求項２、７に係る通信装置と同様の作用効果を得ることができる。
　本発明によれば、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。
　本願の請求項１、２、３、７、９乃至１２に記載の発明によれば、コンテンツ利用装置は、コンテンツ提供装置へ、鍵ＩＤを含んだ鍵寿命管理コマンドを所定の送信周期毎に送信し、コンテンツ提供装置は、鍵寿命管理コマンドを所定の受信周期毎に受信できている期間だけ対応する鍵を維持するので、コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限することができる。
　本願の請求項に記載４の発明によれば、コンテンツ提供装置は、鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持しているときには、鍵が有効であることを示すレスポンスを返信する。また、所定の受信周期で鍵寿命管理コマンドを受信できなかったことにより対応する鍵を破棄した後に、コマンドを受信したときには、鍵が無効であることを示すレスポンスを返す。したがって、コンテンツ利用装置は、自分が持つ鍵の現在の状況を確認することができる。
　本願の請求項５、８に記載の発明によれば、コンテンツ利用装置は不要になった鍵に対応する鍵寿命管理コマンドに不要である旨の情報をセットし、コンテンツ提供装置は、鍵が不要である旨の情報がセットされた鍵寿命管理コマンドを受信したことに応答して対応する鍵を破棄するので、台数の上限以内で他のコンテンツ利用装置と新たに鍵交換を行なうことができるようになる。
　本願の請求項６に記載の発明によれば、コンテンツ提供装置は、コンテンツのオーナーの求めなどに応じて、鍵交換するコンテンツ利用装置の事前登録を行なうことができる。コンテンツ提供装置は、事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するので、コンテンツ利用装置は自分が未登録であることを認識することができる。
　本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図１は、本発明に係る通信システムの一構成例を模式的に示した図である。 図２は、本発明に係る通信システムの他の構成例を模式的に示した図である。 図３は、コンテンツ提供装置１０の機能的構成を模式的に示した図である。 図４は、コンテンツ利用装置２０の機能的構成を模式的に示した図である。 図５は、ＳｏｕｒｃｅとＳｉｎｋの間でＤＴＣＰ－ＩＰにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。 図６は、ＳｏｕｒｃｅとＳｉｎｋ間で現行のＤＴＣＰ－ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。 図７は、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示した図である。 図８は、接続テーブルの更新処理の一例を示した図である。 図９は、ＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例を示した図である。 図１０は、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう動作シーケンス例を示した図である。 図１１は、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう他の動作シーケンス例を示した図である。
　以下、図面を参照しながら本発明の実施形態について詳細に説明する。
　本発明は、ＷＡＮなどの外部ネットワークを経由したリモート・アクセス（ＲＡ）を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ（ＲＡ－Ｓｏｕｒｃｅ）と、リモート・アクセスによりコンテンツを要求するクライアント（ＲＡ－Ｓｉｎｋ）からなる。本明細書では、リモート・アクセス時に行なうＡＫＥ手続きを、「ＲＡ－ＡＫＥ」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。
　図１には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、ＲＡ－Ｓｏｕｒｃｅに相当するコンテンツ提供装置１０が家庭内に設置され、ＲＡ－Ｓｉｎｋに相当するコンテンツ利用装置２０が屋外にいる。そして、コンテンツ利用装置２０は、携帯電話のような通信機能によってコンテンツ提供装置１０に対してリモート・アクセスする。
　コンテンツ提供装置１０は、一般にルーター３０とモデム４０経由でＷＡＮ５０などの外部ネットワークに接続される。ＷＡＮ５０は例えばインターネットである。ルーター３０には、ＷＡＮ５０側のＩＰアドレスが、ユーザーが加入するＩｎｔｅｎｅｔ　Ａｃｃｓｅｓｓ　Ｓｅｒｖｉｃｅ（ＩＡＳ）プロバイダー６０から割り当てられる。また、コンテンツ利用装置２０も、基本的にこのＩＰアドレスにアクセスする。ルーター３０は、コンテンツ提供装置１０にはプライベートＩＰアドレスを割り当て、ＷＡＮ５０からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター３０に割り当てられるＩＰアドレスは、ＩＡＳプロバイダー６０によって更新される場合があるが、そのようなケースではＤＤＮＳサービス７０を用い、ルーター３０乃至コンテンツ提供装置１０のＤＤＮＳ（Ｄｙｎａｍｉｃ　ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ））機能を使うことで対応できる。
　また、図２には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、ＲＡ－Ｓｉｎｋに相当するコンテンツ利用装置２０も家庭内に設置され、ルーター３１とモデム４１経由でＷＡＮ５０に接続されている。コンテンツ利用装置２０から発信されるＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）通信は、ルーター３１のＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）機能によってアドレス変換されるが、それ以外は図１の場合と同様である。
　図３には、コンテンツ提供装置１０の機能的構成を模式的に示している。コンテンツ提供装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１１と、コンテンツ受信／再生部１２と、通信部１３と、記憶部１４と、タイマー１５を備えるが、ＲＡ－Ｓｏｕｒｃｅとして機能して、リモート・アクセスでコンテンツを送信する。
　コンテンツ受信／再生部１２は、放送受信機能や、パッケージ・メディア再生機能を備えている。ＣＰＵ１１は、コンテンツ受信／再生部１２で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部１３を通じて、ＲＡ－ＡＫＥにより相互認証及び鍵交換を行なったＲＡ－Ｓｉｎｋ（コンテンツ利用装置２０）に送信する。
　記憶部１４には、後述の登録処理によって記憶することになったＲＡ－Ｓｉｎｋの識別情報や、ＲＡ－ＡＫＥを通じてＲＡ－Ｓｉｎｋと共有したリモート・アセス用の交換鍵とその交換鍵の識別情報（以下、「鍵ＩＤ」とも呼ぶ）などが記憶される。本実施形態では、同時に登録できる交換鍵及び鍵ＩＤの組はｎ個に制限される（但し、ｎは正の整数）。後述する接続テーブルや受信機器テーブルも、記憶部１４に保存される。また、記憶部１４は、コンテンツ受信／再生部１２で得たコンテンツを蓄積する用途で用いることもできる。
　タイマー１５は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合（例えば、後述するように、ＲＡ－Ｓｉｎｋからの鍵ＩＤの受信周期を管理する場合）に使われる。
　図４には、コンテンツ利用装置２０の機能的構成を模式的に示している。コンテンツ利用装置２０は、ＣＰＵ２１と、通信部２２と、コンテンツ出力部２３と、記憶部２４を備えるが、ＲＡ－Ｓｉｎｋとして機能して、リモート・アクセスでコンテンツを受信する。
　ＲＡ－Ｓｉｎｋとしてのコンテンツ利用装置２０は、通信部２２を通じてＲＡ－Ｓｏｕｒｃｅ（コンテンツ提供装置１０）に対して後述する交換鍵及び鍵ＩＤの登録処理を行なう他、ＲＡ－ＡＫＥを行なってＲＡ－Ｓｏｕｒｃｅから交換鍵を取得して記憶部２４に保持するとともに、その鍵を基に算出する暗号鍵でＲＡ－Ｓｏｕｒｃｅから得た暗号化コンテンツを復号して、コンテンツ出力部２３からコンテンツを出力する。記憶部２４は、ＲＡ－Ｓｏｕｒｃｅから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。
　タイマー２５は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合（例えば、後述するように、ＲＡ－Ｓｏｕｒｃｅからの鍵ＩＤの送信周期を管理する場合）に使われる。
　以下の説明では、交換鍵から暗号鍵を算出する方法はＤＴＣＰ－ＩＰに従うものとする（但し、本発明の要旨は必ずしもこの方法には限定されない）。
　ここで、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋの間でＤＴＣＰ－ＩＰにより暗号化コンテンツ伝送を行なう仕組みについて、図５を参照しながら説明しておく（ＲＡ－ＳｏｕｒｃｅとＲＡ－Ｓｉｎｋ間での仕組みも同様であると理解されたい）。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法があるが（周知）、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。
　ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立して、機器同士の認証（ＡＫＥ手続き）を行なう。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＡＫＥ手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵ＫauthをＳｏｕｒｃｅとＳｉｎｋで共有することができる。
　ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ鍵Ｋcの種となる交換鍵Ｋxを生成し、認証鍵Ｋauthで暗号化してＳｉｎｋに送る。Ｓｏｕｒｃｅ及びＳｉｎｋそれぞれにおいて、交換鍵Ｋxに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Ｋcを生成することができる。
　そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、ＨＴＴＰの手続きに従ってコンテンツ伝送が行なわれる。その際、ＡＫＥ手続きのためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成される（すなわち、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。
　ＨＴＴＰプロトコルに従ってコンテンツ伝送を行なうには、ＳｉｎｋがＳｏｕｒｃｅにコンテンツを要求するダウンロード形式と、Ｓｏｕｒｃｅ側からＳｉｎｋにコンテンツをプッシュするアップロード形式の２通りが挙げられる。前者の場合、ＨＴＴＰクライアントとしてのＳｉｎｋは、例えばＨＴＴＰ　ＧＥＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｏｕｒｃｅにコンテンツを要求し、これに対し、Ｓｏｕｃｅからは要求通りのコンテンツがＨＴＴＰレスポンスとして伝送される。また後者の場合、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅは、例えばＨＴＴＰ　ＰＯＳＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｉｎｋとの伝送を開始する。
　Ｓｏｕｒｃｅから伝送されるデータは、ＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Ｓｏｕｒｃｅは、乱数を用いてノンスＮcを生成して、交換鍵ＫxとノンスＮcと暗号モードに応じたコンテンツ鍵Ｋcを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮcと暗号モードの情報を含んだヘッダーからなるパケットをＴＣＰストリーム上に乗せて送信する。ＩＰプロトコルでは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
　Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、このストリームからノンスＮcとＥ－ＥＭＩを取り出すと、これらと交換鍵Ｋxを用いてコンテンツ鍵Ｋcを算出し、コンテンツ鍵Ｋcを用いて暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Ｓｉｎｋは、暗号化コンテンツを復号することなく、コンテンツを記憶部２４に格納したり、他の機器にスルーしたりする。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。（ＤＴＣＰ－ＩＰでは、パケットのヘッダー部に記述するＥ－ＥＭＩ（ＥｘｔｅｎｄｅｄＥｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。）
　なお、ＤＴＣＰ－ＩＰでは、連続不使用時間が所定の期間（例えば２時間）を超える前に交換鍵Ｋxを破棄することが規定されている。ＳｉｎｋはＳｏｕｒｃｅから最新の交換鍵Ｋxを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Ｋxの運用方法には、Ｓｉｎｋ毎に１つずつ鍵を用意する方法と、Ｓｉｎｋによらず１つの鍵を使う方法がある。本実施形態では、Ｓｉｎｋ毎に１つずつ交換鍵Ｋxを用意するとともに、各交換鍵Ｋxに識別情報（鍵ＩＤ）が割り当てられるものとする。
　図６には、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で現行のＤＴＣＰ－ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（ＲＴＴ－ＡＫＥ）を示している。
　ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ－Ｒｅｓｐｏｎｓｅ　ｐｏｒｔｉｏｎ　ｏｆ　ＡＫＥ）では、まず、コンテンツを要求するＳｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対し、Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ　ＩＤが含まれている。
　上記のチャレンジ・レスポンス応答手続きでは、ＴＴＬ（ＩＰルーターのホップ回数）の制限が課されている。すなわち、現在のＤＴＣＰ－ＩＰでは、送信機器はＡＫＥで用いるコマンドを送るＴＣＰ／ＩＰ通信においてＴＴＬが３以下に設定され、受信機器はＴＴＬが３より大きい場合は受け取ったデータを無効にしなければならない。
　その後、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ　ＲＴＴ　Ｐｒｏｔｏｃｏｌ）を経て、ＳｏｕｒｃｅからＳｉｎｋへ、ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドが送信され、これに対し、Ｓｉｎｋからレスポンス（図示しない）が返される。
　図６に示した現行のＤＴＣＰ－ＩＰに従うＲＴＴ－ＡＫＥでは、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）に上限を設定して、ＩＰネットワーク経由でコンテンツを伝送できる範囲を制限している。コンテンツのオーナーによっては、さらにコンテンツの不正利用を制限するために、１台のコンテンツ提供装置（ＲＡ－Ｓｏｕｒｃｅ）から同時にコンテンツ伝送を行なうコンテンツ利用装置（ＲＡ－Ｓｉｎｋ）の台数に上限を設定する場合がある。
　ところが、コンテンツを利用するユーザーは、複数のコンテンツ利用装置（ＲＡ－Ｓｉｎｋ）を状況に応じて使い分けたり、家庭内に設置された１台のコンテンツ提供装置（ＲＡ－Ｓｏｕｒｃｅ）を家族で共用したりすることもあり得る。家庭内の１台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。
　そこで、本実施形態に係る通信システムでは、１台のコンテンツ提供装置から同時にコンテンツ伝送を行なうコンテンツ利用装置の台数の上限をｎ台に設定しながら（但し、ｎは正の整数）、ユーザーによる特別な切り替え操作なしに、上限のｎ台に含まれるコンテンツ利用装置を適宜入れ替えることによって、コンテンツのオーナーからのコンテンツ保護の要求に応えながら、ユーザーによるコンテンツの正当な利用を確保する仕組みを導入している。
　コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限するために、コンテンツ利用装置は、コンテンツ提供装置へ、交換鍵と対応する鍵ＩＤを、所定の送信周期毎にコマンドで送信する。そして、コンテンツ提供装置は、鍵ＩＤを所定の受信周期毎に受信できている期間だけ、対応する交換鍵を保持する。他方、鍵ＩＤを含んだコマンドを所定の受信周期で受信できなかったときには、対応する交換鍵を破棄する。ＤＴＣＰ－ＩＰでは、連続不使用時間が所定の期間を超える前に交換鍵を破棄することが規定されているが（前述）、本実施形態では、２時間以内であっても鍵ＩＤを含んだコマンドを定期的に受信できなくなるとコンテンツ提供装置は対応する交換鍵を破棄する。
　コンテンツ提供装置は、鍵ＩＤを含んだコマンドを受信すると、対応する交換鍵を維持しているかどうかを確認する。そして、交換鍵を維持している間に対応するコマンドを受信したときには、交換鍵が有効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。他方、コンテンツ提供装置は、鍵ＩＤを含んだコマンドを所定の受信周期で受信できなかったことにより、対応する交換鍵を破棄した後にコマンドを受信したときには、交換鍵が無効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
　また、コンテンツ提供装置は、鍵ＩＤを含んだコマンドを定期的に受信できなかったことにより、交換鍵を破棄した後に、これに対応する鍵ＩＤを含んだコマンドを受信したときには、送信元のコンテンツ利用装置に対して、当該交換鍵（若しくは交換鍵から生成したコンテンツ鍵）が無効であるという情報を含んだレスポンスを返信する。
　また、コンテンツ利用装置は、コンテンツ提供装置との通信処理の終了などにより交換鍵が不要になったときには、定期的に送信するコマンドにそのことを示す情報をセットする。コンテンツ提供装置は、交換鍵が不要になったことを示す情報がセットされたコマンドを受信すると、対応する交換鍵を破棄する。
　また、コンテンツ提供装置は、事前に登録しているコンテンツ利用装置としか鍵の寿命管理を行なわないようにしてもよい。コンテンツ利用装置は定期的に送信するコマンドの中に自分を特定する機器ＩＤを含ませ、これに対し、コマンドを受信したコンテンツ提供装置は、受信したコマンドに含まれる機器ＩＤに対応するコンテンツ利用装置が登録済みであるかどうかを確認する。そして、コマンド送信元のコンテンツ利用装置が登録済みでない場合には、コンテンツ提供装置は、コマンドに含まれる鍵ＩＤに対応する交換鍵の有効確認を行なう前に、コンテンツ利用装置が未登録であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。
　図７には、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示している。但し、図示のシーケンスは、ＤＴＣＰのＦｕｌｌ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ処理をベースとして用いるものとする。また、リモート・アクセスでは設定しない運用が一般的と考えられるが、図６に示した動作シーケンスと同様に、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）に上限を設定してもよい。但し、図示を省略している。
　Ｓｉｎｋは、コンテンツを必要とするときに、Ｓｏｕｒｃｅに、ＣＨＡＬＬＥＮＧＥコマンドを送信する。このとき、当該相互認証及び鍵交換の手続が、Ｓｏｕｒｃｅへのリモート・アクセス用の鍵（Ｋｒ）を共有することが目的であることを示すため、Ｓｉｎｋは、ＣＨＡＬＬＥＮＧＥコマンドの中に、Ｋｒ－ｂｉｔをセットする。また、Ｓｉｎｋの特定情報であるＤｅｖｉｃｅ　ＩＤも、ＣＨＡＬＬＥＮＧＥコマンドで送信される。
　以後、ＤＴＣＰのＦｕｌｌ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎプロトコルに基づいて、ＳｏｕｒｃｅからＣＨＡＬＬＥＮＧＥコマンド、ＳｉｎｋからＲＥＳＰＯＮＳＥコマンド、ＳｏｕｒｃｅからＲＥＳＰＯＮＳＥコマンド又はＲＥＳＰＯＮＳＥ２コマンドが順に送信される。
　なお、チャレンジ・レスポンス部分の中では、ＳｉｎｋからＳｏｕｒｃｅへのレスポンスとして「ＲＥＳＰＯＮＳＥ２」が送られることがある。これは、機器がＣｏｍｍｏｎ　Ｄｅｖｉｃｅ　ＫｅｙとＣｏｍｍｏｎ　Ｄｅｖｉｃｅ　Ｃｅｒｔｉｆｉｃａｔｅを実装することで、Ｄｅｖｉｃｅ　ＩＤがＳｉｎｋの特定情報とならない場合であり、ＲＥＳＰＯＮＳＥ２コマンドで送られるＩＤｕがＳｉｎｋの特定情報として用いられる。
　Ｓｏｕｒｃｅは、Ｓｉｎｋを特定するための機器ＩＤを決める（ステップＳ７１）。Ｓｏｕｒｃｅは、ＲＥＳＰＯＮＳＥ２を受信したときはＩＤｕを、ＲＥＳＰＯＮＳＥ２コマンドを受信しなかったときはＤｅｖｉｃｅ　ＩＤを、機器ＩＤとして使う。
　Ｓｏｕｒｃｅは、Ｓｉｎｋとの相互認証及び鍵交換の手続の結果、Ｓｉｎｋにリモート・アクセス用の交換鍵Ｋｒを渡した場合、この交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤと、Ｓｉｎｋの機器ＩＤの組からなるエントリーを、下表に示すように、接続テーブルに保存する。接続テーブルには、同時にコンテンツ伝送できるＳｉｎｋの制限台数分のエントリーを保存することができるものとする。下表ではエントリー数は２であるが、本発明の要旨は制限台数が２台に限定されるものではない。
Figure JPOXMLDOC01-appb-T000001
　また、Ｓｏｕｒｃｅは、下表に示すようなリモート・アクセス用の受信機器テーブルを管理しており、同時にコンテンツ伝送を行なうＳｉｎｋの機器ＩＤを同テーブルに保存している。コンテンツのオーナーがリモート・アクセスするＳｉｎｋの事前登録を求める場合には、Ｓｉｎｋの機器ＩＤを受信機器テーブルにあらかじめ登録しておく。受信機器テーブルに事前登録できるＳｉｎｋの台数に上限を設定してもよいが、本発明の要旨は特定の上限台数に限定されるものではない。なお、Ｓｉｎｋの機器ＩＤを受信機器テーブルに登録する方法の一例として、ＤＴＣＰにおけるＲＴＴ－ＡＫＥを行なった際に、ＳｏｕｒｃｅがＳｉｎｋを登録するといった方法が挙げられる。
Figure JPOXMLDOC01-appb-T000002
　Ｓｏｕｒｃｅは、上述したように、Ｓｉｎｋとの相互認証及び鍵交換の手続においてＳｉｎｋの機器ＩＤを決定すると（ステップＳ７１）、受信機器テーブルに登録済みであるかを確認する（ステップＳ７２）。コンテンツのオーナーは、リモート・アクセスするＳｉｎｋをＳｏｕｒｃｅにあらかじめ登録しておくことを求める場合があり、それを確認するための処理である。
　Ｓｉｎｋの機器ＩＤが受信機器テーブルに未登録の場合には（ステップＳ７２のＮｏ）、Ｓｏｕｒｃｅは、当該相互認証及び鍵交換の手続の中断を知らせるＡＫＥ＿ＣＡＮＣＥＬコマンドをＳｉｎｋに送って、処理を終了する。Ｓｏｕｒｃｅは、ＡＫＥ＿ＣＡＮＣＥＬコマンドの中で、Ｓｉｎｋが受信機器テーブルに未登録であることを示す情報を記載するようにしてもよい。Ｓｉｎｋは、鍵交換の前に受信機器テーブルへの登録を行なうようにしてもよい。
　一方、Ｓｉｎｋの機器ＩＤが受信機テーブルに登録済みの場合には（ステップＳ７２のＹｅｓ）、続いて、Ｓｏｕｃｅは、Ｓｉｎｋの機器ＩＤが接続テーブルに記録されているかを確認する（ステップＳ７３）。
　Ｓｉｎｋの機器ＩＤが接続テーブルに記録されていない場合には（ステップＳ７３のＮｏ）、Ｓｏｕｒｃｅは、接続テーブルに新たに機器ＩＤを記録する余裕があるかをさらに確認する（ステップＳ７５）。本実施形態では、Ｓｏｕｒｃｅは、接続テーブルに記録可能な鍵ＩＤの個数を、鍵カウンターを用いて管理するものとし、この鍵カウンターの値が上限値ｎ未満であれば記録可能とする。Ｓｏｕｒｃｅは、鍵カウンターの値が、接続テーブルに記録されている鍵ＩＤの数と同じになるように管理している。
　鍵カウンターの値が既にｎに達している場合（ステップＳ７５のＮｏ）、Ｓｏｕｒｃｅは、当該相互認証及び鍵交換の手続の中断を知らせるＡＫＥ＿ＣＡＮＣＥＬコマンドをＳｉｎｋに送って、処理を終了する。Ｓｏｕｒｃｅは、ＡＫＥ＿ＣＡＮＣＥＬコマンドの中で、接続テーブルに登録されているエントリー数が上限ｎに達していることを示す情報を記載するようにしてもよい。
　鍵カウンターの値がｎ未満の場合（ステップＳ７５のＹｅｓ）、Ｓｏｕｒｃｅは、鍵カウンターに１を加算した後（ステップＳ７６）、リモート・アクセス用の交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤを生成し（ステップＳ７７）、この交換鍵Ｋｒ及び鍵ＩＤとＳｉｎｋの機器ＩＤの組からなるエントリーを接続テーブルに追加する（ステップＳ７８）。
　また、Ｓｉｎｋの機器ＩＤが接続テーブルに既に記録されている場合には（ステップＳ７３のＹｅｓ）、当該機器ＩＤに対応するエントリーを接続テーブルから削除した後（ステップＳ７４）、リモート・アクセス用の交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤを新たに生成し（ステップＳ７７）、この交換鍵Ｋｒ及び鍵ＩＤとＳｉｎｋの機器ＩＤの組からなるエントリーを接続テーブルに追加する（ステップＳ７８）。なお、別のパターンとして、当該機器ＩＤに対応するエントリーを接続テーブルから削除する代わりに、機器ＩＤと対応する交換鍵Ｋｒ及び鍵ＩＤを接続テーブルから取り出し、改めてこれらの情報を接続テーブルに追加しない処理も考えられる。但し、このパターンについては図示しない。
　そして、Ｓｏｕｒｃｅは、ステップＳ７７で生成したリモート・アクセス用の交換鍵Ｋｒを、ＤＴＣＰ仕様で規定されている方法に従って暗号化した後、ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって、鍵ＩＤとともにＳｉｎｋに送信する。
　Ｓｏｕｒｃｅは、交換鍵ＫｒをＳｉｎｋに送信すると同時に、この交換鍵Ｋｒの寿命管理をタイマーによって開始する（ステップＳ７９）。具体的には、Ｓｏｕｒｃｅは、鍵ＩＤと対応するタイマーを用意し（すなわち、接続テーブルに保存する鍵ＩＤ毎にタイマーを用意し）、所定の値（例えば１分に相当する値）をセットしてダウンカウントを開始する。
　以後、Ｓｏｕｒｃｅは、タイマーを一定のクロックでカウントをゼロまで自動的に減らす。タイマーがゼロに達したら、Ｓｏｕｒｃｅは、接続テーブルの更新処理を起動する。
　図８には、接続テーブルの更新処理の一例を示している。接続テーブルを更新することにより、鍵寿命管理コマンド（ＡＫＥ＿ＡＬＩＶＥ．ＣＭＤ）によって定期的に受信できなかった鍵ＩＤを含むエントリーが接続テーブルから削除される。
　Ｓｏｕｒｃｅは、まず、ゼロになったタイマーに対応する鍵ＩＤを含むエントリーが接続テーブルに存在するか否かをチェックする（ステップＳ８１）。該当するエントリーが接続テーブルに存在しなければ（ステップＳ８１のＮｏ）、処理を終了する。
　該当するエントリーが接続テーブルに存在するときには（ステップＳ８１のＹｅｓ）、Ｓｏｕｒｃｅは、ゼロになったタイマーに対応する鍵ＩＤを含むエントリーを接続テーブルから削除し（ステップＳ８２）、鍵カウンターを１だけ減算する（ステップＳ８３）。この結果、Ｓｏｕｒｃｅは新たに別のＳｉｎｋ（あるいは同じＳｉｎｋ）と改めて鍵交換を行なうことができるようになる。
　なお、コマンドの通信に要する遅延を考慮して、タイマーがゼロになった時点から交換鍵を破棄するまでにマージンを設けることや、別のＳｉｎｋが新たに交換鍵を要求するまでは図８に示した処理を実行しない、という運用も考えられる。
　このようにＳｏｕｏｒｃｅが交換鍵Ｋｒの寿命管理を行なうのに対し、Ｓｉｎｋは使用中の交換鍵Ｋｒの寿命更新を要求することができる。
　本実施形態では、Ｓｉｎｋは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを所定の送信周期で送信することによって交換鍵Ｋｒの寿命更新を要求する。また、Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを所定の受信周期で受信することで、対応する鍵を維持する。図９には、ＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例を示している。図示の例では、ＫＥＥＰ＿ＡＬＩＶＥコマンドは、ペイロードに、送信元であるＳｉｎｋを特定する情報である機器ＩＤを記載するフィールドと、寿命更新を要求する交換鍵Ｋｒを特定する情報である鍵ＩＤを記載するフィールドを含み、最後の１ビットが交換鍵Ｋｒの破棄を指示する破棄フラグとして用いられる。
　Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、寿命更新の処理を実行した後、ＫＥＥＰ＿ＡＬＩＶＥレスポンスを返信する。なお、図示を省略するが、ＫＥＥＰ＿ＡＬＩＶＥレスポンスの応答情報については、ＤＴＣＰのＡＫＥ　Ｃｏｎｔｒｏｌ　Ｃｏｍｍａｎｄ　Ｆｏｒｍａｔに定義されているｓｔａｔｕｓフィールドを用いることが考えられる。
　Ｓｏｕｒｃｅは、Ｓｉｎｋから受信したＫＥＥＰ＿ＡＬＩＶＥコマンドに含まれる鍵ＩＤに対応するタイマーに所定の時間を示す値をセットし、ダウンカウントを改めてその値から行なうように制御することで、寿命を更新する。なお、この寿命更新処理は、タイマーがゼロになった後でも、対応する鍵がまだ破棄されていなければ行なうものとする。
　図１０には、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう動作シーケンス例を示している。Ｓｉｎｋは、Ｓｏｕｒｃｅから交換鍵Ｋｒ及びその鍵ＩＤを渡されると、所定の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを送信する。
　Ｓｏｕｒｃｅは、ＳｉｎｋからＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、同コマンドに含まれる機器ＩＤが受信機器テーブルに登録済みかを確認する（ステップＳ１０１）。
　ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに未登録の場合は（ステップＳ１０１のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「機器が未登録」として（ステップＳ１０５）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに登録済みの場合は（ステップＳ１０１のＹｅｓ）、Ｓｏｕｒｃｅは、続いて、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在するかを確認する（ステップＳ１０２）。
　ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在していなければ（ステップＳ１０２のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１０６）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　また、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在している場合には（ステップＳ１０２のＹｅｓ）、Ｓｏｕｒｃｅは、この鍵ＩＤと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する（ステップＳ１０３）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が有効」として（ステップＳ１０４）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　Ｓｉｎｋは、Ｓｏｕｒｃｅとの相互認証及び鍵交換の手続が完了したら、取得した交換鍵Ｋｒを維持したい限り、所定の期間内の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを繰り返し送信する。
　また、Ｓｉｎｋは、Ｓｏｕｒｃｅとの通信（コンテンツの受信）を終了して交換鍵Ｋｒが不要になったときに、Ｓｏｕｒｃｅに交換鍵Ｋｒの破棄を求めるようにしてもよい。Ｓｏｕｒｃｅは、接続テーブルから該当するエントリーを削除することによって、上限台数ｎ以内で新たに別のＳｉｎｋがＳｏｕｒｃｅに接続して通信（コンテンツ伝送）を行なうことができるようになる。
　Ｓｉｎｋは、例えば所定の送信周期で送信するＫＥＥＰ＿ＡＬＩＶＥコマンドに交換鍵Ｋｒの破棄を求める情報を含めることで、Ｓｏｕｒｃｅに交換鍵Ｋｒの破棄を要求することができる。図９に示したＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例では、ペイロードに破棄フラグが含まれており、この破棄フラグをセットすることで、交換鍵Ｋｒの破棄を指示することができる。
　図１１には、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう他の動作シーケンス例を示している。図示の動作シーケンスは、不要となった交換鍵Ｋｒを破棄する処理を含む点で、図１０に示した動作シーケンスとは相違する。
　Ｓｏｕｒｃｅは、ＳｉｎｋからＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、同コマンドに含まれる機器ＩＤが受信機器テーブルに登録済みかを確認する（ステップＳ１１１）。
　ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに未登録の場合は（ステップＳ１１１のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「機器が未登録」として（ステップＳ１１６）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに登録済みの場合は（ステップＳ１１１のＹｅｓ）、Ｓｏｕｒｃｅは、続いて、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在するかを確認する（ステップＳ１１２）。
　ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在していなければ（ステップＳ１１２のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１２０）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　また、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在している場合には（ステップＳ１１２のＹｅｓ）、Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされているかをさらに確認する（ステップＳ１１３）。
　ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされているときには（ステップＳ１１３のＹｅｓ）、Ｓｏｕｒｃｅは、同コマンド中の鍵ＩＤと、これに対応する交換鍵を破棄するとともに（ステップＳ１１７）、同コマンド中の鍵ＩＤと対応する交換鍵と機器ＩＤのエントリーを接続テーブルから削除し（ステップＳ１１８）、鍵カウンターを１だけ減算する（ステップＳ１１９）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１２０）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされていないときには（ステップＳ１１３のＮｏ）、Ｓｏｕｒｃｅは、この鍵ＩＤと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する（ステップＳ１１４）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が有効」として（ステップＳ１１５）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。
　図１０並びに図１１に示した動作シーケンスによれば、家庭内に設置されたコンテンツ提供装置（Ｓｏｕｒｃｅ）の中のコンテンツを屋外から利用するようなケースで、コンテンツを同時に利用するコンテンツ利用装置（Ｓｉｎｋ）の台数を厳しく制限する必要が生じても、コンテンツ提供装置と相互認証及び鍵交換の手続を行なった各コンテンツ利用装置がそれぞれ所定の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを送信するので、コンテンツ提供装置は維持すべき交換鍵を正確に把握することができ、また、不要な交換鍵を破棄することで、別のコンテンツ利用装置と新たに通信を行なうことができる。
　コンテンツ提供装置は、鍵ＩＤによって維持すべき交換鍵を管理するので、コンテンツ利用装置が移動通信中にアドレスが変化しても、その影響を受けずに処理することができる。
　以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
　本発明の適用例として、ＤＴＣＰ－ＩＰが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨は、ＤＴＣＰ－ＩＰを適用した通信システムにも、コンテンツにリモート・アクセスする通信システムにも限定されない。著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう通信システムに、同様に本発明を適用することができる。
　要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
　１０…コンテンツ提供装置（ＲＡ－ｓｏｕｒｃｅ）
　１１…ＣＰＵ
　１２…コンテンツ受信／再生部
　１３…通信部
　１４…記憶部
　１５…タイマー
　２０…コンテンツ利用装置（ＲＡ－ｓｉｎｋ）
　２１…ＣＰＵ
　２２…通信部
　２３…コンテンツ出力部
　２４…記憶部
　２５…タイマー
　３０、３１…ルーター
　４０、４１…モデム
　５０…ＷＡＮ
　６０…ＩＡＳサービス
　７０…ＤＤＮＳサービス
 

Claims (12)

  1. 　コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
    　コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
    　コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
    　コンテンツ利用装置がコンテンツ提供装置に鍵ＩＤを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵ＩＤの情報を前記鍵記録手段に維持する鍵管理手段と、
    を具備する通信システム。
  2. 　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
    　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
    　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
    を具備する通信装置。
  3. 　前記鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵ＩＤに対応する情報を前記鍵記録手段から破棄する、
    請求項２に記載の通信装置。
  4. 　前記鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵ＩＤに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信する、
    請求項２に記載の通信装置。
  5. 　前記鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄する、
    請求項２に記載の通信装置。
  6. 　鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備え、
    　前記鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信する、
    請求項２に記載の通信装置。
  7. 　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
    　前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
    を具備する通信装置。
  8. 　前記鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信する、
    請求項７に記載の通信装置。
  9. 　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
    　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録ステップと、
    　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
    を有する通信方法。
  10. 　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
    　前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
    を有する通信方法。
  11. 　コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
    　コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
    　各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段、
    　コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段、
    として機能させるためのコンピューター・プログラム。
  12. 　コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
    　コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
    　前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
    として機能させるためのコンピューター・プログラム。
     
PCT/JP2011/062739 2010-07-29 2011-06-02 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム WO2012014566A1 (ja)

Priority Applications (11)

Application Number Priority Date Filing Date Title
MX2013000830A MX2013000830A (es) 2010-07-29 2011-06-02 Sistema de comunicacion, dispositivo de comunicacion, metodo de comunicacion y programa de computadora.
EP11812159.9A EP2600562A4 (en) 2010-07-29 2011-06-02 COMMUNICATION SYSTEM, COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMPUTER PROGRAM
US13/810,792 US8949605B2 (en) 2010-07-29 2011-06-02 Communication system, communication apparatus, communication method, and computer program
CA2804123A CA2804123A1 (en) 2010-07-29 2011-06-02 Communication system, communication apparatus, communication method, and computer program
KR1020137001051A KR20130044298A (ko) 2010-07-29 2011-06-02 통신 시스템, 통신 장치 및 통신 방법 및 컴퓨터 프로그램
BR112013001615A BR112013001615A2 (pt) 2010-07-29 2011-06-02 sistema de comunicação, aparelho de comunicação, método de comunicação e programa de computador
RU2013102867/08A RU2574356C2 (ru) 2010-07-29 2011-06-02 Система связи, устройство связи, способ связи и компьютерная программа
CN2011800358891A CN103026683A (zh) 2010-07-29 2011-06-02 通信系统、通信设备、通信方法和计算机程序
AU2011284062A AU2011284062A1 (en) 2010-07-29 2011-06-02 Communication system, communication device, communication method, and computer program
US14/587,678 US9553857B2 (en) 2010-07-29 2014-12-31 Communication system, communication apparatus, communication method, and computer program
US15/266,730 US9813397B2 (en) 2010-07-29 2016-09-15 Communication system, communication apparatus, communication method, and computer program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010171184A JP5652036B2 (ja) 2010-07-29 2010-07-29 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
JP2010-171184 2010-07-29

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/810,792 A-371-Of-International US8949605B2 (en) 2010-07-29 2011-06-02 Communication system, communication apparatus, communication method, and computer program
US14/587,678 Continuation US9553857B2 (en) 2010-07-29 2014-12-31 Communication system, communication apparatus, communication method, and computer program

Publications (1)

Publication Number Publication Date
WO2012014566A1 true WO2012014566A1 (ja) 2012-02-02

Family

ID=45529787

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/062739 WO2012014566A1 (ja) 2010-07-29 2011-06-02 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム

Country Status (11)

Country Link
US (3) US8949605B2 (ja)
EP (1) EP2600562A4 (ja)
JP (1) JP5652036B2 (ja)
KR (1) KR20130044298A (ja)
CN (2) CN105760718B (ja)
AU (1) AU2011284062A1 (ja)
BR (1) BR112013001615A2 (ja)
CA (1) CA2804123A1 (ja)
MX (1) MX2013000830A (ja)
TW (1) TWI455554B (ja)
WO (1) WO2012014566A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140185617A1 (en) * 2011-12-20 2014-07-03 Intel Corporation Methods and apparatus to limit transmission of data to a localized area in an ipv6 network
JP6230322B2 (ja) * 2013-08-01 2017-11-15 株式会社東芝 通信装置、鍵共有方法、プログラムおよび通信システム
US10198561B2 (en) * 2015-07-20 2019-02-05 Google Llc Systems, methods, and media for media session concurrency management with recurring license renewals
EP3661146B1 (en) * 2017-07-28 2022-10-26 Huawei Technologies Co., Ltd. Method and terminal for updating network access application authentication information
AU2021221526A1 (en) * 2020-09-18 2022-04-07 Thomas Moloney Pty Limited Latch Mechanism

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004062561A (ja) * 2002-07-30 2004-02-26 Dainippon Printing Co Ltd ソフトウェア管理システム、ソフトウェア管理サーバ、クライアント、プログラム、及び、記録媒体。
JP2007036351A (ja) 2005-07-22 2007-02-08 Sony Corp 情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
JP2007174249A (ja) * 2005-12-21 2007-07-05 Matsushita Electric Ind Co Ltd コンテンツ受信装置
JP2007188120A (ja) * 2006-01-11 2007-07-26 Toshiba Corp コンテンツデータ管理システム、及びコンテンツデータ管理方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0973565A (ja) 1995-09-05 1997-03-18 Fujitsu Ltd 有料道路の自動料金徴収システムにおける暗号化情報送受信システム
JP4973899B2 (ja) 2000-07-06 2012-07-11 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、記録媒体、および通信システム
JP2002351564A (ja) 2001-05-22 2002-12-06 Ntt Communications Kk アプリケーション提供サービスのための装置及び方法並びにプログラム
US7343297B2 (en) * 2001-06-15 2008-03-11 Microsoft Corporation System and related methods for managing and enforcing software licenses
JP4664582B2 (ja) 2002-08-28 2011-04-06 パナソニック株式会社 鍵配信装置、端末装置、記録媒体及び鍵配信システム
JP2006323707A (ja) 2005-05-20 2006-11-30 Hitachi Ltd コンテンツ送信装置、コンテンツ受信装置、コンテンツ送信方法及びコンテンツ受信方法
US20060274899A1 (en) * 2005-06-03 2006-12-07 Innomedia Pte Ltd. System and method for secure messaging with network address translation firewall traversal
US7627760B2 (en) * 2005-07-21 2009-12-01 Microsoft Corporation Extended authenticated key exchange
JP4518058B2 (ja) 2006-01-11 2010-08-04 ソニー株式会社 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4908849B2 (ja) * 2006-01-11 2012-04-04 富士通セミコンダクター株式会社 ファイル削除方法、ファイル・オープン方法、ファイル削除プログラム、および、ファイル・オープン・プログラム
WO2007085175A1 (fr) * 2006-01-24 2007-08-02 Huawei Technologies Co., Ltd. Procédé, système d'authentification et centre d'authentification reposant sur des communications de bout en bout dans le réseau mobile
JP2007199890A (ja) * 2006-01-25 2007-08-09 Sony Corp コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
JP4598734B2 (ja) * 2006-09-12 2010-12-15 株式会社エヌ・ティ・ティ・ドコモ 鍵情報配信サーバー、携帯端末、鍵情報配信システム及び車両設定用のアプリケーションプログラム
JP2009157848A (ja) * 2007-12-27 2009-07-16 Panasonic Corp データ送信装置、データ受信装置及びデータ送受信システム
JP2009194860A (ja) * 2008-02-18 2009-08-27 Toshiba Corp 送信装置、受信装置、コンテンツ送受信システム、コンテンツ送信方法、コンテンツ受信方法及びプログラム
JP2011146970A (ja) * 2010-01-15 2011-07-28 Alpine Electronics Inc 通信装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004062561A (ja) * 2002-07-30 2004-02-26 Dainippon Printing Co Ltd ソフトウェア管理システム、ソフトウェア管理サーバ、クライアント、プログラム、及び、記録媒体。
JP2007036351A (ja) 2005-07-22 2007-02-08 Sony Corp 情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
JP2007174249A (ja) * 2005-12-21 2007-07-05 Matsushita Electric Ind Co Ltd コンテンツ受信装置
JP2007188120A (ja) * 2006-01-11 2007-07-26 Toshiba Corp コンテンツデータ管理システム、及びコンテンツデータ管理方法

Also Published As

Publication number Publication date
JP2012034142A (ja) 2012-02-16
JP5652036B2 (ja) 2015-01-14
TW201210295A (en) 2012-03-01
RU2013102867A (ru) 2014-07-27
EP2600562A1 (en) 2013-06-05
US9813397B2 (en) 2017-11-07
US20170006005A1 (en) 2017-01-05
CN105760718B (zh) 2018-02-02
US20130124865A1 (en) 2013-05-16
CA2804123A1 (en) 2012-02-02
EP2600562A4 (en) 2016-01-06
CN105760718A (zh) 2016-07-13
US20150156182A1 (en) 2015-06-04
AU2011284062A1 (en) 2013-01-10
US8949605B2 (en) 2015-02-03
CN103026683A (zh) 2013-04-03
KR20130044298A (ko) 2013-05-02
MX2013000830A (es) 2013-02-11
TWI455554B (zh) 2014-10-01
US9553857B2 (en) 2017-01-24
BR112013001615A2 (pt) 2016-05-24

Similar Documents

Publication Publication Date Title
JP5614016B2 (ja) 通信システム、通信装置及び通信方法、コンピューター・プログラム、並びに、コンテンツ提供装置及びコンテンツ提供方法
JP4081724B1 (ja) クライアント端末、中継サーバ、通信システム、及び通信方法
US20120155642A1 (en) Communication system, communication apparatus, communication method, and computer program
US9813397B2 (en) Communication system, communication apparatus, communication method, and computer program
JP6270672B2 (ja) コンテンツ提供装置及びコンテンツ提供方法
JP6257497B2 (ja) コンテンツ伝送装置並びにシンク機器
JP6443516B2 (ja) 通信システム及び通信方法
US20170238181A1 (en) Mobile terminal to request an authentication to receive an exchanging key for remotely accessing content
JP6269798B2 (ja) リモート・アクセス・コンテンツ提供システム
RU2574356C2 (ru) Система связи, устройство связи, способ связи и компьютерная программа
JP6065881B2 (ja) 通信装置
JP2018174535A (ja) リモート・アクセス・コンテンツ提供方法
JP2017103774A (ja) 通信装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180035889.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11812159

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011812159

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2804123

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2011284062

Country of ref document: AU

Date of ref document: 20110602

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20137001051

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13810792

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: MX/A/2013/000830

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 2013102867

Country of ref document: RU

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112013001615

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112013001615

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20130122