專利名稱：用于安全發(fā)行內(nèi)容的方法和裝置的制作方法
技術領域：
本發(fā)明通常涉及安全通信領域，更特別是涉及通過一種網(wǎng)絡或其它通信媒體安全的電子發(fā)行音樂和其它類型內(nèi)容的技術。
當通過諸如互聯(lián)網(wǎng)的全球通信網(wǎng)傳遞音樂或其它類型的內(nèi)容時，安全性正逐漸變成人們擔心的問題。更特別是，這種基于網(wǎng)絡的內(nèi)容傳遞系統(tǒng)的成功實現(xiàn)在很大程度上依賴確保內(nèi)容提供商收到適當?shù)陌娑悾⑶覀鬟f的內(nèi)容不能被盜版或受到非法的掠奪性使用。
關于音樂內(nèi)容的傳遞，近來領先的唱片工業(yè)和技術公司形成一個稱為安全數(shù)字音樂倡導者聯(lián)盟(SDMI)合作開發(fā)努力。SDMI的目的在于開發(fā)一種具有數(shù)字音樂安全性的開放互操作體系。這將符合使用者方便接入高音質(zhì)數(shù)字音樂的需要，同時還提供版權保護，以保護對內(nèi)容發(fā)行和傳遞的投資。SDMI已經(jīng)提出便攜式音樂裝置的標準規(guī)范，SDMI便攜式裝置規(guī)范，部分1，版本1.0，1999年。目前SDMI的長期工作努力是完成用于傳遞各種形式的數(shù)字音樂的總體結(jié)構。
雖然SDMI和他人正在作出的努力，但是用于安全發(fā)行音樂和其它內(nèi)容的現(xiàn)有技術正遭受多個顯著的缺點。例如，許多這種技術要求內(nèi)容提供商在傳送內(nèi)容時能被內(nèi)容使用者明確識別，即這些技術通常不允許內(nèi)容提供商在沒有發(fā)生爭議時保持完全匿名。遺憾的是，這類安排在某些特定應用中，特別是對于個人或小本生意的內(nèi)容提供商來說不理想或費用較高。在另一個實例中，傳統(tǒng)技術通常不提供所有的內(nèi)容提供商都能安全記錄他們工作的集中機理。因此在現(xiàn)有技術的條件下不能平等地對待內(nèi)容提供商，即可以支付得起實現(xiàn)復雜安全性措施費用的大提供商具有相比較小提供商的優(yōu)勢。
顯然，存在一種發(fā)行符合音樂和其它類型內(nèi)容的改進技術的需要。
本發(fā)明提供用于安全發(fā)行音樂和其它類型內(nèi)容的方法和裝置。本發(fā)明允許內(nèi)容以匿名發(fā)行的方式注冊到集中信托注冊主管機構(TRA)，因此不需要公開內(nèi)容提供商的身份直到出現(xiàn)爭議。
本發(fā)明第一實施例中的內(nèi)容發(fā)行根據(jù)一種內(nèi)容發(fā)行協(xié)議實現(xiàn)，該協(xié)議提供無線權利管理，即內(nèi)容的安全注冊，因此內(nèi)容的使用權不局限于內(nèi)容本身。在此實施例中，發(fā)行的內(nèi)容不通過加密保護，即不提供內(nèi)容的保密性。但是，由于內(nèi)容提供商被TRA認定，因而如果發(fā)現(xiàn)不正當行為可以追蹤或識別的事實，該內(nèi)容要受到保護防止盜版。因為使用權不局限于內(nèi)容，所以內(nèi)容提供商在該內(nèi)容注冊到TRA之后可以改變使用權。在本發(fā)明第二和第三實施例中的內(nèi)容發(fā)行根據(jù)內(nèi)容發(fā)行協(xié)議實現(xiàn)，這些協(xié)議分別提供了具有基于加密的內(nèi)容保密性的無限和有限權利管理。
有利的是，本發(fā)明的內(nèi)容發(fā)行方法和裝置可以為所有的內(nèi)容提供商提供方便、有效和成本劃算的保護。本發(fā)明的這些和其它特征和優(yōu)點將從附圖和下面的詳細描述中變得更加明顯。


圖1說明根據(jù)本發(fā)明的具有無線權利管理的內(nèi)容發(fā)行方法。
圖2，3，4，5和6是說明在圖1的內(nèi)容發(fā)行方法中實現(xiàn)的處理操作。
圖7說明根據(jù)本發(fā)明的具有無線權利管理和內(nèi)容保密性的內(nèi)容發(fā)行方法。
圖8，9，10和11是說明在圖7的內(nèi)容發(fā)行方法中實現(xiàn)的處理操作。
圖12說明根據(jù)本發(fā)明的具有有限權利管理和內(nèi)容保密性的內(nèi)容發(fā)行方法。
圖13，14，15，16，17和18是說明在圖12的內(nèi)容發(fā)行方法中實現(xiàn)的處理操作。
本發(fā)明允許音樂或任何其它形式的內(nèi)容以匿名發(fā)行的方式注冊。下面描述的這些內(nèi)容發(fā)行方法允許內(nèi)容提供商在發(fā)行之前將內(nèi)容注冊到信托權威，從而允許以如果不出現(xiàn)爭議則不需要披露內(nèi)容提供商的方式將內(nèi)容從內(nèi)容提供商發(fā)行到內(nèi)容使用者。有利的是，本發(fā)明的內(nèi)容發(fā)行方法可以為所有的內(nèi)容提供商提供方便、有效和成本劃算的保護。
本發(fā)明的三個實施例將在下面描述，每個相應于實現(xiàn)上述功能的特定協(xié)議。該協(xié)議隨著為內(nèi)容提供商給出的安全和控制程度而變化。在下面的描述中，操作E{K}[S]表示用密鑰K加密括號中的量S，操作D{K}[S]表示用密鑰K解密括號中的量S。下面要描述的協(xié)議可以利用傳統(tǒng)的公共密鑰加密技術來實現(xiàn)這些加密與解密操作。通常，對于這里所述的實施例，用于加密與解密的不對稱算法使用下標包含″Pub″或″Prv″的密鑰，而對稱算法使用所有其它的密鑰，例如下面要描述的KCont和KLicense。適用于本發(fā)明的這些和其它加密與解密技術為本領域技術人員所熟知，因此在這里就不詳細描述了。
圖1說明根據(jù)本發(fā)明第一實施例的發(fā)行具有無限權利管理內(nèi)容的基本協(xié)議。此圖表示鑒定權威(CA)102、內(nèi)容提供商104、信托注冊權威(TRA)106和內(nèi)容使用者108之間的交互作用。這里CA102、內(nèi)容提供商104和內(nèi)容使用者108還分別用字母X、G和C表示。圖1示出的方法包括處理操作110、120、130、140和150，它們分別在圖2，3，4，5和6的流程圖中更詳細的示出。
圖1的處理操作實現(xiàn)了一種基本協(xié)議，在該協(xié)議中不通過加密保護發(fā)行的內(nèi)容，即不提供內(nèi)容的保密性。但是，由于內(nèi)容提供商G被TRA106認定，因而如果發(fā)現(xiàn)不正當行為可以追蹤或識別的事實，該內(nèi)容要受到保護防止盜版。而且，在本發(fā)明的實施例中，使用權不局限于該內(nèi)容。這允許內(nèi)容提供商G在內(nèi)容注冊到IRA106之后可以改變使用權。
在圖1的基本協(xié)議中，內(nèi)容提供商104(G)首先請求CA102(X)的認定。CA102在操作110生成該認定，如圖2所示。認定生成過程可以常規(guī)的方式實現(xiàn)，例如根據(jù)已建立的標準。在步驟111，CA102確定請求者G的身份是否一致。如果否，則不頒發(fā)認定。如果請求者G確定是，則CA102在步驟112為請求者生成一對公共密鑰，在步驟113將專用密鑰KPrvrequestor安全給到請求者G。然后CA102將請求者Irequestor的標識和公共密鑰KPubrequestor結(jié)合在認定中，如步驟114所示，并將認定CertX(IG，KPubG)頒發(fā)給請求者G，如圖1所示。應當注意的是，對于每個交易，認定不是必須的，即一旦某人已經(jīng)獲得認定，則可以重復使用直到期滿。
圖1的操作120在圖3示出。內(nèi)容提供商G在步驟121為具體的內(nèi)容M產(chǎn)生散列碼H＝hash(M)。
然后內(nèi)容提供商G在步驟122用其專用密鑰KPrvG加密HH′＝E{KPrvG}[H]，并在步驟123生成Q如下Q＝(H′，CertX(IG，KPubG))內(nèi)容提供商G然后將請求發(fā)送到TRA106來注冊Q，如圖1所示。圖4表示TRA106實現(xiàn)的操作130。在步驟131，TRA確定內(nèi)容提供商G的認定CertX(IG，KPubG)是否有效。如果否，該操作結(jié)束，拒絕注冊Q的請求。如果認定在步驟131確定為有效，則TRA在步驟132存儲H′和IG對以及接收的時間和日期。在步驟133，TRA從Q提取散列值H如下H＝D{KPubG}[H′]然后TRA在步驟134產(chǎn)生注冊存根Q′如下Q′＝E{KPrvTRA}[H]。
TRA因此解密由內(nèi)容提供商G發(fā)送的散列值H，并用專用密鑰KPrvTRA重新加密。得出的注冊存根Q′發(fā)給內(nèi)容始發(fā)者G，如圖1所示。
然后由內(nèi)容提供商G執(zhí)行圖1的操作140。圖5更詳細的表示此操作。假設內(nèi)容提供商G以任何常規(guī)方式獲得TRA的認定。在步驟141，內(nèi)容提供商G確定TRA的認定是否有效。如果否，該操作結(jié)束。如果TRA的認定有效，則內(nèi)容提供商G在步驟142確定是否D{KPrvTRA}[Q′J＝hash(M)。如果是，則在步驟143存儲用于Q′和M后來的發(fā)行。否則，該操作結(jié)束，不存儲Q′和M。如果存儲Q′和M，則內(nèi)容提供商G知道已經(jīng)成功完成內(nèi)容M的注冊處理，因此內(nèi)容提供商可以自由將該內(nèi)容發(fā)行給一個或多個使用者。
再參見圖1，在成功完成操作140之后，內(nèi)容提供商將注冊存根Q′和M發(fā)行給內(nèi)容使用者108(C)。圖6表示內(nèi)容使用者C執(zhí)行的操作150。內(nèi)容使用者C在步驟151確定TRA的認定是否有效。如果否，該操作結(jié)束。否則，內(nèi)容使用者在步驟152確定是否D{KPrvTRA}[Q′]＝hash(M)。如果否，該操作結(jié)束。否則，內(nèi)容使用者C在步驟153播放和/或存儲內(nèi)容M。只要內(nèi)容提供商G確認為″真″，因此內(nèi)容使用者C接受該內(nèi)容。
應當注意的是，這里描述的由內(nèi)容使用者執(zhí)行的操作150和其它操作可以在防偽裝置中執(zhí)行，例如當內(nèi)容使用者解密該內(nèi)容時，該解密后的內(nèi)容不應該被未授權的用戶和裝置接入。
正如先前所提到的，內(nèi)容M可以是音樂或任何其它類型的內(nèi)容。該內(nèi)容可以是用任何適當編碼裝置生成的壓縮格式，或是未壓縮格式?？梢杂脗鹘y(tǒng)的安全鏈路協(xié)議實現(xiàn)到單個內(nèi)容使用者的保證銷售，這對本領域技術人員來說是顯而易見的。
如果內(nèi)容使用者可以播放遺贈的內(nèi)容以及伴隨注冊存根Q′的內(nèi)容，則上述的基本協(xié)議可能出現(xiàn)潛在的保護問題。即，如果Q′丟失或不存在，則無法從基本協(xié)議注冊的內(nèi)容中區(qū)分出遺贈的內(nèi)容。
在下面要描述的該協(xié)議的增強版本中，加密格式提供該區(qū)別，因此通常不會發(fā)生該保護問題。但是，還可以通過在內(nèi)容M中嵌入水印解決基本協(xié)議中的保護問題。此嵌入水印向內(nèi)容使用者表示在播放內(nèi)容之前應當呈現(xiàn)有效的注冊存根Q′。在此實施例中，圖6示出的操作150改成在步驟151之前包括附加的處理步驟，該步驟確定M是否包含表示Q′應當存在的水印。如果包含，則操作繼續(xù)步驟151。如果沒有這種水印，該工作越過步驟151和152，并進行到步驟153。其它的配置也是可能的，例如上述的嵌入水印的附加處理步驟可以在圖6的處理步驟151和152之間執(zhí)行。
應當注意的是，嵌入的水印只需要表示應當存在有效的注冊存根，可能是例如hash(M)等等的一類存根。因此嵌入的水印不需要包含注冊存根本身。另外，應當注意的是，這種水印還可以用在利用下面描述的增強版本的協(xié)議發(fā)行的內(nèi)容中，從而防止內(nèi)容記錄和發(fā)行到只支持基本協(xié)議的裝置。
圖7說明根據(jù)本發(fā)明第二個實施例的具有無限權利管理和內(nèi)容保密性的內(nèi)容發(fā)行方法。此圖表示另一個認證主管機構CA200，也稱為CAY，和實體CA(X)102、內(nèi)容提供商104、TRA106和內(nèi)容使用者108之間的相互作用。圖8，9，10和11是說明在圖7的內(nèi)容發(fā)行方法中實現(xiàn)的處理操作的流程圖。圖7示出的方法包括處理操作210，220，250，260和270。處理操作210通常對應于圖2的操作110，但由CA(Y)實現(xiàn)。處理操作220，250，260和270分別在圖8，9，10和11的流程圖中更詳細的示出。
圖7中的處理操作實現(xiàn)圖1基本協(xié)議的增強版本。在此增強協(xié)議中，內(nèi)容通過加密來保護，即提供內(nèi)容的保密性。另外，在上述的基本協(xié)議中，增強協(xié)議中的內(nèi)容也要受到保護而不被盜版，并且使用權不局限于內(nèi)容，在內(nèi)容已經(jīng)被注冊之后允許出版商改變使用權。
在圖7的增強協(xié)議中的，內(nèi)容提供商(G)104請求CA(X)102的認證，內(nèi)容使用者(C)108請求CA(Y)200的認證。CA102，200分別在操作110和210按照結(jié)合圖2所述的方式分別產(chǎn)生認證CertX(IG，KPubG)，CertY(IC，KPubC)。認證CertX(IG，KPubG)由CA102頒發(fā)給內(nèi)容提供商G，認證CertY(IC，KPubC)由CA200頒發(fā)給內(nèi)容使用者C。應當注意的是，CA102和CA200可以是相同的CA。在此實例里，它們被表示成單獨的實體是為了說明認證不一定來自同一CA。
圖7的操作220在圖8中示出。內(nèi)容提供商G在步驟221加密內(nèi)容M以產(chǎn)生加密的內(nèi)容M’M′＝E{KCont}[M]。應當注意的是，KCont不一定是單個密鑰。例如，它可以是一序列密鑰，該序列的每個密鑰用于加密該內(nèi)容的不同部分。內(nèi)容提供商G在步驟222產(chǎn)生對于具體內(nèi)容M′的散列值H＝hash(M′)。
內(nèi)容提供商G在步驟223用其專用密鑰KPrvG加密HH′＝E{KPrvG}[H]，并在步驟224產(chǎn)生Q如下Q＝(H′，CertX(IG，KPubG))。
內(nèi)容提供商G然后向TRA106發(fā)送一請求以注冊Q，如圖7所示。該請求由TRA106在操作130處理，如圖4所示，注冊存根Q′由TRA106頒發(fā)給內(nèi)容提供商G。
內(nèi)容提供商G然后執(zhí)行操作140′，其與圖5的操作140相同，除了在步驟142和143M由M′替換。存儲Q′和M′作為條件檢驗142的結(jié)果。如果142是真，則存儲Q′和M′內(nèi)容提供商G得知對加密內(nèi)容M′的注冊處理已經(jīng)成功地完成。因此內(nèi)容提供商能自由將加密內(nèi)容發(fā)行給一個或多個使用者。
再參見圖7，在成功完成操作140′之后，內(nèi)容提供商G將注冊存根Q′和加密內(nèi)容M′發(fā)行到內(nèi)容使用者108(C)。
圖9表示由內(nèi)容使用者C執(zhí)行的操作250。內(nèi)容使用者C在步驟251確定對TRA的認證是否有效。如果否，該操作結(jié)束。否則，內(nèi)容使用者在步驟252確定是否D{KPubTRA}[Q′]＝hash(M′)。如果否，該操作結(jié)束。否則，內(nèi)容使用者C在步驟253存儲加密內(nèi)容M′。只要內(nèi)容提供商G被證實為″真″，則內(nèi)容使用者C存儲該加密內(nèi)容。
為了訪問該內(nèi)容，內(nèi)容使用者C必須也收到內(nèi)容解密密鑰KCont以及始發(fā)者定義的任何使用規(guī)則。只有在內(nèi)容提供商G成功驗證使用者的身份之后，此信息才發(fā)送給內(nèi)容使用者C。為這目的，內(nèi)容使用者C在步驟254的操作250為加密內(nèi)容M′產(chǎn)生散列值H＝hash(M′)。然后內(nèi)容使用者在步驟255用專用密鑰KPrvC加密HH″＝E{KPrvC}[HJ，并在步驟256產(chǎn)生一對包括加密散列值和上述的認證CertY(IC，KPubC)的Q″Q″＝(H″，CertY(IC，KPubC))。然后這對Q″然后從內(nèi)容使用者C發(fā)送給內(nèi)容提供商G。
圖10表示內(nèi)容提供商G執(zhí)行的操作260。在步驟261，內(nèi)容提供商G確定內(nèi)容使用者C的認證CertY(IC，KPubC)是否有效。如果否，該操作結(jié)束。否則，內(nèi)容提供商G在步驟262確定是否D{KPubC}[H″]＝hash(M′)如果否，該操作結(jié)束。否則，內(nèi)容提供商G在步驟263利用許可密鑰Klicense加密內(nèi)容密鑰KCont和使用規(guī)則A＝E{Klicense}[usage_rules|[KPubC]然后在步驟264加密許可密鑰B＝E{KPubC}[Klicense]然后在步驟265生成許可存根L作為一對(A，B)。如圖7所示，內(nèi)容提供商G然后將許可存根L發(fā)送到內(nèi)容使用者C。
圖11表示內(nèi)容使用者C在收到許可存根L之后，內(nèi)容使用者C執(zhí)行的操作270。在步驟271，內(nèi)容使用者C解密許可密鑰Klicense＝D{Klicense}[A]然后在步驟272解密規(guī)則和內(nèi)容密鑰usage_rules|KCont＝D{Klicense}[A]內(nèi)容使用者C然后在步驟273解密加密內(nèi)容M′M＝D{KCont}[M′]。內(nèi)容使用者然后在步驟274將使用規(guī)則應用到內(nèi)容M，并在步驟275播放和/或存儲內(nèi)容M。
圖12說明根據(jù)本發(fā)明第三實施例的具有有限權利管理和內(nèi)容保密性的內(nèi)容發(fā)行方法。此圖表示實體CA(Y)200、CA(X)102、內(nèi)容提供商(G)104、TRA106和內(nèi)容使用者(C)108。圖13，14，15，16，17和18是在圖12的內(nèi)容發(fā)行方法中分別實現(xiàn)的處理操作320，330，340，350，360和370。處理操作110和210是按照先前結(jié)合圖7
圖12中的處理操作實現(xiàn)圖1基本協(xié)議的另一增強版本。在此增強協(xié)議中，如同圖7的增強協(xié)議，內(nèi)容通過加密來保護，即提供內(nèi)容保密性。另外，如同上述的基本和增強協(xié)議，該增強協(xié)議的內(nèi)容也受到保護防止盜版。但是，不同于上述的協(xié)議，此增強協(xié)議還擔保該許可是真實的，因為它與內(nèi)容結(jié)合在一起并注冊到TRA106。
應當注意的是，此方案限制內(nèi)容提供商G，因為內(nèi)容提供商G在內(nèi)容已經(jīng)注冊到TRA106之后不能改變內(nèi)容的使用規(guī)則。因此，如果內(nèi)容提供商G想在注冊之后改變使用規(guī)則，就必需一次新的注冊。
在圖12的增強協(xié)議中，內(nèi)容提供商(G)104請求CA(X)102的認證，內(nèi)容使用者(C)108請求CA(Y)200的認證。CA102，200分別在操作110和210按照結(jié)合圖2所述的方式分別產(chǎn)生認證CertX(IG，KPubG)，CertY(IC，KPubC)。認證CertX(IG，KPubG)由CA102頒發(fā)給內(nèi)容提供商G，認證CertY(IC，KPubC)由CA200頒發(fā)給內(nèi)容使用者C。如上所述，CA102和CA200可以是同一個CA。
圖12的操作320在圖13中示出。內(nèi)容提供商G在步驟321加密內(nèi)容M以產(chǎn)生加密的內(nèi)容M′M′＝E{KCont}[M]如上所述，KCont不一定是單個密鑰。例如，它可以是一序列密鑰，該序列的每個密鑰用于加密該內(nèi)容的不同部分。
內(nèi)容提供商G在步驟322產(chǎn)生對于具體內(nèi)容M′的散列值H1＝hash(M′)在步驟323，內(nèi)容提供商G通過生成許可注冊存根A來組合一組規(guī)則和內(nèi)容密鑰如下A＝E{Klicense}[usage_rules|[KPubC]應當注意的是，結(jié)合規(guī)則和具體的內(nèi)容密鑰可以通過加密進行，如上所述，或者通過任何其它的密碼結(jié)合機理。通過加密實現(xiàn)時，加密應當利用鏈接方式，以防止可能打破該結(jié)合的塊重放攻擊。
在步驟323結(jié)合規(guī)則之后，然后在步驟324生成A的散列值H2＝hash(A)內(nèi)容提供商G然后在步驟325用其專用密鑰KPrvG加密H′＝E{KPrvG}[H1|H2]并在步驟326產(chǎn)生Q如下Q＝(H′，CertX(IG，KPubG)內(nèi)容提供商G然后向TRA106發(fā)送一請求以注冊Q，如圖12所示。該請求由TRA106在操作330處理，如圖14所示。在步驟331，TRA確定內(nèi)容提供商G的認證CertX(IG，KPubG)是否有效。如果否，該操作結(jié)束，并拒絕注冊Q的請求。如果該認證在步驟331確定為有效，TRA在步驟332存儲H′和IG對，以及接收的時間和日期。在步驟333，TRA從Q提取散列值H1和H2。TRA然后在步驟334產(chǎn)生內(nèi)容注冊存根Q1′如下Q1′＝E{KPrvTRA}[H1]并在步驟334生成使用規(guī)則注冊存根Q2′如下Q2′＝E{KPrvTRA}[H2]因此TRA解密由內(nèi)容提供商G發(fā)送的散列值H1和H2并用其專用密鑰KPrvTRA重新加密。得到的注冊存根Q1′和Q2′發(fā)給內(nèi)容始發(fā)者G，如圖12所示。
然后由內(nèi)容提供商G執(zhí)行圖12的操作340。圖15更詳細的表示此操作。在步驟341，內(nèi)容提供商G確定對TRA的認證是否有效。如果否，該操作結(jié)束。如果對TRA的認證有效，內(nèi)容提供商G然后在步驟142確定是否D{KPrvTRA}[Q1′]＝hash(M′)。
如果是，則Q1′，Q2′和M′在步驟343存儲用于后來的發(fā)行。否則，該操作結(jié)束而不必存儲Q1′，Q2′和M′。如果存儲Q1′，Q2′和M′，內(nèi)容提供商G得知用于加密內(nèi)容M的注冊處理已經(jīng)成功完成，因此內(nèi)容提供商自由將內(nèi)容發(fā)行給一個或多個使用者。
再參見圖12，在成功完成操作340之后，內(nèi)容提供商G將注冊內(nèi)容存根Q1′和加密內(nèi)容M′發(fā)行到內(nèi)容使用者108(C)。
圖16表示由內(nèi)容使用者C執(zhí)行的操作350。內(nèi)容使用者C在步驟351確定對TRA的認證是否有效。如果否，該操作結(jié)束。否則，內(nèi)容使用者在步驟352確定是否
D{KPrvTRA}[Q1′]＝hash(M′)。如果否，該操作結(jié)束。否則，內(nèi)容使用者C在步驟353存儲加密內(nèi)容M′。只要內(nèi)容提供商G被證實為″真″，則內(nèi)容使用者C存儲該加密內(nèi)容。
為了訪問該內(nèi)容，內(nèi)容使用者C必須也收到內(nèi)容加密密鑰KCont以及始發(fā)者定義的任何使用規(guī)則。只有在內(nèi)容提供商G成功驗證使用者的身份之后，此信息才發(fā)送給內(nèi)容使用者C。為這目的，內(nèi)容使用者C在步驟354的操作350為加密內(nèi)容M′產(chǎn)生散列值H＝hash(M′)。然后內(nèi)容使用者在步驟355用專用密鑰KPrvC加密HH″＝E{KPrvC}[H]并在步驟356產(chǎn)生一對包括加密散列值和上述的認證CertY(IC，KPubC)的Q″Q″＝(H″，CertY(IC，KPubC)這對Q″然后從內(nèi)容使用者C發(fā)送到內(nèi)容提供商G。
圖17表示內(nèi)容提供商G執(zhí)行的操作360。在步驟361，內(nèi)容提供商G確定內(nèi)容使用者C的認證CertY(IC，KPubC)是否有效。如果否，該操作結(jié)束。否則，內(nèi)容提供商G在步驟362確定是否D{KPubC}[H″]＝hash(M′)。
如果否，該操作結(jié)束。否則，內(nèi)容提供商G在步驟363利用內(nèi)容使用者C的公眾密鑰KPubC加密許可密鑰KlicenseB＝E{KPubC}[Klicense]然后在步驟364生成許可存根L作為三元組(A，B，Q2′)。如圖12所示，內(nèi)容提供商G然后將許可存根L發(fā)送到內(nèi)容使用者C。
圖18表示內(nèi)容使用者C在收到許可存根L之后，內(nèi)容使用者C執(zhí)行的操作370。在步驟371內(nèi)容使用者C確定是否D{KPrvTRA}[Q2′]＝hash(A)。如果否，該處理結(jié)束。否則，內(nèi)容使用者C在步驟372解密許可密鑰Klicense＝D{Klicense}[B]然后在步驟373解密規(guī)則和內(nèi)容密鑰usage_rules|KCont＝D{Klicense}[A]內(nèi)容使用者C然后在步驟374解密加密內(nèi)容M′
M′＝E{KCont}[M]內(nèi)容使用者然后在步驟375將使用規(guī)則應用到內(nèi)容M，并在步驟376播放和/或存儲內(nèi)容M。
在上述的協(xié)議中，如果注冊特定一段內(nèi)容的非法拷貝，例如盜版音樂選擇，來嘗試進行符合SDMI的非法拷貝，則TRA106將進行注冊，沒有任何問題。但是，這種注冊要求內(nèi)容提供商G通過向TRA出示認證來正確地識別它自己。因此，即使非法拷貝已經(jīng)注冊，進行注冊的內(nèi)容提供商可以立即被識別和起訴。通過這種方式，在內(nèi)容發(fā)行給內(nèi)容使用者之后，只要出現(xiàn)沖突就能追捕到違法者。應當合法地確定標識已注冊內(nèi)容提供商的理由，以要求起訴者對相同或充分相似的內(nèi)容提出有效和優(yōu)先的注冊。
應當注意的是，CA102和200、內(nèi)容提供商104、TRA106和內(nèi)容使用者108的一個或多個都表示實現(xiàn)與上述協(xié)議有關的處理操作的一個或多個個人計算機、工作站、主計算機或其它基于處理器的裝置。這種處理器裝置通常包括一個或多個存儲裝置，用于存儲與所述處理功能有關的適當軟件程序指令，和至少一個處理器，用于執(zhí)行這些軟件程序指令。如圖1，7和12所示，這些實體之間的通信1，7和12可以是通過諸如互聯(lián)網(wǎng)的全球通信網(wǎng)、廣域網(wǎng)、局域網(wǎng)、內(nèi)聯(lián)網(wǎng)、外聯(lián)網(wǎng)以及這些和其它網(wǎng)絡的組合實現(xiàn)的網(wǎng)絡連接。圖1，7和12因此也可以看作實現(xiàn)相應協(xié)議的系統(tǒng)處理部件之間互連的系統(tǒng)圖。
上述的本發(fā)明的實施例只是說明性的。例如，本發(fā)明可用于實現(xiàn)任何期望類型的軟件或硬件元件，以及這些和其它元件組合的升級或其它的重新配置，用于任何期望類型的基于處理器的裝置，和用于不同于這里所述用途的許多應用中。本發(fā)明還可以至少部分地按照一個或多個軟件程序的形式實現(xiàn)，這些程序存儲在傳統(tǒng)的電、磁或光存儲器媒介上，并由例如系統(tǒng)200的處理器220和230的處理裝置執(zhí)行。落入下面權利要求范圍內(nèi)的這些和多個其它的實施例對本領域技術人員是顯而易見的。
權利要求
1.一種從內(nèi)容提供商(104)發(fā)行內(nèi)容到內(nèi)容使用者(108)的方法，該方法包括步驟請求將內(nèi)容注冊到信托注冊主管機構(106)；接收來自信托注冊主管機構的注冊信息；和將至少一部分注冊信息連同內(nèi)容一起發(fā)行到內(nèi)容使用者。
2.權利要求1的方法，其中將內(nèi)容注冊到信托注冊主管機構至少部分地根據(jù)內(nèi)容提供商從認證主管機構(102)獲得的認證。
3.權利要求1的方法，其中注冊信息連同內(nèi)容一起發(fā)行到內(nèi)容使用者，因此信托注冊主管機構可以隨后從發(fā)行給內(nèi)容使用者的注冊信息中識別該內(nèi)容提供商。
4.權利要求1的方法，其中內(nèi)容提供商收到來自信托注冊主管機構的注冊信息，確定注冊主管機構的有效性，如果該注冊主管機構有效，則存儲該內(nèi)容和注冊信息，用于后續(xù)發(fā)行到內(nèi)容使用者。
5.權利要求2的方法，其中內(nèi)容提供商為具體的內(nèi)容M產(chǎn)生散列值H，用其專用密鑰KPrvG加密H，以產(chǎn)生加密散列值H′，然后產(chǎn)生一對Q如下Q＝(H′，CertX(IG，KPubG)其中CertX(IG，KPubG)是從認證主管機構獲得的認證，并將Q發(fā)送到信托注冊主管機構用于注冊。
6.權利要求5的方法，其中信托注冊主管機構確定為內(nèi)容提供商的認證CertX(IG，KPubG)是否有效，如果不有效，則拒絕該注冊，如果有效，則存儲加密散列值H′和IG以及接收的時間和日期，并從Q提取散列值H如下H＝D{KPubG}[H′]然后以注冊存根Q′的形式生成注冊信息，如下Q′＝E{KPrvTRA}[H]
7.權利要求6的方法，其中內(nèi)容提供商從信托注冊主管機構收到Q′，并確定是否D{KPrvTRA}[Q′]＝hash(M)，如果是，則存儲Q′和M，用于隨后發(fā)行給內(nèi)容使用者。
8.權利要求7的方法，其中內(nèi)容使用者一從內(nèi)容提供商收到Q′和M就確定是否D{KPrvTRA}[Q′]＝hash(M)1如果是，就使用內(nèi)容M。
9.權利要求8的方法，其中如果內(nèi)容M確定為非法，則由信托注冊主管機構識別內(nèi)容M的來源。
10.一種從內(nèi)容提供商(104)發(fā)行內(nèi)容到內(nèi)容使用者(108)的裝置，該裝置包括裝置(104)，與內(nèi)容提供商有關，并操作(i)請求將內(nèi)容注冊到信托注冊主管機構(106)；(ii)接收來自信托注冊主管機構的注冊信息；和(iii)將至少一部分注冊信息連同內(nèi)容一起發(fā)行到內(nèi)容使用者。
11.一件包括計算機可讀媒介的產(chǎn)品，該媒介包含用于從內(nèi)容提供商(104)發(fā)行到內(nèi)容使用者(108)的一個或多個軟件程序，其中軟件程序在執(zhí)行時實現(xiàn)步驟請求將內(nèi)容注冊到信托注冊主管機構(106)；接收來自信托注冊主管機構的注冊信息；和將至少一部分注冊信息連同內(nèi)容一起發(fā)行到內(nèi)容使用者。
12.一種生成注冊信息的方法，該信息用于從內(nèi)容提供商(104)發(fā)行內(nèi)容到內(nèi)容使用者(108)，該方法包括步驟接收將內(nèi)容注冊到信托注冊主管機構(106)的請求；和將信托注冊主管機構產(chǎn)生的注冊信息發(fā)送到內(nèi)容提供商，因此內(nèi)容提供商可以將至少一部分注冊信息連同內(nèi)容一起發(fā)行到內(nèi)容使用者。
全文摘要
用于安全發(fā)行音樂和其它類型內(nèi)容的方法和裝置。本發(fā)明允許內(nèi)容以匿名發(fā)行的方式注冊到集中信托注冊主管機構(TRA),因此不需要公開內(nèi)容提供商的身份直到出現(xiàn)爭議。本發(fā)明的第一實施例提供了內(nèi)容的無限權利管理,即安全注冊,因此內(nèi)容的使用權不局限于內(nèi)容本身。在此實施例中,發(fā)行的內(nèi)容不通過加密保護,即不提供內(nèi)容的保密性。但是,由于內(nèi)容提供商被TRA認定,因而如果發(fā)現(xiàn)不正當行為可以追蹤或識別的事實,該內(nèi)容要受到保護防止盜版。因為使用權不局限于內(nèi)容,所以內(nèi)容提供商在該內(nèi)容注冊到TRA之后可以改變使用權。在本發(fā)明第二和第三實施例中的內(nèi)容發(fā)行分別提供了具有基于加密的內(nèi)容保密性的無限和有限權利管理。
文檔編號G06Q50/00GK1366631SQ01800850
公開日2002年8月28日 申請日期2001年1月18日 優(yōu)先權日2000年2月7日
發(fā)明者M·A·埃普斯坦, M·羅斯納, A·A·M·斯塔林 申請人:皇家菲利浦電子有限公司