CN115329321A - 一种固件的启动方法、芯片及计算设备 - Google Patents

Abstract

一种固件的启动方法，该方法可以包括：获取客户根公钥，用所述固件预存的原始根公钥验证所述客户根公钥，若所述客户根公钥验证成功，存储所述客户根公钥，其中，所述客户根公钥基于用户设定的信息生成；在重新启动固件的情况下，根据所述客户根公钥对所述固件进行验证；基于所述固件验证成功，启动所述目标固件。使得当客户对固件生产厂商提供商的密钥安全性不信任时，可以通过现网在OTP中烧写客户根密钥信息，并在后续的固件启动过程中，通过烧写的客户根密钥对固件的安全性进行验证。

Description

一种固件的启动方法、芯片及计算设备

技术领域

本发明涉及信息安全技术领域,尤其涉及一种固件的启动方法、芯片及计算设备。

背景技术

随着网络以及数据中心的快速发展，作为数据中心核心的服务器面临着内部或外部的各种安全危险。服务器的管理系统提供服务器的硬件管理，而服务器的硬件的安全依赖于服务器自身提供的固件(fireware)的安全性。固件的安全性是通过验证方式来保证，只有验证通过后的固件才可以正常启动。由于，用于对目标固件进行验证的密钥是存储在一次性可编程存储器(one time programmable,OTP)中的。因此，当黑客攻克签名服务器或者用于对目标固件进行验证的密钥发生泄漏时，会导致目标固件处于安全风险中。

发明内容

本申请提供了一种固件的启动方法、芯片及计算设备，当客户对固件生产厂商提供商的密钥安全性不信任时，可以通过现网在OTP中烧写客户根公钥信息，并在后续的固件启动过程中，通过烧写的客户根公钥对固件的安全性进行验证。

第一方面，本申请提供了一种固件的启动方法，包括：获取客户根公钥，用固件预存的原始根公钥验证客户根公钥，若客户根公钥验证成功，存储客户根公钥，其中，客户根公钥基于用户设定的信息生成；在重新启动固件的情况下，根据客户根公钥对固件进行验证；基于固件验证成功，启动目标固件。

在本方案中，当客户在使用过程中对固件生产厂商提供的密钥安全不信任时，可以在现网阶段将客户自己设定的密钥信息(根公钥)烧写到OTP中。使得在启动固件时，可以使用客户自己设定的根公钥对固件进行验证，增强了固件的安全性。

在一个可能的实现方式中，该方法还包括：获取客户根公钥的签名；用固件预存的原始根公钥验证客户根公钥，若客户根公钥验证成功，存储客户根公钥，包括：使用固件预存的原始根公钥验证客户根公钥的签名；若原始根公钥对客户根公钥的签名验证通过，使用客户根公钥对固件进行验证；若客户根公钥对固件的验证通过，存储客户根公钥。

也就是说，在将客户根公钥存储到OTP之前需要对客户根公钥进行两次验证。第一次使用原始根公钥对客户根公钥进行验证，保证存储到OTP中的客户根公钥为用户设定的客户根公钥。第二次使用客户根公钥对固件进行验证，以保证烧写到存储区域的客户根公钥的合法性，以及烧写到存储区域的客户根公钥能够对目标固件进行验证，以避免在使能客户根后导致目标固件无法启动。

在一个可能的实现方式中，该方法还包括：获取固件的原始根公钥，对原始根公钥进行验证；若原始根公钥的验证通过，使用原始根公钥对客户根公钥进行验证。

也就是说，在使用原始根公钥验证客户根公钥之前，，为了保证验证的准确性，还需对原始根公钥的合法性进行验证。只有确定原始根公钥合法以后，才使用原始根公钥对客户根公钥进行验证。

在一个可能的实现方式中，存储客户根公钥包括：将客户根公钥、客户根公钥的使能信息存储到一次性可编程OTP存储器。

在一个可能的实现方式中，根据客户根公钥对固件进行验证的具体方法包括：获取客户根公钥的代码签名，通过对客户根公钥的代码签名验证实现客户根公钥对固件的验证。

第二方面，本申请提供了一种芯片，芯片包括处理器和接口电路，处理器和接口电路电连接，处理器存储有固件，处理器用于：

获取客户根公钥，用固件预存的原始根公钥验证客户根公钥，若客户根公钥验证成功，存储客户根公钥，其中，客户根公钥基于用户设定的信息生成；

在重新启动固件的情况下，根据客户根公钥对固件进行验证；

基于固件验证成功，启动目标固件。

在一个可能的实现方式中，该处理器还用于：

获取客户根公钥的签名；

使用固件预存的原始根公钥验证客户根公钥的签名；

若原始根公钥对客户根公钥的签名验证通过，使用客户根公钥对固件进行验证；

若客户根公钥对固件的验证通过，存储客户根公钥。

在一个可能的实现方式中，该处理器还用于：

获取固件的原始根公钥，对原始根公钥进行验证；

若原始根公钥的验证通过，使用原始根公钥对客户根公钥进行验证。

在一个可能的实现方式中，该处理器还用于：

将客户根公钥、客户根公钥的使能信息存储到一次性可编程OTP存储器。

第三方面，本申请提供了一种固件，该固件包括：

获取模块，用于获取客户根公钥；

处理模块，用于用固件预存的原始根公钥验证客户根公钥，若客户根公钥验证成功，存储客户根公钥，其中，客户根公钥基于用户设定的信息生成；

处理模块，还用于在重新启动固件的情况下，根据客户根公钥对固件进行验证；

启动模块，用于基于目标固件验证成功，启动目标固件。

在一个可能的实现方式中，获取模块还用于：获取客户根公钥的签名；

处理模块还用于：

使用固件预存的原始根公钥验证客户根公钥的签名；

若原始根公钥对客户根公钥的签名验证通过，使用客户根公钥对固件进行验证；

若客户根公钥对固件的验证验证通过，存储客户根公钥。

在一个可能的实现方式中，获取模块还用于：获取固件的原始根公钥；

处理模块还用于：对原始根公钥进行验证；若原始根公钥的验证通过，使用原始根公钥对客户根公钥进行验证。

在一个可能的实现方式中，处理模块还用于：

将客户根公钥、客户根公钥的使能信息存储到一次性可编程OTP存储器。

第四方面，本申请提供了一种计算设备，计算设备包括主板和芯片，芯片集成在主板上，芯片包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第五方面，本申请提供了一种电子设备，其特征在于，包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第六方面，本申请提供了一种计算机可读介质，计算机存储介质中存储有指令，当指令在计算机上运行时，使得计算机执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第七方面，本申请提供了一种包含指令的计算机程序产品，当指令在计算机上运行时，使得计算机执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为一种固件的启动方法流程图；

图2为本申请实施例提供的一种固件的启动场景示意图；

图3为本申请实施例提供的一种BMC的结构示意图；

图4为本申请实施例提供的一种在OTP烧写客户根公钥信息的方法流程图；

图5为本申请实施例提供的一种目标固件的可执行文件的结构示意图；

图6为本申请实施例提供的一种烧写客户根公钥信息的方法流程图；

图7为本申请实施例提供的又一种在OTP烧写客户根公钥信息的方法流程图；

图8(a)为本申请实施例提供的一种OTP的结构示意图；

图8(b)为本申请实施例提供的一种OTP的结构示意图；

图9为本申请实施例提供的又一种在OTP烧写客户根公钥信息的方法流程图；

图10为本申请实施例提供的一种固件的启动方法流程图；

图11为本申请实施例提供的一种电子设备的结构示意图；

图12为本申请实施例提供的一种芯片的结构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图，对本申请实施例中的技术方案进行描述。

在本申请实施例中的描述中，“示例性的”、“例如”或者“举例来说”的任何实施例或设计方案不应该被理解为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

首先对本申请实施例中涉及的术语进行介绍。

1、单板，可以是指焊接上元器件的电路板。在本发明申请实施例中，单板可以是集成有CPU、基板管理控制器(baseboard management controller,BMC)、flash、总线或者其他元器件的电路板。

2、生产装备阶段，是指单板处于生产或者烧写程序的阶段，此时，单板还没有被封装成可以被用户使用的装置。

3、现网阶段，与生产装备阶段相对应。在本申请实施例中，现网阶段可以指单板已经被封装成对应的装置，用户可以使用的阶段。

单板的CPU、BMC或者其他芯片中均存储有固件，为了保证固件的安全性，生产厂商会对固件进行签名。生产厂商在对固件进行签名时，会生成一对密钥，包括一个私钥和一个公钥(在下文中也可以叫根公钥)。然后生产厂商使用私钥对固件进行签名，并将根公钥烧写到OTP寄存器。当单板启动时，可以通过OTP寄存器中保存的根公钥对固件进行验证，只有验证通过后的固件才可以正常启动。其中，固件可以是BMC的固件，示例的为BMC安全核的固件或用于提供业务功能的固件。固件还可以是uboot，uboot用于引导BMC系统。固件还可以是BIOS固件。

需要说明的是，在其他实施例中，BMC在不同计算设备中有不同的称呼，例如华为服务器、超聚变服务器的BMC为BMC，HPE服务器的BMC称为iLO，DELL服务器的BMC称为iDRAC。

图1示出了一种固件的启动方法。如图1所示，在固件的启动过程中，对固件的安全性验证过程包括：

S101，从OTP寄存器中读取本次启动过程中没有使用过的根公钥key_i。

S102，判断i是否小于等于n，当i＜＝n时，执行S103，否则执行S106。

S103，使用根公钥key_i验证固件。

S104，判断固件是否验证成功，当确定固件验证成功时，执行S105，否则，令i＝i+1,并执行S101。

S105，正常启动固件。

S106，固件启动失败。

在图1所示的固件启动过程中，在生产装备阶段，生产厂商就会在OTP寄存器内烧入根公钥key_1～key_n。这些key都是可信根，无法更改。当单板启动时，会使用OTP寄存器中存储的根公钥key去验证固件的安全性，以保证固件没有被篡改或者伪造。具体地，固件从OTP寄存器读取key_1，使用key_1对固件进行验证，如果验证通过，则单板正常启动。如果key_1验证不通过，则固件继续从OTP区读取key_2后，再继续验证。以此类推，直到所有的key都验证完。

虽然，图1中示出的固件启动方法能够对固件的安全性进行验证。但是，上述方法仍然存在有以下缺点。

1、OTP寄存器中的根公钥key在生产装备阶段一次性写入，在后续使用过程中无法更改，导致无法满足客户对安全多样性的需求。当客户对服务器提供商的根公钥的安全性不信任时(或者客户想要进行国密算法替换时)，无法在现网阶段烧入新的根公钥信息，也无法直接使用处于现网阶段的单板产品。

2、当黑客攻克签名服务器或者加密公钥失效时，导致签名固件都有风险。而无法更改OTP寄存器中的根公钥信息，会导致所有已生产完成的单板产品都处于安全风险中。

3、在启动单板上的固件时，OTP寄存器中的多个key以或的方式对固件进行验证。只要OTP寄存器中的一个key泄露就会导致固件的安全启动失效，使得固件处于较大的风险中。其次，当使用key_n签名固件时，每次启动固件都需要进行n-1次无效验证，导致启动时间增长，影响客户体验。

因此，为了解决上述方案中，在生产装备阶段烧入的根公钥泄露或者需要使用新的根公钥时，无法安全更改公钥的问题。本申请实施例提供了一种固件的启动方法，通过在逻辑上将OTP寄存器划分为不同的部分(比如，在逻辑上将OTP寄存器划分为第一OTP区和第二OTP区),使得当客户在使用过程中对服务器提供商的根公钥的安全性不信任时，可以在现网阶段向OTP寄存器烧写客户根公钥信息，并在后续的固件启动过程中，通过烧写的客户根公钥对固件的安全性进行验证。

示例性的，图2示出了一种固件的启动场景示意图。如图2所示，固件在启动过程中，需要获取第一OTP区或者第二OTP区存储的根公钥信息。其中，第一OTP区存储的根公钥信息为在生产装备阶段烧写的根公钥信息。第二OTP区存储的根公钥信息为在现网阶段烧写的根公钥信息。在本申请实施例中，可以将第一OTP区存储的根公钥称为根公钥1或者原始根公钥，将第二OTP区内存储的根公钥信息称为客户根公钥信息或者客户根公钥2，其中，客户根公钥2为自己设定的公钥。在启动固件时，默认从第一OTP区读取根公钥信息，并根据该根公钥信息对固件进行验证。当固件验证成功后，启动该固件。

当第一OTP区中的根公钥不符合安全要求时，固件先用第一OTP区的根公钥验证客户根公钥信息。当客户根公钥信息验证通过以后，固件将客户根公钥信息烧入第二OTP区，同时在第二OTP区烧写客户根的使能信息en。当固件重启以后，固件需要从第二OTP区读取验证信息来验证启动相应的固件。在一个可能的示例中，第一OTP区的根公钥不符合安全要求的情况包括：由于黑客攻击签名服务器导致密钥泄露的情况，或者客户对生产厂商提供的密钥的性不信任的情况。

在一个可能的示例中，本申请实施例提供的固件的启动方法，可以应用于服务器上的基板管理控制器(baseboard management controller,BMC)。BMC是部署于服务器单板上具有独立供电、独立I/O接口的控制单元，它不依赖于服务器的处理器、基本输入输出系统(basic input output system,BIOS)或者操作系统来工作，是一个单独在服务器内运行的无代理管理子系统。在单板上电过程中，先给BMC上电，使得BMC启动，BMC启动以后带动服务器启动。由于BMC先上电，因此，它可以获得服务器系统的控制权，所以BMC对于服务器的安全显得尤为重要。因此，在BMC启动阶段，需要对存储在BMC中的固件的安全性进行验证。

示例性的，本申请实施例还提供了一种BMC的结构示意图。如图3所示，BMC可以包括：处理器310，网络接口320，及存储器330。其中，处理器310，网络接口320，及存储器330可通过总线或其他方式连接。

本申请实施例中，处理器310(或称为中央处理器(central processing unit,CPU))是BMC的计算核心及控制核心。在一个可能的例子中，在处理器310的内部还包括OTP寄存器。该OTP寄存器可以在逻辑上分为如图2中所示的第一OTP区和第二OTP区。其中，第一OTP区和第二OTP区的可烧写阶段不同。第一OTP区只能在生产装备阶段进行烧写。第二OTP区可以在生产装备阶段或者现网阶段进行烧写。

网络接口320可以包括标准的有线接口，无线接口(如WI-FI，移动通信接口等)，受处理器310的控制用于收发数据，例如，从网络上接收用户输入的根公钥信息等。

存储器330(memory)是服务器的记忆设备，用于存放程序和数据。可以理解的是，此次的存储器330可以是高速RAM存储器，也可以是非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器；可选地还可以是至少一个位于远离前述处理器310的存储装置。存储器330提供存储空间，该存储空间存储了服务器的操作系统和可执行程序代码，可包括但不限于：Windows系统(一种操作系统)，Linux系统(一种操作系统)，鸿蒙系统(一种操作系统)等等，在此不做限定。

可以理解的是，本申请实施例图3示意的结构并不构成对BMC的具体限定。在本申请另一些实施例中，BMC可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

示例性的，本申请实施例还提供了一种在OTP寄存器烧写客户根公钥信息的方法。该方法可以但不限于由图3所示的BMC中的处理器执行。参见图4，该方法包括S401-S403。

S401，处理器获取客户根公钥信息。

需要说明的是，当客户对服务器中的某一个目标固件的安全性不信任时，即客户对根公钥1的安全不信任。客户可以生成自己的密钥信息，并使用该密钥信息对目标固件进行签名和验证。需要说明的是，该密钥信息包括一个公钥和一个私钥。其中，私钥用于对目标固件进行签名，公钥用于对目标固件的签名进行验证。需要说明的是，私钥本质上是一个数字，公钥的本质也是一个数字。如果把任何数字当成私钥，都可以利用椭圆曲线加密算法生成这个数字(私钥)对应的公钥。即客户根公钥是根据私钥形成的，也就是说，客户根公钥是基于用户设定的信息生成的，其中，用户设定的信息例如可以为客户设定的私钥。

客户根据自己设定的密钥信息对目标固件进行签名的方式如下：

在一个可能的示例中，当服务器接收到生产厂商发送的目标固件的安装包以后，服务器首先判断接收到的安装包的版本与当前安装的目标固件的版本是否相同。当服务器确定接收到的安装包的版本与当前安装的目标固件的版本相同时，可以在服务器的显示界面显示目标固件的安装包的编辑界面。用户可以通过在该编辑界面输入自己的私钥信息，并使用自己的私钥对目标固件进行签名，以及通过该编辑界面输入用于对目标固件的签名进行验证的公钥。

在一个可能的示例中，客户可以通过服务器或者其他终端设备从生产厂商获取到目标固件的安装包，该目标固件的安装包中的可执行文件携带的信息如图5中的(a)所示。图5中的(a)示意的版本为目标固件的可执行文件的根公钥1版本。根公钥1版本中包含有目标固件在生产装备阶段烧入到OTP区的根公钥1信息，以及根公钥1的代码签名。其中，根公钥1的代码签名是指使用根公钥1对应的私钥对目标固件的代码进行签名以后，得到的签名。需要说明的是，本示例中的“签名”是指“数字签名”。数字签名(又称公钥数字签名)是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。数字签名是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。

客户从生产厂商获取到目标固件的安装包以后，用户可以使用自己的密钥对该目标固件进行签名。一些实施方式中，客户可以使用自己的私钥对目标固件的代码进行签名，得到目标固件的签名，该目标固件的签名也可以称为客户根公钥2的代码签名。然后客户将与该私钥对应的客户根公钥2、以及客户根公钥2的代码签名写入到目标固件的可执行文件中。具体地，可以使用单向散列函数对目标固件的代码进行处理，得到一份占128位的摘要(该摘要相当于目标固件的的指纹，能够唯一的识别目标固件)。然后，用户自己设定的私钥对这份128位的摘要进行加密，得到一份加密的摘要(该摘要也可以叫做目标固件的签名)。

客户在对目标固件进行签名以后，可以将签名以后的目标固件的安装包(即包含加密摘要的安装包)通过服务器发送给生产厂商。当然，在其他实施例中，客户还可以通过其他终端设备将签名以后的目标固件的安装包发送给生产厂商。

生产厂商在接收到客户发送的目标固件的安装包以后，还需要对该安装包中的目标固件进行再次签名。一些实施方式中，生产厂商获取到客户根公钥2信息以后，根据获取的客户根公钥2在目标固件的可执行文件中写入客户根公钥2的OTP信息。其中，客户根公钥2的OTP信息是指需要写入到OTP寄存器的和客户根公钥2相关的信息。客户根公钥2的OTP信息中至少包含了客户根公钥2或者客户根公钥2的哈希值。然后，生产厂商使用与根公钥1对应的私钥对客户根公钥2的OTP信息进行签名，得到客户根公钥2的OTP信息签名，并将该OTP信息签名写入到目标固件的可执行文件中。

在一个可能的示例中，生产厂商在对客户发送的安装包中的目标固件进行签名以后，该目标固件的可执行文件携带的信息如图5中的(b)所示。图5中的(b)示意版本为的目标固件的可执行文件的双签中间版本。双签中间版本中包含有目标固件在生产装备阶段烧入到OTP寄存器的根公钥1信息、根公钥1的代码签名、客户根公钥2信息、客户根公钥2代码签名、客户根公钥2的OTP信息、OTP信息签名。

生产厂商在对客户发送的安装包中的目标固件进行签名以后，生产厂商可以将经过客户签名以及经过生产厂商签名的安装包发送给BMC。BMC接收到生产厂商发送的安装包以后，BMC的处理器可以从该目标固件的安装包的可执行文件中，获取用于对目标固件进行验证的客户根公钥信息(比如，客户根公钥2)。

S402，处理器获取客户根公钥的使能信息。

当BMC获取客户根公钥信息以后，BMC可以通过执行预置的代码触发处理器生成使能客户根命令。其中，使能客户根命令用于触发处理器向OTP寄存器烧写客户根公钥信息以及该客户根公钥对应的使能信息。当OTP寄存器中烧写了客户根公钥的使能信息以后，BMC在启动时，可以直接使用客户根公钥对在BMC上运行的固件进行验证。

S403，处理器对客户根公钥信息进行验证，基于客户根公钥信息验证通过，处理器将该客户根公钥信息以及该客户根公钥的使能信息烧写到第二OTP区。

在本实施例中，BMC根据接收到的目标固件的可执行文件中携带的密钥信息(包括根公钥1和客户根公钥2的信息)，对客户根公钥2进行验证。

具体地，如图6所示，包括步骤S4031-S4039。

S4031，处理器从目标固件的可执行文件中获取目标固件的根公钥1和客户根公钥2的OTP信息。

S4032，处理器对根公钥1进行验证，根公钥1的验证通过，执行S4033，否则执行S4039。

在本方案中，处理器获取到目标固件的根公钥1和客户根公钥2以后，首先对根公钥1的进行验证，以保证处理器获取的根公钥1与预先存储在OTP寄存器中的根公钥1相同。具体地，在生产装备阶段在将根公钥1烧写到OTP寄存器中时，还对根公钥1做了哈希计算，并将得到根公钥1的哈希值进行了存储。因此，处理器在对根公钥1进行验证时，处理器需要使用与在生产装备阶段对根公钥1进行哈希计算相同的哈希算法，对根公钥1进行哈希计算。然后，处理器，将对根公钥1进行哈希计算得到的哈希值与在生产装备阶段对根公钥1进行哈希计算得到的哈希值进行比较。当两次对根公钥1进行哈希计算得到的哈希值相同时，可以确定对根公钥1的验证通过，否则对根公钥1的验证不通过。

S4033，处理器使用根公钥1验证客户根公钥2的OTP信息，当客户根公钥2的OTP信息验证通过，执行S4034，否则执行S4039。

在本方案中，处理器在对根公钥1的验证通过以后，还需要使用根公钥1验证客户根公钥2的OTP信息。由于生产厂商在将目标固件的安装包发送给BMC之前，先用与根公钥1对应的私钥对客户根公钥2的OTP信息进行签名，得到客户根公钥2的OTP信息签名，即客户根公钥的签名。所以处理器可以使用目标固件的可执行文件中携带的根公钥1对客户根公钥2的OTP信息签名进行验证方式，以达到对客户根公钥2的OTP信息进行验证的目的。

在一个可能的示例中，处理器可以使用根公钥1对根客户公钥2的OTP信息签名进行解密，得到客户根公钥2的OTP信息的摘要。然后，处理器使用单向散列函数对客户根公钥2的OTP信息进行处理，得到另外一份客户根公钥2的OTP信息摘要。处理器将两份客户根公钥2的OTP信息的摘要进行比较，若两份摘要相等，则说明客户根公钥2的OTP信息在传输过程中没有被更改。即对客户根公钥2的OTP信息的验证通过。若两份摘要不同，说明客户根公钥2的OTP信息在传输过程中被更改，即对客户根公钥2的OTP信息的验证不通过。

S4034，处理器从目标固件的可执行文件中获取客户根公钥2信息和客户根公钥2的代码签名。

S4035，处理器使用验证通过的客户根公钥2的OTP信息，对客户根公钥2的代码签名进行验证。

S4036，当客户根公钥2的代码签名验证通过，执行S4037，否则执行S4039。

在本方案中，在将客户根公钥2烧写到OTP寄存器之前，还需要确保烧写到OTP寄存器的客户根公钥2在使能以后能够对目标固件进行验证。即在将客户根公钥2烧写到OTP寄存器之前，需要使用客户根公钥2对目标固件进行验证。由于对目标固件进行验证主要是对目标固件的代码进行验证。因此，在使用客户根公钥2对目标固件进行验证时，可以使用客户根公钥2对客户根公钥2的代码签名进行验证。

在一个可能的示例中，处理器使用客户根公钥2的OTP信息中包含的客户根公钥2对客户根公钥2的代码签名进行解密，得到目标固件的代码的摘要。然后，处理器使用单向散列函数对目标固件的代码进行处理，得到另外一份目标固件的代码的摘要。处理器将两份摘要进行比较，若两份摘要相等，则认为处理器对客户根公钥2的代码签名验证通过(即客户根公钥对固件的验证通过)。若两份摘要不相等，则认为处理器对客户根公钥2的信息和客户根公钥2的代码签名验证不通过(即客户根公钥对固件的验证不通过)。

S4037，处理器调用硬件在第二OTP区烧写客户根公钥2。

在一个可能的示例中，处理器在调用硬件在第二OTP区烧写客户根公钥2时，可以通过调用芯片上的寄存器来将客户根公钥2烧写到第二OTP区。

S4038，处理器调用硬件在第二OTP区烧写客户根公钥2的使能信息。

S4039，烧写失败。

处理器在通过目标固件的可执行文件获取到客户根公钥2以及客户根公钥2的使能信息以后，在将到客户根公钥2以及客户根公钥2的使能信息烧写到第二OTP区之前，需要对目标固件的可执行文件中携带的客户根公钥信息进行两次验证。

其中，第一次验证在S4031中，在获取到客户根公钥2以后，为了保证烧写到BMC的第二OTP区的客户根公钥2是安全的且合法的，还需要对客户根公钥2进行验证。具体的，由于生产厂商在将目标固件的安装包发送给BMC之前，先用与根公钥1对应的私钥对客户根公钥的OTP信息进行了签名。所以处理器可以使用目标固件的可执行文件中携带的根公钥1对客户根公钥2的OTP信息签名进行验证，以保证处理器获取的客户根公钥2是客户需要烧写到第二OTP区的公钥信息。

第二次验证在S4035中，处理器在将客户根公钥2烧写到第二OTP区之前，还需要使用客户根公钥2验证目标固件的合法性，避免在将客户根公钥2烧写到第二OTP区以后，使能客户根公钥2后目标固件无法启动。处理器只有在两次验证都通过以后，才会调用硬件将客户根公钥2以及客户根公钥2的使能信息烧写到第二OTP区。

在一个可能的示例中，处理器在将客户根公钥2以及客户根公钥2的使能信息烧写到第二OTP区以后，目标固件的可执行文件版本可以升级为客户根公钥2版本。其中客户根公钥2的可执行文件版本如图5中的(c)所示。客户根公钥2版本中包含有客户根公钥2信息以及客户根公钥2的代码签名。

需要说明的是，处理器在使用根公钥1对客户根公钥2的OTP信息进行验证之前，处理器还需要对根公钥1进行验证，以确定根公钥1的合法性。处理器在对根公钥1的合法性进行验证时，处理器可以对根公钥1进行哈希计算，得到根公钥1对应的哈希值，然后将该哈希值与第一OTP区中存储的根公钥1的哈希值进行比较。当处理器计算得到的根公钥1的哈希值与第一OTP区存储的根公钥1的哈希值相同时，处理器确定根公钥1是合法的。

在本申请实施例中，通过在逻辑上增加额外的OTP区，当客户在使用过程中固件生产厂商提供商的密钥安全性不信任时，可以通过在额外增加的OTP区中烧写客户自己生成的客户根密钥信息，并在后续的固件启动过程中，通过烧写的客户根密钥对固件的安全性进行验证。满足客户对可信根多样性需求以及根公钥泄露后的现网修改。

在一个可能的示例中，当图3所示的BMC中的处理器为异构多核时，S401-S403可以由处理器的多个内核执行。比如，BMC中包括安全核和业务核。默认情况下，安全核和业务核都可以烧写OTP区。在生产装备阶段，由BMC业务核向OTP寄存器烧写信息。当生产装备阶段结束后，禁止通过BMC业务核向OTP寄存器烧写信息。在现网阶段，由安全核向OTP寄存器烧写信息。

示例性的，基于图3所示的BMC中的处理器为异构多核处理器。本申请实施例还提供了一种在OTP寄存器烧写客户根公钥信息的方法。参见图7,该方法包括：S701-S706。

S701，BMC业务核获取客户根公钥信息。

在本实施例中，BMC业务核可以从升级目标固件的版本中获取客户根公钥信息。具体地，BMC获取到目标固件需要升级的版本的安装包以后，BMC可以在BMC所在的的电子设备(比如，服务器)的显示器上输出目标固件的升级提示。该升级提示用于提示用户是否需要对目标固件进行升级。当用户在选择对目标固件进行升级以后，BMC业务核根据该安装包对目标固件进行升级，并获取目标固件的升级安装包中携带的客户根公钥信息。

在一个可能的示例中，目标固件的升级安装包中携带的可执行文件如图5中的(b)所示。BMC业务核通过解析该执行文件获取目标固件的客户根公钥信息。

S702，BMC业务核获取到客户根公钥信息以后，BMC业务核将获取的客户根公钥信息导入到安全核。

在本实施例中，BMC业务核在获取到客户根公钥信息以后，由于在现网阶段BMC业务核不能烧写OTP寄存器。所以，BMC业务核需要将获取的客户根公钥信息导入到安全核。

S703，BMC业务核向安全核发送使能客户根命令，以触发安全核向BMC的OTP寄存器烧写客户根公钥信息。

在本实施例中，只有在BMC业务核将客户根公钥信息导入到安全核以后，BMC业务核才向安全核发送使能客户根命令，使能客户根命令用以触发安全核将客户根公钥信息烧写到BMC的OTP寄存器。

S704，安全核对BMC业务核获取的客户根公钥信息进行验证。

在本实施例中，安全核接收到BMC业务核发送的使能客户根命令以后，安全核需要读取并验证客户根公钥信息，只有对客户根公钥信息的验证通过以后，安全核才会调用硬件将客户根公钥信息以及客户根公钥的使能信息烧写到OTP寄存器。

安全核在对客户根公钥信息进行验证时，可以包括两层验证。首先，通过使用在生产装备阶段烧写到OTP寄存器的根公钥来验证客户根公钥的合法性。当客户根公钥的合法性验证通过以后，安全核还需要使用验证通过的客户根公钥验证升级后的目标固件的合法性，以避免在BMC启动过程中，使能客户根以后，目标固件无法启动。安全核对客户根公钥信息的具体的验证过程可以参照上述实施例中的S403，在此不再赘述。

S705，基于安全核对BMC业务核获取的客户根公钥信息验证通过，安全核在对应的OTP寄存器烧写客户根公钥信息以及客户根公钥的使能信息。

在本实施例中，安全核对客户根公钥信息验证通过以后，安全核通过调用硬件将客户根公钥信息以及客户根的使能信息烧写到对应的OTP寄存器。

需要说明的是，OTP寄存器为CPU内部的一次性可编程寄存器。按照存储的根公钥信息的类型，在逻辑上可以把OTP寄存器分为第一OTP区、第二OTP区、安全使能区，如图8(a)所示。其中第一OTP区用于存储在生产装备阶段烧写到OTP区的根公钥信息，即根公钥1。第二OTP区用于存储在现网阶段烧写到OTP区的客户根公钥信息，即客户根公钥2。安全使能区用于存储安全使能信息(比如安全使能)，其中安全使能信息可以用于触发目标终端设备执行安全启动。安全使能区还用于存储第二OTP区存储的客户根公钥的使能信息(比如，客户根使能)。

在实现时，安全使能和客户根使能可用单个bit或者多个bit来表示，从安全角度来看，用多个bit表示更好。

在一个可能的示例中，如图8(b)所示，在逻辑上还可以把OTP寄存器分为第一OTP区和客户第二OTP区。其中，第一OTP区还烧写有安全使能信息(比如，安全使能)，客户第二OTP区还烧写有客户根公钥2的使能信息(比如，客户根使能)。

在一个可能的实施例中，根据OTP区的烧写时间不同，可以把OTP寄存器划分为OTP生产装备域段和OTP现网域段。其中，生产装备域段必须在生产装备阶段决定是否烧写。现网域段则可以在生产装备阶段烧写或者现网阶段烧写。

S706，安全核触发BMC重新启动。

在本实施例中，当安全核调用硬件将客户根公钥信息和客户根公钥的使能信息烧写到OTP寄存器以后。当BMC重新启动时，BMC内的软件和硬件都会使用客户根公钥来启动。

在本申请实施例中，将处理器分为安全核和业务核。将OTP寄存器分为生产装备域段和现网域段。使用安全核来烧写现网域段，禁止对生产装备域段的烧写，增加了安全性。进一步地，在烧写客户根公钥信息时，使用在生产装备域段烧写的公钥对需要在现网域段烧写的客户根公钥进行验证，以及使用验证通过的客户根公钥对目标固件进行验证，保证了在现网域段烧写的客户根公钥信息的安全性和正确性。

在另一个可能的示例中，当图3所示的BMC中的处理器没有安全核和业务核之分，只有一个CPU核时，S401-S403可以由CPU核执行。其中，CPU核的执行过程如图9所示。需要说明的是，当BMC中只有一个CPU核时，BMC可以通过和用户进行交互，由用户触发CPU核生成客户根使能命令。当CPU核对客户根公钥信息的验证通过以后，BMC还可以通过执行BMC内预先写入的代码，自动触发CPU核生成客户根使能命令。在本申请实施例中，对CPU核生成客户根使能命令的具体方式不做限定。

示例性的，本申请实施例还提供了一种固件的启动方法。该方法可以但不限于由图3所示的BMC执行，参见图10，该方法包括S1001-S1003。

S1001，获取一次性可编程存储器中存储的客户根公钥。

在本实施例中，目标固件的启动方式可以分为非安全启动和安全启动。当OTP寄存器中没有烧写安全使能信息，目标固件执行非安全启动。当OTP寄存器中烧写了安全使能信息且没有烧客户根使能信息时，目标固件执行在生产装备阶段烧写的根公钥的安全启动。当OTP寄存器中烧写了安全使能信息且烧了客户根使能信息时，执行在现网阶段烧写的客户根公钥的安全启动。处理器确定目标固件的启动方式为客户根公钥启动后，处理器从OTP寄存器获取用于验证目标固件的客户根公钥信息。其中，客户根公钥信息指的是在现网阶段烧写到现网域段的客户根公钥。

需要说明的是，在本申请实施例中，OTP寄存器按照存储信息的类型不同，在逻辑上被划分为了至少两个部分，第一OTP区和第二OTP区。其中，第一OTP区用于存储根公钥1，第二OTP区用于存储客户根公钥2。OTP寄存器按照烧写的时机不同，可以分为OTP现网域段和OTP生产装备域段。其中，生产装备域段只能在生产装备阶段进行烧写，现网域段可以在生产装备阶段和现网阶段进行烧写。即在本申请实施例中，第一OTP区对应的是生产装备域段，第二OTP区对应的是现网域段。

S1002，根据获取的客户根公钥对目标固件进行验证。

在本实施例中，处理器从OTP寄存器获取到客户根公钥信息以后，根据该客户根公钥信息对目标固件的签名进行验证。由于处理器在升级目标固件时，升级的是由客户进行签名的版本，因此，在启动目标固件时，需要使用在现网阶段烧入的客户根公钥进行验证。

S1003，基于目标固件验证成功，启动目标固件。

在本申请实施例中，当客户对目标固件在生产装备阶段烧写到OTP寄存器的根公钥不信任，或者目标固件生产装备阶段烧写到OTP寄存器的根公钥泄露后，用户可以使用在现网阶段烧写到OTP寄存器的新的根公钥，对目标固件进行验证，增强的固件的安全性。

基于上述实施例中的方法，本申请实施例还提供了一种电子设备，请参阅图11，图11是本申请实施例提供的一种电子设备的结构示意图。如图11所示，该电子设备1100包括：接收模块1110、处理模块1120、存储模块1130。

接收模块1110用于接收生产厂商发送的目标固件的升级安装包。

存储模块1130用于存储接收模块1110接收的目标固件的升级安装包。

处理模块1120用于根据目标固件的升级安装包对目标固件进行升级，并将目标固件的升级安装包中携带的客户根公钥信息烧写到处理模块1120中的OTP寄存器。

在一个可能的示例中，处理模块1120包括：控制单元、OTP存储单元和运算单元(图11中未示出)，其中，OTP存储单元为OTP寄存器在软件层面上的描述。控制单元从目标固件的升级安装包中获取目标固件的客户根公钥信息。运算单元对获取的客户根公钥信息进行验证。在对客户根公钥信息的验证通过以后，控制单元通过调用电子设备中的硬件将目标固件的客户根公钥信息烧写到OTP存储单元。其中，处理模块1120将目标固件的客户根公钥信息烧写到OTP寄存器的具体过程可以参照S401-S403的描述，在此不再赘述。

在另一个可能的示例中，处理模块1120包括：控制单元、OTP存储单元、第一运算单元和第二运算单元(图11中未示出)。控制单元从目标固件的升级安装包中获取目标固件的客户根公钥信息。第一运算单元将目标固件的客户根公钥信息导入到第二运算单元。第二运算单元对获取的客户根公钥信息进行验证。在对客户根公钥信息的验证通过以后，控制单元通过调用电子设备中的硬件将目标固件的客户根公钥信息烧写到OTP存储单元。其中，在本示例中，处理模块的第一运算单元可以对应于图7中的BMC业务核。第二运算单元可以对应于图7中的安全核。处理模块1120将目标固件的客户根公钥信息烧写到OTP寄存器的具体过程可以参照S701-S706的描述，在此不再赘述。

图11所描述的电子设备实施例仅仅是示意性的。例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

例如，图11中的各个模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。例如，采用软件实现时，上述处理模块1120可以是由附图3中的至少一个处理器310读取存储器330中存储的程序代码后，生成的软件功能模块来实现。图11中的上述各个模块也可以是由电子设备中的不同硬件分别实现，例如处理模块1120由附图3中至少一个处理器310中的一部分处理资源(例如多核处理器中的一个核)实现，而接收模块1110由附图3的网络端口320和中至少一个处理器310中的其余部分处理资源(例如多核处理器中的其他核)，或者采用FPGA、或协处理器等可编程器件来完成。显然上述功能模块也可以采用软件硬件相结合的方式来实现，例如接收模块1110由硬件可编程器件实现，而处理模块1120是由CPU读取存储器中存储的程序代码后，生成的软件功能模块。

基于上述实施例中的方法，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序在处理器上运行时，使得处理器执行上述实施例中的方法。

基于上述实施例中的方法，本申请实施例提供了一种计算机程序产品，其特征在于，当计算机程序产品在处理器上运行时，使得处理器执行上述实施例中的方法。

基于上述实施例中的方法，本申请实施例提供了一种计算设备，计算设备包括主板和芯片。其中，芯片集成在主板上，芯片包括至少一个存储器，用于存储程序；至少一个处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述实施例中的方法。在本申请实施例中，计算设备可以是服务器、主机等网络设备。芯片可以是BMC、存储BIOS的芯片等。在本申请实施例中对计算设备的类型和芯片的类型并不做限定。

需要说明的是，在其他实施例中，BMC在不同计算设备中有不同的称呼，例如华为服务器、超聚变服务器的BMC为BMC，HPE服务器的BMC称为iLO，DELL服务器的BMC称为iDRAC。

基于上述实施例中的方法，本申请实施例还提供了一种芯片。请参阅图12，图12为本申请实施例提供的一种芯片的结构示意图。如图12所示，芯片1200包括一个或多个处理器1201以及接口电路1202。可选的，芯片1200还可以包含总线1203。其中：

处理器1201可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1201中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1201可以是通用处理器、数字通信器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

接口电路1202可以用于数据、指令或者信息的发送或者接收，处理器1201可以利用接口电路1202接收的数据、指令或者其它信息，进行加工，可以将加工完成信息通过接口电路1202发送出去。

可选的，芯片1200还包括存储器，存储器可以包括只读存储器和随机存取存储器，并向处理器提供操作指令和数据。存储器的一部分还可以包括非易失性随机存取存储器(NVRAM)。

可选的，存储器存储了可执行软件模块或者数据结构，处理器可以通过调用存储器存储的操作指令(该操作指令可存储在操作系统中)，执行相应的操作。

可选的，接口电路1202可用于输出处理器1201的执行结果。

需要说明的，处理器1201、接口电路1202各自对应的功能既可以通过硬件设计实现，也可以通过软件设计来实现，还可以通过软硬件结合的方式来实现，这里不作限制。

应理解，上述方法实施例的各步骤可以通过处理器中的硬件形式的逻辑电路或者软件形式的指令完成。

可以理解的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。此外，在一些可能的实现方式中，上述实施例中的各步骤可以根据实际情况选择性执行，可以部分执行，也可以全部执行，此处不做限定。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

Claims (10)

1.一种固件的启动方法，其特征在于，包括：

获取客户根公钥，用所述固件预存的原始根公钥验证所述客户根公钥，若所述客户根公钥验证成功，存储所述客户根公钥，其中，所述客户根公钥基于用户设定的信息生成；

在重新启动固件的情况下，根据所述客户根公钥对所述固件进行验证；

基于所述固件验证成功，启动所述目标固件。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：获取客户根公钥的签名；

所述用所述固件预存的原始根公钥验证所述客户根公钥，若所述客户根公钥验证成功，存储所述客户根公钥，包括：

使用固件预存的原始根公钥验证所述客户根公钥的签名；

若所述原始根公钥对所述客户根公钥的签名验证通过，使用所述客户根公钥对所述固件进行验证；

若所述客户根公钥对所述固件的验证通过，存储所述客户根公钥。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取所述固件的原始根公钥，对所述原始根公钥进行验证；

若所述原始根公钥的验证通过，使用所述原始根公钥对所述客户根公钥进行验证。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述根据所述客户根公钥对所述固件进行验证的具体方法包括：

获取客户根公钥的代码签名，通过对所述客户根公钥的代码签名验证实现所述客户根公钥对所述固件的验证。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述存储所述客户根公钥包括：

将所述客户根公钥、所述客户根公钥的使能信息存储到一次性可编程OTP存储器。

6.一种芯片，所述芯片包括处理器和接口电路，所述处理器和所述接口电路电连接，所述处理器存储有固件，所述处理器用于：

获取客户根公钥，用所述固件预存的原始根公钥验证所述客户根公钥，若所述客户根公钥验证成功，存储所述客户根公钥，其中，所述客户根公钥基于用户设定的信息生成；

在重新启动固件的情况下，根据所述客户根公钥对所述固件进行验证；

基于所述固件验证成功，启动所述目标固件。

7.根据权利要求6所述的芯片，其特征在于，所述处理器还用于：

使用固件预存的原始根公钥验证所述客户根公钥的签名；

若所述原始根公钥对所述客户根公钥的签名验证通过，使用所述客户根公钥对所述固件进行验证；

若所述客户根公钥对所述固件的验证通过，存储所述客户根公钥。

8.根据权利要求6所述的芯片，其特征在于，所述处理器还用于：

获取所述固件的原始根公钥，对所述原始根公钥进行验证；

若所述原始根公钥的验证通过，使用所述原始根公钥对所述客户根公钥进行验证。

9.根据权利要求6-8任一项所述的芯片，其特征在于，所述处理器还用于：

将所述客户根公钥、所述客户根公钥的使能信息存储到一次性可编程存储器。

10.一种计算设备，所述计算设备包括主板和芯片，所述芯片集成在所述主板上，所述芯片包括：

至少一个存储器，用于存储程序；

至少一个处理器，用于执行所述存储器存储的程序，当所述存储器存储的程序被执行时，所述处理器用于执行如权利要求1-5任一项所述的方法。

Images