CN109829294A - 一种固件验证方法、***、服务器及电子设备 - Google Patents
一种固件验证方法、***、服务器及电子设备 Download PDFInfo
- Publication number
- CN109829294A CN109829294A CN201910097384.6A CN201910097384A CN109829294A CN 109829294 A CN109829294 A CN 109829294A CN 201910097384 A CN201910097384 A CN 201910097384A CN 109829294 A CN109829294 A CN 109829294A
- Authority
- CN
- China
- Prior art keywords
- private key
- public
- firmware
- upgraded
- abstract
- 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
Links
Landscapes
- Stored Programmes (AREA)
Abstract
本发明公开了一种固件验证方法、***、服务器及电子设备,确定待升级固件,生成至少一组公私钥对,获取待升级固件的升级版本的摘要,依次通过公私钥对中的私钥对摘要进行标记,将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。本方案通过私钥对待升级固件的升级版本的摘要进行标记,并由电子设备通过公钥对该标记进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
Description
技术领域
本发明涉及固件领域,尤其涉及一种固件验证方法、***、服务器及电子设备。
背景技术
OTA,即空中升级,是指云服务或手机APP通过自定义通信协议下载和接收最新的软件版本,完成自行升级的过程。
OTA为固件更新提供了众多便利,然而在固件升级过程中,设备端仅实现了对“启动OTA”命令的加密和固件完整性的校验,而未对完整固件做可信签名校验,从而导致可能受到来自黑客恶意的设备升级攻击。
发明内容
有鉴于此,本发明提供一种固件验证方法、***、服务器及电子设备,以解决现有技术中未对完整固件做可信签名校验,从而导致可能受到来自黑客恶意的设备升级攻击的问题,其具体方案如下:
一种固件验证方法,应用于服务器,包括:
确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
获取所述待升级固件的升级版本的摘要;
依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记。
进一步的,还包括:
当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,所述生成的新的公私钥对的数量与出现异常的私钥数量相同;
将存储于所述服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,并通过所述电子设备对固件的升级将存储于所述待升级固件中与所述出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
一种固件验证方法,应用于电子设备,包括:
获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
进一步的,所述通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证,包括:
当所述公私钥对为一组时:
通过所述一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证;
当所述公私钥对为不少于两组时:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性;
当所述摘要的正确性验证通过时,通过所述摘要确定所述待升级固件的升级版本的正确性。
进一步的,所述当所述公私钥对为不少于两组时,通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性,包括:
当所述公私钥对为不少于两组时,将所述不少于两组公私钥对中的不少于两个公钥、所述摘要及所述不少于两个标记进行算法验证,若验证通过,则表明所述摘要正确。
进一步的,当所述公私钥对为不少于两组时,所述通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证,包括:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述待升级固件的升级版本的正确率是否达到第一阈值;
当所述正确率达到第一阈值时,所述待升级固件的升级版本通过验证。
进一步的,所述当所述公私钥对不少于两组时,对所述摘要进行标记,包括:
当正常私钥数量占总私钥数量的比例不小于第二阈值时,分别通过所有正常私钥与预定数量的异常私钥对所述摘要进行标记,其中,所述总私钥由正常私钥与异常私钥组成,所述第二阈值小于第一阈值,所述预定数量为预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
一种服务器,包括:确定单元,获取单元,标记单元及发送单元,其中:
所述确定单元用于确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述获取单元用于获取所述待升级固件的升级版本的摘要;
所述标记单元用于依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
所述发送单元用于将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记。
进一步的,还包括:密钥更新单元,其中:
所述密钥更新单元用于:当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,所述生成的新的公私钥对的数量与出现异常的私钥数量相同;
将存储于所述服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,并通过所述电子设备对固件的升级将存储于所述待升级固件中与所述出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
一种电子设备,包括:获取单元及验证单元,其中:
所述获取单元用于获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述验证单元用于从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
进一步的,所述验证单元用于:
当所述公私钥对为一组时:
通过所述一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证;
当所述公私钥对为不少于两组时:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性;
当所述摘要的正确性验证通过时,通过所述摘要确定所述待升级固件的升级版本的正确性。
进一步的,所述验证单元具体用于:
当所述公私钥对为不少于两组时,将所述不少于两组公私钥对中的不少于两个公钥、所述摘要及所述不少于两个标记进行算法验证,若验证通过,则表明所述摘要正确。
进一步的,所述获取单元具体用于:
当正常私钥数量占总私钥数量的比例不小于第二阈值时,分别通过所有正常私钥与预定数量的异常私钥对所述摘要进行标记,其中,所述总私钥由正常私钥与异常私钥组成,所述第二阈值小于第一阈值,所述预定数量为预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
一种固件验证***,包括:服务器及电子设备,其中:
所述服务器包括:确定单元,获取单元,标记单元及发送单元,其中:
所述确定单元用于确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述获取单元用于获取所述待升级固件的升级版本的摘要;
所述标记单元用于依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
所述发送单元用于将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记;
所述电子设备包括:获取单元及验证单元,其中:
所述获取单元用于获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述验证单元用于从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
从上述技术方案可以看出,本申请公开的固件验证方法、***、服务器及电子设备,确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。本方案通过私钥对待升级固件的升级版本的摘要进行标记,并由电子设备通过公钥对该标记进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例公开的一种固件验证方法的流程图;
图2为本发明实施例公开的一种固件验证处理方法的流程图;
图3为本发明实施例公开的一种一组公私钥对的固件升级版本验证的流程图;
图4为本发明实施例公开的一种不少于两组公私钥对的固件升级版本的摘要验证的流程图;
图5为本发明实施例公开的一种不少于两组公私钥对的固件升级版本验证的流程图;
图6为本发明实施例公开的一种固件验证方法的流程图;
图7为本发明实施例公开的一种服务器的结构示意图;
图8为本发明实施例公开的一种电子设备的结构示意图;
图9为本发明实施例公开的固件验证***的流程图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明公开了一种固件验证方法,应用于服务器,其流程图如图1所示,包括:
步骤S11、确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
当有设备中承载有一个固件时,该设备在出厂时,会自带某个版本的固件,当服务器中有针对该固件的升级版本时,可以下载该升级版本,以便于对固件进行升级。
在升级过程中,为了避免该升级版本的来源不可靠,需要生成公私钥对,以便于对该升级版本进行签名验证。
具体的,在设备出厂时携带的固件中会预先存储有至少一组公私钥对,,无需单独生成,并将至少一组公私钥对中的公钥KEYpub存储于固件中,将至少一组公私钥对中的私钥KEYpriv存储于服务端,具体的,服务端可以为管理员处,也可以为存储设备等,如:将私钥保存于管理员处,以便于后续使用。
当需要对设备中承载的固件版本进行升级时,生成至少一组公私钥对,将至少一组公私钥对中的公钥存储于该待升级的固件中,将至少一组公私钥对中的私钥存储于服务端。
其中,当公私钥对为不少于两组时,将不少于两组公私钥对中的私钥分别存储于服务端,具体的,可以为:将每个私钥分别存储于不同的服务端,或,同一个服务端的不同位置,如:第一私钥存储于第一管理员处,第二私钥存储于第二管理员处,第三私钥存储于第三管理员处,以避免私钥同时出现被泄露或丢失等异常情况,保证了不少于两组公私钥对中私钥的安全性。
步骤S12、获取待升级固件的升级版本的摘要;
获取待升级固件的升级版本的摘要Flash Digest,即hash值,以便于通过hash值确定该待升级固件的升级版本的完整性。
具体的,为了实现本方案中对固件升级版本的签名验证,其签名算法可以采用ECDSA(椭圆曲线数字签名算法),ECDSA是ECC与DSA的结合,整个签名过程与DSA类似,所不一样的是签名中采用的算法为ECC。
在ECDSA中,摘要算法采用SHA256,也可以使用SHA1等其他算法,被称为:SHA256withECDSA或SHA1withECDSA,即在性能满足的情况下,使用SHA256withECDSA,特殊情况下采用其他的摘要算法,如:SHA1withECDSA。
步骤S13、依次通过至少一组公私钥对中的私钥对摘要进行标记;
使用公私钥对中的私钥对摘要Flash Digest进行标记,得到签名Flash Sign。
当只有一组公私钥对时,使用唯一的私钥对摘要Flash Digest进行标记,得到一个签名Flash Sign;当有不少于两组公私钥对时,依次通过每一个私钥对摘要FlashDigest进行标记,得到不少于两个签名Flash Sign1,Flash Sign2,…,Flash SignN。
例如:当有三组公私钥对时,通过第一私钥对摘要Flash Digest进行标记,得到签名Flash Sign1,通过第二私钥对摘要Flash Digest进行标记,得到签名Flash Sign2,通过第三私钥对摘要Flash Digest进行标记,得到签名Flash Sign3。
步骤S14、将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。
将固件升级包信息发送至电子设备,由电子设备通过待升级固件中的公钥与进行的标记对待升级固件的升级版本进行验证。
其中,公钥为预先存储于待升级固件中的,并且,公钥与私钥为一组,是有对应关系的,通过私钥对升级版本的摘要进行标记,得到签名,通过公钥与签名进行匹配或比较,从而可以确认该升级版本的摘要是否通过验证,从而确定该升级版本的来源是否可靠。
当该升级版本的摘要通过验证,则表明该升级版本的来源可靠,当该升级版本的摘要未通过验证,则表明该升级版本的来源不可靠。
当该升级版本的来源不可靠时,其可能为至少一组公私钥对中的私钥发生泄漏或丢失等异常情况,造成该升级版本被黑客或其他不法人员利用,从而导致的升级版本来源不可靠。
进一步的,当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,生成的新的公私钥对的数量与出现异常的私钥数量相同,将存储于服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,通过固件升级将存储于待升级固件中的出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
具体的,当不少于两组公私钥对中有至少一个私钥出现异常,重新生成对应异常私钥数量的公私钥对,即若有一个私钥出现异常,则重新生成一组公私钥对,若有两个私钥出现异常,则重新生成两组公私钥对。
其中,私钥出现异常可以具体为:私钥丢失或泄露等异常情况。
例如:私钥存储于存储设备中,当存储设备中数据丢失或被删除时,则私钥出现异常,需要进行密钥的更新。
具体的,若私钥存储于存储设备中,则可以通过确定存储设备中数据是否被删除,或者,数据是否被未知用户读取等来确定存储设备中的数据是否丢失或泄露;若私钥存储于管理员处,则需要由管理员上传数据丢失或泄露的信息,从而确定私钥出现异常。
本实施例公开的固件验证方法,确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。本方案通过私钥对待升级固件的升级版本的摘要进行标记,并由电子设备通过公钥对该标记进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本实施例公开了一种固件验证方法,应用于电子设备,其流程图如图2所示,包括:
步骤S21、获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
步骤S22、从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。
固件升级包信息是由服务器发送至电子设备的,在发送至电子设备之前,服务器需要确定待升级固件,生成至少一组公私钥对,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,之后服务器将待升级固件的升级版本数据、摘要及对摘要进行的标记打包存储为固件升级包信息,之后将固件升级包信息发送至电子设备,以便通过电子设备对待升级固件的升级版本进行验证。
其中,待升级固件是电子设备中的待升级固件,在电子设备对待升级固件的升级版本的验证通过后,由电子设备对待升级固件进行升级,使其升级到该验证通过的升级版本,从而使得电子设备中的待升级固件的升级版本来源可靠。
将待升级固件的升级版本数据Flash Image、摘要Flash Digest及对摘要进行标记得到的签名Flash Sign存储至固件升级包信息OTAInfo,以便于将升级版本数据、升级版本的摘要及对摘要进行的签名存储至一处,便于管理。
另外,在对待升级固件的升级版本进行验签的过程中,仅需要从固件升级包信息中获取数据即可。
当公私钥对为一组时,通过这一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证,其流程如图3所示。
具体的,将公钥及摘要的标记进行匹配或比较,当匹配成功,或,比较判定该公钥与标记中的私钥信息匹配,则表明该标记对应的摘要通过验证,从而确定该待升级固件的升级版本通过验证,其来源可靠;当匹配失败,或,比较判定该公钥与标记中的私钥信息不匹配,则表明该标记对应的摘要未通过验证,从而确定该升级版本未通过验证,其来源不可靠,不对待升级固件进行版本更新。
当公私钥对为一组时,固件升级包信息中可以仅存储升级版本数据及标记,由于在验证过程中,并不需要摘要的信息,则可以无需存储摘要。
当公私钥对为不少于两组时,通过不少于两组公私钥对中的公钥及标记确定摘要的正确性,当摘要的正确性验证通过时,通过摘要确定待升级固件的升级版本的正确性。
具体的,首先获取固件升级包信息中的标记及摘要,通过标记确认摘要的正确性,其流程如图4所示,即验证公钥及标记中的私钥信息是否匹配,若匹配,则表明摘要通过正确性验证。由于公私钥对为不少于两组,那么,通过私钥确定的标记也为不少于两个,在确定摘要的正确性的过程中是需要多次验证的,有几组公私钥对就需要验证对应次数的摘要,从而得到最终摘要是否通过验证的结论。
具体的,可以为:将不少于两组公私钥对中的不少于两个公钥、摘要及不少于两个标记进行算法验证,若验证通过,则表明摘要正确。
具体的,将不少于两个公钥KEYpub、摘要Flash Digest及不少于两个标记FlashSign输入ECDSA做VERIFY算法的验证,若验证成功则表明Flash Digest是正确的。
具体的,由于每一组公私钥对中的私钥均对应一个标记,因此,当一个标记、与该标记对应的一个公钥及摘要进行算法验证时,可以验证公钥与标记对应的私钥是否匹配,并可进一步确定摘要是否能够通过该组公私钥对的验证,当摘要能够通过该组公私钥对的验证时,则表明该摘要的正确性验证通过,即摘要是正确的。
当摘要通过验证后,获取升级版本数据Flash Image,使用摘要Flash Digest确认升级版本数据Flash Image的正确性,其流程如图5所示。当确认Flash Image合法后,将升级版本数据Flash Image转移至代码区,以便于对待升级固件进行更新。
本实施例公开的固件验证方法,应用于电子设备,获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端,从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。本方案由电子设备通过公钥对待升级固件的升级版本进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本实施例公开了一种固件验证方法,其流程图如图6所示,包括:
步骤S61、获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
步骤S62、通过不少于两组公私钥对中的公钥及标记确定待升级固件的升级版本的正确率是否达到第一阈值;
步骤S63、当正确率达到第一阈值时,待升级固件的升级版本通过验证。
当公私钥对为一组时,通过公钥及标记可以直接得到升级版本是否通过验证的结论;
当公私钥对为不少于两组时,由于公钥及私钥分别为不少于两个,标记是通过私钥得到的,那么,标记也为不少于两个,通过不少于两个公钥中的公钥及与该公钥对应的标记进行摘要正确性验证,即通过第一公钥及与第一公钥对应的第一标记进行摘要正确性验证,通过第二公钥及与第二公钥对应的第二标记进行摘要正确性验证,依此类推,得到多个摘要正确性验证的结果,摘要正确性验证的结果数量与公私钥对的数量相同,只有当多个摘要正确性验证的结果中正确率达到一定阈值时,才认为摘要通过正确性验证。
例如:有3组公私钥对,正确率达到2/3就认为通过验证。通过3个私钥分别对摘要进行标记,得到3个签名,通过3个公钥分别与这3个签名进行摘要正确性验证,即第一公钥与第一签名验证,得到结果为Ture,第二公钥与第二签名验证,得到结果为Flase,第三公钥与第三签名验证,得到结果为True,那么,在上述3组公私钥对中,有2个结果为正确,1个结果为错误,则摘要通过验证。在本例中,可以认为第一私钥及第三私钥处于正常状态,没有出现被泄露或丢失等异常情况,而由于通过第二私钥得到的第二签名未通过验证,则认为第二私钥出现了被泄露或丢失等异常情况。
当摘要的正确性验证的正确率达到了第一阈值,则继续进行后续通过摘要确认升级版本数据的正确性的验证,当摘要的正确性验证的正确率未达到第一阈值,则退出流程,无需获取升级版本数据,也无需通过摘要确认升级版本数据的正确性验证。
进一步的,当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,生成的新的公私钥对的数量与出现异常的私钥数量相同,将存储于服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,通过固件升级将存储于待升级固件中的出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
具体的,当不少于两组公私钥对中有至少一个私钥出现异常,重新生成对应异常私钥数量的公私钥对,即若有一个私钥出现异常,则重新生成一组公私钥对,若有两个私钥出现异常,则重新生成两组公私钥对。
进一步的,不少于两组公私钥对中不少于两个私钥中,除异常私钥外为正常私钥,正常私钥数量占总私钥数量的比例不小于第一阈值,其中,正常私钥占总私钥数量中的第一阈值,与待升级固件的升级版本的正确率中的第一阈值的数值相同。
例如:有三组公私钥对,通过公钥及标记确定待升级固件的升级版本的正确率达到2/3时,升级版本通过验证,即第一阈值为2/3,当3个私钥中有1个出现异常,则有2个为正常状态,此时,正常私钥数量占总私钥数量的比例为2/3,2/3与第一阈值相同,则可以采用异常私钥及与异常私钥对应公钥的替换;当3个私钥中有2个出现异常,则有1个为正常状态,此时,正常私钥数量占总私钥数量的比例为1/3,1/3小于第一阈值,那么,则不能采用上述方式进行异常私钥及与异常私钥对应的公钥的替换。
在重新生成对应异常私钥数量的公私钥对后,将异常的私钥及与异常私钥对应的公钥进行替换,将其替换为重新生成的公私钥对,以使得替换完成的所有公私钥对中不包括异常的私钥及其对应的公钥。
其中,新生成的私钥直接保存在服务端,以替换异常的私钥,其中,新生成的私钥可以与需要被替换的私钥保存在同样的位置,即将异常的私钥转移至其他位置存储,而将新生成的私钥存储至异常私钥原来存储的位置,例如:第一私钥存储于第一位置,当第一私钥出现异常时,新生成第二公私钥对,将第一私钥从第一位置转移至第二位置,将第二公私钥对中的私钥,即第二私钥,存储至第一位置,从而实现第二私钥对第一私钥的替换。
而对于与异常私钥对应的公钥,也需要进行相应的替换,通过固件版本升级的方式将异常私钥对应的公钥替换为新生成的公私钥对中的公钥。
例如:当有3组公私钥对时,第一阈值为2/3,当有一个私钥出现异常时,有两个私钥为正常状态,那么,在进行升级版本的验证时,是可以通过两个正常私钥满足正确率未2/3的需求的,即可以正常进行固件版本的升级,在升级之后,直接将固件中存储的与1个异常私钥对应的1个公钥进行替换,替换为新生成的公钥,以便后期再次对固件进行更新时,可以通过公私钥对进行安全性校验。
另外,当不少于两组公私钥对中不少于两个私钥中,正常私钥数量占总私钥数量的比例小于第一阈值,第一阈值为通过公钥及标记确定待升级固件的升级版本的正确率达到第一阈值时,升级版本通过验证中的第一阈值,此时,在通过公私钥对中的正常私钥进行版本校验时,是不能达到第一阈值的。
此时,当正常私钥数量占总私钥数量的比例不小于第二阈值时,第二阈值小于第一阈值,可以采用所有正常私钥与预定数量的异常私钥共同验证,以达到固件版本升级的目的,采用全部正常私钥,从而避免不采用或少采用正常私钥导致的异常私钥数量过多,从而使升级版本被黑客或不法分子篡改导致数据泄露或其他损失。其中,预定数量为:预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
例如:当有3组公私钥对时,第一阈值为2/3,第二阈值为1/3,当有一个私钥出现异常时,有两个私钥为正常状态,那么,在进行升级版本的验证时,是可以通过两个正常私钥满足正确率未2/3的需求的;而当有2个私钥出现异常时,正常私钥数量占总私钥数量的比例为1/3,该比值是小于第一阈值的,且与第二阈值相同,则可以采用第二阈值的方式进行版本升级。即,采用1个正常私钥及1个异常私钥进行版本校验,进而进行版本升级,其中,1个正常私钥与1个异常私钥相加的和为2,占所有总私钥数量的比例为2/3,是能够达到第一阈值的。
本实施例公开的固件验证方法,应用于电子设备,获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端,从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。本方案由电子设备通过公钥对待升级固件的升级版本进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本实施例公开了一种服务器,其结构示意图如图7所示,包括:
确定单元71,获取单元72,标记单元73及发送单元74。
其中,确定单元71用于确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
当有设备中承载有一个固件时,该设备在出厂时,会自带某个版本的固件,当服务器中有针对该固件的升级版本时,可以下载该升级版本,以便于对固件进行升级。
在升级过程中,为了避免该升级版本的来源不可靠,需要生成公私钥对,以便于对该升级版本进行签名验证。
具体的,在设备出厂时携带的固件中会预先存储有至少一组公私钥对,,无需单独生成,并将至少一组公私钥对中的公钥KEYpub存储于固件中,将至少一组公私钥对中的私钥KEYpriv存储于服务端,具体的,服务端可以为管理员处,也可以为存储设备等,如:将私钥保存于管理员处,以便于后续使用。
当需要对设备中承载的固件版本进行升级时,生成至少一组公私钥对,将至少一组公私钥对中的公钥存储于该待升级的固件中,将至少一组公私钥对中的私钥存储于服务端。
其中,当公私钥对为不少于两组时,将不少于两组公私钥对中的私钥分别存储于服务端,具体的,可以为:将每个私钥分别存储于不同的服务端,或,同一个服务端的不同位置,如:第一私钥存储于第一管理员处,第二私钥存储于第二管理员处,第三私钥存储于第三管理员处,以避免私钥同时出现被泄露或丢失等异常情况,保证了不少于两组公私钥对中私钥的安全性。
获取单元72用于获取待升级固件的升级版本的摘要;
获取待升级固件的升级版本的摘要Flash Digest,即hash值,以便于通过hash值确定该待升级固件的升级版本的完整性。
具体的,为了实现本方案中对固件升级版本的签名验证,其签名算法可以采用ECDSA(椭圆曲线数字签名算法),ECDSA是ECC与DSA的结合,整个签名过程与DSA类似,所不一样的是签名中采用的算法为ECC。
在ECDSA中,摘要算法采用SHA256,也可以使用SHA1等其他算法,被称为:SHA256withECDSA或SHA1withECDSA,即在性能满足的情况下,使用SHA256withECDSA,特殊情况下采用其他的摘要算法,如:SHA1withECDSA。
标记单元73用于依次通过至少一组公私钥对中的私钥对摘要进行标记;
使用公私钥对中的私钥对摘要Flash Digest进行标记,得到签名Flash Sign。
当只有一组公私钥对时,使用唯一的私钥对摘要Flash Digest进行标记,得到一个签名Flash Sign;当有不少于两组公私钥对时,依次通过每一个私钥对摘要FlashDigest进行标记,得到不少于两个签名Flash Sign1,Flash Sign2,…,Flash SignN。
例如:当有三组公私钥对时,通过第一私钥对摘要Flash Digest进行标记,得到签名Flash Sign1,通过第二私钥对摘要Flash Digest进行标记,得到签名Flash Sign2,通过第三私钥对摘要Flash Digest进行标记,得到签名Flash Sign3。
发送单元74用于将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。
将固件升级包信息发送至电子设备,由电子设备通过待升级固件中的公钥与进行的标记对待升级固件的升级版本进行验证。
其中,公钥为预先存储于待升级固件中的,并且,公钥与私钥为一组,是有对应关系的,通过私钥对升级版本的摘要进行标记,得到签名,通过公钥与签名进行匹配或比较,从而可以确认该升级版本的摘要是否通过验证,从而确定该升级版本的来源是否可靠。
当该升级版本的摘要通过验证,则表明该升级版本的来源可靠,当该升级版本的摘要未通过验证,则表明该升级版本的来源不可靠。
当该升级版本的来源不可靠时,其可能为至少一组公私钥对中的私钥发生泄漏或丢失等异常情况,造成该升级版本被黑客或其他不法人员利用,从而导致的升级版本来源不可靠。
进一步的,还可以包括:密钥更新单元。
其中,密钥更新单元用于:当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,生成的新的公私钥对的数量与出现异常的私钥数量相同,将存储于服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,通过固件升级将存储于待升级固件中与出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
具体的,当不少于两组公私钥对中有至少一个私钥出现异常,重新生成对应异常私钥数量的公私钥对,即若有一个私钥出现异常,则重新生成一组公私钥对,若有两个私钥出现异常,则重新生成两组公私钥对。
其中,私钥出现异常可以具体为:私钥丢失或泄露等异常情况。
例如:私钥存储于存储设备中,当存储设备中数据丢失或被删除时,则私钥出现异常,需要进行密钥的更新。
具体的,若私钥存储于存储设备中,则可以通过确定存储设备中数据是否被删除,或者,数据是否被未知用户读取等来确定存储设备中的数据是否丢失或泄露;若私钥存储于管理员处,则需要由管理员上传数据丢失或泄露的信息,从而确定私钥出现异常。
本实施例公开的服务器,确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。本方案通过私钥对待升级固件的升级版本的摘要进行标记,并由电子设备通过公钥对该标记进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本实施例公开了一种电子设备,其结构示意图如图8所示,包括:
获取单元81及验证单元82。
其中,获取单元81用于获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
验证单元82用于从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。
固件升级包信息是由服务器发送至电子设备的,在发送至电子设备之前,服务器需要确定待升级固件,生成至少一组公私钥对,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,之后服务器将待升级固件的升级版本数据、摘要及对摘要进行的标记打包存储为固件升级包信息,之后将固件升级包信息发送至电子设备,以便通过电子设备对待升级固件的升级版本进行验证。
其中,待升级固件是电子设备中的待升级固件,在电子设备对待升级固件的升级版本的验证通过后,由电子设备对待升级固件进行升级,使其升级到该验证通过的升级版本,从而使得电子设备中的待升级固件的升级版本来源可靠。
将待升级固件的升级版本数据Flash Image、摘要Flash Digest及对摘要进行标记得到的签名Flash Sign存储至固件升级包信息OTA Info,以便于将升级版本数据、升级版本的摘要及对摘要进行的签名存储至一处,便于管理。
另外,在对待升级固件的升级版本进行验签的过程中,仅需要从固件升级包信息中获取数据即可。
当公私钥对为一组时,通过这一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证,其流程如图3所示。
具体的,将公钥及摘要的标记进行匹配或比较,当匹配成功,或,比较判定该公钥与标记中的私钥信息匹配,则表明该标记对应的摘要通过验证,从而确定该待升级固件的升级版本通过验证,其来源可靠;当匹配失败,或,比较判定该公钥与标记中的私钥信息不匹配,则表明该标记对应的摘要未通过验证,从而确定该升级版本未通过验证,其来源不可靠,不对待升级固件进行版本更新。
当公私钥对为一组时,固件升级包信息中可以仅存储升级版本数据及标记,由于在验证过程中,并不需要摘要的信息,则可以无需存储摘要。
当公私钥对为不少于两组时,通过不少于两组公私钥对中的公钥及标记确定摘要的正确性,当摘要的正确性验证通过时,通过摘要确定待升级固件的升级版本的正确性。
具体的,首先获取固件升级包信息中的标记及摘要,通过标记确认摘要的正确性,其流程如图4所示,即验证公钥及标记中的私钥信息是否匹配,若匹配,则表明摘要通过正确性验证。由于公私钥对为不少于两组,那么,通过私钥确定的标记也为不少于两个,在确定摘要的正确性的过程中是需要多次验证的,有几组公私钥对就需要验证对应次数的摘要,从而得到最终摘要是否通过验证的结论。
具体的,可以为:将不少于两组公私钥对中的不少于两个公钥、摘要及不少于两个标记进行算法验证,若验证通过,则表明摘要正确。
具体的,将不少于两个公钥KEYpub、摘要Flash Digest及不少于两个标记FlashSign输入ECDSA做VERIFY算法的验证,若验证成功则表明Flash Digest是正确的。
具体的,由于每一组公私钥对中的私钥均对应一个标记,因此,当一个标记、与该标记对应的一个公钥及摘要进行算法验证时,可以验证公钥与标记对应的私钥是否匹配,并可进一步确定摘要是否能够通过该组公私钥对的验证,当摘要能够通过该组公私钥对的验证时,则表明该摘要的正确性验证通过,即摘要是正确的。
当摘要通过验证后,获取升级版本数据Flash Image,使用摘要Flash Digest确认升级版本数据Flash Image的正确性,其流程如图5所示。当确认Flash Image合法后,将升级版本数据Flash Image转移至代码区,以便于对待升级固件进行更新。
进一步的,验证单元82用于:当公私钥对为不少于两组时,通过不少于两组公私钥对中的公钥及标记确定待升级固件的升级版本的正确率是否达到第一阈值,当正确率达到第一阈值时,待升级固件的升级版本通过验证。
当公私钥对为一组时,通过公钥及标记可以直接得到升级版本是否通过验证的结论;
当公私钥对为不少于两组时,由于公钥及私钥分别为不少于两个,标记是通过私钥得到的,那么,标记也为不少于两个,通过不少于两个公钥中的公钥及与该公钥对应的标记进行摘要正确性验证,即通过第一公钥及与第一公钥对应的第一标记进行摘要正确性验证,通过第二公钥及与第二公钥对应的第二标记进行摘要正确性验证,依此类推,得到多个摘要正确性验证的结果,摘要正确性验证的结果数量与公私钥对的数量相同,只有当多个摘要正确性验证的结果中正确率达到一定阈值时,才认为摘要通过正确性验证。
例如:有3组公私钥对,正确率达到2/3就认为通过验证。通过3个私钥分别对摘要进行标记,得到3个签名,通过3个公钥分别与这3个签名进行摘要正确性验证,即第一公钥与第一签名验证,得到结果为Ture,第二公钥与第二签名验证,得到结果为Flase,第三公钥与第三签名验证,得到结果为True,那么,在上述3组公私钥对中,有2个结果为正确,1个结果为错误,则摘要通过验证。在本例中,可以认为第一私钥及第三私钥处于正常状态,没有出现被泄露或丢失等异常情况,而由于通过第二私钥得到的第二签名未通过验证,则认为第二私钥出现了被泄露或丢失等异常情况。
当摘要的正确性验证的正确率达到了第一阈值,则继续进行后续通过摘要确认升级版本数据的正确性的验证,当摘要的正确性验证的正确率未达到第一阈值,则退出流程,无需获取升级版本数据,也无需通过摘要确认升级版本数据的正确性验证。
进一步的,不少于两组公私钥对中不少于两个私钥中,除异常私钥外为正常私钥,正常私钥数量占总私钥数量的比例不小于第一阈值,其中,正常私钥占总私钥数量中的第一阈值,与待升级固件的升级版本的正确率中的第一阈值的数值相同。
例如:有三组公私钥对,通过公钥及标记确定待升级固件的升级版本的正确率达到2/3时,升级版本通过验证,即第一阈值为2/3,当3个私钥中有1个出现异常,则有2个为正常状态,此时,正常私钥数量占总私钥数量的比例为2/3,2/3与第一阈值相同,则可以采用异常私钥及与异常私钥对应公钥的替换;当3个私钥中有2个出现异常,则有1个为正常状态,此时,正常私钥数量占总私钥数量的比例为1/3,1/3小于第一阈值,那么,则不能采用上述方式进行异常私钥及与异常私钥对应的公钥的替换。
在重新生成对应异常私钥数量的公私钥对后,将异常的私钥及与异常私钥对应的公钥进行替换,将其替换为重新生成的公私钥对,以使得替换完成的所有公私钥对中不包括异常的私钥及其对应的公钥。
其中,新生成的私钥直接保存在服务端,以替换异常的私钥,其中,新生成的私钥可以与需要被替换的私钥保存在同样的位置,即将异常的私钥转移至其他位置存储,而将新生成的私钥存储至异常私钥原来存储的位置,例如:第一私钥存储于第一位置,当第一私钥出现异常时,新生成第二公私钥对,将第一私钥从第一位置转移至第二位置,将第二公私钥对中的私钥,即第二私钥,存储至第一位置,从而实现第二私钥对第一私钥的替换。
而对于与异常私钥对应的公钥,也需要进行相应的替换,通过固件版本升级的方式将异常私钥对应的公钥替换为新生成的公私钥对中的公钥。
例如:当有3组公私钥对时,第一阈值为2/3,当有一个私钥出现异常时,有两个私钥为正常状态,那么,在进行升级版本的验证时,是可以通过两个正常私钥满足正确率未2/3的需求的,即可以正常进行固件版本的升级,在升级之后,直接将固件中存储的与1个异常私钥对应的1个公钥进行替换,替换为新生成的公钥,以便后期再次对固件进行更新时,可以通过公私钥对进行安全性校验。
另外,当不少于两组公私钥对中不少于两个私钥中,正常私钥数量占总私钥数量的比例小于第一阈值,第一阈值为通过公钥及标记确定待升级固件的升级版本的正确率达到第一阈值时,升级版本通过验证中的第一阈值,此时,在通过公私钥对中的正常私钥进行版本校验时,是不能达到第一阈值的。
此时,当正常私钥数量占总私钥数量的比例不小于第二阈值时,第二阈值小于第一阈值,可以采用所有正常私钥与预定数量的异常私钥共同验证,以达到固件版本升级的目的,采用全部正常私钥,从而避免不采用或少采用正常私钥导致的异常私钥数量过多,从而使升级版本被黑客或不法分子篡改导致数据泄露或其他损失。其中,预定数量为:预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
例如:当有3组公私钥对时,第一阈值为2/3,第二阈值为1/3,当有一个私钥出现异常时,有两个私钥为正常状态,那么,在进行升级版本的验证时,是可以通过两个正常私钥满足正确率未2/3的需求的;而当有2个私钥出现异常时,正常私钥数量占总私钥数量的比例为1/3,该比值是小于第一阈值的,且与第二阈值相同,则可以采用第二阈值的方式进行版本升级。即,采用1个正常私钥及1个异常私钥进行版本校验,进而进行版本升级,其中,1个正常私钥与1个异常私钥相加的和为2,占所有总私钥数量的比例为2/3,是能够达到第一阈值的。
本实施例公开的电子设备,获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端,从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。本方案由电子设备通过公钥对待升级固件的升级版本进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本实施例公开了一种固件验证***,其结构示意图如图9所示,包括:
服务器91及电子设备92。
其中,服务器91的结构示意图如图7所示,包括:确定单元,获取单元,标记单元及发送单元,其中:
确定单元用于确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
获取单元用于获取待升级固件的升级版本的摘要;
标记单元用于依次通过至少一组公私钥对中的私钥对摘要进行标记;
发送单元用于将固件升级包信息发送至电子设备,以便于电子设备通过固件升级包信息及至少一组公私钥对中的公钥对待升级固件的升级版本进行验证,其中,固件升级包信息包括:待升级固件的升级版本数据、摘要及对摘要进行的标记。
电子设备92的结构示意图如图8所示,包括:获取单元及验证单元,其中:
获取单元用于获取服务器发送的固件升级包信息,固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端;
验证单元用于从固件升级包信息中获取待升级固件的升级版本数据、摘要及对摘要进行的标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。
本实施例所公开的固件验证***中的服务器及电子设备均是与上述是实施例相同,在此不再赘述。
本发明公开了一种固件验证***,确定待升级固件,生成至少一组公私钥对,公私钥对包括:存储于待升级固件中的公钥及存储于服务端的私钥,当公私钥对不少于两组时,私钥被分别存储于服务端,获取待升级固件的升级版本的摘要,依次通过至少一组公私钥对中的私钥对摘要进行标记,通过至少一组公私钥对中的公钥及标记对待升级固件的升级版本进行验证。本方案通过私钥对待升级固件的升级版本的摘要进行标记,并通过公钥对该标记进行验证,只有验证通过后才能对固件进行升级,避免了现有技术中未对完整固件做可信签名校验,从而导致可能承载该固件的设备受到来自黑客恶意的设备升级攻击的问题。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (14)
1.一种固件验证方法,应用于服务器,其特征在于,包括:
确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
获取所述待升级固件的升级版本的摘要;
依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记。
2.根据权利要求1所述的方法,其特征在于,还包括:
当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,所述生成的新的公私钥对的数量与出现异常的私钥数量相同;
将存储于所述服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,并通过所述电子设备对固件的升级将存储于所述待升级固件中与所述出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
3.一种固件验证方法,应用于电子设备,其特征在于,包括:
获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
4.根据权利要求3所述的方法,其特征在于,所述通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证,包括:
当所述公私钥对为一组时:
通过所述一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证;
当所述公私钥对为不少于两组时:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性;
当所述摘要的正确性验证通过时,通过所述摘要确定所述待升级固件的升级版本的正确性。
5.根据权利要求4所述的方法,其特征在于,所述当所述公私钥对为不少于两组时,通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性,包括:
当所述公私钥对为不少于两组时,将所述不少于两组公私钥对中的不少于两个公钥、所述摘要及所述不少于两个标记进行算法验证,若验证通过,则表明所述摘要正确。
6.根据权利要求3所述的方法,其特征在于,当所述公私钥对为不少于两组时,所述通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证,包括:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述待升级固件的升级版本的正确率是否达到第一阈值;
当所述正确率达到第一阈值时,所述待升级固件的升级版本通过验证。
7.根据权利要求6所述的方法,其特征在于,所述当所述公私钥对不少于两组时,对所述摘要进行标记,包括:
当正常私钥数量占总私钥数量的比例不小于第二阈值时,分别通过所有正常私钥与预定数量的异常私钥对所述摘要进行标记,其中,所述总私钥由正常私钥与异常私钥组成,所述第二阈值小于第一阈值,所述预定数量为预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
8.一种服务器,其特征在于,包括:确定单元,获取单元,标记单元及发送单元,其中:
所述确定单元用于确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述获取单元用于获取所述待升级固件的升级版本的摘要;
所述标记单元用于依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
所述发送单元用于将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记。
9.根据权利要求8所述的服务器,其特征在于,还包括:密钥更新单元,其中:
所述密钥更新单元用于:当不少于两组公私钥对中有至少一个私钥出现异常时,生成至少一组新的公私钥对,所述生成的新的公私钥对的数量与出现异常的私钥数量相同;
将存储于所述服务端的出现异常的至少一个私钥替换为新生成的公私钥对中的私钥,并通过所述电子设备对固件的升级将存储于所述待升级固件中与所述出现异常的至少一个私钥对应的至少一个公钥替换为新生成的公私钥对中的公钥。
10.一种电子设备,其特征在于,包括:获取单元及验证单元,其中:
所述获取单元用于获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述验证单元用于从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
11.根据权利要求10所述的电子设备,其特征在于,所述验证单元用于:
当所述公私钥对为一组时:
通过所述一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证;
当所述公私钥对为不少于两组时:
通过所述不少于两组公私钥对中的公钥及所述标记确定所述摘要的正确性;
当所述摘要的正确性验证通过时,通过所述摘要确定所述待升级固件的升级版本的正确性。
12.根据权利要求11所述的电子设备,其特征在于,所述验证单元具体用于:
当所述公私钥对为不少于两组时,将所述不少于两组公私钥对中的不少于两个公钥、所述摘要及所述不少于两个标记进行算法验证,若验证通过,则表明所述摘要正确。
13.根据权利要求11所述的电子设备,其特征在于,所述获取单元具体用于:
当正常私钥数量占总私钥数量的比例不小于第二阈值时,分别通过所有正常私钥与预定数量的异常私钥对所述摘要进行标记,其中,所述总私钥由正常私钥与异常私钥组成,所述第二阈值小于第一阈值,所述预定数量为预定数量与所有正常私钥数量相加的和占总私钥数量的比例为第一阈值时的预定数量。
14.一种固件验证***,其特征在于,包括:服务器及电子设备,其中:
所述服务器包括:确定单元,获取单元,标记单元及发送单元,其中:
所述确定单元用于确定待升级固件,生成至少一组公私钥对,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述获取单元用于获取所述待升级固件的升级版本的摘要;
所述标记单元用于依次通过所述至少一组公私钥对中的私钥对所述摘要进行标记;
所述发送单元用于将固件升级包信息发送至电子设备,以便于所述电子设备通过所述固件升级包信息及所述至少一组公私钥对中的公钥对所述待升级固件的升级版本进行验证,其中,所述固件升级包信息包括:所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记;
所述电子设备包括:获取单元及验证单元,其中:
所述获取单元用于获取服务器发送的固件升级包信息,所述固件升级包信息包括:待升级固件的升级版本数据、摘要及依次通过至少一组公私钥对中的私钥对摘要进行的标记,所述公私钥对包括:存储于所述待升级固件中的公钥及存储于服务端的私钥,当所述公私钥对不少于两组时,所述私钥被分别存储于服务端;
所述验证单元用于从所述固件升级包信息中获取所述待升级固件的升级版本数据、所述摘要及对所述摘要进行的标记,通过所述至少一组公私钥对中的公钥及所述标记对所述待升级固件的升级版本进行验证。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910097384.6A CN109829294B (zh) | 2019-01-31 | 2019-01-31 | 一种固件验证方法、***、服务器及电子设备 |
PCT/CN2019/094682 WO2020007339A1 (en) | 2018-07-04 | 2019-07-04 | Method and system for operating an electronic device |
US17/141,189 US11743336B2 (en) | 2018-07-04 | 2021-01-04 | Method and system for operating an electronic device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910097384.6A CN109829294B (zh) | 2019-01-31 | 2019-01-31 | 一种固件验证方法、***、服务器及电子设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109829294A true CN109829294A (zh) | 2019-05-31 |
CN109829294B CN109829294B (zh) | 2021-07-13 |
Family
ID=66863308
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910097384.6A Active CN109829294B (zh) | 2018-07-04 | 2019-01-31 | 一种固件验证方法、***、服务器及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109829294B (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110287725A (zh) * | 2019-06-04 | 2019-09-27 | 大唐微电子技术有限公司 | 一种设备及其权限控制方法、计算机可读存储介质 |
CN110298145A (zh) * | 2019-06-28 | 2019-10-01 | 兆讯恒达微电子技术(北京)有限公司 | 一种基于公开密钥密码算法的固件程序装载保护方法 |
CN110378105A (zh) * | 2019-07-02 | 2019-10-25 | 广州小鹏汽车科技有限公司 | 安全升级方法、***、服务器及车载终端 |
CN111309360A (zh) * | 2020-02-07 | 2020-06-19 | 腾讯科技(深圳)有限公司 | 快充设备的固件更新方法、装置、计算机设备及存储介质 |
CN111382397A (zh) * | 2020-02-26 | 2020-07-07 | 浙江大华技术股份有限公司 | 升级软件包配置方法、软件升级方法、设备及存储装置 |
CN111880828A (zh) * | 2020-07-31 | 2020-11-03 | 苏州浪潮智能科技有限公司 | 一种在Secure Boot环境中批量升级多板卡驱动的方法 |
CN112929871A (zh) * | 2019-12-05 | 2021-06-08 | 上海艾拉比智能科技有限公司 | Ota升级包的获取方法、电子设备以及存储介质 |
CN114637987A (zh) * | 2022-05-18 | 2022-06-17 | 广州万协通信息技术有限公司 | 基于平台验证的安全芯片固件下载方法及*** |
US11847201B2 (en) | 2019-11-19 | 2023-12-19 | Micron Technology, Inc. | Authenticating a device using a remote host |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050204348A1 (en) * | 1999-07-29 | 2005-09-15 | Inter Trust Technologies Corporation | Software self-defense systems and methods |
CN1822015A (zh) * | 2002-04-17 | 2006-08-23 | 微软公司 | 基于公开密钥加密的数据存储和数据检索 |
CN101436141A (zh) * | 2008-11-21 | 2009-05-20 | 深圳创维数字技术股份有限公司 | 基于数字签名的固件升级、固件封装方法与装置 |
CN103117857A (zh) * | 2013-01-16 | 2013-05-22 | 深圳市怡化电脑有限公司 | 基于硬件加密算法的atm机信息安全检测方法及*** |
CN104166565A (zh) * | 2014-08-11 | 2014-11-26 | 成都瑞博慧窗信息技术有限公司 | 一种智能显示终端固件升级方法 |
CN104915591A (zh) * | 2014-03-10 | 2015-09-16 | 联想(北京)有限公司 | 一种数据处理方法及电子设备 |
CN105701372A (zh) * | 2015-12-18 | 2016-06-22 | 布比(北京)网络技术有限公司 | 一种区块链身份构建及验证方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106412121A (zh) * | 2016-11-21 | 2017-02-15 | 四川长虹电器股份有限公司 | 应用于智能冰箱上的***安全升级方法 |
-
2019
- 2019-01-31 CN CN201910097384.6A patent/CN109829294B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050204348A1 (en) * | 1999-07-29 | 2005-09-15 | Inter Trust Technologies Corporation | Software self-defense systems and methods |
CN1822015A (zh) * | 2002-04-17 | 2006-08-23 | 微软公司 | 基于公开密钥加密的数据存储和数据检索 |
CN101436141A (zh) * | 2008-11-21 | 2009-05-20 | 深圳创维数字技术股份有限公司 | 基于数字签名的固件升级、固件封装方法与装置 |
CN103117857A (zh) * | 2013-01-16 | 2013-05-22 | 深圳市怡化电脑有限公司 | 基于硬件加密算法的atm机信息安全检测方法及*** |
CN104915591A (zh) * | 2014-03-10 | 2015-09-16 | 联想(北京)有限公司 | 一种数据处理方法及电子设备 |
CN104166565A (zh) * | 2014-08-11 | 2014-11-26 | 成都瑞博慧窗信息技术有限公司 | 一种智能显示终端固件升级方法 |
CN105701372A (zh) * | 2015-12-18 | 2016-06-22 | 布比(北京)网络技术有限公司 | 一种区块链身份构建及验证方法 |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110287725A (zh) * | 2019-06-04 | 2019-09-27 | 大唐微电子技术有限公司 | 一种设备及其权限控制方法、计算机可读存储介质 |
CN110298145A (zh) * | 2019-06-28 | 2019-10-01 | 兆讯恒达微电子技术(北京)有限公司 | 一种基于公开密钥密码算法的固件程序装载保护方法 |
CN110378105A (zh) * | 2019-07-02 | 2019-10-25 | 广州小鹏汽车科技有限公司 | 安全升级方法、***、服务器及车载终端 |
US11847201B2 (en) | 2019-11-19 | 2023-12-19 | Micron Technology, Inc. | Authenticating a device using a remote host |
CN112929871A (zh) * | 2019-12-05 | 2021-06-08 | 上海艾拉比智能科技有限公司 | Ota升级包的获取方法、电子设备以及存储介质 |
CN111309360A (zh) * | 2020-02-07 | 2020-06-19 | 腾讯科技(深圳)有限公司 | 快充设备的固件更新方法、装置、计算机设备及存储介质 |
CN111309360B (zh) * | 2020-02-07 | 2022-06-28 | 腾讯科技(深圳)有限公司 | 快充设备的固件更新方法、装置、计算机设备及存储介质 |
CN111382397A (zh) * | 2020-02-26 | 2020-07-07 | 浙江大华技术股份有限公司 | 升级软件包配置方法、软件升级方法、设备及存储装置 |
CN111880828A (zh) * | 2020-07-31 | 2020-11-03 | 苏州浪潮智能科技有限公司 | 一种在Secure Boot环境中批量升级多板卡驱动的方法 |
CN111880828B (zh) * | 2020-07-31 | 2022-07-01 | 苏州浪潮智能科技有限公司 | 一种在Secure Boot环境中批量升级多板卡驱动的方法 |
CN114637987A (zh) * | 2022-05-18 | 2022-06-17 | 广州万协通信息技术有限公司 | 基于平台验证的安全芯片固件下载方法及*** |
CN114637987B (zh) * | 2022-05-18 | 2022-08-12 | 广州万协通信息技术有限公司 | 基于平台验证的安全芯片固件下载方法及*** |
Also Published As
Publication number | Publication date |
---|---|
CN109829294B (zh) | 2021-07-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109829294A (zh) | 一种固件验证方法、***、服务器及电子设备 | |
CN109313690B (zh) | 自包含的加密引导策略验证 | |
US10474823B2 (en) | Controlled secure code authentication | |
CN107396360B (zh) | 区块验证方法及装置 | |
US9705678B1 (en) | Fast CAN message authentication for vehicular systems | |
US7127067B1 (en) | Secure patch system | |
CN107483509A (zh) | 一种身份验证方法、服务器及可读存储介质 | |
US8874922B2 (en) | Systems and methods for multi-layered authentication/verification of trusted platform updates | |
CN108334753B (zh) | 盗版应用验证方法和分布式服务器节点 | |
US8028167B2 (en) | Method and apparatus for certificate roll-over | |
CN104166564B (zh) | 一种显示终端程序更新方法 | |
TW201516733A (zh) | 用以核對uefi認證變量變化之系統及方法 | |
CN108234134A (zh) | 区块同步方法及*** | |
CN105706099A (zh) | 软件更新装置及软件更新程序 | |
JP2008527510A (ja) | 処理デバイスのメモリコンテンツの更新 | |
CN107992753B (zh) | 用于更新车辆的控制设备的软件的方法 | |
CN110795126A (zh) | 一种固件安全升级*** | |
CN114065176A (zh) | 安全运算装置、安全运算方法、验证器及装置验证方法 | |
CN111160879B (zh) | 一种硬件钱包及其安全性提升方法和装置 | |
KR20050056204A (ko) | 메시지 무결성 보증 시스템, 방법 및 기록 매체 | |
EP3436949A1 (en) | Data recovery with authenticity | |
CN111585995A (zh) | 安全风控信息传输、处理方法、装置、计算机设备及存储介质 | |
CN114448794B (zh) | 一种基于芯片可信根对固件进行安全升级的方法及装置 | |
CN111064723A (zh) | 一种基于备份***的空中下载升级方法及*** | |
CN111506915A (zh) | 授权访问的控制方法、装置和*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CP01 | Change in the name or title of a patent holder | ||
CP01 | Change in the name or title of a patent holder |
Address after: 100085 a521, 5th floor, block a, Huilongguan maker Plaza, 338 Huilongguan East Street, Changping District, Beijing Patentee after: Yunding Network Technology (Beijing) Co.,Ltd. Address before: 100085 a521, 5th floor, block a, Huilongguan maker Plaza, 338 Huilongguan East Street, Changping District, Beijing Patentee before: YUN DING NETWORK TECHNOLOGY (BEIJING) Co.,Ltd. |