Custom SQLite encryption and decryption method

Abstract

The invention discloses a method for data mutual migration between relational databases, which is characterized by comprising the following steps that: an SQLite database is opened, a user sets an original password by himself / herself, and the SQLite database is an open source SQLite database; a structural body is self-defined in codes of the SQLite database and used for configuring parameters and achieving encryption of the SQLite database, and the structural body comprises a database original password, an original password byte length, a tree structure, an encryption password generated after the database original password is adopted for encoding and a decryption password generated after the database original password is adopted for encoding; generating an encrypted password and a decrypted password by adopting the original password; data writing of the SQLite data the encrypted password and to-be-written data are subjected to xor according to word bits, and the result serves as encrypted data to be written into the SQLite database; and reading the data of the SQLite database, wherein the decryption password and the data to be read are subjected to xor according to word bits, and a result is used as a read result of the decrypted data of the SQLite database.

Description

Technical Field

[0001] This invention belongs to the field of encryption and decryption and electronic forensics, and relates to the electronic data preservation in the local database of a smart mobile terminal, particularly a method for custom encryption and decryption of SQLite. Background Technology

[0002] With the booming development of the mobile internet, mobile applications on smart mobile terminals such as smartphones, tablets, and wearable devices have sprung up like mushrooms after rain, bringing great convenience to people's lives. Among them, information exchange and mobile payment are the most important applications of smart mobile terminals, and also the applications with the highest requirements for confidentiality and privacy.

[0003] The local storage of smart mobile terminals and the application of SQLite databases have a deeply integrated ecosystem: SQLite is a "standard core component" for local data storage on smart mobile terminals, while mobile terminals are one of the most core application scenarios for SQLite. The two are mutually adapted and complementary, supporting the local data management capabilities of mobile applications. This is reflected in two main aspects: SQLite adapts to the underlying characteristics of mobile terminals and fills the gaps in other storage methods.

[0004] However, as a lightweight embedded database, SQLite's biggest drawback is that the open-source SQLite database does not provide open-source encryption functionality; that is, it lacks a native strong encryption mechanism and only provides a simple file-level encryption extension interface. On the one hand, users need to purchase a commercial version to implement encryption, which is a significant expense for small and medium-sized users. On the other hand, existing database browsing tools can easily write / read SQLite database data, which is undoubtedly a major weakness for applications with extremely high confidentiality and privacy requirements. Specifically:

[0005] 1. By default, SQLite stores data in plaintext in local files (with extensions such as .db / .db3 / .sqlite, etc.). Anyone who obtains this file (e.g., if the device is stolen, server files are leaked, or the file is read during debugging) can directly view / modify the data through the SQLite client.

[0006] 2. Different industries / regions have mandatory encryption requirements for data storage, but SQLite only natively supports extended encryption, which cannot flexibly adapt to compliance scenarios;

[0007] 3. Native SQLite encryption solutions (such as SQLCipher) are mostly general-purpose and cannot adapt to specific business scenarios.

[0008] Therefore, on the one hand, there is an urgent need for SQLite as a database for smart mobile terminals, and on the other hand, there is an urgent need to solve the encryption and decryption of SQLite databases.

[0009] Currently, there is no free, simple, efficient, and secure method for custom encryption and decryption of SQLite. Summary of the Invention

[0010] This invention addresses the shortcomings of existing technologies by providing a method for customizing SQLite encryption and decryption. It generates encryption and decryption passwords for the SQLite database using a user-defined default password. Therefore, when writing / reading data on a smart mobile terminal, the encryption / decryption password is not provided externally, but rather the user-defined default password and the custom encryption / decryption method provided by this invention are used. This ensures both security when writing / reading SQLite databases and the simplicity and efficiency of the encryption / decryption method, all completely free of charge.

[0011] This invention includes the following steps:

[0012] Open the SQLite database and set the original password yourself. The length and type of the original password meet the password requirements of the SQLite database. The SQLite database is an open-source SQLite database.

[0013] A custom structure is defined in the code of the SQLite database to configure parameters and implement the encryption of the SQLite database. The structure includes the original database password, the original password byte length, a tree structure, the encrypted password generated after encoding with the original database password, and the decrypted password generated after encoding with the original database password.

[0014] The encryption and decryption passwords are generated using the original password.

[0015] The data writing to the SQLite database is as follows: the encryption password is XORed with the data to be written by word bits, and the result is written to the SQLite database as the encrypted data.

[0016] Reading data from an SQLite database: The decryption password and the data to be read are XORed bitwise, and the result is used as the result of reading the decrypted SQLite database data.

[0017] Preferably, the characters of the encryption password are composed as follows: the original password is supplemented with one or more identification symbols, and the identification symbols are arbitrary symbols.

[0018] Preferably, the decryption password is composed of characters arranged in a different order than the encryption password to generate the decryption password, wherein the character position of the identifier in the decryption password is different from that in the encryption password.

[0019] Preferably, the method for changing the character order of the encrypted password includes: arranging / combining the characters, and arranging them in ascending / descending order.

[0020] The beneficial effects of this invention are: while ensuring the security of writing to / reading SQLite databases, it also has the simplicity and efficiency of encryption and decryption methods, all under the premise of being completely free. Attached Figure Description

[0021] Figure 1 This is the overall flowchart of the present invention. Detailed Implementation

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0023] Figure 1 A flowchart illustrating the overall structure of the invention is shown. Figure 1 As shown, the method of the present invention includes the following steps:

[0024] Open the SQLite database and set your own default password. The password's length and character types must meet SQLite's password requirements; for example, it must be at least 8 characters long and include uppercase and lowercase letters, numbers, and special characters. Note that this refers to the open-source SQLite database.

[0025] In the SQLite database code, a custom structure is defined to configure parameters and implement SQLite database encryption. This structure includes the original database password, the original password byte length, the encrypted password encoded using the original database password, the decrypted password encoded using the original database password, a tree structure, etc.

[0026] In one embodiment of the present invention, the following structure code for recording context is used as an example:

[0027] typedef struct my_codec_ctx{

[0028] char*password;

[0029] int pwdLen;

[0030] char* EnKey;

[0031] char*DeKey;

[0032] Btree*m_bt;

[0033] }my_codec_ctx;

[0034] The defined structure is named `my_codec_ctx`. `my_codec_ctx` and its internal parameter variables are defined according to user habits and there is no fixed standard. The parameters `password`, `pwdLen`, `EnKey`, `DeKey`, and `m_bt` represent: the original password, the length of the original password in bytes, the encrypted password encoded using the database's original password (or another data structure), the decrypted password encoded using the database's original password (or another data structure), and the tree structure `B-tree`.

[0035] The original cipher is used to generate the encrypted cipher. The generated encrypted cipher is composed of one or more identifiers added to the original cipher, where the identifiers can be any symbols.

[0036] The decryption cipher is formed by changing the order of the characters in the encryption cipher to generate the decryption cipher. The position of the symbol in the decryption cipher is different from its position in the encryption cipher.

[0037] In one embodiment of the present invention, for the encryption password EnKey and decryption password DeKey in the structure my_codec_ctx, when writing data to an SQLite database, the encryption password EnKey and its corresponding encryption method are used to encrypt and store the data; when reading the data, the decryption password DeKey and its corresponding decryption method are used to decrypt the stored data so that the user can see the plaintext data. Here, different passwords and encryption / decryption methods are generated twice for encryption and decryption processing. Both passwords are generated using the same original password, but the generated results are different. This is done for enhanced security; that is, the so-called database password is not a password provided from the outside, but a password obtained internally after further processing.

[0038] As an embodiment of the present invention, the method for generating encryption and decryption ciphers using primitive cryptography is as follows:

[0039] The original password is processed twice: the encryption key (EnKey) is created by adding a "-" symbol to the end of the original password, and the decryption key (DeKey) is created by reversing the original password and then adding a "-" symbol to the beginning. Therefore, these two keys are different. In short, the general format for both encryption and decryption keys in this embodiment is: symbol + original password in ascending order and original password in reverse order + symbol. The symbol can be any non-numeric / alphanumeric character.

[0040] As an embodiment of the present invention, assuming the original password string is "123456", and its identifier is "-", then the encryption password EnKey is "-123456"; the decryption password DeKey is "654321-", which are exactly the reverse of each other.

[0041] It should be understood that the method for arranging the characters in the encrypted password includes: permutation / combination of characters, and ascending / descending order.

[0042] In another embodiment of the present invention, the characters in the encryption password are not arranged in ascending / descending order. For example, suppose the original password string is "123456", the encryption password string is "135246", and the decryption password string is "246135"; taking the identifier "+-* / ", placing the identifier of the encryption password after the "1" in "135246", and placing the identifier of the decryption password before the "5" in "246135", then the encryption password EnKey is "1+-* / 35246", and the decryption password DeKey is "24613+-* / 5". In other words, it can also be understood as: changing the character order of each character in the encryption password 1+-* / 35246 to generate the decryption password 24613+-* / 5, wherein the character position of the identifier in the decryption password is different from the character position in the encryption password.

[0043] Writing data to an SQLite database: The encrypted password and the data to be written are XORed bitwise, and the result is written to the SQLite database as the encrypted data.

[0044] In one embodiment of the present invention, the encryption algorithm employs an XOR (^) operation to encrypt the data. The specific implementation is as follows:

[0045] for(int a = 0; a <strlen(txt);a++){

[0046] txt[a] = txt[a]^EnKey[0];

[0047] for(int b = 1; b <strlen(EnKey);b++){

[0048] txt[a] = txt[a]^EnKey[b];

[0049] }

[0050] }

[0051] The encryption uses a for loop to extract the input data character by character and XOR it with the existing password character by character. Then the data is put back into the original location, where txt is the original data address.

[0052] In the above embodiment, the first for loop is for detecting the length of the data; the second for loop is for detecting the length of the encryption key; then the data and the key are XORed sequentially and stored in the original location, and finally m_bt stores them in the database file through the SQLite file system.

[0053] Reading data from an SQLite database: The decrypted password and the data to be read are XORed bitwise, and the result is used as the decrypted SQLite database data to be read.

[0054] In one embodiment of the present invention, the decryption algorithm employs an XOR (^) operation to decrypt the data. The specific implementation is as follows:

[0055] for(int a = 0; a <strlen(txt);a++){

[0056] for(int b = 0; b <strlen(DeKey);b++){

[0057] txt[a] = txt[a]^DeKey[b];

[0058] }

[0059] }

[0060] In the above embodiment, txt represents data read from the database. The first for loop searches for data in the database; the second for loop reads the decryption key in a loop; then, the data read from the database and the key are XORed sequentially and stored back in their original locations, thus completing the decryption process.

[0061] The method provided by this invention solves the technical problem that there is no existing method for custom encryption and decryption of SQLite.

[0062] It should be understood that the present invention is not limited to the examples described above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A method for custom encryption / decryption of SQLite, characterized in that... Includes the following steps: Open the SQLite database and set the original password yourself. The length and type of the original password meet the password requirements of the SQLite database. The SQLite database is an open-source SQLite database. A custom structure is defined in the code of the SQLite database to configure parameters and implement the encryption of the SQLite database. The structure includes the original database password, the original password byte length, a tree structure, the encrypted password generated after encoding with the original database password, and the decrypted password generated after encoding with the original database password. The encryption and decryption passwords are generated using the original password. The data writing to the SQLite database is as follows: the encryption password is XORed with the data to be written by word bits, and the result is written to the SQLite database as the encrypted data. Reading data from an SQLite database: The decryption password and the data to be read are XORed bitwise, and the result is used as the result of reading the decrypted SQLite database data.

2. The method for custom encryption / decryption of SQLite according to claim 1, characterized in that, The encryption password is composed of the following characters: the original password is modified by adding one or more identifiers, and the identifiers are arbitrary symbols.

3. The method for custom encryption / decryption of SQLite according to claim 1, characterized in that, The decryption password is composed of characters arranged in a different order than the encryption password.

4. The method for custom encryption / decryption of SQLite according to claim 1, characterized in that, Methods for changing the character order of the encrypted password include: arranging / combining the characters, and arranging them in ascending / descending order.

Images