专利名称：用于保证软件更新的方法
技术领域：
本发明涉及一种用于确保不同系统的工作的保证处理软件更新的方法。具体地，本发明的方法使用一种数字签名机制，它具有一个非对称加密算法的私有密钥。
背景技术：
此处将一个系统定义为一个或一组设备，其功能取决于存于非易失性存储器内或硬盘上的一个或数个软件程序。当必须将该系统的功能改进或完善从而适应于用户不断增加的要求时，通常只需将相关软件更新因而不须改变所有用于组成该系统的硬件。
一般都是通过替代早已安装的软件文件或增加新文件以便完善那些早已安装的文件而将给定软件更新的。这类组装件因而组成早先安装在系统中的软件的一个新版本，该系统因而以此方式从所希望的改善中得益。
不同设备例如计算机及其外围设备、自动售货机、固定和移动电话、付费电视解码器等都是由适用于它们配置的和适用于专门部件功能的软件程序所控制的。
例如，在一个付费电视解码器(机顶盒)内，处理软件控制着外围设备例如硬盘、芯片卡读取器、数据接收接口和存储器。为或在配置级别上或在功能级别上引进改变，有时需要替代现有软件或者对早已安装在解码器内的软件加以改善。通过由操作员管理中心所提供的一定数量用户所订购的称为更新软件或补丁的软件部分来实现此类改善。这些更新软件定期地由管理中心提供，并被下载到每个具有必备权利的订户的解码器内。
文件WO98/43431描述了一种用于将应用程序下载到一个接收器/解码器内的方法。该应用软件分为各模块，而在模块的下载之前先在一个确定的本地地址处搜索一个目录模块。各模块被加上签名和该目录模块被加上签名和加密，从而将单个加密应用于组成该应用程序的所有模块。数个公有加密密钥存于接收器/解码器的一个只读存储器(ROM)内。因此能通过不同来源创建该应用程序而不须知道它们每个被获取的私有密钥。目录签名可以隐藏在目录模块的一个任意数据块内的可变位置处。可通过与存储在接收器/解码器内的应用程序有效性位图进行比较而验证待下载的应用程序。
文件WO01/35670描述了一种被传输至一个付费电视解码器的信息证实方法。一个软件对象和一个单独的包含授权数据的数据结构用一个适用于上述这两个对象的全局签名被加上数字签名。这些对象被分别传输至解码器。一旦解码器收到这些对象，该签名被验证。
一般而言，各解码器用户具有一个和操作员签订的订购合同，用于保证对安装在解码器内的软件进行正常维护服务。为限制错误使用，例如非授权复制和引入外部软件部件，保证解码器的软件更新是重要的。一个已知方法包含使用一个通过RSA类型非对称加密算法密钥进行编码的提要。通过一个单向散列函数而获得的提要来在线地提供更新软件。此提要由代表整个更新软件的单个图像组成，并假设在具有不同数据的两个相同的组装件内绝对不存在两个相同的提要。得益于与一组订户相关联的构成一个此组订户所专用的签名的操作员私有密钥，此提要得以加密。由此签名所伴随的软件被装载入解码器的一个RAM(随机访问存储器)内。一个属于解码器软件的程序用于计算一个存于RAM中的具有散列函数的软件的提要。收到的签名使用一个包含于解码器中的公有密钥加以解密，然后与先前计算的软件提要进行比较。如果所解密的签名对应于通过散列函数所获得的提要，则伴随着该存于RAM中的更新软件的签名被认为有效。更新软件将被安装于解码器的非易失性存储器(闪烁存储器)内。
因此通过使用解码器中的对应于操作员私有密钥的公有密钥而验证签名来执行保证过程。
解码器中存在的公有密钥以及允许验证签名的程序必须固定。由于私有密钥取决于解码器公有密钥这一事实而保证签名的证实性。因为私有密钥只有指定的操作员知道，所以签名无法复制。此外，由于签名是一个很好地定义的更新软件的函数，相同的签名无法用于不同的更新过程。一个其内容在RAM中被修改的加上签名的更新软件将会产生另一个提要，而该提要无法被由公有密钥所解密的签名来使得有效。事实上，在将更新软件在解码器级别上使用散列函数后获得的提要不同于将签名解密后获得的提要。
然而，此保证方法具有一个由操作员私有密钥本身所造成的弱点。事实上，当所述密钥被第三方发现时，它能将任何软件加上签名，因而导致系统的被滥用性地修改。
可以如下地实现发现的过程通过将第三方从解码器中提取的公有密钥进行递归演算，直至发现一对正确密钥。由于第三方能够使用合适的程序来避免这些修改，只是修改解码器软件性能而使它拒绝使用所发现的密钥所生成的签名的这一反措施是不够的。
发明内容
本发明的目的是通过解码器软件工作的对称性分析或者可观地增加用于确定所述私有密钥的过程所需的时间和装置，从而显著地减少发现一个私有密钥的威胁。
通过如独立权利要求1中所描述的一种用于在多个设备中将数据更新的保证方法而达到此目的。
更新软件的数据被管理中心以一个补丁和一个控制块的形式被传输，该控制块包括一个由使用来自管理中心的私有密钥进行加密的补丁的提要所形成的签名。解码器将该数据存于RAM中以供处理用。一个与此私有密钥相关联的称为当前密钥的公有密钥被从一个第一非易失性存储器中所存储的清单中选出，从而将补丁签名解密。在解密和验证成功的情况下，执行一条命令，从而导致将补丁安装在解码器的第二个非易失性存储器(闪存)内。以此方式所用的当前密钥随即在清单中停用，使随后的密钥可用于下一次更新操作。
当使用一个来自清单中的公有密钥来验证签名和将解码器解密时，所述密钥被删除，从而无法再一次使用来进行更新。因此，每次更新操作使用一个新密钥，然后从清单中删除。来自清单中的公有密钥以及用于验证签名的程序必须是不能修改的。只有清单能使用验证程序来修改(删除用过的密钥)。
以上描述的方法允许显著地减少已经发现私有密钥的第三方对解码器进行修改的可能性。由于一个密钥只能使用一次，第三方只能执行一个单次修改操作。由此，修改解码器特性从而保护它免受盗窃是更为有效的，因为第三方不再具有有效的私有密钥，也就无法访问该设备。
由于私有密钥数量较大这一事实，第三方必须系统地启用所有密钥以便避免在对应于所发现的密钥的更新操作中被阻挡。必须知道，各解码器的软件的发展很快，如果密钥中的一个被发现，则以下更新操作将阻塞第三方能够进入的安全空隙。如果此第三方能够阻挡所有随后更新操作，则解码器的功能将快速过时，因而对操作员不会构成任何重要损害。
在此意义中，使用非对称密钥是重要的，而从解码器中提取公有密钥并不允许实施一个可接受的更新操作，因为所述更新操作必须有操作员的私有密钥来加上签名。习惯上将私有密钥放置于安全部分(操作员)，而公有密钥放于公共部分(解码器)。当然，有可能将各密钥倒置而不损害本发明的功能。
本发明的第一实施例建议使用从清单中按照预定顺序取出的公有密钥。因此，一旦先前密钥被使用过，立即从清单中取出一个密钥。
参照附图来阅读以下用作非限制性例子的详细说明时，将能更好地理解本发明，附图中图1代表一个解码器从版本N向版本N+1的更新过程。
图2显示一个从版本N向版本R的更新过程。
具体实施例方式
在图1中所公开的例子中，使用补丁P1将初始版本解码器更新至版本1。此补丁P1连同其签名(H(P1))PK1被操作员管理中心传输至解码器。更新过程开始时将补丁P1下载至解码器的RAM中。
通过使用操作员的私有密钥PK1将补丁P1的提要H(P1)加密而获得签名(H(P1))PK1，此操作是在管理中心内执行的。此提要是由操作员使用一个单向散列类型函数H从补丁P1中计算所得。
解码器软件使用一个公有密钥K1将收到的签名(H(P1))PK1解密，从而获得补丁的提要H(P1)1。与此同时，这个相同的软件计算存于RAM中的补丁P1的提要H(P1)2。将从签名的解密操作中获得的第一提要H(P1)1与通过散列函数H所计算的第二提要H(P1)2进行比较。如果两个值彼此对应，则补丁P1被安装在解码器的非易失性闪烁存储器FH中，以便执行解码器软件的更新操作。用于将签名解密的公有密钥K1即从清单中清除。
由管理中心传输的、用由其签名(H(P2))PK2伴随的新补丁P2的形式的从版本1到版本2的第二次更新操作经历相同的下载和验证过程。然后解码器使用从清单中取出的新公有密钥K2。每次使用一个从清单中取出的新公有密钥以相同方式验证所有随后的被传输的更新软件。先前的更新密钥或者被清除或者被打上印记从而被停用。
通过应用此过程，在N-1个步骤中执行从版本1到版本N的软件更新操作。管理中心将传输具有相应的N-1个签名的N-1个补丁，而每个签名都用每个版本所专用的私有密钥进行加密。因此不同补丁的安装导致N-1个公有密钥在清单中停用。
公有密钥的清单可存在例如一个EEPROM(电可擦可编程只读存储器)类型的非易失性存储器内。在每次更新中使用一个密钥之后，所述密钥被确切地从EEPROM中清除，从而授权访问下一个密钥以供下一次更新操作之用。
根据另一个实施例，公有密钥的清单不因密钥的清除或被打印记而改变。在每次将软件版本安装在非易失性闪烁存储器中之后，将一个计数器增量或将一个指针移动以便指示下一次更新操作中将从清单中选出的密钥的位置。因此，在每次更新操作中，将只指定用于将补丁的签名加以解密的密钥，而先前密钥不再能用于选择，因为计数器或指针只能在一个方向内前进，即增加位置的方向。
根据一个变动方案，可由操作员的私有密钥将补丁加密。在以上所述的过程中加入一个补充的解密步骤。收到并下载入RAM的补丁P能在使用用于验证签名的提要的散列函数进行计算之前使用公有密钥解密。也可用其加密形式在补丁上计算提要。
由于每次版本更改都需要知道当前密钥，第三方要实现更新安装就更为困难。每次更新中当前密钥都改变，这迫使第三方必须知道所有密钥以便跟随不同更新操作。
当解码器退出服务一段时间而在此期间应该执行数个更新操作时，以前描述的过程中可能出现一个问题。当一个旧软件版本过渡到一个新版本而该新版本的序号又和先前版本的序号不连续时，要在数个连续的步骤中顺序地执行该过渡操作。所述各步骤使用从清单中一个接一个顺序地取出的不同公有密钥。应该提醒，补丁本身并不包含允许选择当前密钥之外的密钥的命令。如果属于此类情况，则第三方能够使用此命令来强迫使用所述第三方所知道的密钥。
图2显示一个从软件版本N向版本R的更新过程，其中新版本与先前版本之间的差别R-N大于一。该一般方法被描述于独立权利要求11中。
以下例子涉及的情况是N＝2和R＝5。
一个具有版本2软件的解码器无法直接将新版本5的签名(H(P))PK5解密，因为该公有密钥清单中的可用密钥只是较高一级的版本，也即密钥K3。为安装新版本5，解码器必须能够访问对应于此版本的密钥也即密钥K5。
该解决方案在于传输一个包含补丁P的数据流，用于将解码器的软件更新至使用密钥PK5加上签名的版本5，对其加入了多个消息M1、M2、M3、M4，这些消息中的每一个都用从密钥清单中取出的私有密钥PK1、PK2、PK3、PK4进行加密。RAM存储器用于存储这些消息以及带有其签名(H(P))PK5的补丁P。解码器的版本是2，而版本1至2的更新密钥早已被第一次更新操作所停用。因为用于将消息M1解密的密钥K1早已无效，所以消息M1被忽略。
随后的消息M2、M3和M4用于连续地将公有密钥K2、K3和K4停用，这些公有密钥对应于版本5之前的从版本2到版本4的每一个中间版本。因此，为将版本5安装于非易失性闪烁存储器内，清单中的每个公有密钥K2、K3和K4都被使用并然后被停用或删除。在使用正确的密钥将消息解密期间，此消息的内容被确认，并引起当前密钥的停用操作。如果该消息不被确认，则这意味着此消息的加密密钥不是当前密钥。
在将各消息M2、M3和M4连续地并正确地解密之后，为将补丁的签名(H(P))PK5(以及补丁P)解密所需的密钥K5就成为当前密钥。在将补丁安装之后，密钥K5也从清单中被删除，而密钥K6将出现在清单首部，以供随后从版本5到版本6更新之用。
因此，得益于伴随该补丁的密钥更改消息，无论整组解码器的软件版本如何，此类流程都能将它们更新。在停用旧密钥之后，每个解码器掌握清单中的一个能够将当前版本的更新操作加以解密的公有密钥。
在解码器软件将版本N更新至版本R而R-N较大例如大于10的情况下，版本R-1的解码器要将所有消息都系统地解密以便验证停用顺序是很繁琐的。此解码器将其当前密钥(R-1)应用于所有这些消息以便通知它们不能解释其内容。
一个第一解决方案包含在消息首部内引入对应于不同版本序号的明文索引。此索引只用于避免将已经由一个当前密钥之外的密钥加密过的消息进行解密。此索引并不选择当前密钥的位置，只当使用所述当前密钥将消息成功解密后，才在密钥清单中前进一个位置。
根据第二个解决方案，使用先前更新操作的所有私有密钥将更新补丁的提要连续地加密。此过程迫使清单中的每个公有密钥都用于连续地将签名解密。在此链式加密的情况下，和先前情况不同，所有公有密钥必须在解码器的EEPROM中一直保持有效。例如，为了从版本1更新至版本N，使用版本N的一个私有密钥将补丁P的提要加密。然后使用版本N-1的私有密钥将整组加密，再使用版本N-2的密钥，一直继续下去，直至使用版本1。因此该解密操作要求连续地使用对应于从版本1到版本N的从公有密钥K1到公有密钥KN-1。允许通过确认解密结果中的一个合适标记而中断此递归机制。
如果希望保护更新数据，一个方法在于使用一个例如由管理中心随机地生成的对话密钥SK。考虑到运行速度，此密钥是对称类型。管理中心使用对话密钥SK将补丁加密，并建成一组包括对话密钥SK和更新补丁提要的数据。此组数据由操作员的当今私有密钥进行加密以便组成控制块。
加密的补丁和控制块被装载入解码器的RAM存储器内。该块使用清单上的当今公有密钥解密，从而提供补丁提要和对话密钥SK。后者应用于装载于RAM中的补丁从而允许它解密。然后该补丁提要被验证，并在相对应的情况下该补丁被安装在非易失性闪烁存储器内。
在以上描述的任何变动方案中，对话密钥能被引入作为辅助安全装置，例如-以数个步骤从版本1至版本N的简单更新，-使用补丁和密钥停用消息从版本N更新至R。
在一个已经多次更新的解码器中，当停用的密钥数量随着成功更新操作增加时，可用的公有密钥的数量减少。为重建密钥清单以便允许将来进行更新操作，可以由管理中心将一个新公有密钥清单发送至解码器。此清单能被包含入数据流内并在更新补丁的情况下由一个签名伴随。所述清单被存入EEPROM从而替代旧的包含已停用密钥的清单。
根据本发明方法的一个变动方案，管理中心和解码器分别地掌握一个固定的私有和公有密钥清单。对于每次更新，管理中心随机地从清单的私有密钥中选择一个私有密钥组并且连续地使用该组的每个密钥将补丁提要加密。该中心建立一个数据块，它包括加密的提要(签名)和一系列对应于先前选择的密钥位置的数值。所述系列能被明文地传输或使用一个对话密钥加密。接收所述系列的解码器根据公有密钥在清单中的位置从清单中选择为将补丁提要解密所需的密钥。该清单不能多于一次地包括相同密钥号，以及此清单的长度(所用密钥的数量)是已知的和不能修改的。在此变动方案中，密钥清单保持固定以及在成功的补丁安装后并不变动。每次更新时，一个从清单中取出的新的密钥组合用于补丁签名。由此，第三方必须始终掌握一组密钥，才能将一个更新操作引入一个设备，这比确定单个密钥所需装置要求具有更为重要的装置。
根据本发明的更新保证过程是独立于提供商和用户之间所用传输模式的。事实上，该过程也能应用于在CD-ROM上、在盘上或在任何其它数字数据存储介质上发布的补丁。
权利要求
1.一种用于保证多个设备的数据更新的方法，每个设备从一个管理中心接收更新，所述更新包括有称为补丁的数据，并伴随有一个由管理中心所包含的非对称密钥清单中取出的一个非对称密钥加密的控制块，所述方法的特征在于它包括以下步骤-由设备从公有密钥清单中选择一个当前密钥，-接收并存储更新补丁于存储器中，-接收加密的控制块，-由所述当前公有密钥解密所述控制块，-验证被解密的控制块是否与所述补丁相对应，-安装接收的补丁，-停用当前密钥和启动清单中下一个密钥。
2.根据权利要求1的方法，其特征在于控制块包括补丁数据上的签名，所述签名是散列函数的结果，并在于所述控制块的验证包括在接收的补丁上建立一个签名并将其与所述控制块中解密的签名进行比较的步骤。
3.根据权利要求1或2的方法，其特征在于控制块还包括一个由管理中心确定的对称对话密钥(SK)，所述密钥用于将补丁的数据加密。
4.根据权利要求1或2的方法，其特征在于在每次更新时设备使用清单中的一个新公有密钥。
5.根据权利要求1至4中任一项所述的方法，其特征在于在公有密钥被使用之后即在清单中无效，在所有随后更新中所述密钥将无法再用。
6.根据权利要求1至5中任一项所述的方法，其特征在于在每次更新期间，来自清单的公有密钥按预定的次序被顺序使用。
7.根据权利要求1至6中任一项所述的方法，其特征在于公有密钥的清单存于一个非易失性存储器中，一个成功地使用过的密钥被确切地从存储器中删除，所述存储器授权访问下一个密钥并用于下一次更新。
8.根据权利要求1至7中任一项所述的方法，其特征在于为了使设备的软件从版本N升级到版本R，新版本和先前版本之间的差别R-N超过一个单位，加入至少一个由私有密钥PKn加密的消息Mn，使当前密钥Kn改变为清单中随后的密钥Kn+1，所述消息的成功解密使得停用当前密钥Kn和选择下一个密钥Kn+1。
9.根据权利要求8的方法，其特征在于消息的数目对应于分隔设备的初始版本与最后更新版本的更新的数目。
10.根据权利要求1或2的方法，其特征在于安装更新后计数器被增量；或者指针被移动，用于指示清单中下一次更新要选择的密钥的位置，同时保持清单不变。
11.根据权利要求1至4中任一项所述的方法，其特征在于控制块由先前更新密钥连续加密，清单中的每个密钥被先后使用用于解密签名。
12.根据权利要求1至10中任一项所述的方法，其特征在于所述设备包括一个付费电视解码器，由来自管理中心的伴随有一控制块的补丁的远程加载来实现解码器的更新，所述控制块存储在一个随机存取存储器(RAM)中，并由所述解码器的第一非易失存储器中的清单中的一个当前公有密钥解密，然后进行验证，当相符的情况下，一命令导致在一个第二非易失存付器中安装所述补丁，并使当前密钥停用。
13.根据权利要求12的方法，其特征在于一个新的公有密钥清单被传输至该设备，所述清单替代存于第一非易失性存储器内的包含由先前成功的更新操作所停用的各密钥的清单。
全文摘要
本发明涉及一种用于保证多个解码器的软件程序更新的方法，它的基础是使用一个非对称私有密钥生成一个签名。通过从管理中心下载一个包括一个补丁及其签名的数据块而将解码器更新，所述数据块存于一个随机访问存储器内。使用一个来自包含在解码器的第一非易失性存储器内的清单的当今公有密钥将该签名解密，并随后将它验证。在匹配的情况下，一条命令启动将该补丁安装在第二非易失性闪烁存储器内并将当前密钥停用。本发明的目的是显著地减少通过系统地分析解码器软件运行而发现私有密钥的威胁，或者可观地增加用于确定所述私有密钥的过程所需的时间和装置。
文档编号H04N7/16GK1720715SQ200380104959
公开日2006年1月11日 申请日期2003年12月1日 优先权日2002年12月3日
发明者马尔科·撒西利, 尼古拉斯·皮卡恩 申请人:纳格拉影像股份有限公司