End-to-end data encryption processing method

Abstract

The present invention proposes an end-to-end data encryption processing method, which aims to use the advantages of edge computing to solve the encryption performance bottleneck problem caused by resource constraints of IoT devices. The method adopts a hybrid mechanism combining identity-based encryption (IBE) and traditional public key encryption (such as RSA) to build multi-level end-to-end secure communication between devices, edge nodes and the cloud. The device generates a session key and uses IBE to encrypt sensitive data. The edge node uses proxy re-encryption to convert the session key and undertakes some complex asymmetric key calculations, while the cloud uses the traditional public key to decrypt the session key. Key negotiation based on elliptic curve cryptography (ECC) is used between resource-constrained devices and the edge to ensure forward security. The present invention also introduces a key management mechanism based on threshold signatures to improve the availability of the system. Theoretical analysis and simulation experiments show that compared with traditional schemes, the hybrid method can significantly reduce the computing and communication overhead of the device side while ensuring end-to-end security, providing an efficient and flexible encryption scheme for IoT applications.

Description

Technical Field

[0001] The present invention relates to the field of encryption technology, and in particular to an end-to-end data encryption processing method. Background Art

[0002] With the rapid development of IoT technology, a large number of resource-constrained IoT devices have been widely deployed, generating a massive amount of sensitive data. Protecting the confidentiality, integrity and privacy of this data has become a major challenge facing IoT systems. End-to-end encryption is considered an effective means to ensure data security, but traditional encryption schemes such as RSA and AES face many difficulties in their application on resource-constrained devices. On the one hand, asymmetric cryptographic algorithms have high computational complexity, which consumes a large amount of computing resources and energy of the device, affecting battery life. On the other hand, key management is complex, involving issues such as key generation, distribution, storage and update. Therefore, how to achieve efficient, secure and easy-to-manage end-to-end encryption in a resource-constrained environment has become a problem that needs to be solved urgently.

[0003] The main challenges in implementing end-to-end encryption for IoT include the following:

[0004] (1) IoT devices have limited resources. Most IoT devices, such as sensor nodes, use low-power microcontrollers and wireless transceivers, with very limited computing power, storage space, and battery capacity. Traditional asymmetric cryptographic algorithms, such as RSA, require a key length of at least 2048 bits, which is computationally intensive and difficult to implement efficiently on these devices.

[0005] (2) IoT application scenarios are diverse. IoT devices are diverse, with different communication modes (such as one-to-one, one-to-many, many-to-many, etc.), different data types (such as short messages, multimedia data streams), and different requirements for latency, reliability, and security. Traditional "one-size-fits-all" encryption schemes are difficult to meet such flexible and changeable requirements. Targeted optimization design is required in combination with specific application scenarios.

[0006] (3) Key management is difficult. In large-scale IoT deployments, keys need to be configured and managed for a large number of devices. Key generation, distribution, storage, backup, update, and revocation all face many challenges. Centralized key management solutions may become performance bottlenecks and single points of failure, while distributed solutions may introduce consistency issues. It is necessary to balance the security, scalability, and availability of the system. Summary of the invention

[0007] In view of the problems in the prior art, the present invention proposes an end-to-end data encryption processing method, which combines IBE with traditional public key cryptography to build a layered end-to-end secure communication between IoT devices, edge and cloud, and reduce the computing and communication overhead on the device side.

[0008] The system model of the present invention includes a device layer, an edge layer, and a cloud layer. The device layer is composed of a large number of resource-constrained IoT devices (such as sensors, actuators, wearable devices, etc.), which are responsible for sensing the environment and controlling objects. The edge layer is composed of edge nodes (such as gateways, micro base stations, routers, etc.) deployed near the devices, which have certain computing, storage, and network resources and can perform some tasks locally. The cloud layer provides powerful data storage, processing, and sharing capabilities.

[0009] The present invention pre-registers a unique identifier (such as MAC address, IMEI, etc.) for each device, and the cloud maintains the mapping relationship between the device identifier and the corresponding public key. There is a two-way security authentication mechanism between the device and the edge, and between the edge and the cloud, such as a PKI-based digital certificate or pre-shared key. There is no long-term online secure channel between the communicating parties. Attackers may eavesdrop or tamper with data on any communication link, but cannot crack the cryptographic algorithm or side channel attack to obtain the private key. In addition, edge nodes may be compromised, but not most of them at the same time.

[0010] In view of the limited resources and diverse application requirements of IoT devices, the present invention adopts a layered hybrid end-to-end encryption mechanism consisting of IBE and traditional public key cryptography. The process is as follows:

[0011] (1) The device uses its own private key (such as an ECC private key) to generate a session key, and uses the key to symmetrically encrypt (such as AES) sensitive data, and uses the IBE public key to encrypt the session key. The IBE public key can be obtained from the identification ID mapping, and the present invention selects the device identifier as the ID.

[0012] (2) After receiving the ciphertext, the edge node first uses proxy re-encryption (PRE) to convert the IBE encrypted session key into a ciphertext encrypted by the preset RSA public key, and then directly forwards the symmetrically encrypted ciphertext of the device. Here, the Edge can only access the session key ciphertext but cannot obtain the plaintext.

[0013] (3) The cloud uses the corresponding RSA private key to decrypt the session key ciphertext, and then uses the session key to decrypt the data ciphertext sent by the device to obtain the plaintext data. Finally, the cloud can encrypt the response message with the device's IBE public key and send it back.

[0014] Throughout the process, end-to-end data confidentiality is protected by session keys, and key confidentiality is first protected by IBE and then by RSA through Edge conversion. IBE key pairs are mapped by device identities to avoid pre-distribution and storage, and RSA key pairs can be pre-set on the edge and cloud. Since IBE decryption is computationally expensive, it is completed by the cloud with stronger computing power after conversion. Therefore, this mechanism has low computing overhead on resource-constrained devices while ensuring end-to-end security.

[0015] Between resource-constrained devices and edge nodes, the present invention uses the key agreement scheme ECDH (Elliptic Curve Diffie-Hellman) based on elliptic curve cryptography (ECC) to establish a shared key to ensure forward security. The device and edge respectively select the ECC private key to generate the public key, exchange and calculate the shared key for subsequent session key encryption and integrity verification. Since the ECDH key length is short (160-256bit), the calculation amount is small, which is very suitable for IoT devices.

[0016] In order to further reduce the key management overhead on the device side, the present invention introduces a key management mechanism based on threshold signatures at the edge node. A (t, N) threshold signature scheme is composed of N edge nodes, and each node holds a partial private key. The device only needs to verify the public key certificate jointly generated by at least t nodes to ensure the validity of the certificate. The master key (Master Key) of the IBE system is also distributed and stored in each edge node using threshold secret sharing. When the device requests the IBE private key, more than t nodes jointly generate partial private keys and then aggregate them, which can tolerate node loss to a certain extent.

[0017] In the proposed hybrid mechanism, edge nodes not only forward encrypted data between devices and the cloud, but also actively participate in encryption calculations, including the following two steps:

[0018] (1) ECC key negotiation: The device uses ECDH to negotiate a shared key with the edge node, which requires ECC scalar multiplication. A complete ECC-256 scalar multiplication requires about 1,500 large integer (256-bit) multiplications, which is a large amount of computation for the MCU. This solution uses edge assistance to generate a one-time ECC public and private key pair for the device. The device only needs a small amount of modular multiplication and hash operations to confirm the shared key, greatly reducing the computational complexity.

[0019] set up is the base point of ECC, n is the order of the ECC group, and the private key of the device is , the private key of the edge is , the corresponding public key is and The device and the edge share a seed key in advance The negotiation process is as follows:

[0020] Edge Nodes:

[0021] (1) Select a random number

[0022] (2) Calculation

[0023] (3) Calculation

[0024] (4) Calculation

[0025] (5) Send Give equipment

[0026] equipment:

[0027] (1) Receive After that, calculate

[0028] (2) Verification

[0029] (3) If verification succeeds, calculate the shared key

[0030] in is a cryptographic hash function. Since hash and modular multiplication operations are much smaller than ECC scalar multiplication, the amount of computation on the device side is significantly reduced. At the same time, even if the edge node knows the private key of the device ,because Different each time, the negotiated shared key Also different, forward safety is guaranteed.

[0031] (2) Proxy re-encryption of session keys:

[0032] The edge node uses the PRE mechanism to encrypt the session key ciphertext encrypted by IBE Convert to RSA encrypted ciphertext , the cloud can directly use the RSA private key to decrypt. and They are the IBE public and private key pairs of the device, and For the RSA public and private key pair in the cloud, the converted key is , where N is the modulus of RSA. The conversion process is:

[0033] .

[0034] During the entire conversion process, the edge node cannot obtain the plaintext information of the session key, thus ensuring end-to-end confidentiality. The cloud decryption is:

[0035] . BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 This is a system structure diagram provided by the present invention. DETAILED DESCRIPTION

[0037] The following further describes an end-to-end data encryption processing method proposed by the present invention in conjunction with the accompanying drawings.

[0038] like Figure 1 As shown, the present invention considers a typical three-layer IoT system architecture, including a device layer, an edge layer, and a cloud layer. The device layer is composed of a large number of resource-constrained IoT devices (such as sensors, actuators, wearable devices, etc.), which are responsible for sensing the environment and controlling objects. These devices usually use low-power microcontrollers and wireless communication modules, such as MCUs based on the ARM Cortex-M series and wireless protocols such as Zigbee / BLE, and their computing and storage capabilities are very limited. The edge layer is composed of edge nodes (such as gateways, micro base stations, routers, etc.) deployed near the devices, which have certain computing, storage, and network resources. For example, embedded platforms such as Raspberry Pi and industrial computers are used, equipped with GB-level memory and multi-core CPUs, and some data processing and security management tasks can be performed locally. The cloud layer provides powerful data storage, computing, and application service capabilities, usually using high-performance server clusters and virtualization technologies, and is connected to edge nodes through a high-speed network.

[0039] The present invention pre-burns a unique device identifier (such as MAC address, IMEI, etc.) for each device, and the edge node and the cloud can identify and authenticate the device based on the identifier. The cloud acts as a trust anchor and is responsible for managing the binding relationship between the device identifier and the public key. Short-range wireless communication is used between the device and the edge, and a secure wired or cellular network is used between the edge and the cloud. There is no long-term online direct secure channel between the communicating parties. Attackers may eavesdrop or tamper with data on the wireless channel, but cannot crack the cryptographic algorithm itself. In addition, edge nodes may be compromised.

[0040] In view of the limited resources and diverse application requirements of IoT devices, this invention uses a layered hybrid mechanism that integrates symmetric encryption, public key encryption, and identity-based encryption to balance efficiency and security. The overall process is as follows:

[0041] (1) The device generates a session key. The device first generates a random number as the symmetric encryption session key (denoted as ), which is used for subsequent encryption and decryption of sensitive data. The session key uses an algorithm with sufficient security strength and key length, such as 128-bit AES. Symmetric encryption is used because its computational efficiency is much higher than public key encryption and is more suitable for devices with limited resources.

[0042] (2) The device encrypts data and session keys. , the device collects the original data Perform symmetric encryption to obtain data ciphertext To ensure data confidentiality, the encryption algorithm should select a block cipher or a serial cipher with sufficient security strength, such as AES, ChaCha20, etc. At the same time, in order to protect the confidentiality of the session key itself, the device uses identity-based encryption (IBE) public key right Encrypt and get the key ciphertext .in It is mapped from the device identifier (such as MAC address) and does not need to be distributed in advance. The advantage of IBE over the traditional public key system is that it does not require certificate management and the key can be revoked at any time.

[0043] (3) Edge node data forwarding and key conversion. The device forwards the encrypted data and session key Sent to edge nodes. Direct forwarding by the edge , while Perform proxy re-encryption to convert it from IBE ciphertext to traditional public key (such as RSA) ciphertext, denoted as .Conversion Key The IBE master private key and RSA public key are exported from the cloud-hosted IBE master private key and RSA public key. The conversion can be completed. The reason for introducing this conversion step is that the decryption calculation cost of IBE is high and it is not suitable to be directly implemented on resource-constrained devices, while RSA decryption efficiency is higher.

[0044] (4) Cloud data decryption. The cloud receives and After that, first use the preset RSA private key to decrypt Get the session key , and then use Decryption Get plaintext data Finally, the cloud can call application services to store, process, and distribute data.

[0045] It can be seen that in the end-to-end communication process of the above hybrid mechanism, sensitive data is always transmitted and stored in ciphertext, and its confidentiality is protected by the session key. The protection of the session key itself has undergone hierarchical authentication and authorization from the device to the edge and then to the cloud, which not only reduces the computing burden of the device, but also avoids the exposure of plaintext at the edge node. At the same time, the data and key transmission channels are independent of each other, further reducing security risks.

[0046] In order to ensure forward security of communication and reduce key distribution overhead between resource-constrained devices and edge nodes, this solution adopts the key agreement scheme ECDH based on elliptic curve cryptography (ECC). The device and edge nodes select ECC private keys respectively. and , calculate the corresponding public key and ,in The two parties can independently calculate the shared key by exchanging public keys through an authenticated channel (such as the device burning the edge public key, and the edge obtaining the public key corresponding to the device identifier). .

[0047] The security of ECDH is based on the difficulty of the elliptic curve discrete logarithm problem. As long as sufficiently secure elliptic curve parameters (such as NIST P-256 / SM2) are selected, it is difficult for an attacker to recover the private key from the public key even if he eavesdrops on the communication, thus ensuring that the session key cannot be cracked. In addition, since both parties generate a new random private key for each negotiation, even if the private key is leaked at some point, the past communication data will not be affected, ensuring forward security.

[0048] The core of the IBE system is to use user identity information (such as ID, attributes, etc.) directly as the public key, avoiding certificate-based key distribution and storage. However, the private key of IBE needs to be generated by a trusted third-party key generation center (KGC), which is costly for a large number of dispersed devices in the IoT scenario. In addition, KGC holds the master key (MSK), which may lead to "hosted" privacy leakage.

[0049] To this end, this solution introduces distributed KGC at the edge layer, where multiple independent trusted nodes jointly generate and manage the IBE master key using the secure multi-party computing (MPC) protocol. edge nodes, using Threshold secret sharing scheme, the master key Split into Subkey , distributed to each node respectively. Nodes can be jointly recovered , and less than Nodes cannot obtain any Each node independently generates the IBE private key fragment corresponding to the device , and then aggregated into a complete private key The private key generation process does not require the participation of the device, which greatly saves communication and computing costs.

[0050] Thanks to the threshold characteristics, this scheme can tolerate less than The failure or loss of a node can flexibly balance security and availability. In addition, since the private key fragments are independently generated by multiple nodes, even if a node is compromised, it is difficult to recover the complete private key, effectively preventing the "custodial" privacy leakage. Compared with centralized key custody, this solution improves the robustness of the system while ensuring privacy.

[0051] Since the encryption and decryption computational complexity of IBE is high, it will bring a heavy burden to resource-constrained devices. Therefore, this solution further utilizes the computing resources of edge nodes to reduce the pressure on terminals and achieve a balance between security and efficiency.

[0052] Specifically, after the device generates a session key, it first encrypts it with the IBE public key to obtain , and then use the IBE private key right Perform "re-encryption" to obtain The re-encryption algorithm maps the original ciphertext to the new ciphertext without decrypting the plaintext, and the computational cost is much lower than the original IBE. and The edge node can send "Unseal" to the original ciphertext , and then perform subsequent proxy re-encryption. Although the device pre-calculates IBE and then encrypts it, it adds a small amount of overhead, but it can avoid the private key being offline and is safer.

[0053] Before system deployment, complete the following steps in an offline environment:

[0054] (1) Select security parameters, including elliptic curve parameters (such as NIST P-256), IBE master key length (such as 256 bits), session key length (such as 128 bits), etc.

[0055] (2) Generate an IBE master key. Select Trusted nodes use MPC protocols such as Shamir secret sharing to jointly generate the master key , and distribute subkeys .

[0056] (3) Pre-set edge nodes. Burn the corresponding and the proxy re-encryption key and establish a secure channel with trusted nodes.

[0057] (4) Cloud key generation. The cloud generates RSA key pairs autonomously. , private key Self-sustaining, public key Distributed to each edge node through a trusted channel.

[0058] When a new device accesses the network, it needs to complete identity authentication and key binding. The main steps are as follows:

[0059] (1) The device generates an ECDH private key through the hardware security module , public key Random The two are sent together to the nearest edge node through an authentication channel (such as manual pairing).

[0060] (2) The edge node verifies the device identity (such as checking the physical anti-counterfeiting mark) and sends Report to the cloud.

[0061] (3) The cloud binds the device ID in the device information database With public key The mapping relationship and generate a device certificate The certificate is signed with a cloud-based private key and can be verified online by edge nodes and other devices.

[0062] (4) The edge node receives After that, first verify the certificate yourself, then send it together with your own ECDH public key , proxy re-encryption public key Send them to the device together.

[0063] (5) Equipment verification , extract from The device is now registered and can be used and Establish trusted connections with other entities.

[0064] Data encryption transmission

[0065] (1) Equipment data collection , randomly generate AES-128 bit session key , use it to encrypt data to get ciphertext .

[0066] (2) The device calls the IBE algorithm ENC and uses its own identifier As public key encryption get .

[0067] (3) The device calls an authentication encryption algorithm such as ECIES or AuthEncrypt, using the ECDH key Protect , append metadata such as timestamp ,generate .here Use fast algorithms such as HMAC or CMAC to prevent ciphertext from being tampered with.

[0068] (4) Device private key For the whole Make a digital signature ,and Send to edge nodes together .

[0069] (5) Edge nodes are used first Verify the signature and use the ECDH key Unlock and verify ,extract , .

[0070] (6) The edge node calls the PRE algorithm and uses the proxy key Will Convert from IBE ciphertext to RSA ciphertext After conversion, the length of the ciphertext will increase, but the original text will not be disclosed.

[0071] (7) The edge node uses its own RSA private key right and Signature, together with the original Forward to the cloud .

[0072] (8) Cloud use Verify the edge signature and then use Decryption Get the session key .

[0073] (9) Cloud use Decryption Get plaintext data , combined with Metadata storage.

[0074] (10) The cloud can selectively return some data to the device. The steps are similar and are omitted here.

[0075] To ensure long-term security, each key needs to be updated regularly.

[0076] (1) Session key It is randomly generated for each communication and does not need to be updated.

[0077] (2) Device ECDH key It can be solidified after registration, and if leaked, re-registration is required.

[0078] (3) Edge ECDH key Regular updates are generated offline by administrators and distributed securely.

[0079] (4) Proxy re-encryption key Synchronous updates can be generated and issued on demand by the cloud or third-party KMS.

[0080] (5) Cloud RSA key pair Synchronous updates, private keys are stored in the cloud, and public keys are distributed through the edge.

[0081] (6) IBE master key Split into , refreshed regularly by trusted nodes and then redistributed securely.

[0082] The beneficial effects of the present invention are as follows:

[0083] End-to-end data confidentiality is ensured by session keys protection, and The confidentiality of the device to the edge is protected by IBE public key encryption ( From the device ID mapping), the edge to the cloud is converted by the RSA public key after the PRE Protection. Since IBE and RSA are both mature public key cryptography systems, the confidentiality of the key can be ensured by selecting a key of sufficient length (such as 256-bit security strength parameters for IBE and 2048-bit and above for RSA). At the same time, the private keys are properly kept by their respective holders, and the edge nodes cannot obtain the plaintext of the session key.

[0084] This solution uses an end-to-end message authentication code (MAC) to ensure the integrity of the data sent and received by both parties. The device and the cloud use the shared key (denoted as ) as the MAC key, calculate the MAC value for the sent ciphertext and attach it to the message. Only the device and the cloud know, and the intermediate nodes (including the edge) cannot forge a valid MAC value. For downlink communication from the cloud to the device, a similar method is used, and the MAC value of the downlink message is calculated by the cloud. This scheme achieves forward security by introducing fresh random numbers. First, each time the device and the edge node run ECDH, the edge selects a different random number. , thereby deriving different device one-time private keys Even if the private key is leaked, it will only affect the current session. They are all randomly selected and do not rely on long-term keys. Therefore, this scheme can effectively prevent attacks caused by key leakage.

Claims

1. An end-to-end data encryption processing method, characterized in that: The system in which the method is applied includes: device layer, edge layer and cloud layer. The system adopts a layered hybrid end-to-end encryption mechanism, which is composed of IBE and traditional public key cryptography. The process is as follows: (1) The device uses its own private key to generate a session key and uses the key to symmetrically encrypt sensitive data. It also uses the IBE public key to encrypt the session key. The IBE public key is obtained from the identity ID mapping, and the device identifier is selected as the ID. (2) After receiving the ciphertext, the edge node first uses proxy re-encryption to convert the IBE encrypted session key into one encrypted by the preset RSA public key, and then directly forwards the symmetric encrypted ciphertext of the device; (3) The cloud uses the corresponding RSA private key to decrypt the session key ciphertext, and then uses the session key to decrypt the data ciphertext sent by the device to obtain the plaintext data; finally, the cloud encrypts the response message with the device's IBE public key and sends it back; The edge layer is composed of edge nodes deployed near the device. The edge nodes adopt a key management mechanism based on threshold signature, which specifically includes: a (t, N) threshold signature scheme is composed of N edge nodes, each node holds a partial private key, and the device only needs to verify the public key certificate jointly generated by at least t nodes to ensure the validity of the certificate. The master key of the IBE system is also distributed and stored in each edge node in a threshold secret sharing manner. When the device requests the IBE private key, the partial private key is jointly generated by more than t nodes and then aggregated; the edge node participates in encryption calculations, specifically including: ECC key negotiation and proxy re-encryption of session keys; the proxy re-encryption of the session key includes: the edge node uses the PRE mechanism to convert the IBE encrypted session key ciphertext Convert to RSA encrypted ciphertext , the cloud directly uses the RSA private key to decrypt, set and They are the IBE public and private key pairs of the device, and For the RSA public and private key pair in the cloud, the converted key is , where N is the modulus of RSA, the conversion process is: ， Cloud decryption is: 。 2. The method according to claim 1, characterized in that The device layer is composed of resource-constrained IoT devices, which are responsible for sensing the environment and controlling objects. The edge layer is composed of edge nodes deployed near the devices, which have certain computing, storage and network resources and perform some tasks locally. The cloud layer provides powerful data storage, processing and sharing capabilities.

3. The method according to claim 1, characterized in that The ECC key negotiation includes: the device negotiates a shared key with the edge node using ECDH, which requires an ECC scalar multiplication operation. is the base point of ECC, n is the order of the ECC group, and the private key of the device is , the private key of the edge is , the corresponding public key is and , the device and the edge share a seed key in advance The negotiation process is as follows: Edge Nodes: (1) Select a random number (2) Calculation (3) Calculation (4) Calculation (5) Send Give equipment equipment: (1) Receive After that, calculate (2) Verification (3) If verification succeeds, calculate the shared key in A cryptographic hash function.

Images