安全修补系统的制作方法

专利名称：安全修补系统的制作方法
技术领域：
本发明大致系关于软件更新，且详而言之，系关于分散系统(distributed system)中之软件更新的安全发布(secure distribution)。
背景技术：
许多计算机媒体或通讯系统由于安全的漏洞而让数据被非法存取 或计算机蠕虫(worm)的散布。因此，造成可观的损害。通常是用与 安全有关的软件更新封闭此类的安全漏洞，这种软件更新也被称作修 补(patch)。在分散系统中，可用修补服务器产生修补，然后发布到许 多修补客户端，例如，通讯系统的行动单元或有嵌入式处理器 (embedded processor)的消费者装置。不过，从不安全系统下载的修补仍须加以保护以免被恶意修改。 否则，计算机病毒或蠕虫仍能引起有效的攻击。例如，阻断服务(DoS) 攻击会针对GSM网(全球行动通讯系统)，其中，每一个无线电格(radio cell)中只要有一个主动装置被感染就足以阻断整个系统。在先前技术系统中，公共密钥密码系统(public key cryptography, PKC)，也被称作非对称密码(asymmetric cryptography),常用来藉由 避免在不安全网络传送密钥(secret key)以保护套装软件的发布。基 本概念为有两种钥匙仅用于加密且为大众所知的公共密钥(PK)以及 解密讯息需要知道的私有密钥(private key),也被称作密钥(SK)。该 安全性系取决于由公共密钥推导出私有密钥的困难度以及在不知道私 有密钥的情况下解开加密讯息的困难度。PKC的特殊应用为数字签名。在此，计算出一些文件的密码哈希 计算总合(cryptographic hash sum)，然后用创作者之私有密钥加密此 哈希计算总合以建立该数字签名。以某种方式把该签名附加于文件。 任何一位知道创作者之公共密钥者可计算文件的哈希计算总合，用公 共密钥解密附属的签名并且拿结果与哈希计算文件作比较。替换地，
藉由以创作者的私有密钥将哈希计算总合解密可产生数字签名。为了 验证，收文者可再次计算该哈希计算总合，用公共密钥加密且拿结果 与提供的签名作比较。正确的数字签名可证明其创作者知道私有密钥(真实性，authenticity)且自从签名产生后该文件没有被以增减或修改内容的方式 或者是以重新排列部份内容的方式修改(完整性)。后者系以所使用之密 码哈希计算函数的性质提供，例如，MD5(讯息摘要算法5)、 SHA-1(保 全哈希计算算法1)或RIPEMD-160(完整性原语评价信息摘要160)。不 过，无法知道，例如，在签名产生时私有密钥是否已被盗取。由于不被信任的一方，亦即不知道秘密者，也能检查数字签名， 所以非对称密码常用于数字签名。不过，PKC的缺点为敏感性高且缓 慢。此外，PKC系统的安全漏洞在于有可能遭受中间人攻击 (man-in-the-middle attack)。如果能以某种方式证明公共密钥的真实 性，就可预防这种问题。在有些情况下，计算公共密钥(即所谓的指 纹)的密码核对和(cryptographic checksum)再经由例如电话直接告诉 收文者就可以。不过，在复杂又动态改变的环境中这是不可能的。因 此，为此可使用公共密钥基础建设(PKI)，而公共密钥由可信任的一方 数字地签名。不过，PKI基础建设的实施及维护很昂贵。此外，PKC会有一些其它的风险及问题，例如在使用RSA(瑞未斯 特-希米尔-爱得曼)加密时。除了PKC太慢以外，明文(plaintext)部份还 要填补随机位，否则数种攻击仍有是可能的。因此，通常不直接使用 公共密钥加密明文。反而是，产生随机对话密钥(random session key) 且使用于传统的对称式加密，例如使用像AES(高级加密标准)或双鱼 (Two-fish)这类的算法。在这些被称作混合式协议的协议中，只将对 话密钥以公共密钥加密再加到密文(ciphertext)中。不过，即使使用混合式协议，对话密钥仍需随机填补成，例如， 512或1024个位长度。填补不足会导致安全性降低。此外，如果RSA私有密钥中的位被硬件或攻击者翻转(flip)且然后 用此私有密钥定义讯息，则可将该公共密钥因式分解，从而安全被完 全破解。这在PKC系统中会产生相当程度的风险。此外，在产生公共密钥时可能会被加上暗门(trapdoor)。知道如
何修改生成算法(creation algorithm)的攻击者会有办法轻易地由公共 密钥推论出私有密钥，以致安全再度被完全破解。因此，许多先前技术的修补系统设法避开PKC。在可信任服务器 与客户端(例如，GSM电话中之嵌入式处理器)之间有对话的系统中， 序列化密钥(serialized key)(可能在智能卡(smart card)中)与挑战-响应协议(challenge response protocol)能提供简单且强健的解决方案。 不过，有许多系统无法应用这种方法。例如，当在开机时间接收器为 固定且被动时，不可能做序列化。替换地，各方分享共同秘密的先前技术系统系使用像HMAC(哈希 计算讯息身份验证代码)这类的密码核对和。彼之实施例之一为 GSM/UMTS(全球行动通讯系统/通用行动通讯系统)行动电话的验证及 密钥处理，其系以SIM(用户识别模块，Subscriber Identification Module) 卡发布密钥。与PKC相比，此解决方案较为简单、较快、且较强健。 不过，尽管HMAC密码核对和可证明完整性，对应的密钥会被固定于 EP(嵌入式处理器)接收器的韧体内。因此，泄露此秘密的HMAC密钥 会使所有的核对和变为毫无价值。因此，许多先前技术修补系统利用数字签名。不过，确保完整性 常常不足。如果修补被施加还原工程(reverse engineer),还是可找出安 全漏洞。签名过的修补只证明其真实性，而不是安全性。在作者这边 只能靠信任来提供安全性。此外，对于所有修补客户端，都用相同公 共密钥签名修补会有相当不安全的缺点。如果私有密钥泄露，则所有 的安全性消失。更有可能的情况是遗失私有密钥。就此情形而言，无 法再释出修补以致所有的修补客户端愈来愈不安全。发明内容因此，提供数种改良的修补服务器、修补客户端、以及对应的方 法，其可克服先前技术的缺点。数个实施例可增加秘密保护以及密钥 遗失容忍度(tolerance)。这则可增加投资保障。此外，可改善免于泄 露密钥的保护。其它的实施例在密钥产生仍有安全漏洞的情形下可减 少弱密钥(weakkey)的风险。根据一方面，修补服务器系连接至修补客户端，用以提供修补至
该修补客户端。该修补服务器包含第一密钥产生平台、与该第一密 钥产生平台不相同的第二密钥产生平台、第一密钥选择器、第二密钥 选择器、第一签名产生器、第二签名产生器、以及发送器。该第一密 钥产生平台系经配置成产生包含多个第一私有密钥的第一私有密钥群 组。该第二密钥产生平台系经配置成产生包含多个第二私有密钥的第 二私有密钥群组。该等第一与第二密钥选择器系经配置成各自从该等 第一与第二私有密钥群组选定该等第一与第二私有密钥中之一个。该 第一签名产生器系经配置成基于该修补与该第一选定私有密钥而产生 第一数字签名。该第二签名产生器系经配置成基于该修补与该第二选 定私有密钥而产生第二数字签名。该发送器系经配置成一起发送该修 补以及该等第一与第二数字签名至该修补客户端。 在另一实施例中，该修补服务器进一步包含对话(session)密钥产生器，经配置成产生随机对话密钥；第一加密组件，经配置成使用对称加密算法用该随随机对话密钥 加密该修补；以及第二加密组件，经配置成用主密钥(masterkey)加密该随机对话 密钥；其中该发送器系进一步经配置成一起发送呈加密的形式的该修补 以及该等第一与第二数字签名和该经加密之随机对话密钥至该修补客 户端。在另一实施例中，该修补服务器之该第一加密组件系进一步经配 置成使用该对称加密算法而用该随机对话密钥加密该等第一与第二数 字签名；以及其中该发送器系进一步经配置成一起发送呈加密的形式的该修补 以及呈加密的形式的该等第一与第二数字签名和该经加密之随机对话 密钥至该修补客户端。根据另一方面，提供一种提供修补至修补客户端的方法。使用第 一密钥产生平台产生包含多个第一私有密钥的第一私有密钥群组。使 用不同于该第一密钥产生平台的第二密钥产生平台产生包含多个第二 私有密钥的第二私有密钥群组。从该第一私有密钥群组选定该等第一 私有密钥中之一个，且从该第二私有密钥群组选定该等第二私有密钥
中之一个。基于该修补与该第一选定私有密钥产生第一数字签名。基 于该修补与该第二选定私有密钥产生第二数字签名。将该修补以及该 等第一与第二数字签名一起发送至该修补客户端。 在另一实施例中，该方法进一步包含基于该修补计算出第一哈希计算总合(hash sum);以及 基于该第一哈希计算总合计算出第二哈希计算总合； 其中产生该第一数字签名包含基于该第二哈希计算总合以及该第一选定私有密钥而产生该第一数字签名。在另一实施例中，该方法进一步包含 基于该第二哈希计算总合计算出第三哈希计算总合； 其中产生该第二数字签名包含基于该第三哈希计算总合以及该 第二选定私有密钥而产生该第二数字签名。 在另一实施例中，该方法进一歩包含 计算出多个哈希计算总合； 其中该修补包含多笔记录；其中计算出该等多个哈希计算总合包含基于包含在该修补内之 最后一笔记录计算出该等多个哈希计算总合的第一哈希计算总合；以 及其中计算出该等多个哈希计算总合进一步包含每次基于包含于 该修补内之各自的下一笔最近所用的记录(next last record)以及该等多 个哈希计算总合中之各自的最近计算所得的哈希计算总合而计算出该 等多个哈希计算总合中之另一哈希计算总合。在另一实施例中，产生该第一数字签名包含基于该等多个哈希 计算总合中之最近计算出之哈希计算总合而产生该第一数字签名；以 及其中发送该修补包含 一起发送该修补以及该等第一与第二数字签名和该等多个哈希计算总合至该修补客户端。在另一实施例中，产生该第二数字签名包含基于该等多个哈希 计算总合中之最近计算出之哈希计算总合而产生该第二数字签名；以及其中发送该修补包含 一起发送该修补以及该等第一与第二数字
签名和该等多个哈希计算总合至该修补客户端。 在另一实施例中，该方法进一步包含产生密钥指针(key indicator),该密钥指针包含第一密钥指针， 其指向已从该第一私有密钥群组选定的第一私有密钥，以及第二密钥 指针，其指向已从该第二私有密钥群组选定的第二私有密钥；其中发送该修补包含 一起发送该修补以及该等第一与第二数字 签名和该密钥指针至该修补客户端。在另一实施例中，产生该密钥指针包含产生进一步包含虚拟指针之该密钥指针，该虚拟指针鉴定该等第一与第二数字签名中之一个 为虚拟签名。在另一实施例中，该方法进一歩包含 产生随机对话密钥；使用对称加密算法而用该随机对话密钥加密该修补；以及 用主密钥加密该随机对话密钥；其中发送该修补包含 一起发送呈加密的形式的该修补以及该等 第一与第二数字签名和该经加密之随机对话密钥至该修补客户端。 在另一实施例中，该方法进一步包含'使用该对称加密算法而用该随机对话密钥加密该等第一与第二数 字签名；其中发送该修补包含 一起发送呈加密的形式的该修补以及呈加 密的形式的该等第一与第二数字签名和该经加密之随机对话密钥至该 修补客户端。另一方面系关于一种修补客户端，其连接至修补服务器，用以从 该修补服务器接收修补。该修补客户端包含第一与第二存储构件 (storage means)、第一与第二密钥选择器、以及第一与第二签名验证组 件。该第一存储构件存储包含多个已由第一密钥产生平台产生之第一 公共密钥的第一公共密钥群组。该第二存储构件存储包含多个第二公 共密钥的第二公共密钥群组，该等多个第二公共密钥系由不同于该第 一密钥产生平台的第二密钥产生平台产生。该等第一与第二密钥选择 器系经配置成各自从该第一与第二公共密钥群组选定该等第一与第二 公共密钥中之一个。该第一签名验证组件系经配置成使用该第一选定 公共密钥验证第一数字签名，该第一数字签名与该修补一起从该修补 服务器接收到。该第二签名验证组件系经配置成使用该第二选定公共 密钥验证第二数字签名，该第二数字签名与该修补一起从该修补服务 器接收到。该修补客户端系经配置成只有在验证该等第一与第二数字签名的结果分别显示该等第一与第二数字签名的真实性(authenticity) 与完整性时，才安装该修补。在另一实施例中，该修补客户端进一步包含第一哈希计算器(hasher)，经配置成基于该修补计算出第一哈希 计算总合；以及第二哈希计算器，经配置成基于该第一哈希计算总合计算出第二 哈希计算总合；其中该第一签名验证组件系进一步经配置成基于该第二哈希计算 总合验证该第一数字签名。在另一实施例中，该修补客户端进一步包含第三哈希计算器，经配置成基于该第二哈希计算总合计算出第三 哈希计算总合；其中该第二签名验证组件系进一步经配置成基于该第三哈希计算 总合验证该第二数字签名。在另一实施例中，该第一签名验证组件系进一步经配置成基于 与该修补一起从该修补服务器接收到的第一哈希计算总合而验证该第 一数字签名；以及其中该第二签名验证组件系进一步经配置成基于该第一哈希计算 总合验证该第二数字签名。在另一实施例中，该第一密钥选择器系进一步经配置成根据与 该修补一起从该修补服务器接收到的第一密钥指针而选定该等第一公 共密钥中之该一个；以及其中该第二密钥选择器系进一步经配置成根据与该修补一起从 该修补服务器接收到的第二密钥指针而选定该等第二公共密钥中之该 一个。在另一实施例中，该修补客户端系进一歩经配置成如果与该修 补一起从该修补服务器接收到的虚拟指针分别鉴定(identify)该第一或
第二数字签名为虚拟签名，忽略(disregard)验证该第一或第二数字签名 的结果。在另-一实施例中，该修补客户端进一步包含 存储主密钥的第三存储构件；第一解密(decryption)组件，经配置成使用该主密钥解密与该修补 一起从该修补服务器接收到的经加密之随机对话密钥以得到该随机对 话密钥；以及第二解密组件，经配置成使用该随机对话密钥藉由施加对称解密 算法而解密该修补。在另一实施例中，该第二解密组件系进一歩经配置成使用该随机 对话密钥藉由施加该对称解密算法而解密该等第^一与第二数字签名。在另一实施例中，该主密钥系存储于该第三存储构件内且隐藏于 存储于该第三存储构件的其它信息之中。在另一实施例中，在修补客户端的制造期间，将该主密钥输入于 该第三存储构件内。在另一实施例中，在修补客户端的制造期间，将该第一公共密钥 群组与该第二公共密钥群组分别输入于该等第一与第二存储构件内。根据又另一方面，提供一种安装修补于修补客户端中的方法。该 修补系与第一及第二数字签名一起从连接至该修补客户端的修补服务 器接收到。在该修补客户端中存储包含多个第一公共密钥的第一公共 密钥群组，该等第一公共密钥系已由第一密钥产生平台产生。此外， 在该修补客户端中存储包含多个第二公共密钥的第二公共密钥群组， 该等第二公共密钥系已由不同于该第一密钥产生平台的第二密钥产生 平台产生。该等第一公共密钥中之一个以及该等第二公共密钥中之一 个系各自从该等第一与第二公共密钥群组选定。使用该第一选定公共 密钥验证该第一数字签名，且使用该第二选定公共密钥验证该第二数 字签名。只有在验证该等第一与第二数字签名的结果分别显示该等第 一与第二数字签名的真实性与完整性时，才将该修补安装于该修补客 户端内。在另一实施例中，该方法进一步包含 基于该修补计算出第一哈希计算总合；以及 基于该第一哈希计算总合计算出第二哈希计算总合； 其中验证该第一数字签名包含基于该第二哈希计算总合而验证该第一数字签名。在另一实施例中，该方法进一步包含 基于该第二哈希计算总合计算出第三哈希计算总合； 其中验证该第二数字签名包含基于该第三哈希计算总合而验证该第二数字签名。在另一实施例中，该方法进--歩包--哈希计算总合以及该修补；基于该第一哈希计算总合而验证 基于该第一哈希计算总合而验证从该修补服务器一起接收到負 其中验证该第一数字签名包1该第一数字签名；以及其中验证该第二数字签名包1 该第二数字签名。在另一实施例中，该方法进一步包含从该修补服务器一起接收到第一密钥指针与第二密钥指针以及该修补；其中选定该等第一公共密钥中之该一个包含根据该第一密钥指 针选定该等公共密钥中之该一个；以及其中选定该等第二公共密钥中之该一个包含根据该第二密钥指 针选定该等第二公共密钥中之该一个。在另一实施例中，该方法进一步包含从该修补服务器一起接收到虚拟指针以及该修补；以及如果该虚拟指针分别鉴定该第一或第二数字签名为虚拟签名时， 则忽略验证该第一或第二数字签名的结果。在另一实施例中，该方法进一步包含从该修补服务器一起接收到经加密之随机对话密钥以及该修补； 在该修补客户端中存储主密钥；使用该主密钥解密该经加密之随机对话密钥以得到该随机对话密 钥；以及使用该随机对话密钥藉由施加对称解密算法而解密该修补。 在另一实施例中，该方法进一步包含 使用该随机对话密钥藉由施加该对称解密算法而解密该等第一与 第二数字签名。在另一实施例中，在该修补客户端中存储该主密钥包含存储该 主密钥而隐藏在存储于该修补客户端内的其它信息之中。 在另一实施例中，该方法进一步包含在该修补客户端的制造期间，输入该主密钥于该修补客户端内。 在另一实施例中，该方法进一步包含在该修补客户端的制造期间，输入该第一公共密钥群组与该第二 公共密钥群组于该修补客户端内。


为了解释本发明的原理，将附图并入本说明书且作为本说明书的 一部份。该等附图不视为是要把本发明限定成只是用来图解说明及描 述如何做成及使用本发明的范例。如附图所示，由以上本发明更详细 的说明可更加明白本发明的其它特征及优点，其中图1系根据一实施例而图标修补系统的组件的方块图；图2系根据一实施例而图解说明密钥管理的方块图； '图3系根据一实施例而图解说明公共密钥管理的方块图；图4系根据一实施例而图解说明修补发送的流程图；图5系根据一实施例而图解说明哈希计算链接的步骤；图6系根据一实施例而显示私有密钥选择的流程图；图7系根据一实施例而图解说明签名产生的流程图；图8系根据一实施例而展示KEK加密的步骤；图9系根据另一实施例而图解说明哈希计算链接的步骤的流程图；图IO系根据另一实施例而显示签名产生的流程图；图11系根据一实施例而图解说明修补块的构成；图12系根据该实施例而图解说明密钥指针的组态的方块图；图13系根据另一实施例而图解说明修补块的配置的方块图；图14系根据一实施例而图标传输块的方块图；图15系根据一实施例而图解说明修补的安装过程的流程图；图16系根据一实施例而图解说明公共密钥选择的流程图17系根据一实施例而展示签名验证的流程图；图18系根据另一实施例而图解说明修补安装的流程图；图19系根据另一实施例而图解说明签名验证；以及图20系根据另一实施例而图解说明逐笔记录的修补解密的流程第一密钥产生平台 第三密钥产生平台 150 公共密钥矩阵主要组件符号说明100修补服务器 110 120第二密钥产生平台130 140 修补客户端 160 密钥加密密钥200、 205、 210、 215、 220、 225、 230、 235、 240、 245、 250、 255 私有密钥260第一私有密钥群组 270 第二私有密钥群组280 第三私有密钥群组300、 305、 310、 315、 320、 325、 330、 335、 340、 345、 350、 355共密钥360第一公共密钥群组 370 380 第三密钥群组400、 410、 420、 430、 440、 450、 460、 470步马k480、 490、 510、 520、 530、 540、 610、 620、 630、 710、 720、 730、810、 820、 830、 910、 920、 930、 940、 1010、 1020、 1030步骤公.公共密钥群组膝1100 修补块 11101120 第二数字签名 11301140 密钥指针 11501210 第一密钥指针 12201230 第三密钥指针 1240 1300 修补块1310、 1320、 1330 数字签名 1340 密钥指针1350、 1360、 1370、 1380 密码哈希计算总合1355、 1365、 1375、 1385 记录第一数字签名 第三数字签名 修补第二密钥指针 虚拟指针 1400 传输块1420 加密修补块 1500、 1510、 1520、 1530、 1540、 1630、 1700、 1710、 1720、 1730 1790、 1800、 1810、 1820、 1830、 1930、 1940、 1950、 1960、 1970-2015、 2020、 2030、 2035、 2040、D,第一数字签名 D2D3第三数字签名H2第二哈希计算总合 H31410 加密对话密钥1550、 1560 、 1570、 1610、 1620、1740、 1750、 1760、 1770、 1780、1840、 1850、 1900、 1910、 1920、1980、 1990、 2000、 2005、 2010、 2045、 2050步骤第二数字签名第一哈希计算总合第三哈希计算总合具体实施方式
现在参考附图，描述本发明示范之实施例。修补客户端的软件， 例如，某些装置的嵌入式处理器可从不安全的系统取得修补。该等实 施例可保证在进行修补时这些修补没有被修改。例如，有些病毒或计 算机蠕虫会做成恶意修补。软件或修补本身之中未被发现的安全漏洞 也有可能具有相同的效果。该等实施例可保护修补客户端不会有此类 情况的负面影响。图1系根据一实施例图标修补系统的组件。修补服务器100系连 接至多个修补客户端140以提供该等修补客户端与安全有关的软件更 新，亦即，修补。该等修补客户端可为，例如嵌入式系统、个人计算 机、或媒体/通讯装置。彼等可通过任何适当的联机而连接至该修补服 务器100，例如无线或有线连接。该修补服务器100可为计算机或分布 式计算机系统。根据图标之实施例，该修补服务器100包含3个密钥产生平台110、 120、 130。该等平台110、 120、 130可彼此分开且可用来产生密钥以 及处理。 一般而言，平台系指某种在硬件或软件或两者中能执行软件 的架构。本实施例的密钥产生平台110、 120、 130系基于不同的应用 系统和硬件且可平行使用。这可改善与密钥产 根据该实施例，该第一密钥产生平台110藉助nCipher的一些 nShield HSM而产生及存储密钥。该第二密钥产生平台120可在 Knoppix Linux操作系统下产生及使用密钥。只在RAM(随机存取存储 器)中运作的Knoppix Linux不会在硬盘上留下踪迹。可将产生的密钥 以加密的形式存储于外部。可用OpenSSL在该第二密钥产生平台120 完成密钥处理。此外，可将长通行短语(pass phrase)分割，藉此由两 个不同的人员先后输入通行短语以开启私有密钥供使用。传统但是在 SELinux(安全性增强Linux)系统或某些等价的高安全性操作系统下，该 第三密钥产生平台130可用OpenSSL处理密钥。替换地，第三密钥产 生平台130可使用加密运算卡(cryptocard)。为了增加预防私有密钥泄露的可靠性，nShield可使用秘密分享("n 个操作员卡(operator card)中之k个")。签名处理过程可包含独立的 主体且可将密钥拆开分给第一密钥产生平台110的两位管理人或多组 管理人。本实施例的修补系统是用多个签名签名修补，该等多个签名系使 用藉由密钥产生平台110、 120、 130产生及管理的密钥之变动子集。 也可用密钥产生平台110、 120、 130分别产生对应的公共密钥且于制 造该等修补客户端140时，输入于该等修补客户端140。然后，可将该 等公共密钥存储于在该等修补客户端140中的公共密钥矩阵150。在被传输到该等修补客户端140之前，修补可用随机对话密钥加 以对称加密。接着使用常用于所有修补客户端140的秘密主密钥(也 被称作密钥加密密钥(key encryption key， KEK密钥)160)加密该随机 对话密钥。相对于先前技术PKC系统，这可提供增加的速度与简单性。 此外，可增加加密算法对未知弱点的防护力。由于以同一密钥加密明 文的较小部份以致攻击者要找出弱点比较困难。故可由修补服务器100 安全地存储KEK密钥160。在修补客户端140中，可以隐藏的方式存储KEK密钥160以增加 安全性。为此目的，可结合硬件及软件的措施。例如，可由数个128 位部份(秘密分割)经由XOR(互斥)闸控(gating)建立128位密钥。数 据可分散于程序内且难以找到。此外，利用在程序中数个极为不同的 地方用例如宏执行疯狂的计算以动态方式指定功能指针(flmction pointer)可提供对还原工程的反制(countermeasure)并且使除错器无 法使用。在加密期间以实际上无人知道密钥的方式，可使用这种秘密 分割，而在运行时间期间，只有程序可暂时建立这种秘密分割。在各个修补客户端140卖给使用者之前，可由厂商将公共密钥矩 阵150与密钥加密密钥160插设于修补客户端140内。厂商可将对应 的密钥保存于安全的地方。至于在本实施例中，公共密钥为固定式， 私有密钥的改变为不可能且只能作废。因此，可将私有密钥隐藏于修 补服务器100内。各个修补客户端140可包含不可重设之计数器，其存储最近收到 之修补的序号以避免攻击重演。这使得可防止施加有已知安全漏洞的 较旧修补。为此目的，该等修补客户端140例如可核对和修补一起收 到的时间戳记与广播时间(radio-receivedtime)。各个修补可包含一些修补记录。为了防止利用溢位(overflow)的攻 击，可用软件限制修补记录的数目及大小。可不激活该等修补记录而 只完成修补。因此，不必计算单一修补记录的核对和。根据本实施例，12对密钥用来签名该等修补。各个修补可包含3 个签名，各个签名系基于4个一组中之一个密钥，以下会有更详细的 说明。以下的原理会在第2与3图中图解说明。图2图标一组由修补服务器100产生及管理的私有密钥200至 255。第一私有密钥群组260可包含4个私有密钥200至215。同样地， 第二私有密钥群组270可包含另外4个私有密钥220至235，以及第三 私有密钥群组280可包含另外4个私有密钥240至255。第一、第二及 第三密钥产生平台110、 120、 130可分别产生及处理第一、第二及第 三私有密钥群组260、 270、 280。根据一实施例，3个私有密钥群组260、 270、 280可具有不同的信任等级。在密钥产生平台110、 120、 130中，HSM可用来防止私有密钥200 至255的非法取出。替换地，可使用例如基于HSM和Knoppix/OpenSSL 的"混合式密钥"以提供安全存储和完全信任的优点。此外，这可考虑 到控制密钥产生以及回收密钥而不需另一 HSM装置的情形。可将密钥 200至255的存取权拆开分给非合作群组(non-cooperating group)。此 外，可利用秘密分享(若为HSM，是"5个操作员卡中之3个")的原理。
可将对应的公共密钥存储于修补客户端140的矩阵150内，图3图标更多细节。第一公共密钥群组360可包含4个公共密钥300至315，彼等各自 对应至第一私有密钥群组260的私有密钥200至215。该第一公共密钥 群组360可已由第一密钥产生平台110产生且在制造修补客户端140 期间输入到修补客户端140内。可已由第二密钥产生平台120产生且 由厂商输入到修补客户端140的第二公共密钥群组370可包含4个与 第二私有密钥群组270之私有密钥相对应的公共密钥320至335。最后， 第三公共密钥群组380可由4个公共密钥340至355组成，彼等与第 三私有密钥群组280的4个私有密钥240至255相对应。该第三公共 密钥群组380可已由第三密钥产生平台130产生且在出售前存储于修 补客户端140内。可以标准化格式产生私有密钥200至255。这可提供用于密钥备份 及灾难复原的情形。此外，密钥的产生可不用依赖任何一个安全供货 商(security provider)。在应用RSA加密的实施例中，经由模数(亦即， 秘密质数的pgq乘积)与公开指数(public exponent),公共密钥300至 355可当作C标头直接处理。该等签名可以PKCSW(公共密钥密码系 统标准釘)格式产生，RSA的CryptoCME与BSAFE链接库以及与HSM 装置协作的OpenSSL有支持此格式。在一实施例中，公共密钥300至355可为1024个位长。不过，在 其它实施例中，可用其它的密钥长度。例如，可使用512位的RSA或 DSA(数字签名算法)密钥以节省存储器以及签名核对的计算时间。与 KEK密钥160相反，公共密钥300至355可不必隐藏于修补客户端140 内。根据本实施例，KEK密钥160为用于所有修补客户端140的主密 钥且有128个位的位长度。例如，KEK密钥160可为128位的AES密 钥。替换地，128位的双鱼密钥或256位的AES密钥或任何其它适当 的密钥可用来作为KEK密钥160。应注意，使用12对密钥做出修补的签名只是一特殊的实施例。替 换地，可使用较少或较多的密钥群组(修补服务器100则各自包含较少 或较多的密钥产生平台)且各个公共密钥/私有密钥群组可包含比4个少 或多的公共密钥/私有密钥。此外，矩阵中密钥的排列系经选定而仅供
图解说明。可使用各种其它用于存储公共密钥及私有密钥的形式。具 体言之，可用3个密钥产生平台110、 120、 130分开存储及处理3个私有密钥群组260、 270、 280。基于安全理由，甚至可分开存储各个私 有密钥群组260、 270、 280的个别私有密钥200至255。请参考第4至8、 11、 12及14图，以下根据第一实施例描述修补 服务器100的操作。在此实施例中，该等修补客户端140在读取整个 修补后能够验证由修补服务器100与修补一起收到的签名。图4根据该实施例图标修补服务器100的整体操作。在歩骤400 中，可进行哈希计算链接(hash chain)。该哈希计算链接400可包含4 个步骤，如图5所示。首先，在步骤510中，藉由哈希计算修补而计算出基本哈希计算 总合H。随后，在步骤520中，可藉由哈希计算该基本哈希计算总合H 与一数值为O之字节的串接(HI'O')而计算出第一哈希计算总合H"因此， "卩'系指串接而'O'系数值为0的字节)。然后，在步骤530中，藉由哈 希计算步骤520计算出之第一哈希计算总合a与一数值为1之字节'l' 的串接(H,I'1')而计算出第二哈希计算总合H2。最后，藉由哈希计算步 骤530所得之第二哈希计算总合H2与一数值为2之字节'2'的串接 (H2l'2')而计算出第三哈希计算总合Hs(步骤540)。应注意，根据本实施例，各个修补包含3个在步骤420基于该3 个哈希计算总合Hp H2、及H3而计算出的签名(请参考以下说明)。在 其它实施例中，该等修补可包含较少或较多的签名。因此，在这些实 施例中，哈希计算链接400会较短或较长。请回到图4，此时在步骤410中可选定私有密钥以便在歩骤420 产生签名。根据该实施例，私有密钥选择410的个别步骤系图标于图6。在步骤610中，可由第一私有密钥群组260选出第一私有密钥。 然后，在步骤620中，从第二私有密钥群组270选出第二私有密钥。 同样地，在步骤630中，从第三私有密钥群组280选出第三私有密钥。应了解，图中步骤的顺序系经选定仅供图解说明用。当然，可以 任何其它的次序选定该等私有密钥。替换地，在步骤400进行哈希计 算链接之前可选定一些或所有的私有密钥。此外，在使用私有密钥群 组260至280数目不相同的实施例中，私有密钥选择410可因此包含 比图6中3个歩骤600至630少或多的选择步骤。在私有密钥选择410之后，在步骤420中可产生3个数字签名D, 至D3，随后会将彼等加至待送到修补客户端140的修补以便能检查真 实性与完整性。图7系图标更多私有密钥选择410的细节。在步骤710中，使用在步骤610选出的第一私有密钥，藉由签名 在歩骤520中计算出之第一哈希计算总合f^而可计算出第一数字签名 D"然后，在歩骤720中，使用在歩骤620选出之第二私有密钥群组 270，藉由签名在步骤530所得之第二哈希计算总合H2而可计算出第 二数字签名D2。最后，在歩骤730中，使用在步骤630选出之第三私 有密钥，藉由签名在步骤540计算出的第三哈希计算总合H3而可计算 出第三数字签名D3。因此，本实施例所用的3个签名各自基于每一种 的一个密钥。因此，签名哈希计算总合H,至H3的各个步骤可包含另一哈希计 算运算接着使用各自选定的私有密钥加密(或解密，这取决于所用的签 名算法)。替换地，藉由用对应选定之私有密钥简单地加密或解密各个 哈希计算总合K至H3而可计算出数字签名D至D3。其它的算法可用 来产生数字签名D,至D3系取决于密钥产生平台110至130用于哪一种 实作。此外，图7图标之步骤的特定顺序仅供图解说明用。在其它实施 例中，可以任何次序产生数字签名D,至D3或签名产生420的步骤可 与哈希计算链接400及/或私有密钥选择410的步骤交错。例如，在刚 计算出第一哈希计算总合H"步骤520)以及选定第一私有密钥(步骤 610)后，就可进行计算第一数字签名D，的步骤710。第二数字签名D2 的计算720可以类似的方式进行。此外，对于将较多或较少数位签名 加至修补的实施例，签名产生420可因此包含较多或较少的计算歩骤。在步骤420中产生签名后，在步骤430可判断该等签名中之一个 是否应为虚拟签名(dummy signature)。使用虚拟签名使得安全地跳过被 破解(compromised)或遗失的密钥成为可能。例如，如果在步骤610 至630中之一个步骤中，选出的私有密钥已知被破解时，在步骤430 可判断对应的数字签名应为虚拟签名。对于此目的，修补服务器100 可以适当的形式存储哪些私有密钥200至255己被偷或遗失，亦即，
不会再使用的密钥。例如，藉由维护对应査找表可做成此功能。因此， 根据本实施例，可安全地跳过遗失或被偷的密钥。而不需作废或更换 这些密钥。如果要使用虚拟签名，在歩骤440中可用虚拟签名取代各由步骤420产生的数字签名。替换地，在签名产生之前，可进行是否签名应为 虚拟签名的判断430，且如果签名应为虚拟签名，可跳过对应的签名产 生步骤710、 720、 730，而各个签名直接使用虚拟签名。在歩骤450中，可产生密钥指针。该密钥指针可记录在步骤410 从3个私有密钥群组260、 270、 280之中选出的密钥。图12中图标该 密钥指针的示范构成元素。根据本实施例，该密钥指针为8位整数值。前两个位可表示第一 密钥指针1210，其指定第一私有密钥群组260的4个私有密钥200至 215中之哪一个己被选定用来产生第一数字签名D,。例如，如果前两 个位的数值为3，这表示在步骤610中已选定第三私有密钥210且用于 步骤710。下两个位可建立第二密钥指针1220，其表示第二私有密钥 群组270的4个私有密钥220至235中之哪一个已被选定(步骤620)用 来产生第二数字签名(步骤720)。同样地，第三密钥指针1230可用第 五及第六位指定已在步骤630选定4个私有密钥240至255之中的哪 一个是用来在步骤730产生第三数字签名。在使用较多或较少私有密钥群组的实施例中，密钥指针可因此包 含较多或较少的个别密钥指针1210至1230。此外，有些实施例是每一 私有密钥群组260、 270、 280包含比4个多或少的私有密钥。因此， 各个第一至第三密钥指针1210至1230可较长或较短。此外，个别密 钥指针1210至1230的顺序可不相同。密钥指针可进一步指定是否已使用虚拟签名，若是的话，是签名 中哪一个为虚拟签名。为此目的，图12中密钥指针用最后两个位表示 虚拟指针1240。根据本实施例，该虚拟指针1240指定所有3个签名 D,至D3中，如果两个位的数值为O时，则该等签名为有效的签名。]、 2或3的数值可分别表示第一、第二或第三签名为虚拟签名。替换地， 虚拟指针当然可分配不同的数值。—在其它实施例中，可使用比3个多或少的签名签名修补。虚拟指
针1240因此可比2个位长或短。此外，1个以上的签名可为虚拟签名。在该等实施例中，虚拟指针1240也可比2个位长。 一旦产生密钥指针 后，在步骤460中可组合修补块(patch block)。根据本实施例，该修补 块具有图标于图11的格式。如图11所示，该修补块1100可以在歩骤710产生第一数字签名 1110开始，接着分别在步骤720与730中产生第二数字签名1120与第 三数字签名1130。在签名1]]0至1130之后，该修补块1100可包含由 步骤450得到的密钥指针1140。最后，修补块1140可包含修补1150 本身。图标于图11之修补块1100的特定构成元素不应被视为是要限 定本发明。在其它实施例中，可以不同的的方式配置修补块1100。在修补块组合460之后，在步骤470可进行KEK加密。图8中系 图标根据本实施例之KEK加密470的更多细节。在步骤810中，可产生随机对话密钥，以下也被称作对称密钥。 通行短语的拆开部份可保全对话密钥的产生，例如用nCipher HSM装 置的操作员卡上的共享秘密。在其它实施例中，在修补传输处理期间 不产生该对称密钥，反而是先行产生且存储于修补服务器100。在该等 实施例中，可将对称密钥隐藏于硬件内。这可用各种方式实现。例如， 由于会有很多人检査这个代码，由数个分散来源产生密钥可用于此目 的，使得无人知道密钥如何产生的所有细节，但在必要时可重建所有 的信息。替换地，可将对称密钥隐藏于某些HSM内。此外，该等实施 例的修补服务器100可包含一些硬方法(hard method)以便在遗失时 重建对称密钥。步骤820中可使用随机对话密钥加密在步骤460组合的修补块 1100。这可用AES加密来完成。最后，在步骤830中使用KEK密钥 160加密该随机对话密钥。在其它实施例中，可以相反顺序进行步骤 820与830。在KEK加密470期间，可以输出反馈模式(OFB)加密所有的信息 (除了基于一些理由需呈明文的标头部份以外)。这使得修补随后在修补 客户端140可被译码成串流(stream)。不需填补(padding)且可进行 逐笔记录的解密而不会有任何问题。在替代性的实施例中，串流加密 可改用加密反馈模式(CFB)。 CFB模式与明文相关且错误会散布至少一
个修补块。然而，如果使用OFB模式，即使只有一个位被某一攻击者 翻转或添加也会有与被毁修补块一样的致命效果，而且在这两种情况下在修补客户端140的数字签名验证会失败。所以，使用OFB模式能增强安全性。由于在进行KEK加密步骤470之前已使数字签名Di至D3内含于 修补块1100(步骤460)，也根据本实施例用加密保护该等数字签名。这 可降低攻击者找到安全漏洞的风险。为了致使对称式KEK加密470更加安全，OFB模式中使用的初始 化向量(initializationvector)可经选定为唯一，亦即，使彼等在所有修 补中决不重复。这可藉由例如在初始化向量的固定部份中包含序号达 成。替换地，可使用用于此目的的时间戳记。现在请参考图4，在步骤480中可组合传输块(transmission block)。本实施例之传输块的构成元素系图标于图14。具体言之，传输块1400可分别由步骤830、 820所得之加密对话 密钥1410接着加密修补1420而构成。根据本实施例，加密对话密钥 为128个位长。替换地，在其它实施例中也可使用其它长度的对话密 钥。 '最后，在歩骤490中，可将传输块发送到修补客户端140。如前述，在签名期间的硬件失败可能会泄露私有密钥。为了避免 此风险，在送到修补客户端140(步骤490)之前，可核对步骤420中产 生的签名。因此，可用不同的程序核对各个签名Di至D3。例如，可由 厂商验证(尚未出售)修补客户端140在开机时是否有包含待核对之签 名的实际修补。根据上述实施例，修补客户端140中数字签名D!至Ds的验证有 可能是只在读取整个修补1150之后。不过，在其它的实施例中，可能 希望在译码每笔修补后立即检査真实性与完整性。这在第二实施例中 是有可能的，而现在将参考第9、 10及13图而予以说明。在此实施例中，修补服务器100的整体操作可与图4中的操作相 对应，且私有密钥选择410、虚拟处理430与440、密钥指针产生450、 KEK加密470、以及传输块的组合与传输480与490可与上述的相同。 不过，可使用经修改之哈希计算链接400与签名产生420。此外，修补
块组合460可能产生构成元素与上述不同的修补块。首先与本实施例有关的修补块及其构成系图标于图13。与第一实施例的修补块1100相似，修补块1300可由3个数字签 名(D,至D3)1310、 1320、 1330开始，接着密钥指针1340。密钥指针 1340可对应至以上参考第11、 12图所描述的密钥指针1140。不过， 数字签名1310、 1320、 1330的计算方式可不同于第一实施例的数字签 名，以下将参考图10而加以解释。此外，修补的每笔记录(R,至Rn)1355、 1365、 1375、 1385的前面为密码哈希计算总合(H,至HJ1350、 1360、 1370、 1380。根据本实施例，哈希计算总合1350、 1360、 1370、 1380的计算是 在图4的歩骤400中进行且在图9中图标更多细节。首先，在步骤910中，藉由哈希计算待传输修补之第n笔记录Rn 1385与由0值位构成之哈希计算总合值"Q"的串接(Rn防可计算出哈希 计算总合Hn 1380。在其它的实施例，在歩骤910中只有将记录Rn加 以哈希计算。然后，在歩骤920中，藉由哈希计算第(n-l)笔记录Rn_] 1375 与前一个计算出之哈希计算总合Hn 1380的串接(R^IHn)计算出哈希计 算总合H^ 1370。接着，在步骤930至940中以类似的方式计算出哈 希计算总合Hn-2至H^在其它实施例中，可跳过最后一个步骤940， 且在随后的歩骤中第一记录&用来取代由歩骤940所得之哈希计算总 合H,。不过，图标于图9之实施例的编程(programming)比较简单和强 健。根据本实施例，经修改之签名产生420系图标于图10。 在步骤1010中，藉由使用在图6步骤610选出的第一私有密钥签 名(亦即，哈希计算及译码/加密或简单译码/加密，如在描述图7时所 述)第一哈希计算总合H, 1350而可计算出第一数字签名D, 1310。在步 骤1020中，藉由使用在步骤620选定的第二私有密钥签名第一哈希计 算总合Ht 1350而可因此计算出第二数字签名D2 1320。最后，在步骤 1030中，藉由使用在步骤630所得之第三私有密钥签名第一哈希计算 总合^ 1350而可产生第三数字签名D3 1330。图标步骤之顺序不应被视为要限定本发明。例如，可以不同的次 序计算数字签名D,至D3。此外，计算步骤1010至1030可与图标于图 6之私有密钥选择及/或图标于图9之哈希计算链接交错。例如，在刚 计算出第一哈希计算总合H,以及选定对应的私有密钥后，就可计算出 数字签名D,至D;3。一旦修补服务器100已将包含加密修补的传输块1400送到修补客 户端140后，可使用公共密钥矩阵150与KEK密钥160而将该修补安 全地安装于修补客户端140。此吋参考第15至17图，其系根据一实施 例描述由修补客户端140完成的安全修补安装过程。于只在解密整个 修补之后验证数字签名D,至D3 1110、 1120、 1130的实施例中，可使 用此修补安装过程。首先请参考图15，在歩骤1500中修补客户端140可收到传输块 1400。然后，在歩骤1510中可使用KEK密钥160解密经加密之随机 对话密钥1410。在歩骤1520中，在AES算法下使用在步骤1510之前 得到的随机对话密钥可解密经加密之修补块1420。使用以上在描述图 8时所述之OFB模式可达成步骤1510与1520的解密。在步骤1530中，可选定待用来验证签名的公共密钥。更多细节会 图标于图16。首先，在步骤1.610中，使用在步骤1520之前被解密的第一密钥 指针1210从第一公共密钥群组360可选出第一公共密钥。具体言之， 可选定在公共密钥300至315之中的密钥(第一密钥指针1210指向该 密钥)作为第一公共密钥。经选定的第一公共密钥可与在步骤610被 选定修补服务器100的第一私有密钥相对应(请参考图6)。因此，步骤 1620与1630可包含各自使用第二与第三密钥指针1220、 1230,各 自从第二与第三公共密钥群组370、 380选出第二与第三公共密钥。第 二与第三公共密钥可分别与各自在步骤620与630被修补服务器100 选定的第二与第三私有密钥相对应。当然，可用任何一种次序进行公共密钥选定步骤1610至1630。此 外，在使用比3个多或少的公共密钥群组360至380(且因此有比3个 多或少的私有密钥群组260至280)的实施例中，公共密钥选择1530可 因此包含较多或较少的选择步骤。在选定公共密钥后，在步骤1540可验证签名1110至1130。图17 系根据本实施例图标签名验证的子步骤(substep)。
首先，在步骤700中进行哈希计算链接。根据该实施例，由修补客户端140进行的哈希计算链接700系与由以上在说明图5时所描述 之修补服务器100形成的哈希计算链接相对应。然后，在步骤710中，各自从步骤520、 530及540得到的哈希计 算总合H1、 H2及H3可再度加以哈希计算。在由修补服务器100于歩 骤710至730进行的签名歩骤不包含进一步的哈希计算而只有解密/加 密的实施例中，步骤1710可跳过。在步骤1710之后，在步骤1520解密经加密之修补块1420时所得 到的数字签名(D,-D3)1110、 1120、 1130可分别用第一、第二及第三公 共密钥解密。然后，在步骤1750至]770中，由步骤1720至1740得到的经解 密之数字签名可与在歩骤1710得到经再度哈希计算之哈希计算总合 H,至H3相比较。在跳过歩骤1710的实施例中，经解密之数字签名可 各自直接与哈希计算总合H)至H3相比较。在步骤1780中，可判断数字签名(DrD3)1110、 1120、 1130之中是 否有虚拟签名。这可藉由检查密钥指针1140的虚拟指针1240达成。若有的话，在步骤1790中，可决定在其余的安全修补安装过程期 间忽略以虚拟指针1240鉴定为虚拟签名的数字签名。在其它实施例中， 如上述，会有l个以上的数字签名可能为虚拟签名。在该等实施例中， 在其余的修补安装过程期间可忽略所有的虚拟签名。如果步骤1780显示虚拟指针1240指定所有的数字签名1110至 1130均为有效的签名，亦即，没有虚拟签名，则不会进行步骤1790且 在安全修补安装的其余步骤期间会将所有的数字签名1110、 1120、 1130 纳入考虑。一旦在步骤1540验证签名后，在步骤1550中可判断所有的数字 签名1110、 1120、 1130是否正常。根据本实施例，如果比较步骤1750 至1770的结果为相等则成立。若是如此，在步骤1560中可安装修补 于修补客户端140内。步骤1560可包含向修补客户端140的使用者 提供修补安装成功的报告及/或因此通知修补服务器100。不过，如果步骤1750至1770中之至少一个显示经解密之数字签 名与对应哈希计算总合(已被哈希计算)不相同时，在歩骤1570中可决 定不将所收到的修补安装于修补客户端140内。这可包含，例如，向 使用者提供错误讯息及/或通知修补服务器100修补安装失败。应了解，第15至17图中步骤的特定顺序系经选定仅供图解说明用。在其它实施例中，可以不同的次序排列个别的子步骤，例如，解密步骤1720至1740可与比较步骤1750至1770相互交错。此外，可 将哈希计算步骤1710分为3个个别的子步骤，彼等也可与比较步骤 1720至1770的解密相互交错。此外，哈希计算链接1700的个别歩骤 510至540可分散于哈希计算解密与比较步骤1710至1770之中。此外，在使用较多或较少个私有密钥及公共密钥群组的实施例中， 签名验证1540可因此包含较多或较少的哈希计算、解密及比较步骤 1710至1770。此外，在第一解密步骤1720之前或甚至在签名验证1540开始时 或公共密钥选择1530之前，可进行步骤1780与1790的虚拟处理。如 果在该等实施例的步骤1780中判断特定的签名1110、 1120、 1130为虚 拟签名，则公共密钥选择1530与签名验证1700至1770的对应步骤可 跳过。例如，如果第三数字签名D3为虚拟签名，则不需计算步骤540 的第三哈希计算总合H"选出步骤1630的第三公共密钥、哈希计算步 骤1710的第三哈希计算总合H"解密步骤1740的第三数字签名、及/ 或进行步骤1770的比较。如上述，本实施例的修补安装计画使得只在整个加密修补块1420 已被解密之后才能验证签名。不过，有的实施例是想要在修补有已被 解密的记录后就立即验证修补是否可安装。以上在说明第9、 10、 13 图时己描述该实施例中之修补服务器100的操作。此时，参考第18至 20图描述待由修补客户端140完成的对应安全修补安装。在图18的歩骤1800中，在修补客户端140可收到传输块1400。 在步骤1810中，使用KEK密钥160解密内含于该传输块1400的加密 随机对话密钥1410。此步骤可对应至图15的步骤1510。随后，在歩骤1820中，在步骤1810得到的随机对话密钥可用来 解密内含于加密修补块1420的信息。步骤1820完成解密的方式可与 步骤1520完成解密的方式相同。不过，根据本实施例，在步骤1820 中可以只将经加密之签名和经加密之密钥指针解密。随后在歩骤1840
与1850中可将经加密之修补块1420的其余部份以逐笔记录的方式解在歩骤1830中，公共密钥的选定可基于在步骤1820取得的密钥 指针1340。这可对应至以上在说明图15时所描述的公共密钥选择 1530。然后，在步骤1840中，可验证在步骤1820得到的数字签名(D, 至D3)1310、 1320、 1330。图19中有详细图标。首先，在步骤1900中，传输块1400所收到之修补的经加密之第 一哈希计算总合以及经加密之第一记录可用步骤1810得到的随机对话 密钥解密。达成的方式可与以上在解释图15时所描述之步骤1520的 解密相同。随后，在步骤1910中可哈希计算在步骤1900回收的第一 哈希计算总合H, 1350。在其它实施例中，特别是，在步骤1010至1030 由修补服务器100完成签名的步骤不包含任何哈希计算的实施例中， 可跳过步骤1910。随后，在步骤1920至1940中，使用在步骤1830中选出的第一至 第三公共密钥可分别将由步骤1820得到的数字签名(D,至D3)1310至 1330解密。然后，在歩骤1950至1970中，步骤1920至1940的每个 结果可分别与步骤1910的结果比较。反之，在跳过步骤1910的实施 例中，由步骤1920至1940得到的经解密之签名可与从步骤1900得到 的哈希计算总合H,相比较。最后，在步骤1980与1990中可进行虚拟签名的处理。这可对应 至以上在说明图17步骤1780与1790所描述之虚拟签名的处理。此外，第18与19图中步骤的特定顺序为仅供图解说明用且不应 被视为要限定本发明。在其它实施例中，各个步骤的次序可不相同， 例如交错的顺序。此外，例如，在签名验证1840开始时或在公共密钥 选择1830之前，可进行歩骤1980与1990的虚拟签名处理。在该等实 施例中，可跳过以下所有的歩骤与被虚拟指针1240鉴定为虚拟签名 之数字签名有关的公共密钥选择1830与签名验证]900至1970。现在请参考图18，在步骤1850中，可以逐笔记录的方式解密经加 密之修补块1420的其余部份。根据本实施例逐笔记录的修补解密计画 系图标于图20。因此，首先在步骤2000中可检查所有的签名D,至D3是否正常。
步骤2000可包含判断所有的比较步骤1950至1970的结果是否相等。如上述，对于此判断，最后几个虚拟签名可不纳入考虑。如果判断为否，亦即，经解密之数字签名Dt至D3中之至少一个 不同于(经哈希计算之)哈希计算总合H,，在歩骤2050中可决定不安装 本修补。这可对应至图15的步骤1570。不过，如果所有的签名都正常，内含于加密修补块1420的第二加 密哈希计算总合与第二加密修补记录可用在步骤1810得到的随机对话 密钥解密。步骤2005完成解密的方式可与上述步骤1820完成解密的 方式相同。然后，在步骤2010中，可哈希计算第一记录R, 1355(已在 步骤1900得到)与在步骤2005得到之第二哈希计算总合H2 1360的串 接(Ri陶。结果可与先前得到的哈希计算总合Hi 1350(在解密步骤1900)相比 较。如果歩骤2020判定这两个哈希计算总合不相等，则修补解密计画 可前进到步骤2050而决定不安装该修补。否则对于第三至最后一个哈 希计算总合以及加密修补块1420中的记录，可因此分别重复步骤2005 至2020。如果步骤2020的比较对于所有经解密之哈希计算总合和记录有正 面的解答，则在步骤2030可计算出最后一笔修补记录Rn 1385与由O 位构成之哈希计算总合数值"O"的串接(igO)。在步骤2035，此数值可 与修补块1300的最后一个哈希计算总合Hn 1380相比较。如果在步骤2040判断两个数值为相等，则在步骤2045可安装修 补，且可通知使用者及/或修补服务器IOO修补安装成功。否则，在步 骤2040决定不安装该修补。根据图标于第18至20图的实施例，在步骤2045中不是完全安装 所收到的修补就是不安装，即使只有一个修补记录损坏。在该实施例 中，修补中只要有一个翻转的位或增减的字节就足以阻止修补客户端 140的激活。这可增加安全性，例如，防止以让使用者认为只是收到畸 形修补的方式修改修补的计算机蠕虫。不过，在其它实施例中，在不需要有此程度的安全性时，修补的 记录1355、 1365、 1375、 1385各自对于步骤2000、 2020或2040的解 答为正面时就可安装。因此，对于步骤2000、 2020或2040的负面解
答在步骤2050不会导致忽略整个修补而只对记录1355、 1365、 1375、 1385做一般性的检查。在此类系统中，藉由在收到修补时强迫使用者 检查例如MD5总合或在修补安装过程中包含一些初诊检查，仍可增强 安全性。由于OFB模式可使错误局部化，OFB加密模式只能用于修补 的个别记录1355、 1365、 1375、 1385。根据所描述的实施例，安全修补安装过程系由修补客户端140自 动完成且使用者对于处理不会有任何影响。此外，使用者也没有看见 修补客户端140内部发生何事的任何可能性。不过，在歩骤1570或2050 仍会提供使用者错误讯息或在步骤1560或2045报告修补已正确安装。此外，根据本实施例，所描述的安全功能被关掉是不可能的。这 可防止由"影子"变量报告有关取消安全密码(security disable pin)的状 态而引起的攻击。在基于效能的理由关掉安全功能的实施例中，可保 证这个变量不会被任何软件修改。这是因为设定该变量的软件也会被由以上实施例的说明显而易见，本发明可提供用于更新软件的方 法与系统且增加秘密保护和密钥遗失的容忍度。特别是，藉由使用密 钥产生平台110、 120、 130而可显著增加安全性。藉由组合源自不同产生平台110、 120、 130的密钥，可降低如果 用于产生密钥的平台110、 120、 130有安全漏洞所致之弱签名密钥的 风险。通常这种风险会在嵌入新密钥之硬件中造成硅有变化的问题， 因此相当昂贵。因此，建议在不同平台110、 120、 130上产生密钥的 组合也可降低产品及维护成本。藉由使用位指针1140、 1340 (其系指向从矩阵150选出的密钥) 可实现密钥遗失(亦即，在无法使用密钥的情形下)的保护。从而， 如果遗失密钥，可避免变更硬件或使用作废清单的需要。此外，建议从由12个密钥构成之矩阵选出的3个密钥使用于3个 数字签名D,至D3可增加在密钥泄露/被偷的情形之下的保护，从而可 供大众使用。这使得攻击者更加难以插入假造的修补。为了安排攻击 需要盗取至少一整组的3个密钥(可用不同的方法或实体保护)，而这组 密钥是由密钥矩阵的3栏260、 270、 280形成。即使在此情况下，假 若不知的欠周详(indiscretion)，所有修补客户端140之中只有约64分
之一会被假造的蠕虫感染。对于已知的欠周详，理论上达10个密钥才 可被破解而不破坏安全性上述有2个位之密钥指针1140、 1340的虚拟指针1240可容许破解一个私有密钥群组260、 270、 280之中的所有 4个密钥。在使用4个签名且不容许虚拟签名的替代实施例，机率甚至 由1/64降到1/256(在此必须泄露至少4个私有密钥)。不过，在该等实 施例中，各个私有密钥群组必有至少一个有效密钥可维持安全性。以上在说明第5及9图时所描述的哈希计算链接可允许包含不同 的机构在签名处理时无一机构能够知道所签名的是否为同一个修补套 装软件。在有些情况下这可提供进一步的安全性，同时成本不变。此外，第5及9图的哈希计算链接提供重要的安全胜利。最新的 结果暗示密码哈希计算函数(例如，MD5与SHA-O(保全哈希计算算法 O))有致命的瑕疵。不清楚SHA-1是否可破解甚至是否可以可用方式 破解。不过，即使用相同的SHA-1哈希计算值可构成有不同意义的文 字，完全不切实际的是，若由图标于第5及9图的哈希计算链接提供， 这对2个甚至更多个的链接哈希计算而言是有可能的。建议的概念保证有极佳的修补完整性，其使用数个数字签名D,至 D3，使用与周全密钥管理结合的异质公共密钥。即使在只使用'HSM密 钥的实施例中，安全性仍然很高。藉由用可藏在修补客户端韧体内的 KEK密钥加密可保护修补内容。在可信赖的第三方(TTP)涉入安全处理的实施例中，只有哈希计算 值才需要加以签名。从而可进一步增强安全性，因为可避免显露修补 来源的风险。相较于增益，建议之解决方案的成本低。修补开发及发布远比密 钥处理、备份、数字签名及加密昂贵，即使在此过程涉及数个实例的 实施例中。修补客户端140的制造成本几乎不变且添加所描述之安全 修补功能所增加的成本也有限。在修补客户端140开机期间解密及签 名检查可能需要最少的时间。不过，安全性胜过先前技术简单的修补 系统很多。因此，本发明实施例可显著增加修补系统的安全性、可靠 性及效率，而不会过当地增加对应的成本。尽管已用依照本发明所述构成的实际实施例描述本发明，显然对 熟谙此艺者而言，根据上述教导且在随附之申请专利范围的范围内可
做出各种本发明的修改、变体及改进而不脱离本发明的范畴。此外， 相信本技艺一般技术人员已熟悉的领域在本文中不需再加以描述以免 不必要地混淆在本文中所描述的发明。因此，应了解，本发明不受限 于特定的示范实施例，而只受限于随附申请专利范围的范畴。 产业上利用性本发明的实施例可应用于计算机技术领域，而因此可用于工业领域。
权利要求
1、一种修补服务器(100)，连接至修补客户端(140)，用以提供修补(1150、1355、1365、1375、1385)至所述修补客户端，该修补服务器包含第一密钥产生平台(110)，经配置成产生包含多个第一私有密钥(200至215)的第一私有密钥群组(260)；第二密钥产生平台(120)，与所述第一密钥产生平台不相同且经配置成产生包含多个第二私有密钥(220至235)的第二私有密钥群组(270)；第一密钥选择器，经配置成从所述第一私有密钥群组选定(410、610)所述第一私有密钥中的一个；第二密钥选择器，经配置成从所述第二私有密钥群组选定(410、620)所述第二私有密钥中的一个；第一签名产生器，经配置成基于所述修补以及所述第一选定的私有密钥而产生(420、710、1010)第一数字签名(1110、1310)；第二签名产生器，经配置成基于所述修补以及所述第二选定的私有密钥而产生(420、720、1020)第二数字签名(1120、1320)；以及发送器，经配置成一起发送(490)所述修补以及所述第一与第二数字签名至所述修补客户端。
2、 如权利要求1的修补服务器，进一步包含 第一哈希计算器，经配置成基于所述修补而计算出(400、 510)第一哈希计算总合；以及第二哈希计算器，经配置成基于所述第一哈希计算总合而计算出 (400、 520)第二哈希计算总合；其中第一签名产生器进一步经配置成基于所述第二哈希计算总合 而产生(420、 710)所述第一数字签名。
3、 如权利要求2的修补服务器，进一歩包含 第三哈希计算器，经配置成基于所述第二哈希计算总合而计算出 (400、 530)第三哈希计算总合；其中所述第二签名产生器进一步经配置成基于所述第三哈希计算总合而产生(420、 720)所述第二数字签名。
4、 如权利要求1的修补服务器，进一步包含哈希计算器，经配置成计算出(400、910至940)多个哈希计算总合; 其中所述修补包含多个记录(1355、 1365、 1375、 1385); 其中所述哈希计算器进一步经配置成基于包含于所述修补内的最 后一个记录(1385)而计算出(400、 910)所述多个哈希计算总合的第一哈希计算总合；以及其中所述哈希计算器进一步经配置成基于包含于所述修补内的 各自的下一个最近的记录以及所述多个哈希计算总合中的各自的最近 计算出的哈希计算总合而计算出(400、 920至940)所述多个哈希计算总 合中的每一个进一步的哈希计算总合。
5、 如权利要求4的修补服务器，其中所述第一签名产生器进一步 经配置成基于所述多个哈希计算总合中的最近计算出的哈希计算总合 而产生(420、 IOIO)所述第一数字签名；以及其中所述发送器进一步经配置成一起发送所述修补以及所述第一 与第二数字签名和所述多个哈希计算总合至所述修补客户端。
6、 如权利要求4或5的修补服务器，其中所述第二签名产生器进 一步经配置成基于所述多个哈希计算总合中的最近计算出的哈希计算 总合而产生(420、 1020)所述第二数字签名；以及其中所述发送器进一步经配置成一起发送所述修补以及所述第一 与第二数字签名和所述多个哈希计算总合至所述修补客户端。
7、 如权利要求1至6的修补服务器，进一步包含 密钥指针产生器，经配置成产生密钥指针(1140、 1340)，所述密钥指针包含第一密钥指针(1210)，指向已从所述第一私有密钥群组选定 的第一私有密钥，以及第二密钥指针(1220)，指向已从所述第二私有密 钥群组选定的第二私有密钥；其中所述发送器进一步经配置成一起发送所述修补以及所述第一 与第二数字签名和所述密钥指针至所述修补客户端。
8、 如权利要求7的修补服务器，其中所述密钥指针产生器进一步 经配置成产生进一步包含虚拟指针(1240)的所述密钥指针，所述虚拟指 针(1240)鉴定所述第一与第二数字签名中的一个为虚拟签名。
9、 一种提供修补(1150、 1355、 1365、 1375、 1385)至修补客户端 (140)的方法，包含使用第一密钥产生平台(110)产生包含多个第一私有密钥(200至 215)的第一私有密钥群组(260);使用不同于所述第一密钥产生平台的第二密钥产生平台(120)产生 包含多个第二私有密钥(220至235)的第二私有密钥群组(270);从所述第一私有密钥群组选定(410、610)所述第一私有密钥中的一个，从所述第二私有密钥群组选定(4，10、 620)所述第二私有密钥中的一个；基于所述修补与所述第一选定私有密钥产生(420、 710、 IOIO)第一 数字签名(1110、310);基于所述修补与所述第二选定私有密钥产生(420、 720、 1020)第二 数字签名(1120、 1320);以及一起发送所述修补以及所述第一与第二数字签字至所述修补客户
10、 一种修补客户端(140)，连接至修补服务器(IOO)，用以从所述 修补服务器接收(1500、 1800)修补(1150、 1355、 1365、 1375、 1385)，所述修补客户端包含存储第一公共密钥群组(360)的第一存储装置，所述第一公共密钥 群组(360)包含多个已由第一密钥产生平台(110)产生的第一公共密钥 (300至315);存储第二公共密钥群组(370)的第二存储装置，所述第二公共密钥 群组(370)包含多个己由第二密钥产生平台(120)产生的第二公共密钥 (320至335)，所述第二密钥产生平台(120)与所述第一密钥产生平台不 相同；第一密钥选择器，经配置成从所述第一公共密钥群组选定(1530、 1610、 1830)所述第一公共密钥中的一个；第二密钥选择器，经配置成从所述第二公共密钥群组选定(1530、 1620、 1830)所述第二公共密钥中的一个；第一签名验证组件，经配置成使用所述第一选定公共密钥验证 (1540、 1720、 1750、 1840、 1920、 1950)第一数字签名(1110、 1310)， 所述第一数字签名与所述修补一起从所述修补服务器接收到；以及第二签名验证组件，经配置成使用所述第二选定公共密钥验证 (1540、 1730、 1760、 1840、 1930、 1960)第二数字签名(1120、 1320)， 所述第二数字签名与所述修补一起从所述修补服务器接收到；其中所述修补客户端经配置成只有在验证所述第一与第二数字 签名的结果分别显示所述第一与第二数字签名的真实性与完整性时， 才安装(1560、 2045)所述修补。
全文摘要
本发明提供可增加秘密保护及密钥遗失容忍度(key loss tolerance)的修补服务器、修补客户端及对应的方法。修补服务器包含第一密钥产生平台与不同于第一密钥产生平台的第二密钥产生平台。使用第一或第二密钥产生平台各自产生各自包含多个第一或第二私有密钥的第一与第二私有密钥群组。从第一私有密钥群组选定该等第一私有密钥中之一个，且从第二私有密钥群组选定该等第二私有密钥中之一个。第一数字签名系基于该修补与该第一选定私有密钥而产生。第二数字签名系基于该修补与该第二选定私有密钥而产生。该修补系与第一与第二数字签名一起发送到修补客户端。
文档编号H04L29/06GK101213814SQ200680023968
公开日2008年7月2日 申请日期2006年5月23日 优先权日2005年6月30日
发明者A·瓦克特勒, F·许克, R·芬德森 申请人:先进微装置公司