Key generation method, device, equipment, medium and program product

Abstract

The present application discloses a key generation method, device, equipment, medium and program product, the method comprising: using the root key of the requesting end to encrypt the first preset data, obtaining the root key verification value of the requesting end, and sending the root key verification value of the requesting end to the database; receiving the verification result of the root key of the database sent by the database; generating the session key of the requesting end based on the root key of the requesting end when the verification result indicates that the root key of the database is consistent with the root key of the requesting end; determining whether the session key of the requesting end is consistent with the session key of the database; the session key of the database is generated based on the root key of the database; when the session key of the requesting end is consistent with the session key of the database, determining the session key of the requesting end as the current session key of the communication between the requesting end and the database. In this way, the security of the requesting end when accessing the database can be improved.

Description

Technical Field

[0001] The present application relates to, but is not limited to, the field of information security technology, and in particular to a key generation method, device, equipment, medium and program product. Background Art

[0002] A database is a warehouse that organizes, stores, and manages data according to data structures. Databases can include relational databases (such as MySQL) and non-relational databases (such as MongoDB). However, whether it is a relational database or a non-relational database, when authenticating the access end, the account password is used for authentication. The account password can be easily obtained by a third party, thereby reducing the security of the access end when accessing the database. Summary of the invention

[0003] In view of this, the embodiments of the present application at least provide a key generation method, apparatus, device, medium and program product.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] In a first aspect, an embodiment of the present application provides a key generation method, which is applied to a requesting end; the key generation method includes:

[0006] The first preset data is encrypted using the root key of the requesting end to obtain a root key verification value of the requesting end, and the root key verification value of the requesting end is sent to the database; the root key verification value of the requesting end is used to verify the root key of the database;

[0007] Receiving a verification result of a root key of a database sent by the database; if the verification result indicates that the root key of the database is consistent with the root key of the requesting end, generating a session key of the requesting end based on the root key of the requesting end;

[0008] Determining whether the session key of the requesting end is consistent with the session key of the database; the session key of the database is generated based on the root key of the database;

[0009] In the case where the session key of the requesting end is consistent with the session key of the database, the session key of the requesting end is determined as the current session key for communication between the requesting end and the database.

[0010] In the embodiment of the present application, by sending the root key verification value of the requesting end encrypted by the root key of the requesting end to the database, the database can verify the root key of the database through the root key verification value of the requesting end to complete the first key negotiation. Then determine whether the session key of the requesting end generated by the root key of the requesting end is consistent with the session key of the database to complete the second key negotiation. Finally, the session key of the requesting end that is consistent with the session key of the database is determined as the current session key for the communication between the requesting end and the database. In this way, by verifying the root key and verifying the session key, two key negotiations between the database and the requesting end can be achieved, so that when the requesting end uses the current session key obtained after two key negotiations to interact with the database, compared with the prior art through the account and password password, the security of the requesting end when accessing the database is improved, and the authentication efficiency is also improved (that is, there is no need for the user to enter the account and password).

[0011] In a second aspect, an embodiment of the present application provides a key generation method, which is applied to a database; the key generation method includes:

[0012] Receiving a root key check value of the requesting end sent by the requesting end; the root key check value of the requesting end is obtained by encrypting the first preset data using the root key of the requesting end;

[0013] Based on the root key verification value of the requesting end, verify the root key of the database to obtain a verification result of the root key of the database;

[0014] If the verification result indicates that the root key of the database is consistent with the root key of the requesting end, generating a session key of the database based on the root key of the database;

[0015] When the session key of the database is consistent with the session key of the requesting end, the session key of the database is determined as the current session key for communication between the database and the requesting end; the session key of the requesting end is generated based on the root key of the requesting end.

[0016] In a third aspect, an embodiment of the present application provides a key generation device, which is applied to a requesting end; the key generation device includes:

[0017] A first encryption unit is used to encrypt the first preset data using the root key of the requesting end, obtain the root key verification value of the requesting end, and send the root key verification value of the requesting end to the database; the root key verification value of the requesting end is used to verify the root key of the database;

[0018] A first receiving unit, configured to receive a verification result of a root key of a database sent by the database;

[0019] A first generating unit, configured to generate a session key of the requesting end based on the root key of the requesting end when the verification result indicates that the root key of the database is consistent with the root key of the requesting end;

[0020] A first determining unit, configured to determine whether the session key of the requesting end is consistent with the session key of the database; the session key of the database is generated based on the root key of the database;

[0021] The first determining unit is further configured to determine the session key of the requesting end as a current session key for communication between the requesting end and the database when the session key of the requesting end is consistent with the session key of the database.

[0022] In a fourth aspect, an embodiment of the present application provides a key generation device, including a memory and a processor, wherein the memory stores a computer program that can be executed on the processor, and when the processor executes the program, some or all of the steps in the above method are implemented.

[0023] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements some or all of the steps in the above method when executed by a processor.

[0024] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions, which implement some or all of the steps in the above method when executed by a processor.

[0025] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.

[0027] Figure 1 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 1 ;

[0028] Figure 2 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 2 ;

[0029] Figure 3 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 3 ;

[0030] Figure 4 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 4 ;

[0031] Figure 5 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 5 ;

[0032] Figure 6 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 6 ;

[0033] Figure 7 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 7 ;

[0034] Figure 8 A schematic diagram of the architecture of a database provided in an embodiment of the present application;

[0035] Fig. 9 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 8 ;

[0036] Fig.10 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 9 ;

[0037] Fig.11 A schematic diagram of the implementation process of a key generation method provided in an embodiment of the present application Figure 10 ;

[0038] Fig.12 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 1 ;

[0039] Fig.13 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 2 ;

[0040] Fig.14 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 3 ;

[0041] Fig.15 A schematic diagram of the structure of a key generation device provided in an embodiment of the present application Figure 1 ;

[0042] Fig.16 A schematic diagram of the structure of a key generation device provided in an embodiment of the present application Figure 2 ;

[0043] Fig.17 A schematic diagram of a hardware entity of a key generation device in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0045] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0046] The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that "first / second / third" can be interchanged with a specific order or sequence where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0047] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing this application and are not intended to limit this application.

[0048] Before describing the key generation method in the embodiment of the present application, the professional terms involved in the embodiment of the present application are first explained:

[0049] SM2 algorithm: an asymmetric cryptographic algorithm based on elliptic curve.

[0050] SM4 algorithm: A symmetric encryption algorithm, also known as the SM4 block cipher algorithm.

[0051] PBKDF2 (Password-Based Key Derivation Function 2): used to derive keys through a pseudo-random function.

[0052] Transmission Control Protocol (TCP): A connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0053] Hypertext Transfer Protocol (HTTP): is a simple request-response protocol. HTTP usually runs on top of TCP.

[0054] JSON (JavaScript Object Notation): is a lightweight data exchange format.

[0055] TLV (Tag-Length-Value): data exchange format with data type and length.

[0056] Golang: A statically strongly typed, compiled language.

[0057] Hash-based Message Authentication Code (HMAC): A method of message authentication based on a hash function and a key.

[0058] Digital Envelope Cryptography: A method of distributing symmetric keys as the result of asymmetric encryption to ensure confidentiality.

[0059] CBCMAC: Message Authentication Code for Cipher Block Chaining (CBC) mode ciphertext.

[0060] Message Authentication Code (MAC): Used to check whether the content of a message has been changed during the message transmission process.

[0061] DBROOT: The root key jointly determined by the requester and the database.

[0062] DBSM2: DBROOT is based on SM2 key pair derived from PBKDF2.

[0063] DBDEK: Data encryption key derived by DBROOT based on PBKDF2.

[0064] DBDMK: Data MAC authentication key derived by DBROOT based on PBKDF2.

[0065] In order to solve the problems of the related art, the embodiment of the present application provides a key generation method, which can be applied to the request end, such as Figure 1 As shown, the key generation method can be implemented through steps S101 to S105:

[0066] Step S101: encrypt first preset data using the root key of the requesting end to obtain a root key verification value of the requesting end, and send the root key verification value of the requesting end to a database.

[0067] The root key verification value of the requesting end is used to verify the root key of the database.

[0068] Here, the requesting end may be a business system for accessing a database. Exemplarily, the business system may be a cryptographic service platform or a key management system. In an embodiment of the present application, the requesting end may send a root key verification value of the requesting end to the database before formally accessing the database.

[0069] It is understandable that before the requester formally accesses the database, the database needs to authenticate the requester first, and the database needs the corresponding key to authenticate the requester. Therefore, the requester can determine the corresponding key by sending the root key check value of the requester to complete the database's authentication of the requester. In other words, the requester needs to re-determine the corresponding key every time it accesses the database. In this way, the security of the database can be improved.

[0070] In the embodiment of the present application, the first preset data is data pre-agreed between the requesting end and the database, and the encryption method for encrypting the first preset data using the root key of the requesting end is also an encryption method pre-agreed between the requesting end and the database. The encryption method may be a symmetric encryption method, and exemplarily, the encryption method may be an SM4 algorithm.

[0071] In an embodiment of the present application, when the requesting end performs the first key negotiation with the database, the requesting end may use its own root key of the requesting end to encrypt the first preset data, and then send the encrypted root key verification value of the requesting end to the database.

[0072] It is understandable that the requesting end does not directly send the root key of the requesting end to the database, nor does it encrypt the root key of the requesting end and then send the encrypted root key of the requesting end to the database. This is because when the root key of the requesting end is used as the interactive data between the requesting end and the database, whether the root key of the requesting end is encrypted or not, there is a risk of being obtained by a third party. In an embodiment of the present application, the requesting end uses the root key of the requesting end to encrypt the first preset data, and uses the encrypted root key check value of the requesting end as the interactive data between the requesting end and the database. In this way, even if a third party obtains the root key check value of the requesting end, it cannot obtain the root key of the requesting end, thereby improving the security of the first key negotiation between the requesting end and the database.

[0073] Step S102: receiving the verification result of the root key of the database sent by the database.

[0074] Here, the verification result of the root key of the database is determined by the database based on the root key verification value of the requesting end. The verification result of the root key of the database is used to indicate whether the root key of the database is consistent with the root key of the requesting end.

[0075] In some embodiments, the database can use the database's root key to encrypt the first preset data in the same encryption method to obtain the database's root key verification value, and determine the verification result of the database's root key by comparing the database's root key verification value with the root key verification value of the requesting end.

[0076] Step S103: when the verification result indicates that the root key of the database is consistent with the root key of the requesting end, a session key of the requesting end is generated based on the root key of the requesting end.

[0077] In an embodiment of the present application, after receiving the verification result of the root key of the database, the requesting end can determine whether the root key of the database is consistent with the root key of the requesting end through the verification result. When the verification result indicates that the root key of the database is consistent with the root key of the requesting end, the requesting end can generate the session key of the requesting end based on the root key of the requesting end.

[0078] In some embodiments, step S103 may be implemented by the following steps:

[0079] Step S1031, using a preset key generation algorithm, processing the preset salt value, the number of iterations, the root key of the requesting end, and the second byte length to obtain the session key of the requesting end.

[0080] Here, the second byte length is the byte length of the session key of the requesting end, and different session keys of different requesting ends correspond to different byte lengths.

[0081] In some embodiments, the session key of the requesting end may be implemented by formula (1):

[0082] The session key of the requesting end = PBKDF2 (q, salt, iteration, keyLen) formula (1);

[0083] Wherein, q is the root key of the requesting end; salt is the preset salt value; iteration is the number of iterations; keyLen is the byte length corresponding to the session key of the requesting end. For example, when the session key of the requesting end is DBSM2, keyLen is 32 bytes; when the session key of the requesting end is DBDEK or DBDMK, keyLen is 16 bytes.

[0084] In an embodiment of the present application, when the session key of the requesting end is DBSM2, the session key of the requesting end can be applied to digital envelope encryption and HMAC; when the session key of the requesting end is DBDEK, the session key of the requesting end can be applied to signature verification, CBCMAC and symmetric data encryption; when the session key of the requesting end is DBDMK, the session key of the requesting end can be applied to signature verification and CBCMAC.

[0085] Step S104, determining whether the session key of the requesting end is consistent with the session key of the database.

[0086] The session key of the database is generated based on the root key of the database.

[0087] In the embodiment of the present application, after the requesting end and the database complete the first key negotiation, a second key negotiation is required, that is, to determine whether the session keys of the two are consistent.

[0088] In some embodiments, the requester may request to obtain a session key of the database, and then determine whether the session key of the database is consistent with the session key of the requester.

[0089] In some embodiments, the requesting end may also request to obtain ciphertext data encrypted by the database using the database's session key, and determine whether the database's session key is consistent with the requesting end's session key through the ciphertext data.

[0090] Step S105: When the session key of the requesting end is consistent with the session key of the database, the session key of the requesting end is determined as the current session key for communication between the requesting end and the database.

[0091] The session key of the database is generated based on the root key of the database.

[0092] In an embodiment of the present application, when the session key of the requesting end is consistent with the session key of the database, it means that the requesting end and the database have completed the second key negotiation. At this time, the requesting end can determine the session key of the requesting end as the current session key used for formal access to the database and communication with the requesting end. For example, the current session key is used for identity authentication, data transmission, etc. during the formal access.

[0093] In the embodiment of the present application, by sending the root key verification value of the requesting end encrypted by the root key of the requesting end to the database, the database can verify the root key of the database through the root key verification value of the requesting end to complete the first key negotiation. Then determine whether the session key of the requesting end generated by the root key of the requesting end is consistent with the session key of the database to complete the second key negotiation. Finally, the session key of the requesting end that is consistent with the session key of the database is determined as the current session key for the communication between the requesting end and the database. In this way, by verifying the root key and verifying the session key, two key negotiations between the database and the requesting end can be achieved, so that when the requesting end uses the current session key obtained after two key negotiations to interact with the database, compared with the prior art through the account and password password, the security of the requesting end when accessing the database is improved, and the authentication efficiency is also improved (that is, there is no need for the user to enter the account and password).

[0094] In some embodiments, Figure 2 As shown, the above step S104 can be implemented through steps S201 to S203:

[0095] Step S201, receiving a database session key verification value sent by a database; the database session key verification value is obtained by encrypting second preset data using the database session key.

[0096] In the embodiment of the present application, the database can use the session key of the database to encrypt the second preset data, and send the encrypted session key verification value of the database to the requesting end. The process of database encryption can refer to the above embodiment.

[0097] Step S202: encrypt the second preset data using the session key of the requesting end to obtain a session key verification value of the requesting end.

[0098] In the embodiment of the present application, the requesting end may encrypt the second preset data using an encryption method pre-determined with the requesting end, using the session key of the requesting end. Exemplarily, the encryption method may be an SM4 algorithm.

[0099] In an embodiment of the present application, the number of session keys of the requesting end is the same as the number of session keys of the database. Therefore, if the number of session keys of the requesting end is at least two, the session keys of every two databases are used to encrypt the second preset data to obtain at least two session key verification values ​​of the requesting end, and the session key verification values ​​of the requesting end correspond one-to-one to the session keys of the requesting end.

[0100] Step S203: Based on the session key verification value of the requesting end and the session key verification value of the database, determine whether the session key of the database is consistent with the session key of the requesting end.

[0101] It is understandable that the database and the requesting end encrypt the same second preset data through the same encryption method. If the encryption keys used by the two are also the same, the session key check value of the database and the session key check value of the requesting end should be consistent. Therefore, when the session key check value of the database is consistent with the session key check value of the requesting end, it is determined that the session key of the database is consistent with the session key of the requesting end. When the session key check value of the database is inconsistent with the session key check value of the requesting end, it is determined that the session key of the database is inconsistent with the session key of the requesting end.

[0102] In some embodiments, if the number of session keys of the requesting end is at least two, the number of session keys of the database is also at least two, that is, the session key verification value of the database and the session key verification value of the requesting end are both at least two, and it is necessary to compare the session key verification value of the database and the session key verification value of the requesting end of the same type. The consistency of type here means that the type of the session key of the database is consistent with that of the session key of the requesting end. For example, when the session key of the database and the session key of the requesting end both include DBSM2, DBDEK, and DBDMK, the consistency of the session key verification value of the database encrypted by DBSM2 and the session key verification value of the requesting end encrypted by DBSM2 are compared respectively, the consistency of the session key verification value of the database encrypted by DBDEK and the session key verification value of the requesting end encrypted by DBSM2, and the consistency of the session key verification value of the database encrypted by DBDMK and the session key verification value of the requesting end encrypted by DBSM2 are compared respectively.

[0103] In some embodiments, if the number of session key verification values ​​of the database received by the requesting end is inconsistent with the number of session keys of the requesting end, the session key verification value of the requesting end may not be generated, and it is determined that the second key negotiation has failed.

[0104] In the embodiment of the present application, the requesting end can determine whether the session key of the database is consistent with the session key of the requesting end based on the session key check value of the requesting end obtained by encrypting the session key of the requesting end and the session key check value of the database sent by the database. Because, during the second negotiation of the key between the requesting end and the database, the session key is not transmitted in plain text, nor is it used as transmission data, so that the situation of session key leakage caused by a third party intercepting the interactive information between the database and the requesting end during the second key negotiation can be reduced, thereby improving the security of the database.

[0105] In some embodiments, the key generation method applied to the requesting end may also be implemented by the following steps:

[0106] Step 1: Send a key generation request carrying the public key of the requesting end to the database.

[0107] In an embodiment of the present application, the requesting end may first generate a key pair of the requesting end using a preset asymmetric key algorithm. Exemplarily, the asymmetric key algorithm may be an SM2 algorithm. Then, the requesting end sends its own public key to the database.

[0108] Step 2: Receive the public key of the database sent by the database in response to the key generation request.

[0109] Step 3: Generate the root key of the requester based on the public key of the database and the private key of the requester.

[0110] The database is used to generate a root key of the database based on the public key of the requesting end and the private key of the database.

[0111] In some embodiments, the root key of the requesting end may be generated by formula (2):

[0112] q=d1[*]p2-n[*]G Formula (2);

[0113] Among them, q is the root key of the requesting end, d1 is the private key of the requesting end, p2 is the public key of the database, [*] represents the point multiplication algorithm; the value range of n is [0, N], N is the order of the point G of the SM2 elliptic curve; G is the base point in the SM2 elliptic curve.

[0114] In an embodiment of the present application, after the database sends the public key of the database to the requesting end in response to the key generation request, the requesting end can generate the root key of the requesting end based on the public key of the database and the private key of the requesting end.

[0115] In some embodiments, the root key of the database may be generated by formula (3):

[0116] p=d2[*]p1-n[*]G Formula (3);

[0117] Among them, p is the root key of the database, d2 is the private key of the database, and p1 is the public key of the requesting end; the value range of n is [0, N], N is the order of point G of the SM2 elliptic curve; G is the base point in the SM2 elliptic curve.

[0118] Because the public key p2 of the database can be represented by d2[*]G, and the public key p1 of the requester can be represented by d1[*]G, substituting p2=d2[*]G into formula (2) and p1=d1[*]G into formula (1), we can get:

[0119] q=d1[*]d2[*]Gn[*]G=d2[*]d1[*]Gn[*]G=p Formula (4).

[0120] From formula (4), it can be seen that if the requesting end is legitimate, the root key q of the requesting end is consistent with the root key p of the database. Therefore, through the first key negotiation between the requesting end and the database, the root key used to generate the session key can be determined, and thus whether the requesting end is legitimate can also be determined.

[0121] In the embodiment of the present application, by receiving the public key of the data end, the root key of the request end can be generated based on the public key of the data end and the private key of the request end. In this way, because the private key of the request end is not transmitted externally, even if a third party obtains the public key of the data end, it cannot obtain the root key of the request end, thereby improving the security of the root key of the request end.

[0122] In some embodiments, the session key of the requesting end includes at least one authentication key and at least one encryption key; after step S105, the above method can also be implemented by the following steps:

[0123] Step S106: Generate authentication information based on the target authentication key in the at least one authentication key and the authentication algorithm corresponding to the target authentication key, and send the authentication information to the database.

[0124] In the embodiment of the present application, when the requesting end determines the session key of the requesting end as the current session key for the requesting end to communicate with the database, the currently used authentication algorithm can be first determined from a plurality of preset authentication algorithms, and then the target authentication key corresponding to the authentication algorithm is determined from at least one authentication key in the session key of the requesting end. Finally, based on the target authentication key and the authentication algorithm corresponding to the target authentication key, authentication information is generated, and the authentication information is sent to the database, and the database can use the authentication algorithm corresponding to the target authentication key to authenticate the identity of the requesting end based on the authentication information.

[0125] Exemplarily, the authentication algorithm includes at least one of the following: a signature verification algorithm, a key-related hash operation message authentication algorithm, and a symmetric key-based block encryption algorithm. In the case where the requesting end's session key includes DBDEK, DBDMK, and DBSM2, the authentication key corresponding to the signature verification algorithm may be DBDEK or DBDMK, the authentication key corresponding to the key-related hash operation message authentication algorithm may be DBSM2, and the authentication key corresponding to the symmetric key-based block encryption algorithm may be DBDEK or DBDMK.

[0126] Step S107, when the identity authentication of the requesting end is successful, encrypt the data to be stored using the target encryption key in the at least one encryption key and the encryption algorithm corresponding to the target encryption key, and send the encrypted data to be stored to the database;

[0127] In an embodiment of the present application, after successful identity authentication, the requesting end can first determine the currently used encryption algorithm among multiple encryption authentication algorithms, and then determine the target encryption key corresponding to the encryption algorithm from at least one encryption key in the session key of the requesting end.

[0128] Exemplarily, the encryption algorithm includes at least one of the following: a digital envelope encryption algorithm and a symmetric encryption algorithm. When the session key of the requesting end includes DBDEK, DBDMK and DBSM2, the encryption key corresponding to the digital envelope encryption algorithm may be DBSM2, and the encryption key corresponding to the symmetric encryption algorithm may be DBDEK.

[0129] In an embodiment of the present application, the requesting end selects a target authentication key from at least one authentication key, thereby using an authentication algorithm corresponding to the target authentication key for identity authentication; and the requesting end can also select a target encryption key from at least one encryption key when the authentication is passed, thereby using an encryption algorithm corresponding to the target encryption key to encrypt the stored data. In this way, the flexibility of identity authentication and data encryption of the requesting end can be improved.

[0130] In some embodiments, the present application also provides a key generation method, which can be applied to a database. Figure 3 As shown, the key generation method can be implemented through steps S301 to S304:

[0131] Step S301, receiving the root key verification value of the requesting end sent by the requesting end.

[0132] Step S302: verify the root key of the database based on the root key verification value of the requesting end to obtain a verification result of the root key of the database.

[0133] Here, the root key of the database is obtained by the database using a preset generation method. The preset generation method is the same as the method in which the requesting end generates the root key of the requesting end. That is to say, in the absence of interference from a third party, the root key of the requesting end is consistent with the root key of the database, that is, the first key negotiation between the database and the requesting end is successful.

[0134] It can be understood that, because the request end uses the root key of the request end to encrypt the first preset data, the encryption method is pre-agreed between the request end and the database, and the encryption method is a symmetric encryption method. Therefore, after the database obtains the root key verification value of the request end, the root key of the database can be used to decrypt the root key verification value of the request end. If the first preset data can be decrypted, it means that the root key of the request end is consistent with the root key of the database; if the first preset data cannot be decrypted, it means that the root key of the request end is inconsistent with the root key of the database. In other embodiments, the database can also use the root key of the database to encrypt the first preset data through the same encryption method to obtain the root key verification value of the database, and determine the verification result of the root key of the database by comparing the consistency of the root key verification value of the database with the root key verification value of the request end.

[0135] Step S303: When the verification result indicates that the root key of the database is consistent with the root key of the requesting end, a session key of the database is generated based on the root key of the database.

[0136] In the embodiment of the present application, after the database generates the session key of the database, it needs to perform a second key negotiation with the requesting end, that is, to verify the consistency between the session key of the database and the session key of the requesting end.

[0137] It is understandable that when the root key of the database is consistent with the root key of the requesting end, it means that the root key of the requesting end is legal, that is, the first key negotiation between the database and the requesting end is successful. At this time, the database can generate a session key of the database based on the root key of the database. Here, the session key of the database is the key used by the requesting end to formally access the database. In some embodiments, the database can generate session keys for multiple databases according to different application scenarios. Exemplarily, different application scenarios may include two-end identity authentication and two-end data transmission, wherein two-end identity authentication can be implemented by at least one of signature verification, HMAC and CBCMAC; two-end data transmission can be implemented by at least one of digital envelope encryption and symmetric data encryption.

[0138] In an embodiment of the present application, the database may use a preset key generation algorithm to generate a session key of the database based on the root key of the database. Exemplarily, the preset key generation algorithm may be PBKDF2.

[0139] Step S304: when the session key of the database is consistent with the session key of the requesting end, the session key of the database is determined as the current session key for communication between the database and the requesting end.

[0140] It is understandable that, because the root key is not the key used by the requesting end to formally access the database, after the database generates the session key of the database based on the root key of the requesting end, it is necessary to continue to verify the consistency of the session key of the database with the session key of the requesting end. Among them, the session key of the requesting end is generated based on the root key based on the requesting end, and the way in which the requesting end generates the session key of the requesting end is the same as the way in which the database generates the session key of the database. Therefore, in the case where the requesting end is a legal terminal, the session key of the database and the session key of the requesting end should be consistent. Therefore, in order to further improve the security of the database, it is necessary to verify the consistency of the session key of the database with the session key of the requesting end.

[0141] In the embodiment of the present application, the method of verifying the consistency between the session key of the database and the session key of the requesting end may be the same as the method of verifying the consistency between the root key of the database and the root key of the requesting end.

[0142] In an embodiment of the present application, when the session key of the database is consistent with the session key of the requesting end, it indicates that the requesting end is a legitimate terminal, that is, the second key negotiation between the requesting end and the database is successful, then the session key of the database can be determined as the current session key for communication between the database and the requesting end.

[0143] In some embodiments, because the session key of the database is consistent with the session key of the requesting end, the session key of the database and the session key of the requesting end are both the current session keys for the communication between the requesting end and the database. The requesting end can use the current session key to formally access the database for identity authentication, data transmission, etc.

[0144] In the embodiment of the present application, the root key of the database in the database is verified by the root key verification value of the requesting end sent by the requesting end. When the verification result indicates that the root key of the database is consistent with the root key of the requesting end, the session key of the database is generated based on the root key of the database. When the session key of the database is consistent with the session key of the requesting end, the session key of the database is determined as the current session key for communication between the database and the requesting end. In this way, by verifying the root key and verifying the session key, two key negotiations between the database and the requesting end can be achieved, so that a session key with higher security can be obtained, and then when the requesting end uses the current session key obtained after two key negotiations to interact with the database, the security of the requesting end when accessing the database is improved.

[0145] In some embodiments, Figure 4 As shown, the key generation method can also be implemented by the following steps S401 and S402, and the above step S304 can be implemented by step S403:

[0146] Step S401, encrypting the second preset data using the session key of the database to obtain a session key verification value of the database.

[0147] In an embodiment of the present application, the database can encrypt the second preset data using the session key of the database through an encryption method pre-determined with the requesting end. The second preset data is data pre-agreed between the requesting end and the database, and the above encryption method can be the same as the encryption method for obtaining the root key check value of the requesting end, that is, a symmetric encryption method. Exemplarily, the above encryption method can be an SM4 algorithm.

[0148] In some embodiments, if the number of database session keys is at least two, the second preset data is encrypted using the session key of each database to obtain session key verification values ​​of at least two databases, and the session key verification values ​​of the databases correspond one-to-one to the session keys of the databases.

[0149] Step S402: Send the session key verification value of the database to the requesting end.

[0150] The session key verification value of the database is used to verify the consistency between the session key of the database and the session key of the requesting end.

[0151] In the embodiment of the present application, after the requesting end receives the session key verification value of the database, the session key verification value of the database can be compared with the session key verification value of the requesting end to obtain a verification result of whether the session key of the database is consistent with the session key of the requesting end. The session key verification value of the requesting end is obtained by encrypting the session key verification value of the database using the session key of the requesting end.

[0152] Step S403, when the verification result determined based on the database session key verification value indicates that the database session key is consistent with the requesting end session key, the database session key is determined as the current session key for communication between the database and the requesting end.

[0153] In an embodiment of the present application, after the requesting end determines the verification result of whether the session key of the database is consistent with the session key of the requesting end, the verification result can be sent to the database. When the database determines that the verification result indicates that the session key of the database is consistent with the session key of the requesting end, the database session key is determined as the current session key for communication between the database and the requesting end.

[0154] In some embodiments, the requesting end may not send the verification result of whether the session key of the database is consistent with the session key of the requesting end to the database. In this case, if the requesting end determines that the session key of the database is consistent with the session key of the requesting end, the database can be formally accessed using the session key of the database. When the database receives the formal access request from the requesting end, it can determine the verification result determined based on the session key check value of the database, indicating that the session key of the database is consistent with the session key of the requesting end. At this time, the database can determine the session key of the database as the current session key for communication between the database and the requesting end.

[0155] In the embodiment of the present application, the database can use its own database session key to encrypt the second preset data to obtain the database session key verification value, and then send the database session key verification value to the requesting end, so that the requesting end verifies the database session key and the requesting end session key through the database session key verification value. In this way, by sending the database session key verification value to the requesting end, the second key negotiation between the database and the requesting end can be achieved, thereby improving the security of the database.

[0156] In some embodiments, Figure 5 As shown, the above step S302 can be implemented by the following steps S501 to S503:

[0157] Step S501: encrypt first preset data using a root key of a database to obtain a root key verification value of the database.

[0158] In the embodiment of the present application, the database can encrypt the first preset data using the root key of the database through an encryption method agreed with the requesting end to obtain the root key check value of the database. The encryption method can be a symmetric encryption method. Exemplarily, the encryption method can be SM4.

[0159] Step S502: when the root key verification value of the database is consistent with the root key verification value of the requesting end, determine the verification result that the root key of the database is consistent with the root key of the requesting end.

[0160] Step S503: when the root key verification value of the database is inconsistent with the root key verification value of the requesting end, a verification result that the root key of the database is inconsistent with the root key of the requesting end is determined.

[0161] In an embodiment of the present application, the root key verification value of the database and the root key verification value of the requesting end sent by the requesting end can be compared, and the comparison result obtained can be determined as the verification result of the root key of the database.

[0162] It is understandable that the database and the request end encrypt the same first preset data through the same encryption method. If the encryption keys used by the two are also the same, the root key check value of the request end and the root key check value of the database should be consistent. Therefore, when the root key check value of the database is consistent with the root key check value of the request end, it is determined that the root key of the database is consistent with the root key of the request end. When the root key check value of the database is inconsistent with the root key check value of the request end, it is determined that the root key of the database is inconsistent with the root key of the request end.

[0163] In the embodiment of the present application, by comparing the consistency of the root key check value of the database obtained by encrypting the first preset data with the root key of the database and the root key check value of the request end obtained by encrypting the first preset data with the root key of the request end, the consistency of the root key of the database and the root key of the request end can be determined, thereby completing the first key negotiation between the database and the request end. Because the root key is not transmitted in plain text or as transmission data, it can reduce the leakage of the root key due to the third party intercepting the interactive information between the database and the request end during the first key negotiation, thereby improving the security of the database.

[0164] In some embodiments, the key generation method may further include: updating, in a whitelist interface of the requesting end, a current session key for communication between the requesting end and the database.

[0165] The shared requesting end that shares a database with the requesting end is used to obtain the current session key in the whitelist interface; and communicate with the database based on the current session key.

[0166] In the embodiment of the present application, the number of shared request terminals can be at least one, and at least one shared request terminal and the request terminal share a database, that is, the data generated by at least one shared request terminal and the request terminal can be stored in the database.

[0167] It is understandable that when the requesting end successfully negotiates the key with the database and obtains the current session key, the current session key for communication between the requesting end and the database can be updated in the whitelist interface of the requesting end. In this way, subsequent shared requesting ends do not need to negotiate the key with the database.

[0168] In some embodiments, the key generation method may further include: obtaining the data to be synchronized from the database based on the current session key; and sending the data to be synchronized to other requesting ends.

[0169] Among them, other requesting ends are used to store the data to be synchronized in other databases based on other session keys; other session keys are keys obtained by negotiation between other requesting ends and other databases.

[0170] In the embodiment of the present application, the number of other requesting terminals may be at least one. When the requesting terminal generates business data, it may synchronize at least one other requesting terminal. In this way, data synchronization may be achieved on the application layer between the at least one other requesting terminal and the cluster formed by the requesting terminal, so that the data is consistent.

[0171] In some embodiments, Figure 6 As shown, the above key generation method can also be implemented by the following steps S601 and S602:

[0172] Step S601: receiving a key generation request sent by a requesting end and carrying the public key of the requesting end.

[0173] Step S602: In response to the key generation request, the public key of the database is sent to the requesting end, and the root key of the database is generated based on the public key of the requesting end and the private key of the database.

[0174] In the embodiment of the present application, the database may first use the above-mentioned preset asymmetric key algorithm to generate a key pair of the database. Then, in response to the key generation request, the public key of the database is sent to the requesting end, and the root key of the database is generated based on the public key of the requesting end and the private key of the database. Among them, the step of sending the public key of the database to the requesting end and the step of generating the root key of the database are not in order, and can be performed simultaneously or sequentially.

[0175] In some embodiments, the root key of the database can be implemented by the above formula (3).

[0176] In the embodiment of the present application, by receiving the public key of the requesting end, the root key of the database can be generated based on the public key of the requesting end and the private key of the database. In this way, because the private key of the database is not transmitted externally, even if a third party obtains the public key of the requesting end, it cannot obtain the root key of the database, thereby improving the security of the root key.

[0177] In some embodiments, Figure 7 As shown, the above method further includes step S701; step S303 can be implemented through step S702:

[0178] Step S701, receiving a preset salt value and number of iterations sent by a requesting end.

[0179] In an embodiment of the present application, the requesting end may first use a root key through a preset encryption method to encrypt a preset salt value and a number of iterations, and send the encrypted data to the requesting end.

[0180] In some embodiments, when the verification result of the root key of the database received by the requesting end indicates that the root key of the database is consistent with the root key of the requesting end, a preset salt value and the number of iterations are sent to the database.

[0181] Step S702, when the verification result indicates that the root key of the database is consistent with the root key of the requesting end, a preset key generation algorithm is used to process the preset salt value, the number of iterations, the root key of the database and the first byte length to obtain the session key of the database.

[0182] Here, the first byte length is the byte length of the session key of the database, and different session keys of different databases correspond to different byte lengths.

[0183] Because, after the requesting end and the database perform the first key negotiation, the root key of the requesting end and the root key of the database are consistent, and the first byte length and the second byte length are also consistent, therefore, the session key of the database can be implemented by the above formula (1).

[0184] In the embodiment of the present application, by receiving the preset salt value and the number of iterations sent by the requesting end, a preset key generation algorithm can be used to generate a session key of the database. Because the root key of the database will not be exchanged between the database and the requesting end, even if a third party intercepts the preset salt value and the number of iterations, it cannot obtain the session key of the database, thereby improving the security of the session key of the database.

[0185] The following examples illustrate the application of the database construction method provided in the embodiments of the present application in actual scenarios. Figure 8 A schematic diagram of the architecture of a database provided in an embodiment of the present application. Figure 8 As shown, the database 820 is used to interact with the business end 810 (which can be understood as the request end in the previous text) to store the data to be stored by the business end 810, and provide the business end 810 with functions such as query, deletion or modification of the stored data. The database 820 supports data transmission based on HTTP and TCP. When the database 820 transmits data based on HTTP, the format of the data is JSON; when the database 820 transmits data based on TCP, the format of the data is TLV.

[0186] In the embodiment of the present application, the interactive data between the service end 810 and the database 820 may include key data and service data obtained through negotiation between the service end 810 and the database 820. The key data may include the current session key in the above embodiment; the service data refers to the data generated by the user accessing other applications through the service end and needs to be stored in the database. Exemplarily, the current session key includes an SM2 key pair, an RSA key pair, a symmetric PINKEY and a MACKEY.

[0187] For example, data in JSON data format can be: {"key1":"data1","key2":"data2",...}. Data in TLV data format can be: Key1\x00\x05data1key2\x00\x06data11..., and the transmission method can be: using restfull data protocol based on HTTP transmission.

[0188] On the one hand, the database 820 establishes a management service 821 for the local disk 822 by setting a management interface, including determining authentication and encryption methods, creating tables or records, etc. The database 820 also establishes a data storage service 823 for implementing data insertion, deletion, modification or query functions on the local disk 822 by setting a business interface. In other embodiments, the management interface is also used to implement a data persistence strategy, which is used to configure the method and frequency of data persistence on the disk.

[0189] The management interface of the database 820 includes: db_open (ip, port); db_derivekey (salt, iterate); db_init (authmode, encmod, syncstrategy, transmitprotomode);

[0190] The business interfaces of database 820 include: command interface for creating database (db_createdb, dbname), function interface for creating table (db_createtable (tablename, tablestructs)), interface for inserting record (db_insert (data, datalen)), interface for deleting record (db_delete (condition, conditonlen)), interface for updating data (db_update (condition, conditonlen, data, datalen)), interface for building query statement db_select (condition, conditonlen), interface for deleting table db_droptable (tablename), interface for deleting database db_dropdb (dbname), interface for starting database transaction (db_transaction_begin()), interface for ending transaction (db_transaction_end()), and interface for rolling back database transaction (db_transaction_rollback()).

[0191] On the other hand, Figure 8 In the example, golang fiber (first server 824) is used as a server framework for json format data transmission based on HTTP, that is, golang fiber framework is used as http+json server framework; golang goev (second server 825) is used as a server framework for tlv data transmission based on TCP, that is, golang goev framework is used as tcp+tlv server framework. Among them, golang fiber is a framework that can be used to build Internet-based (Web) applications; golang goev is a framework that can be used for I / O event-driven and TCP network programming.

[0192] Therefore, golang fiber or golang goev, as a server architecture, can realize local disk persistence based on management interface and business interface. In other words, database 820 exposes a set of business add, delete, modify and query interfaces and a set of management interfaces for creating and destroying database 820, creating and destroying tables, creating, deleting, modifying and querying data records, and can update local disk data instantly or nearly instantly, so that the data in the local disk is the latest or nearly the latest.

[0193] In an embodiment of the present application, a collaborative computing method is used to negotiate the encryption key and authentication key of the database 820 (i.e., the session key of the database and the session key of the requesting end in the above embodiment), while supporting configuration options for multiple authentication and encryption methods, and providing a set of standard interfaces for data synchronization mechanisms.

[0194] In an embodiment of the present application, when the business end 810 negotiates a key with the database 820, it can choose to interact with the management service 821 in the database 820 using HTTP, or it can choose to interact with the management service 821 in the database 820 using TCP.

[0195] In some embodiments, Fig. 9 As shown, the above key generation method can be implemented through steps S901 to S904:

[0196] Step S901: The business end calls the database open interface and initiates an access request to the database.

[0197] The open interface may be an interface in the management interface in the database. Exemplarily, the open interface may be db_open (ip, port).

[0198] Step S902: In response to the access request, the database determines whether a root key exists in the local disk.

[0199] If the root key exists, execute step S904; if the root key does not exist, execute step S903.

[0200] Step S903: The business end and the database generate their own root keys respectively.

[0201] In an embodiment of the present application, the database randomly generates a 32-byte random number as its own private key during the initialization phase, and the private key is used to generate a root key DBROOT through collaborative computing and negotiation with the business end.

[0202] Step S904: The business end and the database derive a session key of the business end and a session key of the database based on their own root keys respectively.

[0203] In the embodiment of the present application, the database derives the session key of the database through PBKDF2 based on the root key of the database; the service end derives the session key of the service end through PBKDF2 based on the root key of the database. The session key of the database and the session key of the service end both include DBDEK, DBSM2 and DBDMK.

[0204] In some embodiments, after completing step S904, the database can call the interactive control interface (db_init) to set the data encryption method, authentication method and business interface, where the business interface is used by the database to implement data insertion, deletion, modification and query, and the data encryption method and authentication method correspond to the session key.

[0205] The data encryption method can be digital envelope encryption or symmetric data encryption, both of which are used as data transmission methods for two-way data transmission. The authentication method can be signature verification, HMAC or CBCMAC, both of which are used for two-way authentication. The selection of data transmission method and authentication method occurs in the initialization stage of the database.

[0206] In the embodiment of the present application, the database calls the management interface to set the encryption and authentication methods and the control parameters of the database during the initialization phase. In other embodiments, the management interface is also used to implement the data persistence strategy, which is used to configure the method and frequency of data persistence on disk.

[0207] Accordingly, during the use phase of the database, the business add, delete, modify and query interface of the database is called to perform data insertion, deletion, modification and query functions.

[0208] In some embodiments, Fig.10 As shown, the above step S903 can be implemented through steps S1001 to S1007:

[0209] Step S1001: The business end sends the business end public key to the database.

[0210] Step S1002: The database sends the database public key to the business end.

[0211] Step S1003: The business end generates a root key of the business end based on the database public key and the business end private key.

[0212] In the embodiment of the present application, the root key of the service end can be implemented by the above formula (2).

[0213] In step S1004, the business end uses the root key of the business end to encrypt the preset value and sends the encrypted preset data to the database.

[0214] In an embodiment of the present application, the preset value may be / x00*16, the encryption method may be sm4, the root key of the service end may be represented by q, and step S1004 may be represented by sm4 (q, / x00*16).

[0215] Step S1005: The database generates a root key of the database based on the business end public key and the database private key.

[0216] In the embodiment of the present application, the root key of the database can be implemented by the above formula (3).

[0217] Step S1006, the database uses the database root key to encrypt the preset value, and determines whether the data encrypted by the database is consistent with the data encrypted by the business end, so as to determine whether the database root key is consistent with the business end root key.

[0218] Step S1007, the database encrypts the result of determining whether the root key of the database is consistent with the root key of the service end by the root key of the database and sends the result to the service end.

[0219] In an embodiment of the present application, step S1007 can be represented by sm4 (p, success / fail), where sm4 is the encryption method, p is the root key of the database, success indicates that the root key of the database is consistent with the root key of the business end, and fail indicates that the root key of the database is inconsistent with the root key of the business end.

[0220] In some embodiments, Fig.11 As shown, the above step S904 can be implemented through steps S1101 to S1103:

[0221] Step S1101: The business end sends the salt value and the number of iterations to the database.

[0222] Step S1102: The database generates a session key of the database based on the salt value, the number of iterations, and the root key of the database.

[0223] In the embodiment of the present application, the generation of the session key of the database can be achieved by the above formula (1).

[0224] Step S1103: The database uses the session key of the database to encrypt the preset value and sends the encrypted data to the service end.

[0225] In the embodiment of the present application, when the session key of the database includes DBSM2, step S1103 can be represented by sm4 (DBSM2, / x00*16), sm4 is the encryption method, / x00*16 is the preset value, and DBSM2 is the encryption key. When the session key of the database includes DBDEK, step S1103 can be represented by sm4 (DBDEK, / x00*16), sm4 is the encryption method, / x00*16 is the preset value, and DBDEK is the encryption key; when the session key of the database includes DBDMK, step S1103 can be represented by sm4 (DBDMK, / x00*16), sm4 is the encryption method, / x00*16 is the preset value, and DBDMK is the encryption key.

[0226] Fig.12 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 1 In the embodiment of the present application, the service end 810 and the database 820 can be integrated into one service to form a database system, which can also be called a stand-alone mode. Fig.12 As shown, the interaction between the business end 810 and the database 820 is shown, and the interaction may at least include steps S1101 to S1106.

[0227] Step S1101, the business end calls the database opening interface to open the database.

[0228] Step S1102: The database checks whether a root key exists. If no root key exists, a root key is generated and a key verification value of the root key is sent to the service end.

[0229] Here, step S1102 is represented by sm4 (p, success / fail).

[0230] Step S1103: The business end calls the key generation interface of the database to negotiate a session key with the database.

[0231] The key generation interface is db_derivekey.

[0232] Step S1104: the database derives a session key and sends the key verification value of each session key to the service end in sequence.

[0233] Step S1105: The business end calls the database's mutual control interface to complete database initialization.

[0234] In the embodiment of the present application, the authentication and encryption modes can be set when the database is initialized.

[0235] Step S1106: The database sends the initialization result to the business end.

[0236] In the embodiment of the present application, step S1106 is represented by sm4 (p, success / fail).

[0237] Fig.13 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 2 Compared to Fig.12 implementation method, Fig.13In the embodiment, two business terminals share a database to form a database system, which can also be called a sharing mode. In other words, in the embodiment of the present application, two servers share a database. The database system includes a first business terminal 1310, a second business terminal 1320 and a database 820, wherein a whitelist interface 1330 is set between the first business terminal 1310 and the second business terminal 1320, and the whitelist interface 1330 is used for the first business terminal 1310 and the second business terminal 1320 to exchange keys after the completed key negotiation, and the keys after the key negotiation may include one or more of the root key, DBSM2, DBDEK and DBDMK.

[0238] In the embodiment of the present application, the interaction process between the first service end 1310 and the database 820 may include: steps S1101 to S1106; the interaction process between the second service end 1320 and the database 820 may include: steps S1101 to S1106.

[0239] In the embodiment of the present application, due to the authentication of the key and the transmission of the encrypted data, the database can only be requested by the business end that initiates the initialization operation for the first time. For example, when the first business end 1310 initiates the initialization operation to the database 820, the second business end 1320 cannot initiate the initialization operation. Therefore, the two business ends need to pre-make the same private key, and open a whitelist interface on the business end to update the business end private key, and update it to the same key as the business end that initiates the initialization operation for the first time.

[0240] Fig.14 A schematic diagram of an application scenario of a database provided in an embodiment of the present application Figure 3 Compared to Fig.12 implementation method, Fig.14 It shows that two business ends use one database respectively, and the data between the two databases is synchronized, which can also be called a dual-machine mode. In other words, in the embodiment of the present application, two servers deployed in a single-machine mode form a cluster, and the data synchronization solution on the application layer is used between the clusters to ensure data consistency.

[0241] In the embodiment of the present application, the database system includes a third service end 1410, a fourth service end 1420, a first database 1430 and a second database 1440. The third service end 1410 is used to store first data through the first database 1430, and the fourth service end 1420 is used to store second data through the second database 1440.

[0242] Among them, a channel is established between the third business terminal 1410 and the fourth business terminal 1420 to achieve data synchronization 1350 at the application layer between the first database 1430 and the second database 1440. For example, the third business terminal 1410 can obtain information about the business interface used by the fourth business terminal 1420 to transmit to the second database 1440 through the channel to update the first data of the first database 1430 to be consistent with the second data. Similarly, the fourth business terminal 1420 can obtain information about the business interface used by the third business terminal 1410 to transmit to the first database 1430 through the channel to update the second data of the second database 1440 to be consistent with the first data, so as to achieve data synchronization.

[0243] In this application scenario, the interaction process between the third business end 1410 and the first database 1430 may at least include steps S1101 to S1106; the interaction process between the fourth business end 1420 and the second database 1440 may at least include steps S1101 to S1106.

[0244] In the embodiment of the present application, the provided database supports multiple modes to meet different application scenarios, including stand-alone mode, dual-machine mode and shared mode. Fig.12 For dual-machine mode, see Fig.14 For sharing mode, see Fig.13 .

[0245] Fig.15 A schematic diagram of the structure of a key generation device provided in an embodiment of the present application Figure 1 , the key generation device is applied to the requesting end; Fig.15 As shown, the key generation device 1500 includes: a first encryption unit 1501, a first receiving unit 1502, a first generation unit 1503 and a first determination unit 1504, wherein:

[0246] The first encryption unit 1501 is used to encrypt the first preset data using the root key of the requesting end, obtain the root key verification value of the requesting end, and send the root key verification value of the requesting end to the database; the root key verification value of the requesting end is used to verify the root key of the database;

[0247] The first receiving unit 1502 is used to receive the verification result of the root key of the database sent by the database;

[0248] The first generating unit 1503 is used to generate a session key of the requesting end based on the root key of the requesting end when the verification result indicates that the root key of the database is consistent with the root key of the requesting end;

[0249] The first determining unit 1504 is used to determine whether the session key of the requesting end is consistent with the session key of the database; the session key of the database is generated based on the root key of the database;

[0250] The first determining unit 1504 is further configured to determine the session key of the requesting end as the current session key for communication between the requesting end and the database when the session key of the requesting end is consistent with the session key of the database.

[0251] In some embodiments, the first determination unit 1504 is also used to receive a session key verification value of a database sent by a database; the session key verification value of the database is obtained by encrypting the second preset data using the session key of the database; the second preset data is encrypted using the session key of the requesting end to obtain the session key verification value of the requesting end; based on the session key verification value of the requesting end and the session key verification value of the database, it is determined whether the session key of the database is consistent with the session key of the requesting end.

[0252] In some embodiments, the key generation device 1500 includes a first issuing unit; the first issuing unit is used to send a key generation request carrying the public key of the requesting end to the database; the first receiving unit 1502 is used to receive the public key of the database sent by the database in response to the key generation request; the first generating unit 1503 is used to generate the root key of the requesting end based on the public key of the database and the private key of the requesting end; wherein the database is used to generate the root key of the database based on the public key of the requesting end and the private key of the database.

[0253] In some embodiments, the session key of the requesting end includes at least one authentication key and at least one encryption key; the key generating device 1500 includes an authentication unit and a data encryption unit; the authentication unit is used to generate authentication information based on a target authentication key in at least one authentication key and an authentication algorithm corresponding to the target authentication key, and send the authentication information to a database; the data encryption unit is used to encrypt the data to be stored using a target encryption key in at least one encryption key and an encryption algorithm corresponding to the target encryption key when the identity authentication of the requesting end is successful, and send the encrypted data to be stored to a database; wherein the database is used to authenticate the identity of the requesting end based on the authentication information using an authentication algorithm corresponding to the target authentication key; the authentication algorithm includes at least one of the following: a signature verification algorithm, a key-related hash operation message authentication algorithm, and a symmetric key-based block encryption algorithm; the encryption algorithm includes at least one of the following: a digital envelope encryption algorithm and a symmetric encryption algorithm.

[0254] Fig.16 A schematic diagram of the structure of a key generation device provided in an embodiment of the present application Figure 2 , the key generation device is applied to the database; Fig.16 As shown, the key generation device 1600 includes: a second receiving unit 1601, a verification unit 1602, a second generation unit 1603 and a second determination unit 1604, wherein:

[0255] The second receiving unit 1601 is used to receive a root key verification value of the requesting end sent by the requesting end; the root key verification value of the requesting end is obtained by encrypting the first preset data using the root key of the requesting end;

[0256] The verification unit 1602 is used to verify the root key of the database based on the root key verification value of the requesting end, and obtain the verification result of the root key of the database;

[0257] The second generating unit 1603 is used to generate a session key of the database based on the root key of the database when the verification result indicates that the root key of the database is consistent with the root key of the requesting end;

[0258] The second determining unit 1604 is used to determine the session key of the database as the current session key for communication between the database and the requesting end when the session key of the database is consistent with the session key of the requesting end; the session key of the requesting end is generated based on the root key of the requesting end.

[0259] In some embodiments, the key generation device 1600 also includes a second encryption unit; the second encryption unit is used to encrypt the second preset data using the database session key to obtain the database session key verification value; and send the database session key verification value to the requesting end; wherein the database session key verification value is used to verify the consistency between the database session key and the session key of the requesting end.

[0260] In some embodiments, the verification unit 1602 is also used to encrypt the first preset data using the root key of the database to obtain a root key verification value of the database; when the root key verification value of the database is consistent with the root key verification value of the requesting end, determine the verification result that the root key of the database is consistent with the root key of the requesting end; when the root key verification value of the database is inconsistent with the root key verification value of the requesting end, determine the verification result that the root key of the database is inconsistent with the root key of the requesting end.

[0261] In some embodiments, the second receiving unit 1601 is further used to receive a key generation request sent by the requesting end and carrying the public key of the requesting end; the second generating unit 1603 is further used to send the public key of the database to the requesting end in response to the key generation request, and generate the root key of the database based on the public key of the requesting end and the private key of the database; wherein the requesting end is used to generate the root key of the requesting end based on the public key of the database and the private key of the requesting end.

[0262] In some embodiments, the second generation unit 1603 is also used to receive a preset salt value and a number of iterations sent by the requesting end; using a preset key generation algorithm, the preset salt value, the number of iterations, the root key of the database and the first byte length are processed to obtain a session key of the database; the first byte length is the byte length of the session key of the database.

[0263] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0264] The embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented. The computer-readable storage medium can be transient or non-transient.

[0265] An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0266] The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented in hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0267] Fig.17 A schematic diagram of a hardware entity of a key generation device in an embodiment of the present application is shown in FIG. Fig.17 As shown, the hardware entity of the key generation device 1700 includes: a processor 1701, a communication interface 1702 and a memory 1703, wherein:

[0268] The processor 1701 generally controls the overall operation of the key generation device 1700 , and the overall operation may be to implement the key generation method provided in the embodiment of the present application.

[0269] The communication interface 1702 may enable the key generation device 1700 to communicate with other terminals or servers via a network.

[0270] The memory 1703 is configured to store instructions and applications executable by the processor 1701, and can also cache data to be processed or processed by the processor 1701 and each module in the key generation device 1700 (for example, image data, audio data, voice communication data, and video communication data), which can be implemented by flash memory (FLASH) or random access memory (Random Access Memory, RAM). Data can be transmitted between the processor 1701, the communication interface 1702, and the memory 1703 through the bus 1704.

[0271] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0272] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0273] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A key generation method, characterized in that: The key generation method is applied to the requesting end; the key generation method includes: Sending a key generation request carrying the public key of the requesting end to the database; receiving a public key of a database sent by the database in response to the key generation request; Generate a root key of the requesting end based on the public key of the database and the private key of the requesting end; The first preset data is encrypted using the root key of the requesting end to obtain a root key verification value of the requesting end, and the root key verification value of the requesting end is sent to the database; the root key verification value of the requesting end is used to verify the root key of the database; the database is used to generate the root key of the database based on the public key of the requesting end and the private key of the database; Receiving a verification result of a root key of a database sent by the database; the verification result of the root key of the database is determined based on the root key verification value of the requesting end and the root key verification value of the database; the root key verification value of the database is obtained by encrypting the first preset data using the root key of the database; If the verification result indicates that the root key of the database is consistent with the root key of the requesting end, generating a session key of the requesting end based on the root key of the requesting end; Determining whether the session key of the requesting end is consistent with the session key of the database; the session key of the database is generated based on the root key of the database; In the case where the session key of the requesting end is consistent with the session key of the database, the session key of the requesting end is determined as the current session key for communication between the requesting end and the database.

2. The key generation method according to claim 1, characterized in that: The determining whether the session key of the requesting end is consistent with the session key of the database includes: Receiving a database session key verification value sent by the database; the database session key verification value is obtained by encrypting second preset data using the database session key; Encrypting the second preset data using the session key of the requesting end to obtain a session key verification value of the requesting end; Based on the session key verification value of the requesting end and the session key verification value of the database, it is determined whether the session key of the database is consistent with the session key of the requesting end.

3. The key generation method according to claim 1 or 2, wherein the session key of the requesting end includes at least one authentication key and at least one encryption key; the method further comprises: generating authentication information based on a target authentication key among at least one authentication key and an authentication algorithm corresponding to the target authentication key, and sending the authentication information to the database; In the case where the identity authentication of the requesting end is successful, encrypting the data to be stored by using a target encryption key in at least one encryption key and an encryption algorithm corresponding to the target encryption key, and sending the encrypted data to be stored to the database; Among them, the database is used to adopt the authentication algorithm corresponding to the target authentication key to authenticate the identity of the requesting end based on the authentication information; the authentication algorithm includes at least one of the following: a signature verification algorithm, a key-related hash operation message authentication algorithm and a symmetric key block encryption algorithm; the encryption algorithm includes at least one of the following: a digital envelope encryption algorithm and a symmetric encryption algorithm.

4. The key generation method according to claim 1 or 2, further comprising: Updating a current session key for communication between the requesting end and the database in a whitelist interface of the requesting end; The shared requesting end that shares the database with the requesting end is used to obtain the current session key in the whitelist interface; and communicate with the database based on the current session key.

5. The key generation method according to claim 1 or 2, further comprising: Based on the current session key, obtaining the data to be synchronized from the database; Sending the data to be synchronized to other requesting ends; The other requesting end is used to store the data to be synchronized in other databases based on other session keys; the other session keys are keys obtained through negotiation between the other requesting end and the other databases.

6. The key generation method according to claim 1 or 2, wherein the generating the session key of the requesting end based on the root key of the requesting end comprises: A preset key generation algorithm is used to process a preset salt value, the number of iterations, the root key of the requesting end, and the second byte length to obtain the session key of the requesting end; the second byte length is the byte length of the session key of the requesting end.

7. A key generation method, characterized in that: The key generation method is applied to a database; the key generation method comprises: Receiving a key generation request sent by a requesting end and carrying a public key of the requesting end; In response to the key generation request, the public key of the database is sent to the requesting end, and the root key of the database is generated based on the public key of the requesting end and the private key of the database; the requesting end is used to generate the root key of the requesting end based on the public key of the database and the private key of the requesting end; Receiving a root key check value of the requesting end sent by the requesting end; the root key check value of the requesting end is obtained by encrypting the first preset data using the root key of the requesting end; Determine a verification result of the root key of the database based on the root key verification value of the requesting end and the root key verification value of the database; the root key verification value of the database is obtained by encrypting the first preset data using the root key of the database; If the verification result indicates that the root key of the database is consistent with the root key of the requesting end, generating a session key of the database based on the root key of the database; When the session key of the database is consistent with the session key of the requesting end, the session key of the database is determined as the current session key for communication between the database and the requesting end; the session key of the requesting end is generated based on the root key of the requesting end.

8. The key generation method according to claim 7, characterized in that: The determining a verification result of the root key of the database based on the root key verification value of the requesting end and the root key verification value of the database includes: Encrypting the first preset data using the root key of the database to obtain a root key check value of the database; When the root key verification value of the database is consistent with the root key verification value of the requesting end, determining a verification result that the root key of the database is consistent with the root key of the requesting end; In the case that the root key verification value of the database is inconsistent with the root key verification value of the requesting end, a verification result that the root key of the database is inconsistent with the root key of the requesting end is determined.

9. The key generation method according to claim 7 or 8, characterized in that: The key generation method further comprises: Receiving a preset salt value and a number of iterations sent by the requesting end; The step of generating a session key of the database based on a root key of the database comprises: The preset salt value, the number of iterations, the root key of the database and the first byte length are processed using a preset key generation algorithm to obtain a session key of the database; the first byte length is the byte length of the session key of the database.

10. A key generation device, characterized in that: The key generation device is applied to the requesting end; the key generation device comprises: A first sending unit, used for sending a key generation request carrying the public key of the requesting end to the database; A first receiving unit, configured to receive a public key of a database sent by the database in response to the key generation request; A first generating unit, configured to generate a root key of the requesting end based on a public key of a database and a private key of the requesting end; A first encryption unit is used to encrypt the first preset data using the root key of the requesting end, obtain the root key verification value of the requesting end, and send the root key verification value of the requesting end to the database; the root key verification value of the requesting end is used to verify the root key of the database; The first receiving unit is further used to receive a verification result of a root key of a database sent by the database; the verification result of the root key of the database is determined based on a root key verification value of the requesting end and a root key verification value of the database; the root key verification value of the database is obtained by encrypting the first preset data using the root key of the database; The first generating unit is further configured to generate a session key of the requesting end based on the root key of the requesting end when the verification result indicates that the root key of the database is consistent with the root key of the requesting end; A first determining unit is configured to receive a session key verification value of a database sent by the database; the session key verification value of the database is obtained by encrypting second preset data using the session key of the database; the session key of the database is generated based on the root key of the database; the second preset data is encrypted using the session key of the requesting end to obtain the session key verification value of the requesting end; based on the session key verification value of the requesting end and the session key verification value of the database, determine whether the session key of the database is consistent with the session key of the requesting end; The first determining unit is further configured to determine the session key of the requesting end as a current session key for communication between the requesting end and the database when the session key of the requesting end is consistent with the session key of the database.

11. A key generation device, characterized in that: include: A memory for storing executable instructions; A processor, configured to implement the method described in any one of claims 1 to 6, or the method described in any one of claims 7 to 9, when executing the executable instructions stored in the memory.

12. A computer-readable storage medium, characterized in that: The storage medium stores executable instructions, which, when executed by a processor, implement the method described in any one of claims 1 to 6, or the method described in any one of claims 7 to 9.

13. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the method described in any one of claims 1 to 6 or the method described in any one of claims 7 to 9 is implemented.

Images