专利名称：从非易失性存储卡、致密盘或其他介质中回放记录音频、视频或其他内容的系统、方法和设备的制作方法
技术领域：
本发明一般且具体涉及从存储卡、致密盘或其他介质安全回放数字音频、视频或其他内容。
2.相关技术在因特网上、通过其他通信系统或通过零售亭(retail kiosk)电子发行带版权音乐的潜力正受到未经授权拷贝音乐相关方面的限制。对于其他音频以及视频、内容也是这种情况。内容典型地以加密形式提供给最终客户，并且客户将加密内容文件记录到某些存储介质如个人计算机存储器、便携式播放设备存储器、可写入致密盘(CD)或非易失性存储卡上。内容提供商意欲消除未经授权拷贝内容的可能性，但必须满足采取最小化所发生拷贝量的步骤。这包括提供对记录介质上的内容的保护。在此以保护存储在非易失性存储卡上的内容为例进行描述，但是相同的内容保护技术可以应用于致密盘或其他可记录介质。
存在若干可商业获得的非易失性存储卡适于用作内容数据存储介质。其中一种是致密快闪(CompactFlash，CF)卡，另一种是多媒体卡(MultiMediaCard，MMC)，另外还有一种是与MMC卡紧密相关的安全数字(SD)存储卡。所有这三种和其他存储器都可以以各种存储容量从SanDisk Corporation(SanDisk公司)，桑尼维尔，加利福尼亚(本申请的受让人)获得。MMC的物理和电气规范参见由MultimediaCardAssociation(多媒体卡协会，MMCA)，库珀蒂诺，加利福尼亚时常更新和发布的“MultimediaCard System Specification(多媒体卡系统规范)”其版本2.11和2.2的发布日期分别为1999年6月和2000年1月，在此将其引作参考。MMC产品在由SanDisk Corporation发布且日期为2000年4月的“MultiMediaCard Product Manual(多媒体卡产品手册)”，修订版2中也有描述，在此将其引作参考。MMC产品的电气操作的某些方面在作者为Thomas N.Toombs和Micky Holtzman、序列号为09/185,649和09/186,064、提交日期均为1998年11月4日且受让给SanDisk Corporation的共同未决专利申请中也有描述。物理卡结构及其制造方法在受让给SanDisk Corporation的美国专利6,040,622号中有描述。在此均将这些申请和专利引作参考。
较新的SD卡类似于MMC卡，它们在平面图上相同。它们之间的主要差别是SD卡包括附加数据触点从而允许卡和主机间的更快数据传输。SD卡的其他触点与MMC卡相同，从而被设计为接受SD卡的插槽(socket)也将接受MMC卡。与SD卡的电气接口对于大部分也使得向后兼容于在上述引用的其规范版本2.11中描述的MMC产品，从而不需要为容纳这两种卡而对主机操作作很多修改。SD卡的电气接口及其操作在2000年8月17日提交的共同未决专利申请09/643,023序列号中有描述，在此将其全文引作参考。
发明内容
加密内容难以访问，并且带加密内容的存储卡或致密盘均具有需要特定命令和例程来访问加密和未经加密内容的特定结构。本发明的软件是一种任何原始设备制造商(OEM)可以在具有各种不同类型的微处理器的各种不同类型设备上安装并运行的简单解决方案。这些设备的范围从个人计算机到便携式设备以及到小汽车立体声系统，并且包括用户意欲通过其访问可能加密的内容的任何设备。便携式设备可以是便携式音频播放器、蜂窝电话、便携式组织器(organizer)、或者更一般的是任何微处理器控制便携式设备。存储介质可以是闪存或任何类型的可记录盘。这些设备可以具有带小量或大量存储器的简单或强大微处理器。软件仅利用和需要小缓冲区以用于加密的目的，并且被设计为即使在受限处理能力和存储器的环境下也高效运行。它可以由任何类型的通用微处理器或专用微处理器如DSP或ASIC运行。另外，软件的计算密集部分如加密和解密(安全)引擎可以由DSP执行，而软件的其他部分可以由另一微处理器或ASIC执行。
软件具有音频、视频和图像接口以接收相应文件类型的命令。这些接口可以组织回放和记录，包括管理播放列表和其他方便特性。因此，不管是什么设备，它只需要发出一个命令到接口，软件就将负责对安全介质进行数据读写，并且在音频、视频或图像引擎内对任何公知音频、视频或图像文件格式的数据进行解码和解压缩。
加密和解密是在一个隔离模块中发生的，该模块非常难以访问，因此与来自想要访问加密密钥以从介质或设备中拷贝文件的未经授权人员的任何尝试相隔离。内容仅以小部分来解密，并且动态密钥生成和删除的方法最小化解密密钥的泄露。
图1是用来在安全介质上读取和写入信息的设备的图；图2是用来访问安全介质的设备的示意图；图3A是安全介质各层的抽象图；图3B是安全介质存储单元的物理和逻辑结构的图；图3C是轨道结构及其组成部分的图；图4是分为多个组成分段(chunk)的介质密钥块(MKB)映象的图；图5是验证和解密过程的一部分的图；图6是验证和加密过程的的图；图7是图6所示的验证密钥交换过程的示意图；图8A是本发明软件的方框图；图8B是示出本发明软件各模块的方框图；
图8C是根据本发明的预播放和播放过程的流程图概览，其中示出相关API模块/调用；图8D是图8C的音频内容初始化阶段的拓展流程图；图8E是图8C的预播放过程805期间所创建的信息块的图；图9是根据本发明回放音频轨道的流程图概览；图10是处理图4所示的MKB映象即图9的一个步骤的流程图。
具体实施例方式
加密内容难以访问，并且带加密内容的存储卡或致密盘均具有需要特定命令和例程来访问加密和未经加密内容的特定结构。本发明的软件是一种任何原始设备制造商(OEM)可以在具有各种不同类型的微处理器的各种不同类型设备上安装并运行的简单解决方案。这些设备的范围从个人计算机到便携式设备以及到小汽车立体声系统，并且包括用户意欲通过其访问可能加密的内容的任何设备。便携式设备可以是便携式音频播放器、蜂窝电话、便携式组织器、或者更一般的是任何微处理器控制便携式设备。存储介质可以是闪存或任何类型的可记录盘。这些设备可以具有带小量或大量存储器的简单或强大微处理器。软件仅利用和需要小缓冲区以用于加密的目的，并且被设计为即使在受限处理能力和存储器的环境下也高效运行。它可以由任何类型的通用微处理器、专用微处理器如DSP或ASIC运行。另外，软件的计算密集部分如加密和解密(安全)引擎可以由DSP执行，而软件的其他部分可以由另一微处理器或ASIC执行。在交叉引用部分中所提及的源码形成本申请的一部分，并且在此将其全部内容引作参考。
参照图1，描述对音频内容如音乐施加内容保护的一个示例系统。主机计算机设备11可以是如图所示的个人计算机(PC)、位于零售店用来发行音乐或其他内容的售货亭等。在本例中使用SD存储卡13来存储音乐。卡13可插入到利用设备(utilization device)中，在本例中为靠电池工作以通过个人耳机播放记录在卡13上的音乐或其他音频内容的便携式设备(PD)15。例如通过计算机通用串行总线(USB)连接17将设备15连接到主机11，当卡13插入到设备15中时，音乐可以存储在卡13上。可选地，如果播放器设备15没有配备有将内容记录在卡13上的功能，或者由于其他方面的希望，则卡写入器/读取器19可以通过USB连接21连接到计算机，并且将卡13插入到其中以在卡上记录音乐。然后，从写入器/读取器19移走卡13，并且插入到便携式设备15中以播放记录在卡上的音频内容。当主机11包括根据4C团体(4C Entity)和SD组(SD Group)的安全和验证协议对卡13进行内容数据读写所需的软件时，主机11称作许可遵循模块(Licensed Compliant Module，LCM)。
图2示出示例便携式利用设备15内的电子系统。在工作时通过总线23连接在一起的是计算单元(MCU)25，最好带有某非易失性闪存25A；系统存储器27，最好是高速随机访问存储器(RAM)；以及接口电路29，用于与存储卡13连接。USB连接17也可选地提供给MCU 25。如果需要，还包括数字信号处理器(DSP)31，用于对以压缩和/或加密形式存储的内容数据如音频或视频数据进行解压缩和/或解密。DSP 31还具有作为处理器的一部分而包括的其自己的RAM存储器31A。可以包括或可以不包括DSP 31。而且，如果包括DSP处理器，它可以执行MCU 25的功能，因此可以删去MCU 25。只读存储器(ROM)32可以存储本发明软件的部分或全部。ROM 32中的软件指令和数据可以直接从ROM 32执行或读取，或者首先映射(shadow)到包括在设备电路中的任一RAM存储器中。
可记录介质上的内容保护的规范由Intel Corporation(英特尔公司)，International Business Machines Corporation(国际商业机器公司)，Matsushita Electric Industrial Co.Ltd.(Matsushita电气工业有限公司)以及Toshiba Corporation(东芝公司)(4C团体)联合建立。在此具体相关的是4C团体的下面三个文献，在此将其引作参考“Content Protectionfor Recordable Media Specfication，Introduction and CommonCryptographic Elements(可记录介质内容保护规范，介绍和公共加密基础)”，修订版0.94，2000年10月；“Content Protection for RecordableMedia Specfication，SD Memory Card Book(可记录介质内容保护规范，SD存储卡册)”，修订版0.95，2001年5月；“C2 Block CipherSpecfication(C2分块加密规范)”，修订版0.9，2000年1月；以及“Content Protection for Recordable Media Specfication，DVD Book(可记录介质内容保护规范，DVD册)”，修订版0.95，2001年5月。在SD存储卡上实现这些4C团体规范的附加详细规范已由Matsushita ElectricIndustrial Co.Ltd.(MEI)、SanDisk Corporation和ToshibaCorporation(SD组)建立。
参照图3A，存储卡13可以认为具有四个不同层。这些层也可以出现在其他类型的安全介质中。
在其最基本层，数据存储在以簇排列在存储卡13的物理层13d上的存储单元中。如果数据是带版权材料或者它值得加密，则数据是加密或安全的。用来对安全内容加密和解密的密钥也经过加密并存储在物理层的安全区域中。
本发明的软件运行在一个设备内以让该设备存储和检索加密信息，而无需制造商(OEM)必须编写非常特定的指令来访问包含加密数据和密钥的存储单元。它包含将加密数据发送到设备、对设备内的数据进行解密以及根据设备请求对音频、视频和图像文件进行解压缩和播放的方法。简而言之，设备只需要发送一个命令如“播放轨道”。软件将接受命令，检索存储在存储卡中的加密数据、检索加密密钥、对数据进行组织和解密、对它进行解压缩和格式化，并且回放歌曲。
逻辑层13c包含物理层13d的存储单元和簇的组织结构。这两层13c和13d包含并在逻辑上组织存储卡13的存储器。由于卡13是安全卡，因此安全层13b控制和限制对居于以下层的安全数据的访问。
应用层13a是与访问存储在卡中的内容的设备进行通信的存储卡13的一部分。它通过设备接口或触点39来完成此操作。存储卡13最好包括管理卡操作和应用层13a的功能以及控制卡的所有层13a-d的控制器。
图3B示出根据前面规范且对应于图3A的层13c和13d的记录介质(存储卡13)的物理和逻辑结构。该卡包括存储单元阵列33和存储控制器35。用户数据、命令和状态信号通过电路37在控制器35与存储阵列33之间通信。控制器35与连接到一个插口的主机设备进行通信，其中，该插口通过卡上的一系列电气触点39插入卡。
存储单元阵列33分为四个非重叠单元区域，它们被单独设计为存储不同类型的数据。最大存储容量区域41被设计为存储用户数据，在本例中为加密音频、视频或其他数据。用户数据可以包括或者也可以不包括未经加密数据。存储器的系统区域43存储卡制造商的64比特介质标识符(IDmedia)以及由4C团体提供的16个介质密钥块(MKB)，其中每个MKB的最大尺寸为4k字节，它们均由卡制造商预先记录。16个MKB的其中一个被指定为与音频用户数据一起使用，另一个与视频用户数据一起使用，另一个用于图像数据等等。系统区域43是可从卡外部读取来访问的写保护区域。隐藏区域45承载与存储在系统区域43中的16个不同介质密钥块(MKB)相对应的16个预记录介质唯一密钥(Kmu)。隐藏区域45是仅可由存储卡本身访问的写保护区域。保护区域47是仅在显式相互验证成功之后才可访问的读/写区域。随机选取标题密钥(Kt)和拷贝控制信息(CCI)以加密形式存储在保护区域47中。存储在用户数据区域41中的各个内容片断(文件)以唯一标题密钥加密，其中，标题密钥也以加密形式存储在保护区域47中。存储在保护区域47中的标题密钥和CCI串接在一起，并且用对于各存储卡唯一且存储在其隐藏区域45中的介质唯一密钥一起加密。
用户数据区域41的文件系统典型地是普通FAT文件系统。FAT系统描述哪些存储簇构成哪些轨道和轨道的各个子组成部分。用户数据区域41内的音频或视频轨道可以如图3C所示包括多个文件。音频文件称作音频对象(AOB)，并且图片文件称作图片对象(POB)。一个轨道可以包括两者。例如，轨道300由AOB 304和AOB 308组成，轨道302由AOB 306组成，并且最后轨道xxx由AOB xxx和POB xxx组成。各AOB或POB还分为子组成部分。AOB 304如图所示分为多个AOB块312，它进一步分为多个带首标318的AOB元素316。各元素可以存储在存储卡13的一个或多个存储簇中。AOB元素分为最低组成级别即AOB帧320。根据内容的编码和压缩，每两秒可以包括可变数目的帧。时间搜索表(TMSRT)具有有关对应于“每两秒”回放的帧数和数据大小的信息。当由于快进和快退而访问音频或视频轨道和组成部分AOB元素和帧时，使用该信息。另外，如后面参照图9和10所述，虽然一次可以对来自任何地方的小于1到10秒的内容进行解密，但是标题密钥(Kt)只有在访问此“每两秒”内容所花时间内才处于解密状态。若要了解详情，请参考前面引作参考的“CRPM规范，SD存储卡册”。
存储在卡存储器的系统区域43中的介质密钥块(MKB)包含一系列连续记录，其中一个记录如图4所示。整个MKB映象49为64K字节。它分为128个512字节的分段(chunk)，并且对分段1放大以示出其组成部分，其中，分段1包含第一记录的全部或部分，并且在图中标为MKB分段50。分段50也可以包含多个记录。第一字段51包含记录类型、第二字段53包含记录总长度，并且剩余字段55包含密钥本身。记录类型和长度字段51和53中的数据不经加密。MKB的各个记录在总长上是4字节的倍数。如图5的块57所示，MKB密钥记录采用存储在利用存储卡以对存储在其上的内容数据进行读取或编程的便携式设备(PD)、许可遵循模块(LCM)或其他设备中的设备密钥来解密。设备密钥Kd1、Kd2、Kd3…由设备制造商写入到利用设备的存储器如图2的便携式音频播放器的MCU 25内的非易失性闪存中。这些设备密钥由4C团体提供给设备制造商，并且保持保密。存储在给定利用设备中的设备密钥数目依赖于设备类型。
执行图5处理的利用设备(PD、LCM或其他设备)计算介质密钥Km作为对块57进行解密的一部分，这将在后面参照图9和10作进一步的讨论。从所插存储卡的系统区域中读取的MKB的各个记录(图4)通常以这种方式处理。在完成MKB处理之后，采用最近算出的Km值作为块57的机密介质密钥输出。该介质密钥Km和介质标识符IDmedia通过使用C2单向函数来组合，如图5的块59所示，以产生介质唯一密钥Kmu。该处理的其他详情可以参考前面引用的4C团体文献。
图6示出当将音频内容记录到具有图3的存储空间分配的存储卡13上或者从其播放音频内容时所发生的所有验证和加密处理。图中示出为将音频或其他内容记录到卡13上而在个人计算机或其他LCM 63中发生的处理。类似地，图中还示出为从卡13读取记录内容而在便携式音频或其他利用设备65中执行的处理。这两个处理均包括参照图5所述的处理，处理块57和59是利用设备65的一部分，并且相应处理块57’和59’是内容记录系统63的一部分。
作为记录内容的一部分，在线路67输入任意分配的标题密钥Kt以由加密模块69用来加密在线路71输入的一个音频或其他内容文件(片断)。然后，将加密文件存储在存储卡13的用户数据区域41中。为了使标题密钥可用于对记录内容进行解密，如前所述，标题密钥(Kt)的加密型式存储在保护卡存储区域47中。标题密钥(Kt)的加密型式还存储在系统存储器27、MCU 25的RAM存储器25A或DSP 31的RAM存储器31A中。将加密标题密钥(Kt)存储在设备存储器中消除了访问保护卡存储区域47的需要。这是重要的，因为与每次读取都访问保护区域47相比，它节省相当可观的时间和处理容量。这将在后面参照图9讨论。标题密钥Kt和拷贝控制信息CCI由LCM 63中的一系列加密模块75、77和79以及存储卡61上的模块81加密。介质唯一密钥Kmu由模块77使用。验证密钥交换(AKE)模块83组合由模块59’算出且存储在卡61的隐藏区域45中的介质唯一密钥Kmu，以生成由模块79和81均使用的会话密钥Ks。为了使利用设备65对记录加密内容解密，利用以相同标号但加有单撇号(’)表示的相应模块来执行加密过程的逆过程。
图7示出利用卡与某LCM或利用设备之间的验证和密钥交换(AKE)询问-答复(challenge-response)协议来访问存储卡的保护区域47的技术。当该验证成功时，卡和其他模块或设备共享安全公共会话密钥Ks。前述处理和协议的其他详情可以参考前面引用的4C团体文献。
图8A和8B示出被设计为在便携式设备或LCM中运行以便访问以前述过程加密的信息的软件系统的一个实施例。SanDisk软件，SW 100是一种完全总控(turn-key)软件解决方案，它允许OEM音乐播放器和记录器容易地支持安全介质包括安全数字(SD)存储卡。图中示出SW 100在便携式设备15内，从而访问SD卡13。SW 100也可以安装在任何许可遵循模块如个人计算机中。如图8A所示，在其最高层，SW 100从设备15，具体是设备15的用户接口，接收调用，从安全数字卡13中检索加密内容，并且将解密内容返回给设备。因此，只需要简单的调用，就可执行很多复杂的过程。检索存储在卡13的存储位置中的加密内容然后对内容进行解密和格式化的复杂过程由SW 100处理。
如前所述，执行对SD存储卡的验证区域的访问需要使用OEM必须从4C团体取得许可的机密设备密钥。保护这些密钥值并且限制它们暴露在SDK SW 100软件层内是软件设计中心考虑因素之一。将这些密钥(和其他结果值如会话密钥)隔离在单个内部模块内同时允许安全介质如SD存储卡的设备驱动程序执行依赖于这些值的操作以健壮和安全接口方法来实现。再次，使用SD存储卡来说明本发明；然而，本发明也能用于可以在卡内或者甚至是在远端存储设备中的任何安全介质如CD或其他安全存储器。
图8B更详细地示出SW 100的分层结构。音频接口105、视频接口110和图像接口115是与设备的通信点。这些接口提供设备的单个通信点，并且通常从设备接收简单命令，从而使设备无需卷入从安全介质获得加密数据然后对数据进行解密和处理的复杂过程。所有这些复杂过程均由SW 100处理。接口105、110和115还管理回放安排，例如管理播放列表以及如艺术家的图像与其歌曲或各播放列表的相关性。应用编程接口(API)130A驻留在命令调度器(CD)130内。CD 130和API 130A从接口105、110和115接收命令，将信息中转给接口，并且组织在SW100中发生的所有过程-与采用所有必需加密、解密和压缩算法回放和记录存储在安全介质上的内容相关的设备15的过程。
当从CD 130接收到指令时，SD音频引擎(SDAE)140、SD视频引擎(SDVE)150和SD图像引擎(SDIE)160分别处理驻留在安全介质上的音频、视频和图像内容。这意味着SDAE 140可以处理任何公知音频格式如AAC、WMA和MP3。同样，SDVE 150可以处理任何公知视频片断格式如WindoWs媒体文件、实时网络文件MPEG或任何其他公知类型的视频文件。最后，SDIE 160可以处理任何公知类型的图像文件如TIF、GIF、JPEG、位图等。各接口具有安全API(SAPI)和非安全API(NSAPI)。所处理的内容可以经过或可以不经过加密。加密内容通过SAPI 140A、150A和160A访问。这些SAPI与SanDisk安全管理器(SSM)180通信。必须处理安全内容的所有命令通过SSM 180来引导(channel)。安全数字安全引擎(SDSE)175处理所有加密和解密过程，它将在后面作更详细的描述。用来验证介质和对内容解密的密钥包含在SDSE 175内并且由其专门处理。驻留在卡上的未经加密内容通过NSAPI 140B、150B和160B访问。这些NSAPI与非安全文件接口(NSFI)170通信，从而访问介质上的未经加密内容。
为了在存储介质中读取或写入数据，NSFI 170和SDSE 175与设备驱动程序190通信。SD卡例子中的设备驱动程序190管理和驱动存储卡13的设备接口39触点的来往信号。设备驱动程序190将针对各种设备或介质的设备接口39的特定类型来裁剪。在存储卡设备的情况下，驱动程序190管理和驱动位于设备15上的触点的来往信号。在光介质的情况下，设备驱动程序190可以管理和驱动来自硬件组件包括光拾取单元的信号。可选地，在硬盘驱动器(hdd)的情况下，设备驱动程序190将管理和驱动所需hdd信号。设备驱动程序190包含安全设备驱动程序接口(SDDI)190A以及非安全设备驱动程序接口(NSDDI)190B。SDDI190A和NSDDI 190B在设备驱动程序190内相互隔离。SDDI 190A专门与SDSE 175通信，而NSDDI 190B专门与NSFI 170通信。
对SD-音频安全方案起中心作用的设备密钥和其他值居于一个受限安全软件模块即SD安全引擎(SDSE)175内。这些值的所有操纵只限于该模块。这些值从不传入或传出到SDSE 175以上的软件层。涉及这些密钥的安全服务的所有请求由屏蔽该安全模块的SSM 180控制和监视。在安全模块以下，SD存储卡设备驱动程序190执行安全访问。这些驱动程序服务的请求是通过仅对安全模块已知的私有驱动程序安全接口即安全服务驱动程序接口(SDDI)190A来作出的。SDSE 175使用该接口190A来执行特殊安全命令如获得介质密钥块(MKB)。非安全设备驱动程序接口(NSDDI)190B还利用设备驱动程序190来访问卡13的用户区域41中的任何未经加密文件。
SW 100架构的安全性在于其密钥的安全性。机密“软密钥”不长时间地存储在临时安全区域中，因为这增大对密钥以及加密内容泄密的可能性。SW 100利用在SDSE 175内动态生成所需密钥(或“软密钥”)并且当不立即需要这些特定密钥时删除它们的方案。
现在将更详细地描述SW 100的操作。SW 100，具体而言，命令调度器130/API 130A具有可以调用来执行特定功能的大量API例程。虽然存在很多例程，但是这些例程中只有22个由设备15进行外部访问。这些例程通过调用来访问，其中，调用也称作命令。为了检索存储卡(或其他介质)13中的内容，设备只需要发送22个调用之一，就将对内容进行检索、解密(如果必要)和解码。在音频的情况下，例如，设备只需要发送“播放”调用，音乐就将开始。
下列API允许应用通过接口与遵循安全数字(SD)标准的设备交互。虽然本发明的实现是以SD标准来说明的，但是本发明可以与很多不同标准一起使用。
表1-API例程/调用
现在将详细描述可以由设备15调用的主要API例程。将参考图8A-8E。
从图8C可以看出，存在预播放过程805和播放过程810。图8E的各块是在图8C的过程中创建的。相关API模块是通过设备15的用户接口调用时执行的。在音频回放的情况下，如图8B所示，模块调用是通过设备15的用户接口发送到音频接口105的。执行流程图中所列功能的主要调用/模块在右边示出。很多这些模块执行其他内部和外部访问模块，并且该列表不意味着是无遗漏的，但意味着对前面引作参考且形成本申请一部分的致密盘上的软件代码的参照。若要了解详情，请参考软件代码。
设备首先在步骤803加电，然后，预播放过程805开始。预播放过程包括两个主要阶段加电初始化阶段805.10和音频内容初始化阶段805.20。音频内容初始化阶段将参照图8D作更详细的描述。
一般而言，在预播放过程805中，对设备和介质进行初始化，并且从介质中读取来自介质的特定信息，并且存储在设备15的RAM存储器的缓冲区中。如前面图2所示，该RAM存储器可以是系统存储器27、DSP 31的RAM存储器31A或MCU 25的RAM存储器25A。在步骤805A，SW 100将获得介质的驱动器号。在一些应用中，可能存在多个存储卡或盘正被设备15访问。在该步骤，它将获得所有驱动器号，从而可以正确访问各驱动器上的内容。这是以API例程SdInitAudioSystem来完成的，并且可以由设备15调用或者可以由SW100内部调用作为预播放例程的一部分。然后，SW 100将初始化SW100内的SSM 180和SDSE 175。在可以处理来自介质的任何加密密钥和内容之前，这是必要的。SW 100还将初始化卡13中的播放列表和轨道管理器。
在步骤805B，SW 100将初始化并验证介质。在此所示的SD卡的情况下，将执行图5-7的MKB过程。该MKB过程也可以在步骤805A期间执行，并且如果先前执行过，则它将不在步骤805B再次执行。若要了解该过程的详情，请参见图5-7和前面引作参考的4C文档。该过程还将参照图10作更详细的讨论。在步骤805B，将从卡13中拷贝介质信息值，并且在设备13的RAM存储器中将其存储在图8E的介质信息块850的位置。这是以API例程SdMountAudio来完成的，并且可以由设备15调用或者可以由SW 100内部调用作为预播放例程的一部分。因此，播放列表一般信息(pTGInfo)、介质有效号(SanDisk)、驱动器号(drivenum)、介质的安全系统(security)以及介质的加载状态(mounted)的值将填充在它们各自的位置。然后，当通过任意数目的API调用来进行调用时，可以从设备15的RAM中顺序读取这些位置，而无需从卡13中读取它们。
在完成加电初始化805.10之后，音频内容初始化805.20开始。一般而言，在音频内容初始化805.20期间，将指定各个单独轨道和多个音频轨道(播放列表)的加密音频内容的位置和顺序的信息从卡(或其他介质)13拷贝到设备15的RAM内的小缓冲区中。这样，在图8E的块中示出的此信息可以在设备内快速且容易地访问，并且在随后的播放过程810期间不需要总是对卡13进行读取或更新。
参照图8D，将更详细地描述音频内容初始化阶段805.20。该阶段对存储卡(或其他介质)13上的加密内容创建大量充当本地路标(localroadmap)或目录的结构。
在步骤805C，设备15调用API模块SdGetPlayListCount。该调用和所有下面调用通常从设备15的用户接口软件发送到SW 100的接口模块之一。在音频回放的这一示例中，调用从用户接口发送到音频接口105。在视频回放的情况下，调用将发送到视频接口110，而在图像再现的情况下，调用将发送到图像接口115。然后，该调用中转给在API130A内包含API模块的命令调度器130。
在步骤805D，SdGetPlayListCount通过将来自卡13的信息拷贝到设备15的RAM存储器中来填充播放列表信息块860的值。它将通过参考介质信息块850来选择适当的经授权驱动器。所有经授权驱动器的播放列表的总数将拷贝到设备15的RAM中。
在步骤805E，设备15调用API模块SdGetPlayList。
在步骤805F，SdGetPlayList通过将来自卡13的信息拷贝到设备15的RAM存储器中来填充播放列表信息块860的值。它将通过参考介质信息块850来选择播放列表信息所在的适当经授权驱动器。以毫秒为单位的所选或缺省播放列表的总回放时间(pListTime)、播放列表中的轨道数(tracksInPlist)、对应于当前播放列表的索引号(index)、播放列表名称字符串长度(Length)以及播放列表名称(pListName)将分别填充到它们在播放列表信息块860中的各自位置。
在步骤805G，设备15调用API模块SdGetTrackInfo。
在步骤805H，SdGetTrackInfo通过将来自卡13的信息拷贝到设备15的RAM中来填充轨道信息块870的值。它将通过参考介质信息块850来选择播放列表信息所在的适当经授权驱动器。它将通过参考播放列表信息块860来选择各播放列表内的轨道。包括轨道中相关轨道单元(“TKI”)的以毫秒为单位的总轨道时间(trackTime)、包括相关TKI的以字节为单位的总轨道大小(bytesize)、轨道中的TKI数(tkisInTrack)、轨道数(tracknum)、对应于当前轨道的索引(index)以及来自介质的轨道信息(trkInformation)将填充到它们各自的位置。
在步骤805I，设备15调用API模块SdOpenTrack。
在步骤805J，SdOpenTrack通过将来自卡13的信息拷贝到设备15的RAM中来填充轨道一般信息块880的一些值。它将通过参考介质信息块850来选择适当驱动器，并且它将通过参考播放列表信息块860和轨道信息块870、以毫秒为单位的播放列表总回放时间(pListTime)、当前播放列表号(plistnum)、所要播放的轨道号(tracknum)、轨道的第一AOB块(firstAOB)和正被解密的当前AOB(currentAOB)，选择适当播放列表和轨道内的轨道。
在步骤805K，SdOpenTrack通过将来自卡13的信息拷贝到设备15的RAM中来填充轨道索引信息块875。它将通过参考介质信息块850和播放信息块860来选择播放列表信息所在的经授权驱动器，并且它将通过参考播放列表信息块860和轨道信息块870来选择适当播放列表内的适当轨道。
在创建轨道信息块870之后，在步骤805L，SdOpenTrack通过将来自卡13的信息拷贝到设备15的RAM中来填充轨道一般信息块880的剩余值。下面值将填充到它们在块880中的各自位置介质的验证号(SanDisk)、操作命令(CMD)、音频格式如MP3、AAC或WMA(audioformat)、编解码器采样频率(sampfreq)、应用属性例如音乐、图书等(appAttrib)、以字节为单位的音频对象大小(sizeAOB)、轨道的最后AOB块(lastAOB)、轨道的AOB总数(countAOB)、AOB中同步位置的当前位置(syncword)，也称作首标、AOB内的定位位置(seekposAOB)、以毫秒为单位的轨道消逝时间(trkElapsedTime)、以毫秒为单位的轨道总播放时间(trkTotalTime)、包括相关TKI的以字节为单位的总轨道大小(bytesize)、以毫秒为单位的各元素的播放时间(elementplaytime)、向前定位时间(fwTime)、到下一轨道的时间(fwNext)、播放列表中的轨道数(tracksInPlist)、当前元素大小(elementsize)、当前元素内的偏移(elementoffset)、AOB中的当前元素(currentelement)、AOB中的元素总数(totalelements)以及AOB的文件句柄(fdAOB)。在本发明的一个不同实施例中，步骤805J将完全填充轨道一般信息块880的值，并且将删去步骤805K。轨道索引信息块875是轨道一般信息块880的子集并且被设计为节省空间和处理时间。它意味着在它正浏览信息的情况下通过设备15的用户接口来参考。一旦用户接口选定一个特定轨道以进行回放，则将填充轨道一般信息块880包括包含在块875中的信息子集。
SdOpenTrack可以由设备15调用或者可以由SW 100内部调用作为预播放例程的一部分。
让块和块信息包含在设备的存储器中是一个优点，因为如果播放过程发生任何失败，则不需要对介质复位，即执行加电初始化805.10的步骤805A或805B。另外，在正常情况下不需要读取从卡13回放所需的信息。因为块850、860、870、875和880中的信息用作包含在下一帧中的内容的指针，所以这些块中的信息可以用来访问下一内容(音频、视频等)帧。图8E的各块详细示出如前面参照图3C所述构成位于存储卡13内的音频或视频轨道的文件、元素和帧在存储卡13内的位置。
步骤805的预播放过程可以通过很多调用来触发(括号中的编号表示表1中的调用)。如图8C所示，将触发音频内容初始化805.20的外部调用为SdOpenTrack、SdGetPlayListCount、SdGetPlayList和SdGetTrackInfo。SdOpenTrack(10)由SdNextTrack(12)、SdStopPlay(13)和SdResetPlayList(16)内部调用。API模块SdGetPlayListCount、SdGetPlayList和SdGetTrackInfo也可以由SdOpenTrack内部调用。通常，它将由设备15调用来用于如显示轨道时间、快退、快进、改变播放列表、改变图形用户接口显示或删除轨道的设备功能。一旦预播放过程805完成，则播放过程810可以开始。
在播放过程810中，将开始、停止或暂停一个或多个音频或视频轨道回放的调用在步骤810A通过图8B的音频接口105、视频接口110或图像接口115接收。这些调用在图8C中列在播放过程810的旁边，它们为SdPlayTrack、SdNextTrack、SdStopPlay、SdPauseTrack、SdResumeTrack、SdResetPlayList、SdForward、SdAddTKItoPLM、SdDelTKItoPLM、SdDelTKItoTMG、SdConvertMP3ToSA1和SdConvertAACToSA1。
不管是在内部还是当由设备调用时执行多少API模块，要播放音频轨道，将总是需要两个主要模块。这两个模块就是SdOpenTrack(10)和SdPlayTrack(11)。SdOpenTrack(10)和SdPlayTrack(11)将读取轨道一般信息块880中的信息，从而访问存储卡13的簇存储位置的加密内容。
SdOpenTrack(10)由SdNextTrack(12)、SdStopPlay(13)和SdResetPlayList(16)内部调用。通常，它将由设备15调用来用于如显示轨道时间、快退、快进、改变播放列表、改变图形用户接口显示或删除轨道的设备功能。
SdPlayTrack(11)是播放音乐或视频轨道的核心API。通常，当用户想要播放当前轨道、下一轨道时或者当他想要在轨道内快进或快退时，设备使用该API。它由如SdNextTrack(12)、SdResumeTrack(15)和SdForward(17)的其他API调用。SdPlayTrack查找所选轨道的AOB，检查音频格式(MP3、AAC或WMA等)，并且对轨道进行解码。
参照图8B、9和10，现在将描述加密轨道的回放，图8C的步骤810B。
如果需要加密内容，则从需要使用OEM的4C许可设备密钥的设备15和SW100发出命令或向其发出命令。这些密钥的所有处理仅限于居于SSM 180之下的SDSE 175。如果请求非安全或非加密内容，则NSFI 170和NSAPI 140B、150B和160B以及NSDD 190B将访问该内容。
当SSM 180接收安全服务请求时，它通过将命令请求分组传到SDSE 175内的process_security函数来对其执行。密钥值从不包含在请求分组内或者暴露在SDSE 175以上的软件层。
当SDSE 175内部需要时，通过对OEM提供库的函数调用来检索设备密钥。SDSE 175的库security.lib包含下列API，它们被设计为减少解密密钥驻留在系统的安全区域中的时间1)SEC_AKE API；2)SEC_ENC_TKEY API；3)SEC_DEC_TKEY API；4)SEC_GETCCI API；5)SEC_UPDATECCI API。
SW 100的功能和结构在本申请的正文中有描述，更具体地说，图9的流程图示出上面API 1-5的功能。图中这些API在它们所实现的相应功能旁边示出。实现这些API以及所有SW 100的详情可以参见在本申请的附件中提交的源码。
一旦获得，设备密钥就与来自SD存储卡的介质密钥块(MKB)组合以形成“介质密钥”。该值保存在SDSE 175内以用于处理随后的请求。然而，注意，“介质唯一密钥(Kmu)”从不保留在SDSE 175内。形成所有安全访问基础的该值总是实时地计算(并且从不缓存)作为额外的安全防范措施。在SDSE 175内处理密钥的详细描述如下。
加密过程笼统地被设计为防止未经授权拷贝安全介质上的内容。存在本发明的很多方面来实现此目的。首先，从不一次对整个文件例如一首歌曲进行解密，并且将其存储在存储器中，在此，它可能容易遭受未经授权的拷贝。便携式设备分配一个缓冲区，并且SDSE 175一次读取多个加密内容分段，对它进行解密，然后反复覆写相同的缓冲区，直到文件的结束。
如图6和7所示，介质唯一密钥(Kmu)和标题密钥(Kt)是最终用来对内容进行解密的密钥。存在很多方法来保护标题密钥。其中一种是将密钥存储在设备15的非常安全区域中，另一种是每次读取加密缓冲区并对其解密时，从卡13的保护区域47中读取标题密钥。图9是示出此优选方法的流程图。
回到图9，在步骤205，读取如图4所示为64k字节的MKB映象，以如图6所示处理介质密钥(Km)，从而产生介质唯一密钥(Kmu)。该步骤将在后面将要描述的图10中详细示出。在步骤205完成设备与介质的相互验证之后，经过AKE过程以产生仅在那个会话(有效时长为设备处于打开或活动状态)期间才可使用的会话密钥(Ks)。AKE过程可以再次参见图6。在步骤213，删除介质唯一密钥(Kmu)。在步骤215，使用会话密钥(Ks)来对存储在存储卡13的保护区域47中的双重加密标题密钥E(E(Kt))进行解密。结果是单重加密标题密钥(E(Kt))。在步骤220，将该加密标题密钥(E(Kt))存储在设备15的存储器中。(E(Kt))可以存储在系统存储器27、MCU 25的RAM存储器25A或DSP 31的RAM存储器31A中。标题密钥Kt特定于每个标题，在音频领域内称作轨道，并且在图9中用来说明本发明。每个轨道均可以由多个文件组成，例如，在长的经典歌曲的情况下。对于大视频片断，一个标题可以包括很多文件。因此，对于所有随后对该轨道的加密内容的读取和解密，都不需要从存储卡中检索标题密钥，因为它存储在本地存储器中，并且可以节省宝贵的时间和计算资源，同时为安全的目的标题密钥保持加密。
在步骤225，回放轨道的一部分。该部分可以在组成轨道的任一文件中。在步骤225a，再次计算介质唯一密钥(Kmu)。在步骤225b，对存储在本地存储器中的加密标题密钥进行解密。然后，在步骤225c，使用标题密钥来对来自便携式设备15的缓冲区的内容进行解密，其中，来自便携式设备15的缓冲区包含来自存储卡13的用户区域41的内容。在对缓冲区解密之后，立即在步骤225d删除标题密钥，并且在步骤225e删除介质唯一密钥。步骤225d和步骤225e的次序是不重要的，但是这两个密钥仅在读取轨道的一部分所花时间内暴露是重要的。该部分可以是来自任何地方的1秒到约10秒回放(解密、解压缩和解码)内容(音频或其他)的片断。最好，它为两秒。读取一部分所花时间依赖于很多因素包括设备的处理速度和缓冲区大小。如上所述，SW 100可以由MCU 25或DSP 31执行，并且存储在设备15的存储器27、25A、31A或32中的任一个内，因此，处理时间可以变化。如步骤230所示，重复这一过程直到读完轨道的所有部分。一旦读完所有部分，则如果继续回放，系统就可以移到下一轨道，如步骤235所示。这可能是例如用户已选择播放整个播放列表的情况。
当读完轨道的所有部分并且开始读取下一轨道时，过程将在步骤215再次开始，并且将从存储卡13的保护区域47中检索下一双重加密标题密钥。这通常是用户设定设备在运转中播放包括多个轨道的整个播放列表的情况。如果会话关闭(即，设备15已被打开或关闭)，则将必须生成新会话密钥，并且过程将在步骤210开始。如果移走或新插入存储卡，则将必须重新验证设备和介质，并且过程将在步骤205再次开始以读取轨道。
图10描述处理介质密钥块的操作，上述图9的步骤205。如图4所示，MKB映象49的长度为64K字节。一次读取整个映象49来计算MKB将是低效的，这将需要大量RAM和长处理时间。本系统减少RAM需求并且减少处理时间。MKB映象49分为分段1到128。每个分段为512字节，并且可以包含四种不同类型的MKB记录之一验证介质密钥记录(VMKR)，以0x81表示；计算介质密钥记录(CMKR)，以0x01表示；条件计算介质密钥记录(CCMKR)，以0x82表示；或结束介质密钥记录(EMKR)，以0x02表示。这些记录在前面引用的4C团体的可记录介质的内容保护(CPRM)规范中有描述。
在本例中，分段长度和缓冲区长度是相同的。然而，缓冲区长度和分段长度的范围可以从256字节到4096字节。检查每个记录以根据记录类型执行特定操作，并且保存特定数据以在后面获得介质密钥。每次识别出一个记录时，将记录长度加到缓冲区偏移的总长度。分段号通过将总长度除以分段长度来计算。分段号是所选分段数据在介质密钥块内的索引。总长度的余数是所选分段数据内的偏移。行和列用来计算加密介质密钥和条件加密介质密钥的位置。保存那些加密密钥，并且执行采用电子码本模式算法的解密C2加密，以获得介质密钥。然后，验证该介质密钥以获得正确的最终介质密钥(Km)。
逐MKB分段地从MKB中获得介质密钥(Km)的读取次数T与记录数之间的关系如下所示记录数＜T＜(记录数*2)T访问MKB分段所需的次数。
每个记录具有不同的长度和数据值。每个记录的信息可以在两次读取内获得。由于存在四个记录，处理MKB分段并获得记录需要4到8次读取。
因此，读取次数T为4＜T＜8假定花费N毫秒访问512字节MKB数据，则采用第一方法将花费(128*N)毫秒访问整个64K MKB映象来获得介质密钥。而采用第二方法在最坏的情况下也只花费(8*N)毫秒来获得介质密钥。因此，使用该方案将节省相当多的时间。平均起来，要获得介质密钥(Km)，读取次数的范围为4到6，并且所需时间按比例将少于上述时间。
图10拓展图9的步骤205，执行这一步骤，直到在步骤205.75产生最终介质密钥或者在步骤205.80拒绝介质。为计算介质密钥，并不需要读取所有128个分段，并且不需要读取每分段的所有512字节。处理MKB数据是需要一次请求一个数据分段，指向那个特定分段内的所需位置并且计算获得值的操作。并不需要所有MKB数据。图10所示的算法将提供数学计算来准确算出需要哪个MKB数据，应处理哪个记录以及加密数据位于何处。
在步骤205.5，将缓冲区指针设到数据缓冲区，并且清除缓冲区偏移。下一步，在步骤205.10，检查分段号以查看它是否等于或大于最大分段号。如果是，则在步骤205.15返回错误。如果否，则在步骤205.20，增加分段号，并且将新数据载入到缓冲区中。然后，在步骤205.25更新缓冲区偏移。这样，指针可以设到正确位置(分段号加上偏移)。在步骤205.30，缓冲区指针设到缓冲区偏移。在步骤205.40，以指针所在偏移开始读取缓冲区。然后，系统判定它正在读取什么类型的记录。如步骤205.40所示，系统首先检查正在读取什么类型的记录，以及什么记录长度与那个记录相关联。随后的操作依赖于记录类型和长度而不同。每个记录的记录长度将用来判定读取随后记录时缓冲区指针应位于何处。这由步骤205.49来反映，从而更新缓冲区指针并且将缓冲区指针设在新偏移。
如果在步骤205.42表示记录为CMKR，则在步骤205.49系统更新缓冲区分组号和偏移到加密介质密钥(Km)所在的正确MKB位置。每个卡具有16MKB。因此，系统将获得加密介质密钥所在的偏移，进入特定MKB分段号，分配缓冲区(16块×512字节)，并且进入各块内的偏移以读取加密介质密钥。然后，在步骤205.50，系统使用从设备15提供的设备密钥(Kd)来解密(计算)介质密钥。一旦算出介质密钥，则下一步骤是验证介质密钥。
如果在步骤205.44判定记录为VMKR，则在步骤205.55，比较先前在步骤205.50的第一尝试或步骤205.65的随后尝试中算出的介质密钥与参考介质密钥(Km)。为了完成此操作，将首先本地存储参考介质密钥。如果密钥相同，则将返回“通过”，用十六进制表示为DEADBEEF，并且系统将不需要有条件地计算介质密钥。为了算出在何处开始读取下一记录，使用VMKR的记录长度来将缓冲区指针移到下一记录。如果不相同，则在步骤205.46当读取CCMKR记录时对它进行再次计算。当读取该记录时，在步骤205.49设定缓冲区指针以在更新缓冲区偏移读取之后，将在步骤205.65再次计算介质密钥，然后，当读取下一VMKR时将对它进行验证。计算CCMKR的最大次数可以由系统设置，并且最好设为1。
第一次计算发生在发现CMKR时。如果当发现VMKR时开始的验证过程期间判定计算成功，则将不需要有条件地计算介质密钥(Km)。如果验证不成功，则当发现CCMKR时将重新计算并重新验证介质密钥(Km)。这意味着存在两次机会来计算介质密钥。最后，如果在步骤205.48判定记录为EMKR，则在步骤205.49为这种记录将缓冲区指针设在正确的偏移之后，系统将在步骤205.70验证在记录的结束是否存在有效介质密钥(Km)，并且将在步骤205.75产生最终介质密钥(Km)。然而，如果在步骤205.70没有返回有效介质密钥，则将在步骤205.80拒绝介质。如果在步骤205.70返回最终介质密钥，则处理将在图9的步骤210继续，如步骤205.85所示。这样，MKB处理完成。
SDSE 175内的函数通过使用对设备驱动程序190的安全设备驱动程序接口(SDDI)190A来执行安全访问如获得MKB。该同一设备驱动程序SDDI 190A也使用它可以直接调用的SDSE 175内的函数。例如，在发出验证区域读取操作之前，SDDI 190A必须首先调用SDSE 175内的sec ake函数。sec ake函数将反过来回调到SDDI 190A中。该“双向调用关系”有助于隔离SDSE 175内的设备密钥，并且独特于SD音频标准的SW 100实现。
由于SDSE 175处理所有面向密钥的处理，并且当通过音频接口105、视频接口110或图像接口115接收特定SD命令时需要这些值，因此设备驱动程序必须使用它可以直接调用的SDSE 175内的函数。当执行这些函数时，SDSE 175必须反过来回调到设备驱动程序190的私有安全接口SDDI 190A中。该“双向调用关系”允许SDSE 175与设备驱动程序190之间的交织请求，因此允许密钥值隔离在安全模块内。
SDSE 175软件层通过发起安全驱动程序请求分组和调用传递请求分组指针的安全驱动程序接口入口点来经由私有接口调用安全设备驱动程序服务。
为了阐明引作参考的所附源码，提供下面表。
请求分组(在sdapi.h中定义)由如下定义的数据类型SSMSERVE组成
表2
命令索引(INI16 opCode)保存正被请求服务的命令。支持命令包括表3
安全设备驱动程序服务请求从SDSE 175模块发出。例如，生成询问1函数发送如下的询问1表4生成询问1
由于所有密钥操纵均局限于SDSE 175，因此SDDI 190A必须依赖于SDSE 175函数来执行验证密钥交换(AKE)或对跨总线传输的数据进行解密(注意，跨总线发送的所有数据首先使用从各AKE生成的“会话密钥”来加密。)当执行AKE时，SDSE 175必须将命令发送到存储卡13，因此，它必须反过来调用到SDDI 190A中。该调用关系已在示出处理验证区域读取所需的步骤的图7中概述过。
注意，当由安全SDDI 190A调用时，SDSE 175内的sec_ake函数通过私有接口执行四个对安全设备驱动程序的回调。这四个请求包括SDDRV_SETCHALGE、SDDRV_GETCHALGE、SDDRV_SETRESP和SDDRV_GETRESP。这就允许安全模块执行图7所示的必要设置询问/获得询问、设置答复/获得答复步骤。结果会话密钥存储在安全模块内。当安全设备驱动程序回调到SDSE 175的bus_decrypt函数中以从SDDI 190A获得信息时，这用来对数据进行解密。本发明的系统和方法在很多方面优于现有技术。本发明提供一种用于原始设备制造商的总控解决方案，它用来访问加密内容而无需具有存储介质的存储结构的任何知识。解密过程本身是非常复杂的。而且，对存储卡或致密盘进行简单读写本身也是复杂的。不管是什么设备，制造商需要做的全部操作是发送简单命令如“播放”或“下一轨道”并且从设备返回解密内容。
设备密钥和结果会话密钥是在非常隔离和保护的软件层中操纵的。这些从不在高层暴露。即使是较低设备驱动程序层也不能直接访问密钥。当生成介质密钥时，从OEM提供库中检索设备密钥。该密钥保留在安全引擎内，但是从不存储作为安全方案核心的介质唯一密钥(Kmu)。安全引擎的私有接口允许安全引擎实现对存储卡的低层访问，同时保持所有安全相关密钥(例如，设备密钥、介质密钥、会话密钥)的暴露局限于安全引擎以内。“双向调用关系”允许安全引擎和安全设备驱动程序相互交织使用对方的服务。
尽管描述了本发明的具体实施例及其优点，但是应该理解，在不脱离由所附权利要求限定的本发明的精神和范围的情况下，可以对其进行各种修改、替换和变更。例如，虽然为说明本发明的功能而示出使用SD存储卡，但是本发明也可以用于任何具有加密内容的介质。它还可以由任何类型的设备利用。而且，可以从任何类型的存储设备中对加密内容进行解密，不管它是固定的还是可移动的，以及它是固态还是旋转的。内容不限于音频或视频，而可以是任何值得加密的内容。
权利要求
1.一种由设备的原始设备制造商用于音频或视频设备中的软件程序，其中，设备用于回放驻留在存储卡上的加密音频或视频内容，所述软件程序被配置为从设备的用户接口接收命令包括回放命令；对来自存储卡的加密音频或视频内容进行解密，从而使原始设备制造商只需将回放命令从设备的用户接口发送到软件程序就回放解密音频或视频。
2.如权利要求1所述的软件程序，其中，软件程序还被配置为将加密内容的位置信息拷贝到音频视频设备的存储器中；从音频视频设备的存储器中访问位置信息；以访问位置信息定位存储卡内的加密内容。
3.如权利要求1所述的软件程序，其中，对音频或视频内容进行解密包括将来自存储卡保护区域的一个或多个加密密钥拷贝到设备的存储器缓冲区中；将来自存储卡的加密音频或视频内容拷贝到设备的存储器缓冲区中；对所述一个或多个拷贝加密密钥进行解密；以所述一个或多个解密密钥对拷贝加密音频或视频内容进行解密。
4.如权利要求3所述的软件程序，还包括在对音频或视频内容解密之后，立即删除所述一个或多个解密密钥。
5.如权利要求4所述的软件程序，其中，在删除所述一个或多个解密密钥之前，以所述一个或多个解密密钥一次对约少于1至10秒的内容进行解密。
6.如权利要求4所述的软件程序，其中，在删除所述一个或多个密钥之前，以所述一个或多个解密密钥一次对约2秒内容进行解密。
7.如权利要求1所述的软件程序，其中，对音频或视频内容进行解密包括(a)计算介质唯一密钥；然后(b)以介质唯一密钥对存储在设备的存储器中的标题密钥进行解密；然后(c)对一组帧进行解密；然后(d)删除解密标题密钥；(e)删除介质唯一密钥；以及(f)重复(a)至(e)直到整个轨道完成。
8.一种具有微处理器、随机访问存储器和由微处理器执行的软件程序的便携式设备，所述设备被配置为从便携式设备的用户接口接收一组命令包括回放命令；当接收到命令时，检索驻留在可移动存储介质中的加密数据；将加密数据存储在设备的存储器中；对数据进行解密；以及输出解密音频或视频内容，从而使设备只需将命令组中的一个命令从用户接口发送到软件程序就输出解密音频或视频内容。
9.如权利要求8所述的便携式设备，其中，约两秒加密数据存储在设备的存储器中，然后在删除之前进行解密。
10.如权利要求8所述的便携式设备，其中，可移动存储介质为固态存储卡。
11.如权利要求8所述的便携式设备，其中，可移动存储介质为光盘。
12.如权利要求8所述的便携式设备，其中，设备软件还被配置为对采用AAC、MP3或WMA格式的音频内容进行解压缩和解码。
13.如权利要求8所述的便携式设备，其中，设备软件还被配置为将来自可移动存储介质的播放列表信息和轨道信息拷贝到设备的存储器中；以及根据设备存储器内的播放列表和轨道信息，定位所要检索的加密数据。
14.如权利要求13所述的便携式设备，其中，轨道信息对于每个轨道包括轨道所包括的音频对象数；轨道所包括的第一音频对象；轨道所包括的最后音频对象；正被解密的当前音频对象；以及当前音频对象的偏移。
15.如权利要求14所述的便携式设备，其中，轨道信息还包括以字节为单位的轨道大小；轨道的总回放时间；轨道的消逝时间；音频对象内的当前元素号；所要播放的轨道当前元素；当前元素的偏移；音频对象中的元素总数。
16.一种通过设备播放存储在安全介质中的加密音频或视频内容的方法，所述方法包括预播放过程包括将关于所要回放的轨道的一个或多个信息组拷贝到设备的存储器中；播放过程包括从用户接口接收多个命令以开始回放；从设备存储器中访问所述一个或多个信息组；根据拷贝到RAM存储器中的所述一个或多个信息组中的信息，按照顺序将来自安全介质的加密内容拷贝到设备的存储器中；根据所述一个或多个信息组中的信息，顺序地对来自安全介质的加密信息进行解密。
17.如权利要求16所述的方法，其中，一次拷贝和解密约少于1至5秒加密内容。
18.如权利要求16所述的方法，其中，所述一个或多个信息组包括播放列表和轨道信息。
19.如权利要求16所述的方法，其中，所述一个或多个信息组指定要播放哪个播放列表，要播放播放列表内的哪个轨道。
20.如权利要求19所述的方法，其中，所述一个或多个信息组还包括要播放轨道内的哪个音频对象以及音频对象位于安全介质内的何处。
21.如权利要求20所述的方法，其中，所述一个或多个信息组还包括要播放音频对象内的哪个元素以及要播放元素内的哪个帧。
22.如权利要求16所述的方法，其中，预播放过程还包括对安全介质授权。
23.一种系统，允许便携式设备访问存储设备上的加密音乐，包括一个或多个应用编程接口，被配置为从便携式设备的用户接口接收多个命令；将命令发送到隔离安全引擎，隔离安全引擎被配置为从应用编程接口接收命令；将来自存储设备的加密密钥和加密内容拷贝到便携式设备的存储器；对密钥进行解密；使用解密密钥对内容进行解密；然后删除解密密钥。
24.一种允许具有处理器和随机访问存储器的设备通过一组命令容易地从存储卡中访问加密数据的方法，所述方法包括从存储卡中检索播放列表信息，并且将该信息存储在设备的随机访问存储器中；从存储卡中检索轨道信息，并且将轨道信息存储到设备的随机访问存储器中；从设备接收从命令组中选择的命令，其中，所述命令从随机访问存储器中访问播放列表信息和轨道信息两者；通过根据访问信息检索存储在存储卡内的加密数据并且对数据进行解密来执行命令。
25.如权利要求24所述的方法，其中，播放列表信息包括播放列表名称；播放列表名称字符串长度；播放列表的回放时间；播放列表所包括的轨道；以及对应于播放列表的索引。
26.如权利要求24所述的方法，其中，轨道信息包括轨道号；对应于轨道号的索引；轨道中的轨道单元数；以及轨道的回放时间。
27.如权利要求24所述的方法，其中，轨道信息包括轨道的格式类型；轨道的采样频率；以字节为单位的轨道大小；以及正被解密的当前轨道。
28.如权利要求27所述的方法，其中，一般轨道信息还包括轨道所包括的音频对象数；轨道所包括的第一音频对象；轨道所包括的最后音频对象；正被解密的当前音频对象；以及当前音频对象的偏移。
29.如权利要求27所述的方法，其中，对数据进行解密包括将来自存储卡保护区域的一个或多个加密密钥拷贝到设备的存储器缓冲区中；将来自存储卡的加密音频或视频内容拷贝到设备的存储器缓冲区中；对所述一个或多个拷贝加密密钥进行解密；以所述一个或多个解密密钥对拷贝加密音频或视频内容进行解密。
30.如权利要求27所述的方法，其中，对数据进行解密包括(a)计算介质唯一密钥；然后(b)以介质唯一密钥对存储在设备的存储器中的标题密钥进行解密；然后(c)对一组帧进行解密；然后(d)删除解密标题密钥；(e)删除介质唯一密钥；以及(f)重复(a)至(e)直到整个轨道完成。
31.一种允许设备访问安全介质上的内容的软件系统，包括一个或多个用户接口模块，用于从设备接收命令；应用编程接口，用于从用户接口模块接收命令，并且管理检索和存储来自安全介质的加密和非加密内容；安全引擎，用于对从安全介质发送到设备存储器的加密内容和加密密钥进行解密，解密密钥用来对加密内容进行解密；并且其中一个或多个密钥包含在第一加密数据段中，并且加密内容包含在第二加密数据段中，并且安全引擎对第一数据段的一部分进行缓冲和解密，对第二数据段进行缓冲和解密，然后在解密之前删除经过解密的一个或多个密钥，从而使解密密钥在对少于1至约5秒内容进行解密所花的时间内处于解密状态。
32.如权利要求31所述的软件系统，其中，密钥在对约2秒内容进行解密和处理所花的时间内处于解密状态。
33.如权利要求32所述的软件系统，其中，内容以AAC、MP3或WMA的形式来编码。
34.如权利要求31所述的软件系统，其中，所缓冲和解密的第一数据段的所述一部分约为512字节。
全文摘要
一种用于原始设备制造商的安全软件包，它在电子设备中运行，以便从存储设备如存储卡、光盘或硬盘中对加密音频、视频或其他内容进行访问和动态解密，从而使设备的用户接口只需发送简单的命令就输出解密内容。
文档编号H04N5/913GK1720578SQ01822009
公开日2006年1月11日 申请日期2001年11月6日 优先权日2000年12月7日
发明者巴哈曼·卡瓦米, 法施德·萨柏特－沙基, 罗伯特·C·常 申请人:三因迪斯克公司