从非易失性存储卡、光盘或其它介质重放所记录的音频、 视频或其它内容的系统、方法和器件 相关申请的交叉参考
本专利申请涉及2000年12月7日申请的题为“SECURESOFTWARE SYSTEM FOR PLAYING BACK RECORDED AUDIO，VIDEO OR OTHER CONTENT FROM NON-VOLATILE MEMORYCARDS，COMPACT DISKS OR OTHER MEDIA(用于从非易失性存储卡、光盘或其它介质重放所记录的音频、视频或其它内容的系统、方法和器件)”的美国临时专利申请60/251731，并要求此专利申请的优先权，而且，本申请涉及与本专利申请同一天申请并与本专利申请具有相同发明人的题为“SYSTEM，METHOD，AND DEVICE FORPLAYING BACK RECORDED AUDIO，VIDEO OR OTHERCONTENT FROM NON-VOLATILE MEMORY CARDS，COMPACTDISKS OR OTHER MEDIA(用于从非易失性存储卡、光盘或其它介质重放所记录的音频、视频或其它内容的系统、方法和器件)”的美国专利申请，后者的代理卷号为M-9913US。
在根据37 CFR1.52的光盘上提供源代码，作为包含以下文件的附录，每一个文件的全部内容都在此引作参考，这些文件为：
Sd_security\Sd_oem\Makefile，11/05/01，2KB；
Sd_security\Sd_oem\Readme，11/05/2001，3KB；
Sd_security\Sd_oem\Sd_oem.c，11/05/2001，6KB；
Sd_security\Sd_oem\Sd_oem.h，11/05/2001，1KB；
Sd_security\Sd_oem\Sd_oem.inc，11/05/2001，1KB；
Sd_security\Sd_oem\Sdtypes.h，11/05/2001，3KB；
Sd_security\Sd_oem\vssver.scc，11/05/2001，1KB；
Sd_security\Security\Tstsampl\Dotest.c，11/05/2001，8KB；
Sd_security\Security\Tstsampl\Makefile，11/05/2001，4KB；
Sd_security\Security\Tstsampl\Readme，11/05/2001，3KB；
Sd_security\Security\Tstsampl\Regress.c，11/05/2001，26KB；
Sd_security\Security\Tstsampl\Sdls.c，11/05/2001，10KB；
Sd_security\Security\Tstsampl\Sdrm.c，11/05/2001，5KB；
Sd_security\Security\Tstsampl\Securmmc.c，11/05/2001，6KB；
Sd_security\Security\Tstsampl\Tstsampl.inc，11/05/2001，1KB；
Sd_security\Security\Tstsampl\vssver.scc，11/05/2001，1KB；
Sd_security\Security\Err.h，11/05/2001，1KB；
Sd_security\Security\Fsentry.c，11/05/2001，7KB；
Sd_security\Security\keyInfo.h，11/05/2001，84KB；
Sd_seeurity\Security\Makefile，11/05/2001，3KB；
Sd_security\Security\Readme，11/05/2001，4KB；
Sd_security\Security\Scdrv.c，11/05/2001，29KB；
Sd_security\Security\Scdrv.h，11/05/2001，5KB；
Sd_security\Security\Scfs.c，11/05/2001，13KB；
Sd_security\Security\Scfs.h，11/05/2001，4KB；
Sd_security\Security\Sdsec.h，11/05/2001，5KB；
Sd_security\Security\Sdsys.c，11/05/2001，2KB；
Sd_security\Security\Security.c，11/05/2001，64KB；
Sd_security\Security\Smanager.c，11/05/2001，7KB；
Sd_security\Security\Smanager.h，11/05/2001，2KB；
Sd_security\Security\Ssmapi.c，11/05/2001，3KB；
Sd_security\Security\vssver.scc，11/05/2001，1KB；
Sdaudlib\HostFunc.c，11/05/2001，3KB；
Sdaudlib\Inpoutp.c，11/05/2001，1KB；
Sdaudlib\mssccprj.scc，11/05/2001，1KB；
Sdaudlib\plmInfo.h，11/05/2001，16KB；
Sdaudlib\Sd_plm.h，11/05/2001，5KB；Sdaudlib\Sd_tkm.h，11/05/01，4KB；
Sdaudlib\Sd_types.h，11/05/2001，2KB；
Sdaudlib\Sdapi.h，11/05/2001，2KB；
Sdaudlib\Sdaudapi.c，11/05/2001，91KB；
Sdaudlib\Sdaudapi.h，11/05/2001，8KB；
Sdaudlib\Sdaudapi.dsp，11/05/2001，4KB；
Sdaudlib\Sdaudapi.dsw，11/05/2001，1KB；
Sdaudlib\vssver.scc，11/05/2001，1KB。
【技术领域】
本发明一般地和具体地涉及从存储卡、光盘或其它介质安全地重放数字音频、视频或其它内容。
背景技术
考虑到音乐的非法拷贝，在因特网上通过其它通信系统或通过零售店来电子分配受版权保护地音乐的潜力受到限制。对于其它音频、视频内容，情况也是如此。所述内容一般以加密的形式提供给最终顾客，并且，顾客把加密内容记录到一些存储介质上，如个人计算机存储器、便携式播放器的存储器、可写光盘(CD)或非易失性存储卡。内容提供商希望消除内容非法拷贝的可能性，但却不得不满足于采取措施使发生拷贝的次数最小化。这包括对记录介质上的内容提供保护。在此描述对储存在非易失性存储卡上的内容的保护作为具体实例，但相同的内容保护技术也可应用到光盘或其它可记录介质。
现在有几种适合商业上可得到的作为内容数据存储介质的非易失性存储卡。一种是CompactFlash(CF)卡，另一种是MultiMediaCard(MMC)，还有一种是与MMC卡密切相关的Secure Digital(SD)存储卡。从本专利申请的受让人SandiskCorporation of Sunnyvale，California可得到有各种存储容量的所有这三种卡以及其它的存储卡。在“The MultiMediaCard SystemSpecification”中给出MMC的物理和电气规范，“TheMultiMediaCard System Specification”由MultiMediaCardAssociation(“MMCA”)of Cupertino，California经常更新和出版。此规范的版本2.11和2.2的日期分别为1999年6月和2000年1月，在此特别引作参考。MMC产品也在Sandisk Corporation于2000年4月出版的“MultiMediaCard Product Mannual”修订本2中描述，此手册在此特别引作参考。MMC产品电气操作的一些方面在Thomas N.Toombs和Micky Holtzman于1998年11月4日申请的共同未决的专利申请09/185649和09/186064中也有描述，这些专利申请转让给Sandisk Corporation。在转让给Sandisk Corporation的美国专利申请6040622中描述物理卡结构及其制造方法。这些专利申请和专利在此也特别引作参考。
较新的SD卡与MMC卡相似，具有相同的平面图。它们之间的主要差别在于SD卡包括辅助数据触点，以使数据在卡和主机之间传输更快。SD卡的其它触点与MMC卡的相同，以使设计成容纳SD卡的插槽也可容纳MMC卡。与SD卡的电气接口在极大程度上被进一步制作成与在上述引用的2.11版本规范中描述的MMC产品向下兼容，从而主机操作几乎不作改变就可接纳两种类型的卡。在2000年8月17日申请的共同未决的专利申请09/641023中描述SD卡的电气接口及其操作，该专利申请的全部内容在此引作参考。
【发明内容】
加密内容难以访问，并且包含加密内容的存储卡或光盘中的每一个都具有特定的结构，此特定结构要求特定的命令和例行程序来访问加密的和未加密的内容。本发明的软件是一个简单的解决方案，任何原始设备制造商(OEM)可在许多不同类型的具有许多不同类型微处理器的器件上安装和运行此软件。这些器件的范围从个人计算机到便携式器件，到汽车立体声音响，并且包括任何可从其访问加密内容的器件。便携式器件可以是便携式音频播放器或蜂窝电话或便携式管理器或通常是任何由微处理器控制的便携式器件。存储介质可以是闪存或任何类型的可记录盘。所述器件具有简单的或功能强的微处理器，并具有小容量或大容量的存储器。为了加密目的，所述软件利用并且只需要小的缓冲器，而且所述软件设计成即使在处理功率和存储器受限制的环境下也能有效运行。所述软件可以由任何类型的通用微处理器、专用微处理器如DSP、或ASIC运行。另外，所述软件要求计算的部分，如加密和解密(安全)引擎可由DSP执行，同时，所述软件的其它部分可由另一微处理器或ASIC执行。
所述软件具有接收命令的音频、视频和图象接口，其中，所述命令用于各类文件中的每一个。这些接口可组织重放和记录，包括管理播放列表和其它方便的特征。因而无论是什么器件，它只需向接口发送命令，所述软件则承担从安全介质读或写数据，并且在音频、视频或图象引擎内对任何已知的音频、视频或图象文件格式的数据进行解码和解压缩。
在非常难以访问的孤立模块内进行加密和解密，因而避免未授权的人访问加密密钥而从介质或器件拷贝文件的任何企图。内容只在小部分内加密，并且动态密钥产生和删除的方法使解密密钥的暴露最小化。
【附图说明】
图1示出用于在安全介质上读和写信息的器件。
图2为用于访问安全介质的器件的示意图。
图3A抽象地示出安全介质的层。
图3B示出安全介质存储单元的物理和逻辑结构。
图4示出分解成组件组块的介质密钥块(MKB)图象。
图5示出验证和解密过程的一部分。
图6示出验证和加密过程。
图7为图6所示验证密钥互换过程的示意图。
图8为示出本发明软件的模块的框图。
图9为根据本发明的概述音频轨道重放的流程图。
图10为图4所示MKB图象的处理的流程图，其中，MKB图象处理是图9中的一个步骤。
【具体实施方式】
参照图1，描述对音频内容如音乐采取内容保护的示例性系统。如图所示，主机11可以是个人计算机(PC)，位于零售店内的亭子分配音乐或其它内容等。在此实例中使用SD存储卡13储存音乐。卡13可插入到应用器件中，在此情况下应用器件为便携式器件(PD)15，PD15用电池工作，通过个人耳机播放记录在卡13上的音乐或其它音频内容。当卡13插入到器件15中时，通过把器件15连接到主机11，如借助计算机通用串行总线(USB)连接17，音乐可储存到卡13上。可替换地，如果播放器15不具备把内容记录到卡13上的功能，或者如果不希望有此功能，卡读/写器19就可通过USB连接21连接到计算机，并把卡13插入到其中而在卡上记录音乐。随后，卡13从读/写器19移出，并插入到便携式器件15中，以播放记录在卡上的音频内容。当主机11包含根据4C Entity和SDGroup的安全性和验证协议从卡13读写内容数据所需的软件时，主机11称作许可兼容模块(LCM)。
图2示出在示例性便携式应用器件15中的电子系统。通过总线23可操作地连接在一起的是计算单元(MCU)25、系统存储器27以及用于连接存储卡13的接口单元29，其中，计算单元25优选具有一些非易失性闪存25A，系统存储器27优选为高速随机存取存储器(RAM)。还为MCU25可选地提供USB连接17。当需要时，也可包括用于对以压缩和/或加密形式储存的内容数据如音频或视频数据进行解压缩和/或解密的数字信号处理器(DSP)31。DSP31还具有其自己的RAM存储器31A，作为处理器的一部分。可以包括或不包括DSP31。进一步地，如果包括DSP处理器，它就执行MCU25的功能，并因而可取消MCU25。只读存储器(ROM)32可储存本发明的部分或全部软件。ROM32中的软件指令和数据可直接从ROM32执行或读取，或首先投影到器件电路所包括的RAM存储器中。
在可记录介质上保护内容的规范已由Intel Corporation，International Business Machines Corporation，Matsushita ElectricIndustrial Co.，Ltd.和Toshiba Corporation(4C Entity)共同建立。在此具体相关的是4C Entity的以下三个出版物：“ContentProtection for Recordable Media Specification，Introduction andCommon Cryptographic Elements”，修订本0.94，2000年10月；“Content Protection for Recordable Media Specification，SDMemory Card Book”，修订本0.95，2001年5月；以及“C2 BlockCipher Specification”，修订本0.9，2000年1月11日；“ContentProtection for Recordable Media Specification，DVD Book”，修订本0.95，2001年5月，它们在此特别引作参考。在SD存储卡上执行这些4C Entity规范的附加详细规范已由Matsushita Electric IndustrialCo.，Ltd.(MEI)、SanDisk Corporation和Toshiba Corporation(SD Group)建立。
参照图3A，存储卡13可看作是有四个不同的层。这些层在其它类型的安全介质上也存在。
在存储卡13最基本的层上，即在物理层13d上以簇布置的存储单元中储存数据。如果数据是具有版权或值得加密的资料，就加密或保护数据。对安全内容加密和解密的密钥也被加密并储存在物理层的安全区中。
本发明的软件在器件内运行，以允许器件储存和检索加密信息，制造商(OEM)就不必编写非常具体的指令来访问包含加密数据和密钥的存储单元。本发明的软件包含根据器件的请求向器件发送加密数据、在器件内解密数据以及解压缩和播放音频、视频和图象文件的方法。简而言之，器件只需发送诸如“播放轨道”的命令。该软件接受命令，检索储存在存储单元中的加密数据，检索加密密钥，组织和解密数据，对数据解压缩和格式化，以及重放歌曲。
逻辑层13c包含用于物理层13d的存储单元和簇的组织结构。两个层13c和13d包含并逻辑构造卡13的存储器。由于卡13是安全卡，安全层13b控制并限制对容纳在以下层中的安全数据的访问。
应用层13a是存储卡13的一部分，与访问卡中所存内容的器件通信。这通过器件接口或触点39来实现。存储卡13优选包括管理卡的操作和应用层13的功能并控制卡的所有层13a-d的控制器。
在图3B中示出根据上述规范的记录介质SD卡13的物理和逻辑结构，所述结构与图3A的层13c和13d相对应。此卡包括存储单元阵列33和存储控制器35。控制器35和存储阵列33之间通过电路37交换用户数据、命令和状态信号。控制器35通过卡上的一系列电触点39与连接到插有卡的插槽的主器件通信。
阵列33的存储单元划分成四个不重叠的单元区，分别指定这些单元区储存不同类型的数据。最大存储容量的区41被指定储存用户数据，在此情况下，储存加密的音频、视频或其它数据。用户数据可以包括或不包括未加密的数据。存储器的系统区43储存卡制造商的64位介质标识符(IDmedia)以及由4C Entity提供的16个介质密钥块(MKB)，每个MKB具有最大为4k字节的大小，全部MKB由卡制造商预先记录。16个MKB中的一个被指定用于音频用户数据，另一个用于视频用户数据，另一个用于图象数据，等等。系统区43是可从卡外部读取的写保护区。隐藏区45包含与储存在系统区43中的16个不同介质密钥块(MKB)相对应的16个预先记录的介质唯一密钥(Kmu)。隐藏区45是只能由存储卡自身访问的写保护区。保护区47是仅在发生成功的明确相互验证之后可访问的读/写区。随机选取的标题密钥(Kt)和拷贝控制信息(CCI)以加密形式储存在保护区47中。储存在用户数据区41中的每个内容件(文件)用同样以加密形式储存在保护区47中的唯一标题密钥加密。储存在保护区47中的标题密钥和CCI并置在一起并用介质唯一密钥加密，介质唯一密钥对于每个存储卡都是唯一的并且储存在其隐藏区45中。用户数据区41的文件系统一般为普通的FAT文件系统。
储存在卡存储器的系统区43中的介质密钥块(MKB)包含一连串的相邻记录，在图4中示出一个这样的记录。整个MKB图象49是64KB。它被分成128个组块，每个组块512个字节，并且，在图中被标注为MKB组块50的组块1包含它们第一记录的全部或部分，组块1被放大以示出其组成部分。组块50还可包含多个记录。第一字段51包含记录类型，第二字段53包含记录的总长度，而剩余的字段55则包含密钥本身。记录类型字段和长度字段51和53中的数据不加密。MKB的每个记录的总长度是4字节的倍数。如图5中的程序块57所示，MKB密钥记录由储存在使用存储卡的便携式器件(PD)、许可兼容模块(LCM)或其它器件中的器件密钥解密，用于读取或编程储存在存储卡上的内容数据。器件密钥Kd1、Kd2、Kd3…由器件制造商写入应用器件的存储器中，所述存储器例如为在图2便携式音频播放器的MCU25中的非易失性闪存。器件密钥由4C Entity提供给器件制造商，并且秘密保存。储存在指定应用器件中的器件密钥的数量取决于器件的类型。
执行图5处理的应用器件(PD、LCM或其它器件)计算介质密钥Km，作为解密块57的一部分，这将结合图9和10进一步讨论。从所插入的存储卡的系统区读取的MKB的每个记录(图4)通常以此方式处理。在完成MKB的处理之后，最近计算的Km值作为从块57输出的秘密介质密钥。通过使用图5中块59所示的C2单向函数，而结合此介质密钥Km和介质标识符IDmedia，以产生介质唯一密钥Kmu。此处理的其它细节可参考前面引用的4C Entity出版物而获得。
图6示出当在具有图3存储空间配置的存储卡13上记录音频内容或从其上播放音频内容时发生的验证和加密处理。举例示出了在个人计算机或其它LCM63中进行的用于在卡13上记录音频或其它内容的处理。相似地，示出便携式音频或其它应用器件65从卡13读取所记录内容的处理。以上两个处理是结合图5描述的处理，块57和59作为应用器件65的一部分，并且，相应的块57′和59′是内容记录系统63的一部分。
作为内容记录的一部分，在直线67上输入任意分配的标题密钥Kt，加密模块69使用此密钥对在直线71输入的音频或其它内容的一个文件(件)进行加密。然后，加密文件储存在存储卡13的用户数据区41中。为了使标题密钥可用于对所记录的内容解密，标题密钥(Kt)的加密版本储存在受保护的卡存储区47中，如前所述。标题密钥(Kt)的加密版本还储存在系统存储器27、MCU25的RAM存储器25A、或DSP31的RAM存储器31A中。在器件的存储器中储存加密的标题密钥(Kt)就不必访问受保护的卡存储区47。这意义重大，因为在每次读取时，它节省与访问保护区47而进行比较时所花的大量时间和处理量。这在后面将结合图9讨论。用LCM63中的一组加密模块75、77和79以及存储卡61上的模块81对标题密钥Kt和拷贝控制信息CCI加密。介质唯一密钥Kmu由模块77使用。验证密钥互换(AKE)模块83结合由模块59′计算的以及储存在卡61隐藏区45中的介质唯一密钥Kmu，以产生由模块79和81中每个使用的对话密钥Ks。应用器件65为了对记录的加密内容进行解密，利用具有相同参考号但增加撇号(′)的相应模块执行加密处理的逆操作。
图7示出用于访问存储卡的保护区47、在卡和一些LCM或应用器件之间使用验证和密钥互换(AKE)询问-响应协议的技术。当此验证成功时，卡和其它模块或器件共享安全公共对话密钥Ks。前述处理和协议的其它细节可参照先前提出的4C Entity出版物。
如前所述，对SD存储卡的验证区执行访问要求使用OEM必须从4C Entity得到的秘密器件密钥。在SDK SW100软件层中保护这些密钥值并限制它们暴露是在软件设计时需要重点考虑的事情之一。在使安全介质如SD存储卡器件驱动器根据密钥值执行操作的同时，在单个内部模块内隔离这些密钥(和其它相关值如对话密钥)可用牢靠安全的接口方法实现。SD存储卡再次用于举例说明本发明；然而，本发明可应用于任何安全介质，如CD或其它在卡内的、甚至在远程存储器件内的安全存储器。
图8示出设计成在便携式器件或LCM内运行的软件系统的实施例，此软件系统访问用上述过程加密的信息。SanDisk软件SW100是一种完全总控的软件解决方案，它使OEM音乐播放器和记录器容易支持包括安全数字(SD)存储卡的安全介质。
如图8所示，SW100装入便携式器件15中，以便访问SD卡13。SW100也可安装在任何许可兼容模块如个人计算机中。音频接口105、视频接口110以及图象接口115是器件的通信端。这些接口向器件提供单个通信端，并且一般从器件接收简单的命令，从而器件不必受困于以下复杂的工作以从安全介质获得加密数据，随后对数据解密和处理。所有这些复杂的过程由SW100处理。接口105、110和115还管理重放的设置，如管理播放列表以及图象的关联，图象关联例如为艺术家图象与艺术家歌曲或各种播放列表的关联。应用编程接口(API)130A驻留在命令调度程序(CD)130内。CD130和API130A从接口105、110和115接收命令，向接口传递信息，并组织在SW100中发生的全部处理-与储存在安全介质上的内容的重放和记录有关的器件15的处理，CD130和API130A具有所有必需的加密、解密和压缩算法。对于与此无缝接口和控制有关的更多信息，参见与本专利申请同一天申请并与本专利申请具有相同发明人的题为“SYSTEM，METHOD，AND DEVICE FOR PLAYING BACKRECORDED AUDIO，VIDEO OR OTHER CONTENT FROM NON-VOLATILE MEMORY CARDS，COMPACT DISKS OR OTHERMEDIA”的美国专利申请，后者的代理卷号为M-9913US。
SD音频引擎(SDAE)140、SD视频引擎(SDVE)150和SD图象引擎(SDIE)160在从CD130接收指令时，分别处理驻留在安全介质上的音频、视频和图象内容。这意味着SDAE140可处理任何已知的音频格式，如AAC、WMA和MP3。同样，SDVE150可处理任何已知的视频削波格式如Windows介质文件或真实网络文件MPEG或任何其它已知类型的视频文件。最后，SDIE160可处理任何已知类型的图象文件，如TIF、GIF、JPEG、位图等。每个接口具有安全API(SAPI)和非安全API(NSAPI)。所处理的内容可以是或不是加密的。通过SAPI140A、150A和160A访问加密内容。这些SAPI与SanDisk安全管理器(SSM)180通信。处理安全内容的所有命令都通过SSM180引导。安全的数字安全引擎(SDSE)175处理所有的加密和解密过程，SDSE175在后面详细描述。用于验证介质并对内容解密的密钥包含在SDSE175中，并专门由SDSE175处理。通过NSAPI140B、150B和160B访问驻留在卡上的未加密内容。这些NSAPI与非安全文件接口(NSFI)170通信而访问介质上未加密的内容。
为了在存储介质上读或写数据，NSFI170和SDSE175与器件驱动器190通信。在SD卡的实例中的器件驱动器190管理并驱动发送到或来自SD卡13的器件接口39的触点的信号。器件驱动器190是根据各种器件或介质的器件接口39的具体类型而定制的。在存储卡器件的情况下，驱动器190管理并驱动发送到或来自位于器件15上的触点的信号。在光学介质的情况下，器件驱动器190管理并驱动来自各种硬件组件的信号，所述组件包括光学拾波器单元。器件驱动器190包含安全的器件驱动器接口(SDDI)190A以及非安全的器件驱动器接口(NSDDI)190B。SDDI190A和NSDDI190B在器件驱动器190中是相互隔离的。SDDI190A专门与SDSE175通信，而NSDDI190B专门与NSFI170通信。
SD-音频安全方案中重要的器件密钥和其它数值存放在一个受限制的安全软件模块：SD安全引擎(SDSE)175中。这些数值的全部操作只限制在此模块中。数值决不进入或输出到SDSE175之上的软件层。安全服务涉及这些密钥的所有请求由屏蔽此安全模块的SSM180控制和监视。在安全模块之下，SD存储卡器件驱动器190执行安全访问。通过私人驱动器安全接口：安全的器件驱动器接口(SDDI)190A，而发出对这些驱动器服务的请求，所述接口只为安全模块所知。SDSE175使用此接口190A来执行特殊的安全命令，如获得介质密钥块(MKB)。非安全的器件驱动器接口(NSDDI)190B还利用器件驱动器190访问卡13的用户区41中任何未加密的文件。
SW100体系结构的安全性取决于其密钥的安全性。秘密的“软密钥”不长时间地储存在临时的安全区域中，因为这增加包含密钥并因而包含加密内容的可能性。SW100在SDSE175内采用这样一种方案：动态地产生所需的密钥(或“软密钥”)并且当不立即需要这些特定密钥时就删除它们。
现在更详细地描述SW100的操作。在SW100内，命令发送到要求使用OEM的4C授权器件密钥的器件。这些密钥的所有处理只限制在位于SSM180之下的SDSE175模块中。
当SSM180接收安全服务请求时，它通过把命令请求包传递到SDSE175内的过程安全函数而执行此请求。密钥值从不包含在请求包内或不在SDSE175之上的软件层中暴露。
当在SDSE175内部需要时，通过函数调用OEM提供的库而检索器件密钥。SDSE175的库，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；以及
在本专利申请的文本中描述SW100的功能和结构，并且更具体地，以上API1-5的功能在图9流程图中示出。这些API在它们执行的相应功能旁边示出。在本专利申请附录中提供的源代码中可看到这些API实施以及全部的SW100的进一步细节。该源代码形成本专利申请的一部分，并在此特别引作参考。
一旦获得器件密钥，器件密钥就与来自SD存储卡的介质密钥块(MKB)结合，形成“介质密钥”。此值保留在SDSE175中，用于处理后续的请求。然而，注意，“唯一介质密钥”(Kmu)从不保留在SDSE175中。此值构成所有安全访问的基础，它总是实时计算(并且从不会被截获)以作为额外的安全预警。以下详细描述密钥在SDSE175中的处理。
加密过程一般设计为阻止位于安全介质上的内容被非法拷贝。本发明有许多方面能实现这点。首先，整个文件，如歌曲，从不同时解密并且不储存在易受攻击的存储器中。便携式器件分配缓冲器，SDSE175同时读取加密内容的组块，并对它们解密，然后一再地改写相同的缓冲器，直到文件结束为止。
从图6和7看出，介质唯一密钥(Kmu)和标题密钥(Kt)是最终用于对内容解密的密钥。有许多种方法保护标题密钥。一种是在器件15非常安全的区域中储存密钥，另一种是在每次读加密缓冲器并解密时从卡13的保护区47中读取标题密钥。图9是描述优选方法的流程图。
现在回到图9，在步骤205中，读取MKB图象以处理图6所示的介质密钥(Km)，产生介质唯一密钥(Kmu)，其中，如图4所示，MKB图象是64KB。此步骤在后面描述的图10中进一步详细讨论。在步骤205中完成器件和介质的相互验证之后，进行AKE过程，以产生只能在步骤210的对话(只要器件打开或处于活动状态)过程中使用的对话密钥(Ks)。通过再次参考图6可看到AKE过程。在步骤213中，删除介质唯一密钥(Kmu)。在步骤215中，使用对话密钥(Ks)对储存在存储卡13的保护区47中的双重加密标题密钥E(E(Kt))进行解密。所得到的结果是单重加密的标题密钥(E(Kt))。在步骤220中，此加密的标题密钥(E(Kt))储存在器件15的存储器中。(E(Kt))可储存在系统存储器27、MCU25的RAM存储器25A、或DSP31的RAM存储器31A中。标题密钥Kt对于每个标题而言是特殊的，其中，标题在音频范围内被称作轨道并且在图9中是用于举例说明本发明的。例如，在较长的古典歌曲情况下，每个轨道由多个文件构成。对于大的视频削波，标题包含许多文件。因而，对于所有后续读轨道加密内容并对其解密，不必从存储卡检索标题密钥，因为它储存在本地存储器中，并可节省宝贵的时间和计算资源，同时，出于安全考虑，标题密钥仍然加密。
在步骤225中，重放轨道的一部分。此部分可以在组成轨道的任何文件中。在步骤225a中，再次计算介质唯一密钥(Kmu)。在步骤225b中，对储存在本地存储器中的加密标题密钥进行解密。然后，在步骤225c中，标题密钥用于对来自器件15的缓冲器的内容进行解密，其中，此缓冲器包含来自存储卡13的用户区41中的内容。就在缓冲器被解密之后，在步骤225d中立即删除标题密钥，并在步骤225e中删除介质唯一密钥。步骤225d和225e的次序不重要，但重要的是这两个密钥只在读取一部分轨道时才被暴露。所述轨道部分可以是在重放(解密、解压缩和解码)内容、音频或其它的几分之一秒到约十秒之间。优选所述轨道部分为两秒。读此部分所花时间取决于许多因素，包括器件的处理速度和缓冲器大小。如前面所讨论的，SW100可由MCU25或DSP31执行，并储存在器件15的任一存储器27、25A、31A或32中，因而处理时间会变化。重复此操作，直到读取轨道的所有部分为止，如步骤230所示。一旦已读取所有部分，如果继续重放的话，系统就移动到下一轨道，如步骤235所示。例如，这是用户已选择播放整个列表的情况。
当已读取轨道的所有部分并开始读取下一轨道时，此过程将在步骤215重新开始，并检索来自卡13的保护区47的下一双重加密标题密钥。这一般是用户已设置器件为运行状态以播放包括多个轨道的整个文件的情况。如果关闭对话(即，器件15已打开或关闭)，那么，就必须产生新的对话密钥，并且此过程在步骤210中开始。如果移开或刚刚插入存储卡，器件和介质就必须重新进行验证，过程在步骤205重新开始以便读取轨道。
图10描述处理介质密钥块的操作，即上述图9中的步骤205。如图4所示，MKB图象49的长度为64KB。一次性读取整个图象49来计算MKB效率较低，需要较大的RAM和较长的处理时间。本系统减少RAM的需求并缩短处理时间。MKB图象49划分成组块1-128。每个组块都是512个字节，并包含以下四种不同类型的MKB记录中的一种：核实介质密钥记录(VMKR)，即0x81；计算介质密钥记录(CMKR)，即0x01；有条件计算介质密钥记录(CCMKR)，即0x82；或结束介质密钥记录(EMKR)，即0x02。在以上参考的4C Entity的可记录介质内容保护(CPRM)规范中描述这些记录。
在此实例中，组块长度和缓冲器长度是相同的。然而，缓冲器长度和组块长度都可在256字节到4096字节的范围内。检查每个记录，基于记录类型而执行特定的操作，并且为以后获得介质密钥而保存某些数据。在每次识别记录时，记录长度都增加到缓冲器位移的总长度上。通过用总长度除以组块长度而计算组块号。组块号是所选组块数据的介质密钥块的索引。总长度的剩余部分是相对于所选组块数据的位移。行和列用于判断加密介质密钥和有条件加密介质密钥所处的位置。保存这些加密密钥，并执行电子密码本模式算法中的解密C2密码以获得介质密钥。然后，核实此介质密钥是否为正确的最终介质密钥(Km)。
每个MKB组块用于从与记录号相关的MKB获得介质密钥(Km)所需的读取次数T表示如下：
记录号＜T＜(记录号*2)
T：访问MKB组块所需的次数
每个记录具有不同的长度和数据值。每个记录的信息可在两次读取中获得。由于有四个记录，需要4到8次读取来处理MKB组块和获得所述记录。
从而，读次数T为：
4＜T＜8
假设访问512字节的MKB数据需要N ms。在第一种方法中访问整个64K MKB图象以获得介质密钥需要(128*N)ms。在第二种方法中，在最坏的情况下获得介质密钥也只需要(8*N)ms。因而，使用此方案可节省大量的时间。平均而言，获得介质密钥(Km)所需的读次数在4到6的范围内，并且所需时间相应地小于上述时间。
图9的步骤205在图10中得以扩展，该步骤一直执行到在步骤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.49更新缓冲器位移并在新的位移设置缓冲指针。
如果记录是如步骤205.42所示的CMKR，那么，系统就更新缓冲器组块号，并把位移更新为加密介质密钥(Km)在步骤205.49中所处的正确MKB位置。每个卡有16个MKB。因而，系统将获得加密介质密钥所处位置的位移，前进到特定的MKB组块号，分配缓冲器(16个块×512字节)，并前进到每个数据块内的位移以读取加密介质密钥。然后，系统在步骤205.50中使用器件15提供的器件密钥(Kd)，而对介质密钥解密(计算)。一旦已经计算介质密钥，下一步骤就是核对介质密钥。
如果记录是在步骤205.44中所估计的VMKR，事先在步骤205.50的第一次尝试中或在步骤205.65的后续尝试中计算的介质密钥就在步骤205.55中与基准介质密钥(Km)比较。为此，首先就地储存基准介质密钥。如果密钥相同，就返回传送，这在十六进制中是DEADBEEF，并且系统不必有条件地计算介质密钥。为了判断从何处开始读取下一记录，VMKR的记录长度用于把缓冲指针移动到下一记录。如果密钥不相同，当读取CCMKR记录时，就在步骤205.46中重新计算介质密钥。当读取此记录时，在步骤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过程。
SDSE175内的函数执行安全访问，如通过使用安全器件驱动器接口(SDDI)190A来访问器件驱动器190的Get MKB。这个相同的器件驱动器SDDI190a还利用SDSE175内可直接调用的函数。例如，在发送读验证区之前，SDDI190a必须首先调用SDSE175内的sec_ake函数。sec_ake函数反过来调用SDDI190a。这种有助于在SDSE175内隔离器件密钥的“双重调用关系”对于SD音频标准的SW100实施是唯一的。
由于SDSE175处理所有面向密钥的处理，并且当音频接口105、视频接口110或图象接口115接收到某些SD命令时需要这些数值，因此，器件驱动器必须利用SDSE175内可直接调用的函数。在执行这些函数时，SDSE模块175必须反过来调用器件驱动器190的私人安全接口SDDI190A。这种“双重调用关系”允许在SDSE175和器件驱动器190之间交叉请求，因而，使得密钥值能在安全模块中被隔离。
SDSE175软件层通过启动安全驱动器请求包并调用传递请求包指针的安全驱动器接口入口点，而经过私人接口来调用安全器件驱动器服务。
为了阐明已引作参考的后附源代码，提供以下表格。
请求包(以sdapi.h定义)包括如下定义的数据类型SSMSERVE。 变量 变量名 Typedef struct_mySecuredDrv { 数据缓冲器 UCHAR*buffer 数据块的数量 UINT16 noBlocks 应用唯一号 UNIT16 mkb_ID 开始地址 UNIT16 lba 安全标记 INT16 securityFlag 驱动器号 INT16 driveNo 命令索引 INT16 opCode
命令索引(INT16 opCode)保留用于所请求服务的命令。被支持的命令包括：
命令 操作码例行程序 器件识别 #define SDDRV_IDENT 0 安全识别 #define SDDRV_SECIDENT 1 安全读 #define SDDRV_SECRD 2 安全写 #define SDDRV_SECWR 3 安全擦除 #define SDDRV_SECERASE 4 读MKB #define SDDRV_RDMKB 5 获得MID #define SDDRV_GETMID 6 设置询问 #define SDDRV_SETCHALGE 7 获得询问 #define SDDRV_GETCHALGE 8 设置响应 #define SDDRV_SETRESP 9 获得响应 #define SDDRV_GETRESP 10 改变保护区大小 #define SDDRV_CHANGESA 11
安全器件驱动器服务请求从SDSE175模块发出。例如，产生询问1函数发送如下询问1：
产生询问1 命令 操作 调用安全例行程序 SDSECURITYDRV mySecDrv 设置驱动器号 mySecDrv.driveNo＝(INT16)drv 设置介质内的存储器地址 mySecDrv.lba＝0 数据块的数量 mySecDrv.noBlocks＝1 设置询问 mySecDrv.opCode＝SDDRV_SETCHALGE 发送询问1 mySecDrv.buffer＝Chlg1 调用器件驱动器 scDDHandler(&mySecDrv)
由于所有的密钥操作限制在SDSE175中，因此，SSDI190a必须依靠SDSE175函数来执行验证密钥互换(AKE)或对在总线上传输的数据进行解密(注意：所有通过总线发送的数据首先用每个AKE产生的“对话密钥”来加密)。
在执行AKE时，SDSE175必须向SD存储卡13发送命令，因而，SDSE175必须反过来调用SDDI190a。此种调用关系在描述处理验证区读取所必需的步骤的图7视图中被概括。
注意，SDSE175内的sec_ake函数在被安全SDDI190a调用时，通过私人驱动器接口执行四次调用安全器件驱动器。这四个请求包括：SDDRV_SETCHALGE、SDDRV_GETCHALGE、SDDRV_SETRESP和SDDRV_GETRESP。这使安全模块能执行图7所示的设置询问/获得询问、设置响应/获得响应的必需步骤。所得到的对话密钥储存在安全模块内。当安全器件驱动器调用SDSE175的bus_decrypt函数以从SDDI190a获得信息时，对话密钥用于对数据解密。
随机数产生：
图6和7所示的AKE过程83要求产生随机数。SD随机数产生(RNG)的实施要求基于先前的随机数Vt计算随机数籽数V(t+1)。随机数籽数V(t+1)必须储存在闪存中，并且用作产生下一随机数的籽数。此随机数和籽数用于C2_G中，C2_G是一种C2密码单向函数。
在不可能重写随机数籽数Vt+1的低成本计算平台(即，没有为籽数存储指定EEPROM)中，RNG实施会产生问题。
如果程序使用固定数或可预测的数作为随机数产生器的籽数，黑客就可破坏拷贝保护或窃取密钥。对于固定的籽数，如果要访问相同的SD卡地址，第一个随机数和询问也就是固定的。通过跟踪响应，唯一介质密钥有可能被窃取。在这，我们使用系统计时器作为PC应用的解决方案。为了确保计时器产生的籽数不可预测，我们混洗计时器，以使随机数籽数的每个字节都是随机的。在诸如Microchip PIC16xxx的系统中，作为被执行命令数的Timer1可在混洗之后用作随机数产生的籽数。
主要观点是使用多于一个的总在作加法的计时器，并且控制更新最慢(最高有效)字节的频率以使它们以更高的频率更新。计算更新最慢(最高有效)字节的值，作为更新最快(最低有效)字节的函数。一种随机数产生方法利用系统计时器。它使用处理器时钟的4个字节和通用协调时间的4个字节。处理器时钟是自程序开始之后处理器时间的数量。此时间被细化为CLOCKS_PER_SECONDS，它在本专利申请中为60。它通过Microsoft C++运行时间函数“clock()”获得。通用协调时间通过Microsoft C++运行时间函数“time()”获得。通用协调时间是从1899年12月31日午夜开始的秒数。
处理器时钟被读入字节0-3，而通用协调时间被读入字节4-7。字节0和1迅速变化，而字节2和3变化没那么快。因而，我们可通过使字节2和3以基于字节0和1变化步调的步调而变化，以增加字节2和3的变化速率。这可通过各种方法来实现。例如，采用专门的OR函数：
vt_1[2]＝vt_1[2]^vt_1[0]
vt_1[3]＝vt_1[3]^vt_1[1]^vt_1[0]。
相似地，可通过以下实例而使字节6和7以更快的步调变化：
vt_1[6]＝vt_1[0]+vt_1[1]+vt_1[2]+vt_1[3]+vt_1[4]+vt_1[5]+vt_1[6]
vt_1[7]＝vt_1[0]^vt_1[1]^vt_1[2]^vt_1[3]^vt_1[4]^vt_1[5]^vt_1[6]^vt_1[7]。
增加变化的步调也可通过在某个字节位置使用计时器值的倍数或通过其它使变化较慢的字节依赖于变化较快的字节的方法来实现。对于更多的细节，请参考构成本专利申请一部分的后附源代码。
结果，在固定的籽数上应用C2密码将产生新的随机数籽数V(t+1)。C2_G是一种C2密码单向函数。它在固定的籽数“v0”上应用随机数密钥“c1”，为第一AKE产生不同的初始籽数“v1”。
CurrentTime是使用DOS软件中断“1A”函数“0”读取计时器计时的汇编程序。以下是_CurrentTime PROC NEAR的代码：push cx；mov ax，0；int 1ah；mov ax，dx；mov dx，cx；pop cx；ret；_CurrentTime ENDP。
优点
本发明的系统和方法在许多方面比现有技术有利。器件密钥和所得到的对话密钥在良好隔离的和受保护的软件层中操作。这些密钥从不会在更高的层中暴露。甚至是更低的器件驱动器层也不能直接访问所述密钥。在产生介质密钥时，从OEM提供的库中检索器件密钥。此密钥保留在安全引擎中，但从不储存作为安全方案核心的介质唯一密钥(Kmu)。安全引擎的私人接口使安全引擎能获得对存储卡的低层访问，同时使与安全性有关的所有密钥(如器件密钥、介质密钥、对话密钥)的暴露限制在安全引擎内。“双重调用关系”允许安全引擎和安全器件驱动器交叉利用相互的服务。
虽然已示出和描述本发明的具体实施例和它们的优点，但应该理解，只要不偏离后附权利要求所定义的本发明的精神和范围，可在此作出各种改变、替换和变更。例如，尽管已示出SD存储卡的使用来举例说明本发明的作用，但本发明也可应用于任何具有加密内容的介质上。本发明也可被任何类型的器件利用。