CN112270002B

CN112270002B - Full-disc encryption method, system operation method and electronic equipment

Info

Publication number: CN112270002B
Application number: CN202011159166.XA
Authority: CN
Inventors: 姚威; 耿兆强; 于林; 王伟
Original assignee: Beijing Zhizhangyi Technology Co ltd
Current assignee: Beijing Zhizhangyi Technology Co ltd
Priority date: 2020-10-26
Filing date: 2020-10-26
Publication date: 2024-03-22
Anticipated expiration: 2040-10-26
Also published as: CN112270002A

Abstract

The embodiment of the application provides a full-disc encryption method, a system operation method and electronic equipment, wherein the full-disc encryption method is applied to first equipment, and the method comprises the following steps: the method comprises the steps of obtaining a guide program encapsulated with a decryption key and appointed hardware information, wherein the decryption key is used for decrypting a partition needing full-disc decryption in a target system when the target system is started after being encrypted, and the appointed hardware information is used for carrying out equipment verification on equipment mounted on the target system when the target system is started after being encrypted; installing the bootstrap program in the target system to be encrypted; configuring a starting flow of the target system to be encrypted based on the bootstrap program; and determining the partition needing encryption in the target system as a first partition, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key. Therefore, the safety of the self-starting process of the equipment can be improved.

Description

Full-disc encryption method, system operation method and electronic equipment

Technical Field

The application relates to the technical field of encryption and decryption, in particular to a full-disc encryption method, a system operation method and electronic equipment.

Background

In Linux systems, files or partitions are encrypted for security. But if the security is to be improved, full disc encryption is required. Compared with a file encryption mode for encrypting a specific certain file, the whole disk encryption protects data in the whole system, including core data of an operating system. Once encrypted in full disk, the data in the system hard disk cannot be obtained if unauthorized.

However, for full disk encryption, one partition needs to be separately split from the/boot directory to place the kernel and the decrypted boot, and the/boot partition where the kernel and the boot are placed is not encrypted. Because if the separately partitioned/boot partition is also encrypted, the encrypted system will not be bootable.

If the encrypted system is mounted with no interface device or a device which can not be accessed to a peripheral to input a password, the encrypted partition needs to be automatically mounted by the system after the system is started and the password is automatically input to enter the system.

In the prior art, if it is desired to achieve encrypted self-boot, the password needs to be stored in an unencrypted area, and then the decrypted boot program obtains the password for decryption. However, whether the password is script or text, if the script or text for automatically inputting the password is directly configured in the unencrypted area, the script or text as the password can be easily found, and the password can be equivalent to plaintext, in which case the data in the encrypted partition can be easily obtained.

Therefore, the self-starting in the existing processing mode cannot guarantee the safety.

Disclosure of Invention

The purpose of the application is to provide a full-disc encryption method, a system operation method and electronic equipment, which can solve the problem that in the prior art, a large potential safety hazard exists in the self-starting process.

In a first aspect, an embodiment of the present application provides a full disc encryption method, applied to a first device, where the method includes:

the method comprises the steps of obtaining a guide program encapsulated with a decryption key and appointed hardware information, wherein the decryption key is used for decrypting a partition needing full-disc decryption in a target system when the target system is started after being encrypted, and the appointed hardware information is used for carrying out equipment verification on equipment mounted on the target system when the target system is started after being encrypted;

installing the bootstrap program in the target system to be encrypted;

configuring a starting flow of the target system to be encrypted based on the bootstrap program;

and determining the partition needing encryption in the target system as a first partition, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key.

In the method, since the bootstrap program which encapsulates the decryption key used for automatic decryption and the designated hardware information used for device verification is installed in the target system, under the condition, the starting flow of the target system is configured, and the encryption key corresponding to the decryption key is encrypted for the partition which needs to be encrypted in the configured target system, so that the method is favorable for device verification of the device mounted on the target system by the designated hardware information encapsulated in the bootstrap program and decryption of the encrypted first partition by the decryption key encapsulated in the bootstrap program when the target system is automatically started after being encrypted, the method can realize automatic mounting and automatic starting while protecting data, does not need users to input passwords to the encrypted target system by external devices, and can be well applied to interface-free devices or other devices which cannot be accessed to peripheral devices and need data protection. The method can improve the safety of the full-disc encryption self-starting scene.

In an alternative embodiment, the bootstrap program is an executable program that is subject to code instrumentation and code obfuscation.

By the implementation mode, the target program with the password packaged is prevented from being decompiled, and the security in the full-disc encryption self-starting scene can be improved by installing the guide program obtained through the code reinforcement and the code confusion mode and configuring the starting flow of the target system.

In an optional embodiment, the configuring, based on the bootstrap program, a start-up procedure of the target system to be encrypted includes:

partitioning configuration is carried out on the target system based on the bootstrap program, and a partition mapping relation of the target system is determined;

generating a sub-file system for the target system based on the partition mapping relation, and compiling a kernel of the target system so that the target system can access a partition needing decryption in the target system through the sub-file system according to the partition mapping relation when the target system is started after being encrypted.

By the implementation manner, the system starting flow is configured according to the bootstrap program, so that the target system can execute the starting process according to the configured starting flow and the partition mapping relation when being started after being encrypted, and the partition needing decryption can be accessed.

In an optional embodiment, the partition configuration of the target system based on the bootstrap program, and determining the partition mapping relationship of the target system includes:

generating an encryption mapping file for the target system based on the bootstrap program;

and establishing a partition mapping relation between the first partition and the encryption mapping file.

By the implementation manner, the method and the system are beneficial to quickly determining which partition should be mounted, encrypting/decrypting which partition and mapping relation related to the encrypted partition when the system is started.

In an optional embodiment, the target system is a Linux system, the generating a sub-file system for the target system based on the partition mapping relationship, and compiling a kernel of the target system, so that when the target system is started after being encrypted, the target system can access, according to the partition mapping relationship, a partition that needs to be decrypted in the target system through the sub-file system, including:

installing and configuring a dropoff tool in the target system based on the partition mapping relation, wherein the dropoff tool is a remote connection tool realized based on an SSH protocol;

generating a sub-file system containing the dropoff tool and the bootstrap program for the target system;

And compiling a kernel of the target system so that the target system can call the dropdear tool and the bootstrap program through the sub-file system when being started after being encrypted, and accessing the first partition according to the partition mapping relation.

Through the implementation manner, the content and the tool which are required to be operated when the Linux system is self-started can be configured, the content (such as a bootstrap program and a dropdear tool) which are required to be operated when the Linux system is self-started can be packaged into the sub-file system, so that the system is not directly mounted with a physical partition when the Linux system is self-started, but is mounted according to the partition mapping relation, and the secure access to the encrypted first partition is realized based on the bootstrap program, the dropdear tool and the pre-configured partition mapping relation.

In an optional embodiment, the determining the partition to be encrypted in the target system as the first partition, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key, includes:

determining a partition needing encryption in the target system as a first partition, so that the second equipment performs data backup on the first partition;

Formatting the first partition after the data backup is completed;

encrypting the first partition according to the encryption key after formatting is completed;

and after encryption is completed, carrying out data recovery on the first partition based on the content of the data backup.

Through the implementation mode, the partition needing to be encrypted in the target system can be encrypted, and full-disc encryption is achieved.

In a second aspect, an embodiment of the present application provides a system operation method, which is applied to a first device, where the first device includes a target system obtained by encrypting by the method in the first aspect, where the target system includes a first partition and a second partition, where the first partition is an encrypted partition, the second partition is an unencrypted partition, and a bootstrap program for decrypting the first partition is stored in the second partition;

the method comprises the following steps:

when the target system is started, performing equipment verification on the first equipment currently mounted on the target system according to the appointed hardware information packaged in the bootstrap;

and when the first device passes the device verification, decrypting the first partition through a decryption key encapsulated in the bootstrap program.

By the method, in the process of self-starting of the target system, equipment can be automatically verified on the equipment mounted on the target system based on the pre-packaged appointed hardware information through the bootstrap program stored in the unencrypted partition (the second partition), and the encrypted first partition is decrypted through the decryption key packaged in the bootstrap program only when the equipment verification is passed. Therefore, the method can realize automatic mounting and automatic starting while protecting data, does not need a user to input a password to an encrypted system through external equipment, can realize safe self-starting under the condition that the user does not need to input the password to the encrypted system through the external equipment and does not need to input the password through external media, and can improve the safety in a full-disc encryption self-starting scene.

In an optional implementation manner, a sub-file system and a pre-generated encryption mapping file are deployed in the target system, and before performing device verification on the first device currently mounted on the target system according to specified hardware information encapsulated in the bootstrap, the method further includes:

when the target system is started, accessing a sub-file system in the target system;

calling a pre-installed and configured dropoff tool through the sub-file system, and accessing the first partition corresponding to the encryption mapping file through the dropoff tool according to the encryption mapping file and a preset partition mapping relation.

Through the implementation manner, the address to be mounted or accessed can be rapidly determined in the system self-starting process.

In an alternative embodiment, the method further comprises:

and ending the calling process of the bootstrap program when the first device fails device verification, so that the first partition cannot be decrypted and accessed.

By the implementation manner, when the fact that the device mounted on the current target system is not the specific device corresponding to the packaged and bound specified hardware information in the bootstrap program is detected, the content in the first partition can be well protected.

In a third aspect, an embodiment of the present application provides an electronic device, including:

a storage medium;

a processor;

the storage medium has stored thereon a computer program executable by the processor, which when executed by the processor performs the method of the first aspect or the method of the second aspect.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of encryption and decryption of a full disc in the prior art.

Fig. 2 is a schematic diagram of encryption and decryption of a full disc according to an embodiment of the present application.

Fig. 3 is a flowchart of a full disc encryption method according to an embodiment of the present application.

Fig. 4 is a schematic diagram of a relationship between a first device and a second device in a partial period of an encryption stage according to an embodiment of the present application.

Fig. 5 is another schematic diagram of a relationship between a first device and a second device in a partial period of an encryption stage according to an embodiment of the present application.

Fig. 6 is a flowchart of another full disc encryption method according to an embodiment of the present application.

Fig. 7 is a partial flowchart of a full disc encryption method according to an embodiment of the present application.

Fig. 8 is a flowchart of a system operation method provided in an embodiment of the present application.

Fig. 9 is a schematic diagram of an implementation process of a system operation method according to an embodiment of the present application.

Fig. 10 is a functional block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

Fig. 1 shows a schematic diagram of encryption and decryption of a full disc in the prior art.

After the system disk partition is performed, as shown in fig. 1, in order to implement full disk encryption, a partition (i.e., a boot partition) is separately separated for the system/boot directory to place the kernel and the decrypted boot program of the system, and the kernel and the boot program are placed in the boot partition without encryption, where "/boot" is a file used by the operating system in the boot process.

In the prior art, in order to realize the encrypted self-starting, a password is directly stored in an unencrypted/boot partition in the form of a script or text, and correspondingly, when the system is self-started, the password directly stored in the unencrypted/boot partition is acquired through a bootstrap program stored in the unencrypted/boot partition, and the encrypted encryption partition is decrypted by using the password, so that the content in the encryption partition is obtained, and the system self-starting is realized.

The inventor finds that, in the scheme in the prior art, the password is set in the unencrypted partition due to the self-starting requirement, but the password exposed in the unencrypted partition is easy to find whether in script form or text form, so that the processing mode in the prior art has a great potential safety hazard.

In view of this, the inventors propose an embodiment in which secure self-starting can be achieved based on the device authentication result and decryption conditions in the system self-starting process by encapsulating a password required for full disc decryption in a boot program (as shown in fig. 2), binding the decryption process at the self-starting with the hardware information of the device, modifying and installing the boot program by such a principle, and performing configuration of the system start-up flow based on the boot program encapsulated with the password and the hardware information.

After binding the hardware information, the encrypted system which is physically transplanted cannot be operated under other devices at will, and the program packaged with the password can be prevented from being decompiled after being reinforced and mixed, so that the security of the whole-disk encryption self-starting scene can be improved from multiple aspects.

Based on the principle provided by the embodiment of the application, the data protection can be realized under the automatic mounting and self-starting scene, and some passwords are not required to be input into the self-starting process of the system through an external medium or an interactive interface, so that the method and the device are better applicable to the environments of interface-free systems, interface-free devices or other devices which cannot be accessed to peripheral equipment and data needs to be protected.

In order to protect data of a target system, the embodiment of the application provides a full-disk encryption method, and in order to enable safe self-starting of the target system after full-disk encryption, the embodiment of the application also provides a system operation method.

The full disc encryption method provided in the embodiment of the present application will be described below. The full-disc encryption method comprises three stages: the first stage, obtaining a packaged bootstrap program; the second stage, configuring a starting flow of a system to be encrypted; and thirdly, encrypting the partition which needs to be encrypted in the configured system to be encrypted, namely, completing the full-disc encryption.

Referring to fig. 3, fig. 3 is a flowchart of a full disc encryption method provided in an embodiment of the present application, where the method may be applied to an encryption system, and the encryption system may include a first device and a second device, where the first device is used as a device to be encrypted (or referred to as an encrypted device), the first device is used for mounting a target system (the target system may be regarded as an operating system of the first device), the second device is used as an auxiliary device, and the second device has a system other than the target system, and is used for encrypting a partition that needs to be encrypted in the target system after the target system is configured.

In the embodiment of the application, the target system is a Linux system, and the first device is a device running based on the Linux system. The second device may be a device running based on a Linux system, or may be a device running based on an operating system other than the Linux system.

As shown in fig. 3, the full disc encryption method includes: steps S31-S34. The contents of S31-S34 may be implemented by the aforementioned first device, and the full disc encryption method may be a method implemented based on dm-crypto encryption technology.

S31: a boot program encapsulated with a decryption key and specified hardware information is acquired.

The decryption key is used for decrypting the partition needing to be subjected to full-disc decryption in the target system when the target system is started after being encrypted. The appointed hardware information is used for carrying out equipment verification on equipment mounted on the target system when the target system is started after being encrypted.

The target system acts as a system to be encrypted before being encrypted, and acts as a system to be decrypted after being encrypted (or referred to as an encrypted system).

The specified hardware information corresponding to the system to be encrypted refers to the hardware information which needs to be bound by the system and is used for distinguishing the equipment mounted by the system, and the specified hardware information can be the hardware information of legal equipment which is allowed to be deployed and allowed to run the system after authorized approval. In this embodiment of the present application, the specified hardware information is hardware information corresponding to the first device, for example, may be information such as a device identifier, a processor (for example, central Processing Unit, CPU), a memory, etc. of the first device, or may be a specific device parameter for participating in authentication, which is not described herein.

S32: the boot program is installed in the target system to be encrypted.

S33: and configuring a starting flow of the target system to be encrypted based on the bootstrap program.

S34: and determining the partition needing encryption in the target system as a first partition, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key.

Alternatively, the encryption key may be the same as the decryption key encapsulated in the boot program. The "encryption partition" in fig. 2 is the first partition in the embodiment of the present application.

In the process of self-starting after the target system is encrypted, if the content of the encrypted first partition in the target system needs to be accessed, the encrypted first partition needs to be decrypted through a bootstrap program, when the encrypted first partition is successfully decrypted, the target system can be successfully started and operated, and when the encrypted first partition cannot be decrypted and accessed, the target system cannot be effectively started and operated, namely, the encrypted first partition in the target system cannot be continuously accessed, so that data protection is realized.

In S31, in order to obtain the boot program in which the decryption key and the specific hardware information are packaged, the boot program in which the decryption key and the specific hardware information are packaged may be generated by a device other than the first device (for example, the second device, the first device, the third device other than the second device, or the like), and the generated boot program may be provided to the first device so that the first device obtains the boot program in which the decryption key and the specific hardware information are packaged.

As an implementation manner of generating the aforementioned boot program, the specified hardware information to be bound for the target system and the password (i.e., decryption key) for performing full-disc decryption on the target system may be encapsulated in the target source code by modifying and editing the source code, and then the target source code may be compiled (the processes such as editing and compiling may be implemented by an automated script, may be batch-processed, and may be implemented by a manner of manual assistance modification in a case of a small processing amount), and the program generated after compiling is referred to as the target program (the target program is an executable program).

Wherein the decryption key may be encapsulated in the target source code by modifying the implementation of the source code of the cryptoptsetup. Cryptsetsetup is a command line tool for interacting with dm-crypt, essentially an executable program.

The target program or an executable program obtained by performing code reinforcement and code confusion on the target program can be used as the bootstrap program, so that the bootstrap program packaged with the decryption key and the specified hardware information can be obtained.

Since a processing device such as a computer, an industrial personal computer, or the like cannot directly execute a source program written in a high-level language, an executable program in a machine language form needs to be translated through a compiling process in order for the processing device such as a computer, an industrial personal computer, or the like (these processing devices may become first devices) to recognize and execute.

If the memory a of the first device a (e.g., the hard disk of the first device a) is used as a storage carrier of the target system, in one example, as shown in fig. 4, the first device a may receive, by using a wired transmission manner, a boot program encapsulated with a decryption key and specified hardware information sent by another device, for example, the first device a may receive the boot program provided by the second device B and encapsulated with the decryption key and specified hardware information.

In another example, as shown in fig. 5, the memory a of the first device a may be removed from the first device a and connected to other devices, and then a boot program encapsulating the decryption key and the specified hardware information may be written to the memory a of the first device a through the other devices. For example, a hard disk removed from the first device a may be connected to the second device B (the second device B itself has an operating system capable of supporting the second device B to start and run, and the operating system of the second device B may be regarded as being stored in the memory B of the second device B), then the foregoing boot program is written to the mobile hard disk of the first device a through the second device B, and then the hard disk of the first device a is re-mounted on the first device a, so that the first device a obtains the boot program encapsulated with the decryption key and the specified hardware information.

After the first device obtains the boot program encapsulated with the decryption key and the specified hardware information, S32 may be performed.

Regarding S32 described above, as one implementation of S32, the target system to be encrypted may be run on the first device, and the aforementioned boot program may be installed in the target system to be encrypted.

The boot program installed in the target system may be an executable program that is code hardened and/or code obfuscated. Code obfuscation, code instrumentation are two independent code protection techniques.

Code confusion may increase the difficulty of code reading. Code obfuscation (code obfuscation) refers to the conversion of the code of a program into a functionally equivalent content, where functionally equivalent means that the functions are the same or similar before and after transformation. Exemplary code obfuscation procedures are: the program P is subjected to confusion transformation into P ', if P is not finished or wrongly finished, P ' cannot be finished or wrongly finished, and P ' has the same output result as P. Otherwise P' is not a valid confounding result of P. Commonly employed code obfuscation techniques include: layout confusion (layout obfuscation), data obfuscation (data obfuscation), control confusion (control obfuscation), and prevention confusion (preventive obfuscation).

The common reinforcement mode for code reinforcement is to upload a code data packet to a selected reinforcement platform for reinforcement processing. The present application is not limited to specific code confusion, code reinforcement, and order of processing.

The decompilation of the boot program can be avoided by installing a boot program encapsulated with code instrumentation and code obfuscation in the target system. By installing the bootstrap program obtained through the code reinforcement and code confusion modes and configuring the starting flow of the target system, the security in the full-disk encryption self-starting scene can be improved. The processes of code instrumentation, code obfuscation may be device implementations that provide a bootstrap.

After the first device installs the resulting boot program (the aforementioned cryptosetp) in the target system, the configuration process of S33 may be performed.

Regarding the above S33, two aspects may be included: and carrying out partition mapping configuration and startup configuration on the target system according to the bootstrap program. The partition mapping configuration process can determine what partition should be mounted, decrypted and mapping relation among partitions when the target system is started after being encrypted. The configuration of the start-up item can determine which tools, programs or components are called to execute the system start-up flow when the target system is started up after being encrypted.

And in the configuration process of the starting flow, after the kernel of the target system is recompiled, the configuration process of the starting flow of the target system is regarded as ending. At the end of the configuration, S34 may be performed.

The specific configuration content of S33 will be finished in detail below, and will not be described here.

Regarding the above S34, it may be determined that the partition to be encrypted in the target system is determined to be the first partition at the end of the configuration process, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key, thereby implementing full disc encryption.

Since the file system of the target system itself cannot encrypt itself in full, the encryption process is completed by means of the second device as an auxiliary device.

In one example, an unencrypted target system may be mounted to the second device after S33 to obtain an encryption key by the second device and encrypt the first partition of the target system with the encryption key. In the embodiment of the present application, encrypting the first partition that needs to be encrypted in the target system may be regarded as performing full-disc encryption on the target system.

It should be noted that, mounting the target system on the second device for performing auxiliary encryption refers to associating the storage carrier of the target system with the second device when the second device has an operating system, for example, a memory dedicated to storing the target system in the first device may be connected to the second device, so that the second device can encrypt the first partition in the target system.

Wherein encrypting the first partition by the second device means: the second device obtains an encryption key corresponding to the decryption key without parsing the access boot program, and performs symmetric encryption or asymmetric encryption on the first partition by using the encryption key. The process of obtaining the encryption key by the second device and the encryption process are not realized through a bootstrap program, and only a specific password is needed to be obtained to encrypt the partition.

There are many ways of obtaining the encryption password by the second device, for example, when the encryption key and the decryption key that are matched with each other are set in advance for the target system of the first device, the second device may obtain the encryption key corresponding to the decryption key by means of table lookup, temporary entry/import, or the like.

In the embodiment of the application, after the bootstrap program encapsulated with the decryption key and the specified hardware information is successfully installed and deployed in the target system, the bootstrap program can be used for guiding the encrypted target system to perform self-starting according to the configured starting flow.

In the above-mentioned method of S31-S34, since the boot program, in which the decryption key for automatic decryption and the specified hardware information for performing device verification are encapsulated, is installed in the target system, in this case, the boot flow of the target system is configured, and the partition, in which encryption is required in the configured target system, is encrypted with the encryption key corresponding to the decryption key, so that when the target system is encrypted and then the system is self-started, it is advantageous to perform device verification on the device mounted on the target system automatically by the specified hardware information encapsulated in the boot program, and decrypt the encrypted first partition automatically by the decryption key encapsulated in the boot program, so that automatic mounting and automatic starting can be implemented while protecting data, and no user is required to input a password to the encrypted target system by an external device.

After the decryption key is encapsulated in the source code of the cryptosetup, the executable program of the cryptosetup can be started to run as a bootstrap program, and the encrypted first partition is automatically decrypted by using the encapsulated decryption key without manually inputting a password by a user in the process of system self-starting by means of an interactive interface or external equipment.

When the hardware information of the first device is added as the specified hardware information to the source code of the cryptoptsetup, when the executable program of the cryptoptsetup is started to run as the boot program, the device mounted on the target system is automatically verified by the specified hardware information, the hardware information (such as "proc" in fig. 2) in the virtual file system of the target system is checked first, and if the boot program of the cryptoptsetup is started after the target system is encrypted, the hardware information currently stored in the virtual file system is checked to be not matched with the specified hardware information pre-packaged in the boot program, and then the encrypted first partition is not continuously decrypted by the pre-packaged decryption key. Therefore, the processing mode of packaging the hardware information into the bootstrap program is beneficial to carrying out equipment verification in the self-starting process of the system, is beneficial to avoiding other people from directly stealing the bootstrap program package with the packaged hardware information and the password to the appointed other system equipment for operation (because decryption cannot be completed if the packaged appointed hardware information cannot be matched with the actually mounted equipment), and can improve the data security.

Therefore, the method can be well applied to interface-free equipment or other equipment which cannot be accessed to peripheral equipment and needs data protection. The full-disc encryption method can improve the security of the full-disc encryption under the self-starting scene.

The virtual file system stores the contents such as the running state of the kernel and the hardware information of the current device actually mounted by the target system. The data in the virtual file system is stored in random access memory (Random Access Memory, RAM) when the target system is powered up and erased from the random access memory when the power is off. The RAM is an internal memory that directly exchanges data with the CPU of the system, as a temporary data storage medium.

With regard to the above-mentioned method of S31-S34, since the hardware information of the device needs to be bound before encryption is performed, when the plurality of devices to be encrypted need to be encrypted respectively in full disc, each device to be encrypted needs to be processed by the above-mentioned method of S31-S34 for the corresponding system to be encrypted and the corresponding device respectively, so as to avoid that the designated hardware information and decryption key stored in the system of each device to be encrypted are the same.

The configuration process of the foregoing S33 will be described in detail.

As an implementation of S33, S33 may include sub-steps S331-S332, as shown in fig. 6. S331 and S332 may be implemented as the partition mapping configuration and the startup configuration, respectively.

S331: and carrying out partition configuration on the target system based on the bootstrap program, and determining the partition mapping relation of the target system.

As shown in fig. 7, S331 may include: S3311-S3312.

S3311: an encryption map file is generated for the target system based on the boot program.

S3311 may include: and generating an image file for the target system, and encrypting the image file through a bootstrap program to obtain an encrypted mapping file.

S3312: and establishing a partition mapping relation between the first partition and the encryption mapping file.

S3312 may include: storing the encryption mapping file under a specified first directory, wherein the first directory is a directory used for storing logic equipment in the target system; and configuring a partition mapping relation between the first partition and the encryption mapping file in a configuration file directory of the target system.

For example, taking the Linux system to be encrypted of the first device as the target system, after the aforesaid boot program is installed in the Linux system to be encrypted, an IMG file may be generated for the Linux system based on the boot program, where the IMG file is an image file. And then encrypting the IMG file through the bootstrap program of the installed cryptatup, and generating a mapping file after encryption, namely an encrypted mapping file.

The encryption map file may be named herein as crypt, and stored under the/dev/mapper directory, i.e. get/dev/mapper/crypt. The/dev/mapper directory is a specified first directory, where the first directory is a directory in the target system for storing logical devices. Wherein/dev is a device management file (device management directory) of the target system, in which data of a plurality of devices are stored.

Then fstab (file system information) and cryptotab (cryptosettup configuration information) under the per-etc can be modified, so that the first partition can be mapped to the file directory of the per-dev/mapper/cryptopt, and a mapping relation configuration process between the first partition and the encrypted mapping file can be realized. Therefore, the target system can automatically decrypt and mount the encrypted partition (for example, the first partition and the logical partition corresponding to the encryption mapping file) when being started.

Where/etc is a profile directory for storing various profiles of the target system. fstab is file system information in the configuration file directory, in which mapping relation to the first partition, encrypted mapping file, may be configured. The cryptotatab stores therein configuration options related to the boot program of the cryptoptsetup. By configuring fstab, crypttab, the first partition or other partitions having a mapping relationship with the first partition can be accessed by the cryptosetup based on the configured partition mapping relationship at the time of system self-start.

Through the implementation of S3311-S3312 described above, it is advantageous to quickly determine what partitions should be mounted, encrypted/decrypted, and the mapping relationship related to the encrypted partitions when the system is powered on.

After the configuration process of the partition mapping relationship is completed, S332 may be performed.

S332: generating a sub-file system for the target system based on the partition mapping relation, and compiling a kernel of the target system so that the target system can access the partition needing decryption in the target system through the sub-file system according to the partition mapping relation when the target system is started after being encrypted.

In the embodiment of the present application, S332 may include: S3321-S3323.

S3321: and installing and configuring a dropoff tool in the target system based on the partition mapping relation.

The dropobel tool is a remote connection tool implemented based on the SSH protocol.

S3322: a sub-file system is generated for the target system that contains the dropoff tool and the aforementioned bootstrap program.

The sub-file system is initrimfs, a lightweight file system running in memory. The initrimfs is run before the system mounts the root directory.

S3323: and compiling a kernel of the target system so that the target system can access the first partition according to the partition mapping relation by calling a dropdear tool and a bootstrap program through the sub-file system when the target system is started after being encrypted.

The method comprises the steps of generating a sub-file system in a system starting directory of a target system, establishing an association relation among an installed guide program, an installed dropdear tool and the sub-file system, compiling a kernel of the target system, and enabling the target system to access a first partition based on a partition mapping relation configured in a configuration file directory by calling the guide program and the dropdear tool through the sub-file system when the target system is self-started after being encrypted.

The following describes the procedure of S3321 to S3323 in detail:

after the configuration process of the partition mapping relationship is completed, a dropdear tool can be installed and configured in the Linux system to be encrypted. For example, a dropdear (which is an SSH terminal) may be installed and configured in a configuration file directory of the target system, where the dropdear is configured so that the dropdear tool can implement decryption operations for the partition based on the SSH protocol in an initrimfs file system running at the start-up of the target system. Dropobar is used as a tool to "remotely" connect to an encrypted partition (first partition) in an initrimfs, a lightweight file system using the SSH protocol.

After configuring the dropdear tool, a new init fs (i.e., sub-file system) may be regenerated in the system boot directory, a/boot, using the mkinit mfs tool.

Wherein mkinitramfs is a command line tool for generating the sub-file system of initramfs. After generating a new initramfs with the mkinitramfs, the modified, compiled, criptisetups and dropoff tools are packed into the initmfs before this. By such configuration, the init fs may be started at boot time of the target system, and the encrypted first partition may be decrypted by invoking the cryptsetup (i.e., bootstrap) and the dropdear tool through the init fs.

It should be noted that after generating the sub-file system of init fs based on the principle provided by the embodiment of the present application, the encrypted target system will first enter and access the sub-file system of init fs when the target system is started, and both the cryptosetp and dropoff tools responsible for decryption are in the sub-file system, where the conventional system is not configured with init fs, or the conventional init fs is not configured with cryptosetp and dropoff, so that the embodiment of the present application specifically generates a new init fs as the sub-file system that is first accessed when the encrypted target system is started. In the sub-file system, the content that the target system wants to run when it is booted up can be packaged in.

After the generation of the subf iotale system (initrimfs), the kernel of the Linux system to be encrypted may be modified and compiled. After the kernel compiling is completed, the encrypted Linux system is enabled not to directly mount a physical partition during self-starting, but to mount a logical partition obtained by mapping of/dev/mapper/crypt, and newly generated initrimfs (namely the sub-file system generated in the previous step) is operated during starting of the encrypted Linux system, and whether the encrypted first partition can be continuously accessed is determined based on the operation and calling results of the sub-file system.

Through the implementation manner of S3321-S3323, the content and tool which want to be operated when the Linux system is self-started can be configured, and the content (such as a bootstrap program and a dropdear tool) which want to be operated when the Linux system is self-started can be packaged into the sub-file system, so that the system does not directly mount a physical partition when the Linux system is self-started, but mounts the physical partition according to the partition mapping relationship, and the secure access to the encrypted first partition is realized based on the generated bootstrap program and dropdear tool which are called by the sub-file system and the partition mapping relationship which is pre-configured.

By configuring the system startup procedure according to the bootstrap program through the configuration implementation manner related to S331-S332, the target system can execute the startup procedure according to the configured startup procedure and the partition mapping relationship when being started after being encrypted, so as to access the partition needing to be decrypted.

The encryption process (corresponding to S34 described above) executable after completion of the boot flow configuration of the target system may include: and determining the partition needing encryption in the target system as a first partition, so that the second device performs data backup on the first partition. The first partition is formatted after the data backup is completed. After formatting is completed, the first partition is encrypted according to the encryption key. And after encryption is completed, carrying out data recovery on the first partition based on the content of the data backup.

The first device may be powered off after completing the kernel compiling process after completing the configuration flow described above. The Linux system to be encrypted in the first device is then mounted on the second device for auxiliary encryption, for example, by mounting a storage carrier of a system file (including the foregoing various directories and files) in which the target system is disposed on the second device (the encryption operation may be implemented by using a device relationship similar to that of fig. 5), so that the first partition in the system to be encrypted, which needs to be encrypted, is encrypted by the second device with the foregoing encryption key. Before encryption operation is executed, all data backup is carried out on the partition to be encrypted, then the partition to be encrypted is formatted, encryption operation is carried out on the first partition to be encrypted by the encryption key after the formatting is completed, and after the encryption is completed, data recovery is carried out on the formatted first partition based on the content of the data backup. So far, the full disk encryption operation for the target system ends.

In this embodiment of the present application, the storage carrier of the deployment target system may be a physical memory or a virtual memory, for example, may be a storage medium such as a TF card, an EMMC (abbreviation for embedded multimedia controller), or an image file that is ready for batch burning.

Alternatively, the device that provides the boot program for the target system of the first device and encrypts the first partition may be different devices, for example, the device that provides the boot program may be a third device (as with the second device, the third device itself has its operating system, and does not need to rely on the target system to perform device startup or operation). The first device as the encrypted device is used for completing the configuration process of the target system according to the obtained bootstrap program, so that the target system can realize safe self-starting and quick self-starting on the first device after the configuration is completed and the target system is encrypted, and meanwhile, other devices except the first device can be prevented from running the target system. The first device may be a device that is incapable of providing an interactive interface.

Based on the same inventive concept, in order to realize the security of full disc decryption in a self-starting scenario, the embodiment of the present application provides a system operation method, and the system operation method provided in the embodiment of the present application will be described below.

Referring to fig. 8, fig. 8 is a flowchart of a system operation method according to an embodiment of the present application. The method can be used as the method content of the decryption stage and is used for decrypting the target system encrypted by the method through the bootstrap program which is used in the encryption stage and is packaged with the hardware information and the decryption key, so that the full-disc decryption is realized.

The system operation method can be applied to the encrypted equipment, and the encrypted equipment is provided with the target system obtained by encrypting the whole-disk encryption method. The encrypted device may be the first device described above.

The target system includes a first partition that is an encrypted partition and a second partition that is an unencrypted partition, the second partition having stored therein a boot program for decrypting the first partition. The second partition also stores the kernel of the target system.

The system operation method may be regarded as a method applied to the encrypted target system.

As shown in fig. 8, the system operation method may include: S41-S42.

S41: when the target system is started, performing equipment verification on the first equipment currently mounted on the target system according to the appointed hardware information packaged in the bootstrap program.

S42: and when the first device passes the device verification, decrypting the first partition through a decryption key encapsulated in the bootstrap program.

When the first device fails device verification, the calling process of the bootstrap program is ended, so that the first partition cannot be decrypted and accessed. Theoretically, if the specified hardware information packaged in the bootstrap of the target system is matched with the first device currently mounted on the target system, the first device can pass the verification of the device, and if the specified hardware information packaged in the bootstrap of the target system is not matched with the device currently mounted on the target system, the device currently mounted on the target system cannot pass the verification.

By the system operation method, in the self-starting process of the target system, the device mounted on the target system can be automatically verified by the bootstrap program stored in the unencrypted partition (second partition) based on the pre-packaged specified hardware information, and the encrypted first partition is decrypted by the decryption key packaged in the bootstrap program only when the device verification is passed. Therefore, the method can realize automatic mounting and automatic starting while protecting data, does not need a user to input a password to an encrypted system through external equipment, can realize safe self-starting under the condition that the user does not need to input the password to the encrypted system through the external equipment and does not need to input the password through external media, and can improve the safety in a full-disc encryption self-starting scene.

Based on the method, when the fact that the device mounted by the current target system is not the specific device corresponding to the packaged and bound specified hardware information in the bootstrap program is detected, the content in the first partition can be well protected, and the situation that the content encrypted by the whole disk in the target system is randomly decrypted and accessed due to a physical transplanting means can be avoided.

Optionally, in the case that the sub-file system and the pre-generated encrypted mapping file are deployed in the target system, before performing device verification on the first device currently mounted on the target system according to the specified hardware information encapsulated in the bootstrap program, the system operation method may further include: when the target system is started, a sub-file system in the target system is accessed. Calling a pre-installed and configured dropdear tool through a sub-file system, and accessing a first partition corresponding to the encryption mapping file through the dropdear tool according to the encryption mapping file and a preset partition mapping relation.

The implementation process of the system operation method is shown in fig. 9, and when the target system is started, the sub-file system (initrimfs system) generated in the encryption stage can be accessed. The keynear tool is then called by the init fs system to prepare for access to the encrypted partition, and a bootstrap (cryptosetup) is called that encapsulates the specified hardware information and decryption keys, and the cryptosetup is started to perform device authentication on the device currently mounted by the target system. Under the condition that the current mounted equipment of the target system (the encrypted Linux system) passes equipment verification, the decryption key encapsulated in the cryptsetup is used for decrypting the first partition, so that full-disc decryption is realized, the main system of the target system is successfully accessed, and the target system is successfully started. Under the condition that the currently mounted device of the target system (the encrypted Linux system) fails to pass the device verification, the calling process of the cryptsetup is ended, the cryptsetup program jumps out, the first partition cannot be decrypted, the target system is failed to start, the main system of the target system is started under the condition that the devices are not matched, and therefore safety of the system under a self-starting scene can be improved.

Based on the same inventive concept, as shown in fig. 10, the embodiment of the present application further provides an electronic device 500. The electronic device 500 includes: memory 501, processor 502, and communication component 403. The electronic device 500 may be used to implement the aforementioned methods. The electronic equipment is used for realizing the whole-disk encryption method or the system operation method.

The communication component 503 includes a communication bus that is used to enable direct or indirect connection between the various components in the electronic device 500.

The memory 501 is a storage medium, and may be a high-speed RAM memory or a nonvolatile memory (non-volatile memory).

The processor 502 has an arithmetic processing capability, and may be, but is not limited to, a general purpose processor such as a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but may be a special purpose processor or other programmable logic device built processor. The processor 502 may implement the methods, steps and logic blocks provided by the embodiments of the present application.

The memory 501 has stored thereon a computer program executable by the processor 502, the processor 502 being adapted to execute the computer program stored in the memory 501, thereby implementing some or all of the steps of the methods provided by the foregoing embodiments.

It should be noted that the structure shown in fig. 10 is only illustrative, and more components may be provided in the specific application, or other configurations may be provided different from those shown in fig. 10.

In the embodiments provided in the present application, it should be understood that the disclosed embodiments may be implemented in other manners. The embodiments described above are merely illustrative, and further, components illustrated as separate components may or may not be physically separate, i.e., may be located in one place, or may be distributed across multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

It should be noted that the functions of the above-described method, if implemented in the form of software functional modules and sold or used as a separate product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device to perform all or part of the steps of the methods of the embodiments of the present application.

In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The above is only an example of the present application, and is not intended to limit the scope of the present application, and various modifications and variations will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A method of full disc encryption, for use with a first device, the method comprising:

the method comprises the steps of obtaining a guide program encapsulated with a decryption key and appointed hardware information, wherein the decryption key is used for decrypting a partition needing full-disk decryption in a target system when the target system is started after being encrypted, the appointed hardware information is used for performing equipment verification on equipment mounted in the target system when the target system is started after being encrypted, and the target system is a Linux system;

Installing the bootstrap program in the target system to be encrypted;

configuring a start-up procedure of the target system to be encrypted based on the bootstrap program, including: generating an encryption mapping file for the target system based on the bootstrap program; establishing a partition mapping relation between a first partition and the encryption mapping file; installing and configuring a dropoff tool in the target system based on the partition mapping relation, wherein the dropoff tool is a remote connection tool realized based on an SSH protocol; generating a sub-file system containing the dropoff tool and the bootstrap program for the target system; compiling a kernel of the target system so that the target system can call the dropdear tool and the bootstrap program through the sub-file system when being started after being encrypted, and accessing the first partition according to the partition mapping relation;

2. The method of claim 1, wherein the bootstrap program is a code hardened and code obfuscated executable program.

3. The method according to claim 1, wherein determining the partition to be encrypted in the target system as the first partition, so that the second device encrypts the first partition according to the encryption key corresponding to the decryption key, includes:

formatting the first partition after the data backup is completed;

4. A system operation method, characterized in that the system operation method is applied to a first device, the first device comprises a target system obtained by encrypting the method according to any one of claims 1-3, the target system comprises a first partition and a second partition, the first partition is an encrypted partition, the second partition is an unencrypted partition, and a bootstrap program for decrypting the first partition is stored in the second partition;

The method comprises the following steps:

5. The method of claim 4, wherein a sub-file system and a pre-generated encrypted mapping file are deployed in the target system, and wherein prior to device authentication of the first device currently mounted on the target system according to specified hardware information encapsulated in the boot program, the method further comprises:

6. The method of claim 5, wherein the method further comprises:

7. An electronic device, comprising:

a storage medium;

a processor;

the storage medium having stored thereon a computer program executable by the processor for performing the method of any of claims 1-3 or the method of any of claims 4-6 when executed by the processor.