CN114491565A - 固件安全启动方法、装置、计算设备和可读存储介质 - Google Patents
固件安全启动方法、装置、计算设备和可读存储介质 Download PDFInfo
- Publication number
- CN114491565A CN114491565A CN202210327791.3A CN202210327791A CN114491565A CN 114491565 A CN114491565 A CN 114491565A CN 202210327791 A CN202210327791 A CN 202210327791A CN 114491565 A CN114491565 A CN 114491565A
- Authority
- CN
- China
- Prior art keywords
- interface
- image file
- verification
- signature
- hash
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
Abstract
本申请提供一种固件安全启动方法、装置、计算设备和可读存储介质，方法应用于计算设备，计算设备搭载有普通执行环境和可信执行环境；普通执行环境下运行有UEFI固件，普通执行环境中设置有至少一个第一调用接口，可信执行环境中设置有至少一个第二调用接口；该方法包括：当接收到对镜像文件的验证请求信息时，通过第一调用接口，将镜像文件的验证请求信息传递给第二调用接口，通过至少一个第二调用接口接收验证请求信息，并对镜像文件进行验证，得到验证结果；通过第二调用接口将验证结果返回至第一调用接口，以执行UEFI固件的启动过程。本申请实现了在可信执行环境下对镜像文件的验证，提高了UEFI启动的安全性。
Description
技术领域
本申请涉及计算机技术领域，具体而言，涉及一种固件安全启动方法、装置、计算设备和可读存储介质。
背景技术
UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）从规范的角度来看，它是一个规范，定义了计算机操作系统和平台固件之间的接口规范。从实体的角度来讲，BIOS（Basic Input Output System，基本输入输出系统） 和 UEFI 是两种不同类型的计算机固件，计算机固件就是固化在计算机主板上某个非易失存储区（EEPROM）中的小系统，计算机启动都是先启动它，然后加载真正的操作系统。
计算机启动后进入配置界面，能直观看到的是 UEFI 固件的UI界面，可以通过 UI来配置这个固件的可配置项，比如：操作系统启动顺序、启动等待时间等等。在 BIOS 时代，所有的设置都只能存储在主板上，容量很小，无法扩展。而 UEFI 将基础固件烧制在主板存储区中，然后在磁盘上创建 EFI （Extensible Firmware Interface，可扩展固件接口）系统分区来存储更多的内容和数据，通过 UEFI 规范来定义如何使用扩展的方式来定制和扩展功能。
当前UEFI安全启动系统是基于RSA算法实现的，在生成密钥、证书、签名和验签时都是使用RSA算法。 RSA加密算法是一种非对称加密算法。在公开密钥加密和电子商业中RSA被广泛使用。随着密码技术和计算的发展，RSA公钥密码算法正面临日益严重的安全威胁，国密SM2算法相比RSA具有如下优势：同等安全级别下，SM2算法签名速度快。为保障重要经济系统密码应用安全，防止出现非自主密码算法受到攻击导致重要经济系统敏感数据泄露，国密局推荐使用国产密码算法。
随着信息技术的发展，信息安全的形势日益严峻。保障信息安全的前提是信息系统本身是安全的，如果系统自身在启动时被恶意程序篡改，那么系统将进入一种不可信的状态，从而导致基于此系统的应用程序和上层安全机制都是不可信的。因此，系统的安全启动技术已逐步被引起重视。
发明内容
本申请实施例的目的在于提供一种固件安全启动方法、装置、计算设备和可读存储介质，用以实现在可信执行环境下对镜像文件的验证，提高UEFI启动的安全性。
本申请实施例第一方面提供了一种固件安全启动方法，所述方法应用于计算设备，所述计算设备搭载有普通执行环境和可信执行环境；所述普通执行环境下运行有UEFI固件，所述普通执行环境中设置有至少一个第一调用接口，所述可信执行环境中设置有至少一个第二调用接口，；所述方法包括：当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，其中，所述至少一个第一调用接口被配置的执行权限大于所述至少一个第二调用接口被配置的执行权限；通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果；通过所述第二调用接口将所述验证结果返回至所述第一调用接口，以执行所述UEFI固件的启动过程。
上述步骤中，在UEFI启动过程中，当接收到对镜像文件的验证请求信息时，通过调用可信执行环境中的接口来执行涉密的镜像文件验证过程，实现了在可信执行环境下对镜像文件的验证，提高了UEFI启动的安全性。
于一实施例中，所述普通执行环境和所述可信执行环境下被配置有执行权限依次增大的特权级别：EL0、EL1、EL2、EL3；所述UEFI固件被配置运行在所述普通执行环境的EL2级别，所述至少一个第一调用接口被配置在所述UEFI固件中；所述至少一个第二调用接口被配置运行在所述可信执行环境的EL1级别。
在上述步骤中，第一调用接口的执行权限大于第二调用接口，以这种方式，可以保证UEFI固件启动过程中的安全性。
于一实施例中，所述验证请求信息包括哈希计算请求；所述至少一个第一调用接口包括第一哈希接口；所述至少一个第二调用接口包括第二哈希接口；所述当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，包括：通过所述第一哈希接口，将所述镜像文件的哈希计算请求传递给所述第二哈希接口；所述通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果，包括：通过所述第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果；所述通过所述第二调用接口将所述验证结果返回至所述第一调用接口，包括：通过所述第二哈希接口将所述哈希计算结果返回至所述第一哈希接口。
在上述步骤中，当所述验证请求信息包括哈希计算请求时，预先在UEFI固件下配置第一哈希接口，在可信执行环境下配置第二哈希接口，在UEFI安全启动过程对镜像文件验证的步骤中，通过调用第二哈希接口对镜像文件进行hash计算，实现了对镜像的hash计算在可信环境下执行，降低hash计算中涉密数据泄露的风险，加强了UEFI启动过程的安全性。
于一实施例中，所述验证请求信息包括验签请求；所述至少一个第一调用接口包括第一验签接口；所述至少一个第二调用接口包括第二验签接口；所述当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口包括：通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口；所述通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果，包括：通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果；所述通过所述第二调用接口将所述验证结果返回至所述第一调用接口，包括：通过所述第二验签接口将所述验签结果返回至所述第一验签接口。
在上述步骤中，当所述验证请求信息包括验签请求时，预先在UEFI固件下配置第一验签接口，在可信执行环境下配置第二验签接口，在UEFI安全启动过程对镜像文件验证的步骤中，通过调用第二验签接口对镜像文件进行验签过程，实现了对镜像的验签在可信环境下执行，降低验签过程中涉密数据泄露的风险，加强了UEFI启动过程的安全性。于一实施例中，所述哈希计算请求包括所述镜像文件、所述镜像文件的数据长度、以及第一加密调用指令；所述通过第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果，包括：通过所述第二哈希接口从所述哈希计算请求中解析出所述镜像文件和所述镜像文件的数据长度、以及所述第一加密调用指令；通过所述第一加密调用指令对所述镜像文件和所述镜像文件的数据长度进行处理，生成所述镜像文件的所述哈希计算结果。
在上述步骤中，第二哈希接口接收到哈希计算请求后，首先从哈希计算请求中解析出镜像文件和镜像文件的数据长度、以及第一加密调用指令，然后使用第二哈希接口调用预先配置的第一加密算法，使用第一加密算法对原始镜像文件进行哈希运算，得到镜像文件的哈希计算结果。如此，UEFI启动过程中涉密的哈希计算请求的解析和处理均在安全世界进行，降低UEFI启动过程中的信息泄露风险。
于一实施例中，所述验签请求包括：所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度以及所述第二加密调用指令；所述通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果，包括：通过所述第二验签接口从所述验证请求信息中解析出所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、以及所述签名的长度；通过所述第二加密调用指令对所述哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度进行处理，生成所述镜像文件的验签结果。
在上述步骤中，第二验签接口接收到验签请求后，首先从验签请求中解析出镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、以及签名的长度，然后使用第二验签接口执行第二加密调用指令，调用预先配置的第二加密算法，使用第二加密算法对原始镜像文件进行验签运算，得到镜像文件的验签结果。如此，UEFI启动过程中涉密的验签请求的解析和处理均在安全世界进行，降低UEFI启动过程中的信息泄露风险。
于一实施例中，所述验签请求还包括：公钥、所述公钥的长度、初始化指令；在所述通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口之前，还包括：通过所述初始化指令对所述公钥、所述公钥的长度进行处理，以初始化第二加密算法。
在上述步骤中，通过预先对第二加密算法进行初始化，以保证后续验签过程可以安全顺利进行，进一步确保UEFI启动过程中验签过程的准确性和安全性。
本申请实施例第二方面提供了一种固件安全启动装置，所述装置应用于计算设备，所述计算设备搭载有普通执行环境和可信执行环境；所述普通执行环境下运行有UEFI固件，所述普通执行环境中设置有至少一个第一调用接口，所述可信执行环境中设置有至少一个第二调用接口，；所述装置包括：传递模块，用于当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，其中，所述至少一个第一调用接口被配置的执行权限大于所述至少一个第二调用接口被配置的执行权限；验证模块，用于通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果；返回模块，用于通过所述第二调用接口将所述验证结果返回至所述第一调用接口，以执行所述UEFI固件的启动过程。
于一实施例中，所述普通执行环境和所述可信执行环境下被配置有执行权限依次增大的特权级别：EL0、EL1、EL2、EL3；所述UEFI固件被配置运行在所述普通执行环境的EL2级别，所述至少一个第一调用接口被配置在所述UEFI固件中；所述至少一个第二调用接口被配置运行在所述可信执行环境的EL1级别。
于一实施例中，所述验证请求信息包括哈希计算请求；所述至少一个第一调用接口包括第一哈希接口；所述至少一个第二调用接口包括第二哈希接口；所述传递模块用于：通过所述第一哈希接口，将所述镜像文件的哈希计算请求传递给所述第二哈希接口；
于一实施例中，所述验证模块用于：通过所述第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果；
于一实施例中，所述返回模块用于：通过所述第二哈希接口将所述哈希计算结果返回至所述第一哈希接口。
于一实施例中，所述验证请求信息包括验签请求；所述至少一个第一调用接口包括第一验签接口；所述至少一个第二调用接口包括第二验签接口；所述传递模块用于：通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口；
于一实施例中，所述验证模块用于：通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果；
于一实施例中，所述返回模块用于：通过所述第二验签接口将所述验签结果返回至所述第一验签接口。
于一实施例中，所述哈希计算请求包括所述镜像文件、所述镜像文件的数据长度、以及第一加密调用指令；所述通过第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果，包括：通过所述第二哈希接口从所述哈希计算请求中解析出所述镜像文件和所述镜像文件的数据长度、以及所述第一加密调用指令；通过所述第一加密调用指令对所述镜像文件和所述镜像文件的数据长度进行处理，生成所述镜像文件的所述哈希计算结果。
于一实施例中，所述验签请求包括：所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度以及所述第二加密调用指令；所述通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果，包括：通过所述第二验签接口从所述验证请求信息中解析出所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、以及所述签名的长度；通过所述第二加密调用指令对所述哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度进行处理，生成所述镜像文件的验签结果。
于一实施例中，所述验签请求还包括：公钥、所述公钥的长度、初始化指令；在所述通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口之前，还包括：通过所述初始化指令对所述公钥、所述公钥的长度进行处理，以初始化第二加密算法。
本申请实施例第三方面提供了一种计算设备，包括：存储器，用以存储计算机程序；处理器，用以执行所述计算机程序，以实现本申请实施例第一方面及其任一实施例的方法。
本申请实施例第四方面提供了一种非暂态计算设备可读存储介质，包括：程序，当其藉由计算设备运行时，使得所述计算设备执行本申请实施例第一方面及其任一实施例的方法。
本申请提供的固件安全启动方法、装置、计算设备和可读存储介质，通过在所述计算设备中搭载普通执行环境和可信执行环境，并在所述普通执行环境下运行有UEFI固件，在所述普通执行环境中设置有至少一个第一调用接口，在所述可信执行环境中设置有至少一个第二调用接口，当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，然后通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果；最后通过所述第二调用接口将所述验证结果返回至所述第一调用接口，以执行所述UEFI固件的启动过程。如此，在UEFI启动过程中，通过调用可信执行环境接口来执行镜像文件验证过程，实现了在可信执行环境下对镜像文件的验证，提高了UEFI启动的安全性。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本申请一实施例的电子设备的示意图；
图2A为本申请一实施例的基于国密算法的UEFI安全启动方案中对待加载镜像的一次完整验证流程示意图；
图2B为本申请一实施例的固件启动接口系统示意图；
图2C为本申请一实施例的固件启动场景示意图；
图2D为本申请一实施例的提供的的固件启动接口系统示意图；
图2E为本申请一实施例的UEFI和OP-TEE之间交互通信示意图；
图3为本申请一实施例的固件安全启动方法的流程示意图；
图4为本申请一实施例的固件安全启动方法的流程示意图；
图5为本申请一实施例的固件安全启动方法的流程示意图；
图6为本申请一实施例的固件安全启动装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
为了清楚的描述本实施例的方案，现将涉及的名词定义如下：
UEFI：Unified Extensible Firmware Interface，统一可扩展固件接口。
TEE：Trusted Execution Environment，可信执行环境，TEE是基于trustzone技术搭建的一个与非安全世界隔离的可信程序运行环境。
OP-TEE：Open Portable TEE，开放可移植可信执行环境，OP-TEE 是一个开源工程，完整的实现了一个可信执行软硬件环境，在这个环境中，可以极大加强信息安全。
BL：BootLoader，引导加载程序。
OS：Operating System，操作系统。
SMC：SECURE MONITOR CALL，安全监控调用，用于正常世界和安全世界的切换。
终端设备：可以是移动终端、固定终端或便携式终端，例如移动手机、站点、单元、设备、多媒体计算机、多媒体平板、互联网节点、通信器、台式计算机、膝上型计算机、笔记本计算机、上网本计算机、平板计算机、个人通信系统设备、个人导航设备、个人数字助理、音频/视频播放器、数码相机/摄像机、定位设备、电视接收器、无线电广播接收器、电子书设备、游戏设备或者其任意组合，包括这些设备的配件和外设或者其任意组合。还可预见到的是，终端设备能够支持任意类型的针对用户的接口（例如可穿戴设备）等。
服务器：可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务以及大数据和人工智能平台等基础云计算服务的云服务器。
镜像文件：与压缩包类似，它将特定的一系列文件按照一定的格式制作成单一的文件，可以被特定的软件识别并可直接刻录到光盘上，以方便用户下载和使用，如，操作系统以及游戏等。在镜像文件中可以包含更多的信息，如，说系统文件、引导文件以及分区表信息等，镜像文件可以包含一个分区甚至是一块硬盘的所有信息。
国密算法：是国家密码局制定标准的一系列算法，包括了对称加密算法，椭圆曲线非对称加密算法（如，国密SM2算法）以及杂凑算法（即哈希算法，如，国密SM3算法）等。
国密SM2：是由国家密码管理局颁布的一种椭圆曲线公钥密码算法，主要用于数字签名、数据加密、密钥交换以及身份认证等。
平台密钥（Platform Key，PK）：是UEFI安全启动中的顶级密钥，用于递级验证来保证安全启动的可靠性。UEFI安全启动支持单个PK。PK通常由主板制造商提供，并被设置在主板的可快速擦除、可现场编程的非易失性快擦写存储器（flash）中。
密钥交换密钥（Key Exchange Key，KEK）：用于建立操作系统和平台固件之间的信任关系。每个操作系统（即每个需要与平台固件通信的第三方应用程序）登记一个公共key（即KEK）到平台固件中。
白名单（Authorized Signature Database，DB），即授权的签名库，包含已授权的证书和数字签名。
黑名单（Forbidden Signature Database，DBX）：即禁止的签名库，包含已知禁止运行的UEFI镜像文件的证书和数字签名。
如图1所示，本实施例提供一种计算设备1，包括：至少一个处理器11和存储器12，图1中以一个处理器为例。处理器11和存储器12通过总线10连接。存储器12存储有可被处理器11执行的指令，指令被处理器11执行，以使计算设备1可执行下述的实施例中方法的全部或部分流程，以在UEFI安全启动过程中，实现在可信执行环境下对镜像文件的完整性检查以及安全认证功能。
于一实施例中，计算设备1可以是终端设备，如手机、平板电脑、笔记本电脑、台式计算机或者多个计算机组成的大型运算系统。计算设备1也可以为服务器。
上述计算设备中运行有引导系统启动的固件，在计算设备正常运转之前，需要先启动固件，待引导系统启动的固件启动成功后，操作系统才会获得处理器的控制权，计算设备才可以正常使用。UEFI固件为计算设备众多固件中的一部分。在UEFI固件启动过程中，UEFI 安全启动会检查每个启动软件的签名，包括 UEFI 固件驱动程序（也称为 ROM 选项）、可扩展固件接口 (EFI) 应用程序以及操作系统驱动程序和二进制文件。如果签名有效或被原始设备制造商 (OEM) 认可，则计算设备将启动成功，固件将处理器的控制权交给操作系统。
当前UEFI安全启动系统是基于RSA算法实现的，在生成密钥、证书、签名和验签时都是使用RSA算法。 RSA加密算法是一种非对称加密算法。在公开密钥加密和电子商业中RSA被广泛使用。随着密码技术和计算的发展，RSA公钥密码算法正面临日益严重的安全威胁，国密SM2算法相比RSA具有如下优势：同等安全级别下，SM2算法签名速度快。为保障重要经济系统密码应用安全，防止出现非自主密码算法受到攻击导致重要经济系统敏感数据泄露，国密局推荐使用国产密码算法。
如图2A所示，为基于国密算法的UEFI安全启动方案中对待加载镜像的一次完整验证流程图， 一种实施方式中，当一个UEFI镜像文件被加载时，系统会进入CoreLoadImage（）函数，该函数调用DxeImageVerificationHandler（）函数，按照图2A所示的流程图，对UEFI镜像文件进行签名验证，只有验签成功才能加载该镜像，否则，阻止镜像的加载。该方法的具体实施流程如下：
步骤201：判断待加载的UEFI镜像文件的镜像文件类型是否为指定类型，若是，则执行步骤209，否则，执行202。
步骤202：判断待加载的UEFI镜像文件中包含的格式字段是否为指定格式，若是，则执行步骤203，否则，执行步骤210。
步骤203：判断待签名验证的UEFI镜像文件中是否包含镜像签名信息，若是，则执行步骤204，否则，执行步骤211。
步骤204：判断镜像签名信息中的算法标识信息与国密算法的算法标识信息是否匹配，若是，则执行步骤205，否则，执行步骤210。
步骤205：判断镜像签名信息中的摘要与原始镜像内容的摘要是否一致，若是，则执行步骤206，否则，执行步骤210。
在本步骤中，国密算法包括SM3算法，原始镜像内容的摘要是基于国密算法中的SM3算法对原始镜像内容进行哈希运算获得的具有唯一计算结果的一段32字节的字符串。
其中，原始镜像内容的摘要可以表示为mdigest。镜像签名信息中的摘要可以表示为digest。原始镜像内容是从UEFI镜像文件中的原始数据区中获取。镜像签名信息是从UEFI镜像文件中的签名数据（AuthData）区域获取的。
于一实施例中，步骤205具体可以包括：获取镜像签名信息中包含的摘要，并采用SM3算法对原始镜像内容进行哈希运算，获得原始镜像内容的摘要，以及将镜像签名信息中包含的摘要与原始镜像内容的摘要进行比对，以确定两者是否一致。若镜像签名信息中的摘要与原始镜像内容的摘要不一致，则说明原始镜像内容被篡改了，则签名验证失败。
步骤206：判断是否基于黑名单中的黑名单密钥对镜像签名信息中包含的加密后的摘要解密失败，若是，则执行步骤207，否则，执行步骤211。
在本步骤中，国密算法中还包括SM2算法，以对加密后的摘要进行解密，黑名单中还包括禁止通过的黑名单密钥。
于一实施例中，步骤206具体可以包括：获取黑名单中包含的黑名单密钥，以及镜像签名信息中包含的加密后的摘要，并采用SM2算法，基于黑名单密钥对加密后的摘要进行解密，以及根据解密结果，判断是否解密失败。
这是由于若基于黑名单中的黑名单密钥解密成功，说明UEFI镜像文件的签名证书是被列入了黑名单，则需要进一步判断白名单中是否包含原始镜像内容的摘要。
步骤207：判断是否基于白名单中的白名单密钥对镜像签名信息中包含的加密后的摘要解密成功，若是，则执行步骤208，否则，执行步骤211。
在本步骤中，白名单包括允许通过的摘要和白名单密钥。于一实施例中，步骤207具体可以包括：获取白名单中的白名单密钥，以及镜像签名信息中包含的加密后的摘要，并采用SM2算法，基于白名单密钥对加密后的摘要进行解密，以及根据解密结果，确定是否解密成功。
这是由于若基于白名单中的白名单密钥解密失败，则说明白名单没有授权UEFI镜像文件的签名证书，若白名单中既没有授权UEFI镜像文件的签名证书，也没有授权原始镜像内容的摘要，则确定UEFI镜像文件是不合法的，即签名验证失败。步骤208：判断黑名单中是否包含原始镜像内容的摘要，若是，则执行步骤209，否则，执行步骤210。
在本步骤中，黑名单（如，DBX库）中包括禁止通过的摘要。若黑名单包含原始镜像内容的摘要，则说明UEFI镜像文件为禁止加载的文件，即签名验证失败。步骤209：验证成功。步骤210：验证失败。
步骤211：判断黑名单中是否未包含原始镜像内容的摘要，若是，则执行步骤212，否则，执行步骤210。步骤212：判断白名单中是否包含原始镜像内容的摘要，若是，则执行步骤209，否则，执行步骤210。
在本步骤中，若UEFI镜像文件的签名证书被列入了黑名单，白名单中也没有授权原始镜像内容的摘要，则确定UEFI镜像文件是不合法的，即签名验证失败。
本申请实施例中，仅以步骤201-步骤212的执行顺序进行签名验证为例进行说明，实际应用中，签名验证时的各判断步骤，可以根据实际应用场景进行调整，在此不做限制。
其中，在步骤205至步骤207中涉及到对镜像文件的安全性和完整性进行验证，完整性是通过hash计算得到的hash值来比对的，安全性是通过verify接口来验证该镜像是否经过授权。而上述镜像文件验证过程，会涉及计算设备的安全信息，为了提高镜像文件验证过程的安全性，可以将上述验证过程通过可信执行环境来实现。即当步骤205中需要“计算镜像文件的原文hash”，时，可以采用可信执行环境中的hash接口进行实现。而步骤206中的“DBX （黑名单）库中的证书信息验证AuthData区的签名”和步骤207中地的“DB（白名单）库中的证书信息验证AuthData区的签名”通过调用可信执行环境的验签接口来实现。
为了实现本申请实施例的固件安全启动方法，可以预先在计算设备中搭载有普通执行环境和可信执行环境，将涉密的验证过程设置在可信执行环境下执行。
如图2B所示，为本实施例提供一种固件启动接口系统200示意图，在计算设备中搭载有普通执行环境21和可信执行环境22，普通执行环境21下运行有UEFI固件，普通执行环境21中设置有至少一个第一调用接口211，可信执行环境22中设置有至少一个第二调用接口221。当接收到对镜像文件的验证请求信息时，通过第一调用接口211，将镜像文件的验证请求信息传递给第二调用接口221，然后通过至少一个第二调用接口221接收验证请求信息，并对镜像文件进行验证，得到验证结果。最后通过第二调用接口221将验证结果返回至第一调用接口211，以执行UEFI固件的启动过程。
下面以某一类型架构的处理器为例，详细说明本实施例的固件启动接口系统200的应用场景。
如图2C所示，为本实施例提供一种固件启动场景示意图，硬件资源划被分成了两个部分secure world（安全世界，即图2C中的Secure部分）和normal world（指普通世界，即图2C中的Non-Secure部分）。当CPU运行在secure world的时候，它可以访问所有的硬件资源，但当CPU运行在normal world的时候，它只能访问normal world的资源。也就是说，普通世界中的用户应用程序和操作系统是具备传统功能，而安全世界中的用户应用程序和操作系统具有专门的用途，例如数字签名管理，认证等。两个世界通过共享内存进行通信。
上述固件启动场景中，安全世界依次包括的固件有：Boot ROM（无盘启动ROM接口）、Platform initialization firmwre（平台初始化固件）、EL3 runtime firmwre（EL3运行时固件）、OP-TEE。
普通世界包括：U-Boot/UEFI固件、Kernel（操作系统OS的内核）。
在计算设备整个启动过程中，箭头上的数字，表示启动顺序。从Boot ROM里面的BL1开始，按照BL1->BL2->BL31->BL32->BL33->OS顺序启动，直到启动操作系统OS界面，完成启动。如图2B所示，普通世界和安全下被配置有执行权限依次增大的特权级别：EL0、EL1、EL2、EL3，UEFI固件被配置运行在普通世界的EL2级别，OP-TEE被配置运行在安全世界的EL1级别。在进入UEFI（BL33）启动的时候，OP-TEE已经完成启动，而UEFI与OP-TEE之间可以通过SMC interface接口进行通信。因此，在进行UEFI启动时，在对镜像文件进行完整性和安全性验证时，可以通过普通世界触发SMC方式调用安全世界的OP-TEE对应接口来实现某些功能，如此，可以将上述步骤205至步骤207中涉及到对镜像文件的的验证过程传递到安全世界进行验证，并返回验证结果给普通世界。
如图2D所示，为本实施例提供一种固件启动接口系统200示意图，其中普通执行环境21可以由如图2C所示的normal world（普通世界）来实现，可以在UEFI固件配置至少一个第一调用接口211，第一调用接口211可以包括：hash接口、verify接口和SM2接口。可信执行环境22可以由图2C所示的secure world（安全世界）来实现，至少一个第二调用接口221可以配置在OP-TEE中，第二调用接口221可以包括：tee-hash接口、tee-verify接口。其中至少一个第一调用接口211与至少一个第二调用接口221之间通过SMC实现一一对应的通信交互关系，比如hash接口对应于tee-hash接口，verify接口对应于tee-verify接口。
在本实施例中，UEFI固件整体是运行在normal世界的。在UEFI安全启动过程中，会对待执行的镜像文件进行hash计算或verify（验签），主要流程如下：
1）在收到hash请求或者verify的请求时，UEFI主动向SMC发出对应操作请求。
2）SMC负责把从UEFI接收到的请求转发给处于安全世界的OP-TEE。
3）OP-TEE收到命令后对命令进行解析并执行和反馈给SMC。
4）SMC将执行结果和反馈传回给UEFI。
5）UEFI根据从SMC收到的结果进行下一步操作。
其中，第一调用接口211与第二调用接口221之间的信息交互是基于UEFI和OP-TEE之间交互通信来实现的，如图2E所示，具体过程如下：
UEFI（设为客户端）和OP-TEE（设为可信端）之间的交互通过Uuid（UniversallyUnique Identifier，通用唯一识别码）来进行识别，只有使用相同的 Uuid，双方才能实现交互。图2E为客户端和可信端的一次完整接口交互过程。包括：OpteeInit、OpteeOpenSession、OpteeInvokeFuntion 和 OpteeCloseSession四个接口，具体功能及参数定义如下：
OpteeInit()：用来初始化上下文，创建共享内存。
OpteeOpenSession(OPTEE_OPEN_SESSION_ARG *OpenArg)：根据约定的Uuid参数，建立客户端呼叫可信端的通道，为连接客户端-可信端的起始点，可信端返回会话打开结果。其OPTEE_OPEN_SESSION_ARG类型参数定义如下：
Typedef struct {
EFI_GUID Uuid; //与可信端约定的uuid
UINT32 Session; // 会话端口号
UINT32 Return; //返回值
}
OpteeInvokeFuntion：客户端调用该接口传送指令与需要的参数给可信端，可信端返回执行结果给客户端。其中，OPTEE_INVOKE_ FUNCTION_ARG的结构体参数InvokeArg定义如下：
Typedef struct {
UINT32 Function; //发送给OPTEE的命令
UINT32 Session; // 会话端口号
UINT32 Return; //返回值
OPTEE_MESSAGE_PARAM params[];
//传送参数信息，包括数据和长度等
}
OpteeCloseSession (IN UINT32 Session)：客户端关闭本次会话，参数Session为OpteeOpenSession（&OpenArg）所建立的会话端口号，可信端返回关闭会话执行结果给客户端。
其中TA可以分为Static TA（静态TA） 和Dynamic TA（动态TA）两种，静态TA运行在内核模式中，动态TA运行在用户模式中，一般存储在文件系统中，通过TEE_Supplicant被OP-TEE加载。
在TA档案中就是在TEE中要执行的内容，主要使用五个API（接口）来控制连结与指令操作，如下：
TA_CreateEntryPoint：建立进入点，让TA可以被呼叫。
TA_OpenSessionEntryPoint：建立UEFI呼叫TA的通道，为连接的起始点。
TA_CloseSessionEntryPoint：关闭UEFI与TA的通道。
TA_InvokeCommandEntryPoint：接收UEFI传送的指令，并在这边执行。
TA_DestroyEntryPoint：移除进入点，结束TA的功能。
本申请实施例中，可以通过在UEFI代码中调用hash接口进行对镜像哈希计算，该过程实际上是通过SMC到达OP-TEE的tee-hash接口来实现的。在进行镜像验签时，UEFI的verify接口，会调用sm2_verify接口实现，sm2_verify接口实际上是通过SMC到达OP-TEE的tee-verify接口来实现的。如此，实现了镜像的完整性和安全性都是在secure世界完成的，进一步加强了启动过程的安全性。
下面结合图例，进一步详细描述本申请实施例的固件安全启动方法。
请参看图3，其为本申请一实施例的固件安全启动方法，该方法可由图1所示的计算设备1来执行，并可以应用于对上述图2A-图2E所示固件安全启动场景中，以在UEFI安全启动过程中，实现在可信执行环境22下对镜像文件的完整性检查以及安全认证功能。该方法包括如下步骤：
步骤301：当接收到对镜像文件的验证请求信息时，通过第一调用接口211，将镜像文件的验证请求信息传递给第二调用接口221。
在本步骤中，至少一个第一调用接口211被配置的执行权限大于至少一个第二调用接口221被配置的执行权限。如图2D中，作为第一调用接口211的hash接口、verify接口和SM2接口配置在UEFI固件中，而UEFI固件被配置的特权等级为EL2，作为第二调用接口221的tee-hash接口、tee-verify接口配置在OP-TEE中，而OP-TEE中被配置的特权等级为EL1，EL2大于EL1。在上述配置下，验证请求信息包含但不限于哈希计算请求和验签请求，比如可以是如图2A中步骤205中提到的哈希计算过程的请求，或者步骤206和步骤207中提及的验签请求。实时检测是否接收到上述验证请求，当接到对镜像文件的验证请求信息时，通过第一调用接口211，将镜像文件的验证请求信息传递给第二调用接口221。
于一实施例中，如果验证请求是哈希计算请求，可以在UEFI代码中调用hash接口进行对镜像哈希计算，此时可以通过SMC到达OP-TEE的tee-hash接口来实现将验证请求信息的传递过程。
于一实施例中，如果验证请求是验签请求，可以通过的verify接口，调用sm2_verify接口实现，sm2_verify接口通过SMC到达OP-TEE的tee-verify接口来实现验证请求信息的传递。
步骤302：通过至少一个第二调用接口221接收验证请求信息，并对镜像文件进行验证，得到验证结果。
在本步骤中，验证请求传递给安全世界后，通过安全世界下OP-TEE中配置的对应接口来执行相关验证操作。预先在OP-TEE中配置验证过程需要的算法函数，OP-TEE即可按照验证请求信息执行对应的算法处理过程，进而对镜像文件进行验证，并生成验证结果。如此，涉及系统安全的一些验证过程可以转移到安全世界进行执行，降低系统启动过程中的泄密风险，提高系统启动的安全性。
步骤303：通过第二调用接口221将验证结果返回至第一调用接口211，以执行UEFI固件的启动过程。
在本步骤中，验证结果可以通过OP-TEE中配置的第二调用接口221一一对应的返回给普通世界的第一调用接口211。比如tee-hash接口执行哈希计算，得到哈希计算结果，然后将哈希计算结果返回给UEFI固件的hash接口，这样图2A中步骤205中的采用SM3算法对原始镜像内容进行哈希运算的过程就可以在安全世界完成，UEFI固件可以根据hash接口接收到的哈希计算结果执行后续启动步骤。同样的tee-verify接口执行验签过程，并得到验签结果，然后将验签结果返回给UEFI固件的verify接口。如此，图2A中步骤206以及步骤207的验签过程，也在安全世界完成， UEFI固件可以根据verify接口接收到的验签结果执行后续启动步骤，以完成UEFI固件的启动过程。如此，涉及信息安全的步骤转移到了安全世界执行，提高了系统启动的安全性能。
上述固件安全启动方法，当接收到对镜像文件的验证请求信息时，通过第一调用接口211，将镜像文件的验证请求信息传递给第二调用接口221，然后通过至少一个第二调用接口221接收验证请求信息，并对镜像文件进行验证，得到验证结果。最后通过第二调用接口221将验证结果返回至第一调用接口211，以执行UEFI固件的启动过程。如此，在UEFI启动过程中，通过调用可信执行环境22接口来执行涉密的镜像文件验证过程，实现了在可信执行环境22下对镜像文件的验证，提高了UEFI启动的安全性。
请参看图4，其为本申请一实施例的固件安全启动方法，该方法可由图1所示的计算设备1来执行，并可以应用于对上述图2A-图2E所示固件安全启动场景中，以在UEFI安全启动过程中，实现在可信执行环境22下对镜像文件的完整性检查以及安全认证功能。以验证请求信息包括哈希计算请求为例，至少一个第一调用接口211包括第一哈希接口。至少一个第二调用接口221包括第二哈希接口。则该方法包括如下步骤：
步骤401：当接收到对镜像文件的哈希计算请求时，通过第一哈希接口，将镜像文件的哈希计算请求传递给第二哈希接口。
在本步骤中，第一哈希接口可以由图2D中的hash接口实现，第二哈希接口可以由图2D中的tee-hash接口实现，当接收到对镜像文件的哈希计算请求时，通过普通世界的hash接口将哈希计算请求传送给安全世界的tee-hash接口。tee-hash接口用来执行哈希计算的过程。哈希计算请求包含但不限于：镜像文件、镜像文件的数据长度、以及第一加密调用指令。其中第一加密调用指令用来调用安全世界中tee-hash接口预定的第一加密算法，第一加密算法可以是国密算法，比如SM3算法，也可以是其他类型的加密算法，比如RSA算法。
于一实施例中，假设hash接口用来实现如图2A中步骤205的采用SM3算法对原始镜像文件进行哈希运算，则第一加密调用指令用来调用安全世界中tee-hash接口SM3算法（第一加密算法）。hash接口可以分Sm3Init()、Sm3Update()、Sm3Final()三部分实现。其中Sm3Init()：用于初始化安全世界tee-hash接口的SM3算法。Sm3Update()用于向安全世界tee-hash接口传递参数，并调用对应的算法执行哈希运算。Sm3Final()用于从安全世界tee-hash接口返回执行结果。
基于如图2E所示的UEFI和OP-TEE之间交互通信流程，步骤401之前，需要首先使用Sm3Init()来初始化安全世界tee-hash接口的SM3算法。具体调用过程如下：
Sm3Init()：用于初始化安全世界tee-hash接口的SM3算法。先调用OpteeInit，初始化上下文，创建共享内存。再调用OpteeOpenSession，根据UEFI和OP-TEE之间约定的Uuid打开会话。接着调用OpteeInvokeFuntion，传送SM3_INIT（SM3算法初始化指令）指令给OP-TEE端的tee-hash接口，如果OP-TEE端返回值为成功，则Sm3Init返回成功，即tee-hash接口的SM3算法初始化成功。
然后使用Sm3Update()实现步骤401，具体调用过程如下：
Sm3Update()：将SM3_UPDATE指令（第一加密调用指令）和待计算的镜像文件和及其数据长度填充到InvokeArg（调用参数）中，调用OpteeInvokeFuntion，并取回返回值。即可将还需计算请求传递给tee-hash接口。
步骤402：通过第二哈希接口接收哈希计算请求，并对镜像文件进行哈希计算，得到镜像文件的哈希计算结果。
在本步骤中，以步骤401中的例子，第二哈希接口就是安全世界tee-hash接口，tee-hash接口接收到哈希计算请求后，基于哈希计算请求中的调用参数和第一加密调用指令，执行对镜像文件进行哈希计算，得到镜像文件的哈希计算结果。
具体地，步骤402可以包括：通过第二哈希接口从哈希计算请求中解析出镜像文件和镜像文件的数据长度、以及第一加密调用指令。通过第一加密调用指令对镜像文件和镜像文件的数据长度进行处理，生成镜像文件的哈希计算结果。
即tee-hash接口接收到哈希计算请求后，首先从哈希计算请求中解析出镜像文件和镜像文件的数据长度、以及SM3_UPDATE指令，然后使用tee-hash接口调用预先配置的SM3算法，使用SM3算法对原始镜像文件进行哈希运算，得到镜像文件的哈希计算结果。如此，UEFI启动过程中涉密的哈希计算请求的解析和处理均在安全世界进行，降低UEFI启动过程中的信息泄露风险。
步骤403：通过第二哈希接口将哈希计算结果返回至第一哈希接口。
在本步骤中和，UEFI固件中的hash接口可以使用Sm3Final()从tee-hash接口获取镜像文件的哈希计算结果，流程如下：
Sm3Final()：将SM3_FINAL指令（结果返回指令）填充到InvokeArg中，调用OpteeInvokeFuntion，取回InvokeArg的params数据，保存镜像文件的哈希计算结果mdigest。
于一实施例中，在完成步骤401-步骤403的步骤中，可以调用OpteeCloseSession(OpenArg.Session)结束会话。避免会话占用额外资源。
步骤404：根据哈希计算结果执行UEFI固件的启动过程。详细参见上述实施例中对步骤303的描述。
上述固件安全启动方法，通过预先在UEFI固件下配置hash接口，在可信执行环境22下配置tee-hash接口，在UEFI安全启动过程对镜像文件验证的步骤中，通过调用OP-TEE接口对镜像文件进行hash计算，实现了对镜像文件的hash计算在可信环境下执行，加强了UEFI启动过程的安全性。
请参看图5，其为本申请一实施例的固件安全启动方法，该方法可由图1所示的计算设备1来执行，并可以应用于对上述图2A-图2E所示固件安全启动场景中，以在UEFI安全启动过程中，实现在可信执行环境22下对镜像文件的完整性检查以及安全认证功能。以验证请求信息包括验签请求为例，至少一个第一调用接口211包括第一验签接口。至少一个第二调用接口221包括第二验签接口。则该方法包括如下步骤：
步骤501：当接收到对镜像文件的验签请求时，通过初始化指令对公钥、公钥的长度进行处理，以初始化第二加密算法。
在本步骤中，第一验签接口可以由图2D中的verify接口实现，第二验签接口可以由图2D中的tee-verify接口实现。验签请求可以包括：公钥、公钥的长度、初始化指令。此处公钥pubkey可以是verify接口与tee-verify接口约定的用于镜像文件验签的公钥。
于一实施例中，验签计算请求还可以包括：镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、签名的长度以及第二加密调用指令。其中第二加密调用指令用来调用安全世界中tee-verify接口预定的第二加密算法。第二加密算法可以是国密算法，比如SM2算法，也可以是其他类型的加密算法，比如RSA算法。镜像文件的哈希计算结果可以是上述实施例中通过步骤401-步骤403得到的哈希计算结果，也可以是通过其他算法得到的哈希计算结果，本实施例对于镜像文件的哈希计算结果来源不做限定。
于一实施例中，假设verify接口用来实现如图2A中步骤206或者步骤207中采用SM2算法对原始镜像文件进行验签的过程，则第二加密调用指令用来调用安全世界中tee-verify接口的SM2算法（第二加密算法），第二加密调用指令可以定义为SM2_VERIFY，对SM2算法的初始化指令就可以是SM2_VERIFY_INIT。
基于如图2E所示的UEFI和OP-TEE之间交互通信流程，在步骤501之前，需要首先建立verify接口到tee-verify接口的会话，具体调用过程如下：
步骤S1: 调用OpteeInit()。用来初始化上下文，创建共享内存。
步骤S2: 调用OpteeOpenSession(&OpenArg)打开会话。
然后采用如下调用过程实现步骤501：
将公钥pubkey数据和长度填充到InvokeArg的params中，将命令SM2_VERIFY_INIT填充到InvokeArg的Functio中，调用OpteeInvokeFuntion(&InvokeArg)。实现对SM2算法的初始化。
步骤502：通过第一验签接口，将镜像文件的验签请求传递给第二验签接口。
在本步骤中，当安全世界tee-verify接口对SM2算法初始化成功后，会返回成功结果给普通世界中UEFI的verify接口，然后通过普通世界的verify接口将验签请求传送给安全世界的tee-verify接口。
具体地，可以将镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、签名的长度以及第二加密调用指令作为调用参数，调用OpteeInvokeFuntion，实现将验签请求从verify接口传递到tee-verify接口，调用过程如下：
将待验证镜像的hash计算结果数据mdigest和长度填充到InvokeArg的params[0]中，将待验证镜像文件的签名sig和签名的长度填充到InvokeArg的params[1]中，将命令SM2_VERIFY（第二加密调用指令）填充到InvokeArg的Function中Function中，调用OpteeInvokeFuntion(&InvokeArg)，即可将验签请求传递给tee-verify接口。
步骤503：通过第二验签接口接收验签请求，并对镜像文件进行验签，得到验签结果。
在本步骤中，以步骤501至步骤502中的例子，第二验签接口就是安全世界tee-verify接口，tee-verify接口接收到验签请求后，基于验签请求中的调用参数和第二加密调用指令，执行对镜像文件进行验签过程，得到镜像文件的验签结果。
具体地，步骤503可以包括：通过第二验签接口从验证请求信息中解析出镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、以及签名的长度。通过第二加密调用指令对哈希计算结果、哈希计算结果的长度、镜像文件的签名、签名的长度进行处理，生成镜像文件的验签结果。
即tee-verify接口接收到验签请求后，首先从验签请求中解析出镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、以及签名的长度，然后使用tee-verify接口执行SM2_VERIFY指令，调用预先配置的SM2算法，使用SM2算法对原始镜像文件进行验签运算，得到镜像文件的验签结果。如此，UEFI启动过程中涉密的验签请求的解析和处理均在安全世界进行，降低UEFI启动过程中的信息泄露风险。
步骤504：通过第二验签接口将验签结果返回至第一验签接口。
在本步骤中，tee-verify接口对镜像文件验签结束后，可以通过建立的会话返回验签结果给普通世界的verify接口，也可以配置UEFI固件，通过verify接口发送结果返回指令给tee-verify接口，以使tee-verify接口返回验签结果给UEFI固件的verify接口。
于一实施例中，在完成步骤501-步骤504后，可以调用OpteeCloseSession(OpenArg.Session)结束会话。避免会话占用额外资源。
步骤505：根据验签结果执行UEFI固件的启动过程。详细参见上述实施例中对步骤303的描述。
上述固件安全启动方法，通过预先在UEFI固件下配置verify接口，在可信执行环境22下配置tee-verify接口，在UEFI安全启动过程对镜像文件验证的步骤中，通过调用OP-TEE接口对镜像文件进行验签过程，实现了对镜像的验签在可信环境下执行，实现了在可信执行环境22下对镜像的安全认证功能。
请参看图6，其为本申请一实施例的固件安全启动装置600，该装置可应用于图1所示的电子设备1，并可以应用于对上述图2A-图2E所示固件安全启动场景中，以在UEFI安全启动过程中，实现在可信执行环境22下对镜像文件的完整性检查以及安全认证功能。装置应用于计算设备，计算设备搭载有普通执行环境21和可信执行环境22。普通执行环境21下运行有UEFI固件，普通执行环境21中设置有至少一个第一调用接口211，可信执行环境22中设置有至少一个第二调用接口221。该装置包括：传递模块601、验证模块602和返回模块603，各个模块的原理关系如下：
传递模块601，用于当接收到对镜像文件的验证请求信息时，通过第一调用接口211，将镜像文件的验证请求信息传递给第二调用接口221，其中，至少一个第一调用接口211被配置的执行权限大于至少一个第二调用接口221被配置的执行权限。
验证模块602，用于通过至少一个第二调用接口221接收验证请求信息，并对镜像文件进行验证，得到验证结果。
返回模块603，用于通过第二调用接口221将验证结果返回至第一调用接口211，以执行UEFI固件的启动过程。
于一实施例中，普通执行环境21和可信执行环境22下被配置有执行权限依次增大的特权级别：EL0、EL1、EL2、EL3。UEFI固件被配置运行在普通执行环境21的EL2级别，至少一个第一调用接口211被配置在UEFI固件中。至少一个第二调用接口221被配置运行在可信执行环境22的EL1级别。
于一实施例中，验证请求信息包括哈希计算请求。至少一个第一调用接口211包括第一哈希接口。至少一个第二调用接口221包括第二哈希接口。传递模块601用于：通过第一哈希接口，将镜像文件的哈希计算请求传递给第二哈希接口。
于一实施例中，验证模块602用于：通过第二哈希接口接收哈希计算请求，并对镜像文件进行哈希计算，得到镜像文件的哈希计算结果。
于一实施例中，返回模块603用于：通过第二哈希接口将哈希计算结果返回至第一哈希接口。
于一实施例中，验证请求信息包括验签请求。至少一个第一调用接口211包括第一验签接口。至少一个第二调用接口221包括第二验签接口。传递模块601用于：通过第一验签接口，将镜像文件的验签请求传递给第二验签接口。
于一实施例中，验证模块602用于：通过第二验签接口接收验签请求，并对镜像文件进行验签，得到验签结果。
于一实施例中，返回模块603用于：通过第二验签接口将验签结果返回至第一验签接口。
于一实施例中，哈希计算请求包括镜像文件、镜像文件的数据长度、以及第一加密调用指令。通过第二哈希接口接收哈希计算请求，并对镜像文件进行哈希计算，得到镜像文件的哈希计算结果，包括：通过第二哈希接口从哈希计算请求中解析出镜像文件和镜像文件的数据长度、以及第一加密调用指令。通过第一加密调用指令对镜像文件和镜像文件的数据长度进行处理，生成镜像文件的哈希计算结果。
于一实施例中，验签请求包括：镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、签名的长度以及第二加密调用指令。通过第二验签接口接收验签请求，并对镜像文件进行验签，得到验签结果，包括：通过第二验签接口从验证请求信息中解析出镜像文件的哈希计算结果、哈希计算结果的长度、镜像文件的签名、以及签名的长度。通过第二加密调用指令对哈希计算结果、哈希计算结果的长度、镜像文件的签名、签名的长度进行处理，生成镜像文件的验签结果。
于一实施例中，验签请求还包括：公钥、公钥的长度、初始化指令。在通过第一验签接口，将镜像文件的验签请求传递给第二验签接口之前，还包括：通过初始化指令对公钥、公钥的长度进行处理，以初始化第二加密算法。
上述固件安全启动装置600的详细描述，请参见上述实施例中相关方法步骤的描述。
本发明实施例还提供了一种非暂态计算设备可读存储介质，包括：程序，当其在计算设备上运行时，使得计算设备可执行上述实施例中方法的全部或部分流程。其中，存储介质可为磁盘、光盘、只读存储记忆体（Read-Only Memory，ROM）、随机存储记忆体（RandomAccess Memory，RAM）、快闪存储器（Flash Memory）、硬盘（Hard Disk Drive，缩写：HDD）或固态硬盘（Solid-State Drive，SSD)等。存储介质还可以包括上述种类的存储器的组合。
虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。
Claims (10)
1.一种固件安全启动方法，其特征在于，所述方法应用于计算设备，所述计算设备搭载有普通执行环境和可信执行环境；所述普通执行环境下运行有UEFI固件，所述普通执行环境中设置有至少一个第一调用接口，所述可信执行环境中设置有至少一个第二调用接口；所述方法包括：
当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，其中，所述至少一个第一调用接口被配置的执行权限大于所述至少一个第二调用接口被配置的执行权限；
通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果；
通过所述第二调用接口将所述验证结果返回至所述第一调用接口，以执行所述UEFI固件的启动过程。
2.根据权利要求1所述的方法，其特征在于，所述普通执行环境和所述可信执行环境下被配置有执行权限依次增大的特权级别：EL0、EL1、EL2、EL3；所述UEFI固件被配置运行在所述普通执行环境的EL2级别，所述至少一个第一调用接口被配置在所述UEFI固件中；所述至少一个第二调用接口被配置运行在所述可信执行环境的EL1级别。
3.根据权利要求1所述的方法，其特征在于，所述验证请求信息包括哈希计算请求；所述至少一个第一调用接口包括第一哈希接口；所述至少一个第二调用接口包括第二哈希接口；所述当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，包括：
通过所述第一哈希接口，将所述镜像文件的哈希计算请求传递给所述第二哈希接口；
所述通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果，包括：
通过所述第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果；
所述通过所述第二调用接口将所述验证结果返回至所述第一调用接口，包括：
通过所述第二哈希接口将所述哈希计算结果返回至所述第一哈希接口。
4.根据权利要求1所述的方法，其特征在于，所述验证请求信息包括验签请求；所述至少一个第一调用接口包括第一验签接口；所述至少一个第二调用接口包括第二验签接口；所述当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口包括：
通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口；
所述通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果，包括：
通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果；
所述通过所述第二调用接口将所述验证结果返回至所述第一调用接口，包括：
通过所述第二验签接口将所述验签结果返回至所述第一验签接口。
5.根据权利要求3所述的方法，其特征在于，所述哈希计算请求包括所述镜像文件、所述镜像文件的数据长度、以及第一加密调用指令；所述通过第二哈希接口接收所述哈希计算请求，并对所述镜像文件进行哈希计算，得到所述镜像文件的哈希计算结果，包括：
通过所述第二哈希接口从所述哈希计算请求中解析出所述镜像文件和所述镜像文件的数据长度、以及所述第一加密调用指令；
通过所述第一加密调用指令对所述镜像文件和所述镜像文件的数据长度进行处理，生成所述镜像文件的所述哈希计算结果。
6.根据权利要求4所述的方法，其特征在于，所述验签请求包括：所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度以及第二加密调用指令；所述通过所述第二验签接口接收所述验签请求，并对所述镜像文件进行验签，得到验签结果，包括：
通过所述第二验签接口从所述验证请求信息中解析出所述镜像文件的哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、以及所述签名的长度；
通过所述第二加密调用指令对所述哈希计算结果、所述哈希计算结果的长度、所述镜像文件的签名、所述签名的长度进行处理，生成所述镜像文件的验签结果。
7.根据权利要求4所述的方法，其特征在于，所述验签请求还包括：公钥、所述公钥的长度、初始化指令；在所述通过所述第一验签接口，将所述镜像文件的验签请求传递给所述第二验签接口之前，还包括：
通过所述初始化指令对所述公钥、所述公钥的长度进行处理，以初始化第二加密算法。
8.一种固件安全启动装置，其特征在于，所述装置应用于计算设备，所述计算设备搭载有普通执行环境和可信执行环境；所述普通执行环境下运行有UEFI固件，所述普通执行环境中设置有至少一个第一调用接口，所述可信执行环境中设置有至少一个第二调用接口；所述装置包括：
传递模块，用于当接收到对镜像文件的验证请求信息时，通过所述第一调用接口，将所述镜像文件的验证请求信息传递给所述第二调用接口，其中，所述至少一个第一调用接口被配置的执行权限大于所述至少一个第二调用接口被配置的执行权限；
验证模块，用于通过所述至少一个第二调用接口接收所述验证请求信息，并对所述镜像文件进行验证，得到验证结果；
返回模块，用于通过所述第二调用接口将所述验证结果返回至所述第一调用接口，以执行所述UEFI固件的启动过程。
9.一种计算设备，其特征在于，包括：
存储器，用以存储计算机程序；
处理器，用以执行所述计算机程序，以实现如权利要求1至8中任一项所述的方法。
10.一种非暂态计算设备可读存储介质， 其特征在于，包括：程序，当其藉由计算设备运行时，使得所述计算设备执行权利要求1至8中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210327791.3A CN114491565B (zh) | 2022-03-31 | 2022-03-31 | 固件安全启动方法、装置、计算设备和可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210327791.3A CN114491565B (zh) | 2022-03-31 | 2022-03-31 | 固件安全启动方法、装置、计算设备和可读存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114491565A true CN114491565A (zh) | 2022-05-13 |
| CN114491565B CN114491565B (zh) | 2022-07-05 |
Family
ID=81487958
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210327791.3A Active CN114491565B (zh) | 2022-03-31 | 2022-03-31 | 固件安全启动方法、装置、计算设备和可读存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114491565B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117131519A (zh) * | 2023-02-27 | 2023-11-28 | 荣耀终端有限公司 | 一种信息的保护方法及设备 |
Citations (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101350044A (zh) * | 2008-09-02 | 2009-01-21 | 中国科学院软件研究所 | 一种虚拟环境信任构建方法 |
| US20090327741A1 (en) * | 2008-06-30 | 2009-12-31 | Zimmer Vincent J | System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid) |
| CN103748594A (zh) * | 2011-07-29 | 2014-04-23 | 微软公司 | 针对arm*trustzonetm实现的基于固件的可信平台模块 |
| CN105022954A (zh) * | 2015-07-07 | 2015-11-04 | 中国人民解放军国防科学技术大学 | 飞腾cpu上三态操作系统安全内核服务动态运行方法 |
| CN105260663A (zh) * | 2015-09-15 | 2016-01-20 | 中国科学院信息工程研究所 | 一种基于TrustZone技术的安全存储服务系统及方法 |
| CN108399339A (zh) * | 2018-02-12 | 2018-08-14 | 广东为辰信息科技有限公司 | 一种基于安全芯片的可信启动方法 |
| CN109086100A (zh) * | 2018-07-26 | 2018-12-25 | 中国科学院信息工程研究所 | 一种高安全可信移动终端安全体系架构及安全服务方法 |
| CN109150811A (zh) * | 2017-06-27 | 2019-01-04 | 深圳市中兴微电子技术有限公司 | 一种实现可信会话的方法及装置、计算设备 |
| CN109714303A (zh) * | 2017-10-25 | 2019-05-03 | 阿里巴巴集团控股有限公司 | Bios启动方法及数据处理方法 |
| CN110730159A (zh) * | 2019-09-03 | 2020-01-24 | 东南大学 | 一种基于TrustZone的安全和可信混合系统启动方法 |
| US20200050798A1 (en) * | 2018-01-23 | 2020-02-13 | Amlogic (Shanghai) Co., Ltd. | Method for improving security of trusted application |
| CN111241548A (zh) * | 2020-01-07 | 2020-06-05 | 天津飞腾信息技术有限公司 | 计算机启动方法 |
| CN111353162A (zh) * | 2020-03-26 | 2020-06-30 | 中国人民解放军国防科技大学 | 基于TrustZone分核异步执行的主动可信计算方法及系统 |
| CN111538566A (zh) * | 2020-04-24 | 2020-08-14 | 咪咕文化科技有限公司 | 镜像文件处理方法、装置、系统、电子设备及存储介质 |
| CN112069506A (zh) * | 2020-09-16 | 2020-12-11 | 地平线(上海)人工智能技术有限公司 | 一种安全启动方法和装置 |
| CN112087303A (zh) * | 2020-09-15 | 2020-12-15 | 炬星科技（深圳）有限公司 | 一种证书预置和签发方法、机器人及服务端 |
| US20210019420A1 (en) * | 2020-09-25 | 2021-01-21 | Intel Corporation | Phased boot process to dynamically initialize devices in a verified environment |
| CN112257058A (zh) * | 2020-10-12 | 2021-01-22 | 麒麟软件有限公司 | 一种操作系统可信计算校验方法及系统 |
| CN112784280A (zh) * | 2021-01-12 | 2021-05-11 | 苏州浪潮智能科技有限公司 | 一种SoC芯片安全设计方法及硬件平台 |
| CN112818327A (zh) * | 2021-02-26 | 2021-05-18 | 中国人民解放军国防科技大学 | 基于TrustZone的用户级代码和数据安全可信保护方法及装置 |
| CN113239329A (zh) * | 2021-04-19 | 2021-08-10 | 南京大学 | 一种用于移动端应用程序的可信执行环境的实现系统 |
| CN113268447A (zh) * | 2021-06-10 | 2021-08-17 | 海光信息技术股份有限公司 | 计算机架构及其内的访问控制、数据交互及安全启动方法 |
| CN113591159A (zh) * | 2021-07-30 | 2021-11-02 | 支付宝(杭州)信息技术有限公司 | 一种可信度量方法和可信计算节点 |
| CN113703924A (zh) * | 2021-09-22 | 2021-11-26 | 上海交通大学 | 基于可信执行环境的安全虚拟机系统设计方法及系统 |
| CN113779652A (zh) * | 2020-06-09 | 2021-12-10 | 华为技术有限公司 | 数据完整性保护的方法和装置 |
| CN113806787A (zh) * | 2021-11-19 | 2021-12-17 | 苏州浪潮智能科技有限公司 | 一种arm平台自动解密的方法、装置、设备及可读介质 |
| CN113901473A (zh) * | 2021-09-10 | 2022-01-07 | 苏州浪潮智能科技有限公司 | 一种服务器安全启动的方法、装置、设备及可读介质 |
| CN113946375A (zh) * | 2021-10-19 | 2022-01-18 | 珠海全志科技股份有限公司 | 嵌入式系统快速安全启动方法、装置及电子设备 |
| CN114035842A (zh) * | 2022-01-07 | 2022-02-11 | 飞腾信息技术有限公司 | 固件配置方法、计算系统配置方法、计算装置以及设备 |
-
2022
- 2022-03-31 CN CN202210327791.3A patent/CN114491565B/zh active Active
Patent Citations (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090327741A1 (en) * | 2008-06-30 | 2009-12-31 | Zimmer Vincent J | System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid) |
| CN101350044A (zh) * | 2008-09-02 | 2009-01-21 | 中国科学院软件研究所 | 一种虚拟环境信任构建方法 |
| CN103748594A (zh) * | 2011-07-29 | 2014-04-23 | 微软公司 | 针对arm*trustzonetm实现的基于固件的可信平台模块 |
| CN105022954A (zh) * | 2015-07-07 | 2015-11-04 | 中国人民解放军国防科学技术大学 | 飞腾cpu上三态操作系统安全内核服务动态运行方法 |
| CN105260663A (zh) * | 2015-09-15 | 2016-01-20 | 中国科学院信息工程研究所 | 一种基于TrustZone技术的安全存储服务系统及方法 |
| CN109150811A (zh) * | 2017-06-27 | 2019-01-04 | 深圳市中兴微电子技术有限公司 | 一种实现可信会话的方法及装置、计算设备 |
| CN109714303A (zh) * | 2017-10-25 | 2019-05-03 | 阿里巴巴集团控股有限公司 | Bios启动方法及数据处理方法 |
| US20200050798A1 (en) * | 2018-01-23 | 2020-02-13 | Amlogic (Shanghai) Co., Ltd. | Method for improving security of trusted application |
| CN108399339A (zh) * | 2018-02-12 | 2018-08-14 | 广东为辰信息科技有限公司 | 一种基于安全芯片的可信启动方法 |
| CN109086100A (zh) * | 2018-07-26 | 2018-12-25 | 中国科学院信息工程研究所 | 一种高安全可信移动终端安全体系架构及安全服务方法 |
| CN110730159A (zh) * | 2019-09-03 | 2020-01-24 | 东南大学 | 一种基于TrustZone的安全和可信混合系统启动方法 |
| CN111241548A (zh) * | 2020-01-07 | 2020-06-05 | 天津飞腾信息技术有限公司 | 计算机启动方法 |
| CN111353162A (zh) * | 2020-03-26 | 2020-06-30 | 中国人民解放军国防科技大学 | 基于TrustZone分核异步执行的主动可信计算方法及系统 |
| CN111538566A (zh) * | 2020-04-24 | 2020-08-14 | 咪咕文化科技有限公司 | 镜像文件处理方法、装置、系统、电子设备及存储介质 |
| CN113779652A (zh) * | 2020-06-09 | 2021-12-10 | 华为技术有限公司 | 数据完整性保护的方法和装置 |
| CN112087303A (zh) * | 2020-09-15 | 2020-12-15 | 炬星科技（深圳）有限公司 | 一种证书预置和签发方法、机器人及服务端 |
| CN112069506A (zh) * | 2020-09-16 | 2020-12-11 | 地平线(上海)人工智能技术有限公司 | 一种安全启动方法和装置 |
| US20210019420A1 (en) * | 2020-09-25 | 2021-01-21 | Intel Corporation | Phased boot process to dynamically initialize devices in a verified environment |
| CN112257058A (zh) * | 2020-10-12 | 2021-01-22 | 麒麟软件有限公司 | 一种操作系统可信计算校验方法及系统 |
| CN112784280A (zh) * | 2021-01-12 | 2021-05-11 | 苏州浪潮智能科技有限公司 | 一种SoC芯片安全设计方法及硬件平台 |
| CN112818327A (zh) * | 2021-02-26 | 2021-05-18 | 中国人民解放军国防科技大学 | 基于TrustZone的用户级代码和数据安全可信保护方法及装置 |
| CN113239329A (zh) * | 2021-04-19 | 2021-08-10 | 南京大学 | 一种用于移动端应用程序的可信执行环境的实现系统 |
| CN113268447A (zh) * | 2021-06-10 | 2021-08-17 | 海光信息技术股份有限公司 | 计算机架构及其内的访问控制、数据交互及安全启动方法 |
| CN113591159A (zh) * | 2021-07-30 | 2021-11-02 | 支付宝(杭州)信息技术有限公司 | 一种可信度量方法和可信计算节点 |
| CN113901473A (zh) * | 2021-09-10 | 2022-01-07 | 苏州浪潮智能科技有限公司 | 一种服务器安全启动的方法、装置、设备及可读介质 |
| CN113703924A (zh) * | 2021-09-22 | 2021-11-26 | 上海交通大学 | 基于可信执行环境的安全虚拟机系统设计方法及系统 |
| CN113946375A (zh) * | 2021-10-19 | 2022-01-18 | 珠海全志科技股份有限公司 | 嵌入式系统快速安全启动方法、装置及电子设备 |
| CN113806787A (zh) * | 2021-11-19 | 2021-12-17 | 苏州浪潮智能科技有限公司 | 一种arm平台自动解密的方法、装置、设备及可读介质 |
| CN114035842A (zh) * | 2022-01-07 | 2022-02-11 | 飞腾信息技术有限公司 | 固件配置方法、计算系统配置方法、计算装置以及设备 |
Non-Patent Citations (4)
| Title |
|---|
| 冷冰 等: ""基于国产处理器的可信计算平台构建方法"", 《通信技术》 * |
| 尹超 等: ""一种基于TrustZone架构的引导时可信度量机制设计"", 《信息通信》 * |
| 范冠男等: "基于TrustZone的可信执行环境构建技术研究", 《信息网络安全》 * |
| 韩臻等: "基于可信计算技术的计算环境安全增强", 《网络安全技术与应用》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117131519A (zh) * | 2023-02-27 | 2023-11-28 | 荣耀终端有限公司 | 一种信息的保护方法及设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114491565B (zh) | 2022-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10931451B2 (en) | Securely recovering a computing device | |
| TWI598814B (zh) | 用於管理及診斷配備有統一可延伸韌體介面（ｕｅｆｉ）相容韌體的計算裝置之系統與方法 | |
| CN107533609B (zh) | 用于对系统中的多个可信执行环境进行控制的系统、设备和方法 | |
| US8789037B2 (en) | Compatible trust in a computing device | |
| JP5497171B2 (ja) | セキュア仮想マシンを提供するためのシステムおよび方法 | |
| CN109669734B (zh) | 用于启动设备的方法和装置 | |
| US8826405B2 (en) | Trusting an unverified code image in a computing device | |
| US8201239B2 (en) | Extensible pre-boot authentication | |
| US7865712B2 (en) | Method and apparatus for booting a processing system | |
| US20090327741A1 (en) | System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid) | |
| US11200300B2 (en) | Secure sharing of license data in computing systems | |
| CN107077567B (zh) | 标识计算设备上的安全边界 | |
| US11714895B2 (en) | Secure runtime systems and methods | |
| US10853086B2 (en) | Information handling systems and related methods for establishing trust between boot firmware and applications based on user physical presence verification | |
| US11288377B1 (en) | Virtual machine-based trusted execution environment | |
| US10229272B2 (en) | Identifying security boundaries on computing devices | |
| US8776248B2 (en) | Method and apparatus for booting a processing system | |
| CN114499892B (zh) | 固件启动方法、装置、计算机设备及可读存储介质 | |
| CN114491565B (zh) | 固件安全启动方法、装置、计算设备和可读存储介质 | |
| Sharma | Onboard credentials: Hardware assisted secure storage of credentials | |
| Quaresma | TrustZone Based Attestation in Secure Runtime Verification for Embedded Systems | |
| Perrotis | Development of cryptographic algorithms in the trusted execution environment |
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 |