CN101213814A - 安全修补*** - Google Patents

安全修补*** Download PDF

Info

Publication number
CN101213814A
CN101213814A CN200680023968.XA CN200680023968A CN101213814A CN 101213814 A CN101213814 A CN 101213814A CN 200680023968 A CN200680023968 A CN 200680023968A CN 101213814 A CN101213814 A CN 101213814A
Authority
CN
China
Prior art keywords
key
repairing
hash calculation
digital signature
private cipher
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200680023968.XA
Other languages
English (en)
Other versions
CN101213814B (zh
Inventor
A·瓦克特勒
R·芬德森
F·许克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced Micro Devices Inc
Original Assignee
Advanced Micro Devices Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced Micro Devices Inc filed Critical Advanced Micro Devices Inc
Priority claimed from PCT/US2006/019941 external-priority patent/WO2007005140A1/en
Publication of CN101213814A publication Critical patent/CN101213814A/zh
Application granted granted Critical
Publication of CN101213814B publication Critical patent/CN101213814B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/08—Randomization, e.g. dummy operations or using noise

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

本发明提供可增加秘密保护及密钥遗失容忍度(key loss tolerance)的修补服务器、修补客户端及对应的方法。修补服务器包含第一密钥产生平台与不同于第一密钥产生平台的第二密钥产生平台。使用第一或第二密钥产生平台各自产生各自包含多个第一或第二私有密钥的第一与第二私有密钥群组。从第一私有密钥群组选定该等第一私有密钥中之一个，且从第二私有密钥群组选定该等第二私有密钥中之一个。第一数字签名系基于该修补与该第一选定私有密钥而产生。第二数字签名系基于该修补与该第二选定私有密钥而产生。该修补系与第一与第二数字签名一起发送到修补客户端。

Description

安全修补***
技术领域
本发明大致系关于软件更新，且详而言之，系关于分散***(distributed system)中之软件更新的安全发布(secure distribution)。
背景技术
许多计算机媒体或通讯***由于安全的漏洞而让数据被非法存取或计算机蠕虫(worm)的散布。因此，造成可观的损害。通常是用与安全有关的软件更新封闭此类的安全漏洞，这种软件更新也被称作修补(patch)。在分散***中，可用修补服务器产生修补，然后发布到许多修补客户端，例如，通讯***的行动单元或有嵌入式处理器(embedded processor)的消费者装置。
不过，从不安全***下载的修补仍须加以保护以免被恶意修改。否则，计算机病毒或蠕虫仍能引起有效的攻击。例如，阻断服务(DoS)攻击会针对GSM网(全球行动通讯***)，其中，每一个无线电格(radiocell)中只要有一个主动装置被感染就足以阻断整个***。
在先前技术***中，公共密钥密码***(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)。这则可增加投资保障。此外，可改善免于泄露密钥的保护。其它的实施例在密钥产生仍有安全漏洞的情形下可减少弱密钥(weak key)的风险。
根据一方面，修补服务器系连接至修补客户端，用以提供修补至该修补客户端。该修补服务器包含：第一密钥产生平台、与该第一密钥产生平台不相同的第二密钥产生平台、第一密钥选择器、第二密钥选择器、第一签名产生器、第二签名产生器、以及发送器。该第一密钥产生平台系经配置成产生包含多个第一私有密钥的第一私有密钥群组。该第二密钥产生平台系经配置成产生包含多个第二私有密钥的第二私有密钥群组。该等第一与第二密钥选择器系经配置成各自从该等第一与第二私有密钥群组选定该等第一与第二私有密钥中之一个。该第一签名产生器系经配置成基于该修补与该第一选定私有密钥而产生第一数字签名。该第二签名产生器系经配置成基于该修补与该第二选定私有密钥而产生第二数字签名。该发送器系经配置成一起发送该修补以及该等第一与第二数字签名至该修补客户端。
在另一实施例中，该修补服务器进一步包含：
对话(session)密钥产生器，经配置成产生随机对话密钥；
第一加密组件，经配置成使用对称加密算法用该随随机对话密钥加密该修补；以及
第二加密组件，经配置成用主密钥(master key)加密该随机对话密钥；
其中该发送器系进一步经配置成一起发送呈加密的形式的该修补以及该等第一与第二数字签名和该经加密之随机对话密钥至该修补客户端。
在另一实施例中，该修补服务器之该第一加密组件系进一步经配置成使用该对称加密算法而用该随机对话密钥加密该等第一与第二数字签名；以及
其中该发送器系进一步经配置成一起发送呈加密的形式的该修补以及呈加密的形式的该等第一与第二数字签名和该经加密之随机对话密钥至该修补客户端。
根据另一方面，提供一种提供修补至修补客户端的方法。使用第一密钥产生平台产生包含多个第一私有密钥的第一私有密钥群组。使用不同于该第一密钥产生平台的第二密钥产生平台产生包含多个第二私有密钥的第二私有密钥群组。从该第一私有密钥群组选定该等第一私有密钥中之一个，且从该第二私有密钥群组选定该等第二私有密钥中之一个。基于该修补与该第一选定私有密钥产生第一数字签名。基于该修补与该第二选定私有密钥产生第二数字签名。将该修补以及该等第一与第二数字签名一起发送至该修补客户端。
在另一实施例中，该方法进一步包含：
基于该修补计算出第一哈希计算总合(hash sum)；以及
基于该第一哈希计算总合计算出第二哈希计算总合；
其中产生该第一数字签名包含：基于该第二哈希计算总合以及该第一选定私有密钥而产生该第一数字签名。
在另一实施例中，该方法进一步包含：
基于该第二哈希计算总合计算出第三哈希计算总合；
其中产生该第二数字签名包含：基于该第三哈希计算总合以及该第二选定私有密钥而产生该第二数字签名。
在另一实施例中，该方法进一步包含：
计算出多个哈希计算总合；
其中该修补包含多笔记录；
其中计算出该等多个哈希计算总合包含：基于包含在该修补内之最后一笔记录计算出该等多个哈希计算总合的第一哈希计算总合；以及
其中计算出该等多个哈希计算总合进一步包含：每次基于包含于该修补内之各自的下一笔最近所用的记录(next last record)以及该等多个哈希计算总合中之各自的最近计算所得的哈希计算总合而计算出该等多个哈希计算总合中之另一哈希计算总合。
在另一实施例中，产生该第一数字签名包含：基于该等多个哈希计算总合中之最近计算出之哈希计算总合而产生该第一数字签名；以及
其中发送该修补包含：一起发送该修补以及该等第一与第二数字签名和该等多个哈希计算总合至该修补客户端。
在另一实施例中，产生该第二数字签名包含：基于该等多个哈希计算总合中之最近计算出之哈希计算总合而产生该第二数字签名；以及
其中发送该修补包含：一起发送该修补以及该等第一与第二数字签名和该等多个哈希计算总合至该修补客户端。
在另一实施例中，该方法进一步包含：
产生密钥指针(key indicator)，该密钥指针包含：第一密钥指针，其指向已从该第一私有密钥群组选定的第一私有密钥，以及第二密钥指针，其指向已从该第二私有密钥群组选定的第二私有密钥；
其中发送该修补包含：一起发送该修补以及该等第一与第二数字签名和该密钥指针至该修补客户端。
在另一实施例中，产生该密钥指针包含：产生进一步包含虚拟指针之该密钥指针，该虚拟指针鉴定该等第一与第二数字签名中之一个为虚拟签名。
在另一实施例中，该方法进一步包含：
产生随机对话密钥；
使用对称加密算法而用该随机对话密钥加密该修补；以及
用主密钥加密该随机对话密钥；
其中发送该修补包含：一起发送呈加密的形式的该修补以及该等第一与第二数字签名和该经加密之随机对话密钥至该修补客户端。
在另一实施例中，该方法进一步包含：
使用该对称加密算法而用该随机对话密钥加密该等第一与第二数字签名；
其中发送该修补包含：一起发送呈加密的形式的该修补以及呈加密的形式的该等第一与第二数字签名和该经加密之随机对话密钥至该修补客户端。
另一方面系关于一种修补客户端，其连接至修补服务器，用以从该修补服务器接收修补。该修补客户端包含：第一与第二存储构件(storage means)、第一与第二密钥选择器、以及第一与第二签名验证组件。该第一存储构件存储包含多个已由第一密钥产生平台产生之第一公共密钥的第一公共密钥群组。该第二存储构件存储包含多个第二公共密钥的第二公共密钥群组，该等多个第二公共密钥系由不同于该第一密钥产生平台的第二密钥产生平台产生。该等第一与第二密钥选择器系经配置成各自从该第一与第二公共密钥群组选定该等第一与第二公共密钥中之一个。该第一签名验证组件系经配置成使用该第一选定公共密钥验证第一数字签名，该第一数字签名与该修补一起从该修补服务器接收到。该第二签名验证组件系经配置成使用该第二选定公共密钥验证第二数字签名，该第二数字签名与该修补一起从该修补服务器接收到。该修补客户端系经配置成：只有在验证该等第一与第二数字签名的结果分别显示该等第一与第二数字签名的真实性(authenticity)与完整性时，才安装该修补。
在另一实施例中，该修补客户端进一步包含：
第一哈希计算器(hasher)，经配置成基于该修补计算出第一哈希计算总合；以及
第二哈希计算器，经配置成基于该第一哈希计算总合计算出第二哈希计算总合；
其中该第一签名验证组件系进一步经配置成基于该第二哈希计算总合验证该第一数字签名。
在另一实施例中，该修补客户端进一步包含：
第三哈希计算器，经配置成基于该第二哈希计算总合计算出第三哈希计算总合；
其中该第二签名验证组件系进一步经配置成基于该第三哈希计算总合验证该第二数字签名。
在另一实施例中，该第一签名验证组件系进一步经配置成：基于与该修补一起从该修补服务器接收到的第一哈希计算总合而验证该第一数字签名；以及
其中该第二签名验证组件系进一步经配置成基于该第一哈希计算总合验证该第二数字签名。
在另一实施例中，该第一密钥选择器系进一步经配置成：根据与该修补一起从该修补服务器接收到的第一密钥指针而选定该等第一公共密钥中之该一个；以及
其中该第二密钥选择器系进一步经配置成：根据与该修补一起从该修补服务器接收到的第二密钥指针而选定该等第二公共密钥中之该一个。
在另一实施例中，该修补客户端系进一步经配置成：如果与该修补一起从该修补服务器接收到的虚拟指针分别鉴定(identify)该第一或第二数字签名为虚拟签名，忽略(disregard)验证该第一或第二数字签名的结果。
在另一实施例中，该修补客户端进一步包含：
存储主密钥的第三存储构件；
第一解密(decryption)组件，经配置成使用该主密钥解密与该修补一起从该修补服务器接收到的经加密之随机对话密钥以得到该随机对话密钥；以及
第二解密组件，经配置成使用该随机对话密钥藉由施加对称解密算法而解密该修补。
在另一实施例中，该第二解密组件系进一步经配置成使用该随机对话密钥藉由施加该对称解密算法而解密该等第一与第二数字签名。
在另一实施例中，该主密钥系存储于该第三存储构件内且隐藏于存储于该第三存储构件的其它信息之中。
在另一实施例中，在修补客户端的制造期间，将该主密钥输入于该第三存储构件内。
在另一实施例中，在修补客户端的制造期间，将该第一公共密钥群组与该第二公共密钥群组分别输入于该等第一与第二存储构件内。
根据又另一方面，提供一种安装修补于修补客户端中的方法。该修补系与第一及第二数字签名一起从连接至该修补客户端的修补服务器接收到。在该修补客户端中存储包含多个第一公共密钥的第一公共密钥群组，该等第一公共密钥系已由第一密钥产生平台产生。此外，在该修补客户端中存储包含多个第二公共密钥的第二公共密钥群组，该等第二公共密钥系已由不同于该第一密钥产生平台的第二密钥产生平台产生。该等第一公共密钥中之一个以及该等第二公共密钥中之一个系各自从该等第一与第二公共密钥群组选定。使用该第一选定公共密钥验证该第一数字签名，且使用该第二选定公共密钥验证该第二数字签名。只有在验证该等第一与第二数字签名的结果分别显示该等第一与第二数字签名的真实性与完整性时，才将该修补安装于该修补客户端内。
在另一实施例中，该方法进一步包含：
基于该修补计算出第一哈希计算总合；以及
基于该第一哈希计算总合计算出第二哈希计算总合；
其中验证该第一数字签名包含：基于该第二哈希计算总合而验证该第一数字签名。
在另一实施例中，该方法进一步包含：
基于该第二哈希计算总合计算出第三哈希计算总合；
其中验证该第二数字签名包含：基于该第三哈希计算总合而验证该第二数字签名。
在另一实施例中，该方法进一步包含：
从该修补服务器一起接收到第一哈希计算总合以及该修补；
其中验证该第一数字签名包含：基于该第一哈希计算总合而验证该第一数字签名；以及
其中验证该第二数字签名包含：基于该第一哈希计算总合而验证该第二数字签名。
在另一实施例中，该方法进一步包含：
从该修补服务器一起接收到第一密钥指针与第二密钥指针以及该修补；
其中选定该等第一公共密钥中之该一个包含：根据该第一密钥指针选定该等公共密钥中之该一个；以及
其中选定该等第二公共密钥中之该一个包含：根据该第二密钥指针选定该等第二公共密钥中之该一个。
在另一实施例中，该方法进一步包含：
从该修补服务器一起接收到虚拟指针以及该修补；以及
如果该虚拟指针分别鉴定该第一或第二数字签名为虚拟签名时，则忽略验证该第一或第二数字签名的结果。
在另一实施例中，该方法进一步包含：
从该修补服务器一起接收到经加密之随机对话密钥以及该修补；
在该修补客户端中存储主密钥；
使用该主密钥解密该经加密之随机对话密钥以得到该随机对话密钥；以及
使用该随机对话密钥藉由施加对称解密算法而解密该修补。
在另一实施例中，该方法进一步包含：
使用该随机对话密钥藉由施加该对称解密算法而解密该等第一与第二数字签名。
在另一实施例中，在该修补客户端中存储该主密钥包含：存储该主密钥而隐藏在存储于该修补客户端内的其它信息之中。
在另一实施例中，该方法进一步包含：
在该修补客户端的制造期间，输入该主密钥于该修补客户端内。
在另一实施例中，该方法进一步包含：
在该修补客户端的制造期间，输入该第一公共密钥群组与该第二公共密钥群组于该修补客户端内。
附图说明
为了解释本发明的原理，将附图并入本说明书且作为本说明书的一部份。该等附图不视为是要把本发明限定成只是用来图解说明及描述如何做成及使用本发明的范例。如附图所示，由以上本发明更详细的说明可更加明白本发明的其它特征及优点，其中：
图1系根据一实施例而图标修补***的组件的方块图；
图2系根据一实施例而图解说明密钥管理的方块图；
图3系根据一实施例而图解说明公共密钥管理的方块图；
图4系根据一实施例而图解说明修补发送的流程图；
图5系根据一实施例而图解说明哈希计算链接的步骤；
图6系根据一实施例而显示私有密钥选择的流程图；
图7系根据一实施例而图解说明签名产生的流程图；
图8系根据一实施例而展示KEK加密的步骤；
图9系根据另一实施例而图解说明哈希计算链接的步骤的流程图；
图10系根据另一实施例而显示签名产生的流程图；
图11系根据一实施例而图解说明修补块的构成；
图12系根据该实施例而图解说明密钥指针的组态的方块图；
图13系根据另一实施例而图解说明修补块的配置的方块图；
图14系根据一实施例而图标传输块的方块图；
图15系根据一实施例而图解说明修补的安装过程的流程图；
图16系根据一实施例而图解说明公共密钥选择的流程图；
图17系根据一实施例而展示签名验证的流程图；
图18系根据另一实施例而图解说明修补安装的流程图；
图19系根据另一实施例而图解说明签名验证；以及
图20系根据另一实施例而图解说明逐笔记录的修补解密的流程图。
主要组件符号说明
100  修补服务器          110  第一密钥产生平台
120  第二密钥产生平台    130  第三密钥产生平台
140  修补客户端          150  公共密钥矩阵
160  密钥加密密钥
200、205、210、21 5、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  步骤
480、490、510、520、530、540、610、620、630、710、720、730、
810、820、830、910、920、930、940、1010、1020、1030  步骤
1100  修补块             1110  第一数字签名
1120  第二数字签名       1130  第三数字签名
1140  密钥指针           1150  修补
1210  第一密钥指针       1220  第二密钥指针
1230  第三密钥指针       1240  虚拟指针
1300  修补块
1310、1320、1330  数字签名
1340  密钥指针
1350、1360、1370、1380  密码哈希计算总合
1355、1365、1375、1385  记录
1400  传输块    1410  加密对话密钥
1420  加密修补块
1500、1510、1520、1530、1540、1550、1560、1570、1610、1620、
1630、1700、1710、1720、1730、1740、1750、1760、1770、1780、
1790、1800、1810、1820、1830、1840、1850、1900、1910、1920、
1930、1940、1950、1960、1970、1980、1990、2000、2005、2010、
2015、2020、2030、2035、2040、2045、2050  步骤
D1  第一数字签名        D2  第二数字签名
D3  第三数字签名        H1  第一哈希计算总合
H2  第二哈希计算总合    H3  第三哈希计算总合
具体实施方式
现在参考附图，描述本发明示范之实施例。修补客户端的软件，例如，某些装置的嵌入式处理器可从不安全的***取得修补。该等实施例可保证在进行修补时这些修补没有被修改。例如，有些病毒或计算机蠕虫会做成恶意修补。软件或修补本身之中未被发现的安全漏洞也有可能具有相同的效果。该等实施例可保护修补客户端不会有此类情况的负面影响。
图1系根据一实施例图标修补***的组件。修补服务器100系连接至多个修补客户端140以提供该等修补客户端与安全有关的软件更新，亦即，修补。该等修补客户端可为，例如嵌入式***、个人计算机、或媒体/通讯装置。彼等可通过任何适当的联机而连接至该修补服务器100，例如无线或有线连接。该修补服务器100可为计算机或分布式计算机***。
根据图标之实施例，该修补服务器100包含3个密钥产生平台110、120、130。该等平台110、120、130可彼此分开且可用来产生密钥以及处理。一般而言，平台系指某种在硬件或软件或两者中能执行软件的架构。本实施例的密钥产生平台110、120、130系基于不同的应用***和硬件且可平行使用。这可改善与密钥产生装置内被加入暗门有关的安全性。然而，在可接受HSM(硬件安全模块)为唯一基础的实施例中，为产生密钥而使用不同的软件及硬件是不必要的。
根据该实施例，该第一密钥产生平台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位密钥。数据可分散于程序内且难以找到。此外，利用在程序中数个极为不同的地方用例如宏执行疯狂的计算以动态方式指定功能指针(functionpointer)可提供对还原工程的反制(countermeasure)并且使除错器无法使用。在加密期间以实际上无人知道密钥的方式，可使用这种秘密分割，而在运行时间期间，只有程序可暂时建立这种秘密分割。
在各个修补客户端140卖给使用者之前，可由厂商将公共密钥矩阵150与密钥加密密钥160插设于修补客户端140内。厂商可将对应的密钥保存于安全的地方。至于在本实施例中，公共密钥为固定式，私有密钥的改变为不可能且只能作废。因此，可将私有密钥隐藏于修补服务器100内。
各个修补客户端140可包含不可重设之计数器，其存储最近收到之修补的序号以避免攻击重演。这使得可防止施加有已知安全漏洞的较旧修补。为此目的，该等修补客户端140例如可核对和修补一起收到的时间戳记与广播时间(radio-received time)。
各个修补可包含一些修补记录。为了防止利用溢位(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加密的实施例中，经由模数(亦即，秘密质数的p*q乘积)与公开指数(public exponent)，公共密钥300至355可当作C标头直接处理。该等签名可以PKCS#1(公共密钥密码***标准#1)格式产生，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与一数值为0之字节的串接(H|‘0′)而计算出第一哈希计算总合H1(因此，“|”系指串接而‘0′系数值为0的字节)。然后，在步骤530中，藉由哈希计算步骤520计算出之第一哈希计算总合H1与一数值为1之字节‘1’的串接(H1|‘1′)而计算出第二哈希计算总合H2。最后，藉由哈希计算步骤530所得之第二哈希计算总合H2与一数值为2之字节‘2′的串接(H2|‘2′)而计算出第三哈希计算总合H3(步骤540)。
应注意，根据本实施例，各个修补包含3个在步骤420基于该3个哈希计算总合H1、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个数字签名D1至D3，随后会将彼等加至待送到修补客户端140的修补以便能检查真实性与完整性。图7系图标更多私有密钥选择410的细节。
在步骤710中，使用在步骤610选出的第一私有密钥，藉由签名在步骤520中计算出之第一哈希计算总合H1而可计算出第一数字签名D1。然后，在步骤720中，使用在步骤620选出之第二私有密钥群组270，藉由签名在步骤530所得之第二哈希计算总合H2而可计算出第二数字签名D2。最后，在步骤730中，使用在步骤630选出之第三私有密钥，藉由签名在步骤540计算出的第三哈希计算总合H3而可计算出第三数字签名D3。因此，本实施例所用的3个签名各自基于每一种的一个密钥。
因此，签名哈希计算总合H1至H3的各个步骤可包含另一哈希计算运算接着使用各自选定的私有密钥加密(或解密，这取决于所用的签名算法)。替换地，藉由用对应选定之私有密钥简单地加密或解密各个哈希计算总合H1至H3而可计算出数字签名D1至D3。其它的算法可用来产生数字签名D1至D3系取决于密钥产生平台110至130用于哪一种实作。
此外，图7图标之步骤的特定顺序仅供图解说明用。在其它实施例中，可以任何次序产生数字签名D1至D3或签名产生420的步骤可与哈希计算链接400及/或私有密钥选择410的步骤交错。例如，在刚计算出第一哈希计算总合H1(步骤520)以及选定第一私有密钥(步骤610)后，就可进行计算第一数字签名D1的步骤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中之哪一个已被选定用来产生第一数字签名D1。例如，如果前两个位的数值为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个签名D1至D3中，如果两个位的数值为0时，则该等签名为有效的签名。1、2或3的数值可分别表示第一、第二或第三签名为虚拟签名。替换地，虚拟指针当然可分配不同的数值。
在其它实施例中，可使用比3个多或少的签名签名修补。虚拟指针1240因此可比2个位长或短。此外，1个以上的签名可为虚拟签名。在该等实施例中，虚拟指针1240也可比2个位长。一旦产生密钥指针后，在步骤460中可组合修补块(patch block)。根据本实施例，该修补块具有图标于图11的格式。
如图11所示，该修补块1100可以在步骤710产生第一数字签名1110开始，接着分别在步骤720与730中产生第二数字签名1120与第三数字签名1130。在签名1110至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之前已使数字签名D1至D3内含于修补块1100(步骤460)，也根据本实施例用加密保护该等数字签名。这可降低攻击者找到安全漏洞的风险。
为了致使对称式KEK加密470更加安全，OFB模式中使用的初始化向量(initialization vector)可经选定为唯一，亦即，使彼等在所有修补中决不重复。这可藉由例如在初始化向量的固定部份中包含序号达成。替换地，可使用用于此目的的时间戳记。
现在请参考图4，在步骤480中可组合传输块(
transmission block)。本实施例之传输块的构成元素系图标于图14。
具体言之，传输块1400可分别由步骤830、820所得之加密对话密钥1410接着加密修补1420而构成。根据本实施例，加密对话密钥为128个位长。替换地，在其它实施例中也可使用其它长度的对话密钥。
最后，在步骤490中，可将传输块发送到修补客户端140。
如前述，在签名期间的硬件失败可能会泄露私有密钥。为了避免此风险，在送到修补客户端140(步骤490)之前，可核对步骤420中产生的签名。因此，可用不同的程序核对各个签名D1至D3。例如，可由厂商验证(尚未出售)修补客户端140在开机时是否有包含待核对之签名的实际修补。
根据上述实施例，修补客户端140中数字签名D1至D3的验证有可能是只在读取整个修补1150之后。不过，在其它的实施例中，可能希望在译码每笔修补后立即检查真实性与完整性。这在第二实施例中是有可能的，而现在将参考第9、10及13图而予以说明。
在此实施例中，修补服务器100的整体操作可与图4中的操作相对应，且私有密钥选择410、虚拟处理430与440、密钥指针产生450、KEK加密470、以及传输块的组合与传输480与490可与上述的相同。不过，可使用经修改之哈希计算链接400与签名产生420。此外，修补块组合460可能产生构成元素与上述不同的修补块。
首先与本实施例有关的修补块及其构成系图标于图13。
与第一实施例的修补块1100相似，修补块1300可由3个数字签名(D1至D3)13 10、1320、1330开始，接着密钥指针1340。密钥指针1340可对应至以上参考第11、12图所描述的密钥指针1140。不过，数字签名1310、1320、1330的计算方式可不同于第一实施例的数字签名，以下将参考图10而加以解释。此外，修补的每笔记录(R1至Rn)1355、1365、1375、1385的前面为密码哈希计算总合(H1至Hn)1350、1360、1370、1380。
根据本实施例，哈希计算总合1350、1360、1370、1380的计算是在图4的步骤400中进行且在图9中图标更多细节。
首先，在步骤910中，藉由哈希计算待传输修补之第n笔记录Rn1385与由0值位构成之哈希计算总合值“0”的串接(Rn|0)可计算出哈希计算总合Hn 1380。在其它的实施例，在步骤910中只有将记录Rn加以哈希计算。然后，在步骤920中，藉由哈希计算第(n-1)笔记录Rn-11375与前一个计算出之哈希计算总合Hn1380的串接(Rn-1|Hn)计算出哈希计算总合Hn-1 1370。接着，在步骤930至940中以类似的方式计算出哈希计算总合Hn-2至H1。在其它实施例中，可跳过最后一个步骤940，且在随后的步骤中第一记录R1用来取代由步骤940所得之哈希计算总合H1。不过，图标于图9之实施例的编程(programming)比较简单和强健。
根据本实施例，经修改之签名产生420系图标于图10。
在步骤1010中，藉由使用在图6步骤610选出的第一私有密钥签名(亦即，哈希计算及译码/加密或简单译码/加密，如在描述图7时所述)第一哈希计算总合H1 1350而可计算出第一数字签名D1 1310。在步骤1020中，藉由使用在步骤620选定的第二私有密钥签名第一哈希计算总合H1 1350而可因此计算出第二数字签名D2 1320。最后，在步骤1030中，藉由使用在步骤630所得之第三私有密钥签名第一哈希计算总合H1 1350而可产生第三数字签名D3 1330。
图标步骤之顺序不应被视为要限定本发明。例如，可以不同的次序计算数字签名D1至D3。此外，计算步骤1010至1030可与图标于图6之私有密钥选择及/或图标于图9之哈希计算链接交错。例如，在刚计算出第一哈希计算总合H1以及选定对应的私有密钥后，就可计算出数字签名D1至D3。
一旦修补服务器100已将包含加密修补的传输块1400送到修补客户端140后，可使用公共密钥矩阵150与KEK密钥160而将该修补安全地安装于修补客户端140。此时参考第15至17图，其系根据一实施例描述由修补客户端140完成的安全修补安装过程。于只在解密整个修补之后验证数字签名D1至D3 1110、1120、1130的实施例中，可使用此修补安装过程。
首先请参考图15，在步骤1500中修补客户端140可收到传输块1400。然后，在步骤1510中可使用KEK密钥160解密经加密之随机对话密钥1410。在步骤1520中，在AES算法下使用在步骤1510之前得到的随机对话密钥可解密经加密之修补块1420。使用以上在描述图8时所述之OFB模式可达成步骤1510与1520的解密。
在步骤1530中，可选定待用来验证签名的公共密钥。更多细节会图标于图16。
首先，在步骤1610中，使用在步骤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时所得到的数字签名(D1-D3)1110、1120、1130可分别用第一、第二及第三公共密钥解密。
然后，在步骤1750至1770中，由步骤1720至1740得到的经解密之数字签名可与在步骤1710得到经再度哈希计算之哈希计算总合H1至H3相比较。在跳过步骤1710的实施例中，经解密之数字签名可各自直接与哈希计算总合H1至H3相比较。
在步骤1780中，可判断数字签名(D1-D3)1110、1120、1130之中是否有虚拟签名。这可藉由检查密钥指针1140的虚拟指针1240达成。
若有的话，在步骤1790中，可决定在其余的安全修补安装过程期间忽略以虚拟指针1240鉴定为虚拟签名的数字签名。在其它实施例中，如上述，会有1个以上的数字签名可能为虚拟签名。在该等实施例中，在其余的修补安装过程期间可忽略所有的虚拟签名。
如果步骤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的第三哈希计算总合H3、选出步骤1630的第三公共密钥、哈希计算步骤1710的第三哈希计算总合H3、解密步骤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得到的数字签名(D1至D3)1310、1320、1330。图19中有详细图标。
首先，在步骤1900中，传输块1400所收到之修补的经加密之第一哈希计算总合以及经加密之第一记录可用步骤1810得到的随机对话密钥解密。达成的方式可与以上在解释图15时所描述之步骤1520的解密相同。随后，在步骤1910中可哈希计算在步骤1900回收的第一哈希计算总合H1 1350。在其它实施例中，特别是，在步骤1010至1030由修补服务器100完成签名的步骤不包含任何哈希计算的实施例中，可跳过步骤1910。
随后，在步骤1920至1940中，使用在步骤1830中选出的第一至第三公共密钥可分别将由步骤1820得到的数字签名(D1至D3)1310至1330解密。然后，在步骤1950至1970中，步骤1920至1940的每个结果可分别与步骤1910的结果比较。反之，在跳过步骤1910的实施例中，由步骤1920至1940得到的经解密之签名可与从步骤1900得到的哈希计算总合H1相比较。
最后，在步骤1980与1990中可进行虚拟签名的处理。这可对应至以上在说明图17步骤1780与1790所描述之虚拟签名的处理。
此外，第18与19图中步骤的特定顺序为仅供图解说明用且不应被视为要限定本发明。在其它实施例中，各个步骤的次序可不相同，例如交错的顺序。此外，例如，在签名验证1840开始时或在公共密钥选择1830之前，可进行步骤1980与1990的虚拟签名处理。在该等实施例中，可跳过以下所有的步骤：与被虚拟指针1240鉴定为虚拟签名之数字签名有关的公共密钥选择1830与签名验证1900至1970。
现在请参考图18，在步骤1850中，可以逐笔记录的方式解密经加密之修补块1420的其余部份。根据本实施例逐笔记录的修补解密计画系图标于图20。
因此，首先在步骤2000中可检查所有的签名D1至D3是否正常。步骤2000可包含：判断所有的比较步骤1950至1970的结果是否相等。如上述，对于此判断，最后几个虚拟签名可不纳入考虑。
如果判断为否，亦即，经解密之数字签名D1至D3中之至少一个不同于(经哈希计算之)哈希计算总合H1，在步骤2050中可决定不安装本修补。这可对应至图15的步骤1570。
不过，如果所有的签名都正常，内含于加密修补块1420的第二加密哈希计算总合与第二加密修补记录可用在步骤1810得到的随机对话密钥解密。步骤2005完成解密的方式可与上述步骤1820完成解密的方式相同。然后，在步骤2010中，可哈希计算第一记录R1 1355(已在步骤1900得到)与在步骤2005得到之第二哈希计算总合H2 1360的串接(R1|H2)。
结果可与先前得到的哈希计算总合H1 1350(在解密步骤1900)相比较。如果步骤2020判定这两个哈希计算总合不相等，则修补解密计画可前进到步骤2050而决定不安装该修补。否则对于第三至最后一个哈希计算总合以及加密修补块1420中的记录，可因此分别重复步骤2005至2020。
如果步骤2020的比较对于所有经解密之哈希计算总合和记录有正面的解答，则在步骤2030可计算出最后一笔修补记录Rn 1385与由0位构成之哈希计算总合数值“0”的串接(Rn|0)。在步骤2035，此数值可与修补块1300的最后一个哈希计算总合Hn 1380相比较。
如果在步骤2040判断两个数值为相等，则在步骤2045可安装修补，且可通知使用者及/或修补服务器100修补安装成功。否则，在步骤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个数字签名D1至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-0(保全哈希计算算法0))有致命的瑕疵。不清楚SHA-1是否可破解甚至是否可以可用方式破解。不过，即使用相同的SHA-1哈希计算值可构成有不同意义的文字，完全不切实际的是，若由图标于第5及9图的哈希计算链接提供，这对2个甚至更多个的链接哈希计算而言是有可能的。
建议的概念保证有极佳的修补完整性，其使用数个数字签名D1至D3，使用与周全密钥管理结合的异质公共密钥。即使在只使用HSM密钥的实施例中，安全性仍然很高。藉由用可藏在修补客户端韧体内的KEK密钥加密可保护修补内容。
在可信赖的第三方(TTP)涉入安全处理的实施例中，只有哈希计算值才需要加以签名。从而可进一步增强安全性，因为可避免显露修补来源的风险。
相较于增益，建议之解决方案的成本低。修补开发及发布远比密钥处理、备份、数字签名及加密昂贵，即使在此过程涉及数个实例的实施例中。修补客户端140的制造成本几乎不变且添加所描述之安全修补功能所增加的成本也有限。在修补客户端140开机期间解密及签名检查可能需要最少的时间。不过，安全性胜过先前技术简单的修补***很多。因此，本发明实施例可显著增加修补***的安全性、可靠性及效率，而不会过当地增加对应的成本。
尽管已用依照本发明所述构成的实际实施例描述本发明，显然对熟谙此艺者而言，根据上述教导且在随附之申请专利范围的范围内可做出各种本发明的修改、变体及改进而不脱离本发明的范畴。此外，相信本技艺一般技术人员已熟悉的领域在本文中不需再加以描述以免不必要地混淆在本文中所描述的发明。因此，应了解，本发明不受限于特定的示范实施例，而只受限于随附申请专利范围的范畴。
产业上利用性
本发明的实施例可应用于计算机技术领域，而因此可用于工业领域。

Claims (10)

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、1010)所述第一数字签名；以及
其中所述发送器进一步经配置成一起发送所述修补以及所述第一与第二数字签名和所述多个哈希计算总合至所述修补客户端。
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)所述第一私有密钥中的一个；
从所述第二私有密钥群组选定(410、620)所述第二私有密钥中的一个；
基于所述修补与所述第一选定私有密钥产生(420、710、1010)第一数字签名(1110、1310)；
基于所述修补与所述第二选定私有密钥产生(420、720、1020)第二数字签名(1120、1320)；以及
一起发送所述修补以及所述第一与第二数字签字至所述修补客户端。
10.一种修补客户端(140)，连接至修补服务器(100)，用以从所述修补服务器接收(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)所述修补。
CN200680023968.XA 2005-06-30 2006-05-23 安全修补*** Active CN101213814B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE102005030590A DE102005030590B4 (de) 2005-06-30 2005-06-30 Sicheres Patchsystem
DE102005030590.3 2005-06-30
US11/219,260 2005-09-02
US11/219,260 US7127067B1 (en) 2005-06-30 2005-09-02 Secure patch system
PCT/US2006/019941 WO2007005140A1 (en) 2005-06-30 2006-05-23 Secure patch system

Publications (2)

Publication Number Publication Date
CN101213814A true CN101213814A (zh) 2008-07-02
CN101213814B CN101213814B (zh) 2012-02-08

Family

ID=37110635

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200680023968.XA Active CN101213814B (zh) 2005-06-30 2006-05-23 安全修补***

Country Status (5)

Country Link
US (1) US7127067B1 (zh)
JP (1) JP4875075B2 (zh)
CN (1) CN101213814B (zh)
DE (1) DE102005030590B4 (zh)
TW (1) TWI429255B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104753678A (zh) * 2013-12-31 2015-07-01 恩智浦有限公司 利用预计算减小生成ecdsa签名的延迟的方法
CN108604263A (zh) * 2016-02-10 2018-09-28 思科技术公司 用于客户提供的完整性的双重签名可执行镜像

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AUPS169002A0 (en) 2002-04-11 2002-05-16 Tune, Andrew Dominic An information storage system
US7813510B2 (en) * 2005-02-28 2010-10-12 Motorola, Inc Key management for group communications
US7876902B2 (en) * 2006-08-31 2011-01-25 Microsoft Corporation Distribution of encrypted software update to reduce attack window
EP3474283A1 (en) * 2007-05-30 2019-04-24 Ascensia Diabetes Care Holdings AG Method and system for managing health data
DE102007052180A1 (de) * 2007-10-31 2009-05-07 Fujitsu Siemens Computers Gmbh Verfahren, Rechnersystem und Computerprogrammprodukt
US20090132999A1 (en) * 2007-11-21 2009-05-21 At&T Corp. Secure and fault-tolerant system and method for testing a software patch
US8595486B2 (en) * 2008-07-15 2013-11-26 Industrial Technology Research Institute Systems and methods for authorization and data transmission for multicast broadcast services
US20100329458A1 (en) * 2009-06-30 2010-12-30 Anshuman Sinha Smartcard, holder and method for loading and updating access control device firmware and/or programs
TWI448148B (zh) * 2010-08-27 2014-08-01 Tatung Co 可自動驗證ｋｓｖ金鑰及自我重建ｈｄｃｐ金鑰組之顯示器裝置及其方法
US10298684B2 (en) 2011-04-01 2019-05-21 International Business Machines Corporation Adaptive replication of dispersed data to improve data access performance
US11418580B2 (en) 2011-04-01 2022-08-16 Pure Storage, Inc. Selective generation of secure signatures in a distributed storage network
US8874991B2 (en) * 2011-04-01 2014-10-28 Cleversafe, Inc. Appending data to existing data stored in a dispersed storage network
TWI451741B (zh) * 2012-03-19 2014-09-01 Chiou Haun Lee 以ｘｏｒ運算於三方通訊之加解密方法
CN102904721B (zh) * 2012-09-20 2015-04-08 湖北省电力公司电力科学研究院 用于智能变电站信息安全控制的签名、认证方法及其装置
US8949594B2 (en) * 2013-03-12 2015-02-03 Silver Spring Networks, Inc. System and method for enabling a scalable public-key infrastructure on a smart grid network
DE102015108336A1 (de) * 2015-05-27 2016-12-01 Fujitsu Technology Solutions Intellectual Property Gmbh Verfahren zum Ausführen einer sicherheitsrelevanten Anwendung, Computersystem und Anordnung
CN106559217B (zh) 2015-09-29 2019-09-20 腾讯科技（深圳）有限公司 一种动态加密方法、终端、服务器
KR101893518B1 (ko) 2016-10-28 2018-10-04 한국전자통신연구원 제어 시스템의 업데이트 관리 장치, 업데이트 검증 장치 및 그 방법
CN111046389A (zh) * 2018-10-11 2020-04-21 东硕资讯股份有限公司 固件组件安全更新的方法以及用以实施的携行计算机站
US11372977B2 (en) * 2018-11-12 2022-06-28 Thirdwayv, Inc. Secure over-the-air firmware upgrade
JP6782758B2 (ja) * 2018-12-06 2020-11-11 三菱電機インフォメーションシステムズ株式会社 長期署名データ生成装置および長期署名データ生成方法
CN109687959B (zh) 2018-12-29 2021-11-12 上海唯链信息科技有限公司 密钥安全管理***和方法、介质和计算机程序
US11138295B2 (en) 2019-03-11 2021-10-05 Good Way Technology Co., Ltd. Method for securely updating firmware components and docking station using the same
US11347895B2 (en) * 2019-12-03 2022-05-31 Aptiv Technologies Limited Method and system of authenticated encryption and decryption
TWI756631B (zh) * 2020-02-12 2022-03-01 瑞昱半導體股份有限公司 具有韌體驗證機制的電腦系統及其韌體驗證方法
JP2020141425A (ja) * 2020-06-10 2020-09-03 エヌ・ティ・ティ・コミュニケーションズ株式会社 端末装置、鍵提供システム、鍵生成方法及びコンピュータプログラム
TWI807707B (zh) * 2022-03-21 2023-07-01 中華電信股份有限公司 安全性軟體更新系統、方法及電腦可讀媒介

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US6367012B1 (en) * 1996-12-06 2002-04-02 Microsoft Corporation Embedding certifications in executable files for network transmission
JPH11282672A (ja) * 1998-03-31 1999-10-15 Hitachi Software Eng Co Ltd オンラインプログラム転送方法およびオンラインプログラム実行システム
WO2002025409A2 (en) * 2000-09-21 2002-03-28 Research In Motion Limited Software code signing system and method
US7424706B2 (en) * 2003-07-16 2008-09-09 Microsoft Corporation Automatic detection and patching of vulnerable files

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104753678A (zh) * 2013-12-31 2015-07-01 恩智浦有限公司 利用预计算减小生成ecdsa签名的延迟的方法
US10135621B2 (en) 2013-12-31 2018-11-20 Nxp B.V. Method to reduce the latency of ECDSA signature generation using precomputation
CN104753678B (zh) * 2013-12-31 2019-03-22 恩智浦有限公司 利用预计算减小生成ecdsa签名的延迟的方法
CN108604263A (zh) * 2016-02-10 2018-09-28 思科技术公司 用于客户提供的完整性的双重签名可执行镜像
CN108604263B (zh) * 2016-02-10 2023-04-07 思科技术公司 用于客户提供的完整性的双重签名可执行镜像

Also Published As

Publication number Publication date
JP4875075B2 (ja) 2012-02-15
JP2009500905A (ja) 2009-01-08
TW200711436A (en) 2007-03-16
TWI429255B (zh) 2014-03-01
US7127067B1 (en) 2006-10-24
DE102005030590B4 (de) 2011-03-24
DE102005030590A1 (de) 2007-01-04
CN101213814B (zh) 2012-02-08

Similar Documents

Publication Publication Date Title
CN101213814B (zh) 安全修补***
CN1985466B (zh) 使用分发cd按签署组向设备传递直接证据私钥的方法
CN101443774B (zh) 优化完整性验证过程的方法和***
CN102419804B (zh) 具有冗余安全性的可靠的软件产品验证和激活
US5214698A (en) Method and apparatus for validating entry of cryptographic keys
CN100487715C (zh) 一种数据安全存储***和装置及方法
CN101019368B (zh) 使用分发cd将直接证明私钥传递给设备的方法
EP0482371B1 (en) Method and apparatus for controlling the use of a public key, based on the level of integrity for the key
EP3035585B1 (en) S-box selection in white-box cryptographic implementation
JP2008541591A (ja) 完全性保護されたセキュアストレージの実装
TWI517653B (zh) 電子裝置及密碼材料供應之方法
EP1407339A2 (en) Firmware validation
CN111611593A (zh) 安全数据处理设备
CN101627390A (zh) 用于程序状态数据在电子设备中的安全存储的方法
US8774407B2 (en) System and method for executing encrypted binaries in a cryptographic processor
CN109951276B (zh) 基于tpm的嵌入式设备远程身份认证方法
CN104868998A (zh) 一种向电子设备供应加密数据的***、设备和方法
US9571273B2 (en) Method and system for the accelerated decryption of cryptographically protected user data units
US20080000971A1 (en) Method for customizing customer identifier
JP5171787B2 (ja) サインクリプションシステムおよびサインクリプション生成方法
US11516024B2 (en) Semiconductor device, update data-providing method, update data-receiving method, and program
WO2013016736A2 (en) Product authentication based upon a hyperelliptic curve equation and a curve pairing function
US10404718B2 (en) Method and device for transmitting software
KR101290818B1 (ko) 보안 패치 시스템
KR100897075B1 (ko) 배포 ｃｄ를 사용하는 장치에 서명 그룹의 다이렉트 증명개인 키들을 전달하는 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant