CN101001354A - 内容传输系统、装置及方法 - Google Patents

内容传输系统、装置及方法 Download PDF

Info

Publication number
CN101001354A
CN101001354A CN 200710000216 CN200710000216A CN101001354A CN 101001354 A CN101001354 A CN 101001354A CN 200710000216 CN200710000216 CN 200710000216 CN 200710000216 A CN200710000216 A CN 200710000216A CN 101001354 A CN101001354 A CN 101001354A
Authority
CN
China
Prior art keywords
content
sink
source
unit
move
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN 200710000216
Other languages
English (en)
Other versions
CN100581239C (zh
Inventor
中野雄彦
岛久登
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
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
Application filed by Sony Corp filed Critical Sony Corp
Publication of CN101001354A publication Critical patent/CN101001354A/zh
Application granted granted Critical
Publication of CN100581239C publication Critical patent/CN100581239C/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种内容传输系统、装置及方法,即使在传输中在传输路径中发生了故障,也能防止内容分断或丢失而可靠地进行Move。Sink将正在Move的内容顺序记录到记录介质,但是,此记录内容在Move的结束处理成功之前处于无法使用的状态,在确认结束处理后,在对Sink端的记录内容进行有效化而将其置为可以使用的状态的同时,在Source端进行删除原来的内容或将其置为不可使用的处理。即使在传输路径中发生了故障,也可以在满足DTCP规定的条件的同时进行内容的Move处理。

Description

内容传输系统、装置及方法
技术领域
本发明涉及一种在设备间对数字化的AV数据等内容进行传输的内容传输系统、内容传输装置及内容传输方法以及计算机程序,尤其涉及一种在设备间对为了保护著作权及其他目的而限制复制的内容进行加密传输的内容传输系统、内容传输装置及内容传输方法以及计算机程序。
进一步详细地说,本发明涉及一种在遵循DTCP的信息设备之间执行加密内容的传输手续的内容传输系统、内容传输装置及内容传输方法以及计算机程序,尤其涉及一种使用DTCP MOVE功能从Source向Sink移动内容的内容传输系统、内容传输装置及内容传输方法以及计算机程序。
背景技术
随着信息技术的普及,AV内容几乎都进行了数字化,CD及DVD等记录播放数字内容的介质被广泛使用。另外,最近,HDD录音(像)机及装有HDD的DVD录音(像)机等对内容进行数字记录的设备也渗透到了家庭内。而且,经由网络的影像及音乐等内容的流通发布服务流行起来,不需要CD或DVD等介质的移动,通过网络在远程终端之间进行内容发布。
但是,由于数字化的内容比较容易进行复制或篡改等非法操作,所以,需要在允许个人的或家庭的内容的使用的同时,防御非法使用。尤其是,在国内面向2011年的地上模拟广播停止,正在急速从模拟广播接收机置换为数字广播接收机,必须从技术上实现对家庭内的AV内容的数字化进行内容的保护。
在日本国内,正在以ARIB(Association of Radio Industriesand Businesses:电波产业会)为中心推进数字广播相关的标准化,在数字卫星广播、数字地面波广播以及数字CATV中采用MPE G2系统(例如,参考非专利文献1),并且,附加“只能复制1次”(1次复制)这样的复制控制功能的导入义务,设置了严格的内容保护规定(例如,参考非专利文献2、非专利文献3)。
另外,作为与数字传输内容的保护相关的业界标准技术,有DTLA(Digital Transmission Licensing Administrator:数字传输授权管理者)开发的DTCP(Digital Transmission ContentProtection:数字传输内容保护),对以复制控制为代表的保护著作权的形式传输内容的结构进行了规定(例如,参考非专利文献4)。
在DTCP中,对内容传输时的设备之间的认证协议和加密内容的传输协议进行了规定。该规定的主旨是,遵循DTCP的设备不以非加密状态向设备外发出MPEG(Moving Picture ExpertsGroup:运动图像专家组)等容易操作的压缩内容,并且根据指定的相互认证及密钥交换(Authentication and Key Exchange:AKE)算法进行用于对加密内容进行解码所需的密钥交换,并且限制通过AKE命令进行密钥交换的设备的范围等。
作为内容提供源的服务器(Source)和作为内容提供目的地的客户端(Sink)通过AKE命令的发送接收,经过认证手续进行密钥的共享,使用该密钥,对传输路径进行加密,进行内容的传输。因此,非法客户端如果不成功地进行与服务器的认证就无法取得加密密钥,所以,就无法享受内容。
DTCP最初是对在传输路径中使用了IEEE1394等的本地网络上的数字内容的传输进行了规定。最近,以DLNA(DigitalLiving Network Alliance:数字生活网络联盟)为代表,在家庭内也可以通过IP网络流通数字化的AV内容的动向正式开始了,所以,对应于IP网络的DTCP技术,即DTCP-IP(DTCP mapping toIP:DTCP映射到IP)的开发正在进展。
DTCP-IP是将DTCP技术移植到IP网络的同样的技术,但是,在传输路径中使用IP网络、在加密的内容的传输中使用HTTP(Hyper Text Transter Protocol:超文本传输协议)或RTP(Real-Time Transter Protocol:实时传输协议)等在IP网络上安装的内容传输用协议的方面,与基于IEEE1394而规定的原来的DTCP不同。例如,按照HTTP的手续传输内容时,Source成为HTTP服务器,Sink成为HTTP客户端,生成用于HTTP的TCP/IP连接,进行加密内容的下载传输(在进行上载传输时,Source成为HTTP客户端,Sink成为HTTP服务器)。
如果本地网络通过路由器连接到互联网等外部的IP网络,则有数据的窃听、篡改、内容的非法复制等危险。另外,通过在Source与Sink之间的传输路径上设置由个人计算机等构成的非法的代理服务器,可以容易地进行内容的非法使用。为此,在DTCP-IP中,规定了一种方法,其通过设置AKE命令的TTL(Time To Live:存在时间),即对IP路由器的跳跃次数设置上限,将内容的使用范围限制在个人或家庭的范围内等,在保护内容的同时进行网络传输(例如,参考非专利文献5)。
在进行对应于著作权保护的内容传输时,需要指定与内容保护相关的内容属性。在DTCP-IP中,通过在内容传输用的信息包(PCP)的头部描述的E-EMI(Extended  Encryption ModeIndicator:扩展的加密模式指示器)和Embedded CCI(CopyControl Information:复制控制信息)这2种机制来实现内容所附带的复制控制信息的传输。
Embedded CCI是作为加密的内容流的一部分(即,插入到信息包的有效负载中)传输的复制控制信息。因为如果篡改内容流则会进行错误的解密,所以,可以保证Embedded CCI的完整性。另外一个E-EMI在纯文本状态的头部中记载,通过在信息包的头表示与内容流相关的复制控制信息,在可以容易访问的同时,实现安全性。E-EMI由描述加密模式的4位的字段构成,其值与复制控制信息的7个种类对应。位值定义如下表所示。在同表中,未使用的9个E-EMI值预备将来的扩展用。
【表1】
E-EMI值  加密模式  复制控制信息
1100  A0  Copy never(CN)
1010  B1  Copy-one-generation (COG) (只有Cognizant设备可以记录)
1000  B0  Copy-one-generation (COG) (Non-Cognizant可以记录)
0110  C1  Move mode(Audiovisual)
0100  C0  No-more-copies(NMC)
0010  D0  Copy-free with EPN asserted(CF/EPN)
0000  N.A. Copy-free(CF)
作为Source运行的设备根据内容流的特性选择正确的加密模式,据此设置E-EMI。与此相对,作为Sink运行的设备选择传输内容的信息包的头中的E-EMI指定的正确的解密模式。另外,作为Sink运行的设备按照E-EMI或Embedded CCI中的指定,对接收内容进行编码,暂时保存,在接着作为Source运行时,根据复制控制信息,控制2次内容传输动作。复制控制的种类如下。
Copy Free:保留著作权本身,但是,不进行使用了DTCP的复制控制。
Copy Never:绝对不得复制内容。
Copy One Generation:只允许复制1次(One Generation)。
No More Copies:已经不允许复制。
上述之中,No More Copies是原来设置为Copy OneGeneration的内容通过只复制1次(first generation)而成为不允许复制的状态。在DTCP-IP中,作为传输作为No More Copies编码后的内容的方法,提供了MOVE功能(例如,参考非专利文献5、非专利文献6)。网络通信中的MOVE相当于在设备间移动数据,基本上在移动源不残留数据。DTCP-IP中的MOVE功能是:Sink对接收到的内容作为No More Copies进行编码及操作,在Source端对传输后的内容进行删除或置为不能使用的条件下,从Source向Sink传输加密内容。例如,Copy One Generation的内容作为No More Copies编码并记录到了个人的录像机(PVR)等的Source中时,通过使用MOVE功能,在满足上述条件的同时,可以在CopyOne Generation的状态下进行编码,传输给单一Sink。另外,只在单一Source与单一Sink之间允许MOVE。
依据现状的规定,可以在E-EMI中使用C1模式或B1模式之一来进行MOVE传输。在Sink端,可以对这些模式中接收到的内容,使用AKE手续中取得的密钥进行解码并记录。另外,在Source端,需要在发送的瞬间对数据进行无效化。
依据MOVE功能,可以与将有形物体从某场所移动到其他场所的情况同样,不会出现MOVE的内容的实体数增加。反言之,需要保证作为传输对象的内容不在Source和Sink中同时存在(或不可使用)。因此,从Source向Sink的内容由多个消息传递手续构成时,必须在全部消息传递手续中贯彻遵守上述的在Source端删除内容或置为不能使用这个条件。为此,作为内容传输方法,需要进行“INCREMENTALMOVE”,即,在Source端将发送后的数据依次置为不能使用,并且在Sink端将接收数据依次置为可以使用。
例如,提出了一种内容管理装置,其将内容分割成多个区域,分别用不同的标题密钥进行加密,抽出内容解码化时使用的时变密钥,用抽出的该时变密钥顺序覆盖标题密钥区域的原来的标题密钥,使以前的内容无法进行解码,通过这种方式,安全且高效地删除MOVE处理后的原来的内容(例如,参考专利文献1)。
在此,出现了一种问题,即在Source与Sink之间进行的INCREMENTALMOVE序列由于内容传输中发生故障等中断了时,内容被分别分断在Source及Sink中。如果内容整体的传输成功结束,则可以安全地在Source与Sink之间转让内容的权利,但是,如果在传输处理的途中发生故障,则已经传输了的数据部分存在于Sink端,而传输前的数据部分残留在Source中,所以,内容被分断。作为INCREMENTAL MOVE处理中可能产生的故障,可以举出以下原因,例如:发生连接错误;一方的设备的电源被切断;内容保存用的介质被取出(或存储器故障);在Sink端保存内容的存储器没有剩余空间等,内容分断的事态并不少见。
在1个内容的移动通过多个消息传递手续进行时,如果每次Source进行消息传递时依次删除向Sink端移动结束的数据部分,则在内容传输中断时,在Source和Sink都无法恢复内容。如果在从Source向Sink的内容传输完成后对Source端的内容进行总括删除或置为不能使用,用户就不担心内容消失。但是,就无法贯彻遵守DTCP-IP中规定的MOVE执行时的前提条件(上述),很可能会危及内容的著作权保护。
例如,提出了一种内容移动系统,其在通过通用总线进行内容传输的Source和Sink之间设置内容移动控制器,根据在MOVE传输时Source和Sink双方中重复存在的可以播放的内容的量按照通常的播放时间不得超过1分钟这个DTCP规格,在内容移动控制器在Source及Sink任意一方检测出故障时,在1分钟以内中断MOVE,通过用以可以播放的状态残留在Source中的部分重新开始移动动作,避免内容的消失(例如,参考专利文献2)。但是,此时,由于必须通过内容移动控制器,所以,装置成本增加。另外,在无线LAN上任意的DTCP-IP设备作为Source以及Sink分别运行,在这些Source及Sink之间以自组织方式启动内容的MOVE处理的情况下,内容移动控制器的配置变得困难,或内容移动控制器的存在成为传输序列的瓶颈。
另外,提出了一种内容记录系统,其通过根据从接收完内容的Sink返回的内容的记录状态信息删除Source发送完成的内容,防止在Sink无法正常记录内容时的Source端的内容丢失(例如,参考专利文献3)。但是,在同系统中,对于由于内容传输中断而造成内容在Source和Sink中分断的事态,没有作任何考虑。
另外,提出了一种操作内容数据的装置,其在将进行了著作权保护的数据移动到其他记录装置时,通过独自的复制加密密钥对复制数据进行加密并保持,在万一由于移动时的故障等造成移动后的数据不良的情况下,将移动后的数据置为无效,在同装置中,通过根据复制数据恢复原来的数据,在进行著作权保护的同时,防止原来的数据消失(例如,参考专利文献4)。但是,在同装置中,在数据记录到移动目的地之后删除原来的数据,或与移动目的地中的数据的记录并行地删除原来的数据,所以,对于由于内容传输中断而造成的内容在Source和Sink中分断的事态,没有充分考虑。
【专利文献1】特开2003-101529号公报
【专利文献2】特开2005-158056号公报
【专利文献3】特开2005-293731号公报
【专利文献4】特开2005-250567号公报
【非专利文献1】ISO/IEC13818-1GENERIC CODING OFMOVING PICTURES AND ASSOCIATED AUDIO:SYSTEMSRecommendation H.222.0
【非专利文献2】ARIB TR-B14  地上デジタルテレビジョン放送運用規定
【非专利文献3】ARIB TR-B15BS/広带域CSデジタル放送運用規定
【非专利文献4】DTCP Specification Volume 1(Informational Version)Revision 1.4(http://www.dtcp.com/)
【非专利文献5】DTCP Volume 1 Supplement E(VISE)Mapping DTCP to IP(Informational Version)Revision 1.1(http://www.dtcp.com/)
【非专利文献6】DIGITAL TRANSMISSIONPROTECTION LICENSE AGREEMENT,Adopter Agreement--May 2005
发明内容
发明要解决的问题
本发明的目的在于提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其可以在遵守DTCP的信息设备之间很好地执行加密内容的传输手续。
本发明的进一步的目的在于提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其可以使用MOVE功能很好地从Source向Sink移动内容。
本发明的进一步的目的在于提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其在即使在内容传输中在传输路径中发生了故障时,也防止发生内容分断或丢失,可以可靠地进行内容的MOVE处理。
解决问题的手段
本发明是考虑上述问题而作出的,其第1方面是一种内容传输系统,其在发送内容的Source和接收内容的Sink之间传输内容,其特征在于,具备:内容指定单元,其指定在Source与Sink之间作为传输对象的内容;认证单元,其在Source与Sink之间进行相互认证及密钥交换;内容传输单元,其使用上述认证单元交换的密钥,将上述内容指定单元指定的内容从Source加密传输到Sink;内容传输结束处理单元,其响应于上述内容传输单元进行的内容传输处理的结束,对Sink端的内容进行有效化,并且,对Source端的原来的内容进行无效化;该内容传输系统从Source向Sink移动内容。
其中,此处所说的“系统”指的是多个装置(或实现特定功能的功能模块)从理论上集合在一起的系统,不考虑各装置或功能模块是否在单一的箱体内(以下相同)。
本发明涉及在IP网络上传输需要著作权保护的信息内容的内容传输系统,具体的,涉及一种内容传输系统,其在遵循DTCP-IP的信息通信设备之间,使用通过相互认证及密钥交换而共享的密钥,安全地进行加密内容传输。
在DTCP中,对以复制控制为代表的保护了著作权的形式传输内容的结构进行了规定。内容传输的形式有:将Source上的内容复制到Sink中的方法;从Source向Sink移动内容而不在Source中残留内容的方法,即,MOVE。在DTCP中,准备了MOVE功能,该MOVE功能是以Sink将接收的内容作为No More Copies进行编码并操作以及在Source端对传输后的内容进行删除或置为不能使用为条件,对作为No More Copy进行了编码的内容进行传输。
依据MOVE功能,用户可以将无法复制的内容移动到其他设备并享受。另外,可以与将有形物体从某场所移动到其他场所的情况同样,不会出现MOVE的内容的实体数增加,所以,没有内容保护上的问题。
在MOVE传输序列上必须贯彻遵守在Source端删除内容或置为不能使用这个条件。为此,需要进行“INCREMENTALMOVE”,即,在Source端将发送后的数据依次置为不能使用,并且在Sink端将接收数据依次置为可以使用。但是,如果由于发生传输路径中的故障或其他原因,MOVE序列中断时,会发生内容在Source与Sink之间分断或丢失,用户本来正确取得的内容消失的情况。
针对这种情况,在本发明涉及的内容传输系统中,Sink将MOVE传输中的内容顺序记录到记录介质,但是,此记录内容到MOVE传输的结束处理成功之前处于无法使用的状态。之后,在进行了内容传输的结束处理的确认,即,Commitment时,对Sink端的记录内容进行有效化将其置为可以使用的状态,同时,在Source端进行删除原来的内容或置为不能使用的处理。通过这种方式,在MOVE传输中不会出现在Source和Sink中No MoreCopies内容重复存在的情况,而且,即使由于在传输路径中发生故障等造成MOVE传输中断,内容也不会分断,可以从Source重新开始内容传输。
依据这种内容传输方法的MOVE传输等价于在Source与Sink之间总括移动内容整体。在Source端将发送后的数据依次置为不能使用并且在Sink端将接收数据依次置为可以使用的INCREM ENTAL MOVE不同,也可以称为“BLOCK MOVE”。BLOCK MOVE也不会在其传输序列上在Source和Sink上重复存在相同的内容,所以,可以说是满足了DTCP中规定的条件的内容的MOVE处理。
另外,Sink在MOVE的结束处理成功之前,不能播放记录的内容,但是,也可以与在对接收内容进行了无效化的状态下进行记录的动作并行,对接收内容进行播放输出(表现)。因为BLOCKMOVE如果是满足DTCP中规定的条件的MOVE处理,那么,与BLOCK MOVE并行对内容进行解码并输出等价于内容的流动。即,在解码内容输出的同时数据消失,所以,不等于内容的复制,不与在Source和Sink双方中不得重复存在可以播放的内容这个DTCP规格相抵触。
此时,在Sink端,在暂时对接收的内容进行了解码时,与作为No More Copies实施规定的编码处理并保存到硬盘或其他记录介质的动作并行,将此解码内容直接转换(表现)为视频及音频信号,从显示器等AV输出部进行影像以及声音输出。用户可以在MOVE传输中确认该内容的内容,并且可以实时地享受内容视听。
另外,在MOVE处理手续期间中,Source以无法从其他Sink进行MOVE请求的方式,对作为MOVE对象的内容进行锁定。因为,如果对多个Sink对相同的内容进行多重MOVE,则内容的实体数会增加,即,事实上成为复制,会破坏No More Copies这个复制控制信息。
INCREMENTAL MOVE可以通过DTCP-IP决定的MOVE传输进行安装。与此相对,并不是BLOCK MOVE包含在作为本申请的基础申请的专利申请2006-4129的申请当时(2006年1月11日)的DTCP式样中。因此,在进行BLOCK MOVE时,上述认证单元希望在Source与Sink之间进行认证处理之时,同时确认相互的设备是否对应于BLOCK MOVE,或防止MOVE传输的冒充。另外,在其中一方的设备不对应BLOCK MOVE的情况下,也可以将模式切换到目前的INCREMENTAL MOVE,进行内容的MOVE处理。
在本发明涉及的内容传输系统中,为了指定要移动的内容,可以使用UPnP(注册商标)中规定的CDS(Content DirectoryService:内容目录服务)来进行。另外,之后进行的在Source与Sink之间的认证手续、内容传输手续、及内容传输结束处理手续可以按照DTCP-IP进行各处理。
例如,用户可以操作Sink,以从作为提供内容的服务器运行的Source下载内容的形式进行内容的移动。
在这种情况下,在Sink中,可以根据针对CDS∷Browserequest的来自Source的CDS∷Browse response中包含的信息,取得要移动的内容的认证及密钥交换用的套接字信息,并且,确认该内容是否可以从Source移动。
然后,Sink可以在头内包含表示内容的移动的头信息,使用HTTP GET方法,从Source取得加密内容。
或者,用户可以操作Source,以对作为提供内容的服务器运行的Sink上载内容的形式移动内容。
在这种情况下,Source可以使用CDS∷Create Objectrequest,对Sink请求该内容的移动场所的生成。
此时,由于认证处理从Sink开始,所以,为了从Sink端确立认证及密钥交换用的T CP连接,Source需要对Sink通知套接字信息。例如,也可以通过在CDS∷Create Object request中包含带有套接字信息的属性,对Sink通知认证及密钥交换用的套接字信息。或者,Source也可以使用(不包含内容的)HTTP POST方法中包含的头信息,对Sink通知认证及密钥交换用的套接字信息。
然后,Source可以在头内包含表示内容的移动的头信息,使用HTTP POST方法,向Sink上载传输加密内容。
另外,假设在Source与Sink之间,针对每个移动的内容,通过AKE手续进行内容移动专用的密钥的交换。Source在从Sink接收到将成为多次传输移动对象内容的GET请求时,拒绝该请求,在MOVE传输处理完成的同时,迅速对MOVE传输结束的内容进行无效化,通过这种方式,使得不会出现多次移动相同的内容(即,实质是复制)的情况。
另外,Source通过在正在将内容移动到某Sink时,拒绝来自其他Sink的该内容的移动请求,使得不会出现将相同的内容移动到多个Sink(即,实质是复制)的情况。
另外,对内容的MOVE传输结束、进而内容传输结束处理完成了的情况进行应答,消除Source及Sink中的内容移动专用的交换密钥。反言之,到内容的传输结束处理结束为止,维持为了AKE手续确立的TCP连接。
此时,在到内容传输处理结束为止的过程中,可以使用为了AKE手续确立的TCP连接,取消内容传输处理。内容传输的取消处理根据来自Sink或Source的至少一方的请求启动。取消内容传输处理时,对传输到Sink的内容进行无效化。
另外,在到内容传输处理结束为止的过程中,在Sink与Source之间的通信中断时,可以根据来自Sink或Source的至少一方的请求中止内容传输处理。中止时的Source以及Sink的动作与取消内容传输的情况相同。
在本发明涉及的内容传输系统中,实施用于确认在Sink与Source之间内容传输安全结束,即,Commitment的内容传输结束处理,通过对Sink端的内容进行有效化,并且对Source端的原来的内容进行无效化,完成内容的移动。在此内容传输的结束处理中,首先,从Sink发送表示内容接收结束的第1命令,Source对此命令进行应答,将Source端的原来的内容置为中间无效状态。接着,在从Source返回了针对第1命令的第1响应时,Sink对此响应进行应答,对传输到Sink端的内容进行有效化,并且消除Sink端保持的内容移动专用的密钥。然后,在从Sink发送了表示内容有效化的第2命令时,Source对此命令进行应答,将Source端的原来的内容置为无效状态,并且消除Source端保持的内容移动专用的密钥。
另外,为了如下的情况,即,在尽管内容传输单元进行的从Source向Sink的内容传输成功结束,但是,由于一方的设备的电源切断等造成内容传输结束处理单元进行的处理中断的情况,内容传输系统还可以具备用于重新开始中断了的内容传输结束处理的内容传输结束处理重新开始单元。通过此重新开始单元,内容传输手续不会浪费,并且,可以回避在Sink与Source双方内容都变成无效。
此内容传输结束处理重新开始单元可以通过以下方式重新开始内容传输结束手续,即,在Source从Sink接收到表示内容接收结束的第1命令时,在Source还保持着内容移动专用的交换密钥及第1响应发送的信息的情况下,将Source端的原来的内容置为中间无效状态,从Source向Sink返回针对第1命令的第1响应。
或者,内容传输结束处理重新开始单元可以通过以下方式重新开始内容传输结束手续,即,在Source从Sink接收到表示内容接收结束的第2命令时,在Source还保持着内容移动专用的交换密钥及第1响应发送的信息的情况下,将Source端的原来的内容置为无效状态,消除Source端保持的内容移动专用的密钥及第1响应发送的信息,并且,从Source向Sink返回针对第2命令的第2响应。
或者,内容传输结束处理重新开始单元可以通过以下方式重新开始内容传输结束处理,即,在Sink还保持着内容移动专用的交换密钥及第1命令发送的信息的情况下,确立与作为内容移动源的Source之间的连接,如果相应的内容在Sink端是无效状态,则对Source发送第1命令,如果相应的内容在Sink端已经进行了有效化,则发送第2命令。
此时,为了从Sink端确立认证及密钥交换用的TCP连接,Source需要对Sink通知套接字信息。在内容传输以下载形式进行的情况下,Sink对Source发送CDS∷Browse request,根据来自Source的CDS∷Browse response中包含的信息,取得套接字信息,可以确立用于重新开始内容传输结束处理的TCP连接。另外,在内容传输以上载形式进行的情况下,在Source中,使用(不包含内容的)HTTP POST方法的头信息,对Sink通知套接字信息,Sink根据此套接字信息,可以确立重新开始内容传输结束处理的TCP连接。
另外,在DTCP-IP中,通过在Source与Sink之间的传输路径上设置由个人计算机等构成的非法的代理服务器,可以容易地进行通信内容的篡改。尤其是在认证单元进行的在Source与Sink之间确认与MOVE方法相关的能力之后开始BLOCK MOVE这样的系统中,尽管Source对应于BLOCK MOVE,但是,代理服务器可以对Sink假装Source不对应BLOCK MOVE,使Sink进行INCREMENTAL MOVE。此时,在Sink端,在每次从Source接收数据时逐次进行有效化的同时,在内容传输处理结束时,代理服务器对Source进行内容传输处理的取消,通过这种方式,产生在Source和Sink双方中存在有效的内容的与DTCP-IP的规定相抵触的事态。
因此,本发明涉及的内容传输系统希望还具备冒充防止单元,该冒充防止单元防止冒充在Source与Sink之间确认过的能力,或者通过其他方式伪装Sink端的MOVE模式。
此冒充防止单元在例如,针对每个内容传输方法,即,INCREMENTAL MOVE和BLOCK MOVE,改变根据上述认证单元中交换的密钥生成内容加密密钥的方法。在这种情况下,通过冒充进行INCREM ENTAL MOVE的Sink无法与进行BLOCKMOVE的Source共享内容加密密钥,内容不被有效化。因此,不会在Source和Sink中重复存在内容。
或者,冒充防止单元也可以针对每个内容传输方法,即,INCREMENTAL MOVE和BLOCK MOVE,改变对在上述认证单元中交换的密钥进行加扰(scramble)的方法。在这种情况下,通过冒充进行INCREMENTAL MOVE的Sink无法对在认证单元中交换的密钥进行解扰,无法得到正确的内容加密密钥。因此,不会在Source和Sink中重复存在内容。
或者,冒充防止单元也可以在用于相互认证及密钥交换的挑战/响应手续中,在从Sink向Source的通过电子签名保护的通信消息中包含与内容传输方法相关的信息。通过冒充Sink进行了INCREMENTAL MOVE的情况下,即使在Source端要根据能力的确认进行BLOCK MOVE,也可以在挑战/响应的手续中检测出进行了冒充的情况。Source可以采用停止MOVE传输本身,或配合Sink端,切换为INCREMENTAL MOVE等对策。
另外,本发明的第2方面是一种计算机程序,其是为了在计算机系统上执行用于作为DTCP Source发送内容的处理而以计算机可读形式描述的计算机程序,其特征在于,使上述计算机系统只执行一下步骤:内容指定步骤,其在与Sink之间指定作为传输对象的内容;认证步骤,其通过AKE手续在与Sink之间进行相互认证及密钥交换;内容传输步骤,其使用在上述认证步骤中交换的密钥,将在上述内容指定步骤中指定的内容向Sink进行加密传输;内容传输结束处理步骤,其响应于在上述内容传输步骤中进行的内容传输处理的结束,对原来的内容进行无效化;向Sink移动内容。
另外,本发明的第3方面是一种计算机程序,其是为了在计算机系统上执行用于作为DTCP Sink接收内容的处理而以计算机可读形式描述的计算机程序,其特征在于,使上述计算机系统执行以下步骤:内容指定步骤,其指定在与Source之间作为传输对象的内容;认证步骤,其通过AKE手续在与Source之间进行相互认证及密钥交换;内容传输步骤,其使用在上述认证步骤中交换的密钥,将在上述内容指定步骤中指定的内容从Source进行加密传输;内容传输结束处理步骤,其响应于在上述内容传输步骤中进行的内容传输处理的结束,对接收到的内容进行有效化;从Source移动内容。
本发明的第2到第3的各方面涉及的计算机程序定义了为了在计算机系统上实现规定处理而以计算机可读形式描述的计算机程序。换言之,通过将本发明的第2到第3的各方面涉及的计算机程序安装到计算机系统,在计算机系统上,发挥协作的作用,分别作为在本发明的第1方面涉及的内容传输系统中的Source及Sink来运行。通过启动这种内容传输装置,构筑基于DTCP的网络,可以得到与本发明的第1方面涉及的内容传输系统相同的作用效果。
发明效果
依据本发明,可以提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其可以在遵守DTCP的信息设备之间很好地执行加密内容的传输手续。
另外,依据本发明,可以提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其可以使用MOVE功能很好地从Source向Sink移动内容。
另外,依据本发明,可以提供一种优秀的内容传输系统、内容传输装置及内容传输方法以及计算机程序,其在即使在内容传输中在传输路径中发生了故障时,也能防止发生内容分断或丢失,可以可靠地进行内容的MOVE处理。
本发明涉及的内容传输系统可以按照DTCP中规定的条件,进行与在Source与Sink之间总括移动内容整体等价的BLOCKMOVE。
BLOCK MOVE通过内容传输结束处理来实现,该内容传输结束处理响应于内容传输处理的结束,对Sink端的内容进行有效化的同时,对Source端的原来的内容进行无效化。由于其中一方的设备的电源切断等原因,存在内容传输结束处理中断的危险,但是,依据本发明涉及的内容传输系统,可以重新开始内容传输结束处理,正确结束MOVE处理。
另外,在进行BLOCK MOVE的情况下,存在以下危险:通过在Source与Sink之间存在非法的代理服务器,例如,冒充Sink端的能力,或者通过其他方法伪装MOVE传输,进行复制传输,内容重复存在。针对这种危险,依据本发明涉及的内容传输系统,冒充防止单元可以防止冒充在Source与Sink之间确认过的能力,伪装Sink端的MOVE模式的情况。
另外,根据本发明,提供一种内容传输装置,其作为按照DTCP发送内容的Source来运行,其特征在于,具备:内容指定单元,其指定在与Sink之间作为传输对象的内容;认证单元,其通过AKE手续在与Sink之间进行相互认证及密钥交换;内容传输单元,其使用所述认证单元交换的密钥,将所述内容指定单元指定的内容向Sink进行加密传输;和内容传输结束处理单元,其响应于所述内容传输单元进行的内容传输处理的结束,对原来的内容进行无效化,该内容传输装置向Sink移动内容。
另外,根据本发明,提供一种内容传输装置,其作为根据DTCP接收内容的Sink来运行,其特征在于,具备:内容指定单元,其指定在与Source之间作为传输对象的内容;认证单元,其通过AKE手续在与Source之间进行相互认证及密钥交换;内容传输单元,其使用所述认证单元交换的密钥,将所述内容指定单元指定的内容从Source进行加密传输;和内容传输结束处理单元,其响应于所述内容传输单元进行的内容传输处理的结束,对接收到的内容进行有效化,从Source移动内容。
另外,根据本发明,提供一种内容传输方法,其作为DTCPSource发送内容,其特征在于,具备:内容指定步骤,其指定在与Sink之间作为传输对象的内容;认证步骤,其通过AKE手续在与Sink之间进行相互认证及密钥交换;内容传输步骤,其使用在所述认证步骤中交换的密钥,将在所述内容指定步骤中指定的内容向Sink进行加密传输;和内容传输结束处理步骤,其响应于在所述内容传输步骤中进行的内容传输处理的结束,对原来的内容进行无效化,向Sink移动内容。
另外,根据本发明,提供一种内容传输方法,其作为DTCPSink接收内容,其特征在于,具备:内容指定步骤,其指定在与Source之间作为传输对象的内容;认证步骤,其通过AKE手续在与Source之间进行相互认证及密钥交换;内容传输步骤,其使用在所述认证步骤中交换的密钥,将在所述内容指定步骤中指定的内容从Source进行加密传输;和内容传输结束处理步骤,其响应于在所述内容传输步骤中进行的内容传输处理的结束,对接收到的内容进行有效化,从Source移动内容。
本发明的进一步的其他目的、特征及优点通过根据后述的本发明的实施方式及附图的详细说明,将会清楚。
附图说明
图1是表示本发明的一实施方式涉及的信息通信系统的结构例的示意图。
图2是表示在图1所示的信息通信系统中作为客户端(即,Sink)运行的信息通信装置的功能结构的图。
图3是表示在图1所示的信息通信系统中作为服务器(即,Source)运行的信息通信装置的功能结构的图。
图4是用于说明在Source与Sink之间进行加密内容传输的结构的图,该加密内容传输使用了通过基于AKE的密钥交换手续、及密钥交换而共享的密钥。
图5是表示PCP的数据结构的示意图。
图6是表示填充PCP有效负载的样子的图。
图7是表示用于并行进行内容的MOVE处理和接收内容的播放处理的Sink的结构例的图。
图8是表示以下载形式在Source与Sink之间进行MOVE传输的情况下的动作序列的图。
图9是表示在以下载形式在Source与Sink之间进行MOVE传输的情况下,以UPnP(注册商标)为基础,使用CDS选择在Sink与Source之间作为MOVE对象的内容的动作序列的图。
图10是表示MOVE用AKE手续的动作序列的图。
图11是表示在Source及Sink之间执行MOVE结束处理手续的动作序列的图。
图12是表示以上载形式在Source与Sink之间进行MOVE传输的情况下的动作序列的图。
图13是表示在以上载形式在Source与Sink之间进行MOVE传输的情况下,以UPnP(注册商标)为基础,使用CDS从Source向Sink通知内容的上载的动作序列的图。
图14A是表示以下载形式从Source向Sink进行内容的MOVE的情况下的Source及Sink各自执行的处理动作的流程图。
图14B是表示从作为HTTP服务器的Source向作为HTTP客户端的Sink进行内容的下载MOVE传输的情况下的Source及Sink各自执行的处理动作的流程图。
图15A是表示以上载形式从Source向Sink进行内容的MOVE的情况下的Source及Sink各自执行的处理动作的流程图。
图15B是表示以上载形式从Source向Sink进行内容的MOVE时的Source及Sink各自执行的处理动作的流程图。
图16是表示包含了能力的确认序列的MOVE用AKE手续的动作序列例的图。
图17是详细表示图16中的能力交换手续的部分的图。
图18是具体表示在图11所示的下载MOVE传输结束序列上Sink及Source各自实施的处理内容的图。
图19是表示在作为HTTP服务器运行的Source中,重新开始中断了的下载MOVE传输结束处理的处理步骤的流程图。
图20是表示在作为HTTP服务器运行的Source中,重新开始中断了的下载MOVE传输结束处理的处理步骤的流程图。
图21是表示在作为HTTP客户端运行的Sink中,重新开始中断了的下载MOVE传输处理的处理步骤的流程图。
图22是表示对Sink进行MOVE模式冒充攻击的动作序列例的图。
图23是表示对MOVE模式冒充攻击采取了对策的动作序列例的图。
图24是表示对MOVE模式冒充攻击采取了对策的动作序列例的图。
图25是表示对MOVE模式冒充攻击采取了对策的动作序列例的图。
图26是表示对MOVE模式冒充攻击采取了对策的动作序列例的图。
图27是表示MOVE用AKE手续的其他动作序列例的图。
图28是表示Sink使用HTTP GET请求来请求内容,Source使用HTTP GET响应进行内容传输的动作序列例的图。
图29是表示在下载形式的MOVE序列中,重新开始中断了的MOVE传输结束处理时,在Sink及Source之间确立TCP连接的处理步骤的流程图。
图30是表示在Source与Sink之间进行上载MOVE传输的动作序列的图(但是,这是使用Source使用POST请求来通知套接字信息的方法的情况)。
图31是表示在Source与Sink之间进行上载MOVE传输的动作序列的图(但是,这是对从Source发送的带有套接字信息的POST请求,在AKE手续结束后,Sink返回POST响应,之后,将内容作为针对POST请求的消息体进行传输的情况)。
图32A是表示从Source向Sink进行内容的上载MOVE传输的情况下的Source及Sink各自执行的处理动作的流程图。
图32B是表示从Source向Sink进行内容的上载MOVE传输的情况下的Source及Sink各自执行的处理动作的流程图。
图33是表示在上载形式的MOVE序列中,重新开始中断了的MOVE传输结束处理时,在Sink及Source之间确立TCP连接的处理步骤的流程图。
附图标记说明
10:DTCP-IP认证块;11:AKE块;12:消息摘要生成块;13:内容解码块;20:DTCP-IP内容接收块;21:HTTP客户端块;22:HTTP请求管理块;23:HTTP响应管理块;30:内容播放/记录块;40:DTCP-IP认证块;41:AKE块;42:消息摘要生成块;43:内容加密块;50:DTCP-IP内容发送块;51:HTTP服务器块;52:HTTP请求管理块;53:HTTP响应管理块;60:内容管理块。
具体实施方式
本发明涉及一种内容传输系统,其根据指定的复制控制信息,对以著作权或其他目的需要保护的信息内容进行加密传输。这种系统的具体例是使用了在DTCP-IP设备之间进行的HTTP协议的内容传输。下面参照附图详细说明本发明的实施方式。
A.系统结构
遵循DTCP-IP的内容传输由发送内容的Source和接收内容并播放或记录的Sink构成。作为内容的传输方法,可以考虑下载传输和上载传输,下载传输是作为服务器运行的Source根据来自作为客户端运行的Sink的请求发送内容;上载传输是根据来自作为客户端运行的Sink的请求,向作为服务器运行的Sink发送内容。
图1是表示本发明的一实施方式涉及的信息通信系统的结构例的示意图。在图示的例中,通过Source和Sink的各装置构成了DTCP-IPAKE系统。作为遵守DTCP-IP的认证服务器的Source和作为遵守DTCP-IP的认证客户端的Sink通过网络连接在一起。此处所说的网络包括Ethernet(注册商标)、互联网、其他IP网络。
图2及图3分别是表示在图1所示的内容传输系统中,作为Sink及Source运行的内容传输装置的、特别着眼于认证及内容传输的功能结构的示意图。但是,在图2及图3中,表示作为服务器运行的Source根据来自作为客户端运行的Sink的请求来下载传输内容的情况下的功能结构,省略对上载传输时的功能结构的说明。Sink和Source可以在互联网等TCP/IP网络上确立连接,使用此连接,可以执行认证手续及内容传输手续。
图2所示的Sink具备DTCP-IP认证块10、DTCP-IP内容接收块20、内容播放/记录块30,并作为HTTP客户端运行、接收从作为HTTP服务器运行的Source下载传输的内容。
DTCP-IP认证块10由AKE块11、消息摘要生成块12、内容解码块13构成。DTCP-IP认证块10比较好地具备防篡改性。
AKE块11实现DTCP-IP中的AKE机构(Sink端)。此AKE块11也具备传递后述的消息摘要生成块请求的参数的功能。AKE块11与进行复制等通常的内容传输手续时的AKE不同,也可以规定MOVE专用的AKE手续,通过使加扰方法等有所不同,防止MOVE模式的冒充。
消息摘要生成块12根据指定的算法,生成参数的消息摘要。生成消息摘要的算法可以指定预先准备的算法。作为预先准备的算法,例如,可以举出MD5及SHA-1等与一方向性哈希函数相关的算法(SHA-1与MD5同样,相当于对MD4的改良,因为生成160位的哈希值,所以,强度超过MD系列)。
消息摘要生成块12以可以生成不得对DTCP-IP认证块10以外公开的AKE块11保持的参数的消息摘要的方式,与AKE块11紧密配置,可以向AKE块11请求参数而取得参数,可以生成该参数或从外部赋予的参数的消息摘要。
内容解码块13使用由AKE交换的密钥KX,计算内容的解码密钥Kc,通过此解码密钥Kc对从Source接收的加密内容进行解码。此处将解码后的内容向内容播放/记录块传递。规定了MOVE专用的AKE手续的情况下,也是如此。
内容播放/记录块30对于从内容解码块13传递过来的内容,在播放模式的情况下进行播放,在记录模式的情况下保存到硬盘或其他记录介质(未图示)。但是,内容的记录动作要遵循内容传输用的信息包PCP内插入的复制控制信息的规定。
DTCP-IP内容接收块20是在实施了AKE之后执行与Source的内容传输手续的处理模块。在图示的例中,DTCP-IP内容接收块20具有HTTP客户端块21,作为HTTP客户端向HTTP服务器(即,Source)请求内容,从HTTP服务器接收应答的内容。
HTTP客户端块21分为HTTP请求管理块22和HTTP响应管理块23。进而,HTTP请求管理块分为HTTP请求发送块22A和HTTP请求生成块22B。
HTTP请求生成块22B生成发送的内容传输请求(HTTP请求)。此处生成的HTTP请求(例如,HTTP GET请求)通过HTTP请求发送块22A向HTTP服务器(即,Source)发送。
HTTP响应管理块23分为HTTP响应接收块23A和HTTP响应解释块23B。从服务器返回的HTTP响应和加密后的内容在HTTP响应接收块23A中接收。此处接收的HTTP响应在HTTP响应解释块23B中被检查。此处的检查为OK的情况下,将接收的加密内容发送给DTCP-IP认证块10内的内容解码块13。另外,此检查为NG时,进行作为错误响应的处理。来自Source的H TTP响应由1个以上的PCP构成。
DTCP-IP认证块10和DTCP-IP内容接收块20在与服务器设备之间确立个别的TCP/IP连接,分别独立执行认证手续及内容传输手续。
另外,图3所示的Source具备DTCP-IP认证块40、DTCP-IP内容发送块50、内容管理块60,并作为HTTP服务器运行,对HTTP作为客户端运行的Sink进行内容的下载传输。
DTCP-IP认证块40由AKE块41、消息摘要生成块42、内容加密块43构成。DTCP-IP认证块40最好具备防篡改性。
AKE块41实现DTCP-IP中的AKE机构(Source端)。此块也具备传递消息摘要生成块42请求的参数(后述)的功能。AKE块41按照AKE认证后的设备的数量保持与认证了的Sink相关的信息,并将其用于在客户端请求了内容时判别是否是已经认证了的客户端。AKE块41也可以与进行复制等通常的内容传输手续时的AKE不同,规定MOVE专用的AKE手续,通过使加扰方法等有所不同,防止MOVE模式的冒充。
消息摘要生成块42根据指定的算法,生成参数的消息摘要。生成消息摘要的算法可以指定预先准备的算法。作为预先准备的算法,例如,可以举出MD5及SHA-1等与一方向性哈希函数相关的算法(同上)。
消息摘要生成块42以可以生成不得对DTCP-IP认证块40以外公开的AKE块41保持的参数的消息摘要的方式,与AKE块41紧密配置,可以向AKE块41请求参数并取得参数,可以生成该参数或从外部赋予的参数的消息摘要。
内容解码块43对根据DTCP-IP内容发送块50的请求从内容管理块60读出的内容数据,使用根据由AKE交换的密钥KX生成的内容密钥Kc进行加密。此处加密后的内容为了向客户端发送,传递给DTCP-IP内容发送块50。
内容管理块60使用DTCP-IP的机构,管理应该保护的内容。响应于内容加密块的读出,传递内容的数据。
DTCP-IP内容发送块50具有HTTP服务器块51,作为HTTP服务器,受理来自客户端(即,Sink)的请求(例如,HTTP GET请求),执行响应请求的处理。
HTTP服务器块51分为HTTP请求管理块52和HTTP响应管理块53。
HTTP请求管理块52进而分为HTTP请求接收块52A和HTTP请求解释块52B。HTTP请求接收块52A接收来自客户端的HTTP请求。接收到的HTTP请求被发送到HTTP请求解释块52B进行检查。在HTTP请求解释块52B中的检查为OK的情况下,将HTTP请求的信息通知给DTCP-IP认证块40。
HTTP响应管理块53进而分为HTTP响应生成块53B和HTTP响应发送块53A。
HTTP响应生成块53B在HTTP请求解释块52B中的检查为OK的情况下,生成用于返回加密后的内容的HTTP响应。HTTP响应由1个以上的PCP构成。另一方面,在HTTP请求解释块52B中的检查为NG的情况下,生成用于返回错误的HTTP响应。
HTTP响应发送块53A将生成的HTTP响应发送给发出请求的客户端。另外,在HTTP请求解释块52B中的检查为OK的情况下,接在HTTP响应头之后,发送由DTCP-IP认证块40内的内容加密块43加密后的内容。
DTCP-IP认证块40和DTCP-IP内容发送块50在与Sink之间确立个别的TCP/IP连接,分别独立执行认证手续及内容传输手续。
另外,DTCP-Sink及DTCP-Source中的DTCP-IP认证块内具有的消息摘要生成块都不是DTCP-IP本身规定的功能模块,另外,都不直接关系到本发明的要旨。
B.使用了HTTP的内容传输
接着,说明遵循DTCP-IP的内容的传输步骤。图4是用于说明在Source与Sink之间进行加密内容传输的结构的图,该加密内容传输使用了通过基于AKE的密钥交换手续、及密钥交换而共享的密钥。内容传输的形式有:将Source上的内容复制到Sink的方法;从Source向Sink移动内容并在Source中不残留内容的方法。在此项中,以通过前者的复制的内容传输方法为前提进行说明。后者的内容传输方法通过MOVE功能来实现,关于进行MOVE传输时的AKE手续的详细情况,将在后面叙述。
Source与Sink首先确立1个TCP/IP连接,进行设备之间的认证。将此认证称为DTCP认证或AKE(Authentication and KeyExchange:认证和密钥交换)。在遵循DTCP的设备中,插入了由DTLA(上述)发行的设备证明书。在DTCP认证手续中,在确认了相互都是正规的遵循DTCP的设备后,可以在Source与Sink中共享认证密钥Kauth
AKE手续成功后,Source生成作为内容密钥Kc的源的交换密钥KX,用认证密钥Kauth进行加密,发送给Sink。在Source及Sink各自中,通过对交换密钥KX适用指定的运算处理,生成用于在内容传输时对内容进行加密的内容密钥Kc。也可以根据内容传输方法,改变用于根据交换密钥KX生成内容密钥Kc的公式(例如,也可以在内容的复制传输和MOVE传输中切换公式),这一点的详细内容将在后面叙述。
然后,在遵循DTCP的设备之间完成了通过AKE的认证及密钥交换手续后,Sink请求Source上的内容。Source通过UPnP(注册商标)中规定的CDS(Content Directory Service:内容目录服务)等,可以预先将表示Source上的内容的访问目的地的内容场所预先传达给Sink。在Sink请求内容时,可以使用HTTP及RTP等协议。
在图4所示的例中,在按照HTTP的手续由作为HTTP客户端的Sink对作为HTTP服务器的Source请求内容的下载形式的内容传输的情况下,例如,使用HTTP GET方法开始内容的传输。另外,虽然没有图示,但是,在按照HTTP的手续由作为HTTP客户端的Source对作为HTTP服务器的Sink推出内容的上载形式的内容传输的情况下,例如,使用HTTP POST方法开始内容的传输。或者,在请求RTP的传输时,Source成为RTP Sender,Sink成为RTP Receiver,开始内容的传输。
用HTTP进行内容传输时,与AKE手续即用于DTCP认证的TCP/IP连接不同,用于HTTP的TCP/IP连接由HTTP客户端生成(即,Source与Sink各自分别具有用于AKE手续和用于内容传输的套接字信息(IP地址和端口号的组合))。然后,作为HTTP客户端的Sink通过与通常的HTTP完全相同的动作步骤,通过使用了GET方法的HTTP请求,请求HTTP服务器上的内容。对此,HTTP服务器将依照请求的内容作为HTTP响应而返回。
作为HTTP响应而传输的数据是HTTP服务器即Source使用在AKE认证后共享的密钥对内容进行了加密的数据。具体的,Source使用随机数生成现时Nc,根据交换密钥KX、现时Nc和表示加密模式的E-EMI,生成内容密钥Kc。然后,使用内容密钥Kc,对Sink请求的内容进行加密,将作为信息包的PCP(ProtectedContent Packet:受保护的内容信息包)放在TCP流上进行发送,该信息包由包含了由加密内容构成的有效负载、现时Nc和E-EMI的头构成。然后,IP协议将TCP流分割成指定单位的信息包的大小,作成进而附加了头部的IP信息包,到达指定的IP地址。
在Sink端,在接收到来自Source的各IP信息包时,将它们组合成TCP流,取出发送的PCP。然后,在从流中取出现时Nc和E-EMI时,可以使用它们和交换密钥KX,计算内容密钥Kc,对加密内容进行解码。然后,可以对解码化后的纯文本的内容实施播放或记录等处理。这样,在使用了HTTP协议的内容传输结束时,例如,从Sink端正确分断内容传输中使用的TCP连接。
图5是表示在DTCP-IP中在内容传输中使用的信息包PCP的数据结构的示意图。如图所示,PCP是一种信息包,其由包含现时Nc的头和由加密内容构成的有效负载构成。另外,HTTP响应由1个以上的PCP构成,RTP有效负载由1个PCP构成。
PCP头是纯文本,包含现时Nc。另外,PCP有效负载由通过用现时Nc决定的内容密钥Kc加密后的内容(但是,作为复制控制信息指定了“Copy-free”的内容不需要加密)构成。
PCP有效负载规定了数据长即Protected_Content_length的值总是16字节的倍数。Protected_Content_length的值不是16的整数倍时,根据需要,在加密前进行填充(padding),在内容中进行1~15字节的填充。图6表示了填充PCP的样子。
在此,如果在又大又长的TCP流整体中持续使用相同的加密密钥,则密钥被解读的危险增高。因此,在DTCP-IP中,Source决定每128MB更新现时Nc即内容密钥Kc(逐1增加),谋求内容的安全化。即使在定期更新现时Nc的时候,也填充PCP(即使不更新内容密钥Kc,也可能对多个PCP进行填充)。
另外,在DTCP-IP中,随着现时Nc的更新,启动内容密钥确认手续。在内容密钥确认手续中,Sink还确立与内容传输用的TCP连接不同的内容密钥确认用的TCP连接,对Source进行用于内容密钥确认的手续。Sink在需要内容密钥的确认时,正确确立此TCP连接。例如,在DTCP-IP Volume 1 Supplement E.8.6中,作为内容密钥的确认手续,规定了“Content Key Confirmation”。据此,Sink使用CONT_KEY_CONF subfunction,进行与现在的现时Nc关联的内容密钥的确认。
C.内容的MOVE传输
在DTCP-IP中,作为可以在Sink中使用在Source端作为NoMore Copies进行了编码的内容的方法,准备了MOVE功能。
网络通信中的MOVE相当于在设备间移动数据,数据移动到移动目的地的设备后,基本上在移动源的设备中不残留数据。DTCP-IP中的MOVE功能是在Sink将接收的内容作为No MoreCopies进行编码并操作及在Source端对传输后的内容进行删除或置为不能使用的条件下,从Source向Sink传输加密内容,只允许在单一的Source和单一的Sink之间的MOVE。
下面说明用于实现遵循DTCP-IP的设备之间的相互运用的MOVE序列。为了确保最低限的相互运用,推荐使用了单一的HTTP GET方法或POST方法的MOVE传输,但是,并不是禁止使用了其他序列的安装。
在DTCP-IP中的MOVE序列中,要求贯彻遵守上述的在Source端删除内容或置为不能使用这个条件。因此,需要进行“INCREMENTAL MOVE”,即,在Source端将发送后的数据依次置为不能使用的同时,在Sink端将接收数据依次置为可以使用。但是,如果由于发生传输路径中的故障或其他原因,MOVE序列中断时,会发生内容在Source与Sink之间分断或丢失。然后,作为MOVE序列中断的结果,用户本来正确取得的内容消失。
这样,在本实施方式涉及的内容传输系统中,Sink将MOVE传输中的内容顺序记录到记录介质,但是,到MOVE的结束处理成功之前将顺序记录的内容保持无法使用的状态。然后,在进行了MOVE传输的结束处理的确认即Commitment时,对Sink端的记录内容进行有效化,置为可以使用的状态,同时,在Source端删除原来的内容或置为不能使用。依据这种传输步骤,在MOVE传输中不会出现在Source和Sink中No More Copy内容重复存在的情况。并且,即使由于在传输路径中发生故障等造成MOVE传输中断,内容也不会分断,可以从Sink重新开始(resume)内容传输。
这种内容的MOVE传输等价于在Source与Sink之间总括移动内容整体。与在Source端将发送后的数据依次置为不能使用的同时在Sink端将接收数据依次置为可以使用的INCREMENTALMOVE不同,也可以称为“BLOCK MOVE”。BLOCK MOVE也不会在Source和Sink上重复存在相同的内容,所以,可以说是满足了DTCP中规定的条件的内容的MOVE处理。
另外,Sink在MOVE传输的结束处理成功之前,不能播放记录的内容,但是,也可以与在对接收内容进行了无效化的状态下进行记录的动作并行,对接收内容进行播放输出(表现)。因为BLOCK MOVE如果是满足DTCP中规定的条件的MOVE处理,那么,与之并行的表现处理等价于与MOVE传输用的TCP连接并行地,确立内容流动传输用的TCP连接,对流动数据进行播放输出。在与BLOCK MOVE并行进行表现处理的情况下,因为TCP连接只要1个就可以,所以,可以节约通信路径。另外,对于Source或Sink的设备来说,因为用单一的内容传输处理就可以完成MOVE传输和表现这两者的处理,所以,负荷减轻。
为了并行进行内容的MOVE处理和接收内容的播放处理,只要将图2所示的Sink内的内容播放/记录块30作为内容播放块31和内容记录块32这2个独立的模块来构成就可以。图7表示了这种情况下的功能块图。
在内容解码块13中,使用根据由AKE交换的交换密钥KX计算出来的内容的解码密钥Kc,对从Source接收的加密内容进行解码时,将其分别提供给内容播放块31和内容记录块32。
在内容记录块32中,将内容作为No More Copies实施规定的编码处理,首先以无效化的状态保存到硬盘或其他的记录介质(未图示)。通过内容记录块32保存的编码内容到MOVE传输整体完成为止不进行有效化,所以,不能从记录介质读出并解码使用(例如,用内容播放块播放)。另外,通过与内容解码块13同样地,将内容记录块32配置在防篡改性的DTCP-IP认证块10内,可以消除在内容解码块13与内容记录块32之间的解码内容泄漏的问题。
另一方面,在内容播放块31中,将从内容解码块13提供的内容直接转换(表现)为视频及音频信号,从显示器等的AV输出部进行影像及声音输出。这种解码内容的输出是在输出的同时数据消失,所以,不等于内容的复制,不与在Source和Sink双方不得重复存在可以播放的内容这个DTCP规格相抵触。
按照这种方式,通过与MOVE处理并行执行接收内容的播放处理,用户可以在MOVE传输中确认该内容的内容,并且可以实时地享受内容视听。
在此,在Source与Sink之间的内容传输比内容播放块中的播放的实际时间快的情况下,内容播放块31可以在本地具备AV输出用缓冲器33。在进行上述的并列处理时,只要将从内容解码块13直接提供的内容积蓄到此AV输出用缓冲器33,以FIFO形式进行播放输出,就可以进行通过内容播放块31的内容的实际时间播放。作为AV输出用缓冲器33的安装方法,除了设置内容播放块31专用的缓冲存储器之外,也可以考虑将内容记录块32带有的硬盘等的记录介质(未图示)和AV输出用缓冲器33合并在一起,对AV输出用的内容和记录用的内容进行一元化。
本发明的发明者们将在Source与Sink之间的MOVE传输大体分成下载和上载来处理。此处所说的下载表示操作Sink的用户从Source对内容进行拉(pull)发布,例如,可以Source作为HTTP服务器运行的同时,Sink作为HTTP客户端运行,使用HTTP GET方法,安装MOVE序列。另外,上载表示操作Source的用户对Sink进行内容的推(push)发布,例如,可以在Source作为HTTP客户端运行的同时,Sink作为HTTP服务器运行,使用HTTP POST方法,安装MOVE序列。为了确保最低限的相互运用,推荐使用了单一的HTTP GET方法或POST方法的MOVE传输,但是,当然不禁止安装使用其他序列。
在目前的DTCP-IP中,一般是从Sink以发生内容传输的触发的下载形式进行复制传输(例如,参考图4),下面说明下载传输和上载传输各自的情况下的BLOCK MOVE传输序列。
C-1.下载形式的BLOCK MOVE
图8是表示以下载形式在Source与Sink之间进行BLOCKMOVE传输的情况下的动作序列的图。如图所示,这种情况下的MOVE传输由以下4个阶段构成:Source及内容选择;MOVE用AKE手续;内容移动(MOVE)手续;MOVE结束处理手续。其中,MOVE用AKE手续、内容移动(MOVE)手续、MOVE结束处理手续按照DTCP上规定的步骤执行。
Source及内容选择的阶段可以例如,基于UPnP(注册商标)进行,这种情况下,Sink可以使用CDS(Content DirectoryService),取得内容信息。CDS是UPnP(注册商标)介质服务器的主要服务之一。通常,Sink使用CDS进行内容的阅览或检索、内容的元数据的编辑等。图9表示了这种情况下的在Source与Sink之间的动作序列。
首先,Sink发行CDS∷Browse request,根据来自Source的CDS∷Browse response,可以取得内容一览信息(content listInformation)。如同图所示,在此响应内,内容用item ID和parentID识别,对每个内容,记载内容的标题、内容的UPnP(注册商标)类、针对CD S∷Browse request的响应信息。然后,在响应属性信息(res protocolInfo property)的第3字段中记载每个内容的套接字信息(DTCP Socket Info),并且用其他响应属性信息(res@allowedUse)记载表示内容是否可以进行MOVE传输的Movable信息,在这些信息之后,包含了表示内容的保管场所的URL。另外,Movable信息的记载方法不限定于此,例如,也可以考虑在DTCP中定义响应属性信息并使用。作为可能的MOVE方法,也可以考虑对BLOCK MOVE和INCREMENTAL MOVE进行个别表现。
在图9所示的例中,Source在res的protocolInfo属性的第3个字段中记载作为套接字信息的字符串“DTCP1HOST=(host);DTCP1PORT=(port)”,并且,在allowe dUse属性中,记载了表示该内容通过DTCP-IP可以MOVE的字符串“MOVE:1”。因此,Sink通过从图示的响应中读出与用户选择的内容相关的res标签内的protocolInfo以及allowedUse的各属性的值,可以取得每个内容的套接字信息和内容是否可以进行MOVE传输。
另外,res@allowedUse不是DTCP规格中规定的内容,“MOVE:1”的运用方法也没有详细定义,所以,对于将来的定义内容,有可能不是正确的内容。因此,可以考虑代替res@allowedUse,在res@protocolInfo的第4字段中设置“DTCP.COM_FLAGS param”这个参数,表示内容的MOVE传输的可否。DTCP.COM_FLAGS param是32位长的字段,位定义如下。在位30中记载了1时,位31中也记载1。Sink忽略预备的位字段。
位31:可以进行基于DTCP的MOVE传输。
位30:支持满足DTCP说明书中规定的条件的BLOCK MOVE协议。
位29~0:预备
DTCP.COM_FLAGS param设置在res@protocolInfo的第4字段中,用16进制数表述32位值。另外,使用了DTCP.COM_FLAGS param的情况下的res@protocolInfo属性的描述例如下。
【式1】
<res
protocolInfo=“http-get∶*:application/x-dtcp1;DTCP1HOST=(
host);DTCP1Port=(port);CONTENTFORMAT=(mimetype):DT
CP.COM_FLAGS=C0000000”>
http://1.2.3.4/content?id=def-abc</res>
Sink在从1个以上的Source取得CDS∷Browse响应时,进行Source的选择(Select Source),从选择的Source进行应该MOVE的内容的选择(Select Content),以及进行移动目的地的选择(Select Destination)。然后,接着Sink端的内容的选择,开始选择的内容的MOVE传输处理。
在进行MOVE传输之前,首先为了进行在Source与Sink之间的相互认证及MOVE用的密钥共享,实施MOVE用AKE手续。在此,在从Sink向Source传递AKE触发信息之前,Source成为可以受理来自Sink的AKE的状态。在本实施方式中,按照与通常的DTCP-IP中的AKE手续(参照上述以及图4)相同的步骤,执行在Source与Sink之间的相互认证和用于共享作为内容解码密钥的源的源密钥的处理。但是,在执行MOVE时,生成与通常的内容传输时不同的交换密钥KXM,并且,对每1次的MOVE传输消除交换密钥。通过这种方式,可以使得比较不容易将MOVE传输伪装成复制传输,进行内容的复制动作。
图10表示了MOVE用AKE手续的动作序列。如图所示,使用挑战(CHALLENGE)响应(RESPONSE)认证手续,进行手续。Source对来自Sink的MOVE用的挑战请求(MV-CHALLENGE)进行应答,对每1次的MOVE用AKE手续生成MOVE用的交换密钥KXM,通过后续的响应,在Source与Sink之间实现密钥KXM及KXM_label的共享。但是,在EXCHANGE KEY命令中,应用与通常的AKE手续的情况下不同的加扰方法,防止将MOVE传输伪装成复制传输。
密钥KXM及KXM_label的生成方法与通常的内容传输时(参考上述以及图4)相同,所以,此处省略详细说明。另外,消除密钥KXM及KXM_label的规则也与密钥KX及KX_label的情况相同,所以,省略说明。
Source和Sink都是在每当1次的MOVE手续结束时,消除该MOVE手续用的密钥KXM及KXM_label。
图27是表示MOVE用AKE手续的其他动作序列例的图。在图示的例中,Sink使用发送MV-INITIATE命令这个MOVE协议,初始化MOVE传输,启动MOVE RTT-AKE进程。在RTT-AKE进程中,按照与通常的AKE相同的步骤,进行通过挑战响应手续的相互认证。依据RTT可以进行Sink及Source的Localization检查,但是,与本发明的要旨没有直接关连。然后,通过MV_EXCHANGE_KEY命令进行交换密钥的共享。
如上已述,在本实施方式涉及的内容传输系统中,作为内容的MOVE模式,具备INCREMENTAL MOVE和BLOCK MOVE这2种。INCREMENTAL MOVE可以通过DTCP-IP中决定的MOVE传输进行安装。与之相对,BLOCK MOVE没有包含到现在的规格中。因此,例如,在进行MOVE用AKE手续时,希望确认相互的设备是否对应于BLOCK MOVE,即,确认能力。
图16是表示包含了能力的确认序列的MOVE用AKE手续的动作序列例的图。在图示的例中,在进行MOVE用的挑战响应认证手续之前,执行在Sink与Source之间交换相互的能力的手续(CAPABILITY_EXCHANGE)。
图17是表示图16中的能力交换手续的部分的详细的图。用于此命令/响应的消息由描述各个设备具备的能力的CAPABILITY字段和针对CAPABILITY字段的电子签名构成。
消息的开头第1位用于识别Sink或Source。在设备发送作为Sink的能力的情况下记载1,在发送作为Source的能力的情况下记载0。通过这种方式,防止按照作为Source的能力的方式,发送作为Sink的能力(或进行与此相反的动作),对能力进行冒充。使用CAPABILITY字段的末尾的字段,记载设备是否对应于MOVE(或BLOCK MOVE)。
电子签名由消息开头的Sink/Sourc位和对CAPABILITY字段由各设备的密钥要求的电子签名构成。接收到CAPABILITY_EXCHANGE命令的Source可以使用Sink的公开密钥,验证签名,接收到CAPABILITY_EXCHANGE响应的Sink可以使用Source的公开密钥,验证签名。
例如,Sink请求BLOCK MOVE模式下的内容的MOVE时,首先,从Sink端发行CAPABILITY_EXCHANGE命令,与之相对,从Source返回CAPABILITY_EXCHANGE响应。在任何一方的设备不对应BLOCK MOVE的情况下,也可以将模式切换到目前的INCREMENTAL MOVE,进行内容的MOVE处理。
CAPABILITY_EXCHANGE序列作为针对MOVE传输模式冒充攻击的对策是充分的。但是,在采取了针对这种冒充攻击的其他对策的情况下,不需要通过CAPABILITY_EXCHANGE序列的安全的信息交换手续。
在MOVE传输用的AKE手续安全完成时,接着开始内容移动(MOVE传输)手续。在通过Sink端的用户操作从Source对内容进行MOVE传输时,Source作为HTTP服务器运行的同时,Sink作为HTTP客户端运行,使用HTTP协议进行下载MOVE传输即可。在内容的数据实体的传输本身中,INCREMENTAL MOVE和BLOCK MOVE都可以同样地进行,无论哪种情况都可以使用HTTP协议。即,作为HTTP客户端的Sink使用HTTP GET请求,请求内容,与之相对,作为HTTP服务器的Source使用HTTP GET响应,可以进行在内容选择阶段选择的内容的MOVE传输。GET是在从特定的URI取得信息时,作为请求发送的HTTP方法(众所周知)。
图28中例示了使用HTTP协议对内容进行下载MOVE传输的情况下的动作序列。例如,在图27所示的MOVE RTT-AKE手续顺利完成时,作为HTTP客户端运行的Sink通过发送HTTP GET请求,初始化MOVE传输进程。
在使用HTTP协议,对内容进行下载MOVE传输时,Source将E-EMI的模式设置为C1(即,MOVE模式(参考表1))。Sink在接收到C1以外的E-EMI模式时,不将接收到的内容作为MOVE对象来处理。
Sink发送在HTTP的GET请求的头中设置了“MOVE.DTCP.com:<KXM_label>”(或不是“MOVE.DTCP.com”,而是“BLKMOVE.DTCP.com”)这样的头信息的HTTP GET请求,开始进行下载MOVE传输。Source检测到此头信息后,对被请求的内容,用根据与作为密钥ID的KXM_label对应的MOVE用的密钥KXM得到的加密密钥Kc进行加密,将E-EMI设置为C1,作为GET响应,进行传输。
图14A及图14B是表示从作为HTTP服务器的Source向作为HTTP客户端的Sink进行内容的下载MOVE传输的情况下的Source及Sink各自执行的处理动作的流程图。
Sink在发现作为HTTP服务器运行的Source,选择从那里对内容进行MOVE(步骤S21)时,将CDS∷Browse request发送到该Source地址(步骤S22),等待来自Source的响应(步骤S23)。
在Source端,等待来自Sink的CDS∷Browse request或其他请求的接收(步骤S1),在接收到该请求时,对Sink返回CDS∷Browse response(步骤S2),进行等待直到接收到MOVE用的AKE请求为止(步骤S3)。
Sink在通过来自Source的CDS∷Browse response,取得了内容一览时,决定要MOVE的内容(步骤S24),并且,对Source请求MOVE用的AKE处理(步骤S25)。
然后,在Sink与Source之间,开始MOVE用的AKE手续,相互执行MOVE用的AKE处理(步骤S4、S26)。在MOVE用的AKE的认证成功时(步骤S5、S27),Source生成MOVE用的密钥和密钥ID,发送给Sink(步骤S6),Sink从Source接收MOVE用的密钥和密钥ID(步骤S28)。但是,在Source与Sink之间的MOVE用的AKE的认证失败时,Source和Sink都跳过全部后续的处理,结束整个本处理例程。
Sink在成功结束了MOVE用AKE手续时,发送带有“MOVE.DTCP.com:<KXM_label>”(或者,不是“MOVE.DTCP.com”,而是<“BLKMOVE.DTCP.com”)头信息的HTTP GET请求(步骤S29)。
Source在从Sink接收到带有MOVE用头的HTTP GET请求时(步骤S7),检查该请求中请求的内容是否正在对其他Sink进行MOVE(步骤S8)。然后,如果是MOVE传输中,则对Sink返回错误应答(步骤S15)。
在Sink端,等待来自Source的HTTP GET响应的接收(步骤S30)。在此接收等待中,如果从Source接收到无法对请求的内容进行MOVE的错误应答(步骤S31),则在此结束整个本处理例程。
另外,Source在从Sink进行MOVE请求的内容没有正在对其他Sink进行MOVE传输,可以对该Sink进行MOVE传输时,对该内容设置”MOVE传输中”标志后(步骤S9),使用MOVE用的密钥,对该内容进行加密,发送给请求源的Sink地址(步骤S10)。在设置了“MOVE传输中”标志时,该内容成为锁定状态。然后,在加密内容的传输处理结束时,等待来自Sink的MOVE结束处理的请求的接收(步骤S11)。
Sink如果从Source成功下载了加密内容(步骤S32),则对Source发送MOVE结束处理的请求(步骤S33)。然后,Source和Sink分别执行MOVE结束处理手续(步骤S12、S34),在Sink端对内容进行有效化的同时,删除Source端的原来的内容。Source及Sink间的MOVE传输结束处理手续的动作序列的详细说明见后述。
然后,Source和Sink在完成MOVE结束处理手续时(步骤S13、S35),都放弃MOVE用的密钥和密钥ID(步骤S14、S36),结束整个本处理例程。
在图14A及图14B所示的下载MOVE处理手续的期间中,对作为MOVE对象的内容进行锁定使得不能从其他Sink进行MOVE请求,防止多重MOVE的发生。通过下载进行MOVE的情况下,Source相当于服务器,但是,对于保持的各个内容是否是MOVE传输中,例如,使用下表2所示的表进行管理。在同表中,可以对确定内容的URI和表示是否是MOVE传输中的标志进行关联,使得可以确认内容的状态。另外,Source对通过下载请求内容的MOVE的其他Sink,通过在CDS∷Browse response中不示出正在MOVE传输的内容的存在,可以防止混乱(在视听途中由于MOVE完成而造成的传输中断等)。
【表2】
    内容#1URI  MOVE中标志=OFF
    内容#2URI  MOVE中标志=OFF
    内容#3URI  MOVE中标志=ON
    内容#4URI  MOVE中标志=OFF
另外,Sink在以BLOCK MOVE模式进行下载MOVE传输处理的期间,内容还没有有效化,所以,不能以实时表现以外的目的使用接收的内容。实时表现的结构已经使用图7进行了说明,所以,在此省略说明。
另外,在MOVE用AKE手续以及内容移动(MOVE)手续的期间,有中途停止MOVE传输的Cancel或Abort等中断处理启动的情况,关于这一点的详细说明见后述。
如果Sink通过HTTP协议的GET请求,从选择的Source成功下载了期望的内容,则实施MOVE结束处理手续,该MOVE结束处理手续用于确认在Sink与Source之间内容传输顺利结束,即,进行Commitment。在此结束处理中,在Sink端对此下载的内容进行有效化的同时,在Source端删除原来的内容。另外,Sink和Source分别进行内容传输中使用的交换密钥的删除。在BLOCKMOVE模式中,通过实施这种Commitment,可以实现与在Source与Sink之间总括移动内容整体等价的MOVE处理。BLOCKMOVE也不会在Source和Sink上重复存在相同的内容,所以,可以说是满足了DTCP中规定的条件的内容的MOVE处理。
图11是表示在Source及Sink之间执行MOVE结束处理手续的动作序列的图。图示的动作序列在图14B所示的流程图的步骤S12以及S34中实施。
Sink在顺利结束作为MOVE对象的内容的接收时,到从Source接收响应为止,持续发送MOVE结束处理用命令CMD1(或MV_FINALIZE命令)。
另一方面,Source在接收到MOVE结束处理用命令CMD1时,返回MOVE结束处理用响应RSP1。另外,Source将有效状态(Valid)的原来的内容转换到中间(interim)无效状态(Invalid)。
在接收到的RSP1中如果记载了Source已经结束了MOVE处理手续,那么,Sink同样地结束MOVE处理手续。随之,使从Source进行了MOVE的内容从无效状态转换到有效状态。
接着,Sink到从Source接收响应为止,持续发送下一个MOVE结束处理用命令CMD2(或MV_COMPLETE命令)。与之相对,Source使原来的内容从中间无效状态转换到完全无效状态之后,返回MOVE结束处理用响应RSP2。
图18是表示在图11所示的下载MOVE传输结束序列上Sink及Source各自实施的处理内容的具体内容的流程图。
在Sink端,首先生成随机数R(步骤S81),对此随机数R应用指定的运算处理,计算消息摘要MAC5A及MAC6A。MAC5A是传递给Source的值,MAC6A是期待从Source返回的值。MAC5A及MAC6A的计算式例如如下。此计算中使用与KXM_label对应的KXM
【式2】
MAC5A=MAC5B=[SHA-1(MK+R)]msb80
MAC6A=MAC6B=[SHA-1(MK+R)]lsb80
MK=SHA-1(KXM||KXM)
接着,Sink以非易失的方式保存作为密钥ID的KXM_label和随机数R、MAC5A、MAC6A、MOVE的内容的ID、Source的ID(步骤S82)。通过以非易失的方式保存这些数据,即使由于电源切断等内容传输结束处理中断,也可以重新开始处理,可以避免在Sink和Source双方中内容无效。
然后,Sink向Source发送包含了KXM_label和随机数R、MAC5A的MOVE结束用命令CMD1(或MV_FINALIZE命令)。Sink到从Source接收响应为止,在每次发生接收超时时持续发送CMD1(步骤S83)。
另一方面,Source在接收到MOVE用命令CMD1时,对其中包含的随机数R应用指定的运算处理(同上),计算消息摘要MAC5B及MAC6B。MAC6B是传递给Sink的值,MAC5B是期待从Sink得到的值。然后,Source对CMD1中包含的MAC5A和自己求得的MAC5B进行对照,检查命令的真实性(步骤S91)。在此检查失败时,中止(Abort)内容传输结束处理。但是,Source在由于自身的套接字信息中途变化的原因而可能存在Sink搞错CMD1的发送目的地的情况下,可以不中止处理,继续等待CMD1。
另外,Source在真实性的检查成功时,以非易失的方式保存作为密钥ID的KXM_label和MAC6B、MOVE的内容的ID(步骤S92)。通过以非易失的方式保存这些数据,即使由于电源切断等造成内容传输结束处理中断,也可以重新开始处理,可以避免在Sink和Source双方中内容无效(同上)。
然后,Source使有效状态的原来的内容转换到中间无效状态之后(步骤S93),返回表示受理了CMD1(Accepted)的MOVE结束处理用响应RSP1。
Sink在从Source接收到MOVE结束处理用响应RSP1时,检查CMD1是否没有被拒绝(Rejected)(步骤S84)。在RSP1表示了Accepted的情况下,进而检查RSP1中包含的MAC6B是否与自己保持的MAC6A一致(步骤S85)。然后,在这些检查成功时,使从Source进行了MOVE的内容从无效状态转换到有效状态(步骤S86)。
接着,Sink向Source发送包含了作为密钥ID的KXM_label的MOVE结束用命令CMD2(或MV_COMPLETE命令)。Sink到从Source接收响应为止,在每次发生接收超时时持续发送CMD2(步骤S87)。
Source在接收到MOVE结束处理用命令CMD2时,删除与其中包含的KXM_label对应的数据(步骤S94)。此处所说的数据是在步骤S92中以非易失方式保存着的KXM_label和MAC6B、MOVE的内容的ID。然后,Source返回MOVE结束处理用响应RSP2。
Sink在接收到MOVE结束处理用响应RSP2时,删除与其中包含的KXM_label对应的数据(步骤S88)。此处所说的数据是在步骤S82中以非易失方式保存着的KXM_label和随机数R、MAC5A、MAC6A、内容的ID、Source的ID。
对下载MOVE传输结束后在Sink端对内容进行有效化的方法没有特别限定。在进行了有效化时,在Sink内的内容记录块中作为No More Copies编码并记录的内容可以使用(例如,可以进行记录时应用的密码的解除)。其结果,对内容播放块31提供编码内容,转换(rendering)为视频及音频信号,可以从显示器等的AV输出部进行影像以及声音输出。另外,Sink也可以在下次作为Source对其他Sink,将No more Copies内容与上述同样以下载形式进行MOVE,或以后述的上载形式进行MOVE。
另外,对下载MOVE传输结束后在Source端删除原来的内容的方法也没有特别限定。除了从保存了内容的硬盘等记录介质删除内容数据的实体本身以外,也可以残留被编码(加密)记录的内容的实体,但是,不能再次使用解码密钥。
在此,尽管从Source向Sink成功进行了内容的实体的下载MOVE传输,但是,由于一方的设备的电源切断等,可能出现如图11所示的下载MOVE传输的结束处理序列中断。在这种情况下,由于下载MOVE传输的结束处理的中断(interrupted),存在在Source及Sink双方中无法使用移动的内容的危险。因此,在本实施方式涉及的内容传输系统中,防备这种事态,设置用于重新开始内容传输结束处理的处理手续,使Commitment顺利结束。通过此重新开始手续,内容传输手续不会浪费,并且,可以避免在Sink和Source双方中内容无效。
为了使下载MOVE传输的结束处理的重新开始成为可能,在Sink及Source各自中,在开始下载MOVE传输的结束处理时,使用NVRAM等非易失性存储器,保存重新开始处理所需的数据。在Sink端,在发行CMD1,即,MV_FINALIZE命令时,以非易失的方式保存该命令中发送的KXM_lable、随机数R、MAC5A、还有MAC6A、下载MOVE的内容的ID(相当于CDS的对象ID)、Source的ID(相当于UPnP(注册商标)的UUID)(参考图18中的步骤S82)。另一方面,在Source端,以非易失的方式保存作为密钥ID的KXM_label和MAC5B、MAC6B(参考图18中的步骤S92)。重新开始处理基本上由Sink端启动。
Sink通过存储UPnP Device Architecture(UpnP设备结构)中规定的UUID,可以发现作为CDS处理的查询目的地的Source,另外,通过存储UPnP AV CDS2中规定的Object ID,可以指定MOVE对象内容。然后,在重新开始中断的MOVE处理时,Sink与最初选择内容时同样的,通过进行UPnP(注册商标)的CDS的处理,可以得到针对作为MOVE对象的内容的套接字信息。例如,即使Source电源切断,在重新开始时其IP地址变更了,也没有问题。
Sink在得到了MOVE对象内容的套接字信息时,接着,确立与对应的Source的TCP连接。图29表示了在重新开始MOVE传输结束处理时,在Sink及Source之间确立TCP连接的处理步骤的流程图。
Sink在选择了1个以非易失方式存储的SourceID(UUID)时(步骤S131),通过UPnP的设备发现的协议(SSDP),检查是否存在带有相同的UUID的设备(步骤S132)。在此,如果不存在带有相同的UUID的设备,则跳过全部后续的处理,结束整个本处理例程。
另一方面,在存在带有相同的UUID的设备时(步骤S132的“是”),对该设备以带有Object ID指定的方式发送CDS∷Browse请求(步骤S133)。
Source在从Sink接收到CDS∷Browse请求时(步骤S141),返回包含了表示对于对应的内容没有完成内容传输结束处理的信息的CDS∷Browse响应(步骤S142)。
另外,内容传输结束处理没有完成的情况可以用以下方法表示,例如,不包含表示内容是Movable的属性信息,或不包含应该发送HTTP GET请求的URL,包含正在执行MOVE处理的属性信言息。
然后,Sink在接收到CDS∷Browse响应时(步骤S134),使用该消息中包含的套接字信息,确立CMD1、CMD2等的AKE命令用的TCP连接(步骤S135)。
Sink在以这种方式确立AKE命令用的TCP连接时,参考以非易失的方式保存着的作为密钥ID的KXM_label和随机数R、MAC5A,向Source发送CMD1(MV_FINALIZE命令)或CMD2(MV_COMPLETE命令)。与之相对,使用同样以非易失的方式保存着的KXM_label和MAC6B,返回针对CMD1的响应RSP1或针对CMD2的响应RSP2。通过这种方式,可以完结在Sink与Source之间的下载MOVE传输的结束处理。
图19表示了如图11以及图18所示的下载MOVE传输的结束处理序列由于某些原因中断(interrupted)后,Source从Sink接收到MOVE结束处理用命令CMD1时的处理步骤的流程图。
Source检查自己是否以非易失的方式保存着MOVE结束处理用命令CMD1中包含的KXM_label(步骤S101)。
在此,在没有保持KXM_label时,Source认为已经完成了对应的内容传输结束处理,或CMD1与自己无关,所以,返回表示拒绝该命令(Rejected)的MOVE结束处理用响应RSP1(步骤S104)。
另一方面,在保持了KXM_label时,表示对应的内容传输结束处理中断,所以,Source使CMD1内的内容ID表示的原来的内容转换到中间无效状态后(步骤S102),返回表示受理了CMD1(Accepted)的MOVE结束处理用响应RSP1(步骤S103)。按照这种方式,可以在作为HTTP服务器运行的Source中重新开始中断的MOVE结束处理。
另外,图20表示了如图11以及图18所示的下载MOVE传输的结束处理序列由于某些原因中断(interrupted)后,Source从Sink接收到MOVE结束处理用命令CMD2时的处理步骤的流程图。
Source检查自己是否以非易失的方式保存着MOVE结束处理用命令CMD2中包含的作为密钥ID的KXM_label(步骤S111)。
在此,在保持了KXM_label时,表示对应的内容传输结束处理中断,所以,Source删除与KXM_label关联保存的数据(即,MAC6B、MOVE的内容的ID)(步骤S112),返回表示受理了CMD2(Accepted)的MOVE结束处理用响应RSP2(步骤S113)。
另一方面,在没有保持KXM_label时,Source认为已经完成了对应的内容传输结束处理,或CMD2与自己无关,所以,跳过步骤S112,返回表示受理了CMD2(Accepted)的MOVE结束处理用响应RSP2(步骤S113)。按照这种方式,可以在作为HTTP服务器运行的Source中重新开始中断的MOVE结束处理。
另外,图21表示了如图11以及图18所示的下载MOVE传输的结束处理序列由于某些原因中断(interrupted)后,Sink重新开始MOVE结束处理的处理步骤的流程图。
Sink检测出在步骤S82中以非易失的方式保存的数据,即,作为密钥ID的KXM_label和随机数R、MAC5A、MAC6A、内容ID、SourceID存在时(步骤S121),知道内容传输结束处理中断,与Source的Commitment没有完成,这些数据没有删除,还残留着。
在这种情况下,为了重新开始内容传输结束处理,确立与对应的Source的TCP连接(步骤S122)。
然后,检查内容ID表示的内容是否是无效状态(步骤S123)。
如果内容仍然是无效状态(步骤S123的“是”),那么,表示在从Source接收MOVE结束处理用响应RSP1之前内容传输结束处理中断了,所以,跳转到图18所示的流程图的#1(步骤S124),开始与Source的Commitment。
如果内容已经成为有效状态(步骤S123的“否”),那么,表示在从Source得到Commitment后在接收MOVE结束处理用响应RSP2之前内容传输结束处理中断了,所以,跳转到如图18所示的流程图的#2(步骤S125),发送针对Source的MOVE结束处理用命令CMD2。按照这种方式,在作为HTTP客户端运行的Sink中重新开始中断的MOVE结束处理。
通过图19~图21所示的MOVE传输序列的重新开始处理,内容传输手续不会浪费,并且,可以回避在Sink与Source双方中内容变成无效。
Source返回MOVE结束处理用响应RSP2,或对应该进行无效化的用户的指示输入进行应答,使原来的内容从中间无效状态转换到完全无效状态。
C-2.上载形式的BLOCK MOVE
图12是表示以上载形式在Source与Sink之间进行MOVE传输的情况下的动作序列的图。此时的MOVE传输也与下载同样,由以下4阶段构成:Sink及内容选择;MOVE用AKE手续;内容移动(MOVE)手续;MOVE结束处理手续。其中,MOVE用AKE手续、内容移动(MOVE)手续、MOVE结束处理手续按照DTCP上规定的步骤执行。
在Sink及内容选择的阶段,用户在Source端进行要MOVE的内容的选择(Select Content)和作为内容的传输目的地的Sink的选择(Select Sink&Destination)后,对对应的Sink,通知与作为DTCP MOVE传输的内容相关的认证及密钥交换用的套接字信息。然后,接着开始选择的内容的MOVE处理。
从Source针对Sink的通知可以基于UPnP(注册商标),使用CDS来进行。图13表示了这种情况下的在Source与Sink之间的动作序列。
首先,Source在对Sink请求上载MOVE传输时,发行请求生成要传输的内容的保管场所的CDS∷CreateObject请求。Source在此CDS∷CreateObject请求内,对每个要MOVE的内容,记载内容的标题、内容的UPnP(注册商标)类、认证及密钥交换用的套接字信息以及通过DTCP-IP的MOVE手续进行内容传输的情况。另外,内容确定用的item ID、parent ID、内容的URI在请求中不定,由作为HTTP服务器的Sink决定,通过CDS∷CreateObject响应,通知给作为HTTP客户端的Source。在图13所示的例中,Source在res的protocolInfo属性的第3字段中记载作为套接字信息的字符串“DTCP1HOST=(host);DTCP1PORT=(port)”,并且,记载表示通过DTCP-IP的MOVE传输序列传输该内容的字符串“DTCPOP=MOVE”。
另外,如果在res@protocolInfo中包含DTCPOP等上载时临时使用的属性信息,Sink在自己作为HTTP服务器在对CDS∷Browse请求的应答中发送res@protocolInfo时,需要删除该属性信息,处理变得复杂。因此,也可以考虑与protocolInfo相对独立,用新的属性发送属性信息的方法。具体的,可以考虑设置res@DTCP:uploadInfo属性来表示内容的MOVE传输的可否。res@DTCP:uploadInfo属性是32位长的字段,位定义如下。在位30中记载了1时,位31中也记载1。Sink忽略预备的位字段。
位31:基于DTCP,作为MOVE进行传输。
位30:使用满足DTCP说明书中规定的条件的BLOCK MOVE协议。
位29~0:预备
res@DTCP:uploadInfo属性的32位用16进制数表述。CDS∷CreateObject请求中的res@DTCP:uploadInfo属性的描述例如下。
【式3】
<res
protocolInfo=“*:*:application/x-dtcp1;CONTENTFORMAT=(
mimetype):*”>dtcp:uploadInfo=”C0000000”/>
Sink在接收到CDS∷CreateObject请求时,可以识别作为内容的传输源的Source端的认证及密钥交换用的套接字信息,可以识别内容是否作为MOVE进行传输。然后,Sink在接收到来自Source的上载MOVE传输请求时,在本地的存储区生成内容的保管场所(即,导入位置),并且,将包含有此保管场所的信息的CDS∷CreateObject响应返回到请求源的Source。在图13所示的例中,Sink在res@protocolInfo属性内的importURI属性中记载表示作为MOVE对象的内容的导入位置的字符串“http://1.2.3.4:50000/import?id=6”。或者,在使用res@D CP:uploadInfo属性表示MOVE传输的可否的情况下,CDS∷CreateObject响应的描述例如下。
【式4】
<res
protocolInfo=“*:*:application/x-dtcp1;DTCP1HOST=(host);D
TCP1PORT=(port);CONTENTFORMAT=(mimetype):*”>
importUri=“http://1.2.3.4/import?id=6”
dtcp:uploadInfo=”C0000000”/>
按照这种方式,Source在从Sink接收不是错误的CDS∷CreateObject响应,确认内容可以MOVE到Sink地址,确保了内容的保管场所时,接着开始选择的内容的上载MOVE传输处理。
在进行MOVE传输之前,首先为了进行在Source与Sink之间的相互认证及MOVE用的密钥共享,  实施MOVE用AKE手续。MOVE用AKE手续的动作序列已经参考图10以及图16~17进行了说明,所以,在此省略说明。但是,在MV-CHALLENGE命令中,应用与通常的AKE的情况下不同的加扰方法,防止MOVE传输被伪装成复制传输(同上)。
或者,在MOVE用AKE手续中,可以使用如图27所示的动作序列。此时,Sink使用发送MV-INITIATE命令的MOVE协议,初始化下载MOVE传输,启动MOVE RTT-AKE进程。在RTT-AKE进程中,按照与通常的AKE相同的步骤,进行通过挑战响应手续的相互认证。然后,通过MV_EXCHANGE_KEY命令进行共享密钥的交换(同上)。
然后,在MOVE传输用的AKE手续顺利完成时,接着开始内容移动(MOVE)手续。通过Source端的用户操作向Sink进行内容的MOVE传输的情况下,只要在Source作为HTTP客户端运行的同时,Sink作为HTTP服务器运行,使用HTTP协议进行上载MOVE传输就可以。即,通过作为HTTP客户端的Source发送HTTP POST请求,与此相对,作为HTTP服务器的Sink返回HTTPPOST响应,将内容选择阶段选择的内容从Source向Sink进行上载MOVE传输。POST是用于对特定的URI发送信息的、作为请求进行发送的HTTP方法(众所周知)。
在使用HTTP协议进行内容的上载MOVE传输时,Source将E-EMI的模式设置为C1(即,MOVE模式(参考表1))。Sink在接收到C1以外的E-EMI模式时,不将接收到的内容作为MOVE对象来处理(同上)。
Source发送在HTTP的POST请求的头中设置了“MOVE.dtcp.com:<KXM_label>”(或不是“MOVE.dtcp.com”,而是“BLKMOVE.DTCP.com”)的头信息的HTTP POST请求,开始进行上载MOVE传输。然后,Source对请求的内容,用根据与KXM_label对应的MOVE用的密钥KXM得到的加密密钥Kc进行加密,将E-EMI设置为C1,作为后续的POST请求进行传输。
图15A及图15B表示了从作为HTTP客户端的Source向作为HTTP服务器的Sink进行内容的上载MOVE传输的情况下的Source及Sink分别执行的处理动作的流程图。
Source在发现了作为内容的上载目的地的服务器运行的Sink时(步骤S41),为了对Sink请求内容的保管场所的生成,发送CDS∷CreateObject request(步骤S42),等待其响应的接收(步骤S43)。
Sink在从Source接收到CDS∷CreateObject request时(步骤S61),返回针对其的响应(步骤S62)。
Source在从Sink接收到CDS∷CreateObject response时,接着决定进行MOVE的内容(步骤S44),进行等待直到接收MOVE用的AKE请求为止(步骤S45)。
Sink在发送了CDS∷CreateObject response后,对Source请求MOVE用的AKE处理(步骤S63)。
然后,在Sink与Source之间,开始MOVE用的AKE手续,相互执行MOVE用的AKE处理(步骤S46、S64)。在MOVE用的AKE的认证成功时(步骤S47、S65),Source生成MOVE用的密钥和密钥ID,发送给Sink(步骤S48),Sink从Source接收MOVE用的密钥和密钥ID(步骤S66)。但是,在Source与Sink之间的MOVE用的AKE的认证失败时,Source和Sink都跳过全部后续的处理,结束整个本处理例程。
接着,Source对要通过MOVE进行上载到Sink的内容,设置“MOVE传输中”标志后(步骤S49),使用MOVE用的密钥,对该内容进行加密,通过带有“MOVE.dtcp.com:<KXM_label>”头信息的HTTP POST请求,发送加密内容(步骤S50)。在设置了“MOVE传输中”标志时,该内容成为锁定状态。然后,等待来自Sink的HTTP POST响应的接收(步骤S51)。
在Sink端,在结束了MOVE用的AKE手续时,等待接收来自Source的HTTP POST请求(步骤S67)。然后,在接收该请求,接收到全部加密内容时,返回HTTP POST响应(步骤S68)。
按照这种方式,如果从Source向Sink成功上载了加密内容,则Source等待MOVE结束处理的接收(步骤S52)。另外,Sink对Source发送MOVE结束处理的请求(步骤S69)。然后,Source和Sink分别执行MOVE结束处理手续(步骤S53、S70),在Sink端对内容进行有效化的同时,删除Source端的原来的内容。Source及Sink之间的MOVE结束处理手续的动作序列已经使用图11以及图18进行了说明,所以,在此省略说明。
然后,Source和Sink在完成了MOVE结束处理手续时(步骤S54、S71),都放弃MOVE用的密钥和密钥ID(步骤S55、S72),结束整个本处理例程。
在图15A及图15B所示的上载MOVE处理手续的期间中,对作为MOVE对象的内容进行锁定以使得不能从其他Sink进行MOVE请求,防止多重MOVE的发生。在以上载形式进行内容的MOVE的情况下,Sink相当于服务器,但是,对于保持的各个内容是否是MOVE传输中,例如,可以使用表2(上述)所示的表进行管理(同上)。
另外,Sink在以BLOCK MOVE模式进行上载MOVE传输处理的期间中,内容还没有有效化,所以,不能以实时表现以外的目的使用接收的内容。实时表现的结构已经使用图7进行了说明,所以,在此省略说明。
另外,在MOVE用AKE手续以及内容移动(MOVE)手续的期间中,有通过用户操作取消MOVE传输的取消(Cancel)或中止(Abort)等中断处理启动的情况,这一点的详细说明见后述。
然后,如果Source通过HTTP协议的POST请求,对作为HTTP服务器运行的指定的Sink成功上载了期望的内容,则实施上载MOVE传输的结束处理手续,在Sink端对此上载的内容进行有效化的同时,在Source端删除原来的内容。按照与图11以及图18所示的相同的动作序列执行MOVE结束处理手续(同上)。
对上载MOVE传输结束后在Sink端对内容进行有效化的方法没有特别限定。在进行了有效化时,在Sink内的内容记录块中作为No More Copies编码并记录的内容可以使用(例如,可以进行记录时应用的密码的解除)。其结果,对内容播放块提供编码内容,转换(rendering)为视频及音频信号,可以从显示器等的AV输出部进行影像以及声音输出。或者,也可以在下次作为Source,与上述同样以下载或上载形式向其他Sink进行MOVE。
另外,对上载MOVE传输结束后在Source端删除原来的内容的方法也没有特别限定。除了从保存了内容的硬盘等记录介质删除内容数据的实体本身以外,也可以残留编码(加密)记录的内容的实体,但是,不能再次使用解码密钥。
另外,在Sink在从Source进行了内容的上载MOVE传输后,下次自己作为Source提供内容的情况下,需要删除res标签内的DTCPOP=MOVE(或,删除res@DTCP:uploadInfo属性),并且将套接字信息的主机名和端口变更为自己的内容。另外,在允许将内容带出(MOVE out)到其他Sink的情况下,在res标签内追加记载有表示可以MOVE的字符串“MOVE:1”的allowedUse属性(或,将上述DTCP.COM_FLAGS param追加到res@protocolInfo属性的第4字段)。
在图13所示的动作序列中,Source通过CDS∷CreateObject请求,通知在Sink端确立用于MOVE用AKE手续的TCP连接所需的套接字信息(DTCP socket Info)。但是,在此通知方法中,在重新开始中断的MOVE传输结束手续时,为了通知套接字信息,必须再次发行请求相同内容的上载MOVE传输的CDS∷CreateObject请求,有与只允许1次MOVE传输的DTCP规格相抵触的危险。
因此,本发明的发明者们提出了以下方法,即,除了通过图13所示的动作序列的通知方法以外,在CDS∷CreateObject的处理后,在进行MOVE用AKE手续之前,在HTTP POST请求的头中记载套接字信息(DTCP socket Info),从Source向Sink通知套接字信息。例如,使用Content-Type头,如下记载。
【式5】
Content-Type:application/x-dtcp1;DTCP1HOST=(host);DTCP1PORT=(port);CONTENTFORMAT=<mimetype>
Sink到AKE手续完成之前不能解开内容的加密,所以,考虑Source在此POST请求中还不传输内容,在AKE手续完成后传输的步骤。即,通知套接字信息的HTTP POST请求可以不带有内容,另外,与图13不同,在CDS∷CreateObject中不需要发送套接字信息。
图30表示了在使用Source利用POST请求通知套接字信息的方法的情况下,在Source与Sink之间进行上载MOVE传输的动作序列。
首先,Source使用CDS∷CreateObject请求,对Sink请求作为内容的移动目的地的对象的生成。此时,Source在res@uploadInfo属性中,请求基于MOVE传输的事务。与之相对,Sink在CDS∷CreateObject响应的res@importUri属性中,返回HTTPPOST用的URI。
接着,Source发送针对从CDS∷CreateObject响应的记载内容取得的URI的HTTP POST请求,对Sink通知认证及密钥交换用的套接字信息。套接字信息按照上述方式作为Content Type发送。但是,用于通知套接字信息的HTTP POST请求不包含内容。
Sink在取得了套接字信息时,确立认证及密钥交换用的TCP连接。然后,Sink通过发送MV-INITIATE命令,启动MOVERTT-AKE进程,对上载MOVE传输进行初始化。
在MOVE RTT-AKE进程结束时,通过发送包含有BLKMOVE.dtcp.com头信息的HTTP POST请求,Source进行加密内容的传输。
Sink在接收到全部MOVE对象内容后,通过发送MV_FINALIZE命令,启动MOVE传输结束处理。按照图11所示的动作序列实施MOVE结束处理手续。
另外,也可以如图31所示,从Source用不带有内容的POST请求的头来发送套接字信息,Sink确立认证及密钥交换用的TCP连接,结束了AKE手续后,返回POST响应。在这种动作序列的情况下,由于通过将AKE手续中共享的KXM_label,使用MOVE.dtcp.com(或,BLKMOVE.dtcp.com)头,作成“MOVE.dtcp.com:<KXM_label>”,用来自Sink的POST响应来发送,Source即使在同时进行多个MOVE传输处理的情况下,也可以可靠地把握要应用于内容加密的交换密钥KXM
另外,作为得到与图31所示的动作序列相同的效果的其他方法,通过使在进行多个MOVE处理的情况下对Sink通知的套接字信息为唯一,可以可靠地进行Sink与KXM的关联。在这种情况下,Sink在AKE手续完成前,也可以发送不带有MOVE.dtcp.com(或,BLKMOVE.com)头的POST响应。另外,也可以考虑此后的内容传输不是作为新的POST请求,而是作为AKE手续前的POST请求的手续来发送的方法。
另外,在此说明的套接字信息的通知方法不只是在上载MOVE传输中,在上载形式的COPY传输中也可以同样适用。
图32A及图32B表示通过图31所示的动作序列,从作为HTTP客户端的Source向作为HTTP服务器的Sink进行内容的上载MOVE传输的情况下的Source及Sink分别执行的处理动作的流程图。
Source在发现了作为内容的上载目的地的服务器运行的Sink时(步骤S151),为了对Sink请求内容的保管场所的生成,发送CDS∷CreateObject request(步骤S152),等待该响应的接收(步骤S153)。
Sink在从Source接收到CDS∷CreateObject request时(步骤S171),返回针对此的响应(步骤S172)。
Source在从Sink接收到CDS∷CreateObject response时,接着决定作为MOVE对象的内容(步骤S154)。然后,用带有Content-Type头的HTTP POST请求对Sink发送了套接字信息后(步骤S155),进行等待直到接收MOVE用的AKE请求为止(步骤S156)。
Sink在从Source接收到带有套接字信息的HTTP POST请求时(步骤S173),确立针对从该请求得到的套接字的TCP连接(步骤A174),对Source请求MOVE用的AKE处理(步骤S175)。
然后,在Sink与Source之间,开始MOVE用的AKE手续,相互执行MOVE用的AKE处理(步骤S157、S176)。在此,在MOVE用的AKE的认证成功时(步骤S158、S177),Source生成MOVE用的密钥和密钥ID,发送给Sink(步骤S159)。但是,在Source与Sink之间MOVE用的AKE的认证失败时,Source和Sink都跳过全部后续的处理,结束整个本处理例程。
Sink在从Source接收到MOVE用的密钥和密钥ID时(步骤S178的“是”),用带有BLKMOVE.dtcp.com头的HTTP POST响应发送密钥ID(步骤S179)。
然后,Source在从Sink接收到带有密钥ID的HTTP POST响应时(步骤S160的“是”),选择与此密钥ID对应的MOVE传输用的密钥用于以后的处理(步骤S161)。
接着,Source在对要上载MOVE传输到Sink的内容,设置“MOVE传输中”标志后(步骤S162),使用MOVE传输用的密钥,对该内容进行加密,作为带有套接字信息的HTTP POST请求的消息体进行发送(步骤S163)。在设置了“MOVE传输中”标志时,该内容成为锁定状态。然后,等待来自Sink的HTTP POST响应的接收(步骤S164)。
在Sink端,在结束了MOVE用的AKE手续时,等待接收来自Source的作为HTTP POST请求的消息体的加密内容(步骤S181)。然后,在接收该请求,接收到加密内容时,返回HTTP POST响应(步骤S182)。
按照这种方式,如果从Source向Sink成功上载了加密内容,则Source等待MOVE结束处理的接收(步骤S165)。另外,Sink对Source发送MOVE结束处理的请求(步骤S183)。然后,Source和Sink分别执行MOVE结束处理手续(步骤S166、S184),在Sink端对内容进行有效化的同时,对Source端的原来的内容进行删除或无效化。Source及Sink之间的MOVE结束处理手续的动作序列已经参考图11以及图18进行了说明,所以,在此省略说明。
然后,Source和Sink在完成了MOVE结束处理手续时(步骤S167、S185),都放弃MOVE传输用的密钥和密钥ID(步骤S168、S186),结束整个本处理例程。
在此,尽管从Source向Sink成功进行了内容的实体的上载MOVE传输,但是,由于一方的设备的电源切断等,可能出现MOVE传输的结束处理序列中断。由于MOVE传输的结束处理的中断(interrupted),存在在Source及Sink双方中无法使用移动的内容的危险。在这种MOVE结束处理手续中断时,按照图19~21所示的处理步骤重新开始,可以避免在Sink及Source双方中内容无效。
为了使上载MOVE传输的结束处理的重新开始成为可能,在Sink及Source各自中,在开始上载MOVE传输的结束处理时,使用NVRAM等非易失性存储器,保存重新开始处理所需的数据。在Sink端,以非易失的方式保存CMD1,即,MV_FINALIZE命令中使用的参数(KXM_label)和MAC6A。
另外,Source带有中断的Commitment信息的情况下,需要对对应的Sink通知套接字信息,提示处理的重新开始。为此,Source在Commitment处理的过程中,以非易失的方式保存Sink发现所需的UUID、及发现POST的目标地址URI所需的ObjectID、作为密钥ID的KXM_label和MAC5B、MAC6B。重新开始处理基本上由Sink端启动。
依据在HTTP POST请求的头中记载套接字信息(DTCPsocket Info),从Source向Sink通知套接字信息的上述方法,与使用CDS∷CreateObject,通知套接字信息的方法不同,即使在重新开始中断的MOVE处理时,Sink也可以没有问题地取得与作为MOVE对象的内容相关的套接字信息。
图33表示在重新开始MOVE传输结束处理时,在Sink及Source之间确立TCP连接的处理步骤的流程图。
Source选择1个以非易失的方式存储的UUID(步骤S191),通过UPnP的设备发现的协议,检查是否发现了与以非易失的方式存储的UUID一致的设备(Sink)(步骤S192)。然后,Source在发现了带有与以非易失的方式存储的UUID相同的UUID的Sink时,对该设备,以带有Object ID指定的方式发送CDS∷Browse请求(步骤S193)。
另一方面,Sink在从Source接收到CDS∷Browse请求时(步骤S2O1),返回CDS∷Browse响应(步骤S2O2)。
Source在从Sink接收到CDS∷Browse响应时(步骤S194的“是”),从该响应的描述内容取得作为套接字信息的发送目的地的res@importUri(步骤S195)。然后,对Sink发送将套接字信息包含在Content-Type头中的HTTP POST请求(步骤S196)。
Sink在从Source接收到带有套接字信息的HTTP POST请求时(步骤S203),参考该请求中包含的套接字信息,在与Source之间确立AKE命令的通信用的TCP连接(步骤S204)。然后,使用此TCP连接,按照图19~21所示的处理步骤,可以重新开始中断的MOVE传输结束处理。
C-3.BLOCK MOVE的CANCEL以及Abort
无论在以上述下载及上载的哪种形式进行内容的MOVE的情况下,Sink只要是在对Source发送MOVE结束处理用命令CMD1之前,就可以对MOVE处理进行取消(cancel)或中止(abort)。
Source以及Sink都是通过对对方发送MV-CANCEL子功能,可以取消(CANCEL)MOVE处理手续。
在本实施方式中,MOVE处理手续的CANCEL作为AKE手续的一部分进行安装。用于AKE手续的TCP连接通常通过来自Sink的触发而确立。在内容的流动或进行复制的通常的内容传输手续中,在通过AKE共享了密钥时,切断AKE用的TCP连接。但是,在此,在MOVE处理手续中,为了从Source端也可以发送MV-CANCEL子功能,需要保持AKE用的TCP连接。
Source在开始MOVE结束处理手续之前对MV-CANCEL子功能进行了发送或接收时,结束MOVE处理手续,并且解除作为MOVE对象的内容的锁定状态(具体的,将表2中相应的内容的状态恢复到MOVE可能),为了针对该内容的其他MOVE请求而释放。另外,与MOVE处理手续的结束一起,Source消除交换密钥KXM。此后,拒绝来自Sink的与该结束了的MOVE处理手续相关的请求。
另外,在开始MOVE结束处理手续之前进行了MV-CANCEL子功能的发送或接收时,结束MOVE处理手续,并且删除MOVE到自己的内容。与此MOVE处理手续的结束一起,Sink消除交换密钥KXM
另外,在MOVE结束处理开始前在Source与Sink之间的通信中断时,Source与Sink都可以中止(abort)MOVE处理手续。这种情况下的Source和Sink进行与发送或接收到MV-CANCEL时相同的动作。
D.MOVE模式冒充攻击的对策
在DTCP-IP中,通过在Source与Sink之间的传输路径上设置由个人计算机等构成的非法的代理服务器,可以容易地进行通信内容的篡改。尤其是,在Source与Sink之间通过能力的确认手续(参考图16~17),开始BLOCK MOVE的系统中,该确认手续的安装不是必须的情况下,尽管Source对应于BLOCK MOVE,但是,代理服务器对Sink伪装成Source不对应BLOCK MOVE,可以对Sink进行INCREM ENTAL MOVE。在如图22所示的动作序列例中,代理服务器将来自Sink的记载了对应BLOCK MOVE的情况的CAPABILITY_EXCHANGE消息直接传达给Source,但是,篡改来自Source的记载了对应BLOCK MOVE的情况的CAPABILITY_EXCHANGE消息,拒绝BLOCK MOVE的请求(Rejected),伪装成Source不对应BLOCK MOVE。在这种情况下,Source端根据来自Sink的请求,以BLOCK MOVE模式进行内容发送处理,但是,Sink切换为INCREMENTAL MOVE模式,进行内容接收处理。
在受到这种MOVE模式冒充攻击时,在Sink端,在每次从Source接收到数据时依次进行有效化,并且在内容传输处理结束时,代理服务器对Source进行内容传输处理的取消,通过这种方式,产生在Source和Sink双方中重复存在有效的内容的与DTCP-IP的规定相抵触的事态。
因此,本实施方式涉及的内容传输系统应用了几种方法以防止:冒充在Source与Sink之间确认了的能力,伪装Sink端的MOVE模式;或者,通过某些方法伪装是MOVE传输而进行内容的复制传输。
例如,即使在代理服务器篡改来自Source设备的CAPABILITY_EXCHANG E消息,拒绝BLOCK MOVE的请求(Rejected),伪装成Source不对应BLOCK MOVE的情况下,之后,在AKE手续中,Sink对Source通知设置的MOVE模式,Source通过与通过能力的确认手续决定的自己的MOVE模式进行对照,可以检查是否进行了冒充。或者,在图8中的Source及内容的选择手续或图12中的Sink及内容的选择手续中,使Sink正确理解进行通过MOVE的内容传输,不错误进行COPY传输。
在图23所示的动作序列例中,Sink使用AKE认证手续内进行的挑战响应,在对Source发送的响应中包含与自己的动作模式相关的信息。此时,希望在用签名保护的信息中包含MOVE模式的信息。接收到此响应的Source根据与自己设置的BLOCK MOVE模式不同,可以注意到已进行了MOVE模式的冒充,在Source与Sink之间的传输路径暴露在危险之中。然后,Source不向Sink发送交换密钥KX,不在这种危险的传输路径中开始内容传输,而结束MOVE处理。
另外,图24表示了图23所示的动作序列的变形例。在图示的序列例中,Sink在AKE认证手续内向Source发送的响应中,在用签名保护的信息中包含MOVE模式的信息。接收到此响应的Source在根据与自己设置的BLOCK MOVE模式不同,注意到已进行了MOVE模式的冒充时,从BLOCK MOVE模式切换到INCREMENTAL MOVE模式,向Sink发送交换密钥KX。然后,Source和Sink分别对交换密钥KX实施指定的运算,生成内容加密密钥Kc,开始作为MOVE对象的内容的加密传输。
作为防止MOVE模式的冒充的其他方法,有对每个MOVE模式切换加扰交换密钥KX的方法的方法。图25表示了这种情况下的动作序列例。在Source端,在进行BLOCK MOVE时,用哈希函数处理用交换密钥KX进行加扰时使用的一次性密钥后进行使用。这样,INCREMENTAL MOVE模式下的Sink在交换密钥KX用的解扰方法中就无法共用BLOCK MOVE用的交换密钥KXM。即,Sink在BLOCK MOVE模式以外,禁止交换密钥KX用的解扰,无法生成正确的内容加密密钥Kc,所以,无法对MOVE的内容进行解码。
另外,作为防止MOVE模式的冒充的其他方法,还有对每个MOVE模式切换根据交换密钥KX生成内容加密密钥Kc的计算式的方法。图26表示这种情况下的动作序列例。在Source端,在进行BLOCK MOVE时,将根据交换密钥KXM生成内容加密密钥Kc的计算式中包含的常数变更为特别的值。这样,在INCREMENTALMOVE模式下的Sink端,即使按照通常的计算式根据交换密钥KX进行计算,也无法生成正确的内容加密密钥Kc(换言之,禁止了根据交换密钥KXM计算内容加密密钥Kc),所以,无法对MOVE的内容进行解码。
因此,通过采用上述任何一项对策,即使在非法的代理服务器存在于传输路径中的情况下,也可以回避在Source和Sink双方中存在有效内容的与DTCP-IP的规定相抵触的事态。
在图16中,作为MOVE传输模式冒充攻击的对策,就CAPABILITY_EXCHANGE序列进行了说明,但是,通过如图23~图26所示的对策,可以充分防止MOVE传输模式冒充攻击,在这些情况下,不需要通过CAPABILITY_EXCHANGE序列的安全信息交换手续。
以上参考特定的实施方式详细说明了本发明。但是,显然,在不脱离本发明的要旨的范围,本领域的技术人员可以进行该实施方式的修改或代用。
作为本发明的应用例,可以举出使用在Source与Sink之间进行的HTTP协议的内容传输,但是,本发明的要旨不限定于此。即使是按照指定的复制控制信息对由于著作权或其他目的而需要保护的信息内容进行加密传输的其他所有内容传输系统、或不进行复制控制或内容的加密的系统,也可以在不在移动源中残留数据地在设备间移动数据时,同样应用本发明。
总之,以例示的方式说明了本发明,不应该限定地解释本说明书的记载内容。为了判断本发明的要旨,应该参考权利要求书。

Claims (70)

1.一种内容传输系统,其在发送内容的Source和接收内容的Sink之间传输内容,其特征在于,具备:
内容指定单元,其指定在Source与Sink之间作为传输对象的内容;
认证单元,其在Source与Sink之间进行相互认证及密钥交换;
内容传输单元,其使用所述认证单元交换的密钥,从Source向Sink加密传输所述内容指定单元指定的内容;和
内容传输结束处理单元,其响应于所述内容传输单元进行的内容传输处理的结束,对Sink端的内容进行有效化,并且对Source端的原来的内容进行无效化,
从Source向Sink移动内容。
2.根据权利要求1所述的内容传输系统,其特征在于,
所述认证单元在相互认证及密钥交换之外,还确认Source与Sink是否都对应内容传输结束处理单元进行的处理的能力。
3.根据权利要求1所述的内容传输系统,其特征在于,
所述内容指定单元使用UPnP中规定的CDS(ContentDirectory Service)来进行所述指定,
所述认证单元、所述内容传输单元、及内容传输结束处理单元在DTCP-IP(Digital Transmission Content Protection-Internet Protocol)上进行各处理。
4.根据权利要求3所述的内容传输系统,其特征在于,
用户操作的Sink以从作为提供内容的服务器运行的Source下载内容的形式进行内容的移动。
5.根据权利要求4所述的内容传输系统,其特征在于,
在Sink中,所述内容指定单元根据针对CDS::Browserequest的来自Source的CDS::Browse response中包含的信息,取得要移动的内容的认证及密钥交换用的套接字信息,并且,确认该内容是否可以从Source移动。
6.根据权利要求4所述的内容传输系统,其特征在于,
在Sink中,所述内容传输单元在头内包含表示内容的移动的头信息,使用HTTP(Hyper Text Transter Protocol)GET方法,从Source取得加密内容。
7.根据权利要求1所述的内容传输系统,其特征在于,
用户操作的Source以对作为提供内容的服务器运行的Sink上载内容的形式进行内容的移动。
8.根据权利要求7所述的内容传输系统,其特征在于,
在Source中,所述内容指定单元使用CDS::CreateObjectrequest,请求生成该内容的移动场所,并且,通过针对该请求的来自Sink的应答来接收内容的移动场所的URI(UniformResource Identifier),
所述内容传输单元使用HTTP POST方法,从Source向该接收到的内容的移动场所的URI传输加密内容。
9.根据权利要求8所述的内容传输系统,其特征在于,
在Source中,所述内容指定单元使用CDS::CreateObjectrequest,对Sink通知认证及密钥交换用的套接字信息,
所述认证单元根据该套接字信息,从Sink端确立认证及密钥交换用的TCP连接。
10.根据权利要求8所述的内容传输系统,其特征在于,
在Source中,所述内容指定单元对通过CDS::CreateObjectrequest的应答接收到的内容移动目的地的URI,使用(不包含内容的)HTTP POST方法的头信息,对Sink通知认证及密钥交换用的套接字信息,
所述认证单元根据该套接字信息,从Sink端确立认证及密钥交换用的TCP连接。
11.根据权利要求7所述的内容传输系统,其特征在于,
在Source中,所述内容传输单元在头内包含表示内容的移动的头信息,使用HTTP POST方法,向Sink发送加密内容。
12.根据权利要求2所述的内容传输系统,其特征在于,
所述认证单元对每个移动的内容,通过AKE手续进行内容移动专用的密钥的交换。
13.根据权利要求12所述的内容传输系统,其特征在于,
所述认证单元对所述内容传输结束处理单元进行的内容传输结束处理的结束进行应答,消除Source及Sink中的内容移动专用的交换密钥。
14.根据权利要求1所述的内容传输系统,其特征在于,
Source在正在向Sink移动内容时,拒绝来自其他Sink的该内容的移动请求。
15.根据权利要求1所述的内容传输系统,其特征在于,
Sink具备播放正在从Source移动且还没有被有效化的内容的单元。
16.根据权利要求2所述的内容传输系统,其特征在于,
所述认证单元在到内容传输结束处理单元进行的内容传输结束处理结束为止的期间,保持认证及密钥交换用的TCP连接,
该内容传输系统还具备内容传输处理取消单元,该内容传输处理取消单元在到所述内容传输单元进行的内容传输处理结束为止的期间,根据来自Sink或Source至少一方的请求,使用认证及密钥交换用的TCP连接,取消内容传输处理。
17.根据权利要求16所述的内容传输系统,其特征在于,
所述内容传输处理取消单元在取消内容传输处理时,对传输到Sink的内容进行无效化。
18.根据权利要求1所述的内容传输系统,其特征在于,还具备:
内容传输处理中止单元,其在到所述内容传输单元进行的内容传输处理结束为止的期间,在Sink与Source之间的通信中断时,根据来自Sink或Source至少一方的请求,中止内容传输处理。
19.根据权利要求1所述的内容传输系统,其特征在于,
所述内容传输结束处理单元对从Sink向Source发送了表示内容接收结束的第1命令的情况进行应答,将Source端的原来的内容置为中间无效状态,
所述内容传输结束处理单元对从Source向Sink返回了针对第1命令的第1响应的情况进行应答,对传输到Sink端的内容进行有效化,并且,消除在Sink端保持的内容移动专用的密钥及用第1命令发送的信息,
所述内容传输结束处理单元对从Sink向Source发送了表示内容有效化的第2命令的情况进行应答,将Source端的原来的内容置为无效状态,并且,消除在Source端保持的内容移动专用的密钥及用第1响应发送的信息。
20.根据权利要求19所述的内容传输系统,其特征在于,还具备:
内容传输结束处理重新开始单元,其在尽管所述内容传输单元进行的从Source向Sink的内容传输成功结束、但是所述内容传输结束处理单元进行的处理中断了的情况下,重新开始内容传输结束处理。
21.根据权利要求20所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元在Source从Sink接收到表示内容接收结束的第1命令时,在Source还保持着内容移动专用的交换密钥及用第1响应发送的信息的情况下,将Source端的原来的内容置为中间无效状态,从Source向Sink返回针对第1命令的第1响应。
22.根据权利要求20所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元在Source从Sink接收到表示内容接收结束的第2命令时,在Source还保持着内容移动专用的交换密钥及用第1响应发送的信息的情况下,将Source端的原来的内容置为无效状态,消除在Source端保持的内容移动专用的密钥及用第1响应发送的信息,并且,从Source向Sink返回针对第2命令的第2响应。
23.根据权利要求20所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元在Sink还保持着内容移动专用的交换密钥及用第1命令发送的信息的情况下,确立与作为内容移动源的Source之间的连接,如果相应的内容在Sink端是无效状态,则对Source发送第1命令,如果相应的内容在Sink端已经进行了有效化,则发送第2命令。
24.根据权利要求20所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元具备确立用于进行重新开始处理的Sink与Source之间的连接的单元。
25.根据权利要求24所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以下载形式进行的内容传输的结束处理时,在Sink中,根据针对CDS::Browserequest的来自Source的CDS::Browse response中包含的信息,取得认证及密钥交换用的套接字信息,确立与Source的连接。
26.根据权利要求24所述的内容传输系统,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以上载形式进行的内容传输的结束处理时,在Source中,使用(不包含内容的)HTTP POST方法,对Sink通知认证及密钥交换用的套接字信息,Sink根据该套接字信息,确立与Source的连接。
27.根据权利要求1所述的内容传输系统,其特征在于,还具备:
冒充防止单元,其防止冒充在Source与Sink之间被所述认证单元确认过的MOVE传输。
28.根据权利要求27所述的内容传输系统,其特征在于,
所述冒充防止单元对每个内容传输方法改变根据在所述认证单元中交换的密钥生成内容加密密钥的方法。
29.根据权利要求27所述的内容传输系统,其特征在于,
所述冒充防止单元对每个内容传输方法改变对在所述认证单元中交换的密钥进行加扰的方法。
30.根据权利要求27所述的内容传输系统,其特征在于,
所述冒充防止单元在用于相互认证及密钥交换的挑战响应手续中,在从Sink发给Source的通信消息中包含与内容传输方法相关的信息。
31.一种内容传输装置,其作为按照DTCP发送内容的Source来运行,其特征在于,具备:
内容指定单元,其指定在与Sink之间作为传输对象的内容;
认证单元,其通过AKE手续在与Sink之间进行相互认证及密钥交换;
内容传输单元,其使用所述认证单元交换的密钥,将所述内容指定单元指定的内容向Sink进行加密传输;和
内容传输结束处理单元,其响应于所述内容传输单元进行的内容传输处理的结束,对原来的内容进行无效化,
该内容传输装置向Sink移动内容。
32.根据权利要求31所述的内容传输装置,其特征在于,
所述认证单元在相互认证及密钥交换之外,还确认Sink是否对应内容传输结束处理单元的能力。
33.根据权利要求31所述的内容传输装置,其特征在于,
在作为提供内容的服务器运行,根据来自Sink端的用户操作向Sink下载内容时,
所述内容指定单元对来自Sink的CDS::Browse request进行应答,返回记载了各内容的认证及密钥交换用的套接字信息及该内容是否可以从Source移动的CDS::Browse response,
所述内容传输单元根据来自Sink的、在头内包含了表示内容的移动的头信息的HTTP GET方法,传输加密内容。
34.根据权利要求31所述的内容传输装置,其特征在于,
在对作为提供内容的服务器运行的Sink,根据用户的操作上载内容时,
所述内容指定单元对Sink,使用CDS::CreateObjectrequest,请求生成该内容的移动场所,并且,通过针对该请求的来自Sink的应答,接收内容的移动场所的URI,
所述内容传输单元在头内包含表示内容的移动的头信息,对该接收到的内容的移动场所的URI,使用HTTP POST方法,向Sink发送加密内容。
35.根据权利要求34所述的内容传输装置,其特征在于,
所述内容指定单元对Sink,使用CDS::CreateObjectrequest,通知认证及密钥交换用的套接字信息,
所述认证单元根据该套接字信息,从Sink端确立认证及密钥交换用的TCP连接。
36.根据权利要求34所述的内容传输装置,其特征在于,
所述内容指定单元对Sink,对CDS::CreateObject request的应答中接收到的内容移动目的地的URI,使用(不包含内容的)HTTP POST方法的头信息,通知认证及密钥交换用的套接字信息,
所述认证单元根据该套接字信息,从Sink端使用认证及密钥交换用的TCP连接,使用HTTP POST方法,确立加密内容。
37.根据权利要求31所述的内容传输装置,其特征在于,
所述认证单元对每个向Sink移动的内容,通过AKE手续进行内容移动专用的密钥的交换。
38.根据权利要求31所述的内容传输装置,其特征在于,
所述认证单元对所述内容传输单元进行的内容传输的结束进行应答,消除内容移动专用的密钥。
39.根据权利要求31所述的内容传输装置,其特征在于,
所述内容传输单元在正在对Sink移动内容时,拒绝来自其他Sink的该内容的移动请求。
40.根据权利要求31所述的内容传输装置,其特征在于,
所述认证单元在到内容传输单元进行的内容传输处理结束为止的期间,保持认证及密钥交换用的TCP连接,
该内容传输装置还具备:
内容传输处理取消单元,其在到所述内容传输单元进行的内容传输处理结束为止的期间,使用认证及密钥交换用的TCP连接,取消内容传输处理。
41.根据权利要求31所述的内容传输装置,其特征在于,还具备:
内容传输处理中止单元,其在所述内容传输单元进行的内容传输处理结束为止的期间,在与Sink之间的通信中断时,中止内容传输处理。
42.根据权利要求31所述的内容传输装置,其特征在于,
所述内容传输结束处理单元
对从Sink接收到表示内容接收结束的第1命令的情况进行应答,将原来的内容置为中间无效状态,并且,返回针对第1命令的第1响应,
对从Sink接收到表示内容有效化的第2命令的情况进行应答,将Source端的原来的内容置为无效状态。
43.根据权利要求42所述的内容传输装置,其特征在于,还具备:
内容传输结束处理重新开始单元,其在尽管所述内容传输单元进行的向Sink的内容传输成功结束、但是所述内容传输结束处理单元进行的处理中断了的情况下,重新开始内容传输结束处理。
44.根据权利要求43所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在从Sink接收到表示内容接收结束的第1命令时,在所述认证单元还保持着内容移动专用的交换密钥及用第1响应发送的信息的情况下,将原来的内容置为中间无效状态,并且,对Sink返回针对第1命令的第1响应。
45.根据权利要求43所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在从Sink接收到表示内容接收结束的第2命令时,在所述认证单元还保持着内容移动专用的交换密钥及用第1响应发送的信息的情况下,将原来的内容置为无效状态,消除所述认证单元保持的内容移动专用的密钥,并且,对Sink返回针对第2命令的第2响应。
46.根据权利要求43所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元具备确立用于进行重新开始处理的与Sink之间的连接的单元。
47.根据权利要求46所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以下载形式进行的内容传输的结束处理时,对来自Sink的CDS::Browserequest,返回包含了认证及密钥交换用的套接字信息的CDS::Browse response,确立与Sink的连接。
48.根据权利要求46所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以上载形式进行的内容传输的结束处理时,使用HTTP POST方法,对Sink通知认证及密钥交换用的套接字信息,确立与Sink的连接。
49.根据权利要求31所述的内容传输装置,其特征在于,还具备:
冒充防止单元,其防止冒充在与Sink之间被所述认证单元确认过的MOVE传输。
50.根据权利要求49所述的内容传输装置,其特征在于,
所述冒充防止单元对每个与能力对应的内容传输方法改变根据在所述认证单元中交换的密钥生成内容加密密钥的方法。
51.根据权利要求49所述的内容传输装置,其特征在于,
所述冒充防止单元对每个内容传输方法改变对在所述认证单元中交换的密钥进行加扰的方法。
52.一种内容传输装置,其作为根据DTCP接收内容的Sink来运行,其特征在于,具备:
内容指定单元,其指定在与Source之间作为传输对象的内容;
认证单元,其通过AKE手续在与Source之间进行相互认证及密钥交换;
内容传输单元,其使用所述认证单元交换的密钥,将所述内容指定单元指定的内容从Source进行加密传输;和
内容传输结束处理单元,其响应于所述内容传输单元进行的内容传输处理的结束,对接收到的内容进行有效化,
从Source移动内容。
53.根据权利要求52所述的内容传输装置,其特征在于,
所述认证单元在相互认证及密钥交换之外,还确认Sink是否对应内容传输结束处理单元的能力。
54.根据权利要求52所述的内容传输装置,其特征在于,
在从作为提供内容的服务器运行的Source,根据用户操作下载内容时,
所述内容指定单元发送CDS::Browse request,根据来自Source的CDS::Browse response中包含的信息,取得要移动的内容的认证及密钥交换用的套接字信息,并且,确认该内容是否可以从Source移动,
所述内容传输单元在头内包含表示内容的移动的头信息,使用HTTP GET方法,从Source取得加密内容。
55.根据权利要求52所述的内容传输装置,其特征在于,
在作为提供内容的服务器运行,根据来自Source端的用户的操作上载内容时,
所述内容指定单元根据从Source接收到的CDS::CreateObject request,生成该内容的移动场所,
所述内容传输单元通过来自Source的、在头内包含了表示内容的移动的头信息的HTTP POST方法,接收加密内容。
56.根据权利要求52所述的内容传输装置,其特征在于,
所述认证单元对所述内容传输单元进行的内容的传输的结束进行应答,消除内容移动专用的密钥的交换。
57.根据权利要求52所述的内容传输装置,其特征在于,
还具备播放正在从Source移动的还没有被有效化的内容的单元。
58.根据权利要求52所述的内容传输装置,其特征在于,还具备:
内容传输处理取消单元,其在到所述内容传输单元进行的内容传输处理结束为止的期间,使用认证及密钥交换用的TCP连接,取消内容传输处理。
59.根据权利要求58所述的内容传输装置,其特征在于,
所述内容传输处理取消单元在取消内容传输处理时,对从Source传输的内容进行无效化。
60.根据权利要求52所述的内容传输装置,其特征在于,还具备:
内容传输处理中止单元,其在到所述内容传输单元进行的内容传输处理结束为止的期间,在与Source之间的通信中断时,中止内容传输处理。
61.根据权利要求52所述的内容传输装置,其特征在于,
所述内容传输结束处理单元对Source发送表示内容接收结束的第1命令,对从Source向Sink返回了针对第1命令的第1响应的情况进行应答,对传输的内容进行有效化,并且,消除所述认证单元保持的内容移动专用的密钥及用第1命令发送的信息。
62.根据权利要求61所述的内容传输装置,其特征在于,还具备:
内容传输结束处理重新开始单元,其在尽管所述内容传输单元进行的与Source的内容传输成功结束、但是所述内容传输结束处理单元进行的处理中断了的情况下,重新开始内容传输结束处理。
63.根据权利要求62所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在所述认证单元还保持着内容移动专用的交换密钥及用第1命令发送的信息的情况下,确立与Source之间的连接,如果相应的内容是无效状态,则对Source发送第1命令,如果相应的内容在Sink端已经进行了有效化,则发送第2命令。
64.根据权利要求62所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元具备确立用于进行重新开始处理的与Source之间的连接的单元。
65.根据权利要求64所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以下载形式进行的内容传输的结束处理时,根据针对CDS::Browse request的来自Source的CDS::Browse response中包含的信息,取得认证及密钥交换用的套接字信息,确立与Source的连接。
66.根据权利要求64所述的内容传输装置,其特征在于,
所述内容传输结束处理重新开始单元在重新开始以上载形式进行的内容传输的结束处理时,根据使用来自Source的(不包含内容的)HTTP POST方法通知的认证及密钥交换用的套接字信息,确立与Source的连接。
67.根据权利要求52所述的内容传输装置,其特征在于,还具备:
冒充防止单元,其防止冒充在与Source之间被所述认证单元确认过的MOVE传输。
68.根据权利要求67所述的内容传输装置,其特征在于,
所述冒充防止单元在用于相互认证及密钥交换的挑战响应手续中,在发给Source的通信消息中包含与内容传输方法相关的信息。
69.一种内容传输方法,其作为DTCP Source发送内容,其特征在于,具备:
内容指定步骤,其指定在与Sink之间作为传输对象的内容;
认证步骤,其通过AKE手续在与Sink之间进行相互认证及密钥交换;
内容传输步骤,其使用在所述认证步骤中交换的密钥,将在所述内容指定步骤中指定的内容向Sink进行加密传输;和
内容传输结束处理步骤,其响应于在所述内容传输步骤中进行的内容传输处理的结束,对原来的内容进行无效化,
向Sink移动内容。
70.一种内容传输方法,其作为DTCP Sink接收内容,其特征在于,具备:
内容指定步骤,其指定在与Source之间作为传输对象的内容;
认证步骤,其通过AKE手续在与Source之间进行相互认证及密钥交换;
内容传输步骤,其使用在所述认证步骤中交换的密钥,将在所述内容指定步骤中指定的内容从Source进行加密传输;和
内容传输结束处理步骤,其响应于在所述内容传输步骤中进行的内容传输处理的结束,对接收到的内容进行有效化,
从Source移动内容。
CN200710000216A 2006-01-11 2007-01-11 内容传输系统、装置及方法 Expired - Fee Related CN100581239C (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2006004129 2006-01-11
JP2006004129 2006-01-11
JP2006060268 2006-03-06
JP2006271240 2006-10-02

Publications (2)

Publication Number Publication Date
CN101001354A true CN101001354A (zh) 2007-07-18
CN100581239C CN100581239C (zh) 2010-01-13

Family

ID=38693141

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200710000216A Expired - Fee Related CN100581239C (zh) 2006-01-11 2007-01-11 内容传输系统、装置及方法

Country Status (1)

Country Link
CN (1) CN100581239C (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102177702A (zh) * 2008-08-14 2011-09-07 三星电子株式会社 通过使用通用即插即用播放场景的方法和装置
CN103189872A (zh) * 2010-09-16 2013-07-03 凡瑞斯公司 联网环境中的安全和有效内容筛选
US9189955B2 (en) 2000-02-16 2015-11-17 Verance Corporation Remote control signaling using audio watermarks
US9208334B2 (en) 2013-10-25 2015-12-08 Verance Corporation Content management using multiple abstraction layers
US9251549B2 (en) 2013-07-23 2016-02-02 Verance Corporation Watermark extractor enhancements based on payload ranking
US9262794B2 (en) 2013-03-14 2016-02-16 Verance Corporation Transactional video marking system
US9323902B2 (en) 2011-12-13 2016-04-26 Verance Corporation Conditional access using embedded watermarks
CN105611325A (zh) * 2015-12-23 2016-05-25 成都云晖航空科技股份有限公司 一种基于wifi技术的空中娱乐系统
US9596521B2 (en) 2014-03-13 2017-03-14 Verance Corporation Interactive content acquisition using embedded codes

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08263438A (ja) * 1994-11-23 1996-10-11 Xerox Corp ディジタルワークの配給及び使用制御システム並びにディジタルワークへのアクセス制御方法
US7134145B1 (en) * 1999-04-30 2006-11-07 Koninklijke Philips Electronics N.V. Registering copy protected material in a check-out, check-in system
US6372974B1 (en) * 2001-01-16 2002-04-16 Intel Corporation Method and apparatus for sharing music content between devices

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9189955B2 (en) 2000-02-16 2015-11-17 Verance Corporation Remote control signaling using audio watermarks
CN102177702A (zh) * 2008-08-14 2011-09-07 三星电子株式会社 通过使用通用即插即用播放场景的方法和装置
US10211997B2 (en) 2008-08-14 2019-02-19 Samsung Electronics Co., Ltd Method and apparatus for playing back scene using UPnP
CN102177702B (zh) * 2008-08-14 2015-03-04 三星电子株式会社 通过使用通用即插即用播放场景的方法和装置
CN104539638A (zh) * 2008-08-14 2015-04-22 三星电子株式会社 通过使用通用即插即用播放场景的方法和装置
CN104539638B (zh) * 2008-08-14 2018-04-24 三星电子株式会社 通过使用通用即插即用播放场景的方法和装置
CN103189872B (zh) * 2010-09-16 2016-05-18 凡瑞斯公司 联网环境中的安全和有效内容筛选的方法和装置
CN103189872A (zh) * 2010-09-16 2013-07-03 凡瑞斯公司 联网环境中的安全和有效内容筛选
US9323902B2 (en) 2011-12-13 2016-04-26 Verance Corporation Conditional access using embedded watermarks
US9262794B2 (en) 2013-03-14 2016-02-16 Verance Corporation Transactional video marking system
US9251549B2 (en) 2013-07-23 2016-02-02 Verance Corporation Watermark extractor enhancements based on payload ranking
US9208334B2 (en) 2013-10-25 2015-12-08 Verance Corporation Content management using multiple abstraction layers
US9596521B2 (en) 2014-03-13 2017-03-14 Verance Corporation Interactive content acquisition using embedded codes
CN105611325A (zh) * 2015-12-23 2016-05-25 成都云晖航空科技股份有限公司 一种基于wifi技术的空中娱乐系统

Also Published As

Publication number Publication date
CN100581239C (zh) 2010-01-13

Similar Documents

Publication Publication Date Title
KR101411774B1 (ko) 컨텐츠 전송 시스템, 컨텐츠 전송 장치 및 컨텐츠 전송 방법, 및 프로그램이 기록된 기록매체
CN100581239C (zh) 内容传输系统、装置及方法
CA2590172C (en) Method and system for securing content in media systems
US8819409B2 (en) Distribution system and method for distributing digital information
US6950941B1 (en) Copy protection system for portable storage media
US9055353B2 (en) Content transmission device, content transmission method, and computer program used therewith
RU2377642C2 (ru) Устройство и способ для перемещения и копирования объектов прав между устройством и портативным запоминающим устройством
US8601590B2 (en) Content distribution system
US20110238983A1 (en) Network integrity maintenance
CN101009808A (zh) 内容传输系统、装置和方法
US20080016307A1 (en) Storage device and storing method
TW200903296A (en) Data security
CN100391255C (zh) 数字家庭网络密钥有效性验证方法
JP4883199B2 (ja) コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
US20090144549A1 (en) Copyright protection processing apparatus and copyright protection processing method
JP4671653B2 (ja) 暗号化装置、復号化装置、それらの方法、プログラムおよび記録媒体
JP4956845B2 (ja) 情報処理装置、秘密情報保護システムおよび秘密情報保護方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20100113