CN114915416A

CN114915416A - Method for encrypting file, method for verifying decryption and related products

Info

Publication number: CN114915416A
Application number: CN202210420401.7A
Authority: CN
Inventors: 王志勇
Original assignee: China Financial Certification Authority Co ltd
Current assignee: China Financial Certification Authority Co ltd
Priority date: 2022-04-20
Filing date: 2022-04-20
Publication date: 2022-08-16

Abstract

The present disclosure relates to a method for encrypting a file, a method for verifying decryption, and a related product, the method for encrypting comprising obtaining an encryption password for encrypting the file; generating an encryption key according to the encryption password and a device identification of an encryption device for performing the file encryption, wherein the device identification is stored in a password management system; and encrypting the file according to the encryption key. According to the encryption scheme, the encryption key for encrypting the file is generated by adopting the unique equipment identifier which is not easy to counterfeit and is not easy to obtain by other equipment, so that the encrypted file cannot be decrypted on other equipment, the problem of file migration is solved, and the safety of data is ensured. In addition, based on the method, the range of the decryption failure reason can be narrowed by judging whether the equipment identification is stored in the password management system during decryption, so that the decryption failure reason can be accurately positioned.

Description

Method for encrypting file, method for verifying decryption and related products

Technical Field

The present disclosure relates generally to the field of information security technology. More particularly, the present disclosure relates to a method for encrypting a file, a method for decrypting a file, a device, and a computer-readable medium.

Background

Some current operating systems often adopt open source embedded databases, for example, SQLite is a popular open source embedded database in iOS and Android systems. There is no method for encrypting the database in these systems, and the database stores the plain text of the service data, so that the database file can be used in the iOS system by adding libsql lite3.0.tbd dependency and introducing sql lite3.h header file.

At present, although some database encryption schemes exist, the security of database files cannot be guaranteed.

Disclosure of Invention

At least to address the above deficiencies in the background, the present disclosure provides a method for encrypting a file, a method, an apparatus, and a computer-readable medium for decrypting a file.

In a first aspect, the present disclosure provides a method for encrypting a file, comprising: acquiring an encryption password for encrypting the file; generating an encryption key according to the encryption password and a device identification of an encryption device for executing the file encryption, wherein the device identification is stored in a password management system; and encrypting the file according to the encryption key.

In one embodiment, the generating the encryption key comprises: splicing the encrypted password and the equipment identifier to obtain a splicing result; carrying out hash calculation on the splicing result through an SM3 algorithm to obtain an incoming key; and generating the encryption key from the incoming key.

In one embodiment, said generating said encryption key from said incoming key comprises: performing data splicing on the incoming secret key and a predicted initial secret key to obtain a splicing result; performing hash calculation on the splicing result for preset times through an SM3 algorithm to obtain a calculation result; and generating the encryption key according to the calculation result.

In another embodiment, before the file is encrypted, the method further comprises: generating a first plaintext check code according to the file content of the file; and storing the first plaintext check code in the file so as to verify whether decryption is successful or not when the encrypted file is decrypted.

In yet another embodiment, the generating the first plaintext check code comprises: calculating the file content of the file by using an SM3 algorithm to generate the first plaintext check code.

In a second aspect, the present disclosure also provides a method for decryption verification of a file, comprising: when the file is decrypted, searching a device identifier of an encryption device used for encrypting and forming the file in a password management system; and in response to not finding the device identifier, not performing decryption verification operation on the file; or, in response to finding the device identifier, performing decryption verification operation on the file.

In one embodiment, in response to finding the device identifier, performing a decryption verification operation on the file includes: acquiring a decryption password for decrypting the file; decrypting the file according to the decryption password to obtain the content of the file to be verified; and determining whether the file is decrypted successfully according to the content of the file to be verified.

In another embodiment, determining whether the file was decrypted successfully comprises: generating a second plaintext check code according to the content of the file to be verified; acquiring a first plaintext check code from the file, wherein the first plaintext check code is a check code generated according to the file content before the file is encrypted; and determining whether the file is decrypted successfully according to the matching result of the second plaintext check code and the first plaintext check code.

In a third aspect, the present disclosure also provides an apparatus comprising: a processor; a memory storing program instructions executable by a processor, the program instructions, when executed by the processor, causing the apparatus to perform a method for encrypting a file according to any of the embodiments of the first aspect or to perform a method for decrypting a file for verification as described in any of the embodiments of the second aspect.

In a fourth aspect, the present disclosure also provides a computer-readable medium storing program instructions for verifying a fingerprint, which when executed by at least one processor, cause the method for encrypting a file according to any of the embodiments of the first aspect described above or the method for decrypting a verification file described above in any of the embodiments of the second aspect described above to be performed.

Based on the above description of the present disclosure, those skilled in the art can understand that in the encryption scheme described in the above embodiment, because the encryption key for encrypting the file is generated by using the unique device identifier that is not easy to counterfeit and is not easy to obtain by other devices, the encrypted file cannot be decrypted on other devices, and thus the problem of file migration is solved, and the security of data is ensured. In addition, based on the method, the device identification is judged whether to be stored in the password management system or not during decryption to determine the reason of decryption failure or narrow the range of the reason of decryption failure, so that the reason of decryption failure can be accurately positioned.

Drawings

The above and other objects, features and advantages of exemplary embodiments of the present disclosure will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. In the drawings, several embodiments of the disclosure are illustrated by way of example and not by way of limitation, and like or corresponding reference numerals indicate like or corresponding parts and in which:

FIG. 1 is a schematic flow chart diagram of a method for encrypting a file in accordance with an embodiment of the present disclosure;

fig. 2 and 3 are schematic flow diagrams of a method of generating an encryption key, respectively, according to an embodiment of the present disclosure;

FIG. 4 is a schematic flow chart diagram of a method for encrypting a file in accordance with another embodiment of the present disclosure;

FIGS. 5a and 5b are schematic flow diagrams of a method for decryption verification of a file according to an embodiment of the present disclosure, respectively;

FIGS. 6 and 7 are schematic flow diagrams respectively illustrating a decryption verification operation performed on a file according to another embodiment of the present disclosure;

fig. 8 is a block diagram of a device according to an embodiment of the present disclosure.

Detailed Description

The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

The current more common database encryption scheme is the SQLCipher scheme using the open source on github, which has the following problems:

the encryption scheme is public, and a plurality of database operation software such as DB Browser for SQLite can directly open encrypted database files;

the database file can be migrated, that is, the database encrypted file generated on one device (such as a terminal device like a mobile phone) can still be decrypted on another device (that is, there is a possibility that the decryption is successful).

Thus, the security of the database file is still poor.

In view of this, the embodiments of the present disclosure provide a scheme for encrypting and decrypting a file, where an encryption key for encrypting the file is generated by using a unique device identifier that is not easily counterfeited and is not easily obtained by other devices, so that the encrypted file cannot be decrypted on other devices, thereby solving the problem of file migration and ensuring data security. Based on the scheme, when decryption is performed, the reason of decryption failure can be determined or the range of the reason of decryption failure can be narrowed by judging whether the equipment identification is stored in the password management system, so that the reason of decryption failure can be accurately positioned.

Fig. 1 is a schematic flow chart diagram of a method 100 for encrypting a file according to an embodiment of the present disclosure.

As shown in fig. 1, the method 100 includes, at step S101, acquiring an encryption password for encrypting the above-described file.

The file may be a database file, and the database may include, but is not limited to, an SQLite database in an IOS or Android system, that is, the database file may be an SQLite database file. When the SQLite database file is encrypted, a libCFCASQLite.a interface can be called to receive an encryption password.

After obtaining the encryption password, at step S102, the method 100 may generate an encryption key from the encryption password and a device identification of the encryption device performing the file encryption, where the device identification is stored in the password management system.

The device identifier may be generated during encryption, or may be an existing identifier called directly from the password management system, as long as it is guaranteed to be unique and secure. In order to ensure the uniqueness and security of the device Identifier and make other devices unable to be counterfeited, a relatively secure and Unique UUID (universal Unique Identifier) may be used as the device Identifier. In an IOS system, the UUID may be generated by an NSUUID (identification code interface of the IOS system).

It is understood that the use of UUID as the device identification is merely an exemplary implementation, and those skilled in the art may also use other unique and secure identification codes as the device identification, such as an advertisement identifier or a vendor identifier of the cryptographic device, as desired. The two identifiers of different devices are also different and cannot be counterfeited and can therefore also be used as encrypted device identifications.

In addition, because the device identifier is stored in the password management system with higher security, other devices cannot acquire the device identifier from the password management system, so that the security of the device identifier can be further ensured. Specifically, the device identifier may be stored in a predetermined identifier storage location (e.g., a predetermined storage field) in the password management system, so as to be obtained when decrypting.

Different storage systems may be employed as password management systems in different operating systems. For example, in the IOS system, keyhain (key fob) may be adopted as a password management system, and in the android system, keystore (key warehouse) may be adopted as a password management system.

The encryption device in the present solution includes, but is not limited to, a mobile terminal (e.g., a mobile phone, a tablet computer, etc.) and a computer device (a personal computer, a server, or a network device), so that the encryption method in the present solution can be executed in different devices.

Further, after generating the encryption key, at step S103, the method 100 may encrypt the file according to the encryption key. In one implementation scenario, a symmetric encryption algorithm may be employed for the encryption operation.

As can be seen from the above description, in the embodiment of the present disclosure, the encryption key for encrypting the file is generated by using the unique device identifier that is not easy to counterfeit and is not easy to obtain by other devices, so that the encrypted file cannot be decrypted on other devices, and thus the problem of file migration is solved, and the security of data is ensured. In addition, based on the method, the reason of decryption failure can be determined or the range of the reason of decryption failure can be narrowed by judging whether the equipment identification is stored in the password management system during decryption, so that the reason of decryption failure can be accurately positioned.

The scheme will be further described below with reference to fig. 2 and 3. As shown in fig. 2, the method 200 for generating an encryption key may include splicing an encryption password and a device identifier to obtain a splicing result at step S201. For example, the encryption password is a, the device identifier is b, and the splicing result may be a character string of ab or ba.

After obtaining the splicing result, at step S202, the method 200 may perform a hash calculation on the splicing result through the SM3 algorithm to obtain the incoming key. For example, the above ab or ba string may be subjected to hash calculation to obtain a hexadecimal string, and the hexadecimal string is used as the incoming key.

After obtaining the incoming key, the method 200 may generate an encryption key from the incoming key at step S203.

As can be seen from the above description, the embodiments of the present disclosure utilize a more secure cryptographic algorithm and employ a more complex computational logic to generate the encryption key, thereby increasing the security of the encryption key.

One exemplary flow of generating an encryption key from an incoming key is further illustrated in fig. 3. As can be seen from fig. 3, the method 300 includes data splicing the incoming key and the pre-known initial key at step S301, and obtaining a splicing result.

The initial key may be a string of a preset length (e.g., 16 bytes) and may be stored in a preset location, e.g., a header, of the file (file to be encrypted) for recall upon decryption. The concatenation result may also be a string of the incoming key and the initial key.

After the splicing result is obtained, in step S302, the method 300 may perform hash calculation on the splicing result for a preset number of times through the SM3 algorithm to obtain a calculation result. The number of hash operations may be specifically set, and may be 256000 times, for example.

Next, the method 300 proceeds to step S303, where an encryption key is generated based on the calculation result. Specifically, the contents of two different fields in the calculation result may be logically operated, and the calculation result may be used as an encryption key. For example, for a calculation result of 32 bytes, the contents of the first 16 bytes and the contents of the second 16 bytes may be subjected to an exclusive or operation to obtain an encryption key. It is understood that the exclusive or operation is only an exemplary calculation method, and those skilled in the art may select other logic operations, such as and operation or the like, as needed.

Therefore, the embodiment of the disclosure still adopts a safer national cryptographic algorithm and a more complex calculation logic in the process of generating the encryption key by the transmitted key, thereby further increasing the security of the encryption key.

The inventor finds that the current decryption method cannot accurately locate whether the failure reason is decryption password error when decryption fails. In the embodiment of the disclosure, a solution is provided, by which whether the reason of the decryption failure is a decryption password error can be accurately located.

Fig. 4 is a schematic flow chart diagram of an encryption method 400 according to another embodiment of the present disclosure.

As shown in fig. 4, before encrypting the file, the method 400 may further include generating a first plaintext check code from the file content of the file at step S401.

In order to ensure the security of the generated plaintext check code, in this embodiment, the plaintext check code may also be generated by using the cryptographic algorithm as described above. For example, the file content of the file may be calculated by the SM3 algorithm to generate a first plaintext check code. In one implementation, the plaintext check code may be, for example, a 32-byte or 16-byte check code.

The file content used here to generate the first plaintext check code may include all the content of the file, including, for example, the actual data content of the file and the contents of the header and footer of the file. However, since the header and the footer of the file store the description information of the file, which may be changed due to the written data, the content of the file used to generate the plaintext check code may also be only the actual data content of the file (i.e., the content of the header and the footer of the file is not included) in order to not affect the data writing function of the header and the footer and to perform accurate positioning of the reason for the decryption failure.

In order to verify the consistency between the content of the decrypted file and the plaintext used in the encryption, the content of the file used for generating the first plaintext check code needs to be consistent with the plaintext used for encrypting the file.

After generating the first plaintext check code, at step S402, the method 400 may store the first plaintext check code in a file to verify whether the decryption is successful when decrypting the encrypted file. For example, the decryption result may be stored in a preset position (e.g., a start position) of a preset field (e.g., a reserved field) at the end of a page in the file, so as to be called during decryption, compare the decryption result with a plaintext check code generated according to the decrypted file content, and finally verify whether the reason of the decryption failure is a decryption password error according to the comparison result. Therefore, the reason of decryption failure can be accurately positioned when the file is decrypted by setting the plaintext check code.

The inventors have also found that current encryption schemes are open (e.g., using international methods), and thus can be decrypted using many existing decryption methods. For example, for a database file encrypted by SQLCipher, currently, many database operating software such as "DB Browser for SQLite" can be directly opened, so that the security is poor, and the present disclosure adopts an encryption scheme based on a complex logic of a national password, so that the file encrypted by the encryption method is not easy to decrypt, and the security is greatly improved.

In order to more fully describe the encryption scheme of the embodiment of the present disclosure, details will be given below by taking the encryption of the SQLite database file as an example.

In the encryption scheme of the embodiment, two static library files, libsqlite3.a and libcFCASQlite.a, are used, wherein libcFCASQlite.a provides external calling interfaces for setting passwords, executing SQL and the like, and libcFCASQlite.a calls libsqlite3.a to operate the database. The two static library files can be combined into one file, or packaged into a dynamic library to be provided in a framework form. Before the encryption operation is executed, libsqlite3.a can be called to judge whether the database file exists, and if not, the database file can be created.

The specific encryption method may include the steps of:

a1, before encryption, for each page database file to be encrypted, generating a 32-byte check code (i.e. a first plaintext check code) for the file content before encryption (excluding the page header and the page tail) by using the SM3 algorithm, and filling the 32-byte check code in the starting position of the page tail reserved field of the page.

a2, when encrypting, firstly calling a libcFCASQLite.a interface to transmit an encryption password of a database, then generating a device identifier (such as UUID) of an encryption device, splicing the encryption password and the device identifier, then performing hash calculation on a splicing result through an SM3 algorithm, and taking the hash result (such as a hexadecimal character string) as a transmission key.

a3, an initial key (e.g., a 16 byte random number) is generated for each page of database file and then stored in the header of the page of database file. The initial key of each page of database file may be the same or different.

a4, calculating the encryption key of each page of database file. Specifically, the incoming key and the initial key are spliced to obtain a splicing result. Then, 256000 times of hash calculation is carried out on the splicing result through an SM3 algorithm, if the calculation result is a 32-byte character string, the first 16 bytes and the last 16 bytes of the character string are subjected to exclusive-or operation through an SM4 algorithm, an SM4 key of the page database file is obtained, and the SM4 key is used as an encryption key.

a5, after generating the SM4 key, generating an initial vector (IV value) used when encrypting each page of database file, wherein the IV value can be a 16-byte random number. The IV value is then stored to the last bit position of the tail reserved field of the corresponding page database file.

a6, encrypting the database file of the corresponding page (for example, performing SM4_ CBC encryption) by using the generated SM4 key and IV value to obtain the ciphertext of the page. Then, for each page of ciphertext, generating a 32-byte ciphertext check code for the file content of the ciphertext through an SM3 algorithm, and filling the ciphertext check code behind the first plaintext check code of the reserved field at the tail part of the page. And then, the database file is encrypted.

The foregoing describes a method for encrypting a file in connection with various embodiments. The method for verifying the decryption of the file will be described in detail below with reference to fig. 5a to 7. It can be understood that, in order to locate the reason for the failure of decryption of the file encrypted by the above encryption method, the scheme may employ a symmetric decryption algorithm to decrypt the encrypted file.

Fig. 5a is a schematic flow chart diagram of a method 500a for decryption verification of a file according to an embodiment of the present disclosure.

As shown in fig. 5a, the method 500a includes at step S501, upon decrypting a file, looking up a device identification of an encryption device used to encrypt the formed file in a password management system.

Specifically, whether data is stored or not may be searched for in a preset identifier storage location in the password management system, and if it is determined that data is stored, it is determined that the password management system has an equipment identifier, and at this time, it is determined that the decryption equipment and the encryption equipment forming the file are the same equipment. Correspondingly, if the data are not stored, the password management system is confirmed to have no equipment identification, and the decryption equipment and the encryption equipment forming the file are confirmed to be different equipment at the moment. In addition, a contributing factor to this situation may also be that the file is not encrypted based on the device identification.

In addition, the file may be a database file, and the database may include, but is not limited to, an SQLite database in the IOS or Android system, that is, the database file may be an SQLite database file.

After finding the device identifier, at step S502, in response to not finding the device identifier, the method 500a does not perform a decryption verification operation on the file. As can be seen from the above description, it may be confirmed that the decryption device and the encryption device forming the file are different devices at this time, or that the file is not encrypted based on the device identification of the encryption device. For the first reason, as can be seen from the description of the encryption method section, it is impossible for the decryption device to successfully decrypt the file, and therefore decryption verification is not required at this time. For the second reason, the decryption method according to the present scheme is also unsuccessful in decryption, and therefore, there is no need for decryption verification. That is, no decryption verification is necessary for any reason that the device id is not found.

Therefore, the embodiment of the disclosure can determine whether the reason of the decryption failure is file migration by judging whether the device identifier of the encryption device forming the file is stored in the password management system, so as to realize accurate positioning of the reason of the decryption failure.

Fig. 5b is a schematic flow chart diagram of a method 500b for decryption verification of a file according to another embodiment of the present disclosure.

As shown in fig. 5b, the method 500b includes, at step S503, upon decrypting the file, looking up a device identification of an encryption device used to encrypt the formed file in the password management system. This step is the same as step S501, and therefore the description related to step S501 also applies to step S503, and is not repeated here.

After finding the device identifier, at step S503, in response to finding the device identifier, the method 500b performs a decryption verification operation on the file. According to the above description, it can be known that, at this time, it is determined that the decryption device and the encryption device forming the file are the same device, and if decryption fails in such a case, the factor of file migration can be eliminated, so that the scope of the cause of decryption failure can be narrowed, and the cause of failure can be accurately located.

One exemplary flow of performing a decryption verification operation on a file is shown in FIG. 6.

As can be seen in fig. 6, the method 600 may include, at step S601, obtaining a decryption password for decrypting the file. When the SQLite database file is decrypted, a libCFASQLite.a interface can be called to transfer in a decryption password.

After obtaining the decryption password, at step S602, the method 600 may decrypt the file according to the decryption password to obtain the file content to be verified. When the encryption algorithm forming the file is a symmetric encryption algorithm, the step may employ its inverse algorithm to decrypt the file. Specifically, during decryption, a ciphertext check code may be generated according to the file content of the file. And then, reading the encrypted ciphertext check code from the file, and comparing the two ciphertext check codes. If the two ciphertext check codes are not matched as a result of the comparison, the file content of the ciphertext is confirmed to be changed, and at the moment, the decryption is determined to fail. Further, at this time, data abnormality or decryption failure or the like may be prompted.

If the comparison result is that the two ciphertext check codes are matched, the file content of the ciphertext is not changed, and at the moment, the incoming secret key can be generated by using the decryption password and the device identifier found in the previous step. The initial key generated at the time of encryption may then be read from the file and a decryption key generated using the initial key and the incoming key. And finally, reading an initial vector (IV value) from the file, and decrypting the ciphertext by using the decryption key and the initial vector to obtain the content of the file to be verified.

After the content of the file to be verified is obtained, the method 600 proceeds to step S603, and determines whether the file is decrypted successfully according to the content of the file to be verified.

It will be appreciated that when the decryption password and the encryption password match, the contents of the file to be verified should be consistent with the plaintext contents of the file. Correspondingly, when the decryption password is not matched with the encryption password, the content of the file to be verified is inconsistent with the plaintext content of the file. Therefore, whether the decryption password is correct can be determined based on whether the content of the file to be verified is consistent with the plaintext content of the file, and whether the reason of decryption failure is decryption password error or not is determined.

As can be seen from the foregoing description, in the present solution, whether the reason of the decryption failure is a decryption password error can be determined by comparing the first plaintext check code with the plaintext check code generated according to the decrypted file content. Based on this, a specific decryption verification flow is provided in fig. 7. As can be seen from fig. 7, the method 700 includes, at step S701, generating a second plaintext check code according to the content of the file to be verified.

The second plaintext check code may be generated in the same manner as the first plaintext check code stored in the file, and reference may be made to the description of the foregoing embodiment, and details are not described here. In addition, for comparison, the format of the second plaintext check code may also be the same as the first plaintext check code, for example, when the first plaintext check code is a 32-byte check code, the second plaintext check code may also be a 32-byte check code, so as to compare the two.

Next, at step S702, the method 700 may obtain a first plaintext check code from the file, where the first plaintext check code is a check code generated according to the content of the file before the file is encrypted.

After the first plaintext check code and the second plaintext check code are obtained, in step S703, the method 700 may determine whether the file is decrypted successfully according to a matching result of the second plaintext check code and the first plaintext check code.

According to the description of the foregoing embodiment, when the matching result is that the second plaintext check code is consistent with the first plaintext check code, it is determined that the file decryption is successful; correspondingly, when the matching result is that the second plaintext check code is inconsistent with the first plaintext check code, the decryption of the file is confirmed to fail, and the reason for the failure is that the decryption password is wrong. Therefore, whether the reason of the decryption failure is the decryption password error or not can be accurately positioned by setting the plaintext check code, so that the accurate positioning of the reason of the decryption failure can be realized.

In order to more fully describe the decryption verification scheme of the embodiment of the present disclosure, details will be described below by taking decryption verification of the SQLite database file as an example. Here, it is assumed that the database file to be decrypted is generated by the encryption method of the foregoing embodiment, and the encryption algorithm is an encryption symmetric algorithm, i.e., a generation method in which the respective parameters are the same as the generation method of the encryption, such as a generation method of the incoming key and the decryption password, and the like.

Based on this, the specific decryption verification method may include the steps of:

b1, searching a preset identification storage position of the password management system, determining that decryption fails when data are not searched, and ending; when the data is found, acquiring the equipment identifier from the data, and entering step b 2;

b2, for each page of database file to be decrypted, calling an SM3 algorithm to obtain a ciphertext check code, obtaining the ciphertext check code stored in the ciphertext check code from the database file, comparing the generated ciphertext check code with the ciphertext check code obtained from the file, and entering the step b3 if the generated ciphertext check code is consistent with the ciphertext check code obtained from the file; if not, the file content of the ciphertext is proved to be changed, decryption is failed, and abnormity is prompted;

b3, calling a libCFASQLite.a interface to transmit a decryption password into a database, and generating a transmission key according to the decryption password and the searched equipment identifier;

b4, reading the initial key in the header of the database file, and calculating the decryption key (SM4 key) of the database file together with the above-mentioned incoming key;

b5, reading an initial vector (IV value) stored in the database file, and decrypting the file by using the decryption key and the initial vector to obtain the decrypted file content (namely the file content to be verified);

b6, generating a second plaintext check code according to the decrypted file content, acquiring the first plaintext check code from the database file, comparing the first plaintext check code and the second plaintext check code, and if the first plaintext check code and the second plaintext check code are consistent, performing the step b 7; if the two are not consistent, the decryption key is proved to be incorrect, the decryption is failed, and an exception is prompted;

b7, normally executing database operation.

In one embodiment, the present solution may encapsulate the database operation interface as an OC interface, that is, its libcfcsqlite. In addition, the OC interface can be kept consistent with the popular FMDatabase database by the scheme, so that the SQLite database can be operated more conveniently (for example, the operations of addition, deletion, modification and check are carried out). In addition, this disclosure still can encapsulate SQLite database to make the API interface that provides more reasonable, and then make the integration more convenient.

Furthermore, the CFCADataBaseQueue class can be used for guaranteeing thread safety in the scheme, and the CFCAResultSet is used for packaging the query result. In addition, the scheme can also provide an upper layer interface which is convenient to call, such as export encrypted database, for example, an export EncryptedDB interface, so that the unencrypted database file is exported to the encrypted database file.

Fig. 8 is a block diagram of a structure of a device 800 according to an embodiment of the disclosure.

As shown in fig. 8, the apparatus 800 includes a processor 801(processor), a memory 802(memory), and a bus 803; the processor 801 and the memory 802 communicate with each other via a bus 803. In operation, the processor 801 is configured to call program instructions in the memory 802 to perform the encryption method and decryption verification method provided by the various embodiments described above. For example, in one aspect, a processor may perform operations to: the method comprises the steps of obtaining an encryption password used for encrypting the file, generating an encryption key according to the encryption password and a device identification of an encryption device executing file encryption, wherein the device identification is stored in a password management system, and encrypting the file according to the encryption key.

In another aspect, the processor 801 may also perform the operations of: when the file is decrypted, searching the equipment identification of the encryption equipment used for encrypting and forming the file in a password management system, and responding to the condition that the equipment identification is not searched, and not executing decryption verification operation on the file; or, in response to finding the device identifier, performing decryption verification operation on the file.

It can be understood that: all or part of the steps for implementing the above method embodiments may be performed by hardware associated with program instructions, and the aforementioned program may be stored in a non-transitory computer readable medium, and when executed, performs the steps including the above method embodiments.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

It should be understood that the terms "first," "second," "third," and "fourth," etc. in the claims, description, and drawings of the present disclosure are used to distinguish between different objects and are not used to describe a particular order. The terms "comprises" and "comprising," when used in the specification and claims of this disclosure, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also to be understood that the terminology used in the description of the disclosure herein is for the purpose of describing particular embodiments only, and is not intended to be limiting of the disclosure. As used in the specification and claims of this disclosure, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the specification and claims of this disclosure refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.

The above embodiments are only used for illustrating the technical solutions of the embodiments of the present disclosure, and not for limiting the same; although embodiments of the present disclosure have been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art will understand that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the respective embodiments of the present disclosure.

Claims

1. A method for encrypting a file, comprising:

acquiring an encryption password for encrypting the file;

generating an encryption key according to the encryption password and a device identification of an encryption device for executing the file encryption, wherein the device identification is stored in a password management system; and

and encrypting the file according to the encryption key.

2. The method of claim 1, wherein the generating an encryption key comprises:

splicing the encrypted password and the equipment identifier to obtain a splicing result;

carrying out hash calculation on the splicing result through an SM3 algorithm to obtain an incoming key; and

generating the encryption key from the incoming key.

3. The method of claim 1, wherein the generating the encryption key from the incoming key comprises:

performing data splicing on the incoming secret key and a predicted initial secret key to obtain a splicing result;

performing hash calculation on the splicing result for preset times through an SM3 algorithm to obtain a calculation result; and

and generating the encryption key according to the calculation result.

4. The method of any of claims 1-3, prior to the file being encrypted, the method further comprising:

generating a first plaintext check code according to the file content of the file; and

and storing the first plaintext check code in the file so as to verify whether decryption is successful or not when the encrypted file is decrypted.

5. The method of claim 4, wherein the generating a first plaintext check code comprises:

calculating the file content of the file by using an SM3 algorithm to generate the first plaintext check code.

6. A method for decryption verification of a file, comprising:

when the file is decrypted, searching a device identifier of an encryption device used for encrypting and forming the file in a password management system; and

in response to not finding the device identifier, not performing decryption verification operation on the file; alternatively, the first and second electrodes may be,

and responding to the found equipment identification, and executing decryption verification operation on the file.

7. The method of claim 6, wherein performing a decryption validation operation on the file in response to finding the device identification comprises:

acquiring a decryption password for decrypting the file;

decrypting the file according to the decryption password to obtain the content of the file to be verified; and

and determining whether the file is decrypted successfully according to the content of the file to be verified.

8. The method of claim 7, wherein determining whether the file was decrypted successfully comprises:

generating a second plaintext check code according to the content of the file to be verified;

acquiring a first plaintext check code from the file, wherein the first plaintext check code is a check code generated according to the file content before the file is encrypted; and

and determining whether the file is decrypted successfully according to the matching result of the second plaintext check code and the first plaintext check code.

9. An apparatus, comprising:

a processor;

memory storing program instructions executable by a processor, the program instructions, when executed by the processor, causing the apparatus to perform the method for encrypting a file according to any one of claims 1 to 5 or to perform the method for decrypting a file for verifying verification according to any one of claims 6 to 8.

10. A computer readable medium storing program instructions for verifying a fingerprint, which when executed by at least one processor cause the method for encrypting a file according to any one of claims 1 to 5 or the method for decrypting a verification of a file according to any one of claims 6 to 8 to be performed.