CN116938465A - 网关设备启动方法、装置、电子设备及存储介质 - Google Patents

网关设备启动方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN116938465A
CN116938465A CN202210359432.6A CN202210359432A CN116938465A CN 116938465 A CN116938465 A CN 116938465A CN 202210359432 A CN202210359432 A CN 202210359432A CN 116938465 A CN116938465 A CN 116938465A
Authority
CN
China
Prior art keywords
preset
signature information
kernel
bootloader
information corresponding
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.)
Pending
Application number
CN202210359432.6A
Other languages
English (en)
Inventor
金泽
李洁
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.)
Beijing Xiaomi Mobile Software Co Ltd
Original Assignee
Beijing Xiaomi Mobile Software Co Ltd
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 Beijing Xiaomi Mobile Software Co Ltd filed Critical Beijing Xiaomi Mobile Software Co Ltd
Priority to CN202210359432.6A priority Critical patent/CN116938465A/zh
Publication of CN116938465A publication Critical patent/CN116938465A/zh
Pending legal-status Critical Current

Links

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/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
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本公开关于一种网关设备启动方法、装置、电子设备及存储介质。其中，所述网关设备启动方法，包括：获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。采用本公开实施例提供的方法可以有效避免被入侵的情况，提高网关设备的安全性，提高网关设备中数据的安全性。

Description

网关设备启动方法、装置、电子设备及存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及一种网关设备启动方法、装置、电子设备及存储介质。
背景技术
相关技术中，网关设备是智能家居系统的中枢设备，智能家居设备可以通过网关设备连接到智能家居服务器，可以通过网关设备实现智能家居设备的远程控制、智能家居设备联动等。对于Linux操作系统的网关设备，其启动过程通常可以分为Bootloader(引导加载程序)启动、Kernel(内核)启动、根文件系统挂载等阶段。但在这个启动过程中，容易被入侵，导致网关设备的安全性较低，网关设备中的数据泄露风险较高。
发明内容
本公开提供一种网关设备启动方法、装置、电子设备及存储介质，以至少解决相关技术中网关设备的安全性较低，网关设备中的数据泄露风险较高的问题。本公开的技术方案如下：
根据本公开实施例的第一方面，提供一种网关设备启动方法，包括：
获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；
基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；
在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
在一种可能的实施方式中，所述预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据；
所述获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还包括：
生成所述Bootloader对应的第一预设密钥对、所述Kernel对应的第二预设密钥对、所述根文件系统对应的预设Hash数据；其中，所述第一预设密钥对包括第一预设公钥和第一预设私钥、所述第二预设密钥对包括第二预设公钥和第二预设私钥，所述第一预设密钥对和所述第二预设密钥对为对称密钥。
在一种可能的实施方式中，所述获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还包括：
基于所述第一预设私钥对所述Bootloader进行签名，得到所述Bootloader对应的第一签名信息；
基于所述第二预设私钥对所述Kernel进行签名，得到所述Kernel对应的第二签名信息；
基于所述预设Hash数据对所述根文件系统进行签名，得到所述根文件系统对应的第三签名信息。
在一种可能的实施方式中，所述基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证，包括：
验证所述第一预设公钥是否能够解密所述Bootloader对应的第一签名信息；
验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息；
验证所述预设Hash数据是否与所述根文件系统对应的第三签名信息相匹配。
在一种可能的实施方式中，在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，包括：
在所述第一预设公钥成功解密所述第一签名信息的情况下，确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader；
在所述第二预设公钥成功解密所述第二签名信息的情况下，确定所述Kernel对应的第二签名信息验证通过，加载所述Kernel；
在所述预设Hash数据与所述第三签名信息相匹配的情况下，确定所述根文件系统对应的第三签名信息验证通过，挂载所述根文件系统。
在一种可能的实施方式中，所述确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader之后，还包括：
确定是否进入固件升级Recovery模式；
在进入Recovery模式的情况下，获取第四预设公钥；
基于所述第四预设公钥验证所述Recovery模式的第四签名信息；
在所述Recovery模式的第四签名信息验证通过的情况下，加载所述Recovery模式，以安装OTA数据包。
在一种可能的实施方式中，所述确定是否进入固件升级Recovery模式之后，还包括：
在不进入Recovery模式的情况下，验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息。
根据本公开实施例的第二方面，提供一种网关设备启动装置，包括：
第一获取模块，用于获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；
第一验证模块，用于基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；
第一加载模块，用于在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
在一种可能的实施方式中，所述预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据；
所述网关设备启动装置，还包括：
生成模块，用于生成所述Bootloader对应的第一预设密钥对、所述Kernel对应的第二预设密钥对、所述根文件系统对应的预设Hash数据；其中，所述第一预设密钥对包括第一预设公钥和第一预设私钥、所述第二预设密钥对包括第二预设公钥和第二预设私钥，所述第一预设密钥对和所述第二预设密钥对为对称密钥。
在一种可能的实施方式中，所述网关设备启动装置，还包括：
第一签名模块，用于基于所述第一预设私钥对所述Bootloader进行签名，得到所述Bootloader对应的第一签名信息；
第二签名模块，用于基于所述第二预设私钥对所述Kernel进行签名，得到所述Kernel对应的第二签名信息；
第三签名模块，用于基于所述预设Hash数据对所述根文件系统进行签名，得到所述根文件系统对应的第三签名信息。
在一种可能的实施方式中，所述第一验证模块，包括：
第一验证单元，用于验证所述第一预设公钥是否能够解密所述Bootloader对应的第一签名信息；
第二验证单元，用于验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息；
第三验证单元，用于验证所述预设Hash数据是否与所述根文件系统对应的第三签名信息相匹配。
在一种可能的实施方式中，所示第一加载模块，包括：
第一加载单元，用于在所述第一预设公钥成功解密所述第一签名信息的情况下，确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader；
第二加载单元，用于在所述第二预设公钥成功解密所述第二签名信息的情况下，确定所述Kernel对应的第二签名信息验证通过，加载所述Kernel；
第三加载单元，用于在所述预设Hash数据与所述第三签名信息相匹配的情况下，确定所述根文件系统对应的第三签名信息验证通过，挂载所述根文件系统。
在一种可能的实施方式中，所述网关设备启动装置，还包括：
模式确定模块，用于确定是否进入固件升级Recovery模式；
第二获取模块，用于在进入Recovery模式的情况下，获取第四预设公钥；
第二验证模块，用于基于所述第四预设公钥验证所述Recovery模式的第四签名信息；
第二加载模块，用于在所述Recovery模式的第四签名信息验证通过的情况下，加载所述Recovery模式，以安装OTA数据包。
在一种可能的实施方式中，所述第二验证单元，具体用于：
在不进入Recovery模式的情况下，验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息。
根据本公开实施例的第三方面，提供一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如第一方面中任一项所述的网关设备启动方法。
根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面中任一项所述的网关设备启动方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如第一方面中任一项所述的网关设备启动方法。
本公开的实施例提供的技术方案至少带来以下有益效果：
在本公开的实施例中，通过获取预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息；基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；在Bootloader、Kernel、根文件系统的签名信息验证通过的情况下，加载Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。这样，可以在加载Bootloader、Kernel、根文件系统之前，增加Bootloader、Kernel、根文件系统的签名验证过程，且仅在验证通过的情况下，才加载Bootloader、Kernel、根文件系统。如此，可以有效避免被入侵的情况，提高网关设备的安全性，提高网关设备中数据的安全性。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是本公开实施例提供的一种网关设备启动方法的流程图。
图2是本公开实施例提供的另一种网关设备启动方法的流程图。
图3是本公开实施例提供的一种网关设备启动装置的框图。
图4是本公开实施例提供的一种电子设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
由背景技术可知，相关技术中，Linux操作系统的网关设备在启动过程中，容易被入侵，网关设备一旦被入侵会导致严重的设备安全问题。例如，入侵者可以拿到网关设备关联的智能家居设备的敏感信息、可以控制家庭中的智能家居设备、可以通过网关设备打开的智能家居系统控制闭环内的缺口对获取用户的数据及财产。也即，相关技术中，网关设备的安全性较低，网关设备中的数据泄露风险较高。基于此，本公开的实施例提供了一种网关设备启动方法、装置、电子设备及存储介质，能够在加载Bootloader、Kernel、根文件系统之前，增加Bootloader、Kernel、根文件系统的签名验证过程，且仅在验证通过的情况下，才加载Bootloader、Kernel、根文件系统，从而可以有效避免被入侵的情况，提高网关设备的安全性，提高网关设备中数据的安全性。
下面结合附图对本公开实施例提供的网关设备启动方法、装置、电子设备及存储介质进行详细说明。
图1是本公开实施例提供的一种网关设备启动方法的流程图，该网关设备启动方法可以应用于网关设备。如图1所示，网关设备启动方法可以包括以下步骤。
在步骤S110中，获取预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息。
其中，在Linux操作系统中，Bootloader(引导加载程序)在Kernel(内核)运行之前运行，可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。Bootloader可以用于完成整个操作系统的加载启动任务。根文件系统是Kernel启动时所挂载的第一个文件系统，Kernel代码的映像文件保存在根文件系统中，Bootloader会在根文件系统挂载之后从中把一些初始化脚本和服务加载到内存中去运行。
在本公开实施例中，网关设备在启动时，可以先获取预设验证信息，预设验证信息可以是预先设置好的用于对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证的验证信息。还可以获取Bootloader、Kernel、根文件系统各自对应的签名信息，也即分别获取Bootloader对应的签名信息、Kernel对应的签名信息，以及根文件系统对应的签名信息。其中，Bootloader、Kernel、根文件系统各自对应的签名信息，均对应有一个相应的验证信息。
在步骤S120中，基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证。
在本公开实施例中，在获取到预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息之后，可以基于预设验证信息分别对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证。示例性的，可以基于Bootloader对应的预设验证信息对Bootloader对应的签名信息进行验证，基于Kernel对应的预设验证信息对Kernel对应的签名信息进行验证，基于根文件系统对应的预设验证信息对根文件系统对应的签名信息进行验证。
在步骤S130中，在Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
在本公开实施例中，在基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证之后，可以确定Bootloader、Kernel、根文件系统各自对应的签名信息是否验证通过。在Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载Bootloader、Kernel以及根文件系统，实现网关设备的启动，使网关设备处于启动状态。这样，可以修改网关设备的启动流程，通过固件加密和固件签名，实现从Bootloader到Kernel再到根文件系统的全流程安全保护。
在本公开的实施例中，通过获取预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息；基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；在Bootloader、Kernel、根文件系统的签名信息验证通过的情况下，加载Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。这样，可以在加载Bootloader、Kernel、根文件系统之前，增加Bootloader、Kernel、根文件系统的签名验证过程，且仅在验证通过的情况下，才加载Bootloader、Kernel、根文件系统。如此，可以有效避免被入侵的情况，提高网关设备的安全性，提高网关设备中数据的安全性。
在一种可能的实施方式中，预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据。相应的，在步骤S110获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还可以执行如下步骤：
生成Bootloader对应的第一预设密钥对、Kernel对应的第二预设密钥对、根文件系统对应的预设Hash数据。
其中，第一预设密钥对包括第一预设公钥和第一预设私钥、第二预设密钥对包括第二预设公钥和第二预设私钥，且第一预设密钥对和所述第二预设密钥对可以为对称密钥。而且，第一预设密钥对、第二预设密钥对可以打包存储在固件中，网关设备启动过程中可以读取相应的密钥进行解密及验证签名操作。
在本公开的实施例中，在获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，网关设备可以预先生成Bootloader对应的第一预设密钥对，第一密钥对可以包括有第一预设公钥和第一预设密钥，即Bootloader对应的公钥和密钥；预先生成Kernel对应的第二预设密钥对，第二密钥对可以包括有第二预设公钥和第二预设密钥，即Kernel对应的公钥和密钥。其中，第二预设密钥对可以与第二预设密钥对相同，也可以不同。示例性的，可以通过在网关设备首次上电后自动生成一组随机字符串(例如可以是16位或32位的字符串)作为第一密钥对和第二密钥对，或者，也可以生成两组对称密钥，分别作为第一密钥对和第二密钥对，但均要确保网关设备的密钥对是唯一的。
预设Hash数据为根文件系统对应的Hash数据，预设Hash数据可以包括Hash树的数据结构和固件的根Hash(即root hash)。示例性的。考虑到根文件系统是只读系统且根文件系统通常较大，对根文件系统进行加密挂载会消耗大量的系统启动时间，所以选择验签方式验证根文件系统的安全性。根文件系统的签名采用Hash树的方式实现。将根文件系统固件分为多个block(区块)，对每个block做Hash运算后的结果，作为第一层Hash结果。对第一层Hash结果顺序排列后再进行block划分再进行Hash运算，以此类推，最终计算得到Hash树，得到该Hash树的数据结构和固件的根Hash(root Hash)。
可以理解的，在生成Bootloader对应的第一预设密钥对、Kernel对应的第二预设密钥对、根文件系统对应的预设Hash数据之后，可以保存第一预设密钥对、第二预设密钥对、预设Hash数据，例如可以加密保存在data分区。且第一预设密钥对、第二预设密钥对、预设Hash数据的生成过程可以仅在编译过程中执行一次，无需在每次网关设备启动时执行。
在进一步可能的实施例中，在步骤S110获取预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息之前，还可以执行如下步骤：
基于第一预设私钥对Bootloader进行签名，得到Bootloader对应的第一签名信息；
基于第二预设私钥对Kernel进行签名，得到Kernel对应的第二签名信息；
基于预设Hash数据对根文件系统进行签名，得到根文件系统对应的第三签名信息。
在本公开的实施例中，网关设备在获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还可以先基于第一预设私钥对Bootloader进行签名，即用第一预设私钥对Bootloader的固件进行签名，得到Bootloader对应的签名信息，即第一签名信息；基于第二预设私钥对Kernel进行签名，即用第二预设私钥对Kernel的固件进行签名，得到Kernel对应的第二签名信息；示例性的，可以通过secureboot套件实现Bootloader、Kernel的加密和签名操作。也就是说，可以通过对称密钥对Bootloader和Kernel进行固件加密，这样，可以使得eMMC(Embedded Multi MediaCard)被脱机读取时，也不会读取到网关设备的明文信息，提高网关设备安全性。
以及，基于预设Hash数据对根文件系统进行签名，得到根文件系统对应的签名信息，即第三签名信息，示例性的，可以对预设Hash数据的根Hash进行签名，将该签名添加至根文件系统，得到得到根文件系统对应的签名信息，即第三签名信息。可以理解的，可以将根Hash签名的Base64编码结果也附加在根Hash后，使用工具(例如veritysetup)将根Hash及签名结果(即Base64编码结果)一同存放在安全存储区域中，保证根Hash的安全性。
这样，可以为后续对Bootloader、Kernel、根文件系统的签名信息进行验证，提供数据依据。
可以理解的，上述对Bootloader、Kernel、根文件系统进行签名的过程，可以在编译时执行一次，也可以在每次网关设备启动时都执行。
在一些可能的实施例中，上述步骤S120中基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证的具体实现方式可以为：
验证第一预设公钥是否能够解密Bootloader对应的第一签名信息；
验证第二预设公钥是否能够解密Kernel对应的第二签名信息；
验证预设Hash数据是否与根文件系统对应的第三签名信息相匹配。
相应的，上述步骤S130的具体实现方式可以如下：
在第一预设公钥成功解密第一签名信息的情况下，确定Bootloader对应的第一签名信息验证通过，加载Bootloader；
在第二预设公钥成功解密第二签名信息的情况下，确定Kernel对应的第二签名信息验证通过，加载Kernel；
在预设Hash数据与第三签名信息相匹配的情况下，确定根文件系统对应的第三签名信息验证通过，挂载根文件系统。
在本公开的实施例中，在基于预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证时，可以基于第一预设公钥验证Bootloader对应的第一签名信息，即用第一预设公钥对Bootloader对应的第一签名信息进行解密，验证第一预设公钥是否能够解密Bootloader对应的第一签名信息。在第一预设公钥成功解密第一签名信息的情况下，则可以认为第一签名信息未被篡改，确定Bootloader对应的第一签名信息验证通过，并可以加载Bootloader，例如，可以加载Bootloader环境变量。反之，则可以认为可能第一签名信息已经被篡改，确认Bootloader对应的第一签名信息验证失败，此时，则可以重新启动网关设备，重新获取预设验证信息和Bootloader、Kernel、根文件系统各自对应的签名信息。
在第一预设公钥成功解密第一签名信息的情况下，用第二预设公钥对Kernel对应的第二签名信息进行解密，验证第二预设公钥是否能够解密Kernel对应的第二签名信息。在第二预设公钥成功解密Kernel对应的第二签名信息的情况下，则可以认为第二签名信息未被篡改，确定Kernel对应的第二签名信息验证通过，可以加载Kernel。反之，则可以认为可能第二签名信息已经被篡改，确认Kernel对应的第二签名信息验证失败，此时，则可以重新启动网关设备，重新获取预设验证信息和Bootloader、Kernel、根文件系统各自对应的签名信息。
在第二预设公钥成功解密第二签名信息的情况下，可以验证预设Hash数据是否与根文件系统对应的第三签名信息相匹配。示例性的，考虑到根文件系统对应的签名信息可以是基于预设Hash数据的根Hash进行签名得到的，故而，在验证预设Hash数据是否与根文件系统对应的第三签名信息相匹配时，可以将存储的预设Hash数据的根Hash的签名与第三签名信息进行匹配(例如确定存储的预设Hash数据的根Hash的签名与第三签名信息是否相同)。若预设Hash数据的根Hash与第三签名信息相匹配，则可以确定根文件系统对应的第三签名信息验证通过，可以挂载根文件系统。反之，则可以重新启动网关设备，重新获取预设验证信息和Bootloader、Kernel、根文件系统各自对应的签名信息。也就是说，每一个签名验证步骤失败都会重新启动网关设备。
这样，结合对Bootloader、Kernel、根文件系统的签名信息的三重验证，可以进一步提高网关设备的安全性，提高网关设备中数据的安全性。
可以理解的，考虑到Bootloader的环境变量一般都作为参数传递给Kernel，相关技术中，Bootloader环境变量通常保存在单独分区明文存储。这样，在从Bootloader切换到Kernel的流程中可能被通过串口等接口打断，导致需要重新加载环境变量，或者还可能出现脱机修改分区内容来修改明文存储的环境变量的情况。由于对Bootloader环境变量的修改可能造成安全风险，黑客可能通过修改Bootloader环境变量来修改Bootloader启动逻辑，从而跳过启动验证签名过程，或增加启动延时，以通过串口方式登录设备，读取分区加密密钥，及修改根文件系统验签密钥。这会造成分区加密失效及根文件系统被替换等安全风险。为避免由于Bootloader环境变量明文存储，出现Bootloader环境变量被篡改的情况，可以将Bootloader环境变量加密存储或者以只读方式存储。
在一些可能的实施例中，考虑到网关设备还可能进行固件升级处理，故而，在上述步骤确定Bootloader对应的第一签名信息验证通过，加载Bootloader之后，还可以执行如下步骤：
确定是否进入固件升级Recovery模式；
在进入Recovery模式的情况下，获取第四预设公钥；
基于第四预设公钥验证Recovery模式的第四签名信息；
在Recovery模式的第四签名信息验证通过的情况下，加载Recovery模式，以安装OTA数据包。
其中，recovery固件是一个最小内核，在设备进行OTA升级时会进入recovery模式，进行OTA数据包的安装。
在本公开的实施例中，在确定Bootloader对应的第一签名信息验证通过，加载Bootloader之后，网关设备还可以确定当前是否需要进行无线升级，即判断是否需要进入固件升级模式(即Recovery模式)。在需要进入Recovery模式的情况下，可以获取Recovery模式的签名信息，即第四签名信息，以及获取用于验证Recovery模式的签名信息的预设公钥，即第四预设公钥。其中，第四签名信息应该是基于第四预设公钥对应的第四预设私钥进行签名得到的。然后，可以基于第四预设公钥验证Recovery模式的第四签名信息，示例性的，可以用于第四预设公钥对第四签名信息进行解密，以确定第四预设公钥是否能够成功解密第四签名信息。在第四预设公钥成功解密第四签名信息的情况下，则可以认为Recovery模式的第四签名信息验证通过，可以加载Recovery模式，获取OTA安装包，以安装OTA数据包。可以理解的，在安装OTA数据包之后，可以重置Recovery模式标志位，然后，进行网关设备的重新启动。
这样，一方面，可以实现OTA数据包的安装，实现网关设备的固件更新。另一方面，仅在Recovery模式的签名信息验证通过的情况下，加载Recovery模式安装OTA数据包，还可以提高固件升级的安全性。
可以理解的，为了进一步提高无线升级安全性，还可以对OTA数据包进行加密和验签处理。示例性的，可以在OTA数据包打包过程中，对OTA数据包进行加密处理，例如可以通过AES(Advanced Encryption Standard，高级加密标准)对称加密算法对OTA包进行加密，并对加密后的OTA数据包附加对应的云平台的签名。在加载Recovery模式后，安装OTA数据包时，可以先验证OTA数据包的携带的云平台的签名是否正确。在OTA数据包的携带的云平台的签名正确的情况下，使用预设密钥解密OTA数据包，再进行OTA数据包的安装。这样，可以进一步提高OTA数据包的安全性，从而进一步提高固件升级过程的安全性，提高用户数据的安全性。
在进一步可能的实施例中，在确定是否进入Recovery模式之后，还可以执行如下步骤：
在不进入Recovery模式的情况下，验证第二预设公钥是否能够解密Kernel对应的第二签名信息。
在本公开的实施例中，在确定是否进入Recovery模式之后，如果不需要进行固件升级，则可以确认不需要进入Recovery模式。此时，则可以进行第二签名信息的验证，即验证第二预设公钥是否能够解密Kernel对应的第二签名信息，在第二预设公钥成功解密所述第二签名信息的情况下，确定Kernel对应的第二签名信息验证通过，加载Kernel；在预设Hash数据与第三签名信息相匹配的情况下，确定根文件系统对应的第三签名信息验证通过，挂载根文件系统。
在一些可能的实施例中，为避免由于网关设备暴露硬件调试接口，导致入侵者可以低成本入侵网关设备的情况，可以关闭网关设备的硬件调试接口，示例性的，可以关闭网关设备的串口登录接口、USB(Universal Serial Bus，通用串行总线)调试接口及远程登录接口，禁止通过硬件调试接口登录网关设备、禁止通过串口登录接口登录网关设备、禁止通过USB调试接口的ADB(Android Debug Bridge，Android调试桥)登录功能、禁止通过远程登录方式登录网关设备。这样，可以进一步提高网关设备的安全性，提高网关设备中的数据安全性。
为使本公开实施例提供的方法更清晰，下面结合附图2对本公开实施例提供的网关设备启动方法进行说明。如图2所示，该网关设备启动方法可以包括如下步骤：
在步骤S210中，获取预设验证信息，以及Bootloader、Kernel、根文件系统各自对应的签名信息。
在本公开的实施例中，获取预设验证信息，可以是获取第一预设公钥、第二预设公钥、预设哈希Hash数据；获取Bootloader、Kernel、根文件系统各自对应的签名信息，可以是获取Bootloader对应的第一签名信息、Kernel对应的第二签名信息、根文件系统对应的第三签名信息。
在步骤S220中，验证第一预设公钥是否能够解密Bootloader对应的第一签名信息。
在步骤S230中，在第一预设公钥成功解密第一签名信息的情况下，确定Bootloader对应的第一签名信息验证通过，加载Bootloader。
在步骤S240中，确定是否进入Recovery模式。
在不进入Recovery模式的情况下，执行步骤S250-S280。在进入Recovery模式的情况下，执行步骤S290-S2110。
在步骤S250中，验证第二预设公钥是否能够解密Kernel对应的第二签名信息。
在步骤S260中，在第二预设公钥成功解密第二签名信息的情况下，确定Kernel对应的第二签名信息验证通过，加载Kernel。
在步骤S270中，验证预设Hash数据是否与根文件系统对应的第三签名信息相匹配。
在步骤S280中，在预设Hash数据与第三签名信息相匹配的情况下，确定根文件系统对应的第三签名信息验证通过，挂载根文件系统。
在步骤S290中，在进入Recovery模式的情况下，获取第四预设公钥。
在步骤S2100中，基于第四预设公钥验证Recovery模式的第四签名信息。
在步骤S2110中，在Recovery模式的第四签名信息验证通过的情况下，加载Recovery模式，以安装OTA数据包。
在上述步骤执行之前，还可以执行如下步骤：
生成Bootloader对应的第一预设密钥对、Kernel对应的第二预设密钥对、根文件系统对应的预设Hash数据。
基于第一预设私钥对Bootloader进行签名，得到Bootloader对应的第一签名信息。
基于第二预设私钥对Kernel进行签名，得到Kernel对应的第二签名信息。
基于预设Hash数据对根文件系统进行签名，得到根文件系统对应的第三签名信息。
上述步骤的具体实现方式和技术效果已在相关的方法实施例中进行详细说明，为简洁起见，在此不再赘述。
基于相同的发明构思，本公开实施例还提供了一种网关设备启动装置，如图3所示，该网关设备启动装置300，可以包括：
第一获取模块310，用于获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；
第一验证模块320，用于基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；
第一加载模块330，用于在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
在一种可能的实施方式中，所述预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据；
所述网关设备启动装置300，还包括：
生成模块，用于生成所述Bootloader对应的第一预设密钥对、所述Kernel对应的第二预设密钥对、所述根文件系统对应的预设Hash数据；其中，所述第一预设密钥对包括第一预设公钥和第一预设私钥、所述第二预设密钥对包括第二预设公钥和第二预设私钥，所述第一预设密钥对和所述第二预设密钥对为对称密钥。
在一种可能的实施方式中，所述网关设备启动装置300，还包括：
第一签名模块，用于基于所述第一预设私钥对所述Bootloader进行签名，得到所述Bootloader对应的第一签名信息；
第二签名模块，用于基于所述第二预设私钥对所述Kernel进行签名，得到所述Kernel对应的第二签名信息；
第三签名模块，用于基于所述预设Hash数据对所述根文件系统进行签名，得到所述根文件系统对应的第三签名信息。
在一种可能的实施方式中，所述第一验证模块320，包括：
第一验证单元，用于验证所述第一预设公钥是否能够解密所述Bootloader对应的第一签名信息；
第二验证单元，用于验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息；
第三验证单元，用于验证所述预设Hash数据是否与所述根文件系统对应的第三签名信息相匹配。
在一种可能的实施方式中，所示第一加载模块330，包括：
第一加载单元，用于在所述第一预设公钥成功解密所述第一签名信息的情况下，确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader；
第二加载单元，用于在所述第二预设公钥成功解密所述第二签名信息的情况下，确定所述Kernel对应的第二签名信息验证通过，加载所述Kernel；
第三加载单元，用于在所述预设Hash数据与所述第三签名信息相匹配的情况下，确定所述根文件系统对应的第三签名信息验证通过，挂载所述根文件系统。
在一种可能的实施方式中，所述网关设备启动装置300，还包括：
模式确定模块，用于确定是否进入固件升级Recovery模式；
第二获取模块，用于在进入Recovery模式的情况下，获取第四预设公钥；
第二验证模块，用于基于所述第四预设公钥验证所述Recovery模式的第四签名信息；
第二加载模块，用于在所述Recovery模式的第四签名信息验证通过的情况下，加载所述Recovery模式，以安装OTA数据包。
在一种可能的实施方式中，所述第二验证单元，具体用于：
在不进入Recovery模式的情况下，验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
图4示出了可以用来实施本公开的实施例的示例电子设备400的示意性框图。电子设备400旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图4所示，电子设备400包括计算单元401，其可以根据存储在只读存储器(ROM)402中的计算机程序或者从存储单元408加载到随机访问存储器(RAM)403中的计算机程序，来执行各种适当的动作和处理。在RAM 403中，还可存储设备400操作所需的各种程序和数据。计算单元401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。
电子设备400中的多个部件连接至I/O接口405，包括：输入单元406，例如键盘、鼠标等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许电子设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元401的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元401执行上文所描述的各个方法和处理，例如网关设备启动方法。例如，在一些实施例中，网关设备启动方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由ROM 402和/或通信单元409而被载入和/或安装到电子设备400上。当计算机程序加载到RAM 403并由计算单元401执行时，可以执行上文描述的网关设备启动方法的一个或多个步骤。备选地，在其他实施例中，计算单元401可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行网关设备启动方法。
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网和区块链网络。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (16)

1.一种网关设备启动方法，其特征在于，包括：
获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；
基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；
在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
2.根据权利要求1所述的网关设备启动方法，其特征在于，所述预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据；
所述获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还包括：
生成所述Bootloader对应的第一预设密钥对、所述Kernel对应的第二预设密钥对、所述根文件系统对应的预设Hash数据；其中，所述第一预设密钥对包括第一预设公钥和第一预设私钥、所述第二预设密钥对包括第二预设公钥和第二预设私钥，所述第一预设密钥对和所述第二预设密钥对为对称密钥。
3.根据权利要求2所述网关设备启动方法，其特征在于，所述获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息之前，还包括：
基于所述第一预设私钥对所述Bootloader进行签名，得到所述Bootloader对应的第一签名信息；
基于所述第二预设私钥对所述Kernel进行签名，得到所述Kernel对应的第二签名信息；
基于所述预设Hash数据对所述根文件系统进行签名，得到所述根文件系统对应的第三签名信息。
4.根据权利要求3所述的网关设备启动方法，其特征在于，所述基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证，包括：
验证所述第一预设公钥是否能够解密所述Bootloader对应的第一签名信息；
验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息；
验证所述预设Hash数据是否与所述根文件系统对应的第三签名信息相匹配。
5.根据权利要求4所述的网关设备启动方法，其特征在于，在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，包括：
在所述第一预设公钥成功解密所述第一签名信息的情况下，确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader；
在所述第二预设公钥成功解密所述第二签名信息的情况下，确定所述Kernel对应的第二签名信息验证通过，加载所述Kernel；
在所述预设Hash数据与所述第三签名信息相匹配的情况下，确定所述根文件系统对应的第三签名信息验证通过，挂载所述根文件系统。
6.根据权利要求5所述的网关设备启动方法，其特征在于，所述确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader之后，还包括：
确定是否进入固件升级Recovery模式；
在进入Recovery模式的情况下，获取第四预设公钥；
基于所述第四预设公钥验证所述Recovery模式的第四签名信息；
在所述Recovery模式的第四签名信息验证通过的情况下，加载所述Recovery模式，以安装OTA数据包。
7.根据权利要求6所述的网关设备启动方法，其特征在于，所述确定是否进入固件升级Recovery模式之后，还包括：
在不进入Recovery模式的情况下，验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息。
8.一种网关设备启动装置，其特征在于，包括：
第一获取模块，用于获取预设验证信息，以及引导加载程序Bootloader、内核Kernel、根文件系统各自对应的签名信息；
第一验证模块，用于基于所述预设验证信息对Bootloader、Kernel、根文件系统各自对应的签名信息进行验证；
第一加载模块，用于在所述Bootloader、Kernel、根文件系统各自对应的签名信息验证通过的情况下，加载所述Bootloader、Kernel、根文件系统，以使网关设备处于启动状态。
9.根据权利要求8所述的网关设备启动装置，其特征在于，所述预设验证信息包括第一预设公钥、第二预设公钥、预设哈希Hash数据；
所述网关设备启动装置，还包括：
生成模块，用于生成所述Bootloader对应的第一预设密钥对、所述Kernel对应的第二预设密钥对、所述根文件系统对应的预设Hash数据；其中，所述第一预设密钥对包括第一预设公钥和第一预设私钥、所述第二预设密钥对包括第二预设公钥和第二预设私钥，所述第一预设密钥对和所述第二预设密钥对为对称密钥。
10.根据权利要求9所述网关设备启动装置，其特征在于，所述网关设备启动装置，还包括：
第一签名模块，用于基于所述第一预设私钥对所述Bootloader进行签名，得到所述Bootloader对应的第一签名信息；
第二签名模块，用于基于所述第二预设私钥对所述Kernel进行签名，得到所述Kernel对应的第二签名信息；
第三签名模块，用于基于所述预设Hash数据对所述根文件系统进行签名，得到所述根文件系统对应的第三签名信息。
11.根据权利要求10所述的网关设备启动装置，其特征在于，所述第一验证模块，包括：
第一验证单元，用于验证所述第一预设公钥是否能够解密所述Bootloader对应的第一签名信息；
第二验证单元，用于验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息；
第三验证单元，用于验证所述预设Hash数据是否与所述根文件系统对应的第三签名信息相匹配。
12.根据权利要求11所述的网关设备启动装置，其特征在于，所示第一加载模块，包括：
第一加载单元，用于在所述第一预设公钥成功解密所述第一签名信息的情况下，确定所述Bootloader对应的第一签名信息验证通过，加载所述Bootloader；
第二加载单元，用于在所述第二预设公钥成功解密所述第二签名信息的情况下，确定所述Kernel对应的第二签名信息验证通过，加载所述Kernel；
第三加载单元，用于在所述预设Hash数据与所述第三签名信息相匹配的情况下，确定所述根文件系统对应的第三签名信息验证通过，挂载所述根文件系统。
13.根据权利要求12所述的网关设备启动装置，其特征在于，所述网关设备启动装置，还包括：
模式确定模块，用于确定是否进入固件升级Recovery模式；
第二获取模块，用于在进入Recovery模式的情况下，获取第四预设公钥；
第二验证模块，用于基于所述第四预设公钥验证所述Recovery模式的第四签名信息；
第二加载模块，用于在所述Recovery模式的第四签名信息验证通过的情况下，加载所述Recovery模式，以安装OTA数据包。
14.根据权利要求13所述的网关设备启动装置，其特征在于，所述第二验证单元，具体用于：
在不进入Recovery模式的情况下，验证所述第二预设公钥是否能够解密所述Kernel对应的第二签名信息。
15.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的网关设备启动方法。
16.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至7中任一项所述的网关设备启动方法。
CN202210359432.6A 2022-04-06 2022-04-06 网关设备启动方法、装置、电子设备及存储介质 Pending CN116938465A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210359432.6A CN116938465A (zh) 2022-04-06 2022-04-06 网关设备启动方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210359432.6A CN116938465A (zh) 2022-04-06 2022-04-06 网关设备启动方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN116938465A true CN116938465A (zh) 2023-10-24

Family

ID=88385150

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210359432.6A Pending CN116938465A (zh) 2022-04-06 2022-04-06 网关设备启动方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN116938465A (zh)

Similar Documents

Publication Publication Date Title
US10148442B2 (en) End-to-end security for hardware running verified software
US10635821B2 (en) Method and apparatus for launching a device
US9319380B2 (en) Below-OS security solution for distributed network endpoints
US9525555B2 (en) Partitioning access to system resources
EP4020193A1 (en) Firmware update technologies
US8732445B2 (en) Information processing device, information processing method, information processing program, and integrated circuit
US11106798B2 (en) Automatically replacing versions of a key database for secure boots
US10878101B2 (en) Trusted booting by hardware root of trust (HRoT) device
US9325506B2 (en) Cryptographically enforcing strict separation of environments
CN113886809A (zh) 计算设备
KR20180093038A (ko) 신뢰 실행 환경을 갖는 모바일 디바이스
US20140215202A1 (en) Extension of a platform configuration register with a known value
WO2009051471A2 (en) Trusted computer platform method and system without trust credential
KR20090108706A (ko) 컴퓨팅 장치의 보안 부팅
EP3343424B1 (en) Control board secure start method, and software package upgrade method and device
CN111695166B (zh) 磁盘加密保护方法及装置
US11868474B2 (en) Securing node groups
US10771462B2 (en) User terminal using cloud service, integrated security management server for user terminal, and integrated security management method for user terminal
US11816236B1 (en) Customer-controlled dynamic attestation-policy-based remote attestation of compute resources
JP7439067B2 (ja) ファイルシステムの検証とインストール
CN115361132A (zh) 密钥生成方法、装置、片上系统、设备及存储介质
CN116938465A (zh) 网关设备启动方法、装置、电子设备及存储介质
CN113806787A (zh) 一种arm平台自动解密的方法、装置、设备及可读介质
CN112054895A (zh) 可信根构建方法及应用
CN113966510A (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