CN101471943B

CN101471943B - 用于验证硬件装置并为发布数据提供安全通道的方法

Info

Publication number: CN101471943B
Application number: CN200810178075.3A
Authority: CN
Inventors: B·韦姆布; G·L·格劳恩克; S·萨达斯万; A·斯里尼瓦斯
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2007-12-20
Filing date: 2008-12-19
Publication date: 2013-01-09
Anticipated expiration: 2028-12-19
Also published as: US20100027790A1; EP2073142A3; EP2073142A2; CN101471943A

Abstract

一种使用软件应用程序来通过硬件装置发布音频/视频数据的方法，包括在硬件端接收来自所述软件的加密的应用密钥、加密的随机会话密钥和加密的音频/视频数据。之后，所述硬件使用加密密钥对所述加密的应用密钥进行解密，使用所述应用密钥对所述加密的随机会话密钥进行解密，并使用所述随机会话密钥对所述加密的音频/视频数据进行解密。之后，所述硬件可以通过显示器和扬声器发布不加密的音频/视频数据。所述加密密钥在较早的时间点以安全的方式嵌入在所述硬件装置内。

Description

用于验证硬件装置并为发布数据提供安全通道的方法

背景技术

可以使用软件应用程序对来自诸如DVD、CD-ROM、闪速存储器等介质源的音频和视频内容以及直接下载到计算机的硬盘驱动器上的数据进行发布。软件应用程序通常是由独立的软件供应商提供的，例如，总部位于台湾的台北的

和总部位于加拿大的渥太华的

独立的软件供应商通常签署内容许可证，因而负责确保以安全的方式发布音频和视频内容。为了履行内容许可证中的条款，所述软件应用程序必须合理地保护数据在软件应用程序与内容发布装置之间的流动，例如，所述内容发布装置可以是向计算机显示器和扬声器提供输出的视频和音频处理装置。

对于媒体内容的播放而言，软件应用程序通常执行至少一部分数据处理。之后，软件应用程序将依赖于诸如视频处理装置(例如，显卡)之类的硬件装置来执行所有余下的处理以及发布经过处理的数据。由于软件应用程序必须对发送到视频处理装置的数据进行保护，因此软件应用程序必须验证所述视频处理装置，而且必须建立发送数据的安全通道。

目前存在几种有效的用于验证视频处理装置和建立安全通道的机制。在一种机制中，所述软件应用程序和所述视频处理装置可以共享密钥。这种机制的评价不高，这是因为所述软件应用程序中针对密钥的折衷方案影响了所有其他供应商应用。另一种机制包括使用公钥-私钥基础设施，但是这包括高昂的硬件成本，原因在于它包括RSA型取幂(exponentiation)。

附图说明

图1是根据本发明实施方式的用于向软件供应商提供加密的应用密钥(application key)的方法；

图2A以图示的方式示出了向软件供应商提供加密的应用密钥；

图2B以图示的方式示出了使用分组密码加密和加密密钥对应用密钥的加密；

图3是根据本发明实施方式的用于验证硬件装置和建立安全通道的运行方法；

图4A以图示的方式示出了运行的验证过程和安全通道的建立；

图4B以图示的方式示出了使用分组密码解密和加密密钥对所述加密的应用密钥的解密；以及

图4C以图示的方式示出了使用分组密码解密和应用密钥对加密的随机会话密钥的解密。

具体实施方式

本文描述了用于保护源装置与接收装置(sink device)，例如软件应用程序与硬件装置之间的数据流的系统和方法。源装置通常是数据的制造者或创建者，而接收装置则是数据的消费者。在下述描述中，将利用本领域技术人员通常用于向其他领域技术人员表达其工作实质的术语来描述所述示例性实施方式的各个方面。但是，对本领域技术人员显而易见的是，本发明可以只利用所描述方面中的一些来实施。出于介绍的目的，阐述了具体的数字、材料和构造，以便提供对所述示例性实施方式的透彻理解。但是，对本领域技术人员显而易见的是，可以在没有这些具体细节的情况下实施本发明。在其它示例中，省略或简化了公知的特征，以便不会使所述示例性实施方式变得难以理解。

将按照对理解本发明最有帮助的方式将各项操作作为多个分立的操作依次予以描述，但是不应将这种描述顺序解释为暗示这些操作一定是顺序相关的。具体而言，不需要一定按照所给出的顺序来执行这些操作。

本发明的实施方式为源装置验证接收装置并建立与该接收装置的安全数据通道提供了多种鲁棒的方法。所述源装置和接收装置可以是硬件装置或软件应用程序。例如，本发明的一些实施方式可以为第一硬件装置(即源装置)验证第二硬件装置(即，接收装置)并建立与该第二硬件装置的安全通道提供多种方法。本发明的备选实施方式可以为软件应用程序(即源装置)验证硬件装置(即接收装置)并建立与该硬件装置的安全通道提供多种方法。在其它实施方式中，所述源装置可以是硬件装置，而所述接收装置则为软件应用程序，或者所述源装置和所述接收装置均为软件应用程序。

本发明的方法确保了以安全、受保护的方式将数据从源装置传输到接收装置。本发明的实施方式通过在新颖性机制中采用三种不同的密钥实现了这一目的。在初始提供阶段期间，生成这些密钥中的两个密钥，即，永久性地存在于接收装置内的加密密钥和提供给源装置的应用密钥。部分使用这两个密钥来验证接收装置。第三个密钥，即随机会话密钥是由源装置生成的运行密钥，用于在源装置与接收装置之间建立安全通道。

为了更加清晰地说明如何在真实的世界情境中使用本发明的方法，下列描述集中在使用本发明的方法来验证硬件装置以及在软件应用程序与硬件装置之间建立安全通道。所述软件应用程序起源装置的作用，而硬件应用起接收装置的作用。尽管这是下述描述的中心，但是应当指出本发明不限于软件源装置，也不限于硬件接收装置。

在本文描述的本发明的实施方式中，所述硬件装置包括视频处理装置，所述软件应用程序用于向所述视频处理装置提供音频和视频数据。本发明的方法确保了以安全、保护的方式发布音频/视频数据。对于下文所述的实施方式而言，所述加密密钥永久性地存在于所述视频处理装置内，所述应用密钥被提供给生成软件应用程序的软件供应商，所述随机会话密钥由所述软件应用程序生成。

图1是根据本发明的实施方式的用于向软件供应商提供加密的应用密钥的方法100。图2以图示的方式示出了根据本发明的实施方式向软件供应商提供加密的应用密钥。

根据本发明的实施方式，将加密密钥永久性地嵌入在诸如视频处理装置之类的硬件装置内(图1的过程102)。在一些实施方式中，所述视频处理装置可以包括一个或一组嵌入在计算机主板上的集成电路装置。在其它实施方式中，所述视频处理装置可以包括显卡，该显卡与计算机主板分离但电耦合到计算机主板。在各种实施方式中，可以通过加速图形端口(AGP)、外围部件接口(PCI)插槽、PCI Express插槽或其它类似的扩展端口将所述显卡耦合到所述计算机主板。本领域技术人员应该认识到，所述视频处理装置是能够处理音频/视频数据的装置。在备选的实施方式中，所述硬件装置可以是除了视频处理装置以外的装置。

所述加密密钥(SEK)可以是128位密钥。在备选的实施方式中，所述SEK可以具有更大的位数，例如，192位或256位，或者具有更小的位数，例如，32位或64位。本领域技术人员应该认识到，所述位数可以基于所期望的安全级别而变化。在本发明的一些实施方式中，所述SEK可以是与高级加密标准(AES)兼容的128位、192位或256位密钥。也可以使用其它加密方法。

在本发明的实施方式中，可以通过专用熔丝(fuse)将SEK永久性地嵌入在所述视频处理装置内。例如，可以通过包括所述专用熔丝的写入路径将所述SEK写入到所述视频处理装置的存储器阵列内。之后，可以有意烧断这一专用熔丝，从而避免所述SEK受到外部源的访问或窜改。对所述SEK的唯一保留通道在所述视频处理装置的内部，并且外部源无法触及这一内部通道。在备选的实施方式中，可以将所述SEK硬布线到寄存器传输级(RTL)内。

图2A以图示的方式示出了包括嵌入SEK 202的视频处理装置200。将所述SEK 202永久性地嵌入在所述视频处理装置200内，并且外部源无法对其进行访问或窜改。如上所述，所述SEK 202可以是与AES或其它密码加密过程一起使用的128、192或256位密钥。

返回至图1，将唯一的应用密钥(AppKey)分配给软件供应商(104)。为生产供本发明的视频处理装置使用的软件应用程序的每一软件供应商分配唯一的AppKey。没有任何两个软件供应商会共用同一AppKey。在一些情况下，可以为软件供应商分配两个或更多个AppKey。例如，如果第一AppKey被泄密，那么可以分配第二AppKey。在一些实施方式中，软件供应商选择AppKey。在备选应用中，由所述视频处理装置的制造商生成所述AppKey。在其它实施方式中，由独立的第三方选择所述AppKey。

在本发明的一些实施方式中，所述AppKey可以是128位密钥。在备选实施方式中，所述AppKey可以具有更大的位数，例如，192位或256位，或者具有更小的位数，例如，32位或64位。如下文所述，除了被分配给软件供应商之外，所述AppKey以后还将起到加密密钥的作用。同样地，所述AppKey可以是与AES或备选密码加密过程兼容的128位、192位或256位密钥。

接下来，使用SEK对所述唯一的AppKey加密，以生成加密的AppKey(106)，在本文中将加密的AppKey称为(AppKey)^SEK。在一些实施方式中，可以使用分组密码加密。在本发明的其它实施方式中，可以使用诸如AES等标准化加密术。AES是已经被采纳作为加密标准的特定分组密码。对本领域技术人员公知的是，可以将这种分组密码与所述SEK结合使用来对所述AppKey加密。例如，如图2B所示，使用SEK对所述AppKey进行分组密码加密，从而输出加密的(AppKey)^SEK。在备选的实施方式中，可以使用AES以外的密码。

在一些实施方式中，所述加密可以在所述视频处理装置本身上进行。例如，可以通过所述视频处理装置发送所述唯一的AppKey，在所述视频处理装置中，利用SEK使所述唯一的AppKey被加密。在其它实施方式中，可以使用未必特指视频处理装置的装置来对所述唯一AppKey加密。例如，可以使用加密工具来接受所述唯一的AppKey，并按照与视频处理装置相同的方式使用AES和SEK对其加密。唯一的要求是：所述加密工具中使用的SEK与卖给消费者的大量视频处理装置中永久性地嵌入的SEK相匹配。这使得每一消费者购买的视频处理装置能够使用AES分组密码和SEK对所述(AppKey)^SEK解密。在本发明的实施方式中，所述加密工具可以包括运行加密软件的计算机。

之后，将加密的AppKey，即(AppKey)^SEK提供给软件供应商(108)。所述软件供应商只能访问所述AppKey和所述(AppKey)^SEK。所述软件供应商无法访问所述SEK。此外，由于可以使用诸如AES等加密法，因此即使所述软件供应商能够对AppKey和(AppKey)^SEK二者进行访问，它也无法解密所述SEK。

来看图2A，该图示出了：在加密的应用密钥(AppKey)^SEK的最初提供过程中，软件供应商204与视频处理装置200进行交互。如上所述，可以使用加密工具来替代所述视频处理装置。软件供应商204为所述视频处理装置(或加密工具)200提供AppKey 206。此外，尽管图2示出了AppKey206是由软件供应商204提供的，但是在备选实施方式中，AppKey 206也可以是由视频处理装置200的制造商或独立的第三方提供的。所述视频处理装置(或加密工具)200使用SEK 202对AppKey 206加密。可以使用诸如AES等加密法进行加密。之后，所述视频处理装置(或加密工具)200输出加密的AppKey，将该加密的AppKey表示为(AppKey)^SEK 208，并且将这一(AppKey)^SEK 208提供给软件供应商204。

因此，图1和图2描述了本发明的生成加密的AppKey并将其提供给软件供应商的初始提供阶段。根据本发明的实施方式，如图2A所示，可以在安全的场所对AppKey进行加密以生成(AppKey)^SEK。例如，可以在制造所述视频处理装置的制造设施处实施所述提供阶段。在备选实施方式中，可以将所述加密工具提供给所述软件供应商，之后所述软件供应商在安全的场所对所述加密工具进行维护，以及使用所述工具生成加密的AppKey。出于安全的目的而规定不应在一般的用户平台上实施这一加密过程不存在任何必要性。

图3是根据本发明实施方式的用于验证诸如视频处理装置等硬件装置(即接收装置)并且在软件应用程序(即，源装置)与所述视频处理装置之间建立安全通道的运行方法300。图4A以图示的方式示出了根据本发明实施方式的运行的验证过程和安全通道的建立。如上所述，使用所述安全通道来将音频/视频数据以受保护的方式从软件应用程序传送到所述视频处理装置。在本发明的实施方式中，所述软件应用程序和所述硬件装置可以存在于同一计算机系统内或者存在于不同的计算机系统内。例如，所述软件应用程序可以存在于第一计算机系统的硬盘上和/或第一计算机系统的计算机存储器(例如，随机存取存储器或闪速存储器)内，同时可以将所述视频处理装置集成或耦合至所述第一计算机系统的主板上或者第二计算机系统的主板上。在一些实施方式中，所述计算机系统之一或二者均可以容纳于消费者电子装置内，例如，DVD播放器、便携式媒体播放器或音频/视频接收机。如果使用了两个独立的计算机系统，那么可以通过有线或无线装置使所述两个计算机系统通信耦合。

从图3开始，软件供应商提供了用于与所述视频处理装置一起使用的软件应用程序(图3的过程302)。将所述软件应用程序设计为对音频/视频数据至少进行部分处理。根据本发明的实施方式，将对软件供应商而言是唯一的AppKey嵌入在所述软件应用程序中。此外，还将加密的(AppKey)^SEK嵌入在所述软件应用程序中，其中，所述(AppKey)^SEK包括由视频处理装置或加密工具使用SEK加密后的AppKey。上文已经描述了针对具体软件供应商生成(AppKey)^SEK的过程。

一般而言，所述软件应用程序使用本领域已知的标准抗窜改软件方法来保护所述AppKey和(AppKey)^SEK。常规软件应用程序通常使用这样的方法在处理过程中保护许可证密钥和音频/视频数据。应当注意，如果AppKey和(AppKey)^SEK被泄密，那么由于使用了诸如AES等加密法，因此仍然无法确定SEK的值。

图4A示出了软件应用程序400和视频处理装置200。如上所述，将SEK202永久性地嵌入在视频处理装置200内。将对软件供应商而言是唯一的AppKey 206以及加密的(AppKey)^SEK 208包含在软件应用程序400中，其中所述(AppKey)^SEK 208由使用SEK 202加密之后的AppKey 206构成。软件应用程序400还包括必须被安全地发送到视频处理装置200的音频/视频数据(A/V)402。

在运行时，指派所述软件应用程序和视频处理装置来处理和发布音频/视频数据。在发送音频/视频数据之前或与之同时，软件应用程序将(AppKey)^SEK发送到视频处理装置(304)。由于(AppKey)^SEK是加密的，因此它能够以几乎不可能被破译的受到高度保护的方式在软件应用程序与视频处理装置之间传输。

所述软件应用程序还生成了随机会话密钥(RSK)(306)。所述RSK通常是由软件应用程序随机生成的唯一密钥，并且它不必与任何软件供应商绑定到一起。所述软件应用程序可以使用标准的随机数生成库来生成所述会话密钥。

之后，所述软件应用程序使用AppKey对所述RSK加密(308)。这生成了加密的(RSK)^AppKey。如上所述，AppKey可以是与标准加密方法兼容的128、192或256位密钥。在一种实施方式中，可以使用与用于借助SEK对AppKey加密的技术类似的技术来执行所述加密。例如，可以使用诸如AES等分组密码加密。对所述RSK进行使用AppKey的分组密码加密，从而输出加密的(RSK)^AppKey。在其它实施方式中，可以使用借助AppKey对RSK加密的备选方法。

接下来，所述软件应用程序将加密的(RSK)^AppKey发送至所述视频处理装置(310)。可以大约在发送所述加密的(AppKey)^SEK的同时将所述加密的(RSK)^AppKey发送至所述视频处理装置，或者可以在稍后发送所述加密的(RSK)^AppKey。通常，所述软件应用程序将大约同时发送加密的(RSK)^AppKey和所述加密的(AppKey)^SEK二者。与(AppKey)^SEK的情况一样，由于(RSK)^AppKey是加密的，因此它能够以几乎不可能被破译的受到高度保护的方式在软件应用程序与视频处理装置之间传输。

在从软件应用程序接收到加密的(AppKey)^SEK之后，所述视频处理装置使用永久性地嵌入在所述视频处理装置之内的SEK对所述(AppKey)^SEK解密(312)。现在所述视频处理装置已经提取出所述AppKey。图4B不出了如何使用SEK对(AppKey)^SEK进行分组密码解密，以输出解密的AppKey。可以使用AES作为解密标准。因此，所述视频处理装置以受保护的方式接收到了AppKey。

接下来，在从所述软件应用程序接收到了所述加密的(RSK)^AppKey之后，所述视频处理装置使用前面解密的AppKey对(RSK)^AppKey进行解密(314)。现在所述视频处理装置已经提取出RSK。图4C示出了如何使用AppKey对所述加密的(RSK)^AppKey进行分组密码解密，以输出解密的RSK。而且，可以使用AES作为解密标准。因此，所述视频处理装置以受保护的方式接收到了RSK。在过程流中的这一点上，所述软件应用程序和所述视频处理装置具有通用的共享RSK。

现在，所述软件应用程序可以使用所述RSK将加密的音频/视频数据以受保护的方式发送至所述视频处理装置。首先，所述软件应用程序使用所述RSK对所述音频/视频数据加密(316)。本文将加密的音频/视频数据称为(A/V)^RSK。在一种实施方式中，可以使用与用于借助SEK对AppKey加密以及借助AppKey对RSK加密的技术类似的技术执行所述加密。在另一种实施方式中，可以将电子密码本(ECB)模式用于密钥加密，同时可以将计数器(CTR)模式用于音频/视频数据加密。应当注意，对于音频/视频数据加密而言，可以使用本领域可用的任何加密模式，包括但不限于诸如密码块链接(CBC)、传播密码块链接(PCBC)、密码反馈(CFB)和输出反馈(OFB)之类的分组密码加密技术的可用变型中的任何一种。之后，所述软件应用程序将加密的(A/V)^RSK发送至所述视频处理装置(318)。随着所述音频/视频数据在所述软件应用程序与所述视频处理装置之间传输，所述加密将避免(A/V)^RSK被侦听和破译。

所述视频处理装置接收到加密的(A/V)^RSK，并使用先前解密的RSK对其解密(320)。在一种实施方式中，可以使用与用于对(AppKey)^SEK和(RSK)^AppKey解密的技术类似的技术来执行所述解密。这里，可以基于怎样才适合对所述音频/视频数据使用的加密方法这一原则来选择所实施的解密方法。

现在，所述视频处理装置已经提取出可被处理和发布的未加密的音频/视频数据(322)。例如，所述视频处理装置可以对所述数据进行处理，并将视频显示在显示装置上，同时通过扬声器发布音频。

加密的使用保护了数据的发送。由于所述视频处理装置不能在未事先拥有SEK的情况下对AppKey或RSK解密，因此这里暗中对硬件进行了验证。没有SEK的硬件不能对任何数据解密，因此也不能处理和发布音频/视频数据。

图4A示出了在软件应用程序400与视频处理装置200之间的加密数据流。如图所示，所述软件应用程序将(AppKey)^SEK 208发送到所述视频处理装置200。所述软件应用程序400还生成随机会话密钥RSK 404，使用AppKey 206对RSK 404加密以生成(RSK)^AppKey 406，并且将(RSK)^AppKey 406发送到所述视频处理装置200。最后，所述软件应用程序400使用RSK 404对A/V 402加密，以生成加密的音频/视频数据(A/V)^RSK 408，并且将(A/V)^RSK408发送到所述视频处理装置200。如图4A所示，对从所述软件应用程序400流动到所述视频处理装置200的所有数据进行了加密。

本发明的总体过程流具有鲁棒性，这是因为只有含有SEK的硬件装置才能解开AppKey，进而解开最终的会话密钥RSK。用户平台上的攻击程序只能发现在所述软件应用程序与所述硬件装置之间流动的加密的(AppKey)^SEK、加密的(RSK)^AppKey和加密的(A/V)^RSK。所述加密避免了所述数据受到侦听和破译。如果所述硬件装置含有密钥SEK，那么只能完成对从所述软件应用程序到所述硬件装置的AppKey和RSK的解密。

只有所述硬件装置的制造商才知道所述密钥SEK。如上所述，所述软件供应商只接收(AppKey)^SEK，所述(AppKey)^SEK是不能被软件供应商解密的加密数据串，这是因为软件供应商没有接触SEK的通道。每一软件供应商可以具有自己独立的AppKey。因此，供应商的AppKey的泄密只能暴露供应商A，而不会影响供应商B。

如上所述，尽管本说明书描述了媒体内容的保护，但是本发明的方法不限于音频和视频数据的传输。例如，可以使用本发明的方法来保护其它形式的数据在其它类型的软件与硬件装置之间的传输，包括但不限于金融交易和一般网络业务。

可以通过硬件、固件和软件之一或其组合实现本发明。所述硬件可以是包括处理器的计算机系统，处理器指的是对来自寄存器和/或存储器的电子数据进行处理以便将所述电子数据转换成可存储在寄存器和/或存储器内的其它电子数据的任何装置或装置的一部分。处理平台可以包括一个或多个处理器。

还可以将本发明实现为存储在机器可读介质上的指令，可以由处理平台读取并执行所述指令，以执行本文描述的操作。机器可读介质可以包括任何用于存储、发送或接收机器(例如，计算机)可读形式的信息的机构。例如，机器可读介质可以包括只读存储器(ROM)；随机存取存储器(RAM)；磁盘存储介质；光存储介质；闪速存储装置；电、光、声或其它形式的传播信号(例如，载波、红外信号、数字信号、发射和/或接收这些信号的接口等)，等等。传播信号包括通过Internet以及通过无线通信装置发送的信号。“无线”一词及其派生词可以用来描述利用调制的电磁辐射通过非固态介质进行数据通信的电路、装置、系统、方法、技术、通信通道等。

本发明示例性实施方式的上述说明(包括摘要中的内容)并非旨在穷举或将本发明限定为所公开的精确形式。尽管出于举例说明的目的在本文描述了本发明的具体实施方式和例子，但是本领域技术人员应该认识到，在本发明的范围内各种等价修改都是可能的。

根据上面的详细描述，可以对本发明做出这些修改。不应将下列权利要求中使用的术语理解为将本发明局限于说明书和权利要求中所公开的具体实施方式。相反，本发明的范围将完全由下列权利要求确定，应当根据公认的权利要求解释原则对其进行理解。

Claims

1.一种用于接收装置对从源装置接收的数据进行处理的方法，包括：

从所述源装置接收加密的应用密钥；

从所述源装置接收加密的随机会话密钥；

从所述源装置接收加密的数据；

使用所述接收装置所持有的加密密钥来对所述加密的应用密钥进行解密，由此提取出应用密钥；

使用所述应用密钥来对所述加密的随机会话密钥进行解密，由此提取出随机会话密钥；

使用所述随机会话密钥来对所述加密的数据进行解密，由此提取出不加密的数据；以及

对所述不加密的数据进行处理，

其中，所述加密的应用密钥是使用AES和所述加密密钥加密的，并且

其中，所述加密的随机会话密钥是使用AES和所述应用密钥加密的。

2.根据权利要求1所述的方法，其中，所述源装置包括软件应用程序，所述接收装置包括硬件装置。

3.根据权利要求2所述的方法，其中，所述加密密钥被永久性地嵌入在所述硬件装置内。

4.根据权利要求1所述的方法，其中，所述数据是使用计数器模式加密的。

5.根据权利要求2所述的方法，其中，所述数据包括音频和视频数据。

6.根据权利要求1所述的方法，其中，所述源装置包括硬件装置。

7.根据权利要求1所述的方法，其中，所述接收装置包括软件应用程序。

8.一种用于源装置将数据发送到接收装置的方法，包括：

将加密的应用密钥发送到所述接收装置，其中，所述加密的应用密钥包括利用所述接收装置所持有的加密密钥加密的应用密钥；

生成随机会话密钥；

利用所述应用密钥对所述随机会话密钥进行加密；

将所述加密的随机会话密钥发送到所述接收装置；

利用所述随机会话密钥对所述数据进行加密；以及

将所述加密的数据发送到所述接收装置，

其中，使用AES来执行利用所述应用密钥对所述随机会话密钥的加密。

9.根据权利要求8所述的方法，其中，所述源装置包括软件应用程序，所述接收装置包括硬件装置。

10.根据权利要求8所述的方法，其中，在将所述数据发送到所述接收装置之前，在安全的场所利用加密密钥对所述应用密钥进行加密。

11.根据权利要求8所述的方法，其中，使用AES来执行利用所述随机会话密钥对所述数据的加密。

12.根据权利要求8所述的方法，其中，使用计数器模式来执行对所述数据的加密。

13.根据权利要求8所述的方法，其中，所述源装置包括硬件装置。

14.根据权利要求8所述的方法，其中，所述接收装置包括软件应用程序。

15.一种使用软件应用程序通过硬件装置处理数据的方法，包括：

将加密的应用密钥从所述软件应用程序发送到所述硬件装置，其中，所述加密的应用密钥包括使用分组密码加密和所述硬件装置所持有的加密密钥所加密的应用密钥；

使用所述硬件装置来利用分组密码解密和所述硬件装置所持有的加密密钥对所述加密的应用密钥进行解密，由此提取出所述应用密钥；

使用所述软件应用程序来生成随机会话密钥；

使用所述软件应用程序来利用分组密码加密和所述应用密钥对所述随机会话密钥进行加密；

将所述加密的随机会话密钥从所述软件应用程序发送到所述硬件装置；

使用所述硬件装置来利用分组密码解密和所述应用密钥对所述加密的随机会话密钥进行解密，由此提取出所述随机会话密钥；

使用所述软件应用程序来利用所述随机会话密钥对所述数据进行加密；

将所述加密的数据从所述软件应用程序发送到所述硬件装置；

使用所述硬件装置来利用所述随机会话密钥对所述加密的数据进行解密，由此提取出所述数据；以及

对所述数据进行处理。

16.根据权利要求15所述的方法，其中，所述分组密码加密和解密是以AES为基础的。

17.根据权利要求15所述的方法，其中，所述硬件装置包括视频处理装置。

18.根据权利要求15所述的方法，其中，所述软件应用程序和所述硬件装置二者均存在于同一计算机系统内。

19.根据权利要求15所述的方法，其中，所述软件应用程序和所述硬件装置二者存在于不同的计算机系统内。

20.根据权利要求15所述的方法，其中，所述加密的应用密钥是在使用所述软件应用程序通过硬件装置发布媒体内容之前而在安全的场所使用所述分组密码加密和所述加密密钥加密的。

21.一种用于接收装置对从源装置接收的数据进行处理的装置，包括：

用于从所述源装置接收加密的应用密钥的模块；

用于从所述源装置接收加密的随机会话密钥的模块；

用于从所述源装置接收加密的数据的模块；

用于使用所述接收装置所持有的加密密钥来对所述加密的应用密钥进行解密，由此提取出应用密钥的模块；

用于使用所述应用密钥来对所述加密的随机会话密钥进行解密，由此提取出随机会话密钥的模块；

用于使用所述随机会话密钥来对所述加密的数据进行解密，由此提取出不加密的数据的模块；以及

用于对所述不加密的数据进行处理的模块，

22.根据权利要求21所述的装置，其中，所述数据包括音频和视频数据，所述接收装置通过在显示装置上以及经由扬声器发布所述音频视频数据来处理所述数据。

23.一种用于源装置将数据发送到接收装置的装置，包括：

用于将加密的应用密钥发送到所述接收装置的模块，其中，所述加密的应用密钥包括利用所述接收装置所持有的加密密钥加密的应用密钥；

用于生成随机会话密钥的模块；

用于利用所述应用密钥对所述随机会话密钥进行加密的模块；

用于将所述加密的随机会话密钥发送到所述接收装置的模块；

用于利用所述随机会话密钥对所述数据进行加密的模块；以及

用于将所述加密的数据发送到所述接收装置的模块，

24.根据权利要求23所述的装置，其中，所述数据包括音频和视频数据，所述接收装置通过在显示装置上以及经由扬声器发布所述音频视频数据来处理所述数据。