CN104200153A - 一种启动验证方法和系统 - Google Patents

Abstract

本发明的启动验证方法和系统，预先在主芯片的CPU中集成包括第一验证信息的miniboot，在主芯片的falsh中存放用于验证uboot的第二验证信息，在uboot中嵌入用于验证kernel和recovery的第三验证信息。在启动主芯片时，可首先利用miniboot中的第一验证信息对第二验证信息进行验证，在验证通过时，利用第二验证信息对uboot进行验证，并在uboot合法时启动uboot，之后，uboot可利用其第三验证信息对kernel和recovery进行验证，并在两者合法时，对其进行启动。而如果任意一个环节验证未通过，则启动失败。本发明通过采用多级串联验证为智能终端带来了更高的安全保障。

Description

一种启动验证方法和系统

技术领域

本发明属于信息安全技术领域，尤其涉及一种启动验证方法和系统。

背景技术

为防止终端产品被非法复制，防止恶意刷机，同时为保证终端上涉及支付、认证、版权内容等各种运营业务的安全，对智能终端提出了较高的安全要求。

智能终端的安全程度取决于其主芯片的安全程度，目前，仅采用简单的基于版权芯片标识信息的硬件验证来保障智能终端的安全性，即具体地，在智能终端电路板上焊接一版权芯片作为主芯片，该芯片能够返回一个唯一的标识信息，例如ID(Identity，身份标识号码)，后续通过依据所述标识信息判定其片内Flash中存储的uboot、kernel及recovery等原始代码的合法性，来保证移动终端的安全。然而，上述验证方式的判定条件较为简单，易被通过反汇编等方式破解，安全程度较低。

发明内容

有鉴于此，本发明的目的在于提供一种启动验证方法和系统，以克服现有验证方式易被破解、安全程度较低的缺陷，进而为智能终端提供更高的安全保障。

为此，本发明公开如下技术方案：

一种启动验证方法，应用于电子设备，所述电子设备包括主芯片，所述方法包括：

启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的中央处理器CPU中，所述miniboot中包括第一验证信息；

利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证；

在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息；

利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证；

在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

上述方法，优选的，所述利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证，包括：

基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证；

在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

上述方法，优选的，所述利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证，包括：

基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

上述方法，优选的，所述第一公钥及所述第一私钥由芯片厂家生成，所述第一私钥由芯片厂家保管；所述第二公钥及所述第二私钥由运营商生成，所述第二私钥由运营商保管；所述第三公钥及所述第三私钥由运营商生成，所述第三私钥由运营商保管。

上述方法，优选的，所述第一签名数据及所述第二签名数据存储在所述主芯片flash中uboot文件的头部，所述第三签名数据存储在所述主芯片flash中的设定区域。

上述方法，优选的，还包括：

在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。

一种启动验证系统，应用于电子设备，所述电子设备包括主芯片，所述系统包：

第一启动模块，用于启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的中央处理器CPU中，所述miniboot中包括第一验证信息；

第一验证模块，用于利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证；

第二启动模块，用于在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息；

第二验证模块，用于利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证；

第三启动模块，用于在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

上述系统，优选的，所述第一验证模块包括：

第一验证单元，用于基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证；

第二验证单元，用于在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

上述系统，优选的，所述第二验证模块包括：

第三验证单元，用于基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

上述系统，优选的，还包括：

故障处理模块，用于在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。

综上，本发明的启动验证方法和系统，提供了一种多级串联验证的验证方式，即具体预先在主芯片的CPU中集成包括根秘钥(第一验证信息)的miniboot，miniboot不可被更改、拷贝，并在主芯片的falsh中存放用于对uboot进行验证的第二验证信息，在uboot代码中嵌入用于对kernel和recovery进行验证的第三验证信息。基于此，在启动主芯片的过程中，可首先利用miniboot中包括的第一验证信息对第二验证信息进行验证，在第二验证信息合法时，利用第二验证信息对uboot进行验证，并在uboot合法时启动uboot，之后uboot可利用其内嵌的第三验证信息对kernel和recovery进行验证，并在两者合法时，对其进行启动。而如果任意一个环节验证未通过(如uboot、kernel或recovery被篡改)，则启动失败。

可见，相比于现有技术，本发明通过采用多级串联验证为智能终端带来了更高的安全保障，克服了现有验证方式易被破解、安全程度较低的缺陷。

附图说明

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

图1是本发明实施例一公开的启动验证方法的一种流程图；

图2是本发明实施例一公开的主芯片分区示意图；

图3是本发明实施例二公开的启动验证方法的另一种流程图；

图4是本发明实施例二公开的应用本发明对主芯片进行启动验证的过程流程图；

图5是本发明实施例三公开的启动验证系统的一种结构示意图；

图6是本发明实施例三公开的启动验证系统的另一种结构示意图。

具体实施方式

为了引用和清楚起见，下文中使用的技术名词、简写或缩写总结解释如下：

CSK：根密钥，主要是由芯片厂商提供。

BSK：私钥，Bootloader开发者管理。

OTP：One Time Programmable，一次性编程存储器。

Uboot：一种通用的cpu引导程序

Kernel：linux操作系统的别称。

Recovery：用于恢复或升级操作系统的程序。

romcode区域：即只读内存Read-Only Memory的代码区域。

签名：这里指数字签名，是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

ChipID：cpu芯片的唯一标识码。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

本实施例一公开一种启动验证方法，该方法可应用于诸如智能终端等电子设备，所述电子设备包括主芯片。

参考图1，所述方法可以包括以下步骤：

S101：启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的CPU(Central Processing Unit，中央处理器)中，所述miniboot中包括第一验证信息。

S102：利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证。

其中，本步骤S102包括：

基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证；

在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

S103：在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息。

其中，步骤S103具体包括基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

S104：利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证。

S105：在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

其中，本实施例基于多级串联验证思想并采用基于公钥、私钥的签名认证机制对主芯片flash中的原始代码uboot、kernel及recovery进行启动验证，以保证主芯片的原始代码在安全合法的前提下才能被正常启动，进而保证智能终端的安全性。

为了更为方便地对本发明进行描述，以下采用Pub表示公钥，采用Pri表示私钥。

本实施例具体采用三套秘钥key：K1＝(Pri1，Pub1)，K2＝(Pri2，Pub2)和K3＝(Pri3，Pub3)实现对主芯片的原始代码进行串联验证。

智能终端的物理安全源于主芯片的安全保障，其安全根基为主芯片OTP(One Time Programmable，一次性编程存储器)中内置的根秘钥/公钥。基于此，本发明首先在主芯片OTP(One Time Programmable，一次性编程存储器)内的romcode区域集成了负责对uboot进行验证的miniboot安全程序，并在miniboot中内嵌了作为根秘钥的Pub1，以方便启动安全验证机制，对主芯片的原始代码进行安全验证。应用本发明时，可在芯片出厂前将miniboot固化集成在主芯片CPU中，并保证所述miniboot不可被篡改或拷贝。

其中，如图2所示，Pri1、Pub1由芯片厂家生成，芯片厂家保管pri1，在芯片出厂前Pub1已被作为根秘钥内嵌在芯片的CPU romcode区域中，出厂时，芯片厂家将内嵌了pub1且已烧写ChipID的安全芯片给终端厂家。

Pri2、pub2由运营商生成，运营商保管pri2，并将pub2提供给终端厂家，再由终端厂家将其提供给芯片厂家，芯片厂家使用pri1对pub2进行签名，得到pub2的签名数据；运营商采用pri2对uboot code(uboot代码)进行签名，生成uboot code的签名数据，且芯片厂家、运营商分别将pub2的签名数据、uboot code的签名数据提供给终端厂家，最终由终端厂家将pub2、pub2的签名数据及ubootcode的签名数据保存在uboot文件的头部。

Pri3、pub3由运营商生成，运营商将pub3提供给终端厂家，由终端厂家将其内嵌于uboot code中，同时，运营商保管pri3，采用pri3对kernel和recovery进行签名，生成对应的kernel和recovery签名数据，并将生成的签名数据提供给终端厂家，由终端厂家将其保存在flash的特定区域。

在此基础上，对智能终端上电后，主芯片中的miniboot首先启动,之后miniboot利用其内部的pub1验证pub2的正确性；pub2通过验证后，miniboot再利用pub2验证uboot的正确性，并在uboot合法通过验证后，启动uboot；接下来，uboot利用其内嵌的pub3验证kernel和recovery的正确性，并在kernel和recovery合法通过验证时，启动kernel和recovery。

也就是说，主芯片的CPU启动时会利用K1和K2验证uboot，uboot验证成功后，利用K3验证Recovery和Kernel，整套信任链机制从物理上确保了uboot，kernel和Recovery是安全的，保证了智能终端的安全性。

其中，本发明不直接使用pub1和pri1对uboot进行签名验证，而采用两套key(K1、K2)的验证方式，目的是将验证权下放给pub2，由于pub2存放在flash中，而不是存放在芯片内部的OTP区域中，所以可以更加方便调试和更换pub2。

综上，本发明的启动验证方法，提供了一种多级串联验证的验证方式，即具体预先在主芯片的CPU中集成包括根秘钥(第一验证信息)的miniboot，miniboot不可被更改、拷贝，并在主芯片的falsh中存放用于对uboot进行验证的第二验证信息，在uboot代码中嵌入用于对kernel和recovery进行验证的第三验证信息。基于此，在启动主芯片的过程中，可首先利用miniboot中包括的第一验证信息对第二验证信息进行验证，在第二验证信息合法时，利用第二验证信息对uboot进行验证，并在uboot合法时启动uboot，之后uboot可利用其内嵌的第三验证信息对kernel和recovery进行验证，并在两者合法时，对其进行启动。而如果任意一个环节验证未通过(如uboot、kernel或recovery被篡改)，则启动失败。

可见，相比于现有技术，本发明通过采用多级串联验证为智能终端带来了更高的安全保障，克服了现有验证方式易被破解、安全程度较低的缺陷。

实施例二

本实施例中，参考图3，上述方法还包括以下步骤：

S106：在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。

也就是说，应用本发明时，当各个验证环节中任意一个环节的验证未通过时，主芯片不能被正常启动。

例如，在主芯片flash中存储的uboot、kernel或recovery等原始代码基于非法目的被复制后，由于主芯片CPU中内嵌了根秘钥的miniboot无法被复制，从而被复制的uboot、kernel或recovery等原始代码因无法启动验证流程而不能被正常启用。

在主芯片flash中相应原始代码被篡改后，基于签名机制被篡改的代码已失去其合法有效性，从而在加电启动时，其不能通过合法验证，进而主芯片启动失败，保证了终端上涉及支付、认证、版权内容等各种运营业务的安全。

参考图4，利用本发明的方法对主芯片进行启动验证的过程如下：

S401：上电，启动、运行miniboot；

S402：miniboot利用其内嵌的pub1验证pub2；

S403：判断pub2是否验证成功，若判断结果为是，则执行步骤S405；否则，若判断结果为否，则执行步骤S404；

S404：CPU halt，即停止运行CPU；

S405：miniboot利用pub2验证uboot；

S406：判断uboot是否验证成功，若判断结果为是，则执行步骤S407；否则，若判断结果为否，则执行步骤S404；

S407：运行uboot；

S408：uboot利用其内嵌的pub3验证Kernel及Recovery；

S409：判断Kernel及Recovery是否验证成功，若判断结果为是，则执行步骤S410；否则，若判断结果为否，则执行步骤S411；

S410：启动应用；

S411：停止启动，进行出错处理。

实施例三

本实施例三公开一种启动验证系统，该系统与实施例一及实施例二公开的启动验证方法相对应。

首先，相应于实施例一，参考图5，所述系统包括第一启动模块100、第一验证模块200、第二启动模块300、第二验证模块400和第三启动模块500。

第一启动模块100，用于启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的中央处理器CPU中，所述miniboot中包括第一验证信息；

第一验证模块200，用于利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证。

其中，第一验证模块200包括第一验证单元和第二验证单元。

第一验证单元，用于基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证。

第二验证单元，用于在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

第二启动模块300，用于在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息。

第二验证模块400，用于利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证。

其中，第二验证模块400包括第三验证单元。

第三验证单元，用于基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

第三启动模块500，用于在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

相应于实施例二，参考图6，所述系统还包括故障处理模块600，该模块用于在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。

对于本发明实施例三公开的启动验证系统而言，由于其与实施例一和实施例二公开的启动验证方法相对应，所以描述的比较简单，相关相似之处请参见实施例一和实施例二中启动验证方法部分的说明即可，此处不再详述。

综上所述，本发明基于多级串联的信任链机制从物理上确保了主芯片中uboot、kernel及recovery是安全的，相比于现有技术，本发明的验证机制不易被破解，安全程度较高，进而为智能终端带来了更高的安全保障。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种启动验证方法，其特征在于，应用于电子设备，所述电子设备包括主芯片，所述方法包括：

启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的中央处理器CPU中，所述miniboot中包括第一验证信息；

利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证；

在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息；

利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证；

在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

2.根据权利要求1所述的方法，其特征在于，所述利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证，包括：

基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证；

在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

3.根据权利要求2所述的方法，其特征在于，所述利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证，包括：

基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

4.根据权利要求2或3所述的方法，其特征在于，所述第一公钥及所述第一私钥由芯片厂家生成，所述第一私钥由芯片厂家保管；所述第二公钥及所述第二私钥由运营商生成，所述第二私钥由运营商保管；所述第三公钥及所述第三私钥由运营商生成，所述第三私钥由运营商保管。

5.根据权利要求2或3所述的方法，其特征在于，所述第一签名数据及所述第二签名数据存储在所述主芯片flash中uboot文件的头部，所述第三签名数据存储在所述主芯片flash中的设定区域。

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

在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。

7.一种启动验证系统，其特征在于，应用于电子设备，所述电子设备包括主芯片，所述系统包：

第一启动模块，用于启动微引导程序miniboot，所述miniboot预先集成在所述主芯片的中央处理器CPU中，所述miniboot中包括第一验证信息；

第一验证模块，用于利用所述第一验证信息对第二验证信息进行验证，并在所述第二验证信息通过验证时，利用所述第二验证信息对引导程序uboot进行验证；

第二启动模块，用于在所述uboot通过验证时，启动所述uboot，所述uboot中内嵌有第三验证信息；

第二验证模块，用于利用所述第三验证信息对操作系统内核Kernel及操作系统的恢复/升级程序Recovery进行验证；

第三启动模块，用于在所述Kernel及所述Recovery通过验证时，启动所述Kernel及所述Recovery，其中，所述第二验证信息、uboot、Kernel及Recovery存储在所述主芯片的存储器flash中。

8.根据权利要求7所述的系统，其特征在于，所述第一验证模块包括：

第一验证单元，用于基于预先采用第一私钥对第二公钥进行签名所生成的第一签名数据，利用第一公钥对所述第二公钥进行验证；

第二验证单元，用于在所述第二公钥通过验证时，基于预先采用第二私钥对所述uboot进行签名所生成的第二签名数据，利用所述第二公钥对所述uboot进行验证，其中，所述第一公钥、第一私钥为相互匹配的一对秘钥，所述第二公钥、第二私钥为相互匹配的一对秘钥。

9.根据权利要求8所述的系统，其特征在于，所述第二验证模块包括：

第三验证单元，用于基于预先采用第三私钥对所述Kernel及所述Recovery进行签名所生成的第三签名数据，利用第三公钥对所述Kernel及所述Recovery进行验证，其中，所述第三公钥、第三私钥为相互匹配的一对秘钥。

10.根据权利要求7所述的系统，其特征在于，还包括：

故障处理模块，用于在所述第二验证信息或所述uboot未通过验证时，停止运行所述CPU，在所述Kernel及所述Recovery未通过验证时，停止启动，进行相应的出错处理。