Encryption processing method, device and equipment

Abstract

According to the encryption processing method, device and equipment provided by the embodiment of the invention, after the to-be-transmitted network data is acquired, the encryption feature is determined based on the data type and the data volume of the network data, and then the network data is encrypted based on the encryption process matched with the encryption feature. The encryption features are used for determining information such as an encryption algorithm, an encryption mode (hardware encryption or software encryption) and a key exchange algorithm of a session key, a proper encryption process can be selected for network data to perform encryption operation by determining the encryption features, adaptive balance is performed on security and timeliness, the communication security is ensured, and the security of the session key is ensured. And the communication performance is not influenced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to an encryption processing method, apparatus, and device. Background Art

[0002] When a device performs wireless communication, it is usually necessary to encrypt the data to be sent to achieve secure data transmission. In different usage scenarios, different requirements are placed on the performance of encryption and decryption algorithms, and different algorithms also have different requirements for hardware and software performance, resulting in great difficulties in algorithm design. Generally speaking, hardware encryption is more secure, but software encryption is faster. At the same time, different algorithm schemes, such as symmetric encryption, asymmetric encryption, or different key lengths under the same algorithm, also have different impacts on security and device performance. The existing single encryption scheme cannot adapt to various usage scenarios, affecting the security and efficiency of data transmission. Summary of the Invention

[0003] In view of this, the present application provides an encryption processing method, apparatus, and device to facilitate solving the problem that the existing single encryption scheme cannot adapt to various usage scenarios.

[0004] In a first aspect, an embodiment of the present application provides an encryption processing method, including:

[0005] Obtain network data to be transmitted;

[0006] Determine an encryption feature based on the data type and data volume of the network data;

[0007] Perform an encryption operation on the network data based on an encryption process matching the encryption feature.

[0008] In an alternative embodiment, the determining an encryption feature based on the data type and data volume of the network data includes:

[0009] Determine a key exchange algorithm based on the data type of the network data;

[0010] Determine a data encryption mode based on the data volume of the network data, where the data encryption mode includes hardware encryption or software encryption.

[0011] In an alternative embodiment, the determining a data encryption mode based on the data volume of the network data includes:

[0012] Determine the data encryption mode and key length based on the data volume of the network data.

[0013] In an alternative embodiment, the determining a key exchange algorithm based on the data type of the network data includes:

[0014] Identify the data type of the network data, where the data type is used to indicate the application scenario of the network data;

[0015] Determine a key exchange algorithm that matches the data type of the network data based on a pre-stored list of data algorithms.

[0016] In an alternative embodiment, the determining the data encryption mode based on the data volume of the network data includes:

[0017] When it is detected that the data volume of the network data exceeds a first threshold, determine that the data encryption mode of the network data is software encryption;

[0018] When it is detected that the data volume of the network data does not exceed the first threshold, determine that the data encryption mode of the network data is hardware encryption.

[0019] In an alternative embodiment, the determining the data encryption mode and key length based on the data volume of the network data includes:

[0020] When it is detected that the data volume of the network data is within a first interval, determine that the data encryption mode of the network data is software encryption and the key length of the network data is a first length value;

[0021] When it is detected that the data volume of the network data is within a second interval, determine that the data encryption mode of the network data is software encryption and the key length of the network data is a second length value;

[0022] When it is detected that the data volume of the network data is within a third interval, determine that the data encryption mode of the network data is hardware encryption and the key length of the network data is the first length value;

[0023] When it is detected that the data volume of the network data is within a fourth interval, determine that the data encryption mode of the network data is hardware encryption and the key length of the network data is the second length value;

[0024] Wherein, the intervals covering the values from large to small are the first interval, the second interval, the third interval, and the fourth interval in sequence, and the first length value is greater than the second length value.

[0025] In an alternative embodiment, the method further includes:

[0026] Determine a first key length based on the data volume of the network data;

[0027] Receive a second key length sent by a peer device;

[0028] Determine the minimum value of the first key length and the second key length as the key length of the session key.

[0029] In an alternative embodiment, the method further includes:

[0030] When it is detected that the usage duration of the session key exceeds a preset duration threshold, a new encryption feature is determined based on the data type and data volume of the network data, and the network data is encrypted based on the session key that matches the new encryption feature.

[0031] In a second aspect, an embodiment of the present application provides an encryption processing apparatus, including:

[0032] An acquisition module, configured to acquire network data to be transmitted;

[0033] A determination module, configured to determine an encryption feature based on the data type and data volume of the network data;

[0034] An encryption module, configured to encrypt the network data based on an encryption process that matches the encryption feature.

[0035] In a third aspect, an embodiment of the present application provides an electronic device, including a memory for storing computer program instructions and a processor for executing the program instructions. When the computer program instructions are executed by the processor, the electronic device is triggered to execute the method according to any one of the first aspects described above.

[0036] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium includes a stored program. When the program runs, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of the first aspects described above.

[0037] In a fifth aspect, an embodiment of the present application provides a computer program product, where the computer program product includes executable instructions. When the executable instructions are executed on a computer, the computer is caused to execute the method according to any one of the first aspects described above.

[0038] By adopting the solution provided by the embodiment of the present application, after acquiring the network data to be transmitted, an encryption feature is determined based on the data type and data volume of the network data, and then the network data is encrypted based on the session key that matches the encryption feature. The encryption feature is used to determine information such as the encryption algorithm, encryption mode (hardware encryption or software encryption), and key exchange algorithm of the session key. By determining the encryption feature, a suitable session key can be selected for encrypting the network data, achieving an adaptive balance between security and timeliness, ensuring communication security while taking into account that the communication performance is not affected. Description of the Drawings

[0039] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0040] Figure 1 It is a schematic example diagram of an encryption processing method provided by an embodiment of the present application;

[0041] Figure 2 It is a schematic flowchart of an encryption processing method provided by an embodiment of the present application;

[0042] Figure 3 It is a schematic example diagram of another encryption processing method provided by an embodiment of the present application;

[0043] Figure 4 It is a schematic flowchart of another encryption processing method provided by an embodiment of the present application;

[0044] Figure 5 It is a schematic flowchart of another encryption processing method provided by an embodiment of the present application;

[0045] Figure 6 It is a schematic flowchart of another encryption processing method provided by an embodiment of the present application;

[0046] Figure 7 It is a schematic structural diagram of an encryption processing device provided by an embodiment of the present application;

[0047] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0048] To better understand the technical solutions of the present application, the following will describe the embodiments of the present application in detail with reference to the drawings.

[0049] It should be clear that the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0050] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms of "a", "the" and "said" used in the embodiments of the present application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0051] It should be understood that the term "and / or" used herein is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, both A and B exist simultaneously, and B exists alone. Additionally, the character " / " in this text generally represents an "or" relationship between the preceding and following associated objects.

[0052] As information security has gradually gained the attention of users, each operator has proposed its own countermeasures in communication security. For example, the quantum communication solution promoted by Company A, which is an end-to-end encryption solution based on quantum communication. To adapt to the third-party client for distributing keys, a dedicated encrypted path needs to be established. The Generic Bootstrapping Architecture (GBA) encryption solution promoted by Company B divides the TA domain responsible for encryption and decryption and the CA domain responsible for service interaction in the terminal, and cooperates with the security deployment on the network side to achieve the secure transmission of data. Additionally, some device manufacturers will also deploy some customized encryption solutions, such as exchanging key pairs during call establishment to perform symmetric / asymmetric encryption on voice data, usually in the form of key negotiation.

[0053] The above encryption methods may lead to the following problems: (1) Since the requirements of each operator / device manufacturer for encryption processes and algorithms vary greatly, a dedicated framework needs to be designed for adaptation for each set of encryption processes, resulting in a complicated development process and difficult later maintenance. (2) Due to different performance requirements for encryption and decryption algorithms in different usage scenarios, and different algorithms also have different requirements for hardware performance, it is very difficult in algorithm design. (3) The call scenarios vary greatly, and the real-time service occupancy and performance parameters of different terminals are also different. Since the encryption and decryption process is a process with high performance requirements, if either end of the communication fails to process in time, the overall communication quality will decline. (4) Once a third party steals the key during the communication process, this round of call will no longer be secure.

[0054] In response to the above problems, the embodiments of the present application provide an encryption processing method, which selects a corresponding session key for encryption operations based on the characteristics of network data itself, ensuring encryption performance and security.

[0055] To implement this encryption processing method, the embodiments of the present application first provide a communication security call framework based on the Android framework / Local Android Framework / Native layer, which can be compatible with hardware encryption based on an integrated secure element (ISE), software encryption running on the application processor (AP) side, and encryption and decryption libraries provided by third-party manufacturers such as operators. This framework can also be compatible with third-party application software (App) through the interfaces provided by the Framework layer for interacting with external devices for keys and authentication information, etc.

[0056] Referring to Figure 1 , the top layer of this framework is the user-oriented application, including phone calls, text messages, and third-party applications manually downloaded by users, etc. The second layer is the Android framework (Framework layer), and an SDK will also be integrated in the Framework layer. This SDK provides interfaces for other modules of the Framework and third-party applications to call. The Framework layer can also provide system services corresponding to each application, such as phone services, text message services, etc. The third layer is Android native, which includes the Radio Interface Layer (RIL), Native Software Development Kit (Native SDK), Crypto Library (Crypto lib), and Trusted Execution Environment (TEE). RIL is responsible for transmitting communication data, Native SDK is responsible for data encryption work, Crypto lib is used to store optional session keys, and TEE realizes data encryption at the software level. The fourth layer is the underlying system, including the Modem and the integrated secure element (ISE). The Modem is the hardware and software component in the mobile device responsible for processing wireless communication, and the integrated secure element (ISE) realizes data encryption at the hardware level.

[0057] When the user uses the phone, text message, or other third-party applications of the terminal device, the terminal device will generate network data to be transmitted to other devices. The network data is transmitted downward through the Framework SDK to RIL, and then from RIL to Native SDK. Native SDK determines the encryption method according to the attributes of the network data itself. If software encryption is adopted, Native SDK will transmit the network data to TEE for software encryption. If hardware encryption is adopted, Native SDK will transmit the network data to the integrated secure element (ISE) for hardware encryption.

[0058] The hardware encryption implementation is based on the inherited security chip ISE, and the software encryption implementation is in the TEE. Both are interacted by the NativeSDK. Data from the underlying Modem (such as voice data packets) directly enters the NativeSDK through RIL, undergoes encryption and decryption operations, and then returns to the Modem without passing through the upper-layer Framework, which further ensures data security.

[0059] In addition, the framework reserves an interaction interface with the Framework SDK for third-party software at the application layer. If the terminal device receives a key sent by a third-party server through a third-party application, the key can be transmitted to the Native SDK through the Framework SDK to complete subsequent encryption and decryption work. If the third-party application has a closed-source encryption and decryption library with specific algorithms, the framework also reserves the Crypto lib as an extension library to uniformly interact with these third-party libraries through the Native SDK, making management more convenient.

[0060] In the embodiments of this application, the communication security call framework adapts hardware encryption and software encryption, and at the same time reserves an extension interface for third-party encryption solutions, greatly reducing the workload when adapting different encryption solutions.

[0061] Figure 2 It is a schematic flowchart of an encryption processing method provided by the embodiments of this application. This method can be executed by the Native SDK of the above framework to achieve adaptive encryption of different network data. As Figure 2 shown, this method may include:

[0062] Step 201, obtain the network data to be transmitted;

[0063] Step 202, determine the encryption characteristics based on the data type and data volume of the network data;

[0064] Step 203, perform an encryption operation on the network data based on the encryption process matching the encryption characteristics.

[0065] When the terminal device needs to send network data to other devices, the network data is transmitted to the Native SDK through the path in the above framework flowchart for encryption operations. Different network data may have different requirements for encryption. After receiving the network data, the Native SDK will first determine the attributes of the network data itself (such as data type or data volume, etc.), and then determine the corresponding encryption characteristics according to the attributes of the network data.

[0066] In an alternative embodiment, the encryption features may include information such as encryption mode, key exchange algorithm, and key length. The encryption mode may specifically include hardware encryption or software encryption. Hardware encryption is more secure, but software encryption is faster. Different key exchange algorithms have different levels of security and different requirements for device performance. For example, the Diffie-Hellman Ephemeral (DHE) algorithm generally has higher requirements for device performance than the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) algorithm. Different key lengths also result in different confidentiality effects. From the perspective of the algorithm's requirements for performance, the shorter the key length, the lower the requirements for device performance, and the longer the key length, the higher the confidentiality and security. Based on the requirements for security, transmission performance, etc. of network data, the Native SDK can determine one or more encryption features to meet the requirements of network data.

[0067] In an alternative embodiment, the Native SDK can determine the key exchange algorithm based on the data type of the network data. Specifically, the Native SDK first identifies the data type of the network data and then determines the key exchange algorithm that matches the data type. The data type is used to indicate the application scenario of the network data, such as phone data, text message data, or game data, etc. Network data of different data types have different requirements for confidentiality level and transmission speed. For example, phone data or text message data usually have high confidentiality requirements and the DHE algorithm can be selected. Game data usually has high requirements for transmission speed and the ECDHE algorithm can be selected. Optionally, a data algorithm list may be pre-stored in the Native SDK, which contains the correspondence between the data type and the key exchange algorithm. After the Native SDK determines the data type of the network data, it can select the key exchange algorithm that matches the current data type from the data algorithm list. The above is only an exemplary description. The Native SDK can also select other key exchange algorithms, and the correspondence between each data type and the key exchange algorithm may also change when the encryption requirements change.

[0068] In an alternative embodiment, the Native SDK can determine the data encryption mode based on the data volume of network data. The data encryption mode can specifically include hardware encryption or software encryption. Generally, hardware encryption is more secure and software encryption is faster. Therefore, the Native SDK can determine whether to use hardware encryption or software encryption based on the data volume of network data. Specifically, when the Native SDK detects that the data volume of network data exceeds the first threshold, it can determine that the data encryption mode of the network data is software encryption. When the Native SDK detects that the data volume of network data does not exceed the first threshold, it can determine that the data encryption mode of the network data is hardware encryption. In another alternative embodiment, the Native SDK can also determine the encryption mode based on the confidentiality requirement level of network data. When the confidentiality level of network data is higher than a certain threshold, hardware encryption is selected; otherwise, software encryption is selected. Alternatively, the Native SDK can also combine the data volume and confidentiality requirement level of network data to determine the encryption mode, and output the final encryption mode by setting different weights for the data volume and confidentiality requirement level.

[0069] In an optionally embodiment, hardware encryption specifically refers to encryption performed in the integrated security chip ISE, and software encryption specifically refers to encryption performed in the Trusted Execution Environment (TEE) of the Application Processor (AP). The structures and interaction methods of the integrated security chip ISE and the AP chip can be as Figure 3 shown. The integrated security chip ISE is designed in three layers from bottom to top. The Hardware Driver Level serves as the hardware interface layer with the security chip and can directly operate the security chip hardware. It is responsible for initializing each hardware module, enabling and disabling module functions, interrupt handling, data reading and writing, module status monitoring, and alarming. The Transaction Level and the Crypto API Level of the integrated security chip ISE are responsible for the business transmission part. They receive data packets (network data) from the hardware communication interface layer and forward them to the security function layer for further processing. The integrated security chip ISE provides an Application Protocol Data Unit (APDU) interface externally. The operating system (OS) component of the AP chip transmits network data to the integrated security chip ISE in the APDU data format to implement encryption and decryption operations. The hardware driver layer of the AP chip operates the hardware of the AP chip to implement functions such as initializing each hardware module and data reading and writing, and the business transmission layer of the AP chip is responsible for business transmission.

[0070] In an alternative embodiment, the Native SDK can also determine the key length of the session key based on the amount of network data. For network data with a large amount of data, the Native SDK can select a session key with a smaller key length for encryption. For network data with a small amount of data, the Native SDK can select a session key with a larger key length for encryption. Optionally, the Native SDK can configure multiple data volume ranges, and each data volume range has its corresponding encryption mode and key length. For example, the Native SDK can configure four data volume ranges, and the values covered by the data volume ranges are, in descending order, the first range, the second range, the third range, and the fourth range. (1) When the amount of network data is in the first range, the Native SDK determines that the data encryption mode of the network data is software encryption, and the key length is the first length value. (2) When the amount of network data is in the second range, the Native SDK determines that the data encryption mode of the network data is software encryption, and the key length is the second length value. When the amount of network data is in the third range, the Native SDK determines that the data encryption mode of the network data is hardware encryption, and the key length is the first length value. When the amount of network data is in the fourth range, the Native SDK determines that the data encryption mode of the network data is hardware encryption, and the key length is the second length value. Among them, the first length value is less than the second length value. For example, the session key of the first length value can be 128 bits, and the session key of the second length value is 256 bits. The configuration of the data volume range and the setting of the key length are not limited and can be adjusted based on specific scenarios.

[0071] Figure 4 As shown in the flowchart of another encryption processing method provided by the embodiments of the present application, Figure 4 as shown, the method may include:

[0072] Step 401, obtain network data.

[0073] Step 402, detect whether the current network data has a specified encryption process. If so, go to step 410; otherwise, go to step 403.

[0074] Step 403, select the symmetric encryption algorithm AES.

[0075] Step 404, detect whether the type of network data is in the high security level table. If so, go to step 405; otherwise, go to step 406.

[0076] Step 405, select the key exchange algorithm DHE and periodically update the symmetric key.

[0077] Step 406, select the key exchange algorithm ECDHE and do not periodically update the symmetric key.

[0078] Step 407: Determine whether the data volume of the current network data is greater than N3 kilobits per second. If so, proceed to Step 408; otherwise, proceed to Step 409.

[0079] Step 408: Encrypt using the TEE software.

[0080] Step 409: Determine whether the data volume of the current network data is greater than N2 kilobits per second. If so, proceed to Step 410; otherwise, proceed to Step 411.

[0081] Step 410: Encrypt using the TEE software.

[0082] Step 411: Encrypt using the ISE hardware.

[0083] Step 412: Determine whether the data volume of the current network data is greater than N1 kilobits per second. If so, proceed to Step 413; otherwise, proceed to Step 414.

[0084] Step 413: The AES algorithm uses a 128-bit key.

[0085] Step 414: The AES algorithm uses a 256-bit key.

[0086] Step 415: Encrypt the network data based on the corresponding encryption process.

[0087] In Step 402, if the encryption process has been specified for the network data, there is no need to perform subsequent encryption feature determination, and the encryption operation can be directly executed based on the specified encryption process. If the encryption process has not been specified for the network data, the encryption features need to be selected based on the attributes of the network data, including the encryption algorithm, key exchange algorithm, encryption mode, and key length, etc., and then the encryption operation is performed on the network data based on the matching encryption process. In the embodiments of the present application, the Native SDK can select the symmetric encryption algorithm AES to perform the encryption operation.

[0088] In Step 404, the Native SDK can select the key exchange algorithm based on the data type of the current network data. For data types with higher confidentiality requirements, the Native SDK can select the DHE algorithm and periodically update the symmetric key. For data types with lower confidentiality requirements, the Native SDK can select the ECDHE algorithm without periodically updating the symmetric key. Specifically, a high security level table can be pre-stored in the Native SDK, and this table records some data types with higher confidentiality requirements, such as phone data or text message data, etc. When it is detected that the data type of the current network data is recorded in the high security level table, the DHE algorithm can be selected; otherwise, the ECDHE algorithm is selected.

[0089] Steps 407 to 414 are the process of determining the encryption mode and key length based on the data volume. The Native SDK can pre-set multiple thresholds, such as N1 kilobits per second, N2 kilobits per second, and N3 kilobits per second, where N3 > N2 > N1. When the data volume of network data is greater than N2 kilobits per second, the Native SDK can select TEE software encryption. When the data volume of network data is less than or equal to N2 kilobits per second, the Native SDK can select ISE hardware encryption.

[0090] Furthermore, when the data volume of network data is greater than N3 kilobits per second, the Native SDK can select TEE software encryption and the AES algorithm uses a 128-bit key. It can be understood that when the data volume is large, in order to ensure the encryption speed, even under the premise of software encryption, some algorithms that consume less computing power need to be used for data processing, such as selecting software encryption and a session key (symmetric key) with a smaller key length. When the data volume of network data is between N2 kilobits per second and N3 kilobits per second, the Native SDK can select TEE software encryption and the AES algorithm uses a 256-bit key. When the data volume of network data is between N1 kilobits per second and N2 kilobits per second, the Native SDK can select ISE hardware encryption and the AES algorithm uses a 128-bit key. When the data volume of network data is less than N1 kilobits per second, the Native SDK can select ISE hardware encryption and the AES algorithm uses a 256-bit key. It can be understood that when the data volume is small, in order to ensure security, hardware encryption and a session key with a larger key length should be selected.

[0091] After the above encryption features are selected, the Native SDK can perform encryption operations on network data based on the corresponding encryption process.

[0092] In the embodiments of the present application, the optimal encryption scheme is selected according to the attributes of network data itself, and a balance is achieved between the security and speed of encryption, which can be adapted to various usage scenarios and meet different encryption requirements.

[0093] Since the call scenarios vary widely, the occupancy of real-time services on different terminals and the hardware performance parameters will also be different. And the encryption and decryption process is a process with high computing power consumption. If either party of the communication pair cannot process the encrypted data in time, it will lead to a decline in the overall communication quality. For example, the encryption algorithm suitable for the sending end may exceed the computing power requirements at the receiving end. In order to ensure that the performance of both communication parties is not affected, a scheme with lower performance requirements can be adopted after verifying the algorithm selection results at both ends during the key negotiation stage.

[0094] The process of key negotiation can refer to Figure 5, taking the ECDHE algorithm as an example for description, which may specifically include the following steps:

[0095] 501. Device A randomly generates a random value Ra (private key) and generates a public key Pa through the ECDHE algorithm.

[0096] 502. Device A sends the public key Pa to Device B.

[0097] 503. Device B randomly generates a random value Rb (private key) and generates a public key Pb through the ECDHE algorithm.

[0098] 504. Device B sends the public key Pb to Device A.

[0099] 505. Both Device A and Device B calculate the elliptic curve coordinates (x, y) through Ra and Rb. x is the session key, and 256 bits are taken from x as St, which is used as the temporary AES key.

[0100] 506. Device A determines the expected key length as La and encrypts it through St.

[0101] 507. Device A sends the information with the key length of La to Device B.

[0102] 508. Device B determines the expected key length as Lb and encrypts it through St.

[0103] 509. The smaller value of La and Lb is used as the final key length L.

[0104] After the key length L is determined, both Device A and Device B can select the session key S with the corresponding length from x and use S for subsequent AES encryption.

[0105] In the embodiments of the present application, the smaller the key length, the lower the requirement for device performance and the faster the encryption speed. When the key lengths determined by the two communication parties are different, it is recommended to select the smaller value of the key lengths as the common key length for the two communication parties. The hardware performance of both ends can normally support the encryption and decryption of interactive data, ensuring the overall communication quality.

[0106] If the session keys of the two communication parties are stolen, it may lead to information leakage. To further ensure communication security, the session keys can be updated periodically in the embodiments of the present application. The process of updating the session keys is as follows Figure 6 shown, which specifically includes:

[0107] 601. Device A uses the key S for AES encryption and records the usage duration of the key S.

[0108] 602. When Device A detects that the usage duration of the key S exceeds the preset duration threshold, it stops data transmission.

[0109] 603. Device A sends a key update request to Device B.

[0110] 604. Device B stops data transmission and returns a key update response.

[0111] 605. Device A and Device B negotiate a new session key S1 based on ECDHE+AES. For specific details, please refer to Figure 5 the process description.

[0112] 606. Device A and Device B subsequently use the key S1 for AES encrypted communication.

[0113] 607. When Device A or Device B detects that the usage duration of the key S1 also exceeds the duration threshold, the session key is updated again.

[0114] The session key update request can be initiated by either party of the communication parties. Steps 601 to 603 are described with Device A as the initiator. In another embodiment, Device B can also be the initiator and send a key update request to Device A.

[0115] In the embodiment of the present application, through the above process for periodic key update, even if the device private key is stolen at a certain moment, it is only possible to cause information leakage for a short period of time, and to a greater extent ensure the security of communication.

[0116] In view of the defects of the existing encryption scheme, the embodiment of the present application first constructs a general framework that is compatible with software and hardware encryption schemes, with strong scalability, strong reuse ability, and low maintenance cost. On this basis, the encryption characteristics are determined through the attributes of network data, and encryption is performed through a matching encryption process, achieving an adaptive balance between security and timeliness. In addition, the key length is determined during the key negotiation stage, taking into account the actual performance of both end devices, and ensuring the communication quality is not affected as much as possible while ensuring security. Finally, by periodically updating the session key, the forward security of encryption is further guaranteed. Through the above optimization scheme, the encryption processing method of the embodiment of the present application expands the application scope and has better use value.

[0117] Figure 7 It is a schematic structural diagram of an encryption processing device provided by the embodiment of the present application. This device can be deployed on an electronic device, such as Figure 4 shown. This device may include: an acquisition module 710, a determination module 720, and an encryption module 730.

[0118] The acquisition module 710 is used to acquire the network data to be transmitted.

[0119] The determination module 720 is used to determine the encryption characteristics based on the data type and data volume of the network data.

[0120] An encryption module 730 is configured to perform an encryption operation on the network data based on an encryption process that matches the encryption feature.

[0121] For the specific process, reference may be made to the description in the above method flowchart.

[0122] Corresponding to the above embodiments, the present application further provides an electronic device. Figure 8 FIG. is a schematic structural diagram of an electronic device provided by an embodiment of the present application. The electronic device 800 may include: a processor 801, a memory 802, and a communication unit 803. These components communicate through one or more buses. Those skilled in the art can understand that the structure of the electronic device shown in the figure does not constitute a limitation on the embodiments of the present application. It may be a bus structure, a star structure, and may also include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0123] Among them, the communication unit 803 is configured to establish a communication channel so that the electronic device can communicate with other devices. Receive user data sent by other devices or send user data to other devices.

[0124] The processor 801 is the control center of the electronic device, connecting various parts of the entire electronic device through various interfaces and lines. By running or executing software programs, instructions, and / or modules stored in the memory 802, and by calling the data stored in the memory, to perform various functions of the electronic device and / or process data. The processor may be composed of an integrated circuit (IC). For example, it may be composed of a single packaged IC, or may be composed of connecting multiple packaged ICs with the same or different functions. For example, the processor 801 may only include a central processing unit (CPU). In the embodiment of the present application, the CPU may be a single operation core or may include multiple operation cores.

[0125] The memory 802 is used to store the execution instructions of the processor 801. The memory 802 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disc.

[0126] When the execution instructions in the memory 802 are executed by the processor 801, the electronic device 500 is enabled to execute Figure 2 Some or all of the steps in the illustrated embodiments.

[0127] In a specific implementation, the present application further provides a computer storage medium. The computer storage medium can store a program, and when the program is executed, it can include some or all of the steps in the embodiments of the encryption processing method provided by the present application. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), or the like.

[0128] In a specific implementation, the present application further provides a computer program product. The computer program product includes executable instructions, and when the executable instructions are executed on a computer, the computer is caused to execute some or all of the steps in the embodiments of the encryption processing method provided by the present application.

[0129] The embodiments of the present application further provide a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions cause the computer to execute the encryption processing method provided by the embodiments of the present application.

[0130] The above non-transitory computer-readable storage medium can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (hereinafter referred to as ROM), an erasable programmable read-only memory (hereinafter referred to as EPROM), or a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, apparatus, or device.

[0131] A computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which computer-readable program code is carried. Such a propagated data signal may take many forms, including - but not limited to - an electromagnetic signal, an optical signal, or any suitable combination of the foregoing. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.

[0132] The program code contained on a computer-readable medium may be transmitted using any appropriate medium, including - but not limited to - wireless, wire, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0133] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solutions in the embodiments of the present application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present application.

[0134] For the same or similar parts among the various embodiments in this specification, reference can be made to each other. In particular, for the device embodiments and the terminal embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. An encryption processing method, characterized in that: include: Get the network data to be transmitted; Determining encryption characteristics based on the data type and data volume of the network data; The network data is encrypted based on an encryption process that matches the encryption feature.

2. The method according to claim 1, characterized in that The determining of the encryption feature based on the data type and data volume of the network data includes: Determining a key exchange algorithm based on the data type of the network data; A data encryption mode is determined based on the data volume of the network data, and the data encryption mode includes hardware encryption or software encryption.

3. The method according to claim 2, characterized in that The determining of the data encryption mode based on the data volume of the network data includes: The data encryption mode and key length are determined based on the data volume of the network data.

4. The method according to claim 2 or 3, characterized in that: The determining of the key exchange algorithm based on the data type of the network data comprises: Identify a data type of the network data, where the data type is used to indicate an application scenario of the network data; A key exchange algorithm matching the data type of the network data is determined based on a pre-stored data algorithm list.

5. The method according to claim 2 or 3, characterized in that: The determining of the data encryption mode based on the data volume of the network data includes: When it is detected that the data volume of the network data exceeds a first threshold, determining that the data encryption mode of the network data is software encryption; When it is detected that the data volume of the network data does not exceed the first threshold, it is determined that the data encryption mode of the network data is hardware encryption.

6. The method according to claim 3, characterized in that The determining the data encryption mode and the key length based on the data volume of the network data includes: When it is detected that the data volume of the network data is in the first interval, determining that the data encryption mode of the network data is software encryption and the key length of the network data is the first length value; When it is detected that the data volume of the network data is in the second interval, determining that the data encryption mode of the network data is software encryption and the key length of the network data is the second length value; When it is detected that the data volume of the network data is in the third interval, determining that the data encryption mode of the network data is hardware encryption and the key length of the network data is the first length value; When it is detected that the data volume of the network data is in the fourth interval, determining that the data encryption mode of the network data is hardware encryption and the key length of the network data is the second length value; The covered value intervals from large to small are the first interval, the second interval, the third interval and the fourth interval, and the first length value is smaller than the second length value.

7. The method according to claim 3, characterized in that The method further comprises: Determining a first key length based on the amount of the network data; Receiving a second key length sent by a peer device; A minimum value between the first key length and the second key length is determined as a key length of a session key.

8. The method according to claim 1, characterized in that The method further comprises: When it is detected that the usage time of the session key exceeds a preset time threshold, a new encryption feature is determined based on the data type and data volume of the network data, and the network data is encrypted based on an encryption process matching the new encryption feature.

9. An encryption processing device, characterized in that: include: An acquisition module, used for acquiring network data to be transmitted; A determination module, configured to determine an encryption feature based on a data type and a data volume of the network data; An encryption module is used to perform encryption operations on the network data based on an encryption process that matches the encryption feature.

10. An electronic device, characterized in that: The electronic device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device executes the method according to any one of claims 1 to 7.

Images