全盘加密方法、系统运行方法和电子设备与流程

[0001]
本申请涉及加解密技术领域，具体而言，涉及一种全盘加密方法、系统运行方法和电子设备。


背景技术：

[0002]
在linux系统中，出于安全考虑，会对文件或者分区进行加密处理。但是如果想提高安全性能，需要进行全盘加密。相较于针对特定的某个文件进行加密的文件加密方式，全盘加密将会对整个系统内的数据进行保护，包括操作系统的核心数据。一旦经过全盘加密，如果未经授权，则无法获取系统硬盘内的数据。
[0003]
但是，对于全盘加密，需要从/boot目录中单独分出一个分区来放置内核以及解密的引导程序，且放置内核和引导程序的/boot分区不进行加密。因为如果对单独划分出来的/boot分区也进行加密，那么被加密的系统将无法进行引导启动。
[0004]
如果被加密的系统挂载的是无界面设备或无法接入外设以输入密码的设备，就需要实现在开机后由系统自动挂载被加密的分区并自动输入密码来进入系统中。
[0005]
在现有技术中，如果想要实现加密后的自启动，密码就需要存储在未加密区域中，然后由解密的引导程序来获取这个密码进行解密。但是不论密码是脚本还是文本，如果将这个自动输入密码的脚本或文本直接配置到未加密区域中，作为密码的脚本或文本都会被轻易找到，那么密码就会相当于是明文，这种情况下，被加密分区中的数据很容易被获取到。
[0006]
因此，现有处理方式下的自启动将无法保证安全性。


技术实现要素：

[0007]
本申请的目的在于提供一种全盘加密方法、系统运行方法和电子设备，能够改善现有技术中在自启动过程存在较大安全隐患的问题。
[0008]
第一方面，本申请实施例提供一种全盘加密方法，应用于第一设备，所述方法包括：
[0009]
获取封装有解密密钥以及指定硬件信息的引导程序，所述解密密钥用于在目标系统被加密后启动时，对所述目标系统中需要进行全盘解密的分区进行解密，所述指定硬件信息用于在所述目标系统被加密后启动时，对所述目标系统所挂载的设备进行设备验证；
[0010]
将所述引导程序安装在待加密的所述目标系统中；
[0011]
基于所述引导程序配置待加密的所述目标系统的启动流程；
[0012]
将所述目标系统中需要加密的分区确定为第一分区，以使第二设备根据所述解密密钥对应的加密密钥对所述第一分区进行加密。
[0013]
在上述方法中，由于在目标系统中安装了封装有用于自动解密的解密密钥以及用于进行设备验证的指定硬件信息的引导程序，在此情况下对目标系统的启动流程进行配置，并对配置完成的目标系统中需要进行加密的分区以解密密钥对应的加密密钥进行加
密，以此有利于在目标系统被加密后进行系统自启动时，自动通过引导程序中封装的指定硬件信息对目标系统挂载的设备进行设备验证、自动通过引导程序中封装的解密密钥对被加密的第一分区进行解密，以此可以在实现保护数据的同时实现自动挂载、自动启动，并且不需要用户通过外部设备向被加密的目标系统输入密码，可较好地适用于无界面设备或是其他无法接入外设且数据需要保护的设备上。上述方法可提升全盘加密自启动场景下的安全性。
[0014]
在可选的实施方式中，所述引导程序是经过代码加固和代码混淆的可执行程序。
[0015]
通过上述实现方式，有利于避免封装有密码的目标程序被反编译，通过对经过代码加固和代码混淆方式得到的引导程序进行安装，并配置目标系统的启动流程，可以提升全盘加密自启动场景下的安全性。
[0016]
在可选的实施方式中，所述基于所述引导程序配置待加密的所述目标系统的启动流程，包括：
[0017]
基于所述引导程序对所述目标系统进行分区配置，确定所述目标系统的分区映射关系；
[0018]
基于所述分区映射关系为所述目标系统生成子文件系统，并编译所述目标系统的内核，以使所述目标系统能够在被加密后启动时，通过所述子文件系统根据所述分区映射关系访问所述目标系统中需要进行解密的分区。
[0019]
通过上述实现方式，根据引导程序来配置系统启动流程，可以使得目标系统能够在被加密后启动时根据配置的启动流程以及分区映射关系来执行启动过程，以此访问需要进行解密的分区。
[0020]
在可选的实施方式中，所述基于所述引导程序对所述目标系统进行分区配置，确定所述目标系统的分区映射关系，包括：
[0021]
基于所述引导程序为所述目标系统生成加密映射文件；
[0022]
在所述第一分区与所述加密映射文件之间建立分区映射关系。
[0023]
通过上述实现方式，有利于快速确定系统在开机时应该挂载哪个分区、对哪个分区进行加密/解密以及与被加密的分区有关的映射关系。
[0024]
在可选的实施方式中，所述目标系统是linux系统，所述基于所述分区映射关系为所述目标系统生成子文件系统，并编译所述目标系统的内核，以使所述目标系统能够在被加密后启动时，通过所述子文件系统根据所述分区映射关系访问所述目标系统中需要进行解密的分区，包括：
[0025]
基于所述分区映射关系在所述目标系统中安装并配置dropbear工具，所述dropbear工具是基于ssh协议实现的远程连接工具；
[0026]
为所述目标系统生成包含所述dropbear工具和所述引导程序的子文件系统；
[0027]
编译所述目标系统的内核，以使所述目标系统能够在被加密后启动时，通过所述子文件系统调用所述dropbear工具和所述引导程序，根据所述分区映射关系访问所述第一分区。
[0028]
通过上述实现方式，可配置linux系统自启动时想要运行的内容、工具，可将自启动时想要运行的内容(例如引导程序、dropbear工具)打包到子文件系统中，有利于使得系统在进行自启动时并不直接挂载物理分区，而是根据分区映射关系进行挂载，基于引导程
序和dropbear工具以及预先配置的分区映射关系，有利于实现对于被加密的第一分区的安全访问。
[0029]
在可选的实施方式中，所述将所述目标系统中需要加密的分区确定为第一分区，以使第二设备根据所述解密密钥对应的加密密钥对所述第一分区进行加密，包括：
[0030]
将所述目标系统中需要加密的分区确定为第一分区，以使所述第二设备对所述第一分区进行数据备份；
[0031]
在所述数据备份完成后对所述第一分区进行格式化；
[0032]
在格式化完成后根据所述加密密钥对所述第一分区进行加密；
[0033]
在加密完成后基于所述数据备份的内容对所述第一分区进行数据恢复。
[0034]
通过上述实现方式，可以对目标系统中需要进行加密的分区进行加密，实现全盘加密。
[0035]
第二方面，本申请实施例提供一种系统运行方法，应用于第一设备，所述第一设备中包括通过前述第一方面所述的方法加密后得到的目标系统，所述目标系统包括第一分区和第二分区，所述第一分区是加密过的分区，所述第二分区是未加密的分区，所述第二分区中存储有用于对所述第一分区进行解密的引导程序；
[0036]
所述方法包括：
[0037]
在所述目标系统启动时，根据所述引导程序中封装的指定硬件信息对所述目标系统当前挂载的所述第一设备进行设备验证；
[0038]
在所述第一设备通过设备验证时，通过所述引导程序中封装的解密密钥对所述第一分区进行解密。
[0039]
通过上述方法，在目标系统的自启动过程中，可以通过存储在未加密分区(第二分区)中的引导程序基于预先封装的指定硬件信息对目标系统挂载的设备自动进行设备验证，并在设备验证通过的情况下，才通过引导程序中封装的解密密钥对加密过的第一分区进行解密，相较于现有技术，上述方法可以在全盘加密的自启动过程中隐藏密码，可将解密密钥以及用于设备验证的硬件信息隐藏在引导程序中，并且通过解密之前的设备验证步骤可以降低因被加密的系统载体(例如存储器)被物理移植而带来的安全隐患。因此，上述方法可以在实现保护数据的同时实现自动挂载、自动启动，并且不需要用户通过外部设备向被加密的系统输入密码，可在无需用户通过外部设备向被加密的系统输入密码、无需外部介质输入密码的情况下实现安全自启动，可提升全盘加密自启动场景下的安全性。
[0040]
在可选的实施方式中，所述目标系统中部署有子文件系统以及预先生成的加密映射文件，在根据所述引导程序中封装的指定硬件信息对所述目标系统当前挂载的所述第一设备进行设备验证之前，所述方法还包括：
[0041]
在所述目标系统启动时，访问所述目标系统中的子文件系统；
[0042]
通过所述子文件系统调用预先安装并配置好的dropbear工具，并通过所述dropbear工具根据所述加密映射文件以及预先设定的分区映射关系，访问所述加密映射文件对应的所述第一分区。
[0043]
通过上述实现方式，可以在系统自启动过程中快速确定需要挂载或访问的地址。
[0044]
在可选的实施方式中，所述方法还包括：
[0045]
在所述第一设备未通过设备验证时，结束对于所述引导程序的调用过程，使得所
述第一分区无法被解密访问。
[0046]
通过上述实现方式，可以在检测出当前的目标系统所挂载的设备不是引导程序中封装、绑定的指定硬件信息所对应的特定设备时，对第一分区中的内容进行较好保护。
[0047]
第三方面，本申请实施例提供一种电子设备，包括：
[0048]
存储介质；
[0049]
处理器；
[0050]
所述存储介质上存储有所述处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行前述第一方面所述的方法或前述第二方面所述的方法。
附图说明
[0051]
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
[0052]
图1为现有技术中的一种全盘加解密原理图。
[0053]
图2为本申请实施例提供的一种全盘加解密原理图。
[0054]
图3为本申请实施例提供的一种全盘加密方法的流程图。
[0055]
图4为本申请实施例提供的第一设备与第二设备在加密阶段的部分时期的一种关系示意图。
[0056]
图5为本申请实施例提供的第一设备与第二设备在加密阶段的部分时期的另一种关系示意图。
[0057]
图6为本申请实施例提供的另一种全盘加密方法的流程图。
[0058]
图7为本申请实施例提供的一种全盘加密方法的部分流程图。
[0059]
图8为本申请实施例提供的一种系统运行方法的流程图。
[0060]
图9为本申请实施例提供的一种系统运行方法的实施过程示意图。
[0061]
图10为本申请实施例提供的一种电子设备的功能结构框图。
具体实施方式
[0062]
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
[0063]
图1示出了现有技术中的一种全盘加解密原理图。
[0064]
如图1所示，在进行系统磁盘分区后，为了实现全盘加密，因此为系统的/boot目录单独分出一个分区(即/boot分区)来放置系统的内核以及解密的引导程序，并且放置内核和引导程序的/boot分区不进行加密，其中，“/boot”是操作系统在启动引导过程中使用的文件。
[0065]
在现有技术中，为了实现加密后的自启动，是将密码以脚本或文本的形式直接存储在该未加密的/boot分区中，相应的，在进行系统自启动时，通过该未加密的/boot分区中存储的引导程序获取直接存储在该/boot分区中的密码，并用这个密码对加密过的加密分区进行解密，从而得到加密分区中的内容，以此实现系统自启动。
[0066]
发明人经过研究发现，由于在现有技术中的方案中，出于自启动需求会将密码设
置在未加密分区中，但暴露在未加密分区中的密码无论是以脚本形式还是文本形式存在，都容易被轻易找到，因此现有技术的处理方式存在较大安全隐患。
[0067]
有鉴于此，发明人提出以下实施例，通过将全盘解密所需的密码封装在引导程序中(如图2所示)，并且将自启动时的解密过程与设备的硬件信息绑定，通过这样的原理对引导程序进行改进、安装，并且基于封装有密码和硬件信息的引导程序进行系统启动流程的配置，以此可以在系统自启动过程中基于设备验证结果和解密情况实现安全自启动。
[0068]
其中，在绑定硬件信息后，加密后被物理移植的系统将无法随意在其他设备下运行，封装有密码的程序在经过加固、混淆后可以避免被反编译，因此可以从多方面提升全盘加密自启动场景下的安全性。
[0069]
基于本申请实施例的提供的原理，可以在自动挂载、自启动场景下实现数据保护，并且不需要通过外部介质或交互界面来对系统的自启动过程输入一些密码，可较好地适用于无界面系统、无界面设备或其他无法接入外设且数据需要保护的设备环境。
[0070]
为了对目标系统进行数据保护，本申请实施例提供了一种全盘加密方法，为了能够对全盘加密后的目标系统进行安全自启动，本申请实施例还提供了一种系统运行方法。
[0071]
下面将对本申请实施例提供的全盘加密方法进行介绍。该全盘加密方法包括三个阶段：第一阶段，得到封装完毕的引导程序；第二阶段，配置待加密系统的启动流程；第三阶段，对配置完成的待加密系统中需要进行加密的分区进行加密，即，完成全盘加密。
[0072]
请参阅图3，图3为本申请实施例提供的一种全盘加密方法的流程图，该方法可应用于加密系统，加密系统可包括第一设备和第二设备，第一设备作为待加密设备(或称为被加密设备)，第一设备用于挂载目标系统(目标系统可视为第一设备的操作系统)，第二设备作为辅助设备，第二设备自身具有目标系统以外的系统，用于在目标系统被配置完成后对目标系统中需要加密的分区进行加密。
[0073]
在本申请实施例中，目标系统是linux系统，第一设备是基于linux系统运行的设备。第二设备可以是基于linux系统运行的设备，也可以是基于linux系统以外的其他操作系统运行的设备。
[0074]
如图3所示，该全盘加密方法包括：步骤s31-s34。s31-s34的内容可以由前述的第一设备实现，该全盘加密方法可以是一种基于dm-crypt加密技术实现的方法。
[0075]
s31：获取封装有解密密钥以及指定硬件信息的引导程序。
[0076]
其中，解密密钥用于在目标系统被加密后启动时，对目标系统中需要进行全盘解密的分区进行解密。指定硬件信息用于在目标系统被加密后启动时，对目标系统所挂载的设备进行设备验证。
[0077]
目标系统在未被加密前作为待加密系统，而在被加密后作为待解密系统(或称为被加密系统)。
[0078]
待加密系统对应的指定硬件信息是指该系统需要绑定的硬件信息，用于对系统所挂载的设备进行区分，指定硬件信息可以是经过授权同意后，被允许部署、允许运行该系统的合法设备的硬件信息。在本申请实施例中，指定硬件信息是第一设备对应的硬件信息，例如可以是第一设备的设备标识、处理器(例如central processing unit，cpu)、内存等信息，也可以是用于参与身份验证的特定设备参数，对此不作赘述。
[0079]
s32：将引导程序安装在待加密的目标系统中。
[0080]
s33：基于引导程序配置待加密的目标系统的启动流程。
[0081]
s34：将目标系统中需要加密的分区确定为第一分区，以使第二设备根据解密密钥对应的加密密钥对第一分区进行加密。
[0082]
可选地，加密密钥可以与封装在引导程序中的解密密钥相同。图2中的“加密分区”即为本申请实施例中的第一分区。
[0083]
在目标系统被加密后进行自启动的过程中，如果需要访问目标系统中被加密的第一分区的内容，需要通过引导程序对已经被加密的第一分区进行解密，当成功解密后，目标系统可成功启动并运行，当被加密的第一分区无法被解密访问时，目标系统无法实现有效启动和运行，即，无法继续访问被加密的目标系统中的第一分区，实现数据保护。
[0084]
关于上述s31，为了得到封装有解密密钥以及指定硬件信息的引导程序，可以通过第一设备以外的其他设备(例如前述的第二设备或第一设备、第二设备以外的第三设备等)生成封装有解密密钥以及指定硬件信息的引导程序，并将生成的引导程序提供给第一设备，以使第一设备得到封装有解密密钥以及指定硬件信息的引导程序。
[0085]
作为一种生成前述引导程序的实现方式，可以通过修改、编辑源代码的方式将想要为目标系统绑定的指定硬件信息以及用于对目标系统进行全盘解密的密码(即，解密密钥)封装在目标源代码中，然后对目标源代码进行编译(编辑、编译等过程可通过自动化脚本实现，可批量处理，处理量少的情况下也可以通过人为辅助修改的方式实现)，编译后生成的程序称为目标程序(目标程序是可执行程序)。
[0086]
其中，可通过修改cryptsetup的源代码的实现方式将解密密钥封装在目标源代码中。cryptsetup是一种用于与dm-crypt进行交互的命令行工具，本质上是一种可执行程序。
[0087]
目标程序或者对目标程序进行代码加固、代码混淆之后得到的可执行程序，可作为前述的引导程序，以此得到封装有解密密钥以及指定硬件信息的引导程序。
[0088]
由于计算机、工控机等处理设备无法直接执行以高级语言编写的源程序，因此需要通过编译过程翻译得到机器语言形式的可执行程序，以便计算机、工控机等处理设备(这些处理设备可成为第一设备)识别和执行。
[0089]
如果第一设备a的存储器a(例如第一设备a的硬盘)作为目标系统的存储载体，在一个实例中，如图4所示，第一设备a可以通过有线传输的方式接收其他设备发送的封装有解密密钥以及指定硬件信息的引导程序，例如第一设备a可以接收第二设备b提供的封装有解密密钥以及指定硬件信息的引导程序。
[0090]
在另一个实例中，如图5所示，可以将第一设备a的存储器a从第一设备a上取下并连接到其他设备上，然后通过其他设备向第一设备a的存储器a写入封装有解密密钥以及指定硬件信息的引导程序。例如可以将从第一设备a上取下的硬盘连接到第二设备b上(第二设备b本身有能够支持第二设备b启动、运行的操作系统，第二设备b的操作系统可视为存储在第二设备b的存储器b中)，然后通过第二设备b向第一设备a的移动硬盘写入前述的引导程序，然后将第一设备a的硬盘重新挂载到第一设备a上，以使第一设备a得到封装有解密密钥以及指定硬件信息的引导程序。
[0091]
在第一设备得到封装有解密密钥以及指定硬件信息的引导程序以后，可执行s32。
[0092]
关于上述s32，作为s32的一种实现方式，可以在第一设备上运行待加密的目标系统，并在待加密的目标系统中安装前述的引导程序。
[0093]
其中，安装在目标系统中的引导程序可以是经过代码加固和/或代码混淆的可执行程序。代码混淆、代码加固是两种独立的代码保护技术。
[0094]
代码混淆可提高代码阅读难度。代码混淆(code obfuscation)是指将程序的代码，转换成一种功能上等价的内容，所谓功能上的等价是指其在变换前、后功能相同或相近。示例性地代码混淆过程为：程序p经过混淆变换为p
’
，若p没有结束或错误结束，那么p
’
也不能结束或错误结束，而且p
’
应与p具有相同的输出结果。否则p
’
不是p的有效的混淆结果。普遍采用的代码混淆技术包括：布局混淆(layout obfuscation)、数据混淆(data obfuscation)、控制混淆(control obfuscation)和预防混淆(preventive obfuscation)。
[0095]
代码加固常用的加固方式是将代码数据包上传到选定的加固平台进行加固处理。本申请不对具体的代码混淆、代码加固方式以及处理顺序进行限制。
[0096]
通过在目标系统中安装封装经过代码加固、代码混淆的引导程序可以避免引导程序被反编译。通过对经过代码加固和代码混淆方式得到的引导程序进行安装，并配置目标系统的启动流程，可以提升全盘加密自启动场景下的安全性。代码加固、代码混淆的过程可以是提供引导程序的设备实现。
[0097]
在第一设备将得到的引导程序(前述的cryptsetup)安装在目标系统中以后，可执行s33的配置过程。
[0098]
关于上述s33，可包括两方面内容：根据前述的引导程序对目标系统进行分区映射配置和启动项配置。通过分区映射配置过程可以确定在目标系统被加密后开机启动时，应该挂载什么分区、对什么分区进行解密以及各分区之间的映射关系。通过启动项配置可以确定在目标系统被加密后开机启动时，调用哪些工具、程序或组件来执行系统启动流程。
[0099]
在启动流程的配置过程中，对目标系统的内核进行重新编译后，视为目标系统的启动流程配置过程结束。在配置结束时，可执行s34。
[0100]
关于s33的具体配置内容将在下文进行详细结束，此处不作赘述。
[0101]
关于上述s34，可以在配置过程结束时确定目标系统中需要加密的分区确定为第一分区，以使第二设备根据解密密钥对应的加密密钥对该第一分区进行加密，以此实现全盘加密。
[0102]
由于目标系统的文件系统本身无法对自己进行全盘加密，因此借助作为辅助设备的第二设备完成加密过程。
[0103]
在一个实例中，可以在s33之后将未加密的目标系统挂载到第二设备上，以通过第二设备获取加密密钥并采用加密密钥对该目标系统的第一分区进行加密。在本申请实施例中，对目标系统中需要进行加密的第一分区进行加密即可视为对目标系统进行全盘加密。
[0104]
需要说明的是，将目标系统挂载到用于进行辅助加密的第二设备上，是指在第二设备已有操作系统的情况下将目标系统的存储载体与第二设备进行关联，例如可将第一设备中专用于存储目标系统的存储器与第二设备连接，以使第二设备能够对目标系统中的第一分区进行加密。
[0105]
其中，通过第二设备对第一分区进行加密是指：通过第二设备在不解析访问引导程序的情况下获取与解密密钥对应的加密密钥，并用加密密钥对第一分区进行对称加密或非对称加密。第二设备获取加密密钥的过程以及加密的过程不用通过引导程序实现，只需要能够得到特定的密码来对分区进行加密即可。
[0106]
第二设备获取加密密码的方式有很多，例如可以在预先为第一设备的目标系统设置相互匹配的加密密钥、解密密钥的情况下，由第二设备通过查表、临时录入/导入等方式来得到与解密密钥对应的加密密钥。
[0107]
在本申请实施例中，在封装有解密密钥以及指定硬件信息的引导程序被成功安装并部署到目标系统中以后，可以用于引导被加密过的目标系统按照配置的启动流程进行自启动。
[0108]
在上述s31-s34的方法中，由于在目标系统中安装了封装有用于自动解密的解密密钥以及用于进行设备验证的指定硬件信息的引导程序，在此情况下对目标系统的启动流程进行配置，并对配置完成的目标系统中需要进行加密的分区以解密密钥对应的加密密钥进行加密，以此有利于在目标系统被加密后进行系统自启动时，自动通过引导程序中封装的指定硬件信息对目标系统挂载的设备进行设备验证、自动通过引导程序中封装的解密密钥对被加密的第一分区进行解密，以此可以在实现保护数据的同时实现自动挂载、自动启动，并且不需要用户通过外部设备向被加密的目标系统输入密码。
[0109]
当将解密密钥封装在cryptsetup的源代码中以后，可以使得cryptsetup这一可执行程序作为引导程序启动运行时，自动使用封装的解密密钥对被加密的第一分区进行解密，无需用户借助交互界面或外部设备在系统自启动过程中手动输入密码。
[0110]
当第一设备的硬件信息作为指定硬件信息被添加到cryptsetup的源代码中以后，可以使得cryptsetup这一可执行程序作为引导程序启动运行时，自动通过指定硬件信息对目标系统所挂载的设备先进行设备验证，先检查目标系统的虚拟文件系统中的硬件信息(如图2中的“proc”)，如果cryptsetup这一引导程序在目标系统被加密后启动时，检查到虚拟文件系统中当前存储的硬件信息与预先被封装在引导程序中的指定硬件信息不匹配，则不会继续通过预先封装的解密密钥对被加密的第一分区进行解密。因此，通过将硬件信息封装到引导程序中的处理方式，有利于在系统自启动过程中进行设备验证，有利于避免别人直接将封装有硬件信息和密码的引导程序包cryptsetup挪用到指定其他系统设备上运行(因为如果封装的指定硬件信息与实际挂载的设备无法匹配，则无法完成解密)，可提升数据安全性。
[0111]
因此，上述的方法可较好地适用于无界面设备或是其他无法接入外设且数据需要保护的设备上。上述全盘加密方法可提升全盘加密自启动场景下的安全性。
[0112]
其中，上述的虚拟文件系统中存储有内核运行状态、目标系统实际挂载的当前设备的硬件信息等内容。在目标系统上电时，该虚拟文件系统中的数据存储在随机存取存储器(random access memory，ram)中，而在断电时从该随机存取存储器中擦除。ram是与系统的cpu直接交换数据的内部存储器，作为临时数据存储介质。
[0113]
关于上述s31-s34的方法，由于在进行加密之前需要绑定设备的硬件信息，因此在需要对多个待加密设备分别进行全盘加密时，对于每个待加密设备需要分别通过上述s31-s34的方法为相应的待加密系统和相应的设备进行处理，以此避免各个待加密设备的系统所存储的指定硬件信息、解密密钥相同。
[0114]
下面将对前述s33的配置过程进行详细介绍。
[0115]
作为s33的一种实现方式，如图6所示，s33可以包括子步骤s331-s332。s331、s332可分别作为前述分区映射配置、启动项配置的实现内容。
[0116]
s331：基于引导程序对目标系统进行分区配置，确定目标系统的分区映射关系。
[0117]
其中，如图7所示，s331可以包括：s3311-s3312。
[0118]
s3311：基于引导程序为目标系统生成加密映射文件。
[0119]
s3311可以包括：为目标系统生成镜像文件，以及通过引导程序对该镜像文件进行加密，得到加密映射文件。
[0120]
s3312：在第一分区与加密映射文件之间建立分区映射关系。
[0121]
s3312可以包括：将前述的加密映射文件存储在指定的第一目录下，该第一目录是该目标系统中用于存储逻辑设备的目录；在该目标系统的配置文件目录中配置第一分区与该加密映射文件之间的分区映射关系。
[0122]
示例性地，以第一设备的待加密的linux系统作为目标系统，可以在前述的引导程序安装在待加密的linux系统中之后，基于该引导程序为该linux系统生成一个img文件，该img文件是一种镜像文件。然后通过安装完成的cryptsetup这一引导程序对该img文件进行加密，加密后生成一个映射文件，即加密映射文件。
[0123]
这里可以将该加密映射文件命名为crypt，并将该crypt文件存储在/dev/mapper目录下，即得到/dev/mapper/crypt。其中，该/dev/mapper目录即为指定的第一目录，该第一目录是目标系统中用于存储逻辑设备的目录。其中，/dev是目标系统的设备管理文件(设备管理目录)，在/dev中存储有多种设备的数据。
[0124]
然后可以修改/etc下的fstab(文件系统信息)和crypttab(cryptsetup配置信息)，以此可将第一分区映射到/dev/mapper/crypt这一文件目录下，实现对于第一分区与加密映射文件之间的映射关系配置过程。以此可以使得目标系统在启动时可以自动解密并挂载被加密的分区(例如第一分区、加密映射文件对应的逻辑分区)。
[0125]
其中，/etc是用于存放目标系统的各种配置文件的配置文件目录。fstab是该配置文件目录中的文件系统信息，在fstab中可配置与第一分区、加密映射文件有关的映射关系。crypttab中存储有与cryptsetup这一引导程序有关的配置选项。通过对fstab、crypttab进行配置，可以在系统自启动时通过cryptsetup基于配置的分区映射关系访问第一分区或与第一分区存在映射关系的其他分区。
[0126]
通过上述s3311-s3312的实现方式，有利于快速确定系统在开机时应该挂载什么分区、对什么分区进行加密/解密以及与被加密的分区有关的映射关系。
[0127]
在完成分区映射关系的配置过程之后，可执行s332。
[0128]
s332：基于分区映射关系为目标系统生成子文件系统，并编译目标系统的内核，以使目标系统能够在被加密后启动时，通过子文件系统根据分区映射关系访问目标系统中需要进行解密的分区。
[0129]
在本申请实施例中，s332可以包括：s3321-s3323。
[0130]
s3321：基于分区映射关系在目标系统中安装并配置dropbear工具。
[0131]
dropbear工具是基于ssh协议实现的远程连接工具。
[0132]
s3322：为目标系统生成包含dropbear工具和前述引导程序的子文件系统。
[0133]
该子文件系统是initramfs，是一个运行在内存中的轻量级文件系统。initramfs是在系统挂载根目录之前运行的。
[0134]
s3323：编译目标系统的内核，以使目标系统能够在被加密后启动时，通过子文件
系统调用dropbear工具和引导程序，根据分区映射关系访问第一分区。
[0135]
其中，通过在目标系统的系统启动目录中生成子文件系统，并在安装的引导程序、安装完成的dropbear工具以及子文件系统之间建立关联关系，并编译目标系统的内核，可以使得目标系统在被加密后进行自启动时，能够通过子文件系统调用引导程序和dropbear工具，基于配置文件目录中配置的分区映射关系访问第一分区。
[0136]
下面对s3321-s3323的过程进行详细介绍：
[0137]
在完成分区映射关系的配置过程以后，可以在待加密的linux系统中安装并配置dropbear工具。例如，可以在目标系统的配置文件目录中安装并配置dropbear(是一种ssh终端)，配置dropbear使得dropbear工具能够在目标系统启动时运行的initramfs文件系统中基于ssh协议实现对于分区的解密操作。其中，dropbear作为在initramfs这一轻量级文件系统中使用ssh协议“远程”连接到加密的分区(第一分区)的工具。
[0138]
在配置完dropbear工具以后，可以使用mkinitramfs这一工具在/boot这一系统启动目录中重新生成新的initramfs(即，子文件系统)。
[0139]
其中，mkinitramfs是用于生成initramfs这一子文件系统的命令行工具。在采用mkinitramfs生成新的initramfs之后，在这之前修改、编译完的cryptsetup(引导程序)和dropbear工具被打包放进initramfs中。通过这样的配置方式，可以在目标系统开机时启动initramfs，并通过initramfs调用cryptsetup(即，引导程序)和dropbear工具对被加密的第一分区进行解密。
[0140]
需要说明的是，基于本申请实施例提供的原理生成initramfs这一子文件系统后，被加密的目标系统在开机启动时会先进入、访问initramfs这一子文件系统，而负责解密的cryptsetup和dropbear工具都是在这个文件系统中，传统系统中是没有配置initramfs的，或者是传统的initramfs中没有cryptsetup和dropbear，因此，本申请实施例特意生成了一个新的initramfs作为被加密的目标系统自启动时最先访问的子文件系统。在该子文件系统中，可将目标系统自启动时想要运行的内容打包进去。
[0141]
在生成子文件系统(initramfs)以后，可修改并编译待加密的linux系统的内核。在完成内核编译后，可以使得被加密的linux系统在自启动时并不直接挂载物理分区，而是挂载/dev/mapper/crypt这个映射得到的逻辑分区，并在被加密的linux系统启动时运行新生成的initramfs(即前述步骤中生成的子文件系统)，基于子文件系统的运行、调用结果确定是否可以继续访问被加密的第一分区。
[0142]
通过上述s3321-s3323的实现方式，可配置linux系统自启动时想要运行的内容、工具，可将自启动时想要运行的内容(例如引导程序、dropbear工具)打包到子文件系统中，有利于使得系统在进行自启动时并不直接挂载物理分区，而是根据分区映射关系进行挂载，基于生成的子文件系统调用的引导程序和dropbear工具以及预先配置的分区映射关系，实现对于被加密的第一分区的安全访问。
[0143]
通过上述与s331-s332有关的配置实现方式，根据引导程序来配置系统启动流程，可以使得目标系统能够在被加密后启动时根据配置的启动流程以及分区映射关系来执行启动过程，以此访问需要进行解密的分区。
[0144]
在完成目标系统的启动流程配置之后可执行的加密过程(对应前述s34)可以包括：将目标系统中需要加密的分区确定为第一分区，以使第二设备对第一分区进行数据备
份。在数据备份完成后对第一分区进行格式化。在格式化完成后根据加密密钥对第一分区进行加密。在加密完成后基于数据备份的内容对第一分区进行数据恢复。
[0145]
其中，可以在完成上述的配置流程之后，完成内核编译过程以后，将第一设备断电。然后将第一设备中待加密的linux系统挂载到用于辅助加密的第二设备上，例如，可以通过将部署有目标系统的系统文件(包含前述的各种目录、文件)的存储载体挂载到第二设备上(可采用类似图5的设备关系来实现加密操作)，以通过第二设备对待加密的系统中需要进行加密的第一分区以前述的加密密钥进行加密。其中，在执行加密操作之前，先对将要加密的分区进行全部数据备份，然后对将要加密的分区进行格式化，格式化完成后以前述的加密密钥对要加密的第一分区进行加密操作，在加密完成以后，基于数据备份的内容对被格式化过的第一分区进行数据恢复。至此，对于目标系统的全盘加密操作结束。
[0146]
在本申请实施例中，部署目标系统的存储载体可以是实体存储器，也可以是虚拟存储器，例如可以是tf卡、emmc(嵌入式多媒体控制器的缩写)、或是准备批量烧录的镜像文件等的存储介质。
[0147]
通过上述的实现方式，可以对目标系统中需要进行加密的分区进行加密，实现全盘加密。
[0148]
可选的，为上述的第一设备的目标系统提供引导程序和对第一分区进行加密的设备可以是不同的设备，例如提供引导程序的设备可以是第三设备(与第二设备同理，第三设备本身具有其操作系统，不需要依赖目标系统来进行设备启动或运行)。作为被加密设备的第一设备是用于根据得到的引导程序完成目标系统的配置过程，以使得目标系统在配置完成并被加密后能够在第一设备上实现安全自启动、快速自启动，同时可避免第一设备以外的其他设备来运行目标系统。第一设备可以是无法提供交互界面的设备。
[0149]
基于同一发明构思，为了实现自启动场景下的全盘解密安全性，本申请实施例提供一种系统运行方法，下面将对本申请实施例提供的系统运行方法进行介绍。
[0150]
请参阅图8，图8为本申请实施例提供的一种系统运行方法的流程图。该方法可作为解密阶段的方法内容，用于通过加密阶段使用的封装有硬件信息和解密密钥的引导程序对通过前述的方法加密过的目标系统进行解密，以此实现全盘解密。
[0151]
该系统运行方法方法可应用于被加密设备，被加密设备中部署有通过前述的全盘加密方法加密后得到的目标系统。该被加密设备可以是前述的第一设备。
[0152]
该目标系统包括第一分区和第二分区，第一分区是加密过的分区，第二分区是未加密的分区，第二分区中存储有用于对第一分区进行解密的引导程序。第二分区中还存储有该目标系统的内核。
[0153]
其中，该系统运行方法也可以视为应用于被加密的目标系统的方法。
[0154]
如图8所示，该系统运行方法可包括：s41-s42。
[0155]
s41：在目标系统启动时，根据引导程序中封装的指定硬件信息对目标系统当前挂载的第一设备进行设备验证。
[0156]
s42：在第一设备通过设备验证时，通过引导程序中封装的解密密钥对第一分区进行解密。
[0157]
其中，在第一设备未通过设备验证时，结束对于引导程序的调用过程，使得第一分区无法被解密访问。理论上如果目标系统的引导程序中封装的指定硬件信息与该目标系统
当前挂载的第一设备匹配，第一设备可通过设备验证，而如果该目标系统的引导程序中封装的指定硬件信息与该目标系统当前挂载的设备不匹配，则该目标系统当前挂载的设备无法通过验证。
[0158]
通过上述的系统运行方法，在目标系统的自启动过程中，可以通过存储在未加密分区(第二分区)中的引导程序基于预先封装的指定硬件信息对目标系统挂载的设备自动进行设备验证，并在设备验证通过的情况下，才通过引导程序中封装的解密密钥对加密过的第一分区进行解密，相较于现有技术，上述方法可以在全盘加密的自启动过程中隐藏密码，可将解密密钥以及用于设备验证的硬件信息隐藏在引导程序中，并且通过解密之前的设备验证步骤可以降低因被加密的系统载体(例如存储器)被物理移植而带来的安全隐患。因此，上述的方法可以在实现保护数据的同时实现自动挂载、自动启动，并且不需要用户通过外部设备向被加密的系统输入密码，可在无需用户通过外部设备向被加密的系统输入密码、无需外部介质输入密码的情况下实现安全自启动，可提升全盘加密自启动场景下的安全性。
[0159]
基于上述的方法可以在检测出当前的目标系统所挂载的设备不是引导程序中封装、绑定的指定硬件信息所对应的特定设备时，对第一分区中的内容进行较好保护，可避免目标系统中被全盘加密的内容因物理移植手段而被随意解密访问。
[0160]
可选的，在目标系统中部署有子文件系统以及预先生成的加密映射文件的情况下，在根据引导程序中封装的指定硬件信息对目标系统当前挂载的第一设备进行设备验证之前，该系统运行方法还可包括：在目标系统启动时，访问目标系统中的子文件系统。通过子文件系统调用预先安装并配置好的dropbear工具，并通过dropbear工具根据加密映射文件以及预先设定的分区映射关系，访问加密映射文件对应的第一分区。
[0161]
通过上述的实现方式，可以在系统自启动过程中快速确定需要挂载或访问的地址。
[0162]
该系统运行方法的实施过程如图9所示，在目标系统启动时，可进入、访问在加密阶段生成的子文件系统(initramfs系统)。然后通过initramfs系统调用dropbear工具来准备访问加密过的分区，并调用封装有指定硬件信息和解密密钥的引导程序(cryptsetup)，启动cryptsetup来对目标系统当前挂载的设备进行设备验证。在目标系统(被加密的linux系统)当前挂载的设备通过设备验证的情况下，用cryptsetup中封装的解密密钥对第一分区进行解密，实现全盘解密，成功进入目标系统的主系统，目标系统成功启动。而在目标系统(被加密的linux系统)当前挂载的设备未通过设备验证的情况下，结束对于cryptsetup的调用过程，cryptsetup程序跳出，无法对第一分区解密，目标系统启动失败，以此避免设备不匹配的情况下启动目标系统的主系统，可以提升系统自启动场景下的安全性。
[0163]
基于同一发明构思，如图10所示，本申请实施例还提供一种电子设备500。该电子设备500包括：存储器501、处理器502和通信组件403。该电子设备500可用于实现前述的方法。该电子设备用于实现前述的全盘加密方法或系统运行方法。
[0164]
通信组件503包括通信总线，通信总线用于实现电子设备500中各个组件之间的直接或间接连接。
[0165]
存储器501是一种存储介质，可以是高速ram存储器，也可以是非易失性存储器(non-volatile memory)。
[0166]
处理器502具有运算处理能力，可以是但不限于中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等通用处理器；还可以是专用处理器或者其他可编程逻辑器件搭建的处理器。处理器502可以实现本申请实施例提供的方法、步骤及逻辑框图。
[0167]
存储器501上存储有处理器502可执行的计算机程序，处理器502用于执行存储器501中存储的计算机程序，从而实现前述实施例提供的各方法中的部分或全部步骤。
[0168]
需要说明的是，图10所示结构仅作为示意，具体应用时可以有更多的组件，或具有不同于图10所示的其他配置方式。
[0169]
在本申请所提供的实施例中，应该理解到，所揭露实施例，可以通过其它的方式实现。以上所描述的实施例仅仅是示意性的，另外，作为分离部件说明的组件可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0170]
需要说明的是，上述方法的功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以用软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备执行本申请各个实施例方法的全部或部分步骤。
[0171]
在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
[0172]
以上仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。